High-end disks don't need those high platter densities. The platter densities increase the sequential transfer rate, but you get the same effect from spinning the disk faster. In addition, the faster spinning disk reduces seek times.
CPU speed is totally unrelated. Even if we ignore the CPU penalty of IDE, about twice as much CPU time as SCSI, the SCSI disks are just moving faster than any IDE drive at any price.
The conclusion: today's IDE drives are significantly faster than SCSI drives costing two or three times more per gigabyte stored.
That's probably true. For example, you can buy a n 80GB western digital 7200RPM drive for $150. That is $1.88/GB. The only 7200RPM SCSI drive made these days is the Seagate Barracuda, which is $300 for 36GB: $8.33/GB.
That really isn't the point of SCSI though. I'll accept that IDE wins on a money-per-GB basis. But, IDE has a performance ceiling that SCSI doesn't have. You can't get 10000RPM and 15000RPM drives for IDE at any price, period.
There is a point, when building RAID systems, where SCSI exceeds IDE in the $-per-I/O-per-second metric. In desktop systems, you probably won't exceed this point. But if you intend to have stripe sets of 4 or more disks, SCSI will win the price wars again.
Anyway it really isn't a matter of SCSI being expensive and IDE being cheap. It's the drives that are expensive/cheap and it simply works out that expensive drives get SCSI connections and cheap drives get IDE connections.
P.S. Have fun trying to get you 4-disk IDE RAID all within 18 inches of your IDE controller:)
Personally I hope Disney continue to piss their money away buying the most overpriced and useless machine SGI sells. I also hope the movies produced thereby fail horribly at the box office. Finally, I hope Disney then goes out of business.
What is it about slashdot, where disease corporations like Disney and other MPAA members are alternately booed and cheered?
Someone has to manufacture an ASIC to decode vorbis. You can't do it on a general purpose processor because the usual embedded processors like ARM are not fast enough and processors that are fast enough use too much power. I don't think anyone will produce a vorbis ASIC until a huge market for portable, low-power vorbis players exist.
The only likely scenario would be an existing MP3 ASIC manufacturer adding vorbis support to their product. At least that wouldn't require (much) more space on the circuit board.
Musenski must have better PR people, but don't forget about Soekris. They make network computers that include two slots for radios and one slot for hardware encryption, running *BSD or Linux.
Several people have mentioned Apple's Software Base Station. I will point out that free Unix-alike operating systems provide for a much more capable "software base station" than MacOS does. Slap one or two 802.11b cards into any Unix box and you can use the machine for a base station, router, and bridge all at once.
With a device like the Soekris net4521, your base station is just a compact general purpose unix machine with two radios and hardware encryption. Many people have also hacked regular base station products to boot Linux or BSD instead of the vnedors software.
So remember, every access point is a software base station. The only difference in Apple's Software Base Station is that the nouns are capitalized.
On a system doing ONLY I/O, software RAID is usually faster. A 1.0 GHz Pentium III can XOR some checksums in a hurry. It's much more powerful than the i960 chip on your DPT cards.
For a system that needs to save some CPU time for things other than I/O, I agree that hardware RAID makes sense.
Well, I don't personally make this stuff up. I assumed the huge number is due to cache effects. The 200,000 number comes from presentation given by Compaq people, archived here:
http://www.eecs.umich.edu/vlsi_seminar/f01/slides/ bannon.pdf
Check page 31.
You are right though, after checking http://www.cs.virginia.edu/stream/standard/Bandwid th.html the scale on that chart probably should be divided by 1000.
Wow those stream numbers suddenly look really pathetic. On a 32-way DEC^WCompaq EV7, STREAM hauls down 200,000GB/s, or 300 times faster than the top supercomputer in the list you cite.
The point is LCDs have three times as many individually controlled pixels as CRTs. Check http://grc.com/ctwhat.htm for an explanation. XFree86 4.1+ and Windows 2000+ take advantage of this but MacOS X (afaik) only renders in whole pixels which is silly.
More LCD Pros: Power consumption Digital interface Sub-pixel text rendering
More CRT cons: Power consumption Power supply & amp failure Analog interface Focus Convergence Radiation
Seriously, I have sitting right here on the desk with me the Sony GDM-F500R, still the best monitor Sony makes, and a Samsung SyncMaster 210T, both running at 1600x1200. There is no contest. I can stare at source code continuously with the Samsung (thanks to the sub-pixel rendered text, the horizontal resolution is 300dpi), but with the Sony I need to take breaks. Focus and convergence on the Sony are worse in proportion to the distance from the center of the screen. The Sony needs to go to Irvine, CA (100lbs shipping cost) for professional adjustment and maintenance every two years or so.
Sure, the CRT has terrific color and response, but that isn't enough to overcome its annoying electro-optical problems.
The pixels themselves last a really really long time. Much longer than the display technology will probably be useful. The backlights need to be replaced after a few years of use. An old backlight will either fail altogether or just turn purple. Luckily the backlights are inexpensive and easy to replace.
That's really not true. LCDs reduce eyestrain because their horizontal resolution is much higher than CRTs. A 1600x1200 LCD has 4800 pixels across. This wealth is exploited by software like Xfree86's Xft and Microsoft's ClearType, effectively tripling the horizontal resolution of the screen for reading text. The result is much less eyestrain when reading text on an LCD.
The other problem with CRTs which causes eyestrain is movement. Display a web page on a CRT, then look at a glyph under a magnifying glass. The glyph will be shaking slightly. Even the best CRTs do this, because the scanning process has some inherent inaccuracy. This problem does not affect LCDs. The pixels on an LCD are mechnically fixed and cannot move. When using a digital LCD, there are no PLLs and amplifiers to distort the signal.
The combination of these two things means LCDs cause much less eyestrain than CRTs.
You must live on in an alternate universe where a vessel can be
in open, navigable waters; and
stuck on a reef
Are you for real? The U.S. Coast Guard define aground as "touching or fast to the bottom." The Valdez was hard aground on a reef. It could not be dislodged. You don't have to hit land to be aground. Any lack of sufficient depth qualifies.
I'm having a little trouble seeing which part of your statement refutes mine. The Valdez was not in a shipping lane when it ran aground. It was operating close inshore, whether intentionally or accidentally. I refer you to the report of the State of Alaska at http://www.oilspill.state.ak.us/history/commish.ht m
At no time did the Exxon Valdez report or seek permission to depart farther east from the inbound traffic lane; but that is exactly what it did.
At 11:30 p.m. Hazelwood informed the Valdez traffic center that he was turning the ship toward the east on a heading of 200 degrees and reducing speed to "wind my way through the ice" (engine logs, however, show the vessel's speed continued to increase). At 11: 39 Cousins plotted a fix that showed the ship in the middle of the traffic separation scheme. Hazelwood ordered a further course change to a heading of 180 degrees (due south) and, according to the helmsman, directed that the ship be placed on autopilot. The second course change was not reported to the Valdez traffic center. For a total of 19 or 20 minutes the ship sailed south-through the inbound traffic lane, then across its easterly boundary and on toward its peril at Bligh Reef. Traveling at approximately 12 knots, the Exxon Valdez crossed the traffic lanes' easterly boundary at 11:47 p.m.
If you have trouble envisioning how far off course the Valdez went, have a gander at this map:
http://library.thinkquest.org/10867/spill/maps/tan ker_lanes.jpg
The level of ignorance on Slashdot has increased tremendously lately.
The Prince William Sound herring population has failed almost completely and commercial fishing is no longer allowed.
http://www.cf.adfg.state.ak.us/region2/finfish/h er ring/pws/pwsupd02.htm
According to the Alaska Department of Fish and Game, who can be considered a primary source, "no recovery was evident in 1995, and based on this, the 1996 commercial fishing season was canceled." The fishing season has been cancelled every year since. The population of herring in Prince William Sound is only 1/10th the size needed to support commercial fishing.
Ignoring the above microsoft tangential rant, the rest of the post is spot on. The "drunk captain" story was something Exxon cooked up to try to save face. Hazelwood was below decks asleep (and drunk) when the Exxon Valdez ran aground. The third mate Gregory Cousins was at the helm. The real reason the Exxon Valdex ran aground is because it had a broken radar and had been operating without radar for over a year. The Valdez was out of VTS radar coverage and operating close in to shore, much closer that the 20 mile buffer they were required to keep. The reason the oil spill was such a disaster is because the oil terminal operators had gotten rid of those pesky expensive oil spill experts and their costly equipment.
Uh? I don't remember any #9 cards with 128MB of memory. In fact, #9 was out of business two years ago. You may remember the #9 i128 series of cards, but those are very old and do not have 128MB memory.
You only need 16MB to handle th highest resolution computer graphics displays ever made.
This is actually what SRV records are for. You can put in a SRV record for smtp pointing to h0001. SRV records have the bonus feature of automatic discovery by smarter applications and operating systems. Unfortunately elightenment is currently limited to very few applications.
Make the hostname and the service orthogonal. If your machine is just named h0001.sfo.domain.net, you can easily repurpose it from http to imap service. But if the name is http0001.sfo.domain.net, you'll need to change DNS and change the machine's configuration files before you can repurpose the box. Then you'll have to update your ssh authorized_keys and known_hosts files, and any other information that deals with hosts.
My company is an example of extremely stupid behavior. We have desktop machines named jsmithw2knyc. Anytime the machine is reassigned to another person, moved from office to office, or changes operating systems, the hostname and DNS must be updated. It's silly.
I doubt this will produce any performance gains at all. Code will still need to be written specifically for the AltiVec unit, using either the C extensions or assembler. A simple recompile will not bring any gains, unless RedHat are able to improve GCC's PPC code generation.
BTW, GCC and binutils already support the AltiVec, including the C extensions.
Slashdot Mirror
CPU speed is totally unrelated. Even if we ignore the CPU penalty of IDE, about twice as much CPU time as SCSI, the SCSI disks are just moving faster than any IDE drive at any price.
Maxtor's product page
That's probably true. For example, you can buy a n 80GB western digital 7200RPM drive for $150. That is $1.88/GB. The only 7200RPM SCSI drive made these days is the Seagate Barracuda, which is $300 for 36GB: $8.33/GB.
That really isn't the point of SCSI though. I'll accept that IDE wins on a money-per-GB basis. But, IDE has a performance ceiling that SCSI doesn't have. You can't get 10000RPM and 15000RPM drives for IDE at any price, period.
There is a point, when building RAID systems, where SCSI exceeds IDE in the $-per-I/O-per-second metric. In desktop systems, you probably won't exceed this point. But if you intend to have stripe sets of 4 or more disks, SCSI will win the price wars again.
Anyway it really isn't a matter of SCSI being expensive and IDE being cheap. It's the drives that are expensive/cheap and it simply works out that expensive drives get SCSI connections and cheap drives get IDE connections.
P.S. Have fun trying to get you 4-disk IDE RAID all within 18 inches of your IDE controller :)
Ever consider setting your fonts one size larger?
What is it about slashdot, where disease corporations like Disney and other MPAA members are alternately booed and cheered?
Someone has to manufacture an ASIC to decode vorbis. You can't do it on a general purpose processor because the usual embedded processors like ARM are not fast enough and processors that are fast enough use too much power. I don't think anyone will produce a vorbis ASIC until a huge market for portable, low-power vorbis players exist.
The only likely scenario would be an existing MP3 ASIC manufacturer adding vorbis support to their product. At least that wouldn't require (much) more space on the circuit board.
It is at the same stage as the Musenki: shipped in small quantities to testing customers.
Musenski must have better PR people, but don't forget about Soekris. They make network computers that include two slots for radios and one slot for hardware encryption, running *BSD or Linux.
With a device like the Soekris net4521, your base station is just a compact general purpose unix machine with two radios and hardware encryption. Many people have also hacked regular base station products to boot Linux or BSD instead of the vnedors software.
So remember, every access point is a software base station. The only difference in Apple's Software Base Station is that the nouns are capitalized.
For a system that needs to save some CPU time for things other than I/O, I agree that hardware RAID makes sense.
Well, I don't personally make this stuff up. I assumed the huge number is due to cache effects. The 200,000 number comes from presentation given by Compaq people, archived here: http://www.eecs.umich.edu/vlsi_seminar/f01/slides/ bannon.pdf
Check page 31.
You are right though, after checking http://www.cs.virginia.edu/stream/standard/Bandwid th.html the scale on that chart probably should be divided by 1000.
Wow those stream numbers suddenly look really pathetic. On a 32-way DEC^WCompaq EV7, STREAM hauls down 200,000GB/s, or 300 times faster than the top supercomputer in the list you cite.
The point is LCDs have three times as many individually controlled pixels as CRTs. Check http://grc.com/ctwhat.htm for an explanation. XFree86 4.1+ and Windows 2000+ take advantage of this but MacOS X (afaik) only renders in whole pixels which is silly.
More LCD Pros:
Power consumption
Digital interface
Sub-pixel text rendering
More CRT cons:
Power consumption
Power supply & amp failure
Analog interface
Focus
Convergence
Radiation
Seriously, I have sitting right here on the desk with me the Sony GDM-F500R, still the best monitor Sony makes, and a Samsung SyncMaster 210T, both running at 1600x1200. There is no contest. I can stare at source code continuously with the Samsung (thanks to the sub-pixel rendered text, the horizontal resolution is 300dpi), but with the Sony I need to take breaks. Focus and convergence on the Sony are worse in proportion to the distance from the center of the screen. The Sony needs to go to Irvine, CA (100lbs shipping cost) for professional adjustment and maintenance every two years or so.
Sure, the CRT has terrific color and response, but that isn't enough to overcome its annoying electro-optical problems.
The pixels themselves last a really really long time. Much longer than the display technology will probably be useful. The backlights need to be replaced after a few years of use. An old backlight will either fail altogether or just turn purple. Luckily the backlights are inexpensive and easy to replace.
The other problem with CRTs which causes eyestrain is movement. Display a web page on a CRT, then look at a glyph under a magnifying glass. The glyph will be shaking slightly. Even the best CRTs do this, because the scanning process has some inherent inaccuracy. This problem does not affect LCDs. The pixels on an LCD are mechnically fixed and cannot move. When using a digital LCD, there are no PLLs and amplifiers to distort the signal.
The combination of these two things means LCDs cause much less eyestrain than CRTs.
Are you for real? The U.S. Coast Guard define aground as "touching or fast to the bottom." The Valdez was hard aground on a reef. It could not be dislodged. You don't have to hit land to be aground. Any lack of sufficient depth qualifies.
If you have trouble envisioning how far off course the Valdez went, have a gander at this map: http://library.thinkquest.org/10867/spill/maps/tan ker_lanes.jpg
The level of ignorance on Slashdot has increased tremendously lately.
http://www.cf.adfg.state.ak.us/region2/finfish/h er ring/pws/pwsupd02.htm
According to the Alaska Department of Fish and Game, who can be considered a primary source, "no recovery was evident in 1995, and based on this, the 1996 commercial fishing season was canceled." The fishing season has been cancelled every year since. The population of herring in Prince William Sound is only 1/10th the size needed to support commercial fishing.
Basically, oil companies are extremely evil.
You only need 16MB to handle th highest resolution computer graphics displays ever made.
Maybe because they're labeled experimental?
They have been on the standards track for two years. Check RFC 2782 which obsoletes RFC 2052.
This is actually what SRV records are for. You can put in a SRV record for smtp pointing to h0001. SRV records have the bonus feature of automatic discovery by smarter applications and operating systems. Unfortunately elightenment is currently limited to very few applications.
My company is an example of extremely stupid behavior. We have desktop machines named jsmithw2knyc. Anytime the machine is reassigned to another person, moved from office to office, or changes operating systems, the hostname and DNS must be updated. It's silly.
BTW, GCC and binutils already support the AltiVec, including the C extensions.