Re:"Ultra 160 no better than Ultra 80"...?
on
What is Ultra DMA?
·
· Score: 1
Pretty easy when you think about it.
A faster clock means the host adapter can more efficiently switch amongst devices, servicing those devices with pending data quicker (and, if they've been waiting for long, chances are it'll be in their cache.)
The most interesting thing I read about the case..
on
Rambus Losing In Court
·
· Score: 1
..was that, depending on how the jury rules (should Rambus be convicted of fraud), certain Rambus employees could face jail time for all this.
- A.P.
--
Forget Napster. Why not really break the law?
"Ultra 160 no better than Ultra 80"...?
on
What is Ultra DMA?
·
· Score: 4
Sure, maybe a single drive... but if you've got 5 or 6 of those 15K RPM Seagate bastards on a single chain, you'll easily max out Ultra 80, but you'll still have a little headroom on an Ultra 160 chain. Sure, no drive can actually do 160MB/second ALONE, but a bunch of them sure can.
Sort of. At one interview I went to for an insurance company, carrying a pager on the weekends meant an extra $250 in your pocket per weekend. Plus, if you got called in to fix something, the standard overtime rates applied (even though this was a salaried job.) Pretty sweet deal, actually.
Even though it isn't your stuff, it's always fun when boxes of new equipment show up, and you tear them open and set up the machines inside. If all I did was admin UNIX and NT all day, and never had the chance to set up a new piece of kit, I'd be somewhere else by now...
So, if I just stored it and didn't ever do anything with it, I'd be okay.
Ever heard the story of the CD-WOM? It was a device consisting of two blocks of ordinary wood and a cable connecting it to the user's PC. CD media was placed between the two blocks and data was written to the CD. The process was foolproof (I challenge you to prove to me that no data was written to write-only media!)
That's about how useful storing a checksum of a webpage would be without *doing* anything with the data. Sure, the checksum exists, but if you don't bother to do anything with it, the data is as worthless as a CD-WOM. Obviously, someone creating MD5 hashes of all their webpages would also build some sort of system around it to make use of those hashes!
Sure. I've put the code (tiny as it is) up at http://bitey.net/code/dupefind.txt. The file should be self-explanitory, and there's a couple comments in there that should help explain the database (just a flat-file, actually) format.
The code that actually creates the flat-file database (from a mounted CD-Rom) is here.
Another script that plays stuff and searches through the database is here.
Two "identical" songs may produce different hashes depending on the encoder used, bitrate, etc.
What I did was write a perl script which compares (using String::Similarity and File::MP3Info) the filenames themselves and their running time in seconds to those in my MP3 database. The script is command-line configurable to accept different "similarity" values as well as different "difference in seconds" values. The code itself is insanely simple, and so far it's about 80-90% accurate at finding duplicate MP3s. False-positives are surprisingly low, too. Greatly simplifies the task of weeding out already-downloaded crap.
If a case ever went to court over this, Burlington Northern would lose badly, since the Americans with Disabilities Act has been twisted so thoroughly out of shape by the American legal system. They're just covering their asses.
Didn't some of the comments contain shit like poems and mindless ramblings and long, wordy descriptions of simple functions? That's the story I remember anyway.
Conventional wisdom has it that you can't bring a sealed lead-acid battery on board a commercial airplane. This isn't entirely true. As long as you can prove your battery is safe, they'll allow you to bring it onboard. A lot of manufacturers have downloadable certificates on their websites nowadays that state their batteries are safe for air travel. I've brought the lead-acid batteries for my Tascam DA-P1 and Sony M1 DAT machines on board several flights, including one to Australia in 1999. I wasn't even asked about them that time.
YMMV, but as long as you've got the documentation, you shouldn't have a problem.
Slashdot Mirror
A faster clock means the host adapter can more efficiently switch amongst devices, servicing those devices with pending data quicker (and, if they've been waiting for long, chances are it'll be in their cache.)
- A.P.
--
Forget Napster. Why not really break the law?
- A.P.
--
Forget Napster. Why not really break the law?
- A.P.
--
Forget Napster. Why not really break the law?
- A.P.
--
Forget Napster. Why not really break the law?
- A.P.
--
Forget Napster. Why not really break the law?
- A.P.
--
Forget Napster. Why not really break the law?
- A.P.
--
Forget Napster. Why not really break the law?
- A.P.
--
Forget Napster. Why not really break the law?
- A.P.
--
Forget Napster. Why not really break the law?
- A.P.
--
Forget Napster. Why not really break the law?
- A.P.
--
Forget Napster. Why not really break the law?
Ever heard the story of the CD-WOM? It was a device consisting of two blocks of ordinary wood and a cable connecting it to the user's PC. CD media was placed between the two blocks and data was written to the CD. The process was foolproof (I challenge you to prove to me that no data was written to write-only media!)
That's about how useful storing a checksum of a webpage would be without *doing* anything with the data. Sure, the checksum exists, but if you don't bother to do anything with it, the data is as worthless as a CD-WOM. Obviously, someone creating MD5 hashes of all their webpages would also build some sort of system around it to make use of those hashes!
- A.P.
--
Forget Napster. Why not really break the law?
The code that actually creates the flat-file database (from a mounted CD-Rom) is here.
Another script that plays stuff and searches through the database is here.
- A.P.
--
Forget Napster. Why not really break the law?
What I did was write a perl script which compares (using String::Similarity and File::MP3Info) the filenames themselves and their running time in seconds to those in my MP3 database. The script is command-line configurable to accept different "similarity" values as well as different "difference in seconds" values. The code itself is insanely simple, and so far it's about 80-90% accurate at finding duplicate MP3s. False-positives are surprisingly low, too. Greatly simplifies the task of weeding out already-downloaded crap.
- A.P.
--
Forget Napster. Why not really break the law?
- A.P.
--
Forget Napster. Why not really break the law?
- A.P.
--
Forget Napster. Why not really break the law?
- A.P.
--
Forget Napster. Why not really break the law?
--
Forget Napster. Why not really break the law?
All work is now done on the production site.
- A.P.
--
Forget Napster. Why not really break the law?
--
Forget Napster. Why not really break the law?
Find a new way to advertise.
Dvorak's a whiner.
- A.P.
--
Forget Napster. Why not really break the law?
- A.P.
--
Forget Napster. Why not really break the law?
YMMV, but as long as you've got the documentation, you shouldn't have a problem.
- A.P.
--
Forget Napster. Why not really break the law?
- A.P.
--
Forget Napster. Why not really break the law?
- A.P.
--
Forget Napster. Why not really break the law?