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."
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?
I am Slashdot. Are you Slashdot as well?
Linux is still alive and well on my desktop, thank you!
Smivs on the intertubes!
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.
These comments are my own and do not necessarily reflect the views or opinions of my employer or colleagues...
I used either Fink or MacPorts (I've used both in the past and both caused issues) to install a package which resulted in a lot of new issues; things not working, crashes and lockups. XCode stopped working shortly after that; I was just beginning to learn that tool and the combination of new things and broken things was beyond my ability to resolve. 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.
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.
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.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
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.
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.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
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.
. 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.
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".
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.