GNU/Hurd Web Server Online

Ross Vandegrift writes "Jeff Baily sent an email to the Hurd development list today announcing he has put up a GNU/Hurd webserver. Not much content there, but the fact that it is up is incredible alone. Keep up the good work Hurd! "

Comments

/unix.elc

[Tom Christiansen]

Superficially you'd think there's an element of jealousy there because Stallman almost wrote an OS then someone else got most of the limelight by writing the kernel... but that just doesn't feel like the case

I realize that emacs is a fine operating system, but some of us still prefer Unix.

Ouch

[Daniel]

Periodically, someone comments that warnings should be sent to admins of systems whose systems are linked to from here, just in case the load is too much. But linking to a system running an experimental operating system should probably fall somewhere under premeditated assault.. ;-)

Daniel

Poor guy

[legoboy]

I can just imagine him surfing the net, reading Slashdot.. He sees a story about him appear at the top of the main page. He has two seconds to say "Oh NO!".

Suddenly, his net connection is hosed for the next week.

------

Cool Hurd Tricks

[roystgnr]

It's my understanding that while the Hurd is aiming for Posix compatibility, and going to use glibc as the standard library, they're going to be much more modular and abstracted (read: cool but possibly slow) under the hood.

The neatest things I've heard of:

The whole system is basically cooperating servers running atop the GNU Mach microkernel:

the idea that every user can build up his own system on top. So, if you want to operate, start compatible servers. It's after all your decision, much like it is your personal decision if you use one desktop system (like Gnome) or Xlib, Athena etc programs together. Latter don't interoperate well (drag n drop etc). As they run in user space, you can tweak the system to your liking, even as a user.

But there are still some servers that are the base of the Hurd system. Those are the auth, proc, init and password server at least. You don't need to register your process with the proc server (and it won't show up in the output of "ps" if you don't do so), but that the only thing that will give you access to the features of the proc server. Same with auth. If you don use auth, your tasks will have little to none privilegdes.

Better yet, filesystem support comes from servers, which I believe means that users can have files or filesystems (limited to user permissions) that live off their own servers. Every mounted filesystem is just another new filesystem server added to the pool. No need to make smbmount suid root or put every smb share with the user option into fstab, for instance; any user process would be able to mount arbitrary smb shares in their own directories and make them viewable without being able to circument security. Cooler yet, in theory you could make .signature be randomly generated by a program without using ugly named pipe hacks, you could "cd file.tar.gz" without ugly virtual filesystem libraries, you could implement albods more easily... I can't imagine all the possibilities, but it's fun to try.

Superficially you'd think there's an element of jealousy there because Stallman almost wrote an OS then someone else got most of the limelight by writing the kernel... but that just doesn't feel like the case.

There's appropriate mailing lists you can hunt down for deep info, but you can follow the Cliff's Notes of the Debian Hurd work at the debian-hurd Kernel Cousin page.

Re:So, what is herd?

[adubey]

Before there was Linux, there was GNU. What is GNU? GNU's not Unix. What is Unix? A castrated Multics. What is multics? An operating system. So GNU's not a castrated operating system.

Wait. That's not right. No, it is right, but it isn't what you're looking for, right? Right.

GNU was intended to be a castrated operating system, er, I mean operating system. The difference is that GNU was intended to be free to distribute and modify. When Richard Stallman set about to write the GNU system in 1984, he quickly saw that he couldn't get anywhere without a compiler.

Or tools.

Or libraries.

So the GNU project carried on for 7 years writing compilers, tools, and libraries, always psyching themselves up for writing the key part of the OS - the kernel. But Linus beat them to it. Linux, released under the same "GPL" liscense of the GNU System, starting getting acceptance amoung the so-called open source community (except it wasn't so-called at that time. It started being so-called in 1998. Back then it was so-called something else.).

But the GNU people never lost their dream of writing not-a-castrated-kernel for their system. And that's what HURD is. I mean HIRD. I mean... well, I know I don't mean herd.

The HURD kernel, technically, has one big advantage over the Linux kernel - it is microkernel-based.

As Linus continually points out, anything you can do to make a microkernel OS fast, you can do to a monolithic kernel (like Linux). All this is true - and the monolithic kernel wins because of lower overhead. That's why Linux continually beats out high-end rockin' Solaris on single-processor machines.

However, the overhead due to microkernels are only constant factors. Kinda like in the old days when you could write in assembler and beat the pants off of any compiler by a constant factor (depending on how good you were, and how bad the compiler was, that constant could be pretty high). But the problem with giving up a high-level language for assembly is the same problem with giving up microkernels for monolithic kernels - giving up the abstraction makes programming harder. (This might be kind of prophetic: these days compilers will beat assembly programmers almost every time)

Since programming is already so hard (grin), the development of new abstractions has been one of the key factors behind the advancement of computer science. All abstractions (think: high-level languages, structured programming, object-oriented programming, pure-OO programming, lambda-calculus programming) increasingly make programming easier at the expense of decreasing speed.

*But* Linux still has many more years of development behind it than HURD. Or HIRD. But not herds (some of them have been around for millenia... unfortunate about the Buffalo, though). And Linux still has more coders. So Linux will likely stay ahead of HURD for a while.... (at least until they have a stable release :).

How does this concern you? To finish this off, I must say that unless you happen to have a 16-processor box lying around, all this won't help. Linux still rules the day on single processor machines, and probably won't be over taken.

Since you probably don't have a massive SMP machine, everything I've written was a complete waste of time. So there.

There is an end to Linux

[Bruce Perens]

There is an end to Linux. Some day, we'll be using something else. That something will most likely be Open Source, there's no going back on that one, and it will probably be compatible on some level with what we had before. But it will be a successor to Linux, not Linux. Will it be the Hurd? Maybe. But the point I want to make is that Linux is not forever.

Thanks

Bruce