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."
Hurd, education only? (or: From Linux to Minix)
by
marcovje
·
· Score: 2
What strikes me from the tone of articles about Hurd lately, is that the tone has changed from "the OS that is going to replace Linux" to "A clean implementation (at least cleaner than Linux/FreeBSD) to dissect in the classroom)
I.o.w. when it first was positioned as successor to Linux, it now seems to be the successor to Minix.
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.
Re:Most useful as an experiment...
by
DickBreath
·
· Score: 2
Possible reasons:
* Because Linux is available in very nice boxed distributions. i.e. Convenience, easy to re-install. Kickstart. Easy to re-image onto a bunch of lab PC's.
* Because Linux is here now, and easily available. (See previous point.)
* Inertia? People already know it?
I could probably dream up other reasons.
--
I'll see your senator, and I'll raise you two judges.
Re:Most useful as an experiment...
by
Ami+Ganguli
·
· Score: 2
Research on filesystems and UI's taking place under Linux (and others) and can be ported to other systems (like, for example Hurd).
Hurd is looking at different ways of implementing the kernel.
-- It is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail. - Abraham Maslow
I think if you want to get hung up on calling things "Debian GNU/Linux" then you will be correct; you're only likely to offend others when they expect correctness and you don't give it.
Maybe the GNU bit goes hand in hand with it being a port of Debian (versions of GNU s/ware packaged the Debian way) with a Hurd kernel. ~Tim
-- .|` Clouds cross the black moonlight,
-- ~Tim
-- .|` Clouds cross the black moonlight,
Rushing on down to the circle of the turn
Really strange moderation lately...
by
Ami+Ganguli
·
· Score: 2
Has anybody else noticed that the moderation lately has been more bizarre than usual. It seems like _everything_ is being marked "offtopic".
The post above, for example, might be a little off-base, but it's definately on-topic.
I've noticed other threads that were really offtopic, but instead of just the top message being modded down, every reply (some quite interesting) was modded down as well. What's the point in that?
Anyway, just my observation. I'm going to start meta-moderating a lot more and see if I can do my bit to fix this.
-- It is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail. - Abraham Maslow
Re:Really strange moderation lately...
by
Mike+Connell
·
· Score: 2
> I'm going to start meta-moderating a lot more and see if I can do my bit to fix this.
Be prepared to lose karma over it. Rationality is not in vogue on slashdot (sad to say).
I will say "I bet I lose karma over saying this". The question is, do I mean it, or am I just saying it because I'm a karma whore?;-)
I'm not arguing that source distribution is a bad idea. I think its great. I'm probably close to RMS on this one. However, the idea that you can build a source driver from one kernel version to another is just not entirely true. One of the reasons that ReiserFS hasn't made it into the kernel is because it doesn't follow the API as well as it should. However, the reason that it doesn't follow the API is because the kernel API has not been stable enough to follow closely. Semantics of certain kernel function calls change even within minor releases of the kernel. In these cases, in order to work 100%, all drivers using these functions have to be updated to use the new semantics. Now, even with such changes, many source compiles will compile, build, and even work for a time, but if they aren't following Linus's changing semantics exactly, there could be a number of race conditions that result.
In addition, having a stable API forces you to examine the API in detail beforehand. Thus, you are probably more likely to come up with a reasonable, sensible API.
From an engineering perspective, stable APIs are always the best, because, even if you have to work around certain things, you always know what they are. Now, just because you have a stable API, doesn't mean that you can't come up with a new one. A kernel could have two separate APIs (I don't know if the HURD allows this, but it is possible) - one for old drivers and one for new. "But what about bloat". Well, its just like LIBC - if you want compatibility, build the old library too, if you don't, leave it out. With LIBC, you have 2 stable APIs, but you can junk either of them if you want to. The same could be done with a kernel.
Re:Most useful as an experiment...
by
Wesley+Felter
·
· Score: 2
Hurd would be useful as a research system if any research was being done in it... but I don't see any. If Linux is useful as both a production kernel and a research platform, who needs the Hurd?
Now if you want to talk about interesting research, let's look at SawMill and EROS.
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.
I didn't see any mention of security in the article (other than the authentication "server"). Does anyone know how they handle Data vs Code in memory? Seeing as they are still in the development stage, couldn't they take a big step away from one of the intrinsic security issues in all the *NIXes? I just can't imagine starting the process of weeding out thousands of buffer overflows in a new OS. (Please note, I may be smoking crack here, but I thought that separating Data from Code in memory would help the buffer overflows.) Oh well, it sounds like it _Might_ be interesting.
--
Still, with a plan, you only get the best you can imagine. I'd always hoped for something better than that. -CP
Data and code are separate in just about every current environment. The problem is the 1) the stack, and 2) that executable pages are marked as writeable. You can get rid of most buffer overflows by compiling everything with a program I believe is called StackGuard, or something like that.
It seems that/. rarely if ever corrects a spelling mistake when that mistake is made by the submitter of the story. So its up to the submitters to learn to spell and use grammar correctly. In which case, we could be here a damn long time...
Re:Development time is the key
by
stevew
·
· Score: 2
A few points here from one who watched the Linus vs Andy T debate in real time.
It is well know what Linus thinks of Microkernels, while QNX (which was quite spiffy on an IBM PC-1!) proves that all microkernels are not created equal.
The Linux of today is not nearly as peppy compared to the Linux of yesteryear performance wise. At the same time, the first Linux kernels could only handle 64Mb processes. The original Linux was like a Datsun 240Z compared to your Grand-dad's DeSoto. Not alot of features - but it was FAST.
Compared to Minix at the time - it was lightyears ahead! Minix was REALLY designed to STAY on a 8088.
Finally - if Microkernels were God's gift to the world. Why did it take 10 years to get to a useable state, while Linux got there in less than two years?
-- Have you compiled your kernel today??
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.
You're missing the point. In HURD, the servers are in virtual memory, not physical memory. Therefore it _can_ write random chunks of memory.
Also, I think you're missing another point. In HURD, the kernel/user distinction is not very big. Each server is only given certain permissions, and it only has rights within that. Therefore, if you write and load kernel code, it still only operates within your permission set. I think the main difference between kernel/user code is the communication method.
Re:Most useful as an experiment...
by
DickBreath
·
· Score: 2
Wouldn't Hurd be useful as a research tool? (Not be all end all.)
Given that you can extend the OS by just building servers, doesn't this lend it to quickly being able to show proof of concept?
I'm assuming here that building servers for Hurd (even for things that are "in" the OS, such as network stacks, device drivers, new filesystems, etc.) is considerably easier than putting similar things into Linux. If not, then I suppose it makes no better a research platform than Linux.
--
I'll see your senator, and I'll raise you two judges.
Re:Most useful as an experiment...
by
Arandir
·
· Score: 2
We've got Linux and the BSDs, why do we need anything else?
Because there can be no GNU System without the hurd. The rational for calling a particular OS environment "GNU/Linux" is just ridiculous if there has never been a completed GNU System for it to be derived from. But even Debian Hurd won't be the GNU System, it will just be the Debian distribution of an OS never released by its makers.
No matter how you define "operating system", it still requires a kernel. No kernel, no operating system. And GNU is described by its makers as an operating system.
Moderators: don't mod this down. I am not bashing your holy GNU. I think GNU is great. But I'm also honest enough to admit that it isn't an operating system, yet. In the meantime it makes a great parts repository for those creating other free operating systems.
-- A Government Is a Body of People, Usually Notably Ungoverned
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 ?
And BeOS, BSD, Darwin and Solaris also have GNU software. What's your point? Are you demanding that Steve Jobs call his new product "GNU/OS X"?
Until GNU finally completes its own operating system by integrating a working hurd into the rest of their OS stuff, there is no GNU System. It does not exist.
-- A Government Is a Body of People, Usually Notably Ungoverned
Why is the link to the article is colored
by
Kickasso
·
· Score: 2
like I've already visited it? maybe because of this? --
People will no more call the GNU/Linux system only as Linux.
This does not follow out all. None of the Linux distributions out there are the GNU System. RMS says that it should be called "GNU/Linux" because it really is the GNU System with just the kernel swapped out. But there is *NO* GNU System! There is not now any stable OS with a stable hurd to swap out. And there certainly wasn't when the first Linux distributions arose out of the primordial software soup.
Rather, I think when Debian GNU/Hurd is finally released as stable (and it really ought to be named just "Debian GNU System"), then all of this crap about "LiGnuX" will disappear.
-- A Government Is a Body of People, Usually Notably Ungoverned
Re:"GNU" is embarassing name? How about HURD?
by
Arandir
·
· Score: 2
Yeah, I know tons of BSD people who understand GIMP perfectly well.
-- A Government Is a Body of People, Usually Notably Ungoverned
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
Don't get me wrong, I'm not downing the Hurd, it's a very interesting project with a lot of promise.
Just a small note though - your stable kernel API is not necessarily an advantage. Linus doesn't want that for good reasons.
A stable kernel API means a commitment to backward binary compatibility. Which, over time, means an accumulation of all kinds of cruft (look at the latest iteration of Windows9x for plenty of examples.) It can severely limit developer options. Sometimes changing the API is the right thing to do. And the only advantage one would get out of this is binary compatibility - with any Free (or even merely Open) program, a simple recompile against the updated kernel source works. The drawbacks in this case clearly outweigh the rather dubious benefits.
I'm not a Hurd hacker, just an interested party that follows the information released on it, but I don't remember seeing this claim that the HURD will maintain a stable kernel API anywhere. Lacking any official word to the contrary, I would tend to expect that their position is the same as Linus on this - I would certainly be shocked if the FSF's own kernel project were willing to go make any significant technical sacrifice simply to maintain binary compatibility with some yet-to-be written commercial program that isn't even Open Source.
-- =-=-=-=-=-=-=-=-=-=-=-=-=-=-
Friends don't let friends enable ecmascript.
If you don't have a stable API, a simple recompile does _not_ work. Even if it compiles, there is no guarantee without a stable API that it will work. Stable APIs have a number of advantages - the biggest of which is the further parralellization (I think I messed that word up) of development.
Also, remember that recompiling is something hackers, not users, do - even in free software.
It seems we mean different things by "stable kernel API." Normally when this comes up, the reference is not to changing the external (POSIX) API but the internal API - this has been an issue with proprietary device drivers for years. The specifications for how kernel modules interact has changed, and Linus has made it clear it can change again at any time. A recompile of the modules, linked against the new kernel source, normally works in this case.
Also, remember that recompiling is something hackers, not users, do - even in free software.
I won't grant that this is necessarily true - I am hardly a hacker, but I compile things fairly often. With configure and make this is hardly a challenging task, unless there is something wrong with the source distribution.
It's dangerous to make too much of that dichotomy - hackers are users too, albeit a particular type of users, just like DTP and Graphic Designers are types of users.
However, it is true that most people install binaries, but the availability of binaries is a direct function of compilation. With a closed source driver, only one organisation has the source and thus only they can do a recompile and make the updated binary available. This is often a major bottleneck. In the world of Free Software, everyone has or can get the source, and therefore many people can and do compile the same program and make packages available - often linked against different libraries, with different compilation options. This is as it should be, and maximises the availability and choice, and minimises the turn-around time when an update must be made, for all users - even the ones that don't compile, for whatever reason.
-- =-=-=-=-=-=-=-=-=-=-=-=-=-=-
Friends don't let friends enable ecmascript.
Most useful as an experiment...
by
Ami+Ganguli
·
· Score: 2
I can already see the "why bother" people starting to come out of the woodwork. We've got Linux and the BSDs, why do we need anything else?
I don't think we really do at the moment, but it's healthy to have some people doing something completely different and seeing where it will take them. It's called "research" and it's the precursor to the "innovation" that everybody thinks free software is incapable of.
So there's a good chance that The Hurd will never make it past the "what a neat idea" stage. But it's also possible that, just when Linux starts hitting the scalability wall (it'll be a few years yet), a system like Hurd will be waiting to take over.
-- It is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail. - Abraham Maslow
Re:Most useful as an experiment...
by
Wesley+Felter
·
· Score: 2
I'm assuming here that building servers for Hurd is considerably easier than putting similar things into Linux.
I haven't used the Hurd, so I don't know. But if it is considerably easier, why isn't anyone doing it? Why are most research projects using Linux and *BSD instead?
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.
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.
>>>>>>>>>>
How often is hardware the cause of crashes? Much more often it is flakey OS code. Take BeOS's (soon to be replaced) net_server for example. When I ran it as a NAT server, it used to crash on me twice a day. However, since the whole thing was in user-space, I had a shell script that would restart it. I think you're missing some of the benifets of microkernels. QNX and BeOS have used them to great effect, and in order to get a balanced view, I suggest you read some of the docs that come with each (www.be.com/developer, qdn.qnx.com)
-- A deep unwavering belief is a sure sign you're missing something...
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 agree. All these selfish people wasting time on the Hurd. What kind of world do we live in where irresponsible people can work on the project they chose? Clearly all this Hurd nonsense must be what has held back the 2.4 Linux release. For shame!
I'm sure Apple's engineers will be surprised to hear that Mach runs only on IA-32 and PA-RISC, especially since Mach is the core of Mac OS X. Ditto for the MkLinux people.
An unconfirmed report by a NASA staffer claims that the computers responsible for the successful extension of the International Space Station solar panels are, in fact, controlled the the Hurd kernel and GNU software in general.
Not only does this demonstrate the stability and reliability of GNU software in a 'mission critical' context, it also is the first instance of the Hurd, shot around the world.
(sorry. I had to)
The REAL jabber has the/. user id: 13196
--
The REAL jabber has the user id: 13196
What you do today will cost you a day of your life
how many kernel-level programmers are available?
by
tcyun
·
· Score: 2
Is there any chance that development/popularization of HURD will act as a brain drain from Linux development? Or, is the current popularity of Linux hampering the development of HURD?
I realize that the two are fundamentally different OSes. However, I am not sure how many people are trained and skilled enough to work on low level programming projects such as HURD. So my question is simple and can be reduced to: how many open source OSes can the planet support?
How is this an improvement over MkLinux?
by
XLawyer
·
· Score: 2
MkLinux uses the Mach microkernel as the core of a Linux-compatible operating system. It was originally developed in cooperation with Apple, so it runs mostly on Macintoshim. Still, I remember either hearing or hallucinating that an IA-32 version existed somewhere.
In any case, with MkLinux, you have an operating system that's based on Mach and, to applications, looks like Linux. What does Hurd have that MkLinux doesn't? For that matter, what does MkLinux have that Hurd doesn't?
I suppose phrasing it this way is an invitation to a flame war, but, well, I'm ignorant of the details. Thus, Hurd looks to me like a duplication of the MkLinux effort. If I'm wrong in that conclusion, I'd appreciate it if someone would exlain why.
Re:How is this an improvement over MkLinux?
by
Pseudonym
·
· Score: 2
Simple. MkLinux is a kernel fork and therefore responsible for the downfall of civilisation. The Hurd, by comparison, isn't.
-- sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
I was almost certain I'd already read that article, and couldn't imagine why... then it occurred to me; Slashdot thinks several month old articles are news!
X is a _great_ idea for businesses, even if it doesn't offer a lot of advantages for the home user. It certainly doesn't hurt them any. HURD actually is kind of revolutionary in OS design. The fact that it emulates UNIX is more of a compatibility deal than a design issue. The overall design of HURD is extremely modern. There are many reasons why it would be useful. And of course there are no guarantees about its usefulness (how many projects have usefulness guarantees attached?).
You mentioned security exploits. The reason that there are "more exploits for UNIX than Windows", is that people don't usually even look for console exploits on Windows, since they assume the console operator will be trusted. In UNIX, since it has the additional feature of allowing so much to be done through remote logins. If I wanted to make my OS a featureless as Windows, I would make it more secure as well.
Anyway, don't flame an OS just because it doesn't give _you_ any advantages. That's the beauty of the open source movement - there is such diversity. If something doesn't appeal to you, don't use it! But there are many people (including myself) anxiously awaiting HURD to emerge because it offers us a lot of useful features. Maybe HURD isn't for the desktop, maybe it is. So what! Not every OS is for the desktop. Some are for servers, some are for mainframes, some are for graphic designers, some are for home desktops. If you go to a "one size fits all" mentality, then the OS chosen will suck for everyone.
(in the voice of the Comic Book store owner, typing into his laptop) "Choosed", best grammatical error for the purpose of enhancing posts and ad revenue ever!
-- For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
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.
Re:how many kernel-level programmers are available
by
Espen+Skoglund
·
· Score: 2
I don't think the Hurd (or any other OS) for that matter will be a brain drain for the Linux kernel. Thing is that most (kernel) programmers stick to a system which they are familiar with. New programmers will find some project that they want to work on, and they will maybe come to master that project to great extent (and stick to it).
Also, being a kernel developer is not necessarily any harder than developing for a user-level project. This is a myth. In fact, it might in many cases be easier to be a kernel developer becasue you do not have to deal with different operating system APIs. In other words, they key issue is complexity. That is, there are relatively few Linux kernel developers because the complexity of the kernel is too high (and not well enough docuemented) to overcome for most people. So, if the kernel itself is less complex, more people would be able to make contributions. I think this was the main reason that I chose to ditch Linux in favour of BSD years ago -- I just got too fed up with the ugly undocumented hacks inside the Linux kernel.
(Note, I'm not saying that BSD is completely free of hacks, but I do find the code easier to understand. In addition, you tend to get manual pages for in-kernel features. The size of my man9 section currently counts 233.)
I always thought that DDJ was a more high-tech
publication, but this article appears to be
written for a lowest-common denominator
audience.
Linux kernel development is dominated by a hacker ethos, in which external documentation is held in contempt, and even code comments are viewed with suspicion. In such an environment, quick code modification is the top priority...
I know that the linux kernel is not documented as
well as it should be, but for starters, there is
a Documentation directory right there in the
source code! I know I've seen some HOWTO's about
writing device drivers. And looking at various
files, I see plenty of comments.
So, let's take a look at Hurd and see how it compares. Looking at a few files,
I see some comments, but not nearly as many as in
the Linux source code tree. And do you see any
documentation, other than TODO and CHANGES? I
think Linux wins the documentation battle hands-down.
Full multithreading has only been possible in Linux since the fairly recent widespread use of the glibc C library, while multiprocessing is an ongoing effort that is not yet complete.
Ummm... Ok.... I think this person was confusing multiprocessing with Multiple Processors. And this is a guy who writes
software for medical devices. Sheesh.
Oh well. I guess it's still nice that The Hurd is
getting some publicity.
-- I'm a leaf on the wind. Watch how I soar.
Re:Development time is the key
by
Hard_Code
·
· Score: 2
Yeah, my usual response to the "hey, we could make this 2% faster by just totally munging up the code!!" mentality, is that computing and software development these days is no longer about maximizing scarce resources, but in managing complexity. Resources are abundant, we're drowning in disk space, memory, data, etc. We should be writing software that solves *human* problems, not hardware problems. A stick of 128 MB RAM is a much better solution in many cases than 2 man-years of optimizing for hardware which will just be obsolete anyway. I'd rather have a solidly designed, well implemented system, which is easily maintainable and upgradable, than a system optimized to run like an amphetamine addict which will break in a year, once the hardware needs to be upgraded or a feature added.
Re:Development time is the key
by
stevew
·
· Score: 2
Were as I drove a 84 300ZX for 11 years - about the same distance between that and a 240Z as there is between a 0.12 kernel (my first) and a 2.4.x kernel;-)
-- Have you compiled your kernel today??
Re:Development time is the key
by
f5426
·
· Score: 2
You can't find anyone more convinced than me. I am on the same development since 1994, and I written most parts myself.
Managing complexity is the key. Complexity in design, complexity in implementation, complexity in debugging, complexity in testing, complexity in documentation, complexity in maintenance, complexity in evolution.
The scarsiest resource is the development time. No way to do a baby in one month by using 9 women. Hardware is cheap. Complexity use time. Complexity is time.
When I look back at that huge project, I can see that Donald Knuth (I think the sentence is from him) was right. "Premature Optimisation is the Root of al Evils". Writing 1000 lines of code one day is of no use if you have to dig it a couple of years later.
Slashdot Mirror
What strikes me from the tone of articles about Hurd lately, is that the tone has changed from "the OS that is going to replace Linux" to "A clean implementation (at least cleaner than Linux/FreeBSD) to dissect in the classroom)
I.o.w. when it first was positioned as successor to Linux, it now seems to be the successor to Minix.
> 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.
Possible reasons:
* Because Linux is available in very nice boxed distributions. i.e. Convenience, easy to re-install. Kickstart. Easy to re-image onto a bunch of lab PC's.
* Because Linux is here now, and easily available. (See previous point.)
* Inertia? People already know it?
I could probably dream up other reasons.
I'll see your senator, and I'll raise you two judges.
Research on filesystems and UI's taking place under Linux (and others) and can be ported to other systems (like, for example Hurd).
Hurd is looking at different ways of implementing the kernel.
It is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail. - Abraham Maslow
I think if you want to get hung up on calling things "Debian GNU/Linux" then you will be correct; you're only likely to offend others when they expect correctness and you don't give it.
.|` Clouds cross the black moonlight,
Maybe the GNU bit goes hand in hand with it being a port of Debian (versions of GNU s/ware packaged the Debian way) with a Hurd kernel.
~Tim
--
~Tim
--
Rushing on down to the circle of the turn
Has anybody else noticed that the moderation lately has been more bizarre than usual. It seems like _everything_ is being marked "offtopic".
The post above, for example, might be a little off-base, but it's definately on-topic.
I've noticed other threads that were really offtopic, but instead of just the top message being modded down, every reply (some quite interesting) was modded down as well. What's the point in that?
Anyway, just my observation. I'm going to start meta-moderating a lot more and see if I can do my bit to fix this.
It is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail. - Abraham Maslow
I'm not arguing that source distribution is a bad idea. I think its great. I'm probably close to RMS on this one. However, the idea that you can build a source driver from one kernel version to another is just not entirely true. One of the reasons that ReiserFS hasn't made it into the kernel is because it doesn't follow the API as well as it should. However, the reason that it doesn't follow the API is because the kernel API has not been stable enough to follow closely. Semantics of certain kernel function calls change even within minor releases of the kernel. In these cases, in order to work 100%, all drivers using these functions have to be updated to use the new semantics. Now, even with such changes, many source compiles will compile, build, and even work for a time, but if they aren't following Linus's changing semantics exactly, there could be a number of race conditions that result.
In addition, having a stable API forces you to examine the API in detail beforehand. Thus, you are probably more likely to come up with a reasonable, sensible API.
From an engineering perspective, stable APIs are always the best, because, even if you have to work around certain things, you always know what they are. Now, just because you have a stable API, doesn't mean that you can't come up with a new one. A kernel could have two separate APIs (I don't know if the HURD allows this, but it is possible) - one for old drivers and one for new. "But what about bloat". Well, its just like LIBC - if you want compatibility, build the old library too, if you don't, leave it out. With LIBC, you have 2 stable APIs, but you can junk either of them if you want to. The same could be done with a kernel.
Engineering and the Ultimate
Hurd would be useful as a research system if any research was being done in it... but I don't see any. If Linux is useful as both a production kernel and a research platform, who needs the Hurd?
Now if you want to talk about interesting research, let's look at SawMill and EROS.
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.
Still, with a plan, you only get the best you can imagine. I'd always hoped for something better than that. -CP
It seems that /. rarely if ever corrects a spelling mistake when that mistake is made by the submitter of the story. So its up to the submitters to learn to spell and use grammar correctly. In which case, we could be here a damn long time...
A few points here from one who watched the Linus vs Andy T debate in real time.
It is well know what Linus thinks of Microkernels, while QNX (which was quite spiffy on an IBM PC-1!) proves that all microkernels are not created equal.
The Linux of today is not nearly as peppy compared to the Linux of yesteryear performance wise. At the same time, the first Linux kernels could only handle 64Mb processes. The original Linux was like a Datsun 240Z compared to your Grand-dad's DeSoto. Not alot of features - but it was FAST.
Compared to Minix at the time - it was lightyears ahead! Minix was REALLY designed to STAY on a 8088.
Finally - if Microkernels were God's gift to the world. Why did it take 10 years to get to a useable state, while Linux got there in less than two years?
Have you compiled your kernel today??
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?
Mac OS X isn't microkernel-based at all, so I wouldn't really call it a single-server.
Likewise, AFAIK only the BeOS network stack is in user space, so I'm not sure what that counts as.
You're missing the point. In HURD, the servers are in virtual memory, not physical memory. Therefore it _can_ write random chunks of memory.
Also, I think you're missing another point. In HURD, the kernel/user distinction is not very big. Each server is only given certain permissions, and it only has rights within that. Therefore, if you write and load kernel code, it still only operates within your permission set. I think the main difference between kernel/user code is the communication method.
Engineering and the Ultimate
Wouldn't Hurd be useful as a research tool? (Not be all end all.)
Given that you can extend the OS by just building servers, doesn't this lend it to quickly being able to show proof of concept?
I'm assuming here that building servers for Hurd (even for things that are "in" the OS, such as network stacks, device drivers, new filesystems, etc.) is considerably easier than putting similar things into Linux. If not, then I suppose it makes no better a research platform than Linux.
I'll see your senator, and I'll raise you two judges.
We've got Linux and the BSDs, why do we need anything else?
Because there can be no GNU System without the hurd. The rational for calling a particular OS environment "GNU/Linux" is just ridiculous if there has never been a completed GNU System for it to be derived from. But even Debian Hurd won't be the GNU System, it will just be the Debian distribution of an OS never released by its makers.
No matter how you define "operating system", it still requires a kernel. No kernel, no operating system. And GNU is described by its makers as an operating system.
Moderators: don't mod this down. I am not bashing your holy GNU. I think GNU is great. But I'm also honest enough to admit that it isn't an operating system, yet. In the meantime it makes a great parts repository for those creating other free operating systems.
A Government Is a Body of People, Usually Notably Ungoverned
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
And BeOS, BSD, Darwin and Solaris also have GNU software. What's your point? Are you demanding that Steve Jobs call his new product "GNU/OS X"?
Until GNU finally completes its own operating system by integrating a working hurd into the rest of their OS stuff, there is no GNU System. It does not exist.
A Government Is a Body of People, Usually Notably Ungoverned
like I've already visited it? maybe because of this?
--
People will no more call the GNU/Linux system only as Linux.
This does not follow out all. None of the Linux distributions out there are the GNU System. RMS says that it should be called "GNU/Linux" because it really is the GNU System with just the kernel swapped out. But there is *NO* GNU System! There is not now any stable OS with a stable hurd to swap out. And there certainly wasn't when the first Linux distributions arose out of the primordial software soup.
Rather, I think when Debian GNU/Hurd is finally released as stable (and it really ought to be named just "Debian GNU System"), then all of this crap about "LiGnuX" will disappear.
A Government Is a Body of People, Usually Notably Ungoverned
Yeah, I know tons of BSD people who understand GIMP perfectly well.
A Government Is a Body of People, Usually Notably Ungoverned
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]
Don't get me wrong, I'm not downing the Hurd, it's a very interesting project with a lot of promise.
Just a small note though - your stable kernel API is not necessarily an advantage. Linus doesn't want that for good reasons.
A stable kernel API means a commitment to backward binary compatibility. Which, over time, means an accumulation of all kinds of cruft (look at the latest iteration of Windows9x for plenty of examples.) It can severely limit developer options. Sometimes changing the API is the right thing to do. And the only advantage one would get out of this is binary compatibility - with any Free (or even merely Open) program, a simple recompile against the updated kernel source works. The drawbacks in this case clearly outweigh the rather dubious benefits.
I'm not a Hurd hacker, just an interested party that follows the information released on it, but I don't remember seeing this claim that the HURD will maintain a stable kernel API anywhere. Lacking any official word to the contrary, I would tend to expect that their position is the same as Linus on this - I would certainly be shocked if the FSF's own kernel project were willing to go make any significant technical sacrifice simply to maintain binary compatibility with some yet-to-be written commercial program that isn't even Open Source.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Friends don't let friends enable ecmascript.
I can already see the "why bother" people starting to come out of the woodwork. We've got Linux and the BSDs, why do we need anything else?
I don't think we really do at the moment, but it's healthy to have some people doing something completely different and seeing where it will take them. It's called "research" and it's the precursor to the "innovation" that everybody thinks free software is incapable of.
So there's a good chance that The Hurd will never make it past the "what a neat idea" stage. But it's also possible that, just when Linux starts hitting the scalability wall (it'll be a few years yet), a system like Hurd will be waiting to take over.
It is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail. - Abraham Maslow
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.
I'm sure Apple's engineers will be surprised to hear that Mach runs only on IA-32 and PA-RISC, especially since Mach is the core of Mac OS X. Ditto for the MkLinux people.
Not only does this demonstrate the stability and reliability of GNU software in a 'mission critical' context, it also is the first instance of the Hurd, shot around the world.
(sorry. I had to)
The REAL jabber has the /. user id: 13196
The REAL jabber has the user id: 13196
What you do today will cost you a day of your life
I realize that the two are fundamentally different OSes. However, I am not sure how many people are trained and skilled enough to work on low level programming projects such as HURD. So my question is simple and can be reduced to: how many open source OSes can the planet support?
MkLinux uses the Mach microkernel as the core of a Linux-compatible operating system. It was originally developed in cooperation with Apple, so it runs mostly on Macintoshim. Still, I remember either hearing or hallucinating that an IA-32 version existed somewhere.
In any case, with MkLinux, you have an operating system that's based on Mach and, to applications, looks like Linux. What does Hurd have that MkLinux doesn't? For that matter, what does MkLinux have that Hurd doesn't?
I suppose phrasing it this way is an invitation to a flame war, but, well, I'm ignorant of the details. Thus, Hurd looks to me like a duplication of the MkLinux effort. If I'm wrong in that conclusion, I'd appreciate it if someone would exlain why.
I was almost certain I'd already read that article, and couldn't imagine why ... then it occurred to me; Slashdot thinks several month old articles are news!
- Michael T. Babcock (Yes, I blog)
X is a _great_ idea for businesses, even if it doesn't offer a lot of advantages for the home user. It certainly doesn't hurt them any. HURD actually is kind of revolutionary in OS design. The fact that it emulates UNIX is more of a compatibility deal than a design issue. The overall design of HURD is extremely modern. There are many reasons why it would be useful. And of course there are no guarantees about its usefulness (how many projects have usefulness guarantees attached?).
You mentioned security exploits. The reason that there are "more exploits for UNIX than Windows", is that people don't usually even look for console exploits on Windows, since they assume the console operator will be trusted. In UNIX, since it has the additional feature of allowing so much to be done through remote logins. If I wanted to make my OS a featureless as Windows, I would make it more secure as well.
Anyway, don't flame an OS just because it doesn't give _you_ any advantages. That's the beauty of the open source movement - there is such diversity. If something doesn't appeal to you, don't use it! But there are many people (including myself) anxiously awaiting HURD to emerge because it offers us a lot of useful features. Maybe HURD isn't for the desktop, maybe it is. So what! Not every OS is for the desktop. Some are for servers, some are for mainframes, some are for graphic designers, some are for home desktops. If you go to a "one size fits all" mentality, then the OS chosen will suck for everyone.
Engineering and the Ultimate
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
I find it extremely ironic to find a note complaining about bias on Slashdot.
> The biggest myth is the one put out by you microkernel freaks is that the linux kernel is a monolithic kernel. It's not. It's a hybrid.
Could you back up this assertion, please ?
Cheers,
--fred
1 reply beneath your current threshold.
Also, being a kernel developer is not necessarily any harder than developing for a user-level project. This is a myth. In fact, it might in many cases be easier to be a kernel developer becasue you do not have to deal with different operating system APIs. In other words, they key issue is complexity. That is, there are relatively few Linux kernel developers because the complexity of the kernel is too high (and not well enough docuemented) to overcome for most people. So, if the kernel itself is less complex, more people would be able to make contributions. I think this was the main reason that I chose to ditch Linux in favour of BSD years ago -- I just got too fed up with the ugly undocumented hacks inside the Linux kernel.
(Note, I'm not saying that BSD is completely free of hacks, but I do find the code easier to understand. In addition, you tend to get manual pages for in-kernel features. The size of my man9 section currently counts 233.)
So, let's take a look at Hurd and see how it compares. Looking at a few files, I see some comments, but not nearly as many as in the Linux source code tree. And do you see any documentation, other than TODO and CHANGES? I think Linux wins the documentation battle hands-down.
Ummm... Ok.... I think this person was confusing multiprocessing with Multiple Processors. And this is a guy who writes software for medical devices. Sheesh.Oh well. I guess it's still nice that The Hurd is getting some publicity.
I'm a leaf on the wind. Watch how I soar.
Yeah, my usual response to the "hey, we could make this 2% faster by just totally munging up the code!!" mentality, is that computing and software development these days is no longer about maximizing scarce resources, but in managing complexity. Resources are abundant, we're drowning in disk space, memory, data, etc. We should be writing software that solves *human* problems, not hardware problems. A stick of 128 MB RAM is a much better solution in many cases than 2 man-years of optimizing for hardware which will just be obsolete anyway. I'd rather have a solidly designed, well implemented system, which is easily maintainable and upgradable, than a system optimized to run like an amphetamine addict which will break in a year, once the hardware needs to be upgraded or a feature added.
It's 10 PM. Do you know if you're un-American?
Were as I drove a 84 300ZX for 11 years - about the same distance between that and a 240Z as there is between a 0.12 kernel (my first) and a 2.4.x kernel ;-)
Have you compiled your kernel today??
You can't find anyone more convinced than me. I am on the same development since 1994, and I written most parts myself.
Managing complexity is the key. Complexity in design, complexity in implementation, complexity in debugging, complexity in testing, complexity in documentation, complexity in maintenance, complexity in evolution.
The scarsiest resource is the development time. No way to do a baby in one month by using 9 women. Hardware is cheap. Complexity use time. Complexity is time.
When I look back at that huge project, I can see that Donald Knuth (I think the sentence is from him) was right. "Premature Optimisation is the Root of al Evils". Writing 1000 lines of code one day is of no use if you have to dig it a couple of years later.
Cheers,
--fred
1 reply beneath your current threshold.