FTFY. No need for subtlety.

Or accuracy, apparently. That story was debunked.

even worse then. you must be paying for the automation with speed.

"Must"?

If you pay attention, you might notice that the languages in question have strong metaprogramming support (and one of them has native immutable data structures with structural-sharing updates and typical log32n performance, and transactional memory baked in deep).

The metaprogramming support means that there's lots of room to do compile-time analysis and optimization, and the native transactional memory support means that the cell abstractions aren't doing much that the language's designers haven't already put a lot of effort into making fast.

Sure, there's performance overhead -- but it's overhead that's built to parallelize well. Whereas traditional locking can deadlock, Clojure ensures that there's always useful work going on somewhere -- the worst case you get into is that other threads' work needs to be thrown away on conflict. That's a model that scales a lot better to the highly parallel hardware of a decade from now than the conventional approaches today.

That's why "subsidized" is a relevant thing. :)

No; they support only their own hardware (Moto X w/ custom firmware).

On the other hand, it's a no-contract subsidized current-gen phone, and it's the first device I've had where manufacturer firmware is actually an improvement on AOSP.

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.