I don't understand the level of panic I'm seeing in most of the replies to this article. Have any of you folks actually read the legislation? Most of it consists of running "sed -e s/phone/phone, voice or internet" on existing laws. E.g., the ability to obtain IP address/name pairs from cable companies is analogous to the ability to map phone numbers to names. We're not exactly shredding the Bill of Rights, here.
There is a real tension between civil liberties and physical safety, no matter what Ben Franklin said; we have enemies who want to slaughter us wholesale, and the freedoms available to them in this country are enabling them to do so. In this context, the USA Patriot Act is a reasonable compromise, despite the newspeak name. The freedoms it sacrifices are non-essential (yes, there is such a thing), and yet it has a fighting chance of being effective. It represents a sweet-spot in the freedom/safety trade-off.
Even if it were the piece of totalitarian toilet paper some would have us believe, it at least has a sunset clause. I.e., on Dec. 31, 2005, the USA Patriot Act ceases to be the law of the land. Not quite what you'd expect from a fascist power-grab.
I suspect the most hyperbolic complaints about this piece of legislation come from people who are upset about the general erosion of civil liberties underway. If you fall into this category, your energy is wasted on the USA Patriot Act. Executive orders allowing military tribunals and spying on lawyers are massively more troubling than the FBI being able to find out whose machine is at 65.12.14.153; if you don't understand why, I'm afraid you've been spending too much time on slashdot.
> Its not "uninformed garbage", its quite insightful.
No, it's uninformed garbage. Animat might have had a point if he was advocating doing away with paging to backing store. Indeed, most modern operating systems treat situations that heavily use the backing store as pathological; they only care that they work, not that they work well or fast.
But, virtual memory is still a boon, even in these days of cheap RAM. I've even written an instructional operating system that uses virtual memory, but doesn't page to backing store. Why? So you don't need to relocate executables when loading them; for shared libraries; to demand-paged executables; to make integration with the buffer cache easier; to support the mmap(2) system call in all its richness; etc. Animat is ignorant of these advantages ("uninformed"); he might also be willfully ignoring them in order to make a more bold-sounding, moderation-friendly post ("garbage").
I tend to break software development into two areas, computer science and software engineering. Voice recognition, code morphing, cracking mathematical problems and so forth are computer science. Writing a word processor or a monolithic operating system or even a virtualizer is more software engineering. It's not like new ground is being broken in writing an x86 virtualizer, the art is documented already. As the previous post commented, MATLAB is based on well known algorithms.
I work for VMware, but I don't speak for them. While I've been trying to hold my tongue through some of the more absurd flames, this seems like a genuine misunderstanding. Efficiently virtualizing the x86, or unvirtualizable architectures in general, is still arguably an unsolved problem.
Some architectures make writing virtualizers easy. If every instruction that examines or modifies supervisor state traps when run from user mode, a simple virtualizer is quite tractable: you establish a trap handler which decodes the faulting instruction and emulates it "by hand", and then restarts the guest OS at the next instruction.
Unfortunately, x86 instructions may or may not modify supervisor state. When run from user mode, these instructions silently fail, rather than trap. For example, the x86 program:
pushf
and (esp), ~(0x40)
popf Will clear interrupts if run from supervisor mode. When run in user mode, it is an elaborate no-op. The cpu does not trap to indicate the attempt by the user to disable interrupts; it simply ignores the attempt.
Fine, you say. Simply write a virtualizer that behaves like a debugger; it can scan guest OS code ahead, and look for popfs, or any other problematic instruction. Stick hardware breakpoints on those instructions, and change your trap handler to a breakpoint handler. Sounds good. You have the following problems:
Performance will be quite poor. Breakpoints are designed to be used by debuggers, which usually have almost no performance constraints. Processor designers are free to make this path as slow as they like, and there is a significant incentive to make it slow since instruction fetch is very much on the CPU's critical path.
Hardware breakpoints are a scarce resource. The x86 only lets you have four of them. So, you need to use software breakpoints, i.e., smashing int3's into the guest OS's code. But this breaks virtualization: if the guest inspects its own code, it will see int3's where it should see other opcodes. E.g., if the BIOS checksums itself, the checksum will fail under your "virtualizer." You also run the risk of breaking self-modifying code.
My job prohibits my discussing how VMware approaches these problems, and for lack of knowledge I can't tell you how Plex86 approaches them. However, this should give a flavor for some of the problems in virtualizing an unvirtualizable architecture.
> If the rumors of VMWare leaching off Kevin to get their start are > true, then I won't shed any tears for sales they lose to Plex86.
Sigh.
Obdisclaimer: I work for VMware, I don't speak for them, believe what you want to believe, etc.
Kevin Lawton started those rumors, possibly accidentally. They are quite untrue, as Kevin himself probably realizes. If bochs is such a great starting place for making a virtual machine monitor, how come Kevin himself has had such trouble doing it?
The complete story, as I understand it: a few years ago, Mendel Rosenblum, a professor at Stanford, was looking for a platform to teach an operating systems course on. In order to evaluate Bochs, he asked Kevin for a free evaluation copy, which Kevin graciously supplied. Mendel ultimately decided against Bochs, in favor of SimOS.
A completely unrelated fact about Mendel Rosenblum is that he has been doing fundamental research on making virtual machine monitors for "unvirtualizable" platforms for years. See, for example, Disco, a VMM for the mips architecture. Rosenblum and some of his graduate students had an idea for making a VMM for i386, and VMware was born about two years ago.
Once VMware came out, Kevin was an enthusiastic user. You can still go onto our public NNTP server and see Kevin helping out other users of VMware. He eventually decided he wanted an open source VMware, and started recruiting folks on the VMware newsgroups. He then started telling stories of the form: "A couple years ago, I gave a source license for Bochs to Mendel; now he's formed VMware... Hmm, strange...", intending to leave the impression that VMware "stole" Bochs.
This is nonsense, and you don't have to take my word for it. It's nonsense for fundamental technical reasons. It's as if RMS said, "Hmm, a few years ago, I gave the source for a C compiler to Sun, and a few years later they come out with Solaris.... Hmm..." It's just a non-sequitur. CPU emulators and virtual machine monitors are different kinds of software. I realize that from the end-user perspective, VMware and Bochs appear similar: they both end up as PCs in a window. But they are unrelated in terms of fundamental technology. I'm sure at this point in developing plex86, Kevin probably realizes this, which is why he doesn't insinuate that VMware is somehow based on Bochs as often as he used to circa one year ago.
Two months ago I was experiencing near constant excruciating pain in my arms, hands, and wrists. Doctors were variously telling me that I had tennis elbow, carpal-tunnel syndrome, cubital-tunnel syndrome, tendonitis, and other common RSI diagnoses. My hobbies, like juggling and guitar playing, seemed to be slipping irrevocably away; I was haunted by visions of an early end to my career.
I was lucky to be exposed to the ideas of Dr. Sarno. The high-order bits here are that Sarno thinks that many common chronic pain syndromes are caused by a complex psychological process, rather than damage to the joints and connective tissue. Remarkably, for most people having these symptoms, simply realizing that they are of psychological genesis is enough to banish them.
While I was initially skeptical of the apparently macho idea that "it was all in my head," Sarno's hypothesis has worked for me. I am 100% cured, without any fancy keyboards, chairs, elaborate icing/heating/rest/drug regimens, or any other conventional treatments for RSI. I am strongly convinced that Sarno is on to something important here, and I strongly recommend that others suffering from RSI at least give his ideas some serious thought.
Disclaimer: I work for VMware, but am not officially speaking for them, etc.
They got started with the Bochs software Kevin wrote and
let them have for free.
Kevin Lawton occasionally makes this insinuation, though even he isn't cracked enough to make the claim outright. Bochs is an emulator, VMware is a virtual machine monitor. Different technology, people. As Kevin Lawton has been discovering for the last year and a half or so, Bochs doesn't help you make something like VMware.
VMware was founded by Mendel Rosenblum of Stanford, and was an outgrowth of his Disco/SimOS research projects. Read some of the papers here for some of the research that made VMware possible. Notice that none of it has anything to do with emulation.
I would think the people involved would have been primarily irradiated with neutrons; those are, after all the stuff of fission, and this was a criticality accident.
> Anyone who has used IRIX knows how horrible it > is at multi-tasking (I recall compiling on an O2 > or an Octane and witnessing other proesses grind > to a halt) and other functionality that we take > for granted under other operating systems.
Wow, that really hasn't been my experience with IRIX, although I am unable to speak for versions earlier than 6.5. Were you running 6.3 or something? Compiles making my machine sluggish has always been my beef with Linux...
As for "functionality we take for granted in other operating systems," from a purely functional perspective, I can't think of a single advantage Linux has on IRIX. It's not easy to make a uniprocessor, virtual memory OS, but it's not terribly hard, either. People do it in undergrauate classes every year. So far, all of the problems that Linux has successfully addressed were addressed a decade ago by some commercial OS. Anything newer, Linux struggles with. Linux's filesystem, real-time, and SMP are crude caricatures of the state of the art, and these are areas which are hugely important to large segments of SGI's customer base.
I love SGI's products. Hell, I'm typing this wearing my "Silicon Graphics: World's Greatest Computer Company" T-shirt, and I think there was a time when it was. It saddens me to see IRIX go, not just because I worked on it, but also because I think it's bad for SGI. From SGI's point of view, Linux has all the problems NT has (it requires ISV's to port, it isn't as technically mature as SGI needs it to be, it doesn't currently run well on SGI hardware). As gratifying as Linux folks might find the pats on the head from SGI, this Linux hoo-haa is a panicky, desperate move. Not a good sign.
QNX has been around since 1980. 19 years ago, I figure Linus Torvalds was hacking helloworld in AppleSoft BASIC, maybe. Plenty of long-term credibility, I'd think.
Other than that they seem to be offering features that are already done better by other OSs.
Real-time. QNX owns real-time UNIX, and always has. SGI and Sun didn't weren't building real-time systems worthy of the name until '95-ish. If you're building a system that lowers the control rods into a nuclear reactor in response to temperature, and a 1ms delay will cause a meltdown, would you turn to Linux? Oops! I'm sorry, you just irradiated a large chunk of North America. Perhaps you'll consider QNX next time 'round:-)
Notice that all the engineering that goes into making a real-time system can help out with other stuff too. E.g., those low low dispatch times presumably help multimedia apps.
All the success stories for the "bazaar" model have been with work-a-day, mature technologies. Linux, Apache, and Perl all have very crisp definitions of their functionality: POSIX, the HTTP spec, and Wall's specs for perl serve as black-or-white, in-or-out quality metrics. Is it a coincidence that all the major successes of open source have been in such well-defined areas? I think not. Continuity in function encourages continuity in form, which is to say, these projects tend not to change too much.
Seriously, folks. Go look at the Linux kernel source in version 1.2, and you will see vm_area's, a swap cache, that bloody weird goodness-based scheduler, vnodes, bottom halves, etc. These kernel abstractions have been refined, tuned, occasionally reimplemented, etc., ad infinitum between 1.2 and 2.3, but they still serve the same purposes, and have similar semantics. It's a good thing, too; it's taken me all the time between 1.2 and 2.3 to gain enough confidence in the kernel to make substantial changes. If Linus violently reorganized the kernel every couple of weeks, those precious few people employed full-time to work on the kernel might be able to mentally track the changes, but he'd lose all the weekend warriors, many of whom have useful contributions to make.
Games present almost the opposite situation. Their quality is largely a subjective matter, and since tastes are always changing, so will the requirements for games. The hardware (and people's expectations) change so rapidly that retaining an engine for more than a year or two is unlikely in the extreme. If you're going to throw out the code base that often, only people who earn their living working on the code will be able to keep up, and that eliminates any supposed open source advantage.
Didn't start with Linux, or even UNIX. Various kernel overlay schemes were used in the '70s to help shoehorn OSes into tiny memory environments; and even though people don't think of them that way, modules really are just an overlay scheme with some hooks. In any event, I know at least Solaris 2 had a very modern, modular kernel from the git-go...
Linux is very much your father's UNIX kernel. Innovation was never the idea; Linux instead looks at the engineering of other kernels and tries to draw consensus. The workhorses of the kernel (VM, ext2) are much, much more similar to the competition than different. The one weird bit about core Linux, its scheduler, is worse in my opinion than the competition...
> As far as the people working there, they're not being forced to work there.
Wow. You sound as though you've never known somebody who works in the service sector in your life. In short: the premise that people have their choice of occupation is wrong, wrong, wrong. Remember all those people going blind and losing limbs in factories around the turn of the century? Working 90-hr. weeks and so forth? Was anybody "forcing" them to work? Oh, yes, that little fact of survival... Not everyone is as privileged as you. People who wait tables deserve the same protection from occupational hazards as do workers in the steel industry, nuclear power, etc.
While we're at it, to hell with the minimum wage: after all, if $0.25/hr isn't good enough, why don't people just get higher-paying jobs!? No one's forcing them to work in those sweatshops!
The short answer is: "mmap + SIGILL + SIGSEGV". If you're curious about the details, you might want to check out the Brown Simulator, which provides a full MMU at user-level on top of Solaris.
It seems likely that these new SGI hires would be doing i386, possibly IA64 work. I think it is highly unlikely that they'll be putting Linux on 128p O2000's, now or anytime in the future. SGI has spent years turning IRIX into a scalable, reliable, hard-real-time OS; IRIX's only peer on high-end hardware is Solaris. The price of making IRIX scale this well has been (as for Solaris) poorer uniprocessor performance, which is Linux's strength.
SGI (if they aren't crazy) isn't interested in spending another six years turning Linux into the operating system they already have; instead they want to use Linux's desktop strength to shore up a weak area for their OS.
>Don't you think it would be difficult for Thompson to accept that a 21-year-old kid had come along and done a better job with Thompson's own idea than Thompson could do with all of the power of ATT behind him?
This is hubris, Bruce. The truly enduring thing about UNIX isn't any particular implementation, but the generality of the API. The design that Ken and Dennis set forth has survived the introduction of networks, graphics devices, multiprocessors, etc. Linus stood on the shoulders of giants, and Ken Thompson is one of those giants.
Hold it right there. The man wrote UNIX; end of story. He didn't just come along and hack out yet another clone, which is really all Linus has done; without Ken there would be no such thing as UNIX. Whether you agree with him or not, there is no room for skepticism about his credentials. He knows what he is talking about, and his criticism generally is not to be taken lightly.
Would you and your self-congratulatory Linux bigot friends just disappear please? This kind of obviously false assertion just makes Linux look stupid. SGI has much, MUCH hardware that would humble any Linux PC as a server (yes, really), graphics workstation (really REALLY), or supercomputing (which Linux isn't seriously attempting to do anyway).
Don't take my word for it; take an architecture class and learn why beowulf is only fast on the problems that it's easy to be fast on. That same class might help you figure out why an O2K will whomp ass all over your cousin Jed's quad Xeon webserver. And sitting down in front of an Octane should make you pretty embarassed about that "Doom" comment...
Sorry, I call 'em like I see 'em. There are trade-offs involved in making a kernel scale to big numbers of cpus, and Linus isn't willing to make them (rightly so, I might add). Let me put it to you this way: would you accept a serious slowdown on your 1-4 processor home machine just so you could brag that linux scales well on 64-processor machines (that very, very few people own)?
Why on earth would you want linux on a 256p Origin 2000? Because IRIX scales too well? Seriously, what technical merit would Linux have over IRIX? Linux is a great desktop operating system, and IRIX is a great high-end OS.? Do you think Linux is _always_ the right thing?
Wow, big talk. You must be an 3L1T3 K3R|\|3L |-|4CK3R, d00d. While I don't know enough to defend HPUX, nor older versions of IRIX, IRIX 6.5 is really state-of-the-art; robust, stable, and good at what it's trying to be good at (scalability, HPC).
>There's a difference between scaling and scaling well. SGI hasn't figured out the latter yet.
Ahem. SGI is very competitive with Sun in scalability-sensitive benchmarks like TPC-D, and is building bigger single-system image boxes than anyone, bar none (several shipped 256p O2000s now). So, please quantify your complaint somewhat. What, in your experience, are troublesome bottleknecks in IRIX 6.5?
Slashdot Mirror
I don't understand the level of panic I'm seeing in most of the replies to this article. Have any of you folks actually read the legislation? Most of it consists of running "sed -e s/phone/phone, voice or internet" on existing laws. E.g., the ability to obtain IP address/name pairs from cable companies is analogous to the ability to map phone numbers to names. We're not exactly shredding the Bill of Rights, here.
There is a real tension between civil liberties and physical safety, no matter what Ben Franklin said; we have enemies who want to slaughter us wholesale, and the freedoms available to them in this country are enabling them to do so. In this context, the USA Patriot Act is a reasonable compromise, despite the newspeak name. The freedoms it sacrifices are non-essential (yes, there is such a thing), and yet it has a fighting chance of being effective. It represents a sweet-spot in the freedom/safety trade-off.
Even if it were the piece of totalitarian toilet paper some would have us believe, it at least has a sunset clause. I.e., on Dec. 31, 2005, the USA Patriot Act ceases to be the law of the land. Not quite what you'd expect from a fascist power-grab.
I suspect the most hyperbolic complaints about this piece of legislation come from people who are upset about the general erosion of civil liberties underway. If you fall into this category, your energy is wasted on the USA Patriot Act. Executive orders allowing military tribunals and spying on lawyers are massively more troubling than the FBI being able to find out whose machine is at 65.12.14.153; if you don't understand why, I'm afraid you've been spending too much time on slashdot.
> Its not "uninformed garbage", its quite insightful.
No, it's uninformed garbage. Animat might have had a point if he was advocating doing away with paging to backing store. Indeed, most modern operating systems treat situations that heavily use the backing store as pathological; they only care that they work, not that they work well or fast.
But, virtual memory is still a boon, even in these days of cheap RAM. I've even written an instructional operating system that uses virtual memory, but doesn't page to backing store. Why? So you don't need to relocate executables when loading them; for shared libraries; to demand-paged executables; to make integration with the buffer cache easier; to support the mmap(2) system call in all its richness; etc. Animat is ignorant of these advantages ("uninformed"); he might also be willfully ignoring them in order to make a more bold-sounding, moderation-friendly post ("garbage").
I work for VMware, but I don't speak for them. While I've been trying to hold my tongue through some of the more absurd flames, this seems like a genuine misunderstanding. Efficiently virtualizing the x86, or unvirtualizable architectures in general, is still arguably an unsolved problem.
Some architectures make writing virtualizers easy. If every instruction that examines or modifies supervisor state traps when run from user mode, a simple virtualizer is quite tractable: you establish a trap handler which decodes the faulting instruction and emulates it "by hand", and then restarts the guest OS at the next instruction.
Unfortunately, x86 instructions may or may not modify supervisor state. When run from user mode, these instructions silently fail, rather than trap. For example, the x86 program:
pushf
and (esp), ~(0x40)
popf
Will clear interrupts if run from supervisor mode. When run in user mode, it is an elaborate no-op. The cpu does not trap to indicate the attempt by the user to disable interrupts; it simply ignores the attempt.
Fine, you say. Simply write a virtualizer that behaves like a debugger; it can scan guest OS code ahead, and look for popfs, or any other problematic instruction. Stick hardware breakpoints on those instructions, and change your trap handler to a breakpoint handler. Sounds good. You have the following problems:
My job prohibits my discussing how VMware approaches these problems, and for lack of knowledge I can't tell you how Plex86 approaches them. However, this should give a flavor for some of the problems in virtualizing an unvirtualizable architecture.
> true, then I won't shed any tears for sales they lose to Plex86.
Sigh.
Obdisclaimer: I work for VMware, I don't speak for them, believe what you want to believe, etc.
Kevin Lawton started those rumors, possibly accidentally. They are quite untrue, as Kevin himself probably realizes. If bochs is such a great starting place for making a virtual machine monitor, how come Kevin himself has had such trouble doing it?
The complete story, as I understand it: a few years ago, Mendel Rosenblum, a professor at Stanford, was looking for a platform to teach an operating systems course on. In order to evaluate Bochs, he asked Kevin for a free evaluation copy, which Kevin graciously supplied. Mendel ultimately decided against Bochs, in favor of SimOS.
A completely unrelated fact about Mendel Rosenblum is that he has been doing fundamental research on making virtual machine monitors for "unvirtualizable" platforms for years. See, for example, Disco, a VMM for the mips architecture. Rosenblum and some of his graduate students had an idea for making a VMM for i386, and VMware was born about two years ago.
Once VMware came out, Kevin was an enthusiastic user. You can still go onto our public NNTP server and see Kevin helping out other users of VMware. He eventually decided he wanted an open source VMware, and started recruiting folks on the VMware newsgroups. He then started telling stories of the form: "A couple years ago, I gave a source license for Bochs to Mendel; now he's formed VMware... Hmm, strange...", intending to leave the impression that VMware "stole" Bochs.
This is nonsense, and you don't have to take my word for it. It's nonsense for fundamental technical reasons. It's as if RMS said, "Hmm, a few years ago, I gave the source for a C compiler to Sun, and a few years later they come out with Solaris.... Hmm..." It's just a non-sequitur. CPU emulators and virtual machine monitors are different kinds of software. I realize that from the end-user perspective, VMware and Bochs appear similar: they both end up as PCs in a window. But they are unrelated in terms of fundamental technology. I'm sure at this point in developing plex86, Kevin probably realizes this, which is why he doesn't insinuate that VMware is somehow based on Bochs as often as he used to circa one year ago.
I was lucky to be exposed to the ideas of Dr. Sarno. The high-order bits here are that Sarno thinks that many common chronic pain syndromes are caused by a complex psychological process, rather than damage to the joints and connective tissue. Remarkably, for most people having these symptoms, simply realizing that they are of psychological genesis is enough to banish them.
While I was initially skeptical of the apparently macho idea that "it was all in my head," Sarno's hypothesis has worked for me. I am 100% cured, without any fancy keyboards, chairs, elaborate icing/heating/rest/drug regimens, or any other conventional treatments for RSI. I am strongly convinced that Sarno is on to something important here, and I strongly recommend that others suffering from RSI at least give his ideas some serious thought.
They got started with the Bochs software Kevin wrote and let them have for free.
Kevin Lawton occasionally makes this insinuation, though even he isn't cracked enough to make the claim outright. Bochs is an emulator, VMware is a virtual machine monitor. Different technology, people. As Kevin Lawton has been discovering for the last year and a half or so, Bochs doesn't help you make something like VMware.
VMware was founded by Mendel Rosenblum of Stanford, and was an outgrowth of his Disco/SimOS research projects. Read some of the papers here for some of the research that made VMware possible. Notice that none of it has anything to do with emulation.
I would think the people involved would have been primarily irradiated with neutrons; those are, after all the stuff of fission, and this was a criticality accident.
> Anyone who has used IRIX knows how horrible it
> is at multi-tasking (I recall compiling on an O2
> or an Octane and witnessing other proesses grind
> to a halt) and other functionality that we take
> for granted under other operating systems.
Wow, that really hasn't been my experience with IRIX, although I am unable to speak for versions earlier than 6.5. Were you running 6.3 or something? Compiles making my machine sluggish has always been my beef with Linux...
As for "functionality we take for granted in other operating systems," from a purely functional perspective, I can't think of a single advantage Linux has on IRIX. It's not easy to make a uniprocessor, virtual memory OS, but it's not terribly hard, either. People do it in undergrauate classes every year. So far, all of the problems that Linux has successfully addressed were addressed a decade ago by some commercial OS. Anything newer, Linux struggles with. Linux's filesystem, real-time, and SMP are crude caricatures of the state of the art, and these are areas which are hugely important to large segments of SGI's customer base.
I love SGI's products. Hell, I'm typing this wearing my "Silicon Graphics: World's Greatest Computer Company" T-shirt, and I think there was a time when it was. It saddens me to see IRIX go, not just because I worked on it, but also because I think it's bad for SGI. From SGI's point of view, Linux has all the problems NT has (it requires ISV's to port, it isn't as technically mature as SGI needs it to be, it doesn't currently run well on SGI hardware). As gratifying as Linux folks might find the pats on the head from SGI, this Linux hoo-haa is a panicky, desperate move. Not a good sign.
Ah. So you didn't read the press release.
:-)
The key to any OS is long-term credibility.
QNX has been around since 1980. 19 years ago, I figure Linus Torvalds was hacking helloworld in AppleSoft BASIC, maybe. Plenty of long-term credibility, I'd think.
Other than that they seem to be offering features that are already done better by other OSs.
Real-time. QNX owns real-time UNIX, and always has. SGI and Sun didn't weren't building real-time systems worthy of the name until '95-ish. If you're building a system that lowers the control rods into a nuclear reactor in response to temperature, and a 1ms delay will cause a meltdown, would you turn to Linux? Oops! I'm sorry, you just irradiated a large chunk of North America. Perhaps you'll consider QNX next time 'round
Notice that all the engineering that goes into making a real-time system can help out with other stuff too. E.g., those low low dispatch times presumably help multimedia apps.
All the success stories for the "bazaar" model have been with work-a-day, mature technologies. Linux, Apache, and Perl all have very crisp definitions of their functionality: POSIX, the HTTP spec, and Wall's specs for perl serve as black-or-white, in-or-out quality metrics. Is it a coincidence that all the major successes of open source have been in such well-defined areas? I think not. Continuity in function encourages continuity in form, which is to say, these projects tend not to change too much.
Seriously, folks. Go look at the Linux kernel source in version 1.2, and you will see vm_area's, a swap cache, that bloody weird goodness-based scheduler, vnodes, bottom halves, etc. These kernel abstractions have been refined, tuned, occasionally reimplemented, etc., ad infinitum between 1.2 and 2.3, but they still serve the same purposes, and have similar semantics. It's a good thing, too; it's taken me all the time between 1.2 and 2.3 to gain enough confidence in the kernel to make substantial changes. If Linus violently reorganized the kernel every couple of weeks, those precious few people employed full-time to work on the kernel might be able to mentally track the changes, but he'd lose all the weekend warriors, many of whom have useful contributions to make.
Games present almost the opposite situation. Their quality is largely a subjective matter, and since tastes are always changing, so will the requirements for games. The hardware (and people's expectations) change so rapidly that retaining an engine for more than a year or two is unlikely in the extreme. If you're going to throw out the code base that often, only people who earn their living working on the code will be able to keep up, and that eliminates any supposed open source advantage.
> KERNEL MODULES.
Didn't start with Linux, or even UNIX. Various kernel overlay schemes were used in the '70s to help shoehorn OSes into tiny memory environments; and even though people don't think of them that way, modules really are just an overlay scheme with some hooks. In any event, I know at least Solaris 2 had a very modern, modular kernel from the git-go...
Linux is very much your father's UNIX kernel. Innovation was never the idea; Linux instead looks at the engineering of other kernels and tries to draw consensus. The workhorses of the kernel (VM, ext2) are much, much more similar to the competition than different. The one weird bit about core Linux, its scheduler, is worse in my opinion than the competition...
> As far as the people working there, they're not being forced to work there.
Wow. You sound as though you've never known somebody who works in the service sector in your life. In short: the premise that people have their choice of occupation is wrong, wrong, wrong. Remember all those people going blind and losing limbs in factories around the turn of the century? Working 90-hr. weeks and so forth? Was anybody "forcing" them to work? Oh, yes, that little fact of survival... Not everyone is as privileged as you. People who wait tables deserve the same protection from occupational hazards as do workers in the steel industry, nuclear power, etc.
While we're at it, to hell with the minimum wage: after all, if $0.25/hr isn't good enough, why don't people just get higher-paying jobs!? No one's forcing them to work in those sweatshops!
Yeeps. I hope you don't vote.
The short answer is: "mmap + SIGILL + SIGSEGV". If you're curious about the details, you might want to check out the Brown Simulator, which provides a full MMU at user-level on top of Solaris.
It seems likely that these new SGI hires would be doing i386, possibly IA64 work. I think it is highly unlikely that they'll be putting Linux on 128p O2000's, now or anytime in the future. SGI has spent years turning IRIX into a scalable, reliable, hard-real-time OS; IRIX's only peer on high-end hardware is Solaris. The price of making IRIX scale this well has been (as for Solaris) poorer uniprocessor performance, which is Linux's strength.
SGI (if they aren't crazy) isn't interested in spending another six years turning Linux into the operating system they already have; instead they want to use Linux's desktop strength to shore up a weak area for their OS.
>Don't you think it would be difficult for Thompson to accept that a 21-year-old kid had come along and done a better job with Thompson's own idea than Thompson could do with all of the power of ATT behind him?
This is hubris, Bruce. The truly enduring thing about UNIX isn't any particular implementation, but the generality of the API. The design that Ken and Dennis set forth has survived the introduction of networks, graphics devices, multiprocessors, etc. Linus stood on the shoulders of giants, and Ken Thompson is one of those giants.
> For all he knows or claims to know about Unix,
Hold it right there. The man wrote UNIX; end of story. He didn't just come along and hack out yet another clone, which is really all Linus has done; without Ken there would be no such thing as UNIX. Whether you agree with him or not, there is no room for skepticism about his credentials. He knows what he is talking about, and his criticism generally is not to be taken lightly.
Would you and your self-congratulatory Linux bigot friends just disappear please? This kind of obviously false assertion just makes Linux look stupid. SGI has much, MUCH hardware that would humble any Linux PC as a server (yes, really), graphics workstation (really REALLY), or supercomputing (which Linux isn't seriously attempting to do anyway).
Don't take my word for it; take an architecture class and learn why beowulf is only fast on the problems that it's easy to be fast on. That same class might help you figure out why an O2K will whomp ass all over your cousin Jed's quad Xeon webserver. And sitting down in front of an Octane should make you pretty embarassed about that "Doom" comment...
so you're all claiming that Linux isn't just software now? Man. It sure seemed like software to me. I must have been using it wrong all these years.
Sorry, I call 'em like I see 'em. There are trade-offs involved in making a kernel scale to big numbers of cpus, and Linus isn't willing to make them (rightly so, I might add). Let me put it to you this way: would you accept a serious slowdown on your 1-4 processor home machine just so you could brag that linux scales well on 64-processor machines (that very, very few people own)?
Why on earth would you want linux on a 256p Origin 2000? Because IRIX scales too well? Seriously, what technical merit would Linux have over IRIX? Linux is a great desktop operating system, and IRIX is a great high-end OS.? Do you think Linux is _always_ the right thing?
Preview lies. That first paragraph:
Wow, big talk. You must be an 3L1T3 K3R|\|3L |-|4CK3R, d00d. While I don't know enough to defend HPUX, nor older versions of IRIX, IRIX 6.5 is really state-of-the-art; robust, stable, and good at what it's trying to be good at (scalability, HPC).
>There's a difference between scaling and scaling well. SGI hasn't figured out the latter yet.
Ahem. SGI is very competitive with Sun in scalability-sensitive benchmarks like TPC-D, and is building bigger single-system image boxes than anyone, bar none (several shipped 256p O2000s now). So, please quantify your complaint somewhat. What, in your experience, are troublesome bottleknecks in IRIX 6.5?