3 ms·

As tired as it may sound, I think there just might be a convenient time for the Hurd to rise, albeit in an unconventional way. You already have a de facto GNU

As tired as it may sound, I think there just might be a convenient time for the Hurd to rise, albeit in an unconventional way. You already have a de facto GNU OS at the moment in the form of the Guix System Distribution (GuixSD), what with it letting you configure the entire system in Scheme, perform transactional upgrades, system state rollbacks, it has its own init daemon and service scripts in Scheme, etc. At the same time, we've been seeing some efforts in creating tiny builds of the Linux kernel [1] that go as far as to reduce syscalls, VMM algorithms, capabilities, character devices and so forth. There's also the recent Linux libOS effort to create a network stack in userspace as a shared library, though that seems about the extent of it. NetBSD then gives you a userland driver framework with rump kernels. So what one can do is build a really stripped down Linux kernel, write a Mach IPC compatibility layer, run the Hurd servers on top of it and plug in the resulting product with GuixSD. And you now have the complete GNU system. As far as you'll ever get, anyway. This has already been discussed before [2], but it's not something that has ever been given any priority. With the current climate, it might be worth a shot. As to why anyone would want to do this... well, for one you get a full OS that is entirely configurable in Scheme with all of its services running as userland file servers (translators) in a sort of Plan 9-ish way, all the while supporting the Linux API. That's still pretty ahead of GNU/Linux. The Hurd also has features like running multiple instances of itself in user mode (subhurds) that can serve a similar purpose to containers. It's obvious no one's going to port the Hurd servers away from GNU Mach, so this is the best shot anyone has. Any Hurd or Guix devs in here to comment on this? [1] https://tiny.wiki.kernel.org/ https://tiny.wiki.kernel.org/ [2] https://www.gnu.org/software/hurd/open_issues/linux_as_the_kernel.html https://www.gnu.org/software/hurd/open_issues/linux_as_the_k...

nickpsecurity 11y ago
I'm not Hurd supporter but that's an interesting idea. I'd say replace Scheme with Python or something mainstream that's similarly powerful. Adding LISP to stuff usually kills it off unfortunately, with Clojure a freak occurrence. The transactional upgrades and rollbacks feature by itself would be compelling to some audiences.
- rekado 11y ago
  "Adding LISP to stuff usually kills it off" What? Oh, you mean like Emacs. Scheme is a beautiful language; it's flexible and trivial to learn. Replacing it with Python would be silly. Besides, Guile Scheme is the designated extension language of the GNU system. Gnucash, dmd (the init system), the Gimp, Guix, gEDA and many more GNU applications all can be hacked in or extended with Guile. In the GNU system Guile Scheme is "mainstream".
  - nickpsecurity 11y ago
    "Oh, you mean like Emacs." No I mean like... surveys the market... nearly everything else. The LISP field is almost non-existent outside of academia and a few companies. Almost nothing mainstream in proprietary or FOSS is built with it. Plus, most programmers hate it. So, using something like in a FOSS app intended to go mainstream is quite a risk. "Besides, Guile Scheme is the designated extension language of the GNU system." Oh Ok. That they're pushing people to use an unpopular language at least explains why the apps you cited used it. " In the GNU system Guile Scheme is "mainstream"." Nah, most programmers haven't heard of it. Of those that have, I'd bank on only a subset even using it. I'd say it's used by a tiny set of developers, esp extension builders. And for tools who mostly each represent a small amount of developers or users. You're really making my point for me by redefining the word mainstream to be "barely known software barely making it with a few exceptions." They should consider something that actually is mainstream as an experiment in increasing adoption. Probably some other things to reconsider while they're at it.
    - rurban 11y ago
      You mean like AutoCAD was killed by all the other CAD packages with a more conventional language? I'd like to see such a counterexample. Lisp is only killed by managers who are afraid to hire cheap labour. Like yahoo and their store.
      - nickpsecurity 11y ago
        What language is AutoCAD written in? And what percentage of successful products and projects use LISP? That's what I mean. It's the status quo of where LISP is in the marketplace. It's you that have to provide dozens to thousands of counterexampes to even illustrate a trend. They're not there. Whereas companies adopting PHP, Python, Ruby, Lua, and so on have no time finding help, libraries, or customers. Because they're mainstream and attract such people. See the difference now?
teythoon 11y ago
Hurd developer here. I also have high hopes for Guix, and in fact there is a gsoc project to port Guix to the Hurd. Guix tries to empower the user, a goal shared by the Hurd. They are a perfect match. I do not believe that it is easy to provide the Mach IPC interface in the Linux kernel. The IPC mechanism is tightly integrated into the thread switching and scheduling systems. Furthermore, I do not see much benefits in doing that, the main point would be drivers, which we want to run as a userspace process anyway. And we are doing that using the DDE framework. Rump is interesting, and it wouldn't even be that hard. It just lacks someone actually doing it. What people don't realize is how compatible the Hurd is. We are shipping the glibc. Debian/Hurd contains ~80% of the software that is found in Debian/Linux. We have Firefox. The other day I deployed two Django sites on my Hurd development server to work out some issues I had with the Apache configuration I had on the production system. I was curious how it would go. All the Python stuff worked out of the box, I merely had to select a different Apache mpm module, because the default didn't work. Need to rescue a box? Append "init=/bin/bash" to the kernel command line to circumvent sysvinit. Other microkernel based systems might have more ambitious goals, but many of them sacrifice compatibility to reach them. Some aspects in POSIX are hard to implement in a distributed fashion, for example fork(2). But what good is a fancy system if it requires a huge effort to port applications to it?
- vezzy-fnord 11y ago
  Right, the hypothetical tiny Linux kernel would probably be built without driver support and have NetBSD's rump kernel drivers in place of both Hurd's DDE and the monolithic Linux drivers, which keeps the userspace advantage. It's true that a Mach port is quite tricky (particularly the virtual memory semantics). Apparently there was an old abandoned attempt to port Mach on top of POSIX, which if someone obtains the source, might be a useful reference to see what went wrong or is incomplete [1]. It's worth noting that the reverse (Linux on top of Mach) was already done by Apple nearly a couple of decades ago as MkLinux, but they ultimately settled on XNU. [1] https://www.gnu.org/software/hurd/open_issues/mach_on_top_of_posix.html https://www.gnu.org/software/hurd/open_issues/mach_on_top_of...

