171–180 of 311 posts
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.
Earlier quoted context omitted.
Minor nitpick. Much of the RPC in Windows predates (D)COM. I think it's closer to vanilla DCE RPC.
DCOM is built on top of MS-RPC which is originally a DCE-RPC variant yes, but DCE-RPC isn't object oriented and all the interfaces inside Windows are. You can't just open a local socket and speak DCE-RPC to Windows services, you have to use COM.
There are still leftovers of that original design all over the system; IIRC, some COM functionality make use of a hidden window to send messages between processes.
Earlier quoted context omitted.
DCOM is built on top of MS-RPC which is originally a DCE-RPC variant yes, but DCE-RPC isn't object oriented and all the interfaces inside Windows are. You can't just open a local socket and speak DCE-RPC to Windows services, you have to use COM.
Am I the only one who still remembers Windows existed before OLE and later COM? The original RPC in Windows was based on sending messages to windows (and suddenly the name of the operating system makes complete sense), each message having, besides the target window and the message type, a word parameter and a long parameter. If you needed to send more data, you allocated memory from the global heap (which was shared…
https://learn.microsoft.com/en-us/windows/win32/dataxchg/abo...
COM (ab)uses window messages primarily for objects with thread affinity. Microsoft don't (didn't?) have a standard way to post lambdas to a thread's message loop like most platforms do, so they hack it by using GUI messages to a hidden window.
Earlier quoted context omitted.
All these things you listed are objectively bad and a tumor and I'm glad that those that are gone, are gone for good, because the one that stayed is a menace to any programmer caring about his sanity.
Bad how and why? 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.
Earlier quoted context omitted.
When everything is a file, what is a "file" becomes flexible. 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.
An attempt is being made to reduce everything to: interface UniversalInterface { fun open(…) fun read(…) fun write(…) fun close(…) } If you went to a software engineering design review meeting, proposing that several different kinds of objects representing everything from files, network sockets, to arbitrary devices should all use the interface above, you’d be laughed out of the room. Ultimately, when someone does en…
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.
Earlier quoted context omitted.
Plan 9 had many improvements over Unix of its times. It opened up too late to conquer the world though. Some good things from it were imported into Solaris and Linux later. 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 (w…
I personally don't like WASM. I think the Native Client (which is more than a decade old today) was a much better technical solution. It used actual cpu native assembly bundled with a verifier, and had actual good integration into low-level platform APIs like graphics, threading, etc. instead of using this weird Javascript bridge approach. Due to it being native code from the start, it also had none of the startup pe…
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 %)
Earlier quoted context omitted.
When everything is a file, what is a "file" becomes flexible. 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.
An attempt is being made to reduce everything to: interface UniversalInterface { fun open(…) fun read(…) fun write(…) fun close(…) } If you went to a software engineering design review meeting, proposing that several different kinds of objects representing everything from files, network sockets, to arbitrary devices should all use the interface above, you’d be laughed out of the room. Ultimately, when someone does en…
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
"Everything is a file" is not a good idea, because different objects have different interfaces. For example, a network socket is not a file because you cannot seek it. A process is not a file because you cannot send signals to a file. 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 A…
Abstractions with 3 orders of magnitude difference in latency / bandwidth are not abstractions.
Earlier quoted context omitted.
When everything is a file, what is a "file" becomes flexible. 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.
An attempt is being made to reduce everything to: interface UniversalInterface { fun open(…) fun read(…) fun write(…) fun close(…) } If you went to a software engineering design review meeting, proposing that several different kinds of objects representing everything from files, network sockets, to arbitrary devices should all use the interface above, you’d be laughed out of the room. Ultimately, when someone does en…
This is very obviously an acceptable solution because the whole world runs on TCP.