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

Re:God's endorsement

[Brawlking]

Is this some kind of weird code?

Re:God's endorsement

[symbolset]

Ransom Love finally escaped.

but can it be 3d printed?!

[Anonymous Coward]

This BellLabs/Berkeley/GNU/RaspberryPi lovefest is only missing 3DPrinting, then it will be Pure Slashdot Gold!

Re:but can it be 3d printed?!

[Anonymous Coward]

what about bitcoins and drones bro

Re:but can it be 3d printed?!

[Anonymous Coward]

With 3d printing, you don't need to specifically mention drones. They'll be printed right after guns.

Re:but can it be 3d printed?!

[plopez]

And a Beowulf cluster.

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.

Re:Still holds up

[Anonymous Coward]

No, you're right, other people could have done it. But they didn't. Those folks did do it. That's the difference. And yes, they were smart. Maybe not the smartest people in the history of the universe, but they were pretty darn intelligent and it follows that they'd be able to make useful contributions to Plan9.

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]

and You are a pdf 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

[Narcocide]

Nice false dichotomy you have there. You can't stop people from jumping ship to run away from your precious systemd though. Whether you like it or not, there is an option you still can't control.

Re:I find it interesting

[Anonymous Coward]

"Whether you like it or not, there is an option you still can't control."

If it's open source - you can control it. If you don't like it - fork it.

Re:I find it interesting

[PolygamousRanchKid]

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

[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

[drinkypoo]

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:I find it interesting

[jones_supa]

Or run to a proprietary dungeon like OSX or Windows.

"Proprietary dungeon". :D

That was funny.

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.

Re:I find it interesting

[Anonymous Coward]

But my dads a doc!

Re:I find it interesting

[Anonymous Coward]

Your mom's a GIF (German Intellectual Feminist).

Re:I find it interesting

[smittyoneeach]

Parallelism has a lot to do with sales. It takes a lot of cores, RAM, and storage appliances to catch up with the latest release of Java. And then there is the next release.

Re:I find it interesting

[Anonymous Coward]

You all should be executed.

Re:I find it interesting

[thrillseeker]

No permissions.

Re:I find it interesting

[Anonymous Coward]

I BMPed yo momma last night.

Re:I find it interesting

[FithisUX]

highly interactive hardware -> you mean NVIDIA ATI hardware? They do not comply to any specification like USB mass storage which can be provided as a file. A graphics card !IS! a file , the crap by vendors is not a GFX card. The systems you talk about, are co-processors. So they are not per-se files. But with some engineering from the part of vendors you can view them generally as files, one for each co-processor. Then you upload VM-images through this file and create dynamic files (endpoints) for RPC between host and each VM. The problem is that you cannot buy a graphics card (like a PCI / USB adapter) . You buy a GFX fused with a co-processor integrated in a very strange proprietary manner. I do not defend the paradigm, like pthreads it has standed the test of time. Vendors are morons.

Re:I find it interesting

[Atzanteol]

What insight. Which business magazine do you write for? Your knowledge on such things is "very deep" for somebody with no computing knowledge what-so-ever.

Re:I find it interesting

[EETech1]

No she's a spreadsheet.

Re:I find it interesting

[wonkey_monkey]

With a sticky bit.

Re:I find it interesting

[TheRealMindChild]

I'd personally love it if everything is a void*

Re:I find it interesting

[smittyoneeach]

If I wrote for a magazine, would I drop a riff quite so derogatory about sales?

Re:I find it interesting

[Anonymous Coward]

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.

You mean hardware such as GPUs? APIs are essentially based on sharing buffers. The new innovation is to attach a file descriptor to the buffer so that it can be passed around between programs and drivers. So it turns out that files are a good abstraction for this as well.

Re:I find it interesting

[Anonymous Coward]

fsck it, we'll do it live!

Re:I find it interesting

[lennier]

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:I find it interesting

[lennier]

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 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 multiple completely separate families of languages and tools each with their own subtle incompatibilities and bugs when we could settle on just one and work all the bugs out once, then use it forever.

Re:I find it interesting

[icebike]

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 further than it has already been carried by BSD and Linux.

There is no logical reason to pretend these things are files, and as such most modern implementations of anything 'Nix has carried the concept as far as is logical to do so, and abandoned it for those things that aren't logical or practical.

Re:I find it interesting

[fnj]

There are some things that just don't work as files ... [for example] sockets ...

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 shows up by "magic" - for example, serial ports.

Curses is highly successful as a text character presentation mechanism where you can do random access by talking to a file. It is self evident to me that you could do similar things for graphics.

Re:I find it interesting

[fnj]

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

[Anonymous Coward]

You're mom is one of those AOL free trial tins I used to get in the mail.

Re:I find it interesting

[Anonymous Coward]

You're not worried about the three-orders-of-magnitude realtime performance difference between shooting logs out to subscribers via a file handle, and carefully placing events into a full relational database system and expecting subscribers to search? I don't think you understand the kinds of problems that are being solved here. Seems like RDBMS is your hammer that's making everything look like a nail (or your sledgehammer that's making everything look like a nut ...)

Any old subscriber system can apply a filter that's coded in something like SQL; you don't need a full relational database to have SQL, and putting the intelligence on the subscriber end is the Right Way To Do It. It's ridiculous expecting to have a central log repository that does all the hard indexing and filtering work, in these days of applications that span datacenters.

So what additional problem are you trying to solve? Your main gripe appears to be that lines of text are unstructured, but you don't have to jump from there right to relational databases. You can have structured records without an RDBMS (C does it, for instance :p) Or you can just define the structure of the lines - text parsing is a solved problem, after all. As you as you do it Right - by putting the intelligence at the endpoints - it doesn't matter how expensive your solution is. While your RDBMS can be perfectly optimized with every trick in the book and it will still bottleneck the entire architecture.

Re:I find it interesting

[Rich0]

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 everything.

Plan9 could abstract X11 windows as files, but only if you used their window manager.

Don't get me wrong, Plan9 did a lot of things right and I think linux could benefit from borrowing more of it. However, many of those things have already been ported over (where do you think /proc and /sys came from?). The everything-is-a-file paradigm doesn't always work out for everything.

Re:I find it interesting

