Philip Charles has announced the availability of the K7 series of Debian GNU/Hurd CDs. He says: “The main feature of the K7 set is its quality. I would say it is the best set to date. IMHO, this set could be used to promote GNU“. This version features XFree86-4.3 for the first time, resulting in greatly improved X11 support. It is also the first version featuring the hurd package itself built against a recent glibc (current Debian unstable).
Hurd: K7 Debian CDs Available
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
The upload will be complete in about three days. I have a 15 KB/sec connection.
Know it does since some of us have 10 mbit line @home, but been there…
is it only one person who develops this?
most time these guys have some friends an Universities or debian
isn’t HURD development at a stand still as the migrate it onto a different micro-kernel?
how many people work on the kernel anyway? is there really any hope for th HURD to be completed within the bnexy two years?
Congrats. I am looking forward to continued developments.
HURD is not the kernel. HURD is a number of servers running atop of the Mach kernel.
“The kernel is GNU Mach not the Hurd. The Hurd is a series of servers which run on top of the microkernel, GNU Mach.”
Taken from http://www.debian.org/ports/hurd/hurd-cd .
I’m not sure that we’ll see a useful release in the near future. Few developers, constant bickering over which microkernel to use, and the fact that “GNU” is not developed as a single system as are the BSDs.
Sure, GNU Mach has some severe limitatitions, but delaying the release of a working GNU system because some of them now want to port the Hurd over to another microkerenel which does not support all of the functionality that the Hurd expects is madness.
Seriously, if they really want this thing to be a success sans a Linux kernel, they should just concentrate on fixing both GNU Mach (and no, not that OSKit monstrosity that is GNU Mach 2.0) and the Hurd, and worry about porting the Hurd to other microkernels much later, if ever.
Whatever, that’s just my opinion. Anyone else who wants a usable modern, threaded, message-passing UNIX-like operating system is free to use DragonFly BSD, which already is usable, and in no more than a year when all of the major VFS work has been done, will be far more stable, scalable and capable to boot, with modern M:N threading, native clustering capabilities, and very likely a number of userland drivers.
between hurd and linux?
or hurd and debian?
[What’s the difference between] between hurd and linux?
or hurd and debian?
Hurd is an extremely minimal kernel, and uses small servers (services, daemons, whatever you want to call them) to provide most functionality (drivers etc.). This is in some ways a better idea than Linux’ “Everything in one box”-monolithic solution, but slower and harder to perfect. the Hurd is from what I’ve gathered not anywhere near as usable as the Linux kernel at the moment.
Debian is a just a distro that happens to let you choose your kernel, and has a common userland on top of that. (At the moment there is a Debian/Linux, and a Debian/Hurd, and if they haven’t died silently, a Debian/NetBSD and Debian/FreeBSD.)
Ok, small mistake. Assuming the poster a few posts above is right, “Hurd” includes the servers, while the microkernel below that is “Mach”.
(Adding GNU in front of everything seems unneccesary. It’s an implied namespace, IMHO.)
Adding GNU in front of everything seems unneccesary. It’s an implied namespace, IMHO.
Mostly, I’d agree with you, except that in the case of the “Mach” kernel, it would be a serious oversight to confuse stock Mach, from GNU Mach, as GNU’s is severly stripped down and lacks considderable capability.
Admitedly, this is what a microkernel is supposed to be; minimal, but it’s still a good idea to differentiate one from the other.
Right, didn’t think about that.
There’s more hope in getting HURD up and running that waiting for E17 to come out. That’s just a plain joke on the nerd popoulation.
Hurd running on top of GNUMach is pretty stable, and most things work exactly as they were designed to work. But you have to recall, the design, and much of the coding is now around ten years old. So, in many ways, it feels like you’re working on a very dated system. It’s not unlike how I feel when I mess around on my NeXT machine.
I had a machine up on a public IP for awhile, and was able to sustain 14day+ uptimes with it. httpd via Boa, qmail, BitchX, mutt, etc. etc. All that kind of stuff works perfectly. SSH is flaky, and there is no real random/urandom generator, so it’s insecure. FTP, NFS translators all work as they’re supposed to. pfinet (tcp/ip server) works fine, although it is painfully slow.
Disk performance sucks if you’ve got ATA hardware. If you’ve got supported SCSI, things are much better.
X works from time to time, although I can’t really recommend it to anyone. The only thing it’s good for, really, is showing off the mouse translator, and maybe running something remotely over SSH. No Gnome. No KDE. No Mozilla.
What doesn’t work:
— Sound. There isn’t any. And it doesn’t seem to be at all a priority.
— PCMCIA. I think it’s higher on the priority list, but seems to have withered. Most of this work was intended for GNUMach 2.0, but that seems to be stillborn. GNUMach 2.0 was a good idea at the time, but GNUMach 1.3 is better-written, faster, more stable, and it’s what most people still use. The drivers are quite dated for most things, dating back to the linux-2.0 branch for many things.
— Big filesystems. That’s real close, and there are pre-release filesystem translators that support partitions >2GB. GNUMach 1.3 supports up to 10GB. But 10GB is still nothing today.
— USB. See PCMCIA and Sound.
Development on the mach-based GNU continues about at the same pace it has for the last few years. People are, in fact, doing work on it. Some discussion has come out about perhaps porting to OSF-Mach, and abandoning GNUMach. OSF-Mach is now under a GPL-compatible license, I think, and it has some other things going for it….I have an old PPC machine that’ll run OSF-Mach (from MkLinux), and have been meaning to try and get GNU up and running on it, but haven’t really had time to screw with it.
I don’t see much from the l4-hurd list lately, but they’ve got some interesting ideas there. L4 is incredibly fast, but compared to Mach, it provides virtually nothing. Mach gives you IPC, VM, memory management, and device drivers. L4 gives you IPC. So, they have to write a new task server, a device driver framework (in user-space), a memory manager, etc. etc. Most of the hurd servers are really tied to the features Mach provides, so many of those will have to be almost totally re-written to work on top of L4.
Huh, what the? Check out rasterman.com and see his most recent post. With the EFL more or less frozen and stable, he’s beginning to move onto the actual WM – and he’s moving pretty damn fast (IMHO – I’m not a coder). Sure, it’s messy and it’s borked, and not commited to CVS (yet), but from what I’ve heard, EFL makes it a lot easier and faster to code gear like this (see his post on the 17-line dvd player – although I suspect he cheated a bit *grin*).
Also, if you check out http://atmos.org/edje/, he’s got some nice screenshots (albeit a bit old, I believe). I just emailed codewarrrior recently about his screenshot (http://enlightenment.org/pages/img/dr16_shots/codewarrier-xinerama….), and he gave me a fairly detailed description of how he did it – which is how I chanced on atmos’s stuff.
Kinda OT, but e rocks =).
Back to Hurd:
And from what hurdboy says above, Hurd isn’t really usable for non-code-ey people like myself – although a livecd woulfd be pretty cool (using Gnustep? – IMHO, kinda ugly, but I’ve never tried it personally) – any iso’s available? (and yes, I saw the Howto above).
Bye,
Victor
Bye,
Victor
Nope, no livecd, either. Unfortunately, to boot the hurd, you need to use grub, and grub doesn’t support cd’s for booting.
The GNUStep idea is interesting, and there’s a GNUStep livecd (runs linux) floating around with a hurd installer aboard. I haven’t, honestly, screwed with any GNUStep stuff on the hurd…I kind of keep that limited to machines where I use X. It wouldn’t surprise me if it does work pretty well — WindowMaker runs fine on the hurd when you get X up. I don’t know if the GNUStep people have implemented mach messaging in their code yet. They’d discussed using them where they exist (Darwin, GNU/Hurd, NetBSD), but I haven’t looked to see if they’ve done it yet.
I honestly don’t use $free_unix on the desktop very much (although I am at the moment, because I’m screwing around). The server machines I maintain are mostly BSD, with a smattering of Solaris, Linux, and Irix, and well, most of my desktop work is done on a Mac running OSX (I have a powermac on my desk at work, and own an iBook).
I honestly don’t use $free_unix on the desktop very much
most of my desktop work is done on a Mac running OSX
You do know that OSX is BSD right?
There’s more hope in getting HURD up and running that waiting for E17 to come out. That’s just a plain joke on the nerd popoulation.
Not even close. The HURD has been in development for over ten years.
Not even close. The HURD has been in development for over ten years.
Quite right. HURD was started because Stallman wanted his own baby and wanted something as an official GNU project.
The HURD is trying to be something technically perfect that it can never be. Such a project is about making sensible trade-offs, as Linux Torvalds has said many times.
Given that it has been in development for over ten years and hasn’t even got to having sound yet (what did Linux have after ten years?), there is no way the project will be used as a replacement for Linux or even BSD as Stallman wants.
If you want to play with a microkernel system that’s reasonably usable today the only alternatives seems to be QNX and perhaps Plan9.
Unfortunately, to boot the hurd, you need to use grub, and grub doesn’t support cd’s for booting.
? This is news to me. Grub can be used to boot from a CD in at least two ways.
Grub 0.93 added “native” support for ElTorito http://www.gnu.org/software/grub/manual/html_node/Making-a-GRUB-boo…
We (Syllable) have been booting our CD’s using Grub as the native boot loader for over a year now using older versions of Grub by creating boot “floppy” image using a FAT filesystem and putting the Grub files and kernel on the disc image, and using this image as the ElTorito boot image. Dead simple.
If you’ve ever used Darwin/OSX, and really played with it, you’d quickly realize it’s *not* BSD. It has BSD bits, and a BSD userland, but the way things work is different in many, many, many ways. Darwin is Mach + some BSD bits thrown in. If you ever use NeXTStep/OpenStep, you’ll see the lineage — Apple didn’t fork NetBSD or FreeBSD in 1999 and throw a pretty graphical interface on top of it, as the BSDtrolls would have you believe.
The one main thing that Linux got right that HURD keeps getting wrong (and this is coming from a perfectionist-idealist so I can empathise with the desire) is that the first thing is really to get it up and going. Just get a well rounded (in terms of features) and then work on tweaking. I am not referring to the M$ but (next to) –for example– no one will use an OS where they can’t use a mouse. Now hack or kludge in mouse support (EVEN IF YOU NEED TO BUILD IT INTO THE MICRO-KERNEL) that way you can pick up more developer and now you have more labour to go around and write the right support. I believe there is an interview with the inventor’s of Unix where they spell it out explicitly as the secret of their success. Just get it done and then round the edges. I know you can’t leave things out and put them in later (see: M$ and security) but they don’t have to be perfect. Just get HURD usable and then worry about cleaning it up and porting it when you got the developers to make it easy.
Just get HURD usable and then worry about cleaning it up and porting it when you got the developers to make it easy.
Exactly.
I think a great counter-example to Hurd is DragonFly BSD which has already released an ISO and created a STABLE branch. That’s the way/
Ah, but the Hurd is a totally different animal. DragonFlyBSD, while it has some neat features, is still a conventional monolithic Unix. You can’t, for example, replace the network stack. Remember, the deal with the Hurd is its modularity. If you want to change your httpd from apache1.3 to apache2, it’s relatively easy to do that. The Hurd aims at making changing parts of the OS that easy.
In other words, there’s nothing the from which the developers can fork. The only thing relatively modern that even resembles the Hurd is QNX, and that’s commercial. At the time Hurd development started, you had the BSD-lites, but their licenses were GPL-incompatible.
Several falisies exist here,
<LI>GNU Mach 1.3 and support for up to 10gb
This is wrong, it supports bigger partitions than 10gb. It is even noted nicely in the NEWS file for the 1.3 release.
<LI>Dumping GNU Mach infavor of OSF Mach.
There has never been any such talk at all.
<LI>GNU Mach 1.3 being faster than 2.x
I have no idea what you base this on, the code for 1.x and 2.x is identical with the execption that all drivers in 2.x have been moved to OSKit. They are equal both in speed and stability (1.x might be a bitmore stable, since it is used more, but that is kinda it)
<LI>Hurd servers tied into Mach.
This is semi-wrong, yes, they are tied in somewhat, but not as much as you say.
— ams, a Hurd hacker
I have no idea what you base this on, the code for 1.x and 2.x is identical with the execption that all drivers in 2.x have been moved to OSKit.
I’ve often wondered why none of the Hurd folks have decided to implement something like Mac OS X’s I/O Kit. Those old Linux drivers are pretty crappy, and I’m not convinced that the OSKit ones are any better.
Why can’t the Hurd have a userspace driver implementation? Personally I would have thought that would fit in much better with the verall goals of the project.
Why can’t the Hurd have a userspace driver implementation?
Personally I would have thought that would fit in much
better with the verall goals of the project
Hurd on L4 will have user-space drivers. The problem with
having user-space drivers when you’re running Mach is that
there is no simple way to export things like interrupts into
userspace.