4 ms·

I’m surprised to see that Mach is still the microkernel for Hurd. When I last (very casually) followed Hurd development two decades ago, Mach was generally rega

I’m surprised to see that Mach is still the microkernel for Hurd. When I last (very casually) followed Hurd development two decades ago, Mach was generally regarded as obsolete and there were hopes to base Hurd on a new microkernel like seL4.

m463 3y ago
Isn't macos Mach?
- mr_toad 3y ago
  A distant descendant. https://en.wikipedia.org/wiki/XNU https://en.wikipedia.org/wiki/XNU
- p_l 3y ago
  MacOS XNU is based on OSFMK which was also used by Tru64 and few others, and sometimes called "Mach 3.5" IIRC. One of the major differences was that it embedded the BSD server into kernel space.
rayiner 3y ago
HURD (the parts that aren't the rest of the GNU OS) is mainly a set of servers for Mach. These are closely coupled to how mach handles IPC, how it handles virtual memory, etc. Apparently, there were also shortcomings in L4 itself, or at least with respect to what HURD wants to do with its microkernel: https://www.gnu.org/software/hurd/history/port_to_another_microkernel.html https://www.gnu.org/software/hurd/history/port_to_another_mi...
- naasking 3y ago
  > Apparently, there were also shortcomings in L4 itself, or at least with respect to what HURD wants to do with its microkernel Yes, that was the issue as I recall. But seL4 is an excellent, secure high-performance microkernel. If something is painful to do in L4, it will likely not be faster or more secure running under any other microkernel, and so you should arguably question the wisdom of what you're trying to do.
marcosdumay 3y ago
Oh, interesting, people created a GNU clone of Mach, removing the licensing problem that all but killed the project early on its life. For the ones not in the know, Mach is an OS designed after the idea of "the network is your environment, not the computer" where it should make little difference if the resources you are accessing is on your computer or not. And "resource" here is really generic, meaning things like files, login information, printers and other periferals, CPU, whatever. For some reason (maybe related to costs and licensing), people never adopted the idea... and insisted on reimplementing it with unreliable hacks and lots and lots of problems on top of every other OS out there instead of just having it on the OS itself.
- cesarb 3y ago
  > For the ones not in the know, Mach is an OS designed after the idea of "the network is your environment, not the computer" where it should make little difference if the resources you are accessing is on your computer or not. And "resource" here is really generic, meaning things like files, login information, printers and other periferals, CPU, whatever. For some reason (maybe related to costs and licensing), people never adopted the idea To me, the reason is obvious: what happens when someone unplugs the network cable? This is #1 in the list of distributed computing fallacies (https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing https://en.wikipedia.org/wiki/Fallacies_of_distributed_compu...): "the network is reliable". The other fallacies on that list might also be relevant.
  - marcosdumay 3y ago
    > what happens when someone unplugs the network cable? About the same thing that happens when you unplug your corporate Windows machine. You only have cached and local resources. People insist on using all of that functionality. People also insist on implementing it by hacks everywhere with nothing talking with each other and each part failing for its own reasons.
- anyfoo 3y ago
  > an OS designed after the idea of "the network is your environment, not the computer" where it should make little difference if the resources you are accessing is on your computer or not. [..] For some reason (maybe related to costs and licensing), people never adopted the idea... I personally think it's a pipe dream, and the way history worked out seems to confirm that. Truly transparent networking never really worked out anywhere. The better RPC solutions in use, for example, make it very obvious that an RPC is an RPC, instead of looking like a local function call. In file transfer, it has been common to e.g. replace NFS with something HTTP based for quite some time. "Cloud" file systems seem to operate at a much higher layer, preferring external syncing and special high level APIs with only some actual OS support sprinkled in. For Operating Systems, a lot of Mach breaks down when you want to do things fast and securely. It's a testament to APIs better being shaped by locality. Roughly and informally spoken, the closer you are to the actual CPU, the more "lightweight" and "direct" your API can and should be. The further you move away, the more resilient you need to become, and the more control and insight you need to give the caller about the actual transport. To pick two very real extremes as an example: When writing to a register on a local bus, you often just assume it will work. If it doesn't, a panic is sensible (sometimes even worse, like a lockup leading to a watchdog timeout). When trying to invoke a function on another server, obviously that's not acceptable. Then you want to be able to timeout, retry, inspect transport failures, fall back to other servers, configure endpoints, be picky and explicit about payload (and result), and so on and so forth. The immense cruft necessary for the latter case becomes unnecessary and expensive the more local you are. It affects security, and can even pose chicken and egg problems.

m463 3y ago

Isn't macos Mach?

mr_toad 3y ago
A distant descendant. https://en.wikipedia.org/wiki/XNU https://en.wikipedia.org/wiki/XNU
p_l 3y ago
MacOS XNU is based on OSFMK which was also used by Tru64 and few others, and sometimes called "Mach 3.5" IIRC. One of the major differences was that it embedded the BSD server into kernel space.

rayiner 3y ago

HURD (the parts that aren't the rest of the GNU OS) is mainly a set of servers for Mach. These are closely coupled to how mach handles IPC, how it handles virtual memory, etc. Apparently, there were also shortcomings in L4 itself, or at least with respect to what HURD wants to do with its microkernel: https://www.gnu.org/software/hurd/history/port_to_another_microkernel.html https://www.gnu.org/software/hurd/history/port_to_another_mi...

naasking 3y ago
> Apparently, there were also shortcomings in L4 itself, or at least with respect to what HURD wants to do with its microkernel Yes, that was the issue as I recall. But seL4 is an excellent, secure high-performance microkernel. If something is painful to do in L4, it will likely not be faster or more secure running under any other microkernel, and so you should arguably question the wisdom of what you're trying to do.

marcosdumay 3y ago

Oh, interesting, people created a GNU clone of Mach, removing the licensing problem that all but killed the project early on its life. For the ones not in the know, Mach is an OS designed after the idea of "the network is your environment, not the computer" where it should make little difference if the resources you are accessing is on your computer or not. And "resource" here is really generic, meaning things like files, login information, printers and other periferals, CPU, whatever. For some reason (maybe related to costs and licensing), people never adopted the idea... and insisted on reimplementing it with unreliable hacks and lots and lots of problems on top of every other OS out there instead of just having it on the OS itself.

cesarb 3y ago
> For the ones not in the know, Mach is an OS designed after the idea of "the network is your environment, not the computer" where it should make little difference if the resources you are accessing is on your computer or not. And "resource" here is really generic, meaning things like files, login information, printers and other periferals, CPU, whatever. For some reason (maybe related to costs and licensing), people never adopted the idea To me, the reason is obvious: what happens when someone unplugs the network cable? This is #1 in the list of distributed computing fallacies (https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing https://en.wikipedia.org/wiki/Fallacies_of_distributed_compu...): "the network is reliable". The other fallacies on that list might also be relevant.
- marcosdumay 3y ago
  > what happens when someone unplugs the network cable? About the same thing that happens when you unplug your corporate Windows machine. You only have cached and local resources. People insist on using all of that functionality. People also insist on implementing it by hacks everywhere with nothing talking with each other and each part failing for its own reasons.
anyfoo 3y ago
> an OS designed after the idea of "the network is your environment, not the computer" where it should make little difference if the resources you are accessing is on your computer or not. [..] For some reason (maybe related to costs and licensing), people never adopted the idea... I personally think it's a pipe dream, and the way history worked out seems to confirm that. Truly transparent networking never really worked out anywhere. The better RPC solutions in use, for example, make it very obvious that an RPC is an RPC, instead of looking like a local function call. In file transfer, it has been common to e.g. replace NFS with something HTTP based for quite some time. "Cloud" file systems seem to operate at a much higher layer, preferring external syncing and special high level APIs with only some actual OS support sprinkled in. For Operating Systems, a lot of Mach breaks down when you want to do things fast and securely. It's a testament to APIs better being shaped by locality. Roughly and informally spoken, the closer you are to the actual CPU, the more "lightweight" and "direct" your API can and should be. The further you move away, the more resilient you need to become, and the more control and insight you need to give the caller about the actual transport. To pick two very real extremes as an example: When writing to a register on a local bus, you often just assume it will work. If it doesn't, a panic is sensible (sometimes even worse, like a lockup leading to a watchdog timeout). When trying to invoke a function on another server, obviously that's not acceptable. Then you want to be able to timeout, retry, inspect transport failures, fall back to other servers, configure endpoints, be picky and explicit about payload (and result), and so on and so forth. The immense cruft necessary for the latter case becomes unnecessary and expensive the more local you are. It affects security, and can even pose chicken and egg problems.