7 ms·

Bits from the Debian GNU/Hurd porters

129 points by tshepang 12y ago

atmosx 12y ago
This advantages page is interesting: http://www.gnu.org/software/hurd/advantages.html http://www.gnu.org/software/hurd/advantages.html
- CHY872 12y ago
  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.
  - justizin 12y ago
    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.
    - CHY872 12y ago
      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.
    - gillianseed 12y ago
      According to this: http://www.roughlydrafted.com/0506.mk3.html 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.
  - synchronise 12y ago
    Good thing that with modern computers and better memory management those IPC issues are largely negated in this day and age.
  - pjmlp 12y ago
    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.
stormbrew 12y ago
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.
- mercurial 12y ago
  > 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.
  - gkya 12y ago
    Hurd is a POSIX OS.
    - justizin 12y ago
      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.
      - chc 12y ago
        This doesn't seem like a useful distinction.
    - stormbrew 12y ago
      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.
bitwize 12y ago
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.
- rat87 12y ago
  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.
- JoshTriplett 12y ago
  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.
- vezzy-fnord 12y ago
  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.
  - pjmlp 12y ago
    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.
- Karellen 12y ago
  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 http://0pointer.de/blog/projects/the-biggest-myths.html
popee 12y ago
> 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
- KMag 12y ago
  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.
- asveikau 12y ago
  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.
  - popee 12y ago
    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.
e12e 12y ago
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!
- danudey 12y ago
  They likely meant ten percentage points, a frustratingly common miscommunication.

129 points by tshepang 12y ago

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

CHY872 12y ago
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.
- justizin 12y ago
  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.
  - CHY872 12y ago
    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.
  - gillianseed 12y ago
    According to this: http://www.roughlydrafted.com/0506.mk3.html 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.
- synchronise 12y ago
  Good thing that with modern computers and better memory management those IPC issues are largely negated in this day and age.
- pjmlp 12y ago
  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.

stormbrew 12y ago

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.

mercurial 12y ago
> 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.
- gkya 12y ago
  Hurd is a POSIX OS.
  - justizin 12y ago
    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.
    - chc 12y ago
      This doesn't seem like a useful distinction.
  - stormbrew 12y ago
    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.

bitwize 12y ago

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.

rat87 12y ago
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.
JoshTriplett 12y ago
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.
vezzy-fnord 12y ago
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.
- pjmlp 12y ago
  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.
Karellen 12y ago
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 http://0pointer.de/blog/projects/the-biggest-myths.html

popee 12y ago

> 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

KMag 12y ago
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.
asveikau 12y ago
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.
- popee 12y ago
  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.

e12e 12y ago

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!

danudey 12y ago
They likely meant ten percentage points, a frustratingly common miscommunication.