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.
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.
Uhmmm, no. Under Linux, if the device driver dereferences NULL the kernel reports the problem and moves on. It has been this way since 1992.
Under either system if the hardware writes a random chunck of physical memory, you are hosed. Putting the device driver code in its own address space doesn't make any difference.
) Any user can write kernel code without creating a security risk. This includes user filesystems and the like.
If there is no security issue, why is that code in the kernel? Oh, because it's part of the file system security model? Hmmmm.
I offered to contribute to the Hurd in 1988, soon after I left MIT. My offer was rejected, with the claim that the design work was already done and that only people physically near MIT would be able to effectively work on the nearly finished code. That makes sense -- it would be impossible to develop a working OS with developers scattered around the world communicating only with email and FTP.
Six years later I remember RMS urging us to stop working on Linux, since it was distracting people from the Hurd, the only OS that the FSF would endorse. If anyone would have written "GNU/Linux" the FSF would probably have sued for trademark misuse! Hmmm, and why isn't it GNU/Hurd?
Anyway, by my count the Hurd is well over a dozen years old. It started from cribbed software, and has used software from the many working OSes that have surpassed it, yet it still hasn't produced a usable system. The same old arguments about how monolithic kernels are too painful to develop for are still being repeated. Give it up, the evidence is clear: the Hurd is a dead-end path.
Re:Hurd intel only for now
by
Hacksaw
·
· Score: 3
HURD is based on Mach, which is on a whole bunch of platforms, such as... err... IA32 and, ummm, PA-RISC.
Well, in any case, Mach is made to be highly portable. If anyone cared to do it.
On the other hand, no one but a few people at the FSF seem to have worked on it since 1995.
Could someone tell me again why the HURD is a good idea?
Oh right, it's a system for managing complexity, making it easy for regular users to add services.
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.
Do regular users spend a lot of time wishing they could services to their box?
Let's face it folks, I think the reason the HURD is there at all is because Thomas Bushnell was/is having fun, along with a few other people.
I am sort of waiting for a few people to take issue with some of the claims made in that article about Linux, such as the claim that it's not very maintainable. I'm sure Linus (who's primary pet peeve is code maintainability) would have something to say about that, if he didn't have better things to do.
--
All the technology in the world won't hide your lack of vision, talent, or understanding.
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 ?
The most disappointing aspect of the Hurd project for me is that it only runs on wintel hardware. The Hurd will only be "linux compatible" when it can run on all the platforms that linux does (sparc, powerpc, arm, alpha, etc). I posted a message on the Hurd mailing list a while back asking if there was any work afoot to port Hurd to powerpc. No one bothered to answer.
-- "Mit der Dummheit kaempfen Goetter selbst vergebens."
- Schiller
The article spends a lot of effort talking about maintainability. However, the Linux kernel source is broken into drivers, so you only need to modify the driver thatis important. I don't see the Hurd as being any different. You just call them "servers" instead of "drivers", and when you're done modifying, the servers are built separately. But that's not the issue.
So if that's all the Hurd has, it's a bunch of bunk. The only truly appealing feature of the Hurd is the ability to plug in new kernels without rebooting. But for that one feature, I'm going to wait decades? Please.
I'd like to ask RMS to either turn out the Hurd very soon, or scrap it. I'm tired of hearing about all it's promise and seeing it's barely able to walk on its own. I think this has become some ego trip for RMS, and that's not what we need. Developer effort could be better spent on Linux, or whatever the next generation kernel is.
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.
Uhmmm, no. Under Linux, if the device driver dereferences NULL the kernel reports the problem and moves on. It has been this way since 1992.
Under either system if the hardware writes a random chunck of physical memory, you are hosed. Putting the device driver code in its own address space doesn't make any difference.
) Any user can write kernel code without creating a security risk. This includes user filesystems and the like.
If there is no security issue, why is that code in the kernel? Oh, because it's part of the file system security model? Hmmmm.
I offered to contribute to the Hurd in 1988, soon after I left MIT. My offer was rejected, with the claim that the design work was already done and that only people physically near MIT would be able to effectively work on the nearly finished code. That makes sense -- it would be impossible to develop a working OS with developers scattered around the world communicating only with email and FTP.
Six years later I remember RMS urging us to stop working on Linux, since it was distracting people from the Hurd, the only OS that the FSF would endorse. If anyone would have written "GNU/Linux" the FSF would probably have sued for trademark misuse! Hmmm, and why isn't it GNU/Hurd?
Anyway, by my count the Hurd is well over a dozen years old. It started from cribbed software, and has used software from the many working OSes that have surpassed it, yet it still hasn't produced a usable system. The same old arguments about how monolithic kernels are too painful to develop for are still being repeated. Give it up, the evidence is clear: the Hurd is a dead-end path.
HURD is based on Mach, which is on a whole bunch of platforms, such as... err... IA32 and, ummm, PA-RISC.
Well, in any case, Mach is made to be highly portable. If anyone cared to do it.
On the other hand, no one but a few people at the FSF seem to have worked on it since 1995.
Could someone tell me again why the HURD is a good idea?
Oh right, it's a system for managing complexity, making it easy for regular users to add services.
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.
Do regular users spend a lot of time wishing they could services to their box?
Let's face it folks, I think the reason the HURD is there at all is because Thomas Bushnell was/is having fun, along with a few other people.
I am sort of waiting for a few people to take issue with some of the claims made in that article about Linux, such as the claim that it's not very maintainable. I'm sure Linus (who's primary pet peeve is code maintainability) would have something to say about that, if he didn't have better things to do.
All the technology in the world won't hide your lack of vision, talent, or understanding.
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
The most disappointing aspect of the Hurd project for me is that it only runs on wintel hardware. The Hurd will only be "linux compatible" when it can run on all the platforms that linux does (sparc, powerpc, arm, alpha, etc). I posted a message on the Hurd mailing list a while back asking if there was any work afoot to port Hurd to powerpc. No one bothered to answer.
"Mit der Dummheit kaempfen Goetter selbst vergebens." - Schiller
See my comments on Debianplanet:
m l
:-)
Deeehhh.... December issue?
Here's a link to this article from Slashdot, posted on 1 November:
http://slashdot.org/articles/00/11/01/1326225.sht
I thought I knew this article already
It's... It's...
"We can confirm that Debian does *not* ship the version with the trojan horse. Our version predates it." [CA-2002-28]
The article spends a lot of effort talking about maintainability. However, the Linux kernel source is broken into drivers, so you only need to modify the driver thatis important. I don't see the Hurd as being any different. You just call them "servers" instead of "drivers", and when you're done modifying, the servers are built separately. But that's not the issue.
So if that's all the Hurd has, it's a bunch of bunk. The only truly appealing feature of the Hurd is the ability to plug in new kernels without rebooting. But for that one feature, I'm going to wait decades? Please.
I'd like to ask RMS to either turn out the Hurd very soon, or scrap it. I'm tired of hearing about all it's promise and seeing it's barely able to walk on its own. I think this has become some ego trip for RMS, and that's not what we need. Developer effort could be better spent on Linux, or whatever the next generation kernel is.
I do not belong in the spam.redirect.de domain.
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