51–60 of 311 posts
The three most used desktop operating systems look and feel archaic. They aren't very different from the oses of two decades ago. BeOS still looks more advanced in some aspects than Windows, Linux and MacOS. I expected lots of advancements to take place in the OS space in 20 years.
In what ways?
Earlier quoted context omitted.
Looking at the Unix to Plan 9 translation [1] gives me a different opinion. To name one egregious example, omitting find(1) in favor of piping du(1) (what is supposed to be a disk usage analyzer) to grep(1) is not an improvement; it's just user-unfriendliness in service of minimalist aesthetics. (Contrary to popular belief, find(1) is not a particularly "bloated" program; Rust's "fd" implementation is under 7,000 lin…
The problem with find is that it tries to put an entire programing language into its arguments.
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
Everything as a file was an interesting architecture in the 70s. The whole system was dependent on that model so it made total sense. In the 00s and beyond I thought everything as a service was a better model. Called through an API. Basically RPC. But even that has failed. It's very difficult to approach a new system from that perspective. I think you can design a protocol to say what the model of interaction should…
As of someone who discovered Plan 9 far too late to do anything about it: everything is a poor man's Plan 9 something. Everything. All of it. Plan 9 lived in the goddamned future.
The same person who is involved with Plan 9 also made Go. Taking one look at that programming language doesn't leave me very optimistic about Plan 9.
Worse is better than nothing, but when better has been demonstrated to exist, worse is just worse
Earlier quoted context omitted.
I got used to `du | grep` after using Plan 9 a lot and still do it on Linux, but yeah really I think Plan 9 fans have had a tendency to ossify the pragmatic minimalism of the Bell Labs guys into a sort of cultishness... there's no reason we couldn't have find on Plan 9, but now it's almost a religious point not to have it. On the other hand, the lack of find is not a particularly good rebuttal to the original point.…
The thing that I use find for most commonly is to perform a hierarchical grep, i.e find . -exec grep -Hn regex \{\} \; How would you do that with the du | grep combo?
This will also be faster, because you fork less.
The simple, everything is a file, model of Plan9 is what makes the namespaces API as clear and as general as it is. All the objects export the same file API. Every interaction with the OS objects is done through file open, create, read, write, etc. But it has it's drawbacks. 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 interf…
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.
Hierarchical nouns, a fixed collection of verbs and a stream of bytes is aesthetically pleasing and can be helpful for developers hacking around, but is too limited and low level a vocabulary to express many important APIs. An obvious example is the Plan 9 windowing/graphics server, which in theory is just files but because that's way too low level is actually accessed via a client library written in C. That's how it would have always gone in the end: in theory it'd be files, in practice it'd be RPCs squashed and squeezed to look a bit like files as long as you don't think too hard, with a C API wrapping it for convenience.
APIs and files are very different things. Every modern platform has a fairly sophisticated inter-process RPC system at its core for that reason. Windows has (D)COM, Apple has XPC, Linux has DBUS (but doesn't use it as much), Android has the Binder, Chrome(OS) has Mojo. The designers of these platforms were all quite familiar with Plan 9 and yet none chose to implement the everything-is-a-file model, which I think is good evidence that this is a dead-end design wise. Fundamentally you don't write complex programs in shell scripts but the Plan 9 design assumes you do.
One place this model does live on is HTTP, but HTTP isn't enough and is thus always used with extensions, at minimum JSON or XML but also things like multipart, websockets, headers, CORS, maybe Swagger etc. And of course HTTP servers only look like a file system on the surface, in reality you can't actually browse them or do most of the things you'd expect of a filing system, and you don't use the filing system APIs to access them.
Networking and filesystems are an especially difficult combination because the UNIX APIs for file access (which Plan 9 largely also uses) are too impoverished to provide necessary functionality. They all assume relatively reliable and low latency access, so even quite basic things like being able to get progress information from operations isn't easy.
Still, the underlying ideas in Plan 9 are worth iterating on. My company has an internal Kotlin based scripting tool designed to bridge the world of shell scripting and 'real' programming languages. It exposes a shell-like API with functions like mv, cp, wget, and so on which are all implemented internally. One of the things it does is expose progress events via a unified progress reporting API. You can assign a progress event handler and then do things like file copies or archival operations, and get information on what's going on. By default it renders a nice animated progress bar on the terminal but you can also do things like serialize these events across network boundaries. The filesystem API is pluggable so you can do things like browse into zips, and there's also an ssh function that lets you connect to the file system of a remote server: strings can be turned into path objects that remember their home filesystem and those can then be used to do things like copy/browse/execute things on remote systems:
val local = dir / "local-archive.tar.gz"
ssh("//foo.com/home/bar") {
cp("remote-archive.tar.gz", local)
}
extract(local)
It also acts as a sort of testbed for vaguely Plan9-ish ideas. For instance I want to experiment with how to adapt a regular POSIX-ish file API to allow nodes to be both files and directories simultaneously. But you don't need an OS for this. It can all be done in userspace.
The simple, everything is a file, model of Plan9 is what makes the namespaces API as clear and as general as it is. All the objects export the same file API. Every interaction with the OS objects is done through file open, create, read, write, etc. But it has it's drawbacks. 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 interf…
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).