Plan 9 from Bell Labs
github.com
github.com
Homepage: https://code.google.com/p/plan9front/
Releases: http://9times.cat-v.org/
bullshit(1) (print out a stream of bullshit)
feminize(1) (replace sexist remarks)
theo(1) (print out insults from Theo de Raadt)
troll(1) (automated trolling) # same as theo(1) it looks like
For anyone not familiar, they have been the stalwarts of Australian political satire for decades.
http://en.wikipedia.org/wiki/John_Clarke_(satirist)
http://en.wikipedia.org/wiki/Bryan_Dawe
http://mrjohnclarke.com/projects/clarke-dawe
https://www.youtube.com/user/ClarkeAndDawe
http://www.abc.net.au/news/programs/clarkeanddawe/ (may not work outside Australia.)
Classics include the 100 metres sprint track, which was "about" 100 metres long and someone asking how many "smacks" their website received.
http://en.wikipedia.org/wiki/The_Games_%28Australian_TV_seri...
I always loved the "everything is an object" approach and in a better world this not NeXT or Windows would be our underlying principle.
Huh? What's the relationship?
Does someone have examples of cool things you can do in wmii thanks to this?
[1] Google Tech Talk about i3: http://www.youtube.com/watch?v=QnYN2CTb1hM (this question at 15:30)
Oberon also had quite nice concepts, specially version 3 with Gadgets.
Which sadly isn't at all what Plan9 does, in the usual "worse is better" way of Unix. Objects would allow a bit more versatility than the "everything is a file, usually one with plain UTF-8 text" approach. (And actually, Windows is closer to an object world with COM, as evidenced by e.g. the core model of PowerShell)
Of course, an object-model has a hard time when the rest of the world and the net is talking in files, you're also much more likely to create a walled garden.
As for simplicity, I can understand that regarding systems like Smalltalk (or possibly lisp machines), although Oberon serves as a prime counter-example here. It did inspire the Acme editor, and here you can see that if your basic text model is objects, not just a byte-stream, some extensions are easier to do (different fonts, syntax highlighting, widgets).
And yes, I'm aware that the usual response to that was and is "you don't need that". Milages obviously do vary.
It is the logical successor to unix that never took off because unix is "good enough"
The programming language (Plan 9 has its own C dialect), breaking with POSIX, abolishing the process/thread dualism and doing away with the root user just to name a few.
By getting rid of all these inherited liabilities they were able to create a much slicker, much more uniform and most importantly truly network centric OS, which in many aspects (not necessarily in terms of performance) still surpasses modern unix-derived operating systems(you know...the usual suspects). On the other hand the lack of backwards compatibility and the high barrier of entry prevented Plan 9's widespread adoption outside the research community.
On the contrary if we need new functionality today the way to go seems to be piling new layers of abstraction on top of the already overly complex stuff we gatherd over the years until everything becomes an incomprehensible mess of special cases(16 million loc linux kernel, anyone?). That of course is a good ol' tradition, which started when we first fumbled network support into the unix kernel and thereby broke the open-read-write-close interface convention.
To summerize: Plan 9 is not Unix. Thankfully...
Access everything like a local filesystem: ftp, ssh, etc. it's all built-in and just works.
With that said:
* All services are network-enabled file servers speaking a common protocol called 9P.
* UI makes heavy use of mouse chording, is inspired by Oberon and old school Smalltalk environments. Supports seamless interaction through an inter-application messaging mechanism called plumber (e.g. you can write a rule that will make all ISBN numbers in a desktop application automatically act as a hyperlink to a web application).
* The rc shell fixes a lot of deficiencies in the Bourne shell.
* Per-process namespaces obsolete a whole lot of things like symlinks.
* There is no superuser (root account). This is obsoleted by an auth server called Factotum.
* Uses its own compiler suite that makes cross-compilation particularly easy, compared to the mess of doing so with GCC. It also uses its own much cleaner libc routines that are quite distinct from POSIX or the messy glibc additions of today. Has its own thread library, as well.
* All network information is held in a text file database mounted on a file server.
* The default file system (Venti) is inherently versioned, introspectable and has backup built into it. You can do things like swap in libraries from cache and revert changes without a hitch.
* Everything is statically linked.
* Uses mk instead of make.
* A lot of things like recursive copy and find aren't built into the standard commands. It's expected you actually chain together commands instead of reinventing the wheel for every single operation. The canonical example is the use of du to walk the file system tree, for everything. This replaces find and other things.
* Designed not just to be multi-user, but multi-tenant. Makes many uses for containers and access controls unneeded because of its core design.
* So much more.
Try it. It's more relevant now than ever.
If I want to access files from a remote machine — mount its file system. Want to play my music from my laptop using the speakers connected to my stationary computer — mount its sound card into my device folder. If want to use another machine as a network gateway — I mount its /net.
Even the editor acme has its own file system, which makes writing a script doing something fancy in my editor really easy. The file system gives easy access (read/write) to anything from the currently selected text in each window, to the "menu" at the top (called the tag). And if I write a script, it is executed anywhere in acme by middle clicking its name.
What makes this all work smoothly is that mounted file systems can overlap, and that each process is presented its own name space. This completely removes the need for symbolic links and unix sockets.
Wow, that sounds really powerful. I've just read a bit about inter-process communication and sharing in Linux, and that seems like much more of a hassle than this.
> Even the editor acme has its own file system, which makes writing a script doing something fancy in my editor really easy. The file system gives easy access (read/write) to anything from the currently selected text in each window, to the "menu" at the top (called the tag). And if I write a script, it is executed anywhere in acme by middle clicking its name.
That sounds like it might be the answer (an answer) to something I've been wondering about: how to let another process - outside the editor - have access to the contents of the editor. Like for example synchronizing the editing/viewing of a file, instead of the outside process only using the file stored on the disk, and reloading whenever the editor saves the file. Could one use the file system of Acme to have another process view for example the file that it is being used to edit, in real time? I'm thinking that something like that might be useful for collaborative editing (at the least, letting one person edit the file while the other person watches the editing, maybe in the same kind of editor but hopefully through whichever editor or program that she wishes to use).
Here is a video of using Acme, and a port of Plan 9 userspace tools to other systems:
That is; Plan 9 is a research project and it is relevant the way research is relevant: For the future.
In some alternate Microsoft strategic universe it might have been released as "OS/2 3.0", but it has effectively no inheritance from the OS/2 1.x/2.x/3.x code base.
Acme is amazing, but the whole thing uses mouse chording and requires a 3-button mouse, so it requires a lot of getting used to if you're newer to computers than, say, 1990.
In general, Plan9 delivers on being "a better UNIX" in terms of what a standalone process perceives as its runtime environment - everything of consequence is a file, regardless of its location, and mounting remote devices of all kinds is wonderfully consistent.
Sadly, all the "nice" things you take for granted on Linux (like hardware support, graphics compositing, audio, wi-fi, graphical web browsers, even SSH and modern language runtimes) are absent or have to be bolted on with fairly ugly hacks.
Still, it runs OK on a Raspberry Pi. Wish it did so on a ODROID-U3, though.
Where have you been all this time? :)
Unfortunately I'm all talk at this point. I have to set up an actual plan9 machine at some point and start working on it if I were to get anywhere.
"All those parentheses in Lisp are pretty stupid, for one."
Considering that the Plan 9 UI fundamentally revolves around mouse chording, I wish you luck with that. It's a shame that Unix users are stuck in the keyboard-only mentality that they write off the mouse as some tool for lowly end users.
works for me!
btw, you can simulate mb 2 and 3 by holding down keyboard modifiers while clicking mb1.
Not really, no.
See wintext(1).
Pretty neat.
Edit: Of course this does not make it much easier if you really just want to execute the very last command. But usually you want to either
* edit the last command, because you mistyped it, in which case you can edit the old command in place and then proceed as described above
or
* you want to execute not the last but some previous command in which case this becomes increasingly useful the older the command is
I'd venture to say that Plan 9 was never meant to be a mainstream OS. It essentially served as a playpen for new OS/systems ideas and research at Bell Labs at the time.
A lot of those ideas were pretty influential: union mounts, per-process namespaces, user-space file systems, UTF8, human-readable protocols, rfork(), file-object interface ubiquity, concurrent programming model, etc. You can see how these ideas have pervaded our current systems landscape.
The implementation of Plan 9 itself is great, but I don't think success of the Plan 9 project should be limited to whether or not its specific implementation stays current and modern. The UX was never designed with the common user in-mind, and it arguably was never the core focus for the system. A greater success would be to see its actual core ideas spread out into other mainstream systems.
So instead of making the Plan 9 UX more modern, why not work on getting some of its missing features into Linux instead? Last time I checked, Linux still needs a union-mount implementation. This way, the world benefits.
BTW, you might like this: http://swtch.com/plan9port/
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux....
As long as that's true, union mounts in linux are not really useful in the same ways they were in plan9.
Maybe tinyssh could qualify as an alternative...
I don't think tinyssh is less complex, as it is compatible.
That is based on how Oberon UI works, which then again is based on Mesa/Cedar at Xerox PARC.
Coming from a Linux and Solaris background the shell was quite basic to say the least! I remember on some instance that we for some reason wanted to bypass the web UI and hand-edit some file and the only editor available was some variant of ed...
But with a steady hand when doing such things and software upgrades etc it worked really well and was quite capable for the time (2006).
Then of course, Plan 9 has one of the most versatile text editors out there: Acme.
The shell itself is rc(1), which cleans up the mess significantly from Bourne shells.
(Not that plan9 in rust wouldn't have merit -- I wonder, post Rust 1.0, if someone ends up writing a full OS, starting with Rust and as much assembler as needed -- if it would make sense to mix go and rust for some of the user-space -- or if it'd make more sense to just stick with Rust).
For the folks who didn't quite know what plan9 was.