The thing is, disposable domains cost money. The reason spam is so profitable now is that they can send out millions of emails without paying a dime. When the second email from their domain to any given user causes the entire domain to get blocked for every user at that server, suddenly their effective cost of sending an advertisement jumps to about $5 per mailout (half the cost of a domain). At that price, the huge financial overhead causes spam to be unprofitable when compared with much cheaper advertising techniques like Google AdWords. Eliminate the funding source for spammers and you eliminate the spammers.
Oh, yes, that's right. We have to ban domain tasting. Then again, that should be obvious for many, many other reasons....
This applies even if spammers ignore the requirement for legit domain information. However, I think ICANN should tighten up the rules on domain registration. New registrants (and any registrants who have received spam complains against them) should have to provide proof of identity when registering their first domain name with a given registrar. There's simply no excuse for not requiring at least a minimal audit trail for registering a domain.
Yes, but if a domain like gmail or hotmail gets sufficiently lax at verifying legitimacy of people applying for accounts, they'll eventually find their traffic getting blocked at the router level.... To some degree, prevention of spam does require systems like that to require at least a little effort to apply for an account (sufficient to make auto-registration impractical).
And there are no words for how much the MWSF schedule sucks. When I realize how many employees at Apple, Adobe, Canon, and hundreds of other vendors are forced to skip Christmas vacation every year to get products and show displays ready for that horribly timed conference, it makes me want to shove my foot up IDG CEO Bob Carrigan's you-know-what. If the conference were in February, those employees would almost certainly be happier, plus it would likely cost those vendors a lot less in extra compensation to make up for keeping those folks through the holidays. If the show were in February, they might not be watching their vendor list drop like flies....
Scheduling a trade show for the first full week in January is just plain abusive. Maybe this will get IDG to extricate their crania from their posteriors long enough to figure that out.... I won't hold my breath, though. I'd imagine they're getting a hefty discount from the Moscone Center for booking during a week that nobody in their right minds would touch with a ten meter pole.
Just to clarify, it is technologically trivial, but nearly impossible to actually implement in a way that completely blocks spam for everyone because it requires complete adoption before you can start rejecting all non-compliant email. Basically, we'd be better off just starting a new email system in parallel and letting the old one die off as people stop using it.
There's a trivial technological means to fight spam. It just requires abandoning SMTP and moving to a new protocol with the following requirements.
All compliant mail transport daemons must require all connections from client computers to be authenticated.
All compliant mail transport daemons must sign all messages as they pass them along.
All compliant mail transport daemons must have a service record in DNS for their host name that provides a public key for verification of the signature.
All compliant mail transport daemons must refuse to accept any email if the signature cannot be verified immediately (even if this is due to load), forcing the sending end to retry.
All compliant mail transport daemons must refuse to accept any email if the host name does not resolve to the IP number from which the inbound message was received.
With that, spam is basically dead. As soon as you require those restrictions, suddenly spammers have to actually own a domain name and provide a working DNS server in order to deliver spam, and that DNS server must contain up-to-date mappings for those hosts to IP numbers. That pretty much obliterates the use of zombies for delivering mail. It also means that there is now a domain name, which by ICANN policy, is required to have a valid postal address, phone number, and other contact information associated with it. In effect, it means that you know who sent the spam definitively unless a company's DNS server and mail server both get compromised. It makes it a lot easier to pin the blame on spammers, which makes it a lot harder for them to repeatedly get off scot free.
In case you're wondering why it needs to be signed, i.e. why Sender ID, etc. are not sufficient, Sender ID and the like can be compromised by merely adding an additional authorized IP number to a list. That means that spammers can masquerade as a company by merely compromising their DNS server briefly, all without disrupting the company's business in any way. With a signed variant of this design, because the private key is be stored on the DNS server, the spammer would be unable to masquerade as the company without changing the public key in the service record. Doing so would cause the company's real outgoing mail to fail to be delivered---an action that would almost certainly be noticed immediately. Thus, adding digital signatures provides a significant bit of immunity from such spoofing attacks (spoofing of a company to customers of a compromised ISP notwithstanding).
The test results are also all cleared if you do a reset via the OBDII interface. AFAIK, the only differences between disconnecting the battery and issuing a code reset are: A. the computer will (probably) remember calibration data upon an OBDII-based code reset, and B. you don't have to reprogram your radio and clock with a code reset.
That would make sense if it were true. Federal law limits the number of withdrawals from certain accounts to six per month. That's not a bank policy. It's a law. Basically, the government wanted to force banks to keep a certain minimum amount of cash on hand (not loaned out to customers), and to preserve that, they put in place both dollar limits and that cap on transactions. Presumably this was because (at the time) computing the amount of cash on hand at the bank took a significant amount of effort. These days, the regulation is just plain idiotic, serves no real purpose, and should have been removed years ago.
That's the problem with laws designed based around limitations in technology. Technology very quickly renders those laws obsolete, but the laws never get removed from the books. Indeed, that's why I feel that all laws beyond a very small core of crucial laws (your basic murder, theft, etc.)---certainly all civil laws and regulations---should be required by the Constitution to have a sunset provision and should be reviewed at minimum every 10-15 years to determine whether the laws are still useful.
It is exceptionally rare to have a choice for electrical providers. Ditto for gas and cable. Probably 99% of the U.S. population is served by one or fewer telephone companies, one or fewer cable company, and one or fewer natural gas providers.
Also, your argument that DSL competes with FiOS is somewhat of a misnomer. Once you get FiOS, they cut your twisted pair. It is no longer possible to get DSL service at that location after that. And unless you have at least one CLEC providing DSL service in your area (outside of major cities, CLECs are rare), your DSL provider is the phone company, so those aren't really in competition at all.
Internet service tends towards a monopoly in all but the largest cities. In my hometown in Tennessee, there is exactly one provider of high speed service---the cable company---and there's rumor that they are on the verge of bankruptcy. No DSL service at that CO, no FiOS, nothing. That's pretty typical of small town America. At best, you have two, and a duopoly is every bit as bad as a monopoly. By contrast, if the municipality owns the lines and can lease them freely to multiple providers, the startup cost to provide service in a town becomes relatively small, and the tendency is to end up with five or six companies competing even in small markets. Why? Because the startup costs are low, and if a major provider starts charging too much, it suddenly becomes very feasible for somebody else to step in and start providing service. The same is not true if the company would have to lay hundreds of thousands of dollars worth of wire infrastructure just to get started.
Introducing the Mach 10 hairdryer. We blow air at Mach 10---fast enough to deflect bullets, cut steel, and even decapitate your friends. Fun for the whole family.
(Small print: WARNING: This product must remain mounted to a solid, stationary platform while in use. Attempting to move the product while in use may cause damage to the product, serious injury, or death.)
Maybe that works in Linux---I haven't tried---but it is definitely neither portable nor POSIX-compliant. The POSIX spec for stty says nothing about it changing the O_NONBLOCK flag, so if an OS modifies that flag with stty raw or -raw, that is a bug. Writing software that depends on a broken behavior is generally a bad idea. Here's the spec for what stty is supposed to do:
Furthermore, it is not even guaranteed that setting O_NONBLOCK in a child process will result in it getting changed in the parent process. If it could be guaranteed across all OSes, I would simply have set the flag once upon entering the app like I do for everything else. It does in Linux. In OSes derived from System-V (AT&T UNIX), however, AFAIK, this does not occur. In BSD OSes, this at least used to behave the way Linux does, though there has been some debate and I'm not sure if it still behaves that way or not. In fact, there are so many portability problems involved with using O_NOBLOCK or O_NDELAY that it almost isn't worth using. It certainly can't be used in anything remotely resembling a portable fashion without getting your hands dirty and writing some C code....
Yeah, it's ugly, but there's just not a viable alternative.
Harriet the Spy? I assumed it was referring to her role as Dawn in the Buffy series, playing a character referred to throughout the entire fifth season only as "the key".
I wouldn't say that BD is going to fail in the colossally spectacular way that DVD-A and SACD failed. It will probably eventually displace DVDs. It is just going to take a heck of a lot longer because of all the compatibility problems the industry has foisted upon us, from the inability to make backups to the inability to play discs at any usable quality via digital connections on first-generation (pre-HDCP) high definition TVs and monitors. You screw over the early adopters hard enough and they'll turn on you. After that, gaining acceptance becomes an uphill battle all the way to the finish line....
As long as you encrypt it in such a way that putting it in the cloud doesn't provide it to anybody else, that's probably reasonable, in much the same way as backing up your iTunes purchases on your Mobile Me iDisk is reasonable. Putting it out there unencrypted... not so much.:-)
What I don't get is why anybody cares about USB 3.0. For disks, its performance will suck compared with eSATA for lots of reasons (lack of true DMA, slower bus, more protocol overhead etc.). For any serious audio/video tasks, FireWire works a lot better and is already generally fast enough for 99.9% of users (and PCIe is a great alternative for that.1%). For all other devices, USB 2.0 is fast enough (and for that matter, USB 1.1 was usually fast enough). What's the intended market for this technology? It seems like it is designed to be fast just to be fast, with no real thought given to why they're making USB faster.
IMHO, USB 3.0 might have made some sense before eSATA's introduction. Now, it really doesn't, particularly given that it can't be made board-layout-compatible with existing USB 2.0 silicon because of the need to wire up the extra optical components for the 3.0 hardware. If you have to do a new board layout for 3.0 anyway, you might as well just switch to the far superior eSATA standard....
Hear, hear. I don't buy Blu-Ray discs for the same reason I won't buy dongle-protected software. If a company really thinks that tying my right to use their software to a piece of hardware that can break, they don't deserve my business. In the case of dongles, the hardware is the dongle. In the case of BRDs, the hardware is the disc itself. Either way, my right to continue using a piece of software/media is being tied to a fragile piece of hardware whose sole reason for existence is copy protection because of the manufacturer's paranoia.
Want to know why Blu-Ray is failing in the marketplace? Because those critical early adopters tend to be people like us, and without that early adopter base, there aren't sufficient manufacturing quantities for economies of scale to bring disc prices down into a price range suitable for ordinary consumers. Somebody needs to jerk a knot in the movie industry until they realize that in BD+ and similar draconian copy protection schemes lies the path to madness.
Okay, I'll feed the troll. Copyright law recognizes your right to make an unlimited number of copies for format shifting purposes, and does not recognize any inherent right of the copyright owner to prevent you from making copies for interoperability purposes.
Therefore, the answer to the question of how many copies I need is this: one backup in the original format, plus one in a format optimized for each device I own or will ever own in my lifetime. Anything less than that is a copout.
True, but in the case of Google supporting FF and Chrome, they are basically helping improve a competing product that they don't own in any way and didn't have a hand in designing. It's more like Ford designing new natural-gas engines for Chevrolet....
Probably, yeah. In the worst case, though, the disc might have gotten finalized incorrectly (e.g. using a bad optical drive), in which case even the original DVD burner might not play it....
The lead-in area (at least for the first session) is the innermost recordable portion of the media. If something went wrong in media fabrication, I'd expect that to be the second-most likely part to have problems, second only to the outer edge (which fails verification frequently in cheap media). So this could have been a media defect as well.
I'm not surprised the Seagate folks were able to recover the data. This pales compared with what the Seagate recovery folks deal with every day--head crashes, surface mount desoldering and replacing defective head preamps, maybe even electron microscope recovery of shattered platters.... Compared with that, a few bad blocks in the lead-in of a DVD is downright trivial and might even be recoverable without hacking the drive firmware....
That said, I sure would like to know who the two companies are that couldn't figure this out so I can never send anything to them....:-)
Perhaps the Winmodem thing was a poor example, but according to this post, some of them do have DSP hardware, but lack a hardware UART. Whether that poster was correct or not, I'm not sure, but that is consistent with my vague memory on the subject. In any case, that's straying pretty far from the subject at hand.:-)
Indeed, that's the whole idea behind the recently ratified OpenCL specification. Design a C-like language that provides a standard abstraction layer for the ability to perform complex computations on a CPU, GPU, or conceivably on any number of other devices lying around (e.g. idle I/O Processors, the DSP core in your WinModem, your printer's raster engine...).
Actually, it makes a lot of sense. They add some trim to the product and make a much bigger profit margin by selling the same vehicle under a high-end brand name. Basically, it all boils down to hoping people won't notice that they are paying a huge premium for trivial enhancements to the same basic vehicle. I'm not saying it is a good practice, but as a business practice, it does pay off, at least so long as the market for luxury goods doesn't dry up. When it does, of course, if you aren't making enough money off your low-end products, you're screwed.
It makes far less sense if the two products aren't build using the same parts, of course, which is why the car analogy falls flat when talking about Google. (It does work for Sun's StarOffice/OpenOffice somewhat.) To explain the Google bifurcation, you have to go back a little farther to an ancient proverb: the enemy of my enemy is my friend. Guess which browser is the enemy.:-)
Slashdot Mirror
That's precisely the sort of system I'm advocating for telecom infrastructure.
The thing is, disposable domains cost money. The reason spam is so profitable now is that they can send out millions of emails without paying a dime. When the second email from their domain to any given user causes the entire domain to get blocked for every user at that server, suddenly their effective cost of sending an advertisement jumps to about $5 per mailout (half the cost of a domain). At that price, the huge financial overhead causes spam to be unprofitable when compared with much cheaper advertising techniques like Google AdWords. Eliminate the funding source for spammers and you eliminate the spammers.
Oh, yes, that's right. We have to ban domain tasting. Then again, that should be obvious for many, many other reasons....
This applies even if spammers ignore the requirement for legit domain information. However, I think ICANN should tighten up the rules on domain registration. New registrants (and any registrants who have received spam complains against them) should have to provide proof of identity when registering their first domain name with a given registrar. There's simply no excuse for not requiring at least a minimal audit trail for registering a domain.
Yes, but if a domain like gmail or hotmail gets sufficiently lax at verifying legitimacy of people applying for accounts, they'll eventually find their traffic getting blocked at the router level.... To some degree, prevention of spam does require systems like that to require at least a little effort to apply for an account (sufficient to make auto-registration impractical).
And there are no words for how much the MWSF schedule sucks. When I realize how many employees at Apple, Adobe, Canon, and hundreds of other vendors are forced to skip Christmas vacation every year to get products and show displays ready for that horribly timed conference, it makes me want to shove my foot up IDG CEO Bob Carrigan's you-know-what. If the conference were in February, those employees would almost certainly be happier, plus it would likely cost those vendors a lot less in extra compensation to make up for keeping those folks through the holidays. If the show were in February, they might not be watching their vendor list drop like flies....
Scheduling a trade show for the first full week in January is just plain abusive. Maybe this will get IDG to extricate their crania from their posteriors long enough to figure that out.... I won't hold my breath, though. I'd imagine they're getting a hefty discount from the Moscone Center for booking during a week that nobody in their right minds would touch with a ten meter pole.
That may be the worst pun I've read on Slashdot in years....
Just to clarify, it is technologically trivial, but nearly impossible to actually implement in a way that completely blocks spam for everyone because it requires complete adoption before you can start rejecting all non-compliant email. Basically, we'd be better off just starting a new email system in parallel and letting the old one die off as people stop using it.
There's a trivial technological means to fight spam. It just requires abandoning SMTP and moving to a new protocol with the following requirements.
With that, spam is basically dead. As soon as you require those restrictions, suddenly spammers have to actually own a domain name and provide a working DNS server in order to deliver spam, and that DNS server must contain up-to-date mappings for those hosts to IP numbers. That pretty much obliterates the use of zombies for delivering mail. It also means that there is now a domain name, which by ICANN policy, is required to have a valid postal address, phone number, and other contact information associated with it. In effect, it means that you know who sent the spam definitively unless a company's DNS server and mail server both get compromised. It makes it a lot easier to pin the blame on spammers, which makes it a lot harder for them to repeatedly get off scot free.
In case you're wondering why it needs to be signed, i.e. why Sender ID, etc. are not sufficient, Sender ID and the like can be compromised by merely adding an additional authorized IP number to a list. That means that spammers can masquerade as a company by merely compromising their DNS server briefly, all without disrupting the company's business in any way. With a signed variant of this design, because the private key is be stored on the DNS server, the spammer would be unable to masquerade as the company without changing the public key in the service record. Doing so would cause the company's real outgoing mail to fail to be delivered---an action that would almost certainly be noticed immediately. Thus, adding digital signatures provides a significant bit of immunity from such spoofing attacks (spoofing of a company to customers of a compromised ISP notwithstanding).
The test results are also all cleared if you do a reset via the OBDII interface. AFAIK, the only differences between disconnecting the battery and issuing a code reset are: A. the computer will (probably) remember calibration data upon an OBDII-based code reset, and B. you don't have to reprogram your radio and clock with a code reset.
That would make sense if it were true. Federal law limits the number of withdrawals from certain accounts to six per month. That's not a bank policy. It's a law. Basically, the government wanted to force banks to keep a certain minimum amount of cash on hand (not loaned out to customers), and to preserve that, they put in place both dollar limits and that cap on transactions. Presumably this was because (at the time) computing the amount of cash on hand at the bank took a significant amount of effort. These days, the regulation is just plain idiotic, serves no real purpose, and should have been removed years ago.
That's the problem with laws designed based around limitations in technology. Technology very quickly renders those laws obsolete, but the laws never get removed from the books. Indeed, that's why I feel that all laws beyond a very small core of crucial laws (your basic murder, theft, etc.)---certainly all civil laws and regulations---should be required by the Constitution to have a sunset provision and should be reviewed at minimum every 10-15 years to determine whether the laws are still useful.
It is exceptionally rare to have a choice for electrical providers. Ditto for gas and cable. Probably 99% of the U.S. population is served by one or fewer telephone companies, one or fewer cable company, and one or fewer natural gas providers.
Also, your argument that DSL competes with FiOS is somewhat of a misnomer. Once you get FiOS, they cut your twisted pair. It is no longer possible to get DSL service at that location after that. And unless you have at least one CLEC providing DSL service in your area (outside of major cities, CLECs are rare), your DSL provider is the phone company, so those aren't really in competition at all.
Internet service tends towards a monopoly in all but the largest cities. In my hometown in Tennessee, there is exactly one provider of high speed service---the cable company---and there's rumor that they are on the verge of bankruptcy. No DSL service at that CO, no FiOS, nothing. That's pretty typical of small town America. At best, you have two, and a duopoly is every bit as bad as a monopoly. By contrast, if the municipality owns the lines and can lease them freely to multiple providers, the startup cost to provide service in a town becomes relatively small, and the tendency is to end up with five or six companies competing even in small markets. Why? Because the startup costs are low, and if a major provider starts charging too much, it suddenly becomes very feasible for somebody else to step in and start providing service. The same is not true if the company would have to lay hundreds of thousands of dollars worth of wire infrastructure just to get started.
If all you want to do is reset the codes, disconnecting the battery for about 30 seconds will do the same thing. All you need is a screwdriver.
Introducing the Mach 10 hairdryer. We blow air at Mach 10---fast enough to deflect bullets, cut steel, and even decapitate your friends. Fun for the whole family.
(Small print: WARNING: This product must remain mounted to a solid, stationary platform while in use. Attempting to move the product while in use may cause damage to the product, serious injury, or death.)
Maybe that works in Linux---I haven't tried---but it is definitely neither portable nor POSIX-compliant. The POSIX spec for stty says nothing about it changing the O_NONBLOCK flag, so if an OS modifies that flag with stty raw or -raw, that is a bug. Writing software that depends on a broken behavior is generally a bad idea. Here's the spec for what stty is supposed to do:
stty POSIX spec
Furthermore, it is not even guaranteed that setting O_NONBLOCK in a child process will result in it getting changed in the parent process. If it could be guaranteed across all OSes, I would simply have set the flag once upon entering the app like I do for everything else. It does in Linux. In OSes derived from System-V (AT&T UNIX), however, AFAIK, this does not occur. In BSD OSes, this at least used to behave the way Linux does, though there has been some debate and I'm not sure if it still behaves that way or not. In fact, there are so many portability problems involved with using O_NOBLOCK or O_NDELAY that it almost isn't worth using. It certainly can't be used in anything remotely resembling a portable fashion without getting your hands dirty and writing some C code....
Yeah, it's ugly, but there's just not a viable alternative.
Harriet the Spy? I assumed it was referring to her role as Dawn in the Buffy series, playing a character referred to throughout the entire fifth season only as "the key".
I wouldn't say that BD is going to fail in the colossally spectacular way that DVD-A and SACD failed. It will probably eventually displace DVDs. It is just going to take a heck of a lot longer because of all the compatibility problems the industry has foisted upon us, from the inability to make backups to the inability to play discs at any usable quality via digital connections on first-generation (pre-HDCP) high definition TVs and monitors. You screw over the early adopters hard enough and they'll turn on you. After that, gaining acceptance becomes an uphill battle all the way to the finish line....
As long as you encrypt it in such a way that putting it in the cloud doesn't provide it to anybody else, that's probably reasonable, in much the same way as backing up your iTunes purchases on your Mobile Me iDisk is reasonable. Putting it out there unencrypted... not so much. :-)
What I don't get is why anybody cares about USB 3.0. For disks, its performance will suck compared with eSATA for lots of reasons (lack of true DMA, slower bus, more protocol overhead etc.). For any serious audio/video tasks, FireWire works a lot better and is already generally fast enough for 99.9% of users (and PCIe is a great alternative for that .1%). For all other devices, USB 2.0 is fast enough (and for that matter, USB 1.1 was usually fast enough). What's the intended market for this technology? It seems like it is designed to be fast just to be fast, with no real thought given to why they're making USB faster.
IMHO, USB 3.0 might have made some sense before eSATA's introduction. Now, it really doesn't, particularly given that it can't be made board-layout-compatible with existing USB 2.0 silicon because of the need to wire up the extra optical components for the 3.0 hardware. If you have to do a new board layout for 3.0 anyway, you might as well just switch to the far superior eSATA standard....
Hear, hear. I don't buy Blu-Ray discs for the same reason I won't buy dongle-protected software. If a company really thinks that tying my right to use their software to a piece of hardware that can break, they don't deserve my business. In the case of dongles, the hardware is the dongle. In the case of BRDs, the hardware is the disc itself. Either way, my right to continue using a piece of software/media is being tied to a fragile piece of hardware whose sole reason for existence is copy protection because of the manufacturer's paranoia.
Want to know why Blu-Ray is failing in the marketplace? Because those critical early adopters tend to be people like us, and without that early adopter base, there aren't sufficient manufacturing quantities for economies of scale to bring disc prices down into a price range suitable for ordinary consumers. Somebody needs to jerk a knot in the movie industry until they realize that in BD+ and similar draconian copy protection schemes lies the path to madness.
Okay, I'll feed the troll. Copyright law recognizes your right to make an unlimited number of copies for format shifting purposes, and does not recognize any inherent right of the copyright owner to prevent you from making copies for interoperability purposes.
Therefore, the answer to the question of how many copies I need is this: one backup in the original format, plus one in a format optimized for each device I own or will ever own in my lifetime. Anything less than that is a copout.
True, but in the case of Google supporting FF and Chrome, they are basically helping improve a competing product that they don't own in any way and didn't have a hand in designing. It's more like Ford designing new natural-gas engines for Chevrolet....
Probably, yeah. In the worst case, though, the disc might have gotten finalized incorrectly (e.g. using a bad optical drive), in which case even the original DVD burner might not play it....
The lead-in area (at least for the first session) is the innermost recordable portion of the media. If something went wrong in media fabrication, I'd expect that to be the second-most likely part to have problems, second only to the outer edge (which fails verification frequently in cheap media). So this could have been a media defect as well.
I'm not surprised the Seagate folks were able to recover the data. This pales compared with what the Seagate recovery folks deal with every day--head crashes, surface mount desoldering and replacing defective head preamps, maybe even electron microscope recovery of shattered platters.... Compared with that, a few bad blocks in the lead-in of a DVD is downright trivial and might even be recoverable without hacking the drive firmware....
That said, I sure would like to know who the two companies are that couldn't figure this out so I can never send anything to them.... :-)
Perhaps the Winmodem thing was a poor example, but according to this post, some of them do have DSP hardware, but lack a hardware UART. Whether that poster was correct or not, I'm not sure, but that is consistent with my vague memory on the subject. In any case, that's straying pretty far from the subject at hand. :-)
Indeed, that's the whole idea behind the recently ratified OpenCL specification. Design a C-like language that provides a standard abstraction layer for the ability to perform complex computations on a CPU, GPU, or conceivably on any number of other devices lying around (e.g. idle I/O Processors, the DSP core in your WinModem, your printer's raster engine...).
No, 26 GHz is still way too slow for Vista.
Actually, it makes a lot of sense. They add some trim to the product and make a much bigger profit margin by selling the same vehicle under a high-end brand name. Basically, it all boils down to hoping people won't notice that they are paying a huge premium for trivial enhancements to the same basic vehicle. I'm not saying it is a good practice, but as a business practice, it does pay off, at least so long as the market for luxury goods doesn't dry up. When it does, of course, if you aren't making enough money off your low-end products, you're screwed.
It makes far less sense if the two products aren't build using the same parts, of course, which is why the car analogy falls flat when talking about Google. (It does work for Sun's StarOffice/OpenOffice somewhat.) To explain the Google bifurcation, you have to go back a little farther to an ancient proverb: the enemy of my enemy is my friend. Guess which browser is the enemy. :-)