Daniel Phillips <phillips@phunq.net> writes:

quoted text
> Anecdote time.  Remember there used to be "brand name" floppy disks and
> generic floppy disks, and the brand name ones cost a lot more because
> they were supposedly safer?  Well, big secret, studies were done and
> the no-name disks came out better.  Why?  Because selling at commodity
> prices the generic makers could not afford returns.  So they made them
> well.

I don't think so. I remember we had much more problems with noname
disks. And yes, certain brands had been problematic too, but most
(such as Fuji and 3M, and others) were fine.

quoted text
> It is like that with PCs.  Supposedly you get a lot more reliability
> when you spend more money and buy all high end near-custom gear.  In
> fact, the cheap stuff just keeps on chugging, because those guys can't
> afford to have it break.

The real life can't agree with this at all. The servers keep working
for years and the cheap stuff quit fast (if initially working, which
is not always the case).

quoted text
> The worst bug I've seen in a server this year?  A buggy bios in a Dell
> server that would issue a keyboard error and sit and wait for somebody
> to press F1 when there was no keyboard attached.

Most BIOS (all I've seen in this Millennium) have an option to disable
that.

On a server board you can usually have a remote console, how could
that work otherwise?

quoted text
> That is embedded
> software for you.

Server != embedded.

quoted text
> Yes.  Dual power supplies are highly recommended for this
> application.

:-)
So which user groups are you aiming at exactly?

quoted text
> Right.  What we are talking about is filling in a missing level in the
> cache hierarchy, something like:
>
>    L1 .3 ns
>    L2 3 ns
>    L3 30 ns
>    Ramdisk 2 us
>    Flash 20 us
>    Disk 3 ms

We already have RAM between L3 and Flash.
The problem is flushing L1 to disk/flash takes time.
-- 
Krzysztof Halasa
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/