[haiku-development] Re: software organization/installation
- From: "Michael Phipps" <michael.phipps@xxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Sun, 15 Feb 2009 22:31:54 -0500
Considering shared libraries - yes, they are an issue with ports. Lots of
things are an issue with ports. That's one of the reasons that I am not
thrilled with ported software. Bezilla being the only exception, I think, ports
are software that will never work the Haiku Way. They will never use our
preferences model, they will never use attributes, etc. Now, I do understand
that some things are beyond the realm of what we could do and, in some cases
(gcc for example), ports are "ok". But personally, I think that Haiku should be
about writing new, better software. Chucking legacy - that was one of the
cornerstones of Be's motivation for BeOS. In fact, most of the issues with
doing something better than the way that *nix does it are that it would break
ports. Most of the interesting proposals that have come along that would make
Haiku R2 and beyond much better than existing OS's cause problems with ports.
:-/
Anyway - to answer the couple of questions -
Command line tools are sort of a special case. Since they are installed by
advanced users, if they are a *little* harder to install, I don't consider that
to be a terrible thing. But I don't think that they have to be - the bundle's
default application could be an installer. That would also cover drivers and
add-ons. It breaks the bundle model, though. Maybe the answer is to create a
link of some kind so that when you type "python", the system checks to see if
/python-3.0.0 is mounted; if not, mount it from the bundle. Then run from the
bundle. I think that a soft link with a couple of attributes would do that if
the link pointed to a bundle mounter of some kind. In fact, I like this idea
because I find installing a lot of these *nix applications on BeOS/Haiku to be
scary. They spew files around faster than a Windows Update and to just as many
obscure places. Bundles would mean that I could install/uninstall gcc using
drag and drop! I know that my apache logs would be in /apache/logs instead of
wherever the person who built the package decided to put it (and why does every
*nix distro have a different location for them, I want to know!)
As to the concept the daemon copying files to the /app directory is a security
hole, well, not really. If you click "download" and the app would be in your
~/Downloads directory, how is something that copies it from there into
/app/games/rpg/ creating a security hole? How is adding to the "Leaf menu" a
security hole? It's not like it will automatically invoke it... Anyway, I would
not be at all opposed to an OPTION for a dialog that says "Final Fantasy 254 is
requesting to be added to your Leaf Menu in the games category and the Role
Playing subcategory. Allow/Refuse/Change Category".
Another note on shared libraries - the issue isn't disk space, the issue is
loading them into memory. Shared libraries weren't invented to save disk space.
When two apps use, for example, libbe.so, there is only one copy of libbe.so
loaded into memory at a time (well, there is only one copy of the code; the
auto-initialized variables are loaded once for each instance used; Ingo will
correct me if I am wrong on the details of that).
Michael
Other related posts:
