First, it's not always easy to map every object operation into either an open read or write. With time, we should have seen a lot of ugly interfaces resulting from this limitation.

Second, hardware progress, the web, etc., introduced a lot of heterogeneity and complexity. People could no more keep up with simple general designs. And to squeeze every bit of performance, everyone was doing things different based on the hardware and the workloads. They use whatever makes their software, drivers, and OS objects work as fast as they could.

And this is how we ended with the extreme fragmentation and heterogeneity we have in Linux, which explains the complex and less general implementation of its namespaces and its other features.

Edit: fix typos

Heck, even for basic files on disk, and even more so for sockets, the traditional open/read/write/close is starting to feel not so great. There is reason why iouring is hailed as the second coming, and it solves just part of the problems; stuff like fsync apocalypse comes to mind.

And ioctls are imho completely disgusting hack.

Ultimately IO is intrinsically complex topic, and trying to paper over that complexity with simple interfaces is disingenuous and falls flat on edge cases.

This is a bad design. Process is not a file because you cannot send signals to a file, or cannot debug a file. Network socket is not a file because you cannot get file's peer address. Shared memory is not a file. And so on.

Debugging is hard to imagine, yes. One could look at /proc/12345/mem, write breakpoints in there, but I'm not sure about how to do the more exotic things.

npm install -g styled-linux

The serialized streams make it easier to think of these ioctl-alikes as something you can easily access over a network (9p).

And that’s how resource sharing is done in plan 9.

The question isn't "will it be just as bad" but "would some things become easier, and if so, how many things would become easier?".

Because if the latter, then it's a worthwhile topic to think about even if we never use it in any commercial sense of of the word.

Outside of lots of non-obvious problems with synchronization, this is your example that best fits the idea. This interface is probably a good one.

> And of course you can get a peer address from /dev/tcp

You will have lots and lots of problems with access controls if this is your only interface.

> Shared memory can be a file

Coercing random access memory into a serial file just to go and emulate a random access over that file is... not a great way to deal with a high-performance primitive.

The file doesn't need to have an on-disk representation. I don't see why an mmap-ed file should behave any different from a SHM segment. They are basically the same thing, the SHM segment even has a file descriptor. It just doesn't have a name somewhere in the filesystem hierarchy. https://man7.org/linux/man-pages/man7/shm_overview.7.html

Because if you just add some high-level interface without any concern for performance, yeah, you get what Linux does today. But if you make them a core concern of your shared memory interface, you will certainly lose performance on the cases it's mapped as memory. And "everything is a file, but this one here is actually all about random access" doesn't give you much abstraction.

As somebody already said on the comments, the nice (maybe IMO, I'm not sure) thing about Plan9 is that every resource is named somewhere in a tree. The fact that those things are "files" only detracts from the value and makes the system less fit for modern usage.

But well, if the proposal is to unify everything, you will have to unstream network connections too.

This interface is a bad one because if you want to filter syscalls then it will be difficult to distinguish write to a file from sending a signal.

Try `strace|grep open` on any program, and you will be spammed with a number of shared libraries. You need to filter them out anyway.

It's far too easy to pretend reality is not complex and that "elegant" solution somehow will fit everything

The situation there is exactly the opposite of a syscall, it is rather that the kernel calls into userspace to perform a helper function.

Communication with the socket is still read()/write()/..., so there are still syscalls. The userspace program will do a read() to get the next struct+packet out of the socket.

The modern, syscall-less interface for stuff would be io_uring. There, you do not need to read(), you can just get your data written into a userspace buffer that you can mwait or poll on.

In Plan 9, you send signals and messages to a file by writing to it. And read messages by reading from it.

It's in essence no different than OOP or actor model or what have you.

    interface UniversalInterface {
        fun open(…)
        fun read(…)
        fun write(…)
        fun close(…)
    }

Ultimately, when someone does end up implementing something like the above as the sole interface for some major component, it’ll result in libraries that return a wrapping object with a more useable and pleasing interface that abstracts away the ugliness of using UniversalInterface to interact with said component.

I see two ways forward with this. Either: (a) present the option of using UniversalInterface to interact with X object, in addition to interface that’s much more idiomatic and closer to how X object actually behaves.

Or, (b) come up with an alternative universal (or flexible) object interaction interface that’s much more flexible than UniversalInterface.

You're describing a meeting in which people seem unaware of the purpose of uniform interfaces. Not sure we could call such a meeting "engineering design" meeting, because engineers tend to know better.

If I went up and proposed the same interface for all cables, displays, mice, keyboards, speakers, hard drives, phones... and called it USB, would I also be laughed out of the room?

There's no benefit to reinventing open/close/read/write in 50 different ways. The goal is to do it once, and then build more complex interfaces on top of it. That is, unless you're paid by the number of lines of code you write.

There is an universal interface, it is called "system call". Rather than build unnecessary layer on top of it, improve the syscalls if you don't like them, and get rid of ioctls, /proc, /sys and other pseudo-syscall abstractions.

Hence open is not part of your UniversalInterface, but it is a way to obtain a reference to it. It seems reasonable to have a generic way to dispose of an UniversalInterface (hence close). read/write are simply a generic ways to send and receive messages from UniversalInterface, not unlike a dynamically typed object. Ideally you would do a checked down cast to your actual interface [3], but this was designed to work with C so you have to make do.

[1] I don't subscribe to the Everything is an Object in the OO sense, but having a common base class for most OS resources seem a reasonable solution.

[2] or at the very least there isn't always a cross-resource-type namespace.

[3] Not unlike COM QueryInterface, and in fact UniversalInterface is equivalent to IUnknown

This is very obviously an acceptable solution because the whole world runs on TCP.

> Or, (b) come up with an alternative universal (or flexible) object interaction interface that’s much more flexible than UniversalInterface.

That’s, basically, what COM/Corba/… are. There, UniversalInterface has an additional call “If you are a Foo, give me your Foo interface”, with Foo as an argument to that call.

That's really good. The fact that the file interface just gives you a string of bytes, with no concept of structure or type safety in the interface itself is a major flow of it. Type safety is immensely valuable.

The metadata around files - ownership, permissions, creation time - apply to a lot more than files.

I don't really see it being laughed out of the room.

Yes? All interfaces do that, especially system interfaces. It's the whole purpose of interface - to provide implementation logic in a usable form. Try to call the kernel by hand and see the difference.

Doubtful. Why are the main paradigms?

Everything is an object

Everything is a function

Everything is a resource (REST)

Uniform interfaces are common for good reason: you gain a lot of flexibility for redirection, introspection and policy control.

It’s really “Everything has a File Descriptor”, nothing about the concept of a file has changed.

It's in essence no different than OOP or actor model or what have you.

I’m sure there’s an isomorphism that could be drawn but it does nothing to show that it’s an equally good paradigm to write software in. IMO, it’s a tortured abstraction.

This is akin to how shell piping in Unix is also just... text and bytes. This is limiting and produces many ad-hoc protocols.

But take what Plan 9 was trying to do, and add to it what Microsoft's PowerShell tried to do, where you stream objects, structured information, instead of just bytes, on the way in and out of commands and files...

And suddenly... we got ourselves an Erlang.

Many perfect and awesome systems have been built that never saw significant adoption.

I agree with ESR's observation: "Plan 9 failed simply because it fell short of being a compelling enough improvement on Unix to displace its ancestor. Compared to Plan 9, Unix creaks and clanks and has obvious rust spots, but it gets the job done well enough to hold its position. There is a lesson here for ambitious system architects: the most dangerous enemy of a better solution is an existing codebase that is just good enough." Source: https://www.catb.org/~esr/writings/taoup/html/plan9.html

Another amazing OS that never caught on was BeOS: https://en.wikipedia.org/wiki/BeOS Neal Stephenson's description of BeOS as "fully operational Batmobiles" is accurate and it is sad that BeOS did not become more mainstream. See https://people.cs.georgetown.edu/~clay/classes/spring2010/os...

1. ioctls can make any "syscall" on a file.

2. a process does not have to be a singular file. All processes have most if not all their attributes exposed as files /proc/$PID/ as files, and can have this arbitrarily extended. In plan9, passing a signal (technically a note) is done by writing to /proc/$PID/note, and there is no technical reason for not allowing the same on Linux.

3. the entire concept of memory mapping is based around files, with anonymous memory - i.e., non-disk-backed memory - just being a subset of this. POSIX shared memory (shm_open) is provided through /dev/shm, which is a tmpfs folder and is indeed just files.

4. sockets are file descriptors, and file descriptors is what makes a file, and as such you can get a peers address of a file descriptor when such is present. Ways to expose creating sockets in the filesystem also exist, and not just for plan. The special socket-bits could easily be made less special, with the only justification for the current BSD socket API being that it became dominant and so everyone copied it.

A file descriptor is exactly nothing like a file. You cannot write to a pidfd. You cannot waitid an eventfd. You cannot getsockopt on a regular file. The only operations that all file descriptors have in common is close, dup, poll and some other basic operations.

So "file descriptor" basically just means "kernel interface object" and the available operations depend on the type of object.

A file is a container for arbitrary data that I can read from, write to, and reposition the read/write cursor in. If you call anything else a "file" then you haven't made everything a file, you've just redefined "file" to mean "thing."

What business does a socket have in a physical, on-disk filesystem? (Let alone a clunky hack to invoke the much simpler `signal` syscall in a roundabout way?) The socket "file" is completely meaningless unless the process that opened it is currently alive and still listening on it. So why the fuck should it get written to a persistent storage device?

How do I specify the socket type, which is a meaningless concept for an actual file, when I open a socket "file"? Oh that's right, I don't. Because I don't open a socket. I bind or connect. I don't use "file" APIs because they're not applicable. I use a dedicated socket API that's fit for the purpose.

Pidfd was not introduced to treat processes as "files," it was introduced so they could share the operations that they do meaningfully share with other kernel objects (e.g. poll).

The overloaded ioctl syscall is bad design. The proc "filesystem" is bad design. /dev/shm is ridiculous design. So I have to mock a fake filesystem in memory so I can create a fake file in that "filesystem" just so I can get the same memory pages mapped into my virtual address space as some other process, all of which has absolutely nothing to do with files or a filesystem (and is much lower level than that). lolwat?

If not being able to write makes it not a file, then files stop existing when a disk is full, and means that /dev/zero and /dev/null are not files - despite being at the heart of the whole "everything is a file" paradigm.

Pidfd was not made to make processes behave like files - that is what /proc is - but to solve problems with process related syscalls and PIDs, which are flawed and racey. The solution to that was to make APIs that treat processes as files, which gives you the ability to poll it like a file.

A streaming socket is exactly like a normal file. You read, write and poll. The only thing that is special is how to create it, but that is a design decision, not a technical limitation - see the plan9 file based API for making TCP sockets, which is trivially implementable in Linux.

Domain sockets are a bit different because of their side channel and would require more ctl files, but Linux's API is 99% magic files and ioctls so this is not that weird.

ioctls are not themselves bad design. In fact, scoping kernel functionality onto file handles is a great design and why that's almost the entirety of the kernel (device driver calls dwarf syscalls). The problem is not the design itself, but the fact that ioctl was not originally meant for it and got overloaded through several design iterations. This is what happens when you do organic design through more than 3 decades.

If you start out by defining a way to do file-scoped syscalls - and file does and always will mean "an fd" to a kernel - then you wouldn't have that awkwardness. That is what plan9 did: Take the learnings, and implement them clean instead of on legacy.

Which is what I said. It's a "file" in name only.

> If not being able to write makes it not a file, then files stop existing when a disk is full, and means that /dev/zero and /dev/null are not files - despite being at the heart of the whole "everything is a file" paradigm.

Great example that showcases the idiocy of Everything Is A File. /dev/null and /dev/zero are basic parts of the Unix API, so the basic OS API is broken-by-default at boot until one mounts a file system that had these dummy "device" nodes at a specific path that's hardcoded everywhere.

Instead of providing a sensible API like memfd_create or timerfd_create, for example.

> A streaming socket is exactly like a normal file. You read, write and poll.

That doesn't make it a file, that makes it an object that shares common traits with file objects. Datagram sockets do not read/write because they're not bound to a fixed remote address. And that's perfectly fine. They're not files.

> The only thing that is special is how to create it, but that is a design decision, not a technical limitation

And it's a good design decision. The socket API is pretty decent except for the dumb "file" nodes it creates when listening on standard unix sockets.

> see the plan9 file based API for making TCP sockets, which is trivially implementable in Linux.

But thank God it's not implemented in Linux.

> ioctls are not themselves bad design. In fact, scoping kernel functionality onto file handles is a great design

Agreed, the only bad part is that too much was shoehorned into the same syscall. It's certainly better than magic "files" that pretend to be "files" by having you read and write structs from, but you're only allowed to read and write whole structs per syscall, which has no resemblance whatsoever to how reading from and writing to a file work. (Maybe Plan9 doesn't have this limitation and tries harder to keep up the charade, I wouldn't know.)

No, it is the very definition of a file from the OS perspective. There is no other applicable definition to the OS. You seem to conflate files with disk storage, in which case not just plan9, not just Linux but the entirety of UNIX history seems to have flown past you.

That files are a nothing but abstract handles that implements the VFS interface to serve every conceivable function - where regular file is treated no differently than a device driver - is the entire point of modern UNIX. If this is the part you are stuck on it is not a surprise that both the existing Linux kernel APIs and trivial (and quite frankly, perfectly ergonomic and efficient) alternatives like the plan9 API seem so foreign to you.

"read and write structs" is the most normal thing for an application to do, whether you are reading JSON from disk, communicating over UNIX domain sockets with raw C structs, or sending protobuf over the network.

"But thank God it's not implemented in Linux" - Linux has many of these APIs already and it constantly grows, see for example all of /dev, /sys and /proc, not to mention FUSE and support for the 9P protocol to use all of plan9's services as-is.

You don't get one object == one file node, you get one object == a subdirectory with lots of file nodes that you have to open and close independently. That should tell you that your pattern doesn't work. (With enough effort, you can of course always shoehorn everything into an ill-conceived concept (and you did), but if you have to bend over backwards to make it fit, you should just admit it doesn't fit.)

It works for /dev, but definitely not for the mess that is /sys and /proc.

"Reading and writing structs" is the most natural thing to do when you're forced to serialize your data. You then design wrappers around that serialization that expose a sane, type-safe API on each end.

Wouldn't the same be applicable to files, processes, devices and so on?

And like it or not OOP shows that it's possible for one idiom to describe all the things when it's flexible enough.

I've got a lot of experience working in systems that model everything as a series of resources passing messages and it works very well. The entire QNX operating system right down to its POSIX support uses this underlying primitive and, while you would never see it in your own code their system-wide profiler leans on this design to make it easy to see how control flow moves between isolated threads and processes within the software system.

Both "special" and "device" files are still "files".

https://man7.org/linux/man-pages/man2/pidfd_send_signal.2.ht...

Also sockets have the concept of ancillary channels used to deliver out of band data (see recvmsg). If every system resource had such channel, it could be used for control similar to how sockets do it.

With a remarkable similarity to certain mainframe systems from half a century ago.

I’m not against pointing out the edge cases in the Plan 9 file model[1,2], but the thing is, I haven’t seen complex I/O interfaces that aren’t a horror show, either. Granted, I haven’t seen that many of those at all, but I’ve had a thorough look at the ones in OS/2, Win32, and NT, and none of them seem particularly inspiring.

I’d very much like to see some nice alternatives, to be clear!

The reference to io_uring also doesn’t seem all that strong of an argument, honestly. I’d like to say there are three layers to the idea of “traditional” “Unix” “files” as an OS (not storage) interface:

- System and user resources you have access to are identified by unforgeable references (called “fds”; the merits of allowing userspace to control their naming as opposed to having the kernel assign the names are debatable). You can feed bytes into these, (ask to) get bytes out of them, and perhaps have a out-of-band call to e.g. transmit one of the other references you hold to a peer. You can of course also delete a reference.

So far this is just dynamically typed object-capabilities by another name. It’s going to require higher-level protocols on top, but so does basically everything else on this level of generality.

Plan 9 mostly (if not completely) eliminated ioctls here by using separate control files instead.

(The part where the OS merges the payloads of write calls into a byte stream then cuts it back up into reads is more opinionated, but I don’t think even Bell Labs systems ever adhered to that principle strictly[1].)

- You obtain (most of) these references by navigating a stringy hierarchical namespace. There are additional calls to do so and to modify that namespace.

This is less of an obviously correct least common denominator, and as history shows the consensus is less strong here as well. Mountpoints, symlinks, namespaces per TFA, even the *at() calls all change how this part functions. On the other hand, I don’t think anybody longs for version numbers or nesting limits (or even drive letters) of other systems that have used naming approaches similar enough for a comparison.

- You access these services through synchronous system calls write(), read(), ioctl(), close(), open(), etc.

This is the part that is changed by the introduction by io_uring... But I don’t feel it’s all that important for the conceptual model, unlike the preceding points.

[1] Cutting a bytestream into packets is as always a tedious slog of buffering so some of the protocol implementations use write() / read() boundaries thus actually (depend on being able to) use the API in a datagram-like fashion (which 9P enables IIUC).

[2] Auth is based on a /proc/self-like hack wherein the kernel-side implementation of the “file” inspects the opening process through kernel-side knowledge you can’t access nor proxy from userspace.

I’m not sure how much stock to put into the multimedia claims, however—a lot has changed since then, both in the state of human knowledge about low-latency multimedia, A/V sync, network streaming, etc., and in what we can and can’t afford on machines we perform multimedia processing on. How relevant and how commonly known are the insights that BeOS incorporated today?

(You can see that I expect the answers to be “not very” and “extremely”, but sometimes life surprises us. For example—did you know that Microsoft shipped a renderer for 2D animation based on FRP ideas, designed with the direct participation of Conal Elliott himself, in 1998? It was called DirectAnimation and released as part of DirectX 5.)

And then comes concurrency and exceptions... UNIX "design" anticipated none of the above. And it's not like these things were somehow unknown at the time. The "designers" thought they are making something remarkable by cutting corners and making a "simple" (but really a half-baked) OS.

It's such a shame that UNIX became the vector for the spread of the Internet and eventually infected virtually every computer system on Earth. It's even a greater disappointment that its "design" decisions are still revered as the holy Bible in academia and in the industry.

I personally liked VMS for concurrency, but for dealing with code and coding there was no contest that Unix was far better. I think the reality is they're all half-baked since none can satisfy every need.

One concrete example of its design: exercising administrator (sudo) permissions causes a User Account Control (UAC) dialog to pop up, which takes over the screen from the current WindowStation -- making it impossible for any software to mess with approval or password entry [1].

IO Completion Ports (IOCP) also stand out as a powerful way to perform asynchronous IO that NT has had since ... I'm not sure how long, but I believe probably since the 90s. As one HN commenter wrote in 2016, "IOCP is the top item on my (short) list of things Windows simply does better. The performance boost you see from designing a server for IOCP from the ground up is jaw-dropping." [2] And it works for a variety of different IO tasks (including disk IO).

Windows gets a lot of hate, but most of the criticism you read about it online is not usually a well-considered critique of how its kernel APIs operate.

[1] https://learn.microsoft.com/en-us/windows/security/applicati...

[2] https://news.ycombinator.com/item?id=11867345

Also, while IOCP has the advantage of being older w.r.t. availability, I wonder how io_uring competes - I haven't used IOCP myself, but from what I've seen io_uring seems to fill its role quite well and I've seen several people complain about various problems with IOCP (in particular poor documentation)

But, what I said about developing software stands: I'd much rather be using a unix .

Unfortunately, today, UNIX is by and large all we have. Other things are either some kind of UNIX but with a twist, or very underdeveloped.

Looking into the future, I'm very enthusiastic about OS-as-a-library approach, but I don't think we have a solid contender there yet.

I think fundamentally, there are only a few things it has to do: Allow applications to run (on the CPU/other hardware), Allow applications to communicate between themselves (establish communication standards), Allow access to disk, Manage the time given to each application well/fairly, Define permissions around resources (who can talk to whom and who can access what). Depending on who you ask, shells/desktop environments should be part of the OS too.

When I think of the minimum that can accomplish that, I think something like a simple communication standard (with authentication mechanisms) would be interesting (with possibility to support more specialized standards). A standard for defining app. share of resources (CPU/disk). Maybe hardware resources like disks, devices like cameras, etc.. could be treated as applications via a driver (or application <-> disk application <-> disk driver). Then instead of 'opening' files, you're just communicating your intentions with a disk driver, and you can do essentially anything. Maybe then instead of a Filesystem Hierarchy standard, there could simply be "OS (standard) applications" that for example list what users are in the OS, what applications are available, and so on (without a filesystem hierarchy at all, if you wish!). An FHS could be provided for legacy reasons.

I also think permissions should take a more fine grained approach than Unix/Linux does (closer to Android permission systems), I think by default applications should have minimum permissions and should be whitelisted as needed.

https://www.theseus-os.com/Theseus/book/index.html

Linux is not derived from Unix, but supports Unix (Posix) APIs. As does modern MS Windows, and Mac OS X.

This also means that Google could experiment with OSes like Haiku or Fuchsia that support Posix, but are built in a different way.

It doesn't seem like it. Linux has a habit of multiplexing alternate functions through a single handle with additional and somewhat scary methods like ioctl. Plan9 manages this with servers, directories, and more than one path available for a single resource depending on what you're trying to access. This is far more sane.

> With time, we should have seen a lot of ugly interfaces resulting from this limitation.

They don't seem any more complicated than they need to be. Compare implementing a fuse server vs implementing a plan9 server. Yet I don't see where all of this complication adds anything or enables implementation of technologies that couldn't be implemented on plan9 with a few additional paths.

> People could no more keep up with simple general designs. And to squeeze every bit of performance,

These are contrary goals, and I'm not sure what you mean people can't "keep up" with "general designs." What is there to "keep up" with? And in exchange for that performance we got one of the most insane /class/ of unfixable CPU bugs ever imagined.

> And this is how we ended with the extreme fragmentation and heterogeneity we have in Linux,

And yet.. many of these systems are now being unified into generalized file descriptor based systems, that have wacky open methods, but boil down to allowing simpler interfaces through read(2) and write(2).

What do Spectre and Meltdown have to do with “everything as a file” system architecture?

Given how horribly asynchronous filesystems are I take one handle owned by the current process over a dozen free hanging files that might be reused for different resources at any time. Hell I am quite sure Linux had to kill suid on scripts because the kernel could not guarantee that the script file wasn't swapped out before the interpreter would load the path.

Almost more importantly, they don't claim to be universal. Instead, you can still send messages where that makes sense. The approaches are much simpler and powerful when combined than when each tries to be everything. Yes, you are allowed to say "synergies".

With the corresponding object streams (that can be specialised to byte-streams as well), we have something I like to call Plan A from Userspace.

https://2019.splashcon.org/details/splash-2019-Onward-papers...

https://objective.st

https://www.jerf.org/iri/post/2931/

The idea there is that the particular way interfaces work in Go is possibly the way that Plan 9 should have worked. In reality, trying to fit everything into a file is still non-functional, because not everything is a file. But if you instead have a hierarchy of interfaces, starting at the very bottom with "this is a stream", working up to "this is a stream you can close", and so on and so forth up through "this is a seekable, sparse, appendable chunk of bytes that can have ACLs set and has the following ioctls", you can get what you're looking for out of common interfaces, while at the same time not having to run all around the system putting "do nothing" methods on things just to conform to interfaces. ("Do nothing" methods are a valid tool for a bit of fitting into an interface, and actually quite important, but only when the methods are themselves something that can be fulfilled by a do-nothing implementation. "Set this ACL" shouldn't be satisfied by a do-nothing method.)

For many things even a file is overkill; what you care about is that you can stream bytes in or out once you have it, not whether you can change the ownership of the thing you are working with. And with ioctls you see cases where files aren't anywhere near good enough.

(Note this is not advocacy for Go as a language you might want to program in; it's more a suggestion for a Plan 10 by drawing on Go as a particular combination of features. It would take non-trivial work to figure out how to turn this into an OS feature, but it's not inconceivable amounts of work IMHO.)

That said, I have no idea how you get "poor man's Erlang" out of this specific post. As a practical matter, Erlang is a standard dynamically-typed language in this matter; as a theoretical matter it has some limited support for protocols as used by things like gen_server but I don't think I ever saw a single use outside of the standard library, and I'm about 90% sure there's no implicit satisfaction of them; you must declare what you are implementing. It is irrelevant to my point as Python or Perl. We already know what this sort of dynamically-typed interface looks like in those systems, namely, "a lot less nice in practice than in theory but still useful enough most of the time". Nice for writing scripts, sufficient for reasonably-sized programs, not a sufficient foundation for an OS with Plan 9's level of aspirations.

Now a days people are mapping everything to JSON, and it works. The Plan9 directory structure was basically the JSON of the 80s, a hierarchical data structure were the hierarchy is easily navigable in a standard way, and the leafs can then hold any non-standard stuff you may need.

There is no real practical difference in capability between this and dedicated syscalls. For Linux, the distinction is usually just whether the functionality is "global" or isolated to a certain area like devices or drivers.

Tangentially, I've long wondered why the Linux "API" is such a mess, in particular why are there multiple tracing frameworks? Multiple security frameworks? Which to choose??

It turns out, this is a consequence of Linux's stand-alone development, along with their (good) "never break userspace" mantra. The two together mean they can never deprecate an API.

Contrast this with the *BSD's development, where the kernel is developed alongside the libc and (a core set of) user-space applications. This allows them to evolve and deprecate their APIs, because they can update the clients.

(From a runtime perspective, all is not lost in Linux, as I suppose they can move an API to a module or allow "users" (distros etc) to disable it at compile-time.)

A lot of what defines REST works well here. The "Uniform Interface" creates a simple API that can scale to a surprising amount of functionality.

Not saying it doesn't have it's downsides, but you can accomplish a lot with minimal increase in the surface area of that "uniform interface".

Plan 9 lived in the goddamned future.

[1]: https://9p.io/wiki/plan9/Unix_to_Plan_9_command_translation/...

[2]: https://github.com/sharkdp/fd

On the other hand, the lack of find is not a particularly good rebuttal to the original point. If I rolled up in a prototype personal transport which could go 1000 miles on a single AA battery, would you complain that the seats were poorly stitched?

If the poor stitching were taken as a point of pride and the community refused to fix it, then yeah, I'd assume that that community values purity over practicality. Which is exactly how I feel about Plan 9: it had good ideas and was an improvement over Unix in many ways, but it was a regression in others, in large part due to choosing minimalist aesthetics over usability.

In a parallel universe where Unix did not take on so much baggage, perhaps it could have even naturally evolved towards Plan 9 and Plan 9 would have not been a necessary break. But then, like Plan 9, maybe Unix would have never rose up to see any widespread use to make that evolution significant.

Tradeoffs, as always.

Hardest thing that comes to mind is there's some slight portability differences to look out for between GNU find and BSD find that may require a quick man dive with relation to the max depth handling, but that's about it.

I've used find extensively in the past two decades and even read the man page (gasp) on occasion, but it's one coreutils command that I have always found cumbersome. I recently discovered fd and I have a feeling that I will be switching to that where I can, muscle memory be damned.

So they chose to just never finish the OS instead.

find . -exec grep -Hn regex \{\} \;

How would you do that with the du | grep combo?

This will also be faster, because you fork less.

du -a will need to do a stat to get the file size, which is comparatively expensive; I don't think find will (not sure)?

Yes, those stat() calls can be very slow in aggregate on a large tree, especially from HDD (due to seeking) or network filesystem, if the stat information isn't already in cache.

Im not sure how one can do \0 separator with du, plan9's du(1) doesn't list such option.

http://git.9front.org/plan9front/plan9front/HEAD/sys/src/cmd...

329 lines of code.

You can also use dmenu's stest to do the equivalent to find's -type f, { walk $PWD | stest -f }

I think a good mini language bridges the gap between interactive commands and programming. Sometimes you need to spend an hour writing a program to do something complicated. But because of various "extraneous features" built into UNIX commands, you rarely need to spend an hour manually poking at the filesystem. The mini language gets you almost as productive as a full-fledged programming language, without feeling like you're programming. (How do you know you're programming? If you "git init" and start committing stuff, you're probably programming. If your carefully-crafted thing scrolls into .history obscurity, then you're interacting.)

find(1) is a bad mini language. Its arguments are in a legacy format and its solution for composability is a hack, and an unstable one.

Different programs introducing their own specific programmatic layers defeats the holistic small pieces, loosely coupled premise.

Plan 9 is not an answer to every problem, but it's just impressive how much it can do with so little code.

Piping programs together is almost always going to use significantly more resources than one program doing it all. More code doesn’t necessarily imply more resource usage.

Plan 9 is not an answer to every problem, but it's just impressive how much it can do with so little code.

I don’t want to be all around negative about plan 9, but I don’t see it as really solving any interesting problems. Indeed it is far easier to write slim, elegant systems when forgoing feature parity and/or competitive performance.

That's true! Yet, somehow we found ourselves in a situation where most people use computers, to chat, read news etc, all of which would be possible with much less resources. All done with the use of platforms that we literally can't rewrite, as they're too complex. It's certainly not find's fault, but the complexity creep starts somewhere.

Plan 9, as a research OS, is not a useful platform to base your next business on, but it does serve as a baseline we can relate our "real" platforms to.

Just having a framebuffer with page flipping for seamlessly redrawing the screen costs 64MB of memory at 4K resolution. People did real work and gaming on computers with a small fraction of that.

Early on in the history of computing the framebuffer was discussed as a theoretical construct, like "what could we do with this concept if we had the memory to implement it".

