Slashdot Mirror
New GNU Hurd Kernel Released
Anonymous Coward writes "I don't know if there is much interest out there, but GNU Mach Kernel 1.3 was just released a couple days ago. (May 28)." Looking forward to that 2002 release...
← Back to Stories (view on slashdot.org)
> When Debian ports it, i'll try it out.
It's work in progress, and already usable. See http://www.debian.org/ports/hurd/ for installation instructions.
By the way, Mach isn't "the hurd kernel", as Michael implies. The Hurd is userspace servers - therefore then name "Hird of Unix-replacing _Daemons_".
Go to kt.zork.net and follow the updates on building a Hurd version of Debian... I believe there's been stuff on there about ISOs.
I find it amazing that Hurd still isn't even close to being ready for production use after 10+ years of development! Even in the current release, there are a *lot* of features missing, incomplete, or just plain don't work. No character device suport, no shared memory, no dynamic library support, etc. Hurd is still very much incomplete, even now.
-- Ed Carp, N7EKG erc@pobox.com PGP KeyID: 0x0BD32C9B What I'm up to: http://intuitives.mine.nu
Nope. X11 works with my Nvidia GeForce2MX, but OpenGL is still software Mesa only as there is no DRI support for GnuMach and no third party Xservers AFAIK.
But X does work, so it isn't just text. It has X11R6 v 4.2 I believe.
Clickety Click
The site www.stallman.org is running Apache/1.3.6 (Unix) on FreeBSD.
Netcraft check of www.stallman.org
Anyone willing to try out the Hurd can download some .ISO's at ftp://ftp.gnu.org/iso/hurd-H4/. They're based on Debian, and so apt-get and all that works in them.
As mentioned before, this version of Mach is about to be dropped in favor of OSKit-Mach. I don't know what the H4 CD's have (I haven't installed 'em yet) but the H3's didn't use OSKit-Mach. OSKit Mach has all the drivers that Linux 2.2 has, which is better than Mach 1.3, which iirc only has Linux 2.0's drivers.
In my brief experience with the HURD (you can only have so much fun without network card drivers) I liked it even more than Linux - using servers instead of using the kernel itself makes it more logical to, say, integrate an FTP directory into your filesystem (and indeed, this server has already been set up). settrans is lots of fun.
It's got X. It has pretty much everything you need - I could convert to the Hurd and barely lose productivity. What it's missing mostly are drivers (though OSKit should help with that, I haven't tried it).
Anyway, if you have a weekend to kill, it's a lot of fun.
Firewire and USB work perfectly on my BSD system. Its called MacOS X.
Strange women lying in ponds distributing swords is no basis for a system of government.
You obviously don't know much about the architecture of the Hurd. Go read up on it (http://hurd.gnu.org/) and come back.
/etc/fstab, which he/she probably won't want to do), even if the encrypted file is owned by you, in your own directory and you want to mount it within your own home directory. This is something that the architecture prevents you from doing, so no UNIX implementation will ever let you do that (without a heavy dose of magic). Allowing stuff like that is one of the architectural features of the Hurd.
The architecture of the Hurd (not to be confused with the implementation) gives users a lot more freedom than any UNIX-based system. For example, UNIX will not let you mount a loopback encrypted filesystem unless you are root (or without bugging root to frob
Porting, and supporting 56k modems are just implementation details, and have nothing to do with the architecture, which is what RMS is talking about.
To get something done, a committee should consist of no more than three persons, two of them absent.
The latest "Hazelnut" L4 kernel (written in C++) finally passed the fastest L4 x86 assembly kernel for interprocess communication performance. This is very important for microkernel performance, since many things traditionally handled by system calls (setting some registers then trapping an interupt in the kernel) are instead handled via IPC with user-space drivers. I'd like to point out that without some crazy high-level macros in your compiler, it still seems like you need a minimum of about 32k of your ring 0 code is written in assembly (on x86) to properly manipulate the hardware. (You could come up with some funky architecture where not all of your ring 0 code is in what you call the kernel. Doesn't NT/2K/XP have some non-bootstrapping ring 0 code outside of kernel32.dll?) (This is from what I remember of L4 and QNX documentation.)
Have no fear, the X.2 API is bein sorted out. People are holding off on porting the HURD to L4 until the L4 X.2 API is finalized. My guess is that porting will begin this Summer.
Copyright Violation:"theft, piracy"::Anti-Trust Violation:"thermonuclear price terrorism"<-Overly dramatic language.
No, it's the bit he didn't do soon enough, because his focus was putting together a widely portable operating system, mainly focusing on tools, that could (and did and still does) run on a variety of kernels, most of which were (at the time), sadly, proprietary.
Another way to view it: from RMS' point of view circa 1989, a "free" kernel was a lot like a "free" device driver, only bigger and more complicated, in that it enabled use of free software on certain hardware (CPUs). Compare that to writing more free OS utilities, which would be portable to all hardware that could support GNU software (regardless of kernel), and you can see why he might have made the choices he did at the time.
Now, did Hurd, once he focused GNU resources on creating it, prove to be an overly ambitious ivory-tower-type project? IMO, yes. In the meantime, Linus and others scratched an itch by evolving (moreso than designing a la Hurd) a kernel for a specific CPU family, which meant that the resources GNU might have used for such a project were used for other, more portable or widely useful, GNU tools -- or, at least, that was a plausible likelihood.
How do I know all this?
Because, in 1988 or 1989, I volunteered my "talents" to RMS for GNU, and specifically asked him if he wanted me to take over the job of writing the OS kernel for GNU, something that was dead-center down my area of expertise. (I'd been doing OS kernel and related work since, oh, about 16 years of age, in a professional sense anyway; since earlier as an "amateur hacker".)
He declined the offer and asked me if I knew anything about Fortran. Since I'd recently learned some things about compilers, specifically Fortran compilers, I said yes, and the upshot was that I wrote GNU Fortran (g77).
RMS's main point at the time was that he believed he'd be able to get some existing portable kernel "freed" for use with GNU, so why throw sparse resources trying to create a free copy out of whole cloth?
Now, you can argue that he should have had me write the kernel instead, and, personally, I would have loved doing that, especially since I'd have been an actual end user of the product (compared to g77, which I don't use). I wouldn't have been nearly as successful at Torvalds when it came to project management though, as can be easily verified from studying g77's history. But my kernel wouldn't have been the ivory-tower-style Hurd, either, and I probably knew more about OS kernel design and implementation as of 1988 than did Linus as of 1991, if technical competency is an important issue. (Not so much a boast as a natural result of having been born so much earlier that I'd had about a two-decade head-start getting into kernel development.)
But, had I undertaken that task, what role might Linus and the others have played? Would they have written g77? I don't think so. They might have scratched some other itch, of course, but, in the end, I think the results are better the way they actually worked out than if I'd been the author of the GNU kernel.
As to your other claims: I agree with most of them, except you do seem to be unaware of the fact that, unlike with Apache, KDE, even BSD components, there is, today, no such thing as a GNU-free Linux kernel, given the kernel's (IMO overly-aggressive) dependency on GNU-specific extensions to the C language.
Linux developed, and remains, much more like a potted plant with GNU as its soil than like a mere partner that happens to use GNU.
Indeed, without that plant, few people would be interested in the "special" soil that is GNU. It's the plant that makes the whole thing worth having, to most people anyway. But GNU soil had been, and continues to be, widely and portably used without a shred of Linux code involved, whereas there is no Linux system without GNU.
(I use "Linux system" to mean a Linux kernel running an OS that provides the means to change the kernel code and recompile the kernel, since that's an important aspect of what makes Linux special. I assume the Linux kernel itself can boot up and run on a given CPU with no GNU code present, but it can't, or at least couldn't, be compiled in the first place without GNU C.)
And, in case anybody's wondering, if it's simply a "small matter of programming" (aka SMOP) to replace the GNU components with some other, thus "demonstrating" that GNU/Linux is really just Linux with a lot of other stuff including GNU, then, by all means, try it.
But, also for the record, there has been, to my knowledge, no shortage of technically competent people who have declared publically that they will write a replacement for GCC that isn't a) GPL-licensed (say, public domain instead) and b) considered a GNU project.
These "threats", as some might view them, go back to maybe 1992 or so -- well before the "GNU/Linux", or "lignux", debacle started by RMS -- yet, last I knew, nobody had actually converted their anger at RMS, the GPL, the GNU project, whatever, into actual code that provides a usable GNU-free Linux.
If and when somebody does write a useful replacement for GNU (for licensing and/or political reasons), that'll be all the more reason to distinguish their Linux variant from the current one, which I have already gotten into the habit of calling GNU/Linux partly in breathless anticipation of that long-awaited event!
Practice random senselessness and act kind of beautiful.
It's still nominally a microkernel, but large chunks of the graphics subsystem (for example) violate pure microkernel design principles, which is why NT 4 was faster that 3.51 but less stable (since video drivers could now torch your system).
Seems to me the opposite would be true for embedded systems - all the benefits of microkernels I can think of tend toward more fully featured systems; for example in the NT world, the OS/2 1.x and POSIX subsystems were seperate personalities on the microkernel. Those are neat features when you want to run diverse userlands on a common platform, but it seems like overkill for an embedded system, where the overhead of the microkernel in terms of size and performance may be too high a price.
As for security, I'm not sure how a microkernel would be a plus or a minus. I suppose the fact that splitting various components of the OS into personalities makes it (in theory) harder to subvert all components by subverting one component.
To be honest, what I'm curious to see is an mk based OS that actually meaningfully demonstrates the benefits of being based around a microkernal. NT could have if MS had been more committed to running the alternate personalities on the same microkernel, but their efforts at POSIX/Unix personalities running alongside the Win32 system have always been sporadic. Too many of the other benefits (such as not having your system die when a network driver goes tits up) mostly benefit programmers (after all, if the NIC in my file server keeps crashing, it's nice that I don't have to reboot to restart the NIC, but I still have an unavailable system).
It seems some people thought I was a troll and modded down my original post, while leaving your written diarrhea un-moderated, so I feel obliged to respond. Normally, I don't give you ACs a chance to say "YHBT", but I'll make an exception for Your Emminence.
OS X is indeed based on a mach microkernel. Not the GNU Mach microkernel, but a mach microkernel derivative (Mach was more-or-less a "proof-of-concept" of the microkernel idea written at CMU and GNU mach was written 'cause the MIT boys decided to have a pissing contest with the CMU boys). Have you ever used OS X? No? Well, then perhaps you'll see this when you do in fact use OS X for the first time:
Granted, 2.7 megabytes isn't very "micro" but a microkernel has nothing to do with the size of the kernel binary, and everything to do with the ways the kernel components communicate with each other.
OS X is a port of some of the FreeBSD userland into Apple's mach-based environment. I don't know if they used any of the FreeBSD kernel code, but most everything in the userland (that is, the userland I care about which is the Unix subsystem) is a straight port of the FreeBSD stuff. Even the manpages still have the FreeBSD emblems on them.
So, yes, it is in fact possible to write a successful microkernel-based system. NT is (or, at least, the NT kernel ideas were) microkernel-based, and Apple's OS X is microkernel based. If you think you can simply port over a FreeBSD driver to OS X, you're sorely mistaken.