In Djirbal, there are also four. According to Everything2, they are, roughly:
Bayi: Masculine (men, male animals etc), many animals, the moon, storms, rainbows, boomerangs, etc.
Balan: Feminine (women, female animals etc), anything connected with water or fire (including fireflies, scorpions etc), other animals, the stars, shields, etc.
Balam: Edible plant material and derivatives thereof. (e.g. fruit, tubers, ferns, honey, cigarettes, wine, cake)
Bala: Neuter-abstract (e.g. noises, language, mud, stones, wind), parts of the body, meat, most trees.
The point of this is that "gender" doesn't make so much sense as a grammatical term, since it only applies to certain Indo-European languages, and even then not consistently. (I've never understood the rationale for "Das Mädchen" in German. Probably because there is no rationale.) The more inclusive term "noun class" makes more sense.
Since you asked, let's answer some of these questions:
Do you have the right to a health care worker's labor?
A health care worker has a choice as to whether they work in the public system or the private system. If they choose to work in the public system, then the answer to your question is "yes".
Is it right for an entity to force people to pay money? For the military, et al, it may be necessary, but it isn't for health care.
You answered your question here. "It may be necessary" to force people to pay money. Looks like you're just arguing about where the boundary lies to me.
And even if you do believe in an essential right to health care, should it be done by the government in addition to being paid for by it?
Ah, now this is a completely different question. The question of who actually does it is different in different countries. In Australia, for example, there aren't any government-employed GPs to a first approximation. You go to your doctor, then claim some or all of the costs back either at the surgery or at the insurance office. Much like would happen under a private system.
Competing private enterprise is almost always more efficient than the government, because people are motivated to do things well.
Private enterprise is more efficient than the government for the same reason that dictatorship is more efficient than democracy. Democratic governments, at least in theory, have openness and accountability constraints that don't apply to corporations. And the few constraints that do apply to corporations at the moment would definitely not apply under a pure libertarian system.
If a health care providing entity will get money and exist not matter how good it is, and no one's fortune depends on how well it does, what motivation is there for it to be efficient? In private enterprise, people strive to do better.
I could change a few words there and come up with a pretty plausible-sounding argument as to why open source software will inevitably be crap compared to proprietary offerings.
Health care professionals are still licensed. The threat of being sued for malpractice or losing ones licence is still there. But more to the point, most health care professionals aren't in that field for the money, but because they care about what they do. Much like any other field.
The Canadian health care system has a lot of problems, [...]
That's true, which is why it's a fallacy to look at just the Canadian system and say "these problems will be true of all nationalised health systems". No system is perfect, but the problems associated with each are a function of history and demographics as much as economics. Some countries have more sparsely distributed populations than others, for example.
Personally, I am glad that we have a free enterprise health care system in the U.S. and do not believe that will ever change.
Clearly, you can afford health care and/or are reasonably healthy.
Amusingly, in just about every other industrialised country, one common catch cry every time anyone wants to modify the system is "this would create a US-style system". Someone always makes that argument, kind of like Godwin's Law.
Part of the reason for this is that most of the stories we hear are about people who fall through the cracks, such as those who end up homeless and still in huge debt to pay for their cancer treatment. I have no doubt that there are many success stories, too.
99% of: conservatives aren't nazis or fascists, liberals aren't immoral elitists or communists, libertarians aren't uncaring or selfish.
Linux has built a system, it works and it's used everywhere. Microkernels are all niche [...]
One of Tanenbaum's central points is that Linux is not used everywhere. In particular, it's not used anywhere that hard-real-timeness, seriously paranoid robustness (e.g. in those applications where a hardware failure should not result in a reboot) etc are important.
The word "niche" is, much like "legacy", often used in places where a more overt dismissal would rightly be seen as unfair. The fact that Linux can do everything that you want it to do doesn't mean that you are the whole world, or that any site that doesn't look like yours is "niche", as opposed to "everywhere".
Even now, you occasionally get a pundit who points to legal risks in open source. The downgrading of the SCO case to what is basically a contract dispute with IBM doesn't change that, because pundits can be pretty stupid sometimes. While it's true that if Groklaw disappeared overnight, SCO would still lose, some of the paid mouthpieces wouldn't stop.
It is possible with alot of clever trickery to simulate message passing using zero-copy shared memory (this is what L3/L4/K42/QNX/etc... any microkernel wanting to do message passing quickly). And if done correctly it CAN perform in the same league as monolithic code for many things where the paradigm is a good fit. But there are ALWAYS situations where it is going to be desirable for seperate parts of an OS to directly touch the same memory in a cooperative manner, and when this is the case a microkernel just gets in your damn way...
I know a bit about the architecture of QNX, so let me just correct some things here.
QNX does not do zero-copy page table magic for IPC. The kernel directly copies the memory between address spaces. If you compare this with Linux, where it copies memory from user to kernel space, you'll see that the overhead is pretty much identical.
Having said that, there are areas where it's desirable for different "parts" of an OS to touch the same memory, but it's rare for those "parts" to be widely different. (I can't see, for example, why the POSIX message queue code will need to touch the same memory as a hard disk driver without passing through a user-space application first.) In such cases, QNX handles it by putting those parts in the same user-space server. In this setup, device drivers are shared objects which are loaded by user-space servers instead of the kernel.
Now to be fair, QNX isn't focussed on security first and foremost, it's focussed on hard real-timeness. The reason why it uses a small microkernel is so that the amount of code that could possibly stuff up any real-time guarantees is minimised. (There are other advantages, see below.) But still, the point here is that not all microkernels are made equal, and it is possible to satisfy the same "copy as little as possible" requirements that a modern macrokernel tries to do.
There is one advantage to modern microkernels (L4/QNX, not Mach) that hasn't been covered here yet, and that's that the kernels tend to be much simpler. You can leverage that to get more performance.
In a macrokernel OS, a task logically has two call stacks: One for the "user" code and one for the "kernel" code. If you are inside a system call and your task needs to be suspended, the kernel simply switches "kernel" stacks. (Yes, this is a simplification. Bear with me.)
Now consider a microkernel OS, where there is a limited number of simple system calls. If a task needs to be suspended during a system call, it can simply store the data that it needs to complete the system call in the thread state, and then return. When you wake up a thread, you first check in the thread state to see if a system call needs to be completed. If so, you do that before returning to the thread.
Yes, this makes the thread state structure slightly bigger, but in return, you don't need to have a separate kernel stack per thread. One per CPU is enough.
There are other tricks, of course, but this example illustrates the general idea: Microkernels can make system calls much cheaper, so you can afford to spend more time on things that in a macrokernel design would be classified as overhead. At the very least, it makes the analysis more complicated than merely saying "more copying == bad".
On the IA32, messing with address spaces is expensive. (This is part of Linus' complaint about COW.) Switching address spaces, for example, causes a complete TLB flush. Sure, the PTEs are likely to be in cache, but still, for a small IPC interaction (client -> server -> client), it's a noticable hit. More modern architectures make it much cheaper to mess with address spaces.
Having said that, L4 had an interesting approach which helped quite a bit. To understand how it works, you need to know a bit about the Intel architecture. Basically, there's a flat 32-bit virtual address space. On top of that, you have segment selectors, which address some region of that flat space.
Now consider an artificial but not unrealistic macrokernel operating system for a 32-bit architecture. You have 4Gb of address space. Let's divide this up into 3Gb of "user space" and 1Gb of "kernel space". Entering the kernel is fairly cheap because you don't need to swap address spaces.
Now consider and artifical but not unrealistic microkernel operating system. The kernel footprint is much smaller. Exactly how much smaller depends on things like how much dynamic memory it needs, but let's say it only takes 0.5Gb. You could keep the same memory map, and reserve the other 0.5Gb for servers which have a small memory footprint, such as device drivers. All "large" address spaces have the same "small" address spaces as part of their map. Then you can creatively use the IA32 segment registers to multiplex on top of the flat address space. Context switching from client to server to client will not actually change address spaces if the server is "small", making it almost as cheap as a system call in a monolithic kernel.
Amusingly, 64 bit architectures make this trick even more elegant, because you can devote even more of the address space to "small" servers, which don't even need to be that small.
Container ships don't have to move cargo from one part of the ship to another, on a regular basis.
Depends what you mean by "regular". Millions of dollars can be saved by ships moving cargo around so that what is needed in the next port is easy to get to by the time you arrive, while maintaining adequate weight balance. (This, incidentally, is a very interesting algorithmic problem. I believe it's NP-hard to do it with the minimum number of container moves.)
I hear what you're saying, but I have one proviso. There are a number of very decent modern cross-platform editors (Vim and Emacs being but two). Whatever editor you decide on, you spend most of your programming career in it, so you need to learn to use it well. This will pay off much, much more than being passingly familiar with a dozen editors.
(Disclaimer: Sure, passing familiarity has its uses. At the very least, learning how to get to and navigate the documentation for any editor you're likely to come into contact with will help you avoid getting lost.)
in the case of gitmo detainees, they have their tribunal
The first tribunal was held in November 2004, a full three years after the first detainees were captured. (To be fair, the tribunals were delayed by about four months due to their legal statis being challenged in the US courts.)
The Geneva Convention doesn't state how long you have to wait to get your tribunal, though the US has laws against indefinite detention without trial. Nevertheless, it does state that you should be afforded all of the rights of a POW while you wait. Whether or not the detainees were afforded those rights before November 2004 is a reasonable question to ask.
A server should never assume the *client* did sanity checking on the data it's sending anyway.
That's not what I said. What I said was that the server should be able to assume that its input has not been modified after sanity checking. vmsplice() appeared to break that assumption, but in retrospect, it was probably that I didn't understand what the previous poster was trying to get at.
Here is the problem with Theo. He is smart and opinionated. Having these two things in common make him a very difficult person to get along with if you are either Smart, but hold a different opinion because you come from a different set of assumptions - but especially if you are NOT smart and opinionated.
I know we all know this, but Linus has much the same problem, which is why he calls Neo-BSD developers rude names when they come to a different conclusion than him on some topic.
But, of course, that's all part of the charm. Hubris is one of the Larry Wall programmer virtues. There's nothing wrong with it so long as everyone understands that it's not personal. Neither Linus nor Theo would ever use a rude name against an individual developer or organisation unless they truly were not smart.
If you're reasons for not wanting an national ID are because the government will accumulate massive amounts of data about you, news flash: it's too late.
For the benefit of the non-Australians in the audience: In the last few years, our government has accidentally deported and detained (in immigration detention centres) several Australian citizens. I say "accidentally", but it's not as if "oops, sorry, we thought you were an illegal immigrant" is an adequate apology.
Once you understand that, the reason why the Australian government wants to introduce a national ID card becomes very, very clear: it wants to outsource responsibility. You see, the next time they accidentally deport an Australian citizen, it will be their own fault because they weren't carrying their ID card.
Please explain how an electric car can take energy from chemical to kinetic to electric to chemical to electric to kinetic and possibly be more efficient or cleaner for the environment than a gas car.
Electric cars don't burn energy while sitting at traffic lights.
I read your explanation, and I fail to see how it isn't a serious potential security hole.
Here's the scenario:
Client crafts some data, initiates IPC using "I promise not to write here" semantics.
Server accepts connection, does sanity checking, finds the data is okay.
Client modifies the data, violating its promise.
Server now has data which it thinks has been sanity checked, but is in fact invalid. Server crashes, gets compromised etc.
I'm probably misunderstanding here, but this is precisely the kind of problem that copying and/or COW is designed to avoid. There is a third approach, of course: if the client tries to write, block it until the memory area is released. (This is how "vfork" works, for example.)
If short term fixes were implemented more often in the kernel, I suspect it'd be much worse off in stability, performance and scalability than it is now. Since linux kernel programmers are forced to do things "The Hard Way" in the kernel, it all but guarantees that they have an intimate knowledge of the systems and workings.
And on the other hand, if the policy of doing it the right way was applied consistently, Linux would be a microkernel OS. But that's an old flamewar (the first flamewar about Linux, indeed!) and I don't propose to reopen it now.
I have two kids, and I play the cello. Believe me, I know all about the amount of stuff you have to haul.
We get along just fine with a decent-sized sedan (for those taking notes, it's an Australian '89 model Ford Falcon EA, bought some years ago). We used to have a station wagon, and as the kids get older I'll definitely consider going back to one.
Oh, for those rare occasions when we need to move something big (e.g. getting rid of the kids' old cot), we have a trailer, though they're also quite cheap to hire.
Slashdot Mirror
I think you meant the Vice President.
(Yes, I'm still milking that incident.)
In Djirbal, there are also four. According to Everything2, they are, roughly:
The point of this is that "gender" doesn't make so much sense as a grammatical term, since it only applies to certain Indo-European languages, and even then not consistently. (I've never understood the rationale for "Das Mädchen" in German. Probably because there is no rationale.) The more inclusive term "noun class" makes more sense.
Since you asked, let's answer some of these questions:
A health care worker has a choice as to whether they work in the public system or the private system. If they choose to work in the public system, then the answer to your question is "yes".
You answered your question here. "It may be necessary" to force people to pay money. Looks like you're just arguing about where the boundary lies to me.
Ah, now this is a completely different question. The question of who actually does it is different in different countries. In Australia, for example, there aren't any government-employed GPs to a first approximation. You go to your doctor, then claim some or all of the costs back either at the surgery or at the insurance office. Much like would happen under a private system.
Private enterprise is more efficient than the government for the same reason that dictatorship is more efficient than democracy. Democratic governments, at least in theory, have openness and accountability constraints that don't apply to corporations. And the few constraints that do apply to corporations at the moment would definitely not apply under a pure libertarian system.
I could change a few words there and come up with a pretty plausible-sounding argument as to why open source software will inevitably be crap compared to proprietary offerings.
Health care professionals are still licensed. The threat of being sued for malpractice or losing ones licence is still there. But more to the point, most health care professionals aren't in that field for the money, but because they care about what they do. Much like any other field.
That's true, which is why it's a fallacy to look at just the Canadian system and say "these problems will be true of all nationalised health systems". No system is perfect, but the problems associated with each are a function of history and demographics as much as economics. Some countries have more sparsely distributed populations than others, for example.
Clearly, you can afford health care and/or are reasonably healthy.
Amusingly, in just about every other industrialised country, one common catch cry every time anyone wants to modify the system is "this would create a US-style system". Someone always makes that argument, kind of like Godwin's Law.
Part of the reason for this is that most of the stories we hear are about people who fall through the cracks, such as those who end up homeless and still in huge debt to pay for their cancer treatment. I have no doubt that there are many success stories, too.
No argument with that!
One of Tanenbaum's central points is that Linux is not used everywhere. In particular, it's not used anywhere that hard-real-timeness, seriously paranoid robustness (e.g. in those applications where a hardware failure should not result in a reboot) etc are important.
The word "niche" is, much like "legacy", often used in places where a more overt dismissal would rightly be seen as unfair. The fact that Linux can do everything that you want it to do doesn't mean that you are the whole world, or that any site that doesn't look like yours is "niche", as opposed to "everywhere".
Even now, you occasionally get a pundit who points to legal risks in open source. The downgrading of the SCO case to what is basically a contract dispute with IBM doesn't change that, because pundits can be pretty stupid sometimes. While it's true that if Groklaw disappeared overnight, SCO would still lose, some of the paid mouthpieces wouldn't stop.
I wholeheartedly recant and apologise for my remarks, Mr Vice President.
Yup. Because Costa Ricans are nicer and more polite than Amercians, they can actually handle the responsibility of carrying guns.
Apparently they're using the term to refer to a gynoid.
I know a bit about the architecture of QNX, so let me just correct some things here.
QNX does not do zero-copy page table magic for IPC. The kernel directly copies the memory between address spaces. If you compare this with Linux, where it copies memory from user to kernel space, you'll see that the overhead is pretty much identical.
Having said that, there are areas where it's desirable for different "parts" of an OS to touch the same memory, but it's rare for those "parts" to be widely different. (I can't see, for example, why the POSIX message queue code will need to touch the same memory as a hard disk driver without passing through a user-space application first.) In such cases, QNX handles it by putting those parts in the same user-space server. In this setup, device drivers are shared objects which are loaded by user-space servers instead of the kernel.
Now to be fair, QNX isn't focussed on security first and foremost, it's focussed on hard real-timeness. The reason why it uses a small microkernel is so that the amount of code that could possibly stuff up any real-time guarantees is minimised. (There are other advantages, see below.) But still, the point here is that not all microkernels are made equal, and it is possible to satisfy the same "copy as little as possible" requirements that a modern macrokernel tries to do.
There is one advantage to modern microkernels (L4/QNX, not Mach) that hasn't been covered here yet, and that's that the kernels tend to be much simpler. You can leverage that to get more performance.
In a macrokernel OS, a task logically has two call stacks: One for the "user" code and one for the "kernel" code. If you are inside a system call and your task needs to be suspended, the kernel simply switches "kernel" stacks. (Yes, this is a simplification. Bear with me.)
Now consider a microkernel OS, where there is a limited number of simple system calls. If a task needs to be suspended during a system call, it can simply store the data that it needs to complete the system call in the thread state, and then return. When you wake up a thread, you first check in the thread state to see if a system call needs to be completed. If so, you do that before returning to the thread.
Yes, this makes the thread state structure slightly bigger, but in return, you don't need to have a separate kernel stack per thread. One per CPU is enough.
There are other tricks, of course, but this example illustrates the general idea: Microkernels can make system calls much cheaper, so you can afford to spend more time on things that in a macrokernel design would be classified as overhead. At the very least, it makes the analysis more complicated than merely saying "more copying == bad".
Things could be improved by not using IA32 chips.
On the IA32, messing with address spaces is expensive. (This is part of Linus' complaint about COW.) Switching address spaces, for example, causes a complete TLB flush. Sure, the PTEs are likely to be in cache, but still, for a small IPC interaction (client -> server -> client), it's a noticable hit. More modern architectures make it much cheaper to mess with address spaces.
Having said that, L4 had an interesting approach which helped quite a bit. To understand how it works, you need to know a bit about the Intel architecture. Basically, there's a flat 32-bit virtual address space. On top of that, you have segment selectors, which address some region of that flat space.
Now consider an artificial but not unrealistic macrokernel operating system for a 32-bit architecture. You have 4Gb of address space. Let's divide this up into 3Gb of "user space" and 1Gb of "kernel space". Entering the kernel is fairly cheap because you don't need to swap address spaces.
Now consider and artifical but not unrealistic microkernel operating system. The kernel footprint is much smaller. Exactly how much smaller depends on things like how much dynamic memory it needs, but let's say it only takes 0.5Gb. You could keep the same memory map, and reserve the other 0.5Gb for servers which have a small memory footprint, such as device drivers. All "large" address spaces have the same "small" address spaces as part of their map. Then you can creatively use the IA32 segment registers to multiplex on top of the flat address space. Context switching from client to server to client will not actually change address spaces if the server is "small", making it almost as cheap as a system call in a monolithic kernel.
Amusingly, 64 bit architectures make this trick even more elegant, because you can devote even more of the address space to "small" servers, which don't even need to be that small.
Depends what you mean by "regular". Millions of dollars can be saved by ships moving cargo around so that what is needed in the next port is easy to get to by the time you arrive, while maintaining adequate weight balance. (This, incidentally, is a very interesting algorithmic problem. I believe it's NP-hard to do it with the minimum number of container moves.)
I hear what you're saying, but I have one proviso. There are a number of very decent modern cross-platform editors (Vim and Emacs being but two). Whatever editor you decide on, you spend most of your programming career in it, so you need to learn to use it well. This will pay off much, much more than being passingly familiar with a dozen editors.
(Disclaimer: Sure, passing familiarity has its uses. At the very least, learning how to get to and navigate the documentation for any editor you're likely to come into contact with will help you avoid getting lost.)
The first tribunal was held in November 2004, a full three years after the first detainees were captured. (To be fair, the tribunals were delayed by about four months due to their legal statis being challenged in the US courts.)
The Geneva Convention doesn't state how long you have to wait to get your tribunal, though the US has laws against indefinite detention without trial. Nevertheless, it does state that you should be afforded all of the rights of a POW while you wait. Whether or not the detainees were afforded those rights before November 2004 is a reasonable question to ask.
That's not what I said. What I said was that the server should be able to assume that its input has not been modified after sanity checking. vmsplice() appeared to break that assumption, but in retrospect, it was probably that I didn't understand what the previous poster was trying to get at.
I know we all know this, but Linus has much the same problem, which is why he calls Neo-BSD developers rude names when they come to a different conclusion than him on some topic.
But, of course, that's all part of the charm. Hubris is one of the Larry Wall programmer virtues. There's nothing wrong with it so long as everyone understands that it's not personal. Neither Linus nor Theo would ever use a rude name against an individual developer or organisation unless they truly were not smart.
For the benefit of the non-Australians in the audience: In the last few years, our government has accidentally deported and detained (in immigration detention centres) several Australian citizens. I say "accidentally", but it's not as if "oops, sorry, we thought you were an illegal immigrant" is an adequate apology.
Once you understand that, the reason why the Australian government wants to introduce a national ID card becomes very, very clear: it wants to outsource responsibility. You see, the next time they accidentally deport an Australian citizen, it will be their own fault because they weren't carrying their ID card.
What about Wodewick, then?
Electric cars don't burn energy while sitting at traffic lights.
Why, yes. If what you want doesn't exist, write it your-fscking-self. If other people want it too, they might even help you.
I read your explanation, and I fail to see how it isn't a serious potential security hole.
Here's the scenario:
I'm probably misunderstanding here, but this is precisely the kind of problem that copying and/or COW is designed to avoid. There is a third approach, of course: if the client tries to write, block it until the memory area is released. (This is how "vfork" works, for example.)
And on the other hand, if the policy of doing it the right way was applied consistently, Linux would be a microkernel OS. But that's an old flamewar (the first flamewar about Linux, indeed!) and I don't propose to reopen it now.
...getting an interview with Brian Eno about how the Windows 95 sound was made?
Good point. Let me revise the OP:
Simple, Open Source, Robust, 3D Game Engine. Pick at most three.
I have two kids, and I play the cello. Believe me, I know all about the amount of stuff you have to haul.
We get along just fine with a decent-sized sedan (for those taking notes, it's an Australian '89 model Ford Falcon EA, bought some years ago). We used to have a station wagon, and as the kids get older I'll definitely consider going back to one.
Oh, for those rare occasions when we need to move something big (e.g. getting rid of the kids' old cot), we have a trailer, though they're also quite cheap to hire.
I play the cello, you insensitive clod. (Still, even I only need a decent-sized sedan or station wagon at most.)