If your computer is sending me spam, it's killing me by taking away, say, one second of otherwise useful life. It's doing that millions of times a day. If we total those seconds up, you've killed several people and you're still not liable for anything.
The typical fortune 500 company or large government organization realized long ago that keeping people on staff to tinker with hardware failure on a PC is not cost effective, and keeping systems longer that three or four years is not cost effective. This is increasingly true over time as the devices have fewer and fewer parts which can be serviced. I saw a calculation at one of my clients which demonstrated that it was actually cheaper for them to keep a spare laptop at every site (hundreds of sites) than it was to try to fix broken laptops in-house.
Think about it. Do they keep people on staff to fix telephone handsets? Microwave ovens in the break areas? Lights? Vacuum cleaners?
No, no, no, and no.
Fixing this problem in your organization is already on your CFO's "to do" list. Tell your PC fixers to start retraining now.
The typical large enterprise doesn't service laptops of any kind today. They buy the unit with support that spans the life of the machine. If it breaks, they call an 800 number, wait for a box, put the dead unit in the box, ship it off to be fixed and wait for the return. When the support contract expires, they retire the unit and buy a new one.
If you're giving the routing number and account number of your checking account to 3rd parites to make payments over the web then you're not treating the data as though it were confidential. Now, in addition to any employee at your bank, any random person at the company of the 3rd party has access to this information. They could rack these things up for a year and then sell them on the internet. Or maybe their web server gets hit by a worm which steals all these numbers along with credit card numbers.
I like your analysis that this is a cryptosystem with the "routing + account" number standing in for both the public and private key. A proper crypto system would allow you to pay someone with some information and a public key, perhaps with a one-time use bit of some sort. This would prevent funds-extraction by 3rd parties (who bought your information on the internet after you paid the first 3rd party for something) because the information couldn't be used to extract money from your account without a new one-time thingy. Meanwhile, never provide your "routing + account" number to anyone (except your employer for auto-deposit... life is all about risk-reward trade-off). Instead, use credit cards to pay third parties so you have better consumer protection against fraud.
However, it's not completely clear that the problem in the original post would be solved by such a system without disrupting the "business process" that the customers probably think they need. An obvious approach would be something like a PKI system with a little card that generated a one-time tidbit on the fly, which the customer would provide to 3rd parties to authorize a payment, and presumably to a banker to authorize a fund transfer or wire or whatever over the phone. The bank's customers may view this as inconvenient and may switch to another bank (the key generator is yet another thing they need to carry around and keep physically secure). After all, the customers clearly want to be able to make a phone call and talk to a person to perform a transaction. In any case, the bank managers will fear this customer response.
Under the existing system, the bank employees are trusted and the customer will need to detect the missing funds and report them to the bank. Many other bank employees (any teller, any banker, any computer operator) already have access to the same sensitive information as is written to paper and placed in the drawer, which is why the bank managers are not really concerned about the drawer. They know, but perhaps haven't completely thought through that the funds will have been transferred to another account somewhere, and that will be traceable. The funds may not be recoverable but the money trail could be followed from account to account to the perpetraitor... right up to the point where the bank manager and the FBI agents are watching a grainy video of somebody in a wig and fake nose-mustache-glasses pull up to a drive through window in a car that was purchased with cash and uh, donated to a rural fire department for, uh, practice extinguishing gasoline fires shortly thereafter, close their account, and drive off with the cash.
You received daily updates only if you were able to use the "Symantec enterprise console" system to obtain and distribute the updates. Symantec had 3 different update paths at that time, LiveUpdate was the original "enterprise" update system which used FTP as a transport and a special "Live Update Administrator" software to fetch from Symantec. The "enterprise console" system used a different mechanism and a "push" transport from the console server to the clients. (Incidentally, I think it is this built in distribution and control system which provided the hole for the worm which spawned this article. The "unmanaged" client configuration didn't have a listener on the client and thus couldn't be exploited that way.) The third mechanism were downloadable update bundles available from the web. Those were updated weekly in concert with Live Update, and occasionally on an ad-hoc basis. There are many, many more details that I could provide, but really, you can't possibly care this much. It was a cluster fsck, the Symantec update situation, for years, and was still a cluster fsck as of the fall of 2005.
Pining for the fjords, eh? Serious security professsionals realized this argument was stone cold (in fact I took the liberty of examinging this here argument and discovered that the only reason it was still standing on its perch at all was that it had been nailed there) dead when the Witty Worm smacked all the vulnerable systems for a given defect within an hour. The particular realization perhaps didn't sink in until a day or so later when the number of said vulnerable systems was shown to be something quite small, quite possibly as few as 12,000 total vulnerable systems. Exploiting niche platforms became no more difficult than exploting any other platform given a remote root vulnerability.
Elsewhere in this discussion it's claimed that worms are irrelevant because modern attacks are directed at browsers and the like. The continual emergence of new worms suggests that malware authors do not agree with that assessment. Even if it were true, recent surveys suggest that over 4% of web surfers are using Safari. That's millions of potential victims. A botnet master needs only a few thousand systems to spam the bejeezus out of the entire world.
The niche platform argument is bogus and should be consigned to the dustbin of history.
Although other AntiVirus vendors provided daily udpates for years, Symantec released updates via Live Update once a week for many many years, and apparantly began more frequent, almost daily updates in 2006. I know (from experience) that as recently as the fall of 2005 Symantec updates were delivered weekly. I used to *beg* on behalf of my client (and via Symantec's expensive enterprise support contract of questionable value) for Symantec to produce more frequent updates. I still have scars on my knees and lips from the chaffing. I'm here as a survivor to tell you they did *not* deliver daily updates via Live Update until relatively recently.
During major outbreaks a mid-week update or two would sometimes become available. Those were sometimes delivered at the request of their enterprise customers (e.g. "We're seeing a rise in foo infections, could you please consider releasing the definition update for that ASAP?") but were made available through all their distribution channels to all their customers.
On occasion Symantec would release a particular definition via consumer channels on an ad-hoc basis (e.g. between the regular weekly udpates) but only via the enterprise-focused "Live Update" system several days later during the regular update. When I asked them about this (each time we noticed) the reason given was that the definition "needed additional testing" before it could be certified for enterprise use. Presumably this was to reduce the number of false positives which when they occur in an enterprise environment can be almost as costly as an actual virus outbreak.
One of my clients has a relatively large Symantec AntiVirus deployment (something like 35,000 Windows PCs). I was, among many other things, directly and soley responsible for their Symantec AntiVirus architecture for several years. I assure you that there are many issues which can be easily overcome at the scale of 300 machines which are pretty close to show stoppers at the 30,000 node scale. I agree that Symantec Enterprise Edition is a reasonable AntiVirus product, but its weakest link, ironically enough, are the issues that arise when trying to deploy, operate, and maintain it at the scale of a real enterprise.
It appears that Symantec has finally begun moving to daily updates. Information about their Live Update system indicates that for their 2006 home user product daily updates were available. Users of prior versions of the product receive only weekly updates. They have been under tremendous pressure from customers to make daily updates available for several years. I'm glad to see them finally moving that direction.
Yours is a frightfully humorless post from somebody who has "It's funny. Laugh." in their sig. Is your blood-caffeine level at a critially low level? Did your barista spike your latte with decaf?
Apple is probably aware that many people don't buy from iTunes Music Store because they don't want DRM-crippled music. Perhaps they are sitting on market research which indicates that *more* people would buy from iTunes Music Store were it not for DRM. (If you're like me, and I know I am, you buy music on a CD and rip it to your iTunes player then sync it to your iPod. DRM-free.)
The open source browsers should all band together and support standards-compliant web sites only. Any quirks related to historical IE or Netscape bugs that are supported should yield whatever remnants of the web site can be displayed, but only after the user accepts the risks as explained by a big flashing warning banner:
The web site you are trying to view is not compliant with web standards. This may be:
part of a grand conspiracy by the creators of this web page and others to force you to switch to a monopoly-controlled computing platform,
simply an indication of their ignorance, or
an attempt by the creators of this web page, their advertising partners, or some random cracker to exploit a security defect and turn your system into a password, identity and bank account stealing botnet daemon of spamming death.
Do you really want to load this broken and possibly malicious web page?
Yeah, I've seen the flash leak, too. Normally, however, this leak doesn't account for the "hundreds of MB" in the original post. The large VM size of Safari is typically an artifact of the cache. I suppose it might get to a size like that under some unusual circumstances.
The claim is factually incorrect, not merely "broad". It is not a "concise" claim because it employs terms incorrectly. My reply provides a technically correct framework for analyzing the question, "how XNU might be considered a BSD kernel" and carefully explains in detail why "how the kernel might not be the deciding factor in whether OS X is BSD" is a question which lacks meaning because it employs a definition of "kernel" which is incorrect.
There are several BSD servers, and Mac OS X provides one of them. It is compatible with the APIs known collectively as "BSD". That's what it is. That's not simply true because it's what Apple says, it's true because there is an objective measure, known as the BSD API which is provided by Mac OS X. Even if Apple never actually used the words UNIX and BSD anywhere, ever, Mac OS X would still be a UNIX in the family of BSD because that's what it is.
I can't respond to "Perhaps you think that the operating system is more important than the kernel" because I don't know what that means. I will, however, try to explain *why* I think that phrase *has no meaning* and neither does the original "claim".
Well, that doesn't sum it up, really. There isn't even much to attack, because it's a baseless assertion which employs incorrect terminology. Somebody who has no clue is spouting buzz words. I can't attack the claim, because there isn't any there there. Know what I mean? I am attacking, if anything, the dogmatic approach to a technical discussion.
Assuming for the moment there is a little tiny bit of there there, let's look at it closer. Which BSD kernel is your golden standard, then? Pick one, I don't really care. How about SunOS 4.3. (SunOS was considered the pinnacle of BSD by a lot of people for a lot of years, and it doesn't even have BSD in the name! ) Next, take a peek at some other systems people "claim" to be BSD, peek at their I/O architectures, their command line interfaces, their device driver architectures, their virtual memory managers, their process schedulers and... what do you know! Major differences! Entirely different code! Entirely different algorithms! Entirely different architectures with different abstractions! By what appears to be your "BSD truthiness yardstick", NetBSD, FreeBSD, OpenBSD, or any other system you want to look at isn't running a "BSD kernel" any more than is Mac OS X/Darwin.
jcr made the claim that when you are using Mac OS X you are using a BSD server. This is reasonable, correct, and dare I say even obvious to those familiar with the usage of the term "server" as in "BSD server" which is the abstract component of the operating system, often but not necessarily compiled into the kernel, which provides the BSD API to the applications.
This is not a religious issue, nor is it dogma, it's objective (although admittedly non-trivial) fact. It becomes a religious issue only for people who don't take the time to understand the various ways in which the overloaded term "server" is used in a given context, nor grasp the many layers of abstraction in a modern operating system nor the fact that they can be combined in various ways to make an operating system--of which the "kernel" is simply one part.
(Incidentally, this type of conflict might seem familiar. Religious dogmatics on one side, rationalists coming from many different religious and even non-religious backgrounds on the other. Ring any bells? If you guessed "Al Queda" vs. "The West" aka "America and the democratic nations of the free world, oh, and Saudi Arabia" aka "The Great Satan", you get a free beer. If you also named "Dominionists" or "American Fascists" vs. "Liberal Free Thinkers (be they Democratic, Republican, Green or Independent)" you get extra credit. I'm intrigued by the ease with which dogma gets tossed around in debates among geeks on slashdot about things w
Mac OS X Server does not restrict the number of clients for most of the traditional UNIX services, rather, it restricts only the filesharing service. The licensing terms listed in the parent simply don't apply in most situations. In fact, the Mac OS X *client* operating system is fully able to provide many of the same traditional UNIX services as Mac OS X Server, also without limitations.
Mac OS X Server is available in 10-client and unlimited-client editions to meet the needs of your organization. Client restrictions apply only to simultaneous file sharing services for Mac and PC clients.
A better indicator than corporate profitability for this question might be profit per worker bee and it might tell you more about how competitive a given market is, or if a company has a monopoly or oligopoly position in its market, than about the potential profitability of the given market. Finding and analyzing actual statistics is left as an exercise.
Hmm... read more than the table of contents. Apple *demonstrated a functioning product to the world*. Apple only made claims about things that *were demonstrated to work*. If you have overinflated expectations based on things *Apple never claimed* then that sounds like you have a bit of drain bammage. I typically don't try to engage crazy people in conversation. (Life is too short.) Bye bye!
Slashdot Mirror
If your computer is sending me spam, it's killing me by taking away, say, one second of otherwise useful life. It's doing that millions of times a day. If we total those seconds up, you've killed several people and you're still not liable for anything.
The typical fortune 500 company or large government organization realized long ago that keeping people on staff to tinker with hardware failure on a PC is not cost effective, and keeping systems longer that three or four years is not cost effective. This is increasingly true over time as the devices have fewer and fewer parts which can be serviced. I saw a calculation at one of my clients which demonstrated that it was actually cheaper for them to keep a spare laptop at every site (hundreds of sites) than it was to try to fix broken laptops in-house.
Think about it. Do they keep people on staff to fix telephone handsets? Microwave ovens in the break areas? Lights? Vacuum cleaners?
No, no, no, and no.
Fixing this problem in your organization is already on your CFO's "to do" list. Tell your PC fixers to start retraining now.
The typical large enterprise doesn't service laptops of any kind today. They buy the unit with support that spans the life of the machine. If it breaks, they call an 800 number, wait for a box, put the dead unit in the box, ship it off to be fixed and wait for the return. When the support contract expires, they retire the unit and buy a new one.
If you're giving the routing number and account number of your checking account to 3rd parites to make payments over the web then you're not treating the data as though it were confidential. Now, in addition to any employee at your bank, any random person at the company of the 3rd party has access to this information. They could rack these things up for a year and then sell them on the internet. Or maybe their web server gets hit by a worm which steals all these numbers along with credit card numbers.
I like your analysis that this is a cryptosystem with the "routing + account" number standing in for both the public and private key. A proper crypto system would allow you to pay someone with some information and a public key, perhaps with a one-time use bit of some sort. This would prevent funds-extraction by 3rd parties (who bought your information on the internet after you paid the first 3rd party for something) because the information couldn't be used to extract money from your account without a new one-time thingy. Meanwhile, never provide your "routing + account" number to anyone (except your employer for auto-deposit... life is all about risk-reward trade-off). Instead, use credit cards to pay third parties so you have better consumer protection against fraud.
However, it's not completely clear that the problem in the original post would be solved by such a system without disrupting the "business process" that the customers probably think they need. An obvious approach would be something like a PKI system with a little card that generated a one-time tidbit on the fly, which the customer would provide to 3rd parties to authorize a payment, and presumably to a banker to authorize a fund transfer or wire or whatever over the phone. The bank's customers may view this as inconvenient and may switch to another bank (the key generator is yet another thing they need to carry around and keep physically secure). After all, the customers clearly want to be able to make a phone call and talk to a person to perform a transaction. In any case, the bank managers will fear this customer response.
Under the existing system, the bank employees are trusted and the customer will need to detect the missing funds and report them to the bank. Many other bank employees (any teller, any banker, any computer operator) already have access to the same sensitive information as is written to paper and placed in the drawer, which is why the bank managers are not really concerned about the drawer. They know, but perhaps haven't completely thought through that the funds will have been transferred to another account somewhere, and that will be traceable. The funds may not be recoverable but the money trail could be followed from account to account to the perpetraitor... right up to the point where the bank manager and the FBI agents are watching a grainy video of somebody in a wig and fake nose-mustache-glasses pull up to a drive through window in a car that was purchased with cash and uh, donated to a rural fire department for, uh, practice extinguishing gasoline fires shortly thereafter, close their account, and drive off with the cash.
You received daily updates only if you were able to use the "Symantec enterprise console" system to obtain and distribute the updates. Symantec had 3 different update paths at that time, LiveUpdate was the original "enterprise" update system which used FTP as a transport and a special "Live Update Administrator" software to fetch from Symantec. The "enterprise console" system used a different mechanism and a "push" transport from the console server to the clients. (Incidentally, I think it is this built in distribution and control system which provided the hole for the worm which spawned this article. The "unmanaged" client configuration didn't have a listener on the client and thus couldn't be exploited that way.) The third mechanism were downloadable update bundles available from the web. Those were updated weekly in concert with Live Update, and occasionally on an ad-hoc basis. There are many, many more details that I could provide, but really, you can't possibly care this much. It was a cluster fsck, the Symantec update situation, for years, and was still a cluster fsck as of the fall of 2005.
Pining for the fjords, eh? Serious security professsionals realized this argument was stone cold (in fact I took the liberty of examinging this here argument and discovered that the only reason it was still standing on its perch at all was that it had been nailed there) dead when the Witty Worm smacked all the vulnerable systems for a given defect within an hour. The particular realization perhaps didn't sink in until a day or so later when the number of said vulnerable systems was shown to be something quite small, quite possibly as few as 12,000 total vulnerable systems. Exploiting niche platforms became no more difficult than exploting any other platform given a remote root vulnerability.
Elsewhere in this discussion it's claimed that worms are irrelevant because modern attacks are directed at browsers and the like. The continual emergence of new worms suggests that malware authors do not agree with that assessment. Even if it were true, recent surveys suggest that over 4% of web surfers are using Safari. That's millions of potential victims. A botnet master needs only a few thousand systems to spam the bejeezus out of the entire world.
The niche platform argument is bogus and should be consigned to the dustbin of history.
Although other AntiVirus vendors provided daily udpates for years, Symantec released updates via Live Update once a week for many many years, and apparantly began more frequent, almost daily updates in 2006. I know (from experience) that as recently as the fall of 2005 Symantec updates were delivered weekly. I used to *beg* on behalf of my client (and via Symantec's expensive enterprise support contract of questionable value) for Symantec to produce more frequent updates. I still have scars on my knees and lips from the chaffing. I'm here as a survivor to tell you they did *not* deliver daily updates via Live Update until relatively recently.
During major outbreaks a mid-week update or two would sometimes become available. Those were sometimes delivered at the request of their enterprise customers (e.g. "We're seeing a rise in foo infections, could you please consider releasing the definition update for that ASAP?") but were made available through all their distribution channels to all their customers.
On occasion Symantec would release a particular definition via consumer channels on an ad-hoc basis (e.g. between the regular weekly udpates) but only via the enterprise-focused "Live Update" system several days later during the regular update. When I asked them about this (each time we noticed) the reason given was that the definition "needed additional testing" before it could be certified for enterprise use. Presumably this was to reduce the number of false positives which when they occur in an enterprise environment can be almost as costly as an actual virus outbreak.
One of my clients has a relatively large Symantec AntiVirus deployment (something like 35,000 Windows PCs). I was, among many other things, directly and soley responsible for their Symantec AntiVirus architecture for several years. I assure you that there are many issues which can be easily overcome at the scale of 300 machines which are pretty close to show stoppers at the 30,000 node scale. I agree that Symantec Enterprise Edition is a reasonable AntiVirus product, but its weakest link, ironically enough, are the issues that arise when trying to deploy, operate, and maintain it at the scale of a real enterprise.
It appears that Symantec has finally begun moving to daily updates. Information about their Live Update system indicates that for their 2006 home user product daily updates were available. Users of prior versions of the product receive only weekly updates. They have been under tremendous pressure from customers to make daily updates available for several years. I'm glad to see them finally moving that direction.
Symantec typically releases new definitions once a week. You an fetch them as often as you like, though.
Yours is a frightfully humorless post from somebody who has "It's funny. Laugh." in their sig. Is your blood-caffeine level at a critially low level? Did your barista spike your latte with decaf?
See the "Security" @ Get A Mac commercial as well as many of the hideous intersitial warnings that Microsoft Internet Explorer produces for reference.
Apple is probably aware that many people don't buy from iTunes Music Store because they don't want DRM-crippled music. Perhaps they are sitting on market research which indicates that *more* people would buy from iTunes Music Store were it not for DRM. (If you're like me, and I know I am, you buy music on a CD and rip it to your iTunes player then sync it to your iPod. DRM-free.)
The web site you are trying to view is not compliant with web standards. This may be:
- part of a grand conspiracy by the creators of this web page and others to force you to switch to a monopoly-controlled computing platform,
- simply an indication of their ignorance, or
- an attempt by the creators of this web page, their advertising partners, or some random cracker to exploit a security defect and turn your system into a password, identity and bank account stealing botnet daemon of spamming death.
Do you really want to load this broken and possibly malicious web page?[Cancel ] or [Allow ]
Yeah, I've seen the flash leak, too. Normally, however, this leak doesn't account for the "hundreds of MB" in the original post. The large VM size of Safari is typically an artifact of the cache. I suppose it might get to a size like that under some unusual circumstances.
You keep using this word, "quote." I do not think it means what you think it means.
Prepare to die.
I, uh, reproduced this problem yesterday. It's not patched yet. :-)
You keep using this word, leak. I do not think it means what you think it means. :-)
The claim is factually incorrect, not merely "broad". It is not a "concise" claim because it employs terms incorrectly. My reply provides a technically correct framework for analyzing the question, "how XNU might be considered a BSD kernel" and carefully explains in detail why "how the kernel might not be the deciding factor in whether OS X is BSD" is a question which lacks meaning because it employs a definition of "kernel" which is incorrect.
Read and understand or drop it. Your choice.
There are several BSD servers, and Mac OS X provides one of them. It is compatible with the APIs known collectively as "BSD". That's what it is. That's not simply true because it's what Apple says, it's true because there is an objective measure, known as the BSD API which is provided by Mac OS X. Even if Apple never actually used the words UNIX and BSD anywhere, ever, Mac OS X would still be a UNIX in the family of BSD because that's what it is.
I can't respond to "Perhaps you think that the operating system is more important than the kernel" because I don't know what that means. I will, however, try to explain *why* I think that phrase *has no meaning* and neither does the original "claim".
The discussion of the "correct assertion" you accuse me of "attacking" begins here, with a more correct assertion:
Sure, because anything you do on an OS X server, you are doing on a BSD server.
The post parent above that is about licensing.
The (vague) claim you refer to and suport is here:
Not really. An OS X server isn't running a BSD kernel. And, really, that sums it up.
Well, that doesn't sum it up, really. There isn't even much to attack, because it's a baseless assertion which employs incorrect terminology. Somebody who has no clue is spouting buzz words. I can't attack the claim, because there isn't any there there. Know what I mean? I am attacking, if anything, the dogmatic approach to a technical discussion.
Assuming for the moment there is a little tiny bit of there there, let's look at it closer. Which BSD kernel is your golden standard, then? Pick one, I don't really care. How about SunOS 4.3. (SunOS was considered the pinnacle of BSD by a lot of people for a lot of years, and it doesn't even have BSD in the name! ) Next, take a peek at some other systems people "claim" to be BSD, peek at their I/O architectures, their command line interfaces, their device driver architectures, their virtual memory managers, their process schedulers and... what do you know! Major differences! Entirely different code! Entirely different algorithms! Entirely different architectures with different abstractions! By what appears to be your "BSD truthiness yardstick", NetBSD, FreeBSD, OpenBSD, or any other system you want to look at isn't running a "BSD kernel" any more than is Mac OS X/Darwin.
jcr made the claim that when you are using Mac OS X you are using a BSD server. This is reasonable, correct, and dare I say even obvious to those familiar with the usage of the term "server" as in "BSD server" which is the abstract component of the operating system, often but not necessarily compiled into the kernel, which provides the BSD API to the applications.
This is not a religious issue, nor is it dogma, it's objective (although admittedly non-trivial) fact. It becomes a religious issue only for people who don't take the time to understand the various ways in which the overloaded term "server" is used in a given context, nor grasp the many layers of abstraction in a modern operating system nor the fact that they can be combined in various ways to make an operating system--of which the "kernel" is simply one part.
(Incidentally, this type of conflict might seem familiar. Religious dogmatics on one side, rationalists coming from many different religious and even non-religious backgrounds on the other. Ring any bells? If you guessed "Al Queda" vs. "The West" aka "America and the democratic nations of the free world, oh, and Saudi Arabia" aka "The Great Satan", you get a free beer. If you also named "Dominionists" or "American Fascists" vs. "Liberal Free Thinkers (be they Democratic, Republican, Green or Independent)" you get extra credit. I'm intrigued by the ease with which dogma gets tossed around in debates among geeks on slashdot about things w
Mac OS X Server
A better indicator than corporate profitability for this question might be profit per worker bee and it might tell you more about how competitive a given market is, or if a company has a monopoly or oligopoly position in its market, than about the potential profitability of the given market. Finding and analyzing actual statistics is left as an exercise.
Five seconds with Google would have spared you this lashing.
Mac OS X System Architecture
Architecture of Mac OS X
UNIX family tree
Please do try to keep up.
Hmm... read more than the table of contents. Apple *demonstrated a functioning product to the world*. Apple only made claims about things that *were demonstrated to work*. If you have overinflated expectations based on things *Apple never claimed* then that sounds like you have a bit of drain bammage. I typically don't try to engage crazy people in conversation. (Life is too short.) Bye bye!
You keep using that word, vaporware. I do not think it means what you think it means.
I have tried some modern CFL bulbs quite recently. They suck. I for one welcome our efficient incandencent patent holding overlords.