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. -- Regards, Ryan