![[Home]](http://www.bayleshanks.com/cartoonbayle.png)
from time to time i feel the need to notes on ppl's opinions of how OSs could be made simpler. Oot isn't an OS but i don't have anywhere to put these, and maybe they'll somehow inform the library APIs for Oot.
---
"...the ideals of Unix: file descriptors and processes orchestrated with C. It’s a beautiful idea. This is not however what we interact with. The complexity was not contained. Instead I deal with DBus and /usr/lib and Boost and ioctls and SMF and signals and volatile variables and prototypal inheritance and C99FEATURES_ and dpkg and autoconf.
Those of us who build on top of these systems are adding to the complexity. Not only do you have to understand $LD_LIBRARY_PATH to make your system work but now you have to understand $NODE_PATH too - there’s my little addition to the complexity you must now know! The users - the one who just want to see a webpage - don’t care. They don’t care how we organize /usr, they don’t care about zombie processes, they don’t care about bash tab completion, they don’t care if zlib is dynamically linked or statically linked to Node. ... " -- Ryan Dahl
excerpt of Rob Pike's comment in the replies: "It's a different kind of mess, and for different reasons, but the Unix/POSIX/Linux systems of today are messier, clumsier, and more complex than the systems the original Unix was designed to replace. It started to go wrong when the BSD signal stuff went in (I complained at the time), then symlinks, sockets, X11 windowing, and so on, none of which were added with proper appreciation of the Unix model and its simplifications."
---
some excerpts from http://doc.cat-v.org/bell_labs/good_bad_ugly/slides.pdf
What makes Unix Unix? Something like the combination of:
All those things were solidly in place in the 1970s! To get to 2001, you need to add networking and graphics, but those are not definitive of Unix. Quite the opposite: these were added later and badly, with models taken largely from other systems.
cool things in Unix:
unix networking (too complicated) vs plan9:
Plan 9:
#include <u.h>
#include <libc.h>
...
fd = dial(netmkaddr(argv[1], "tcp", "discard"), 0, 0, 0);
if(fd < 0)
sysfatal("can’t dial %s: %r", argv[1]);
unix:
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <netdb.h>
...
struct sockaddr_in sock_in;
struct servent *sp;
struct hostent *host;
...
memset(&sock_in, 0, sizeof (sock_in));
sock_in.sin_family = AF_INET;
f = socket(AF_INET, SOCK_STREAM, 0);
if (f < 0)
error("socket");
if (bind(f, (struct sockaddr*)&sock_in, sizeof sock_in) < 0){
error("bind");
host = gethostbyname(argv[1]);
if(host){
sock_in.sin_family = host−>h_addrtype;
memmove(&sock_in.sin_addr, host−>h_addr, host−>h_length);
}else{
sock_in.sin_family = AF_INET;
sock_in.sin_addr.s_addr = inet_addr(argv[1]);
if (sock_in.sin_addr.s_addr == −1)
error("unknown host %s", argv[1]);
}
sp = getservbyname("discard", "tcp");
if (sp)
sock_in.sin_port = sp−>s_port;
else
sock_in.sin_port = htons(9);
if (connect(f, (struct sockaddr*)&sock_in, sizeof sock_in) < 0){
error("connect:");
strengths are also weaknesses:
eg " flat text files.
Amazing expressive power, huge convenience, but serious problems in pushing past a prototype level of performance or packaging. Compare the famous spell pipeline with an interactive spell-checker.
...
What Unix does well isn’t what people want. Integration and hand-holding: Not pipelines, but emacs or IDEs or COM.
((but)) The tool approach teaches lessons other communities can learn from. Try to diff two PowerPoint? docs.
...
Once, the commonest Unix program was grep . Today, it’s emacs or mozilla . People prefer integrated environments and browsers. The tyranny of forced interaction: No ability to step beyond the model. No programmability. (E.g.: Fetching maps, NYT) Wasting human time.
...
Drifting back towards typed, binary files (Ugly): cat . doesn’t work any more ( readdir vs. read ). Databases to hold code. HTTP/HTML interfaces to system services
File Systems
Hierarchical file system was a huge improvement when Unix first appeared.
Devices as files Plan 9 pushed this much farther: /proc , /net , /fd , /dev/draw , etc.
Spectacular ease of networking: total transparency. (Good) (NFS gets this wrong (Bad)).
Some things don’t work well this way: e.g. fork ing and execing.
Mail: upas/fs is fine example of both strengths and weaknesses. Break mailbox into files MIME as hierarchy Attachments appear as .gif files, etc. Much overhead, too many file-system interactions.
Unix’s record of portability is mixed. There are a zillion versions of the system, and widely variable interfaces, leading to:
The Interface to Security Weak security that’s easy to use will help more people than strong security that’s hard to use. E.g.: door locks. Tip: User interface is more important than security. Bad user interfaces drive people away from security. Weak security is much better than none at all.
Community Unix has always been available in source code form. Shared source leads to great progress (Good) but lack of direction (Bad) and incompatible variants (Ugly). The people in this room represent a single community, yet how many different Unix variants are running on the laptops here?
The lesson we never learned Microsoft succeeds not because it’s good, but because there’s only one of them. Division leads to wasted effort and political infighting, limiting the success. Past: 1970s: Variant academic versions: Bell Labs, Berkeley, Toronto, Sydney. 1980s: Variant commercial versions: System V, Xenix, SunOs?, DEC Unix, ... 1990s: Variant open versions: Linux, NetBSD?, OpenBSD?, Plan 9, ... Future: Unixes of the World, Unite!
Conclusion The Good things about Unix are also its Bad things. The things that made it successful also limited its success. C Tools Text files Portability Open source The irony is Ugly. For the next billion seconds, let’s find ways to remove the limitations without losing sight of the original vision.
Two Answers: 1. What is the best thing about Unix? A: The community. 2. What is the worst thing about Unix? A: That there are so many communities.
plan 9:
there's also various plan 9 docs at http://doc.cat-v.org/sitemap
---
" Reuse
Works for Unix filters Big things (OS, DB, browser)
Flaky for Ole/COM " -- [1]
---
" Conclusion
What’s worked in computer systems research? Topic 1999 2015 Virtual memory Yes Yes Address spaces Yes Yes Packet nets Yes Yes Objects / subtypes Yes Yes RDB and SQL Yes Yes Transactions Yes Yes Bitmaps and GUIs Yes Yes Web Yes Yes Algorithms Yes Yes Parallelism Maybe Maybe RISC Maybe No Garbage collection Maybe Yes Reuse Maybe Yes Capabilities No No Fancy type systems No No Functional programming No Maybe Formal methods No Maybe Software engineering No No RPC No Yes Distributed computing No Yes Security No Maybe " -- [2]
---
sel4
---
four (related) systems-y programming-language-y ideas that appear to have 'lost' are:
---
https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/asplos2011-drawbridge.pdf page 4
or
https://github.com/oscarlab/graphene/wiki/PAL-Host-ABI
---
notes on plan 9/inferno
relation between plan 9/inferno
Plan 9 was first and Inferno is a descendent, but not necessarily a successor; Plan 9 seems to be more of a standalone OS for running on bare metal that supports POSIX, whereas Inferno seems to be more of (a) a portable overlay, and/or (b) an easier to port OS. Some people use both in different contexts. [3]
"Plan 9 and Inferno share the same basic core kernel, networking stack, file system protocols, and drivers -- the main difference between the two from a kernel perspective is that Plan 9 has a virtual memory system and Inferno just uses a flat address space. User space tends to be completely different as Inferno's user space is entirely within the virtual machine. Plan 9 can run C code and other generic binaries, it can also run Inferno applications by using the Inferno VM." [4]
They both apparently use the 9P protocol (version 9P2000), although Inferno apparently calls theirs 'styx'.
The 9P protocol is apparently described in: http://man.cat-v.org/plan_9/5/intro
https://en.wikipedia.org/wiki/9P_(protocol)#Implementation gives a summary of the 9P protocol:
(details linked from https://en.wikipedia.org/wiki/9P_(protocol)#Implementation )
Plan 9/inferno design features [5]: "[t]he foundations of the system are built on two ideas: a per-process name space and a simple message-oriented file system protocol." -- [6]
" Unlike most other operating systems, Plan 9 does not provide special application programming interfaces (such as Berkeley sockets, X resources or ioctl system calls) to access devices.[22] Instead, Plan 9 device drivers implement their control interface as a file system, so that the hardware can be accessed by the ordinary file input/output operations read and write. Consequently, sharing the device across the network can be accomplished by mounting the corresponding directory tree to the target machine.[4] "
"The plumber provides an inter-process communication mechanism which allows system-wide hyperlinking." [8]
"In 1991, Plan 9's designers compared their system to other early nineties operating systems in terms of size, showing that the source code for a minimal ("working, albeit not very useful") version was less than one-fifth the size of a Mach microkernel without any device drivers (5899 or 4622 lines of code for Plan 9, depending on metric, vs. 25530 lines). The complete kernel comprised 18000 lines of code.[18] (According to a 2006 count, the kernel was then some 150,000 lines, but this was compared against more than 4.8 million in Linux.[22])" [9]
" Within the operating systems research community, as well as the commercial Unix world, other attempts at achieving distributed computing and remote filesystem access were made concurrently with the Plan 9 design effort. These included the Network File System and the associated vnode architecture developed at Sun Microsystems, and more radical departures from the Unix model such as the Sprite OS from UC Berkeley. Sprite developer Welch points out that the SunOS? vnode architecture is limited compared to Plan 9's capabilities in that it does not support remote device access and remote inter-process communication cleanly, even though it could have, had the preexisting UNIX domain sockets (which "can essentially be used to name user-level servers") been integrated with the vnode architecture.[20]
One critique of the "everything is a file", communication-by-textual-message design of Plan 9 pointed out limitations of this paradigm compared to the typed interfaces of Sun's object-oriented operating system, Spring:
Plan 9 constrains everything to look like a file. In most cases the real interface type comprises the protocol of messages that must be written to, and read from, a file descriptor. This is difficult to specify and document, and prohibits any automatic type checking at all, except for file errors at run time. (...) [A] path name relative to a process' implicit root context is the only way to name a service. Binding a name to an object can only be done by giving an existing name for the object, in the same context as the new name. As such, interface references simply cannot be passed between processes, much less across networks. Instead, communication has to rely on conventions, which are prone to error and do not scale.
-- Roscoe" [10]Links:
---
