In Plan9 they implemented signals using the filesystem https://news.ycombinator.com/item?id=3077504

>Instead of "everything is a file", "everything implements well-documented object-oriented interfaces" would be much better idea. Why "object-oriented" specifically? Is this in any sense different from non object-oriented interfaces, eg. Rust's traits or Go's interfaces, or just to make it more clear that you're talking about interfaces in the programming languange sense?

The operation system already very much behaves like an object-oriented system, even in a languages without language support for this: you ask the OS for a handle, which has to be passed as the first argument to any system call. The kernel has figure out what object the handle refers to and redirect the call to the appropriate subsystem. This is abstraction and polymorphism. And of course, the kernel won't give you any access to internals by default, which gives you encapsulation.

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.

Not really, because then, the influence reaches deep into the programming language, and that means you get one of the many single-language type OSes, like Smalltalk, or Oberon, or Lisp Machines.

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.

Look into COM/dbus. There are generic language independent object models.

I am aware of them!

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.

Oh I absolutely think so, in fact I really hope kdbus gets merged and eventually it gets used to expose kernel structures

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.

Huh.

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.

Huh? Have you never written stuff to files procfs or sysfs?

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.

Aside from the fact that Linux increasingly has documentation for its ioctls and pseudo-filesystems, whether it is documented is a completely orthogonal issue to how these interfaces are designed. You can have well-documented APIs based on files and undocumented API based on object-oriented interfaces as well.

It might not be the best example but in my experience Microsoft seemingly tries with Windows the approach of (almost) everything being an API. It might be the Windows API specifically or that I'm mainly driving Linux outside of work, but I often found the approach of (almost) everything being an API annoying.

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.