Firefox 2 on Dapper

[Donn]

> > So, it's really a result of the rapid change of Linux apps, this synching
> > problem between libraries and apps?
> It happens with Windows as well.  Search a windows computer for a common
> DLL and you'll find many copies of identical and different versions.
> Improvements mean new versions.
Yeah, but then why does new software (largely) run on old versions of Windows 
and not on older versions of Linux, I mean if the same happens on Windows?

> > My problem is that new apps won't run on old distro's... you have
> > explained that's because the new apps have new demands. Right?
> Right.
Okay ... These new demands - they are met by new versions of other libraries 
right? So it's a concerted forward movement along all fronts. Linux is an 
army marching forwards on all fronts, all the time. Windows lurches forward  
every few years and fights a rear-guard action to keep that land supported.

> > Oh, so they have to mess with the source code and re-compile things to
> > meet older library supplies.
> Sometimes.  Other times it is just adjusting the dependency needs stored in
> a deb so that apt knows that x need is also satisfied by y lib.
Alright, so a certain amount of stuff can be done to new apps such that they 
will run on older distros, but it's hard work, time-consuming and only 
supports a limited number of versions backwards. Right?
Windows apps can go backwards because they are like a small army carrying all 
their kit with them every time.

I would say that Linux can't do that because of the radical change along all 
fronts (all it's various libraries and Gnu tools and other small tools) that 
leaves an old distro literally stranded in time.

(I have seen Klick try this trick, not too successfully but it's a start I 
guess.)

> > What is the reason for the seeming stability (i.e. backwards support) of
> > Windows then?
> It is a different programming philosophy.  You may wish to read the
> introduction to Eric S. Raymond's book, The Art of Unix Programming". 
> (maybe the "zen" of Unix programming, I lent my copy and never got it back.
I'll have to go hunting. Is it to do with the "small tools piped together" 
thing?

> MS committed to backward compatibility with most of Windows.  Some say that
> is why it is so cumbersome compared to Linux (Look at the size of a Linux
> vs. Windows package that serves a similar need.)
I dunno, after a few apt-gets I am shocked by the number of dependencies that 
then inflate things to many megabytes. It seems much of a muchness mostly. 
What's the difference between Nero at 40Mb and K3B at 2Mb (plus cdrecord + 
cdrao + mkisofs + growiso + Qt + KDE + etc + etc) ?

It wouldn't be so bad if those deps didn't change so often.

Perhaps there is a cool command-line to find all deps and tot their sizes up. 
That would be a way to see the facts. I might be totally wrong in my above 
contention.

> Whenever possible, Linux programs strive to separate the interface from the
> engine, allowing other developers to provide alternative interfaces.
> Likewise, a gui can use alternative engines.
Yes and no. The Model View Controller thing is an ideal that all programmers 
on all platforms should strive towards. Some make it, some don't (I have yet 
to figure that stuff out!). I think the essential "command line" tool idea 
becomes quite easy to wrap in a gui, but this is not a result of striving, 
it's more a result of wanting to make the cli easier to use.

> Windows, OTOH, tends to distribute proprietary programs in self contained
> packages.  Everything you need to run the program, other than the OS comes
> in setup.exe.
I have distributed VB apps in my time. Linus forgive me, I have sinned :D
The thing is that I only had to include the stuff that I knew was not 'out 
there', like fancy or custom activex controls and then the runtime libs. 
Other than that I could rely on rock solid, never-changing:
1. APIs
2. GUI functionality
3. Filesystem layout (okay, this one got a bit hairy in places)
If the dlls that my app contained were fresher than the ones on the target 
machine, they would simply *replace* those. Other apps using that same dll 
would continue to work. No problems - most of the time.
Okay - I had to use the latest version of Internet Explorer - that sucked. I 
didn't include it - I just declared it necessary and left it to the user. 

> This makes it easy to install a program and get it to work, 
> but results in many copies and versions of some common components, results
> in bloat and may result in conflicts.
I may be wrong, but I'm fairly sure from my experience that newer versions of 
dll's would overwrite (replace) older ones. Perhaps that's what I *thought* 
was happening but something else did instead. Regardless, with drive space 
the size it is today, I won't lose much sleep over multiple versions of 
libBlah if they mean I can run Firefox 2 on Dapper!

> same.  This model is the result of closed source.  A program needs to be
> fully self contained because available components are closed and
> inaccessible to other programs.
I must disagree for my above stated reasons. Again, I could be wrong.

Perhaps there is a better system on Windows for keeping track of versions of 
libraries such that they do not clash and can co-exist. I dunno, I'm winging 
it here.

> In windows you don't have someone maintaining cdrecord.exe so that Nero or
> Roxio or whatever can use it and concentrate on the GUI instead. 
I can't totally agree here either. I used activeX controls that were written 
and maintained by others. You might be right, but my experience was that 
whatever I needed there was some solution out there. I never paid for 
anything, having little money, and so always relied on free solutions -- so 
they are out there for Windows.

> Even if 
> you did, Nero would distribute its own version of cdrecord.exe.  In Linux
> where programs like cdrecord are open and used by other programs, you
> sometimes run into a problem that a gui like k3b version 3.x requires
> cdrecord 4.y or higher for its features.  If your distro provides cdrecord
> 3.y, then you can't upgrade k3b to 3.x.
I see that and I can see how in the mesh of confusing links between packages 
it is easier to simply focus on going forward.

> And it isn't MS so much as windows software
> distributors who are responsible for the forward compatibility.  If they
> need something new to make their program work, they include it if they can.
Okay. What are the reasons that Linux distributors cannot do the same such 
that (for e.g.) Firefox 2 can run on Dapper and Warty?
Is this a result of the largely unpaid for, volunteer nature of open source? I 
suspect it is. It's simply too expensive to keep an app working on distros 
that have been left frozen in time. (I might be repeating myself, this email 
is taking too long!)

> If you don't think Windows has the same problem at least in part, try
> installing iTunes in windows 98.  Can't do it because it relies too much on
> Windows 2000 or greater DRM management.  Same with TurboTax.
Sure, I grant that there are exceptions. I bleev that Vista will do a lot of 
that too.

Thanks for the info.

/d