05:46 pm, 11 Dec 04
Systems Software Research Is Irrelevant
Rob Pike on why Systems Software Research Is Irrelevant. The general theme is that true experimentation and novelty has died out in OS design, and why. Blaming Microsoft is a scapegoat; there are other factors discussed in detail*.
* As much detail as slides can provide.
What could we do differently? Who knows? Here's an overview of Plan 9, Pike's OS from the 80s. I am sorry to write I know nothing about it, but I will read this now, but I understand it is "different" in some radical ways.
* As much detail as slides can provide.
What could we do differently? Who knows? Here's an overview of Plan 9, Pike's OS from the 80s. I am sorry to write I know nothing about it, but I will read this now, but I understand it is "different" in some radical ways.
(It's interesting you mention cars in particular because of all of the accusations I've seen about automobile manufactures / oil companies pressuring people not to invent more efficient cars. But there is some radical stuff going on, especially with ultralight cars, and I heard that even BMW is investing in that. And, of course, hybrids.)
I also reject the notion that no new or exciting ideas in systems are happening. What about exokernels, new filesystem/database blends at various layers, virtual machines, dependency tracking filesystems, new SMP models, etc. It just so happens that we play with a lot of these things on either a) UNIX or b) windows, which at this point is just an api.
I think pike is just pissy about plan9 not being adopted. It was better in a lot of ways, but not enough better in enough ways for people to care. I would assert that it was worse in quite a few ways as well.
Seriously though, even considering this in its time, the document sounds like a developer's attempt to invigorate non-developers.
No mention of BeOS? I seem to remember 2000 was during its lifespan. They did neat things, even in hardware (the analog geek port? eh?). Maybe a database filesystem is a poisonous feature -- MS did cut it from Longhorn.
Classic MacOS had some really neat ideas.
Good
- Hardcoded volume names? Nope - signed short refNums means renaming is no problem.
- Fragile hardcoded paths? Bah, vRefNum, parentDirRefNum, and file name.
- Metadata? The resource fork was a per-file joy-to-use database. Resource fork search chain made it easy to get or override system resources as desired.
- Regions
- MoreFiles
- Jasik's Debugger -- theta and omega commands!! Macsbug was cool too.
- Fast 68k CPU emulation
Bad
- resource fork prone painful to preserve, usually lost across platforms.
- \r
- important machine-wide low memory globals
- cooperative (wink, wink) multitasking -- great for benchmarks though!
- OpenTransport -- why XTI over sockets???
The principle innovations in plan9 revolve around the namespace, universal use of text interfaces, and distributed computing. It has a centralized namespace, which unix sort of tried to do, but didn't rigorously adhere to. For example, you don't open a socket the same way you open a file, which plan9 fixes using something like open(/net/inet/tcp/host/port).
The universal use of text interfaces is primarily for simplicity and byte-order compatibility. By using text only protocols you don't have to deal with byte-order, etc. Their /proc/pid/ debugging interface is completely text, which unix traditionally does not do.
The distributed computing aspect is the result of portions of the namespace handled by servers which may or may not be local. The combination of this and the constant use of the namespace for APIs mean that all sorts of services can transparently(to the application and user) be handled remotely.
They went after the idea of special-purpose distributed computing. You might have a file server, a cpu server, and a thin client. The file-server and the cpu-server only handle their respective jobs, you can't really log into them as there isn't really a local environment in many cases.
There were lots of interesting little innovations in various corners of the system. There's also lots of crap and complexity in it along with a healthy dose of "Not Invented Here" differences with unix. The actual implementation is also very 1980s and overlysimplistic in essential kernel services.