Bits from the Debian GNU/Hurd porters | Hacker News Reader

Bits from the Debian GNU/Hurd porters

lists.debian.org

129 pointstshepang37 comments

It kind of seems like the least interesting possible thing to do with Hurd, given its major architectural differences from Linux, is to make it as much like Linux as possible. I'm just not sure who the target users are for "Debian GNU/Hurd" or why they'd ever be better served by it than by Debian Linux?

Edit to add: That said, since Debian seems to be the main group willing to do any kind of binary distribution with Hurd, they get to call the shots.

> It kind of seems like the least interesting possible thing to do with Hurd, given its major architectural differences from Linux, is to make it as much like Linux as possible.

I suppose that whoever uses it also needs userland software. It's fun to have a kernel with an unusual architecture, but less so when there is no application for it. I'm also not sure who the public is, apart from FSF people(?), kernel enthusiasts and people who like to experiment. But clearly there are enough people interested that it is getting more usable, and there is nothing wrong with that.

Hurd is a POSIX OS.

it may be posix-like, but even Linux is not really a POSIX OS except for one version of Red Hat long ago, and maybe now or in the future some Oracle distribution. Same goes for UNIX - these proprietary, commercial certifications only apply to a frozen codebase.

This doesn't seem like a useful distinction.

So are certain versions of Windows NT.

What I'm talking about is adopting things well outside the confines of POSIX, into using stuff like FHS and systemv-style init. Hurd has some powerful stuff that's more like Plan9 than it is like UNIX, and some linuxy ways of doing things can get in the way of using those.

If having a Linux-like layer is what it takes to gain more traction, then so be it.

The world gains very little from having a great OS nobody knows about.

With time, the Hurd-ish ways should prevail where it makes sense.

They already did, its called Plan9 =P

Really, the next innovation in kernels and system architecture needs to be an improvement on plan9 - not on Unix, again.

Since Linux distributions are actually GNU operating systems with a Linux kernel, there's no reason it doesn't make sense to try a GNU operating system with a GNU kernel.

Hurd predates Linux, it isn't architecturally different from Linux, Linux is architecturally different from it - but almost none of the runtime cares if it is running on a modular monolithic kernel (Linux) or a microkernel (Hurd, Minix, Mach).

I'm probably being over-pedantic here, but you know that technically the kernel is the OS, right? The userspace tools are not the operating system. So Linux distributions are Linux operating systems, with tools from the GNU project.

Back to your sentiment, yeah it makes sense for all things GNU to be able to work with each other. That's one of the biggest benefits of this Debian project.

> that technically the kernel is the OS, right?

According to whose techne?

This really all boils down to opinions, nothing else.

Well, OS is broader than the kernel. I agree with you that Linux is not "a GNU OS," but mostly because only a small portion of any given linux distribution is GNU or couldn't easily be replaced by nearly identical non-GNU components. Certainly once you get into using something like KDE, the bulk of your environment is not in any way part of the GNU project.

I think you may be forgetting glibc :). It certainly doesn't fall under the rubric of "easy to replace" -- although it's certainly possible.

I used to argue that.

Android's largely convinced me otherwise.

(Android isn't a Linux OS so far as I'm concerned).

Yes. The name argument really should be laid to rest now since the "linux OS" has died and been replaced by distributions.

I don't run linux, I run Debian. Debian might include packages from GNU, Linux, BSD, HURD, KDE, GNOME, US, EU, and X, but do I call the OS any of those?

Static operative systems with packages from only one source is a thing of the past.

> It kind of seems like the least interesting possible thing to do with Hurd, given its major architectural differences from Linux, is to make it as much like Linux as possible. I'm just not sure who the target users are for "Debian GNU/Hurd" or why they'd ever be better served by it than by Debian Linux?

Right now, the target audience are Hurd developers, who need a useful userspace to work with. Making that userspace as much like Linux as possible reduces the incremental maintenance effort, which is critically important given the limited number of developers.

(You could reasonably ask the value of developing Hurd at all, but given a set of people wanting to develop it, it makes sense for them to do so using a Debian userspace.)

> is to make it as much like Linux as possible

They don't make it "as much like Linux as possible". Although nobody except for rms uses that name, the OS is actually called GNU. And they're "just" replacing the kernels, not really building the separate OS.

While modern GNU (and related) userland is, indeed, has many strong ties to Linux, their first milestone is probably to get things working, so, I guess, getting rid of Linuxisms just isn't the priority.

This advantages page is interesting: http://www.gnu.org/software/hurd/advantages.html

