OT: Next Time you sing happy birthday

[JoeHill]

Ian Petersen left a post-it on the fridge:

> On 8/14/07, James Knott <james.knott-bJEeYj9oJeDQT0dZR+AlfA at public.gmane.org> wrote:
> > JoeHill wrote:  
> > > Empires do not require an enemy to become pretty much ignored and
> > > ineffective. They do it to themselves every time. Beautiful thing to
> > > watch.
> > >
> > >  
> > http://www.eweek.com/article2/0,1759,2168426,00.asp?kc=EWRSS03129TX1K0000616  
> 
> The general "feel" of that article is nice, but the details in it are
> rather questionable.  From the article:
> 
> "[In a Linux-based OS there is] no such thing as a DLL, which Crawford
> described as the second most evil thing in Windows behind ActiveX."
> 
> Doesn't an .so serve the same purpose as a DLL?  I don't know much
> about DLLs, so there could be subtle differences in purpose that I'm
> unaware of, but I though DLL stood for "dynamic link library", or
> something similar, and is therefor basically the same as an .so
> (shared object, right?).

Functionally, they are very similar, ie. they provide functionality that is
'shared' by different applications. In practical terms, they are not even
remotely the same thing. For one thing, there is absolutely no consensus
whatsoever among developers that produce Windows applications in terms of what
is contained in them. Installing an application from one vendor will very often
give you a libray which contains code that is not only redundant and duplicated
many many times on your system (bloat, confusion), but may even go so far as to
conflict with a library installed with software from another vendor (lockups,
crashes, and a security nightmare). Nice.

Contrast this with shared objects on the FOSS side: as far as I know, there is
almost zero probability that my install of imlib2.so will conflict with
anything else, because most every open source developer on the planet knows
exactly what is contained in imlib2.so, and so they have no need to bother
including anything with their software which might duplicate, or worse,
conflict with, the code in imlib2.so. In fact, so far as I know, I have never
ever installed an application on my system which came with its own bunch of .so
files. They rely on package management to make sure that my system will have
all the required shared objects in order to function properly.

Of course, I'm sure this is not 100%. It has never happened to me or anyone I
am aware of, but conflicts or duplication could happen. But comparing that to
what happens on Windows is really not realistic at all.

> Also from the article:
> 
> "We also need to get the different distributions to work on a common
> release cycle,"
> 
> I suppose you might convince Suse, Red Hat, and Ubuntu to come up with
> some kind of general intention to _try_ to adhere to a common release
> schedule, but outside of that this suggestion seems like complete
> lunacy to me.

Perhaps, I don't know. I'm not sure how significant this is to the success of
LInux, though. The numbers in the article which clearly show that Linux is
making huge gains in terms of users and developers seem to contradict the idea
that a common release cycle is a basic prerequisite to success. Sure, it would
_help_, but it does not appear to holding us back, eh?
 
> It may be the case that Vista is driving Windows users to Linux, but
> the article seems to have weak foundations....

Two minor points (neither of which you have demonstrated to be of any
consequence) is is 'weak foundations'?

-- 
JoeHill
++++++++++++++++++++
 Lucy Liu: That was incredible, Bender. You're like Jackie Chan 
   before he got all doughy.
--
The Toronto Linux Users Group.      Meetings: http://gtalug.org/
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists