Under which country's law?

In most places, I'd expect promissory estoppel to apply.

Good luck remotely erasing the hard drive sitting near (but not presently connected to) my PC... I'll make it easier for you, it's not even in a vault or faraday cage!

Why bother? I'll just wait out the MTBTF; enjoy your head crash (or house fire, or whatever else eventually happens).

Part of what you're paying for with a cloud service (whether in cash or ad-viewing) is geographically distributed redundancy.

A lot of inference from not much data. Aren't you just a bit overinterpreting? Maybe missing a variable here and there? Just asking....

Summarizing, rather, work which is published in more detail elsewhere. (Admittedly, none of it my own).

But the overall reduction in fatalities is still reduced significantly.

Absolutely true -- I did not at any point intend to imply that this was not correct.

uploading photos to the internet IS publishing. that's not even legal grey-area.

Pardon? I store (encrypted) backups online. I'm sure as hell not publishing them to the world.

If that's not the case, please cite sources.

Honestly, I do not really see the advantage of things like upstart and systemd. They haven't significantly altered the boot time of systems (well written init based system booted fast anyway) and they've just added layers of complexity.

Please respond to the post I wrote, not the one you think I wrote. I didn't espouse upstart or systemd, both of which are far, far more complex than runit or daemontools (the DJB tool on which it's based).

Also, regarding pidfile based locking: open(..., O_EXCL | O_CREAT) is atomic, which is what you need for a lock.

Sure, it's atomic, but it's not fit-to-purpose.

Okay: You can create a file atomically. Now, what good does that do you if you want to clear the lock when the process holding the lock is dead?

If you're using POSIX advisory locking, you don't do anything: Lock is released the moment the process closes its file handles. Reboot? No locks are held on the way back up. kill -9? No locks held. You don't have to deal with stale locks, because they can't ever happen.

Never mind the concoction that could likely be made with video editing software to help take things out of context!

...which behooves you to have your own, unedited footage with which to set the record straight.

I'm all for a surveillance society, so long as it's equal-opportunity. If only the powerful have access to the footage, that's 1984; if everyone has their own (read: under their ownership, to be released or withheld as they see fit barring court order) record of everything that happens whenever they're in a public space -- ideally a non-repudiable, tamper-evident one (something cryptography makes possible), I'd call that a step towards a utopia.

The SysV init scripts have one huge advantage though: I can read/debug/understand them and all I need to know for that is a bit of sh(1) and coreutils.

This sentence being included in your reply implies -- strongly -- that you didn't follow the link and read the scripts behind it.

Hint: run scripts are far, far simpler and easier-to-read than SysV init scripts. (They also exist on-disk -- in a directory matching /service/${servicename} if you're following DJB's conventions -- so filename matching is absolutely supported).

If you gained something by your race conditions, I'd see it. Using big, overcomplex SysV init scripts adds nothing but bugs.

I'm... sorry?

You think SysV init scripts are in any way, shape or form moderately acceptable?!

I have a very simple refutation to that -- the collection of run scripts behind this link.

Go ahead -- have a look. Keep in mind that systems using those mostly one-line scripts all provide not just startup/shutdown/status, but also the ability to auto-restart on failure and lack the propensity for race conditions that pidfile-based locking almost universally used by SysV scripts is so very, very prone to.

Holding up SysV init scripts as a thing that doesn't have to be changed... it beggars belief.

So hey, I'm shoving this camera in your face so ten years from now you can be turned down for a job because you might do today that can be taken out of context. But why all the hate?

Dunno. Personally, I'm all for personal responsibility -- if I do something in public today that'd get me turned down for a job in ten years, that's 100% my own damned fault.

Ubiquitous cameras help keep honest people honest, and help get people who aren't honest caught. If some asshat runs me off the road on my (very, very well-lit) bicycle, I damned well want there to be a record showing (1) their license plate, and (2) me being my usual, exceedingly law-abiding, conscientious self. If someone breaks into my condo? Record. If someone picks a fight, and I need to show that self-defense was justified? Record. If someone was merely an asshat? Well, that's fair game too.

Keep in mind, too, that if everyone is getting the same kind of record built up about them, then small infractions aren't such a big thing. If everyone is a drunk asshat at a party every so often, or does a bit of political baiting, then evidence of that happening doesn't really matter -- as long as it's equal-opportunity public record, then employers &c. will be forced to compromise on hiring people whose indiscretions aren't so bad.

So -- if shoving a camera in your face is something you hate, maybe you should think long and hard about the way you behave in public.

You are recording on private property and people can have an expectation of privacy.

It's more complex than that. Have a "privacy fence", where it takes some effort to see through? Yup, expectation of privacy. Have a chain-link fence which can be seen through from public land? Not in any state I've lived in, no.

He chooses what to post on to the internet. If somebody wearing Glass walks up to you, your property, or your workplace, you have no choice in the matter as to which of your activities gets uploaded to Google.

So what? If you're in a public place, you had no expectation of privacy to start with... and a world where you did, where people are prevented from photography in public by virtue of needing to get permissions from every single person near them, is no world I'd want to live in at all.

This is probably just a matter of valuing things differently; I value a person's right to record things which happen around them in public more than I wish to grant a new right not to be recorded in public places (thereby allowing any single member of the multitude present in a crowd to restrict the entirety of the masses nearby).

Seatbelts: "Consumers find them too restrictive!"

So, an aside here: There's absolutely no question that seat belts make drivers and their passengers safer -- none whatsoever.

Pedestrians, on the other hand, have a considerably higher death and injury rate in areas where seat belts are in use -- seat belts reduce risk for drivers, drivers behave more recklessly (because they can), and other road users who aren't protected by those seatbelts die.

I'm also reminded somewhat of guard rails on some of our major freeways (Austin area) being replaced with a trio of metal lines intended to redirect vehicles back onto the road rather than letting them cross the median into the other direction's traffic. It's not an entirely bad idea -- unless you're on a motorcycle, in which contact with those things at speed almost always means dismemberment.

Anyhow -- there's more than one kind of road user, and decisions made intended to protect one class can have unintended effects on the rest. A groundswell of support for something that makes drivers safer might well increase the risk of death for folks who are already in a marginalized class.

What in the world does any have to do with "the cloud"? The scenario is entirely relevant when you're putting servers you own in DC space that you lease.

If anything, using cloud services negates this impact on pricing somewhat, since the service themselves is such a large customer of their DC that they have considerably more negotiating leverage (and, commodity OpenStack instances being reasonably fungible, it can be considerably easier to switch cloud providers than to move physical hardware between datacenters... unless you did something silly like lock yourself in to a single cloud provider's extensions or API).

I mentioned this discussion to my fiancee, a fed. Although the situation referenced wouldn't come up there (expense reimbursement is actually efficient), their training explicitly indicated that refusal to accept a personal-liability card (or behavior in using that card resulting in revocation) would be a firing offense for any job with mandatory travel.

The federal government is pretty darned good about following employment law. I'm guessing, then, that it's the company's past history that made your refusal reasonable, and thus grounds for a wrongful termination suit.