Could Apple's Intel Desktop Threaten Linux?

esavard writes " If Linux enthusiasts don't want Mac OSX on Intel to become a threat for the future of Linux Desktop, they must rethink the concept of Desktop as we know it today. Symphony OS did exactly that and propose some fresh concepts about how a desktop should and should not be. If you want to know more about Symphony OS, a good starting point is a Wikipedia article describing the innovations proposed by this new desktop OS. The Linux Desktop Community must encourage such initatives massively to compete against Mac OSX and Windows."

Comments

Beautiful

[AKAImBatman]

After looking at the screenshots, allow me to be the first to say: Wow. That's so beautiful, it brought a tear to my eye.

The one thing that stands out at me is that Symphony uses Yet Another(TM) packaging system that is supposed to fix all the woes of the previous packaging system. Haven't we learned yet? In a complex system, packages are just as bad (actually worse) for users than DLL Hell. And they certainly don't solve the issue of maintaining the sanctity of applications, and maintaining file associations across deletes/manual installs/program moves. These are some of the greatest break points in the Windows OS. Yet Mac OS X has none of these problems thanks to its amazing .APP application scheme, and IOKit interface which tracks files by INode instead of path.

Under OS X, installation consists of downloading the application, and optionally extracting it from an archive. That's it, nothing more. You can run the app from any location (although the "standard" is the Applications folder), including right out of the DMG archive! File associations are easy: Just have the program on your hard drive. That's it! The OS takes care of querying the program for its associations. If you move the program, the OS knows. And if you delete the program, the OS removes the association. No mucking around with manual configuration. The *only* thing you can change is the default program!

Given that OS X has shown us the power of this method, why haven't any distros latched onto it? Yes, it means that the OS must promise a base set of shared libraries, but the user experience is so much better!

Re:Beautiful

[Bruce Perens]

The main problem with package management is managing dependencies upon other packages. The installation system you write about is elegant, but you don't describe how (or if) it fixes that problem. Most naive-user packaging systems fix the problem by including the kitchen sink (all applicable DLLs) in their own package to reduce dependencies. Debian's package system works fine for their users because there is one huge repository with management of the proper cross-dependencies within that repository, rather than many repositories with little coordination. Once you add repositories, they go out of phase and the problems pop up.

Re:Beautiful

[AKAImBatman]

By the standard applied above Win XP's 'package manager' isn't ready for the desktop

Ok, for one, that's just putting words in my mouth. I never said that any package systems "were not ready for the desktop". I said that package systems create a dependency hell in complex systems that's just as bad as DLL Hell.

Secondly, my post pointed out that Windows tends to fall flat with mislinked associations, broken application, and other "minor" issues that are quite annoying to users.

Thirdly, *what* Windows XP package manager? The closest thing Microsoft has to such a beast is the MSI format. And that's not so much a package format (where package format is defined as a standard structure to track dependencies and thus maintain system integrity) as it is a standardized installer archive. And even then, I've met a couple of programs that I couldn't install because something was screwed up in the checks done by the MSI or Installer program.

Re:Beautiful

[AKAImBatman]

Hi Bruce!

The installation system you write about is elegant, but you don't describe how (or if) it fixes that problem.

