Before and after 2014, you only do the year comparison, for 11 months of 2014 you only do the year and month comparisons, and only for the month of October 2014 do you have to compare all three. That's 31 days of doing three comparisons, 334 days of doing two, and infinity days of doing just one.
Your code first evaluates the day, which will equal 7 12 times each year, so you're doing two comparisons 11 times a year for all eternity, while on October 7th you're doing 3 comparisons, every single year. It doesn't stop there, though, because you're actually doing an extra operation to negate your compound comparison. In reality, your code is never doing a single comparison, it's always two, three, or four, and an infinite number of each, with the worst case being the second most common, rather than the rarest. We're talking about an embedded system, here, where this actually matters.
Anyway, just nitpicking... really just giving you a hard time, I'm sure you'd never put unoptimized code like that into production on a resource-limited embedded system. Right?
In reality, I'm going to be mentoring someone soon and I'm brushing up on my explanations of good and bad practices.
They'd have done well to make the entire phone the thickness of the corner with the camera. *BAM* There's room for an SD slot, and a bigger battery. Oh, and the phone could lay flat on a table.
My wife loves hers, though. Not judging, just pointing out what I see as flaws that other companies have already solved years ago.
My coworker and I took a day trip down Highway 1 this week. I recorded over 30GB of video *on my phone* (while driving) while shooting over 10GB of photos on my camera (while stopped). Now, I'll grant you that my camera is 20MP while my phone is 13MP, so it would have only been 6.5GB of photos, had I taken them with my phone, so we'll use that number. That's still 36.5 GB in a single day, and it wasn't hard to do. At all. Mind you, I was shooting RAW+JPEG; the 10GB of photos is the JPEG portion, the RAW images made up another 30GB that I'm likewise not counting, since my phone wouldn't have used that space, either.
In case you don't understand, a day trip is one day long, so we're talking about a timeframe of less than a day, here, since no photos or video were taken before we left at 10AM, and very little was taken after dark. 36GB. In a day. Well, less than a day, more like 10 hours. Take a weekend hike, shoot some video, and take photos, and you'll very quickly find that even 113GB of usable space on the the 128GB iPhone 6 is a tight fit. Though, weighing in at only 8MP, my 10GB of images would have taken up 4GB on the iPhone, making the daily total 34GB, rather than 36.5GB; so, in theory, it could last Friday evening, all day Saturday and Sunday, and hope you don't see anything interesting on the way back Monday morning. 2 month wilderness hike need not apply.
If you've got apps and music on your iPhone, you're screwed for a weekend hike. Better skip the extra rations and water so you can pack a camera with removable storage.
I'm not sure when I'm gonna get around to editing the video I shot this week, or when I'll have an idle hour to copy it all off the phone, so I'm glad I could just pop out the SD card and pop in another one.
Yeah, I'm getting your point. Hell, I'm not disagreeing with your point. Artists need to get paid, and this artist *does* get paid. They tour half the year, sell out every show, sell out their entire CD inventory almost every single time, and sell out of t-shirts, hoodies, and bumper stickers about half the time. Their 4 members and full-time manager do this, and only this, for a living, and it's paying rent for all 5 of them, covering the cost of a tour bus, keeping food on the table, providing a decent promo budget, and they aren't exactly playing on hand-me-down instruments backed by cheapo gear, all the while setting aside money to retire within the next decade. I'd say they're doing fine, and yes, as we both agree, they both need, and deserve, to be paid for their work, which is why it's good that *they are*.
What you're missing, still, is *my* point. *Some* artists (this artist is *not* the one I linked to in my first post, which means I have provided two examples, which qualifies as *some*; I can provide more, but it's not worth my time) *do* want the exposure, because some artists realize something you are completely *not getting*: someone who's never heard of, let alone heard, your band is unlikely to attend your show and definitely not buying your CDs. Sure, they'll hear you when you're opening for an already established band, but once you gain enough of a following that you're the headline act, you lose that exposure (which is often not free, to begin with; in fact, opening acts often pay dearly for the privilege), so, how do they get that exposure as an indie band who can't afford radio play . Yes, getting on the radio *costs* money, if the you want to be played, rather than the other way around. The answer to that question is "bootleggers". Well, it's *one* answer, but it's a damn good one, and has been for at least half a century.
That music hits those ears, and the owner of said ears either doesn't like it and never listens again, or does like it and goes to see them play next time they're local, buys a CD, or both. Yes, some number of people just take the music, but, get this: **for an indie band, those people wouldn't have ever bought the CD or gone to the show in the first place, because those people would never have known the band existed**
Do lost sales hurt bands? Most definitely. What I think we're disagreeing on is what constitutes a lost sale; I posit that a sale from someone who doesn't even know you exist was never destined to happen and, therefore, cannot be lost.
Wow, missing the boat, really. Some fan puts a bootleg from one of their gigs on YouTube, where someone who *never otherwise would have found them* finds them and, a a result, buys a CD. I can understand why *some* artists wouldn't want this, what with their label taking care of that for them (along with the lion's share of the profits), but that doesn't preclude artists who see the value from deciding to allow it. How many people did the 5 people who bought CDs as a result of the bootleg introduce to their music? How many of them wen to see them play? How many of them bought CDs at the show? In fact, how many saw the bootleg on YouTube and went to a show? And, of them, how many bought CDs at the show? I'd venture to say the number is greater than zero.
Fans buy CDs. The bootlegs on YouTube expose indie artists to more fans, who then buy more CDs. If an artist wants to stand against that, that's fine, more power to them, my point was that *some* artists are okay with it. Can you refute that, in the face of two examples?
Before you answer, keep in mind that *two* fits the definition of *some*.
If you up a couple posts and read the thread, rather than cherry picking what you think you might be able to attack, you'll see my point. Since I know you won't do that, here's a link to the the relevant comment, to provide some context. Where the fuck did I say anything about copyright infringement?
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.
I hadn't realized this track was posted on YouTube. It was a collaboration between me and the enchanting Jo Gabriel, and never actually officially released anywhere. Or at least I thought...
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*.
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.
What is the market share of your Linux-distribution?
It's Ubuntu, so whatever their market share is. 12.04 if you want to get specific.
It absolutely is a bash bug, yes. It is also a bug in any Linux, that makes it/bin/sh.
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.
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.
Let's play out a hypothetical, here. Let's say this exact bug exists within Powershell. When will it be discovered and patched?
Can you look for it? Nope. If Microsoft looking for it? Probably not, they're busy fixing *reported* bugs and writing *new* code. When will it be found? 20 years sounds optimistic.
Well, let's see here... Heartbleed was a bug in OpenSSL, use in a lot of software that has nothing at all to do with Linux, and Shellshock is a bug in the Bash shell, which predates Linux by 2 years and is used on a lot of systems that have nothing at all to do with Linux. Neither bug was a Linux bug, though both affected Linux systems; both also had the ability to affect Windows systems running any number of applications that rely on OpenSSL (if you open your eyes, you might be amazed how many and how common) or Bash (fewer, but still not completely unheard of; there are a number of POSIX layers for Windows, and all of them use Bash by default as far as I'm aware).
The last time I posted these facts, I was modded flamebait, and I'm sure it'll happen again. Plenty of karma to burn, though, so, whatever.
Slashdot Mirror
Just a nitpick, but it's more efficient to use OR...
while (date.year != 2014 || date.month != 10 || date.day != 7) {
Before and after 2014, you only do the year comparison, for 11 months of 2014 you only do the year and month comparisons, and only for the month of October 2014 do you have to compare all three. That's 31 days of doing three comparisons, 334 days of doing two, and infinity days of doing just one.
Your code first evaluates the day, which will equal 7 12 times each year, so you're doing two comparisons 11 times a year for all eternity, while on October 7th you're doing 3 comparisons, every single year. It doesn't stop there, though, because you're actually doing an extra operation to negate your compound comparison. In reality, your code is never doing a single comparison, it's always two, three, or four, and an infinite number of each, with the worst case being the second most common, rather than the rarest. We're talking about an embedded system, here, where this actually matters.
Anyway, just nitpicking... really just giving you a hard time, I'm sure you'd never put unoptimized code like that into production on a resource-limited embedded system. Right?
In reality, I'm going to be mentoring someone soon and I'm brushing up on my explanations of good and bad practices.
They'd have done well to make the entire phone the thickness of the corner with the camera. *BAM* There's room for an SD slot, and a bigger battery. Oh, and the phone could lay flat on a table.
My wife loves hers, though. Not judging, just pointing out what I see as flaws that other companies have already solved years ago.
Here's a followup for you:
My coworker and I took a day trip down Highway 1 this week. I recorded over 30GB of video *on my phone* (while driving) while shooting over 10GB of photos on my camera (while stopped). Now, I'll grant you that my camera is 20MP while my phone is 13MP, so it would have only been 6.5GB of photos, had I taken them with my phone, so we'll use that number. That's still 36.5 GB in a single day, and it wasn't hard to do. At all. Mind you, I was shooting RAW+JPEG; the 10GB of photos is the JPEG portion, the RAW images made up another 30GB that I'm likewise not counting, since my phone wouldn't have used that space, either.
In case you don't understand, a day trip is one day long, so we're talking about a timeframe of less than a day, here, since no photos or video were taken before we left at 10AM, and very little was taken after dark. 36GB. In a day. Well, less than a day, more like 10 hours. Take a weekend hike, shoot some video, and take photos, and you'll very quickly find that even 113GB of usable space on the the 128GB iPhone 6 is a tight fit. Though, weighing in at only 8MP, my 10GB of images would have taken up 4GB on the iPhone, making the daily total 34GB, rather than 36.5GB; so, in theory, it could last Friday evening, all day Saturday and Sunday, and hope you don't see anything interesting on the way back Monday morning. 2 month wilderness hike need not apply.
If you've got apps and music on your iPhone, you're screwed for a weekend hike. Better skip the extra rations and water so you can pack a camera with removable storage.
I'm not sure when I'm gonna get around to editing the video I shot this week, or when I'll have an idle hour to copy it all off the phone, so I'm glad I could just pop out the SD card and pop in another one.
That's fine, that's not where I was going, anyway.
Yeah, I'm getting your point. Hell, I'm not disagreeing with your point. Artists need to get paid, and this artist *does* get paid. They tour half the year, sell out every show, sell out their entire CD inventory almost every single time, and sell out of t-shirts, hoodies, and bumper stickers about half the time. Their 4 members and full-time manager do this, and only this, for a living, and it's paying rent for all 5 of them, covering the cost of a tour bus, keeping food on the table, providing a decent promo budget, and they aren't exactly playing on hand-me-down instruments backed by cheapo gear, all the while setting aside money to retire within the next decade. I'd say they're doing fine, and yes, as we both agree, they both need, and deserve, to be paid for their work, which is why it's good that *they are*.
What you're missing, still, is *my* point. *Some* artists (this artist is *not* the one I linked to in my first post, which means I have provided two examples, which qualifies as *some*; I can provide more, but it's not worth my time) *do* want the exposure, because some artists realize something you are completely *not getting*: someone who's never heard of, let alone heard, your band is unlikely to attend your show and definitely not buying your CDs. Sure, they'll hear you when you're opening for an already established band, but once you gain enough of a following that you're the headline act, you lose that exposure (which is often not free, to begin with; in fact, opening acts often pay dearly for the privilege), so, how do they get that exposure as an indie band who can't afford radio play . Yes, getting on the radio *costs* money, if the you want to be played, rather than the other way around. The answer to that question is "bootleggers". Well, it's *one* answer, but it's a damn good one, and has been for at least half a century.
That music hits those ears, and the owner of said ears either doesn't like it and never listens again, or does like it and goes to see them play next time they're local, buys a CD, or both. Yes, some number of people just take the music, but, get this: **for an indie band, those people wouldn't have ever bought the CD or gone to the show in the first place, because those people would never have known the band existed**
Do lost sales hurt bands? Most definitely. What I think we're disagreeing on is what constitutes a lost sale; I posit that a sale from someone who doesn't even know you exist was never destined to happen and, therefore, cannot be lost.
Wow, missing the boat, really. Some fan puts a bootleg from one of their gigs on YouTube, where someone who *never otherwise would have found them* finds them and, a a result, buys a CD. I can understand why *some* artists wouldn't want this, what with their label taking care of that for them (along with the lion's share of the profits), but that doesn't preclude artists who see the value from deciding to allow it. How many people did the 5 people who bought CDs as a result of the bootleg introduce to their music? How many of them wen to see them play? How many of them bought CDs at the show? In fact, how many saw the bootleg on YouTube and went to a show? And, of them, how many bought CDs at the show? I'd venture to say the number is greater than zero.
Fans buy CDs. The bootlegs on YouTube expose indie artists to more fans, who then buy more CDs. If an artist wants to stand against that, that's fine, more power to them, my point was that *some* artists are okay with it. Can you refute that, in the face of two examples?
Before you answer, keep in mind that *two* fits the definition of *some*.
If you up a couple posts and read the thread, rather than cherry picking what you think you might be able to attack, you'll see my point. Since I know you won't do that, here's a link to the the relevant comment, to provide some context. Where the fuck did I say anything about copyright infringement?
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.
I hadn't realized this track was posted on YouTube. It was a collaboration between me and the enchanting Jo Gabriel, and never actually officially released anywhere. Or at least I thought...
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*.
Most people whining about GIMP and putting Photoshop on a pedestal are amateurs and consumer
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.
Whether or not Ubuntu and CentOS are different OSes or just different distributions, is a matter of semantics...
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.
What is the market share of your Linux-distribution?
It's Ubuntu, so whatever their market share is. 12.04 if you want to get specific.
It absolutely is a bash bug, yes. It is also a bug in any Linux, that makes it /bin/sh.
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):
/bin/sh /bin/sh -> dash
/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.
ls -l
lrwxrwxrwx 1 root root 4 Mar 29 2012
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
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.
Let's play out a hypothetical, here. Let's say this exact bug exists within Powershell. When will it be discovered and patched?
Can you look for it? Nope. If Microsoft looking for it? Probably not, they're busy fixing *reported* bugs and writing *new* code. When will it be found? 20 years sounds optimistic.
Shellshock has nothing to do with Linux, either. Bash predates Linux by 2 years.
Well, let's see here... Heartbleed was a bug in OpenSSL, use in a lot of software that has nothing at all to do with Linux, and Shellshock is a bug in the Bash shell, which predates Linux by 2 years and is used on a lot of systems that have nothing at all to do with Linux. Neither bug was a Linux bug, though both affected Linux systems; both also had the ability to affect Windows systems running any number of applications that rely on OpenSSL (if you open your eyes, you might be amazed how many and how common) or Bash (fewer, but still not completely unheard of; there are a number of POSIX layers for Windows, and all of them use Bash by default as far as I'm aware).
The last time I posted these facts, I was modded flamebait, and I'm sure it'll happen again. Plenty of karma to burn, though, so, whatever.