Trend had a signature the same day it was noticed
The same day Trend noticed it. Probably hours to days after it was released.
It's not necessary for a corporation. It is, in fact, dangerous for a corporation, because it replaces user training. Users believe that anything that makes it past the antivirus program is safe.
Antivirus programs cause more problems than they fix.
They cause significantly degraded performance. They cause unusual and unexpected problems with legitimate software. They give a false sense of security. In the end, though, they can only really protect against known malware, days or weeks after it's a problem.
A combination of user training and regular software updates is more effective, in my opinion.
Of course it would work. New organisms could eat or otherwise kill the weak of the population.
Unless you mean no death at all, no ability to kill anything. Hard to imagine that - I mean, an organism cut into small enough pieces may still be alive, but it certainly ain't gonna be happy about it.
Sigh. Same old advice. Bigger heatsinks, bigger fans, slower speeds..
Each time I see an article like this, I hope that it's actually going to be about a silent PC - passive cooling, solid state storage. But no.. it's always how to make a quieter PC. Always with the same steps. It's like these sites run these articles just to sell the banner impressions.
Move along. Nothing to see here.
Why would Maxtor's drive testing tool disable auto sector relocation? The test is to ensure that the drive is useable, not to ensure that there are no bad sectors on the underlying media. In fact, the underlying media usually has bad sectors from the factory.
The original poster says that the Maxtor tester disables the feature when testing. It's possible that he's right, but it isn't the norm. More than once, I've had a drive with bad sectors that was miraculously "cured" by zeroing it out (dd if=/dev/zero of=/dev/hda), to the satisfaction of the manufacturer's diagnostic test. (To my chagrin, on the one drive, the bad sectors came back with reinforcements months later. I guess there's only so many spare sectors to map.)
I'll agree that Steve Gibson is a nut. SpinRite
has some good ideas in it, though, but it hasn't been updated in years and is more useful for older drives. It was a good piece of software in its time, and it's probably the reason that he gets as much attention as he does today.
[hard drive diag floppy] I just returned two Maxtor drives that passed multiple "extended" tests with their diag utils. BOTH have entire tracks that aren't readable -- sector mark not found... they aren't there anymore.
It's because of automatic sector relocation. All modern drives do it. When a bad sector is identified, it is marked as such, and the next write to that sector is mapped into a certain number of reserved sectors.
Ideally this process happens when the sector is weak, not bad, and the correct data can be copied over into the new sector without waiting for a write. But when the drive is going south quickly, the weak sectors may not be identified until they're actually bad.
The diagnostic program often has a feature to wipe the desk, or something like that. This triggers the automatic sector relocation, and subsequent scans will show the disk as clean.
As far as i can tell, grc.com's SpinRite takes advantage of this feature with the "Disk Exercizer" option, which reads and rewrites each of the sectors. Too bad it only works with dos or windows-formatted partitions.
No one will ever see a post this far down and this late in the story, but..
According to your article, the NSA may be able to crack 512 bit RSA keys. The 128 bit keys you're talking about are AES keys.
The nice thing about cracking RSA keys is that you only have to try combinations of primes, not combinations of all numbers in the keyspace. It's quite a bit faster than brute-force.
The best public algorithms for cracking AES is not that far off from brute force. Your 128 bit AES keys are still relatively safe.
Silverman estimates that one needs a 1620-bit RSA key to provide security equivalent to a 128-bit symmetric cipher key (e.g. AES).
Oh give me a locus
Where the gravitons focus
Where the three-body problem is solved
Where the microwaves play
Down at 3 degrees K
And the cold virus never evolved
Home, home on Lagrange,
Where the space debris always collects,
We possess, so it seems, two of Man's greatest dreams,
Solar power and zero-gee sex.
I've noticed that every once in a while, my phone will heat up to uncomfortable temps while talking. The heat seems to come from the phone itself, not the battery - from the front side of the phone, near the lcd. The phone is in digital mode when it happens.
Now I know y'all like speculating, so - what would cause this? Has anyone else had similar experience with factory-original phones?
Ok, so you can still spoof the addresses of other people on your segment (or possibly subnet, if you are using dumb switches), but shouldn't routers be able to figure out when packets are OBVIOUSLY bogus?
As the saying goes, "That would cost extra". It's one of those things that's only really useful if everybody does it, and it requires more intelligence and processing power in the routing hardware, which equals more dollars.
Many networks already do Reverse Path Filtering, but that doesn't fix the networks that don't do it.
I thought Gnucleus was pretty good too, but on my computer it crashes after a short time if I share any files. It appears to crash while hashing the files and performing queries on those files. If I let it finish hashing the files before connecting to the network, it works just fine - right up until I actually download something and it hashes the download to verify it.
I believe someone on the Gnucleus forum tracked it down, something to do with the shared file lists changing between the start of a hash and the end.
I've been waiting a long time for a Gnucleus 1.8.5 to fix this problem. Nothing's available so far.
UDP and DDoS
on
Gnutella2?
·
· Score: 2, Interesting
I haven't seen anyone mention the potential of abusing the UDP search extension as a massive DDoS reflector. Simply send a query for something very common, with a faked source address on the packet, to as many Ultrapeers as possible. (I'm assuming that Shareaza implemented the GUESS extension, as many people have suggested.)
The documentation for GUESS is not reassuring:
In the past, a principal objection to using UDP has been that it allows anyone to easily execute a DDoS attack on any target machine. This concern has been based on the assumption that queries would require an extension listing the IP address and UDP port to reply to, however. In this proposal, this extension is not required, as responses are always sent directly back to the node that sent them, rendering such an attack impossible.
This totally ignores the fact that the only way to determine which node sent the packet is to use the source address on the UDP packet! Am I missing something here? Am I misreading the documentation?
The local filestore is encrypted with a symmetric cipher along with the key. That part is easy enough to work around.
Each file is encrypted and signed using its name. Although it would be difficult to determine what files you have on your system, it would be easy to determine if a particular file were on your system.
It may not even be that difficult to determine what files you have on your system - just come up with a list of plausible names and descriptive words, and see if the resulting hash is found in your filestore.
This bit of encryption doesn't prevent someone from identifying files in your filestore. Rather, it's supposed to allow you as the node owner to reasonably claim that you don't know what's in your filestore. As they suggest in the FAQ, many legal systems support this position, but that there is a risk in doing anything that your government might potentially disagree with.
This is probably too late to get modded to a point where anyone will see it, but..
Verant's oversights in this case may ruin the player economy, but they don't affect the history and lore within the game. A person who plays the game with the intent to have the most awesome equipment available is going to find this cheating frustrating, but this shouldn't affect people who are playing for the role playing element and a chance to explore an expanding world of lore.
I find the game is more interesting if you refuse to twink (that is, to equip your lower level characters with equipment from your higher level characters). The equipment that you acquire by hard work (so to speak) has greater value than just the currency it will yield, and the effort put into generating a character instead of a "warm body" to put equipment on is well worth it.
Slashdot Mirror
Sometimes I wonder if worrying about pathogens isn't worse for the health than the actual pathogens
Definitely. The placebo effect's evil twin causes a great deal of stress, and stress causes any number of physical side effects.
FCC ID KA2DI524 It's a dlink DI524 rev A1
Waitaminute - I don't see any mention on the site that they actually did get Linux running on this thing, just that they "adopted" it.
Blech.
Oooh.. these use the same chipset as the Dlink DI-524. I've been looking for an in on that one.
Grumble. It's completely silent PC cooling, not a completely silent PC. There's still a hard drive in there making noise.
Granted, it's really quiet, but it does not deserve the adjective "completely".
Still waiting for large-capacity flash-based drives on the cheap.
I'm reminded of a quote:
"Don't worry about people stealing your ideas. If your ideas are any good, you'll have to ram them down people's throats."
-- Howard Aiken
Trend had a signature the same day it was noticed The same day Trend noticed it. Probably hours to days after it was released. It's not necessary for a corporation. It is, in fact, dangerous for a corporation, because it replaces user training. Users believe that anything that makes it past the antivirus program is safe.
Antivirus programs cause more problems than they fix. They cause significantly degraded performance. They cause unusual and unexpected problems with legitimate software. They give a false sense of security. In the end, though, they can only really protect against known malware, days or weeks after it's a problem. A combination of user training and regular software updates is more effective, in my opinion.
Of course it would work. New organisms could eat or otherwise kill the weak of the population. Unless you mean no death at all, no ability to kill anything. Hard to imagine that - I mean, an organism cut into small enough pieces may still be alive, but it certainly ain't gonna be happy about it.
Sigh. Same old advice. Bigger heatsinks, bigger fans, slower speeds.. Each time I see an article like this, I hope that it's actually going to be about a silent PC - passive cooling, solid state storage. But no.. it's always how to make a quieter PC. Always with the same steps. It's like these sites run these articles just to sell the banner impressions. Move along. Nothing to see here.
Why would Maxtor's drive testing tool disable auto sector relocation? The test is to ensure that the drive is useable, not to ensure that there are no bad sectors on the underlying media. In fact, the underlying media usually has bad sectors from the factory.
The original poster says that the Maxtor tester disables the feature when testing. It's possible that he's right, but it isn't the norm. More than once, I've had a drive with bad sectors that was miraculously "cured" by zeroing it out (dd if=/dev/zero of=/dev/hda), to the satisfaction of the manufacturer's diagnostic test. (To my chagrin, on the one drive, the bad sectors came back with reinforcements months later. I guess there's only so many spare sectors to map.)
I'll agree that Steve Gibson is a nut. SpinRite has some good ideas in it, though, but it hasn't been updated in years and is more useful for older drives. It was a good piece of software in its time, and it's probably the reason that he gets as much attention as he does today.
It's because of automatic sector relocation. All modern drives do it. When a bad sector is identified, it is marked as such, and the next write to that sector is mapped into a certain number of reserved sectors.
Ideally this process happens when the sector is weak, not bad, and the correct data can be copied over into the new sector without waiting for a write. But when the drive is going south quickly, the weak sectors may not be identified until they're actually bad.
The diagnostic program often has a feature to wipe the desk, or something like that. This triggers the automatic sector relocation, and subsequent scans will show the disk as clean.
As far as i can tell, grc.com's SpinRite takes advantage of this feature with the "Disk Exercizer" option, which reads and rewrites each of the sectors. Too bad it only works with dos or windows-formatted partitions.
Gallows humor, n.: Humorous treatment of a grave or dire situation.
Hope that helps.
No one will ever see a post this far down and this late in the story, but..
According to your article, the NSA may be able to crack 512 bit RSA keys. The 128 bit keys you're talking about are AES keys.
The nice thing about cracking RSA keys is that you only have to try combinations of primes, not combinations of all numbers in the keyspace. It's quite a bit faster than brute-force.
The best public algorithms for cracking AES is not that far off from brute force. Your 128 bit AES keys are still relatively safe.
Silverman estimates that one needs a 1620-bit RSA key to provide security equivalent to a 128-bit symmetric cipher key (e.g. AES).
Hope that helps
Can't they both be unscrupulous?
I've come to realize a fundamental truth:
You can't always judge a book by its cover, but most of the time you can.
Oh give me a locus
Where the gravitons focus
Where the three-body problem is solved
Where the microwaves play
Down at 3 degrees K
And the cold virus never evolved
Home, home on Lagrange,
Where the space debris always collects,
We possess, so it seems, two of Man's greatest dreams,
Solar power and zero-gee sex.
(to the tune of "Home on the range")
As the RF stage is the main device consuming power in your phone, and it's not 100% efficient , a certain amount of energy will be dissipated as heat.
That sounds plausible. What's not clear is why it only overheats once in, say, a month. There's no noticeable heat from it at any other time.
I've noticed that every once in a while, my phone will heat up to uncomfortable temps while talking. The heat seems to come from the phone itself, not the battery - from the front side of the phone, near the lcd. The phone is in digital mode when it happens.
Now I know y'all like speculating, so - what would cause this? Has anyone else had similar experience with factory-original phones?
No worries.
As the saying goes, "That would cost extra". It's one of those things that's only really useful if everybody does it, and it requires more intelligence and processing power in the routing hardware, which equals more dollars.
Many networks already do Reverse Path Filtering, but that doesn't fix the networks that don't do it.
I thought Gnucleus was pretty good too, but on my computer it crashes after a short time if I share any files. It appears to crash while hashing the files and performing queries on those files. If I let it finish hashing the files before connecting to the network, it works just fine - right up until I actually download something and it hashes the download to verify it.
I believe someone on the Gnucleus forum tracked it down, something to do with the shared file lists changing between the start of a hash and the end.
I've been waiting a long time for a Gnucleus 1.8.5 to fix this problem. Nothing's available so far.
I haven't seen anyone mention the potential of abusing the UDP search extension as a massive DDoS reflector. Simply send a query for something very common, with a faked source address on the packet, to as many Ultrapeers as possible. (I'm assuming that Shareaza implemented the GUESS extension, as many people have suggested.)
The documentation for GUESS is not reassuring:
This totally ignores the fact that the only way to determine which node sent the packet is to use the source address on the UDP packet! Am I missing something here? Am I misreading the documentation?
The local filestore is encrypted with a symmetric cipher along with the key. That part is easy enough to work around.
Each file is encrypted and signed using its name. Although it would be difficult to determine what files you have on your system, it would be easy to determine if a particular file were on your system.
It may not even be that difficult to determine what files you have on your system - just come up with a list of plausible names and descriptive words, and see if the resulting hash is found in your filestore.
This bit of encryption doesn't prevent someone from identifying files in your filestore. Rather, it's supposed to allow you as the node owner to reasonably claim that you don't know what's in your filestore. As they suggest in the FAQ, many legal systems support this position, but that there is a risk in doing anything that your government might potentially disagree with.
This is probably too late to get modded to a point where anyone will see it, but..
Verant's oversights in this case may ruin the player economy, but they don't affect the history and lore within the game. A person who plays the game with the intent to have the most awesome equipment available is going to find this cheating frustrating, but this shouldn't affect people who are playing for the role playing element and a chance to explore an expanding world of lore.
I find the game is more interesting if you refuse to twink (that is, to equip your lower level characters with equipment from your higher level characters). The equipment that you acquire by hard work (so to speak) has greater value than just the currency it will yield, and the effort put into generating a character instead of a "warm body" to put equipment on is well worth it.