The biggest thing that strikes me, now, in comparing OS X to Linux on the desktop is that there's no one thing that can be called Linux. This is true in ways both obvious and hidden but no less real. An OS X user knows exactly what he will be getting on his desktop. A Linux user? Uhm. KDE 4, KDE 3, GNOME 4, GNOME 3, GNOME 2, Xfce, MATE, Cinnamon, LXDE, Unity, e-i-e-i-o. None of them work the same, none of them are configured the same - or even configurable to the same degree - and none of them provide the same capabilities.
There's an argument to be made that this diversity is good. Certainly, if you don't like, or can't adapt, to the OS X way of doing things, then you're not going to be happy with the fact that you can't change many things about the OS X desktop. My roommate is in this camp. He uses Xfce, and tweaks it to his liking.
There's a bigger cost here, though, and that is that developers don't have a single target to aim at. I was reminded of this when I saw a Slashdot article yesterday about how Good Old Games was just announcing OS X versions of its games, but not Linux versions:
If we're able to bring GOG.com games to Linux--and we're constantly evaluating ways that we can do this--we want to make sure that we're doing it the GOG.com way: simple, easy, and it 'just works.' I'm not telling you guys to give up hope--we know how much you want this--but what I am saying is that this is harder to support than it might seem initially, and we're not ready to move to support Linux officially just yet."Harder to support than it might seem initially" is an understatement. I've commented before on the plethora of audio standards on the Linux desktop. (Come on, folks, the old saw "the great thing about standards is that there are so many to choose from" is not intended to be prescriptive!) There are more problems, though. The list of libraries that are present on most systems and yet must be statically linked into a shipping program in order to make sure it works right is insanely long. I got help from one of the Firestorm development team in building a 64-bit version just so audio would work correctly, and the resulting wiki page shows just how daunting a task this is.
Right about here is where the Linux hardliners say "but everyone should build from source instead of installing binaries!" Wrong. The average user will take one look at that page and head to the Apple Store.
There's also the minor matter of putting the program in whatever the desktop environment calls the equivalent to the Windows Start Menu. (Dock? What's that? I've resigned myself to a Windows-style menu and taskbar, bleh.) 40 zillion desktops means there's no single way a program's installation process can automate adding it to the menu. For that matter, there's no real reason to install at all, and it seems many programs don't, leaving the user's home directory cluttered with dot-named subdirectories.
People talk about Android fragmentation in the smartphone/app tablet space. Compared to Linux on the desktop, Android is a model of unity.
"40 zillion desktops means there's no single way a program's installation process can automate adding it to the menu."
ReplyDeleteThis isn't actually true. What this really means is that more of the onus must be placed on the OS as opposed to the developer in regard to positioning things properly.
The way things work in Debian-based distributions (of which Mint is one) is that serious, professional-grade software distribution isn't done in bare binary form, it's done in the form of packages called .debs. The .deb contains the program binary and associated files as well as information like the program's name, its icon, and its dependencies. You double-click the downloaded .deb, and the OS automatically downloads the required dependencies (no need for the user to futz around with Synaptic), installs the program, properly adds it to whatever menu the desktop environment uses, and... that's it. It just works.
Releasing a .deb for a Linux program (and possibly an .rpm for Red Hat and SUSE users) is really kind of like releasing an installer for a Windows or OS X program. If a developer releases installers for Windows and OS X but only puts the Linux binary in a tarball, it likely just means they're treating Linux development as a secondary consideration.
The problem with this is twofold: first, you have to build multiple packages - hopefully, a .deb that will work for most of the Debian-derived systems, and then a .rpm for the Red Hat and CentOS and SuSE users, and then something else for the Slackware types, and oh wait now you have to maintain a Gentoo ebuild, and and and... This means that you can't build just one Linux package, as you can for Windows and OS X. Secondly, you have to pick a set of releases of those systems to build against that's neither bleeding-edge nor too ancient, and track that as things progress - and if you're building five or six packages, that means tracking at least 10 different releases of different distributions.
ReplyDeleteThe job is much bigger for a Linux software builder than it is for anyone else.