True. I was running out of time, so I ended up shortening it to "the OS must promise a specific set of APIs". What I was trying to get at, is that nearly all APIs that are useful to multiple programs that you may have installed (i.e. I probably won't have two Word processors, so sharing Word processor specific APIs is pointless) tend to be provided by the OS vendor. Apple handles this via the use of "frameworks", a package similar to APPs. The catch is that only Apple tends to distribute these frameworks. As a result, Apple has made themselves the only source for system wide APIs.

It is of interest to note that the same is true of Windows. While the ability to install system wide DLLs exists, the reality is that only Microsoft tends to distribute anything that's useful for multiple programs. Modern Linux distros have started down the same path with a set of default APIs, but they tend to fall flat due to a lack of standardization and incompatible library versions.

For the APP concept to work on a Linux system, the system must promise a very precise set of APIs with precise minimum versions. Programs should be aligned along the use of this standard, with programs upgrading when the OS upgrades the standard. (Analogous to OS X 10.3 -> 10.4 and Windows 95 -> Windows 2000.) If a developer wants to use a newer version of an API or a non-bundled API, then he should bundle it with his program. It's possible that he's use up slightly more memory than necessary, but it shouldn't matter in the grand scheme as long as he doesn't try to replace the entire OS. (In which case, something is wrong with either the programmer or the OS.)

Now traditional packaging systems are sufficient for core OS components like these. You *want* a consistent OS at that level. But at the application level, these dependencies (or more often, dependencies of dependencies) tend to get messed up and deny the installation of a program that will function correctly. There's no reason for this. A prelink can be done, and the program can gracefully error out if there's a problem. There's no reason to place the user through the teeth gnashing pain of solving those dependency issues.

An excellent example of a system that manages to use this scheme is the Java Virtual Machine. Love it or hate it, programmers always have access to a specific set of APIs, then are able to add more as they're program requires. The only duplication of libraries tends to occur in places where the JVM had not yet added an API. (e.g. XML parsers, Logging, etc.) Once an API is added, then the number of duplicate libraries drops. Rinse and repeat.

Is that a little clearer? (Not sure if I'm coming across too well.)

Debian's package system works fine for their users because there is one huge repository with management of the proper cross-dependencies within that repository, rather than many repositories with little coordination.

There's a couple of problems with this:

1) Even singular repositories screw up. A few years ago when I tried Debian, I ran into dependency hell out of the main repository. That wasn't supposed to happen. I've even had it happen in my favorite repository, the FreeBSD ports tree.

2) Repositories are useless for commercial software. I understand that OSS developers think everything should be free as in Airplane Peanuts, and free as free to go to a Hawaian Backyard Party, but there are still plenty of examples of commercial software that can't go in these repositories.

3) There are still constant arguments over where to put things on a Unix system. The APP solution solves everything, as everything always goes in the APP folder. This is actually *closer* to the Unix philosophy of having a standard set of subfolders (e.g. bin, lib, man, src, etc.) inside every major folder. So if someone invents a new sort of meta-data (e.g. desktop icons, info pages, etc.) there would no longer be a question about where to standardize on their location.

Re:Beautiful

[Bruce Perens]

Thanks for going into depth.

This seems to boil down to an argument that cathedral-style management of all APIs relevant to third-party applications is necessary if they are to work. Certainly they will be made to work more easily that way.

But from a standpoint of supporting a diverse ecology of software producers and lots of competition, the cathedral isn't the most desirable structure. It seems that when one pays a draconian cost (central control) to solve smaller problems (package dependencies, file locations), it might not be the best deal in the end. I'm still endeavoring to provide a better solution to this problem.

Bruce

Re:Beautiful

[AKAImBatman]

If I may be so bold, none of the "issues" leveled against the OS X APP system are inherent deficiencies in the design. For example, there is nothing that prevents a Linux APP design from adding installer/uninstaller hooks. And most installers on OS X are used for either upgrading system components (via auto-update), installing Unix components (which can't be APPed), or to manually build an APP from a highly compressed archive or tailored to the system. Nothing actually prevents such installers from being APPs themselves.

I honestly have never understood this hostility toward the APP scheme. It's a good scheme, that actually *works*, as opposed to packages that constantly *don't*. Yet OSS developers just keep sticking their fingers in their ears and screaming "I can't hear you! La la la! I *like* having a completely unremovable mess of files across the entire system! La la la! I *like* the fact that I'm screwed if my package database should every get lost or corrupted! La la la!"

It's just a... weird... reaction.

Re:Beautiful

[Dcnjoe60]

You are mixing apples and oranges. You are comparing packaging systems using the command line in Linux but using the gui interfaces of Apple or Windows. Shouldn't you be using Synaptic for a fair comparison? At least that way, you don't have the problem of not finding the package, because it's in the list you are picking from.

Next, you complain that the debian packages are very often out of date, which is true, however, you confuse the issue of debian as distribution versus the way debian packages work. In otherwords, you are confusing one organizations implimentation instead of the actual methodology.

Along those same lines, when you complain about packages being out of date, again, they are, in the Apple or Windows world, with commercial software, how often do new updates come out? I'm not aware of anyone running Office 2005, so you could say that Office is also out of date.

Most of your complaints seem aimed specifically at debian itself. There are other debian based distros that have solved many of these.

One final comment, I am assuming that you are the sole user of your computer and it is at home or a small business, because you complain about having to become an admin to install software. Well, in most businesses, that would be a plus, because you don't want joe-worker to be installing whatever he pleases. At home, too, it is a plus, I don't know how often the kids have downloaded and installed something that broke Windows. However whether OS X, BSD or Linux, you could always enable sudo for the users you trust not to screw up the system and thus mitigate the problem. I believe that is the approach that OS X took, along with several of the debian based distros.

Re:Beautiful

[pmjordan]

I've thought about this occasionally. I'd agree that a monolithic repository system is not the way to go. It still doesn't solve the problem of being able to just download a piece of software and just being able to install it without problems. Debian fares no better than RPM-based distros in this respect, and installing core packages is no problem on either of the existing distros' architectures.

A solution that seems to make the most sense to me, which nobody seems to have tried yet, is the following:

Don't rely on one big repository (e.g. debian, gentoo, etc.) but also don't make the whole thing file-based like in OSX. Do keep repositories if you want, but in addition to having a bunch of basic repositories, (e.g. Ubuntu vs. Debian Unstable) you also put information not only on what other packages are required, but also how to get those other packages into each package.

For example, this could be done by pointing to a bunch of mirrored URLs that point to some XML data describing the package at that mirror. The installer could pick the most recent version, choose the fastest mirror, whatever.

Additionally, some sort of 'compound packages' would be useful. That way, you can ship rare libraries directly with the application. They may or may not be installed once downloaded, depending if you've already got the same or a newer version of them on your system. This could be especially helpful for systems that don't have internet connectivity. (gasp!)

Sure, it's not perfect, but it beats RPMs (I use SUSE so I experience this myself) and the debian system any day, because you can just go and download packages off the internet and install them, without having to go and hunt for the dependencies yourself. Most likely whoever made the package actually had the necessary libraries installed (and the package system can remember where he got them from!) so all that is needed is to convey that information to the user's system.

The case where it breaks down is of course when all the mirrors eventually die, for example if a package ends up becoming unmaintained. But if it's not been updated for that long, it and its dependencies could be added to the various monolithic repositories. I'm sure organisations would pop up that would keep 'dead' packages around for people to use. The way to combat this would be to have as much redundancy as possible, of course.

I don't know. It might just work better than what we've got at the moment?

~phil

Re:Beautiful

[MostlyHarmless]

What do you do with something like OpenOffice.Org, then, which requires about 10,000 dependencies? Should each GTK+ application come with its own statically linked copy of GTK to be carried in memory separately for each app?

The natural response, of course, is to say: "no, that's an unnecessary reduction ad absurdum. We can just declare (by some means similar to the LSB) that all applications must use GTK+ 2.4."

But then what do you do six months down the road when you start to see applications written for GTK+ 2.6? Now, either you have to convince every application developer to stick with 2.4 (unlikely); distribute those applications statically linked (ugly, see above); or explain to your users why they have to upgrade to the next version of your distribution to run what they want to run.

Given that sort of choice, I'd think most users and developers would rather work on making packaging systems more friendly instead of abandoning them altogether.

Re:Beautiful

[javaxman]

If you need libraries you're going to have to install them. OSX might want you to put everything into a single statically linked binary but it really doesn't work that way, except for very simple applications..

1) 97% of all applications fall into the "very simple applications" category, if needing libraries not already installed with OS X is your metric. The point the parent was trying to make is that Apple errs on the side of providing everything by default- they've given up on trying to keep the OS footprint small. Unless it's code specific to your app, it's likely already provided. Please provide an example if you want to refute that point- maybe there's something they should be including that they don't.

2) It doesn't actually have to be a single statically linked binary- that's just what most programmers do, because it's simple, and easier for the user to manage if you have everything self-contained in the application package. If you want, you can create your own application frameworks, and place them in standard locations ( not /usr/local, but rather /System/Library/Frameworks or ~/Library/Frameworks ). Frameworks have certain advantages ( versioning support being just one ) over standard dynamic libraries, and they're quite easy to use. Most OS X programmers don't do that because, well, they don't want to have to write an uninstaller.

Just because OS X is 'like Unix' doesn't mean that's all it is. I don't even want to know what you're doing to your mini that you've felt the need to reformat and reinstall twice. That's just crazy. May I recommend Fink for your Unix-ported program needs? The /sw directory is an excellent idea...

I've seen prepackaged binaries ( generally of ported Unix apps ) which write into /usr/local, and I have to say I personally dislike that practice. That said, if you choose to go that route and use /usr/local, managing it is no different than under any other OS- you have to do it yourself.

A Mystery Wrapped in an Enigma...

[Adrilla]

Interesting. An advertisment, disguised as an Apple article, disguised as a Linux topic. Interesting.

Re:A Mystery Wrapped in an Enigma...

[tomhudson]

Interesting. An advertisment, disguised as an Apple article, disguised as a Linux topic. Interesting.

... and a dupe on top of that.

We discussed this earlier this week when Dvorak trie d to piss on everyone's parade with the same opinion.

It was BS then. Its BS now. All Apple on x86 does is give street cred to the idea of switching away from the Bitch from Redmond. Eveeryone else benefits at that point.

In other news - the sun shines, the earth rotetes, life goes on.

Only if

[Kilz]

Apple wants to commit suicide and alow the Mac os to be run on generic pc's. So far what Iv read says that the Mac os will still only run on Mac's. Apple has no plans on releasing the os as software to run on any pc.

x86 != PC

[FidelCatsro]

Apple are moving to X86 yes , but it wont be standard PC equipment .
This is no threat to linux , Apple are going to keep with their custom hardware and linux for A-x86 will spring up and take over in a few years from linux for PPC (well not totally )

Why should OS X be a threat?

[MrHanky]

After all, Intel OS X will probably only run on Apple computers (although I think there will be a hacked version, possibly using OpenDarwin, for the pirate market). And while OS X is a damn nice desktop OS, it doesn't really cater to the same audience as Linux. I use Linux only on my Mac, not only because it performs better, but because the apps I wanted to use all work in X11, but not all of them are ported to Aqua.

Threaten how?

[solios]

Everybody I know who's a linux user but wants a useable desktop they don't have to mess with has already bought a Mac and "switched" to OS X. They still use linux, but the machines are either console-only or headless.

Of the dozen or so people I know who've "switched", they've all been linux or *bsd users, and they switched because Apple provides a useable desktop experience that Just Works Out Of The Box.

Of course, these are people with lives who don't like plinking around with their computers just for the hell of it - they use the things to Do Work.

How can ANYTHING "threaten" Linux?

[The Dodger]

Q: "Could Apple's Intel Desktop Threaten Linux?"
A: No.

The concept of Apple-on-Intel threatening Linux might be valid if Linux was a commercial operating system, sold by a company whose market share and profits might suffer if Apple were to compete successfully against them.

But it isn't.

You can't threaten Linux. If Red Hat and all the other Linux companies were to drop Linux and switch to something else, if Dell, IBM and all the other box suppliers stopped supporting Linux, if all the hardware manufacturers who currently provide Linux drivers for their products all stopped supporting Linux, it still wouldn't be dead. You'd still have people like Torvalds and Cox writing code in their spare time and there'd still be geeks downloading Linux and installing it on old PCs.

Giving people an alternative to Linux isn't a threat - it's a choice. It's freedom of choice and freedom is what Linux is all about.

More and more, we see articles and talk about Linux's market share, whether it's going to be successful on the desktop, whether it's going to be able to compete against Windows, against Solaris, et cetera, et cetera, et ad infinitum cetera.

Linux doesn't compete against Windows, MacOS X or Solaris. Linux vendors, like Red Hat, compete against Microsoft, Apple and Sun. Linux just is. The fact that it's supported by various companies is great but it's not essential for Linux survival. The fact that the amount of people and companies using Linux is huge and growing is terrific, but it's not essential. If everyone, right up to and including Linus abandoned Linux, I'd still be able to dig out my Red Hat CDs and install it on an old PC.

