SysV is not better. But BSD init is not worse.

On the contrary; I've fixed a number of the dependency orderings in ChromeOS using systemd. Like I said, it's fine if you are OK with rebooting, and as you said, it's possible to express the dependencies correctly. I don't think we are contradicting one another.

It's also possible to explicitly specify correct build order dependencies in the Debian build system, so that it can avoid retries. My issue is that it's also possible to express the dependencies as loose constraints, and things can still be made to work (rebooting in case the mouse didn't start up correctly in ChromeOS was one of the things I fixed; 95% of the time, it started fine, but the first reboot after an upgrade, before the boot cache files had been built, it didn't, due to timing). The Debian build system does it by retrying.

The problem is that people depend on this behaviour to get them out of jams, rather than drilling down and fixing the missing underlying dependency specification, *because the system _mostly_ works without them needing to do so*. And *that's* the problem. If it just freaking *broke* outright, like a reasonable system, you'd know (A) what to fix and (B) that you didn't have any more hidden timing related crap lurking in the shadows, which wouldn't show up in in house testing, but might show up as a heisenbug at some customer site. That's just not acceptable.

Administrators dislike constraint based systems.

This should surprise no one. One of the problems with a constraint based system is that you don't control the precise ordering of things.

This doesn't bother the Debian folks, because their build system is a constraint based system. If they have a package to install which has dependencies, they don't control the actual build order of the dependencies, or of their dependencies, and so on. Turtles all the way down. You do an apt-get install foo, and it's going to try to build subcomponents when they become available to try to build. And if they fail to build, they don't care: they "try again later", in case something that happens later satisfies the dependency that wasn't satisfied the first time around.

This is very disturbing to system administrators, who like things to be both orderly and predictable. All dependencies should be mapped out, known, and explicit. If something gets tried now, and fails, the correct response isn't "We'll try again later!", it's "Stop! Someone fix this fucking thing, it's obviously broken".

The build system is not deterministic; if there are two components, and one has a subdependency on some X of "at least version N", and another has a subdependency on X of "at least version N+2", then depending on the vagaries of network overhead, it's possible that half your code gets built with version N and the other half gets built with N+2, and things break. Things breaking is in fact far more acceptable to a system administrator than "things act weird", and "things act weird" is at least deterministic for a given build instance, and far, far, more preferable than "things sometimes work and sometimes don't".

So system administrators dislike Debian for large system installations. And they dislike systemd for starting things up and shutting things down.

A desktop system is far, far more forgiving: "It's not working; I'll just reboot!". As long as things "mostly work", then things are great! "Look! It's as good as Windows!".

Note that launchd in Mac OS X has many of the same problems as systemd; it's also a constraint based system. It's somewhat worse, in that it insists on controlling file descriptors and sockets and Mach ports for the things it starts - which means you have to rewrite a lot of at least the startup code in most Open Source software to tolerate being run by something that opens the files and sockets that it expects to do itself. But that's just a lot of make-work, and people who are paid to do work are paid because it's not something they'd be willing to do voluntarily, for free, and that's what they're exchanging for the money they are getting in exchange for putting up with that part of the job.

Unlike the people making things work with launchd, though, the people expected to make things work with systemd aren't being paid. And so systemd represents make-work and change for chage's sake, which doesn't sit well with volunteers.

--

So yeah, a lot of people find systemd annoying. Kirk McKusick once accused "vnode" as being "the structure that's taken over the kernel"; in Linux, systemd is fast becoming "the program that's taken over user space".

How this will all play out, I don't know, but don't expect it to be resolved any time soon, given the dichotomy between the philosophies of the stakeholders involved.

It's possible to verify the signature on the message using the public key in the profile for purposes of authentication (*NOT* authorization!) and non-repudiation purposes. You would require the intersection of two information vectors be compromised in order to alter someone's message - equivalent to controlling both the forward and reverse DNS entries for SMTP spoofing; presumably, you would not be subject to unsigned information there, the way the DNS system *without* DNSSEC fails to protect SMTP today.

I already specifically noted that it's arranged as a mutual security game on the GloboCop model. This is the same model that was used during the cold war to prevent active warfare larger than brushfire wars. The math on it is rather complex to explain, but I could give you references to works by the Sante Fe Institute and the Brookings Institute. It's mathematically supportable.

Let me stop you right there. This would open the protocol to the "cancelbot" problem. It can't be allowed. What you can do instead is to implement "no_see_ums". You, or any exterior level of containing groups of subsets of the implied group "everybody" (but not "everybody" itself) can decide to "subscribe" to a set of of things in the category "I'd rather not see that". The top level is always unfiltered, and you can have "politeness" groups of "I'd rather you not see my drunken ramblings" on top of that. Polite people join the "politeness" group, and everyone else can (if they look hard enough) see your drunken ramblings. Forard distribution ACLS (immutable) would let you limit distribution to members of a politeness group. Thus - internal, but not external visibility + cancel. Assuming you group your drunken ramblings instead of flinging them to the winds.

No. It's a permanent record of the data, or at least as permanent as "until an EMP takes out, simultaneously, all the replicas". Deleting a profile would be tantamount to deleting everything the profile has done in the past, which is tantamount to the historical rewrite, without the "polite consent" of those it's being rewritten out from under.

