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
OSX has a larger userbase of Plan9 fans, I think, including a number who run plan9port on it (Rob Pike has said that he uses such a setup). So the bits that you can't get Plan9-ish might rankle someone. Windows isn't any better, but there aren't many people trying to make Windows feel anything like Plan9 in the first place, so nobody's too disappointed about it.
Presumably it's a sort of sideways/backhanded almost-compliment to OS X: it works well enough comparatively that its plusses overwhelm its negatives for the commenter. But, they still wish it supported more flexibility; and the fact it doesn't (and yet its plusses nevertheless still compare favorably enough to its minuses that the commenter continues to use it) leads to a sort of feeling of dissatisfaction and resentment.
Yes, exactly. I mostly love OS X in that it gives me nearly everything I love about Linux with almost none of the hassle. The window management story is terrible though. Wmii really clicked for me, and OS X really pales in comparison on that front.
Presumably the fact that you're tied into using Apple's window manager. But that's really loose and I don't totally understand why it merited being mentioned either, haha.
> I always loved the "everything is an object" approach
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.
I've always been fascinated by Plan9 and in particular the strict adherence to everything being a file. It seems like it works so well and makes administration much easier, and I wonder why it has been pushed for more in other OS's.
Can someone explain why Plan 9 matters? I mean this legitimately. How is this differentiated from yet another flavor of *nix? I'm sure it was hot shit back in the early 90s, but I don't see much of an appeal other than as a curiosity like OS/2.
First of all: Plan 9 is not another flavor of nix. If you expect it to be like Unix, you will* have a bad time.
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.
What I find most amazing is how the kernel is more like a file system multiplexer. Its job is to present a file system to each process built from mounting virtual file systems from all sorts of programs and remote machines.
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.
> What I find most amazing is how the kernel is more like a file system multiplexer. Its job is to present a file system to each process built from mounting virtual file systems from all sorts of programs and remote machines.
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).
Yes. It sounds very much like you want to checkout Acme (and Plan 9). You can test Acme on other operating systems to get an idea. On Linux (or Mac I think), you can even mount the file system using fuse, or access it using a special program called 9p.
Here is a video of using Acme, and a port of Plan 9 userspace tools to other systems:
Yes, one can't stress enough how much Plan 9 is not Unix.
When Bell Labs eventually gave up on Research Unix and started from scratch they deliberately broke with almost every standard and convention in existence.
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.
Your comparison to OS/2 may be apt. The details are a bit murky for me, but as far as I can tell from Wikipedia[1], OS/2 3.0 was at some point simply renamed to Windows NT, which of course is the underlying technology for Windows as we know it today.
That is; Plan 9 is a research project and it is relevant the way research is relevant: For the future.
That's not at all what happened. NT was a completely new OS foundation, unless you think Dave Cutler borrowed pieces of his own VMS work at Digital.
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.
You can check my other comments for more, but a couple of old-time UNIX folk I know described it as being dropped into a bare X11 environment with twm, a flint knife, and the Acme editor.
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.
Yeah, but that makes sense at the OS level. UX-wise (and generally speaking, for most common uses of a computer these days), Plan9 is, sadly, almost useless. I myself only use it because I _like_ messing about with different (and arguably better) operating systems, but it's very, very, VERY hard to do so for general "work" or even browsing the web.
I've considered spending time on plan 9 making the UX less crappy. I think the stuff under the covers is fantastic but the UX is not great. The three button mouse thing is pretty stupid, for one.
While modernizing and redesigning the Plan 9 UI is a valiant cause, it may not be the most efficient way to accomplish your goals.
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.
There have been union mounts of various sorts for linux for a very long time. The issue, in comparing them to plan9, has never been whether or not they were in the mainline kernel, but the fact that they require superuser privileges to use (because changing the view of the filesystem affects how privilege escalation works in unix).
As long as that's true, union mounts in linux are not really useful in the same ways they were in plan9.
Since the window system exposes all windows including their attributes(position,size, etc) via the file system, at least some of the tiling WM functionality could easily be implemented with rc scripts. Being a dwm user myself I planned to do so, but after using rio for some time I found this completely unnecessary since you can place your windows very conveniently with the mouse in the first place.
But how do you 'paste' without a middle button? That's the bit I miss most when I have to use a 2-button mouse. Thank god the guys who invented the scroll-mouse had the sense to build the middle-button into the scroll-wheel axle.
I'm not against a three-button mouse, I'm against its overuse. Example: in plan9, you can't hit "up" to re-use the last command you typed into a terminal. You have to copy+paste it with your mouse.
Not quite true. The command "" (much like bash's !!) runs the previous command you entered. It can also be given a prefix of a command and search the history for this command.
Even better:
Add fn term%{ $* } to your profile and you can just dbl-left-click and send the old command. And since Rio remembers your last menu item selection this becomes just dbl-left-sgl-middle-click on second execution.
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
The three button mouse thing is pretty stupid, for one.
"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.
Please don't. As a Pythonista turned LISPer, I've heard all that stuff before. What is pretty stupid is being unable to use Plan9 on a modern laptop with a trackpad -- again, check my comments on previous Plan9 posts.
So what is Plan9's alternative to SSH?
SSL seems even worse than SSH in terms of algorithms that you have to negotiate, and thanks to misconfigurations you can end up in a situation with no shared ciphers (if server accepts only RC4 and client rejects RC4 for example).
According to that mailing list message cpu uses 9P+ssl, and I consider ssl more complex than ssh.
May not be the case on Plan9 as it looks like their ssl only supports old algorithms and not too many of them.
> 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.
That is based on how Oberon UI works, which then again is based on Mesa/Cedar at Xerox PARC.
My experience with Plan 9 is from my first employment at Kreatel Communications and doing basic admin of the nCUBE/C-COR VOD servers that some of our customers used in production and we had for integration testing. The OS those servers ran, Transit, was apparently based on Plan 9.
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).
I quite like sam, from what I've tried so far. I think it's an interesting take on ed (but I much prefer acme) I still have "learn basic ed (or sam)" as a far-away goal (always pushed down my todo list, since knowing the commands is not enough: using them is what gives power)
That was great, thanks! I'd never played with ed before but as a vim user it was pretty easy to follow without having to think too much. I knew it was an ancestor but never knew it was so similar.
Yes, that post is my source of ed-ness, practical knowledge. Very good, well-written. But ah, the time to apply everything and the will to force me to use it!
I love how decent of a chunk Github's code identifier seems to think is Javascript. On a related note, has Plan9 been rewritten in Javascript yet, and if not, why are you slacking?!
While we could keep playing language-of-the-week-golf -- the go compiler is born from the plan9 c-compiler, and the go designer(s) had a hand in designing plan9. So my comment wasn't quite meant as just a popular-language-x-quip. Plan9 reborn in gopher clothing actually has some merit.
(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).
no - but i wrote a direct translation of libdraw to go, which works. note that i am talking about actual plan 9 libdraw, not plan9port's devdraw program.
