[haiku-development] Re: Question about /system and /boot/system

  • From: Ryan Leavengood <leavengood@xxxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Wed, 2 Mar 2011 08:43:38 -0500

On Wed, Mar 2, 2011 at 6:46 AM, Oliver Tappe <zooey@xxxxxxxxxxxxxxx> wrote:
> Still, the mixing folders approach does mean that /boot/system, /boot/common
> and /boot/home/config would be *read-only* except for the "shine-through"
> folders.

I think if you are going to be putting most of the Haiku system
components into packages anyhow, we might as well go the full distance
and do the above. I don't even think there are that many legacy issues
because we control /boot/system and /boot/common did not exist in
BeOS. Plus we need to be realistic in that there aren't all that many
legacy BeOS applications which people still use, and theoretically if
people REALLY liked certain software and we had no replacement they
could be put into packages too.

> I can live with that as long as there is at least one folder for installing
> non-packaged software.

Yes we would need that for potentially three reasons:

1. For legacy software not available in packages.
2. For people who just don't want to use packages, even for modern
Haiku software.
3. For developers or other people who will compile their own (or
other) software and install it without using packages. Though if it
was made really easy to make a package from external projects this
would be less of an issue.

But either way I think it would be good to predefine this
"non-package" location so to provide sort of a standard, unlike Linux
where sometimes people might use /usr/local and sometimes /opt or
sometimes something else.

Also given 2 and 3 I don't know if legacy is a good name. Maybe
something as specific as "non-packaged" would be better.

Something somewhat related that I was just thinking about is lower
performance if even system components will be in packages. But it
might actually provide performance benefits since the system package
could be just read in one go (and should be contiguous on the disk, at
least after the first install), so it sort of acts like a cache file
already. Of course I could be completely wrong in this. Though long
term I could see disk tools which preferentially defragment and align
the system package file to improve loading performance.

Another issue is updating the system package. Since it will probably
be rather large and not all components would need updating at once, I
think this does show the need for efficient binary updating a la
Chrome which I had emailed about before.


Other related posts: