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

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.