And the indies I know *personally* sell CDs at gigs, primarily because the only people who even know who they are are people at their gigs. One in particular sells TONS of CDs at each of their gigs, they've sold a total of 5 on their website, 4 of which left notes with their orders saying they bought the CD based on a bootleg they found on YouTube.

That might only be 5 sales, but it's 5 more than they'd have had; with more exposure, that number would be higher.

Anecdote != data, but there you have it, the reasoning behind my logic.

Who said anything about "without authorization"? Some artists don't mind it one bit.

And, rather than suing, they post a link to the video.

They're not alone, either. A *ton* of artists would love that kind of exposure. Especially for *free*.

Methinks the text you quoted was meant in the context of the text I quoted. So, you pretty much just made the point jedidiah was trying to make. Derp.

but if that sandbox can ping...

And what of Bonjour? Anyone running their mac connected directly to a cable or DSL modem because "I only have on computer, so why do I need a router?" is potentially vulnerable, and we have no reason to believe otherwise until we see the source for Bonjour to prove that it makes no system calls. It's cross-platform, so you can be sure it's not relying on cocoa APIs.

Then call it a CentOS or Ubuntu bug. There is nothing intrinsic to Linux, itself, that make is any more or less vulnerable to this *bash* bug.

It's Ubuntu, so whatever their market share is. 12.04 if you want to get specific.

It is also an OSX bug, an HPUX bug, a vxWorks bug, and, well, really, a bug in any OS that has bash installed, which makes it a Windows bug in a not-insignificant number of cases, as well. Also, consider that the thousands of Cygwin and MinGW users out there are also likely running servers on top of that POSIX layer on their windows system, they're almost certainly vulnerable.

And the moment they use a found exploit, some dedicated sysadmin detects the intrusion and figures out how it was done, a bug report is filed, and it gets patched within hours. Like this bug, found by a researcher, reported, and patches were available before exploits; whether or not systems were actually patched is a factor if the sysadmin responsible for each individual system, but the fact still remains that we didn't have to wait until Patch Tuesday for a fix.

Was the first patch complete? No. Nor was the second. The third may well not be, either, but Patch Tuesday still hasn't come around and we're better-patched than those who have to wait for that. Well, aside from OSX users (myself included), who actually paid for their OS (in the form of a hardware purchase), so yeah, I guess "you get what you pay for" holds true here, right? See what I'm getting at, here? Linux users have a steady stream of patches already available to install, for free, while OSX users are left behind by Father Apple. Well, at least *some* of us can compile our own patched replacements, so I'm still not sitting here waiting for Patch Tuesday to fix this.

That being said, I haven't had to reboot my Windows machine for updates, lately. That might be, in part, because it does so automatically, whether I'm there to save my work or not, and regardless of whether I'm in the middle of a multi-day render that I'll have to restart, losing 4 days of progress. Thanks, Microsoft.

Do you have a copy of the bash source code in which this bug was first introduced? There is no versioning going that far back for bash, so you can't possibly know *when* it was introduced. It's quite possible that it's from 1989, when bash was first created, 2 years before Linux came to be.

So do OSX, HPUX, and just about every other UNIX variant out there, as well as BSD and any number of embedded systems, and any Windows install running a POSIX layer. It's a POSIX issue, by way of bash being common amongst POSIX systems, not a Linux issue. Focusing on Linux as a means to be able to say "hey, look, Linux fucked up" serves only to mask the existence of the vulnerability in the vast majority of systems *not* running Linux but also running Bash. For the sake of security, as a whole, please, don't do that.

Well, yeah, if your distro symlinks /bin/sh to /bin/bash, which not all do. In fact, you can install sh, zsh, dash, or any other shell, alongside bash, even on systems that symlink to /bin/bash by default, completely negating your entire point. Looks like you did that on a fedora-based system? I'm going to guess RedHat or CentOS? Observe (from one of my production systems):

ls -l /bin/sh
lrwxrwxrwx 1 root root 4 Mar 29 2012 /bin/sh -> dash

My production (and development, for that matter) systems are not vulnerable in that manner, because I didn't configure them like a jackass; in fact, any init scripts on those systems requesting a shell other than /bin/sh (that is to say, those requesting /usr/bin/php, /usr/bin/perl, or some other interpreter were left alone) were altered to use /bin/sh with no apparent ill consequences.

My point is that this is not a Linux bug, it is a bash bug. Bash is used on HPUX, amongst many other UNIX variants, up to and including OSX, as well as many, if not most (or all) Windows POSIX layers. Your cable or DSL modem probably has bash running on it somewhere, FFS.

Technically, it would be a bug in any script starting with

#!/bin/bash

having absolutely nothing to do with Linux.

The ability to drop the GUI and slim the system down to run on a machine with very limited resources, while still having a full system (e.g. not CE) is a significant benefit over Windows. Even on systems without limited resources, it's a benefit to be able to slim down the OS as much as possible and provide those resources to your application.

For those of us who install security updates automatically, this was patched within hours of being discovered, and each further patch has been applied within hours, as well. On a Windows system set to install updates automatically, bugs *still* go unpatched for months after being reported.

I'm saying this not as a Linux proponent, but as someone who uses all 3 major systems on a daily basis, for whom Linux isn't even a primary system.

Well, to be fair, Apple targets an audience with plenty of cash. Who goes on 2 month wilderness hikes? Perhaps a better question to illustrate my point: who can afford to go on 2 month wilderness hikes?

People with plenty of cash. Cash they could use to buy Apple devices.

Having an SD slot wouldn't stop someone from using the iPhone without an SD card. they could still sell the devices to the same market they currently sell them to, and as a shareholder I would certainly hope they would; but, also as a shareholder, I recognize the market they're missing. My example was extreme, so as to be clear, but there are hundreds of other, more common, scenarios in which an SD slot might be useful.

Hell, putting on the shareholder hat again, I'd be happy if they just made it an option on the 128GB model. Really, that would be ideal, as it would stop people from buying the 16GB model and slapping a 128GB SD card in it, while opening up a whole market that Apple is not tapping.

And it still took 20 years. That argument is bunk, just like the argument that it's automatically more secure because it's open. It *can be* more secure, but people actually have to audit it.