[haiku-development] Re: software organization/installation

  • From: "Michael Phipps" <michael.phipps@xxxxxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Tue, 17 Feb 2009 08:25:34 -0500

> -----Original Message-----
> From: "Christian Packmann" [Christian.Packmann@xxxxxx]
> Date: 02/17/2009 06:52
> To: haiku-development@xxxxxxxxxxxxx
> Subject: Re: [haiku-development] Re: software organization/installation
> 
> 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.

I was going to say Office, and it was closer to Office than Works, but Office 
was more powerful.

> 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.

It is TuneTracker (shout out to Dane!). Actually, I think that the fact that 
there were relatively advanced applications  does impact the discussion because 
we are talking about  what complex applications require. My point is that they 
require very little package manager support and the use of very few shared 
libraries that aren't supplied by the OS. 

> > 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".

:-) First of all, I don't want to sound defeatist - I am very optimistic. :-) 
Actually, there is a LOT of energy going into Haiku itself. I encouraged that 
in my tenure - applications for R5 aren't worth a lot, compared to the near 
alpha we have today. 

> >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.

I understand what you mean by advanced software; it just seems to me that 
installing advanced software is not too much different than installing simple 
software. Compare and contrast installing Gobe on Haiku to installing some 
small Linux apps - I will  use Frozen Bubble. Gobe installed into a directory 
and took a few seconds. Frozen Bubble, on Linux, had to download and install a 
ton of Perl stuff and took minutes to complete. Yes, the package manager 
handled all of that, and the fault is certainly not that of Linux the kernel or 
even the distro. 

> 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. :) 

I boot the Amiga in an emulator every so often. There is still a lot to be 
admired. Not the garish color scheme or the low resolution. But I haven't ever 
seen a more elegant C api for an operating system. :-D
 
> 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.

Agreed, but I don't get what this has to do with installing software.

> >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.

I don't see that at all. Windows development is nearly all .Net, now, with very 
few toolkits and helper libraries, except maybe some 3rd party controls. I was 
on a team that developed some VERY complex Windows software (at least an order 
of magnitude more than Gobe), and we used .Net 3.5 out of the box. I think that 
the Mac is the same way. Linux is the exception, and mostly because it has 
NOTHING out of the box.

> >> 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.

It isn't meaningless at all when the point is the installation of software. 
*IF* developers don't find the need to have a whole bunch of common libraries 
because the functionality is available on each and every Haiku system, the need 
for installers is drastically reduced.

> >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?

I don't think that the couple of third party libraries mentioned above were all 
that commonly used on BeOS, and they were a couple. On Windows and Linux, there 
are TONS of those sorts of "common" libraries, each with a slightly different 
version.

> >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...

It depends on what you are bundling. I advocate bundling anything not part of 
the OS, but then again, I also advocate (for R2+) making sure that libsanta and 
liblayout (already done!) aren't necessary. Just like MS did with .Net - you 
don't need anything beyond .Net.

> >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. :)

I agree, of course, that finding pre-written software is quicker and easier 
than writing your own. But Win32 is doomed. It is NOT the direction that 
Microsoft is headed in. It will be around for a long time, for backward 
compatibility, but it is doomed. And very little new software is being written 
in it.

> > 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.

I would say that any binary builder not written in Python would have to handle 
the mounting itself (which isn't hard); if it isn't written in Python, it would 
be, what, C/C++?
 
> 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.

That is another route - Python could be automounted at boot.

> > 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.

Wow. That's pretty harsh. I guess everyone who HAS tried a Mac, then, doesn't 
like themself? I guess I should have turned down the lucrative contract doing 
iPhone development out of some sense of self respect?

> >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.

NONE of the applications that I downloaded were anything other than bundles 
except gcc. It seems to me that most applications ARE bundles and the OSS stuff 
is the (poor) exception.

> 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.

Every community will have people who choose to go their own way and ignore the 
"standard". Like people who still insist on developing Win16 applications. That 
doesn't make it right, good, acceptable or even scalable. 

> 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.

My point was and is that it is the responsibility of the corner cases (i.e. 
programming environments) to find a way to work with the standard that will 
work for 99% of applications. That's what makes Haiku better, IMHO, than Linux 
for the desktop. If you design for the corner cases, you end up with something 
big and hard to use (linux). If you design for the typical case, while thinking 
about the corner cases and making sure that what they need is POSSIBLE, if not 
trivial, I think that you will do better.

Other related posts: