Remembering How Plan 9 Evolved at Bell Labs - Slashdot
source link: https://tech.slashdot.org/story/24/02/25/1620222/remembering-how-plan-9-evolved-at-bell-labs
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
Remembering How Plan 9 Evolved at Bell Labs
Remembering How Plan 9 Evolved at Bell Labs (theregister.com) 15
Posted by EditorDavid
on Sunday February 25, 2024 @01:34PM from the forgotten-operating-systems dept.jd (Slashdot reader #1,658) writes: The Register has been running a series of articles about the evolution of Unix, from humble beginnings to the transition to Plan9. There is a short discussion of why Plan9 and its successors never really took off (despite being vastly superior to microkernels), along with the ongoing development of 9Front.
From the article:
Plan 9 was in some way a second implementation of the core concepts of Unix and C, but reconsidered for a world of networked graphical workstations. It took many of the trendy ideas of late-1980s computing, both of academic theories and of the computer industry of the time, and it reinterpreted them through the jaded eyes of two great gurus, Kenneth Thompson and Dennis Ritchie (and their students) — arguably, design geniuses who saw their previous good ideas misunderstood and misinterpreted. In Plan 9, networking is front and center. There are good reasons why this wasn't the case with Unix — it was being designed and built at the same time as local area networking was being invented. UNIX Fourth Edition, the first version written in C, was released in 1973 — the same year as the first version of Ethernet. Plan 9 puts networking right into the heart of the design. While Unix was later used as the most common OS for standalone workstations, Plan 9 was designed for clusters of computers, some being graphical desktops and some shared servers... Because everything really is a file, displaying a window on another machine can be as simple as making a directory and populating it with some files. You can start programs on other computers, but display the results on yours — all without any need for X11 or any visible networking at all. This means all the Unixy stuff about telnet and rsh and ssh and X forwarding and so on just goes away. It makes X11 look very overcomplicated, and it makes Wayland look like it was invented by Microsoft.
›
This makes various statements about a *research* deomnstrator to show it's superiority to *production* platforms.
For example, they point out how much simpler it is, because they have so many fewer function calls. Well, of *course* because they don't have user requirements driving to do any better. For example. the article even points out the "simplified, one fits all calls that can handle both remote and local resources as equals admittedly bogs down actually local resuorces. You could bet that if it were considered seriously for production, someone would demand a "shortcut" set of system calls for enhanced behavior.
Similarly, he asserts than plan 9 has "kubernetes" built in. It absolutely does not. It may have the same namespace, control group, and chroot facilities (I'm guessing..), but the kernel has that too.
Plan 9 may have some interesting concepts, but the author puts it a bit too much on a pedastal.
-
Ie, everything in Plan 9 is a file. In Unix, only some things were files. Thus Plan 9 has a simpler API. More complexity in an API doesn't necessarily make things better; you can always create more functions by just laying a library on top. If you're on a small system the added simplicity saves space and improves performance. Don't think like Windows where one assumes everything gets bigger and faster so that efficiency is unimportant.
Plan 9 was also a full system. It had enough API to be completely a
-
Problem being that the author doesn't give credit even when Linux models certain things as files. When linux models the process as files, it's " bolted-on extras", when plan 9 does it, it's built in. He has a bad habit of repeated this in containerization, declaring it "bolt-on" when Linux does it, when namepspaces and cgroups and relative root aren't really "bolt-on", it was added and made integral to the architecture as it evolved.
Whatever opportunity Plan9 had, they squandered it by being closed source
-
-
The inflation of system calls in Linux was not driven by any "user requirements", but by honest (and dishonest) mistakes and the need to keep them around forever for backward compatibility. This is how such beauties like olduname() and oldolduname() (sic) came into existence, not because any user asked for them.
And Linux doesn't really even need such "defenders" like you -- its real number of system calls is much less if you get rid of all the compat cruft (which you don't need if you're porting Linux to a new hardware platform, or you don't care about binary compat): for instance, you need to implement only clone3() -- no need for any of clone2(), clone(), fork() or vfork() which are just legacy interfaces which can be easily implemented in glibc on top of clone3().
It may have the same namespace, control group, and chroot facilities (I'm guessing..),
You're guessing wrong. Plan9 doesn't have anything like control group or chroot (because it does not need them), and has only the equivalent of "mount" namespaces (no ipc, network, uts, time, etc namespaces).
Plan 9 may have some interesting concepts, but
you don't seem to be familiar with them.
-
That clearly means that a need for newer, replacement system calls were needed when it met reality. You only have obsolete system calls because at some point the userbase needed the replacement. I think it's silly to presume that the lack of evolving system calls in Plan9 is because they must have gotten it right the first time, instead of the more likely answer of not actually having to have their implementation stand up to the real world.
If it doesn't need them, it's only by virtue of its nature as a res
-
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK