Date: Tue, 22 Mar 2005 11:40:09 +0100 From: Anthony Atkielski <atkielski.anthony@wanadoo.fr> To: freebsd-questions@freebsd.org Subject: Re: Anthony's drive issues.Re: ssh password delay Message-ID: <1181508865.20050322114009@wanadoo.fr> In-Reply-To: <1111486000.751.221.camel@lorna.circlesquared.com> References: <20050321095647.R83831@makeworld.com> <LOBBIFDAGNMAMLGJJCKNIEOAFAAA.tedm@toybox.placo.com> <1907678552.20050322101315@wanadoo.fr> <1111486000.751.221.camel@lorna.circlesquared.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1181508865.20050322114009>