Plan9's underlying "everything is a filesystem" paradigm is wonderful, but as a hardcore user of vim/emacs and fan of tiling window managers like i3, the mouse-centric Rio/Acme interfaces seem to be pretty clunky and inefficient.
Its C-inspired programming language is also pretty primitive. I'd much rather have seen it built around scheme, lisp, or even a modern statically-typed language like OCaml, Haskell, or SML.
Unfortunately that would be tantamount to wanting it designed and written by completely different people; Pike and Thompson are clearly comfortable with that level of abstraction, to judge by Go.
Moreover OSes designed with higher level languages tend to end up in a very different place even if they start with superficially similar assumptions—compare for example the early Lisp Machine OSes with TOPS-20, or ITS. "Everything's a filesystem" tends to mean "everything's a stream of bytes", which is in some ways a defeat for strong typing at the OS level for all that it can be convenient. I know I've had to write text level parsers for things like the output of multipath -ll (which is not standardized and is intended for human readibility and so changes radically every now and again, but is still the best source of some of that data). Now with Plan 9's FS structure you can arguably turn tree-structured data into a filesystem with files as the leaves, but this doesn't generalize well to non-tree-structured data.
That said I really like the OS, and I'm even willing to admit that Acme is pretty good (just not to my Emacs-tainted taste). But I can't imagine what a relational DB would look like in that idiom, unless it's "SQL query as filename". Individual tables, fine, but joins? Transactions?
The same way you would on any other OS. No-one said everything has to be a file, even in Plan 9. Only if it makes sense to be a file. Semaphores aren't files, grep isn't a 9p server, neither is malloc, ...
Its C-inspired programming language is also pretty primitive.
It's actually very beautiful. It's just so damned simple. Despite Plan 9's huge codebase, if you open an arbitrary source file, chances are you can read and grok it in one sitting.
It's shocking especially if you're used to the needlessly complicated modern codebases of today (particularly ones that copiously use GLib, D-Bus, etc. on Linux), but once the initial shock dies down, it's a breath of fresh air.
"I'd much rather have seen it built around scheme, [...]"
It's not meant to be built around any language. If there's a language you want to use, just start using it. All you need is access to the system calls. The whole point of making everything a file system is so that you don't have to cram everything together in the same address space. There's no foreign function interfaces or calling conventions you have to deal with if you want to use a new language with the system. It's all reads and writes. Ocaml, Haskell, and ML all have read and write, so if you want to use a less primitive language, there's nothing stopping you.
Yeah, the wm didn't look that great by modern standards. However, the whole underlying idea is pretty compelling. I'd like to see something like plan9 or inferno retrofitted with a more modern interface, loaded with modern tools and, yes, being built around a more modern language.
I've been messing around with Inferno for a while (link below for completeness). I would love to have, say, Clojure, Python or something else with a sizable set of built-in libraries running on it, but (at least where Inferno is concerned) I had a lot of trouble finding anything to bootstrap that kind of environment (Inferno uses the `dis` VM, and there is a GSOC project that sort of gets Java running around that, but, again, no readily usable stuff).
NT might have system objects structured in a tree for privileged access, but it's not quite the same thing as having everything as a file system object that's transparently accessible by any application.
eg, you couldn't use Notepad to edit those NT objects, where as you could with Plan 9's design since.
The problem is backwards compatibility. To make the code transition from Win16API to Win32API very easy in 1994-95 era Microsoft made several design decisions for Win32API, that don't make sense anymore - 20 years later.
Unfortunately, the Windows shell (explorer.exe/shell32.dll & cmd.exe) are more limited than what you can do with Win32API.
One can access the NT object tree from C/C++
"\\.\PhysicalDrive2" ... opens third physical drive
"\\.\C:\" ... opens the file system of the C: volume
"\\.\COM1" ... opens serial port 1
"\\.\pipe\pipename" ... opens named pipe
"\\.\mailslot\sample" ... open mailslot
"\\?\UNC\server\share" ... opens universal UNC path
"\\?\C:\" ... opens C:, you can exceed the MAX_PATH limits
Instead of further improving Win32API, as they have done like ReadFileEx() (http://msdn.microsoft.com/en-us/library/windows/desktop/aa36... ), Microsoft toys around with several dotNet API layers on top of Win32API and now a WinRT API that stills sits on top of the Win32 subsystem. Windows NT would support several subsystems (like there are POSIX, OS/2, Xbox subsystems for WinNT/ReactOS).
It's a shame if it has this architecture that you can't access a pipe in the same way as a socket using the traditional C API. There's a whole mess of handles, C files and the really nasty self-incompatible MSVCRT.
Well, you can use Win32API CreateFile(), WriteFile(), ReadFile() to access, read/write files, pipes, named-pipes and mailslots (all types also over network).
This makes me wonder: imagine ten years from now, when Rust is a mature systems language (or some other language shooting for safety sans GC that arises in the meantime) and the open source community – tired of dragging around C/C++ security issues – decides to rally around an open source operating system all over again...what's more likely, that we'll just reimplement UNIX all over again for the umpteenth time (but in a safer systems language) or that we'll actually aspire to something better?
I love the slide where plan9 is compared to Linux (37 syscalls, 148,787 lines of code).
For me, the missing tools would be a good up to date browser (google chrome or firefox) and something like virtualbox for virtual machines. I think the browser can not work correctly without good video drivers. Libre Office would be a bonus.
are you sure you even get Plan 9? the point is to avoid bloatmonsters like LO and most browsers, with smaller alternatives that work well with the team of the core utilities.
drivers are a given though. i'm not sure what their philosophy on virtualization is though.
It is unreasonable to think that a system that is not well-suited to desktop use is therefore "going to waste". The features that make something good for supercomputers, appliances, network infrastructure, embedded devices, and so on, are all fairly distinct from what makes a system good on a desktop.
A system could, in theory, be both (although you end up with a least-common-denominator situation), but they are separate.
It's completely unreasonable. Why would someone want to waste a bunch of their time and money writing word processors and web browsers to win a pointless popularity contest? What would a word processor or web browser on Plan 9 enable you to do that you can't do already on Windows? Mass appeal is not the only way to evaluate the merits of a computer operating system, and Plan 9 isn't going to go to waste because it wasn't the most popular way to watch Youtube videos and write TPS reports.
the model of plan9 lends itself to a radically different way to interact with pretty much everything. For a plan9-esque web browser, each site - nay, each element of a page - could be virtual files in an fs graph, and as you access pages and content you pull down the local graph into regional cache, and other 9P enabled systems see in your visible overlay that cache set.
You end up with a distributed web without needing low level distributed meshnets replacing old IP tech, because 9P on top does all the work.
Or word processing, the working draft is its own virtual file system with some organization, and collaborative editing is just working on the same 9P Mount, and each hostname can identify the editor.
That might be what someone means by "wheres my web browser?" because plan9 is meant to be an experiment - if the successor to the http / html web comes from anywhere, the best replacement (but probably not the most popular) will come out of radical new ideas like what plan9 regularly tries.
Abaco (the web browser shipped with Plan 9) already does what you're suggesting, using webfs and an HTML parsing library.
It might be possible to replace that parsing library with a version of Webkit or Gecko ported to Plan 9 in order to achieve "modern" web standards support while sticking to 9P and such for the actual network portion of web browsing.
This discussion is becoming a little uncivil, but I'll try to stay on-track.
"Nobody will [care] about your [...] operating system if it consistently fails to be useful for day-to-day work."
Nobody except those who already find it useful for their day-to-day work, some of whom have already explained the system's utility to them in this thread. Only if you think popularity is the only way to judge the utility of a computer operating system can you so easily dismiss such a large and influential body of work.
I posed a question earlier which you didn't address, and if you think chasing after mass appeal isn't pointless you should have an answer for: What would a word processor or web browser on Plan 9 (which everyone here seems to agree is cool) enable you to do that you can't already do elsewhere?
You're the only one that thinks anyone is talking about popularity. The fact is that if you had something similar to a word processor (for example) natively on Plan 9, you'd be able to read and write rich text, and still have it be in the idiom of Plan 9, the plumber, chords, tools, etc. and not have to switch over to the other OS.
It's totally possible to have a (for this example) word processor without having to have icons, nested menus, clippy, bloat, or whatever it is that you're objecting to.
I'm not objecting to bloat or Clippies or any of that other stuff. I'm objecting to this frame of mind that people have which laments the lack of web browsers, has no interest or intent to write one themselves, but then wonders why no one has spontaneously written one for them free of charge, and then decides Plan 9 is a waste or non-starter on account of it. I don't mind if someone decides Plan 9 sucks† or isn't right for them, but the logic some people in this thread have used to arrive at that conclusion is unreasonable. There's no money in it, and the marginal utility of a word processor on Plan 9 over a word processor on Windows is evidently negligible enough that no one has taken a personal interest in writing one for themselves.
All of the features fantasized about in this thread you could write yourself if you wanted to and had the time and money. If the person lamenting the lack of a spreadsheet program lacks either the time or money or interest to write it, it shouldn't be much surprise that everyone else lacks them too. It is unreasonable to dismiss a system because no uncommonly charitable programmer has donated their time to write programs that they don't personally need or get paid for. Toilets are valuable enough that people pay plumbers to put them in their houses so they don't have to piss on their mattresses, but apparently no one can think of anything valuable enough about a Plan 9 word processor that they would be willing to do anything that would make it a reality.
Really none of this is specific to Plan 9 or even to computers. Maybe I should have bit my tongue, rolled my eyes, and kept quiet like I normally do.
Plan 9 doesn't seem to have any compelling articulated arguments for any use cases that make it worth looking at beyond mere academic interest.
If we want to look at it from a non-academic standpoint, the lack of these tools makes it unpleasant, and the lack of use cases makes it seem a waste of time to investigate.
The argument of "If you want these features, write them yourself" is not wrong, but it ain't winning any friends either.
A simple thing that the Plan 9 fans could do would be to explain what cases would justify picking it over some other *nix--that alone might be enough to get some of us busier programmers to justify sinking our (small) free time into adding stuff to it.
I guess I didn't explain my popularity contest arguments from earlier very well because since this is where all Plan 9 discussions end up, I took it for granted, but this winning friends and evangelizing stuff is what I was talking about.
Among programmers, Plan 9 is not so obscure. Anyone with an interest in programming something besides a commodity system has stumbled across it or seen it mentioned somewhere. Plan 9 was built to be practical and its authors wrote about its practical advantages at length, so anyone who cares can just go to the web site and read about it. Anyone who wants or has an interest in what Plan 9 offers already has everything they need.
Instead of telling people what they either don't care about or already know, I'd rather spend my own time writing my own programs. Unless someone is waving dollar bills in front of my face, I have no interest in convincing people that they should use a research operating system that doesn't fit their needs so they can write programs for it to fit their needs. Unless I'm getting paid or feeling uncharacteristically generous with my time, I'm not going to take too close an interest with what other people do with their computers.
For a system that is supposed to be so pragmatic and practical, it seems quite odd that there isn't a list of reasons to use it in production or a list of people using it for actual business.
I'm going to call bullshit on Plan 9 as a practical operating system without at least one of those pieces of information.
I know of at least one company (name escapes me) that uses the 9P format for practical communication and file work. I know of nobody (none) using either Inferno or Plan 9 as a system, unless you count a sad effort by /g/ or a few loons on IRC.
It's not simply enough to talk about namespaces, or simplicity of porting things, or the awesomeness of the everything-is-a-file-no-really-we-mean-it-this-time, unless you tie that back into the real world and show how it is a clear improvement over the existing tech.
That nobody has done this, and that nobody cares enough to evangelize it, means that the Plan 9 community will be nothing more than an interesting footnote until it is forgotten entirely.
You were blunt enough the first time. I don't care what you do on your computer. I can continue happily writing programs after you've forgotten about Plan 9. If people stop nagging me to write them a stupid web browser, and I stop nagging people to use my stupid toy operating system, everyone can be happy that way.
Chasing mass appeal has a point because what is popular is not as useful as it could be. I see people adapting themselves to the computer instead of adapting the computer to themselves or to their task. For example, a teenager who crashes the car because his or her eyes and fingers were attending to his or her "smart" phone.
Who said anything about winning a popularity contest? I just want to use a cool OS. Linux hasn't won any desktop popularity contests but it's still possible for average people to use it for day to day work.
>What would a word processor or web browser on Plan 9 enable you to do that you can't do already on Windows?
Do you even know what Plan 9 is? If you did, you wouldn't be asking this question.
Oh, I just read your HN profile. Sorry, I didn't realize I was talking to a troll.
You, sir, are a gentleman and a scholar. I only hope one day get the joy of understanding the roots of UNIX, the intention of Plan 9/Inferno, and the places it can be used outside of the PC world. I believe their major achievement is hardly the user interface or the driver support. Those are arcane measures of usefulness by today's standards. The main point of Plan 9/Inferno is not about where it runs at all. The point is that wherever it runs, the communication between networked resources is no longer a matter of each device being an island onto itself. It is designed from the ground to allow for a mesh of storage, computation, display, and other devices. The target audience is not your regular PC user just yet. I think the late Dennis Ritchie, of UNIX and C fame, said that Plan 9, much like UNIX, will not be fully appreciated for another 20 to 30 years.
This is stupid. Bemoaning that a research project is junk because the average consumer can't use it misses the point of a research project. A lot of scientific and research equipment can't be used by the average Joe, and has very little implication on their lives.
The reason it was posted here is because in Computer Science more then any other field the line between professional and research is blurred more then ever.
I used Plan 9 continuously for one summer, a while ago, when I was in high school. It's a nice environment, but certainly not something that could be used for day-to-day computing. I still needed another computer for almost anything that did not involve coding. I don't remember if that was before or after they open sourced it, but I distinctly remember poking around the source code during another summer. It's a pleasure to read it. They ignored a lot of received wisdom and the result is an elegant, if unpolished and occasionally buggy, system. IMHO it would have made much more of an impact if it had not been kept on a leash by Bell Labs.
I still use Acme occasionally and some of the bunch of scripts I use are in rc. Acme is a beautiful editor that doesn't get in my way much, but the mouse-only interface is fairly clunky and I don't have the time and energy to keep my own patches over it for sane (ahem, emacs) bindings. I use it, occasionally, as a distraction when working on a more boring project, or when I just have to write long streams of text that don't require much jumping around.
As people have said browser support is an issue, there is linuxemu + firefox but I prefer to remote desktop/vnc to
a windows/linux VM that my work's IT dept look after.
In this day and age throwing another VM at the problem is not a big deal, and is definitely easier than porting webkit.
I write C code for embedded and server side code so I can write this in portable C and run it on windows, Linux, plan9 or embedded under threadx.
Its an environment I am used to and I like it,
I find I am productive with it.
Not only does it lack them, there is a huge amount of resistance to porting them because they are 'against the spirit of plan 9' or something to that effect. Which increases the barrier to entry.
I'm a huge fan of the principles behind Plan9 but I've never done much more with it than install it, play around with it for a bit, read documentation and newsgroups on what makes it tick. Other than that I've de-installed it... And I would probably use it, maybe even on a (light) production box to see how well it would fare in real life given a chance.
But the amount of stuff that is missing compared to vanilla unix makes that a non-starter.
No one is stopping you from porting whatever you please. All you have to do is sit down and do it. If I had to guess, I'd say that the main barrier you face is that you de-installed it.
It should not be too hard for people to write utilities to fortify what Plan9 offers, if they know what to write. But it's a chicken-egg problem to write utilities if nobody uses the platform. Is it a dead cause?
Converting many of the tools used by the Unix hackerdom is made rather difficult by two aspects:
* Plan 9's approach on terminal is entirely decoupled from the TTY idea. The terminal is basically a program that takes commands, has a shell run them, and pipes back the result, with none of the VT-whatever stuff. Even getting ncurses-based tools to run would require some effort.
* There's no X11
There are some graphical tools for Plan 9 (including more or less barebones web browsers), but there is just enough difference from Linux and BSD environments that people aren't quite willing to cope with it.
Good point. I sort of lost contact with the Plan 9 world a while ago -- I kept following the news, but no longer ran a system. Last time I used it, the X11 port was somewhere between experimental and broken, and vim is, uhm, not the editor whose port I'd be interested in :-). My comment is certainly not up-to-date.
Edit: I share your point about the lack of need for either ncurses or vim (especially vim, hheheh). My first contact with Plan 9 was somewhat disappointing, mainly due to the fact that I approached it with the oh, Unix, I know this! frame of mind. I was very much a Linux fanboy back then (did I mention it was in highschool? And this is not the dumbest thing I did in highschool!). Only after I studied the source code a little, and learned rc more seriously, did I really begin to appreciate it.
None of which are likely to happen, I'd point out, because vim, emacs, bash and zsh are all tied into some sort of notion of a virtual terminal with software controlled cursors, etc etc etc. Plan 9's TTY is astoundingly primitive by those standards; essentially it emulates a line printer but doesn't even have the good grace to allow backspacing. Oddly, said terminal exposes the contents of the scrollback buffer—both read and write—to a file, which is how the native Plan 9 history mechanisms work. This is entirely deliberate, of course, and a substantial part of what makes the system so different and interesting, but step #1 to porting those would involve reinventing xterm, basically.
In theory for vim and emacs you could work around that by using the graphical interface, much as say Acme does. I would estimate this to be at least as much work as porting from X11 to, say, Cocoa was, and possibly even worse. And this port would only get you a vim or an emacs that was materially identical to its Unix counterpart—no Acme style control FS and essentially no cooperation with the normal Plan 9 UI elements.
That's quite a load of legacy baggage. If your first reaction to a new system is "how do I get my old environment?", you may be missing the point. You need two shells, two editors, and a specific (gigantic!) compiler?
There's a vi for Plan 9 (even skipping the old joke about the MIPS interpreter...). I think it's vim, but I haven't paid much attention. David Hogan did a gcc port, and mostly nobody cared so it languished.
Plan9 can probably gain traction in something completely different than workstations or even servers, more like embedded or highly specialized devices. Just like a lot of people say, often one needs single killer app.
I'm always interested to hear opinions from Acme/Sam users. While these "editors" have some unique features, don't you find annoying the lack of basic code completion and syntax highlighting?
Don't you find annoying the lack of built-in file browser and powerful regex-based transformation language?
Don't you find annoying the lack of quick access to search/navigate/execute/copy-paste mechanics via mouse click?
In Acme, all text is hypertext. The difference between Acme and previous generation editors (Vim, EMACS etc.) is like between The Web and a library of paper books.
> Don't you find annoying the lack of quick access to search/navigate/execute/copy-paste mechanics via mouse click?
Yes, which is why I've written some acme emulation for vim twice. (Incidentally, I was working on that yesterday before this link was posted: https://github.com/fmoralesc/plan9-for-vimspace I have to improve the button 2 functionality, and chords are still not supported, but I'm on it. A plumbing system is planned, although I'm not sure if its best to reuse plan9port's plumber or reimplement it.)
> In Acme, all text is hypertext.
Exactly. Which is why, even though I am a serious vim junkie, I love acme so much.
Not at all. I find syntax highlighting awful for actual programming (it's sort of useful for the first few days of learning a new language). It makes code less readable, and encourages some of the worst practices of programming. People have written tons about this. At its best, it's a crutch.
I think code completion is more of a mixed bag. It's useful when you're stuck in ugly environments with FrameworksAndLibraries[withFunctionsLikeThese], but I just avoid those environments.
Also, people have built external commands that do code completion. They're not as nicely integrated, but could be improved enough to be quite comfortable, if that's what you're after. (syntax highlighting couldn't ever really work in acme or sam)
I alternate between Plan 9 and Plan 9 from User Space. There's no getting around the browser issue, so when I'm on the go it's all the User Space version, sadly. When at my desk, it's easier to have a side-by-side setup, or VNC or whatever.
In a word, dismal. They recommend you VNC over to another machine for using a full web browser, since the current existing browsers are far from modern (think Mosaic-grade with some CSS support)
Sad to hear. You - by any chance - don't have any dev experience for plan 9 apps itself do you? Would be interesting to find out how hard 'ui' apps are to build. Incorporating webkit in a 'custom browser' might not be easy; but not undoable.
Yes, it's pretty much undoable. You'd have to compile webkit for Plan 9, which requires a C++ compiler, which Plan 9 doesn't have. There are some gcc ports, but I don't know how well they work. There are also probably a ton of dependencies. So a modern webbrowser is not really feasible.
It might be feasible to swap out Abaco's HTML parsers and such with a "modern" rendering engine like Gecko or Webkit while retaining its webfs-based approach to navigating the world wide web.
Very interesting read and very intriguing. I would be very interested to see what happened since 2006. On [1] you can see that there have been 7 workshops since.
But a nice status update to see if the project is still alive, where is it heading, who uses it for serious work?
Plan 9 and its successor/spin-off Inferno are both in active development.
Main difference:
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 [...]
generic binaries.
Its C-inspired programming language is also pretty primitive. I'd much rather have seen it built around scheme, lisp, or even a modern statically-typed language like OCaml, Haskell, or SML.