It should be noted that Plan 9 is far from dead or outdated. The 9front developers have continued to make many improvements to the OS while retaining backwards compatibility. 9legacy offers a set of patches which try to stay closer to the original Bell Labs distribution. There are also other ongoing developments, such as my own Advanced Namespace Tools and a new grid of public 9p services.
Is there a contingent of 9fans doing work on using Plan 9 for DevOps? The fact that doesn't have popular graphical software (or even the same conventions) wouldn't hold it back there. If it's really as well designed and coherent as the praise always makes it seem, it should be an attractive option on the server. So developers can stick with Windows/Mac/Linux on personal machines, and should be deploying to Plan 9 in the cloud, right?
It might make sense in theory, but in practice there are very very few Plan 9 users and developers. Fundamental design quality is never a guarantee of "success" as measured by size of the userbase. If you look at the culture of Plan 9 users, there is also often a somewhat adversarial perspective on standard software. It's a complicated topic, with a lot of weird history involving things like Plan 9 not having a decent open source license for a long time. Once the patterns were established, sociocultural issues outweighed any technical issues. You can imagine an alternate history where things all worked out differently, but at present, Plan 9 is hard to view as a realistic option for any kind of mainstream corporate software work. A lot of us think that is probably more of a good thing than a bad thing, economic incentives and software design quality are often misaligned.
> ...economic incentives and software design quality are often misaligned.
I'm reminded of this note from the README for 3Blue1Brown's `manim`, an animation library for his own use (and thus decidedly not a community project):
"But the tricky part about anything which confers the benefit of originality is that this benefit cannot be easily shared."
Just because a project has an open source license doesn't mean that it has, or should have, open governance.
This also raises an interesting point that I hadn't properly considered before: an open-source project doesn't have to be universally applicable to be useful.
Anyone that's ever built an open-source demo or example project has potentially contributed to someone else a lot, even if they can't directly use that project or have to make modifications to apply it to their situation.
If more people were willing to open up seemingly niche projects like this, it would surely help countless others.
I guess you could call it a hobby as much as anything. It feels more serious than that to me, based on the amount of time and effort I put into it. In addition to developing os-level projects for Plan 9 itself, I write interactive fiction games, which feels to me like a serious artistic pursuit, but most people would put interactive fiction text adventures in the "hobby" category. My brain doesn't really follow the dichotomy of using whether or not something is profit-making for how "important" it is. I understand that is an attitude that is somewhat a measure of personal privilege to not focus that hard on economic issues.
Would you mind sharing a few good intro sources for Plan 9? I’m a small-time Linux contributor, but haven’t delved into any other operating systems. Interactive fiction games are always appreciated too :)
I use 9front mostly because it's a nice place to live. Most of the stuff I do doesn't run on Plan 9, but I to the development on a 9front system. Compared to FreeBSD (I don't have much Linux experience) the system is simpler and easy to write for. The tools are well thought out and simple, plus it has my favourite text editor. I work on 9front entirely because I use it. Not working on it would be like not repairing your home if it breaks because someone else built it. If you have the ability to help make and improve the projects you live in, I really think it's important that you should. This is basically the raison d'être for 9front's existence.
The Linux kernel is maintained by hundreds of contributers and Linus is quite cautious about regressions.
Linux has a mature ecosystem and several flavors and components to choose from.
Plan9, while leagues ahead the *nix design architecturally, has a much smaller ecosystem, no real choice in components, and virtually no enterprise support.
> The Linux kernel is maintained by hundreds of contributers and Linus is quite cautious about regressions.
I just wish similar caution was demonstrated from userspace component maintainers.
> Linux has a mature ecosystem and several flavors and components to choose from.
And certain high ranking userspace maintainers are chomping at the bit to pair the number of flavors and components right down, to ease their own workload.
Almost no chance, because "mainstream" would require a huge amount of software to be written or ported for the operating system that does not currently exist. When it comes to things like multimedia and games and webbrowsers and standard office-suites that account for the vast majority of the average person's software use, Plan 9 is not an option. It is true that 9front has support for running virtual machines now, but I see little reason that the average person would ever choose to be running LibreOffice in a virtual machine inside Plan 9 as their standard way of working.
No it's both a server and a desktop OS. The architecture semi-requires the ability to be both cooked in. In my usecase I have my terminals which are desktops that boot off of my main fileserver.
Would you care to elaborate on why you consider it so greatly well designed? I have always been curious about plan9, but would be nice to listen a bit about what makes it so distinguishable before getting my hands on it.
I can't agree with that statement. Plan9 was interesting, though it was completely based on ``everything is a file'' abstraction and had no decent solution for dealing with graphics, sound, video/multimedia, input and so on. All this ``mapping bitmaps directly to and fro the framebuffer'' and ``just create a device file for keyboard input [1]'' sounds cool til you meet some real world need.
I also think that old Smalltalk and Lisp systems (e.g. Xerox PARC) had a design much more suitable for the real world applications than this ``everything is a file'' idea.
There are certain use-cases for which plan9 is not useful. I don't think a solve-every-problem-poorly box is better than a solve-several-problems-well box. For the niches it services, plan9 is sublime.
I also feel that InfernoOS deserves better recognition and interest.
From Inferno OS page [1] :
>>>..As this is part of the underlying system, all applications gain these benefits automatically. 9P runs over various transport protocols including TCP/IP.
9P was originally developed for use with Plan 9 from Bell Labs. A simplified subset called Styx was used in Inferno for a few years, but now Inferno's protocol is exactly the same as 9P. Some manual pages and older papers still refer to Styx.
<<<
I think major constraint (or advantage, depending how you look at it) -- is that you can only use GO-like programming language, Limbo, to develop for it.
No other language runtime is supported.
I've always enjoyed your opinion on alternative operating systems and languages. I love plan9, I wore my thesis in it, but that was based on the knowledge that other distributed operating systems existed at the time, amoeba being the most fun to learn about. Now it's a wasteland... And I really would prefer to explore.
I think better or worse isn't the important theme here. It's that we've lost variety...
>Perhaps in 20 or 30 years we will have something akin to plan9 or inferno composed from nodes on these networks?
Seems highly likely to occur within less than a decade. Tops. Just not on the blockchain. Likely something not-blockchain, e.g. https://ecsa.io/ (which /interacts/ with the blockchain, but isn't blockchain based.)
People massively underestimate just how fast technology progresses at the moment.
While the blockchain is clearly a distributed system, in a very real sense it is the antithesis of classical meanings of distributed computing in the sense that cryptocurrencies are designed to escalate their level of difficulty so as to fend off being accelerated by distributed processing, the exact opposite of most distributed systems that are designed to explicitly harness, or at least collaterally benefit from, parallelism.
Nothing. It is an impossible construct. The blockchain is a (very limited) distributed immutable storage system. It cannot run anything, and participating in a blockchain requires a minimal operating system to be present (storage/network/process management).
Operating System:
- the software that supports a computer's basic functions, such as scheduling tasks, executing applications, and controlling peripherals.
Blockchain:
- A decentralized and distributed digital ledger that is used to record transactions across many computers so that the record cannot be altered retroactively without the alteration of all subsequent blocks and the collusion of the network.
I just went and read the wiki page to try and evaluate your statement, but I still don't get it. I mean, I like the distributing computing concept, but what makes Plan 9 especially interesting?
Well, comparing Inferno and Plan9 only makes sense to a certain degree. Inferno includes a VM, and it was designed to compete with Java, whereas Plan9 was conceived as a replacement (or evolution) of UNIX.
It makes some sense from the point of view that Inferno contains some design decisions that were initially planed for Plan 9 and had to be thrown away due to implementation issues, like Alef then reborned as Limbo.
In any case the C APIs are the same as Plan 9 anyway.
The kernel is simple and sanely designed and interfacing with it is done through the filesystem in, again, a very simple and sane way. Your displays are configured by a simple <10 line shell script at boot time that writes plaintext to a device file, rather than a gargantuan graphics stack that's controlled with binary device files and ioctls. Filesystem namespaces are lovely, and make the filesystem cleanly organized and customized to the logged in user's needs and desires. I have a little script that clears my current terminal window: `echo -n "" > /dev/text`. The libc is small and focused (non-POSIX), and there are only a handful of syscalls. The process model is really sane and straightforward as well. Playing an mp3 file is `mp3dec < file.mp3 > /dev/audio`.
To open a TCP connection, you use the dial(3) function, which basically does the following: write "tcp!name!port" to /net/cs and read out "1.2.3.4!80" (/net/cs resolves the name), then you write "connect 1.2.3.4" to /net/tcp/clone and read out a connection ID, and open /net/tcp/:id/data which is now a full-duplex TCP stream.
There's this emphasis on simple, sane ways of fulfilling tasks on plan9 that permeates the whole system. It's beautiful.
Actually, I can kinda see the advantages there - but isn't insanity just a natural result of trying to work in lots of contexts?
I mean, consider something like vim. It's a nice program, well designed - but undoubtedly insane, just because it's supposed to work in every imaginable context.
It strikes me that plan9 wouldn't be immune to the same phenomenon.
It is all about keeping the OS sane to give the users and applications a chance to be sane, rather than causing madness from the get-go.
However, if the system permits arbitrary applications to be executed (which plan9 does), then it cannot be shielded from madness. Proof: plan9 has a POSIX compatibility layer (APE), a vt100 terminal emulator and a vim port. It even has an aging full-on linux emulator. I think it could run a really old version of Firefox, but the memory is vague. People swear by Mothra these days anyway.
Most operating systems, or the most popular operating systems?
The most important distinction between evolution and design, IMO, is that evolution bars forethought, and any refactoring that trips local optima (which in this case, would be breaking backwards-compatibility).
Popular OSes are popular mainly because of their backwards-compatibility and momentum, and are therefore typically unable to be redesigned in any non-evolution fashion.
Anyone else feel that a hierarchical 'bytearray' file system isn't really a great base for organizing an operating system? Some limitations are that you have to share everything as 'sequence of bytes', requiring every reader to re-implement the parsing logic, and not everything fits well into a file metaphor, for instance socket style stream IO.
I wasn't thinking about another data storage system but more about what core abstractions should be provided by an OS?
For example, could the Erlang model be an OS? Say the OS provides a namespace for a constellation of communicating processes. You still have freedom to implement various languages and configuration systems but you submit your code to a process rather than store it in a 'file system'. Storage is accessed via a process and can be switched out with another process with a different implementation, etc.
You can build Harvey with clang if you prefer, or possibly even pcc. Getting Harvey compiling with GCC/clang meant translating Plan 9's C dialect into ISO C. The translation process means there wasn't a lot of opportunity to introduce GCCisms, so any standards-compliant C compiler should be able to build Harvey. I say should because you may run into one or two small nits that have to be fixed before it'll work, and of course you have to find an up-to-date C compiler that's not GCC or Clang (I guess it would be good to try icc?)