[Lemming Mark]

I'll apologise in advance for rambling but I don't often get to talk about Plan 9 and it's nice to have the opportunity!

X11 itself as files would, I imagine, become a bit icky because it's a complicated protocol. But as I understand it, the Plan 9 windowing system was effectively exposed as files (i.e. the display server exported a filesystem interface to applications) and that did actually permit some pretty cool stuff...

Windows basically appeared as a set of files that let you draw to the surface within the window. The interface exposed to windowed apps by the windowing system could also be consumed by other instances of the windowing system, so that nesting instances of the windowing system into windows Just Works.

The fact that everything was in the filesystem meant that network FS shares could be used to e.g. to provide rootless graphical remoting of applications, etc - you just had to arrange for the right filesystem mounts to be available and the display would automagically work out.

Having said all that, obviously these days you'd also want to worry about direct hardware access to GPUs, etc, which I'm sure would make the whole enterprise rather more complicated! Maybe that would put paid to the idea of "everything is a file" being practical for display stuff, or maybe somebody cleverer than me could point out a better way of doing it!

Further tangent: Plan 9 made device files really behave like files, which meant you could remote device access trivially using remote filesystem mounts also. This doesn't work with Unix device files and it always seems a shame that various ad-hoc remoting protocols (USB over IP, Network Block Devices, etc) get used instead. But I suspect a similar argument to the GPU could easily apply - that it's either more efficient to have a specialist protocol or that some devices are just too complicated to meaningfully abstract like that. Who knows.

In some ways, I think I "miss" the olden days when if you'd got a Plan 9 system you probably could feel justified in believing you were in the future!

Re:I find it interesting

[Keybounce]

I like the idea how everything is a file etc.

But if you pay attention to modern evolution of OS's, everything is a directory makes more sense / a better map.

Files have extended attributes, various data/resource/etc forks; real directories cannot be read, but have a bunch of index'd names; etc.

People who say that hardware devices need special parallel communication: each such communication is just another entry in the directory.

And then there's the whole "This program contains different versions for different architectures" is just straight multiple single streams.

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

[bytesex]

Can I get an invitation to your birthday party? Your hipness is off the scale!

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

Re:Hot grits

[tadas]

Netcraft confirms it...

Re:Hot grits

[TheQuantumShift]

So close. Not sticking the "Beowulf Cluster" on landing really cost you points with the judges; it's solid 9's across the board. Not bad by any means, but far from perfect...

Re:Hot grits

[Hognoxious]

Beowulf clusters are like *totally* last decade. I probably should have worked the cloud in, though.

Re:Hot grits

[Anonymous Coward]

Now he has eight!

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

[Anonymous Coward]

but.. is it from outer space? ^^

Re:The link is a license

[Zontar The Mindless]

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

Re:The link is a license

[Anonymous Coward]

Thank you, Zontar.

Re:God's endorsement

[Zontar The Mindless]

God told him to write it (or so he says).

Re:It doesn't use systemd.

[Anonymous Coward]

Definitely not cloud-worthy. Useless egghead crap.

Slashdotted...

[Trax3001BBS]

Was going to run the liveCD just cause, can't get in (too busy try again later).

It probably has a backdoor

[Anonymous Coward]

I used to dive into their code back in the days and there's always a backdoor. It's typically a root jail similar to cisco OS or apple iOS.

But Everything's Not A File

[Greyfox]

And trying to put Everything in a box just makes Everything angry. Everything also doesn't like it when you anthromorphize it. For some value of Everything. I suppose some things might like it when you anthropomorphize them, but they're not Everything, are they?

Re:But Everything's Not A File

[Darinbob]

I'ts filizing, not anthropomorphizing.

It doesn't have SystemD, it is garbage!

[Anonymous Coward]

It doesn't have SystemD, it is garbage!

        SystemD and PulseAudio are the way forward.
        And wayland and gnome.

        So sayith lennart, the 4 debian oligarchs who overrule all because one of their votes count double, and adrian plus matthias douchbag of debian.

        If you don't like systemd, well there is only one solution: go buy a mac or use bsd SNKR.
        Linux IS sytemd.

BTW, do you have stairs in your house?
        Plan9 isn't. Plan9 sux!

Dead end

[countach]

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:Dead end

[Anonymous Coward]

You probably love python then cause everything in python is an object or made of an object. Its just too slow on todays hardware but its a good idea for the future when the hardware supports such an abstraction so far away from the metal. You just need a super duper fast machine to do everything fast enough to make an OS that wont feel like molasis. man

Re:Dead end

[Anonymous Coward]

If everything was a byte stream in MIME format, it could work with the object paradigm.

Re:Dead end

[Anonymous Coward]

object database or something like it is at the heart of a modern popular OS.

The windows registry is your friend. UNIX is junk and for losers marinading in their mother's basements.

Re:Dead end

[stenvar]

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

[Anonymous Coward]

What about an OS where everything is a potato?

Re: Dead end

[Anonymous Coward]

I'm a developer for Windows systems. I have no idea where you get the idea that the registry is object based.

Re:Dead end

[StripedCow]

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

Re:Dead end

[msobkow]

Database at the heart of the OS?

I think you're talking about IBM's approach with the AS/400.

Re:Dead end

[Anonymous Coward]

> 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?)

Re:Dead end

[peragrin]

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

Re:Dead end

[Anonymous Coward]

What about an OS where everything is a potato?

Before OS X, there was MacOS... and before that, there was the dreaded operating system MacDo, where everything was considered a potato.

Re:Dead end

[Anonymous Coward]

Plan 9 starting playing around with the idea of everything as a filesystem.

Re:Dead end

[Anonymous Coward]

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

Ah, so it's like Wayland!

Re:Dead end

[mrfrostee]

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:Dead end

[ChunderDownunder]

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:Dead end

[Anonymous Coward]

OO doesn't have to be slow. Hey, the Linux kernel has a whole host of OO-like interfaces internally and it runs decently enough, right?

Python isn't slow because there's objects everywhere. It's slow because of duck typing and the fact that you can change everything about any object at a whim in your code at runtime. These two properties make fast execution of Python programs a really, really hard problem. And you don't need them that often.

Re:Dead end

[Sevalecan]

Oh, you mean GLaDOS? "So, how are you holding up?... Because I'm a potato..."

Re:Dead end

[Anonymous Coward]

the paradigm that everything is a byte stream is a bit of a dead end idea.

No, it is the right idea. The problem was/is, as ESR pointed out, what they did to the outside world's eyes was to eliminate a few inconsistencies in Unix. But that isn't enough to drive widespread adoption of an operating system, which requires a massive ongoing engineering and marketing (yes, even Linux has the latter) effort.

Re:Dead end

[Anonymous Coward]

"I'm by no means a plan 9 expert, but as far as I see..."

Seems you are very short sighted :(

Re:Dead end

[Anonymous Coward]

Java Disease

Deeply ignorant. Among the many, many flaws of Java is that it has primitives.

Still it's called the Java Disease. Guess why?

Silly gits like you.

Re:Dead end

[Anonymous Coward]

When everything is a byte stream, you uncouple yourself from the application layer. Both can be developed independently.

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:Dead end

[Atzanteol]

> 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:Dead end

[wwphx]

I use the yam fork, the GUI is less gooey.

Re:Dead end

[jd2112]

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:Dead end

[Anonymous Coward]

That is essentially the heart of the Windows Kernel. Every thing is represented by a Kernel Object, of which there are different types. Windows "HANDLES" are nothing more than a way to reference the related kernel object.

Re:Dead end

[sjames]

Objects can be serialized and the result looks like a file.

More generally, everything is a namespace/filesystem.

Re:Dead end

[Anonymous Coward]

A file is an object. And there are different kinds of files. Some are read-only streams, others random access. Some types of files use discrete messages to communicate and change state.

In other words, Plan 9 is precisely what you're arguing for. Except method calls are replaced by message passing. Among other positives, that means it's entirely language and syntax agnostic. All that matters is that you speak the proper protocol; everything else from ABI on up is abstracted away as "I/O". You're not restricted to coding for a JavaOS or SmalltalkOS.

In Plan 9, even things like CPU and graphics are represented as file "objects" (because your process might be using the CPU of box 1 and the graphics output of box 2). And, again, you can use any language you'd like to interact with your instantiated "object" environment.

Plan 9 could never be completely emulated by Linux or BSD because in order to get uniform and consistent behavior across all different object types they had to change some file, I/O, and namespace semantics which are otherwise fundamental to Unix and which many Unix applications depend upon.

Re:Dead end

[sjames]

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.

Re:Dead end

[Anonymous Coward]

Yea, and what about those who understand Unix and realise it's deficiencies? What are they condemned to? dumbass sideliner comments?

Plan9 is created by the people who created Unix, I'm sure they understood Unix, and knew what needed fixing. Unfortunately they mispredicted where computer architecture was going and Plan9 doesn't do IPC through shared memory. They also wrongly assumed people wanted functional, programmable and comprehensible computing systems, and the market revealed that people in fact want expensive blackbox appliances that (sometimes) solve their immediate problems.

Re:Dead end

[Anonymous Coward]

Waiting for the day when an object database or something like it is at the heart of a modern popular OS.

Waiting won't achieve anything. If you're so convinced that is the right way to go, you need to get out there and start building it.

Not saying you're right or wrong, or it will or will not work, but one thing I learnt from working as a Plan9 developer (in 9front), is that telling other people what you want gets you nowhere, you need to go and make it for yourself, and also ignore anyone telling you it won't work unless they have an airtight explanation.

Re:Dead end

[Reservoir Penguin]

Systemd is the last nail in the coffin for Linux, I'm switching to *BSD> The problem with Linux I think is that unlike the BSDs it never head any real UNIX roots. It started from scratch as a UNIX-like hack in Linuse's basement, stuck with following UNIX for awhile and now it's just becoming Windows-like.

Re:Dead end

[Reservoir Penguin]

Agreed, Linux needs more CORBA.

Re:Dead end

[styrotech]

What about an OS where everything is a potato?

Didn't Debian try that already? Then they got a woody.

Re:Dead end

[Anonymous Coward]

Dynamic dispatch alone ensures that OO is slower than without OO. Not to speak of all the other garbage that OO comes with.

Re:Dead end

[lennier]

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 so such a radical proposal isn't likely to be adopted any time soon.

Re:Dead end

[lennier]

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 would allow us to represent binary relations in a simple syntax that reduces to an ordinary list in the case of a relation containing only one row. You end up then with a very low-level but powerful data model which both simplifies and extends the 'array' and 'object' structures in today's scripting languages (eg JSON), and SQL tables, and which has nice mathematical properties: for example, you can union and intersect these relations as you would sets, which is an operation which is undefined on objects or dictionaries. We can also do Cartesian product which is an extension of list appending, _and_ a corresponding Cartesian divide which corresponds to a key-value lookup.

From here, we just need to extend this with a semantics for function evaluation to interpret relations as functions and allow for infinite-sized, recursive computed relations. Which gets a bit tricker, but if we got this, we could represent, say, the entire Internet as a filesystem. Would that be useful?

Re:Dead end

[Anonymous Coward]

I refuse to believe that the UNIX philosophy is the be-all and end-all of operating system design. I have great respect for it and what's been accomplished so far, but to hold onto it as some kinda of immutable concept is foolhardy as technology progresses and new ideas and paradigms are developed.

Re:Dead end

[FlyingGuy]

Uhmm well you must not have been paying any attention over the years. The PICK OS was just that. The OS was the database and the database was the OS.

Re:Dead end

[sjames]

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 in a directory listing but since the lists would be HUGE, I doubt that ls /dev/tcp could ever list every host on the net.

A nice thing about mapping objects to a filesystem is that hard and soft links allow for various structures that don't map neatly to other structured data representations.

Similarly in plan9, instead of a special API for signals, you write to a file in /proc/<pid>

Re:Dead end

[Anonymous Coward]

I'm not following you. A dotted pair is a car/cdr where the cdr isn't a list. The cdr can be a list, and you can consider that list to be a "dotted pair with a list as the part after the dot" if you like, but most people would consider that just a list. So how is your S-expression extension different from this? Do you mean you want to be able to tell between (a . (b c)) and (a b c)? So essentially there's a left-list and a right-list, which can be stored in a cons quite simply and (a b c . (d e f)) is just ((a b c) d e f). Do you actually need to *extend* S-expressions?

Also I'm not sure why you think union isn't defined for dictionaries? Because if A.key and B.key both exist there's no well-defined way to produce a result? How would you system handle this?

I've thought about these ideas a lot too but I want to understand your point-of-view on this.

Yea, it doesn't have systemd.

[Anonymous Coward]

Yea, it doesn't have systemd.
It sucks.

Re:Yea, it doesn't have systemd.

[smittyoneeach]

Does systemd use XML? I heard that's the gold standard.

Systemd is everything.

[Anonymous Coward]

You are correct. Systemd is everything.
The unix way makes lennart angry.

my thoughts on plan9

[Anonymous Coward]

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 were more Windows jobs, so I my focus became that. I still use Linux for setting up servers or playing with at home, but nothing too serious. I am also a big gamer, so I have always had a Windows machine or dual/triple booted with various OS.

I do not really have an opinion on the systemd debate. Or, even whether everything should be a file.

I think they waited way too long to release plan9, it has definitely become irrelevant. Maybe worth looking at just to see a different perspective on OS design at the very least, it might be useful as a teaching too at universities.

To be completely honest, I am kind of disappointed they decided to go with GPL v2. I mean in my opinion either you completely embrace Richard Stallman and his hatred of the proprietary world and use GPL v3 so proprietary software & drivers can never make use of your operating system, or you go the other route and choose BSD/MIT. Picking GPL v2 as a new license for new software releases is kind of strange to me. Maybe they were hoping it would be cannibalized by Linux and their concepts would eventually be used beyond plan9, but did not want direct commercial competition for their Inferno OS.

It makes me wonder if they still make money on Inferno. Maybe this is a way of generating interest in it again, just like CentOS and Fedora generated interest in RedHat Linux's support and commercial offerings.

Re:my thoughts on plan9

[DuckDodgers]

The GPLv3 has the new patent licensing terms. I am speculating wildly, but whenever the GPLv3 is discussed a few people - and not always the same one or two - chime in and say that their employer won't work with GPLv3 for fear those terms would force them to give up the right to file a patent-infringement lawsuit under certain conditions. e.g. Alcatel-Lucent releases Plan9 under GPLv3, it grants implicit rights to some patent in source file X, and then Red Hat Linux puts source file X into OpenStack so they can use the technology covered under that patent without fear of lawsuit.

I agree with you on the rest of your comments. With respect to gaming, if we're lucky - and I'm not sure we will be, but if we are - in five years SteamOS (on top of Debian Linux, or Debian GNU/Linux if you prefer) will cover all of the games you want, and you won't need to run Windows. I run Windows at home too because of my kids' games, and because I don't want to make my wife resent me or free software by forcing her to switch. I boot into Linux when I'm using the computers for myself, and try to only get games that run well natively on Linux or through Wine.

Re:my thoughts on plan9

[Half-pint HAL]

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 unattractive to developers. It puts it on pretty even ground with Linux licensing-wise, but Linux is a lot more feature rich. Even if Plan 9 is more efficient in some ways, the development overhead to expand it is high, whereas with Linux, you can just roll your own distro out of the thousands of SourceForge and GitHub projects....

Re:my thoughts on plan9

[TangoMargarine]

If companies are afraid to purposely infringe the GPL since v3 came out, I would call that a win. :)

Cynics end up bitter; idealists end up screwed.

Re:my thoughts on plan9

[DuckDodgers]

That's not infringement that is the problem for companies, it's the patent license grant.

I wish companies would use GPLv3, I think the patent license grant is a very good thing. But I can understand why they do not. I disagree with it, but I understand it.

Nope. You must use systemd.

[Anonymous Coward]

Nope. You must use systemd.
It has been decided.

Re:Nope. You must use systemd.

[Hognoxious]

Pry my init scripts from my cold, dead hands.

Re:Nope. You must use systemd.

[Anonymous Coward]

Pry my init scripts from my cold, dead hands.

Your terms are agreeable to me.

Name and address, please?

Unimpressed.

[tlambert]

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, and therefore of the GNU-maniffesto-before-ut-oh-service-requires-patent-licenses realization took place.

This pretty much is not going to mean anything, other than they get to play Pontius Pilate and wash their hand of an inconvenient project going nowhere fast, while looking like a good guy.

Using GPLv2 in this case accomplishes no political goals, other than the promary one, of holding the organization blameless for any further research.

Re:Unimpressed.

[Anonymous Coward]

Flamebate?

It purely a research OS that hasn't had development for a decade. Its not trying to displace anything.
Its like shit talking the source release of DOOM saying that it contributes nothing because Quake was out.

Re:Unimpressed.

[Richard_at_work]

Perhaps, *gasp*, political reasons weren't behind the licence choice or indeed the release...

Re:Unimpressed.

[dbIII]

RMS could play daddy

Probably the last thing anyone would want with their project merely because he's too busy.

Re:Unimpressed.

[afxgrin]

So what would impress you? Having a lawyer write up a whole new license? Keeping it closed source?

Re:Unimpressed.

[tlambert]

So what would impress you? Having a lawyer write up a whole new license? Keeping it closed source?

Dropping the LPL for a 3 clause BSD or combined MIT license would be better than the GPLv2, and the GPLv3 would be better, if the intent was to get it in the door at the FSF, since they are quite religious about that, and they would prefer Linux switch to GPLv3 as well, since the license is basically an instrumentality of the GNU Manifesto, and intended to accomplish the goals GNU set out to accomplish. It's why they always tack a "GNU/" prefix onto Linux and piss the Linux people off. In terms of straight uniformity and simplification, since parts are already under the MIT license, that might be preferable. I doubt that they could purge the LGPL without pulling an Android/Bionic move to get the C library out from under the license.

I really don't see code from Plan 9 making its way into Linux, despite the license compatibility, and I don't see it being adopted by the BSD crowd or Mac OS X, both of which are more likely to pull in ideas from an ivory tower like Bell Labs. Like the old Salutation Consortium, the reference implementation being under the GPL makes it relatively unattractive to adopt the code to the people most likely to do so.

So basically, they've thrown it over the wall, and are hoping someone is on the other side to catch it.

9 and done...

[Anonymous Coward]

Now I have VBox with a lot of boxes in it.

Re:9 and done...

[Anonymous Coward]

Username is glenda
The best web browser is to vnc to windows or linux.

too late

[stenvar]

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:too late

[stox]

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.

Re:too late

[Anonymous Coward]

I wouldn't say Blender "went opensource", it sucked so much and had such poor success in the market that it was sold for scraps, and open source people bought its source code.

Re:too late

[Anonymous Coward]

Plan 9 was made public in 1992. Linus & Co. began working on Linux in 1991.

Plan 9 was being developed during the 1980s, but it changed dramatically over time. Some of the characteristic elements of Plan 9 weren't even added until near the public release or even afterward.

Re:too late

[Anonymous Coward]

Plan 9 was a solution to a late 1980s problem, how to run a multi-user graphical OS more efficiently. At that time the state of the art technology was a unix system consisting of something like a MIPS server with X Windows tacked on top serving X Terminals and peripherals connected over 10Mb/s coax ethernet loops.

Plan 9 was to be a graphical Unix extending modularity of unix filesystems to everything. A distributed scalable system with a graphical user terminal which could use a cpu server for number crunching and a fully journaled and backed up file server for storage. Like most research systems it never had a large user base or many applications and as owned intellectual property it was of no use to the free software movement, even if they had wanted to reinvent the wheel. It proved the usefulness of stuff like a journaled file system and unicode with UTF-8 for backwards compatibility. Ideas like completely hardware abstracted graphics and using concurrent code didn't work and ended up being rewritten in C.

The arrival of cheap more useful PCs, starting with the 386, changed things. X Windows proved remarkably hard to kill and, running on top of Linux or BSD PCs connected to the internet over ADSL, won. Releasing Plan 9 under GPL2 is just tidying up things for hobbyists who use it.

Re:too late

[stenvar]

Plan 9 wasn't a "commercial product", it was a research project. And of all companies, AT&T really should have known what it took to make an OS successful, given their SysV/BSD experience.

And, yeah, a lot of software developed by companies was open sourced even back then.

Re:too late

[Anonymous Coward]

Plan 9 wasn't made public in 1992, it was released for university research similar to what they had done with V8.
In 1995 it was released for non-commercial use (by then already too late).
And Lucent released is fully in 2002 (much too late).

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?

license war in 3..2..

[Anonymous Coward]

Publish any change you make to the source code.

On Debian that's allready done.

[Anonymous Coward]

It has been decided.

As the systemd people say: If you don't like it go use bsd or get a mac.
You do not have a choice.
It has been decided. SystemD wins.

get out of here oldfag.
Or (lol) go fork debian or whatver

Don't trust anyone over 30.

Re:On Debian that's allready done.

[pla]

As the systemd people say: If you don't like it go use bsd or get a mac. You do not have a choice. It has been decided. SystemD wins.

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:On Debian that's allready done.

[DarkOx]

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.

[cduffy]

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!"

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..., 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.

[Anonymous Coward]

It begs the question of why can't Systemd features be merged into the mainline kernel? It would seem like it's a kernel on top of a kernel, so why all the redundancy. The same thing happened a while back with FUSE et all, and it was scaled back eventually.

Re:On Debian that's allready done.

[Atzanteol]

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.

[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.

[marcosdumay]

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.

Re:On Debian that's allready done.

[ToasterMonkey]

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, because machines are NEVER perfect. The "recoverable" error rate adds up when you tie bunches of them together. So does the "non-recoverable" rate... so why not do what we can to address it? This is why we put things like Xeons and ECC memory in data centers, it's the only way to scale out the number of machines, and ultimately processes.

Re:On Debian that's allready done.

[sjames]

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 stalling out, would training a woodpecker to hit the start button be the most reasonable response?

Re:On Debian that's allready done.

[cduffy]

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

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 another, in the real world, services die.

Now, the right way to deal with this is to have a parent process that gets immediately notified when this happens, sends an appropriate ping to the monitoring/alerting system, and then does its best to get things back into a working state. Maybe you schedule the node for nuke-and-pave at a time when the cluster isn't under load. Maybe you snapshot the system's state (if it's virtualized) for a human-driven root-cause investigation later. What's definitely, unequivocally the Wrong Thing is just to have the service just be dead.

Yes, there's some overlap with remote monitoring and remediation systems, but that kind of infrastructure has its own, somewhat different failure points -- and the right way to do things is belt-and-suspenders. If you want to start remediation as soon as possible, you use the UNIX process tree the way it was designed, and you have a parent listening for SIGCHLD. Period.

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.

Re:On Debian that's allready done.

[cduffy]

Wow, talk about lowered expectations. I run several machines and restarts are for when you reconfigure.

"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 boys -- Facebook, Google, Etsy -- you don't see folks who build with the assumption that services are going to stay up.

Re:On Debian that's allready done.

[lennier]

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 fundamental guarantees about separation of memory space. At the very least, we need managed languages with an extremely tiny, simple, provably correct kernel that make it mathematically impossible for one process to smash its stack or corrupt another's heap. We've had solutions for decades; microkernels like L4, languages like Erlang, Haskell and D. We can replace failed, non-securable syntaxes like raw ASCII SQL queries with nested list structures that don't suffer from quote-escaping vulnerabilities. We simply refuse to develop and deploy these solutions, because of no better reason than laziness, institutional inertia and a sense of "it's not my problem if my program is not provably secure". Wrong. It's everybody's Net, and that means it's everybody's problem.

As an industry, we're at the stage where medicine was before the discovery of antiseptic surgery. We have no fundamental data hygiene in our execution environments. We kill as much as we cure. This has to change.

Re:On Debian that's allready done.

[cduffy]

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 in depth is still a thing.

Re:On Debian that's allready done.

[cduffy]

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 system that has an Internet-facing service SIGSEGV (hellloooo, denial-of-service attacks!), well, you still need something to actually be wait()ing on the process and deciding what to do about it. In prior iterations of my world, that something is a daemontools derivative kicking off a "finish" script to decide how to handle an erroneous exit -- in future iterations, it's likely to be systemd.

Re:On Debian that's allready done.

[sjames]

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 terminating on an error? There will be no SIGCHLD or any other signal.

It is possible to monitor for those conditions and do a restart if needed, but systemd won't do that.

If you really just need to restart on process exit, why not a while loop in a shell script? If you want to be notified, add a line to the script to fire off an email to the admin group.

As I said elsewhere, guano occurs so sometimes using a restarter as a stopgap makes sense. But that really should be considered an exceptional case, not normal policy and it should certainly be considered a dirty hack. I don't see it being common enough in good practice to build into pid 1.

Re:On Debian that's allready done.

[sjames]

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 actually monitor the service to see that it's actually working (not merely still running) and force a restart if it's not. Systemd is no help at all for a wedged service. It remains a dirty hack to work around bugs, no matter how justified and systemd is not adequate to the task.

Meanwhile, the examples you gave are systems that will have a variety of standard system daemons and one primary app that has to stay up. Put that one under control of a monitor/restart program and all should be well (bugs and all).

As for SysV scripts, I will agree that improvements can and should be made. I'm just not convinced that systemd is the answer.

Re:On Debian that's allready done.

[Rich0]

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:On Debian that's allready done.

[cduffy]

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.

Over here in the real world, saying "that's a bug in the code, so it's not my fault that it brought the cluster down" doesn't fly -- if you're ops, your job is to keep the cluster up in the face of badly-written software on individual nodes. Advocate for better design and development practices, absolutely, but that can't mean that we take our services down while we spend a decade rewriting every third-party component.

What happens when the same memory corruption and race conditions send the daemon chasing it's tail but not actually terminating on an error? There will be no SIGCHLD or any other signal.

So if we don't solve everything, we can't solve anything?

Ugly hacks for detecting and remediating that kind of bug exist. The slightly-less-awful ones tend to be runtime-aware (if you're running a model where requests have sole use of a thread that's handling them, for instance, it's able to have considerably less splash damage in terminating a long-running request), making them inappropriate for a one-size-fits-all situation.

If you really just need to restart on process exit, why not a while loop in a shell script? If you want to be notified, add a line to the script to fire off an email to the admin group.

Great. So now we have to write bespoke policy (via individually maintained scripts) for every service in the system, and modify each and every one of those scripts when we want to make a policy change.

Oh, wait, that's the status quo. And it's bloody awful.

As I said elsewhere, guano occurs so sometimes using a restarter as a stopgap makes sense. But that really should be considered an exceptional case, not normal policy and it should certainly be considered a dirty hack. I don't see it being common enough in good practice to build into pid 1.

It's been part of pid 1 for decades; see /etc/inittab.

Moreover, if it's *not* part of pid 1, it's easy to get into a state where your system isn't amenable to any kind of remediation: You have pid 1 but nothing else running? Sorry, only option is a power cycle.

Re:On Debian that's allready done.

[cduffy]

I haven't done HPC work, but my impression is that they tend to be pretty homogeneous.

I'm accustomed to working with much more hetrogeneous systems -- a N-node intake system, a NxM-node index cluster, a N-node storage system, a few different datastores behind various frontends... some of these are purely developed-in-house (by a separate dev team, meaning that influence on their code quality means asking nicely), some are commercial software with vendors who release on their own cycle and may or may not build with maintainability in mind, some of them are upstream OSS with a passel of patches.

If you're in a world where you can control the quality of the software, you're in a much happier place than I am.

Back around to systemd -- the restarting functionality isn't really a big deal; you can get that in any modern init system (which, of course, SysV ain't). The really interesting bits in systemd are the same ones that make it dependent on functionality unique to Linux -- tight integration with LXC and the like -- and there's room for legitimate debate about whether keeping all that in-process is the right approach. You may recall that I didn't start this out saying that systemd was great -- I started this thread saying that describing SysV init as "not broken" was wrong on its face, and I stand by that claim.

Re:On Debian that's allready done.

[Anonymous Coward]

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.

Actually, at the user end of things auto-restart remains the #1 solution to all problems. Just rebooting whatever bit of electronics isn't working fixes the problem, at the user end, 99.9999999% of the time.

Re:On Debian that's allready done.

[sjames]

It's actually fairly easy to add to SysV as well. Because SysV is scripts it is likely even easier to add service monitoring and restart there than it is to add the necessary monitoring part to something like systemd.

I was also pointing out that restarting crashed daemons automatically is a hack. Sometimes a hack is the best you can do (like when you can't control the quality of the software), but it's still a hack. There's no point pretending it isn't. You seem to understand that but the person I replied to did not.

I don't claim that SysV is somehow perfect or that it can't be improved upon. I do claim that whatever that improved upon system is, it probably isn't some frankenstein process that has out of control dependencies and thinks it should do a little of everything. The answer is much more likely to be an improved SysV. The fundamental design of SysV is as good as any, it just needs a new major version number update. For times when a hack like restarting is called for, that can be a standard tool that is part of SysV.

Small programs doing one thing well and working with other such programs is what allows a system designed decades ago to run circles around much newer OSes. The big Swiss army knife approach with multiplying APIs is what produced Windows. If I wanted that, I'd run Windows.

Re:On Debian that's allready done.

[sjames]

The benefit to preemptive multitasking is in the way it simplifies programs that are written correctly. It isn't just a crutch for poorly written software.

Re:On Debian that's allready done.

[Rich0]

The benefit to preemptive multitasking is in the way it simplifies programs that are written correctly.

The benefit to preemptive multitasking is that there are no programs that are written correctly.

Re:On Debian that's allready done.

[sjames]

My argument is that claiming the restarts are anything but a dirty hack is just fooling yourself. What's next 'well, you know, sometimes servers just burst into flames for no reason. It's OK, we have a fire department"? It may be a necessary and expedient hack but it is most certainly a hack.So yes, set up the restart for the buggy code but don't for a moment pretend that it's anything but a dirty hack to paper over bugs.

Forgetting that is what leads to considering self-corrupting memory acceptable in production and forgetting that some corruptions result in incorrect data rather than crashes.

As for the scripts, when is the last time you had to rewrite every rc script on a system? When is the last time a single policy was the most appropriate for every single daemon on the system?

As for the rest, there is some value in emergency access being restarted, but let's be honest here, if there is a system fault bad enough to kill off everything but pid 1, what are the odds that you can accomplish anything useful without a reboot? Won't any command you try to run (including the restarted getty) just crash? The most likely cause is a corrupt in-memory kernel image. Best chance to get up and running is to load a new one (reboot).

Of course, the restart functionality in inittab is really there for hysterical raisons. The getty processes terminate when you log out by design (in other words, not a bug).

Re:On Debian that's allready done.

[cduffy]

As for the scripts, when is the last time you had to rewrite every rc script on a system?

About... two years ago? And that was the third time of many.

Though that was because, in all those cases, there *were* no acceptable scripts to begin with. Detaching processes from their parents, thus losing access to their status without either race-prone gymnastics or polling, is not acceptable by any means whatsoever. (Yes, that doesn't handle service-level status, but well, that's what service-level monitoring and runtime-aware management tools are for).

When is the last time a single policy was the most appropriate for every single daemon on the system?

Haven't had that happen yet, but I've had a single policy be most appropriate for 80% of services. And that policy was "restart".

That's likely to continue to be the case in the future. Look at Go -- the idiomatic approach taken to error handling is to panic and exit. That's not a bad thing -- it's a good thing, because you're getting back into a known state, much for the same reasons that it's appropriate to reboot when you have corrupt kernel state.

Re:On Debian that's allready done.

[cduffy]

The fundamental design of SysV is as good as any, it just needs a new major version number update.

I positively cannot agree.

Look at some of your system's SysV init scripts, and then have a look at some of the run scripts at http://smarden.org/runit/runsc....

Is the configuration complexity you're getting from every process having its own, bespoke set of init scripts rather than something that simple -- coupled with responding to standard signals -- really buying you anything?

Re:On Debian that's allready done.

[TangoMargarine]

We're really having an argument about what system my PC uses to bootstrap itself, that I have no interaction with whatsoever?

Er, why should I care?

Re:On Debian that's allready done.

[TangoMargarine]

(I'm not one to say "who cares" on Slashdot practically ever, but it sounds so far like you were trying to start a war over me wearing grey socks instead of white.)

Re:On Debian that's allready done.

[sjames]

If there were no scripts anyway, I don't see how any other init system would have changed anything there. But surely there were scripts for system daemons such as sshd?!?

For cases where you really want to keep the daemon attached and watch it, that sounds like a job for a helper program, not a case for ripping out the whole init system. SysV does at least offer no resistance to a little helper program that follows the Unix philosophy. You could probably have it handle policy as well.

Re:On Debian that's allready done.

[sjames]

Daemontools is not that far off of what I imagined. It leaves the nice reasonable /sbin/init in place.

I agree that the existing start scripts for many distros have been morphed into an ugly mess for no good reason, but that's not fundamental to SysV. My own remain quite simple and effective within SysV supporting start stop, restart, reload, and status just fine. That's the fundamental design of SysV. So is using a tool to monitor the daemon.

There's no need to crap all over everything like systemd does.

Re:On Debian that's allready done.

[cduffy]

If there were no scripts anyway, I don't see how any other init system would have changed anything there. But surely there were scripts for system daemons such as sshd?!?

I said, no acceptable scripts.

OS-provided scripts for sshd are almost universally fire-and-forget, thus unacceptable.

Yes, sshd shouldn't ever exit. Yes, it's a serious bloody problem if it does. But if it exits, and stays dead, and no remediation happens? That's a bigger problem, because that means you need hands-and-eyes to fix it.

Re:On Debian that's allready done.

[cduffy]

My own remain quite simple and effective within SysV supporting start stop, restart, reload, and status just fine.

Doing so how? Are they robust against other processes being assigned the PID of something that exited? Are they following LSB exit status conventions? Are they cgroup-aware? And even if you're getting all the details right in your own init scripts, have you gone to the effort of auditing all the vendor-provided ones?

Details matter, and requiring everyone to reinvent that wheel means when a canonical implementation could easily be provided means that in a great many cases the details will be wrong. For someone as concerned with correctness as you are, I'm surprised that isn't more troubling.

Re:On Debian that's allready done.

[sjames]

Nah, you connect to serial over LAN and log in on the virtual serial line.

Re:On Debian that's allready done.

[sjames]

I rarely do any of those, but again, a simple helper program can take care of it.

And there's no need for it to be a re-invented wheel. If a distro can adopt an abomination like systemd, it can adopt a reasonable clean up of SysV with a few helpers.

It could even adopt daemontools wholesale.

What I find troubling is a system that defies even the chance of correctness without practically creating a new distro. Something that can be stepwise cleaned up and made to work well isn't so troubling, it's just something to configure.

Re:On Debian that's allready done.

[cduffy]

As the person who's building large-scale automation that uses SSH as its backing transport, anything that requires escalation to something that isn't SSH might as well be hands-and-eyes -- it's something my tools can't touch, and if the tools can't touch it, it might as well not exist.

See again, "too large a scale for issue remediation to depend on human involvement".

Re:On Debian that's allready done.

[sjames]

It's fine then if you want to put sshd under a restarter, but I can almost guarantee that if sshd comes down, the machine is dead anyway. You'll probably need IPMI to hit reset or a serial line and the magic sysreq key. It's also worth considering that your use case is nothing like most.

So how is it irrelevant? I don't get your point

[dbIII]

highly interactive hardware with massively parallel threads and then the paradigm starts to become unhinged

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?

Why?

[Anonymous Coward]

It was a nice gimmick back then but why now? Do people to expect finding some earth shattering programming solutions?

Re:God's endorsement

[Teun]

Ah, fun :)

Great idea

[Anonymous Coward]

And houses could have their basements in the roof.

And babies could take just one day. Instead of losing time with cells your mother could use directly arms, head, legs...

Did you patent your idea?

Re:God's endorsement

[Anonymous Coward]

Terry A. Davis tweeted this about four hours ago:

My enemies ruin me in the eyes of man. They don't realize God. I laugh at them n*ggers.

?!

Hmmmm ... could this vitalise the Tuxscreen?

[Anonymous Coward]

Anyone still got a one of these?... http://tuxscreen.net/

I got mine reflashed with Linux, but its pretty much useless (Linux cannot address the phone hardware).

Re:So how is it irrelevant? I don't get your point

[Anonymous Coward]

Two threads trying to write to the same file at the same time is going to end in tears. You need some kind of API on top that manages transactions or at least provides some kind of semaphore system. Well, the alternative is to make the handler for that type of file I/O clever enough to manage multiple writes but then you lose many of the features available with a proper API and end up with horrible, hacky code running in the kernel.

been there

[znrt]

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:been there

[kefalonia]

Add AIX into the mix of tried things; OO-DB at the heart of the OS... OMG!

Re:been there

[Anonymous Coward]

IBM's os/400 morphed it to AS/400 which then morphed it to just simply "i";and then soon after apple quickly named every thing some type of i-fruit. Similar to IBM's use of "System" in the 80s; Apple followed up with "System 7". {my halve-cent}

Licensing

[Zephiris]

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 going in the wrong direction.

Re:Licensing

[Anonymous Coward]

Yeah, someone should explain what the Lucent 1.02 license is (Plan 9's former license, or co-license?) and what it allows/restricts.

Re:Licensing

[Antique Geekmeister]

I'd consider GPL a considerable licensing _improvement_. Its language is more clear and it protects better against the "proprietization" and secretive changes of standards or API's associated with licenses that are "business friendly". The clarity and thoughtfulness of its language has helped me, repeatedly, solve time wasting arguments at software planning meetings about if and how we need to publish our modifications.

Re:Licensing

[Anonymous Coward]

It's worth mentioning that Rob Pike, one of its creators, tweeted that he thought it was a good thing.

Re:It doesn't use systemd.

[smittyoneeach]

If you feed it some Big Data, it grow up big & strong.

Re: boastful wannabe hax0r

[Anonymous Coward]

> I used to dive into their code back in the days[sic]

If by "their code" you mean "mommy's skirt" and by "dive" you mean "hide behind and pose as something of a non-luser" then yes, yes you did.

Otherwise, no, no you didn't.

Re:So how is it irrelevant? I don't get your point

[Anonymous Coward]

The only way that it ends in tears is if you don't have some concept of transactional operations within the thing. You're presuming that this doesn't exist- but it does and it does even in Linux and *BSD. I can see why you posted this Anon Coward. I wouldn't want that stupid stuck to me either.

Resurrect Pick OS ....

[Anonymous Coward]

Instead of everything being a file stream, everything is a Database.

Re:I find it interesting by Kjella

[Anonymous Coward]

That's the first explanation that makes any sense. Do you know if they intend for the 4.0 release of linux to not have a /var/log directory but only a /var/log database so that everything's back in the same place?

It would have been better if the follow on was

[Registered Coward v2]

named Lugosi...

Re:It would have been better if the follow on was

[Kichigai Mentat]

Not Night of the Ghouls? Or The Sinister Urge?

Re:God's endorsement

[Barsteward]

now there's a delusional OS written by a delusional coder, must be worse than Windows then

Re:So how is it irrelevant? I don't get your point

[Anonymous Coward]

No, the file does not end in tears due to multiple threads and cores writing to it. The user may, but a file object is perfectly fine with it. If the user wants a predictable structure to a file, then they need to synchronize the usage of the file as they want it.

unix multics

[typo-lfm]

The guys who invented unix were trying to reinvent multics for small computers.

Re:God's endorsement

[plopez]

No, you're wrong. This is the only One True OS : http://pudge.net/jesux/

(In other words, the 90's called they want their joke back)

Touch my file, head or tail, permission

[mrflash818]

Touch my file, head or tail, I give you permission.

** file porn **

Coolest thing is learning sharing incorporating

[mrflash818]

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.

Software freedom for derivatives is a good thing.

[jbn-o]

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.

9front

[Anonymous Coward]

I wonder how this affects 9front, the only decent distribution of plan9 (and also the only decent, bugfixed version of the plan9 kernel). Can be nasty figuring out the licensing when an upstream developer changes the license unexpectedly.

worse than that, MS could CONTRIBUTE file X

[raymorris]

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:worse than that, MS could CONTRIBUTE file X

[DuckDodgers]

Good point. I had not thought of that.

Re:God's endorsement

[JamieIanMacgregor]

I just don't 'get' most of the spam on here. you would think it would at least be relevant with a link or something but this is just weird, same with the links to goatse... really? is anyone here stupid enough to fall for that? well maybe the new users beta is attracting I guess. what does anyone gain by posting this? I'm assuming it takes human effort somewhere along the line.

Re:God's endorsement

[JamieIanMacgregor]

that is the most hideous thing I've seen in a long time... and I've seen beta.

Re:God's endorsement

[Anonymous Coward]

now there's a delusional OS written by a delusional coder, must be worse than Windows then

You haven't tried Windows 8, I assume?

take a look at Styx-on-a-Brick

[Anonymous Coward]

It should not be that hard. Styx-on-a-Brick was able to get 9P running on a lego mindstorm. Implementing the communication protocol across 9P would not be that hard. I would do it if it were not that I had given up on Plan9 -- just take a look at the code internals. Maybe now that it is re-released under GPL, it will get some decent refactoring. I would not hold my breth though...

Plan 9 Torrent

[Pikoro]

Site doesn't seem to be accepting any connections to download this so here's a magnet uri:

Magnet Link

If only they had published it under GPLv3

[vinsci]

Had they published it under GPLv3 instead (Why Upgrade to GPLv3, by rms), I would have been interested and been playing witht the code. Now, not. Your loss, Alcatel-Lucent.

RE: God's endorsement

[Anonymous Coward]

If the beta is so good that I hear obnoxious posts on EVERY SINGLE FREAKING STORY, than I would count myself lucky to be its lover!

RE: God's endorsement

[Anonymous Coward]

WTF is this!?!? Is this what goes on inside a troll's mind? I truly pity them, I really do. This one needs professional help...

Re:God's endorsement

[Anonymous Coward]

Every inevitably changeable sentences congratulation concentrated calf infidelity relaxedly preeminent brackishness

Truer words have never been spoken...