nickpsecurity 11y ago

I'm not Hurd supporter but that's an interesting idea. I'd say replace Scheme with Python or something mainstream that's similarly powerful. Adding LISP to stuff usually kills it off unfortunately, with Clojure a freak occurrence. The transactional upgrades and rollbacks feature by itself would be compelling to some audiences.

rekado 11y ago
"Adding LISP to stuff usually kills it off" What? Oh, you mean like Emacs. Scheme is a beautiful language; it's flexible and trivial to learn. Replacing it with Python would be silly. Besides, Guile Scheme is the designated extension language of the GNU system. Gnucash, dmd (the init system), the Gimp, Guix, gEDA and many more GNU applications all can be hacked in or extended with Guile. In the GNU system Guile Scheme is "mainstream".
- nickpsecurity 11y ago
  "Oh, you mean like Emacs." No I mean like... surveys the market... nearly everything else. The LISP field is almost non-existent outside of academia and a few companies. Almost nothing mainstream in proprietary or FOSS is built with it. Plus, most programmers hate it. So, using something like in a FOSS app intended to go mainstream is quite a risk. "Besides, Guile Scheme is the designated extension language of the GNU system." Oh Ok. That they're pushing people to use an unpopular language at least explains why the apps you cited used it. " In the GNU system Guile Scheme is "mainstream"." Nah, most programmers haven't heard of it. Of those that have, I'd bank on only a subset even using it. I'd say it's used by a tiny set of developers, esp extension builders. And for tools who mostly each represent a small amount of developers or users. You're really making my point for me by redefining the word mainstream to be "barely known software barely making it with a few exceptions." They should consider something that actually is mainstream as an experiment in increasing adoption. Probably some other things to reconsider while they're at it.
  - rurban 11y ago
    You mean like AutoCAD was killed by all the other CAD packages with a more conventional language? I'd like to see such a counterexample. Lisp is only killed by managers who are afraid to hire cheap labour. Like yahoo and their store.
    - nickpsecurity 11y ago
      What language is AutoCAD written in? And what percentage of successful products and projects use LISP? That's what I mean. It's the status quo of where LISP is in the marketplace. It's you that have to provide dozens to thousands of counterexampes to even illustrate a trend. They're not there. Whereas companies adopting PHP, Python, Ruby, Lua, and so on have no time finding help, libraries, or customers. Because they're mainstream and attract such people. See the difference now?

teythoon 11y ago

Hurd developer here. I also have high hopes for Guix, and in fact there is a gsoc project to port Guix to the Hurd. Guix tries to empower the user, a goal shared by the Hurd. They are a perfect match. I do not believe that it is easy to provide the Mach IPC interface in the Linux kernel. The IPC mechanism is tightly integrated into the thread switching and scheduling systems. Furthermore, I do not see much benefits in doing that, the main point would be drivers, which we want to run as a userspace process anyway. And we are doing that using the DDE framework. Rump is interesting, and it wouldn't even be that hard. It just lacks someone actually doing it. What people don't realize is how compatible the Hurd is. We are shipping the glibc. Debian/Hurd contains ~80% of the software that is found in Debian/Linux. We have Firefox. The other day I deployed two Django sites on my Hurd development server to work out some issues I had with the Apache configuration I had on the production system. I was curious how it would go. All the Python stuff worked out of the box, I merely had to select a different Apache mpm module, because the default didn't work. Need to rescue a box? Append "init=/bin/bash" to the kernel command line to circumvent sysvinit. Other microkernel based systems might have more ambitious goals, but many of them sacrifice compatibility to reach them. Some aspects in POSIX are hard to implement in a distributed fashion, for example fork(2). But what good is a fancy system if it requires a huge effort to port applications to it?

vezzy-fnord 11y ago
Right, the hypothetical tiny Linux kernel would probably be built without driver support and have NetBSD's rump kernel drivers in place of both Hurd's DDE and the monolithic Linux drivers, which keeps the userspace advantage. It's true that a Mach port is quite tricky (particularly the virtual memory semantics). Apparently there was an old abandoned attempt to port Mach on top of POSIX, which if someone obtains the source, might be a useful reference to see what went wrong or is incomplete [1]. It's worth noting that the reverse (Linux on top of Mach) was already done by Apple nearly a couple of decades ago as MkLinux, but they ultimately settled on XNU. [1] https://www.gnu.org/software/hurd/open_issues/mach_on_top_of_posix.html https://www.gnu.org/software/hurd/open_issues/mach_on_top_of...