Where is the mess? Everywhere: sound, video, embedding, etc.
Posted Oct 20, 2008 8:36 UTC (Mon) by khim
In reply to: 64bit platforms? Huge market, yes. Pure 64bit platforms without 32bit support? Don't make me laugh...
Parent article: Linux now an equal Flash player (Linux-Watch)
I'd argue that Win32 is a horrible mess, actually, filled with
compatibility kludges, automagical common control versioning, silently
redirected writes to parts of the filesystem namespace, and so
You are looking on the system from the POV of system developer.
From POV of application developer lack of said automagical
versioning is a mess.
Why? Some examples.
Sound. How well OSS emulation is working today? Oh, right, OSS API was a
mess and so it can not be adequately supported. Now everyone must
rewrite everything for ALSA... or may be GStreamer... or may be
Video. There are just two interfaces: V4L and V4L2. So if I don't need
the features I can safely use V4L, right? Oh, no backward compatibility...
Ok, I'll use V4L2... What? No support for some devices? So I must
support both? What a mess... (Note: AFAIK this particular mess was
cleaned up and now most devices support V4L2 - but for years the
situation was as described).
Widgets. Can I embed Qt widget in a GTK program? No? Why No? Ok. At
least GTK widgets are usable in Qt (not so long ago this was impossible
Remember the ire Windows users directed on Microsoft for discontinuing
VB6? It was supported for ten years before Visual Fred replaced it!
In Linux such tectonic shifts (when you can not use old APIs anymore)
happen once per year or two. And rarely developers offer support for
"obsolete" technologies. The only one lib which actually supports old APIs
is GLibC - yes, there are occasional glitches, but you can still
take old program from the era where files were limited to 2GiB and it'll
work. Oh and linux kernel itself is pretty good at keeping things
backward compatible... unless you'll count aforementioned "big switches"
like OSS->ALSA transition or V4L->V4L2 transitions.
Transitions in Windows are handles in the sane way (from the POV of
everyone who's not system developer):
1. APIv1 is introduced.
2. APIv2 is introduces some years later. APIv1 is still usable and for a
few years you can safely ignore APIv2.
3. APIv1 is declared deprecated and developers are encouraged to switch to
4. Few years later APIv1 is... removed? no! frozen: you can still use
APIv1, but some features are not available.
5. Finally, 10-15 years down the road APIv1 is removed.
If there are APIv3 or APIv4 introduced along the way - it means at some
point you'll have concurrect support for three or four versions of
In linux it's done "in clean way":
1. APIv1 is introduced.
2. APIv2 is introduced some years later. Now you must support both
APIv1 and APIv2. Because they don't play well on the same system and you
never know when particular distributions will switch from APIv1 to
3. APIv1 is removed.
This is the best way to scare away ISVs and "normal" users. Who
just want to use the system and not think about versions of kernel,
GLibC and GTK. Who want to select API to support all currect systems (say:
2-3years old) and future systems (again: 2-3years in the future). Why this
limits? It's easy: PCs average lifespan is 2-3 years. And you want your
application be available for everyone who's currently using PC. So
Any API must be supported for at least five years (ten is better)
and for at least three years after replacement is introduced (five
Situation is slowly changing - but it's still far from being equal to
Windows. Actually friedliness to ISV is almost directly proportional to
market share: Linux is 1% (because of the aforementioned problems), Mac OS
is 5-10% (it's better then Windows, but it still likes to do things like
drop support for Carbon when 100% incompatible replacement was only
available for eight years), and the rest is Windows (which is horrible in
many ways but has excellent backward compatibility).
Remember: Joe Average does not care as much for "cleannes of the
architecture" - but he does care about his ability ro use old
software. And ISVs like to produce software which till PC lasts. This is
not an option in current Linux ecosystem - unless you'll ignore it and go
with separate abstraction layer (JDK, for example).
to post comments)