Plan 9 From Bell Labs Operating System Now Available Under GPLv2

TopSpin writes "Alcatel-Lucent has authorized The University of California, Berkeley to 'release all Plan 9 software previously governed by the Lucent Public License, Version 1.02 under the GNU General Public License, Version 2.' Plan 9 was developed primarily for research purposes as the successor to Unix by the Computing Sciences Research Center at Bell Labs between the mid-1980s and 2002. Plan 9 has subsequently emerged as Inferno, a commercially supported derivative, and ports to various platforms, including a recent port to the Raspberry Pi. In Plan 9, all system interfaces, including those required for networking and the user interface, are represented through the file system rather than specialized interfaces. The system provides a generic protocol, 9P, to perform all communication with the system, among processes and with network resources. Applications compose resources using union file systems to form isolated namespaces."

Comments

Still holds up

[Anonymous Coward]

A model for consistency and simplicity. It validated the concepts underlying Unix, and influenced modern Linux/BSD. It also didn't hurt that they had some category-1 geniuses working on it - Kernighan, Ritchie, Duff, etc.

I find it interesting

[Fri13]

I like the idea how everything is a file etc. That is one reason why I originally became Linux user and now it feels Linux systems have become something totally different by new third/fourth generation "geeks" who don't care anymore about open file system and results are like systemd journalctl.

Re:I find it interesting

[Anonymous Coward]

You're a file.

Re:I find it interesting

[Anonymous Coward]

Your mom is a bmp.

Re:I find it interesting

[icebike]

I like the idea how everything is a file etc. That is one reason why I originally became Linux user and now it feels Linux systems have become something totally different by new third/fourth generation "geeks" who don't care anymore about open file system and results are like systemd journalctl.

Sad that they held on to it just long enough for it to become irrelevant. Anything unique that it had to offer has probably been done in other ways.

I suspect that between various BSDs and Linux versions that the concept of everything being a file has pretty much reached its logical endpoint.
Eventually you have to talk to highly interactive hardware with massively parallel threads and then the paradigm starts to become unhinged, and you spend more time trying to defend and extend the paradigm than anything else.

Re:I find it interesting

[suy]

I like the idea how everything is a file etc. That is one reason why I originally became Linux user and now it feels Linux systems have become something totally different by new third/fourth generation "geeks" who don't care anymore about open file system and results are like systemd journalctl.

Funny that you mention that, because systemd exposes lots of features through cgroups and a nice filesystem on /sys. And to use systemd's journal's files, the documentaion already explains that you just open the files, memory map them, and use inotify, a classic notification API on files...

Re:I find it interesting

[Kjella]

I like the idea how everything is a file (...) "geeks" who don't care anymore about open file system and results are like systemd journalctl.

It's part good, part "when all you have is a hammer, everything looks like a nail". What happens is that you put a lot of very structured information into an unstructured format, then "reverse engineer" the structure on demand. To take a trivial example with log files, pretty much every log entry has a timestamp. Now we could store this in plaintext and use grep, or we could store this in a database and use "SELECT * FROM logentries WHERE timestamp BETWEEN '2014-01-14' AND '2014-01-15'". Particularly if you got other timestamps stored in the same file you start reinventing columns based on position or markers.

On the good side we now have metadata, a language designed for structured queries, indexing, the ability to implement ACID compliance and an easy means to join information from different sources, on the bad side it's no longer plain text, we depend on a running database service and database corruption could potentially render everything unusable. But then again, so could file system corruption. From what I gather that's pretty much what systemd does and journalctl is kind of like SQL for systemd.

That said, it seems like an "almost SQL" implementation with its own limited language, personally I'd rather go with a proper implementation like SQLite but maybe there's some gotchas there I haven't thought about, in particular it seems clients can define their own log fields on the fly which would require a little dynamic DDL but I don't see any showstoppers. In particular I notice they only have text and binary fields, you can't say that something is an integer or date field so you could filter on them more intelligently.

Hot grits

[Hognoxious]

I'm running Plan9 in a VM hosted on Hurd (sorry, that's GNU/Hurd) on a computer I made on a 3D printer that I bought with bitcoins.

Meanwhile, in Soviet Russia Bennet Haselton is waiting for a long pompous article about how everyone else is wrong and beta is great written by ME!!!!

Re:Hot grits

[Jane Q. Public]

Easy to understand. He just had hip replacement surgery.

Re:Hot grits

[smittyoneeach]

Where's Stephen King
Pwning all your base
Found dead, manscaping
With soap on his face?
Burma Shave

The link is a license

[phantomfive]

The link in the article links to the license. Kind of cool, I guess, but if you're actually looking for the source code, it's available at Github.

Re:The link is a license

[Zontar The Mindless]

Or if you're looking for a live image to play with...

Plan 9 from User Space

[stenvar]

Does this mean Plan 9 from User Space (an implementation of Plan 9 tools and libraries for UNIX and Linux) will be GPLv2 licensed too now?

Re:Dead end

[StripedCow]

"Those who don't understand Unix are condemned to reinvent it, poorly."

Re:Dead end

[peragrin]

oddly enough Plan 9 is from the guys who invented Unix who were trying to reinvent it.

Re:Dead end

[Half-pint HAL]

What about an OS where everything is a potato?

I tried that once. Unfortunately when I ran it full multitasking on a multicore processor, the timeslicing just left me with a bag of chips....

Re:On Debian that's allready done.

[sjames]

If you have daemons that keep falling over and needing restart, you're already at the hack stage.

But going to something that can't decide if it's a dessert topping or a floor wax is not the right answer.

Re:On Debian that's allready done.

[lennier]

This is an incredibly basic problem in multiprocess systems. It's like saying IF your computer crashes and needs to be restarted... in a datacenter, it's a matter of WHEN.

Except that in today's hostile Internet, WHEN that broken Internet-facing process crashes it WILL be because it was pwned by shellcode, and if that process had write access to core files, your entire server is now rooted. If that process also had any read or write credentials to your local network, your entire data center possibly just got rooted also.

Are you _really_ saying that the appropriate thing to do in that situation is to simply restart the process and continue? You'd be better to flash-wipe and reinstall at least the entire server node, and probably also change all your internal administration passwords. Otherwise, you're an infosec disaster waiting to happen.

You're fighting a full-scale hot cyberwar out there, don't forget. It's no longer 1970. You don't have the luxury of trusting that incoming packets come from universities and defense contractors with administrators you can chew out with a phone call when they misconfigure stuff by accident. NSA owns the wires and your packets come direct from the Russian Mafia and Syrian Electronic Army.

It's not a hack, because machines are NEVER perfect.

It's totally a hack, and _because_ machines are never perfect you'd better be 150% certain that every single step in your error-recovery process is double and triple checked and accounts for every possible side-effect of executing evil x86 machine code with root permissions.

Look, we both agree that Murphy rules. And you're right to say 'because random stuff happens, I need an overseeing process to automatically fix it'. But auto-restarting pwned services is not that fix, anymore, and it really hasn't been since 1999.