Anthony's drive issues.Re: ssh password delay

Anthony Atkielski atkielski.anthony at wanadoo.fr
Tue Mar 29 13:13:41 PST 2005


Bart Silverstrim writes:

> That's nice.  I wasn't talking about NT there.  I was talking about
> DOS.

I'm not running anything named DOS.

> Command line, popular before Windows but after CP/M...maybe
> you've heard of it?

I used to run a few operating systems by that name.

> They're trying to help troubleshoot over the list.

Why don't they just suggest that I move to another city, in case there's
RF interference in my neighborhood.  That's troubleshooting, too, but
like swapping hardware, it's not very practical, and you don't start
with the impractical methods if you have no idea what's wrong.

> Did you pass science class?  This would show if it's reproducible as a
> bug.

Nobody even knows what the messages mean.  Without knowing that, what
use is it to try to reproduce it on another machine?

> Slap it on the same damn hardware, *right down to the firmware*
> (remember you have modified firmware?).  If it isn't running on two 
> machines that are exactly the same, that shows an increased chance that
> that is indeed a bug in some driver, and you should contact the driver
> maintainer.

What if the messages don't represent an error?

> It's troubleshooting by eliminating variables.

It's rolling dice unless you first determine what the messages mean.

> Bzzt.  Wrong.  Not if the hardware is going bad or has a problem.

There's no reason to believe that the hardware is going bad.

> See, in our magical and mystical world, we need to be able to
> reproduce the problem in order to help.

How do you know it's a problem?  You don't know what the messages mean.

> Otherwise we have to troubleshoot and speculate.

All anyone has done thus far is guess.

> You know, the things you insist we don't need to do.  On
> top of that, you never even commented on the possibility of someone 
> being able to FIX your problem *IF IT IS* a FreeBSD software problem 
> WITHOUT THE DAMN HARDWARE on which to test the fix.  Sheeyit!  How can
> I fix something on a configuration that I don't even have?

By examining and modifying the code.  Developers do it all the time.

> Wow, how long have you worked in the field as a troubleshooter?

I spent a number of years in that capacity.

> So...unless everything is handled exactly as you wish it, unrealistic
> or not, by volunteers no less, it is a waste of your time.

No, unless people follow a logical course of action to isolate the
problem, if there is one, then they waste my time.

> And here I thought it was because it uses a PPC.

My computer uses Intel hardware, but FreeBSD seems to have a problem
with it.

> Your turn. Pull out that shit controller and set of drives, put in new
> drives and a new controller that's generic instead of modified, and
> see if FreeBSD works.

Tell me what the messages mean, first.

> Then fix it.  Or pay someone to.

I don't have the time to examine the source.

> In the length of time you've spend insulting people on this list you
> could have swapped out the drives and controller and probably have 
> things working already.

Hmm.

> It did, it used an IR interface to do the transfer...hence the note
> *right in my question* about the IR interface.  NT wouldn't allow the 
> access to video that their program used to transfer data to the watch.

How does an IR interface work with visible light?

-- 
Anthony




More information about the freebsd-questions mailing list