I switched over from T-Mo. Republic's implementation is considerably better, particularly the handoff support.

If I could get reliable cell coverage in my home, I'd pay $200-300 for that.

Switch to Republic, and your voice, SMS and MMS all run over your WiFi, and hand off to Sprint's cell network when out-of-range.

Which gives you reliable coverage in your home, and a deep discount from a typical carrier's monthly rates.

-- Satisfied customer. (Well, moderately satisfied -- Sprint's 4G coverage in Austin was iffy until they got a bunch of tower repairs done; that they let it go for such a long time didn't speak well).

RIght. but now you are deleting most of the appeal of reactive programming by having to go back to explicitly managing dependencies.

I do? I didn't notice myself explicitly managing dependencies when using Trellis or Hoplon.

Well. I really shouldn't be letting myself getting sucked into this, but.

A world in which freedom of contract is unhindered is a world in which Shelley v. Kramer would have been differently decided. I prefer not to live in that world.

You can't assure when, where and how variables might be changing in some outer reaches of your program while another part of the program is assuming they are momentarily fixed.

Huh? All the reactive programming frameworks I've used (Python's Trellis, various cell-model approaches in Clojure) have transactional memory, so things never appear to be happening in parallel.

Reactive programming without transactional memory is Doing It Wrong.

A world in which not all promises are enforceable is not a world without enforceable promises.

Neither history or the world we live in presently has any shortage of examples of power or information imbalances resulting in individuals being unable, on a large scale, to effectively represent their own best interests.

But then -- we're continuing a conversation I expect we both know will be ultimately unproductive. Surely we can find a better use of our time. :)

I care more about equitable outcomes than about freedom of contract. As such, I do not expect our positions to be reconcilable.

Before continuing this discussion, allow me one question, which I believe should adequately establish whether we have any reasonable chance of being able to reach an agreement on principals, even should we come to agree on facts.

Do you consider it appropriate for a risk pool to contain individuals with varying levels of inherent risk? Consider, for instance, the common case of a risk pool consisting of the set of employees participating in a large enterprise's health plan. Is it appropriate for individuals who are at an inherently high personal risk (on account of genetic predisposition, disability, medical history, or known or predictable factors) to be subsidized by those who are not, or should the pool be stratified into bands by inherent risk level, and thus serving only its traditional role of spreading the costs of unpredictable (and, hopefully, non-clustering) events?

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

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.

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.

Every hospital in the United States is required to provide life saving treatment, regardless of whether you have insurance or not. That hasn't changed and it's not the issue here.

What does the requirement to provide life-saving treatment have to do with anything? It helps people who are so broke that they have no assets, but it doesn't help anyone else.

You have a heart attack, you get treated at a hospital which is required to do so; you're insured but not adequately, and you get a bill for $50,000 more than your insurance covers. Welcome to medical bankruptcy.

Now, how exactly are you supposed to shop around, rather than just taking the first-available treatment? Sure, they're required to provide that treatment whether or not you can pay -- but if you can pay, they're going to do everything in their power to be sure that you will.

In my wife's case, it wasn't a heart attack, but brain surgery -- and while she was in the hospital, her employer went out of business. Her insurance policy disappeared with them, and she was personally on the hook for follow-up care, wiping out years of savings.

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?

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.

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.