Plan 9 From Bell Labs Operating System Now Available Under GPLv2 223
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."
Still holds up (Score:5, Insightful)
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 (Score:4, Insightful)
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 (Score:5, Insightful)
You're a file.
Re:I find it interesting (Score:5, Funny)
Your mom is a bmp.
Re: (Score:2)
No she's a spreadsheet.
Touch my file, head or tail, permission (Score:2)
Touch my file, head or tail, I give you permission.
** file porn **
Re: (Score:3)
With a sticky bit.
Re: (Score:2)
Re:I find it interesting (Score:5, Interesting)
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.
So how is it irrelevant? I don't get your point (Score:3)
How so?
How would this abstraction fall down with cluster computing or GPU processing?
Are you suggesting going back to addressing everything by memory location like we used to do or do you have a different suggestion?
Re: (Score:3)
Eventually you have to talk to highly interactive hardware with massively parallel threads
What does parallelism have to do with anything? The only argument against everything's-a-file is overhead, not complexity.
Re: (Score:2)
Eventually you have to talk to highly interactive hardware with massively parallel threads
What does parallelism have to do with anything? The only argument against everything's-a-file is overhead, not complexity.
Exactly. I'd like to see more exploration of something like Kahn process networks [wikipedia.org] as a fundamental programming abstraction; it seems to me that we need to be thinking of programs, filesystems and networks as examples of the same thing. Our networks are becoming software-defined (especially in virtualisation), our chipsets are compiled from languages like VHDL, our programs are becoming parallelised, and our filesystems are starting to grow virtual nodes and do processing. Seems dumb to be maintaining multip
Re: (Score:2)
Re: (Score:2)
Re: (Score:3)
I suspect that between various BSDs and Linux versions that the concept of everything being a file has pretty much reached its logical endpoint.
Not even close, unless you're thinking about Plan 9.
A truly 'everything is a file' Unix would implement BSD sockets and X11 windows as files, just for a start. Can you do that on Linux yet?
Re: (Score:2)
I suspect that between various BSDs and Linux versions that the concept of everything being a file has pretty much reached its logical endpoint.
Not even close, unless you're thinking about Plan 9.
A truly 'everything is a file' Unix would implement BSD sockets and X11 windows as files, just for a start. Can you do that on Linux yet?
At last someone who understands, unlike the other clowns posting replys to this thread.
There are some things that just don't work as files, X11 being one obvious example, along with sockets, handles to data structures, entry points (methods) to loaded modules, etc.
You can force these things into that mold, but you do so more as an intellectual exercise, at the expense of efficiency and speed, (and largely just to prove a point). There is no rational reason to carry the everything-is-a-file concept any furt
Re: (Score:3)
Oh bullshit. Sockets (and named pipes and serial ports; heck, even anonymous pipes) are the best example of leveraging files. Sockets ARE files. Files with funny names, a necessarily special way to open, and what amount to a bunch of ioctls to tend to details. The main interaction is by read() and write(), exactly the same as files. Monitoring for data to appear is done by select(), the same as for any "file" whose input data s
Re: (Score:2)
A truly 'everything is a file' Unix would implement BSD sockets and X11 windows as files, just for a start. Can you do that on Linux yet?
The problem with this is when does it end? How about menus? How about browser tabs? How about form fields in a browser? How about layers and pixels in gimp? How about paths in SVG?
Why can't I just cp a tab from chrome to firefox and have the page magically open? Oh, with the forms filled out with the same data if I use -r.
The problem is that this really only works if every application on the OS ends up being completely standardized, which means you can't add a feature to anything until you add it to e
Re: (Score:2)
I see your file, and raise you a redirection. Anyone who has had to write a simple ">" or "|> in JCL will know what I mean.
Re:I find it interesting (Score:5, Informative)
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: (Score:3)
And that's how you change minds. The more I learn about systemd and journald, the less my knee jerks against them.
Re:I find it interesting (Score:4, Interesting)
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.
Re: (Score:2)
Re: (Score:2)
Or run to a proprietary dungeon like OSX or Windows.
"Proprietary dungeon". :D
That was funny.
Re: (Score:3)
Pry my init scripts from my cold, dead hands.
Re: (Score:2, Offtopic)
How 'bout I stick with my nice stable Slackware, and you whipper-snappers can use whatever Windows-clone-oh-but-it-runs-Linux-under-the-hood you want? That do it for ya, plucky?
Pffft, arguing about changing something that hasn't broken. "Hey, my left arm works just fine, but I really think I should cut it off and get a shiny new model!"
Re: (Score:3, Insightful)
As a fellow Slackware user I echo you sentiment but I kinda suspect we are going to end up with Systemd.
Even some comments Volkerdi has made reflect that. Now that some big dominos like Debian have toppled its probably over. To much of the user land is ending up with Systemd as a hard dependency. Because of the Systemd spawns processes and tracks things the daemons themselves have to get modified which makes them all require Systemd. udev and udisks getting the shotgun wedding treatment to Systemd as w
Re: (Score:3, Insightful)
What world do you live in where modern SysV init isn't broken?
Hell, the old approach, where everything went in inittab and then init(1) supervised processes, starting things up when they failed, was closer to right than the approach taken by "modern" distros is, where you have everyone trying their own mechanism at self-daemonization and absolutely
Re: (Score:2, Offtopic)
Can we get a mod up for this guy? Seriously - init scripts are a hack. They've always been a hack. Just because they're a hack you're comfortable with doesn't mean it's the "right way" to do it.
Re:On Debian that's allready done. (Score:4, Insightful)
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: (Score:2)
If you have daemons that keep falling over and needing restart, you're already at the hack stage.
What do you mean IF, it just happens from time to time for a variety of reasons. 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.
In both cases, absent an expected, non-rectified reason for them to crash, the immediate action for a human operator is... try restarting it.
If the dependancies are programmatically declared (a Good Thing in itself), we can automate this. It's not a hack, be
Re: (Score:2)
Wow, talk about lowered expectations. I run several machines and restarts are for when you reconfigure. Very rarely, something might get into a bad state, but in those cases the process tends to still be running and so an automatic restart won't help. Often, fixing the configuration will help.
Sure, guano occurs and it's natural to try restarting. If it never happens again, chalk it up to sunspots. If it keeps happening, something 's wrong and automating the restart isn't a good answer.
If your car kept stall
Re: (Score:2)
Then "the hack stage" is the state of the world when you're operating at any significant scale.
You have thousands of machine in the field? Guess what -- some of them are going to hit bizarre race conditions. Some of them are going to be targets of successful DOS attacks that crash your daemons. Some of them will have iffy memory in a way that's only visible when it gets poked in just the wrong way. One way or an
Re:On Debian that's allready done. (Score:4, Insightful)
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.
Re: (Score:2)
"Several machines" meaning what? 5? 10? 30?
Try running 10,000 systems at-load; bonus points if your production system is at a substantially larger scale than your upstream vendors' test labs. You can't afford to look at things manually when something goes belly-up -- not immediately -- so you do an automated remediation, log everything you can, and have a human look at the outliers.
If you look at the big b
Re: (Score:2)
Then "the hack stage" is the state of the world when you're operating at any significant scale.
And that's why every week we have reports of major data centers being hacked. This is not a sustainable course for the global Internet. Eventually, people are going to die from infosec disasters. (In drone warfare, they already have, but that's also a political problem.)
Yes, we'll always have bugs. But we have to get to the point where we have zero tolerance for _preventable_ bugs, such as machine code level crashes. Raw x86 code is simply too unsafe to run at any speed on the Internet; it gives no fundamen
Re: (Score:2)
I agree with almost everything you're saying here.
However, none of that is an excuse for building process supervision infrastructure as a house of cards.
Even building higher-level systems in functional languages with provably correct code, I've seen underlying layers blow up (hello, Erlang... though back in the day, I had much more than my share of JVM failures too... and CRuby, and others). Doing things right at the higher levels doesn't negate the need for doing things right at the lower levels -- defense
Re: (Score:2)
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.
Sure, but process supervision is still part of the solution, and SysV still doesn't get you there (remember, the argument that set off this whole thread was "don't fix what ain't broke" in reference to SysV init).
If you want to set something up to nuke-and-pave any
Re: (Score:2)
If you're crashing on memory corruption, you're also serving garbage due to memory errors. Perhaps you should consider going to ECC if it's happening that often. If a DOS attack takes the daemon out, it's got bugs. It's understood that a DOS attack may cause it to not get to requests in a timely manner but it shouldn't actually crash. Bizarre race conditions? That's another word for bug.
What happens when the same memory corruption and race conditions send the daemon chasing it's tail but not actually termin
Re: (Score:2)
I work at both ends of the spectrum. These days it's mostly embedded systems (no crashes allowed) but I also do HPC clusters (if they rely on automatic restart to stay up, people will not be amused). Beyond that, I run a mixed bag of servers from old beaters to shiny and new. I don't do a lot of service restarting. If I do have to restart a service, it is a bug, pure and simple.
Facebook's poor code quality is legendary. As for the rest, for reasons I have detailed you need more than systemd. You have to act
Re: (Score:2)
If you have daemons that keep falling over and needing restart, you're already at the hack stage.
Sounds like a great argument for why we don't need pre-emptive multitasking. If a process doesn't yield time, just don't run it!
It is called defense in depth. Yes, an application that crashes is broken. That doesn't mean that an OS that can't restart it isn't also broken.
Re: (Score:3)
Err, sorry, but Debian people don't say things like that.
It has indeed be decided. If you don't like it, you do apt-get install sysvinit yourself.
Hot grits (Score:5, Funny)
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: (Score:2)
Can I get an invitation to your birthday party? Your hipness is off the scale!
Re:Hot grits (Score:4, Funny)
Re:Hot grits (Score:4, Funny)
Pwning all your base
Found dead, manscaping
With soap on his face?
Burma Shave
Re: (Score:2)
Re: (Score:2)
Beowulf clusters are like *totally* last decade. I probably should have worked the cloud in, though.
The link is a license (Score:5, Informative)
Re:The link is a license (Score:5, Informative)
Or if you're looking for a live image [bell-labs.com] to play with...
Slashdotted... (Score:2)
Was going to run the liveCD just cause, can't get in (too busy try again later).
But Everything's Not A File (Score:2)
Re: (Score:2)
I'ts filizing, not anthropomorphizing.
Dead end (Score:2, Interesting)
I'm by no means a plan 9 expert, but as far as I see, the paradigm that everything is a byte stream is a bit of a dead end idea. Something like everything is an object or some such paradigm is much more interesting. Sure, UNIX and it's ilk, with everything as a byte stream was a great advance on what came before. But a stream of bytes is inherently too low an abstraction to build everything on. Waiting for the day when an object database or something like it is at the heart of a modern popular OS.
Re: (Score:2)
You'll wait a long time: that's been tried and it doesn't work. There are simply too many conflicting demands placed on databases, and any OS that favors one over the other immediately makes itself irrelevant for a large chunk of possible applications.
Re:Dead end (Score:5, Funny)
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: (Score:2)
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....
Besides, I'm pretty sure you were violating several Frito-Lays patents with that configuration.
Re: (Score:3)
Re: (Score:2)
Didn't Debian try that already? Then they got a woody.
Re:Dead end (Score:4, Insightful)
"Those who don't understand Unix are condemned to reinvent it, poorly."
Re:Dead end (Score:5, Insightful)
oddly enough Plan 9 is from the guys who invented Unix who were trying to reinvent it.
unix multics (Score:2)
Re: (Score:2)
been there (Score:2)
Waiting for the day when an object database or something like it is at the heart of a modern popular OS.
been around for nearly 2 decades now: look up os/400 and os/2, two very fine and different implementations of what you just asked for.
both got trampled into oblivion so, ok, you could argue about the "popular" thing. i'd say you really are asking to much.
Re: (Score:2)
Re: (Score:2)
Database at the heart of the OS?
I think you're talking about IBM's approach with the AS/400.
Re: (Score:3)
Waiting for the day when an object database or something like it is at the heart of a modern popular OS.
That is basically what Smalltalk was (except not that popular). When Apple went to Xerox they copied the look and made it popular, but they didn't really understand the implementation at the time.
Re: (Score:2)
Objects can be serialized and the result looks like a file.
More generally, everything is a namespace/filesystem.
Re: (Score:2)
Objects can be serialized and the result looks like a file.
More generally, everything is a namespace/filesystem.
Yep. There's a very close connection between objects, dictionaries, relational tables, files/filesystems, and functions - all centred around binary relations, a fairly well-understood mathematical object - which seems well worth exploring. However, there haven't been (to my knowledge) many languages which attempt to explore this connection at a fundamental level.
Here's a suggestion: we could fairly simply extend S-expressions so they allow for multiple lists or atoms after the dot in a dotted pair. This wou
Re: (Score:2)
In a limited sense, the internet is already represented by /dev/tcp. For example, in bash do: cat
That feature is part of bash itself and so only works within a bash script. A nice thing in plan9 is that a system daemon can be mounted as /dev/tcp and supply that service for any process that cares to use it (and has permission).
I suspect (but do not know for a fact) that that is inspired by plan9. The concept could be expanded upon by adding persistence such that once it learned of a host it would show up
Re: (Score:2)
Re: (Score:2)
But a stream of bytes is inherently too low an abstraction to build everything on.
How about taking it just one step forward to a stream of streams? Then we could at least create object-like structures but with minimal overhead. Plus, it would be a fully recursive definition that would lend itself to virtualisation.
Of course, S-expressions are only 56 years old [wikipedia.org] so such a radical proposal isn't likely to be adopted any time soon.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Java has primitives, which aren't Objects. (though there's a compiler hack known as auto-boxing, which when misused can lead to NullPointerExceptions)
Perhaps you're thinking of Ruby.
Re: (Score:2)
> Something like everything is an object or some such paradigm is much more interesting.
I see you contracted the Java Disease. I'm sorry for you.
(and no: I know about Smalltalk and all that. Still it's called the Java Disease. Guess why?)
I'll guess- because you're a moron?
Re: (Score:2)
The registry is nobody's friend. A bunch of indistinct junk values with opaque names that get dropped all over the place like rabbit pellets and never cleaned up.
my thoughts on plan9 (Score:2, Interesting)
I just want to note that I am surprised by how many useless troll comments there are on this topic.
Little more than a decade ago I tried out Inferno, actually purchased a copy still have the box even. My take away was that it was interesting, but not very useful. I could not do very much with it. I learned the Limbo programming language that came with it for fun because I like learning new languages. But, after that I went back to Linux again.
Then I needed a job after I graduated from university and there w
Re: (Score:2)
worse than that, MS could CONTRIBUTE file X (Score:2)
The problem is worse than that, in my view. Suppose Bell has a patent on foo. Foo is not used in Plan 9. Microsoft wants the foo patent to go away. Microsoft puts a non-obvious reference to foo in their new raid card driver, then contributes a Plan 9 port of the driver. Alcatel is still distributing Plan 9, now with the reference to foo, at least for a few hours until they notice the problem. Alcatel has given up their patent on foo by briefly distributing Microsoft's code
Re: (Score:2)
Agreed on the license thing. I tend to view software development in terms of "raising the roof" vs "raising the floor". If something's new and unique, it's "raising the roof" and merits some protection. If something's old and not particularly special, it should be freely available (BSD/MIT free) so that it can form a new "base" level of performance that anyone and his dog can build on.
Plan 9 is not new by any stretch of the imagination, and by trying to keep it restricted by GPL terms they've made it unattr
Unimpressed. (Score:2, Troll)
Unimpressed.
I was involved in the genesis of no less than 5 major open source projects and 7 not so major. License is always a political thing. It has benefitted Samba, benefitted Linux less, Benefitted Hurd not at all, and benefitted Apache, OpenLDAP, and the BSD's to varying degrees.
If they wanted to displace Mach in Hurd, they would have GPLv3'ed it (or done a "GPLv2 or later thing) so RMS could play daddy. They didn't. They're not going to displace Linux, which is the poster boy of GPL through v2, a
Re: (Score:2)
Perhaps, *gasp*, political reasons weren't behind the licence choice or indeed the release...
Re: (Score:2)
Probably the last thing anyone would want with their project merely because he's too busy.
Re: (Score:2)
too late (Score:3)
It's a shame that this has come so late. If AT&T hat open source Plan 9 right when it was being developed, it might have saved FOSS from the mess of IPC and distributed computing tools it currently has.
Re: (Score:2)
Plan 9 predates Linux, nobody was open sourcing a commercial product back then.
The most commercial product, I can think of, that went open source, was Blender.
Plan 9 from User Space (Score:4, Interesting)
Does this mean Plan 9 from User Space [swtch.com] (an implementation of Plan 9 tools and libraries for UNIX and Linux) will be GPLv2 licensed too now?
Licensing (Score:2, Interesting)
Unless I'm reading it wrong, it previously appears to've been released under a BSD-like license that is non-copyleft, allows commercial redistribution. The only reason it's GPL incompatible is because they describe the venue of law under which the agreement is binding.
And they aren't dual-licensing, but simply relicensing from one to the other. That...is actually a step backwards. In general. I suppose for this particular code release, there's no difference of practical value, but in general it's still goin
Software freedom for derivatives is a good thing. (Score:2)
Nothing in the GPL prohibits commercial redistribution. The GPL aims to prohibit proprietarization. Commercial redistribution and proprietarization are not the same thing. Ensuring software freedom for users of derivatives is a good thing.
It would have been better if the follow on was (Score:2)
Coolest thing is learning sharing incorporating (Score:3)
For me, the coolest thing about any software becoming GPL, or released GPL from the outset, is the immediate learning and sharing possible with anyone that reads it.
Sometimes it allows other projects to say, "excellent idea, let's incorporate that, and give credit to them", which to my thinking, means all other GPL project(s) can potentially benefit each other synergistic-ly.
Plan 9 Torrent (Score:2)
Site doesn't seem to be accepting any connections to download this so here's a magnet uri:
Magnet Link [magnet]
If only they had published it under GPLv3 (Score:2)
Re: (Score:2)
No, you're wrong. This is the only One True OS : http://pudge.net/jesux/ [pudge.net]
(In other words, the 90's called they want their joke back)
Re: (Score:2)
Re: (Score:3)
God told him to write it [templeos.org] (or so he says).
Re: (Score:2)
Re: (Score:2)
Re: (Score:3)
And a Beowulf cluster.