I get what you're saying, but this project isn't likely to cause a major issue like the Phantom has.

What they are designing is going to need to be about the size of a Blade Nano QX. I've no idea how they plan to get all that technology in such a tiny quad, but assuming they do the "impact" of one of these hitting someone will be practically nothing. The micro/nano size quads just don't have the power, mass, or prop size do to significant harm (unless maybe, it actually hits you in the eye).

It makes sense, /bin/csh was the traditional default shell of BSDish systems.

But the default shell doesn't matter, because the default shell isn't used by C library functions like system(). /bin/sh is used, no matter what your "default shell" is set to. And some foolish folks decided to go ahead and replace /bin/sh with bash.

Trying to brush off blame with the tired old nonsense that "Linux is just the kernel, man!", just doesn't fly anymore. Hell, it never really has.

The term "Linux" is well understood to mean a family of full, complete operating systems (libs, userland, and all). When anyone is actually speaking of just the kernel, it's qualified as exactly that, "The Linux kernel...blagh, blagh".

Sure, a double fork() && exec() pattern is ideal, but it's also significantly more code and complexity (read: fat thumb bugs) than calling system("/some/command &");

And before you say it, yes actually there are tons of use cases where forking a background process is a far superior method than any alternatives. It's one of the oldest and most common Unix programming patterns in existence. Programming doesn't really change much simply because you add "on the web" to the end of your use case.

The vast, vast majority of tools do not need significant "scaling". Often just throwing a heavy weight job in the background (eg, transcoding a video file) is, and always will be, significant. Especially if you've got an auto-scaling web farm that'll just expand under load anyway. system("/big/job &") all day long.

Sure, it'll never scale to YouTube levels, but it'll scale large enough for 99% of common use cases.

The "proper" alternative architecture using message queues, etc is massively more code, complexity, and resource cost. Great if you actually need it, nothing but overhead when you don't, and you typically don't.

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?