Usually doesn't, at first. It increases productivity by making it possible to use the current workers more efficiently. Slowly the unskilled workers who move boxes from point A to point B get replaced by slightly skilled workers who supervise the robots.

Thank God we don't allow the underclass to buy firearms here in the USA, otherwise we'd have to worry about a revolution.

Must be fairly good, then.

I concur. A development methodology ("open source") will not address any of the deficiencies (when viewed from the voter's perspective, the perspective that should matter most) of voting. No matter how much one trusts a voting program, there's no way to be sure that the computer used for voting is running only software one trusts. No electronic system can compete with the simplicity and recount-friendly approach of what is called for here: voter-verified paper ballots.

So address to the question in the /. summary: You never should have stopped using voter-verified paper ballots.

There are computers one can purchase that do as the parent post specified—the voter feeds in a blank ballot (one which they could have filled out manually if desired) and the computer (which has a scanner and printer attached) will scan the ballot, help the voter by showing the choices on a screen, reading the ballot aloud, or reading the ballot text to headphones, and then collect votes from the voter. Then the computer's printer will print the voter's votes on the paper ballot, and eject the printed paper ballot to let the user inspect that printed ballot. At this point the voter can choose to carry the voter-verified paper ballot to be counted or spoil that ballot and start again. The voter can also feed in a marked up ballot (marked by hand or by computer) and let the computer summarize the votes which that ballot specifies. These features let the blind and/or illiterate vote without losing their privacy by forcing them to find & bring in someone else to mark up their ballot for them. This is as close to computers used in voting as one should want to get.

http://www.pcmag.com/article2/...
"Grayson never reviewed Depression Quest, nor did anyone else at Kotaku. "

Except that, in GamerGate, the journalist in question never reviewed the game, which itself was never reviewed in the publication in question. Thus, the entire GamerGate "controversy" was built on lies told by the GamerGate hashtaggers.

A sort-of correction that reaches the same conclusion: End Software Patents (ESP) speculates that "the 2012 'in re Spansion' case in the USA and the judge ruled that a promise is the same as a licence". And since ESP mentions that Microsoft's Patent Promise has serious problems restricting its promise to those who don't add covered code to another project or those who produce something other than a "compliant implementation" of .NET, it seems that Microsoft patent promise has enough problems that it's still wise to not build dependencies on .NET (as the FSF warned).

Mono developer Miguel de Icaza has pledged to continue to add Microsoft's code to Mono saying "Like we did in the past with .NET code that Microsoft open sourced, and like we did with Roslyn, we are going to be integrating this code into Mono and Xamarin's products".

But is that wise? To your point, the Free Software Foundation's reaction to Microsoft's similar 2009 action point to exactly how changing ownership of patents render Microsoft's Patent Promise not to sue useless. This very promise could become the basis for a patent trap. In 2009 Microsoft's promise not to sue was called a "Community Promise" but today's .NET promise not to sue is risky in the same way—it's not (as the FSF rightly puts it) "an irrevocable patent license for all of its patents that Mono actually exercises" and neither is the MIT license Microsoft chose to release their code under.

Looking back at that essay from 2009, we see the FSF warn us (emphasis mine):

The Community Promise does not give you any rights to exercise the patented claims. It only says that Microsoft will not sue you over claims in patents that it owns or controls. If Microsoft sells one of those patents, there's nothing stopping the buyer from suing everyone who uses the software.

Falling into this trap will directly adversely affect your ability to run, share, and modify covered software. The FSF points to a practical way out as well:

The Solution: A Comprehensive Patent License

If Microsoft genuinely wants to reassure free software users that it does not intend to sue them for using Mono, it should grant the public an irrevocable patent license for all of its patents that Mono actually exercises. That would neatly avoid all of the existing problems with the Community Promise: it's broad enough in scope that we don't have to figure out what's covered by the specification or strictly necessary to implement it. And it would still be in force even if Microsoft sold the patents.

This isn't an unreasonable request, either. GPLv3 requires distributors to provide a similar license when they convey modified versions of covered software, and plenty of companies large and small have had no problem doing that. Certainly one with Microsoft's resources should be able to manage this, too. If they're unsure how to go about it, they should get in touch with us; we'd be happy to work with them to make sure it's satisfactory.

Until that happens, free software developers still should not write software that depends on Mono. C# implementations can still be attacked by Microsoft's patents: the Community Promise is designed to give the company several outs if it wants them. We don't want to see developers' hard work lost to the community if we lose the ability to use Mono, and until we eliminate software patents altogether, using another language is the best way to prevent that from happening.

I find it no accident that the built-to-be-business-friendly "open source" language is all over this announcement including the aforementioned blog post from a prominent endorser, while the wise warnings of falling into a patent trap come from the FSF who consistently looks out for all computer user's software freedoms—software freedom being the very thing that "open source" was designed never to bring to mind (see source 1, source 2 for the history and rationale on this point).

was originally developed by the US Government, and is still supported financially by the US Government?

"Few", or "almost none"?

Because the local sand was the wrong type for sandbags...

Generating a secure one time use token for any credit card that is stored?

Why are people getting so excited?

Here.

Well, at least a non-malformed link.

your medical bills are higher than they would have been if you didn't have an airbag
True, dead people don't have very high medical bills...

Crazed shooters are totally our thing.

--America.