5 ms·

Why is it that Apple apparently is so keen on Mach? As I understand it, both this and XNU/Darwin/OSX have Mach in the lower layers. And if it adds so much value

by 0x0 11y ago

Why is it that Apple apparently is so keen on Mach? As I understand it, both this and XNU/Darwin/OSX have Mach in the lower layers. And if it adds so much value, why doesn't regular Linux distributions build on top of this?

gaze 11y ago
Avi. Literally just Avi really wanted it.
fucking_tragedy 11y ago
Completely different kernel principles, designs and architectures. Regular Linux distributions would have to rewrite the kernel, hope it's accepted upstream, fork or patch-and-pray. I'm sure certain concepts were borrowed from Mach and implemented in Linux and the other way around. https://en.wikipedia.org/wiki/Mach_(kernel)#Mach_concepts https://en.wikipedia.org/wiki/Mach_(kernel)#Mach_concepts > And if it adds so much value, It isn't that simple. There are tradeoffs made with every kernel design decision.
- 0x0 11y ago
  What I still don't understand is, for a project like MkLinux to exist, they must have looked at Linux and decided that a (non-mk-)linux kernel was lacking something?
  - wmf 11y ago
    They probably thought that porting Linux to run on Mach and porting Mach to PowerPC was less work than porting Linux to PowerPC. In retrospect, this was not true.
    - riffraff 11y ago
      I don't think that would be true, I recall yellowdog linux was running on macs at the same time.
asveikau 11y ago
Just looking at it from the outside, I have to guess it's because they have had people who know Mach very well going back to the NeXT days, when key Mach figure Avie Tevanian was there. Even if a lot of those original people are gone now I am sure a lot of Mach knowledge and momentum has been built up over the years due to this early decision. People often tend to stick with what they know.
vezzy-fnord 11y ago
Mach had an unusually large amount of fanfare starting from its introduction at USENIX circa 1985 up to the mid-90s. It was envisioned as a generic resource multiplexer to build all sorts of platforms on top of, and particularly for emulating Unix. You had single-server Unixes like Lites and OSF/1 (the latter sold commercially by DEC as Tru64 UNIX), plus multi-server systems like Mach-US, MASIX, MK++ (for high assurance) and GNU Hurd. In the late 80s, the Open Software Foundation (OSF) was founded as a consortium of seven major tech companies spearheaded by DEC to standardize Unix in response to AT&T and Sun's adoption of SVR4. They adopted Mach as part of this and ended up extending it to add locksets, semaphores and resource ledgers. MkLinux was then a joint effort in 1996 by Apple and the OSF to both have Linux on the PPC and exploit Mach features in the single-server emulation. As such, the history is convoluted. It's not that Mach is so great, but rather that circumstances made it creep in various places.
luckydude 11y ago
I was big into OS dev when Mach was coming around but I was a newbie. I read all the Mach papers with stars in my eyes, it all sounded so good. I wasn't alone in getting drawn in by the research papers. I went to Sun and learned how a kernel could work and could perform and the allure of Mach, for me, started to wane. Reading the mach code made it worse, especially compared to the Sun code. All these years later, I remain underwhelmed. Linux has a nicer VM system, performs better, and is more readable. Not Sun level readable by any stretch, but better than my memory of mach (which, to be fair, is in the distant past). If someone can point to actual real world data that shows Mach to be better performing on the same hardware I'd be interested in seeing that, I tend to think that's not possible. If you want to see what a real microkernel done right looks like, go look at QNX before they added the POSIX conformance. You have 4-5 people logged into an 80286 doing work. Very, very light weight and well done. They were the only guys that understood what the "micro" in microkernel meant. I remember Dan Hildebrandt telling me that the microkernel easily fit in a 4K instruction cache (it pretty much had to, it didn't do much so you needed some space for whatever it was dispatching).
- oscargrouch 11y ago
  As someone that loves to dig into source code to see how things are done... Solaris source is the state-of-the-art. If there's a "beautiful" kernel, Solaris is definitely the one. QNX also is one very well made kernel(its like a OS created by a zen master). It's a pity that sun took so long to open the source of Solaris, or else i could be typing this from a solaris kernel, instead of Linux.
  - snw 11y ago
    well... there is illumos
    - oscargrouch 11y ago
      The solaris source code was open, i believe in 2005.. then came OpenSolaris in 2008.. and then the Illumos fork, if i recall correctly in 2010, after Oracle bought Sun.. But even in 2005, when they decided to open the source, it was already too late, because Linux was already a big hit by that time. But, to use Illumos as a first machine, can be really painful, exactly because of the lack of adoption, and the lack of drivers and software as a consequence... that's the reason of my comment about the time to open the code.. and Oracle closing it up again, didnt help it either. I would definetly consider Ilummos as a server node.. but for a personal machine.. it can get painful really easy, if you use for development like i do.
lobster_johnson 11y ago
It's my understanding that Apple has, over the years, gradually supplanted the parts of Mach that really matter. For example, Apple no longer relies on the Mach port mechanism for IPC, instead mostly relying on their own, better XPC, which forms the foundation for libdispatch (aka Grand Central) and OS X's sandboxing. Of course, XNU is also a monolithic kernel, not a microkernel. Transitioning to a different kernel would probably be a costly mostly-zero-velocity project for Apple, especially now that they are no longer in the server OS space. A different kernel might require replacing IOKit, unless one could write a compatibility layer for it.
- vezzy-fnord 11y ago
  XPC is a layer on top of Mach ports, however.
- umanwizard 11y ago
  Ever low-level debugged a running process on OS X ? Mach ports and Mach messages are used loads.
msbarnett 11y ago
Avie Tevanian was a key player in the Mach research project at CMU, and when Jobs brought him onboard at NeXT, he made his work with Mach the basis of NeXTStep. When Apple bought NeXT, Tevanian became CTO as part of the reverse management takeover. The Mach version underlying Openstep was updated for OS X, but kept around since Tevanian was very much a Mach booster.
mwfunk 11y ago
There was a period of time in the '80s when it was widely assumed by the software cognescenti that microkernels were the future. A lot of companies were experimenting with them. A lot of these experimental OSes were based on Mach. GNU Hurd has always been based on Mach. This makes sense because it began development in 1990, and at the time that might've seemed like both a forward thinking and sensible thing to do. NeXTStep was based on a Mach+BSD kernel, which at the time would've been an obvious thing to do if your goal was to create a modernized Unix system with all the latest cutting-edge (in the mid-80s!) technologies available. That kernel lives on in OS X and its descendants. It was always built as a monolithic kernel, AFAIK. It just differed from a traditional BSD kernel in that the lowest layers (VM, process, thread, and scheduler stuff) were replaced by the Mach microkernel. I believe that this kind of monolithic Mach+BSD arrangement was a pretty common thing to do when developing a Mach-based Unix implementation. From the outside it's almost indistinguishable from a BSD kernel. So why not just use an ordinary BSD kernel? Because it future-proofs the design. It gives you an easy path to gradually moving kernel-space services out of the core kernel and into separate address spaces, as microkernel technology improves and it becomes practical to do so. Of course, that never really happened, but it was a very logical choice at the time. There were other benefits to Mach- you also got multithreading (this was a big deal, mid-80s remember), as well as Mach IPC. Mach IPC has its pros and cons, but just being able to have user and kernel services communicate via arbitrarily defined protocols rather than having to constantly add new system calls is very convenient. That's pretty much it. This system has been around for > 30 years now, and even though it never turned into a true microkernel system, there probably was never much of a reason to de-Machify it either. It would be a ton of work and you wouldn't gain anything. It's not that Mach is so awesome (although it has some niceties), it's more that there's a lot of momentum there, and you wouldn't really gain anything by rewriting all that code. As for why Linux distributions don't use it, the same reasons apply. It'd be too much work for relatively little benefit. It made sense to base your cutting edge kernel on Mach in 1985, not so much 30 years later. It doesn't make sense for OS X to stop using it for the reasons given above, but it also doesn't make much sense for anyone who isn't already using it to base new stuff on top of it today.

