
Debian GNU/Hurd Preinstalled by UK Computer Maker 136
Anonymous Coward writes "Space-Time Systems in Malvern, England, is now offering
computers with GNU/Hurd pre-installed
in parallell with the Debian GNU/Linux
system. Please see
this page for more information." Warning: the Space-Time Systems site loaded slowly when I checked it this morning. You may want to use the (slightly out-of-date) Google cached version for the moment.
Re:Microkernel does not have to be slow. (Score:1)
is BeOS a single or multiserver OS?
The Hurd is multi-server multi-threaded, so the overhead is quite high.
But then, we did NO profiling and NO optimization so far.
By introducing new RPCs at strategic places, speed will certainly improve.
However, don't worry about that too soon.
brinkmd@debian.org
Re:Monolithic vs Micro Kernels: Windows? (Score:1)
By the time HURD is ready for primetime, Linux may have already cloned all its features.
Re:Free *BSD derivatives came first and more... (Score:1)
No point in mining the UNIX vein further
There's no reason to run over to or even follow the development of the Hurd.
Those are inane comments. Using your philosophy, *BSD advocates who use BSDLite4.4 derivative can easily attest that since free *BSD derivatives were available before Linux, that there was no point to even developing Linux.
That's not to say that Linux is the ultimate OS, because it isn't. It's a total piece of junk in many ways, but that's what you expect with UNIX, and that's where Linux descended from.
You're quite correct - in *very* many ways, Linux is horribly coded when compared to other OSes (i.e. *BSDs), using temporary patchwork rather than doing the right thing from the beginning. All the more reason for many *nix derivatives to exist - the users/developers can make their own choice.
Hurd is too close to the UNIX/Linux style for anyone to care.
As an ex-NEXTSTEP developer who regrets their acquisition by Apple and now a vocal free software advocate/Linux user as well, I am *very* interested in GNU/Hurd and GNU Mach. Its very architecture will give it excellent scalability and security, with all the familiarity of a *nix. Linux is very good for now, but its scalability is finite - GNU/Hurd may be the alternate free OS when Linux tops out.
Again, having many OSes, a large number which are free or OSD-compliant, is a good thing. Remember, while Linux developers are shaping the present, the Hurd developers are mapping Free Software's future!
~AC
Re:Hurd status (Score:1)
>the Hurd maintainers are having trouble keeping
>up with the changes made to the Linux networking
>code).
Hmm, does this mean that it is properly called "Linux/Hurd," and that Linus will start interrupting other speakers at conferences?
[duck]
Nah, windows only has a captain-- (Score:1)
hawk, who should really be preparing tomorrow's lectures instead of reading this . . .
Re:http://www.slashdot.org/software/hurd/hurd.html (Score:1)
--
Re:Is it usable? (Score:1)
--
Updated: 23 Jan 1999 matthias (Score:1)
Says something about progress of that development.
Why do not they open a start-up, get $1B of IPO money, and actually hire somebody to nake the product.
I am only partially kidding
Re:Monolithic vs Micro Kernels: Windows? (Score:1)
Yeah, but at what cost?
See, this is my problem with Windows. (Really trying to avoid a flamewar. *please* don't think I'm saying that Windows is to Linux as Linux is to the HURD.) Windows just throws more and more things in, eventually turning the thing into Frankenstein's OS. It seems to me that the cleaner approach is better, especially as we get massively faster hardware.
Besides, wasn't there a problem with Linux's ability to scale to many (>4, say) processors? Wouldn't HURD's modularity allow it to scale much higher? (This is a serious question. I'm curious.)
Re: (Score:1)
Re: (Score:1)
Re: (Score:1)
Transputers... (Score:1)
It did what you were talking about right in the chip. And it was a parallel processing chip.
Sadly it died... Broke my heart...
Re:Monolithic vs Micro Kernels: Windows? (Score:1)
Another problem is the lack of interest in this approach. Sure it is cool from a computer science approach, but the reality is that it is not that useful. For example the POSIX system and OS2 system was to be expanded. But because of political and interest reasons those things just were not extended.
Remember the big multi-CPU support plan for NT? Well time has shown there is no interest. The people want Intel.
So while the Hurd concept is neat, the long term will be that it is not something that is useful. Unless HURD does things that other OS's cannot do. Then maybe this approach will win over.
Re:What is reiserfs exactly anyway? (Score:1)
OT - about your .sig (Score:1)
Re:the difference that HURD brings (Score:1)
Obviously, this architecture meant that later implementing full memory protection was next to impossible.
The Amiga system C and 68k macro assembler includes are really fascinating - very well written, but quite different to mainstream systems these days.
Re:First %100 GPL'd system? (Score:1)
www.freiburg.linux.de/openbios/ [linux.de]
Re:HURD: The final piece of the puzzle? (Score:1)
I can see HURD be used in larger server workstation with slower adaptation to new hardwares and devices.
It would seem that part of the microkernel design is to facilitate the exact opposite of what you suggest: is should provide for quicker, easier development of drivers for new hardware as these are individually testable. From what they claim on their web-page it would be much easier then the current "loadable modules" system that Linux uses. It should still be a win-win though as you say. Choice is good and allows competition - I hope that they get 0.3 out soon.
[...]penetration (Score:1)
Likewise for "significantly larger market presence", "fragmentation" etc., who cares? It should be encouraged. You may be right about the company trying to market a distro with a new feature, but what's wrong with that? It'll give more people a chance to play with it at the expense of a fraction of their disk-space.
Re:Hurd status (Score:1)
Re:Monolithic kernel vs. Microkernel. (Score:1)
Not with a light load, but... (Score:1)
However, the great performance problem with MK OS's becomes most apparent when they are heavily loaded; message-passing (and to a lesser extent context switching) takes a bigger and bigger slice of the total system's running time, which means you get effectively much less work. That's where monolithic systems (e.g. Unix) greatly outpace the MK ones.
I'd say that MK systems are probably more well-suited to workstations and monolithic systems to servers.
Just what are you saying? (Score:1)
Re:First %100 GPL'd system? (Score:1)
Transmeta? :) (Score:1)
(I had to make a comment sometime)
well, reiserfs... (Score:1)
If you still like that dream, then reiserfs may send you directly to heaven...
And save you an investment into Intel or AMD.
You don´t want to know! (Score:1)
Well, it doesnt have a kernel.
Where other systems have a kernel, it has =something=.
You really dont want to know, what =something= is.
And forget about your question! Such questions are dangerous!
Hell! (Score:1)
Now the poor guy will have endless nightmares
(and wake up in the night, covered with cold sweat, mumbling "msd...ooos")!
Offtopic? I dont think so... (Score:1)
what an ass.
john
Re:Correct GNU/Hurd URL (Score:1)
Re:No point in mining the UNIX vein further (Score:1)
--Bogey
the difference that HURD brings (Score:1)
The Hurd itself is a system of servers that run on top of the GNU Mach microkernel to manage such things as file systems, network protocols, file access, and the other features that are usually managed by the monolithic Unix and Linux kernels.
The Hurd works in a very different way to Unix/Linux with one of its most important features being translators. These can be modified by the user (as can the whole system), and enable the user to not only seemlessly access files and devices but also networks, so that for instance remote file systems can be accessed, and files edited, with just one command, regardless of whether these files are on a local system, an ftp server or an Internet site.
If that's all.. would someone explain exactly what's so great about that? Am I to assume that Linux and other OSes require more information to be able to access files not on the local drive(s)/using the local filesystem?
I've never heard of HURD before.. so, I'm new to this.
GNU/HURD (Score:1)
GNU's not UNIX/HIRD of UNIX-Replacing Daemons
GNU's not UNIX's not UNIX/HURD of Interfaces Representing Depth of UNIX-Replacing Daemons
GNU's not UNIX's not UNIX's not UNIX/HIRD of UNIX-Replacing Daemons of Interfaces Representing Depth of UNIX-Replacing Daemons
GNU's not UNIX's not UNIX's not UNIX's not UNIX/HURD of Interfaces Representing Depth of UNIX-Replacing Daemons of Interfaces Representing Depth of UNIX-Replacing Daemons
GNU's not UNIX's not UNIX's not UNIX's not UNIX's not UNIX/HIRD of UNIX-Replacing Daemons of Interfaces Representing Depth of UNIX-Replacing Daemons of Interfaces Representing Depth of UNIX-Replacing Daemons
GNU's not UNIX's not UNIX's not UNIX's not UNIX's not UNIX's not UNIX/HURD of Interfaces Representing Depth of UNIX-Replacing Daemons of Interfaces Representing Depth of UNIX-Replacing Daemons of Interfaces Representing Depth of UNIX-Replacing Daemons
GNU's not UNIX's not UNIX's not UNIX's not UNIX's not UNIX's not UNIX's not UNIX/HIRD of UNIX-Replacing Daemons of Interfaces Representing Depth of UNIX-Replacing Daemons of Interfaces Representing Depth of UNIX-Replacing Daemons of Interfaces Representing Depth of UNIX-Replacing Daemons
GNU's not UNIX's not UNIX's not UNIX's not UNIX's not UNIX's not UNIX's not UNIX's not UNIX/HURD of Interfaces Representing Depth of UNIX-Replacing Daemons of Interfaces Representing Depth of UNIX-Replacing Daemons of Interfaces Representing Depth of UNIX-Replacing Daemons of Interfaces Representing Depth of UNIX-Replacing Daemons
GNU's not UNIX's not UNIX's not UNIX's not UNIX's not UNIX's not UNIX's not UNIX's not UNIX's not UNIX/HIRD of UNIX-Replacing Daemons of Interfaces Representing Depth of UNIX-Replacing Daemons of Interfaces Representing Depth of UNIX-Replacing Daemons of Interfaces Representing Depth of UNIX-Replacing Daemons of Interfaces Representing Depth of UNIX-Replacing Daemons
GNU's not UNIX's not UNIX's not UNIX's not UNIX's not UNIX's not UNIX's not UNIX's not UNIX's not UNIX's not UNIX/HURD of Interfaces Representing Depth of UNIX-Replacing Daemons of Interfaces Representing Depth of UNIX-Replacing Daemons of Interfaces Representing Depth of UNIX-Replacing Daemons of Interfaces Representing Depth of UNIX-Replacing Daemons of Interfaces Representing Depth of UNIX-Replacing Daemons
GNU's not UNIX's not UNIX's not UNIX's not UNIX's not UNIX's not UNIX's not UNIX's not UNIX's not UNIX's not UNIX's not UNIX/HIRD of UNIX-Replacing Daemons of Interfaces Representing Depth of UNIX-Replacing Daemons of Interfaces Representing Depth of UNIX-Replacing Daemons of Interfaces Representing Depth of UNIX-Replacing Daemons of Interfaces Representing Depth of UNIX-Replacing Daemons of Interfaces Representing Depth of UNIX-Replacing Daemons
GNU's not UNIX's not UNIX's not UNIX's not UNIX's not UNIX's not UNIX's not UNIX's not UNIX's not UNIX's not UNIX's not UNIX's not UNIX/HURD of Interfaces Representing Depth of UNIX-Replacing Daemons of Interfaces Representing Depth of UNIX-Replacing Daemons of Interfaces Representing Depth of UNIX-Replacing Daemons of Interfaces Representing Depth of UNIX-Replacing Daemons of Interfaces Representing Depth of UNIX-Replacing Daemons of Interfaces Representing Depth of UNIX-Replacing Daemons
GNU's not UNIX's not UNIX's not UNIX's not UNIX's not UNIX's not UNIX's not UNIX's not UNIX's not UNIX's not UNIX's not UNIX's not UNIX's not UNIX/HIRD of UNIX-Replacing Daemons of Interfaces Representing Depth of UNIX-Replacing Daemons of Interfaces Representing Depth of UNIX-Replacing Daemons of Interfaces Representing Depth of UNIX-Replacing Daemons of Interfaces Representing Depth of UNIX-Replacing Daemons of Interfaces Representing Depth of UNIX-Replacing Daemons of Interfaces Representing Depth of UNIX-Replacing Daemons
GNU's not UNIX's not UNIX's not UNIX's not UNIX's not UNIX's not UNIX's not UNIX's not UNIX's not UNIX's not UNIX's not UNIX's not UNIX's not UNIX's not UNIX/HURD of Interfaces Representing Depth of UNIX-Replacing Daemons of Interfaces Representing Depth of UNIX-Replacing Daemons of Interfaces Representing Depth of UNIX-Replacing Daemons of Interfaces Representing Depth of UNIX-Replacing Daemons of Interfaces Representing Depth of UNIX-Replacing Daemons of Interfaces Representing Depth of UNIX-Replacing Daemons of Interfaces Representing Depth of UNIX-Replacing Daemons
GNU's not UNIX's not UNIX's not UNIX's not UNIX's not UNIX's not UNIX's not UNIX's not UNIX's not UNIX's not UNIX's not UNIX's not UNIX's not UNIX's not UNIX's not UNIX/HIRD of UNIX-Replacing Daemons of Interfaces Representing Depth of UNIX-Replacing Daemons of Interfaces Representing Depth of UNIX-Replacing Daemons of Interfaces Representing Depth of UNIX-Replacing Daemons of Interfaces Representing Depth of UNIX-Replacing Daemons of Interfaces Representing Depth of UNIX-Replacing Daemons of Interfaces Representing Depth of UNIX-Replacing Daemons of Interfaces Representing Depth of UNIX-Replacing Daemons
GNU's not UNIX's not UNIX's not UNIX's not UNIX's not UNIX's not UNIX's not UNIX's not UNIX's not UNIX's not UNIX's not UNIX's not UNIX's not UNIX's not UNIX's not UNIX's not UNIX/HIRD of UNIX-Replacing Daemons of Interfaces Representing Depth of UNIX-Replacing Daemons of Interfaces Representing Depth of UNIX-Replacing Daemons of Interfaces Representing Depth of UNIX-Replacing Daemons of Interfaces Representing Depth of UNIX-Replacing Daemons of Interfaces Representing Depth of UNIX-Replacing Daemons of Interfaces Representing Depth of UNIX-Replacing Daemons of Interfaces Representing Depth of UNIX-Replacing Daemons
Re:Hurd operating system's market penetration (Score:1)
Why Install and Use Debian GNU/Hurd Now?
To support free software in general and the development of GNU/Hurd in particular. Even those who are neither developers nor computer programmers
can help the development of GNU/Hurd by using it, submitting bug-reports and trying out new packages when they are released.
GNU/Hurd has the potential to be the best computer Operating System in the world - better than GNU/Linux IMHO - and the more people who install
it, use it and aid its development, the sooner this will happen.
Easier Installation? (Score:1)
//qrash
Re:First %100 GPL'd system? (Score:1)
Re:I have a dream... (Score:1)
What would be the difference between his and yours?
A monopoly is a monopoly..
Re:I have a dream... (Score:1)
the little guy. Their software may be free, but that doesn't prevent them from trying to eliminate the competition. You don't want Linux to be the only OS in existance.
Nor do you want one of the BSDs to be the only one in existance.
Nor do you want Solaris, Be, HP-UX, VMS, OS/2, or Windows NT to be the only one in existance..
Instead of trying to replace each other, try to learn from each other.
Excellent Job (Score:1)
Re:No point in mining the UNIX vein further (Score:1)
However, there are a lot of problem with monolithic systems, which most Unices, and Linux, are: for one thing, they scale very badly to SMP, since each processor must run it's own OS. Running a microkernel is much lighter, and the server processes could just use whatever processor is available.
Another thing is that as module as linux tries, and largely succeeds in being, it is still hard to debug, and replace parts. It is doubly true on a true multi-user system, where you have to be root to do anything at all, so normal users can't do anything. Just consider: why do I need root to make ftp.gnu.org seem like a local fs to me?
So Hurd has a lot of potential. And besides, it's always fun to work on an OS which isn't working...
In the words of someone we all admire:
``When men were men, and wrote their own device drivers''.
(And of course, Linux and Hurd aren't competitors in the same way, say, Netscape and MS are (or were): the Hurd team freely copies code from Linux when it helps, and I do hope that one day Linus will "cut costs" by copying from Hurd. This is the essence of free software, and this is why free software will win)
Re:Can someone explain the trouble with debugging? (Score:1)
Hurd advanced enough to ship? (Score:1)
First %100 GPL'd system? (Score:1)
Could this be the first time a computer maker distributes a machine with %100 GPL'd software?
Is it usable? (Score:1)
Could I use HURD with my current hardware (Intex duel Celeron) and video card (Voodoo 3), without having to write my own drivers? Is it stable? Does the kernel panic constantly? It is a microkernel, so many parts of the core OS can crash, and the system will still be running, but will init be dying on me?
So, in short, to all you 'pure' GNU users out there, how reliable is it? Last time I checked (Which, I admit was a long time ago) there were many unwritten drivers, and massive amounts of work that would be needed in order to bring it to the level that linux is now (with reliability). Has this changed? It would be great to have an Microkernel OS, and that was one of the things that turned me onto GNU in the first place. Could anyone with experiance update us on the present state of the kernel please?
Waiting for a cooler kernel
-mafried
http://www.slashdot.org/software/hurd/hurd.html (Score:1)
... first post?
Re:Open Source the SlashCode v0.4 Now! (Score:1)
So, the more you flame them, the more they will simply ignore you. Not only that, but they're delaying the source release for all of us who have enough respect to not pester them. So, please, give them the time they need.
Unless, of course, you're some sort of anti-Slashdot agent, and simply want the code release pushed back.
meisenst
Re:Hurd advanced enough to ship? (Score:1)
Timing of HURD (Score:1)
At the very beginning of Linux everybody was just waiting for HURD to be complete and it was supposed to be available very soon.
I was looking at a copy of the discussion between Torvalds and Tanaenbaum and everybody was just saying that HURD is going to come out soon and this is just to tide over (but they were also saying that DOS and Intel are inferior and not going to take off).
" The precursor of DOS was FDOS (Fast and Dirty Operating System).
Microsoft dropped the F and guess what was left? "
well this WAS supposed to be a gnu/hurd thread (Score:1)
i dont know why
Re:GNU/HURD (Score:1)
Re:HEE (Score:1)
(im sorry, i couldnt help myself - but at least its kinda on-topic)
Re:Multi-cpu support (Score:1)
Re:Hell! (Score:1)
No, I know Windows has a kernel: it has had one since 2.x (aka Windows/286 and Windows/386).
The dos kernel is io.sys (all interrupts are serviced from there for machine-language programs wanting to modify files, etc, the usual stuff a small kernel provides.)
Windows has... krnl386.exe, which runs the GDI and provides other services such as basic window manipulation, etc. The main WM stuff is in another file (yes, it seriously is a WM, because I killed the WM using WinTop or something and I didn't have any titlebars).
I think it's probably a microkernel then, but not with servers... the DLLs don't provide services themselves, i think, but simply allow other programs to call them and use their features as though they were part of the program (Dynamic Link Library == dll).
Not sure about DirectX yet.
Re:Multi-cpu support (Score:1)
one processor beats the other and says, "Do my work, you CISC bitch! Render that fscking image!"
i guess this is off topic, but it's funny
Monolithic vs Micro Kernels: Windows? (Score:1)
It does have drivers that are similar to Linux's modules, but I don't know if they're dynamicaly linked into the kernel or if they run as servers.
Does anybody have any info on this? How about DirectX? Because dir/s runs as fast on my Windows system as on Linux (on another, almost equally filled Linux partition).
Versions:
Windows 98 SE (with no stupid Windows Update patches)
Debian GNU/Linux (or Debian/GNU Linux if you prefer) potato, latest with apt-get (i do it everyday) and kernel 2.2.13
4 gb for each, roughly 40% full on both sides.
Re:Monolithic vs Micro Kernels: Windows? (Score:1)
HURD: The final piece of the puzzle? (Score:1)
I can see HURD be used in larger server workstation with slower adaptation to new hardwares and devices. Whereas Linux, on the other hand, will continue to thrive on smaller systems and desktops. This should be a win-win for everybody. Cheers!
Re:What is reiserfs exactly anyway? (Score:1)
Hurd operating system's market penetration (Score:1)
Has anyone seen someone who purely uses Hurd as an operating system, or can say that they find Hurd more useful than linux or Solaris for anything? I think installing operating systems just to add another operating system is kind of silly. I like some of the technology Hurd brings (object-oriented source, distributed computing, etc.), but why fragment the market further when there are operating systems out there with new when operating systems when others have significantly larger market presence and real utility.
I guess it's good that they are shipping it with linux as well. Kind of makes you wonder why they are even shipping Hurd anyway. Methinks it's just to be (one of?) the first computer company out there to try to market it.
Re:Is it usable? (Score:1)
Re:Is it usable? (Score:1)
Re:Diversity at the expense of timeliness? (Score:1)
Re:the difference that HURD brings (Score:2)
Of course, the ideal thing would be to figure out how to make IPC and context switches 'free' (i.e. very low cost as far as CPU time go), probably at the memory management and processor level. If you could cache say, three process structures in backup registers on a chip, you could potentially get something like a microkernel for no added cost CPU-time wise. That and the fast context switching of Sun's MAJC chip would probably completely change computer OS design.
Of course, after you do that, you are pretty close to just building memory management and task switching directly into the CPU - you are one step away from not needing an OS at all
Re:the difference that HURD brings (Score:2)
If you could cache say, three process structures in backup registers on a chip, you could potentially get something like a microkernel for no added cost CPU-time wise.
Oddly enough, the old Z80 had two sets of general purpose registers which could be swapped with a single instruction. Something like that ported forward into a modern CPU, and extended to include TLB and segment registers, etc could be the answer. Of course, that's easy to say and I'm not a CPU archetect.
Re:Hurd operating system's market penetration (Score:2)
Kind of makes you wonder why they are even shipping Hurd anyway.
It does seem to be a bit early to do HURD pre-installs. I suspect they are desperatly reaching for anything that will differentiate their product from the many others. If they really want to do that with HURD though, they need to wait, or hire some programmers.
On the other hand, it looks like it is just a matter of time (as in finding some) before I end up with a HURD system. It has some intrigueing features.
Diversity at the expense of timeliness? (Score:2)
It is their distro and they can do as they like, but as a longtime Debian user (and hence "debugger") I wonder if diversifying their distribution like this wasn't putting the cart before the horse. Potato (the 2.2.x based release) will likely come out about the same time as the 2.4.x kernel, and I fear it will be another year before Woody (presumably 2.4.x based) will be released, about the time 2.6.x or even 2.8.x comes out.
Don't get me wrong, I like the long-term direction of having similar releases of dissimilar Open Source/Free OSes. I just wish the issue of timely releases had been adequately dealt with first, before so much effort was divided in so many directions.
Re: (Score:2)
Monolithic kernels vs. microkernels (Score:2)
Linus Torvalds that touches on the monolithic/microkernel issue:
The Linux Edge - Linus Torvalds [oreilly.com]
This is also a good place to find a copy of the
famous argument Linus had on the subject with
the author of Minix:
Appendix A: The Tanenbaum-Torvalds Debate [oreilly.com]
Re:the difference that HURD brings (Score:2)
While Linux provides for kernel modules, the implementation of them are not as nice and general as the implementation of servers.
Each server may run in its own memory space (Is this the case with Hurd?), providing for security (A crashing video driver won't crash the harddrive driver). Linux kernel modules, however are linked into the kernel, just as any dynamic library is loaded into an ordinary program.
In addition to this, a micro kernel design provides a lot more flexibility for future extensions.
In a
Multi-cpu support (Score:2)
The Hurd implementation is aggressively multithreaded so that it runs efficiently on both single processors and symmetric multiprocessors. The Hurd interfaces are designed to allow transparent network clusters (collectives), although this feature has not yet been implemented
Re:Is it usable? (Score:2)
It seems stable, albeit slow, and there isn't much hardware support. Or software support. And those translator thingies, hmmmm. But hey, it's cool to play with.
Re:Monolithic kernels vs. microkernels (Score:2)
But I do not think that Hurd is *just* a microkernal. The ability to modify the kernal without rebooting and by unprivilaged users is unique to the Hurd. As is translators and a whole host of other features that even other microkernal-based system cannot do. Other microkernal systems are NT and BeOS, I think. Note that BeOS supposedly has great performance so it is feasable that the Hurd's performance can be improved as well.
unstable out of dateness (Score:2)
If you ever spot an out-of-date package in Debian unstable, please file a wishlist bug against the package. Instructions on how to submit a bug are outlined here [debian.org].
In fact, please do it ASAP, because potato is freezing in a week.
Re:Monolithic vs Micro Kernels: Windows? (Score:2)
> Unless HURD does things that other OS's cannot do.
Well, of course, anything that any OS can do, a Turing machine can do. So it's more a question of relative ease.
If we imagine the Hurd as more or less finish, it can do all the things that Linux does, perhaps slower (though it is hard to predict by how much), especially on single-processor systems. But here is a concrete use that the Hurd might have which would not work on Linux: it would make it possible to sell computing power on a machine (for example to put a web server on it), including root access (something which is often desirable), to several different clients without any interaction between them, and without compromising the system security. Because Hurd can be virtualized. This is an example something which could provide motivation to get the Hurd working.
Re:Monolithic kernels vs. microkernels (Score:2)
Good point. Moreover, as I pointed out, the monolithic kernel vs microkernel debate is exactly a library vs client/server system, at a sufficiently abstract level.
Clearly there is nothing you can do with a library that you can't do with a client/server system. But in fact, the converse is also mostly true. It would be quite possible, IMHO, to have the Hurd features on a monolithic kernel system: essentially, the monolithic kernel provides the capacity-based security model, and the filesystems are integrated in a set of dynamic libraries rather than in a set of servers. This requires the concept of setuid (or rather, ``acquire capability'') libraries, but there is nothing fundamentally impossible with this.
So, the microkernel issue should not be judged as providing the Hurd functionality but rather, on its own grounds (replacing a library-alike calling system by a client/server model). I am not competent to judge in this matter, but one thing is certain, namely that the entire issue is not completely clear-cut. The official ``Tunes'' rant [tunes.org] on the microkernel issue might not be completely wrong (despite the author's numerous deliberately provotating statements).
Re:Can someone explain the trouble with debugging? (Score:2)
I'd say the debugging is easier, except that what you're trying to debug is much more complex, so that as a whole the whole debugging process is more difficult. Essentially, because the Hurd servers are heavily multithreaded programs that pass messages to each others in all sorts of ways. That is always hard to debug, even in user space.
I don't think this is really the reason why the Hurd has progressed so slowly, though, no matter what Stallman may say. Or at least, there are other factors in play.
I have a dream... (Score:2)
I have a dream... that all computers will not be judged by the clock speed of thier processors, but by the file system of thier hard drive.
I have a dream today....
I have a dream... that when a brand new video card comes out, I will have a linux driver and an X-server all ready install... out of the BOX!
I have a dream... that people will figure out that it doesn't matter what distrobution of linux you are running... Kernel 2.2.14 is Kernel 2.2.14! It doesn't matter what color packaging the box comes in.
I have a dream today...
Re:I have a dream... (Score:2)
...that when a brand new video card comes out, I will have a linux driver and an X-server all ready to install... out of the BOX!
Re:I have a dream... (Score:2)
Re:I have a dream... (Score:2)
Re:I have a dream... (Score:2)
Re:First %100 GPL'd system? (Score:2)
-----------
"You can't shake the Devil's hand and say you're only kidding."
Re:the difference that HURD brings (Score:2)
It's conceptually pretty which makes the Computer Scientist in all of us smile..
Seriously, there are a lot of advantages to microkernel's because you solve the problems in a more generic way. Example: any good microkernel inherently supports all the real-time stuff you would need because that is how it's device drivers work (Mach did not do this in the past.. i donno about now) and there are commercial microkernels which work quite well on this philosophy. This means that when your video driver crashes it dose not crash your system. It also make it much easier to write OS emulation software.
It is also nice that unprivliged users can do all sorts of cool things like create there own file system or user privlage tracking system without creating a security hole. This security system is one of the more revolutionary parts of the Hurd as I understand it. Example: you can add and remove privliges from a running process under the Hurd.
There are advantages and disadvantage and it is generally agreed that the advantages will eventually out weight the disadvantages AND the cost of porting all the software.. the question is when.. sorta like cleaning up your room..
Jeff
Re:No point in mining the UNIX vein further (Score:2)
Linux is a lifeline into almost thirty years of UNIX tool development. This is a wonderful thing for developers, because we don't have to keep re-learning a new set of tools every few years. But that doesn't mean that Linux is the ultimate operating system outside of that context. That's something that Linux advocates often forget.
Oh really... ok here's some more for you. (Score:2)
I have a dream that computer components would be completely 100% backwards compatable and allow me to just take a PIII or something like an Anthalon and just stick it into my 486's motherboard and get it to run. I would like to have a working copy of various GNOME applications that will always work fast and be scable to the processor and memory requirements of a machine. I have a dream that all packages will be allowed for a distribution and that no matter what I install I can upgrade and remove it seamlessly without complaint. I have a dream that all the really interesting developments in computers would not be just for the very elite people in the world and make them more approachable. I have a dream that uncertainty would be removed in the field of technology so that I can be guaranteed at least a decent source of employment. I have a dream that there would be more games that would be scalable and easier to run on crappy machines and not necessitate purtchess of expensive stuff that will be gone shortly.
I have a dream that all kinds of access would be possible for the internet and that truely free internet access would actually work work for linux like it does already for windows and the Mac. I dream of all these things without a heed for their lack of possibility and those of the world call me a Quixotean fool for what ammounts to impossibility in terms of actually advancing civilization. We al dream for these things but they never come true. We all search for things that are not there and we try to believe. What is it that we really want? I want a computer that has all of my interests in heart. But the bastard machines have betrayed me at every turn! Ahhh the humanity of it all! What do I actually care if some person dosn't hae the grapes to actually just get a video card that is a little less powerful or a processor that is in fact a little slower than the absolte best? Does it really affect me? Does the universe cease to turn and does the su n then burn out? Do I suddently become fated to have my life
eclipsed by the shadow of Zuses's wrath? I propose not really.
Linux does a better job of my needs but why the bloat to the total operating system in the array of implimentations of such things as grahics? Why do simple dos games that ran quite well on 286s (Wolfenstein) and such still preform slugglishly on higher end 486 machines? Why the obcession with pretty pictures and the like? Why do we need to observer all that is there without regard to content or use?
Yes we dream of things but will they come true for you or I or any of the people on this spinning blue sphere in any fashion at all? I think not.
What is reiserfs exactly anyway? (Score:2)
I think in this weary world we have clock speed does matter. I should think quite a great deal. Why then do we have overclocking at all in the first place.
Monolithic kernel vs. Microkernel. (Score:2)
Critical timing. (Score:2)
Assembly can do things quite quickly however it is not very easy (not impossibly mind you just takes a lot longer).
That is basically what is happening here; because you are not executing snippets of the code you are executing programs that will interact with another kernel. Because of this you could have for instince say have a problem in playing quake or such when you need to do something like write temp data to the hd or something that it would force something else (maybe the keyboard to take a less active role or maybe the mouse) then boom someyone kills you with the BFG10k or something.
Yes X does this already but some of that is changing look at the frambuffer in the 2.1 and 2.2 kernels.
Can someone explain the trouble with debugging? (Score:3)
Except that it isn't. Not according to Stallman and the HURD developers, anyway. The received wisdom, confirmed by RMS and others, is that one of the things that allowed Linux to streak ahead of the HURD in completeness and useability was the relative ease of debugging on a monolithic kernel, compared to the microkernel.
Clearly, I'm not getting something important: can someone lay it out for me? I'd be dead grateful...
--
Correct GNU/Hurd URL (Score:3)
Re:Hurd status (Score:3)
This is due to the way the communication works. On a monolithic kernel, when a process needs, say, to perform a filesystem read, it will invoke a processor trap to go in kernel mode (protection level 0), then perform the task as a privileged task (from the processor's point of view). The overhead is just a trap call, which is comparatively low: even the branch prediction mechanisms are not invalidated by this. On a microkernel, on the other hand, the process needs to send a message to the server task. Essentially, things proceed thus: the client task writes the message to a memory page, then goes in kernel mode to ``send'' the message to the server task (all that is just as fast as for a monolithic kernel); then it starts waiting for the reply. But that means it is unscheduled and another task (presumably the server task) is scheduled in its stead. The reschedule may be slow, since it involves replacing all the registers, but that is not the worst part. The worst part is that the paging register is changed (the virtual memory layout is unique to each task, so a task change must change the paging register, CR3 on an Intel), and that means that the TLB (``Translation Lookaside Buffer'', the cache for the paging mechanism) gets flushed. This is why processes are so much more costly than threads (which share the same address space), and this is why RPC calls are so costly. There are two context switches (TLB flushes) for each single message sent from the client to the server (plus, possibly, its reply).
At a sufficiently abstract level, a monolithic kernel is nothing else but an I/O access library which is shared by every process and which enjoys certain specific rights. In a way, every process ``carries its own copy of the kernel'' with it. On the other hand, for a microkernel, the ``library'' approach is replaced by a ``client/server'' approach.
There are possible ways around the problem. A microkernel architecture like QNX uses a single address space. Since user tasks operate at the same privilege level, they are not protected the ones from the others. It may be possible to put the device drivers at ring 1 (between the kernel at ring 0 and the user processes at ring 3), I think NT does this; but this contradicts the basic principles of symmetry which the Hurd tries to enforce. Segmentation might also help things, but it is hard to work with. Or, simply, more modern processor architectures might not enforce a TLB flush with each change of address space, but simply mark TLB entries with the address space with which they are associated (or some such thing), or some such thing. I think the Alpha does something of the kind.
On a SMP machine, the cost of an RPC call is not nearly so high: imagine the client task is running on processor A while processor B is idle; when the request is sent, processor B immediately starts executing the server task, and when the client task starts waiting, it is not replaced by another task because no other task is waiting, processor A just waits until processor B finishes execution, so no context switch occurs on either processor if the scheduler is good enough. Essentially, we have not used two processors, but merely the fact that two processors have two TLB's.
It may also be possible to group requests as much as possible before unscheduling the client. But that is rather hard to do. This is what the Xlib does for the X protocol, but I do not see how the libc (which is the analog of the Xlib for the Hurd protocol) could do the same, considering the semantics it has to obey (notably that each call must return an error code).
what GNU/HURD is (Score:3)
However, I have never tried HURD myself, probably will never even do so unless their development kicks into action quickly like Linux has so they can survive, so I cannot verify anything. All that I know is probably just what I've read in the various FAQ's and on
No point in mining the UNIX vein further (Score:3)
It is more stable than other easily available options like Windows 98/NT.
It provides access to, and a healthy environment for, a large pool of standard tools: gcc, Perl, Python, awk, Emacs, etc.
The first is what we usually hear about, but the second item is just as important. If you were using UNIX on the job or at school in 1988, then you'll be pretty much at home in 2000, because everything is generall the same. I used UNIX on a Sun workstation for software development in 1991, and all of that experience carried over when I started using Linux at home and at work in 1999. Nothing much has changed. It's good to be able to keep that knowledge over a long period of time and not have to relearn in every few years.
In that light, the line between Linux and the Hurd is pretty irrelvant. We already have a working key that lets us access the tools we want, so it doesn't matter what kernel is beneath them. There's no reason to run over to or even follow the development of the Hurd.
That's not to say that Linux is the ultimate OS, because it isn't. It's a total piece of junk in many ways, but that's what you expect with UNIX, and that's where Linux descended from. There are great opportunities for operating systems with much different philsophies. Look at the OS in the Palm, for example. It's not an OS in the geeky computer user sense, but it does exactly what it needs to do, is extraordinarily useful, and people like it. Hurd is too close to the UNIX/Linux style for anyone to care.
Microkernel does not have to be slow. (Score:4)
Hurd status (Score:5)
Since a few people seem to be interested, I will recapitulate the overall HURD status, from my personal experience and my reading of the debian-hurd and bug-hurd mailing lists.
First, is it usable? Well, it depends for what. It is still quite unstable. Filesystems are under active development, but there are still some problems with them (the ``native'' Hurd filesystem, if that means anything, is ext2 just like Linux, but the ext2 demon still has problems, one of them being that sometimes entire file blocks are replaced by zeroes — this will be fixed soon). The TCP/IP stack is a copy of that of Linux (but the Hurd maintainers are having trouble keeping up with the changes made to the Linux networking code). The security mechanisms are extremely flexible but that sometimes causes problems (for example, the Hurd has one more set of file permissions besides user, group and other permissions, the ``not-logged-in'' permissions, and no tools yet exist that will allow to manipulate these permissions). There are also some strange limitations: for example, Hurd will not work on a partition of more than 1Gb, and it crashes rapidly if not given a swap partition.
X Windows will work with a set of patches. Some other programs cause problems, and sometimes it's the program's fault (because it makes assumptions about the Unix-like nature of the system which are not verified under the Hurd).
On the other hand, the Hurd is stable enough to bootstrap itself (compiler, microkernel, libraries, demons) and perform tasks that do not have stringent hardware requirements.
The Hurd shares the same libc as Linux (the GNU libc, currently version 2.1.2). So eventually it should be binary compatible with Linux (right now it is not, but there is no severe problem with that, it is only a matter of time). This is one of the great hopes of Hurd, the possibility of making the transition completely smooth.
The slowness of the progress on the Hurd is due to nobody working on it full time. Some very competent programmers are devoting a lot of time to it (Thomas Bushnell, Brent Fulgham, Roland McGrath, Marcus Brinkmann and certainly a few I'm forgetting), but they are overwhelmed by the immensity of the task.
In theory, though, the Hurd should be easier to develop than Linux, because it is more inherently modular, and because of the fantastic possibilities of gdb under the Hurd. Also, you do not need to reboot to test changes to the ``kernel'', and you can debug a live kernel without problem; plus, you can test some experimental features without endangering the base system. So, there is no reason that Hurd can't become very solid and stable — quite the contrary in fact. But they just need more volunteers. And the FSF unfortunately cannot affort to hire someone on it full time (say, why not write a check to the FSF specifying that you would like to see it employed for Hurd development?).
On the other hand, in the domain of performance, it is probable that a microkernel architecture can never be at par with a monolithic kernel, at least on single-processor machines. For the moment, the Hurd is horribly slow with filesystems (rm -rf is just a nightmare), but this is mostly because it is completely unoptimized. Still, even when it is, it will probably remain noticeably slower than Linux. It has been claimed, however, that the difference may be significantly less than expected; but it is yet too early to see.
The main advantage of the Hurd is its flexibility. User-land filesystems are part of that. In fact, you do not even need to be root to write a filesystem. (That is one of the things which angers me the most about Linux, the need to be root to mount a simple loopback file.) The Hurd is completely virtualizable, whereas Unix hardly is (well, there is a ``user-mode Linux'', but it is even more experimental than the Hurd), so any user can set up her own virtual sub-hurd with its own set of users, permissions and so on. The security system is soooo flexible: much better than access control lists, it uses capabilities (àla Eros [eros-os.org]) in the form of Mach ports. If this were made practical, this would be a huge gain on the security side, because you would practically never need to be root for anything, just introduce the ad hoc capabilities and permissions. And the virtualization possibilities let you surround dangerous demons by ``sanitary cords'', making the system much harder to break into. So, theoretically, the Hurd can be a very secure system. Finally, the whole translator system can be used in yet unthought-of ways to provide wondrous communication mechanisms between programs.
However, the real question now is whether binary compatibility with Linux plus the great extra features and flexibility can be sufficient motivation for people to move to the Hurd when it is more stable, and, in the mean time, for more developpers to draw their attention to it. The lack of hardware support, on the other hand, is not a big problem: Roland McGrath has an experimental project for making the Mach microkernel run with the Flux OSKit, so that all the Linux hardware support would immediately benefit the Hurd.