I'm not sure how you'd deal with "multiple persona" in a reasonable way; you could, I suppose, simply allow it, and allow for mutual adoption and unilateral dissociation - "A adopts B & B adopts A" and "A adopts B and B rejects the adoption", but the storage requirements balloon. For example, I have a number of distinct digital persona that I maintain for reasons of separation of roles, and I'd be sorry to lose that, but I probably would not maintain more than a handful in a social network setting in any case, corresponding to my current social networks and the roles the networks themselves are intended to fulfill. I have a persona on Facebook, I have a persona on LinkedIn, I have a persona on Google+, and so on.

I rather expect that any system that got built on this model would want to be able to subsume, or at lest replica the data and organizational structure from those networks. I think Google Groups / Google Wave / Google+ attempted (and failed) to do this by having groups and groups of groups, but the associative relationships necessary for such a thing are necessarily more complex than the representational geometry of the latest offering(s). It's something you have to design in - you can design large and scale down, but scaling up is a PITA if it requires a redesign. To put it another way: you have to map the absolute problem space, not the intended initial deployment space, with your architecture.

Like I said, I typically do not see a great deal of monteizable value in this, unless you get people to also self-select into profile groups. Perhaps you could get them to do this in exchange for Google Fiber service? I expect most people would do so to avoid paying for Internet service, but it would be a radical rethink of the value of physical communications infrastructure; I expect Verizon et. al. would shit themselves and hire hit men before they'd allow it to happen.

I'm pretty sure that means that's what left of them after they have been ashed by the volcano will easily fit in one hand...

You mean that ... *GASP!!!!!* That earthquake machine I built for the government was used for *EVIL*, rather than for the peaceful, *GOOD* type of earthquakes?!?!

I am so glad you were here to enlighten me!!! I'm quitting my job at the government labs, right after I finish the solar flare machine I've been working on!!!!!

Convert Larry Ellison's island back to it's historical use, when we had no effective treatments for Hansen's Disease (Leprosy)?

Historically, Ellis and Angel Islands managed quarantine just fine for massive numbers of immigrants. It's a solvable problem to run a rolling quarantine.

It's all muscle memory, once you have your routine down. It doesn't require thinking to accomplish. It's like the cross-country running I did in High School in order to get out of a PE credit so I could take the first CS class that was offered there. I did it because I had to, not because I wanted to.

If you're into the endorphins/runners high, great. If you're in a team sport that requires strategy and tactics, great. If you're sitting at a Nautilus machine going through a workout routine, you might as well get totally stoned first, because it's going to be your medulla doing all the thinking about moving your muscles; there's no higher brain function involved.

Some of us find it rather impossible to "just zone out".

PS

Just because I could build this thing Bennett Haselton wants, doesn't mean that I agree that it would be a useful or monetarily rewarding or socially redeeming thing to do. I don't even think the technology would be all that tricky, or even patentable, for the most part. As far as I can tell, it's just a "I want to build an X just like Y, but different from Y in these ways" play, like all the other idiots who want to compete with a big player in a large market niche in the hopes of a big $$$ exist strategy.

Technically not true. A better model would be random partial replication between servers. This would follow the usenet "flood fill" distribution model, where multiple replicas end up on different machines. This interferes with the "I want to be able to unsay stupid stuff"/"I want to be able to use the server while high or drunk and fix it later" feature you (effectively) required in another discussion we were having. But it solves the "domain name hostage" problem for profiles.

To prevent editorializing of your profile and posts by putatively authoritative servers, you'd have to deal with the trus/revocaction issue, but this could be handled by treating it like the iTunes/iCloud CDN model, and having signing key of signing keys, generational signing, and a monotonically increasing version number on the signature knapsack for a given profile. This also solves the "stale cache in fraudulent/stale replica holder" problem, but requires a hierarchical and strongly distributed authoritative UUID/OID distribution model.

You could still dick with someone's profile, but you'd have to be a trusted server to do it, and you'd have to deeply compromise the server software such that the authoritative signing key infrastructure was effectively back-doored. If anyone ever found out about it, you'd lose your position of authority forever, and presumably these positions would only be granted to "superpowers" in a GloboCop-style mutual security network. You'd effectively be exposing all your vouchsafed users and their users (in an arms race analogy, you'd be giving China the a ability to vote with France and the U.S. to deactivate all of Russia's nuclear arsenal). A major player is unlikely to risk that on a petty vendetta, or even for an intelligence agency.

Way to address the 18% and not the 82%!

Given that you're not OK with the 70% remaining people that are currently unqualified, that'll get you another 12.6% overall, instead of 57.4% overall. Way to go for the 22% solution to the 100% of the problem there! Let's see... that'll give you a "C+" grade, on the standard scale... way to overachieve!

Perhaps you need to hire some otherwise unqualified STEM people to do your math for you, before you start making policy decisions based on your back of the envelope calculations...

You're thinking about this wrong.

Cardio myopathy? Heart murmur? Arterial-venous malformation? Scoliosis? Spina bifida? Multiple Sclerosis? Myasthenia Gravis? Hypertension? Etc.?

There are many medical reasons for turning inward to concentrate on ones intellect which I will freaking guarantee that you will dedicate yourself to the task, and without the help of Jesus personally laying hands on you, will preclude you from becoming physically fit.

This.

OCD people can generally accomplish anything they become obsessive about. They typically do not obsess about physical fitness, because it does not engage your brain.

LOL; yeah, I noticed that my markup had been filtered after I posted it.