Slashdot Mirror
How Apple Killed the Linux Desktop
An anonymous reader writes "Klint Finley discusses Miguel de Icaza's thoughts on how OS X killed Linux on the desktop: 'de Icaza says the desktop wars were already lost to OS X by the time the latest shakeups started happening. And he thinks the real reason Linux lost is that developers started defecting to OS X because the developers behind the toolkits used to build graphical Linux applications didn’t do a good enough job ensuring backward compatibility between different versions of their APIs. "For many years, we broke people’s code," he says. "OS X did a much better job of ensuring backward compatibility."' This, he says, led developers to use OS X as a desktop for server programming. It didn't help that development was 'shifting to the web,' with the need for native applications on the decline."
Agreed. I've been begging my IT department to let me run Linux on my laptop, and run our corporate Windows image in a desktop VM, but they won't let me. When I had more direct admin rights, I was running a dual boot system on my laptop, and was using the Linux side for about 80% of my work. The only time I'd head over to the Windows side was when I needed to get into Sharepoint or something like that.
it's real, real simple. the successful OSes have, at their heart, a highly effective "Common Object Model" of some description, which provides a) fully-compliant backwards compatibility across APIs, dating back even 20 years b) interoperability between applications and application components *regardless* of the language they're written in.
every f*****g time i raise this successful strategy - deployed by both microsoft (DCE/RPC and then DCOM) *and* apple (Objective-C has an Object Model built-in to the language) - on free software mailing lists, i get shouted down. i get told "that stuff is a piece of shit, why are you even bothering to mentioning it?"
now, the linux distros are paying the price of that arrogance, why is anyone even surprised?
firefox. firefox has a "COM-like" system which was "inspired" by microsoft's COM. it's called XPCOM. what XPCOM does *not* have is the ability to merge interfaces (they're called "coclasses"). that has two implications:
1) whenever there's a change to an interface, all backwards compatibility is lost. with coclasses you can have *both* the "old" interface as well as the "new" one, supported by the *same* application.
2) if you want to have "default values"... you can't. what XPCOM has to have instead is a highly-dubious modification which adds as an *extra* explicit argument into the actual function saying how many arguments are actually used! imagine if the people who wrote the ANSI-C++ standard said "oh yes, if you want the last arguments of any function call to be optional then the very first argument has to be an integer saying how many parameters there are", there would be people laughing at them for decades.
i've raised this with the mozilla foundation core developers at least twice. the first time i was told by one of the key subcontractors that coclasses were "too complicated" for the mozilla developers to understand. the second time, that person wasn't there: i raised it directly with the mozilla foundation core developers; they didn't understand, took it as personal criticism and then later on enacted very fascist censorship onto the mozilla mailing lists, preventing any further discussion.
so, that subcontractor was indeed right: the concept of coclasses *is* too complicated for the mozilla core developers to comprehend. .... but it's not just the mozilla foundation developers.
the KDE team had an opportunity to replace DCOP with something more substantial, as part of the $10m E.U-grant-sponsored KDE4 redesign: i recommended that they start with FreeDCE and go from there.... and they didn't.
the Gnome team make extensive use of GObject, but GObject is a very very poor substitute for COM. only now with the GObject "Introspection" is it *beginning* to approach the capabilities of COM, but because GObject has no concept of co-classes, *again*, there is no way to have backwards-compatibility for APIs.
i won't even get into what happened with the webkit developers.
the bottom line is that time and time again, in every major engineering team behind each of the major projects which make up "a linux desktop" as we see it, there has been a fundamental failure to comprehend the power of having a strong base on which to create good successful software.
that success - stability of APIs and interoperability between components regardless of programming language - can *only* be achieved by using something like COM, with language bindings for every known major programming language, and support for "co-classes" that are then actually *used* - properly - by the developers.
this takes discipline, and i don't see any of the major free software projects getting this, any time soon.
miguel: i've raised FreeDCE with you, before. i know it was 10 years ago :) however, since then, i've learned that the WINE team have actually gone and made pretty much a complete implementation of both MSRPC *and* COM, including, i believe, a complete server implementation (albeit a basic one). they no longer require the installation of DCOM98.EXE for example which is a good sign. also i heard of a guy who managed to "extract" all that client-server code into a separate project: he called it "TangramCOM".
The entire point of the version number is that it'll continue to behave like version 9, even when running on DX10/11/whatever. So... you're kind of arguing against your own point.
Comment of the year