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 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.
Wow, talk about lowered expectations. I run several machines and restarts are for when you reconfigure.
"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.
If you have daemons that keep falling over and needing restart, you're already at the hack stage.
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.
Just like the singularity it seems that improved battery tech is always about 5-10 years down the road.
The awesome thing is that it really is always 5-10 years down the road -- and things are rolling off of that 5-10 year timeline into production all the time.
If you don't think batteries have been getting better, you aren't paying attention.
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!"
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.
I don't see why this is considered a good thing. If I have all necessity plus a few luxuries, I'm not going to work as a garbage man.
Sure, but remember, we're talking about an economic system for a society where automation has taken away almost all of the entry-level jobs (which is certainly a thing we're headed for inside the next few generations).
So there's a need for people to maintain and repair the garbage robots, but not for garbagemen as such.
Yeeeah. And you end up with great decisions to make, like moving to Lion and getting sane Xsan licensing, but losing your ability to run as a NT domain controller.
None of which makes either spy-camera's or Google Glass' recording facility any more acceptable.
...but it does make the likely uses of that recording facility more acceptable, since it makes it a relatively unsuitable tool for people whose goal is surreptitious recording.
Okay -- enough of the theoretical; down to the personal. I'm a commuter cyclist. A very, very law-abiding commuter cyclist (last group ride I went on, the only person quite as meticulous was a LAB instructor). I damn well have cameras, one in obvious view (making the recording I do not surreptitious), others less so (with a circular buffer being recorded over until/unless an impact is detected or manual trigger pressed), and if someone objects? Fuck you. My safety (and ability to demonstrate fault or chain-of-events in court) trumps the reasonable expectation you don't have of being unrecorded in public.
And if you want to throw a punch over being recorded? Better be sure you really did get every device.
It's not. And if you tried to spend a hour recording other diners with a cell phone, you would also be asked to leave a restaurant. If you weren't punched in the face first.
And yet --
In one case, you regulate people based on their actual behavior. In another, you have something against a device, without regard to its actual usage in practice.
Using your mobile them to grab a few quick videos of your friends, or even take pointless Instagrammed pictures of your food is one thing- filming everything you happen to glance at and upload it an advertising company with an interest in facial recognition is quite another.
Do you have reason to believe Glass users are actually using their devices in this way, or is this just a bogeyman?
Cell-network bandwidth costs money. The devices aren't always-on recorders unless someone chooses to use them in such a way... and, well, if I wanted an always-on hidden video recording device, there are cheaper and better ways to do it.
Right, and I've already mentioned them in other comments on this story. And they too are unwelcome in most situations. That a spy camera can be concealed does nothing to make Google Glass more acceptable.
The existence of cheaper alternatives for someone whose goal was surreptitious recording raises the possibility that, perhaps, someone wearing Glass is doing so with an intent other than surreptitious recording... as, if that were their attempt, they would, if competent, be using a tool better suited for the job.
You might wish or expect that Google Glass has such an indicator light. But it doesn't.
You're quite right; I stand corrected.
Even if it did, who's to say the glasses haven't been rooted, or such a light physically disabled.
If someone wanted to surreptitiously record others, there are better devices to do it with. Built-to-purpose "spy cams" exist, have existed for decades, and are much better at the job -- easier to conceal and not requiring the wearer to stare at their subject to get a steady recording.
So, well, "who's to say" that you aren't already being privately recorded? If someone is motivated enough to void the warranty on a $2000 device to root it, surely they're willing to buy something much, much cheaper.
First, I'm not sure how objections regarding surveillance have any reasonable connection to the dictionary definition of the word "obtrusive" -- but ignoring that, and taking the statement per its intent, some points:
These devices are not always-on recorders, and have a light indicating when the camera is running.
Overuse of that recording process can be handled in the same manner as overuse of the (more obtrusive per dictionary definition) practice of holding up a cell phone camera to record.
Now blowing up to a simple request not to wear obtrusive recording devices in restaurants however...
How exactly is Glass more obtrusive than folks pulling out cell phones to record? Going by the simple definition of the word, a device that needs to be pulled out of one's pocket and held up by hand is by definition more obtrusive than a device which is always mounted on the wearer's head.
No matter how badly we need it to be otherwise, not matter how much we wish it were otherwise, this is the short term reality. EV's powered via renewable sources will only work on a small scale.
Quite the strawman you've got there.
In short: So what? Large-scale fossil fuel plants are still vastly more efficient (and cleaner-burning, and easier to monitor, repair, replace and upgrade) than tiny-scale (inside-each-vehicle) fossil fuel plants.
Slashdot Mirror
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 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.
"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.
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.
The awesome thing is that it really is always 5-10 years down the road -- and things are rolling off of that 5-10 year timeline into production all the time.
If you don't think batteries have been getting better, you aren't paying attention.
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.
Sure, but remember, we're talking about an economic system for a society where automation has taken away almost all of the entry-level jobs (which is certainly a thing we're headed for inside the next few generations).
So there's a need for people to maintain and repair the garbage robots, but not for garbagemen as such.
And AOSP is one heckuvalot more than just a kernel.
Typical paper-targeting color printers, yes. Not sure that that applies to 3D printers, and it doesn't apply to black-and-white printers either.
Most "lifetime warranties" are defined as "lifetime of the device", once you get into the fine print.
I'd very surprised -- downright astonished -- if that video card had a warranty for the span of your lifetime.
Yeeeah. And you end up with great decisions to make, like moving to Lion and getting sane Xsan licensing, but losing your ability to run as a NT domain controller.
And going about your business while wearing Glass vs staring at someone to get a steady shot are also different things.
Also, see again re: it being visible from the other side of the display whether the camera app is up and running video.
Hasn't happened yet. Then again, I'm also a big guy (with a friendly public demeanor) wearing loose clothing in a concealed-carry state.
I honestly don't know how much that last bit contributes; ought to find out on moving next year.
There's a longer discussion there, but one better suited to happen over a beer than in a public forum.
Okay -- enough of the theoretical; down to the personal. I'm a commuter cyclist. A very, very law-abiding commuter cyclist (last group ride I went on, the only person quite as meticulous was a LAB instructor). I damn well have cameras, one in obvious view (making the recording I do not surreptitious), others less so (with a circular buffer being recorded over until/unless an impact is detected or manual trigger pressed), and if someone objects? Fuck you. My safety (and ability to demonstrate fault or chain-of-events in court) trumps the reasonable expectation you don't have of being unrecorded in public.
And if you want to throw a punch over being recorded? Better be sure you really did get every device.
I doubt that. Someone who's (say) texting rather than eating might be ejected, but certainly not punched.
And one can tell what's on a Glass user's screen, and whether it's video. Not from a distance, necessarily, but certainly from punching range.
And yet --
In one case, you regulate people based on their actual behavior. In another, you have something against a device, without regard to its actual usage in practice.
I really, really do not grok the difference.
Do you have reason to believe Glass users are actually using their devices in this way, or is this just a bogeyman?
Cell-network bandwidth costs money. The devices aren't always-on recorders unless someone chooses to use them in such a way... and, well, if I wanted an always-on hidden video recording device, there are cheaper and better ways to do it.
The existence of cheaper alternatives for someone whose goal was surreptitious recording raises the possibility that, perhaps, someone wearing Glass is doing so with an intent other than surreptitious recording... as, if that were their attempt, they would, if competent, be using a tool better suited for the job.
You're quite right; I stand corrected.
If someone wanted to surreptitiously record others, there are better devices to do it with. Built-to-purpose "spy cams" exist, have existed for decades, and are much better at the job -- easier to conceal and not requiring the wearer to stare at their subject to get a steady recording.
So, well, "who's to say" that you aren't already being privately recorded? If someone is motivated enough to void the warranty on a $2000 device to root it, surely they're willing to buy something much, much cheaper.
First, I'm not sure how objections regarding surveillance have any reasonable connection to the dictionary definition of the word "obtrusive" -- but ignoring that, and taking the statement per its intent, some points:
And if you have to pull out "if you have to ask", you don't understand your own argument well enough to state it clearly.
How exactly is Glass more obtrusive than folks pulling out cell phones to record? Going by the simple definition of the word, a device that needs to be pulled out of one's pocket and held up by hand is by definition more obtrusive than a device which is always mounted on the wearer's head.
Which? The product discussed here is hardware.
Quite the strawman you've got there.
In short: So what? Large-scale fossil fuel plants are still vastly more efficient (and cleaner-burning, and easier to monitor, repair, replace and upgrade) than tiny-scale (inside-each-vehicle) fossil fuel plants.
You only don't care about sanitizing standard-undefined behavior if you don't care about bugs.
That one's a Really, Really Big Deal.