How Apple Killed the Linux Desktop 933
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."
Re:It's too bad (Score:5, Informative)
Because nothing beats Linux for package management. Miss not having a repo of open source at my disposal; the App Store will never touch it.
You mean you miss something like MacPorts [macports.org]?
Not so (Score:5, Informative)
Re:It's too bad (Score:4, Informative)
You can use macports or homebrew on OS X. Both have all of the key OSS packages, and the latter additionally allows to manage your own private packages. What else would you need? OS X is FreeBSD with a fancy UI (and Obj-C)... You can shell script the daylights out of your box all you want if that's your thing.
Re:Linux marketshare going down? Or OS X going up? (Score:2, Informative)
Ubuntu used to be a decent option. These days, Mint is far better. What with the working codec and lack of Unity.
My Linux Desktop (Score:3, Informative)
Is not dead yet!
Re:The real reason (Score:4, Informative)
You are somewhat correct and yet not. (Score:4, Informative)
There was more to it than that. OSX was a serious problem. The Linux community was so wrapped up in competing with Windows for survival that we didn't see OSX coming.
Linux's core APIs don't change as violently as most people say. SDL 1.2 is still SDL, OpenGL is still OpenGL. At the Kernel level, there is resistance to inter-Kernel compatibility to try and prevent unscrupulous vendors from tainting hardware level code. I don't think I have seen a glibc double free error that was not caused by a real bug in the program since 2005/2006.
Package Management boils down to RPM and DEB. And those should be the only two possibilities.
So the core of Linux is like the core of the Earth. It runs, and if you have drivers for it, it's fine. The Surface of Linux is like the surface of the Earth. Utter Pandemonium. KDE and Gnome and it's various tool kits and it's extensions created a situation where endless pandemonium abound. Honestly, they acted like a bunch of 13 year olds playing with Windows 3.1. (If you were 12, or 13, you constantly wanted to re-arrange icons, change the colors, on and on and on. And people got so frustrated such that they didn't want to do it anymore. And moved to OSX.
There needs to be some iron and steel level discipline (with a lower case d) in desktop development. We need to stop creating a situation where everything on the surface is totally different every other version and nobody can find anything.
Another problem is the networking and communication issues with various networking protocols and whatnot. At the command line level, Linux is completely network transparent, even with X.org itself. But the moment you try and utilize desktop level CalDAV Calenders, or Samba shares, it takes a bunch of trial and error to get things working. An example.
Lets say that I have a file on one machine, and I want to get it on another machine via the network. I can of course use Secure shell (SSH) to do that. But what if I want to use Samba to do that. (One Linux box to another Linux box.). because Samba is supported as an overlay by Gnome and KDE. Will it work? Well if I use the command line smbclient yes it will. Under Gnome and KDE, it's a bit more complex. If the Samba Overlay was not installed in Nautilus (Gnome) or Dolphin (KDE), either one of those will throw an error. Additionally, if specific credentials are required to do such a thing, it would require they be setup in KDE or Gnome System Settings before hand. I garuntee you won't know where that Samba mount point is as an ordinary user even if it DOES work.
Another example. This one not involving LibreOffice, KDE, and evolution. We use KDE as the desktop, LibreOffice as the Office Suite and Evolution as E-mail. Why? Well, LibreOffice for obvious reasons is the most compatible Office Suite. Evolution for some rather odd reasons.
1. Evolution is the only Linux Mail and Groupware client that can be autoconfigured from our Open Directory Infrastructure. (LDAP). Only Evolution can get user information from LDAP with reguard to WebDAV, CalDAV, GroupDAV, and IMAP without having to edit it by hand.(like AD does with Microsoft Office and Outlook.)
2. Evolution is the only Groupware Client that can interoperate with eGroupware's iCal based services. in addition to Offsite Outlook Web Services. Thunderbird Lightning, and Kontact technically work, but not as bug free as Evolution does.
So, this creates the following simple problem:
I have users that are used to being able to "edit attachments" under Outlook with real Outlook Servers. (This is a functionality microsoft is getting ready to remove due to numerous security holes in doing this.) but using "Save As" is time consuming, sometimes my users don't know what directory they saved it in etc. So I introduced them to LibreOffice's "Send as E-mail feature." guess what. If you don't go into LibreOffice and over ride the defaults, it launches ThunderBird of Kontact.
Re:It's too bad (Score:5, Informative)
At the mercy of Apple? It's amazing how much anti-Apple bullshit gets modded as "insightful".
Let's not forget Homebrew. Homebrew does a nice job of packaging programs that coexist with the versions of prerequisite programs that are included in the OS X system files.
Re:It's too bad (Score:3, Informative)
well, on ubuntu you write "apt-get ", on mac ports you write "port ". Big difference, huh?
The only prerequisite is to have a compiler, you can start with the one shipped with xcode and then switch to the gnu one "ported" from ports, if you really want to.
Last but not least, what means "at mercy of Apple"? it isn't something that you remove or that can be blocked by the apple security features in mountain lion.
I used macports and apt long enough to say that macports is nowhere as good to manage updates and dependencies as apt.
Re:It's too bad (Score:3, Informative)
You must be doing something wrong. I use homebrew and had no problems getting it to work. You may want to read the caveats that come up when you install a package, or run "brew doctor" to see what is misconfigured.
Re:I actually met Miguel. (Score:4, Informative)
Nope, he's a scumbag. For instance, let's talk about backwards compatibility and breaking people's code. A while ago the Mono project released a .Net wrapper for SQLite that various projects used and like all Mono-developed libraries it was designed to run under .Net as well as Mono. Then the Mono developers decided to discontinue development on it in favour of a new wrapper library that wasn't API compatible and actually broke the old library in newer Mono releases. So you could still run applications that relied on this Mono-supplied and Mono-developed library under Windows .Net quite trivially but they didn't work under Mono itself without downgrading to an ancient version which distros didn't ship anymore.
Re:It's too bad (Score:5, Informative)
To give you some perspective, I work with RHEL systems for a living (and have been using Red Hat since 5.2 -- not Fedora Core, but way back when you bought "Red Hat Linux" at places such as CompUSA). I am very familiar with yum and rpm, and I can only think of one time I've ever screwed up a Red Hat system using those tools. Apparently either that knowledge didn't transfer to using and working with Fink / MacPorts or there is something wrong with them.
I'm sure Fink and MacPorts work for someone, but in my case installing a2ps and FrozenBubble2 was enough to cause havoc.
Do you really know what Gatekeeper does? (Score:4, Informative)
Yes, 3rd party developers are at the mercy of Apple and this is not some anti-Apple bullshit. See: Gatekeeper.
Gatekeeper is about stopping programs you have downloaded from running without your permission. You can of course simply disable it, or let it ask on a case by case basis.
But it doesn't enter into the picture when we are talking about MacPorts. They are not downloading software, they are downloading source and then compiling it. Thus your software is all local.
But even for package managers that just download binaries, you can as noted simply run whatever you want.
Re:It's too bad (Score:5, Informative)
But if you just wanted a package manager and repos, you could always use Fink (for those who don't know, it's basically apt-get for OS X and a bunch of repos of binaries), no need to bootstrap with dev tools from Apple.
Actually you could probably get a version of gcc from Fink and then use that to bootstrap Mac Ports. Not tried that myself, though.
Re:It's too bad (Score:5, Informative)
Linux doesn't do well as a Desktop OS.
Dang. I've been doing it wrong for 13 years. Thanks for letting me know.
1. Support 3rd party hardware. Apple and Microsoft are willing to let companies make drivers for their hardware and put their own license on them
2005 called and wants its argument back. It's not absolutely perfect, but Linux hardware support is generally excellent these days. Outside of niche devices virtually everything works great. WiFi was a particularly thorny problem for a few years, being both widely problematic and obviously very important due to the situation with a few widely-used chipsets, but that seems to have ceased being an issue.
2. Consistent UI. People get stuck, they try to find instructions the instructions need to be consistent with their system.
Meh. People who aren't knowledgeable enough to figure things out on their own use Ubuntu, and there is plenty of information out there for Ubuntu.
3. The little features matter too. Time to put your system to sleep and wake up. Does that keyboard light work, How quickly can you connect to a wireless network. Does your screen leave artifacts floating around, consistent Copy and Paste.
Umm, everything you just said works great for me, and has for many years, on many machines. And not just on the high-end ThinkPads I've always used; I've installed Ubuntu for people on low-end Acers and e-Machines, and everything just works, at least in the last 3-4 years.
Either you've had some exceptionally bad luck or your experience is out of date.
Re:It's too bad (Score:5, Informative)
Apple doesn't require it either... its required if you want a pleasant experience for the customer, but nothing is stopping you from running non-signed code.
Re:It's too bad (Score:5, Informative)
. I eventually did an in-place reinstall of Snow Leopard. XCode never worked right again; I'm getting a new laptop soon and you can bet MacPorts / Fink will be on my short list of software to avoid.
Well, you fucked up, didn't you? Rest assured, it wasn't MacPorts that hurt your install, it was you. MacPorts installs all it's ports in the /opt directory... and touches nothing else. You can't just reinstall the OS over top of XCode and expect things to still work... you blew away XCode frameworks when you did that. XCode comes with an excellent and comprehensive uninstall script, you should have used that first, and then tried reinstalling XCode. Reinstalling the OS just proves to everyone you had no idea what you were doing. If you do reinstall, a clean install is always preferred, and, it goes without saying, a reinstall of XCode is par for the course.
Re:It's too bad (Score:5, Informative)
I'd wager it's that it's just one more thing to keep track of.
In a small IT shop, adding IMAP support might not be a big deal, but in bigger shops it can involve all kinds of IT bureaucracy involving security reviews, training a bunch of people for support, added testing and validation, and on and on and on, and many of these requirements are not foot dragging or empire building by IT PHBs but externally imposed requirements by law (SOX, HIPPA, PCI) or by other entities (parent companies, audit standards, non-IT security, etc).
And even beyond this, technically it could involve more than just changing the service status from Disabled to Automatic, particularly in large, multisite Exchange implementations that involve multiple CAS and Mailbox servers.
So in a large shop when you add in all the overhead coupled with the usual constraints on money, time and manpower, it's not at all surprising that "IT" doesn't care to cater to people setting their own standards or deviating from standards organizationally agreed to.
Have been there, done that, bought the t-shirt, I'm not at all surprised that someone in IT said "use Outlook".
Re:It's too bad (Score:5, Informative)
apt-get is more like the official app store.
It comes with the system. It handles pretty much anything. It can even accommodate 3rd parties.
So in that respect there's really nothing comparable on a Mac. Just stuff that kind of sort of partially covers what apt-get does.
Being not-quite-comprehensive kind of defeats the entire point.
Having run Debian [typing on it] for over 12 years, APT-GET is nothing like the App Store. In fact, the App Store doesn't have dependency issues that puke out fairly often and force one to manipulate around the bonehead mistakes package owners forget to test against and thus send out other revisions of an App all because they screwed up the packaing. APT-GET is not the end-all-to-be all and neither is Aptitude [ncurses front end], nor DPKG and anything else.