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: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.
Re:On Debian that's allready done. (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 well is yet another problem.
The options for Slackware are looking more and more like (from what I can see):
1) End up with a hopeless broken or obsolete set up packages
2) Spend tons of time and energy maintaining forks of thins like udev and patches for everything else, which would take to many resources away for everything else.
3) Move to more user land borrowed from BSD taking Slackware very far out of the Linux mainstream
4) Accept that unlike other things such as Linux Pam its going to be to difficult to swim up stream on this one and just deal with Systemd, as its intended to be used.
5) Come up with some really characteristically un-Slackware complex and kludgy solution like have Systemd call the existing init scripts or a patched init itself.
I know Patrick will find a way through. He always has and I have confidence he and the people he keeps in the inner circle of Slackware development will find a way to stay on the projects mission and remain a top quality distribution. The reality though is Slackware is today probably among the smallest of what people would generally call a main line Linux distribution. Without some other majors players also not going Systemd I am not sure there is enough mind share out there to resist it.
Re:On Debian that's allready done. (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 nobody responding to SIGCHLD events.
And then you have SysV init scripts. Look at the contents of your /etc/rc.d/* directory and then compare them to the examples at http://smarden.org/runit/runsc... [smarden.org], and tell me you really, honestly think they're the right way to do things.
"Not broken"? Seriously, WTF.
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: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.