Anthony's drive issues.Re: ssh password delay

[Anthony Atkielski]

Peter Risdon writes:

> 1. Does either Windows 2003 or XP SP2, the only versions of Windows that
> are meaningful comparisons with the latest versions of FreeBSD, fully
> and without errors support this SCSI adapter and drive combination?

I don't know.  But I'm not trying to run Windows 2003 or XP SP2.

> 2. Does a version of FreeBSD that is contemporary with NT and your
> machine (ancient, unsupported, like NT) drive this hardware OK?

I don't know.  Why should I have to run an eight-year-old version of
FreeBSD?  Does every new version introduce regressions?  UNIX still
supports dumb terminals that are thirty years old.  Why shouldn't
FreeBSD support disks that are eight years old?

> In the sense that maintaining support for all discontinued devices ever
> made would be a seriously misguided use of resources, this is a feature
> rather than a *defect*.

You don't have to maintain support.  Usually, just leaving the code in
place is sufficient.  That's why UNIX still has support for hardware
that virtually no one still uses.

My guess is that FreeBSD has _never_ supported this hardware correctly.
People have been complaining about it for years.

> You bet. Paid help is surely available. What you fail to realise is that
> nobody is under any obligation to give you such detailed and
> time-consuming help FOR FREE.

So tell me again the advantage of open source, as opposed to proprietary
software?

> FreeBSD development follows the lines decided on by the development
> team, just like every OS in the world. If no developers choose to spend
> time fixing (non-destructive) issues for you, personally, then that's
> their choice. If that is their choice, it's a pretty good one.

It's not the sort of choice that is conducive to widespread use of the
OS.  Software developed by prima donnas answerable to no one makes large
organizations nervous.

> I'd love to see you harangue Microsoft for personalised development and
> support in the way you've been haranguing this list.

I have; some changes in NT were made because of my complaints.

> And, after all is said and done, if your hardware is unsupported, so
> what? It's very, very old. This isn't a fault or a defect; it's part of
> the spec.

What spec?

I have fifty-year-old cameras that still work fine; there's no need to
replace them every 18 months.  Why should I have to replace computers
every 18 months?

> You can find LOTS of archaic hardware that is incompatible
> with the latest versions of FreeBSD - or Apple Mac, or Linux, or (sit
> down for this one) Windows.

You have yet to establish that any "archaic" aspect of the hardware is
at the root of this problem, and in fact you don't actually know what
the problem is.  There doesn't seem to be anyone here who actually knows
anything about FreeBSD internals.  Does anyone ever read the code?

> Staggeringly, you don't appear to realise this. You obviously have
> significant computer experience, but this is something the greenest
> newbie is aware of.

I do have significant computer experience, and I know how attached
people become to their software. I can count on one hand the developers
who have said, on the very bug report, "Oh yes, that sounds like a bug
in my module--I'll get on it right away." It's _always_ Someone Else's
fault in their eyes, and typically they'll never fix their mistakes
unless their job depends on it (or if they do, they'll do so quietly and
pretend that there was never any bug in the first place: "Your hardware
problem must have gone away--you're lucky").

The hardware ploy, in fact, is standard procedure in technical support
organizations.  You always suggest it's hardware, and insist that the
customer verify.  That allows you to suspend the call with "waiting
customer response" for days or weeks.  If the customer ever actually
does what you ask, you come up with some other hardware detail that has
to be tested.  The more awkward and time-consuming it is, the better.
Some customers will give up rather than go through all the useless
procedures you suggest; then you can close the call.

> Maybe he was trying to help? That seems to have been a mistake.

I don't need "help" from people who have no idea what they are talking
about.  I need help from someone who knows what's actually causing the
error and is motivated by something a bit more altruistic than denial.

-- 
Anthony