6 ms·
The preliminary rump kernel support that arrived just a bit more than a week ago is quite promising, if still quite rudimentary. That said, a patched MPlayer li
by vezzy-fnord 11y ago
The preliminary rump kernel support that arrived just a bit more than a week ago is quite promising, if still quite rudimentary. That said, a patched MPlayer linking to rump libraries has been able to play OGG files on a Hurd system: https://lists.gnu.org/archive/html/bug-hurd/2015-08/msg00027.html https://lists.gnu.org/archive/html/bug-hurd/2015-08/msg00027...
Though obviously in the very initial stages, the implications of this development taken to its end could be enormous. Have the GNU Hurd implement translator or server interfaces to the rump drivers, plug it on top of an immutable package and configuration management suite like Guix (actually already being done), and for the first time in history you have a complete, general-purpose microkernel-based Unix-compatible (but beyond plain Unix) system that could rival the likes of GNU/Linux. The great thing about it is that the Hurd isn't afraid to break POSIX semantics where beneficial. This makes it have, among other things, processes running under multiple uids, true Plan 9-style namespacing, unprivileged mounts, token-based authentication, and so forth.
I've been playing with it on-and-off (including cross-toolchains) and been pondering about Mach kernel emulation on Linux. A pure userland server would be most desirable, but faces real changes with modeling port rights as file descriptors sent over ancillary data, how to reliably handle user-level page fault handling on a per-application basis, mapping VM regions across address space boundaries and properly emulating RPC. Kip Macy did successful work on a port of OSF Mach from the MkLinux sources as a FreeBSD kernel module for use with launchd, XPC and other OS X modules, so I think that might end up being a concession I'll look into taking one day. I'm occupied with other projects in the meantime.
It'd be also funny to have Linux "eat" itself in such a manner by becoming a host for the Hurd. Poetic justice, I suppose. But I'll wait to see if the rump kernel stuff pans out first.
(MINIX 3 is great too, much better microkernel, but it's more meant for reliability rather than exposing end-user flexibility like Hurd does with translators. It also doesn't come close to the ~81% of Debian building as is with Hurd, and the MINIX devs themselves are positioning it as an embedded platform rather than general-purpose.)
- nextos 11y agoGuix is becoming increasingly ready for prime time. There's one big HPC install in Germany already running it. I think it's past the toy stage. I guess Guix + Hurd is a great setup, with innovative features in the kernel and userland. Both very pure in their respective ways, with Guix having functional package management, and Hurd keeping the kernel minimal so that crashes or security breaches are not catastrophic.
- 616c 11y agoVery cool to hear. Where can we read more about this? Or is this an insider comment?
- davexunit 11y agoHere's some blog posts about HPC with Guix: http://elephly.net/posts/2015-04-17-gnu-guix.html http://elephly.net/posts/2015-04-17-gnu-guix.html http://zvfak.blogspot.com/2015/07/gnu-guix-for-easily-managing.html http://zvfak.blogspot.com/2015/07/gnu-guix-for-easily-managi... And here's a paper on the subject: https://hal.inria.fr/hal-01161771/en https://hal.inria.fr/hal-01161771/en
- synchronise 11y agoWhat's the difference between Nix and Guix anyway, and which is 'better'?
- thoughtpolice 11y agoNix is what Guix is based on. You can think of Guix as the 'GNU Version' of Nix/NixOS, meaning it provides free software packages, and IIRC it uses Guile Scheme, rather than Nix, to describe all the packages and OS configuration. It's a toss up as to whatever you like. I think Nix has a bigger community, more packages, etc. But Guix, strictly speaking I think, is a 'superset' because changes from Nix often flow into Guix (and Guix can use Nix packages directly), as Guix is built directly on the same source-code as Nix - but not the other way around. There are some other differences, like the fact Guix uses GNU dmd while NixOS uses systemd, etc etc. It's all just personal preference I think. I use NixOS because it's reliable and has a decently sized community, and a lot of packages. It also has really, really good Haskell support, and being a Haskell developer, that's a pretty big plus to me. Having non-free packages isn't so much of a stickler for me. I think the Guix people are doing good work, though, and a distribution for free software and the GNU project is very important - so I wish them the best even if I'm farther away. You'd have to try both of them and make a decision for yourself IMO. But I warn you: the rabbit hole is deep, and will require learning. And when you come out - you may be immensely displeased with the current state of affairs. :) (Full disclosure: IAMA NixOS developer.)
- jakeogh 11y agoExciting! "processes running under multiple uids" Why?
- vezzy-fnord 11y agohttps://www.gnu.org/software/hurd/hurd/authentication.html https://www.gnu.org/software/hurd/hurd/authentication.html It's a form of capability-based security and it makes some forms of sandboxing or access control trivial (i.e. removing rights from processes). If you want to block a process from accessing a certain subsystem, just rmauth its session token to the server.
- sn41 11y agoI remember seeing a demo of a very early version of HURD in 2002, and I thought this was the most interesting thing about it. I think in the demo, Marcus Brinkmann showed how in the midst of editing a file in vi in user mode, you could open another file in superuser mode, do an edit there and then go back to the old file in user mode.
- ai_ja_nai 11y agoI don't get all this hate on Linux: it basically sustained GNU project for almost 25 years...
- vezzy-fnord 11y agoNo one is hating Linux. But Linux isn't exactly of much help towards advancing the status quo of OSes, either.
- renox 11y agoThat's highly debatable: for example BeOS recreators/Haiku devs CHOSE to use a new exotic kernel instead of Linux or FreeBSD kernel. But their reasons seems mainly because of NIH syndrome: those who like to create a new OS also to tinker with "their own kernel" instead of reusing something already existing.
- vezzy-fnord 11y agoWhy the hell would you recreate BeOS on a Unix-like kernel? Are you even listening to yourself? That's not NIH, that's common sense. It's far more effort to try and learn the ins-and-outs of a large kernel like FreeBSD or Linux, then try to shoehorn completely different OS semantics onto Unix, than to just roll your own. Also, Haiku's kernel was forked from NewOS, which was back in 2001, and written by a former Be engineer. Besides, how is their choice signifying a hatred for Linux?
- renox 11y ago> Why the hell would you recreate BeOS on a Unix-like kernel? Because you wouldn't have to code all these drivers to make the result an useful OS? > Are you even listening to yourself? That's not NIH, that's common sense. 1) You're being rude. 2) 'common sense' is not an argument. > It's far more effort to try and learn the ins-and-outs of a large kernel like FreeBSD or Linux, then try to shoehorn completely different OS semantics onto Unix, than to just roll your own. Well its depends whether your goal is to have an OS running in very few configurations or if your goal is to have an OS which is able to be run by many. > Besides, how is their choice signifying a hatred for Linux? It doesn't, I was replying to the sentence "But Linux isn't exactly of much help towards advancing the status quo of OSes, either." an OS isn't a kernel and there WERE discussions about whether using Linux or FreeBSD kernel or NewOS in Haiku..
- synchronise 11y agoThe biggest limiting factor at the moment with Hurd is their choice for the base microkernel, currently Mach which hasn't had substantial updates for years. While Hurd improves its userspace support, the should also revisit the idea of rebasing the OS on L4 (where you can also load a Linux instance in userspace for compatibility) or Minix3 which has been working on its own kernel features.
- vezzy-fnord 11y agowhich hasn't had substantial updates for years. Not true. GNU Mach has been undergoing lots of refactoring recently with regards to locking, protected payloads for threefold lowering of RPC lookups, the VM subsystem and so forth.
- synchronise 11y agoSo what sort of performance improvements have been made? Is Mach now in the same bracket as other, newer microkernels?