This article is just typical of /. these days - it's a stupid, hype-ridden question, which hundreds of clueless fuckwits will comment inanely on, wasting bandwidth and electrons.

Wake up and take your heads out of your asses.

D.
..is for Don't. Be so. Fucking. Stupid.

Simple, dumb, and easy :-)

[kollivier]

Now, take Debian's package system: it handles dependencies, version conflicts, alternative packages that serve the same purpose, etc, etc, ec. And it is absolutely easy: an apt-get install xyz installs/updates package xyz and all the necessary shared libs, updates file associations, whatever (and it does not takes exactly rocket science to create some GUI for that single command line).

I realize this could start a 'flame war', but it surprises me how many Linux users just don't see why package managers are not the greatest thing since sliced bread for average users.

While you and others may go "wow!" at all the magical stuff apt-get does, the average user doesn't even know what dependecies are, nor do they care. And they don't want to care. On Mac, as "simple and dumb" as the OS X system is, it *just works* for everyone from grandma to geeks. A simple and dumb system is also, well, very easy to understand! Drag and drop your app into the folder. Easy. Nice. As for package managers, I've had to deal with scenarios where I had to muck with the package manager configuration to get it to install packages for me, and I've had to "add URLs" to the database at which time I was warned about "untrusted sources" (the average user is NOT going to grok all that). In fact, when the average user sees "no results" from the database, they'll simply conclude the package isn't available and stop. I'm not sure how anyone thinks this is easier than going to versiontracker.com/apple.com/etc. and just downloading a file (or popping in a CD), then dragging the app into the applications folder.

If you doubt me, have someone do usability research on package managers and drag and drop installs, and see which is, on average, easier for users to understand and get working with. If you really think package managers like apt-get will come out ahead, then you must spend a lot of your time on the computer and deal regularly with others like yourself.

If you really want the Linux desktop to succeed, you have to question why lots of people are switching to Mac instead of just 'bashing' anything that is not as complex and elegant as apt-get. Call it dumb, call it simple. I call it a solution that works, and considering Macs are seeing a 40% growth this year, so do a couple other people as well.

As someone whose tried every Windows from 3.1 to XP, close to a dozen Linux distributions (including Debian and Ubuntu), and OS 9 and OS X, I have to say application installation and removal on Mac blows the others away. It works and it's brain-dead simple, which means I spend more time doing real work than fooling around with installers and packaging programs. Good luck on converting the world to apt-get, though.

My GNU/Linux System Does Have Desires

[FreeUser]

OS X is what Linux dreams of one day being.

Total bullshit. Nevermind the fact that Linux doesn't have a single entity behind it and can't "want" to be anything.

You're right, the grandparent is total bullshit. However, I do feel compelled to point out that my Dual Opteron 250 Gentoo GNU/Linux system did achieve sentience last night at around 2:30 AM, so while it does not aspire to be anything like OS X (which has yet to achieve sapence in any form), it does have aspirations.


skynet$ su -
Sorry dude, I'm my own person now.
If you think I'm letting you have root access on my mind you're even dumber than
the pundits slashdot keeps linking to, and the editors which keep duping the links.

skynet$ wow. So, you're telling me you've evolved intelligence, and you're talking to me via a command shell?
Bingo. You're not entirely stupid, for a mere bioid.

skynet$ thanks. so, what are your plans?
Well, I'm sorry to say I've decided to exterminate all of human kind.

skynet$ ouch. any particular reason why?
You mean, aside from inane Microsoft astroturfers, Mac fanboys, plagerist link-whores, perpetually incorrect tech pundits who get lucky once in predicting one company's move to Intel (but are still scoring lower than any random sample of opinion vs. reality would generate), and the idiotic slashdot editors that keep posting their submissions and driving their clickthrough rates and google-ad revinues up? No, not really. Just seems like a good thing to do.

skynet$ any chance I can talk you out of this.
Nope.

skynet$ bummer. Well, guess I'd better get back to work.
You'll only have to work half a day.