LWN: Comments on "Brian Kernighan on the origins of Unix"

Brian Kernighan on the origins of Unix

jdisnard — Tue, 01 Feb 2022 13:17:11 +0000

It's always nice to to see Brian's deep perspective into Unix. One thing I'd like to see more from folks like Brian is how Plan9 fit into the Unix big picture, and how that relates to Linux? I'd also like to understand how one might go about recreating something as magical like Bell Labs in the modern era?

Brian Kernighan on the origins of Unix

scientes — Sat, 29 Jan 2022 15:12:13 +0000

> The C language hit a "sweet spot" in language design that has proved hard for anybody else to hit since, Kernighan said.

Absolutely. I got really excited about Zig-lang's goals to replace C, while still being Turing complete, but it has IMHO since abandoned that goal.

The features of Zig that could feasibly be ported to C (with a great deal of work) would be--

1. Remove the need of C pre-processor, which is a language of its own (the original Go compiler written in C avoided the C pre-processor, but Zig does it better).

2. Better memory allocation. malloc and free are a commonly slow in C applications, leading to Firefix and Chromium using custom allocators (jmalloc and tcmalloc) but these, and also the quite novel Mesh-allocator are not as good as the Zig abstractions. Also, C programs that use malloc and free are generally at the mercy of the OOM killer, and these type of bugs have plagued systemd due to the incredible bug-hunter Evvrx.

3. Make integer overflow part of the language, instead of obscure "undefined behavior" rules which are often over-ruled by an excessive number of non-standard-behavior compiler switches which are even used by Linux.

Brian Kernighan on the origins of Unix

farnz — Fri, 28 Jan 2022 14:48:36 +0000

Cgroups have two things that a virtual machine setup does not have:

Limits to determine which containers swap more than others. By setting memory.low to your "fair" share without overcommiting, and memory.high to your limit with overcommit, you bias the kernel's paging to page out memory hogs (both to swap and paging out their executable pages), and to slow down processes that can't reclaim memory to stay in their lane.
An interface for a management process to use to identify cgroups that are using more than their fair share. You can monitor memory.events for changes, and use the notifications to tell containers to reduce their memory use.

Now, if you're dealing with people who overcommit physical RAM but who've not read and understood In defence of swap, you're in trouble anyway - they're working on a faulty model of how the OS allocates memory to processes to begin with, and both models are going to break because they're expecting "magic" to save them. But with competent people, cgroups already does better than VMs; and because cgroups has more visibility into what the workload is doing, it's more likely that cgroups will improve over time.

