I've read it, and I think he's wrong. A well-designed modern microkernel OS system should do no more copying than a monolithic kernel does (and it does, say, between user-space and kernel-space).
I suspect that Linus was talking about old systems like Mach, Minix and Windows NT, and not modern systems like QNX, L4 or BeOS. If so, his mistake is understandable.
Just to clarify, aheitner's assertion was not that Hurd or Mach's IPC is slow, but that any microkernel-based OS will be slow compared with a monolithic kernel-based OS. I don't know enough about Hurd to comment specifically, but there are plenty of modern microkernel-based OSes which are competitive in this area (e.g. L4, BeOS, QNX).
Mach is an old-style microkernel. It comes from the same era as Windows NT.
QNX/Neutrino is a modern microkernel which comes from the same era as BeOS.
There's no comparison. Mach is big and tries to do too much, even for a microkernel. But it comes from an era when we throught that the most important advantage of microkernels was flexibility. We now know that by making them very "micro" they can give performance too.
You won't find hard real-time in Hurd any time soon. Not as long as they're using Mach and allow use of Linux device drivers, anyway. Hard real-time needs to be designed in everywhere, from the driver to the kernel to the application.
The world does need a free real-time general-purpose OS, you're right. Real-time is becoming ever more important even in server applications (e.g. ATM routing, streaming media). You won't find it in the Hurd, but there are one or two projects happening in relative secrecy at the moment. Watch this space.
First: You don't need to spend any more time copying data between address spaces in a modern microkernel OS than in a monolithic-kernel OS unless you've designed it badly. For example, it's lunacy to put your disk driver and file system driver in different address spaces. Performance-conscious microkernels do what monolithic kernels do: use dynamically loaded objects. The difference is that the disk server dynamically loads the filesystem it's going to use, or the network server loads the NIC driver and protocol implementations. There's no reason at all why a microkernel OS can't use zero-copy networking. (I think that BeOS even did zero-copy sound in some situations. Digitised data would come in off the soundcard and go straight into the mixer. Try doing that in Linux without hacking the kernel.)
As for context switches, true, you have to do more of them, but you get performance gains elsewhere as a result, as I have noted previously.
If you need a microkernel mantra, here it is: "It's not a penalty, it's a tradeoff." Repeat until enlightened.:-)
Nope. The Linux developers are hell-bent on sticking to their monolithic design. Even if you could develop the Hurd as a set of patches, they would never make it into the "standard Linux kernel". (Curious use of the word "standard", BTW.)
The rift of Hurd vs Linux is like vi vs emacs. Vi and Hurd are meant to be a small tools designed to work in conjunction with other small specialised tools, the whole being greater than the sum of the parts. Emacs and Linux are meant to be "all features under one roof".
Actually, that's a good way of looking at your question. Asking "can't you just implement these features in Linux?" is like asking "why do you need all those POSIX commands like diff(1); can't you just implement that in Emacs?" The answer is "yes", but would you want to?
My first comment is that "performance" means different things to different people. To some it means "throughput", that is, the amount of work that the system can do just prior to being overloaded. To some it means how well it can handle overload. To some it means low latency, that is, that the system can respond to an important event quickly. Which one is important for you depends on what you're doing.
Secondly, you're basing your assumptions on "microkernels" like Mach, which dates from around the same era as the original Windows NT. That's an "old style" microkernel. Back then, we thought that the only advantage of using microkernels was flexibility, so kernels didn't have to be very "micro".
Nowadays we know that merely reducing the kernel's domain of influence doesn't buy you much. You also need to simplify your kernel to realise performance gains. You do lose something (cost of context switch etc) but you also gain lots too, so it's not so much of a penalty, but rather it's a tradeoff.
For example, consider this: Linux often has to suspend a task deep inside a system call. If you call read() on a block of disk which is not in the buffer cache, say, you need to suspend until the block is read in from disk. A monolithic kernel may have to do this for a hundred reasons, depending on which modules are loaded. So a context switch consists of dumping registers on the kernel stack then switching stacks.
Now consider a microkernel. You already know in advance what operations you may have to suspend on, and that number is quite small. (In the read() example, you only suspend on IPC while the server responsible for disk I/O does the hard work.) So you can separate the "front half" of each system call from the "back half". You can come up close to the surface and then context switch if necessary. (Note: You have to do this anyway on a modern system, because a higher priority task may have unblocked during the system call.) Once you've done that, each thread doesn't need its own kernel stack, which makes the context switch a little cheaper, saves memory, makes thread creation cheaper, and the kernel can be made re-entrant, delivering an IRQ in the middle of delivering another IRQ, thus improving latency. It also means you don't need to hack around the problem of signal delivery while suspended. (BSD does this by ensuring that the "front half" of every system call is idempotent, and thus possibly less efficient than it could be.)
So you can see that focussing on the cost of context switching alone can be misleading.
Plus, of course, keep this in mind: if raw throughput was our most important criterion, we wouldn't have virtual memory.
I guess. But there's a big difference between effects houses like WETA or Animal Logic and distributors like Disney and Fox. Effects houses do what they're paid to do. They don't dictate intellectually property policy.
You're right about the communication problem, IMO. That's why if ternary computing takes on, it will be limited to "inside" a single chip for a while. For example, an FPU or a DSP processor could make use of ternary arithmetic internally, converting to and from binary when you need to go off-chip. That may have advantages. A general-purpose ternary computer, however, probably won't be useful for a very long time if at all.
MA means nobody under 15 can buy or watch unless accompanied by a parent or guardian. Below MA there is no legal restriction. The full details are available if you're curious.
IMO the best feature about the Australian ratings system is "consumer advice". Anything rated over G for video and over PG for film or television must be accompanied by the reasons why it got that rating. So the South Park film is actually rated "MA; high level coarse language, sexual references". Particularly useful is the consumer advice "adult themes". That covers themes like marital breakup, suicidal feelings, racial prejudice and so on. These are themes which younger children may not be able to understand or which may require parental assistance in understanding. As I've said before, I don't mind my daughter (eventually; she's not even 2 yet) seeing nudity, but I'd be careful about letting her see depictions of racial hate groups before she's ready to understand it.
Yup, the ACT is a piece of federal land about half-way between Sydney and Melbourne, entirely surrounded by NSW. (Slight fudge: I think that the Jervis Bay naval base might technically be ACT land, but don't hold me to that.)
Australia's rating system, for example, is less prudent than that of the US (e.g. South Park is MA rather than R). The drawback is that other countried tend to have non-voluntary ratings with government-mandated restrictions.
In Australia, for example, R material must not be sold to minors no matter who accompanies them. This is the law, not the policy of theatres. In addition, sale of material which is unrated or "refused classification" is illegal in all states. Not in territories like the ACT (our equivalent of DC), though, so you can still get it via mail order thanks to the interstate commerce clause.
As RMS will no doubt point out, "free" means "not encumbered", not "at no cost". If you have to pay money to someone else to sell a copy of this software, it's encumbered and therefore not "free" in the FSF meaning of the word.
Xah is correct except for one detail. As far as the scheduler is concerned, pre-emptable threads running inside the kernel should be pretty much the same as pre-emptable user-space threads in a microkernel system. They should be able to be killed and/or restarted if they've hung.
The one mistake I think xah made was using the term "process". Linux's current design encourages the confusion between threads and processes by implementing threads as processes that happen to share "process stuff" (address space, file handles, credentials, rlimits etc).
Yeah, that's right. Sorry, misunderstood the bracketing rules.
Incidentally, s and k can be constructed from another combinator (can't remember what it's called right now). Unfortunately it's not a supercombinator, so the graph reduction rules aren't simple to implement.
The DoJ (well, John Ashcroft in his official capacity) is being sued by Felten et al. I'm not certain exactly what they're trying to get into case law, but I'm pretty sure it's the idea that the DMCA does not apply to legitimate scientific researchers doing legitimate scientific research, or something close to it, and to get that precedent established before anyone is prosecuted or sued for DMCA violation.
This reply from the DoJ basically said "we didn't try to prosecute these particular people, so what are they complaining about?"
I don't know whether, under US law, Felten et al are technically allowed to fight the possibility of a prosecution rather than an actual prosecution, but hats off to them if they are. It'll make the world safer for those who come after them. For example, it'll make things much easier for the first researcher who discovers a security flaw in the SSSCA-mandated DRM system.
I think that Col. Klink is actually confusing Xerxes with King Canute (or Knud).
Canute's courtiers, during their profuse brown-nosing, claimed that Canute was "So great, he could command the tides of the sea to go back". He made his point in return by having his throne carried to the seashore, and he sat on it as the tide came in, commanding the waves to advance no further. The point being that kings, while `great' in the minds of men, were nothing in the face of God's power. Were Canute an atheist, he would no doubt have done the same thing, only citing the "power of nature".
This reminds me of a headline from The Onion book: "World's Largest Metaphor Hit By Iceberg".
The crews are cheaper (we're used to producing films on budgets, unlike the Hollywood inflationary system), the air is cleaner, the cocaine is plentiful... why not choose Sydney?
BTW, LotR was filmed in New Zealand, not Australia. Australia has a relationship with New Zealand not unlike that which the United States has with Canada: for all intents and purposes, we're pretty much the same, but we give each other hell over it.
First, the story is that Yahoo Serious is appealing the August decision.
Secondly, Yahoo! the company has registered a trademark in Australia for use in, amongst other things, "Entertainment services including television programmes". On the face of it, he may have a case that using "Yahoo!" as a trademark in the entertainment industry would be "confusingly similar" to his name, even though he has not trademarked his name.
Well, RSA isn't exactly a full cryptosystem by itself, but this does show how easy it is.
To review the OpenPGP RFC prior to publication, I re-implemented PGP's decryption and signature checking operations working just from the spec. Admittedly I didn't write my own big integer library, but I did implement 3DES and SHA-1 myself.
It took a week.
And remember, most of that was getting the details of the protocol correct. (I spent a day just getting PKCS encoding right, for example. That's unfortunately not in the OpenPGP spec.) A terrorist who was not trying for inter-operability with PGP probably need not bother with that.
FlexLM, the bane of many a sysadmin's life, is very similar.
A lot of graphics software (e.g. Maya, Photorealistic RenderMan) in particular is licensed with FLEXlm. This form of licensing is particularly badly suited to this kind of product, because a) managing 1000 licences is a logistic nightmare, and b) you tend to only use your "maximum" number of licences during certain peak times (when you get close to delivery).
Slashdot Mirror
I've read it, and I think he's wrong. A well-designed modern microkernel OS system should do no more copying than a monolithic kernel does (and it does, say, between user-space and kernel-space).
I suspect that Linus was talking about old systems like Mach, Minix and Windows NT, and not modern systems like QNX, L4 or BeOS. If so, his mistake is understandable.
Just to clarify, aheitner's assertion was not that Hurd or Mach's IPC is slow, but that any microkernel-based OS will be slow compared with a monolithic kernel-based OS. I don't know enough about Hurd to comment specifically, but there are plenty of modern microkernel-based OSes which are competitive in this area (e.g. L4, BeOS, QNX).
Mach is an old-style microkernel. It comes from the same era as Windows NT.
QNX/Neutrino is a modern microkernel which comes from the same era as BeOS.
There's no comparison. Mach is big and tries to do too much, even for a microkernel. But it comes from an era when we throught that the most important advantage of microkernels was flexibility. We now know that by making them very "micro" they can give performance too.
You won't find hard real-time in Hurd any time soon. Not as long as they're using Mach and allow use of Linux device drivers, anyway. Hard real-time needs to be designed in everywhere, from the driver to the kernel to the application.
The world does need a free real-time general-purpose OS, you're right. Real-time is becoming ever more important even in server applications (e.g. ATM routing, streaming media). You won't find it in the Hurd, but there are one or two projects happening in relative secrecy at the moment. Watch this space.
First: You don't need to spend any more time copying data between address spaces in a modern microkernel OS than in a monolithic-kernel OS unless you've designed it badly. For example, it's lunacy to put your disk driver and file system driver in different address spaces. Performance-conscious microkernels do what monolithic kernels do: use dynamically loaded objects. The difference is that the disk server dynamically loads the filesystem it's going to use, or the network server loads the NIC driver and protocol implementations. There's no reason at all why a microkernel OS can't use zero-copy networking. (I think that BeOS even did zero-copy sound in some situations. Digitised data would come in off the soundcard and go straight into the mixer. Try doing that in Linux without hacking the kernel.)
As for context switches, true, you have to do more of them, but you get performance gains elsewhere as a result, as I have noted previously.
If you need a microkernel mantra, here it is: "It's not a penalty, it's a tradeoff." Repeat until enlightened. :-)
Nope. The Linux developers are hell-bent on sticking to their monolithic design. Even if you could develop the Hurd as a set of patches, they would never make it into the "standard Linux kernel". (Curious use of the word "standard", BTW.)
The rift of Hurd vs Linux is like vi vs emacs. Vi and Hurd are meant to be a small tools designed to work in conjunction with other small specialised tools, the whole being greater than the sum of the parts. Emacs and Linux are meant to be "all features under one roof".
Actually, that's a good way of looking at your question. Asking "can't you just implement these features in Linux?" is like asking "why do you need all those POSIX commands like diff(1); can't you just implement that in Emacs?" The answer is "yes", but would you want to?
My first comment is that "performance" means different things to different people. To some it means "throughput", that is, the amount of work that the system can do just prior to being overloaded. To some it means how well it can handle overload. To some it means low latency, that is, that the system can respond to an important event quickly. Which one is important for you depends on what you're doing.
Secondly, you're basing your assumptions on "microkernels" like Mach, which dates from around the same era as the original Windows NT. That's an "old style" microkernel. Back then, we thought that the only advantage of using microkernels was flexibility, so kernels didn't have to be very "micro".
Nowadays we know that merely reducing the kernel's domain of influence doesn't buy you much. You also need to simplify your kernel to realise performance gains. You do lose something (cost of context switch etc) but you also gain lots too, so it's not so much of a penalty, but rather it's a tradeoff.
For example, consider this: Linux often has to suspend a task deep inside a system call. If you call read() on a block of disk which is not in the buffer cache, say, you need to suspend until the block is read in from disk. A monolithic kernel may have to do this for a hundred reasons, depending on which modules are loaded. So a context switch consists of dumping registers on the kernel stack then switching stacks.
Now consider a microkernel. You already know in advance what operations you may have to suspend on, and that number is quite small. (In the read() example, you only suspend on IPC while the server responsible for disk I/O does the hard work.) So you can separate the "front half" of each system call from the "back half". You can come up close to the surface and then context switch if necessary. (Note: You have to do this anyway on a modern system, because a higher priority task may have unblocked during the system call.) Once you've done that, each thread doesn't need its own kernel stack, which makes the context switch a little cheaper, saves memory, makes thread creation cheaper, and the kernel can be made re-entrant, delivering an IRQ in the middle of delivering another IRQ, thus improving latency. It also means you don't need to hack around the problem of signal delivery while suspended. (BSD does this by ensuring that the "front half" of every system call is idempotent, and thus possibly less efficient than it could be.)
So you can see that focussing on the cost of context switching alone can be misleading.
Plus, of course, keep this in mind: if raw throughput was our most important criterion, we wouldn't have virtual memory.
...and why isn't microsoft.com in your trusted zone, hmm? Don't you trust them or something?
I guess. But there's a big difference between effects houses like WETA or Animal Logic and distributors like Disney and Fox. Effects houses do what they're paid to do. They don't dictate intellectually property policy.
You're right about the communication problem, IMO. That's why if ternary computing takes on, it will be limited to "inside" a single chip for a while. For example, an FPU or a DSP processor could make use of ternary arithmetic internally, converting to and from binary when you need to go off-chip. That may have advantages. A general-purpose ternary computer, however, probably won't be useful for a very long time if at all.
Read the article. That's exactly what he said. Here's the title and the subtitle:
MA means nobody under 15 can buy or watch unless accompanied by a parent or guardian. Below MA there is no legal restriction. The full details are available if you're curious.
IMO the best feature about the Australian ratings system is "consumer advice". Anything rated over G for video and over PG for film or television must be accompanied by the reasons why it got that rating. So the South Park film is actually rated "MA; high level coarse language, sexual references". Particularly useful is the consumer advice "adult themes". That covers themes like marital breakup, suicidal feelings, racial prejudice and so on. These are themes which younger children may not be able to understand or which may require parental assistance in understanding. As I've said before, I don't mind my daughter (eventually; she's not even 2 yet) seeing nudity, but I'd be careful about letting her see depictions of racial hate groups before she's ready to understand it.
Yup, the ACT is a piece of federal land about half-way between Sydney and Melbourne, entirely surrounded by NSW. (Slight fudge: I think that the Jervis Bay naval base might technically be ACT land, but don't hold me to that.)
How would you rate a mailing list or newsgroup archive? Or slashdot?
Just curious.
Australia's rating system, for example, is less prudent than that of the US (e.g. South Park is MA rather than R). The drawback is that other countried tend to have non-voluntary ratings with government-mandated restrictions.
In Australia, for example, R material must not be sold to minors no matter who accompanies them. This is the law, not the policy of theatres. In addition, sale of material which is unrated or "refused classification" is illegal in all states. Not in territories like the ACT (our equivalent of DC), though, so you can still get it via mail order thanks to the interstate commerce clause.
Does it come with an open sourced barcode reader driver?
As RMS will no doubt point out, "free" means "not encumbered", not "at no cost". If you have to pay money to someone else to sell a copy of this software, it's encumbered and therefore not "free" in the FSF meaning of the word.
Good piece of lateral thinking, though.
Xah is correct except for one detail. As far as the scheduler is concerned, pre-emptable threads running inside the kernel should be pretty much the same as pre-emptable user-space threads in a microkernel system. They should be able to be killed and/or restarted if they've hung.
The one mistake I think xah made was using the term "process". Linux's current design encourages the confusion between threads and processes by implementing threads as processes that happen to share "process stuff" (address space, file handles, credentials, rlimits etc).
Yeah, that's right. Sorry, misunderstood the bracketing rules.
Incidentally, s and k can be constructed from another combinator (can't remember what it's called right now). Unfortunately it's not a supercombinator, so the graph reduction rules aren't simple to implement.
Users of unlambda should note that the "i" combinator is strictly speaking unnecessary. For further obfuscation, replace "i" with "skk".
It isn't an amicus brief. The Attorney General is a named defendant in the case.
The DoJ (well, John Ashcroft in his official capacity) is being sued by Felten et al. I'm not certain exactly what they're trying to get into case law, but I'm pretty sure it's the idea that the DMCA does not apply to legitimate scientific researchers doing legitimate scientific research, or something close to it, and to get that precedent established before anyone is prosecuted or sued for DMCA violation.
This reply from the DoJ basically said "we didn't try to prosecute these particular people, so what are they complaining about?"
I don't know whether, under US law, Felten et al are technically allowed to fight the possibility of a prosecution rather than an actual prosecution, but hats off to them if they are. It'll make the world safer for those who come after them. For example, it'll make things much easier for the first researcher who discovers a security flaw in the SSSCA-mandated DRM system.
I think that Col. Klink is actually confusing Xerxes with King Canute (or Knud).
Canute's courtiers, during their profuse brown-nosing, claimed that Canute was "So great, he could command the tides of the sea to go back". He made his point in return by having his throne carried to the seashore, and he sat on it as the tide came in, commanding the waves to advance no further. The point being that kings, while `great' in the minds of men, were nothing in the face of God's power. Were Canute an atheist, he would no doubt have done the same thing, only citing the "power of nature".
This reminds me of a headline from The Onion book: "World's Largest Metaphor Hit By Iceberg".
The crews are cheaper (we're used to producing films on budgets, unlike the Hollywood inflationary system), the air is cleaner, the cocaine is plentiful... why not choose Sydney?
BTW, LotR was filmed in New Zealand, not Australia. Australia has a relationship with New Zealand not unlike that which the United States has with Canada: for all intents and purposes, we're pretty much the same, but we give each other hell over it.
First, the story is that Yahoo Serious is appealing the August decision.
Secondly, Yahoo! the company has registered a trademark in Australia for use in, amongst other things, "Entertainment services including television programmes". On the face of it, he may have a case that using "Yahoo!" as a trademark in the entertainment industry would be "confusingly similar" to his name, even though he has not trademarked his name.
Well, RSA isn't exactly a full cryptosystem by itself, but this does show how easy it is.
To review the OpenPGP RFC prior to publication, I re-implemented PGP's decryption and signature checking operations working just from the spec. Admittedly I didn't write my own big integer library, but I did implement 3DES and SHA-1 myself.
It took a week.
And remember, most of that was getting the details of the protocol correct. (I spent a day just getting PKCS encoding right, for example. That's unfortunately not in the OpenPGP spec.) A terrorist who was not trying for inter-operability with PGP probably need not bother with that.
FlexLM, the bane of many a sysadmin's life, is very similar.
A lot of graphics software (e.g. Maya, Photorealistic RenderMan) in particular is licensed with FLEXlm. This form of licensing is particularly badly suited to this kind of product, because a) managing 1000 licences is a logistic nightmare, and b) you tend to only use your "maximum" number of licences during certain peak times (when you get close to delivery).