[haiku-development] Re: I suggest a vote on 3 items
- From: Adrien Destugues <pulkomandy@xxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Tue, 1 Sep 2015 21:59:20 +0200
On Tue, Sep 01, 2015 at 12:42:50PM +0000, jimmy@xxxxxxxxxxxxxxxx wrote:
Hi all,
I appologize in advance if anything I say is upsetting.
As Haiku is a community project,
[citation needed]
I suggest a vote on 3 items:
item #1. I suggest User installed applications should not be installed
in system folder and should be installed in a subdirectory of /home-
This should be an option in pkgman/HaikuDepot. You can of course copy
your packages to ~/config/packages if you wish so already.
Patches to pkgman and haikudepot to allow this are welcome. No vote
needed.
item #2. I suggest implimenting The BeOS "Hold the shift key" instead of
the read-only file system.
Use the non-packaged directory.
We are not going back on the package-FS. While the initial plan was to
have some kind of "overlay" above it to allow writing to the system
directory in a somewhat transparent way, that approach was found to have
two important drawbacks:
1) It has a big impact on performance for all filesystem accesses.
2) It is confusing, as you are never sure if a file comes from a package
or was rewritten.
Moreover, it is not all that useful. I have not yet heard of one thing
that wasn't achievable through other means, either one of:
1) Use of the non-packaged directory
2) Use of shine-through directories (this is what makes the "settings"
folder writable)
3) Manipulating packages instead of messing witrh files directly and
breaking your system
(yeah, being able to "rm /system/kernel" is a very useful feature no one
could live without).
If the beshare package is not done properly and includes unneeded
things, the proper solution is to split a beshare_docs (or even a
beshare_docs_fr, ...) from it, so you don't need to install everything.
This way, other users will benefit from the change as well, and it makes
it easier for the community to share their work on various software.
item #3. I suggest a vote on a file system organization standard.
We have one and we are tied to it because of BeOS compatibility. What to
vote on?
The DeskBar menu is not very good, there were some discussions on how to
improve this. One idea was to provide the menu entries by adding an
attribute to the files, and looking for them with an FS query. There
were a few other ideas discussed, with the goal of making the menu:
1) Automatically get links for newly installed apps
2) Customizable at will
These two goals are conflicting and no obvious solution has been found.
Do you have one?
/home/config uses the standard FS organization. We are bound by the BeOS
API (find_directory) here and we don't have much room for changes
(except adding even more folders and matching constants to the API).
Let's look at home/config on a typicall Haiku install:
* cache: was already there before PM, used by various apps to cache data
* non-packaged: for non-packaged apps.
* packages: for packaged apps
* settings: user settings. Was already there in BeOS, is not going to
move.
* var: apparently unused, but must exist for some apps to work properly
when installed in config.
Again, what to vote on? Do you have changes to suggest?
Again friends, not trying to start a flame war, actually trying to keep
this small community together. It's already breaking up into factions.
Haikuware is a glaring example of that..
For only $30 you can get HAikuware membership, and this may or may not
include a vote right on Senryu, their announced fork. In Haiku, only the
development team gets a vote right - I'm not sure where you got that
"community driven project" from. We can have a vote amongst the devs if
you insist, but I think everyone mostly agrees on the current layout and
nothing will get out of it.
If you want Haiku to change, what we need is not a vote, but
constructive suggestions on how things can be improved. And no "remove
the package management" is not an option. I use it everyday, it works
great, and I don't want to look back. There is probably room for
improvement but we have to stay within the technical constraints of BeOS
compatibility, and find a solution that doesn't involve once again
several man-years of development and throwing away the previous attempt.
--
Adrien.
Other related posts:
