You don't need to run a "full-bore shell program" to be vulnerable.

You simply need to use the system() function of any popular language (Perl, PHP, Python, Ruby, C, etc). The system() function executes /bin/sh -c to parse the string before executing it. You don't even need to pass any arguments. On every Linux distro /bin/sh IS bash. Game over.

The alternative to using a one line system() call is a few dozen lines of complex, easily screwed up systems programming as you navigate through fork(), exec(), dupe(), wait(), etc.

The real issue are Linux distributions deciding that bash was a suitable substitute for a minimal POSIX /bin/sh.

You failed to note the "Google TV" text all over that app's page.

That version is only usable on Google TV, not Android.

You try and throw it back and me and yet...Linux is one of the only "modern" production kernels that hasn't figured out auto-tuning.

Why is that do you think?

And why should I chose Linux, knowing I'll have to spend considerable time and expense to "tune" it, even for very common use cases, when other systems can tune themselves better than 95% of sysadmins and do so for free?

Better question: It's 2014, why the hell are you still manually tuning kernels?

I'm not saying you don't need to for Linux...I'm asking why you or anyone else feels this is an acceptable requirement? Is it just to keep Linux sysadmins employed?

Sure, for some incredibly unusual workloads we might not be able to expect the kernel to self-tune, but for the other 95% of typical uses they kernel really should be able to tune itself and do so far better than any human.

Seriously, why do people put up with schedulers that are so bad they not only can't self-tune...they need to be wholly replaced...and such "tuning" requirements are considered normal?!

"You can't pay less than $80k to an H1B"

BS. You have to pay the "minimum or prevailing wage in that geographic location for your particular position", which more often than not actually translates to well below the actual prevailing wage for the area and pretty much always well below $80k. It's also trivial to fudge by playing games with job titles:

Online Wage Library - FLC Wage Search Wizard

Does a "Application Software Developer" cost to much? Save a bit by calling them an "Analyst", or call them a "Web Developer" and save yourself $30k! :-/

Even in most all of the highest wage markets in the US, it's trivial to get a "prevailing wage" well south of $80k with an H1B. AND they are effectively indentured servants (a small step up from slave): They can't complain, they have no real freedom to get fed up with your BS and quit.

Yes and no...

  Mojang didn't originally violate any license or infringe on copyright. Bukkit were always the ones in violation (of Mojang's license and copyright infringement). ...But now, Mojang "bought" Bukkit (the name and infrastructure, but not the code assets). This is where things get weird.

Mojang/Bukkit is no longer in violation of Mojang's copyright, but neither is the Bukkit package in compliance with the GPL. Although that actually isn't clear either:

A) Mojang/Bukkit are distributing the complete "source" to Bukkit (via the decompiled Minecraft server code). Although...that decompiled code isn't under GPL...

B) Bukkit is the derivative (much like writing a GPL driver for Windows, or in general the issues of linking GPL code to non-GPL code: http://www.gnu.org/licenses/gp...

Does Bukkit's license have the exception called for in the GPL FAQ linked above? Maybe, but it may not matter. Legally the exception may be considered implied because it was/is required and the distributor (the original Bukkit coders) knew/know that.

But reguardless...Mojang could easily side step the whole issue by stripping the Mojang/Bukkit distributable of all non-GPL code (ie, the decompiled Minecraft server code). So long as Mojang/Bukkit doesn't distribute GPL/non-GPL mixed binaries (ie, only distributes Bukkit source sans Minecraft source), they aren't in violation. The GPL only requires you distribute source for the binaries you distribute and it is not a violation to simply distribute source that can't be compiled or can only be compiled once "brewed" locally with non-GPL code by the end user. While that end-user can't legally distribute their non-compliant binaries, they can legally use them themselves.

And Mojang can count on the InterWebz to make available "unofficial" distributions of the needed decompiled Minecraft code and/or distributing (in violation) compiled binaries. Mojang isn't responsible for other people violating licenses (even as they benifit from the activity) and is under no obligation to expend effort or coin to pursue them. The butthurt Bukkit devs would need to do that legwork on their own dime if they cared.

How did this load of crap get +5 Insightful? Oh that's right, it's Slashdot.

Smoothly? Maybe, if you never upgrade. Linus/Linux has badly botched nearly every major transition they've done.

a.out to ELF
libc to glibc
VM flavor of the month
filesystem of the month
32bit to 64bit
sound, oh god..
MAKEDEV / devfs / udev

And that's the short list...and just the kernel. If we actually talk about the full OS (aka distributions), my god...it's a configuration manager's worst nightmare.

What the hell, I've got some /. karma to burn:

The reality is, Linus is the quintessential asshat. Not a fraction as smart as he thinks or boasts that he is, happily takes credit for everyone else's work (while simultaneously chastising them), dismissing his own failures as the peons not able to understand his greatness. And for all this the "community" regards him as a living god.

If you look at it all honestly, it's difficult to find any "contributions" that Linux has done that weren't/aren't already done first and better by others. I'd even go so far as to say the computing world would have been better off never having been exposed to the plague that is Linux, which didn't win the market through technical merit.

I'm sorry, PowerShell is a trainwreck of a language. Extremely unintuitive, inconsistent, cryptic.

Using a function? Call it as function($arg1, $arg2). Oh, did you write the function? Sorry, you'll have to call it as function $arg1 $arg2.

Want to pass a path to something? It's easy: -Path $path. Oh wait, $path is actually a real path and not a glob? You'll have to use -literalPath...if it's supported. Yep, we kept the same failed idea of CMD and decided argument expansion should be done by each command/function/program/cmdlet independently so that we can make damn sure nothing at all is ever consistent. There's a reason why every Unix shell, bash much included, handles argument expansion in the shell.

Sane variable scoping? Not from PS.

Want to use something from .Net? It's built in, a major selling point! Oh...sorry if the syntax is so incredibly buggered that it makes real world PowerShell/.Net code look like a bid for the Obfuscated Perl Contest. And once you get it "right", PowerShell can't grok anything beyond trivial. God help me, I had to craft and populate an IEnumerable of Tuple of String, String in PowerShell to pass to a .Net method (from DacServices). Finally crafted (looked like a spell incantation), it couldn't get through PowerShell to the method call in one piece. Flat out broken. Finally had to give up and just code a real C# console app to handle the 10 lines of code.

Want output/trace to display in the order you actually write it? When it actually happens? Better | Out-Default all of it or strange things happen.

Most sane languages, especially so-called "OOP" languages, actually stop when an exception is thrown by default. Typically with a default global catch that offers you a nice stack trace, or something. PowerShell? By default it keeps on trucking, not even a peep (bad old habits of CMD are hard to break I guess).

Misspell a variable somewhere? Or a method name? Not even a warning until runtime when it fails (but then keeps on trucking right along, happy to double down on the fail). Even Perl isn't that bad (at least with "use strict;").

PowerShell is better than CMD/Batch. But then, so is a swift kick to the head. It's a horrid language and a bad shell. Bash via Cygwin is a hell of a saner and more powerful way to use a shell on Windows. And if you ever need .Net something, do yourself a huge favor and do it from C# as a console app and call that...1,000,000,000 times better than trying to use the fugly hack of a .Net interface that PowerShell provides.

Why would you assume that?

Especially when it's the main highlight of Amazon's Prime Air concept video?

Sure, but it's a much, much easier problem to solve.

For starters, flying is analogous to driving only if every road had 1,000 lanes and there were such 1,000 road lanes leading directly in any direction from any point.

Or in other words, it's not at all analogous to "traffic" as folks typically think of it. A GPS module, a few cheap sonic sensors and/or slightly more expensive transponders, with basic collision avoidance software would easily solve the problem entirely. All of which I must add, are already on board any and all drones for the simple fact you can't navigate autonomously (more or less the definition of a "drone") without it. Anything less and you have a traditional R/C model aircraft, not a drone.

And you would be completely correct....except for SEC. 336. SPECIAL RULE FOR MODEL AIRCRAFT, which effectively exempts the FAA from almost any authority over anything that could legitimately be called a model aircraft used in a legitimate way. Effectively it puts the AMA in charge of regulating model aircraft, just as the organization has done with astounding success and safety for the better part of a century.

In general, don't do anything that isn't your core business. Or another way of saying it, Do What Only You Can Do.

If you are an insurance company, is building and maintaining hardware your business? No, not in the slightest. You have no more business maintaining computer hardware as you have maintaining printing presses to print your own claims forms.

Maintaining hardware and the rest of the infrastructure stack however, is the business of Amazon AWS, Windows Azure, etc. The "fantasy" you're referring to is the crazy idea that you, as some kind of God SysAdmin, can out-perform the world's top infrastructure providers at maintaining infrastructure. Even if you were the best SysAdmin alive on the planet, you can't scale very far.

Sure, any of those providers can (and do, frequently) fail. Still, they are better than you can ever hope to be, especially once you scale past a handful of servers. If you are concerned that they still fail, that's good, yet it's still a problem worst addressed by taking the hardware in house. A much better solution is to build your deployments to be cloud vendor agnostic: Be able to run on AWS or Azure (or both, and maybe a few other friends too) either all the time by default or at the flip of a (frequently tested) switch.

Even building in multi-cloud redundancy is far easier, cheaper, and more reliable than you could ever hope to build from scratch on your own. That's just the reality of modern computing.

There are reasons to build on premises still, but they are few and far between. Especially now that cloud providers are becoming PCI, SOX, and even HIPAA capable and certified.

Or it's not at all dependent on those factors.

It's much more a matter of how much someone cares to put redundancy in place. Doing it right affects the entire stack: Code architecture, deployment tooling, infrastructure architecture and costing.

It's a large reason why PaaS is gaining momentum: This is all assumed and it ends up being easier to do it the right way (that includes all this) from the start than doing it any other way, given that most all of the boiler plate aspects are already built.

If you're building services that still require "regular maintenance windows" in 2014, you're doing it wrong.

Extremely unlikely bordering on impossible.

Nearly every possible failure condition would result in the quad-copter falling more or less straight down and into the water.

These things do not glide. Even a partial motor failure would send it tumbling end over end...more or less straight down. When they fail they fall out of the sky like a rock.