OT: Next Time you sing happy birthday

[Ian Petersen]

On 8/14/07, JoeHill <joehill-R6A+fiHC8nRWk0Htik3J/w at public.gmane.org> wrote:
> 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.

You have experience where I don't, so maybe Crawford is not as far off
base as I thought, but it seems to me that the fundamental difference
you outlined between DDLs and shared objects is that "you never know
what's in an arbitrary DLL" and "you almost always know what's in an
arbitrary .so" and I think that's got more to do with the open,
communicative nature of FLOSS (as opposed to the closed, secretive
nature of closed software) than it does with any fundamental
difference between a DLL and an .so.  If closed software developers
published the contents of their DLLs, it seems to me you'd be able to
count on the contents of an arbitrary DLL.  This difference is indeed
a benefit of running an open system instead of a closed one, but I
still think Crawford is being misleading when he says "there's no such
thing as a DLL"--although perhaps I'm picking apart technical
trivialities that the average business person doesn't care about.

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

I didn't mean to say that it was lunacy to conclude that a common
release cycle would help Linux adoption.  I meant that it was lunacy
to think that you'd ever _have_ a common release cycle, and therefore
someone that suggests we _need_ a common release cycle is perhaps not
completely reasonable.  As you say, we seem to be managing without
one, so I can't see the need.

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

I guess they _are_ rather minor points, and it was targeted at
business people, not tech people, but I wondered if the existence of
funny logic in some parts of the article indicated the existence of
funny logic in the rest of article or the data sources used in
preparing it.  My BS-O-meter went off.  YMMV.

Ian

-- 
Tired of pop-ups, security holes, and spyware?
Try Firefox: http://www.getfirefox.com
--
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