Anthony's drive issues.Re: ssh password delay

[Anthony Atkielski]

Ted Mittelstaedt writes:

> The dmesg you sent indicated that the 2 disks were negotiating at
> different sync rates.  If you did limit them to 10mbt sync negotiation
> as you stated, then why does the dmesg show them at different rates?

It dates from before the change.  They both show 10.00 MB/s now in both
the BIOS and dmesg, but the problem remains.

> Of course, because you know perfectly well that doing this would
> really prove it's either the hardware or FreeBSD, and you don't want
> to take the risk of it being hardware, and looking like a fool.

I don't care what I look like (I grew out of that decades ago), I just
want a system that runs.  I do know, however, that blaming hardware is
the standard delay tactic for those who wish to deny the existence of
software bugs.  "Rule out every transistor in the machine, and then
we'll talk."

> Let's assume for the sake of argument that a SCSI guru comes over to
> your house with a $100K hardware SCSI analyzer, determines it's a
> bug in the Adaptec microcode, then writes in a workaround in the
> driver.
>
> You would take it as proof that the FreeBSD driver was buggy - because
> it didn't contain the workaround for your buggy hardware.

Yes.  But the problem would be fixed, and that's the important part.

> In short, in your universe, the only possible thing your going to
> believe is that it's a bug in the FreeBSD driver.  Even if the
> bug isn't in the driver but in the hardware and the driver implements
> a kludge for it.

This isn't a religious crusade.  I just want hardware and software that
work together.  They did that with NT; they don't do that with FreeBSD.

> Anthony, I have had EXACTLY the same kind of problem with NT4 back in
> 1998 ...

I'm not running NT4, I'm running FreeBSD, so it was obviously a
different problem.

> I got exactly nowhere.  Oh sure, the tech support person claimed that the
> problem had been escalated to the developer.  But they would just go away
> for a few days then e-mail requesting another dump.  Then repeat the process.

That's the way tech support works.  In tech support, a call that is
waiting for customer response is nearly as good as a call that is
closed.

Additionally, developers often don't ever get around to looking at
problems sent to them by tech support.  And they often play the same
game, asking for this or that just to get the problem off their list.

> This is EXACTLY how it is done in real life.

Yes, I know how it's done in real life.

> That is also when I discovered how Microsoft gets away with telling
> the world that they will fix any problem that you call into their
> $250-and-incident tech support people. If you present them with a
> problem they cannot figure out, they will just ask for dump after
> dump, over and over, until you get tired of it and go away. Then they
> mark it down to the customer not wanting to pursue the ticket and pat
> themselves on the back and claim this must mean it was never their
> fault to begin with.

That's right.  That's how most companies do it.  Is that the example you
chose to follow?

-- 
Anthony