My washer's lid switch broke after about five years, but all it takes is a couple of twist ties to fix that. If your washing machine actually broke in a major way (burned out motor, drum leak, etc.), then you just got really, really unlucky. Most non-electronic hardware (even stuff built today) has a lifespan measured in decades except for minor mechanical problems like sticking timers that need to be oiled, Nader switches that need to be solder-bridged, etc.
Translation: Netflix HD is crap. An average DVD is encoded at 4-5 Mbps (up to twice the data rate you're saying Netflix HD uses, depending on which estimate we believe), and that's just standard definition content. At standard definition, 2-3 Mbps is basically the minimum required just to avoid bad blocking artifacts during fast motion. At 1 Mbps, the picture quality looks pretty rough, at least with MPEG2. H.264 may buy you a bit more quality, but not that much more. With high definition content, assuming we're talking about 1080i, that would mean cramming the same amount of information as six standard definition video streams into the same amount of bandwidth. I can't imagine not having very visible artifacts at such a data rate, even with H.264.
To put it in perspective, a Blu-Ray is typically encoded at about 20-30 Mbps, with some action films running steadily up in the 30Mbps range and spiking into the 40s. That's fully an order of magnitude more than the numbers you're giving for Netflix "HD". In other words, even though their high definition content might pedantically be high definition (as measured in terms of the encoded pixel count), it's HD in much the same way that a cheap video camera is "DVD quality", if that.
Almost all Blu-Ray discs containing movies are dual layer discs. So if we ignore that in some cases part of the disc might be filled with extras, you can potentially have up to 50 GB for two hours. At that rate (true HD quality), that 250 GB cap is barely enough to download five motives. When we're talking about real HD video, 250 GB is a very low cap—almost uselessly so. Indeed, the only reason cable providers seem to think that this is a reasonable cap is that the content providers have grudgingly provided this low quality pseudo-HD content instead of real high definition content so that the sorry excuse for broadband we have in the U.S. doesn't make customers wait two or three days of continuous downloading just to watch one movie.
I'd pay to see somebody have the guts to roll out a full, 1080i, 30Mbps streaming video service, just to watch every cable company and broadband provider have to field tens of thousands of angry calls from their customers asking why their 30Mbps service A. isn't actually providing 30 Mbps, and B. just sent them an $800 monthly bill. Just saying.
I have a hard time figuring out what would actually happen if that plan were put into place because it is so radically different from our current system of taxation. My suspicion is that the poor would take it on the chin, just like with a sales tax, and that the cost of goods would be further increased to make up for the increased cost of production, thus compounding the problem.
A far better way to raise the extra revenue is to simply change our tax structure so that capital gains are taxed as ordinary income (with a one-time-per-person exemption for selling your primary residence). This would substantially increase revenue, but unlike a transaction tax, businesses would not be able to hide it in the cost of doing business. Instead, it would come out of the money that the stockholders leech at the end of the chain.
Now, mind you, this would make retirement harder for a lot of people, but that could be largely solved by lowering the average marginal rates and removing or significantly changing limits on Roth IRAs.
Unless your numbers are adjusted for inflation, that's a large part of the difference right there. Not to mention that U.S. spending on defense is up significantly from even the excesses of the Reagan years, due to the two (three?) wars that the U.S is actively fighting.
Add to that the greater-than-inflationary increases in health care costs (which are out of the government's control unless you want death panels), and you'll probably find that the U.S. spends less per person on non-war, non-health costs than it did in the 80s. At best, it's not a huge increase as you seem to be claiming.
Just to be clear, I do agree about the things that you think should not have been budgeted to nearly the degree that they have, but I think you'll find that in the bigger budgetary picture, those expenditures are almost lost in the noise when compared with defense spending, health care, and other big-ticket items. I've seen some estimates that as much as 54% of our federal budget is spent on military spending (including VA, etc.). According to Wikipedia's chart, about three quarters of our budget was spend on social security, medicare, medicaid, DoD, unemployment, and welfare when you add them up. Most of that isn't proportional to the population, but rather proportional to some rapidly growing portion of the population (the aging, the poor, etc.) or proportional to our level of military activity.
Surely a spammer is going to not want to pay an upfront cost and is definitely not going to want to hand over a credit card number that can track back to him/her.
The problem is that without a change to the protocols, spammers won't bother to pay for an actual account. They'll just slip a little cash to somebody who runs a botnet. They'll send out the mail directly using SMTP (which, remember, is an entirely security-free protocol by nature), and it won't really matter whether free email account users have to pay a fee or not. It won't have a valid return address, and they'll get replies by people going to a web page, same as they do now.
Thus, the only way charging money for accounts will help with the spam problem is if we also throw away SMTP and move to require signed messages, or at least TLS with valid certs used to identify both the server and the client (which is typically another server). Otherwise, anybody who wants to send spam can just query the MX record for the target domain, open up a connection to port 25 on their mail server, and deliver the spam without the need for anything even approaching an actual email account.
telnet hostname.tld 25
HELO myname.myfakedomain.tld
MAIL FROM: <bogus@donotreply.com>
RCPT TO: <target_user@hostname.tld>
DATA
Hello. You do not know me, but I get your address from a mutual friend. I am [name], accountant to [name], Prime Minister of [country]. I am in need of your assistance to transfer the sum of FIVE MILLION USD DOLLARS ($5,000,000 DOLLARS)....
I retract that comment. I've just been informed that something that I thought didn't work actually does. Not sure why it wasn't working for me in certain cases, but since I can't actually find any of my code where closures didn't make local variables available to the enclosing function, I'm going to assume that either I was doing something else wrong or it was a browser bug. *shrugs*
var outerargs = arguments;
return function () {
var newargs = Array (outerargs.length - 2 + arguments.length);
Does this actually work? Every time I've tried to access a variable in the enclosing context, I've had problems with it being undefined. That said, it has been a few years since I tried it. Maybe the browsers were just buggy as all **** back then.
Rather than learn prototype-based OO and closures, you prefer more rigid, static techniques.
Real closures are great. What passes for closures in JavaScript (defining a function by gluing strings together or using global variables to work around the fact that there is no good way to store any arbitrary data in the constructed function so that it will be available when the function calls it) is not.
Contrast blocks in Objective-C with the disaster that is constructed functions in JavaScript, and there's just no comparison. Don't get me wrong, blocks aren't perfect, either—I wish I could trivially make static (permanent function-local) variables into block variables—but it's a lot better than the clumsy hack that JavaScript programmers are forced to use to approximate a proper closure.
Only if you moved email to a completely separate and incompatible service so that people can no longer use WinZombies to send it out in bulk. AFAIK, the vast majority of spam isn't sent out through any sort of legitimate mail server at all, but rather is sent by botnets.
A fee would put Amazon in the subsidy or vanity publishing category -- not pleasant company for indie authors like myself who have sold through traditional publishing too.
Not any more so than they already are. If you're selling through a traditional publisher, then they are paying the fee to list the book. If we're talking about selling eBooks out-of-band, then they're already basically a vanity publishing service, and I fail to see how charging a listing fee is any different than them taking a cut of the profit in that regard.
Besides, I'm not talking about charging a $2,000 editing fee and a $5,000 publishing fee. I'm talking about charging a listing fee that's just large enough to ensure that you're unlikely to break even if you are flooding the market with crap, but small enough that anybody selling a legit book even at a couple of dollars apiece will make it up in no time flat.
Maybe, but that doesn't mean the GP is wrong. The design of JavaScript borders on absurdity. It's a terrible language.
The closest thing it has to actual classes feels like a crudely bolted on hack (like Perl, but with even less syntax support).
It uses the same symbol for addition and string concatenation, leading to the necessity of ugly hacks like parseInt() that could just as easily be done transparently if the two (conceptually dissimilar) operations had separate symbols.
Most of the commonly built-in JavaScript APIs abuse developers by forcing them to use callbacks because JavaScript has no notion of blocking calls and doing work in other threads at the same time.
Worse, most JS APIs (e.g. XHR) don't provide any extra parameters for passing context data through them to your callback. This forces you to do such awful hacks as hiding program data in the DOM tree and building generated helper functions on the fly for every freaking call. Such design makes the use of those functions very, very cumbersome, to say the least.
And so on.
As someone who programs regularly in half a dozen languages and knows way more than that, in my opinion, JavaScript is the absolute worst of the non-esoteric modern scripting languages. I would much rather code in Perl, and I've grown to really despise Perl over the years, so that's saying something.
Heck, I'd just about pick BF or whitespace over JS. That said, as an output target for LLVM, I'm okay with it.
And it would all be solved if Amazon charged a $20 listing fee per title. It's a token amount of money that's easy to get back if you're selling a legitimate book. It's a huge amount of money that's impossible to get back if you're trying to game the system by selling public domain content.
I'm assuming you're being sarcastic. If not, though, by that standard, we should have serious security holes on a near-daily basis in Notepad, Facebook, Google....
This, of course, brings us to the obvious question: how many security holes does a single plug-in have to patch before we can take for granted that the code is one giant, steaming pile of dingo turds? Just curious. Maybe that should be a Slashdot poll....
The x86_64 architecture has the ability to mark memory pages non-executable (NX) and so some forms of overrun exploits simply do not succeed.
Sure, that prevents certain types of exploits against certain vulnerabilities, but it doesn't generally nullify a vulnerability entirely.
A vulnerability is like having a glass window next to the door on your house. The NX bit is like bars on that window. It prevents you from trivially breaking the glass and reaching through to turn the lock, but it does not prevent you from breaking the glass, pointing a gun at someone on the other side, and ordering him or her to unlatch the bars so that you can reach in and unlock the door.
In much the same way, an NX bit prevents you from injecting arbitrary code in some places, but doesn't necessarily prevent you from calling mprotect or whatever to make the writable page executable or to make some other executable page writable or whatever. This just means that you now have to exploit the vulnerability in a more complex fashion or exploit it more than once (e.g. once to return into the first line of mprotect after overwriting the parameters appropriately so that it makes the stack writable, and once to overwrite the stack with your code and jump into it). The exploit just becomes a somewhat more complicated trampoline design instead of a simpler chunk of code.
All those techniques (NX, ASLR, etc.) make it harder to attack 64-bit processes, but even when combined, they are not a cure-all, and I'd be wary of any claim that they can completely nullify any particular security hole. It might be true in a few cases, but that's like buying expensive HDMI cables for your living room under the assumption that it will make the picture look better.
Since Asian and corporate users refuse to upgrade the webmasters are under pressure to make a site that looks great for IE 6 that will work 5 years from now with Chrome 25. Flash is the substitute.
And then their sites won't work on iPhone, iPod Touch, or iPad. In general, pandering to people running outdated browsers on an outdated OS on outdated hardware while ignoring people with the disposable income to buy modern gadgets is generally bad for sales. Just saying.:-)
There are sites too that use more flash if it detects IE 6 or IE 7.
See, since I don't run IE6 or IE7, I don't really care about those. They don't affect me, and if they affect you, this might be a good time for you to click on over to your choice of Google, Apple, or FireFox and download a better browser.:-D
The real issue, actually, is not telling IT folks about the exploit (not necessarily details but enough to know to not use the product or to use a work around to limit/block the exploit) before the patch is released.
You're kidding, right? Are there really any IT admins who still don't know that from a security perspective, Flash is a giant sieve?:-)
Seriously, any IT admin that doesn't (at minimum) install a Flash blocker on every machine is missing a security hole so big you could drive an Abrams through it.
All a vendor having a time table does is allow them to group many exploits together to allow them to pretend the amount of exploits that exist are smaller than there are.
Very, very wrong. It has lots of benefits:
Fewer patches mean each patch likely to be more thoroughly tested because it wasn't rushed out the door.
Fewer patches mean IT admins have time to test them all before rolling them out.
Even with all the testing in the world, patches are going to break at least a few machines. Therefore, fewer patches = fewer hosed machines.
As someone else noted, the release + 6 hours problem occurring once per week instead of once per day means that crackers creating exploits have only one seventh the number of opportunities to break into your machines.
In short, the only reason you should ever release an unscheduled security patch is if you know that the vulnerability is already being exploited in the wild. Mind you, I'm not saying that you should sit on security fixes for two or three months, but releasing non-zero-day security fixes in an unscheduled fashion would be just as reckless and irresponsible as not immediately releasing a patch for a zero-day.
The reason you might be right in this case is that Flash is just so d**n buggy. I don't know how bad it is on Windows, but on Mac OS X, back before I added Click2Flash (and later, ClickToFlash), it used to be the #1 most common cause of Safari crashes on my machine by fully an order of magnitude over all other causes combined. When you realize that the odds are good that every single one of those crashes is an exploitable security hole, it's a wonder they don't have a zero-day a day.
Because it is so buggy, everybody assumes it is an easy target, and they go looking for exploitable holes. This greatly increases the odds of zero-day exploits. Were Flash not a train wreck, most theoretically exploitable holes would not be known until patch time, and it would be very beneficial to schedule patch releases. As it stands, scheduling patches is of only moderate utility because patching the holes in Flash is like to trying to plug the holes in a colander, one at a time.
In general, however, when you have to upgrade tens of thousands of machines at a company, you need to be able to count on scheduling that work ahead of time. It's a major undertaking, and if you can schedule it ahead of time, you minimize the chances that someone will disassemble the patch, come up with a working exploit, deploy that exploit with a bunch of prewritten attack code in a Flash advertisement on some major ad network, and infect half of your machines before you are able to get them patched.
And this is why my machine has been running a Flash blocker for several years even though nobody has targeted Mac OS X through Flash yet. Just think of Flash blockers as a condom for your network browsing experience, and always practice safe web.
Really? I've been using the ClickToFlash Safari extension for a couple of years, and the Click2Flash Safari plug-in for a year or more before that, and (not counting Flash games) I can count the number of sites where I've had to load Flash content on one hand, give or take. I've only seen about two sites in three or four years that use Flash for the main navigation, and neither is a site that I visit regularly.
YouTube content is generally usable with the HTML5 video tag, which pretty much eliminated the one site I regularly use that required Flash. I'm going to go out on a limb and say that 99% of the Flash content I encounter is advertising, and sites generally work correctly if the Flash content doesn't load, so I see no reason not to disable Flash.
Slashdot Mirror
My washer's lid switch broke after about five years, but all it takes is a couple of twist ties to fix that. If your washing machine actually broke in a major way (burned out motor, drum leak, etc.), then you just got really, really unlucky. Most non-electronic hardware (even stuff built today) has a lifespan measured in decades except for minor mechanical problems like sticking timers that need to be oiled, Nader switches that need to be solder-bridged, etc.
Gah! ... that 250 GB cap is barely enough to download five movies.
I'd scream d**n you, autocorrect, but I'm not using my iPhone. *sigh*
Translation: Netflix HD is crap. An average DVD is encoded at 4-5 Mbps (up to twice the data rate you're saying Netflix HD uses, depending on which estimate we believe), and that's just standard definition content. At standard definition, 2-3 Mbps is basically the minimum required just to avoid bad blocking artifacts during fast motion. At 1 Mbps, the picture quality looks pretty rough, at least with MPEG2. H.264 may buy you a bit more quality, but not that much more. With high definition content, assuming we're talking about 1080i, that would mean cramming the same amount of information as six standard definition video streams into the same amount of bandwidth. I can't imagine not having very visible artifacts at such a data rate, even with H.264.
To put it in perspective, a Blu-Ray is typically encoded at about 20-30 Mbps, with some action films running steadily up in the 30Mbps range and spiking into the 40s. That's fully an order of magnitude more than the numbers you're giving for Netflix "HD". In other words, even though their high definition content might pedantically be high definition (as measured in terms of the encoded pixel count), it's HD in much the same way that a cheap video camera is "DVD quality", if that.
Almost all Blu-Ray discs containing movies are dual layer discs. So if we ignore that in some cases part of the disc might be filled with extras, you can potentially have up to 50 GB for two hours. At that rate (true HD quality), that 250 GB cap is barely enough to download five motives. When we're talking about real HD video, 250 GB is a very low cap—almost uselessly so. Indeed, the only reason cable providers seem to think that this is a reasonable cap is that the content providers have grudgingly provided this low quality pseudo-HD content instead of real high definition content so that the sorry excuse for broadband we have in the U.S. doesn't make customers wait two or three days of continuous downloading just to watch one movie.
I'd pay to see somebody have the guts to roll out a full, 1080i, 30Mbps streaming video service, just to watch every cable company and broadband provider have to field tens of thousands of angry calls from their customers asking why their 30Mbps service A. isn't actually providing 30 Mbps, and B. just sent them an $800 monthly bill. Just saying.
Car keys are retinas.
I have a hard time figuring out what would actually happen if that plan were put into place because it is so radically different from our current system of taxation. My suspicion is that the poor would take it on the chin, just like with a sales tax, and that the cost of goods would be further increased to make up for the increased cost of production, thus compounding the problem.
A far better way to raise the extra revenue is to simply change our tax structure so that capital gains are taxed as ordinary income (with a one-time-per-person exemption for selling your primary residence). This would substantially increase revenue, but unlike a transaction tax, businesses would not be able to hide it in the cost of doing business. Instead, it would come out of the money that the stockholders leech at the end of the chain.
Now, mind you, this would make retirement harder for a lot of people, but that could be largely solved by lowering the average marginal rates and removing or significantly changing limits on Roth IRAs.
Unless your numbers are adjusted for inflation, that's a large part of the difference right there. Not to mention that U.S. spending on defense is up significantly from even the excesses of the Reagan years, due to the two (three?) wars that the U.S is actively fighting.
Add to that the greater-than-inflationary increases in health care costs (which are out of the government's control unless you want death panels), and you'll probably find that the U.S. spends less per person on non-war, non-health costs than it did in the 80s. At best, it's not a huge increase as you seem to be claiming.
Just to be clear, I do agree about the things that you think should not have been budgeted to nearly the degree that they have, but I think you'll find that in the bigger budgetary picture, those expenditures are almost lost in the noise when compared with defense spending, health care, and other big-ticket items. I've seen some estimates that as much as 54% of our federal budget is spent on military spending (including VA, etc.). According to Wikipedia's chart, about three quarters of our budget was spend on social security, medicare, medicaid, DoD, unemployment, and welfare when you add them up. Most of that isn't proportional to the population, but rather proportional to some rapidly growing portion of the population (the aging, the poor, etc.) or proportional to our level of military activity.
The problem is that without a change to the protocols, spammers won't bother to pay for an actual account. They'll just slip a little cash to somebody who runs a botnet. They'll send out the mail directly using SMTP (which, remember, is an entirely security-free protocol by nature), and it won't really matter whether free email account users have to pay a fee or not. It won't have a valid return address, and they'll get replies by people going to a web page, same as they do now.
Thus, the only way charging money for accounts will help with the spam problem is if we also throw away SMTP and move to require signed messages, or at least TLS with valid certs used to identify both the server and the client (which is typically another server). Otherwise, anybody who wants to send spam can just query the MX record for the target domain, open up a connection to port 25 on their mail server, and deliver the spam without the need for anything even approaching an actual email account.
I retract that comment. I've just been informed that something that I thought didn't work actually does. Not sure why it wasn't working for me in certain cases, but since I can't actually find any of my code where closures didn't make local variables available to the enclosing function, I'm going to assume that either I was doing something else wrong or it was a browser bug. *shrugs*
Does this actually work? Every time I've tried to access a variable in the enclosing context, I've had problems with it being undefined. That said, it has been a few years since I tried it. Maybe the browsers were just buggy as all **** back then.
Real closures are great. What passes for closures in JavaScript (defining a function by gluing strings together or using global variables to work around the fact that there is no good way to store any arbitrary data in the constructed function so that it will be available when the function calls it) is not.
Contrast blocks in Objective-C with the disaster that is constructed functions in JavaScript, and there's just no comparison. Don't get me wrong, blocks aren't perfect, either—I wish I could trivially make static (permanent function-local) variables into block variables—but it's a lot better than the clumsy hack that JavaScript programmers are forced to use to approximate a proper closure.
Only if you moved email to a completely separate and incompatible service so that people can no longer use WinZombies to send it out in bulk. AFAIK, the vast majority of spam isn't sent out through any sort of legitimate mail server at all, but rather is sent by botnets.
I was thinking more like .Mac.
Not any more so than they already are. If you're selling through a traditional publisher, then they are paying the fee to list the book. If we're talking about selling eBooks out-of-band, then they're already basically a vanity publishing service, and I fail to see how charging a listing fee is any different than them taking a cut of the profit in that regard.
Besides, I'm not talking about charging a $2,000 editing fee and a $5,000 publishing fee. I'm talking about charging a listing fee that's just large enough to ensure that you're unlikely to break even if you are flooding the market with crap, but small enough that anybody selling a legit book even at a couple of dollars apiece will make it up in no time flat.
No, no. It's write once, debug everywhere. Get it right....
Maybe, but that doesn't mean the GP is wrong. The design of JavaScript borders on absurdity. It's a terrible language.
And so on.
As someone who programs regularly in half a dozen languages and knows way more than that, in my opinion, JavaScript is the absolute worst of the non-esoteric modern scripting languages. I would much rather code in Perl, and I've grown to really despise Perl over the years, so that's saying something.
Heck, I'd just about pick BF or whitespace over JS. That said, as an output target for LLVM, I'm okay with it.
And it would all be solved if Amazon charged a $20 listing fee per title. It's a token amount of money that's easy to get back if you're selling a legitimate book. It's a huge amount of money that's impossible to get back if you're trying to game the system by selling public domain content.
Awesome. Now we just have to figure out how to modulate its emissions....
And we'd build giant, terawatt IR emitters to blanket the entire world outdoors? Why do I have the feeling you haven't thought this one through....
Please tell me you're kidding.
No, no.
You've gotta tell 'em! Soylent brown is FECAL!
I'm assuming you're being sarcastic. If not, though, by that standard, we should have serious security holes on a near-daily basis in Notepad, Facebook, Google....
This, of course, brings us to the obvious question: how many security holes does a single plug-in have to patch before we can take for granted that the code is one giant, steaming pile of dingo turds? Just curious. Maybe that should be a Slashdot poll....
Sure, that prevents certain types of exploits against certain vulnerabilities, but it doesn't generally nullify a vulnerability entirely.
A vulnerability is like having a glass window next to the door on your house. The NX bit is like bars on that window. It prevents you from trivially breaking the glass and reaching through to turn the lock, but it does not prevent you from breaking the glass, pointing a gun at someone on the other side, and ordering him or her to unlatch the bars so that you can reach in and unlock the door.
In much the same way, an NX bit prevents you from injecting arbitrary code in some places, but doesn't necessarily prevent you from calling mprotect or whatever to make the writable page executable or to make some other executable page writable or whatever. This just means that you now have to exploit the vulnerability in a more complex fashion or exploit it more than once (e.g. once to return into the first line of mprotect after overwriting the parameters appropriately so that it makes the stack writable, and once to overwrite the stack with your code and jump into it). The exploit just becomes a somewhat more complicated trampoline design instead of a simpler chunk of code.
All those techniques (NX, ASLR, etc.) make it harder to attack 64-bit processes, but even when combined, they are not a cure-all, and I'd be wary of any claim that they can completely nullify any particular security hole. It might be true in a few cases, but that's like buying expensive HDMI cables for your living room under the assumption that it will make the picture look better.
And then their sites won't work on iPhone, iPod Touch, or iPad. In general, pandering to people running outdated browsers on an outdated OS on outdated hardware while ignoring people with the disposable income to buy modern gadgets is generally bad for sales. Just saying. :-)
See, since I don't run IE6 or IE7, I don't really care about those. They don't affect me, and if they affect you, this might be a good time for you to click on over to your choice of Google, Apple, or FireFox and download a better browser. :-D
You're kidding, right? Are there really any IT admins who still don't know that from a security perspective, Flash is a giant sieve? :-)
Seriously, any IT admin that doesn't (at minimum) install a Flash blocker on every machine is missing a security hole so big you could drive an Abrams through it.
Very, very wrong. It has lots of benefits:
In short, the only reason you should ever release an unscheduled security patch is if you know that the vulnerability is already being exploited in the wild. Mind you, I'm not saying that you should sit on security fixes for two or three months, but releasing non-zero-day security fixes in an unscheduled fashion would be just as reckless and irresponsible as not immediately releasing a patch for a zero-day.
In this case, maybe; in general, no.
The reason you might be right in this case is that Flash is just so d**n buggy. I don't know how bad it is on Windows, but on Mac OS X, back before I added Click2Flash (and later, ClickToFlash), it used to be the #1 most common cause of Safari crashes on my machine by fully an order of magnitude over all other causes combined. When you realize that the odds are good that every single one of those crashes is an exploitable security hole, it's a wonder they don't have a zero-day a day.
Because it is so buggy, everybody assumes it is an easy target, and they go looking for exploitable holes. This greatly increases the odds of zero-day exploits. Were Flash not a train wreck, most theoretically exploitable holes would not be known until patch time, and it would be very beneficial to schedule patch releases. As it stands, scheduling patches is of only moderate utility because patching the holes in Flash is like to trying to plug the holes in a colander, one at a time.
In general, however, when you have to upgrade tens of thousands of machines at a company, you need to be able to count on scheduling that work ahead of time. It's a major undertaking, and if you can schedule it ahead of time, you minimize the chances that someone will disassemble the patch, come up with a working exploit, deploy that exploit with a bunch of prewritten attack code in a Flash advertisement on some major ad network, and infect half of your machines before you are able to get them patched.
And this is why my machine has been running a Flash blocker for several years even though nobody has targeted Mac OS X through Flash yet. Just think of Flash blockers as a condom for your network browsing experience, and always practice safe web.
Really? I've been using the ClickToFlash Safari extension for a couple of years, and the Click2Flash Safari plug-in for a year or more before that, and (not counting Flash games) I can count the number of sites where I've had to load Flash content on one hand, give or take. I've only seen about two sites in three or four years that use Flash for the main navigation, and neither is a site that I visit regularly.
YouTube content is generally usable with the HTML5 video tag, which pretty much eliminated the one site I regularly use that required Flash. I'm going to go out on a limb and say that 99% of the Flash content I encounter is advertising, and sites generally work correctly if the Flash content doesn't load, so I see no reason not to disable Flash.