That's the direction Powershell took, and to some extent was what other OSes were doing at the time of Unix. But Unix has become so ubiquitous and influential that we've forgotten that programs could pass more than ill-specified strings around, and that resources could implement richer interfaces rather than trying to force the file IO interface on every single one, regardless of how little sense that makes

Worse is Better may have been a useful expedience in the 20th century, but we're long overdue repaying that technical dept, to get back some of the rich OS/environment features that other camps had got working almost half a century ago. The first step would be to stop putting "Unix philosophy" on a throne

For example, I found a flatpak of a system monitor and thought it was portable. Turns out, it parses `ps` output directly, but it's not compatible with BusyBox `ps` output

https://github.com/hakandundar34coding/system-monitoring-cen...

the author literally doesn't care since it works with coreutils `ps`

it's a culture problem

Well yes, but I think it will be hard or rather impossible to convince the unix crowd of anything good coming from windows.

    ls | where size > 10mb | sort-by modified

If you mean you couldn't run batch scripts from a file, they can do that now. There's an example repo with some community scripts. My favourite is how they handle CLI parsing: https://github.com/nushell/nu_scripts/blob/main/sourced/nu_1...

  ls -t *(Lm+10)

The syntax is not easy, even byzantine, but it's a lot less to type and pretty convenient in interactive shells.

