Sure, the Maglevs are great on test tracks - and Craig Breedlove's race cars go really fast in the Utah deserts, too, and Buck Rogers flying jetpacks are great for 30-second trips. But if you read your articles, neither Japan nor Germany is running the things carrying real passengers on real production train service, and the one at Birmingham Airport in the UK was closed down because it didn't work very well. They don't appear to be practical - the Osaka-Tokyo line hasn't been built yet because it would cost $60 Billion, which is high even for Japan, where high-visibility pork-barrel projects get lots of funding.
Heh. That Simpsons episode came out about the time Newark Airport ripped up all its parking lots to build a monorail. Eventually they finished it, after I'd moved to California, and the construction was much more annoying to parking lots used by locals than to rental cars; I don't know if it's better than the old busses were or not, but it's no real advantage for rental car users.
I lived in New Jersey in the 80s, and I'd frequently take the Metroliner to DC on business. (That was the fast train before the even faster Acela trains.) It took about the same time as flying, and was much much nicer, but didn't give me frequent flyer miles. Part of the time similarity was artificial - I lived about 15-30 minutes closer to the train than the airport, depending on traffic, and the train arrived in downtown DC, while National Airport is about 15 minutes south (by Metro), which was usually closer to where I was working.
But much of the time difference was because the airports are designed for hurry up and wait - huge parking lots that take time to get to the terminal, lots of waiting in line at the terminal, pre-terrorist security lines, paperwork lines. In DC the commuter flights were frequent enough that myboss and I would aim to arrive at the airport 20 minutes before the flight, leaving 10 minutes padding for a missed Metro connection, but normally you'd need to leave more than that.
By contrast, the train station has parking right next to the terminal, you stand in line behind 5-10 people to buy your ticket, boarding the train takes 1 minute instead of 20, and away you go. Coach seats on the Metroliner are about like first class on airlines (not that it was worth taking first class on the commuter flights), so you've got room to use your laptop, read, sleep, and look at the nice view. Also, the train was almost never late, while the airplanes often were delayed by weather.
Look at the link there, and the article on the Old Dominion fiasco. Yes, the Japanese train works very nicely on a test track. They've had 30,000 test passengers over N years. They're not running it as a fully-deployed production system, much less a profit-making one. It's very cute, but it's not even as practical as the Disney World Monorail.
If you've really got lots of rack-mount equipment, like routers and 1U servers, then get yourself a real rack, but if what you've got are mostly PCs in regular desktop tower cases, Metro Shelves and the like are really just as practical, and available in a much wider range of shapes and sizes. Either you can order the heavy-duty restaurant-quality stuff, or do what Michael Forman recommends in the parent article and check out a furniture store or the Container store, and get a pre-assembled unit with wheels.
What kind of video card should I use for PVR for analog cable service? Most of the discussion here seems to be about DirecTV and Digital Cable, but I still get my television the old-fashioned way....
When your computer's down, you want paper...
on
Linux Power Tools
·
· Score: 1
Sure, if your machine is up and running and does everything you need to be able to access the web, fine, but if you're trying to mess with the boot loader, or you're trying to reconfigure X Windows, or you're doing Stupid Firewall Tricks, you might not be able to read the documentation.
Also, books are nice objects, and you can get much more perspective while reading a book than reading on screen, and you've got a reasonable subset of everything you want at once.
What this sounds like to me is bureaucrats trying to be proactive to make sure that as Wifi gets widely deployed in China, that it starts out with some semblence of security up front, rather than deploying large amounts of non-secure equipment. Whether the WAPI standard is any good or not is a separate question - WEP was horribly broken, and the followon stuff that's trying to enable reuse of WEP components is probably not moving along fast enough for these bureaucrats.
Whether the bureaucrats involved will succeed at saying "we're a command economy, and the market will do what we tell it to" or not remains to be seen. Whether anybody outside China will end up making the equipment the bureaucrats are ordering everybody to use remains to be seen. If they don't, then either nobody in China will be able to deploy WiFi anywhere, or else everybody will ignore the bureaucrats and deploy world standard equipment anyway.
I know it can't work, but it would be really nice to have a Fake Relay Blocking List, so that ISPs who find your honeypot can look it up on the FRBL list and leave you alone, without spammers also looking it up and finding that you're hacking with them.
But if there *were*, you'd *want* to be listed on it so the spammers wouldn't bother you. But then the spammers would guess that you were a Fake Fake Relay, and try out your machines anyway, so you'd need to fake them out again by claiming to be a fake fake fake relay....
Maybe you spend some time detecting timeouts and avoiding hosts that don't respond quickly, but you can't overdo that or everybody will add that to their SMTP servers to discourage spammers. But even adding a second of delay at the end of a message is enough to crank your bandwidth drain down a lot and slow down the spammer's average load. And if the spammer is getting a 10:1 multiplier by feeding your relay 10 recipients per message, they won't be surprised if you're only accepting incoming spam at 10-12kbps because that'll fill up your average cable modem or ADSL upstream, and it'll happen by adding random delays to the response time. So go ahead and add a bunch of 100-200ms delays per packet (especially per RCPT TO or per line of message body, since SMTP handles data a line at a time.) If you want to add a bunch of longer delays, see how much you can get away with.
Unfortunately, there's some negative feedback here, because the kinds of people who'd run Linux and especially who'd run interesting applications like this one and who like attacking spammers tend to get their ISP service from clueful ISPs that are going to detect this kind of problem and work quickly to shut down spammer tools... The kinds of ISPs who don't care about it are usually the kind that you don't want to bother dealing with if you're more than a couch potato.
The ISPs that did this were trying to find anybody using SMTP at all, because that might be a *business*, and therefore should be paying them *much* more money than a home user, just as a few of the worst greedy cable modem companies blocked VPNs, and most of them block web servers because those might actual *gasp* use bandwidth. DSL providers that aren't run directly by local telcos are less likely to be that stupid, and some DSL providers have the clue that "Of *course* we'll let you do lots of interesting things with your bandwidth, that's why you're buying DSL."
Even @Home's employees mostly realized that Napster was one of the big reasons people bought broadband, so while their official corporate mantra was "Napster.. Bad... Destroy!", they were happy that it was around.
Open relays are an advantage to the spammer because they can dump one copy of the message lots of addresses to the relay and have _it_ expand them out to all the recipients, so they get a big multiplier effect as well as a layer of obfuscation. But if you only relay one message per spammer, there's no big multiplier effect, so there's not a lot of point in using a relay, and there's not significantly more spam in the world than if you didn't relay any. On the other hand, if you relay one or two messages and silently eat 100,000 more, there's lots less spam in the world.
And if your fake relay includes a bit of delay, say one second before responding to some of the messages, that spam will take a lot longer for the spammer to send out, reduce your bandwidth load, and (if you're tracing and robo-complaining to the spammer's ISP), give you longer to trace them before they vanish.
Teergrube is an anti-spammer tool that implements SMTP with long delays and occasional error messages, so spammers who hit a teergrube waste a bunch of their time waiting for ACKS instead of sending spam. (It's mainly intended for honeypot addresses, not real ones.)
You could apply the same kind of technique to spamhole - adding one second of delay per message to your SMTP responses is enough to drop a bunch of 3KB spams to about 24kbps (and almost all the bandwidth is inbound, so if you're on ADSL or cable modem with a slower upstream, it won't bother you, unlike a _real_ open relay which would be transmitting N copies of spam for each N-recipient message received.) More delay -> Lower bandwidth!, and you're wasting the spammer's time. You'd probably be better off adding a bunch of sub-second waits during the session rather than one long wait, in case it's checking for timeouts, or if you want to get fancy, don't do the waiting phase when you're giving the spammer their one free test message.
Open relays are an advantage to the spammer because they can dump one copy of the message lots of addresses to the relay and have _it_ expand them out to all the recipients, so they get a big multiplier effect as well as a layer of obfuscation. But if you only relay one message per spammer, there's no big multiplier effect, so there's not a lot of point in using a relay, and there's not significantly more spam in the world than if you didn't relay any. On the other hand, if you relay one or two messages and silently eat 100,000 more, there's lots less spam in the world.
And if your fake relay includes a bit of delay, say one second before responding to some of the messages, that spam will take a lot longer for the spammer to send out, reduce your bandwidth load, and (if you're tracing and robo-complaining to the spammer's ISP), give you longer to trace them before they vanish.
Some spammers write their own spamware, but most are just customers of spamware vendors, and most of those spammers are going to buy whatever spamware is best advertised, without worrying about every detailed feature. Most of the potential open relays out there today either accept the message and try to deliver it, or else refuse to relay and report a proper error message, so lots of the spamware won't even bother sending test messages to see if they're delivered, because getting a positive response from the suspected open relay is good enough. Some of the more sophisticated spamware probably does check, and the big professional spammers are more likely to have that, but it's going to cost more than dumb spamware and the anklebiters aren't going to bother paying extra for it. Sending _lots_ of test messages interspersed with the spam is yet another level of complexity. It's probably worth adding to high-level spamware, because it lets you test whether your relay is still open and unblocked _today_, but again, that's a fancier and more expensive feature than the anklebiters need, because they're going to 1) rip off a relay, 2) send their 10 million pieces of junk, 3)...., 4)Profit! (or not), and if step 4 doesn't happen, they'll eventually give up.
There's going to be some arms race with the spamware vendors, but running a zero-message threshold is good enough for a lot of the spammers today, and running a one-or-few-message threshold is good enough for a lot more, and unless spamholes become much more prevalent than genuine open relays, that's enough to kill most of the anklebiters and discourage some of the big vendors.
You don't really need the email addresses, because as another poster pointed out, many of them are forged. What you need are the IP addresses, and traceroutes to find one or two routers upstream to them, because that tells you what ISP the spammer is actually using, so the ISP can either whack their account (if they're a spammer) or get them to clean up their machine (if it's a hijacked zombie.) Sometimes that means the complaints go to the spammer themselves (so your spamhole gets outed), but if you're also hitting their upstream it's a good start.
If you want to get fancy, you can also do a couple of hits on any URL mentioned in the email - you shouldn't robo-complain, because spammers often put real email addresses in the spam as well, but it gets a bit of bandwidth drain, exercises all the URLs that the spammer might be getting clickthrough from (which is likely to get the clickthrough vendor to stop paying the web site or spammer), and generally shakes things up a bit.
If you're going to do logging, CD-ROM just doesn't cut it:-) You either need to use a hard disk, or else do your logging across a network. Alternatively, don't do logging, or only keep some summary logs in RAM.
There were a bunch of people at Stanford who built interesting network things with Ricochet - I think the project was called "Mosquito Net". You could either do point-to-point connections between pairs of them, or do "star mode" by feeding them the magic commands, but I never worked on them myself. They did have longer range than 802.11, so it's sometimes more useful, but of course they're not blazingly fast.
That's because it's raining too hard to see out....
My experience with Seattle weather has been better than its reputation - maybe 10% of my trips there have gotten rain, though I've also been there when there was lots of snow around, which was weird. But the stereotype is more like Scotland and Ireland -
If you can see across the bay, it'll be raining by tomorrow.
If you can't see across the bay, it's because it's already raining...
Twain's line about how the coldest winter he'd ever spent was a summer in San Francisco applies here, but for most of the area, there are a solid six months that the weather forecast doesn't change, and if you don't like the weather, drive 10 miles. It'll be 50s-60s and foggy by the coast, clearing by late morning, ~70 on the Bay side of the city, ~80 in Berkeley, 80-90 in Silicon Valley, ~90 in Walnut Creek,Concord, and Livermore, and 90-100 in the Central Valley.
"Weather reports" adjust this by at most 5-10 degrees, and adjust the fog times by a few hours, and maybe a dozen days in the season San Francisco will warm up to 80 or 90 because the wind did something weird. Eventually daylight savings time ends and it thinks about maybe raining, but it doesn't really do much of it until January and February, which are what passes for winter out here. If it's an El Nino year, the rain will last a bit longer in the spring.
Shamir's TWINKLE and TWIRL machines
on
RSA-576 Factored
·
· Score: 2, Interesting
Beowulf clusters aren't any threat to 1024-bit RSA - you're not going to put enough machines in a room to do the job, nor are you likely to put enough on the continent. On the other hand, for smart cards and cash machines and "export-approved" software with 512-bit keys in them, they're starting to really kick ass.
The real threat is Shamir's TWIRL and TWINKLE optical factorization-assistance gadgets. They aren't necessarily a threat to 1024-bit keys, but they're a definite threat to 768-bit keys, and it's time to start thinking seriously about threat models before embedding 1024-bit limitations in hardware. That's probably big enough that only national governments are likely to be funding, rather than bank robbers and other Mafiosi.
Quantum computers are too speculative at the moment, but they're the main new threat to near-exponentially-strong crypto algorithms. (Moore's law is theoretically a problem, but it can only continue for so long, and theoretical breakthroughs in the mathematics of factoring or a constructive proof of P=NP don't sound likely but could happen.) But they need to have a really high resolution to be any real threat at all - the Heisenberg limit of ~10**-47 only gets you ~150 bits, so you need to have large numbers of separate qubits coupled together to a be useful, rather than one highly-precise device.
For symmetric algorithms, like the DES family, at most they're expected to cut the number of bits of algorithm strength in half, so instead of 3-DES you might need to use 5-DES or 7-DES, which is only a minor annoyance. For key distribution, it does mean returning to systems based on key distribution centers, like Kerberos. That's a big loss of functionality, unless we find asymmetric algorithms that quantum computing can't break. I'm not aware of any results on whether elliptic curve algorithms are susceptible to Quantum Computers, though it's possible that that could also happen.
Darl says that the GPL opposes the Constitution, but then goes on to explain it by providing lots of details that entirely fail to be relevant. He can somewhat conclusively argue that RMS, the FSF, and Red Hat believe a bunch of tree-hugging hippie crap that's opposite to what he believes.
However, that's much different from what the GPL *does*, which is to use copyright law to attempt "To promote the Progress of Science and useful Arts" by making it easy to publish software that's free as in speech (with other positive side effects) and know that the software you're using is free so you can do even more things with it and not have to hire bunch of lawyers telling you that that it's safe to touch before adding value to it.
Re: BTW - Confusing WindRiver with WinDriver would be like confusing MacOS 9 with Mac OS9....
Slashdot Mirror
We tell the same joke in the phone company biz, except that "the man's job is to feed the dog".
Sure, the Maglevs are great on test tracks - and Craig Breedlove's race cars go really fast in the Utah deserts, too, and Buck Rogers flying jetpacks are great for 30-second trips. But if you read your articles, neither Japan nor Germany is running the things carrying real passengers on real production train service, and the one at Birmingham Airport in the UK was closed down because it didn't work very well. They don't appear to be practical - the Osaka-Tokyo line hasn't been built yet because it would cost $60 Billion, which is high even for Japan, where high-visibility pork-barrel projects get lots of funding.
Heh. That Simpsons episode came out about the time Newark Airport ripped up all its parking lots to build a monorail. Eventually they finished it, after I'd moved to California, and the construction was much more annoying to parking lots used by locals than to rental cars; I don't know if it's better than the old busses were or not, but it's no real advantage for rental car users.
But much of the time difference was because the airports are designed for hurry up and wait - huge parking lots that take time to get to the terminal, lots of waiting in line at the terminal, pre-terrorist security lines, paperwork lines. In DC the commuter flights were frequent enough that myboss and I would aim to arrive at the airport 20 minutes before the flight, leaving 10 minutes padding for a missed Metro connection, but normally you'd need to leave more than that.
By contrast, the train station has parking right next to the terminal, you stand in line behind 5-10 people to buy your ticket, boarding the train takes 1 minute instead of 20, and away you go. Coach seats on the Metroliner are about like first class on airlines (not that it was worth taking first class on the commuter flights), so you've got room to use your laptop, read, sleep, and look at the nice view. Also, the train was almost never late, while the airplanes often were delayed by weather.
Look at the link there, and the article on the Old Dominion fiasco. Yes, the Japanese train works very nicely on a test track. They've had 30,000 test passengers over N years. They're not running it as a fully-deployed production system, much less a profit-making one. It's very cute, but it's not even as practical as the Disney World Monorail.
If you've really got lots of rack-mount equipment, like routers and 1U servers, then get yourself a real rack, but if what you've got are mostly PCs in regular desktop tower cases, Metro Shelves and the like are really just as practical, and available in a much wider range of shapes and sizes. Either you can order the heavy-duty restaurant-quality stuff, or do what Michael Forman recommends in the parent article and check out a furniture store or the Container store, and get a pre-assembled unit with wheels.
What kind of video card should I use for PVR for analog cable service? Most of the discussion here seems to be about DirecTV and Digital Cable, but I still get my television the old-fashioned way....
Also, books are nice objects, and you can get much more perspective while reading a book than reading on screen, and you've got a reasonable subset of everything you want at once.
Whether the bureaucrats involved will succeed at saying "we're a command economy, and the market will do what we tell it to" or not remains to be seen. Whether anybody outside China will end up making the equipment the bureaucrats are ordering everybody to use remains to be seen. If they don't, then either nobody in China will be able to deploy WiFi anywhere, or else everybody will ignore the bureaucrats and deploy world standard equipment anyway.
But if there *were*, you'd *want* to be listed on it so the spammers wouldn't bother you. But then the spammers would guess that you were a Fake Fake Relay, and try out your machines anyway, so you'd need to fake them out again by claiming to be a fake fake fake relay....
Maybe you spend some time detecting timeouts and avoiding hosts that don't respond quickly, but you can't overdo that or everybody will add that to their SMTP servers to discourage spammers. But even adding a second of delay at the end of a message is enough to crank your bandwidth drain down a lot and slow down the spammer's average load. And if the spammer is getting a 10:1 multiplier by feeding your relay 10 recipients per message, they won't be surprised if you're only accepting incoming spam at 10-12kbps because that'll fill up your average cable modem or ADSL upstream, and it'll happen by adding random delays to the response time. So go ahead and add a bunch of 100-200ms delays per packet (especially per RCPT TO or per line of message body, since SMTP handles data a line at a time.) If you want to add a bunch of longer delays, see how much you can get away with.
Unfortunately, there's some negative feedback here, because the kinds of people who'd run Linux and especially who'd run interesting applications like this one and who like attacking spammers tend to get their ISP service from clueful ISPs that are going to detect this kind of problem and work quickly to shut down spammer tools... The kinds of ISPs who don't care about it are usually the kind that you don't want to bother dealing with if you're more than a couch potato.
The ISPs that did this were trying to find anybody using SMTP at all, because that might be a *business*, and therefore should be paying them *much* more money than a home user, just as a few of the worst greedy cable modem companies blocked VPNs, and most of them block web servers because those might actual *gasp* use bandwidth. DSL providers that aren't run directly by local telcos are less likely to be that stupid, and some DSL providers have the clue that "Of *course* we'll let you do lots of interesting things with your bandwidth, that's why you're buying DSL."
Even @Home's employees mostly realized that Napster was one of the big reasons people bought broadband, so while their official corporate mantra was "Napster .. Bad... Destroy!", they were happy that it was around.
Open relays are an advantage to the spammer because they can dump one copy of the message lots of addresses to the relay and have _it_ expand them out to all the recipients, so they get a big multiplier effect as well as a layer of obfuscation. But if you only relay one message per spammer, there's no big multiplier effect, so there's not a lot of point in using a relay, and there's not significantly more spam in the world than if you didn't relay any. On the other hand, if you relay one or two messages and silently eat 100,000 more, there's lots less spam in the world.
And if your fake relay includes a bit of delay, say one second before responding to some of the messages, that spam will take a lot longer for the spammer to send out, reduce your bandwidth load, and (if you're tracing and robo-complaining to the spammer's ISP), give you longer to trace them before they vanish.
You could apply the same kind of technique to spamhole - adding one second of delay per message to your SMTP responses is enough to drop a bunch of 3KB spams to about 24kbps (and almost all the bandwidth is inbound, so if you're on ADSL or cable modem with a slower upstream, it won't bother you, unlike a _real_ open relay which would be transmitting N copies of spam for each N-recipient message received.) More delay -> Lower bandwidth!, and you're wasting the spammer's time. You'd probably be better off adding a bunch of sub-second waits during the session rather than one long wait, in case it's checking for timeouts, or if you want to get fancy, don't do the waiting phase when you're giving the spammer their one free test message.
And if your fake relay includes a bit of delay, say one second before responding to some of the messages, that spam will take a lot longer for the spammer to send out, reduce your bandwidth load, and (if you're tracing and robo-complaining to the spammer's ISP), give you longer to trace them before they vanish.
There's going to be some arms race with the spamware vendors, but running a zero-message threshold is good enough for a lot of the spammers today, and running a one-or-few-message threshold is good enough for a lot more, and unless spamholes become much more prevalent than genuine open relays, that's enough to kill most of the anklebiters and discourage some of the big vendors.
If you want to get fancy, you can also do a couple of hits on any URL mentioned in the email - you shouldn't robo-complain, because spammers often put real email addresses in the spam as well, but it gets a bit of bandwidth drain, exercises all the URLs that the spammer might be getting clickthrough from (which is likely to get the clickthrough vendor to stop paying the web site or spammer), and generally shakes things up a bit.
If you're going to do logging, CD-ROM just doesn't cut it :-) You either need to use a hard disk, or else do your logging across a network. Alternatively, don't do logging, or only keep some summary logs in RAM.
There were a bunch of people at Stanford who built interesting network things with Ricochet - I think the project was called "Mosquito Net". You could either do point-to-point connections between pairs of them, or do "star mode" by feeding them the magic commands, but I never worked on them myself. They did have longer range than 802.11, so it's sometimes more useful, but of course they're not blazingly fast.
My experience with Seattle weather has been better than its reputation - maybe 10% of my trips there have gotten rain, though I've also been there when there was lots of snow around, which was weird. But the stereotype is more like Scotland and Ireland -
"Weather reports" adjust this by at most 5-10 degrees, and adjust the fog times by a few hours, and maybe a dozen days in the season San Francisco will warm up to 80 or 90 because the wind did something weird. Eventually daylight savings time ends and it thinks about maybe raining, but it doesn't really do much of it until January and February, which are what passes for winter out here. If it's an El Nino year, the rain will last a bit longer in the spring.
The real threat is Shamir's TWIRL and TWINKLE optical factorization-assistance gadgets. They aren't necessarily a threat to 1024-bit keys, but they're a definite threat to 768-bit keys, and it's time to start thinking seriously about threat models before embedding 1024-bit limitations in hardware. That's probably big enough that only national governments are likely to be funding, rather than bank robbers and other Mafiosi.
For symmetric algorithms, like the DES family, at most they're expected to cut the number of bits of algorithm strength in half, so instead of 3-DES you might need to use 5-DES or 7-DES, which is only a minor annoyance. For key distribution, it does mean returning to systems based on key distribution centers, like Kerberos. That's a big loss of functionality, unless we find asymmetric algorithms that quantum computing can't break. I'm not aware of any results on whether elliptic curve algorithms are susceptible to Quantum Computers, though it's possible that that could also happen.
However, that's much different from what the GPL *does*, which is to use copyright law to attempt "To promote the Progress of Science and useful Arts" by making it easy to publish software that's free as in speech (with other positive side effects) and know that the software you're using is free so you can do even more things with it and not have to hire bunch of lawyers telling you that that it's safe to touch before adding value to it.
Re: BTW - Confusing WindRiver with WinDriver would be like confusing MacOS 9 with Mac OS9....