Posted by
Hemos
on from the hurds-rolling-across-the-plans dept.
mirko writes "After some time with almost no news about it, Doctor Dobb's journal finally choosed to break the silence and to deliver quite a comprehensive article (also available here) about the forthcoming Debian Hurd[?] operating system."
Re:Development time is the key
by
f5426
·
· Score: 5
> The problem with the HURD is that it is still obsessed with the microkernel architecture
It is the only advantage of the HURD versus linux. We already have plenty of monolitic kernel to choose from.
> This may have seemed like a good bet ten years ago, but as Linux has shown, Microkernels are no big deal
This is plain wrong. There are many microkernels out there. They offer no specific advantage to monolithic kernels, but the HURD is a very different beast: A multi-server micro-kernel.
> They are inefficient
Bullshit. You are comparing highly tuned monolithic kernels to development micro kernels. This is apple and oranges, or mindcraft-like attitude.
Sure, micro-kernels are inefficient to perform the tasks that monolithic kernels have been designed to perform. Big deal. But there are tasks that are impossible to perform with a monolithic kernel. When you'll base you benchmark on them, you'll say that monolitic kernels are inefficient.
A couple of examples:
Two years ago I had my first CD-RW. Someone showed me Direct-CD under windows, and I said: "Woov. Cool. How does it works. Can I do that under linux".
Digged around. Found the UDF filesystem project and specs. Found the packet writing specs. Found that there were no packet-writing UDF driver under linux. Found the reason. "Currently you'll only be able to read CDR/CDRWs due to a kernel limitation". So what ? Well, I tried to find what the limitation is, to find if it was possible to work around, and do a packet-writed file system. Unfortunately, due to optimisation in the linux kernel it is not possible. But it may be possible later. Just wait. As you may know if you follow the linux kernel traffics, Linus specifically make it hard to become a kernel hacker, so the ones that hack the kernel are only the most motivated ones. Conclusion: No way to mount and modify a UDF packet-written filesystem. Period. The complexity of the kernel architecture and source rendered linux as closed as a proprietary kernel.
A UDF driver would be possinle under the HURD without having to touch more things than neccessary (It would be called a translator. This is like a user-space file system). It will be less efficient sure. But noone gives a fuck to high efficiency when writing to such a slooow device.
Example 2: Having drivers as server outside the kernel in a network transparent architecture (like mach is), should give you ideas of what will be possible. (Remote physical devices. Who mind a little efficiency loss when you access an USB bus from a different network point)
> and the chances of a code fork with Hurd are even greater than for Linux, due to the easier understandibility of the source code.
I'm sorry, RMS has little to do with this. "Tell RMS to scrap it". Yeah, why don't we tell one of the current desktop projects to do the same (obvious sarcasm). The fact is, a number of people are working on the HURD, and its because they want to, not because RMS told them to. The HURD has a number of advantages over Linux. Let's look at a few
1) There are "servers" instead of "drivers". Why is this important? Servers have their own address space. So, what happens if my network driver decides to go ballistic? Just restart it. If that happens in Linux it's bye-bye system.
2) Any user can write kernel code without creating a security risk. This includes user filesystems and the like.
3) Much more flexible authentication system
4) The ability to emulate multiple environments (the current HURD has several servers that implement UNIX services (process list, scheduling, etc), but all of those are pluggable and/or removable. So, you can have as much or as little UNIX as you want, and you can have it on a per-process basis.
5) The HURD is much more extensively multithreaded, and _should_ scale better to multiple processors (note the _should_ - I'm kind of skeptical here. I think it'll take them a good amount of time to remove the bottlenecks).
6) Stable Kernel API. This is something that Linus has said he will _not_ do.
7) I _believe_ (please correct me if I'm wrong) that the HURD is being developed using CVS. Now, this isn't really a technical issue, but a management issue. Linus still maintains the kernel using his INBOX. That has worked well, but as the kernel grows in size, it works less and less well. HURD's development process allows for more distributed maintenance, rather than a single point. Using CVS also allows developers to get patches into the tree for multiple kernel versions. For example, if Linus had a CVS server, he'd open up a 2.5 branch now, so all new stuff can be put into 2.5, and bug fixes into 2.4. This sounds petty, but project management is a real issue, and I think the Linux kernel is reaching its limits in this area.
So, there you have it. Don't call something you don't understand a bunch of bunk. It really sounds lame.
Sometimes you don't have root on your box.
by
yerricde
·
· Score: 4
Do regular users have a hard time adding services to Linux? I'm root on my own boxes, and I can load and unload kernel modules all day.
Ever tried to run a server over your dial-up connection? It's almost impossible to (legally) get root on a machine with a fast connection to the Internet. For example, Internet hosting companies tend to run several customers on one box; fat chance they'll give away the root password so you can screw it up for other customers. They may give you shell (even this is rare), but they don't give you root. Short of colocating your own dedicated box (very expen$ive), unprivileged userspace services are the only way to run servers on your site.
I always thought of debian/hurd as a tenacious possum or some other clever and mischieviious backwoods rabies-carrying animal. Infectious as rabies now that is advertising!
It should be more vicious than a penguin and ugly I think these are important qualities to keep it from becoming cute like linux.
A whiskey drinking pot-bellied racoon perhaps named ralph or something ?
Slashdot Editors: methinks you may benefit from creating and using a centralized Slashdot link repository, which would contain the URL of every link posted to a Slashdot story. You could then run a simple SQL query against this repository to check each link in submitted stories for potential repeats. Not necessarily a 100% solution, but it would help reduce the number of repeat stories choosed...
Re:Development time is the key
by
Leimy
·
· Score: 5
Microkernels are a big deal. Try learning how they work before you criticize them.
A monolithic kernel has some drawbacks in that there is a lot more sensitive code that can bring the whole system to a screaching halt. It also has very low latency to its advantage.
A microkernel has much less critical code to it making it easier to maintain but in most cases incurs much greater latency in context switches during such activities as IPC between servers and user processes and the kernel proper.
L4 is a microkernel with low latency. If developments like this continue it could spell the end for monolithic kernels.
Sorry.... Its just the truth biting ya in the ass again!:)
When linux finally does swell to the point where it becomes unmaintainable you'll wish you had a microkernel to work on. There is a growing number of people in support of porting Hurd to L4. The main Hurd developers don't care what microkernel it runs on... Just that it runs.
Hope this clarifies the some of the myths and can cut through some of the bigotry that is unfortunately present in the linux community.
Slashdot Mirror
> The problem with the HURD is that it is still obsessed with the microkernel architecture
It is the only advantage of the HURD versus linux. We already have plenty of monolitic kernel to choose from.
> This may have seemed like a good bet ten years ago, but as Linux has shown, Microkernels are no big deal
This is plain wrong. There are many microkernels out there. They offer no specific advantage to monolithic kernels, but the HURD is a very different beast: A multi-server micro-kernel.
> They are inefficient
Bullshit. You are comparing highly tuned monolithic kernels to development micro kernels. This is apple and oranges, or mindcraft-like attitude.
Sure, micro-kernels are inefficient to perform the tasks that monolithic kernels have been designed to perform. Big deal. But there are tasks that are impossible to perform with a monolithic kernel. When you'll base you benchmark on them, you'll say that monolitic kernels are inefficient.
A couple of examples:
Two years ago I had my first CD-RW. Someone showed me Direct-CD under windows, and I said: "Woov. Cool. How does it works. Can I do that under linux".
Digged around. Found the UDF filesystem project and specs. Found the packet writing specs. Found that there were no packet-writing UDF driver under linux. Found the reason. "Currently you'll only be able to read CDR/CDRWs due to a kernel limitation". So what ? Well, I tried to find what the limitation is, to find if it was possible to work around, and do a packet-writed file system. Unfortunately, due to optimisation in the linux kernel it is not possible. But it may be possible later. Just wait. As you may know if you follow the linux kernel traffics, Linus specifically make it hard to become a kernel hacker, so the ones that hack the kernel are only the most motivated ones. Conclusion: No way to mount and modify a UDF packet-written filesystem. Period. The complexity of the kernel architecture and source rendered linux as closed as a proprietary kernel.
A UDF driver would be possinle under the HURD without having to touch more things than neccessary (It would be called a translator. This is like a user-space file system). It will be less efficient sure. But noone gives a fuck to high efficiency when writing to such a slooow device.
Example 2: Having drivers as server outside the kernel in a network transparent architecture (like mach is), should give you ideas of what will be possible. (Remote physical devices. Who mind a little efficiency loss when you access an USB bus from a different network point)
> and the chances of a code fork with Hurd are even greater than for Linux, due to the easier understandibility of the source code.
Oh, you were trolling. Guess what, I felt for it.
Cheers,
--fred
1 reply beneath your current threshold.
I'm sorry, RMS has little to do with this. "Tell RMS to scrap it". Yeah, why don't we tell one of the current desktop projects to do the same (obvious sarcasm). The fact is, a number of people are working on the HURD, and its because they want to, not because RMS told them to. The HURD has a number of advantages over Linux. Let's look at a few
1) There are "servers" instead of "drivers". Why is this important? Servers have their own address space. So, what happens if my network driver decides to go ballistic? Just restart it. If that happens in Linux it's bye-bye system.
2) Any user can write kernel code without creating a security risk. This includes user filesystems and the like.
3) Much more flexible authentication system
4) The ability to emulate multiple environments (the current HURD has several servers that implement UNIX services (process list, scheduling, etc), but all of those are pluggable and/or removable. So, you can have as much or as little UNIX as you want, and you can have it on a per-process basis.
5) The HURD is much more extensively multithreaded, and _should_ scale better to multiple processors (note the _should_ - I'm kind of skeptical here. I think it'll take them a good amount of time to remove the bottlenecks).
6) Stable Kernel API. This is something that Linus has said he will _not_ do.
7) I _believe_ (please correct me if I'm wrong) that the HURD is being developed using CVS. Now, this isn't really a technical issue, but a management issue. Linus still maintains the kernel using his INBOX. That has worked well, but as the kernel grows in size, it works less and less well. HURD's development process allows for more distributed maintenance, rather than a single point. Using CVS also allows developers to get patches into the tree for multiple kernel versions. For example, if Linus had a CVS server, he'd open up a 2.5 branch now, so all new stuff can be put into 2.5, and bug fixes into 2.4. This sounds petty, but project management is a real issue, and I think the Linux kernel is reaching its limits in this area.
So, there you have it. Don't call something you don't understand a bunch of bunk. It really sounds lame.
Engineering and the Ultimate
Do regular users have a hard time adding services to Linux? I'm root on my own boxes, and I can load and unload kernel modules all day.
Ever tried to run a server over your dial-up connection? It's almost impossible to (legally) get root on a machine with a fast connection to the Internet. For example, Internet hosting companies tend to run several customers on one box; fat chance they'll give away the root password so you can screw it up for other customers. They may give you shell (even this is rare), but they don't give you root. Short of colocating your own dedicated box (very expen$ive), unprivileged userspace services are the only way to run servers on your site.
Will I retire or break 10K?
It should be more vicious than a penguin and ugly I think these are important qualities to keep it from becoming cute like linux.
A whiskey drinking pot-bellied racoon perhaps named ralph or something ?
An Education is the Font of All Liberty
Me fail English? That's unpossible!
[ home ]
$ man reality
Obliteracy: Words with explosions
Microkernels are a big deal. Try learning how they work before you criticize them.
:)
A monolithic kernel has some drawbacks in that there is a lot more sensitive code that can bring the whole system to a screaching halt. It also has very low latency to its advantage.
A microkernel has much less critical code to it making it easier to maintain but in most cases incurs much greater latency in context switches during such activities as IPC between servers and user processes and the kernel proper.
L4 is a microkernel with low latency. If developments like this continue it could spell the end for monolithic kernels.
Sorry.... Its just the truth biting ya in the ass again!
When linux finally does swell to the point where it becomes unmaintainable you'll wish you had a microkernel to work on. There is a growing number of people in support of porting Hurd to L4. The main Hurd developers don't care what microkernel it runs on... Just that it runs.
Hope this clarifies the some of the myths and can cut through some of the bigotry that is unfortunately present in the linux community.
dave