All the time arguments and size parameters and rules about depth and boolean syntax and the print0 for pipeline integration ... it makes me long for DOS interfaces from the 80s. There has to be a way to do it with less intellectual lifting every time.

Maybe just a simple set of bash reads will help - that's how I do ssh port forwarding - I was tired of getting confused.

Integration with /etc/mime would be nice as well so I can just search for, say, "image" or "video". (This would be at the frontend in this (currently) fictional helper script)

The existence of things like `-print0` is the downside of Unix's "all files/pipes are byte streams" design decision.

The IBM mainframe implementation of the pipeline idea – CMS Pipelines [0] – makes pipes record-based instead. Since the pipes are not streams of bytes, rather records with out-of-band boundaries, there is no need to reserve a special character (whether LF or NUL) to serve as a record separator.

> Integration with /etc/mime would be nice as well so I can just search for, say, "image" or "video"

It is a pity that Unix never had a "file type" field in the filesystem, unlike classic MacOS, Acorn RISC OS, among others. I suppose both those systems had the limitation that the file type was just a number, subsequent experience has demonstrated it needs to be a much longer string (such as a MIME type or Apple UTI). The problem with file extensions is the same extension ends up being used by completely unrelated applications for completely unrelated file formats – e.g. nowadays .doc is normally assumed to be legacy binary Microsoft Word, but many older archives it is a plain text file instead, or sometimes even some other word processing format.

[0] https://en.wikipedia.org/wiki/CMS_Pipelines

Sed has a fairly well designed although limited interface you again pass in.

By contrast find tries to have separate pieces strung together each as an argument.

When I saw the start of this thread, I thought abusing "du" for "find" sounded insane - but after mulling it over - I guess du is just a recursive stat(1).

And I can see the logic; have a tool that builds a tree of metadata, filter with a tool that... filters.

However - as far as i can tell, du/grep on plan9 can't fill in for find(1) - but the idea (above) would probably fit with PowerShell or other "typed/rich streams" kind of shell...

https://man.cat-v.org/plan_9/1/grep

https://man.cat-v.org/plan_9/1/du

> Rust's "fd" implementation is under 7,000 lines of code

Not counting the 23.8k files, not even lines of code, of rust (https://github.com/search?q=repo%3Arust-lang%2Frust++languag...). Comparison should happen on a similar baseline

I agree, but it seems to me that this is partly because it's stuck in its tiny little niche and never got the rough edges worn down by exposure to millions.

I was a support guy, not a programmer. I started Unixing on SCO Xenix and later dabbled in AIX and Solaris, and they were all painful experiences with so many rough edges that I found them really unpleasant to use.

Linux in the 1990s was, too. Frankly WinNT was a much more pleasant experience.

But while Win2K was pleasant, XP was a bloated mess of themes and mandatory uninstallable junk like Movie Maker. So I switched to Linux and found that, 5-6 years after I first tried Slackware and RHL and other early distros with 0.x or 1.0 kernels, it was much more polished now.

By a few years later, the experience for non-programmers was pretty good. It uses bold and underline and italics and colour and ANSI block characters, right in the terminal, because it assumes you're using a PC, while the BSDs still don't because you might be on a dumb terminal or a VAX or a SPARCstation or something. (!)

Linux just natively supports the cursor keys. It supports up and down and command-line editing, the way Windows does, the way PC folk expect. BSD doesn't do this, or very poorly.

Linux just natively supports plain old DOS/Windows style partitions, whereas BSD did arcane stuff involving "slices" inside its own special primary partitions. (GPT finally banishes this.)

I've taken this up with the FreeBSD and OpenBSD devs, and they just plain do not understand what my problem is.

But this process of going mainstream on mainstream hardware polished the raw Unix experience -- and it was very raw in the 1990s. Linux from the 2nd decade of the 21st century onwards got refined into something much less painful to use on

Plan 9 never got that. It still revels in its 1990s-Unix weirdness.

If Plan 9 went mainstream somehow, as a lightweight Kubernetes replacement say, it would soon get a lot of that weirdness eroded off. The purists would hate it, of course, just as BSD purists still don't much like Linux today.

Secondly, Plan 9 did a tonne of cleaning up the C language, especially (AFAICT) after it dropped Alef. No includes that contain other includes is obvious and sensible and takes orders of magnitude off compilation times. That rarely gets mentioned.

The other vital thing to remember is that despite 9front (and HarveyOS and Jeanne and so on), Plan 9 was not the end of its line.

After Plan 9 came Inferno.

I have played around with both and just by incorporating late-1990s GUI standardisation into its UI, Inferno is much more usable than Plan 9 is.

Plan 9 made microkernels and loosely-couple clustering systems obsolete >25y ago.

A decade or so later, Inferno made native code compilation and runtime VMs and bytecode and all that horrible inefficient 1980s junk obsolete. It obsoleted WASM, 2 decades before WASM was invented.

With Plan 9, all the machines on your network with the same CPU archuitecture were parts of your machine if you wanted.

(A modernised one should embed a VM and a dramatically cut-down Linux kernel so it can run text-only Linux binaries in system containers, and spawn them on other nodes around the network. Inelegant as all get-out, but would make it 100x more useful.)

But with Inferno, the restrictions of CPU architecture went away too. The dream of Tao Group's Taos/Intent/Elate, and AmigaDE, delivered, real, and FOSS.

When considering Plan 9, also consider Inferno. It fixed some of the issues. It smoothed off some of the rough edges.

I feel, maybe wrongly, that there could be some mileage in somehow merging the two of them together into one. Keep Plan 9 C and native code as an option for all-X86-64 or all-Arm64 clusters. Otherwise, by default, compile to Dis. Maybe replace Limbo with Go.

That seems like an insane concept. I honestly can't see how it can be justified in a world where pretty much every compiler since the 90s has support for `#pragma once` and detects include guards automatically without re-reading the header.

Can you illustrate this with examples? Ones that are from outside of the Unix and C family, just to make it clear that we aren't talking about tweaks to old tools?

(note: if you want examples of compilers that have `#pragma once` then I don't know what to say because I'd be hard-pressed to name a compiler that does not support it - similar situation w.r.t. header-guard detection)

> pretty much every compiler since the 90s has support for `#pragma once`

I asked for examples.

Specifically I am asking for examples that are not C compilers, do not compile languages derived from or related to C, and which do not run on Unix-like OSes, because what we are talking about here is what came after Unix. Plan 9 is effectively Unix 2.0: it is what the people who designed and built Unix did next.

Inferno is Unix 3.0. It's what they did after Plan 9.

Tweaks to the project that they had moved on from (or clones thereof, e.g. Linux) are not particularly interesting or relevant in this context, IMHO.

You want me to cite compilers that don't compile C that support a C extension ? And you want the language it compiles to be completely unrelated to C ?

Frankly, I'd already be quite hard-pressed to even cite a compiler that compiles a language that is completely unrelated to C in the first place and doesn't run on any Unix-like OSes (I guess maybe something like cmd.exe (...though it's an interpreter, not even a compiler) or some assembler written entirely in assembly - I think there's a few I've seen for Windows (though an assembler isn't typically considered much of a compiler) or something like that ? Does Windows even count as "not Unix-like" ? Does Wine mean it runs on Unix-like OSes ?)

This just makes your criteria seem like it can't match any compiler at all, quite frankly, unless you're asking to trawl through truly ancient stuff from the 60s that I wouldn't even be able to test at all in the first place (since by the criteria you've given it must not be able to run on my laptop)