by 0x0 11y ago

gaze 11y ago

Avi. Literally just Avi really wanted it.

fucking_tragedy 11y ago

Completely different kernel principles, designs and architectures. Regular Linux distributions would have to rewrite the kernel, hope it's accepted upstream, fork or patch-and-pray. I'm sure certain concepts were borrowed from Mach and implemented in Linux and the other way around. https://en.wikipedia.org/wiki/Mach_(kernel)#Mach_concepts https://en.wikipedia.org/wiki/Mach_(kernel)#Mach_concepts > And if it adds so much value, It isn't that simple. There are tradeoffs made with every kernel design decision.

0x0 11y ago
What I still don't understand is, for a project like MkLinux to exist, they must have looked at Linux and decided that a (non-mk-)linux kernel was lacking something?
- wmf 11y ago
  They probably thought that porting Linux to run on Mach and porting Mach to PowerPC was less work than porting Linux to PowerPC. In retrospect, this was not true.
  - riffraff 11y ago
    I don't think that would be true, I recall yellowdog linux was running on macs at the same time.

asveikau 11y ago

Just looking at it from the outside, I have to guess it's because they have had people who know Mach very well going back to the NeXT days, when key Mach figure Avie Tevanian was there. Even if a lot of those original people are gone now I am sure a lot of Mach knowledge and momentum has been built up over the years due to this early decision. People often tend to stick with what they know.

vezzy-fnord 11y ago

Mach had an unusually large amount of fanfare starting from its introduction at USENIX circa 1985 up to the mid-90s. It was envisioned as a generic resource multiplexer to build all sorts of platforms on top of, and particularly for emulating Unix. You had single-server Unixes like Lites and OSF/1 (the latter sold commercially by DEC as Tru64 UNIX), plus multi-server systems like Mach-US, MASIX, MK++ (for high assurance) and GNU Hurd. In the late 80s, the Open Software Foundation (OSF) was founded as a consortium of seven major tech companies spearheaded by DEC to standardize Unix in response to AT&T and Sun's adoption of SVR4. They adopted Mach as part of this and ended up extending it to add locksets, semaphores and resource ledgers. MkLinux was then a joint effort in 1996 by Apple and the OSF to both have Linux on the PPC and exploit Mach features in the single-server emulation. As such, the history is convoluted. It's not that Mach is so great, but rather that circumstances made it creep in various places.

luckydude 11y ago

I was big into OS dev when Mach was coming around but I was a newbie. I read all the Mach papers with stars in my eyes, it all sounded so good. I wasn't alone in getting drawn in by the research papers. I went to Sun and learned how a kernel could work and could perform and the allure of Mach, for me, started to wane. Reading the mach code made it worse, especially compared to the Sun code. All these years later, I remain underwhelmed. Linux has a nicer VM system, performs better, and is more readable. Not Sun level readable by any stretch, but better than my memory of mach (which, to be fair, is in the distant past). If someone can point to actual real world data that shows Mach to be better performing on the same hardware I'd be interested in seeing that, I tend to think that's not possible. If you want to see what a real microkernel done right looks like, go look at QNX before they added the POSIX conformance. You have 4-5 people logged into an 80286 doing work. Very, very light weight and well done. They were the only guys that understood what the "micro" in microkernel meant. I remember Dan Hildebrandt telling me that the microkernel easily fit in a 4K instruction cache (it pretty much had to, it didn't do much so you needed some space for whatever it was dispatching).

