Another one bites the dust - SGI

This is a discussion on Another one bites the dust - SGI ; Per Ekman wrote: > SkyWriter writes: > > > Per Ekman wrote: > > > > > SkyWriter writes: > > > > > > > What vendor drives failed at that rate? current enterprise drives > > > > ...

+ Reply to Thread
Page 3 of 4 FirstFirst 1 2 3 4 LastLast
Results 41 to 60 of 64

Thread: Another one bites the dust

  1. Re: Another one bites the dust

    Per Ekman wrote:

    > SkyWriter writes:
    >
    > > Per Ekman wrote:
    > >
    > > > SkyWriter writes:
    > > >
    > > > > What vendor drives failed at that rate? current enterprise drives
    > > > > should have a MTBF of 200,000 to 800,000 hours.
    > > >
    > > > That's way low. I'd say 1.2M to 1.4M (with 1M for non-enterprise
    > > > drives). Yes, I know that is what the manufacturers claim and has no
    > > > relation to reality. Reliable numbers are hard to impossible to find.
    > > >
    > > > *p

    > >
    > > unless you happen to have a statistically significant sample

    >
    > True. It's usually pretty hard to get though, even if you have a
    > couple of hundred drives they tend to be from the same batch (such as
    > in a cluster) and are sensitive to skewing the result on that basis.


    for normal process variation, and test escapes. yes.

    >
    >
    > But for the hell of it, back-of-the-envelope for one of our clusters
    > with around 350 disks real MTBF is in the order of 100,000 hours, but
    > that is not enterprise disks. Enterprise disks in my experience is
    > about a factor of 10 more reliable than desktop disks, and tape
    > another factor of 10 (Magstar that is). Reliability for certain
    > desktop disks goes to hell fast after 2 years.
    >
    > *p


    you're in the right ball park. 350 drives is a single mid-highend enterprise
    array.
    still not enough of a sample.

    what are your servicability requirements for your cluster? do you spare out
    entire
    nodes on a regular basis?

    most disk vendors are focusing R&D on desktop market, although there
    are still some tricks to be wrung from highend. overall commodity reliability

    is on the downside lately as cost pressures will cut corners all around.




  2. Re: Another one bites the dust

    >>>>> On Sun, 29 Aug 2004 12:12:41 +0800, hamei
    >>>>> said:


    hamei> There is something intrinsically insulting about calling a
    hamei> person a "fanboy" because they prefer a quality piece of
    hamei> work over a piece of trash.

    [snip]

    hamei> I prefer quality over pig ****.

    well, when you put it like this, what do you expect?

    --
    garglemonster@my-deja.com

    Once, there was NO fun ... This was before MENU planning, FASHION
    statements or NAUTILUS equipment ...


  3. Re: Another one bites the dust

    hamei wrote:

    >
    > And truthfully, I'm not so opposed to Linux. I wanna buy a
    > Samsung i519 *because* it runs Linux, in fact. However, when
    > people propose Linux as the panacea for all corporate ills
    > then I get testy. Linux is okay for what it is. But it's NOT
    > okay for what it isn't. Pretending that everything will be
    > Right with the world as soon as we have Linux to save us is
    > naive and foolish.


    yes, you see, must of use do run linux (i have 18 unix boxes) and we know
    it's failings. I'm just annoyed it doesn't stay in the
    comp.sys.linux.bebopaloobop usenet, instead of commoditizing the
    com.lsys.sgi.* usenet, after all it's the differences that make usenet
    interesting not the similarities. and it has been a whle since there has
    been a 'fix my peece' post for some reason.


  4. Re: Another one bites the dust

    Tony 'Nicoya' Mantler wrote:

    >
    > Clean room implementations are actually done for legal convinience rather than
    > for legal necessity. Since programming is both a creative and a functional
    > pursuit, there is often cases where independant implementations would *appear*
    > to the untrained eye to be copied or derived.
    >
    > Thus some smart lawyers came up with the idea of clean-rooming, so that they
    > could point to their process and say "they couldn't have copied it, they never
    > even saw it!".
    >
    > So you never strictly need to follow a clean-room process to legally reimplement
    > copyrighted code, it's just more convinient if the person who owns the copyright
    > on the original code throws a hissy-fit.


    no, having lately given disposition in a patent case;a clean room implementation is
    precisely for the purposes of saying "I don't know" so you are not speculating and
    either introducing misinformation or giving the any information along the lines so
    they are not pursued by the prosecutor. this is not a matter of convenience, it is a
    metter of proceedure.


  5. Re: Another one bites the dust

    SkyWriter wrote:

    > hamei wrote:
    >
    > >
    > > And truthfully, I'm not so opposed to Linux. I wanna buy a
    > > Samsung i519 *because* it runs Linux, in fact. However, when
    > > people propose Linux as the panacea for all corporate ills
    > > then I get testy. Linux is okay for what it is. But it's NOT
    > > okay for what it isn't. Pretending that everything will be
    > > Right with the world as soon as we have Linux to save us is
    > > naive and foolish.

    >
    > yes, you see, must of use do run linux (i have 18 unix boxes) and we know


    correction:
    "yes, you see, most of us do run linux (i have 18 linux boxes)" etc..

    > it's failings. I'm just annoyed it doesn't stay in the
    > comp.sys.linux.bebopaloobop usenet, instead of commoditizing the
    > com.lsys.sgi.* usenet, after all it's the differences that make usenet
    > interesting not the similarities. and it has been a whle since there has
    > been a 'fix my peece' post for some reason.



  6. Re: Another one bites the dust

    > D) Commercial software support for Linux is superior (certainly
    > within HPC) to Irix
    >

    You meant the other way around, right?
    There is no doubt the trend is to go toward Linux away from traditional
    proprietary UNIX, but this is by far not the case today.

  7. Re: Another one bites the dust

    In article <41323963.8A93CEC9@mrnutty.com>, SkyWriter
    wrote:

    : no, having lately given disposition in a patent case;

    Patents are not copyrights. Clean-room reimplementation of a patented device
    does not grant you any legal protections. In fact, you're still liable even if
    you've never seen the patent or patented device (though if you are aware of the
    patent you get bumped up to willful infringement).

    : a clean room implementation is
    : precisely for the purposes of saying "I don't know" so you are not speculating and
    : either introducing misinformation or giving the any information along the lines so
    : they are not pursued by the prosecutor. this is not a matter of convenience, it is a
    : metter of proceedure.

    I'm having a hard time reading this, are you agreeing or disagreeing?

    What I'm saying is that there's nothing illegal, as far as copyright is
    concerned, about looking at a chunk of code and reimplementing it's ideas and
    functionality yourself.

    The only snag is that code that does the same often looks the same, so following
    clean-room procedures is the simplest way of erasing all doubt.

    Of course, the point is moot as SGI owns SGI code and IBM will eventually make
    sure that SCO ain't seen 'round no more. SCO doesn't even own the copyright on
    any code that would even be useful to Linux.


    Cheers - Tony 'Nicoya' Mantler

    --
    Tony 'Nicoya' Mantler -- Master of Code-fu -- nicoya@ubb.ca
    -- http://nicoya.feline.pp.se/ -- http://www.ubb.ca/ --

  8. Re: Another one bites the dust

    UNIX Museum writes:

    > > D) Commercial software support for Linux is superior (certainly
    > > within HPC) to Irix
    > >

    > You meant the other way around, right?
    > There is no doubt the trend is to go toward Linux away from traditional
    > proprietary UNIX, but this is by far not the case today.


    Not in the HPC space as I see it, it may be different in other sectors
    (I can easily imagine that it's the other way around in graphics for
    instance).

    *p


  9. Re: Another one bites the dust

    Tony 'Nicoya' Mantler wrote:

    > In article <41323963.8A93CEC9@mrnutty.com>, SkyWriter
    > wrote:
    >
    > : no, having lately given disposition in a patent case;
    >
    > Patents are not copyrights. Clean-room reimplementation of a patented device
    > does not grant you any legal protections. In fact, you're still liable even if
    > you've never seen the patent or patented device (though if you are aware of the
    > patent you get bumped up to willful infringement).


    i am not talking about copyrights. given there is no eveidence you have prior knowledge
    of a specific implementation (covered by patent claims) it depends on your history of
    records vs the others to establish who's patent claims infringe.

    >
    > : a clean room implementation is
    > : precisely for the purposes of saying "I don't know" so you are not speculating and
    > : either introducing misinformation or giving the any information along the lines so
    > : they are not pursued by the prosecutor. this is not a matter of convenience, it is a
    > : metter of proceedure.
    >
    > I'm having a hard time reading this, are you agreeing or disagreeing?


    of course i'm not agreeing with you; this is usenet. if perhaps we are arguing the same
    point then so be it.

    >
    >
    > What I'm saying is that there's nothing illegal, as far as copyright is
    > concerned, about looking at a chunk of code and reimplementing it's ideas and
    > functionality yourself.


    no, looking at the code, or even related patatent can be basis for infringement.

    >
    > The only snag is that code that does the same often looks the same, so following
    > clean-room procedures is the simplest way of erasing all doubt


    >
    >
    > Of course, the point is moot as SGI owns SGI code and IBM will eventually make
    > sure that SCO ain't seen 'round no more. SCO doesn't even own the copyright on
    > any code that would even be useful to Linux.


    why does it always come down to linux. i'm out of here....

    when is GNU going to finish their kernel and start something interesting.

    >
    >
    > Cheers - Tony 'Nicoya' Mantler
    >
    > --
    > Tony 'Nicoya' Mantler -- Master of Code-fu -- nicoya@ubb.ca
    > -- http://nicoya.feline.pp.se/ -- http://www.ubb.ca/ --



  10. Re: Another one bites the dust

    Tony 'Nicoya' Mantler wrote:

    > I am very confident that IBM is preparing some concrete galoshes for
    > SCO. Has
    > anyone ever won a significant lawsuit against IBM?



    The Justice Department, back when they had some balls.

    Other than that, no, I've never heard of anyone beating IBM :-)

  11. Re: Another one bites the dust

    On Mon, 30 Aug 2004 20:19:50 +0800,
    hamei , in
    wrote:

    >+ The Justice Department, back when they had some balls.
    >+
    >+ Other than that, no, I've never heard of anyone beating IBM :-)


    And I don't think they actually won. It went on for 10 years, and at
    the end it came to a "well, the reason we sued IBM no longer exists,
    so let's just drop all this and go home".

    The Nazgul seem to be...efficient...

    James
    --
    Consulting Minister for Consultants, DNRC
    I can please only one person per day. Today is not your day. Tomorrow
    isn't looking good, either.
    I am BOFH. Resistance is futile. Your network will be assimilated.

  12. Re: Another one bites the dust

    In article <4132D003.3C43BDF5@mrnutty.com>, SkyWriter
    wrote:

    : i am not talking about copyrights. given there is no eveidence you have prior knowledge
    : of a specific implementation (covered by patent claims) it depends on your history of
    : records vs the others to establish who's patent claims infringe.

    This whole thread is about copyrights and clean-room procedures are both only
    relevant to copyrights, not patents.

    If you are unaware of a patented technology and implement it by coincidence,
    that's infringement. If you are aware of the patented technology that changes to
    willful infringement and the penalties are much higher. If you follow clean-room
    procedures then you (the company) are still aware that the technology is
    patented thus it's still willful infringement.

    Of course, I don't support the very broad range of subjects covered by patents
    these days, but that's a whole other thread.


    : > What I'm saying is that there's nothing illegal, as far as copyright is
    : > concerned, about looking at a chunk of code and reimplementing it's ideas and
    : > functionality yourself.
    :
    : no, looking at the code, or even related patatent can be basis for
    : infringement.

    A: This thread is about copyrights, not patents.
    B: Looking at the code or related patent bumps you up from infringement to
    willful infringement, but both are illegal.


    : why does it always come down to linux. i'm out of here....

    Well that's what this thread is about.


    : when is GNU going to finish their kernel and start something interesting.

    I think they're waiting to bundle Duke Nukem Forever with it, or something.


    Cheers - Tony 'Nicoya' Mantler

    --
    Tony 'Nicoya' Mantler -- Master of Code-fu -- nicoya@ubb.ca
    -- http://nicoya.feline.pp.se/ -- http://www.ubb.ca/ --

  13. Re: Another one bites the dust

    Per Ekman wrote:

    > Not in the HPC space as I see it, it may be different in other sectors
    > (I can easily imagine that it's the other way around in graphics for
    > instance).
    >

    Hmmm... That is not my experience at all... sgi with IRIX/MIPS-based
    systems is actually pretty well represented in HPC. For instance, in the
    domain of crash simulation at all the major automotive OEMs (Ford,
    Daimler, ...), it's all running on massive sgi... Same at Boeing and
    NASA for large scale CFD... No doubt that everybody is trying to move to
    Linux (whether sgi manages to push their Altix stuff or they lose their
    customer to HP or IBM), but the really big stuff isn't there yet...

  14. Re: Another one bites the dust

    Tony 'Nicoya' Mantler wrote:

    > In article <4132D003.3C43BDF5@mrnutty.com>, SkyWriter
    > wrote:
    >
    > : i am not talking about copyrights. given there is no eveidence you have prior knowledge
    > : of a specific implementation (covered by patent claims) it depends on your history of
    > : records vs the others to establish who's patent claims infringe.
    >
    > This whole thread is about copyrights and clean-room procedures are both only
    > relevant to copyrights, not patents.
    >


    ah, yeah you're right. i went off into the weeds on this one; if you want to talk about
    copyrights.

    >
    > : when is GNU going to finish their kernel and start something interesting.
    >
    > I think they're waiting to bundle Duke Nukem Forever with it, or something.


    RMS and Duke Nukem.... i never saw that one coming.

    >
    > Cheers - Tony 'Nicoya' Mantler
    >
    > --
    > Tony 'Nicoya' Mantler -- Master of Code-fu -- nicoya@ubb.ca
    > -- http://nicoya.feline.pp.se/ -- http://www.ubb.ca/ --



  15. Re: Another one bites the dust

    Tony 'Nicoya' Mantler wrote:

    > Hamei thinks that just because SGI added code to their linux kernel, that it
    > instantly has to appear in linus' kernel too or they'd be breaking the GPL.
    > (which is incorrect)


    No, that's correct. If it's part of the kernel then it is GPL (see oss.sgi.com).

    Other portions of the Altix ProPack, though, are LGPL or closed-source. It's
    all a matter of creating GPL kernel hooks and implementing the rest in user space,
    where you're free to license software in any odd way you could chose, and where
    someone else is perfectly free to come up with a better alternative.

    An example: cpumemsets are open-sourced (though soon to be replaced by
    redesigned and Linus-blessed GPL software by SGI, Bull, IBM and SuSE in
    the 2.6 kernel). the cpuset API lbrary that uses cpumemsets is not.

    cpumemsets and libcpuset.so in 2.4 kernels is pretty crappy
    compared to the IRIX kernel cpuset features.

    The redesign for 2.6, however, has the potential to get rid of some of the
    ugly warts of the IRIX cpuset architecture and implementation. One of the
    good things about Linux is that it's much harder to get the community to
    accept ugly warts hacked in by a single brilliant engineer
    to satisfy a customer ASAP, some of which many come to regret afterward
    once you have better ideas.

    >
    > I love IRIX as much as anyone else, but I know that SGI either a: doesn't have
    > the skills and ability to move the goodness of IRIX to Linux, in which case it's
    > doubtful if they have the skills to keep IRIX a viable platform either, or b:
    > has all the skills and ability needed to make Linux as good as and better than
    > IRIX, in which case the future looks pretty bright, no matter what the OS is
    > called.
    >

    b. I have the greatest respect for some of out Linux core engineers (some of
    those were working on Linux outside SGI in the past, some were working on
    specific IRIX functionality our customers really, really need on Linux).

    >
    > So, to all the rabid IRIX fanboys: can the Linux hate.


    Seconded.

    Just for a balanced view, I'll add that Linux fans better cut the
    hype as well - there are many areas in which IRIX is still miles ahead (VM
    management, buffer cache management, NFS,...), and Linux is not yet the
    be-all and end-all of operating systems (and can be just as crappy as Solaris
    at times ), not even when you're running recent 2.6 kernels.

    But those Linux fan boys you'll usually find in other forums...

    --
    Alexis Cousein Senior Systems Engineer
    alexis@sgi.com SGI/Silicon Graphics Brussels

    If I have seen further, it is by standing on reference manuals.


  16. Re: Another one bites the dust

    hamei wrote:
    > If that is incorrect it's a new thing. Linus himself always sneered
    > at SNP,


    Not *always* -- I can assure you he doesn't sneer at SMP anymore.

    Define "new". It's not a new thing in my eyes, but if you
    consider anything newer than 6 years old as "new", we may well have
    semantics that lead us to write different things...

    --
    Alexis Cousein Senior Systems Engineer
    alexis@sgi.com SGI/Silicon Graphics Brussels

    If I have seen further, it is by standing on reference manuals.


  17. Re: Another one bites the dust

    Per Ekman wrote:
    > I'm no laywer but I know that lots of people disagree with your
    > statments here. SGI has done lots of own work on scaling in Irix,
    > derivative works and all that, it's not at all clear that this is in
    > any way owned by SCO or Novell or whoever owns the copyright of Unix.
    > I also very much doubt that Irix and Linux are similar enough that SGI
    > can bring code from Irix into Linux.


    In fact, it's very clear that no-one, not even AT&T, owns these pieces
    of original SGI code. One only has to read the declarations from
    AT&T people IBM recently included in one of its filing to see that SCO's
    fancy derivative works theory is just that -- a theory that no-one at
    AT&T would ever have dreamed of coming up with.

    > "Linux sucks for obscure legal reasons."


    Certainly my favourite.

    --
    Alexis Cousein Senior Systems Engineer
    alexis@sgi.com SGI/Silicon Graphics Brussels

    If I have seen further, it is by standing on reference manuals.


  18. Re: Another one bites the dust

    hamei wrote:
    > You probably aren't from the US, where we have the DMCA and
    > other assorted draconian copyright laws covering software.
    > Do you remember the lawsuit over the original peecee BIOS ?
    > When the only reason Compaq could get away with duplicating
    > IBM software was because their engineers *had never seen a
    > single line of IBM code* ?


    You're confusing patents plus trade secrets on the one hand
    and copyright on the other. Of course, documenting the clean-
    room approach to oyur own software development efforts also
    helps to protect against claims of copyright infringement, but
    it is by no means necessary. If someone has shown you code that
    contains trade secrets under the terms of a contract, then you
    may want to implement a clean-room approach if you want to
    implement something similar, depending on the wording of the
    contract; unless there's a (valid) patent covering the actual
    method, of course, in which case you may want a license or
    cross-license from the original author.

    I can take the functionality of a piece of GPL code, *read the code*
    (which means I'm no longer in a clean room), make my own implementation
    of it, and license it in any way I fancy, without any copyright issues.

    I can't *copy* it (definitions about what that would be are
    different depending on which Circuit your courts fall under, in the
    US) or make a derivative without abiding by the
    terms of the GPL for the result, though.

    --
    Alexis Cousein Senior Systems Engineer
    alexis@sgi.com SGI/Silicon Graphics Brussels

    If I have seen further, it is by standing on reference manuals.


  19. Re: Another one bites the dust

    SkyWriter wrote:
    >>So you never strictly need to follow a clean-room process to legally reimplement
    >>copyrighted code, it's just more convinient if the person who owns the copyright
    >>on the original code throws a hissy-fit.

    >
    >
    > no, having lately given disposition in a patent case;



    Again: patent != copyright. A patent protects a patentable method (i.e. some
    subset of what I'd call "ideas"). Copyright only protects specific *expressions*
    of an idea, and not even *all* expressions of an idea *are* copyrightable.

    Neither does a clean room protect you from patent infringement. It does protect
    you from being charged for *willful* infringements (with all the consequences
    that has on damages that can be recovered from you).


    --
    Alexis Cousein Senior Systems Engineer
    alexis@sgi.com SGI/Silicon Graphics Brussels

    If I have seen further, it is by standing on reference manuals.


  20. Re: Another one bites the dust

    In article ,
    Alexis Cousein wrote:

    : Tony 'Nicoya' Mantler wrote:
    :
    : > Hamei thinks that just because SGI added code to their linux kernel, that it
    : > instantly has to appear in linus' kernel too or they'd be breaking the GPL.
    : > (which is incorrect)
    :
    : No, that's correct. If it's part of the kernel then it is GPL (see
    : oss.sgi.com).

    What I meant is that SGI can maintain it's own branch of the kernel, so long as
    they release the source per GPL requirements. If SGI improves the VM or SMP or
    some other feature, it can linger in their "private" kernel branch for quite
    some time (or indefinitely) without being included in the more mainstream
    kernels.

    Of course, there's nothing stopping Linus from going through SGI's kernel branch
    and pilfering that code as he sees fit, as that's exactly what the GPL is
    designed to permit, except generally speaking Linus Doesn't Do That.

    No part of the GPL requires that SGI ensure their linux kernel code appears in
    Linus' kernel branch.

    Sorry for the confusion.


    Cheers - Tony 'Nicoya' Mantler

    --
    Tony 'Nicoya' Mantler -- Master of Code-fu -- nicoya@ubb.ca
    -- http://nicoya.feline.pp.se/ -- http://www.ubb.ca/ --

+ Reply to Thread
Page 3 of 4 FirstFirst 1 2 3 4 LastLast