"You also seem to be implying that people aren't mentally capable of using firearms safely and/or defensively."

Where do you get that?

Easily mitigated by identifying your target.

People think they'll do this, but in real situations casual gun-owners tend to panic.

Yeah, it's impossible to secure a gun against your kid.

It's quite possible, it just doesn't happen.

What difference does it make if people tell themselves they'll be responsible, sober, and competent, when they routinely fail in the event? In a city or suburb, there's no evidence whatsoever they're statistically effective for the defense of a home or person by a even a trained civilian. There's always going to be stories about the hero who killed the rapist in the dining room but in exchange you get 20 suicides by people that didn't have the guts to slit their wrists.

And note, this is not a criticism of gun rights per se; just because guns don't work for X doesn't mean they're EVIL or anything. But any effort spent defending the practicality or utility of a P220 under the pillow is utterly wasted.

But this is just as hard to invoke, because it requires the application to take a string from an untrusted source, parse it as YAML or XML, and then use the resulting Hash as an argument -- this would only happen if you were taking some sort of web service request or submitted file, parsing it without validation, and then passing it verbatim to the ActiveRecord finder methods.

Parsing untrusted information and then passing it to the API without any validation is a fail. This is a nominal exploit, but you never pass a parsed raw YAML or XML fragment from a tainted source to the .find_by_* methods - they wouldn't accept decoded XML or YAML in the non-exploitable case, unless you've gone out of your way and are passing shrink-wrapped API call arguments to the client for them to edit.

If you're training to use a gun in self-defense, what exactly do you think you should be shooting at?

If you were going to go by the statistics, the target should look like:

• Your husband or pet in a dark hallway after making too much noise coming in late,
• The inside of your mouth after a getting fired from your job,
• The next door neighbor kid, after your kid borrows your gun to "scare him."

Actually the classic target that looks like a dude with a gun pointed at you is one of the much less likely things the gun's ever going to be discharged at.

You got marked as flamebait, but I have to agree. I find it amazing that this is even possible in something like RAILs which is supposed to abstract away all the SQL for you.

Note, all parameters from the user's POST or GET are sanitized when passed to the finder methods, but developer-only parameters to the methods in question are exploited by the attacker sticking data into the server's Session object for the request, or by fooling the server into decoding a submitted parameter as a Hash of Symbol => Object pairs, instead of a String objects. This vector that's been described doesn't work unless the attacker has the HMAC that's signing the session cookie.

The object method in question accepts either a string or a Hash of Symbol => Object pairs, and in the second case allows specifying arbitrary SQL clauses -- these are available for efficiency reasons and the documentation's pretty clear that these aren't sanitized, because they can't be. The problem for the attacker is somehow getting a user-created Hash, with Symbol keys, into the application, which is impossible through GET or POST parameters; the only way people have managed to do it is through forging a Session, which requires having the application's session shared secret.

If you pass a law saying the manufacturer is responsible, nobody will build driverless cars, because there's no way they can accept that level of risk.

If you pass a law saying the operator is responsible, nobody will buy driverless cars, because what's the point?

Of course, in this instance, even though the pilots never recognized why they'd lost their air data, they still knew they didn't have it, and in any event they failed to set their power and surfaces for such a crisis.

This is symptomatic of systems that are over-automated: the operators forget how to do stuff, or the automation makes them complacent and careless.

It's not a settled issue as to wether or not a work under its own license may dynamically link to a GPL'd library. The FSF says that if your code links to a GPL library, that makes your code a derivative work of the library. Not everybody believes this, it's never been tested in court, and this theory would seem to run contrary to the rationale behind the FSFs claim the GNU Classpath is not a derivative work of Java.

That said, even if the FSF's reasoning were to prevail, it would be too easy for someone to write a wrapper around a Modular GCC that allowed people to save intermediate work for use by their own tools. The whole point is people love the huge number of language frontends and the assembly generation, but want to do their own static analysis and AST and middle-stuff. If RMS keeps all of the code tightly-coupled, then people can't bootstrap their own proprietary compilers with the work he put into the parts that don't suck.

It's pretty shitty, but it's a normal way of doing business. I work in the film industry and there's the company you might have heard of called "Panavision," they make crappy cameras but awesome lenses, so what they do is they make their lenses only fit a proprietary mount that only their cameras have. RMS is sorta doing that.

But RMS's position on not modularizing GCC isn't irrational, at least from his perspective -- his concern is that if GCC is made into a set of libraries, vendors will write proprietary front- and middle- ends to do all the (awesome) stuff Clang/LLVM do, and this would lead to a vicious cycle where all development on the GNU toolchain would be diverted from the hard-to-monetize GPL's GCC, and into the BSD or proprietary libraries people stick onto it.

HIs refusal to make GCC into a library is his strategy for making sure commits keep coming into GCC. And in OSS, he who receives the commits has the power.

I suspect distributing even small, redacted portions of a medical or legal dictation would violate the many confidentiality laws in force in these industries.

I'm a sound editor and from time to time I've toyed with sending certain extremely cretinous jobs to Mechanical Turk, things like cutting silence out of audio recordings (can't always automate this), identifying and synchronizing numerous takes, or going through a scene frame by frame and identifying every frame with a gunshot. It's technically possible but if your project is anything more complicated than the tiniest FunnyOrDie video you're going to be breaching the producer's confidence.

As information technology makes things like Mechanical Turk easier to implement, it makes the information you would send to MT all the more valuable and dangerous to release.

Yeah, this is really just exploiting retarded key control.

I dunno, I've let my laptop go into hibernate with a TrueCrypt volume mounted. It's "retarded" but that doesn't mean it doesn't work.

I've been building my Prusa Mendel for several months now (work's been crazy, I should be able to finish it over winter break).

I think if I had it to do again I'd get a Makerbot, the RepRap open source models promise a lot but there are a lot of pitfalls: available instructions, software and parts on eBay all seem to be at different versions at all times!

To me it would have been worth the extra $500 to just get a box that had everything, that was guaranteed to all fit together, not look strange or different from the instructions, and have support, but to each his own. I'm definitely learning a lot -- having the wrong revision of something physical is a big deal compared to having the wrong commit of ImageMagick :) It's something OSS fab folk will have to deal with going forward.