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