The craze of making everything 3D is over. Just leave well enough alone. If a 3D web becomes necessary at some point, then the technology will be developed. Until then, however, we're just taking shots in the dark at what people *might* want.
That being said, if a 3D web is going to come out of anywhere, it will probably stem from the MMOGs. These virtual worlds have become so popular that in some cases they manage to displace the idea of meeting in real life.
We haven't seen Java binaries in FreeBSD since 1.1.8! I'm just in awe of this. Now I'm going to have to evict Linux-JDK from my system just to make room for the natives!
Amen. Whitedust seems to think that public opinion == "The Truth" and refuses to do any actual investigation into the matter. I've lost any and all respect I had for their shameful attempts at journalism.
Mod parent up.
Re:Number one choice for SATA RAID?
on
FreeBSD 6.1 Released
·
· Score: 2, Informative
According to nobody. The summary said:
possibly making FreeBSD the number one choice for SATA RAID implementations
That's "possibly". As in, it hasn't been proven yet but the developers feel that it's ahead of the rest of the market. Therefore it may "possibly" be the number one choice.
No, they're not. Early microkernel projects like Mach were. But there's nothing slow about L4 or QNX.
Microkernels will probably take over eventually, but for now I still don't think computers have gotten fast enough. Current low-end PCs struggle and stutter just to run Windows XP, KDE, or Gnome.
Believe it or not, that has more to do with locking and paging than it does CPU. Your CPU is capable of well over 1 billion cycles per second. Does that tell you anything? It should. Your CPU can do whatever the windowing system needs as long as it's being utilized. The message passing architecture of microkernels are intended to make that a reality by removing much of the overhead inherent in today's locking systems. I can't attest yet if they're there yet (there really aren't any large scale implementations), but I can say that Macs don't seem to have near as much trouble with stutters as other systems do. Could it be the message passing architecture? Possibly.
Mainframes are generally redundant to the point that you can change out thefr CPUs, memory, drives, etc. without turning the power off or rebooting the machine.
Same with the big Unix servers. Unix was considered "ready" for Big Iron usage once machines started shipping with crossbars (for hotplugging CPU boards) and redundnat everything. If you open a Sun E10000, you'll find that it looks a lot like a mainframe on the inside.
The modern mainframe is, in general, vastly more reliable than even the best of the best of 'big servers.'
Right up until Unisys invented "Clearpath" technology. Blech. Leave it to Unisys to take great tech halfway to nowhere.
Only if you want to peform naive 4K paging. Since that's a REALLY bad idea in a garbage collected system, the VM should be made to do the work. By adding a few statistics to object usage, the VM can be tuned to page out memory at either the object level or heap level. (Some VMs have their heaps broken up into different generations and processes. This makes them acceptable candidates for paging.) When the VM decides that more RAM is required, it can swap out the objects in memory, then replace their reference with a page fault routine. The next time something calls that missing object, the software fault will be executed (without an interrupt!) to reload and run the missing object.
While this is an interesting system, it's also a SASOS (single address space OS). Which (in a real environment) has the major drawback that any process can DOS the whole system simply by (over) allocating memory.
I don't really see the issue. Memory is allocated to each process as requested. There's nothing stopping the OS from cutting off as process as it deems necessary. Java already has the OutOfMemoryError mechanism in place.
a) that's hardly a microkernel approach
My point was that it can work in conjunction with the microkernel approach. i.e. Separate your system services into different processes that are protected from accessing each other. The same address space is then useful for the VM-based OS to transfer messages between processes without incurring any overhead.
b) you'still run the bulk of the code in user land
You'd run ALL the code in userland. Which is the point.
c) it's most definetely not new
I didn't claim it was new; merely that it was my favorite concept. I've been harping on it for years, but the research community has been working on it much longer. The idea is actually fairly obvious and has occurred to quite a few people independent from myself AND the bulk of research.
That's kinda the point of my post; microkernels, though 'easier' to maintain, are far more difficult to design - and almost always unbearably slow.
No, I said that early Microkernels have that problem. L4 and QNX exhibit none of the performance issues seen in the earlier Mach work.
Meanwhile, VMs, and virtualization: the industry keeps touting these as ways to utilize more of your servers or some shit, and I don't buy it.
Your point is neither here nor there. This particular bit of research is about system security and stability, not about system utilization.
Driver protection: This is always a trade-off. If the drivers are in kernel space, they're faster, but it's harder to keep them from killing your kernel. If they're in userspace, it's far more stable, but you take the comms-performance hit. It's actually the same tradeoff you get in Mono vs Micro kernel.
It's actually the exact same thing. Most kernels today exhibit Microkernel tendencies for some types of drivers. FUSE, for example, is (IMHO) the greatest Linux invention ever.
The fact is, Microkernels will never become mass-marketed (apple aside).
QNX isn't mass marketed? How about Symbian? Apple aside? I must be missing something.
L4, for example, does the best job of isolated machine virtualization of any VM implementation I've seen - I just don't think they're going to get anywhere on the desktop.
Using something like L4 for the desktop has very little to do with the Microkernel design, and everything to do with legacy support. The cost of building a new desktop environment today is incredibly high. As a result, every OS makes a best effort to run some form of existing software base. In the case of Linux, FreeBSD, OpenSolaris, MINIX, etc. that would be the Unix software base. ReactOS goes for the Windows software base. OS X tries for a combination of Unix, NeXT, and Mac software. No one is trying to build a brand new software base. Too much risk.
Posts like this make me weep for the loss of Computer Science knowledge in the world today. This question is so incredibly munged, I'm not sure whether I should laugh or cry.
Ring 0 is the same thing as bounds checking? Not even close. Ring 0 is the lowest permission area of a system, usually the area reserving the right to change the TLB. The MMU enforces the memory boundaries.
The VM is supposed to check accesses? No it isn't. It's supposed to translate "safe" code without direct memory accesses into well-behaved native code.
Uh, no. Only interference engines have that problem. Unless you're driving a Pontiac (generally classified as "high performance" engines) or an older vehicle, you're unlikely to end up with an interference engine.
Kernels don't often crash for reasons related to lack of memory protection.
I do believe that Tanenbaum was addressing security in his article, not kmem protection. His point was that the segregation of the servers prevents a hole in these programs from opening an elevated privledge attack. Furthermore, he points out that the elevated permissions of the kernel are likely to be far more secure due to the miniscule size of the kernel itself.
You make an interesting point about the stability of the kernel, but that wasn't his point in the slightest.
I don't consider it a "hack to make a micro kernel faster", because the thing no longer is a micro kernel.
I agree. I was merely pointing out that it was interesting how Apple picked up the kernel despite it's well known (and publicized) problems. I am neither saying it was a good choice or a bad choice. Merely that it was an odd choice.
Mach was a research kernel that attempted to make Unix systems into microkernels. What it proved was that this was a poor path to take, and that microkernels need a very different style of architecture to operate well. A few years later, the L4 kernel started making headway into the type of microkernel architecture that *could* work. The result is that many of the Embedded OSes today are either microkernel in design or very similar to a microkernel architecture.
The AC didn't make any real point, he was just being a tool. What did he say that impressed you so much that you would want to be "whipped with a birch branch, tarred & feathered, debaged & raddished"?
Look a few posts up at the fellow who mentioned the L4 kernel. While the L4 was really too little, too late (all the OSes we use today were written by that time), it managed to prove that Microkernels *can* be speed demons. What they require, however, is a radically different architecture. If you simply attempt to shoehorn a microkernel into existing Unix systems - precisely what Mach did - you're going to run into trouble.
On the other hand, if you architect the system so that it is impossible to pass a bad message, you may find that performance can actually be *increased*. My own preference has always been an OS based on a VM like Java where it is literally impossible to write code that can cross memory barriers. The result would be that the hardware protection of an MMU would be unnecessary, as would the firewall between the kernel and usermode. Performance would increase substantially due to a lack of kernel mode (i.e. Ring 0) interrupts or jumps.
Methinks a better analogy is: Snap your timing chain on a high performance engine and watch the entire machine tear itself into a piece of junk. Snap a belt or two on a more pedestrian engine and watch it stop until the belt is replaced.
...decade old comments on an architecture that was unsuitable for serious production work at the time...
that MINIX 3 is only available for... x86.
MINIX has always focused heavily on the x86 platform, despite the built-in portability. Why? Because it's for teaching. x86s are cheap, and thus make ideal teaching platforms.
You know what I find darling? That Linux was heavily modified to port to dozens (hundreds?) of other architectures. Hmmm... maybe Tanenbaum was more on target than you give him credit for?
Spouting or not, at least he's doing something. Minix3 (the end point he gets to in the article) is a BSD licensed OS that implements the concepts he discussed. I think it's time to get out the ole' performance metrics and see if much has changed in 20 years.
It holds no more true in practice today than it did when he started.
WRONG.
Tanenbaum's research is correct, in that a Microkernel architecture is more secure, easier to maintain, and just all around better. The problem is that early Microkernel architectures killed the concept back when most of the OSes we use today were being developed.
What was the key problem with these kernels? Performance. Mach (one of the more popular research OSes) incurred a huge cost in message passing as every message was checked for validity as it was sent. This wouldn't have been *so* bad, but it ended up worse because a variety of flaws in the Mach implementation. There was some attempt to address this in Mach 3, but the project eventually tappered off. Oddly, NeXT (and later Apple) picked up the Mach kernel and used it in their products. Performance was fixed partly through a series of hacks, and partly through raw horsepower.
Beyond that, you might want to read the rest of TFA. Tanenbaum goes over several other concepts that are hot at the moment, include Virtual Machines, Virtualization, and driver protection.
I'd probably count Blogger as the thing that should be deleted, as well as poorly configured WordPress installations which allow anonymous commenting.
And what exactly is so "poorly configured" about allowing anonymous commenting? Some of thebest comments come from anonymous users. (Not that anyone in Wordpress is really validated.) Wordpress not only makes anon commenting easy, but it automatically catches many types of spam posts (especially link-spam) and requires that they be approved before going live.
Why not a hybrid where the engine is not connected to the tranmission?
Conversion losses. Everytime you switch between mechanical and electric power, you're losing some of your energy in the process. As a result, hybrids are designed to accept losses only in power requirement profiles where the gain outweighs the loss. e.g. Acceleration is often handled by the more efficient electric motors while the gasoline motor is reserved for crusing.
As it so happens, alternative engines such as Stirlings work much better in a full hybrid configuration like you describe.
Slashdot Mirror
The craze of making everything 3D is over. Just leave well enough alone. If a 3D web becomes necessary at some point, then the technology will be developed. Until then, however, we're just taking shots in the dark at what people *might* want.
That being said, if a 3D web is going to come out of anywhere, it will probably stem from the MMOGs. These virtual worlds have become so popular that in some cases they manage to displace the idea of meeting in real life.
*rubs eyes*
Binaries? Sweet binaries?
*rubs eyes some more*
It's Christmas in FreeBSD land! Wheee!
We haven't seen Java binaries in FreeBSD since 1.1.8! I'm just in awe of this. Now I'm going to have to evict Linux-JDK from my system just to make room for the natives!
Amen. Whitedust seems to think that public opinion == "The Truth" and refuses to do any actual investigation into the matter. I've lost any and all respect I had for their shameful attempts at journalism.
Mod parent up.
According to nobody. The summary said:
possibly making FreeBSD the number one choice for SATA RAID implementations
That's "possibly". As in, it hasn't been proven yet but the developers feel that it's ahead of the rest of the market. Therefore it may "possibly" be the number one choice.
Microkernels are inherently slower
No, they're not. Early microkernel projects like Mach were. But there's nothing slow about L4 or QNX.
Microkernels will probably take over eventually, but for now I still don't think computers have gotten fast enough. Current low-end PCs struggle and stutter just to run Windows XP, KDE, or Gnome.
Believe it or not, that has more to do with locking and paging than it does CPU. Your CPU is capable of well over 1 billion cycles per second. Does that tell you anything? It should. Your CPU can do whatever the windowing system needs as long as it's being utilized. The message passing architecture of microkernels are intended to make that a reality by removing much of the overhead inherent in today's locking systems. I can't attest yet if they're there yet (there really aren't any large scale implementations), but I can say that Macs don't seem to have near as much trouble with stutters as other systems do. Could it be the message passing architecture? Possibly.
Mainframes are generally redundant to the point that you can change out thefr CPUs, memory, drives, etc. without turning the power off or rebooting the machine.
Same with the big Unix servers. Unix was considered "ready" for Big Iron usage once machines started shipping with crossbars (for hotplugging CPU boards) and redundnat everything. If you open a Sun E10000, you'll find that it looks a lot like a mainframe on the inside.
The modern mainframe is, in general, vastly more reliable than even the best of the best of 'big servers.'
Right up until Unisys invented "Clearpath" technology. Blech. Leave it to Unisys to take great tech halfway to nowhere.
Nope, you'll still need the MMU for 2 reasons.
No you don't.
The obvious one is to provide paging.
Only if you want to peform naive 4K paging. Since that's a REALLY bad idea in a garbage collected system, the VM should be made to do the work. By adding a few statistics to object usage, the VM can be tuned to page out memory at either the object level or heap level. (Some VMs have their heaps broken up into different generations and processes. This makes them acceptable candidates for paging.) When the VM decides that more RAM is required, it can swap out the objects in memory, then replace their reference with a page fault routine. The next time something calls that missing object, the software fault will be executed (without an interrupt!) to reload and run the missing object.
While this is an interesting system, it's also a SASOS (single address space OS). Which (in a real environment) has the major drawback that any process can DOS the whole system simply by (over) allocating memory.
I don't really see the issue. Memory is allocated to each process as requested. There's nothing stopping the OS from cutting off as process as it deems necessary. Java already has the OutOfMemoryError mechanism in place.
a) that's hardly a microkernel approach
My point was that it can work in conjunction with the microkernel approach. i.e. Separate your system services into different processes that are protected from accessing each other. The same address space is then useful for the VM-based OS to transfer messages between processes without incurring any overhead.
b) you'still run the bulk of the code in user land
You'd run ALL the code in userland. Which is the point.
c) it's most definetely not new
I didn't claim it was new; merely that it was my favorite concept. I've been harping on it for years, but the research community has been working on it much longer. The idea is actually fairly obvious and has occurred to quite a few people independent from myself AND the bulk of research.
That's kinda the point of my post; microkernels, though 'easier' to maintain, are far more difficult to design - and almost always unbearably slow.
No, I said that early Microkernels have that problem. L4 and QNX exhibit none of the performance issues seen in the earlier Mach work.
Meanwhile, VMs, and virtualization: the industry keeps touting these as ways to utilize more of your servers or some shit, and I don't buy it.
Your point is neither here nor there. This particular bit of research is about system security and stability, not about system utilization.
Driver protection: This is always a trade-off. If the drivers are in kernel space, they're faster, but it's harder to keep them from killing your kernel. If they're in userspace, it's far more stable, but you take the comms-performance hit. It's actually the same tradeoff you get in Mono vs Micro kernel.
It's actually the exact same thing. Most kernels today exhibit Microkernel tendencies for some types of drivers. FUSE, for example, is (IMHO) the greatest Linux invention ever.
The fact is, Microkernels will never become mass-marketed (apple aside).
QNX isn't mass marketed? How about Symbian? Apple aside? I must be missing something.
L4, for example, does the best job of isolated machine virtualization of any VM implementation I've seen - I just don't think they're going to get anywhere on the desktop.
Using something like L4 for the desktop has very little to do with the Microkernel design, and everything to do with legacy support. The cost of building a new desktop environment today is incredibly high. As a result, every OS makes a best effort to run some form of existing software base. In the case of Linux, FreeBSD, OpenSolaris, MINIX, etc. that would be the Unix software base. ReactOS goes for the Windows software base. OS X tries for a combination of Unix, NeXT, and Mac software. No one is trying to build a brand new software base. Too much risk.
Posts like this make me weep for the loss of Computer Science knowledge in the world today. This question is so incredibly munged, I'm not sure whether I should laugh or cry.
Ring 0 is the same thing as bounds checking? Not even close. Ring 0 is the lowest permission area of a system, usually the area reserving the right to change the TLB. The MMU enforces the memory boundaries.
The VM is supposed to check accesses? No it isn't. It's supposed to translate "safe" code without direct memory accesses into well-behaved native code.
I'm just in shock.
What makes you think I'm unaware of Amoeba? Or for that matter, why do you consider Minix3 a "toy" OS?
Uh, no. Only interference engines have that problem. Unless you're driving a Pontiac (generally classified as "high performance" engines) or an older vehicle, you're unlikely to end up with an interference engine.
Who you callin' wee, laddie?!
That would be "BEEEEEEEE SEVENTEEEEEEEN BOOOOOoooooooommmmmmbeeeeeerrr!"
(Apologies to those who've never had an Intellivision.)
Kernels don't often crash for reasons related to lack of memory protection.
I do believe that Tanenbaum was addressing security in his article, not kmem protection. His point was that the segregation of the servers prevents a hole in these programs from opening an elevated privledge attack. Furthermore, he points out that the elevated permissions of the kernel are likely to be far more secure due to the miniscule size of the kernel itself.
You make an interesting point about the stability of the kernel, but that wasn't his point in the slightest.
I don't consider it a "hack to make a micro kernel faster", because the thing no longer is a micro kernel.
I agree. I was merely pointing out that it was interesting how Apple picked up the kernel despite it's well known (and publicized) problems. I am neither saying it was a good choice or a bad choice. Merely that it was an odd choice.
Mach was a research kernel that attempted to make Unix systems into microkernels. What it proved was that this was a poor path to take, and that microkernels need a very different style of architecture to operate well. A few years later, the L4 kernel started making headway into the type of microkernel architecture that *could* work. The result is that many of the Embedded OSes today are either microkernel in design or very similar to a microkernel architecture.
You don't think that's a hack? Interesting.
I'm not saying that Apple was wrong to do what they did, but it was still a hack of the Mach kernel.
Whatever you will but please mod the parent up.
If I may ask a question: Why?
The AC didn't make any real point, he was just being a tool. What did he say that impressed you so much that you would want to be "whipped with a birch branch, tarred & feathered, debaged & raddished"?
I'll say "What is QNX?" for $500, Alex.
Look a few posts up at the fellow who mentioned the L4 kernel. While the L4 was really too little, too late (all the OSes we use today were written by that time), it managed to prove that Microkernels *can* be speed demons. What they require, however, is a radically different architecture. If you simply attempt to shoehorn a microkernel into existing Unix systems - precisely what Mach did - you're going to run into trouble.
On the other hand, if you architect the system so that it is impossible to pass a bad message, you may find that performance can actually be *increased*. My own preference has always been an OS based on a VM like Java where it is literally impossible to write code that can cross memory barriers. The result would be that the hardware protection of an MMU would be unnecessary, as would the firewall between the kernel and usermode. Performance would increase substantially due to a lack of kernel mode (i.e. Ring 0) interrupts or jumps.
Methinks a better analogy is: Snap your timing chain on a high performance engine and watch the entire machine tear itself into a piece of junk. Snap a belt or two on a more pedestrian engine and watch it stop until the belt is replaced.
I think it's just darling that after...
...decade old comments on an architecture that was unsuitable for serious production work at the time...
that MINIX 3 is only available for... x86.
MINIX has always focused heavily on the x86 platform, despite the built-in portability. Why? Because it's for teaching. x86s are cheap, and thus make ideal teaching platforms.
You know what I find darling? That Linux was heavily modified to port to dozens (hundreds?) of other architectures. Hmmm... maybe Tanenbaum was more on target than you give him credit for?
Spouting or not, at least he's doing something. Minix3 (the end point he gets to in the article) is a BSD licensed OS that implements the concepts he discussed. I think it's time to get out the ole' performance metrics and see if much has changed in 20 years.
It holds no more true in practice today than it did when he started.
WRONG.
Tanenbaum's research is correct, in that a Microkernel architecture is more secure, easier to maintain, and just all around better. The problem is that early Microkernel architectures killed the concept back when most of the OSes we use today were being developed.
What was the key problem with these kernels? Performance. Mach (one of the more popular research OSes) incurred a huge cost in message passing as every message was checked for validity as it was sent. This wouldn't have been *so* bad, but it ended up worse because a variety of flaws in the Mach implementation. There was some attempt to address this in Mach 3, but the project eventually tappered off. Oddly, NeXT (and later Apple) picked up the Mach kernel and used it in their products. Performance was fixed partly through a series of hacks, and partly through raw horsepower.
Beyond that, you might want to read the rest of TFA. Tanenbaum goes over several other concepts that are hot at the moment, include Virtual Machines, Virtualization, and driver protection.
I'd probably count Blogger as the thing that should be deleted, as well as poorly configured WordPress installations which allow anonymous commenting.
And what exactly is so "poorly configured" about allowing anonymous commenting? Some of thebest comments come from anonymous users. (Not that anyone in Wordpress is really validated.) Wordpress not only makes anon commenting easy, but it automatically catches many types of spam posts (especially link-spam) and requires that they be approved before going live.
Why not a hybrid where the engine is not connected to the tranmission?
Conversion losses. Everytime you switch between mechanical and electric power, you're losing some of your energy in the process. As a result, hybrids are designed to accept losses only in power requirement profiles where the gain outweighs the loss. e.g. Acceleration is often handled by the more efficient electric motors while the gasoline motor is reserved for crusing.
As it so happens, alternative engines such as Stirlings work much better in a full hybrid configuration like you describe.
So what you're telling me is, you want a TZero. Or am I missing something?