I'm just not sure they're all advantages for a general purpose kernel. Many have tried the microkernel model - Windows (NT) and OS X as two examples were both designed around the microkernel model, but have had to give it up since then purely for performance reasons. The high overheads of all the IPC meant that the operating system was just a bit slow, and the IPC made it all hard to debug.

it seems that to say that OS X was designed around the microkernel model, but had to give it up is misleading.

XNU, OS X's kernel, is based on the Mach microkernel, but also leverages some monolithic design in some cases.

In any case, it seems that Debian GNU/Hurd would be a worthwhile place to experiment with such technologies with a familiar runtime.

Sorry for the confusion - that's what I meant. They both vaguely work around the microkernel architecture, except where it's not desirable for performance reasons - so for example on my Mac basically every hardware driver runs in supervisor mode.

I agree with the premise that it's more hackable, though.

According to this: http://www.roughlydrafted.com/0506.mk3.html

It states that the Mach kernel used in OSX was Mach 2.5 which was not a micro-kernel (as opposed to Mach 3.0) and is not used in OSX as a micro kernel.

Good thing that with modern computers and better memory management those IPC issues are largely negated in this day and age.

That was a long long time ago.

QNX, Symbian, Type 1 Hypervisors, OKL4 are just a few examples of successful commercial use of the microkernel model.

> Switch to pthreads.

I'm not aware what they used before, but why pthreads? Isn't this perfect opportunity to try to develop something better, introduce new concepts (async, coroutines or some kind of userspace deterministic job management)? Not sure if backward compatibility is best way to go here, but maybe i'm just talking gibberish

They used cthreads before.

I agree that raw threads are a terrible abstraction for application programmers to manipulate directly. Actors and CSP are much better concurrency models for application developers to use.

However, if you're going to do low-level OS and language runtime programming for multi-core computers, threads are a good abstraction on top of which you'd implement CSP or Actors. Also, there's tons of legacy software that uses lots of raw pthread calls, so to have any kind of adoption of a UNIX-like OS, you're going to have to support pthreads.

Putting aside the need to port code from elsewhere and not exist in your own private universe, this is a bit like saying remove the filesystem APIs because we have a database. Both are valid things to keep around. Given the choice there are still lots of instances where you would pick the former.

I'm aware of this and it's rational choice, but whata opportunity. They (just maybe) could also add compatibility layer on top of something else, like other projects do, but nvm.

Sorry to see them selling themselves short, as far as I can tell, coverage increased from 70% to 80% (not from 73%) -- so it's more an increase of 14%, not 10%!

Great to see this port moving forward, now I'm no longer certain my next playdate will be with Debian/kFreeBSD after all!

They likely meant ten percentage points, a frustratingly common miscommunication.

Sysvinit? Really?

systemd is becoming the standard free-Unix init. Even the OpenBSD folks acknowledge the need for a systemd-compatible init and have started a GSoC project for just that.

systemd is a linux only thing.

As for the GSOC project:

-----

Project: Provide bsd-licenced, os-agnostic, dbus-api compatible systemd-{hostnamed,timedated,localed,logind} replacements.

Brief explanation: More and more desktop-level applications now depend on apis provided by linux's systemd. We need to have an equivalent to keep up with them.

systemd only runs on Linux, and that will never change. I'd love to see a mostly-systemd-compatible init for other UNIX OSes, but moving from Hurd's previous pile of custom scripts to sysvinit is a useful incremental step.

systemd is becoming the standard free-Unix init.

Hardly, systemd is a blatant Linuxism. Unless your definition of "Unix" includes nothing but Linux, in which case, you're right at home with it.

Having already UNIX experience before Linus could even think about writing Linux, sometimes I have some difficulties to grasp how people equate UNIX == GNU/Linux.

Uh, no. Check #15 and #16 in "The 30 Biggest Myths about systemd".[0] It's highly unlikely that systemd will ever run on *BSD - even on Debian/BSD with a GNU userland - and those are a lot closer to Linux than than Hurd is. Systemd is Linux-only. I'm tempted to say it's GNU/Linux-only, but I'm not sure if Google's working on getting it to run on Android/Linux.

EDIT - even if the BSDs have started working on their own equivalent, that doesn't help the Debian/Hurd porters who need a working init system _now_. Or, more accurately, a couple of years ago when they really started to get the distro together.

[0] http://0pointer.de/blog/projects/the-biggest-myths.html

The BSDs aren't working on any alternative, as far as I know. OpenBSD is working on creating OS-agnostic replacements for some of the common systemd interfaces (logind, hostnamed, etc.) for use in porting applications that need them, e.g. GNOME.

Reply on news.ycombinator.com