Hacker News Reader

Comment by bediger4000 | Hacker News Reader

Super good question. I owned and used NeXT slabs, 1992 - 1999.

The Mach-as-microkernel thing couldn't have helped portability. The Mach task, port, thread and pager abstractions seem like they'd be difficult to port, but I could be wrong.

I read at the time that NeXTStep the GUI ran faster on Solaris than on Mach, because pipes and sockets were faster than Mach ports. So I'll believe the very little assembly.

I suspect that Mach-O file format had something to do with the portability, you can put arbitrary sections in it. Some NeXT games kept image and sound "files" in a single huge Mach-O executable.

View on HN

Mach more than helped:

"Mach 3 (Figure B.1) moves the BSD code outside of the kernel, leaving a much smaller microkernel. This system implements only basic Mach features in the kernel; all UNIX-specific code has been evicted to run in user-mode servers. Excluding UNIX-specific code from the kernel allows replacement of BSD with another operating system or the simultaneous execution of multiple operating-system interfaces on top of the microkernel. In addition to BSD, user-mode implementations have been developed for DOS, the Macintosh operating system, and OSF/1. This approach has similarities to the virtual-machine concept, but the virtual machine is defined by software (the Mach kernel interface), rather than by hardware."

https://web.eecs.utk.edu/~qcao1/cs560/papers/mach.pdf

NeXT ran a Mach 2.0 variant. I forget which Mach features were absent, but NeXT unmistakeably ran 2.0

The BSD stuff was kind of bolted on. Very uneasy marriage there.

At one point DEC had a 2 Mach task system that could run VMS processes, but I'm pretty sure that was Mach 3.0 based.

That is to say, Mach 2.0 wasn't as advanced in portability, and the "portability" targeted was different.

Early in that timeline Solaris was heavily into being a "pure" System V r4. The pipes and sockets implementations were based on System V Streams -- the in joke was that streams were much more like sewers and they weren't pleasant. Numbers wise, they were perhaps 2 orders of magnitude slower than on SunOS (BSD based). At one state university, where a very "beefy" SPARCcenter 2000 was purchased to support 500 simultaneous users, Solaris on this system could barely support 40 users (streams performance was the reason - telnet sessions pushed several streams modules). Sun ended up having to provide 10 SPARCstation 10 systems running SunOS which could easily support 70 simultaneous users each in order to fulfill the contractual obligations. The SPARCcenter 2000 was turned into an NFS file server.

After the early days, Solaris did improve, but I think that was because ideas / pieces of BSD (from SunOS) were put back into the OS.

I don't think Solaris pipes / sockets performed better than Mach.

Early Solaris was definitely not very good. I briefly ran Solaris 2.4 on a SparcStation 5, and reinstalled SunOS 4.1.x because Solaris 2.4 was so bad. 2.5 was decent though!

The impression I always got from those abstractions were that they were precisely there to support portability. Pagers, for example, are quite flexible about what can back them and what the geometry of that backing can be.

Yes, but it was explicitly a different kind of portability: running MSDOS or VMS executables unchanged, for example.

The task/port/thread/pagers are primitives that let Mach run some other OS executables, not made it easy to port Mach to other hardware. There were papers about getting MSDOS and VMS executables to run in Mach tasks. Some startup was making a system to run (pre-OSX) Mac executables.

Reply on news.ycombinator.com