Re: [SLUG] bogus info?

From: Mario Lombardo (mario@alienscience.com)
Date: Fri Dec 13 2002 - 15:21:08 EST


...

>On Fri, 2002-12-13 at 12:04, Patrick Grantham (at work) wrote:
>> I self proclaimed "expert" tells that - no uncertain terms - that Unix (and
>> Linux) trash hard drives after two-three years. What he says is that
>> because of the heavy load that Unix puts on the heads and actuator, they
>> wear sooner than they would on a M$ box. Could this have been true at one
>> time? I've been in this game a while (albeit on the M$ side of the fence,
>> but on the Linux side for about 3 years now. Sounds like bunk to me. Any
>> thoughts?
>
>what crack is this guy smoking?
>
>he has no idea what he's talking about. 
>
>a) MTBF is based on a buncha drives sitting on a shelf all going
>balls-out 100% TRYING to make them die. If you've ever heard a drive
>doing a read/write head test, it sounds like a machine gun. NO OS, no
>matter how overloaded, is EVER going to stress a drive like an actual
>drive stress test.

Yes, and BLOGs are not any different! :^P When you finally come to
another Tampa meeting, you can punch me then.

>
>b) Linux has an incredibly efficient disk cache. MUCH better than
>MS's. Reads can frequently be cut way down and writes are generally
>lazy/async, which gives the kernel to schedule them in "batches" to
>stress the drive less. (Most BSD's turn on syncronous writes, which is
>a big contention between the BSD and Linux camps. Linux enthusiasts
>like async writes, while BSD enthusiasts insist that syncronous writes
>are much safer and any extra wear on the drive and/or performance impact
>is worth it for getting your data on disk immediately.)

Is that what "sync" is for? I guess that's when you're forcing the
OS to finalize its business with the storage medium.

>
>c) Recent Linux kernels (2.3 series plus) have IDE "elevator"
>optimizations put in. That means that the kernel "schedules" writes to
>the drive so that if, for example, you're writing to cyls 10, 23, 4, 17
>and 9, it will reorder them to write 4, 9, 10, 17, 23. Much more
>efficient, much faster, less stress on the drive.

Wow, I wasn't aware of this. A very interesting and logical approach.

>
>d) tell him "extraordinary claims require extraordinary proof" and ask
>him to back up his claims. if he can't call "ass-talking" on the guy
>and never listen to a thing he says ever again, and make sure everyone
>who you know knows he's a complete idiot.

Then lock him in the elevator with the fireman's key and send him to
the basement and throw boiled lard down the last floor stairs so he
stays there with the LAUNDRY!!!! But before that, make sure you've
secured the valves to the boiler so that he doesn't try to cook you
or freeze you out of winter--pesky little varmint!

>
>e) Smack me in the head with a fish for even bother replying in such
>depth to such an obvious troll....

There is some resemblance of might and brawn to the bearer of
depleted fish in thy hand against the toilsome ragamuffin. That's
why I especially like smacking lads with pregnant fish--that way, all
of the caviar goes on his face and it makes it especially humiliating.

/mario

>
>--
>-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>#!/usr/bin/perl -w
>$_='while(read+STDIN,$_,2048){$a=29;$b=73;$c=142;$t=255;@t=map
>{$_%16or$t^=$c^=($m=(11,10,116,100,11,122,20,100)[$_/16%8])&110;
>$t^=(72,@z=(64,72,$a^=12*($_%16-2?0:$m&17)),$b^=$_%64?12:0,@z)
>[$_%8]}(16..271);if((@a=unx"C*",$_)[20]&48){$h=5;$_=unxb24,join
>"",@b=map{xB8,unxb8,chr($_^$a[--$h+84])}@ARGV;s/...$/1$&/;$d=
>unxV,xb25,$_;$e=256|(ord$b[4])<<9|ord$b[3];$d=$d>>8^($f=$t&($d
>>>12^$d>>4^$d^$d/8))<<17,$e=$e>>8^($t&($g=($q=$e>>14&7^$e)^$q*
>8^$q<<6))<<9,$_=$t[$_]^(($h>>=8)+=$f+(~$g&$t))for@a[128..$#a]}
>print+x"C*",@a}';s/x/pack+/g;eval
>
>usage: qrpff 153 2 8 105 225 < /mnt/dvd/VOB_FILENAME \
> | extract_mpeg2 | mpeg2dec -
>
> http://www.cs.cmu.edu/~dst/DeCSS/Gallery/
>http://www.eff.org/ http://www.anti-dmca.org/



This archive was generated by hypermail 2.1.3 : Fri Aug 01 2014 - 19:16:03 EDT