> Why exactly are Ubuntu attempting to recreate the wheel here? > > This has already been done by Specifix / Foresight Linux (www.foresightlinux.com) > > These distros use a system called Conary, developed in part by the guy behind RPM,
(...who reinvented the wheel creating RPM when he could have used the already existing dpkg instead?...:-) )
> The reason Bitkeeper was choosen over all the others is that it allowed a developer to keep their own private version and others to share specific parts... which is the opposite of nearly every other source management system. Every other system seeks to have one "golden" version with developers contributing only to that... think corperate style software, always working toward some "release". Bitkeeper was the only one to allow individuals to keep their "pet" projects, but still share all the changes amongst themselves... i.e you could have Linus' version, Alan Cox version, etc... they can all "borrow back" from eachother, but don't Have to. it's percisely the opposite philosophy of every other source control system to conform everybody to "the way".
Sorry if that sounds harsh; but you obviously do not have a clue about version control systems. Subversion is actually the *only* one of the newer systems I know, that uses the CVS-style centralistic approach. *All* the others (arch/bazaar/bazaar-ng, darcs, monotone) are distributed.
> They are now propriatary software developers, and it is immoral to support ubunto because of it, unfortunatly.
Wrong. You are missing the point. It's not as if Canonical sells Rosetta as a proprietary product. It's not a product *at all*; it's a service.
The remark about it becoming "Open Source" in the future, really just means that it *might* become a product at some point; and then, *of course* it would be "Open Source".
I accede that the FAQ entry is confusing, though:-)
> The FAQ doesn't say *why* Rosetta isn't open source.
It follows from the object at hand: It isn't intended as a tool that everyone installs on his private box to do his own translations. Rather, you are asked to do your translations using *the* Rosetta, on the Canonical site.
It's simply a service, not a product. Asking to make it "Open Source" is just like asking google to make it "Open Source"...
Well, depends on how broad you define "OS". You talking about Linux all the time would imply that you mean kernel only, in which case it is most certainly much simpler than a browser at the same completeness level.
> I guess I could agree with it if you're extreme about the modifier "simple."
There is nothing extreme about it. It's widely known that a single person can implement a perfectly useful UNIX system in a reasonable amount of time. (See Minix for example.) Everything else is broadening the scope, convenience, and tuning for performance; but not part of a *simple* OS.
> However, any OS that supports enough hardware to actually be useful to the world is going to be much more complex than the most complicated browser.
An OS can be perfectly useful without supporting all possible hardware on the planet.
Also, adding more hardware support for the most part only makes for total size, but not *complexity*.
> Firefox is in the 10's of MB. I don't know of any useful OS that is that small.
Go check for embedded systems. Some of them can even be used as a fairly comfortable desktop.
> Which has taken more development hours and time to mature, Linux or Firefox? Which is the most criticized as not being mature enough for the average person to use even though it has had a longer time to develop and has more development effort put into it, Linux or Firefox?
This is a very bad comparision. Linux gets its complexity from about every feature the developers could thing of being implemented (often in several redundant approaches), and being optimized for getting every last ounce of performance.
Mozilla on the other hand hardly implements the bare minumum for a halfway complete browser. (If you really consider all the newer web standards. it actually falls far from that.)
> Most of Mozilla's problems with complexity and bloat/size are their own doing. They came up with a completely meglomanicial design plan (XUL etc) and it took them 5 long years to make acceptable to the end user. The only reason for this is because they were playing with AOL's $$$ -- it could've been done much more simply and quickly.
This is quite an outrageous insult on the Mozilla developers, and I wonder what evidence you claim to it. Have you worked on a browser project? Can you give some example that did it better?
Konqueror maybe, claimed to have such a clean layout engine? Sorry, konqueror is a joke. It doesn't support *one* of the newer standards, it is about five times as bad in CSS support, plus loads of other bugs and compatibility problems. (Yes, it *did* get better with Apple's support; but last time I checked it was still ridiculous to compare it to Mozilla.)
Or Opera maybe, the one hyped for being standards compliant and efficient at the same time? Last time I compared it supported maybe half of the newer standards Mozilla does, and CSS support was about twice as bad. (This is not to say Mozilla has anything near good CSS 2.1 support; only Opera is still worse.) Plus, it isn't that much faster in most regards, either.
Or do you claim that all of those are just incompetent, and someone else could put together a much better one in half the time? Micorsoft maybe? With their last browser (which took about 6 years development time) not even coming close Konqueror in most regards?
Well, I for one *did* work on a browser. I have considered the problem of implementing web standards in a complete, correct, and efficient manner well enought to be able to claim that the problems are *not* Mozilla's (or any other browser vendor's) fault. It's not just bad luck that even the best browsers available are very very far from deserving to be called really good. It's an inherent complexity problem.
(XUL makes for terrible UI perfomance BTW, but certainly isn't responsible for any of the other problem Mozilla faces.)
Well, validating XML parsers also have to complain on DTD conformance failure, "at user's option". But yes, this doesn't apply to browsers, which generally are not validating. Seems I have implicitely assumed the comment was about well-formedness, as this is much more of a problem in practice... (As the original comment was referring to HTML not XHTML, it isn't actually clear whether it was relating to well-formedness only or also validity in the XML sense -- in SGML, there is no distiction.)
> The second is for IE to show me a big nasty error instead of my web page if it is not compliant with the DTD.
Actually, that's what the standard prescribes for XML -- including XHTML (if served with the right content type). Oh well, IE6 doesn't even know about XHTML...
Let's take a closer look at the numbers. MS hasn't started from zero; they have (as they usually do) bought an existing product for a base. Considering this, we can safely assume that going from zero to matching Netscape would has taken more than three years. It took about the same amount of time to go from there to IE6.
Now it also took Mozilla more than three years to master the complexity of the new code (IIRC they started by the end of 1998) -- but once there, it easily soared not only past IE4, but also IE6 and everything else within a few months.
In short: It took Mozilla about half the time to create a browser overwhelmingly better in nearly every regard. It will be funny looking at MS trying to catch up:-)
Sure, they could make such a browser, at only somewhat more than an order of magnitude more developement effort than has gone into Mozilla... Oh wait, that would be about two orders of Magnitude above IE6.
Seriously, even MS couldn't do that. Not if they focused all the resources they have for a considerable amount of time. Sorry, browsers just aren't that simple anymore.
Actually, I bet for the opposite. If free software developers weren't as busy and constrained by falling for all that "it's completely useless unless it copies every single obscure feature from it's proprietary competitors on top of any genuine functionality" whining anymore, they could produce much more innovative stuff.
Plus, it's just not true that there is little innovation if free software. While all the "big" applications, getting most exposure, are really mostly clones of proprietary conterparts, many smaller projects are doing genuine stuff, which taken together is really impressive. (Even Firefox has a glimpse of that, thanks to all the independently developed extensions.)
> Same here. I advocated IE over Netscape because the releases were coming faster and the product worked better.
Sure, IE was really better than Netscape. But that wasn't hard, considering how much Netscape sucked at the time.
It's a *very* different story with Firefox now.
> it's not like a browser is something as complex as an operating system.
Wrong. A good browser is actually a lot more complex than a simple OS nowadys. All the newer W3C standards are just absurdly complex. (Ever wondered *why* still no browser in existence supports all of CSS2, and never will?...)
Creating a browser that fully supports all the newer standards, is stable, secure, featurefull, *and* has good performance, is a tremendous task. Even the Mozilla family (by far the closest to this ideal, except for performance) is still very far from being an ultimative browser. (About an order of magnitude in terms of developement effort, I'd say.)
IE will really have a hard time catching up. I doubt they will even come very near.
LSB is not embraced, because it's an attempt at faciliationg a distribution method that just doesn't match the way things are done on GNU/Linux.
Application programs coming with an "installation program" that tries to take care of everything, in the hope it will not break in most cases, is the Windows way of doing things. That's a different world. The GNU/Linux world is the world of apt-get, emerge, urpmi.
The ones who do not understand that, are those who think of GNU/Linux as just another Windows. Those who know how GNU/Linux works, and would have the ability to change it, are not interested in doing so -- those who understand GNU/Linux, are able to appreciate the distribution method as one of the major *advantages* over Windows. They will happily take the pain of having to build from source, in the rare case that they need some obscure application not packaged by their distribution, in exchange for everything else working about 10 times easier and better than on Windows.
> Hurd just keeps getting better every year and maybe someday it will clearly surpass Linux in a few areas.
Actually, it clearly surpasses Linux in a few areas already now. Only these are not the obvious parameters like speed, stability, security, hardware and software support; it's rather the "how much effort does it cost to do this-and-that?" kind of things. The Hurd's design allows for various things that are just impossible or very awkward on monolithical systems.
Sadly, people usually only pay attention to the numbers. But the Hurd can never succeed that way; it is an hen-and-egg problem. People won't get interested in it unless it can beat Linux in at least one category, but without enough people interested, it can never gather enough momentum to get the manpower necessary for that.
The only way to break this circle is to get away from those obvious categories, and stress the advantages of the Hurd instead; to demonstrate that even if it can't compete in any of those other categories (yet), the system is already now extremly interesting, and definitely worth a second look.
Sadly, not even most of the Hurd developers seem to realize this, and instead of working on exposing the real strengths, they concentrate on the hopeless struggle trying to catch up on numbers:-(
No, we need another Linus to take up Hurd developement:-) The Hurd had a very bad start (for various reasons); but nevertheless, there is very valuable work in it -- no point to start again from scratch.
> couple that with the lack of anything compelling about it other than the philosophy
Lack of anything compelling? How about these for a start: * resource management (Hurd/L4):
* responsiveness
* performance under load
* adapting to specific applications' needs
* quality of service * robustness/stability * security * extensibility * flexibility * uniformness * transparency * convenience * modularity * integration
The last ones in the list are the most appealing, though not obvious: Taking some Unix concepts farther (most notably through filesystem translators), allows the Unix philosophy to be applied to newer developements (e.g. interactive applications) also. This means enormous power -- building complex systems and solving specific tasks by combining simple standard tools becomes possible again, like it was in the early days of Unix, but not anymore for most of todays applications.
> Linux has already far surpassed it in every catagory (hardware support, > software support, usability, performance, etc.) and is just as Free as the > HURD, so what gives?
Only that the Hurd doesn't focus on any of those categories. The Hurd focuses on robustness, flexibility, convenience; on faciliating things that aren't even possible on monolithical systems, or only in a very awkward fashion.
(Though should the Hurd ever really take off, I wouldn't be surprised if it will best in the other categories too, in one or another case: The Hurd design means that once the mechanisms are in place, it's actually *easier* to achieve many goals.)
It's not about defects. Of course it works; nobody will doubt that. It's about what more you can do with it, and most importantly *how hard* it is to do certain things.
The fundamental design of Unix was created in times when using a computer mainly meant processing simple text data; when hardware drivers were hardly an issue; when timesharing meant: dozens terminals attached to a single computer; when networks were practically non-existant; when nobody dreamed of graphical environments, multimedia; and so on.
Looking at stuff like KDE/GNOME, or any GNU/Linux distribution: They do not follow the often-cited "Unix philosophy" even remotely. They can't. The original Unix design is just too limited for that. When demands are changing that radically, you have to extend the paradigms, bring in new ideas, so the new stuff fits in again.
Of course, with enough effort, you can always fill the needs, somehow, awkwardly. But how much simpler, nicer things could be for programmers, admins, and often also the users, with some concepts at the core better suiting todays requirements?
*That* is why we need innovative systems like the Hurd.
Actually, Plan9 is mostly about taking "everything is a file" even further. (And the Hurd also, to that matter... Only that Hurd additionally has a radically different internal design.)
AFAIK QNX is an example of a very popular multiserver system. Besides not being free, it has a very good reputation. I don't know how much of the theoretical benefits it actually delivers; but at least it proves a real microkernel-based system is actually possible and can do very well.
> Unfortunately, Hurd won't save us from hangs. Drivers can hang your machine, > period. A good example of that is X.org. It runs in userspace, but touching > the wrong register on the graphics card will block your PCI bus. Hurd won't > be different - be it in userspace or not, if you touch the wrong register you > machine will hang. With no oportunity of doing anything.
Wrong. If a driver runs in userspace, we can limit which registers it is allowed to touch. Of course, some drivers can still hang the machine, like a PCI driver or so; but a graphics or a CDROM driver can't do so anymore.
X being in userspace doesn't help (actually, makes it worse; that's why KGI was launched), because monolithical systems are just not prepared for it. X simply get's all privileges, and behaves the same a driver in kernel would do. The protection mechanisms possible with userspace drivers just do not exist in Linux.
> We already have userspace filesystems in linux - just check FUSE in the -mm > tree, or the userspace drivers infrastructure someone posted a couple of > weeks ago in the lkml. If "having everything in userspace" starts having > sense (which won't have, at least with today's hardware) I'd rather work in > porting linux drivers to userspace (like they already did in 2.6 with libusb) > than using a OS like hurd, where developers have started doing something so > wrong like letting apps to do their own mm.
If Linux starts to do things that the Hurd was doing from the beginning, it only proves the Hurd developers right...
Only that userspace file systems will never work very good on Linux (as Linus has pointed out himself), the system not being designed with that in mind. It's not a coincidence the Hurd has such a complicated design; it's a function of what it wants to achieve. The lesson learned from Hurd on Mach is that if we want to do things like filesystems in userspace right, we have to move *even more* things out of the kernel. Therefor the move to L4, processes doing their own memory management etc.
For Linux to be able to do all what the Hurd can do, it would have to be rewritten nearly completely... The result being a design most probably very similar to Hurd's.
AFAIK OpenBSD does nothing fundamentally new to achieve better security. All
they do is try very hard not to let all those bugs slip by that can cause
security problems due to the limitations of the traditional Unix design; it's
kind of a brute force approach. In contrast, the Hurd design is *inherently*
more secure; many security problems just do not emerge in the first place. Let
alone all the things you can do with the Hurd not even possible with OpenBSD or
Linux or other monolithical systems.
The Hurd folks aren't implementing L4. They are implementing about the first serious multi-server system working on top of L4.
(Well, they have also filled some gaps in L4 that nobody else has bother to implement so far, and provided some considerable input to the L4 folks, by means of being the first serious multi-server system on top of L4 and observing how things actually work out in practice...)
Thus talking about "pure microkernel" in the OP is somewhat confusing; it's more about the system *above* the microkernel more consequently following the ideal of a microkernel-based system, strict protection domains and all. If you are really interested in what is so special about the Hurd, take a look at it's design instead of making assumptions about all microkernel-based systems are the same...
Slashdot Mirror
How ironic...
:-) )
> Why exactly are Ubuntu attempting to recreate the wheel here?
>
> This has already been done by Specifix / Foresight Linux (www.foresightlinux.com)
>
> These distros use a system called Conary, developed in part by the guy behind RPM,
(...who reinvented the wheel creating RPM when he could have used the already existing dpkg instead?...
> The reason Bitkeeper was choosen over all the others is that it allowed a developer to keep their own private version and others to share specific parts... which is the opposite of nearly every other source management system. Every other system seeks to have one "golden" version with developers contributing only to that... think corperate style software, always working toward some "release". Bitkeeper was the only one to allow individuals to keep their "pet" projects, but still share all the changes amongst themselves... i.e you could have Linus' version, Alan Cox version, etc... they can all "borrow back" from eachother, but don't Have to. it's percisely the opposite philosophy of every other source control system to conform everybody to "the way".
Sorry if that sounds harsh; but you obviously do not have a clue about version control systems. Subversion is actually the *only* one of the newer systems I know, that uses the CVS-style centralistic approach. *All* the others (arch/bazaar/bazaar-ng, darcs, monotone) are distributed.
> They are now propriatary software developers, and it is immoral to support ubunto because of it, unfortunatly.
:-)
Wrong. You are missing the point. It's not as if Canonical sells Rosetta as a proprietary product. It's not a product *at all*; it's a service.
The remark about it becoming "Open Source" in the future, really just means that it *might* become a product at some point; and then, *of course* it would be "Open Source".
I accede that the FAQ entry is confusing, though
> The FAQ doesn't say *why* Rosetta isn't open source.
It follows from the object at hand: It isn't intended as a tool that everyone installs on his private box to do his own translations. Rather, you are asked to do your translations using *the* Rosetta, on the Canonical site.
It's simply a service, not a product. Asking to make it "Open Source" is just like asking google to make it "Open Source"...
> an OS does A LOT more than a browser
Well, depends on how broad you define "OS". You talking about Linux all the time would imply that you mean kernel only, in which case it is most certainly much simpler than a browser at the same completeness level.
> I guess I could agree with it if you're extreme about the modifier "simple."
There is nothing extreme about it. It's widely known that a single person can implement a perfectly useful UNIX system in a reasonable amount of time. (See Minix for example.) Everything else is broadening the scope, convenience, and tuning for performance; but not part of a *simple* OS.
> However, any OS that supports enough hardware to actually be useful to the world is going to be much more complex than the most complicated browser.
An OS can be perfectly useful without supporting all possible hardware on the planet.
Also, adding more hardware support for the most part only makes for total size, but not *complexity*.
> Firefox is in the 10's of MB. I don't know of any useful OS that is that small.
Go check for embedded systems. Some of them can even be used as a fairly comfortable desktop.
> Which has taken more development hours and time to mature, Linux or Firefox? Which is the most criticized as not being mature enough for the average person to use even though it has had a longer time to develop and has more development effort put into it, Linux or Firefox?
This is a very bad comparision. Linux gets its complexity from about every feature the developers could thing of being implemented (often in several redundant approaches), and being optimized for getting every last ounce of performance.
Mozilla on the other hand hardly implements the bare minumum for a halfway complete browser. (If you really consider all the newer web standards. it actually falls far from that.)
> Most of Mozilla's problems with complexity and bloat/size are their own doing. They came up with a completely meglomanicial design plan (XUL etc) and it took them 5 long years to make acceptable to the end user. The only reason for this is because they were playing with AOL's $$$ -- it could've been done much more simply and quickly.
This is quite an outrageous insult on the Mozilla developers, and I wonder what evidence you claim to it. Have you worked on a browser project? Can you give some example that did it better?
Konqueror maybe, claimed to have such a clean layout engine? Sorry, konqueror is a joke. It doesn't support *one* of the newer standards, it is about five times as bad in CSS support, plus loads of other bugs and compatibility problems. (Yes, it *did* get better with Apple's support; but last time I checked it was still ridiculous to compare it to Mozilla.)
Or Opera maybe, the one hyped for being standards compliant and efficient at the same time? Last time I compared it supported maybe half of the newer standards Mozilla does, and CSS support was about twice as bad. (This is not to say Mozilla has anything near good CSS 2.1 support; only Opera is still worse.) Plus, it isn't that much faster in most regards, either.
Or do you claim that all of those are just incompetent, and someone else could put together a much better one in half the time? Micorsoft maybe? With their last browser (which took about 6 years development time) not even coming close Konqueror in most regards?
Well, I for one *did* work on a browser. I have considered the problem of implementing web standards in a complete, correct, and efficient manner well enought to be able to claim that the problems are *not* Mozilla's (or any other browser vendor's) fault. It's not just bad luck that even the best browsers available are very very far from deserving to be called really good. It's an inherent complexity problem.
(XUL makes for terrible UI perfomance BTW, but certainly isn't responsible for any of the other problem Mozilla faces.)
Well, validating XML parsers also have to complain on DTD conformance failure, "at user's option". But yes, this doesn't apply to browsers, which generally are not validating. Seems I have implicitely assumed the comment was about well-formedness, as this is much more of a problem in practice... (As the original comment was referring to HTML not XHTML, it isn't actually clear whether it was relating to well-formedness only or also validity in the XML sense -- in SGML, there is no distiction.)
There is always the possibility that you missed the point :-) Tipp: See how the original posting was actually moderated :-)
> The second is for IE to show me a big nasty error instead of my web page if it is not compliant with the DTD.
Actually, that's what the standard prescribes for XML -- including XHTML (if served with the right content type). Oh well, IE6 doesn't even know about XHTML...
Let's take a closer look at the numbers. MS hasn't started from zero; they have (as they usually do) bought an existing product for a base. Considering this, we can safely assume that going from zero to matching Netscape would has taken more than three years. It took about the same amount of time to go from there to IE6.
:-)
Now it also took Mozilla more than three years to master the complexity of the new code (IIRC they started by the end of 1998) -- but once there, it easily soared not only past IE4, but also IE6 and everything else within a few months.
In short: It took Mozilla about half the time to create a browser overwhelmingly better in nearly every regard. It will be funny looking at MS trying to catch up
Sure, they could make such a browser, at only somewhat more than an order of magnitude more developement effort than has gone into Mozilla... Oh wait, that would be about two orders of Magnitude above IE6.
Seriously, even MS couldn't do that. Not if they focused all the resources they have for a considerable amount of time. Sorry, browsers just aren't that simple anymore.
Well, this is really quite OT, but anyways:
Actually, I bet for the opposite. If free software developers weren't as busy and constrained by falling for all that "it's completely useless unless it copies every single obscure feature from it's proprietary competitors on top of any genuine functionality" whining anymore, they could produce much more innovative stuff.
Plus, it's just not true that there is little innovation if free software. While all the "big" applications, getting most exposure, are really mostly clones of proprietary conterparts, many smaller projects are doing genuine stuff, which taken together is really impressive. (Even Firefox has a glimpse of that, thanks to all the independently developed extensions.)
> Same here. I advocated IE over Netscape because the releases were coming faster and the product worked better.
Sure, IE was really better than Netscape. But that wasn't hard, considering how much Netscape sucked at the time.
It's a *very* different story with Firefox now.
> it's not like a browser is something as complex as an operating system.
Wrong. A good browser is actually a lot more complex than a simple OS nowadys. All the newer W3C standards are just absurdly complex. (Ever wondered *why* still no browser in existence supports all of CSS2, and never will?...)
Creating a browser that fully supports all the newer standards, is stable, secure, featurefull, *and* has good performance, is a tremendous task. Even the Mozilla family (by far the closest to this ideal, except for performance) is still very far from being an ultimative browser. (About an order of magnitude in terms of developement effort, I'd say.)
IE will really have a hard time catching up. I doubt they will even come very near.
LSB is not embraced, because it's an attempt at faciliationg a distribution method that just doesn't match the way things are done on GNU/Linux.
Application programs coming with an "installation program" that tries to take care of everything, in the hope it will not break in most cases, is the Windows way of doing things. That's a different world. The GNU/Linux world is the world of apt-get, emerge, urpmi.
The ones who do not understand that, are those who think of GNU/Linux as just another Windows. Those who know how GNU/Linux works, and would have the ability to change it, are not interested in doing so -- those who understand GNU/Linux, are able to appreciate the distribution method as one of the major *advantages* over Windows. They will happily take the pain of having to build from source, in the rare case that they need some obscure application not packaged by their distribution, in exchange for everything else working about 10 times easier and better than on Windows.
No place for LSB.
> Hurd just keeps getting better every year and maybe someday it will clearly surpass Linux in a few areas.
:-(
Actually, it clearly surpasses Linux in a few areas already now. Only these are not the obvious parameters like speed, stability, security, hardware and software support; it's rather the "how much effort does it cost to do this-and-that?" kind of things. The Hurd's design allows for various things that are just impossible or very awkward on monolithical systems.
Sadly, people usually only pay attention to the numbers. But the Hurd can never succeed that way; it is an hen-and-egg problem. People won't get interested in it unless it can beat Linux in at least one category, but without enough people interested, it can never gather enough momentum to get the manpower necessary for that.
The only way to break this circle is to get away from those obvious categories, and stress the advantages of the Hurd instead; to demonstrate that even if it can't compete in any of those other categories (yet), the system is already now extremly interesting, and definitely worth a second look.
Sadly, not even most of the Hurd developers seem to realize this, and instead of working on exposing the real strengths, they concentrate on the hopeless struggle trying to catch up on numbers
No, we need another Linus to take up Hurd developement :-) The Hurd had a very bad start (for various reasons); but nevertheless, there is very valuable work in it -- no point to start again from scratch.
> I have no idea why Linux became more popular in the first place, considering that there was already BSD and the HURD
Because there was a nearly finished GNU system readily waiting for a Kernel to be plugged in and complete it.
The free BSD variants -- aside from really starting somewhat later -- had to do work on various parts of the system, not only the Kernel.
The Hurd didn't come along that fast because of the ambitious design and the fairly closed developement model.
> couple that with the lack of anything compelling about it other than the philosophy
Lack of anything compelling? How about these for a start:
* resource management (Hurd/L4):
* responsiveness
* performance under load
* adapting to specific applications' needs
* quality of service
* robustness/stability
* security
* extensibility
* flexibility
* uniformness
* transparency
* convenience
* modularity
* integration
The last ones in the list are the most appealing, though not obvious: Taking some Unix concepts farther (most notably through filesystem translators), allows the Unix philosophy to be applied to newer developements (e.g. interactive applications) also. This means enormous power -- building complex systems and solving specific tasks by combining simple standard tools becomes possible again, like it was in the early days of Unix, but not anymore for most of todays applications.
> Linux has already far surpassed it in every catagory (hardware support,
> software support, usability, performance, etc.) and is just as Free as the
> HURD, so what gives?
Only that the Hurd doesn't focus on any of those categories. The Hurd focuses
on robustness, flexibility, convenience; on faciliating things that aren't even
possible on monolithical systems, or only in a very awkward fashion.
(Though should the Hurd ever really take off, I wouldn't be surprised if it
will best in the other categories too, in one or another case: The Hurd design
means that once the mechanisms are in place, it's actually *easier* to achieve
many goals.)
It's not about defects. Of course it works; nobody will doubt that. It's about
what more you can do with it, and most importantly *how hard* it is to do
certain things.
The fundamental design of Unix was created in times when using a computer
mainly meant processing simple text data; when hardware drivers were hardly an
issue; when timesharing meant: dozens terminals attached to a single computer;
when networks were practically non-existant; when nobody dreamed of graphical
environments, multimedia; and so on.
Looking at stuff like KDE/GNOME, or any GNU/Linux distribution: They do not
follow the often-cited "Unix philosophy" even remotely. They can't. The
original Unix design is just too limited for that. When demands are changing
that radically, you have to extend the paradigms, bring in new ideas, so the
new stuff fits in again.
Of course, with enough effort, you can always fill the needs, somehow,
awkwardly. But how much simpler, nicer things could be for programmers, admins,
and often also the users, with some concepts at the core better suiting todays
requirements?
*That* is why we need innovative systems like the Hurd.
Actually, Plan9 is mostly about taking "everything is a file" even further. (And the Hurd also, to that matter... Only that Hurd additionally has a radically different internal design.)
AFAIK QNX is an example of a very popular multiserver system. Besides not being free, it has a very good reputation. I don't know how much of the theoretical benefits it actually delivers; but at least it proves a real microkernel-based system is actually possible and can do very well.
> Unfortunately, Hurd won't save us from hangs. Drivers can hang your machine,
> period. A good example of that is X.org. It runs in userspace, but touching
> the wrong register on the graphics card will block your PCI bus. Hurd won't
> be different - be it in userspace or not, if you touch the wrong register you
> machine will hang. With no oportunity of doing anything.
Wrong. If a driver runs in userspace, we can limit which registers it is
allowed to touch. Of course, some drivers can still hang the machine, like a
PCI driver or so; but a graphics or a CDROM driver can't do so anymore.
X being in userspace doesn't help (actually, makes it worse; that's why KGI was
launched), because monolithical systems are just not prepared for it. X simply
get's all privileges, and behaves the same a driver in kernel would do. The
protection mechanisms possible with userspace drivers just do not exist in
Linux.
> We already have userspace filesystems in linux - just check FUSE in the -mm
> tree, or the userspace drivers infrastructure someone posted a couple of
> weeks ago in the lkml. If "having everything in userspace" starts having
> sense (which won't have, at least with today's hardware) I'd rather work in
> porting linux drivers to userspace (like they already did in 2.6 with libusb)
> than using a OS like hurd, where developers have started doing something so
> wrong like letting apps to do their own mm.
If Linux starts to do things that the Hurd was doing from the beginning, it
only proves the Hurd developers right...
Only that userspace file systems will never work very good on Linux (as Linus
has pointed out himself), the system not being designed with that in mind. It's
not a coincidence the Hurd has such a complicated design; it's a function of
what it wants to achieve. The lesson learned from Hurd on Mach is that if we
want to do things like filesystems in userspace right, we have to move *even
more* things out of the kernel. Therefor the move to L4, processes doing their
own memory management etc.
For Linux to be able to do all what the Hurd can do, it would have to be
rewritten nearly completely... The result being a design most probably very
similar to Hurd's.
AFAIK OpenBSD does nothing fundamentally new to achieve better security. All they do is try very hard not to let all those bugs slip by that can cause security problems due to the limitations of the traditional Unix design; it's kind of a brute force approach. In contrast, the Hurd design is *inherently* more secure; many security problems just do not emerge in the first place. Let alone all the things you can do with the Hurd not even possible with OpenBSD or Linux or other monolithical systems.
The Hurd folks aren't implementing L4. They are implementing about the first
serious multi-server system working on top of L4.
(Well, they have also filled some gaps in L4 that nobody else has bother to
implement so far, and provided some considerable input to the L4 folks, by
means of being the first serious multi-server system on top of L4 and observing
how things actually work out in practice...)
Thus talking about "pure microkernel" in the OP is somewhat confusing; it's
more about the system *above* the microkernel more consequently following the
ideal of a microkernel-based system, strict protection domains and all. If you
are really interested in what is so special about the Hurd, take a look at it's
design instead of making assumptions about all microkernel-based systems are
the same...