[haiku-development] Re: software organization/installation
- From: Christian Packmann <Christian.Packmann@xxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Tue, 17 Feb 2009 12:52:14 +0100
Michael Phipps:
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.
"As good as Works" is damnation by faint praise, really. Works was never good.
Urgh, I had to work with it once... painful.
But I agree that Gobe was a piece of advanced software. As was this radio
station management program (don't recall the name). But we were talking about
BeOS in general, and the existence of a handful of great programs doesn't
change my argument.
Obviously state of the art has progressed and BeOS software has languished somewhat.
The state of the art has progressed in leaps and bounds. And BeOS software
developement dropped sharply after Be's demise and basically died in the past
few years, at least in regard to serious projects, not some small utilities.
There are exceptions (e.g. Wonderbrush), but this doesn't change facts about
the BeOS software scene as a whole. The uploads to BeBits have turned into a
trickle, the new uploads on the front page stretch back to early December last
year. I remember times in 2002/3 when the upload list wouldn't even span two
weeks.
It's funny (in a sad way) that Aminet has about an order of magnitude more activity. They also don't have many big projects, but the whole Amiga coding scene seems to be much more healthy than the current BeOS scene.
Anyway, if that's your definition of "languished somewhat", then I'd like to know your
definition of "on the verge of extinction".
The issue, though, isn't "advanced" software.
Yes, it is. Although I should define this better. I mean programs which offer a
range of functionality and flexibility which allow me to use computers for
solving my problems in a manner which I regard as adequate in comparison to the
current development state of the computer industry as a whole.
This is a moving target, not fixed. I was very happy with AmigaOS 1.2 and the available software on my Amiga 1000 in 1987. This changed. Today, I wouldn't even dream of using such a system... okay, maybe in a nightmare. :)
And a system has to fulfill these expecations in order to be successful. Of course these
expectations are always personal, but even the "average" user has different
expectations now than he had in 1998. He expects more from his software, and Haiku will
have to satisfy these expectation in order to be successful.
The issue is how much of what you will NEED for building apps is built in to the system.
This statement in itself is useless. All I "need" is some hardware and a
cross-assembler. What I WANT is a different matter. Again, this is a personal thing,
which can't be precisely quantified. But the trends on other OSs show that programmers
often don't work with native tools for any OS, but use GUI toolkits and all kinds of
helper libraries to achieve their goals, with more and more of the complex projects also
being developed cross-platform on Linux, Windows and OS X. What the system itself
provides is becoming ever more meaningless.
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.
Meaningless statement, as the point doesn't matter in practice, see above. And actually,
even BeOS wasn't "easy to write software for", otherwise we wouldn't have seen
the advent of 3rd-party libs like Santa, liblayout, etc. which were in wide use.
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.
So? Just the same as on BeOS then, with the use of 3rd-party libs already
mentioned. What precisely is the difference?
Delphi didn't do this by default, so their apps looked better, but they
compiled it all into your .exe.
Always a solution, even if ugly. But hey, if the "bundle everything" faction
gets their way, we can experience these bad old days of bloat all over again on Haiku! O
brave new world...
Until Vista, which includes .Net (3, I thiink), most decent Windows apps were
bloated because Windows itself didn't include a decent development library.
Uhm, no. There are enough smart programmers on Windows which can write small,
efficient and good apps without the use of .NET. Finding these programs takes
considerable time of course as there's such an incredible amount of software
for Windows, and lots of crap among that. But it is doable. And it's much
faster than having to write your own program for every second problem you want
to solve. :)
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.
Unless you make the volumes R/W, it won't work for Python. You need write
access to its home directory in order to install packages, and this is a vital
feature. The bundle also needs to be mounted when a read access happens to the
bundles content, without the Python interpreter having been started - some
binary builders may need that when they aren't written in Python itself, or
when you use e.g. a binary builder written in Python26 for building a Python24
binary, with both versions living in different bundles.
But this could, in principle, be solved by the approach Jonas mentioned, with
virtual file systems always being mounted on boot, just that they need to be
R/W. But I'm not sure this is a smart idea. Layering virtual FSs on a real FS
would result in performance impacts for all kinds of file operations, and
especially the required dynamic volume resizing is a problem. So you just end
up trading one set of problems for another set of problems.
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?
No, I like myself.
Their system works really well. Better than anything I have ever seen,
Luckily for them, the Mac dev community seems to understand the advantages and disadvantages of the bundle
system better than you do. I've spent some time on Google and then sifting through Mac dev pages and fora.
Now, I do assume that Mac devs will be able to discern the difference between "mounting an image"
and "mounting an image and then running an installer". And guess what? They do install software.
With a venceance, and all over. This goes for the dev tools like GCC, this goes for Python, for Fink (and its
packages of course), this even goes for user-only software like Microsoft Office 2008 (which of course needs
traditional installation due to its highly modular nature). So, obviously, bundles aren't "the"
general software deployment solution used on OS X.
So, to repeat myself: "bundles would be a nice addition to an install system, but
can't solve all problems of software deployment and management". And the Mac
community obviously agrees with my sentiment.
And to make it clear: I'm not against bundles. I think they would make a nice
addition to Haiku - when used properly. But there are cases when they aren't be
the right solution, that's all.
Christian
Other related posts:
