Slashdot Mirror
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."
Is this some kind of weird code?
Ransom Love finally escaped.
Help stamp out iliturcy.
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 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.
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!!!!
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
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.
"First they came for the slanderers and i said nothing."
God told him to write it (or so he says).
Il n'y a pas de Planet B.
With 3d printing, you don't need to specifically mention drones. They'll be printed right after guns.
Was going to run the liveCD just cause, can't get in (too busy try again later).
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?
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
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.
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.
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.
Pry my init scripts from my cold, dead hands.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
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.
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?
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?
Ah, fun :)
"The likes of Facebook and WhatsApp are free to those whose privacy is of zero value."
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.
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.
"A Goddess rarely smiles for she is forced by others to be an island unto herself." - Zephiris
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!"
If you feed it some Big Data, it grow up big & strong.
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
Does systemd use XML? I heard that's the gold standard.
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
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.
Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html
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.
named Lugosi...
I'm a consultant - I convert gibberish into cash-flow.
now there's a delusional OS written by a delusional coder, must be worse than Windows then
"The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
The guys who invented unix were trying to reinvent multics for small computers.
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.
"Ignorance more frequently begets confidence than does knowledge"
- Charles Darwin
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)
putting the 'B' in LGBTQ+
And a Beowulf cluster.
putting the 'B' in LGBTQ+
Touch my file, head or tail, I give you permission.
** file porn **
Uh, Linux geek since 1999.
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.
Uh, Linux geek since 1999.
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.
Digital Citizen
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.
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.
Rethinking email
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.
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?
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.
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.
You are not a brain: http://books.google.com/books?id=2oV61CeDx-YC
"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.
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.
You are not a brain: http://books.google.com/books?id=2oV61CeDx-YC
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
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.
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.
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.
that is the most hideous thing I've seen in a long time... and I've seen beta.
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.
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.
Site doesn't seem to be accepting any connections to download this so here's a magnet uri:
Magnet Link
"Freedom in the USA is not the ability to do what you want. It is the ability to stop others from doing what THEY want"
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.
Trusted Computing FAQ | Free Dawit Isaak!
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.
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.
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.
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.
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.
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.
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.
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.
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.
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).
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).
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.
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?
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?
Unity? Screw that: XFCE. Slashdot Beta? Screw that: SoylentNews. Australis? Screw that: Pale Moon. UX developers DIAF
(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.)
Unity? Screw that: XFCE. Slashdot Beta? Screw that: SoylentNews. Australis? Screw that: Pale Moon. UX developers DIAF
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.
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.
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.
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.
Nah, you connect to serial over LAN and log in on the virtual serial line.
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.
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".
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.