3 ms·

What are your main motivations to use GNU Hurd? Not wanting to troll, fishing for a link for good background reading

christianbryant 11y ago
Advantages: http://www.gnu.org/software/hurd/advantages.html http://www.gnu.org/software/hurd/advantages.html http://www.gnu.org/software/hurd/community/weblogs/ArneBab/technical-advantages-of-the-hurd.html http://www.gnu.org/software/hurd/community/weblogs/ArneBab/t...
- bsaul 11y ago
  Just read the advantages, some parts seem a bit old. Touting object oriented design as something enabling refactoring, whereas the trend for the last fifteen years has been toward interface-oriented design (with golang being the most extreme case). Also, in a world of unikernels and app containers (trending toward the most static and restricted deployment unit possible), having an os being able to change its parts while running seems a bit useless. But, who knows ? maybe we'll see new patterns emerge. That's a fantastic time for people interested in OSes.
  - codeulike 11y ago
    the Hurd has an object-oriented structure that allows it to evolve without compromising its design. This structure will help the Hurd undergo major redesign and modifications without having to be entirely rewritten. Yeah, good luck with that. OO is great but I'm not sure major redesigns are any easier in OO compared to any other arch. Having a completely different OS arch in play does sound good though, perhaps opening up possibilities we havent realised yet. Perhaps someone should re-write that 'advantages' page to encompass the massive changes in Software thinking since it was first written in 2001.
    - noblethrasher 11y ago
      > Yeah, good luck with that. OO is great but I'm not sure major redesigns are any easier in OO compared to any other arch. It depends on what they mean by OO. I can't find a source at the moment, but I've heard of Smalltalk applications that have been running the "same" incrementally modified image[1] since the 1970s or 1980s. http://en.wikipedia.org/wiki/Smalltalk#Image-based_persistence http://en.wikipedia.org/wiki/Smalltalk#Image-based_persisten...
  - vezzy-fnord 11y ago
    Hurd is a bunch of servers on top of Mach (there were attempts to get it ported to L4, Coyotos and some other kernels, but they all sadly fizzled out), so it is dated in many extents. The main deal is the concept of translators, which are similar to 9P file servers and namespaces, and how all the Hurd servers are implemented. This design also enables easy persistence. There is no trend between "object-oriented" and "interface-oriented" design, they're both terms with lots of meanings. The actor model is a form of object model. It's not necessarily bad. The Hurd actually has its own system for running multiple concurrent instances of itself, subhurds: https://www.gnu.org/software/hurd/hurd/subhurd.html https://www.gnu.org/software/hurd/hurd/subhurd.html Application containers still depend on a host OS. In fact, they're basically a way to partition the OS resources and library namespace so that you can get around its deficiencies by limiting each logical software bundle to a sub-OS. Each individual container is not any more malleable than what the host OS provides. It's quite the hack, really. Unikernels/libOS are great, but they're just another technique that harkens back to the old days of writing code to initialize the machine, except it's now reusable through virtualization and library linking. Full OS deployments can still be useful.

Advantages: http://www.gnu.org/software/hurd/advantages.html http://www.gnu.org/software/hurd/advantages.html http://www.gnu.org/software/hurd/community/weblogs/ArneBab/technical-advantages-of-the-hurd.html http://www.gnu.org/software/hurd/community/weblogs/ArneBab/t...

bsaul 11y ago
Just read the advantages, some parts seem a bit old. Touting object oriented design as something enabling refactoring, whereas the trend for the last fifteen years has been toward interface-oriented design (with golang being the most extreme case). Also, in a world of unikernels and app containers (trending toward the most static and restricted deployment unit possible), having an os being able to change its parts while running seems a bit useless. But, who knows ? maybe we'll see new patterns emerge. That's a fantastic time for people interested in OSes.
- codeulike 11y ago
  the Hurd has an object-oriented structure that allows it to evolve without compromising its design. This structure will help the Hurd undergo major redesign and modifications without having to be entirely rewritten. Yeah, good luck with that. OO is great but I'm not sure major redesigns are any easier in OO compared to any other arch. Having a completely different OS arch in play does sound good though, perhaps opening up possibilities we havent realised yet. Perhaps someone should re-write that 'advantages' page to encompass the massive changes in Software thinking since it was first written in 2001.
  - noblethrasher 11y ago
    > Yeah, good luck with that. OO is great but I'm not sure major redesigns are any easier in OO compared to any other arch. It depends on what they mean by OO. I can't find a source at the moment, but I've heard of Smalltalk applications that have been running the "same" incrementally modified image[1] since the 1970s or 1980s. http://en.wikipedia.org/wiki/Smalltalk#Image-based_persistence http://en.wikipedia.org/wiki/Smalltalk#Image-based_persisten...
- vezzy-fnord 11y ago
  Hurd is a bunch of servers on top of Mach (there were attempts to get it ported to L4, Coyotos and some other kernels, but they all sadly fizzled out), so it is dated in many extents. The main deal is the concept of translators, which are similar to 9P file servers and namespaces, and how all the Hurd servers are implemented. This design also enables easy persistence. There is no trend between "object-oriented" and "interface-oriented" design, they're both terms with lots of meanings. The actor model is a form of object model. It's not necessarily bad. The Hurd actually has its own system for running multiple concurrent instances of itself, subhurds: https://www.gnu.org/software/hurd/hurd/subhurd.html https://www.gnu.org/software/hurd/hurd/subhurd.html Application containers still depend on a host OS. In fact, they're basically a way to partition the OS resources and library namespace so that you can get around its deficiencies by limiting each logical software bundle to a sub-OS. Each individual container is not any more malleable than what the host OS provides. It's quite the hack, really. Unikernels/libOS are great, but they're just another technique that harkens back to the old days of writing code to initialize the machine, except it's now reusable through virtualization and library linking. Full OS deployments can still be useful.