[haiku-development] Re: software organization/installation
- From: "Michael Phipps" <michael.phipps@xxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Mon, 16 Feb 2009 09:24:34 -0500
Brecht said:
> The most interesting ports for Haiku would be libraries and command line
> utilities.
100% agreed. But given all of the versioning issues, would you really want to
have end users install a shared library as a separate entity? A system wide
package manager with dependency tracking would fix this, but I still haven't
seen one that always works for me. I should state that I used Fedora (because
of work) for 2 years (2005-2007) exclusively (while at work).
Christian said (regarding the lack of dependency issues):
> Of course not. This may be related to the fact that Beos mostly had no
> advanced software to speak of.
I can't agree with this. Gobe, for example, was as good as, at least, MS Works,
if not quite office, back in 1998 or so. Obviously state of the art has
progressed and BeOS software has languished somewhat. The issue, though, isn't
"advanced" software. The issue is how much of what you will NEED for building
apps is built in to the system. You further on say:
> LOL. Speaking for Windows only: these issues seem to have been solved,
> because by now there is a lot of polished high quality software around,
I never said that there wasn't. What I did say was that Windows and Linux *AS
THEY ARE MADE* are not easy to write software for. For many years, every
Windows app that I saw was distributed with the run time from the tool that
built it. msvc42.dll or vb???.dll. Delphi didn't do this by default, so their
apps looked better, but they compiled it all into your .exe. Until Vista, which
includes .Net (3, I thiink), most decent Windows apps were bloated because
Windows itself didn't include a decent development library. By the way - I
wrote a couple of MFC apps and more than a few Delphi apps, so I have been
there. ;-D
Talking about drivers and command line tools - there are fairly trivial ways to
make this work in bundles. I mentioned one in an earlier email, I think -
create a command line utility (say, python) as a soft link to the bundle
mounter. The soft link has an attribute that points to the bundle. Another way
would be to create a custom data type (bundle link) that contains the bundle
and the file within to invoke, so something like:
pythonw.blk:
bundleLink // for mime detection
python-3.0.0
/python-3.0.0/bin/pythonw.exe
Simple and easy. Either way should work for drivers.
Finally, Cristian said:
> IMO, bundles would be a nice addition to an install system, but can't solve
> all problems of software deployment and management.
Apple seems to disagree. Have you tried a Mac? Their system works really well.
Better than anything I have ever seen, including Amiga (1988-1994), Windows
(1994 - today), Linux (1991 - today), BeOS (1996 - today), OS X (2008) and Unix
(1991- today). I am not a zealot for any given system - everybody has their
good parts and bad parts. Bundles are the best part, IMHO, of OS X. :-D
Michael
Other related posts:
