Although I agree with Paul in general, I understand your need
(although his suggestion to educate them would help - remember when
they ask for the numbers ask them to clearly spell out EXACTLY the
conditions they want the #'s under - how many systems, what kind of
usage, skill of users / admins, etc). Also ask them what exact
standard they are using to measure reliability - is planned downtime
included, what applications, what mix, what hardware, who developed
the standard, how was it developed, how does it compare to their
environment, etc.
As I said in my 1st reply, I suspect this is something that the big
linux supporting companies could fund - some measurements of Linux
uptime across lots of boxes.
Another source: The Linux Kernel Mailing List:
http://kernelnotes.org/lnxlists/linux-kernel/lk_0009_01/msg00107.html
(such timing, any connection?)
jeff
On Thu, 7 Sep 2000, Paul Lussier wrote:
> In a message dated: Thu, 07 Sep 2000 12:44:33 EDT
> Greg Kettmann said:
>
> >I agree with both statements but they completely miss the point.
>
> I disagree. I think they clarify the point if anything. These are
> meaningless statistics, and as such, don't help anyone determine anything.
>
> > I used MTBF, although it's a hardware measurement, because it describes
> > what I need. "Reliability" is more accurate but far more ambiguous.
>
> Realiability is a better term than MTBF, but still vague, and completely
> dependant upon the particular environment in question. And since no 2
> environments are the same, "Reliability", as a statisic, can not really be
> arrived at with any accuracy.
>
> >I've read both responses thoroughly. They make perfect sense but fail to
> >address the core issue. The fact of the matter is that when upper level
> >management, or C-level executives, of multi-billion dollar companies are
> >interested in deploying Linux, that's the language they speak.
>
> Ahh, see, I disagree again. This is not the core issue. The core issue is
> that upper level management seldom really understands what they are buying in
> the first place. Therefore, using generic and meaningless numbers and
> statistics gives them some warm fuzzy feeling inside so that when their
> purchase fails to live up to those promised numbers, they have someone to yell
> at and threaten with legal action.
>
> Because of this, it should not be your job to find and then report these
> meaningless numbers to upper level management types, but rather educate
> them *why* these numbers are meaningless. Then explain why the competing
> product is insufficient for their needs and why Linux is superior.
>
> Should they insist upon these numbers, let them buy some other product
> which comes with promised meaninglessness, and regret their decision
> 6 months down the road.
>
> >I have three such "talks" scheduled over the next three weeks.
> >As silly as their requirements may seem to us the
> >fact is that they won't write that multi-million dollar check, and deploy
> >Linux, without these numbers to back up their decision.
>
> So? Who cares. Move on to the next company who truly understands what it's
> all about. Let them choose the alternative OS. Then visit them again in 6
> months and ask them if it lives up to the promised statistics, and if they've
> remained within budget.
>
> > My original question stands.
>
> So do my original answers.
>
------------------------------------------------------------------------
Jeffry Smith Technical Sales Consultant Mission Critical Linux
[EMAIL PROTECTED] phone:603.930.9739 fax:978.446.9470
------------------------------------------------------------------------
Thought for today: BI //
Common written abbreviation for Breidbart Index.
**********************************************************
To unsubscribe from this list, send mail to
[EMAIL PROTECTED] with the following text in the
*body* (*not* the subject line) of the letter:
unsubscribe gnhlug
**********************************************************