Also, I'll add that you're likely to be correct in the most literal sense - I don't expect many compilers for languages that don't directly descend from C to include anything like `#pragma once`, because they're using a completely different model from C: almost no languages these days use "copy-paste" style file inclusion to handle libraries, and if they do anything like that, `#pragma once` is implied and never needs to be manually specified.

But in practice, `#pragma once` allows C libraries headers to work just like in many other languages - they can freely include other libraries without forcing the user to do so themselves manually.

Just imagine if you had to follow the Plan 9 C scheme on other languages, imagine if everyone that did `import argparse` in Python had to then add `import os`, `import re`, `import gettext`, `import warnings` and `import sys` because `argparse` can't do it itself without fear of double inclusion (...and then you'd also have to manually add `import abc`, `import stat`, `import enum`, `import functools`, `import unicodedata`, `import copyreg`, `import posix`, `import posixpath`, `import nt`, `import ntpath`, `import subprocess`, `import io`, `import locale`, `import builtins`, `import linecache`, `import tracemalloc`, `import traceback`, `import types`, `import operator`, `import reprlib`, `import collections`, `import weakref`, `import typing`, `import genericpath`, `import pwd`, `import errno`, `import time`, `import signal`, `import threading`, `import contextlib`, `import fcntl`, `import msvcrt`, `import select`, `import selectors`, `import grp`, `import encodings`, `import tokenize`, `import fnmatch`, `import pickle`, `import itertools`, `import textwrap`, `import keyword`, `import atexit`, `import gc`, etc. as the nested dependencies of os/re/gettext/warnings/sys/etc.)... I can't imagine anyone would consider that a good thing.

> You want me to cite compilers that don't compile C that support a C extension ?

No.

There are, hmm, I am not sure, at least 2, probably 3, and I suspect more than 3 assumptions in here.

#0, general context:

The bigger picture here is that there is a whole world of OS and language development which is completely outside the world of Unix, C, and things that derive, directly or indirectly from it.

However, the Unix+C world is so big, so commercially successful, that a lot of people in it can't see that there is anything else. To quote Gaiman and Pratchett, it's the same as the reason that "people in Trafalgar Square can't see England".

I wrote about this recently: https://www.theregister.com/2022/03/29/non_c_operating_syste...

#1. Plan 9 is not a Unix. It's what came after Unix. As such, I would say it's fair to say that Plan 9 C is not plain ol' Unix C. While the Unix flavour of C has continued on its own path, it's a very conservative path: it's terrified of breaking backwards compatibility. The developers of Plan 9 were not scared like this, and quite cheerfully made big sweeping changes.

#2. So, yes, I would consider that carefully implementing and adding what you yourself call an extension to an existing compiler (or set or family of compilers, it doesn't really matter) is not the same thing as redefining the semantics of a language to say "you are not allowed recursive includes".

One is a big sweeping change; the other is a minor tweak.

#4. The core, important point here is that Plan 9 made significant changes which in places have big ramifications — for instance, performance improvements on the order of several orders of magnitude — simply by tightening up the rules around an existing, well known language. IMHO, adding a new compiler directive is not comparable to this.

Adding a new directive is patching a hole, while changing the rules of how the languages compiled is fixing the design. What I was enquiring about was other designs that fix this problem in the core design of traditional compilers, in other words UNIX C and its descendants.

> And you want the language it compiles to be completely unrelated to C ?

Well, yes! Why not? There are lots of them!

> Frankly, I'd already be quite hard-pressed to even cite a compiler that compiles a language that is completely unrelated to C in the first place and doesn't run on any Unix-like OSes

Really? OK then, let me see how many I can name of the top of my head without googling: Pascal, Lisp, APL, Fortran, Cobol, Algol, BCPL, Forth, Ada, Prolog, Bliss... Okay I'm starting to struggle a little bit now, but I think the point is made.

I wasn't asking for languages that don't run on UNIX. I was asking for languages that weren't built out of UNIX tools. There are legions of languages today that were built pretty much entirely from the existing UNIX toolchain, from Python to JavaScript. My point is that there are dozens to hundreds of languages which are outside of that family.

Plan 9 is, I would argue, outside of that family because it's what came after that family.

Operating systems from outside of the UNIX family? Classic MacOS, AmigaOS, CP/M, MS-DOS, Atari ST TOS, Concurrent CP/M, Concurrent DOS, DR FlexOS, Novell Netware, OS/2 and all of its descendants, GEOS, Palm OS, Newton OS, Microware OS9, Interlisp/Medley, OpenVMS, OpenGenera.

And of course basically all mainframe operating systems... Tools that are still worth billions of dollars today, whose daily use affect everyone who uses a bank account or everyone who ever travels on an aeroplane.

So, yeah, a pretty significant technological and economic market segment… and one that UNIX people often totally forget exists at all. As it seems you did.

That sure is quite a useful precision to make - personally I found what you were asking for confounding given I can't really think of much of any language that doesn't run on UNIX, save for particularly obscure, often long-defunct ones (i.e. languages that basically don't run on anything at all or on stuff I couldn't possibly check out myself anyway). The fact you've also implicitly added the stipulation that only languages that derive from C and not all those that are related to it are excluded is also quite useful - I was excluding languages like BCPL or Algol on that basis (and I was quite iffy on Fortran/Pascal and a few others too, though since most ran on UNIX I wasn't even considering most of them anyway).

Also, while I broadly agree with your point about most people not even thinking stuff outside of Windows/UNIX exists and indeed find it quite acutely accurate in many cases, I'd say I'd hope I wouldn't be counted in it - I could have named most of the OSes and languages you did, save for a few like Microware OS9 or Bliss, simply I did not name the languages when prompted to because I'm not really aware of any that can't run on UNIX-like OSes, which I had then thought you were excluding before you clarified things.

Anyway, I'm aware of my ignorance of many of the details that are involved, but more importantly for what we were discussing, I would find it remarkably unlikely that any of these languages has a dependency handling system quite alike to that which is involved in Plan 9.

Are you actually telling me that you know of many examples of languages and/or compilers that handle dependencies like in Plan 9 ? That want you to manually specify all the dependencies of all the libraries you want to use before you can use that library, and which consider this sane in any way ?

If any actually exist, then I'd expect there's either: 1. Tooling around them specifically made to work around this exact issue by automatically specifying the dependencies when needed without having to spell them out manually 2. Preferred alternatives that don't have this problem in the first place

Meanwhile, the `#pragma once`-style model (i.e. make it so that imported libraries can use a separate library without ending up with asinine "double definition lol" errors if the program that uses the first library also separately uses the second one) seems like the evident standard that all the other languages use, such as:

- Ada

- Fortran

- Pascal

- APL

- Cobol

- Algol

- Prolog

within which I've found no examples of needing to do something like `import definitions_every_single_library_or_module_relies_on` and `import definitions_from_the_library_almost_every_single_other_library_or_module_uses` at the top of almost every file.

In general, what I am getting at is that Unix is a (?) uniquely weird situation that happens to have grown like Kudzu. It's an early generation of a long running project, where that early generation caught on and became massive and thus ignores simple but profound improvements from later versions of the same project.

And since in that ecosystem, almost everything is built on a foundation of C, problems with C affect everything layered on top... even though they do not in any other ecosystem. But something like 99% of inhabitants of the ecosystem are not even aware that other ecosystems even exist, let alone knowing anything about them.

If they know of any, it's macOS or Windows. macOS is also UNIX, and modern Windows is NT, which is Windows built with Unix tools and a Unix type design... so they are not really different at all.

So what I am getting at is that Plan 9 has aspects other than the namespaces and the cosmetic aspects of the design. It makes changes to the language and how it's compiled that are just as important, and hacks to gain some of that on modern versions of the parent OS family are not of comparable significance.

Famous quote:

<<

So... the best way to compare programming languages is by analogy to cars. Lisp is a whole family of languages, and can be broken down approximately as follows:

* Scheme is an exotic sports car. Fast. Manual transmission. No radio.

* Emacs Lisp is a 1984 Subaru GL 4WD: "the car that's always in front of you."

* Common Lisp is Howl's Moving Castle.

>>

Comparison: if somehow you make a pruned-down Howl's Moving Castle, you can probably never ever, whatever you do, no matter how much effort you invest, make it into something as small and light as the Subaru, let alone the sports car.

In more detail:

Let's imagine one team invented first the train, then the bicycle, then the car.

The bicycle takes the idea of a wheeled vehicle from the train but reduces it down to an incredibly minimal version. It needs no fuel, just 2 wheels, but it is very simple, very light, and can go almost anywhere.

Although you do need 1 per passenger, it's true, whereas a single carriage train can carry 100 people, you can make 100 bicycles for those 100 people with fewer materials than that 1 train, even excluding consideration of the rails etc.

If someone still making trains looked at bicycles and inspired by them came up with a train with just 2 wheels, that balanced or hung from the track, they do not get to claim that they have successfully imported the simplicity of the bicycle.

They have retained just one aspect and may have achieved savings in moving parts, or slight reduction of complexity, or a slightly simpler machine... but it's still a train.

If you tweak a conventional C compiler to not waste time rereading text that has already been read once, or a disk cache obviates it, then you have not caught up with the advance I am trying to discuss here.

For clarity, this is not my original thinking. This idea is from a Go talk over a decade ago:

https://go.dev/talks/2012/splash.article#TOC_5.

Edit to add: I don't know that this actually makes Plan 9 better, but I'm pretty sure it doesn't make it worse (Although from our perspective in 2023, it's definitely alien and difficult)

Technological progress likes to reinvent itself, looping back to the same idea that did not work last time, and maybe making it a hit finally. Two examples:

- Apple Newton, 1992 (a flop) -> Palm Pilot, 1997 (niche success) -> Apple iPhone, 2007 (world domination).

- Java Virtual Machine, 1994 (server-side world domination, a flop in the browser) -> Inferno OS, from the makers of Unix and Plan9, 1996 (a flop) -> WASM (prospects of world domination in the browser).

WASI also seems like a wrong approach, considering it inherits the limitations of WASM, like problems with memory, allocation and multithreading and hacks needed to overcome them.

VM-s are also kind of a wash for me too, since nowadays the most popular way to run software in a portable/sandboxed manner is Docker, which is NOT cpu-agnostic, even if you ran a JVM app in it, the bundled JVM would be CPU arch dependent.

The point of VMs like WASM is not (specifically) performance though, even if performance is desirable. It's the minimal, fixed standard, and the isolation.

If you badly need native performance, develop a native application %)

> The point of VMs like WASM is not (specifically) performance though

I feel like it is though. There was another thing, called asm.js back then, which was a subset of javascript that was easily translatable to machine code. It was a giant hack, and performed worse than NaCl.

I feel like WASM is more of a spiritual successor of that thing.

> If you badly need native performance, develop a native application

And pass up the ease of distribution/compatibility browsers offer?

No. Android won. The concept from iPhone won, but Android it's the world leader.

Unix as a concept (a set of ideas and interfaces) achieved world domination, but it's not the original AT&T kernel, and not the original AT&T userland.

It's an entirely separate, kludgy and vastly inelegant, reinvention of a concept that had already been done much better.

First in Tao Group's Taos, later much refined and improved in Elate and Intent.

Then done in a more Unixy way in Inferno.

Inferno embeds the cross-platform runtime VM right into the kernel and makes it the default.

WASM bodges a cross-platform runtime VM together out of chunks of web browser and Javascript tech, and then others rip it out of the browser and make it run standalone.

Instead I'm trying to show the same general idea tried over and over, at different times and from different angles. The arrows just show the sequence in time.

But it will be slower, and won't have any useful software written for it, also you won't be able to use internet or your GPU. (To be fair several years ago I tried the HURD distribution ArchHurd. I just installed on it on my laptop, and by luck internet just worked, and had a firefox running so it was good.)

All these "X is poor man's Y" are a cope. Plan9 is poor man's <insert any operating system that is supposedly inferior to Plan9> because noone uses it. I'm sure on most people the irony of this statement will be lost, so I'm gonna explain: yeah, plan9 is better on paper, too bad we live in glass world.

I haven't really used it but from what I understood at first most of it is very elegant because at the time it was developped all nodes in a network could still be trusted.

Also, if you're gonna try it do it either with a proper three-button mouse or with a large-ish and easy to press scroll wheel button. Otherwise it's really frustrating.

Plan 9 in general seems very much like a system "by the designers, for its designers" with not all that much attention to user-friendliness. To some degree that's also the case for Unix, but with Unix other people took the thing they made at Bell Labs and made it somewhat user-friendly (and even then, its received plenty of criticism for it). In Plan9 that step never really happened.

It definitely is that. That's a really great thing when the designers needs and assumptions match your own, but if they don't, you end up wondering what these bozos were thinking.

For what it's worth, Rob Pike was a big proponent of the mouse-driven design, and he has some very thoughtful essays/articles/emails about why he feels that way. I can't say I agree with him 100%, but it's clear that the decisions weren't arbitrary.

I think the main thing people get confused by besides the chording is the teleporting of the cursor, but then you realize it's actually really useful once you get used to it (at least I did).

I don't know exactly; this is one of those things where I'd have to implement some things and play around to see what works. Something like some text popping up maybe? I don't know. More advanced users can always just disable these sort of things (I also set up my Vim to not show "-- INSERT --" because at this point it's never helpful for me and it looks a bit nicer this way, but obviously for loads of people it's a very helpful thing).

After longer usage you do that without any thinking

Moving to a mouse primes my brain to start thinking spatially about things. Which is not something I'm typically doing when looking at textual/symbolic things. I can see some value in doing it, of course.

Linux moves towards massive process sharing, and thus various of sharing controls are key to the future that is missing from 90s operating systems.

Just enable sound, run your browser and music app, and count number of processes living with `ps ef|wc -l`. I see 282 kernel threads, and 536 total processes. You will see that we live in the future, because of extensive modularization of system services, and cannot get back without sacrificing reliability and comfort.

