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.
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.
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.
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.
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.
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.
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.
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.
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.)
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.
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.
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.
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.
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
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!
36 comments
[ 2.4 ms ] story [ 74.7 ms ] threadXNU, 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.
I agree with the premise that it's more hackable, though.
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.
QNX, Symbian, Type 1 Hypervisors, OKL4 are just a few examples of successful commercial use of the microkernel model.
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.
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.
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.
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.
Really, the next innovation in kernels and system architecture needs to be an improvement on plan9 - not on Unix, again.
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).
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.
According to whose techne?
This really all boils down to opinions, nothing else.
Android's largely convinced me otherwise.
(Android isn't a Linux OS so far as I'm concerned).
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.
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.)
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.
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.
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.
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
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
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.
Great to see this port moving forward, now I'm no longer certain my next playdate will be with Debian/kFreeBSD after all!