If your filesystem checker does that, it is very, very broken. No fsck tool should ever look inside an existing file for filesystem metadata. A filesystem checker should be collecting its free block list or bitmap as it reads the existing metadata so that it can check that later. Once you have that free block list you now know which blocks might potentially contain filesystem metadata legitimately. Then, you check only the blocks that are not already in use for something else.
Now a deleted disk image, perhaps, but even then, only if you explicitly pass flags to the filesystem checker to tell it to reattach "lost" inodes that haven't been marked as deleted. Even then, the problem can be solved by adding a UUID to each inode and ignoring things that look like inodes if the UUID doesn't match.
For that matter, even without a UUID, and even in the case where the filesystem metadata is severely damaged and you're reconstructing large parts of it from scratch by scavenging blocks, you should never have a situation where an inode appears inside the block range for another file. If you have an embedded disk image, you should be able to programmatically determine which inodes are real and which ones are inside an image by scanning for directory blocks first.
A directory block on a disk image will mostly point to inodes that aren't actually at those physical blocks because the block numbers are logical offsets into a file instead of being relative to the start of the partition. A directory block that's real will point almost if not entirely at real inodes. Then, when you see an inode that looks like it is part of another file, you see whether it was referenced from a directory block that looks real. If not, you assume that the inode isn't real, either.
BTW, the problem of filesystem nesting is fixed in Reiserfs V4, and is a pretty good reason to not use V3.
But you are wrong that the SSD is doing the purging outside of OS intervention.. the OS must specifically mark pages for purging.
That's mostly correct, but incomplete. The TRIM command marks a range of logical flash pages as unused, but it's not correct to say that pages are not wiped except when a TRIM occurs. When the flash controller needs to write a new copy of a flash page, it may leave around an older copy of that page. Those older copies of the pages may later be wiped on an as-time-permits basis by the flash controller without intervention by the OS even if the flash page never sees a TRIM call.
I'm not suggesting not doing anything. I'm merely saying that there are much, much, much better ways to get us off coal than feel-good conservation bullshit. Want to get power companies to move off coal? Tax coal and provide tax incentives for building cleaner energy power plants. Make it cheaper to use something else.
As long as coal is cheaper, nothing we do (unless we can cut more than half our power usage, which quite frankly is a pipe dream) will have a significant impact.
And even if it does have some small impact, in the long term, the ban is harmful because people experience personal discomfort that they they directly associate with the "green" movement. By contrast, taxes on coal that are used to provide tax incentives for building green power have a much smaller, much less directly observable impact on the average person.
BTW, I don't have to justify being wasteful. I'm already paying several times as much per kWh as the average American in exchange for most of my power coming from green energy sources (not entirely by choice, mind you, but I'm doing it), and my next house will be 100% solar (because I'm fed up with paying way more than I should be, even for green power). If I want to waste power, as far as I'm concerned, I'm entitled to do so.
Nobody said it was. It does not, however, to my knowledge, ship with things turned on that are more insecure than an emo kid.
TweakUI is beyond MOST USERS?
In principle, no. In practice, the average computer user has never heard of AutoRun, much less TweakUI. That's why the default state must have at least a certain minimum level of security or you're screwed.
I don't think you realize just how little the average computer user knows about how computers work. A sizable percentage of Windows users don't know how to install software at all, relying only on the software that came preinstalled from Best Buy. Thus, even the act of downloading and installing TweakUI is beyond them....
So yeah. It's way beyond a significant percentage of Windows users. Way, way beyond.
It is closed source. The fact that source code has been shown to specific third parties under nondisclosure does nothing to change that fact. I'd be surprised if any closed source piece of software exists that has not at some point been similarly made available to at least one third party under NDA. That's not the same thing as Open Source, in which the source code is out there with public change logs and bug tracking such that almost every single security bug is disclosed to the entire world the moment it is discovered.
...there ARE & WERE valid workarounds....
Which are completely beyond the average Windows user. As far as I'm concerned, an OS is only as secure as it is in the default configuration. If, as installed, an OS has a hole so big you can drive a truck through it, the fact that they provide mortar and a bunch of bricks so that you can patch the hole yourself doesn't really change anything. By that standard, a ten-year-old Linux distro has no security holes because you can recompile BIND, Apache, OpenSSL, etc. yourself. It's a ludicrous argument.
Again, see 1-3 paragraphs above, & tell us that MOST "hacker/cracker wannabes" out there do NOT re-use existing exploits in THEIR variations of them... or that toolkits that get RAMPANTLY "re-used/used" to create malware, don't exist... ok?
Most of the wannabes do, sure. They rely on people not patching their machines for long periods of time. The people who created those exploits in the first place, however, don't generally sit around trolling the list of patched vulnerabilities. By the time there's a patch out there, the bulk of the potential targets are going to be protected before they can roll an attack, leaving only a small percentage of stragglers. For maximum impact, the serious hackers are exploiting zero-day holes.
I'd like YOUR THOUGHTS on the validity of the MacOS X commercials & their "FUD" regarding them implying "MacOS X is more secure than Windows".
My thoughts are that the facts you give do not prove what you think they do.
Also, the articles you are pointing to this time are pretty much harping about ASLR differences. While ASLR is nice and all, that's only one very small aspect of total OS security, and one that is no more or less important than sandboxing, privilege separation, etc. No OS is the best at every aspect of security.
These links are basically tantamount to saying that a Ferrari is better than a Porsche because the cupholders are nicer. While one or the other might be better, it should be obvious to anyone with a modicum of common sense that using one minor feature as the sole basis for comparison is sheer foolishness.
Irrelevant to my point, which was that the source is not out in the open and therefore the known vulnerabilities for that source are likewise not out in the open. Therefore, the odds of any single security bug in Mac OS X getting pointed out publicly are much greater than the odds for a similar bug in Windows simply because the disclosure is much more likely to occur in a public forum or through a publicly visible commit log.
The fact remains that you don't know how many internally known vulnerabilities there are in Windows because you don't have access to Microsoft's internal bug tracking system. Similarly, you don't know how many vulnerabilities there are in the closed source portions of Mac OS X, but you do know how many have been discovered in the open source portions because those bugs are reported out in the open.
Therefore, the fact that Mac OS X contains lots of open source means that you would expect the number of publicly known bugs to be much higher even if the total number of internally known bugs is comparable or lower. In effect, this means that the number of publicly known vulnerabilities is completely useless as a metric of software quality because it has no real relationship to the number of exploitable bugs.
More to the point, the crackers usually already know about the bugs whether they're discussed publicly (as with open source bugs and announcements by legitimate security researchers) or not. The disclosed vulnerabilities, therefore, are largely uninteresting. What matters is the total number of vulnerabilities known to the bad guys, which as I explained above, is not strongly correlated with the number of vulnerabilities known to the general public.
( So, SO MUCH FOR THAT from you, eh? )
Read what the Microsoft bulletin said again. It says AutoRun is still in full force, but only for optical media. Although that does diminish the impact (by preventing people from unknowingly spreading malware by moving flash drives from machine to machine), the fundamental vulnerability is very much still present. Malware producers can still infect a CD manufacturing plant with malware and cause millions of discs from multiple manufacturers to infect Windows boxes on insertion. This is not a theoretical vulnerability, either; people have actually gotten infections from commercial software discs in the past. So they might have put a lock on the front door with that change, but they still left the window right next to it completely ajar with a footstool below it for your convenience.
Re:Solution: Use a proper protocol (aka ISO)
on
Got (Buffer) Bloat?
·
· Score: 1
No. That should generally look like a single, continuous stream from the head end at your cable company. Your machine sends back-channel messages to the head end to indicate that a channel change should occur, and it sends down a different stream. There's really no good reason to disconnect and reconnect when changing channels; doing so would constitute a rather serious abuse of the network due to all the overhead of setting up and tearing down an isochronous transport stream.
Now if by "changing channels" you mean rapidly switching between separate streams from content sources on the Internet, then yes, but on the other hand, most streaming videos are almost invariably not being transmitted live, and thus have no need to be isochronous in the first place. (The only reason to send data isochronously is if you cannot buffer forwards in time arbitrarily far to compensate for network congestion. Otherwise, you should be sending data in bulk. YouTube, for example, should be sending all of its data as bulk data.) As such, again, using isoch connections in that way would constitute abuse.
In short, you might be able to come up with a few edge case exceptions, but you'd have to try pretty hard. In general, isoch connections should be used for live streams from special events, video chat, VoIP, and a single isoch connection to the head end for anything that resembles IPTV. Chances are, anything that falls very far at all outside those bounds would constitute abuse of the standard.
No, I do get it. In such situations, the user had to deliberately install something. You're missing a critical difference between Mac OS X and Windows, though.
Unlike in Windows, where security dialogs pop up for mundane things, Mac OS X's security model only pops up those dialog boxes when you're doing something that you should legitimately be cautious about. Mac users are trained to be wary when they see those boxes.
It is this fundamental difference that distinguishes Mac OS X from Windows, and makes such social engineering attacks significantly less likely. Also, warnings in Mac OS X make it far more obvious if you've accidentally clicked on an application that has been hacked to look like a document, which further improves security in this regard.
NOW, ONTO ACTUAL STATISTICS/FACTS & FIGURES of UNPATCHED KNOWN SECURITY VULNERABILITIES: (MacOS X vs. Windows 7)
Uh... you do realize that the only reason most known vulnerabilities for Mac OS X are "known" is because they are in Open Source bits, right? And that basically none of Windows is Open Source? This means that the number of known unpatched vulnerabilities in Windows should inherently be smaller, not because there are fewer unpatched vulnerabilities, but because its source code has not undergone the same level of external scrutiny.
Also, most of the things on your list are not vulnerabilities, and the few that were are almost all reports about Apple having fixed those vulnerabilities. The only one I saw that did not fall into that category was a DNS cache poisoning bug. Besides being difficult to exploit usefully, it applies to a DNS server daemon that doesn't even run in Mac OS X unless you explicitly enable the name server by editing config files (or in the GUI in Mac OS X Server).
Not all vulnerabilities are created equal. That's what makes comparisons of vulnerability counts useless. As long as Windows supports AutoRun in any form, it will continue to be so far behind Mac OS X that it isn't really even in the race just from that one fundamental design flaw alone.
Not only that, but surely without any kind of third party security you can easily install loggers and whatnot....
For some time, Mac OS X has required that any software that wants to attach to any device that identifies itself as a keyboard (including some presenter remotes, much to my chagrin) be running as root. Because of this design decision, in order to install a keylogger without the user typing his or her admin password, you would have to not only attack an arbitrary application and gain the ability to run code on the user's machine, but also either find an additional vulnerability in one of only a handful of daemons that run as root or find a kernel exploit that allows you to gain root privileges.
In effect, although you could make a Mac OS X trojan or virus that installs a keylogger, it would be exceedingly difficult to do so without the user doing something careless.
Re:Solution: Use a proper protocol (aka ISO)
on
Got (Buffer) Bloat?
·
· Score: 1
Sure it will. You simply cap the customer at the bandwidth he/she is paying for and do QoS within the customer's allocation. Then you don't oversell the bandwidth.:-) Yeah, right. That'll happen.
Alternatively (and more realistically), you design things such that high priority packets must be sent isochronously (that is, every nth time slot) plus or minus a little jitter. A video codec will have no problem delivering frames at a constant data rate. Random bulk communications will not be able to do so, and those sockets will, after some threshold for maximum failures is exceeded, be automatically de-prioritized down to the level of bulk traffic.
You further penalize the endpoint by cutting it down to 56k modem speeds for a month if you see it making too many short-lived (<5s) connections to multiple IPs and declaring them isoch. By definition, any such connections are an abuse of the standard.
The problem is that you can't. Well, you can produce halogen bulbs, but that's still a somewhat different animal than traditional incandescent bulbs. They burn hotter and brighter, with a higher color temperature. They are unsuitable for enclosed fixtures, and the light produced is substantially different.
More significantly, I'm not positive about this, but I think that any incandescent bulb you could create that would meet those efficiency standards, by definition, would behave more like a halogen bulb (brighter, hotter) than traditional incandescent bulbs. By the very nature of resistive power production, it is not possible to meet those efficiency standards and still produce comparable light.
Well, you might be able to still meet them with a halogen bulb and a dimmer, but then your bulb's life expectancy is reduced, and depending on how you design your dimmer, there's a pretty good chance that the whole system would still not meet the efficiency standards even though the bulb itself would. If you want to do it inside the bulb itself, that poses a problem. Linear regulators are right out, so basically you'd be getting into the fairly pricey PWM designs. At twenty or thirty dollars a bulb, it ceases to be economically viable.
So like it or not, in effect, this efficiency standard is a ban on a lighting technology that a fair number of people strongly prefer over the alternatives. Nobody is stepping up to provide non-halogen incandescent bulbs that meet the standards. It's not at all like CFCs where everybody switched to something else and the consumer didn't really notice the change, not because companies wouldn't like the transition to be invisible to consumers, but because that just plain isn't feasible. And that was the point I was trying to make.
Maybe some people can sleep in a house that's fifty degrees, but I can't. To be fair, part of this is an unfortunate side effect of newer, high efficiency, reflective roofing that the government mandates (resulting in increased energy bills most of the year instead of the decrease that the government claimed).
Okay, so they don't cut back on nuke plants, but instead cut back on construction of solar power stations. Either way, the net impact on coal-based power is the same, and it is zero. Every means of producing power is more expensive than coal.
The only time conserving energy could realistically reduce emissions would be during peak hours when they turn on natural-gas-based peaker plants. However, that's mostly in the afternoon, when the vast majority of people are at work or are coming home from work, and thus are not using much lighting at home. So with the exception of people who work at home or are unemployed, moving from incandescent bulbs to CFLs won't help there, either.
Supply and demand only affects prices in a free market, or at least something that approaches it.
Electricity, from the consumer's point of view, is a highly regulated and completely captive market. In general, the public has no choice in power providers beyond "the power company" unless they are willing to invest in power generation hardware themselves.
Further, the prices are generally capped by public utilities commissions. This means that increased demand, by law, cannot cause an increase in price. To make up for this, unlike with free market commodities, the power companies charge folks who use larger amounts of power more per unit because of the increased cost of buying power from more expensive sources.
It's not an economic theory. It's a basic fact of the way things work due to the severely regulated nature of the "market". As long as prices are regulated and as long as supply substantially outstrips demand as it does currently, demand can have no significant effect on retail power pricing.
Although interesting, I would argue that they probably haven't had much impact on CO2 levels unless it's in developing countries. I'd expect most coal plants to run full tilt most of the time because they are cheap to operate. And new coal plants are being added more slowly than old ones are phased out, I think (at least in the U.S.). Thus, any increased load (at least averaged over the long term) would tend to come primarily from increasing the output of more expensive (but cleaner) sources like nuclear power.
Or there is the fact that if everyone replaced one incandescent bulb in their house it would equal removing hundreds of thousands of cars from the road.
Sorry, but that's not a fact. That's at best a fantasy, and at worst an outright lie. Even if we removed every incandescent bulb in the U.S. with a CFL, we would have exactly zero impact on emissions. Why? Because your power company can save a lot more money on their energy bill by reducing nuclear plant output by a few megawatts than by reducing coal-based power production by the same amount.
Repeat after me: no matter how much power I cut, I am not saving the planet.
No, not really. As you use more power, you are causing more power to be produced from more expensive energy sources, true, but your power rate is tiered accordingly, which means that your impact on your neighbor is essentially zero.
The only time you might be able to argue that increased consumption costs other people money would be when your power usage puts the grid over capacity and requires running additional feeder lines to your city. Realistically, though, the ~1% savings you would get by switching every house from incandescents to CFLs won't make a big enough dent to be measurable in that regard when compared with serious power consumers such as manufacturing plants or even household air conditioning.
Not even the "dimmable" CFLs work in our dimming touch lamps otherwise we'd be using them there, too.
I've tried both CFLs and LED lights in my dimming touch lamp. IIRC, both technically "worked", but I couldn't stand the high pitch squeal, so I went back to an incandescent after all of about thirty seconds of that torture.
I guess if I had killed my high frequency hearing by listening to lots of rock concerts as a kid, I'd love LED and CFL lighting, but until somebody starts building devices that switch at a couple hundred kHz instead of twenty or thirty, I'll stick with my inkies.
No, it's not the same thing-- and in fact the rule has spurred the creation of several brands of incandescents that *do* meet the new efficiency standards.
I'm assuming you mean their "Halogena" line of halogen bulbs. Halogens are certainly easier on my eyes than CFLs, and pedantically, they are incandescent bulbs. That said, it's a little disingenuous to call them incandescent without the halogen qualifier. They produce a significantly different light spectrum than what most people think of as incandescent bulbs.
I'm not aware of any non-halogen incandescent bulbs that meet the standards. I'd love to be proven wrong on that point, but I'm not holding my breath.
I would never want a halogen bulb in my bedside table lamp for the same reason that I can't deal with any of the CFLs I've tried there: the spectrum wakes me up, which is the last thing I want when I'm relaxing and reading a book or watching TV before I crash for the night.
No, both measures really aren't needed. The paltry 1% of additional power consumption that we would save with a complete ban on incandescent bulbs really isn't worth the inconvenience. An outright and immediate ban would basically do nothing more than make 2011 power consumption level with 2010, and then we'd be right back to the same rate of growth.
Funny how the same people bitching about this gov't 'overreach' into bulbs are also against gov't regulation of CO2 emissions. Very convenient for them.
No, I'm actually strongly in favor of regulation of CO2 emissions. I'm strongly against ineffectual regulations, particularly when they have a very direct impact on what I am allowed to do in the privacy of my own home.
Besides, even if we eliminated incandescent bulbs completely, we would not take even a single coal-burning power plant offline. Why? Because coal is cheaper than just about any other means of producing power. If we reduce power use, they'll cut production from higher-cost, cleaner power sources, not coal.
Slashdot Mirror
If your filesystem checker does that, it is very, very broken. No fsck tool should ever look inside an existing file for filesystem metadata. A filesystem checker should be collecting its free block list or bitmap as it reads the existing metadata so that it can check that later. Once you have that free block list you now know which blocks might potentially contain filesystem metadata legitimately. Then, you check only the blocks that are not already in use for something else.
Now a deleted disk image, perhaps, but even then, only if you explicitly pass flags to the filesystem checker to tell it to reattach "lost" inodes that haven't been marked as deleted. Even then, the problem can be solved by adding a UUID to each inode and ignoring things that look like inodes if the UUID doesn't match.
For that matter, even without a UUID, and even in the case where the filesystem metadata is severely damaged and you're reconstructing large parts of it from scratch by scavenging blocks, you should never have a situation where an inode appears inside the block range for another file. If you have an embedded disk image, you should be able to programmatically determine which inodes are real and which ones are inside an image by scanning for directory blocks first.
A directory block on a disk image will mostly point to inodes that aren't actually at those physical blocks because the block numbers are logical offsets into a file instead of being relative to the start of the partition. A directory block that's real will point almost if not entirely at real inodes. Then, when you see an inode that looks like it is part of another file, you see whether it was referenced from a directory block that looks real. If not, you assume that the inode isn't real, either.
BTW, the problem of filesystem nesting is fixed in Reiserfs V4, and is a pretty good reason to not use V3.
That's mostly correct, but incomplete. The TRIM command marks a range of logical flash pages as unused, but it's not correct to say that pages are not wiped except when a TRIM occurs. When the flash controller needs to write a new copy of a flash page, it may leave around an older copy of that page. Those older copies of the pages may later be wiped on an as-time-permits basis by the flash controller without intervention by the OS even if the flash page never sees a TRIM call.
I'm not suggesting not doing anything. I'm merely saying that there are much, much, much better ways to get us off coal than feel-good conservation bullshit. Want to get power companies to move off coal? Tax coal and provide tax incentives for building cleaner energy power plants. Make it cheaper to use something else.
As long as coal is cheaper, nothing we do (unless we can cut more than half our power usage, which quite frankly is a pipe dream) will have a significant impact.
And even if it does have some small impact, in the long term, the ban is harmful because people experience personal discomfort that they they directly associate with the "green" movement. By contrast, taxes on coal that are used to provide tax incentives for building green power have a much smaller, much less directly observable impact on the average person.
BTW, I don't have to justify being wasteful. I'm already paying several times as much per kWh as the average American in exchange for most of my power coming from green energy sources (not entirely by choice, mind you, but I'm doing it), and my next house will be 100% solar (because I'm fed up with paying way more than I should be, even for green power). If I want to waste power, as far as I'm concerned, I'm entitled to do so.
Nobody said it was. It does not, however, to my knowledge, ship with things turned on that are more insecure than an emo kid.
In principle, no. In practice, the average computer user has never heard of AutoRun, much less TweakUI. That's why the default state must have at least a certain minimum level of security or you're screwed.
I don't think you realize just how little the average computer user knows about how computers work. A sizable percentage of Windows users don't know how to install software at all, relying only on the software that came preinstalled from Best Buy. Thus, even the act of downloading and installing TweakUI is beyond them....
So yeah. It's way beyond a significant percentage of Windows users. Way, way beyond.
It is closed source. The fact that source code has been shown to specific third parties under nondisclosure does nothing to change that fact. I'd be surprised if any closed source piece of software exists that has not at some point been similarly made available to at least one third party under NDA. That's not the same thing as Open Source, in which the source code is out there with public change logs and bug tracking such that almost every single security bug is disclosed to the entire world the moment it is discovered.
Which are completely beyond the average Windows user. As far as I'm concerned, an OS is only as secure as it is in the default configuration. If, as installed, an OS has a hole so big you can drive a truck through it, the fact that they provide mortar and a bunch of bricks so that you can patch the hole yourself doesn't really change anything. By that standard, a ten-year-old Linux distro has no security holes because you can recompile BIND, Apache, OpenSSL, etc. yourself. It's a ludicrous argument.
Most of the wannabes do, sure. They rely on people not patching their machines for long periods of time. The people who created those exploits in the first place, however, don't generally sit around trolling the list of patched vulnerabilities. By the time there's a patch out there, the bulk of the potential targets are going to be protected before they can roll an attack, leaving only a small percentage of stragglers. For maximum impact, the serious hackers are exploiting zero-day holes.
My thoughts are that the facts you give do not prove what you think they do.
Also, the articles you are pointing to this time are pretty much harping about ASLR differences. While ASLR is nice and all, that's only one very small aspect of total OS security, and one that is no more or less important than sandboxing, privilege separation, etc. No OS is the best at every aspect of security.
These links are basically tantamount to saying that a Ferrari is better than a Porsche because the cupholders are nicer. While one or the other might be better, it should be obvious to anyone with a modicum of common sense that using one minor feature as the sole basis for comparison is sheer foolishness.
Irrelevant to my point, which was that the source is not out in the open and therefore the known vulnerabilities for that source are likewise not out in the open. Therefore, the odds of any single security bug in Mac OS X getting pointed out publicly are much greater than the odds for a similar bug in Windows simply because the disclosure is much more likely to occur in a public forum or through a publicly visible commit log.
The fact remains that you don't know how many internally known vulnerabilities there are in Windows because you don't have access to Microsoft's internal bug tracking system. Similarly, you don't know how many vulnerabilities there are in the closed source portions of Mac OS X, but you do know how many have been discovered in the open source portions because those bugs are reported out in the open.
Therefore, the fact that Mac OS X contains lots of open source means that you would expect the number of publicly known bugs to be much higher even if the total number of internally known bugs is comparable or lower. In effect, this means that the number of publicly known vulnerabilities is completely useless as a metric of software quality because it has no real relationship to the number of exploitable bugs.
More to the point, the crackers usually already know about the bugs whether they're discussed publicly (as with open source bugs and announcements by legitimate security researchers) or not. The disclosed vulnerabilities, therefore, are largely uninteresting. What matters is the total number of vulnerabilities known to the bad guys, which as I explained above, is not strongly correlated with the number of vulnerabilities known to the general public.
Read what the Microsoft bulletin said again. It says AutoRun is still in full force, but only for optical media. Although that does diminish the impact (by preventing people from unknowingly spreading malware by moving flash drives from machine to machine), the fundamental vulnerability is very much still present. Malware producers can still infect a CD manufacturing plant with malware and cause millions of discs from multiple manufacturers to infect Windows boxes on insertion. This is not a theoretical vulnerability, either; people have actually gotten infections from commercial software discs in the past. So they might have put a lock on the front door with that change, but they still left the window right next to it completely ajar with a footstool below it for your convenience.
No. That should generally look like a single, continuous stream from the head end at your cable company. Your machine sends back-channel messages to the head end to indicate that a channel change should occur, and it sends down a different stream. There's really no good reason to disconnect and reconnect when changing channels; doing so would constitute a rather serious abuse of the network due to all the overhead of setting up and tearing down an isochronous transport stream.
Now if by "changing channels" you mean rapidly switching between separate streams from content sources on the Internet, then yes, but on the other hand, most streaming videos are almost invariably not being transmitted live, and thus have no need to be isochronous in the first place. (The only reason to send data isochronously is if you cannot buffer forwards in time arbitrarily far to compensate for network congestion. Otherwise, you should be sending data in bulk. YouTube, for example, should be sending all of its data as bulk data.) As such, again, using isoch connections in that way would constitute abuse.
In short, you might be able to come up with a few edge case exceptions, but you'd have to try pretty hard. In general, isoch connections should be used for live streams from special events, video chat, VoIP, and a single isoch connection to the head end for anything that resembles IPTV. Chances are, anything that falls very far at all outside those bounds would constitute abuse of the standard.
No, I do get it. In such situations, the user had to deliberately install something. You're missing a critical difference between Mac OS X and Windows, though.
Unlike in Windows, where security dialogs pop up for mundane things, Mac OS X's security model only pops up those dialog boxes when you're doing something that you should legitimately be cautious about. Mac users are trained to be wary when they see those boxes.
It is this fundamental difference that distinguishes Mac OS X from Windows, and makes such social engineering attacks significantly less likely. Also, warnings in Mac OS X make it far more obvious if you've accidentally clicked on an application that has been hacked to look like a document, which further improves security in this regard.
Uh... you do realize that the only reason most known vulnerabilities for Mac OS X are "known" is because they are in Open Source bits, right? And that basically none of Windows is Open Source? This means that the number of known unpatched vulnerabilities in Windows should inherently be smaller, not because there are fewer unpatched vulnerabilities, but because its source code has not undergone the same level of external scrutiny.
Also, most of the things on your list are not vulnerabilities, and the few that were are almost all reports about Apple having fixed those vulnerabilities. The only one I saw that did not fall into that category was a DNS cache poisoning bug. Besides being difficult to exploit usefully, it applies to a DNS server daemon that doesn't even run in Mac OS X unless you explicitly enable the name server by editing config files (or in the GUI in Mac OS X Server).
Not all vulnerabilities are created equal. That's what makes comparisons of vulnerability counts useless. As long as Windows supports AutoRun in any form, it will continue to be so far behind Mac OS X that it isn't really even in the race just from that one fundamental design flaw alone.
For some time, Mac OS X has required that any software that wants to attach to any device that identifies itself as a keyboard (including some presenter remotes, much to my chagrin) be running as root. Because of this design decision, in order to install a keylogger without the user typing his or her admin password, you would have to not only attack an arbitrary application and gain the ability to run code on the user's machine, but also either find an additional vulnerability in one of only a handful of daemons that run as root or find a kernel exploit that allows you to gain root privileges.
In effect, although you could make a Mac OS X trojan or virus that installs a keylogger, it would be exceedingly difficult to do so without the user doing something careless.
Sure it will. You simply cap the customer at the bandwidth he/she is paying for and do QoS within the customer's allocation. Then you don't oversell the bandwidth. :-) Yeah, right. That'll happen.
Alternatively (and more realistically), you design things such that high priority packets must be sent isochronously (that is, every nth time slot) plus or minus a little jitter. A video codec will have no problem delivering frames at a constant data rate. Random bulk communications will not be able to do so, and those sockets will, after some threshold for maximum failures is exceeded, be automatically de-prioritized down to the level of bulk traffic.
You further penalize the endpoint by cutting it down to 56k modem speeds for a month if you see it making too many short-lived (<5s) connections to multiple IPs and declaring them isoch. By definition, any such connections are an abuse of the standard.
That should cover about 95% of the likely abuses.
The problem is that you can't. Well, you can produce halogen bulbs, but that's still a somewhat different animal than traditional incandescent bulbs. They burn hotter and brighter, with a higher color temperature. They are unsuitable for enclosed fixtures, and the light produced is substantially different.
More significantly, I'm not positive about this, but I think that any incandescent bulb you could create that would meet those efficiency standards, by definition, would behave more like a halogen bulb (brighter, hotter) than traditional incandescent bulbs. By the very nature of resistive power production, it is not possible to meet those efficiency standards and still produce comparable light.
Well, you might be able to still meet them with a halogen bulb and a dimmer, but then your bulb's life expectancy is reduced, and depending on how you design your dimmer, there's a pretty good chance that the whole system would still not meet the efficiency standards even though the bulb itself would. If you want to do it inside the bulb itself, that poses a problem. Linear regulators are right out, so basically you'd be getting into the fairly pricey PWM designs. At twenty or thirty dollars a bulb, it ceases to be economically viable.
So like it or not, in effect, this efficiency standard is a ban on a lighting technology that a fair number of people strongly prefer over the alternatives. Nobody is stepping up to provide non-halogen incandescent bulbs that meet the standards. It's not at all like CFCs where everybody switched to something else and the consumer didn't really notice the change, not because companies wouldn't like the transition to be invisible to consumers, but because that just plain isn't feasible. And that was the point I was trying to make.
Maybe some people can sleep in a house that's fifty degrees, but I can't. To be fair, part of this is an unfortunate side effect of newer, high efficiency, reflective roofing that the government mandates (resulting in increased energy bills most of the year instead of the decrease that the government claimed).
Okay, so they don't cut back on nuke plants, but instead cut back on construction of solar power stations. Either way, the net impact on coal-based power is the same, and it is zero. Every means of producing power is more expensive than coal.
The only time conserving energy could realistically reduce emissions would be during peak hours when they turn on natural-gas-based peaker plants. However, that's mostly in the afternoon, when the vast majority of people are at work or are coming home from work, and thus are not using much lighting at home. So with the exception of people who work at home or are unemployed, moving from incandescent bulbs to CFLs won't help there, either.
Supply and demand only affects prices in a free market, or at least something that approaches it.
Electricity, from the consumer's point of view, is a highly regulated and completely captive market. In general, the public has no choice in power providers beyond "the power company" unless they are willing to invest in power generation hardware themselves.
Further, the prices are generally capped by public utilities commissions. This means that increased demand, by law, cannot cause an increase in price. To make up for this, unlike with free market commodities, the power companies charge folks who use larger amounts of power more per unit because of the increased cost of buying power from more expensive sources.
It's not an economic theory. It's a basic fact of the way things work due to the severely regulated nature of the "market". As long as prices are regulated and as long as supply substantially outstrips demand as it does currently, demand can have no significant effect on retail power pricing.
Are the lumens the same at a given color temperature for halogens?
Although interesting, I would argue that they probably haven't had much impact on CO2 levels unless it's in developing countries. I'd expect most coal plants to run full tilt most of the time because they are cheap to operate. And new coal plants are being added more slowly than old ones are phased out, I think (at least in the U.S.). Thus, any increased load (at least averaged over the long term) would tend to come primarily from increasing the output of more expensive (but cleaner) sources like nuclear power.
Kay's law (from Men In Black): A person is smart. People are dumb, panicky dangerous animals and you know it.
Sorry, but that's not a fact. That's at best a fantasy, and at worst an outright lie. Even if we removed every incandescent bulb in the U.S. with a CFL, we would have exactly zero impact on emissions. Why? Because your power company can save a lot more money on their energy bill by reducing nuclear plant output by a few megawatts than by reducing coal-based power production by the same amount.
Repeat after me: no matter how much power I cut, I am not saving the planet.
No, not really. As you use more power, you are causing more power to be produced from more expensive energy sources, true, but your power rate is tiered accordingly, which means that your impact on your neighbor is essentially zero.
The only time you might be able to argue that increased consumption costs other people money would be when your power usage puts the grid over capacity and requires running additional feeder lines to your city. Realistically, though, the ~1% savings you would get by switching every house from incandescents to CFLs won't make a big enough dent to be measurable in that regard when compared with serious power consumers such as manufacturing plants or even household air conditioning.
I've tried both CFLs and LED lights in my dimming touch lamp. IIRC, both technically "worked", but I couldn't stand the high pitch squeal, so I went back to an incandescent after all of about thirty seconds of that torture.
I guess if I had killed my high frequency hearing by listening to lots of rock concerts as a kid, I'd love LED and CFL lighting, but until somebody starts building devices that switch at a couple hundred kHz instead of twenty or thirty, I'll stick with my inkies.
I'm assuming you mean their "Halogena" line of halogen bulbs. Halogens are certainly easier on my eyes than CFLs, and pedantically, they are incandescent bulbs. That said, it's a little disingenuous to call them incandescent without the halogen qualifier. They produce a significantly different light spectrum than what most people think of as incandescent bulbs.
I'm not aware of any non-halogen incandescent bulbs that meet the standards. I'd love to be proven wrong on that point, but I'm not holding my breath.
I would never want a halogen bulb in my bedside table lamp for the same reason that I can't deal with any of the CFLs I've tried there: the spectrum wakes me up, which is the last thing I want when I'm relaxing and reading a book or watching TV before I crash for the night.
No, both measures really aren't needed. The paltry 1% of additional power consumption that we would save with a complete ban on incandescent bulbs really isn't worth the inconvenience. An outright and immediate ban would basically do nothing more than make 2011 power consumption level with 2010, and then we'd be right back to the same rate of growth.
No, I'm actually strongly in favor of regulation of CO2 emissions. I'm strongly against ineffectual regulations, particularly when they have a very direct impact on what I am allowed to do in the privacy of my own home.
Besides, even if we eliminated incandescent bulbs completely, we would not take even a single coal-burning power plant offline. Why? Because coal is cheaper than just about any other means of producing power. If we reduce power use, they'll cut production from higher-cost, cleaner power sources, not coal.
You kidding? I'm in northern California. I run heat nine months out of the year or more.