It's dangerous to have any kind of headset while driving. You need to be able to hear sounds from the traffic around you, and using any earpiece (even an earpiece that covers only one ear) will block those sounds.
I suggest installing a real handsfree kit.
It typically includes a dedicated speaker aimed directly at you (not going through your car radio), and a handsfree microphone near your head. The microphone should have a built-in echo canceler, tuned to match the speaker, so you can talk without the "hollow barrel" effect of traditional speakerphones.
Then, you can leave the cellphone in its cradle, and freely talk without being encumbered by any wires or doodads around your head. If there's an emergency on the road around you, you will still hear it. And, the cellphone will stay charged up while it's in the cradle!
Getting a dedicated handsfree kit is definitely the way to go. I don't have one, because I don't plan on keeping my phone or my car for very much longer. Because of the expense involved, it's wise to only install a dedicated handsfree kit when you know you'll be getting a lot of use out of both the phone and the car, since they become a matched set after the kit is installed.
Wow, I just read the page and read yet a third variant on this text. Here's what I saw.
Important message from Belkin:
In response to a recent Usenet group posting stating that Belkin spams its customers through its routers, Belkin Corporation apologizes for the concern this has caused and is taking action to address the issue. To allay customers' worries, Belkin will offer a firmware upgrade that will be available via download from its website (www.belkin.com) on November 17, 2003. This upgrade will rid the redirect completely so that no additional browser windows will appear during the router's installation process. Questions can be directed to our dedicated networking customer support line at 877-736-5771 or e-mailed to kannynmc@belkin.com.
Notice that there's 2 gotchas in here:
1) It won't be available until 11/17. One full week of more Belkin spam.
2) It only mentions removing extra browser windows during the installation process. This isn't the concern of many. The concern is the hijacking of a random outgoing HTTP connection every 8 hours, redirecting it to the Belkin spam page! They don't mention removing this. Instead, they only mention removing a popup from the installation process (which is typically only done once, and a lot less annoying than the 8-hour-repeating spam that was the main issue in the first place).
I have avoided Belkin products for some time now, because of abysmal experiences using their KVM switches. Wretchedly poor products that often lock up completely and require you to reboot all machines connected to them! Not good, if in a server environment. Switched to Iogear KVM switches and never looked back! Belkin also hides the true cost of their KVM switches by forcing you to buy connector cables separately at an extra price, whereas Iogear kindly includes the cables.
The vandal who put this in the CVS code tree obviously had a lot of skill.
It's a clever backdoor, and might have gone unnoticed, if not for those those good automated checks in the BitKeeper-to-CVS gateway. Notice that the particular coding style is a common C gotcha (using "=", assignment, instead of "==", comparison). At first glance it looks like the value of uid is being compared with 0, when in actuality it is being assigned the value of 0: root! The gcc compiler is good about warning for this, except that this too has been defeated: as mentioned on the mailing list, notice the unusual high number of parenthesis around this expression. That high number of parenthesis has the effect of suppressing the gcc compiler warning.
So, whoever did this obviously knew what they were doing and tried to obfuscate it. As somebody else mentioned on the kernel mailing list, if somebody is going to put in a backdoor like this, why not make it a remote root hack?
As it is now, the above hack is only locally exploitable. A process on the local system still has to call the wait system call with that particular combination of flags, in order to trigger the exploit and get root. To my knowledge, no known applications do this, because the combination of flags is supposed to be invalid.
If a spammer or somebody else was trying to backdoor the Linux kernel in order to gain a large number of machines to infest, then one wonders why they didn't put in a remote root exploit. It seems strange to go to all the trouble. Since this backdoor attempt has been caught and blocked, security will now only become tighter, and they might not ever get another chance like this.
Maybe it was intended to be used with another application, also backdoored in the same manner? It might be insightful to scan other open source applications and search for this particular usage of flags to the wait system call.
The very idea of detecting spam during SMTP reception, and then deliberately slowing down response time in an effort to frustrate/deter spammers, has been discussed before.
Your joke actually has a ring of truth in it: did you know that for Baldur's Gate 1, you could actually buy a reduced version of the game (containing only the first one or two discs) for a lower price?
It would "end" about midway through the plotline of the full game, and not have as many areas to explore. I would imagine it sold poorly, because they didn't retry this idea for Baldur's Gate 2.
That's nothing compared to India. There, many publishers of standard textbooks publish the same book at a steeply discounted price. This is to match local standards of living (the same reason for the much-discussed salary gap).
I saw such classic CS books as K&R and UNPv1, published as "Eastern Economy Edition". The Indian person who owned the books said that they were bought for the equivalent of around $5 each! They are softcover, printed on really cheap paper (thin and not pure white), and generally produced as cheaply as possible in order to meet the low price. The page size is also reduced.
http://www.niyam.com/writing/iconoclasts/niyamac ma y2k.html http://people.csa.iisc.ernet.in/~siddu/b ib/cs.html http://www-scf.usc.edu/~india/newstudentletter.h tm
I was jealous, and wished I had been able to get books at that price during school. The content is exactly the same! Too bad there isn't an Amazon.co.in....
I agree that it would be good to have the initial warning message generated after 30 minutes. Or, perhaps after only 5-15 minutes! Since 99.9% of all email messages reach their destinations instantly (usually in a matter of seconds), alerting users to unusual behaviour is a good thing.
As was said by others, the purpose of this short timeout is to give the user a chance to try other methods of communication (FAX, phone, carrier pigeon, etc.). By holding the warning message until 24 hours or more have elapsed, the user's attention will have gone on to other things and they will begin to erroneously assume that the email has already safely arrived.
However, the hard timeout, at which the SMTP server gives up trying to forward the message, should remain at 4 days or more. I've had servers go down for a few days, typically a weekend upgrade, and it's great to be able to bring them back up without bouncing anybody's email messages. Reducing the hard timeout would just put more of a burden on everybody else to get their servers back up before the hard timeouts expire. It's hard enough to guarantee bringing up a system in 4 days after a disaster, and some want to make it only 1 day?!
Perhaps a third timeout should be added: something between the soft timeout and the hard timeout. I can see having timeouts of 15 minutes, 24 hours, and 4 days. At the middle timeout (24 hours), a second warning message would be generated for the sender, to further let them know that their message has been delayed. This keeps up the "three strikes" tradition of having the first two error messages be only warnings, and only the third email message is a true error (containing the bounced message).
A bit jealous, are we? Nevertheless, it is almost impossible to find another job in just two months in this economy. I'm still looking. There's lots of other people in the same boat, and being out of work for many months at a time is no longer the stigma that it once was during the boom. Employers do understand. I do have plenty of savings, for now, but want to stretch it as long as possible.
I don't like sitcoms and never have watched Seinfeld... but B5 and Buffy, ah!
I was fired in a good way, if such a thing is possible.
It was not really a surprise. I could see it coming. Others had been fired before me, as the company slowly nibbled away at us. I was one of the last non-Indian people in the department. I'm not being racist here: in fact, it was an Indian who helped me to get this job in the first place! I'm not blaming the Indians at all for this, and in fact, two of my best leads for finding another job are through Indian managers or owners. There's no denying the simple economic difference in wages between India and the USA, though.
They did a really cool thing for some H1-B Indians who would also be affected by the layoff, though: in lieu of being laid off, the company gave them the option of returning to India for a guaranteed job at the company's Indian office, paying local India wages (much less than USA wages, even for H1-B's). Many Indians took this option, including my boss. The layoff was across-the-board, affecting Indians as well as USA citizens, but USA citizens bore the brunt of the layoff. I believe that the company was preparing to transfer the entire office to India eventually, so they were taking steps in this direction, and it would have been only a matter of time.
My boss simply called me into his office, shut the door, and that was that. It was not a surprise to me, because I could see it coming for several weeks. On the same day I was fired, about 20% of the company was also fired! This is a company that had about 1000 workers at the time, so it wasn't a small layoff by any means. There was extra security around, but no harassment. They had brought in lots of cardboard boxes for packing. I was able to back up all of my personal stuff (bookmarks, etc.) that was on their computers, and burn a CD to take it home with me. In fact, they let us work through the end of the pay period (several more days)!
Because they were kind, I was kind to them in return. I cleanly documented things I was working on at the time, and organized things in such a way that anybody coming in would be immediately able to find what they were looking for (I was in charge of an internal Linux distribution at the time). When it came time to go, I said my goodbyes, gathered as much contact information from my coworkers as possible, left my contact information, gave my card to my boss, and walked out. No unpleasantries at all.
And the best part? The company was later called on the carpet for violating the WARN Act, so they ended up having to give everybody 60 extra days on the payroll! The WARN Act requires 60 days of notice before a large layoff, and since they failed to do this, they had to make up the 60 days. It was wonderful to get a mini-sabbatical of two months of full pay for sitting around at home and resting! Nice.
Now, unfortunately, the savings is beginning to run a bit thin so I'm looking for another job... not much to be found....
Locality-based sites already exist, and are eager for location-based advertising as you suggest. Here's one of the better ones (and quite possibly the very first one):
There's a thriving community of people here, who swap recommendations for services such as plumbers and veterinarians. It's essentially a nationwide message board that filters by distance from you to the poster, so you end up only seeing the very few posts that are pertinent to your location. Advertisements are also filtered by the relevancy of their location to you. A nice idea that seems to work well!
It would be trivially easy to code up software to monitor this on the client side, if statistics were made available from the ISP (perhaps by using SNMP to get counts of bytes transmitted/received). However, like other people said, it would be hard for the ISP to actually enforce these limits without putting a huge burden on the router's CPU. Perhaps a person working for a packet shaper company is reading this post, and can put this in hardware?:)
It ISP's would use the "toilet tank" idea to limit the amount of data that a customer can produce/consume, then it would singlehandedly solve the problem of certain customers eating too much bandwidth. There wouldn't be a need to limit the customer's ability to run servers, or block certain ports, or do anything else to limit the transparency and usefulness of a connection.
The ISP could offer several tiered pricing levels, letting customers choose the size and refill speed of their own "toilet tank". Perhaps letting people freely run servers would be the best way to promote the higher tiers! After noticing the increase in traffic from a popular server, and the slowdown that results from their tank being depleted, a customer would then have a powerful incentive to upgrade to a higher tier.
I can even see an ISP setting up partnerships with other companies that want customer eyeballs, such as big media companies, by offering to make the sites of those companies exempt from the "toilet tank" rationing system. Customers would be encouraged to see things on those sites, since they would remain at full speed no matter how much they viewed.
This idea could truly be a great idea for the ISP that chooses to run with it!
Good, I wasn't the first to think of this. I first read about the "toilet tank" analogy in an article somewhere (probably broadbandreports.com) that mentioned DirecPC's FAP. I tried to search for that article again but was unsuccessful. The idea is a good one, but FAP is so nasty and Draconian that it gave the idea a bad reputation.
Like all ideas to ration Internet access, the "toilet tank" idea is certainly unpopular, but it is far better than some of the hairbrained schemes that large media companies have recently been doing: cutting off people entirely, forcing people to wait until certain times of the day/month, surprising people with huge bills or nastygrams mailed to them, and so on....
Good article but glosses over most important part
on
Booting Linux Faster
·
· Score: 1
It is a good article, but it glosses over the most important part: in order to successfully boot up your system faster using parallel processes, you must first resolve all dependencies.
This isn't easy, because it's a nontrivial problem to tell exactly what services a given process relies on and assumes to already be existing at the time the service is started. Also, some scripts start off daemons in the background and then return immediately! If another service depends on having this daemon running, it would need to know to wait for that daemon to finish initializing.
What would be great is to have all future init.d files adhere to a convention in which they could list what they provide and what else they depend on, kind of like what the RPM database already does. It would look something like this:
This example would be for a daemon that requires two services to be running, and provides a service of its own that other daemons can depend on. This could be used to resolve initialization dependencies and make the system boot faster. Note that the service names are abstract, not corresponding to any particular daemon, so that replacement daemons could easily be swapped in to do the same job.
I would be surprised if new distributions haven't already thought of this or didn't already have such a system in place!
I wouldn't mind seeing bandwidth capping on my line if they did 3 things to make it fair.
1) Use the "toilet tank" method of capping people, instead of completely cutting them off entirely. This method has been deployed in several places, and people of course don't like it, but it is the fairest system that has been devised so far. Unlimited downloading (or uploading) is allowed, up to a point. When that point is reached, downloading will continue, but at a dramatically lower speed. The download will not be interrupted, but it will be capped to that lower speed. If the customer stops downloading for a period of time, they will re-earn the right to download at a higher speed, as their toilet tank slowly refills over time. This system also doesn't require strict time intervals (such as 24 hours, 1 month, etc.), because it is both triggered and released by the user's behaviour. If the user voluntarily downloads at a speed slower than the top speed, they can stretch out the length of time during which they can enjoy a noncapped connection. This is a good system because it has its intended effect (keeping high-volume users from abusing the service for everybody else) while not punishing people by cutting them off entirely or charging them a huge bill (important for cases in which the user isn't to blame for the high bandwidth usage, such as a virus or a Slashdotting). Also note that uploads and downloads are treated separately and independently, with a different toilet tank for each.
2) Make it clear what the cap level is, for both upload and download, including both the capped speed and the "toilet tank" size. Include this both in customer contracts and advertisements to non-customers. Advertising a connection as "unlimited" is false, when it could be capped! An example of an acceptable service description that could be advertised would be "1.5mbps download (capped 1GB/64kbps) and 256kbps upload (capped 128KB/64kbps)". This refers to a system that would have a toilet tank size of 1GB for downloads, after which the download speed would be reduced to a mere 64kbps. At this speed, it would take roughly 36 hours to refill the toilet tank once drained, but the user could still use their connection during this time (they just wouldn't be able to download another full 1GB without hitting the cap again). There's another similar toilet tank for uploads.
3) Provide tools for the user to monitor their current bandwidth usage, and how it applies against the cap. At the minimum, this should include both a live program that can be installed on the user's computer, and a webpage that can be visited occasionally should the user not wish to keep an extra program running. I would set that webpage as my homepage! The program would display the user's current usage and the threshholds at which capping would occur, and the current fill level of the "toilet tank". It should be made absolutely clear to the user what is going on, and how their current behaviour affects their cap, so there will be no guessing or finger-pointing.
I currently use DSL, not cable, because my connections are largely two-way. I do just as much uploading as downloading (no P2P, just old fashioned stuff like web servers), and cable companies are hostile towards uploaders and servers. The reason I use DSL is because so far my ISP (SBC) has not instituted any unfair caps! If they were to cap the line in an unfair way, I would be screwed, because I can't switch to cable. A friend of mine eats the cost of having a full T1 to his house. Maybe I'd have to do the same?
Wow, this is the first real reason I have for wanting to restrict outgoing connections from my own network. 100% typosquatting is just disgusting.
I don't want Verisign getting any data on what domains I mistype, and I don't want applications (such as email) breaking when users mistype an address. I don't want my outgoing email being intercepted by Verisign! Even if they say they'll set up a dummy SMTP server to generate error messages and bounce the mail, I don't trust them.
It might be a good idea to make a daily cron job to look up the IP address of Verisign's wildcard, and add that to the list of banned IP addresses (no data allowed, not only for incoming but also for outgoing as well).
I remember that as being a very hard dungeon, back when I played the game about 13 years ago.
My best advice is to make sure you've got enough experience (at least 6400 points) to have all of your 8 characters at level 8. You will also need to max out the ability scores of each character, as far as their classes will allow. Play the dungeon of anti-Spirituality (Hythloth), as it has the most efficient orbs that will raise all 3 of your character's statistics at once.
If you have trouble leveling up your weaker characters (the strong characters always seem to get the best hits and kill the monsters first), then equip them with Magic Wands or other distance weapons, and simply pass (hit the spacebar) when controlling your stronger characters. Then, the weaker characters will be able to get in some kills. Upgrading weak characters is vital, especially for characters that can cast magic: you want to have each character able to cast Resurrect, in case you lose all of your strong characters during a battle and only a weak character is left alive!
When your characters are all upgraded as far as they can be, mix up LOTS of spells with your reagents. Take in 99 Heal and 99 Resurrect, at a minimum, and lots of others you will find useful. Max out the reagents as well, so you can brew 99 more spells as needed!
This should be enough firepower to get you through the dungeon. Use a walkthrough if you need maps to help you along the way, or if you get stumped by the riddles that are asked at various times.
BTW, the best version of Ultima IV is the one for its home platform: Apple ][! This version has great music, with the Mockingboard, something that is inexplicably lacking from the PC version. Play it with an emulator, instead of worrying about how to get your PC backward-compatible enough to actually run the native game on the PC.
I still think this game is the BEST EVER RPG of ALL TIME (even beating out newer games such as Baldur's Gate)!
From the client side, Microsoft is already collecting every mistyped URL and substituting their own search engine!
In MSIE, a hostname that is not found will be sent to Microsoft. A page will be auto-generated, containing links to similar hostnames, and the Microsoft MSN search engine.
Microsoft is already receiving this information. I'm sure that there is a high commercial value in knowing the exact data on which domains are mistyped the most often! I would be surprised if Microsoft doesn't use this information internally, or resell it to the highest bidder.
Since MSIE is 90% of the installed browser base, I would be very surprised if server-side information on mistyped domains (as Verisign is logging) is very different from client-side information. The client-side information might even be more accurate, due to intermediary DNS servers doing caching of negative results!
Does anybody know for sure what Microsoft is doing with their large database of mistyped domains?
Was former Netgate customer
on
Hacking By Subpoena
·
· Score: 2, Interesting
There's a reason I'm not a Netgate customer anymore.
They were a fine ISP when I used them several years ago, having good dialin numbers (these were the days before easy broadband access) and reasonable prices. They didn't have any technical problems to speak of. They even had really good USENET access (I used to post a ton from krellan@netgate.net, Google it).
However, Netgate's social/legal policies really stank.
At the time, for example, they had agreed to host godhatesfags.com. So, I left.
It wouldn't surprise me now to see them overzealously comply with a subpoena, hurting their own customers in the process.
I still think it's really cheap of hosting companies to not warn their customers when receiving legal action against them (except when the DMCA actually requires that they not warn, yet another reason why it's such a scary law).
Basically, the author does triage. There are 3 types of people: those who will always pay, those who will never pay (pirates), and those who might pay. He focuses on trying to convince the latter group, and doesn't waste time with copy protection schemes that will just annoy the honest users and not stop the pirates.
How long is it until someone makes a quick patch to LAME (or other popular open-source MP3 encoder) to slightly randomize the VBR bitrate decisions?
In a typical VBR song, the bitrate changes so fast that changing the bitrate of a few blocks would be unnoticeable. It would have practically no effect on the sound quality. Oftentimes, a block will be right on the edge, say between 112 and 128 kbps, and the encoder will have to make a decision on which one to use. Currently, the encoder just follows the same strategy each time, rounding off to the nearest bitrate. A patch could make it random, instead of deterministic. Nobody would know the difference, and then each and every MP3 generated by the encoder would have a completely different MD5 hash, even when using the same source material!
Come to think of it, this technique could also be used for tracking of purchased MP3 music. Every time a customer downloads a purchased track from an online music store (like iTunes), the MP3 could be generated on the fly, and slight variations could be introduced in the VBR bitrates. This could be used to embed a "serial number" into each MP3 track. Then, when the track shows up on Kazaa or whatever, it could instantly be traced and the person who leaked it would be known! That would strongly discourage people from leaking purchased music.
I'd be very surprised if this isn't already being done... surely I can't be the first person who has thought of this....
That's pretty nasty that Netgear would hardcode a NTP time server into their product, without even telling U-Wisc about it.
When I configure my computers to use someone else's NTP server, I always send them an email to let them know (or whatever else they request that people do).
What's worse is that Netgear hardcoded the address, in a way that can't easily be changed without a firmware upgrade (something that very few of the intended Netgear firewall customers will do: these customers are looking for a plug-it-in-and-forget-it box, and are either unwilling or unable to learn how to set up a firewall box themselves). And then, on top of that, Netgear botches the implementation of the protocol, causing it to rapid-fire out requests in certain circumstances!
NTP is a very, very low-profile protocol. It uses UDP, so that connection state doesn't have to be maintained. It sends out packets very rarely, at most every few minutes while being set up, and then once time has been established and clocks are in sync, roughly one packet every few days. Netgear's botched programming caused a NTP flood of one packet per second! This is a ridiculous rate several orders of magnitude above what is normally seen in a functioning NTP implementation.
And Netgear sold hundreds of thousands of these things....
I'm amazed that U-Wisc put up with this effective DoS attack on their servers for so long. They showed great patience waiting several months for their request to crawl through Netgear's channels. Companies really need to have a quick method of access into their corporate structure for people who report major flaws like this! Because Netgear's traditional channels of customer feedback (tech support, etc.) weren't set up for this, U-Wisc's requests kept getting lost in Netgear's bureaucracy. Is Netgear so arrogant to believe that all of their products are and will always be 100% flawless?
There really needs to be a special method of access when people report security holes and such. Microsoft, surprisingly, is starting to come around with this, maintaining a special point of contact for people who have discovered security-related issues or major flaws like this. I hope that more companies do this in the future.
If Netgear would do these three things, I would be happy:
1) Set up their own NTP master servers (stratum 1, using a GPS receiver or atomic clock), at Netgear itself. They would use Netgear's own bandwidth, not U-Wisc or anyone else's. Netgear's future products would then default to using these servers, and they would put out a patch so that hopefully some fraction of older products would also use these servers. That way, if there is a flaw in the future, Netgear will eat their own dogfood! I am pleased to see that Netgear is already taking steps in this direction.
2) Change their corporate structure to be more receptive to outsiders who report serious design flaws or major issues caused by their products (such as this NTP flood), going beyond normal tech support, so that quick action can be taken to avert damage. Tech support is really only set up to handle questions about an individual device owned by the person calling in about it, and not set up to handle serious technical or security issues about all devices in an entire product line.
3) Reimburse U-Wisc for the cost of banwidth consumed by these buggy Netgear devices. If U-Wisc isn't blocking incoming NTP entirely by now, pay for robust NTP servers to handle the high volume of traffic. If Netgear had targeted pretty much any private company instead of U-Wisc, I'm sure they would have sued for damages by now!
And remember, ask first before using someone else's NTP server, especially if you plan to hardcode the address into your product:)
I used to use FSP. I even hacked the source to dramatically shorten the time delay it waits between sending requests for data, to get faster service:)
There were 2 main reasons to use FSP:
1) It used UDP, not TCP. Many monitoring/logging tools and firewalls back in the day only really had a tight control on TCP. Using UDP was a good way to slip under the wire.
2) It deliberately kept its data rate very small. Something on the order of 2K per second. Even with a hacked client, the server simply wouldn't send data any faster than a certain cutoff point, and ignored any requests that came in faster than that. This data rate throttling was done, again, to help stay under the radar. Many sites were detected only because a huge upward spike in consumed bandwidth was noticed. Using FSP, a site could stay up for a much longer period of time before being caught and deleted.
Nowadays, we all have great P2P applications to make good use of UDP, and bandwidth usage is usually adjustable on them, so the main reasons to use FSP have gone away. Good riddance, I say, as it was truly a terrible protocol (think of XMODEM over IP)!
This has been mentioned before,
here on Slashdot, but not in this negative context. Previously, people just thought of Microsoft's newsgroup tracking as a curiosity, and not something with an ulterior motive.
USENET is losing its relevance these days, unfortunately, due to spammers and the difficulty of creating new groups to keep up with current trends. Most message-based chat nowadays takes place on innumerable topic-specific websites running "bulletin board" software such as
YaBBSE. It might be a little too late to do anything to USENET now, either good or bad....
It is highly recommended that checksums be stored on a different server!
Many high profile sites surprisingly do not do this.
By keeping checksums separate from the files themselves, it makes the cracker's job more difficult, because they will have to crack two machines in order to Trojan a file. It is also recommended that these two machines be running different operating systems, such as Linux and OpenBSD, so that an exploit affecting one will hopefully not also affect the other.
If only one server is compromised and the files or the checksums are changed, but not both, people will be able to detect this by the mismatched sums. When the checksums are on the same server as the files themselves, the cracker can replace the checksums at the same time as the files, and nobody will know that the files have been compromised.
Also, GPG keys should be used to put some cryptography into guaranteeing that the files haven't been tampered with. The cracker will have to forge a GPG signature, much more difficult than regenerating a checksum. I am glad to see that the GNU project will do this for future files, to help prevent a situation like this from happening again. Of course, the GPG public keys should be on a different server than the signed files!
Slashdot Mirror
Funny that you should mention MP3's. I looked at AskIgor's site, and a key patent for their technology is owned by... Fraunhofer!
n t
http://www.st.cs.uni-sb.de/askigor/faq.php#pate
I'd look at their technology and admire it, but keep a good distance away, unless you want to get shaken down for huge sums of money at a later date!
It's dangerous to have any kind of headset while driving. You need to be able to hear sounds from the traffic around you, and using any earpiece (even an earpiece that covers only one ear) will block those sounds.
I suggest installing a real handsfree kit.
It typically includes a dedicated speaker aimed directly at you (not going through your car radio), and a handsfree microphone near your head. The microphone should have a built-in echo canceler, tuned to match the speaker, so you can talk without the "hollow barrel" effect of traditional speakerphones.
Then, you can leave the cellphone in its cradle, and freely talk without being encumbered by any wires or doodads around your head. If there's an emergency on the road around you, you will still hear it. And, the cellphone will stay charged up while it's in the cradle!
Getting a dedicated handsfree kit is definitely the way to go. I don't have one, because I don't plan on keeping my phone or my car for very much longer. Because of the expense involved, it's wise to only install a dedicated handsfree kit when you know you'll be getting a lot of use out of both the phone and the car, since they become a matched set after the kit is installed.
Wow, I just read the page and read yet a third variant on this text. Here's what I saw.
:)
Important message from Belkin:
In response to a recent Usenet group posting stating that Belkin spams its customers through its routers, Belkin Corporation apologizes for the concern this has caused and is taking action to address the issue. To allay customers' worries, Belkin will offer a firmware upgrade that will be available via download from its website (www.belkin.com) on November 17, 2003. This upgrade will rid the redirect completely so that no additional browser windows will appear during the router's installation process. Questions can be directed to our dedicated networking customer support line at 877-736-5771 or e-mailed to kannynmc@belkin.com.
Notice that there's 2 gotchas in here:
1) It won't be available until 11/17. One full week of more Belkin spam.
2) It only mentions removing extra browser windows during the installation process. This isn't the concern of many. The concern is the hijacking of a random outgoing HTTP connection every 8 hours, redirecting it to the Belkin spam page! They don't mention removing this. Instead, they only mention removing a popup from the installation process (which is typically only done once, and a lot less annoying than the 8-hour-repeating spam that was the main issue in the first place).
I have avoided Belkin products for some time now, because of abysmal experiences using their KVM switches. Wretchedly poor products that often lock up completely and require you to reboot all machines connected to them! Not good, if in a server environment. Switched to Iogear KVM switches and never looked back! Belkin also hides the true cost of their KVM switches by forcing you to buy connector cables separately at an extra price, whereas Iogear kindly includes the cables.
How do you spell "broken"? B-e-l-k-i-n
The vandal who put this in the CVS code tree obviously had a lot of skill.
It's a clever backdoor, and might have gone unnoticed, if not for those those good automated checks in the BitKeeper-to-CVS gateway. Notice that the particular coding style is a common C gotcha (using "=", assignment, instead of "==", comparison). At first glance it looks like the value of uid is being compared with 0, when in actuality it is being assigned the value of 0: root! The gcc compiler is good about warning for this, except that this too has been defeated: as mentioned on the mailing list, notice the unusual high number of parenthesis around this expression. That high number of parenthesis has the effect of suppressing the gcc compiler warning.
So, whoever did this obviously knew what they were doing and tried to obfuscate it. As somebody else mentioned on the kernel mailing list, if somebody is going to put in a backdoor like this, why not make it a remote root hack?
As it is now, the above hack is only locally exploitable. A process on the local system still has to call the wait system call with that particular combination of flags, in order to trigger the exploit and get root. To my knowledge, no known applications do this, because the combination of flags is supposed to be invalid.
If a spammer or somebody else was trying to backdoor the Linux kernel in order to gain a large number of machines to infest, then one wonders why they didn't put in a remote root exploit. It seems strange to go to all the trouble. Since this backdoor attempt has been caught and blocked, security will now only become tighter, and they might not ever get another chance like this.
Maybe it was intended to be used with another application, also backdoored in the same manner? It might be insightful to scan other open source applications and search for this particular usage of flags to the wait system call.
In any case, I'm glad this hack was caught!
The very idea of detecting spam during SMTP reception, and then deliberately slowing down response time in an effort to frustrate/deter spammers, has been discussed before.
5 25 7
It's a previous Slashdot story, in fact.
http://slashdot.org/article.pl?sid=03/03/02/141
And this story was a dupe, so there may be more....
Your joke actually has a ring of truth in it: did you know that for Baldur's Gate 1, you could actually buy a reduced version of the game (containing only the first one or two discs) for a lower price?
It would "end" about midway through the plotline of the full game, and not have as many areas to explore. I would imagine it sold poorly, because they didn't retry this idea for Baldur's Gate 2.
That's nothing compared to India. There, many publishers of standard textbooks publish the same book at a steeply discounted price. This is to match local standards of living (the same reason for the much-discussed salary gap).
c ma y2k.htmlb ib/cs.html h tm
I saw such classic CS books as K&R and UNPv1, published as "Eastern Economy Edition". The Indian person who owned the books said that they were bought for the equivalent of around $5 each! They are softcover, printed on really cheap paper (thin and not pure white), and generally produced as cheaply as possible in order to meet the low price. The page size is also reduced.
http://www.niyam.com/writing/iconoclasts/niyama
http://people.csa.iisc.ernet.in/~siddu/
http://www-scf.usc.edu/~india/newstudentletter.
I was jealous, and wished I had been able to get books at that price during school. The content is exactly the same! Too bad there isn't an Amazon.co.in....
I agree that it would be good to have the initial warning message generated after 30 minutes. Or, perhaps after only 5-15 minutes! Since 99.9% of all email messages reach their destinations instantly (usually in a matter of seconds), alerting users to unusual behaviour is a good thing.
As was said by others, the purpose of this short timeout is to give the user a chance to try other methods of communication (FAX, phone, carrier pigeon, etc.). By holding the warning message until 24 hours or more have elapsed, the user's attention will have gone on to other things and they will begin to erroneously assume that the email has already safely arrived.
However, the hard timeout, at which the SMTP server gives up trying to forward the message, should remain at 4 days or more. I've had servers go down for a few days, typically a weekend upgrade, and it's great to be able to bring them back up without bouncing anybody's email messages. Reducing the hard timeout would just put more of a burden on everybody else to get their servers back up before the hard timeouts expire. It's hard enough to guarantee bringing up a system in 4 days after a disaster, and some want to make it only 1 day?!
Perhaps a third timeout should be added: something between the soft timeout and the hard timeout. I can see having timeouts of 15 minutes, 24 hours, and 4 days. At the middle timeout (24 hours), a second warning message would be generated for the sender, to further let them know that their message has been delayed. This keeps up the "three strikes" tradition of having the first two error messages be only warnings, and only the third email message is a true error (containing the bounced message).
A bit jealous, are we? Nevertheless, it is almost impossible to find another job in just two months in this economy. I'm still looking. There's lots of other people in the same boat, and being out of work for many months at a time is no longer the stigma that it once was during the boom. Employers do understand. I do have plenty of savings, for now, but want to stretch it as long as possible.
I don't like sitcoms and never have watched Seinfeld... but B5 and Buffy, ah!
I was fired in a good way, if such a thing is possible.
It was not really a surprise. I could see it coming. Others had been fired before me, as the company slowly nibbled away at us. I was one of the last non-Indian people in the department. I'm not being racist here: in fact, it was an Indian who helped me to get this job in the first place! I'm not blaming the Indians at all for this, and in fact, two of my best leads for finding another job are through Indian managers or owners. There's no denying the simple economic difference in wages between India and the USA, though.
They did a really cool thing for some H1-B Indians who would also be affected by the layoff, though: in lieu of being laid off, the company gave them the option of returning to India for a guaranteed job at the company's Indian office, paying local India wages (much less than USA wages, even for H1-B's). Many Indians took this option, including my boss. The layoff was across-the-board, affecting Indians as well as USA citizens, but USA citizens bore the brunt of the layoff. I believe that the company was preparing to transfer the entire office to India eventually, so they were taking steps in this direction, and it would have been only a matter of time.
My boss simply called me into his office, shut the door, and that was that. It was not a surprise to me, because I could see it coming for several weeks. On the same day I was fired, about 20% of the company was also fired! This is a company that had about 1000 workers at the time, so it wasn't a small layoff by any means. There was extra security around, but no harassment. They had brought in lots of cardboard boxes for packing. I was able to back up all of my personal stuff (bookmarks, etc.) that was on their computers, and burn a CD to take it home with me. In fact, they let us work through the end of the pay period (several more days)!
Because they were kind, I was kind to them in return. I cleanly documented things I was working on at the time, and organized things in such a way that anybody coming in would be immediately able to find what they were looking for (I was in charge of an internal Linux distribution at the time). When it came time to go, I said my goodbyes, gathered as much contact information from my coworkers as possible, left my contact information, gave my card to my boss, and walked out. No unpleasantries at all.
And the best part? The company was later called on the carpet for violating the WARN Act, so they ended up having to give everybody 60 extra days on the payroll! The WARN Act requires 60 days of notice before a large layoff, and since they failed to do this, they had to make up the 60 days. It was wonderful to get a mini-sabbatical of two months of full pay for sitting around at home and resting! Nice.
Now, unfortunately, the savings is beginning to run a bit thin so I'm looking for another job... not much to be found....
Locality-based sites already exist, and are eager for location-based advertising as you suggest. Here's one of the better ones (and quite possibly the very first one):
http://www.local2me.com/
There's a thriving community of people here, who swap recommendations for services such as plumbers and veterinarians. It's essentially a nationwide message board that filters by distance from you to the poster, so you end up only seeing the very few posts that are pertinent to your location. Advertisements are also filtered by the relevancy of their location to you. A nice idea that seems to work well!
It would be trivially easy to code up software to monitor this on the client side, if statistics were made available from the ISP (perhaps by using SNMP to get counts of bytes transmitted/received). However, like other people said, it would be hard for the ISP to actually enforce these limits without putting a huge burden on the router's CPU. Perhaps a person working for a packet shaper company is reading this post, and can put this in hardware? :)
It ISP's would use the "toilet tank" idea to limit the amount of data that a customer can produce/consume, then it would singlehandedly solve the problem of certain customers eating too much bandwidth. There wouldn't be a need to limit the customer's ability to run servers, or block certain ports, or do anything else to limit the transparency and usefulness of a connection.
The ISP could offer several tiered pricing levels, letting customers choose the size and refill speed of their own "toilet tank". Perhaps letting people freely run servers would be the best way to promote the higher tiers! After noticing the increase in traffic from a popular server, and the slowdown that results from their tank being depleted, a customer would then have a powerful incentive to upgrade to a higher tier.
I can even see an ISP setting up partnerships with other companies that want customer eyeballs, such as big media companies, by offering to make the sites of those companies exempt from the "toilet tank" rationing system. Customers would be encouraged to see things on those sites, since they would remain at full speed no matter how much they viewed.
This idea could truly be a great idea for the ISP that chooses to run with it!
Good, I wasn't the first to think of this. I first read about the "toilet tank" analogy in an article somewhere (probably broadbandreports.com) that mentioned DirecPC's FAP. I tried to search for that article again but was unsuccessful. The idea is a good one, but FAP is so nasty and Draconian that it gave the idea a bad reputation.
Like all ideas to ration Internet access, the "toilet tank" idea is certainly unpopular, but it is far better than some of the hairbrained schemes that large media companies have recently been doing: cutting off people entirely, forcing people to wait until certain times of the day/month, surprising people with huge bills or nastygrams mailed to them, and so on....
It is a good article, but it glosses over the most important part: in order to successfully boot up your system faster using parallel processes, you must first resolve all dependencies.
This isn't easy, because it's a nontrivial problem to tell exactly what services a given process relies on and assumes to already be existing at the time the service is started. Also, some scripts start off daemons in the background and then return immediately! If another service depends on having this daemon running, it would need to know to wait for that daemon to finish initializing.
What would be great is to have all future init.d files adhere to a convention in which they could list what they provide and what else they depend on, kind of like what the RPM database already does. It would look something like this:
# script for starting myserviced
# REQUIRES network syslog
# PROVIDES myservice
This example would be for a daemon that requires two services to be running, and provides a service of its own that other daemons can depend on. This could be used to resolve initialization dependencies and make the system boot faster. Note that the service names are abstract, not corresponding to any particular daemon, so that replacement daemons could easily be swapped in to do the same job.
I would be surprised if new distributions haven't already thought of this or didn't already have such a system in place!
I wouldn't mind seeing bandwidth capping on my line if they did 3 things to make it fair.
1) Use the "toilet tank" method of capping people, instead of completely cutting them off entirely. This method has been deployed in several places, and people of course don't like it, but it is the fairest system that has been devised so far. Unlimited downloading (or uploading) is allowed, up to a point. When that point is reached, downloading will continue, but at a dramatically lower speed. The download will not be interrupted, but it will be capped to that lower speed. If the customer stops downloading for a period of time, they will re-earn the right to download at a higher speed, as their toilet tank slowly refills over time. This system also doesn't require strict time intervals (such as 24 hours, 1 month, etc.), because it is both triggered and released by the user's behaviour. If the user voluntarily downloads at a speed slower than the top speed, they can stretch out the length of time during which they can enjoy a noncapped connection. This is a good system because it has its intended effect (keeping high-volume users from abusing the service for everybody else) while not punishing people by cutting them off entirely or charging them a huge bill (important for cases in which the user isn't to blame for the high bandwidth usage, such as a virus or a Slashdotting). Also note that uploads and downloads are treated separately and independently, with a different toilet tank for each.
2) Make it clear what the cap level is, for both upload and download, including both the capped speed and the "toilet tank" size. Include this both in customer contracts and advertisements to non-customers. Advertising a connection as "unlimited" is false, when it could be capped! An example of an acceptable service description that could be advertised would be "1.5mbps download (capped 1GB/64kbps) and 256kbps upload (capped 128KB/64kbps)". This refers to a system that would have a toilet tank size of 1GB for downloads, after which the download speed would be reduced to a mere 64kbps. At this speed, it would take roughly 36 hours to refill the toilet tank once drained, but the user could still use their connection during this time (they just wouldn't be able to download another full 1GB without hitting the cap again). There's another similar toilet tank for uploads.
3) Provide tools for the user to monitor their current bandwidth usage, and how it applies against the cap. At the minimum, this should include both a live program that can be installed on the user's computer, and a webpage that can be visited occasionally should the user not wish to keep an extra program running. I would set that webpage as my homepage! The program would display the user's current usage and the threshholds at which capping would occur, and the current fill level of the "toilet tank". It should be made absolutely clear to the user what is going on, and how their current behaviour affects their cap, so there will be no guessing or finger-pointing.
I currently use DSL, not cable, because my connections are largely two-way. I do just as much uploading as downloading (no P2P, just old fashioned stuff like web servers), and cable companies are hostile towards uploaders and servers. The reason I use DSL is because so far my ISP (SBC) has not instituted any unfair caps! If they were to cap the line in an unfair way, I would be screwed, because I can't switch to cable. A friend of mine eats the cost of having a full T1 to his house. Maybe I'd have to do the same?
Wow, this is the first real reason I have for wanting to restrict outgoing connections from my own network. 100% typosquatting is just disgusting.
:)
I don't want Verisign getting any data on what domains I mistype, and I don't want applications (such as email) breaking when users mistype an address. I don't want my outgoing email being intercepted by Verisign! Even if they say they'll set up a dummy SMTP server to generate error messages and bounce the mail, I don't trust them.
It might be a good idea to make a daily cron job to look up the IP address of Verisign's wildcard, and add that to the list of banned IP addresses (no data allowed, not only for incoming but also for outgoing as well).
dig @a.gtld-servers.net \*.com. | grep \^\*.com.
dig @a.gtld-servers.net \*.net. | grep \^\*.net.
Extracting the IP address from that and banning it is an exercise left to the reader
Note that Verisign might have other domains under their control as well....
http://www.uo.com/archive/ultima4/
I remember that as being a very hard dungeon, back when I played the game about 13 years ago.
My best advice is to make sure you've got enough experience (at least 6400 points) to have all of your 8 characters at level 8. You will also need to max out the ability scores of each character, as far as their classes will allow. Play the dungeon of anti-Spirituality (Hythloth), as it has the most efficient orbs that will raise all 3 of your character's statistics at once.
If you have trouble leveling up your weaker characters (the strong characters always seem to get the best hits and kill the monsters first), then equip them with Magic Wands or other distance weapons, and simply pass (hit the spacebar) when controlling your stronger characters. Then, the weaker characters will be able to get in some kills. Upgrading weak characters is vital, especially for characters that can cast magic: you want to have each character able to cast Resurrect, in case you lose all of your strong characters during a battle and only a weak character is left alive!
When your characters are all upgraded as far as they can be, mix up LOTS of spells with your reagents. Take in 99 Heal and 99 Resurrect, at a minimum, and lots of others you will find useful. Max out the reagents as well, so you can brew 99 more spells as needed!
This should be enough firepower to get you through the dungeon. Use a walkthrough if you need maps to help you along the way, or if you get stumped by the riddles that are asked at various times.
BTW, the best version of Ultima IV is the one for its home platform: Apple ][! This version has great music, with the Mockingboard, something that is inexplicably lacking from the PC version. Play it with an emulator, instead of worrying about how to get your PC backward-compatible enough to actually run the native game on the PC.
I still think this game is the BEST EVER RPG of ALL TIME (even beating out newer games such as Baldur's Gate)!
From the client side, Microsoft is already collecting every mistyped URL and substituting their own search engine!
In MSIE, a hostname that is not found will be sent to Microsoft. A page will be auto-generated, containing links to similar hostnames, and the Microsoft MSN search engine.
Microsoft is already receiving this information. I'm sure that there is a high commercial value in knowing the exact data on which domains are mistyped the most often! I would be surprised if Microsoft doesn't use this information internally, or resell it to the highest bidder.
Since MSIE is 90% of the installed browser base, I would be very surprised if server-side information on mistyped domains (as Verisign is logging) is very different from client-side information. The client-side information might even be more accurate, due to intermediary DNS servers doing caching of negative results!
Does anybody know for sure what Microsoft is doing with their large database of mistyped domains?
There's a reason I'm not a Netgate customer anymore.
They were a fine ISP when I used them several years ago, having good dialin numbers (these were the days before easy broadband access) and reasonable prices. They didn't have any technical problems to speak of. They even had really good USENET access (I used to post a ton from krellan@netgate.net, Google it).
However, Netgate's social/legal policies really stank.
At the time, for example, they had agreed to host godhatesfags.com. So, I left.
It wouldn't surprise me now to see them overzealously comply with a subpoena, hurting their own customers in the process.
I still think it's really cheap of hosting companies to not warn their customers when receiving legal action against them (except when the DMCA actually requires that they not warn, yet another reason why it's such a scary law).
Here's possibly one of the best sites on the net about the philosophy of designing shareware. Note that copy protection is not the answer!
http://semicolon.com/ShareSuccess/Shareware1.html
Basically, the author does triage. There are 3 types of people: those who will always pay, those who will never pay (pirates), and those who might pay. He focuses on trying to convince the latter group, and doesn't waste time with copy protection schemes that will just annoy the honest users and not stop the pirates.
What's wrong with copy protection:
http://www.toad.com/gnu/whatswrong.html
Some typical attack methods:
http://www.geocities.com/Pentagon/Barracks/3030/co pyfail.htm
http://fravia.anticrack.de/advanced.htm
You might want to read all of these before deciding if your efforts on copy protection are really worth it in the long run.
http://semicolon.com/ShareSuccess/SharewareLinks.h tml
The author of the first link has a page of more links that are also very good.
How long is it until someone makes a quick patch to LAME (or other popular open-source MP3 encoder) to slightly randomize the VBR bitrate decisions?
In a typical VBR song, the bitrate changes so fast that changing the bitrate of a few blocks would be unnoticeable. It would have practically no effect on the sound quality. Oftentimes, a block will be right on the edge, say between 112 and 128 kbps, and the encoder will have to make a decision on which one to use. Currently, the encoder just follows the same strategy each time, rounding off to the nearest bitrate. A patch could make it random, instead of deterministic. Nobody would know the difference, and then each and every MP3 generated by the encoder would have a completely different MD5 hash, even when using the same source material!
Come to think of it, this technique could also be used for tracking of purchased MP3 music. Every time a customer downloads a purchased track from an online music store (like iTunes), the MP3 could be generated on the fly, and slight variations could be introduced in the VBR bitrates. This could be used to embed a "serial number" into each MP3 track. Then, when the track shows up on Kazaa or whatever, it could instantly be traced and the person who leaked it would be known! That would strongly discourage people from leaking purchased music.
I'd be very surprised if this isn't already being done... surely I can't be the first person who has thought of this....
That's pretty nasty that Netgear would hardcode a NTP time server into their product, without even telling U-Wisc about it.
:)
When I configure my computers to use someone else's NTP server, I always send them an email to let them know (or whatever else they request that people do).
What's worse is that Netgear hardcoded the address, in a way that can't easily be changed without a firmware upgrade (something that very few of the intended Netgear firewall customers will do: these customers are looking for a plug-it-in-and-forget-it box, and are either unwilling or unable to learn how to set up a firewall box themselves). And then, on top of that, Netgear botches the implementation of the protocol, causing it to rapid-fire out requests in certain circumstances!
NTP is a very, very low-profile protocol. It uses UDP, so that connection state doesn't have to be maintained. It sends out packets very rarely, at most every few minutes while being set up, and then once time has been established and clocks are in sync, roughly one packet every few days. Netgear's botched programming caused a NTP flood of one packet per second! This is a ridiculous rate several orders of magnitude above what is normally seen in a functioning NTP implementation.
And Netgear sold hundreds of thousands of these things....
I'm amazed that U-Wisc put up with this effective DoS attack on their servers for so long. They showed great patience waiting several months for their request to crawl through Netgear's channels. Companies really need to have a quick method of access into their corporate structure for people who report major flaws like this! Because Netgear's traditional channels of customer feedback (tech support, etc.) weren't set up for this, U-Wisc's requests kept getting lost in Netgear's bureaucracy. Is Netgear so arrogant to believe that all of their products are and will always be 100% flawless?
There really needs to be a special method of access when people report security holes and such. Microsoft, surprisingly, is starting to come around with this, maintaining a special point of contact for people who have discovered security-related issues or major flaws like this. I hope that more companies do this in the future.
If Netgear would do these three things, I would be happy:
1) Set up their own NTP master servers (stratum 1, using a GPS receiver or atomic clock), at Netgear itself. They would use Netgear's own bandwidth, not U-Wisc or anyone else's. Netgear's future products would then default to using these servers, and they would put out a patch so that hopefully some fraction of older products would also use these servers. That way, if there is a flaw in the future, Netgear will eat their own dogfood! I am pleased to see that Netgear is already taking steps in this direction.
2) Change their corporate structure to be more receptive to outsiders who report serious design flaws or major issues caused by their products (such as this NTP flood), going beyond normal tech support, so that quick action can be taken to avert damage. Tech support is really only set up to handle questions about an individual device owned by the person calling in about it, and not set up to handle serious technical or security issues about all devices in an entire product line.
3) Reimburse U-Wisc for the cost of banwidth consumed by these buggy Netgear devices. If U-Wisc isn't blocking incoming NTP entirely by now, pay for robust NTP servers to handle the high volume of traffic. If Netgear had targeted pretty much any private company instead of U-Wisc, I'm sure they would have sued for damages by now!
And remember, ask first before using someone else's NTP server, especially if you plan to hardcode the address into your product
I used to use FSP. I even hacked the source to dramatically shorten the time delay it waits between sending requests for data, to get faster service :)
There were 2 main reasons to use FSP:
1) It used UDP, not TCP. Many monitoring/logging tools and firewalls back in the day only really had a tight control on TCP. Using UDP was a good way to slip under the wire.
2) It deliberately kept its data rate very small. Something on the order of 2K per second. Even with a hacked client, the server simply wouldn't send data any faster than a certain cutoff point, and ignored any requests that came in faster than that. This data rate throttling was done, again, to help stay under the radar. Many sites were detected only because a huge upward spike in consumed bandwidth was noticed. Using FSP, a site could stay up for a much longer period of time before being caught and deleted.
Nowadays, we all have great P2P applications to make good use of UDP, and bandwidth usage is usually adjustable on them, so the main reasons to use FSP have gone away. Good riddance, I say, as it was truly a terrible protocol (think of XMODEM over IP)!
This has been mentioned before, here on Slashdot, but not in this negative context. Previously, people just thought of Microsoft's newsgroup tracking as a curiosity, and not something with an ulterior motive.
USENET is losing its relevance these days, unfortunately, due to spammers and the difficulty of creating new groups to keep up with current trends. Most message-based chat nowadays takes place on innumerable topic-specific websites running "bulletin board" software such as YaBBSE. It might be a little too late to do anything to USENET now, either good or bad....
It is highly recommended that checksums be stored on a different server!
Many high profile sites surprisingly do not do this.
By keeping checksums separate from the files themselves, it makes the cracker's job more difficult, because they will have to crack two machines in order to Trojan a file. It is also recommended that these two machines be running different operating systems, such as Linux and OpenBSD, so that an exploit affecting one will hopefully not also affect the other.
If only one server is compromised and the files or the checksums are changed, but not both, people will be able to detect this by the mismatched sums. When the checksums are on the same server as the files themselves, the cracker can replace the checksums at the same time as the files, and nobody will know that the files have been compromised.
Also, GPG keys should be used to put some cryptography into guaranteeing that the files haven't been tampered with. The cracker will have to forge a GPG signature, much more difficult than regenerating a checksum. I am glad to see that the GNU project will do this for future files, to help prevent a situation like this from happening again. Of course, the GPG public keys should be on a different server than the signed files!