Monday, May 02, 2005
More Thoughts on Operating Systems
One thing that struck me as I read the ArsTechnica article I previously mentioned was how backwards MacOS X's kernel has been. Until Tiger, it has essentially had a "big kernel lock," though some footnotes apply to that statement. Furthermore, until Tiger, they had not frozen the low-level kernel interfaces in MacOS X, making kernel extensions, file systems, and certain drivers a pain in the ass to develop. Tiger also improves the limited support for 64-bit processors as well.
"What a shame," I thought, "that they didn't choose Linux as their kernel." Linux got rid of their big kernel lock with 2.4, which came out in 2001. The most recent release of the Linux kernel (2.6, which came out in 2003) goes a step farther and is preemptive, a huge win for system responsiveness in interactive applications (read: desktops!). Linux has also had full support for 64-bit PowerPC chips since 2001, with full backwards compatibility with 32-bit applications. As for the stable kernel interfaces, two out of three ain't bad.
So you look at this situation and go, hm, Apple has been making multiprocessor 64-bit desktop machines for a couple of years now. It's like Apple is totally unable to ship an operating system that takes advantage of their current hardware at all, if you look back at how long it took them to ship an operating system that was actually PowerPC native. And, you know, had all the things Windows 95 had.
Gnome and Apple share a very important trait, and that is that they're willing to break with tradition that is stupid. Apple looked at unix and said, "Hey, we can make a great system using this, and fixing what is bad about it." So they ported all the unix utilities to use a standardized XML configuration file format. When I first heard about that with the first release of MacOS X, I thought, "Aha, this is a great idea. This means we only need one parser, knowledge of one syntax, the files are easily displayed through a user-friendly editing interface, and they can be machine-verified for correctness. Surely this will be moved over to Linux in short order." In a word, that has not happened. The Linux types hate it.
Similarly, with Tiger, Apple has fixed the mess that is /etc/rc.d with their faster, more elegant launchd solution. Aaaand, they hate it.
Now, look at Gnome. They've based their configuration file format on GConf, which in practice is always mapped to XML files. Similarly, look at Seth Nickell's proposal for an init replacement that he called SystemServices. It's remarkably similar to launchd, but it never got written.
I would say that if anything, Gnome hasn't been thinking big enough. They've made changes against the kicking and screaming of the unix core, and in so doing dragged them into the, well, a few years past where they were. There isn't anyone performing this sort of modernization on other parts of Linux, however. In my fantasies, a company comes along and decides to build a desktop/workstation system, using Linux as its foundation. Only instead of designing backwards from what software is out there, they design the system and then adapt the software to do what it needs to do, breaking with existing projects if necessary (be that forking or replacing them entirely). Such an entity providing a more stable, centralized location for a software developer to aim at would probably be a very good influence in the Linux market. In my fantasies, they would write kernel driver modules that export a stable, binary-only interface for drivers and are updated to talk to the kernel on the other side whenever the kernel developers try to break those interfaces (Linux has held the line on binary-only drivers long enough; it's clear that the hardware makers would rather just not bother enabling their hardware to work in Linux than providing documentation or source code).
I could keep on elaborating about how great it would be if they would design some vaguely stylish looking x86 hardware to tightly integrate with, and so forth, but the reality is that it could never happen. Although building such a system is probably not as daunting as it might at first seem (Linux is closer than it would seem from outward appearances), no company would want to surrender so much control to a large lineup of widely varied personalities and interests.
And that is probably why Apple decided against choosing Linux.
"What a shame," I thought, "that they didn't choose Linux as their kernel." Linux got rid of their big kernel lock with 2.4, which came out in 2001. The most recent release of the Linux kernel (2.6, which came out in 2003) goes a step farther and is preemptive, a huge win for system responsiveness in interactive applications (read: desktops!). Linux has also had full support for 64-bit PowerPC chips since 2001, with full backwards compatibility with 32-bit applications. As for the stable kernel interfaces, two out of three ain't bad.
So you look at this situation and go, hm, Apple has been making multiprocessor 64-bit desktop machines for a couple of years now. It's like Apple is totally unable to ship an operating system that takes advantage of their current hardware at all, if you look back at how long it took them to ship an operating system that was actually PowerPC native. And, you know, had all the things Windows 95 had.
Gnome and Apple share a very important trait, and that is that they're willing to break with tradition that is stupid. Apple looked at unix and said, "Hey, we can make a great system using this, and fixing what is bad about it." So they ported all the unix utilities to use a standardized XML configuration file format. When I first heard about that with the first release of MacOS X, I thought, "Aha, this is a great idea. This means we only need one parser, knowledge of one syntax, the files are easily displayed through a user-friendly editing interface, and they can be machine-verified for correctness. Surely this will be moved over to Linux in short order." In a word, that has not happened. The Linux types hate it.
Similarly, with Tiger, Apple has fixed the mess that is /etc/rc.d with their faster, more elegant launchd solution. Aaaand, they hate it.
Now, look at Gnome. They've based their configuration file format on GConf, which in practice is always mapped to XML files. Similarly, look at Seth Nickell's proposal for an init replacement that he called SystemServices. It's remarkably similar to launchd, but it never got written.
I would say that if anything, Gnome hasn't been thinking big enough. They've made changes against the kicking and screaming of the unix core, and in so doing dragged them into the, well, a few years past where they were. There isn't anyone performing this sort of modernization on other parts of Linux, however. In my fantasies, a company comes along and decides to build a desktop/workstation system, using Linux as its foundation. Only instead of designing backwards from what software is out there, they design the system and then adapt the software to do what it needs to do, breaking with existing projects if necessary (be that forking or replacing them entirely). Such an entity providing a more stable, centralized location for a software developer to aim at would probably be a very good influence in the Linux market. In my fantasies, they would write kernel driver modules that export a stable, binary-only interface for drivers and are updated to talk to the kernel on the other side whenever the kernel developers try to break those interfaces (Linux has held the line on binary-only drivers long enough; it's clear that the hardware makers would rather just not bother enabling their hardware to work in Linux than providing documentation or source code).
I could keep on elaborating about how great it would be if they would design some vaguely stylish looking x86 hardware to tightly integrate with, and so forth, but the reality is that it could never happen. Although building such a system is probably not as daunting as it might at first seem (Linux is closer than it would seem from outward appearances), no company would want to surrender so much control to a large lineup of widely varied personalities and interests.
And that is probably why Apple decided against choosing Linux.
Comments:
Post a Comment
