Ping is one of the many protocols that run on ICMP. Ping and ping-response are the most popular packet types, but the PMTU discovery is a different type of packet. It's possible to block pings and ping responses without blocking the packet types that make Path MTU Discovery work. Alas, it is not *necessary* to do the job right, and too many administrators and types of equipment blindly kill PMTU while trying to protect their security from ping-based attacks. But just because your pings got killed doesn't mean PMTU is broken (though it wouldn't be any surprise either.)
If your broken intranet requires smaller packets already, try making them even smaller, e.g. drop to 1250 or something. (Sigh..)
Your Covad circuit doesn't look blazingly fast, but that's typically a function of your distance to the telco office. It's probably also asymmetric, with slower upstream than downstream. Is the EVDO link symmetric speeds?
Also, somebody commented about latency and jitter. Aside from any issues about overloading the air channel and fixing it with queuing, measurements like that are often random and large because routers are not very good at responding to pings, especially when they're busy - ping responses tend to be handled by the CPU, while packet routing is actually done in ASIC cards, so the ping or traceroute time is often much much slower than the actual packet routing behaviour. What you need to do end-to-end timings.
Back in the 80s, when the "hackers" meme was spreading around the mundanes, my usual explanation of what we were was along the lines of: Remember when kids used to tinker with cars instead of computers? It's the same thing. Some of them were trying to keep the old family car running so they had something to drive, some were trying to tweak the engine so they could go really fast on the race track, some painted their cars to look cool and impress girls, and some were just taking off the mufflers so they made a lot of noise while they drove across your lawn. (Now that I'm older, it's more like "Hey, you punk kids, get off my lawn!":-)
Jeri Ellworth recently gave a talk at Stanford. She hacked on Commodore 64s as a kid, switched over to racing cars as a teenager, ran a computer store for a couple of years, and taught herself VLSI design, which she's used to do things like Commodore 64 emulators. It was a really cool talk, and it was interesting to see somebody who did a lot of car hacking as well as computers.
Other than fetching beer, the Aibo's main use seems to be as a cat toy - something to drag a string around the floor fast enough that the cat has to do some actual work to catch it. But cats do like chasing laser pointers, so might as well have the aibo carry the laser pointer around for you.
Now, a robot *gecko* would be useful - "Hey gecko, go dust that ceiling spot! And drag this ethernet cable across the crawlspace for me!"
SETI@Home doesn't actually run Linpak, and probably wouldn't run it very well, but for a number of years the combined TFLOPS of SETI@Home was substantially faster than anything else on the list. It's still faster than Earth Simulator (SETI's averaging about 57 TFLOPS, vs. 35 for Earth Simulator) but NASA's machine does 51-60 TFLOPS, and two of the Blue Gene machines are faster (IBM's at about 91-110, doing good work, and Livermore's at 136-183, working on Weapons of Mass Destruction.) Several of the other fast machines are also doing astronomy or other university research.
Slashdot does have a team on SETI@Home, but it looks like it only has about 570 members and isn't going all that fast. (It's a bit hard to tell, because they've rearranged the websites significantly.) I don't run it - I'm running one of the Protein Folding projects, and I used to run the GIMPS prime number searcher.
For this application, the performance differences aren't significant, and any CPU utilization differences don't matter either, but SATA's a lot more convenient mechanically, which is important when you're trying to cram thousands of parts into a manageable space, especially if you want the drives to be removeable.
I was a bit puzzled by that also - the article said the things come in racks of 40 or 64TB, and 16 racks times 64TB is about 1PB, not 1.5.
Also, the article says they don't like RAID, due to bad experiences with RAID5, and the system is configured as JBOD (Just a Bunch Of Disks). It doesn't say why, or what users should do to get equivalent protection. My guess is that depending on RAID within a box means you're still vulnerable if the box's CPU or disk controller decides to scribble the disks, or the power supply decides to catch fire or short out and deliver 240VAC on the +5V line or whatever. So if you want a RAID-like set of redundancy, set up your applications or file system mounting or something to calculate the protection disk in software and hand it off to another 1U box for storage.
The overhead of the motherboards here is not that high - they're about $150-200, and support 4 disks that probably cost $200-300 each, so they're only about 20% of the cost, which is not bad. The article didn't say they're using SATA, and it sounded like it's some IDE variant instead, but if you're only using 100 Mbps Ethernet to connect to the box and not the optional GigE, it's not the bottleneck anyway. If you wanted an alternative design, you could probably do something with a couple of 4-way SATA controllers per CPU, with a lot of disks stacked vertically in a 3-4U box looking like an X-serve or something. But that wouldn't necessarily have much of an advantage.
Hi, Phil - As long as you and I have been in the industry, there's been a constant process of people wanting to run applications that they think they can't do efficiently on their current CPUs, designing and sometimes building separate processors to implement them, people thinking that that's silly and inefficient and finding the real bottlenecks, fixing them, and moving the applications back into the main processor or the mainstream support chips, sometimes at the expense of building other I/O channels into the main processor.
From a market perspective, there's often a period when it's more efficient to build new capabilities into a fancy expensive coprocessor than to fix the underlying bottlenecks. Sometimes you can start shipping boards before the problem goes away, sometimes you even sell enough to make tons of money, but sometimes only the top 1% of computers in the market are really affected so even if you sell it to everybody you don't make back your development costs. And sometimes people would buy the fancy cards for a while even if there were better approaches - back when Van Jacobsen was getting a 3 MIPS Sun 3/60's Ethernet to push 8 Mbps of FTP traffic by fixing the TCP and IP stacks, faster Intel 80386 and 80486 machines generally needed accelerator cards to get 4-5 Mbps instead of 1-2 Mbps, much of which seemed to be related to intricacies of DMA and interrupt handling on the PC as well as on slow bus speeds. Of course, the prices have changed by a few orders of magnitude - it was hard to make money selling $1000 cards when the bottom end of the market was $500, but it's a lot harder when the bottom end of the market is $19 (for gigE, or $3 for 10/100) and the moderately-expensive cards cost $79.
The grandparent article was talking about ATM processor cards, so I'd guess the timeframe is about 5-7 years ago when some people still believed in ATM to the desktop. It looks like my online copies of Fore manuals are from 1999, and when we bought the switch in my lab, the vendor threw in a couple of PCI-based ATM cards which could ostensibly work in both a PC and our blazingly fast Sparcstation 5, though we never did try it in the Sparcstation. The card had some critical ATM features implemented in hardware - segmentation/reassembly between AAL-5 data frames and the layer 2 53-byte cells, priority queuing for different types of ATM PVCs, and ABR flow control. It probably also did AAL-5 frame headers and checksums, and it wouldn't surprise me if it also did UDP checksums just because it had hardware around. Ethernet cards in those days had reputations ranging from deadly stupid to adequately smart to way too clever to be actually useful, pretty much as they do today.
These tradeoffs happen in lots of other parts of the architecture - people like Henry Spencer used to argue in favor of dumb-framebuffer graphics systems with CPUs doing the heavy lifting, but most of the higher-end graphics cards today use the card for SIMD crunching on features like shading and textures, with an AGP*N channel into the CPU because PCI is too slow, and the CPU-vs-card arguments are mainly for geometry calculations (I think CPU is mostly winning?) Serial I/O, to the extent anybody still uses it, seems to have mostly moved into the Southbridge chips, but before that you could get a major performance win by using a 16550A UART instead of the dumber UARTs, and of course I remember the Sys3 / Sys5 folks using Unibus KMC11s to service the DZ11 I/O processors for functions like cooked-mode I/O rather to avoid bothering the CPU (I don't remember the BSD folks ever adopting that, but I don't remember why at this point; perhaps emacs made cooked-mode uncommon enough that it wasn't worth the bother, or maybe the new tty driver could get more work out of a dz11.)
One other place where there's an ongoing argument between using the CPU vs. an I/O board is modems - the Windows side thinks it makes much more sense to do most of the work in the CPU, and use a dumb modem with a fast PCI interface, while the Linux fo
At this point Avalanche is a research project which would like to become a bigger research project. That doesn't mean it's a product that's ready for prime time, with friendly user interfaces etc. It's fundamentally a transport protocol, and the obvious way to handle DRM is as a separate layer, e.g. part of the user interface or the media player applications, rather than gumming up the transport bits with DRM.
While your joke was funny, that's not in fact what's happening here. This isn't a vapor product that the Marketdroids are pushing to kill off the competition - it's a research project that the Labs folks are doing because it seems like it might be cool and useful. It looks like it's in the stage of "Sounds cool and useful, let's promote it a bit so we get some more research support for this project", but it's ok for projects like that to be unfinished and prototypish, which is different from being vaporware.
SDLC?? Most people switched to HDLC years ago, and usually use PPP now...
Designing a system like this is much harder than simply putting together a "simple download client", because the algorithms you need aren't all predictable in advance - it's very much emergent behavior, and while simulations are useful, real users and real networks are often not very cooperative about acting like the simulation. When Bram was developing BitTorrent, he went through a number of rounds of "Write the code - deploy - test - tweak algorithms based on results", using larger and larger sets of users, and finding what unexpected things broke or became bottlenecks that hadn't been a problem at smaller test sizes.
Simulations can get you through some of that, and it's much easier to do if you've got the resources of a Microsoft research lab as opposed to an individual with some help from his friends and friendly users. But it still takes a bunch of cycles, and it's hard to compress that into three months.
When you get a phishing mail, and fill out the site with bogus information, it's not very useful - too hard to generate good fake data, and there's no coordination with catching the perps, so the most you're doing is giving them a bunch of useless data to work on. (Also, technically what you're doing is fraudulent, and accidentally picking a real credit card number would also be a rude thing to do.)
Banks and credit card companies could do a much more effective job of faking the data - they can set up their own bogus accounts that are flagged as fraudulent, so when the phisher tries to spend the credit card at a store they get busted, or when they try to use a fake ATM card they get photographed and located (and the card gets eaten if it's the kind of machine that you put your card into.) At minimum, the phisher's transactions get rejected.
EBay and PayPal could do some of the same thing, though they don't have a mechanism to do more than trace the IP and mailing addresses of the perp. The IP address isn't very reliable, since it could easily be a zombie (though at least it can cut down on the less intelligent eBay phishers and help locate and blacklist some zombies.) Mailing address requires a bit more work for eBay to fake, and it's likely to be some maildrop somewhere, but they could do it.
Last time I looked at Comcast's Terms of Service, they still had extremely fascist policies about what you could and couldn't do with your service, e.g. not running web servers or mail servers, and it was pretty obvious that they considered Napster and newer P2P applications as Evil. While I do have their television service in my house, it's not worth dealing with an "Internet Service Provider" that doesn't like the end-to-end principle that makes Internet Services work, or in general with anybody whose policies are noticably more restrictive than Sonic.net (whom I use) or Speakeasy.
I'm really surprised how much spamware apparently doesn't implement SMTP cleanly - Jef Poskanzer's recent article said that rejecting any address that sends mail before waiting for the response to an initial HELO throws out a significant portion of spam. But Greylisting throws out a lot more - if somebody's address isn't trusted, give them a 451 and tell them to come back in 5 minutes; spammers usually won't bother. You could get fancy and give anybody on a blacklist a long delay time (e.g. come back in an hour.)
Greylisting is especially appropriate for the DialUp List type of blocklists, that track dynamic IP addresses. They might be legitimate users running Linux at home, or they might be zombies, and greylisting usually keeps the zombies out.
There have been spam blacklists that worked that way; they mostly weren't worth using, except as SpamAssassin weights, and mostly nobody cares. And there have been Open Relay blacklists that blacklisted every mail server at an ISP to get their attention until they cleaned up open relays, even if only some of that ISP's customers had open relays.
But this is different - this is ONE IP address - the SBL record identifies it as a/32. Virtual Hosting means that it's possible to have multiple domains all using the same IP address for their email or websites, and if you're going to blacklist based on IP addresses, it doesn't get more granular than one address (unless you want to do things like have different return codes for "address has one spammer and some non-spammers".) So if one IP address has 100 legitimate users and one spammer, and you receive email from them, is it more likely that the mail is one of the 10000 (100 users x 100 messages/day) good messages, or one of the 1,000,000 spam sent by the spammer? 99% likely that it's spam; sorry if it was Paul.
He's not just on a bad street, and the vigilantes aren't shooting randomly with machine guns. He's got an office in the same building as a few mafiosi, and the vigilantes are very carefully using sniper rifles and only sniping at people who come out of that building's front door, and the front doors of a few other houses on the same street. They just aren't looking at *who* walks out the door.
It's one thing for a blacklist to cover a large block of addresses because of one spammer. But there really is a limit to the granularity of a blacklist - it's checking on a single IP address. One reason that we haven't run out of IPv4 addresses in spite of the Internet explosion of the last decade is virtual host addresses in HTTP 1.1 and SMTP - multiple domain names can use the same IP address, and the web and email servers can sort out which requests are for which names. So it's possible that you can have a conscientious blacklist that's only listing the IP address used by a real spammer, but still affect multiple hosts. The blacklist could do something more complex, like return different codes depending on whether there are known to be multiple domains operating at the address and only one is known to be a spammer, but that's pretty tough (and if it were popular, the spammers would of course want to run multiple domains on the same IP address, including perfectly-innocent-example.com and annoying-spammer.com.)
So what do you do about it? Not sure there's a good answer, other than the people who get hit with the collateral damage complain to their email/hosting provider to get rid of the spammer, and email recipients who want to avoid collateral damage can do things like use the blacklist as a SpamAssassin weight instead of total blocking, or use the blacklist to drive greylisting (e.g. tell BL'd addresses to come back in an hour, though spammers hosted at real ISPs are more likely to have real SMTP servers that get around greylisting, as opposed to zombies which usually don't.)
Last week the spammer was at the address Paul's website is on. Now when I dig for the spammer's IP address, it's somewhere else. Assumin gthe spammer is no longer on Yahoo, Paul needs to get Yahoo to tell SBL they're gone.
Maybe you only have three choices of broadband ISP at home, or live somewhere sufficiently rural that there are only three choices of dial ISP - that's entirely irrelevant to how many choices you have on where you get your email, send your email, or host your web servers. Sure, it's convenient to be able to run all those things from your home Linux box, but if you want to do that, you'll probably find that your cable modem company and some of the DSL ISPs that your phone company supports might not permit that. There are hundreds or thousands of companies that run POP/IMAP mailbox services, and probably more that will host web sites, and that's not even getting into options like virtual hosting.
Not all ISPs are following BCP38 or the similar RFCs, but it's pretty straightforward for ISPs to do uRPF Reverse Path Filtering to block spoofed IP packets from their customers' routers, which block any packets claiming to be "from" an access line that they don't belong on. (Obviously it's more complex if your customer is an ISP, and a bit more complex if the customer is multiply homed.) This blocks most of the direct UDP and ICMP attacks, because it lets the recipient identify the source address and block it, and it prevents attackers from forging the victim's address in amplifier attacks (e.g. broadcasts "from" the victim that get big response traffic.)
Walmart is an extremely large database company that also has a bunch of real-estate objects with cheap manufacturing-database-interface objects in them and other database joins that occur when marketing database objects walk in the door and start invoking messages on the manufacturing-database0interface objects.
Their definition of "Customers want stuff" is much different from, say, a mom&pop electronics store, or Weird Stuff Warehouse or HalTed Specialties.
Unfortunately, Fry's seems to have stopped carrying 10-hour VHS tapes. Sure, they were only "standard quality" instead of higher-end tape, but they worked really well for setting the VCR to record when you're going to be gone for a while.
Not being a UK Subject, I probably shouldn't buy the TShirt, but here in the US we've got our own problems with the RealID act giving us a real national ID card real soon unless we stop it.
Use a shorter bucket. Put a sixpack of beer in the bucket along with the ice water. After 15-30 minutes, take the beer out of the bucket, put your feet in the bucket, and drink some of the beer.
Also, it's the kind of application where wimpy American-style canned beers work fine (or whichever of Labatt's or Molson in cheaper in Waterloo) - you want something cold and quick-drinking, not something like the Guinness I'm about to go open a bottle of:-)
Slashdot Mirror
If your broken intranet requires smaller packets already, try making them even smaller, e.g. drop to 1250 or something. (Sigh..)
Also, somebody commented about latency and jitter. Aside from any issues about overloading the air channel and fixing it with queuing, measurements like that are often random and large because routers are not very good at responding to pings, especially when they're busy - ping responses tend to be handled by the CPU, while packet routing is actually done in ASIC cards, so the ping or traceroute time is often much much slower than the actual packet routing behaviour. What you need to do end-to-end timings.
Jeri Ellworth recently gave a talk at Stanford. She hacked on Commodore 64s as a kid, switched over to racing cars as a teenager, ran a computer store for a couple of years, and taught herself VLSI design, which she's used to do things like Commodore 64 emulators. It was a really cool talk, and it was interesting to see somebody who did a lot of car hacking as well as computers.
Now, a robot *gecko* would be useful - "Hey gecko, go dust that ceiling spot! And drag this ethernet cable across the crawlspace for me!"
Slashdot does have a team on SETI@Home, but it looks like it only has about 570 members and isn't going all that fast. (It's a bit hard to tell, because they've rearranged the websites significantly.) I don't run it - I'm running one of the Protein Folding projects, and I used to run the GIMPS prime number searcher.
For this application, the performance differences aren't significant, and any CPU utilization differences don't matter either, but SATA's a lot more convenient mechanically, which is important when you're trying to cram thousands of parts into a manageable space, especially if you want the drives to be removeable.
Also, the article says they don't like RAID, due to bad experiences with RAID5, and the system is configured as JBOD (Just a Bunch Of Disks). It doesn't say why, or what users should do to get equivalent protection. My guess is that depending on RAID within a box means you're still vulnerable if the box's CPU or disk controller decides to scribble the disks, or the power supply decides to catch fire or short out and deliver 240VAC on the +5V line or whatever. So if you want a RAID-like set of redundancy, set up your applications or file system mounting or something to calculate the protection disk in software and hand it off to another 1U box for storage.
The overhead of the motherboards here is not that high - they're about $150-200, and support 4 disks that probably cost $200-300 each, so they're only about 20% of the cost, which is not bad. The article didn't say they're using SATA, and it sounded like it's some IDE variant instead, but if you're only using 100 Mbps Ethernet to connect to the box and not the optional GigE, it's not the bottleneck anyway. If you wanted an alternative design, you could probably do something with a couple of 4-way SATA controllers per CPU, with a lot of disks stacked vertically in a 3-4U box looking like an X-serve or something. But that wouldn't necessarily have much of an advantage.
From a market perspective, there's often a period when it's more efficient to build new capabilities into a fancy expensive coprocessor than to fix the underlying bottlenecks. Sometimes you can start shipping boards before the problem goes away, sometimes you even sell enough to make tons of money, but sometimes only the top 1% of computers in the market are really affected so even if you sell it to everybody you don't make back your development costs. And sometimes people would buy the fancy cards for a while even if there were better approaches - back when Van Jacobsen was getting a 3 MIPS Sun 3/60's Ethernet to push 8 Mbps of FTP traffic by fixing the TCP and IP stacks, faster Intel 80386 and 80486 machines generally needed accelerator cards to get 4-5 Mbps instead of 1-2 Mbps, much of which seemed to be related to intricacies of DMA and interrupt handling on the PC as well as on slow bus speeds. Of course, the prices have changed by a few orders of magnitude - it was hard to make money selling $1000 cards when the bottom end of the market was $500, but it's a lot harder when the bottom end of the market is $19 (for gigE, or $3 for 10/100) and the moderately-expensive cards cost $79.
The grandparent article was talking about ATM processor cards, so I'd guess the timeframe is about 5-7 years ago when some people still believed in ATM to the desktop. It looks like my online copies of Fore manuals are from 1999, and when we bought the switch in my lab, the vendor threw in a couple of PCI-based ATM cards which could ostensibly work in both a PC and our blazingly fast Sparcstation 5, though we never did try it in the Sparcstation. The card had some critical ATM features implemented in hardware - segmentation/reassembly between AAL-5 data frames and the layer 2 53-byte cells, priority queuing for different types of ATM PVCs, and ABR flow control. It probably also did AAL-5 frame headers and checksums, and it wouldn't surprise me if it also did UDP checksums just because it had hardware around. Ethernet cards in those days had reputations ranging from deadly stupid to adequately smart to way too clever to be actually useful, pretty much as they do today.
These tradeoffs happen in lots of other parts of the architecture - people like Henry Spencer used to argue in favor of dumb-framebuffer graphics systems with CPUs doing the heavy lifting, but most of the higher-end graphics cards today use the card for SIMD crunching on features like shading and textures, with an AGP*N channel into the CPU because PCI is too slow, and the CPU-vs-card arguments are mainly for geometry calculations (I think CPU is mostly winning?) Serial I/O, to the extent anybody still uses it, seems to have mostly moved into the Southbridge chips, but before that you could get a major performance win by using a 16550A UART instead of the dumber UARTs, and of course I remember the Sys3 / Sys5 folks using Unibus KMC11s to service the DZ11 I/O processors for functions like cooked-mode I/O rather to avoid bothering the CPU (I don't remember the BSD folks ever adopting that, but I don't remember why at this point; perhaps emacs made cooked-mode uncommon enough that it wasn't worth the bother, or maybe the new tty driver could get more work out of a dz11.)
One other place where there's an ongoing argument between using the CPU vs. an I/O board is modems - the Windows side thinks it makes much more sense to do most of the work in the CPU, and use a dumb modem with a fast PCI interface, while the Linux fo
At this point Avalanche is a research project which would like to become a bigger research project. That doesn't mean it's a product that's ready for prime time, with friendly user interfaces etc. It's fundamentally a transport protocol, and the obvious way to handle DRM is as a separate layer, e.g. part of the user interface or the media player applications, rather than gumming up the transport bits with DRM.
SDLC?? Most people switched to HDLC years ago, and usually use PPP now...
Simulations can get you through some of that, and it's much easier to do if you've got the resources of a Microsoft research lab as opposed to an individual with some help from his friends and friendly users. But it still takes a bunch of cycles, and it's hard to compress that into three months.
Banks and credit card companies could do a much more effective job of faking the data - they can set up their own bogus accounts that are flagged as fraudulent, so when the phisher tries to spend the credit card at a store they get busted, or when they try to use a fake ATM card they get photographed and located (and the card gets eaten if it's the kind of machine that you put your card into.) At minimum, the phisher's transactions get rejected.
EBay and PayPal could do some of the same thing, though they don't have a mechanism to do more than trace the IP and mailing addresses of the perp. The IP address isn't very reliable, since it could easily be a zombie (though at least it can cut down on the less intelligent eBay phishers and help locate and blacklist some zombies.) Mailing address requires a bit more work for eBay to fake, and it's likely to be some maildrop somewhere, but they could do it.
Last time I looked at Comcast's Terms of Service, they still had extremely fascist policies about what you could and couldn't do with your service, e.g. not running web servers or mail servers, and it was pretty obvious that they considered Napster and newer P2P applications as Evil. While I do have their television service in my house, it's not worth dealing with an "Internet Service Provider" that doesn't like the end-to-end principle that makes Internet Services work, or in general with anybody whose policies are noticably more restrictive than Sonic.net (whom I use) or Speakeasy.
Greylisting is especially appropriate for the DialUp List type of blocklists, that track dynamic IP addresses. They might be legitimate users running Linux at home, or they might be zombies, and greylisting usually keeps the zombies out.
But this is different - this is ONE IP address - the SBL record identifies it as a /32. Virtual Hosting means that it's possible to have multiple domains all using the same IP address for their email or websites, and if you're going to blacklist based on IP addresses, it doesn't get more granular than one address (unless you want to do things like have different return codes for "address has one spammer and some non-spammers".) So if one IP address has 100 legitimate users and one spammer, and you receive email from them, is it more likely that the mail is one of the 10000 (100 users x 100 messages/day) good messages, or one of the 1,000,000 spam sent by the spammer? 99% likely that it's spam; sorry if it was Paul.
He's not just on a bad street, and the vigilantes aren't shooting randomly with machine guns. He's got an office in the same building as a few mafiosi, and the vigilantes are very carefully using sniper rifles and only sniping at people who come out of that building's front door, and the front doors of a few other houses on the same street. They just aren't looking at *who* walks out the door.
So what do you do about it? Not sure there's a good answer, other than the people who get hit with the collateral damage complain to their email/hosting provider to get rid of the spammer, and email recipients who want to avoid collateral damage can do things like use the blacklist as a SpamAssassin weight instead of total blocking, or use the blacklist to drive greylisting (e.g. tell BL'd addresses to come back in an hour, though spammers hosted at real ISPs are more likely to have real SMTP servers that get around greylisting, as opposed to zombies which usually don't.)
Last week the spammer was at the address Paul's website is on. Now when I dig for the spammer's IP address, it's somewhere else. Assumin gthe spammer is no longer on Yahoo, Paul needs to get Yahoo to tell SBL they're gone.
Maybe you only have three choices of broadband ISP at home, or live somewhere sufficiently rural that there are only three choices of dial ISP - that's entirely irrelevant to how many choices you have on where you get your email, send your email, or host your web servers. Sure, it's convenient to be able to run all those things from your home Linux box, but if you want to do that, you'll probably find that your cable modem company and some of the DSL ISPs that your phone company supports might not permit that. There are hundreds or thousands of companies that run POP/IMAP mailbox services, and probably more that will host web sites, and that's not even getting into options like virtual hosting.
Not all ISPs are following BCP38 or the similar RFCs, but it's pretty straightforward for ISPs to do uRPF Reverse Path Filtering to block spoofed IP packets from their customers' routers, which block any packets claiming to be "from" an access line that they don't belong on. (Obviously it's more complex if your customer is an ISP, and a bit more complex if the customer is multiply homed.) This blocks most of the direct UDP and ICMP attacks, because it lets the recipient identify the source address and block it, and it prevents attackers from forging the victim's address in amplifier attacks (e.g. broadcasts "from" the victim that get big response traffic.)
Their definition of "Customers want stuff" is much different from, say, a mom&pop electronics store, or Weird Stuff Warehouse or HalTed Specialties.
Unfortunately, Fry's seems to have stopped carrying 10-hour VHS tapes. Sure, they were only "standard quality" instead of higher-end tape, but they worked really well for setting the VCR to record when you're going to be gone for a while.
Not being a UK Subject, I probably shouldn't buy the TShirt, but here in the US we've got our own problems with the RealID act giving us a real national ID card real soon unless we stop it.
/monster emerges from hat.
N: What we do with Moose and Squirrel?
Also, it's the kind of application where wimpy American-style canned beers work fine (or whichever of Labatt's or Molson in cheaper in Waterloo) - you want something cold and quick-drinking, not something like the Guinness I'm about to go open a bottle of :-)
If you live somewhere that it gets significantly colder at night than in the daytime, that works.