It doesn't need a microkernel, because the concept of microkernels is to split a big monolithic kernel into lots of small simple "servers" running in user space, and have them communicate by passing messages over a defined communications protocol, some kind of RPC type thing. It works, and QNX is the existence proof. But it's really hard and it's really inefficient -- of which, the HURD and Minix 3 are the existence proofs.

So most of the actual working "microkernel" OSes kludge it by embedding a huge in-kernel "Unix server" that negates the entire microkernel concept but delivers compatibility and performance. Apple macOS and iOS are the existence proof here. (It could be argued that Windows NT 4 and later are also examples.)

Plan 9 achieves the same result, without the difficulties, by default by having most things user space processes and communicating via the filesystem.

Disclaimer: this is my very rudimentary understanding. I am not an expert on Plan 9 by any means.

But I think the core point here is that, as with much of the Plan 9 design, by including a more elegant and powerful abstraction in the core design, the need for a much more powerful and much more complicated abstraction layer on was obviated, if not eliminated.

Remember CPUs were largely single threaded, and you had expensive multi-cpu systems that ran 2, 4, and 8 CPUs. Compute heavy processes consumed entire systems, or CPU since SMT was also not common. You couldn't effectively microsegment CPU usage, because you were only really multiplexing idle time. Additionally, your OS had to consume more cycles to do that resource sharing.

Today, the story is pretty similar, but we have systems with multiple cores, and SMT. We can share resources more effectively, but its also that our systems have 16x more scheduling slots.

Which is what ChromeOS and Android are mostly today, leaving C to the kernel, or tiny special purpose libs, and everything else in a managed language, Limbo.

https://www.vitanuova.com/inferno/limbo.html

https://www.vitanuova.com/inferno/docs.html

Edit: fixed a typo

Worse is better than nothing, but when better has been demonstrated to exist, worse is just worse

All because I couldn't care less about 3rd party services like github.

Go was designed by:

- Robert Griesemer, known for nothing else,

- Rob Pike, primarily known for sam(1), acme(1) and several other Plan 9 tools, the Blit (Unix's own graphical terminal), UTF-8 (with Ken Thompson), Inferno and Limbo,

- and Ken Thompson, ancient god.

- Strongtalk: https://www.strongtalk.org/history.html

- Object Oberon: https://en.wikipedia.org/wiki/Object_Oberon

- Sather: https://www.gnu.org/software/sather/docs-1.2/tutorial/intro2...

I mean, as editors, for instance, Vi and Emacs are horrible ugly things that were rendered obsolete by the Apple Lisa in 1982, let alone by the mainstream success of the Mac a couple of years later.

And yet, they persist.

X11 is a horrid lashup for what most people actually use it for. And yet, it remains way more mainstream than Wayland, say.

Disagree. In the vi/TECO model and emacs to a slightly lesser extent, you operate on text, using text, with an input device that has a 1:1 mapping to units of text. In the Lisa model, you operate on pictures of text.

As far as the UI goes, the critical distinction is not about how it looks on screen or how it is rendered, it's about modal versus nonmodal user interfaces. I happened to side with Larry Tesler on this: "don't mode me in!"

As far as Emacs goes, I was more thinking about its strange set of user interface conventions and terminology, which pre-date (and conflict with) industry standards such as the IBM CUA set of standards which came to almost completely dominate DOS, Windows, and Linux.

How the appearance of the thing is rendered on the screen is completely irrelevant to this.

In (q)ed/ex/vi and their direct and/or spiritual successors, you'll reach Command Mode by pressing Escape. In Emacs, it's Ctrl/Alt/Meta. In Acme, it's the mouse. Even editors which (almost?) follow the CUA standards have a Command Mode - using the Ctrl modifier key.

All editors have commands of some kind, yes. Otherwise, it's not an editor.

But holding down a modifier key is not a mode in the software. You could sort of argue it's a mode of the keyboard,. or of the key, but I think it's over reaching.

I've seen editors with no menus, no visible UI at all, just hotkeys that do stuff. It is still a UI even if it is not visible. There are apps for blind Windows users with no visible presence on the screen at all, such as the Qwitter Twitter client.

If pressing the Ctrl key suddenly made the app switch into a different type of operation until you pressed it again, that might count, but it doesn't. The app doesn't even need to know. It just knows "keycodes #F to #Z enter letters, but #A to #E are commands". There are no modes here.

Granted, one is Shift and one is Caps Lock…

It's like saying that cars, motorbikes and bicycles were irrelevant, because trains already existed.

A lot of terminal driven software design pivoted around lots of modes. Input mode, edit mode, command mode, extended command mode, etc etc etc. It's powerful but it's very hard to learn and everything becomes very context sensitive. What any key or instruction does depends heavily on what you did before.

That means you have to remember. That means you have to think much more.

The design of second generation GUIs (the Apple Lisa etc.) strove hard to eliminate this totally. The user can do anything at any point without modes of interaction.

The pivotal event that is often missed, and much of the Unix industry even today does not get, is that in the years after the Lisa and the Mac (and, don't forget, their affordable cousins such as the ST, Amiga etc.) appeared, that this stuff then filtered down to DOS and revolutionised DOS apps too.

And those (DOS and DOS apps) were the commercial mainstream, and that ecosystem is what evolved into Windows and all modern computers. Yes including the ones running Linux, and including Linux at the GUI level.

The Mac now is a descendant of NeXT, and is a Unix, remember. It's unrelated to Classic MacOS.

But the UI design of the GUI layer comes directly from Apple R&D. The UI at the shell layer comes from a decade or 2 earlier and is totally different.

Unless you know this, the differences between Unix' and Windows' GUIs and shells makes little sense.

Windows modernised its shell layer.

Unix didn't.

Hilarious how in any thread on HN tangentially related to Go, somebody will inevitably find a way to construct that bridge to Go purely to shit on it (and it's rarely anything more interesting than "Go sucks, right?").

This also caused appearance of syscalls like ioctl - very ugly solution. Ioctl is a large and undocumented API. Pseudo-filesystems like /proc or /sys are also examples of undocumented APIs.

Instead of "everything is a file", "everything implements well-documented object-oriented interfaces" would be much better idea.

Not every file there is seekable/readable - some only exist as an input interface to change some property.

The very same way there could exist a 'signals' file to write signals to.

The argument of GP is that file-oriented interfaces like `rewind` or `seek` are ill-suited for anything that doesn't behave like a seekable file. `read` and `write` work well for anything with a streaming interface, but are utterly unsuitable for things like processes. You'd have to layer protocols on top of it.

They do have many advantages, but lots of people don't like being compelled to use just one thing, and I think that's a huge factor in how the Unix/WinNT model did so well.

Do you really think that something like this is suitable to be embedded as the core internal communications mechanism of an entire operating system? 'Cause I don't.

Do you remember, for example, that the original plan for the GNOME desktop environment was that components would communicate over CORBA? They abandoned that after version 1.

Processes being real objects /kernel/proc/1363 with interfaces like org.kernel.proc.Process1 that allow you to manipulate them with generic message passing/function calls would be amazing.

Okay then.

Me, I'd prefer to throw the whole lot out and start over with something clean that incorporated this into its central design.

The presence of PowerShell softened my annoyance somewhat, but it never the less often feels unnecessary over-complex and overtly limiting. Tasks I can do in a few seconds on Linux often require reading long convoluted documentations and writing quite long PowerShell scripts or even full blown programs on Windows.

My experience is that the more basic and simple the task at hand the more annoying having to search thru pages upon pages of documentation and writing scripts became. But the more complex a task became the more I was happy not having to always deal with (and error handle) parsing an integer out of a string or splitting a string by a certain character.