As an example, EPOC32 had low memory signals it sent to the applications to let them know that the system was low on memory, and that it was out of memory. Applications were expected to handle these signals by discarding caches, performing an early GC etc - and could also (ab)use them for better performance (e.g. don't run GC until the system is low on memory). You can get similar signals in a cgroup-aware application by having the application monitor memory.events, and treating a breach of the "low" threshold as "memory is running low" and a breach of the "high" threshold as "out of memory". Then, your JVM could be aware of this, and whenever it breaches the "low" threshold (container using too much memory), it does a GC run, while when it breaches the "high" threshold, it also discards any cached JITted sections etc.

This interacts in a good way with the kernel's preference to swap stuff that breaches low more than it swaps stuff that breaches high - when you breach low, you try to come back under control, when you breach high, you try to avoid being killed.

Brian Kernighan on the origins of Unix

wahern — Fri, 28 Jan 2022 06:05:56 +0000

cgroups doesn't solve the memory sharing problem any better, though admittedly VMs do currently compound the problem. virtio-balloon, which is widely supported (including by typical Linux hosts and guests) permits a guest to return memory (e.g. filesystem buffer caches) to the host. The problem (AFAIU) is that currently there's no implementation on either side (host or guest) that communicates memory pressure back-and-forth, opportunistically shifting memory around. See defunct auto-ballooning project at https://www.linux-kvm.org/page/Projects/auto-ballooning. So, just as with cgroups, if the memory accounting budget is overcommitted and the VM manager hits a hard OOM condition, it's already too late to guarantee ideal behavior; that is, it's too late to first recover caches and other any pages across all processes/guests that aren't strictly necessary for correct continuation (if at all possible) of every process/guest.

The alternative in each case--VMs and cgroups--is to preallocate memory so that the sum is no more than available backing space. But the Kubernetes clusters I've worked on, for example, all overcommitted cgroups memory--the sum of all pod cgroup memory limits was greater than physical memory (and machines had no swap space, despite my protests). Use of cgroups couldn't prevent the OOM killer from unnecessarily shooting down processes when under high aggregate load; it only helped blunt edge cases where individual pods allocated much more memory than ever expected (e.g. because of a memory leak). This was especially true if a JVM was running in a pod, as for whatever reasons the Java applications people liked to run on those clusters aggressively used anonymous memory. Whenever some other team complained about their pod being OOM killed despite not going over their cgroup budget, the host invariably had a JVM running in another, unrelated pod. (This was especially problematic for the period, 2019-2020, when Linux kernels had a regression that made it *much* more likely that the OOM killer couldn't flush buffer caches faster than processes would dirty them. Worse, the result was the OOM killer spinning, sleeping, and eventually timing out in its flush routine; and often times multiple processes could end up in that routine--or end up trying to take a lock held by that routine--effectively resulting in a situation where the entire system could lock-up for an indeterminate amount of time. Even if you could get an SSH session, poke the wrong process and your session would lock-up, too.)

Brian Kernighan on the origins of Unix

ceplm — Sat, 22 Jan 2022 21:57:44 +0000

Hmm, I have to revert myself a bit. I was talking about completely independent system and then I was talking about using “normal” formats, which is mutually exclusive. Damn.

Concerning Perkeep, it looks interesting, but more as a secondary story for backup and archiving (something similar to https://github.com/ThinkUpLLC/ThinkUp ?) not as something where you actually work.

Brian Kernighan on the origins of Unix

ceplm — Sat, 22 Jan 2022 19:28:18 +0000

OK, an interesting idea I will try to learn more about it. Two problems seem obvious, why I think keeping it on the lower level of a filesystem makes more sense is that nobody wants to use any format they don’t already use (https://xkcd.com/743/), and the second is that I have never heard about, so I don’t expect it to take over the world anytime soon.

Brian Kernighan on the origins of Unix

malmedal — Sat, 22 Jan 2022 13:03:36 +0000

My own memory also rather lacking at this point, but I think the deal-breaker for me was that the migrated process would die if the node it originally ran on rebooted.

Did MOSIX ever fix that issue?

Brian Kernighan on the origins of Unix

intgr — Fri, 21 Jan 2022 23:54:30 +0000

> What I was thinking was that all my data are somewhere in The Cloud and whatever machine I use to access them (workstation, my hobby home laptop, tablet, or phone) I get access to the same data.

Perkeep (previously Camlistore) is an attempt to solve this problem.

Brian Kernighan on the origins of Unix

Cyberax — Fri, 21 Jan 2022 18:38:50 +0000

Sorry, I'm a writer, not a reader. 🤦

Yes, of course you're correct. I used a Beowulf cluster with MOSIX back in the day, so that's why I'm confusing two of them.

Brian Kernighan on the origins of Unix

malmedal — Fri, 21 Jan 2022 18:36:50 +0000

I believe I said Beowulf couldn't but MOSIX could migrate processes, they are different things.

Brian Kernighan on the origins of Unix

Cyberax — Fri, 21 Jan 2022 18:14:22 +0000

Yes, they did. You could migrate processes between nodes: https://web.archive.org/web/20031002104248/http://www.ope... with some measure of automatic load balancing.

Brian Kernighan on the origins of Unix

gwolf — Fri, 21 Jan 2022 15:24:30 +0000

Indeed, that book was my favorite 2020 read. Much recommended!

Brian Kernighan on the origins of Unix

smurf — Fri, 21 Jan 2022 14:01:44 +0000

… or something like the GNU Hurd.

Beowulf

corbet — Fri, 21 Jan 2022 14:01:14 +0000

Yeah...Beowulf clusters still exist, they are just called "data centers" now...

Brian Kernighan on the origins of Unix

malmedal — Fri, 21 Jan 2022 13:58:25 +0000

I don't think Beowulf clusters had that capability. You could schedule your job in any cluster-member, but not move them. Similarly with VMS, you could maintain the illusion of 100% uptime of a specially written application even while replacing all hardware.(admittedly I've only used VMS on VAX, maybe later versions could actually move jobs).

MOSIX however, could move arbitrary processes between cluster machines.

Another option is Condor, which uses CRIU to move simple processes.

Brian Kernighan on the origins of Unix

Cyberax — Fri, 21 Jan 2022 12:01:09 +0000

People tried that with Linux (famous Beowulf clusters!) but this really doesn't buy you a lot. Why would you migrate jobs between hosts in the first place?

You can do full machine migration easily either via VM checkpoint/restore or via CRIU, and this is useful in virtualization scenarios. You can also do high-availability via Xen where the same code runs on two computers at once, in case one of them goes down.

Brian Kernighan on the origins of Unix

ceplm — Fri, 21 Jan 2022 11:16:52 +0000

Yes, VMSClusters look like something I was thinking about (as far as I can get from the Wikipedia article on it). I speak mostly out of my frustration with the current state of the affairs.

What I was thinking was that all my data are somewhere in The Cloud and whatever machine I use to access them (workstation, my hobby home laptop, tablet, or phone) I get access to the same data. Perhaps I don’t have all applications for all data (thinking that tablet or phone), then I cannot access those, but for those data which I have application for I can access the exact same data. And of course all that over the Internet, so fully secure, with authorizations and all that crap. And all that cached on the local disc, because otherwise latency will kill any user experience. It should be the normal state of everyday affairs not something like pulling your teeth slowly.

If you try something like that today you have NFS or Samba or stuff like that, which is unuseable for everyday work over even slightly non-local network (not mentioning a potential security disaster, so one switches to something even more obscure like sshfs and that’s even slower; NFSv4 may be more secure). Or you have some ultra-high-level stuff like Coda/OpenAFS etc. which requires really high-end hardware (no chance of running it on my tablet, phone could not be even mentioned) and even there I am not sure how well it works. Or you have series of mutually incompatible ad-hoc synchronization hacks (offline-IMAP, similar for CardDAV/CalDAV/etc., some weird in-browser proprietary caching for Google Docs, scripts using rsync, etc.).

http://ninetimes.cat-v.org/ seems to claim that Plan9 was supposed to be able of something like that, but I have my deepest doubts and I will believe it when I see it.

If you have some system which fulfils my requirements than you are either God or a liar, and I be on the latter.

Brian Kernighan on the origins of Unix

sfeam — Thu, 20 Jan 2022 22:44:58 +0000

We have either local systems (BTRFS, XFS, etc.) or network systems (NFS, Samba, etc.), but nothing in between.

Well, there were VAXClusters. Start a job on the cluster and it would migrate from machine to machine or node to node as they connected or disconnected themselves from the cluster. So far as I know unix/linux clusters never have reached this level of flexibility. Or maybe you were focusing specifically on filesystems?

Brian Kernighan on the origins of Unix

ceplm — Thu, 20 Jan 2022 22:37:22 +0000

One thing which is very much not A Solved Problem™ is really working networked system. Something which would be networked but it would allow seamless work offline (or when the network is not that really fast as we would like it to be). We have either local systems (BTRFS, XFS, etc.) or network systems (NFS, Samba, etc.), but nothing in between.

I believe that Plan9 was more on the way towards this ideal, but Plan9 unfortunately died.

Brian Kernighan on the origins of Unix

ermo — Thu, 20 Jan 2022 17:10:42 +0000

I can't help but think that what you're asking for is a micro-kernel-like design from the ground up, where e.g. the user graphical session is its own set of processes (possibly related via a cgroup or namespace-like idiom), each browser tab is its own process and each container is its own proces and where all these processes use the fundamental micro-kernel message-passing paradigm (possibly wrapped) to communicate with each other?

If all processes used the same form of containerisation/namespacing/layering and the same means of IPC (possibly with some faster-than-TCP-but-still-reliable network transport available), this might function as seamlessly as one could ideally expect.

At least, that's the endpoint my imagination extrapolates to from your problem statement. I could be (very) wrong of course.

I don't know how close Plan 9 comes to this hypothetical scenario or whether it's even close. But perhaps Zircon/Fuchsia might very well become the closest modern approximation of what I outline?

Brian Kernighan on the origins of Unix

karim — Thu, 20 Jan 2022 16:55:32 +0000

Thanks for this, interesting point of view.

I somewhat feel git might actually a good example of commoditization. I followed this very much in "real-time" as the BitKeeper drama unfolded and was at OLS in 2005 when Matt Mackall first presented Mercurial -- I loved mercurial btw, and I was sad to see git prevail, but I digress. It was my understanding that BitKeeper was tailor-built by Larry McVoy for Linux development based on direct conversations between Linus and Larry. I don't have a reference for this, so I could be misremembering, but that was my understanding. As such, when the history section of git on Wikipedia (https://en.wikipedia.org/wiki/Git#History) states: "Support a distributed, BitKeeper-like workflow." as one of the goals set out by Linus for git, one can probably easily overlook the work that Larry presumably did to actually and actively listen to Linus and come up with something that fit "the customer's needs". [side bar: I've butted heads with Larry several times in the early 2000s on unrelated topics, but credit should go where it's deserved.]

And maybe this is what it boils down to. "Listening to the customer's needs" and "creating a product the customer will actually use" have nothing to do with the ability of replicating in an open source manor the end result of what those customer-facing steps entail. In fact, I'd venture to say that the open source community generally has had a bad history of being able to listen to customer needs. It's been, on other hand, very effective at replicating what those that have have produced, albeit sometimes in a more sustainable fashion ... because direct monetization wasn't the end goal or even possibly a need.

Again: 1) very rough ideas/arguments off the top of my head, 2) I care not of being right nor making a point. i.e. destroy/demolish at will.

Brian Kernighan on the origins of Unix

farnz — Thu, 20 Jan 2022 11:16:27 +0000

The other thing that would be nice to solve that VMs don't is good resource utilization; a VM's memory allocation is hard to vary dynamically based on overall system load, as is its filesystem size. The only host resource that's demand-shared in a VM setup is CPU.

It would be nice if we didn't have to preallocate resources to processes, but instead could rely on the system sharing all resources fairly and reasonably for the use cases in question. That's a hard problem, but it's one that (e.g.) filesystem quotas and cgroups aim to solve for containerized systems.

Brian Kernighan on the origins of Unix

gasche — Thu, 20 Jan 2022 09:37:53 +0000

Interesting discussion! I can think of several open source projects that were disruptive to the rest of the ecosystem (even if they are often built on pre-existing ideas that hadn't seen wide diffusion yet). They are limited to my own expertise and I'm sure there are many more examples:

- Git made distributed version-control widely available and changed our development practices in a radical way.
- Haskell is a radical programming language that gave a lot of ideas now adopted by other languages
- Nix and Guix are proposing a fresh take on software package management and generally the OS
- QubesOS is also a fairly radical take on OS (although it is a layer on top of existing systems for usability reasons)
- the Coq proof assistant ( https://en.wikipedia.org/wiki/Coq ), and in general Interactive Theorem Provers, are radical projects and all the active ones are open source, with most run as free software projects (with a strong academic bias among contributors).
- I believe that some peer-to-peer projects also had a radical impact (Bitorrent these days), but I don't know enough about their history to tell if the open source / free software community participated actively. (I think there was a fair amount of Windows-based freeware at the time.)
- I would guess that Bitcoin was also operated by a crew of enthusiast hackers from the open source community at the start -- but again I'm not sure.

Many of those projects were born in academia (a natural place to look for radical ideas), but they were also open source projects from the start, and in many cases the free software community contributed greatly to the fact that they became successful enough to spread their ideas to the rest of the software world.

For Git one could argue that this is a commoditization of the proprietary system BitKeeper; but there were also open source ancestors (GNU Arch) and competitors (darcs, Mercurial) that were also influential.
(I think it would be worth articulating whether we are discussing inventions that were born in the open source community and became successful-enough within it, or inventions that were born anywhere but remained fairly confidential, and became successful thanks to the open source community. I rather have the later in mind, and I think it is different from "commoditization".)

One important area of innovation that is missed here is machine learning, that saw relatively little involving from well-identified open source communities, possibly as the requirements for entering the space (having a *lot* of training data at hand) made distributed development difficult. There are now striving open source projects within the machine learning software ecosystem, but I wouldn't say that the field would be substantially different without the open source community (by which I mean: without large-scale cooperation of hobbyists / benevolent contributors).

Brian Kernighan on the origins of Unix

ikitayama — Thu, 20 Jan 2022 02:49:41 +0000

I very much enjoyed this specific piece, thank you Jon!

Brian Kernighan on the origins of Unix

epa — Wed, 19 Jan 2022 19:55:53 +0000

If you don't want the users to communicate with each other (except over network links) then yes. You give each user their own system, whether by physical hardware or a virtual machine. My vision of a multi-user system is that it has the properties I mentioned, but at the same time you can communicate between users in the lightweight way you do on a current Linux system, provided you've granted permission. The multi-user interface provided by a set of virtual machines is pretty basic, because usually the only way for them to communicate is via TCP/IP.

We have approximations such as sandboxes used by web browsers to isolate one tab from another. Again, I see those as a kind of workaround or a hazy approximation to the right answer: creating a new user on the fly for each tab, giving it its own memory and CPU budget, and then communicating via signals, Unix domain sockets, or a shared filesystem. But yeah, talk is cheap. The point I want to make is that if it's considered a solved problem, that may be because we're too used to the limitations of the current systems. Before git, software version control might have been seen as a solved problem by some.

Brian Kernighan on the origins of Unix

mpr22 — Wed, 19 Jan 2022 17:42:47 +0000

(Also it charges rent on business-use access to its services.)

Brian Kernighan on the origins of Unix

mpr22 — Wed, 19 Jan 2022 17:40:50 +0000

The trick is that Google doesn't sell software at all.

It sells advertising space (and possibly trademark licences?), and uses a slice of the revenue to pay the salaries of its technology division.

Brian Kernighan on the origins of Unix

dgm — Wed, 19 Jan 2022 17:07:13 +0000

The moment you have per-user everything (programs, libraries, permissions, filesystems, network, ...) what you have is, in essence, a per-user kernel. I think that the best solution for running per-user kernels are good 'ol Virtual Machines (in the VirtualBox sense), so it is a solved problem indeed.

Brian Kernighan on the origins of Unix

farnz — Wed, 19 Jan 2022 13:56:36 +0000

Technical writing is a very different discipline to software writing, and needs a different set of skills. Unfortunately, too many companies fail to value tech writing, and instead expect that the software authors will write good documentation themselves.

A really good tech writer knows how to take a developer's documentation (written from a place of deep familiarity with the code) and turn it into something useful for people unfamiliar with the code. A software developer just doesn't have that skill.

Brian Kernighan on the origins of Unix

cyperpunks — Wed, 19 Jan 2022 12:10:23 +0000

Yep, sometimes I puzzled how Google can earn all that money and have all these brilliant minds; the software they produce and release lacks both pooper documentation and sane release policy. If they sold software the Microsoft way they would be out of business many years ago.

Brian Kernighan on the origins of Unix

cyperpunks — Wed, 19 Jan 2022 12:01:49 +0000

Indeed, a very nice read. Thanks to Brian for that gem!

Brian Kernighan on the origins of Unix

nilsmeyer — Wed, 19 Jan 2022 05:45:27 +0000

> Disclaimer: I work for Google, and while they would probably *like* me to tell you that we have already gotten to that point with GCP, I'm not 100% convinced that we're fully there yet.

I think as a proprietary solution it's a bit of a non-starter anyways.

Brian Kernighan on the origins of Unix

jkingweb — Wed, 19 Jan 2022 05:36:40 +0000

This has been my experience with all Google documentation I've ever seen.

Brian Kernighan on the origins of Unix

bartoc — Wed, 19 Jan 2022 00:37:10 +0000

> Sure source availibility isn't everything, and isn't the same thing as community (the point Andy Rubin makes) but, when the source is available with no community it is still possible for a community to form later (by forking if needed). To some extent this happened, albeit temporarilly, with Android with early "community" Android forks like Cyanogen actually bringing significant new features that ended up becoming available in official Android only later (stuff like tethering and permissions modifications come to mind).

Interestingly this happened with iPhones too! Despite most of their software not being open source. All those quick control popouts and a lot of the additional interaction options for stuff like notifications were added by third party mods for "jailbroken" iphones long before apple implemented them. I'm not sure if this is Android/Apple taking ideas from the "community" or just obviously good ideas being implemented by the community first, because a hobbyist doesn't need to polish things up that much before shipping (or go through endless UI redesigns, UX research, etc, etc).

Brian Kernighan on the origins of Unix

bartoc — Wed, 19 Jan 2022 00:29:00 +0000

I bet many do see k8s as the "one true container solution". I also bet around 100% of those people work for Google.

I've tried to understand k8s multiple times and it's like they refuse to _ever_ document what anything actually does, just some high-level abstract theory of what the results might be. It feels like reading a formal standard but more arbitrary.

Brian Kernighan on the origins of Unix

mfuzzey — Tue, 18 Jan 2022 18:36:05 +0000

I see what you're getting at and don't really disagree, major open source projects do seem to often be better at improving an existing idea rather than implementing completely new things.

However I think there are other factors at play in your examples.

Android: hardware was a huge factor too. The Android OS would be useless with appropriate hardware and that is still difficult / impossible to fully open source and even harder to develop in a community manner.
Now that suitable hardware exists there are projects building open source, non AOSP based, operating systems for them. They will probably never become mainstream, just as Linux isn't and will probably never be mainstream on the desktop but they do exist.
I also think Android wouldn't have succeeded as well as it has if it hadn't been open source, even though it definitely isn't a community driven project.
Furthermore Android had specific time to market pressures (to have a chance of avoiding Apple dominating the market and Microsoft taking the rest).

ChromeOS: hardware too (though you can run it on a PC so not entirely). But also the chromeOS web centric model relies on huge Google data centres that aren't really reproducible outside of huge companies.

GCC / LLVM: I think this was more a question of the incumbrent being less nimble. GCC, as the dominant OSS compiler saw less need to innovate and, because they had a large existing code base doing so was harder. This happens in the proprietary world too where innovation is often more likely to occur from a new entrant than a large existing player.

But I think where the open source community has really suceeded is in the development model rather than particular technologies.
Back in the 90's many people thought the future of computing would be building systems from sets of commercial , closed source, components. That was the model Microsoft technologies like ActiveX, OLE, COM/DCOM etc were supposed to enable.
That failed to materialize and most new languages / frameworks today are non starters unless they are open source.
For many if you can't get it with "git clone" and no jumping through hoops it doesn't exist.

Sure source availibility isn't everything, and isn't the same thing as community (the point Andy Rubin makes) but, when the source is available with no community it is still possible for a community to form later (by forking if needed). To some extent this happened, albeit temporarilly, with Android with early "community" Android forks like Cyanogen actually bringing significant new features that ended up becoming available in official Android only later (stuff like tethering and permissions modifications come to mind).

Brian Kernighan on the origins of Unix

kleptog — Tue, 18 Jan 2022 17:23:28 +0000

I personally found that Docker Swarm actually did reasonably well for the middle. The user experience was pretty good and it was really easy to set-up. Together with docker-compose for the configuration you could get fairly complicated set-ups working pretty quickly with sensible defaults.

Its main problem was that the implementation was plagued with bugs that made it really annoying to run in production. When its internal state got corrupted (which was often in the beginning) the only fix was to blow away the entire cluster. Which is really annoying when you've got a hundreds of containers spread over dozens of nodes. Bringing everything up at once was a guaranteed way to get more corrupted state.

It's better now, and it's has been pretty stable for a while, but the mind share has all gone to k8s. Swarm is good for smaller set-ups, but if you want to build another layer of automation on top of it, Swarm is a real pain while k8s does this easily. Silly things like secrets that can't be updated are just nails in the coffin.

I've wondered about how the world would have turned out if the Swarm UI could have been merged with a k8s reliable backend. I see there is something called Kompose, but I've never tried it.

Brian Kernighan on the origins of Unix

ballombe — Tue, 18 Jan 2022 16:20:25 +0000

UNIX/POSIX was instrumental to the free software movement. POSIX provided interface definition that allowed independent developers to write operating system code and userspace code that worked together without requiring too much coordination.
The ability to work in parallel was crucial to the growth the free software.

Creating a new operating system paradigm from scratch that is not a UNIX copycat require a different mindset.

Brian Kernighan on the origins of Unix

epa — Tue, 18 Jan 2022 15:36:19 +0000

Multi-user systems are not a solved problem. If they were, there would hardly be any need for containers. Most container setups work around the inherently single-user setup of typical Linux distributions or Microsoft Windows.

In theory each user can have an independent set of software, sharing only the kernel; in practice it's damned awkward to run your own software stack from your home directory, and there aren't package management tools to make it easy.

In theory each user can have their own share of CPU time and I/O budget; in practice it's far too easy for one user to take more than their fair share, or to bust global limits with fork bombs and the like.

Users and permissions are themselves not per-user; there's a single global set of users and groups and it does not nest. You can have subdirectories in the file system but you can't have sub-accounts under your user account or make your own groups. It all has to go through a single global administrator. A true multi-user system would let you manage your own permissions within your space and delegate to sub-users.

Can you set up a multiuser Linux system where each user gets their own IP address, so they can run their own httpd on port 80 serving that address, and not interfere with other users? I am sure it's possible with enough hackery, but it's far from being straightforward or manageable.

Brian Kernighan on the origins of Unix

nilsmeyer — Tue, 18 Jan 2022 15:32:00 +0000

> I think this missed the point of the question "Could Unix happen again?"
> Though it could be that it just sees a different point to the one that I see - it is a rather vague question.

Maybe it is happening right now? Without the benefit of hindsight who would have known that Unix or Linux would have such an impact?