oscargrouch 11y ago
As someone that loves to dig into source code to see how things are done... Solaris source is the state-of-the-art. If there's a "beautiful" kernel, Solaris is definitely the one. QNX also is one very well made kernel(its like a OS created by a zen master). It's a pity that sun took so long to open the source of Solaris, or else i could be typing this from a solaris kernel, instead of Linux.
- snw 11y ago
  well... there is illumos
  - oscargrouch 11y ago
    The solaris source code was open, i believe in 2005.. then came OpenSolaris in 2008.. and then the Illumos fork, if i recall correctly in 2010, after Oracle bought Sun.. But even in 2005, when they decided to open the source, it was already too late, because Linux was already a big hit by that time. But, to use Illumos as a first machine, can be really painful, exactly because of the lack of adoption, and the lack of drivers and software as a consequence... that's the reason of my comment about the time to open the code.. and Oracle closing it up again, didnt help it either. I would definetly consider Ilummos as a server node.. but for a personal machine.. it can get painful really easy, if you use for development like i do.

lobster_johnson 11y ago

It's my understanding that Apple has, over the years, gradually supplanted the parts of Mach that really matter. For example, Apple no longer relies on the Mach port mechanism for IPC, instead mostly relying on their own, better XPC, which forms the foundation for libdispatch (aka Grand Central) and OS X's sandboxing. Of course, XNU is also a monolithic kernel, not a microkernel. Transitioning to a different kernel would probably be a costly mostly-zero-velocity project for Apple, especially now that they are no longer in the server OS space. A different kernel might require replacing IOKit, unless one could write a compatibility layer for it.

vezzy-fnord 11y ago
XPC is a layer on top of Mach ports, however.
umanwizard 11y ago
Ever low-level debugged a running process on OS X ? Mach ports and Mach messages are used loads.

msbarnett 11y ago

Avie Tevanian was a key player in the Mach research project at CMU, and when Jobs brought him onboard at NeXT, he made his work with Mach the basis of NeXTStep. When Apple bought NeXT, Tevanian became CTO as part of the reverse management takeover. The Mach version underlying Openstep was updated for OS X, but kept around since Tevanian was very much a Mach booster.

mwfunk 11y ago

There was a period of time in the '80s when it was widely assumed by the software cognescenti that microkernels were the future. A lot of companies were experimenting with them. A lot of these experimental OSes were based on Mach. GNU Hurd has always been based on Mach. This makes sense because it began development in 1990, and at the time that might've seemed like both a forward thinking and sensible thing to do. NeXTStep was based on a Mach+BSD kernel, which at the time would've been an obvious thing to do if your goal was to create a modernized Unix system with all the latest cutting-edge (in the mid-80s!) technologies available. That kernel lives on in OS X and its descendants. It was always built as a monolithic kernel, AFAIK. It just differed from a traditional BSD kernel in that the lowest layers (VM, process, thread, and scheduler stuff) were replaced by the Mach microkernel. I believe that this kind of monolithic Mach+BSD arrangement was a pretty common thing to do when developing a Mach-based Unix implementation. From the outside it's almost indistinguishable from a BSD kernel. So why not just use an ordinary BSD kernel? Because it future-proofs the design. It gives you an easy path to gradually moving kernel-space services out of the core kernel and into separate address spaces, as microkernel technology improves and it becomes practical to do so. Of course, that never really happened, but it was a very logical choice at the time. There were other benefits to Mach- you also got multithreading (this was a big deal, mid-80s remember), as well as Mach IPC. Mach IPC has its pros and cons, but just being able to have user and kernel services communicate via arbitrarily defined protocols rather than having to constantly add new system calls is very convenient. That's pretty much it. This system has been around for > 30 years now, and even though it never turned into a true microkernel system, there probably was never much of a reason to de-Machify it either. It would be a ton of work and you wouldn't gain anything. It's not that Mach is so awesome (although it has some niceties), it's more that there's a lot of momentum there, and you wouldn't really gain anything by rewriting all that code. As for why Linux distributions don't use it, the same reasons apply. It'd be too much work for relatively little benefit. It made sense to base your cutting edge kernel on Mach in 1985, not so much 30 years later. It doesn't make sense for OS X to stop using it for the reasons given above, but it also doesn't make much sense for anyone who isn't already using it to base new stuff on top of it today.