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 [...]
Inferno repo: https://code.google.com/p/inferno-os/source/list (latest commit May 25, 2014); http://en.wikipedia.org/wiki/Inferno_(operating_system)
Plan 9 repo: http://plan9.bell-labs.com/sources/ (latest commit May 26, 2014); http://en.wikipedia.org/wiki/Plan_9_from_Bell_Labs
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.
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?
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.
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.
Nonetheless, I might try a vm of plan9, for fun.
Notes here: http://the.taoofmac.com/space/blog/2014/05/04/2230#diving-in...
Try out WinObj.exe (Microsoft): http://technet.microsoft.com/en-us/sysinternals/bb896657.asp... (best with admin privileges)
eg, you couldn't use Notepad to edit those NT objects, where as you could with Plan 9's design since.
Some of them are the limited MAX_PATH, which is defined as 260 characters, reserved characters in file names, 8.3 filename aliasing (fixed), etc. - see: http://msdn.microsoft.com/en-us/library/windows/desktop/aa36...
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++
You can use CreateFile(), ReadFile(), WriteFile(), etc. Win32API function to work on NT objects (not just files but real NT objects, the name is just inherited from Win16API) - http://msdn.microsoft.com/en-us/library/windows/desktop/aa36... , http://msdn.microsoft.com/en-us/library/windows/desktop/aa36... , http://msdn.microsoft.com/en-us/library/windows/desktop/aa36...
Some NT path examples:
"\\.\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).
Berkeley sockets introduced in Win3.1 for Workgroups and later as WinSocks for IE 1 (based on Mosaic) came late (Bill Gates vision was the Microsoft Network based on Win95 GUI, later renamed was MSN as dial-up network): http://en.wikipedia.org/wiki/Berkeley_sockets , http://en.wikipedia.org/wiki/Microsoft_Network#MSN_Classic
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.
see also 9front, a plan9 fork with stuff included that's not been blessed by the Labs (which is just Jim & Geoff nowadays I think).
drivers are a given though. i'm not sure what their philosophy on virtualization is though.
A system could, in theory, be both (although you end up with a least-common-denominator situation), but they are separate.
Get off your high horse.
Nobody will give two shits about your toy operating system if it consistently fails to be useful for day-to-day work.
(Which is a shame, because P9 is quite cool.)
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.
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.
"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?
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.
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.
† It does.
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.
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.
It's somewhat like, "What would peeing in the bathroom offer you that you can't already do elsewhere, e.g. the kitchen?"
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.
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.
My money is on the former.
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.
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.
* 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.
There is also an ncurses port and a vim port. I don't feel the need for either of those.
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.
I'd love to use, learn more about, and improve Plan9, but the lack of the above make it pretty painful.
This is why Hurd is probably far more likely to gain traction in the foreseeable future than Plan9.
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.
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.
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.
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.
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)
Anyone here in the know on the current state of browsers on plan9?
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.
Going back to other environments is like going back to stone tools.
But a nice status update to see if the project is still alive, where is it heading, who uses it for serious work?
Approximately everyone else in the entire world: No, we don't.
I imagine this mascot reflects the developer demographic, but compared to common mascots it's a bit raw.