Forgetting the history of Unix is coding us into a corner
- Reference: 1708086131
- News link: https://www.theregister.co.uk/2024/02/16/what_is_unix/
- Source link:
This article is the second based on The Reg FOSS desk's [1]talk at FOSDEM 2024 (part 1 was [2]Drowning in code ). FOSDEM is a conference all about free and open source software, and these days, perhaps regrettably, FOSS is about Unix. Increasingly, [3]Unix today is Linux . The problem is that everyone is forgetting what UNIX really is and knowing your history is essential. As George Santayana said, often misquoted:
Progress, far from consisting in change, depends on retentiveness. When change is absolute there remains no being to improve and no direction is set for possible improvement: and when experience is not retained, as among savages, infancy is perpetual. Those who cannot remember the past are condemned to repeat it.
It's often misquoted, which may be why Henry Spencer (who did the original [4]FOSS implementation of regex) [5]paraphrased it as:
Those who do not understand Unix are condemned to reinvent it, poorly.
What Santayana predicted is coming true around the world today, and so is what Spencer predicted. There are other options, but few even look at them. Why is that?
What is 'Unix' anyway?
First things first, it doesn't mean anything related to the original AT&T codebase. That definition hasn't been true since 1993. [6]Novell bought Unix from AT&T 31 years ago, kept the code, and donated the UNIX trademark to the Open Group. Since then, the name "Unix" has meant "passes Open Group testing," which is broadly what POSIX used to mean. The original codebase is effectively gone. [7]SCO Group offshoot Xinuos still sells things based on it, but their main product is based on FreeBSD.
But alongside macOS on both x86-64 and Arm64 and a handful of other OSes, such as HP/UX and IBM AIX, in the [8]Open Group register of UNIX® certified products , there used to be two different Linux distros, [9]Huawei EulerOS and [10]Inspur K/UX , both Chinese CentOS Linux derivatives. Like it or not, this means that Linux isn't "a Unix-like OS" any more. It is a Unix.
It's a member of a [11]big family of Unixes . Even the [12]simplified version [PDF] from Cambridge University shows nearly 30 branches. The Wikipedia family tree shows lots of branches and lines: Version 1 to 4, then Version 5 to 6, then Version 7, System III and System V … plus lots and lots of derivatives, mostly proprietary, and all the BSDs. And of course Linux, with zero shared code, but a shared design .
[13]
But if you take another step back, given that Unix now means compatibility, they are all one branch . It's not about lines of descent any more, because in a sense, what was once the POSIX definition became Unix. But if your goal is simply to pass compatibility tests, you can do that with a shim, some kind of compatibility layer. That's why several versions of IBM z/OS are on the Open Group List. That seems strange because they are not Unix-like at all.
[14]
[15]
This leads to other questions, such as what constitutes a "Unix-like" OS anyway? Anyone who has a basic idea of how to work with Linux, or macOS from inside the terminal, knows what a Unix looks like. Some identifying characteristics are:
One file system, rooted at / .
A shell. (It doesn't matter which one: bash , tcsh , zsh .)
Commands like ls , cat , echo , mkdir , rmdir , touch .
A case-sensitive file system.
Plain text files, and commands connected with redirection and pipes.
Certainly, there can be exceptions to these. For instance, macOS is a Unix™. It passes the tests, and Apple pays for the certification. But it hides most of the real Unix directory tree, its /etc is relatively empty, it doesn't have an X server – it's an [16]optional extra . And most of all, it's not case sensitive.
But all the same, it's still recognizably a Unix.
So taking that list of general characteristics, and adding a less visible one – that it's programmed mainly in C or something C-like – and requiring that the OS looks like Unix and nothing else , meaning there's no other native layer underneath, then the family is bigger.
[17]
So if it's just about compatibility and we don't care about who inherited code from where any more, this raises other questions. How can we categorize them? What is a Unix-like OS anyway?
Generations and the gaps between
Looking at the successive projects in the original Unix family within AT&T is very instructive. For its first decade, Unix was a research project, not a commercial product, and in that time it went through about seven generations.
The thing is that even when other projects started branching off from it and going their own way from between Unix V4 and V8, the original research project kept going. Both the Wikipedia and Cambridge family trees show the AT&T line stopping after the Tenth Edition. But actually, there were two more generations.
If we consider that whole extended family to be one unit, one box on the chart, that leaves a few outliers. Linux is one. Minix is another. There are others that aren't shown, and a whole category of them are very much Unix-like systems: the microkernels.
The original microkernel, [18]CMU Mach , led to a whole bunch of Unix OSes, including the [19]Open Group's OSF/1 and [20]DEC Tru64 , as well as [21]MkLinux and famously the [22]GNU HURD . The only one that isn't a historical curiosity or a tiny neglected niche is Apple's macOS family, including iOS, iPadOS and so on.
[23]
Dr Andy Tanenbaum's Minix, which was an indirect progenitor of Linux itself, is another, although Minix 1 and 2 were largely monolithic. [24]Minix 3 , though, is a true microkernel, and a version runs inside most modern Intel CPUs' management processors.
There are others. The research on Mach led to [25]L4 and [26]others , and work's [27]still going on . [28]QNX is a commercial microkernel Unix-like OS, and it's used in billions of embedded devices … although the only time you might have played with it was [29]Blackberry 10 .
[30]Damn Small Linux returns after a 12-year gap
[31]Drowning in code: The ever-growing problem of ever-growing codebases
[32]PiStorm turbocharges vintage Amigas with the Raspberry Pi
[33]KDE 6 misses boat to make it into Kubuntu 24.04
Although they have enjoyed more success than you might think, microkernels are hard to get working well. Tiny kernels with lots of user-space processes doing stuff are not so hard – AmigaOS did this successfully in the mid-1980s. The problem is keeping the various processes isolated, yet able to communicate with each other. AmigaOS ran on machines with no memory management hardware – everything was in one address space. It's easy to communicate with another process when you can read and write its memory.
The idea of a true microkernel is that the kernel runs in ring 0, in supervisor mode. It schedules processes, it allocates memory, and that's about it. Everything else is implemented in "servers" in user space. Getting them to talk to each other quickly is the hard problem.
For instance, macOS uses Mach, but to provide Unix-compatible APIs so it looks like a Unix, it took a big chunk of the BSD kernel and called it a "Unix server." Mach still manages the processes, not this Unix server, but even so, the server is still big and complicated. And it still wasn't that fast, so NeXT moved it inside the Mach kernel, meaning it's in kernel space too, running in the same memory space as the not-so-micro-any-more Mach kernel.
This leaves us with two families of Unix-like OSes. Monolithic kernels, which includes almost all the old proprietary commercial Unixes, and all the BSDs – and Linux. Plus microkernels, which we can very loosely group into two families. One is commercial, and today mainly means Apple's OSes and QNX. QNX is proprietary, while Apple's kernel and userland is open source but hasn't influenced much else.
And an open source family, including Minix 3, the GNU Hurd, L4, seL4, and many others. Some are used in embedded control systems – such as [34]Intel's ME – but there is little visible mainstream use.
But that is not the end of the line. It is all that most histories show, but there is a third line of descent. Dennis Ritchie and Ken Thompson's work didn't end in 1979 with Unix 7, even if that's where most commercial Unix originated.
Turn it up to 11
The versions of Unix after the Seventh Edition are sometimes collectively called [35]Research Unix , and when I have asked about this online, it has resulted more in people telling me that's wrong than much useful information.
Even so, the lesser-known editions within AT&T's Unix System Laboratories were the Eighth Edition in 1985, the Ninth Edition in 1986, and in 1989 the Tenth Edition. Some fragmentary [36]source code is available , but little information. (Working links or references to what was in these are welcome!)
What came after the Tenth Edition is, for this writer, where it gets interesting. By 1992, Unix was big commercial news, of course. FreeBSD and NetBSD were happening, and Linux was gathering attention.
Meanwhile, Bell Labs did something else.
Think about what constitutes traditional, old-school Unix. It's about [37]"everything is a file," streams of bytes, the familiar shell, and so on. But there are important things on all modern computers that aren't covered by this.
Graphics, notably, don't really form part of the classic Unix kernel. macOS and Linux are both Unixes, as is BSD, but they have radically different GUI layers. This is because Unix was a [38]minicomputer OS. As [39]Dennis Ritchie himself described , it was written on a [40]DEC PDP-7 , and later ported to the bigger [41]DEC PDP-11 .
These were departmental-scale, multiuser computers. A host machine, plus dumb text terminals on serial connections, with no graphics and no networking – even so, high-end kit for the 1970s.
During the period when commercial Unix flowered, in the 1980s there were very expensive workstations : effectively, personal, single-user minicomputers. It took until the late 1980s for equipment like inexpensive 32-bit computers with onboard graphics, reasonably fast expansion buses (and thus, reasonably fast networking as a fairly cheap option) to start to be mainstream. Then Unix acquired networking support, as it still has. But ways for one Unix machine to talk to another wasn't considered in the original design. Instead, it has files of terminal type definitions. Even today, decades later, networking and graphics need auxiliary, helper tools, such as NFS, SSH, X11, and so on. It works, and it works very well, but these are bolted-on extras that appeared years after the design was set in stone.
This is the point at when Unix Tenth Edition appeared, in 1989, when networking and GUIs were proliferating everywhere.
Today, the Wayland enthusiasts like to talk about how they are modernizing the Linux graphics stack. But Linux is a Unix, and in Unix, [42]everything is meant to be a file . So any Wayland evangelists out there, tell us: where in the file system can I find the files describing a window on the screen under the Wayland protocol? What file holds the coordinates of the window, its place in the Z-order, its colour depth, its contents?
If this stuff is not in the file system, are you sure this is a Unix tool?
Research Unix 10 started to address some of this, but it was too little, too late. The industry had taken much older, simpler versions, commercialized them, and the results were mutating and metastasizing across the world.
So Dennis Ritchie and Ken Thompson did [43]what Niklaus Wirth did with Modula-2 and later with Oberon. They ignored what the industry was doing, went back to their original ideas, and kept working on refining them.
The result is the next step in the development of Unix, and in this era of spiralling software complexity and bloat, it's time to examine it afresh and see if the geniuses who invented Unix didn't have the right ideas, just as Linux was being created. ®
Get our [44]Tech Resources
[1] https://fosdem.org/2024/schedule/event/fosdem-2024-3095-one-way-forward-finding-a-path-to-what-comes-after-unix/
[2] https://www.theregister.com/2024/02/12/drowning_in_code/
[3] https://www.theregister.com/2023/01/17/unix_is_dead/
[4] https://groups.google.com/g/mod.sources/c/OqVZYQNSmDs/m/G_T2jHu5QI8J
[5] https://groups.google.com/g/sci.space.shuttle/c/L8-Upf8gZoY/m/NN6ngTI0K0QJ
[6] https://www.theregister.com/2013/07/25/novell_peaked_with_netware_four/
[7] https://www.theregister.com/2021/03/31/ibm_redhat_xinuos/
[8] https://www.opengroup.org/openbrand/register/
[9] https://www.opengroup.org/openbrand/register/brand3622.htm
[10] https://www.opengroup.org/openbrand/register/brand3617.htm
[11] https://en.wikipedia.org/wiki/History_of_Unix#/media/File:Unix_history-simple.svg
[12] https://www.cl.cam.ac.uk/teaching/0708/OSFounds/P04-4.pdf
[13] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/oses&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2Zc@UvBmsAApIVysfyA9VzgAAAZM&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[14] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/oses&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44Zc@UvBmsAApIVysfyA9VzgAAAZM&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[15] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/oses&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33Zc@UvBmsAApIVysfyA9VzgAAAZM&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[16] https://www.xquartz.org/
[17] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/oses&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44Zc@UvBmsAApIVysfyA9VzgAAAZM&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[18] https://www.cs.cmu.edu/afs/cs/project/mach/public/www/mach.html
[19] https://kb.iu.edu/d/agoq
[20] https://kb.iu.edu/d/agoo
[21] https://www.mklinux.org/
[22] https://www.gnu.org/software/hurd/
[23] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/oses&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33Zc@UvBmsAApIVysfyA9VzgAAAZM&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[24] https://www.minix3.org/
[25] http://os.inf.tu-dresden.de/L4/
[26] https://www.l4ka.org/
[27] https://sel4.systems/
[28] https://blackberry.qnx.com/en
[29] https://www.theregister.com/2015/10/02/bb10_five_reasons_why_it_failed/
[30] https://www.theregister.com/2024/02/14/damn_small_linux_returns/
[31] https://www.theregister.com/2024/02/12/drowning_in_code/
[32] https://www.theregister.com/2024/02/12/pistorm_accelerated_amiga_pi/
[33] https://www.theregister.com/2024/02/06/no_kde6_for_noble/
[34] https://www.intel.com/content/www/us/en/support/articles/000008927/software/chipset-software.html
[35] https://en.wikipedia.org/wiki/Research_Unix
[36] https://www.theregister.com/2017/03/30/old_unix_source_code_opened_for_study/
[37] http://ibgwww.colorado.edu/~lessem/psyc5112/usail/concepts/filesystems/everything-is-a-file.html
[38] https://www.britannica.com/technology/minicomputer
[39] https://www.bell-labs.com/usr/dmr/www/hist.html
[40] https://www.soemtron.org/pdp7.html
[41] https://gunkies.org/wiki/PDP-11/20
[42] https://hackmd.io/@jkyang/unix-everything-is-a-file
[43] https://www.theregister.com/2024/01/04/niklaus_wirth_obituary/
[44] https://whitepapers.theregister.com/
And stuff that Poettering hasn't touched.
and EXCLUDES anything Wayland...
[Author here]
> Unix system calls
Yes indeed, and that is where the talk went next. I originally planned this to be all in 1 article but it would have made it impossibly long -- about twice this already-excessive length.
Come back for next week's exciting episode!
I wondered if I might have been anticipating where you were going.
Before reaching the cliff-hanger, I thought the conclusion was going to be Plan 9...
Also...
The Unix philosophy for the various parts were do one thing and do it well which is why things such as SystemD are anathema to many.
Re: Also...
The one bit they seem to have done well is control of services...
The rest I'm not so sure about.
Not *everything* is a file
Surely it's that everything *required for inter-process communication* is a file? What you're describing sounds like internal state to me.
I don't know Wayland at all, but I'm fairly certain that if there is a way for unrelated processes to communicate with the Wayland compositor, it's done by means of a UNIX socket, TCP socket, pipe, pseudo-filesystem, shared memory mapped or message-queue, because (from memory) those are all the options for inter-process communications on UNIX. And they all live behind a file-like interface (definition stretched slightly for TCP sockets). Did I miss any?
Re: Not *everything* is a file
I think the original idea was that everything was a represented by a name somewhere in the tree of mounted filesystems, and was manipulated by one of a small number of system calls.
Unfortunately, things like sockets on top of IP don't have names. Network devices don't have names (relative to / ). USB devices don't have names... the list goes on, although in fairness the /state/ of many of those is often accessible via /sys or /proc (with, in the case of Linux, a layout decided entirely by the whim of the kernel module author).
And again unfortunately, there's a vast number of devices which have their own APIs funneled through ioctl() or accessible only via a private kernel-level API.
So in short: everything is a file (provided that it's a file).
The challenge for a putative C21st UNIX replacement would be generalising all possible devices to have a consistent minimal API, generalising all streams interacting with a device to have a consistent minimal API, and so on. And what I've seen of the industry over the last 50ish years doesn't encourage me to hold my breath waiting.
Re: Not *everything* is a file
Try ls -lR /dev
Re: Not *everything* is a file
And /you/ try netstat -an, which includes all of the ports your system exposes none of which appear directly in /dev.
Re: Not *everything* is a file
just a minor correction...
with respect to network layer, the basic I/O works exactly as it does for a serial device, from the standpoint of reading, writing, FCNTL, ioctl, polling, etc..
A program that accesses a serial port can just as easily work with a socket rather than a file identifier so long as you do not expect to change the baud rate, etc..
Other than that the socket API functions (like send, recv) are supersets of read/write (etc.), and you have connections for TCP. Yet the basic I/O looks the same from inside as well as outside.
So "everything is a file" still applies to sockets and networking.
In X11 the basic communication is client/server through sockets. I am not sure how Wayland does it, but there is NO "DISPLAY" environment variable to indicate which socket to communicate on, such as X11 would use for multiple displays and remote execution.
Re: Not *everything* is a file
Unfortunately, things like sockets on top of IP don't have names.
That's the way things have evolved, AT&T Research Unix introduced Streams which worked well both as a generalisation and allowing for some neat tricks. It would probably have taken off had it been five years earlier, but by then the sockets model was too engrained thanks to the BSDs and Sun in particular.
Re: Not *everything* is a file
It's slightly complicated by the fact that the Wayland protocol doesn't specify the IPC mechanism it uses, the compositor and the client have to agree on it. Weston, the reference implementation, uses UNIX domain sockets but there's no particular reason that a different IPC mechanism couldn't be used.
What is unix anyway?
"That's why several versions of IBM z/OS are on the Open Group List. That seems strange because they are not Unix-like at all."
Which has always struck me as very, very odd. It's like saying that OS/2 or Windows "is A Unix" by virtue of their compatibility layer. Or that a proprietary hypervisor becomes "A Unix" because it can run UNIX in a VM.
Or- and purists will find this really contentious- Linux becomes "A Unix" by virtue of running UNIX in a VM.
I have enormous respect for the classic IBM mainframe designs, and for the architecture of OS: which was astounding once they finally got it working, a worthy challenger to established products such as Burroughs's MCP. But many of its strengths that, for example, allow seamless process migration between members of a cluster, are fundamentally incompatible with UNIX: claiming z/OS is "A Unix" does neither justice.
Re: What is unix anyway?
It's like saying that OS/2 or Windows "is A Unix" by virtue of their compatibility layer.
I was wondering about the reverse of that prompted by the end of W10.
It would be possible, if there were sufficiently free space available, for a Linux installer to compact and shrink an NTFS partition and create a new partition into which to install a bootable Linux. The user's data files could be linked in to the new home directory.
But would it be possible to retain in place any Windows applications that couldn't be substituted, run them via Wine and reassure them that they were still on the same Windows machine on which they'd been registered?
Re: What is unix anyway?
That doesn't sound too difficult, and could basically be achieved by using different code and data search paths depending on the OS requirement of a particular application program.
The sticking point would be libraries and support programs that came with Windows, and couldn't- at least legitimately- be run on top of some other foundation OS.
However it does remind me of something that happened to a user on CIX (anybody remember CIX?) a considerable number of years ago, when WINE was much less mature than it is today. He came across something that he strongly suspected carried a (non-bootsector) virus, and idly ran it: it infected files in his application search path, which meant that malware-carrying files could be referenced directly by a carelessly-entered shell command.
Of course, Windows has improved enormously since that happened, albeit more by the inclusion of virus scanners and mandatory code signing than by inherent good design. Which makes me wonder how much of that "medicine" would work properly if the foundation OS was something other than Windows.
Re: What is unix anyway?
"The sticking point would be libraries and support programs that came with Windows, and couldn't- at least legitimately- be run on top of some other foundation OS."
Wine can run Windows applications without Windows being present so it must be (not!) emulating them already. What I'm pondering is whether it would pick up applications already installed in Windows as if it had installed them itself. If so then, at least at first sight, there should be no difference between Windows being there and not being there except for the paths where it finds them.
On the other hand the original installation might be directing the executables to use the installed Windows libraries. S do the "libraries and support programs" come with Windows or are they part of it? There would still be a registered* copy of Windows installed. If the libraries are part of that then while they're executing Windows would be executing. And how would that differ from running the original installation in a VM, which would be an alternative way of going about it?
Much the same applies to any support programs from the original installation although there would be a greatly reduced dependency on them as the Linux installation would largely take over their roles.
* Assuming it was legit in the first place unless Microsoft were to actually cancel licences when a version goes out of support.
Re: What is unix anyway?
Incidentally, if anybody is as perplexed by IBM's z/Wotzit range as I am, I can recommend the PDF at
https://www.ksp.kit.edu/site/books/m/10.5445/KSP/1000034624/
as a particularly good read. It goes into a lot of detail about IBM's mainframes up to the early 2010s, and does so in the context of "industry dominant" terminology: i.e. it describes a sysplex in the wider context of clustered systems and so on.
> The result is the next step in the development of Unix
I smell a plan 9 here...
Further reading?
Does this story continue somewhere and where does Plan 9 come into this?
Re: Further reading?
>> where does Plan 9 come into this?
Before reading the article, this was the only Plan 9 I was aware of....
https://www.imdb.com/title/tt0052077/?ref_=nv_sr_srsg_0_tt_7_nm_1_q_plan%25209
Re: Further reading?
Plan 9 from Out^H^H^H Bell Labs
Re: Further reading?
> Does this story continue somewhere
I have not yet adapted part 3 into article form, but the very first paragraph of the story links to both part 1 and to the FOSDEM talk it is based on. You can download the script and read it now if you're impatient, but note, it is essentially speaker's notes and not an article aimed at anyone else, just me.
Plan 9 was my thought as well ...
I actually downloaded Plan 9 and gave it a try. I admired it from a tech perspective but wasn't sure how it could be useful at that time ...
Best,
Lorie
I was thinking this was leading to a discussion on Plan 9
I actually downloaded Plan 9 at some point and gave it a try. I admired it from a tech perspective but wasn't sure how it could be useful at that time ... USL was actually across the street in Summit, New Jersey from where I worked for a few years ...
Best,
Lorie
"it's time to examine it afresh and see if the geniuses who invented Unix didn't have the right ideas,"
This is dangerous territory.
We'll end up arguing that C *used appropriately*, is pretty much the perfect tool for the job. Wait... what...?
...dusts off original K&R...
One thing that has/should change is...
...the user experience of a system should be decoupled from the OS.
Files and folders are how computers work, but this no longer how the user interaction should be defined.
Re: One thing that has/should change is...
"the user experience"
That phrase and "UX" vs "UI" always makes me *cringe*
It also reminds me of a joke: How many people in Silicon Valley does it take to change a light bulb? Three. One to physically change the bulb, and 2 to "share in the experience".
(that is assuming that anyone in Silly Valley even KNOWS what a light bulb IS...)
Re: One thing that has/should change is...
Files and folders are how computers work
Files and directories are how computers work
T,FTFY.
Linux use to be Unix
I no longer consider Linux to be Unix. I have worked with Unix on and off since 1988, and full time since 1997. For the last 8-10 years, Linux has become "Unix-like", abandoning many Unix philosophies. It has become more and more complex like Windows. Complexity is the bane of operating systems. Everyone seems to think they can do a subsystem better and forks the code. I do like some of the improvements made in Linux. And Linux has helped proprietary Unixes to improve their DE. Making Linux to look like Windows won't significantly increase its desktop presence.
It took until the late 1980s for equipment like inexpensive 32-bit computers with onboard graphics, reasonably fast expansion buses (and thus, reasonably fast networking as a fairly cheap option) to start to be mainstream. Then Unix acquired networking support, as it still has.
I'd date Unix networking more from the late 1970s when UUCP became standard, or perhaps around 1975 with RFC681.
Where is the story?
It just kind of ends... without ever circling back to the aledged point in the headline. Did somebof run out of ChatGPT tokens????
What Unix cost us
You can find a contrasting (not necessarily conflicting) viewpoint [1]here , and [2]here , wherein the author challenges the notion that the Unix way is the best way, the idea that "everything is a file" is inherent to the fuzzy-headed concept of the Unix philosophy, and, for good measure, makes a case for systemd. I know that latter point will garner me a lot of downvotes from the initd zombies along with some long-winded angry screeds; rest assured that while you're frothing angrily at your keyboard, I'm sitting back and experiencing amusement.
[1] https://youtu.be/9-IWMbJXoLM
[2] https://www.youtube.com/watch?v=o_AIw9bGogo
We need a new Unix
I personally think we need a new Unix, not based on the original ideas but on new ones. Where networking and GUI's are first class clients and not some afterthought shoehorned in.
I'm a fan of microkernels so I'd like to point out that another microkernel is missing in the list: MMURTL. It's described in a PDF book which can freely be downloaded and has some interesting takes, such as *no dynamic linked libraries* (the dreaded DLL's under Windows). Dynamic libraries are the instigators of misery in operating systems and doing away with them would save a world of pain.
Re: We need a new Unix
Draw up and implement your set of new ideas. What happens when a new new idea emerges? The test of the quality of your design is how well it gets accommodated.
The original Unix ideas were few and flexible so that networking and GUIs could be built on top. They didn't have to be built in as first-class clients (whatever that means).
If you start out be saying "this needs to be built in and that needs to be built in as special cases" then you're making assumptions about what belongs in there. Assumptions have a habit of becoming limitations.
If the new new idea violates the assumptions, you have to take the back off the system and build in another extra case. That way lies bloat.
The original ideas of extensible simplicity have lasted for decades and been scaled from some controller based on a Pi to supercomputers. That seems a good indication that they got things right.
If there's a case for a new Unix it has to be for removing cruft and getting back to the minimalism.
What is unix?
The pinpoint answer is, to me: fork() .Or a mechanism that similarily re-uses the address space.
If you want everything to look like a nail - I mean file - then we should be looking at UNIX II aka Plan 9, right?
MacOS Unix server?
I don't think MacOS has a Unix server. I'm pretty sure that the Unix system calls are supported directly by the OS kernel these days.
I certainly don't see one running on my MacBook.
The list of things that make something look like Unix needs to include Unix system calls.