Date: Wed, 16 Jan 2002 07:20:48 +0100 From: "Anthony Atkielski" <anthony@freebie.atkielski.com> To: "Mike Meyer" <mwm-dated-1011574745.7d17f9@mired.org> Cc: <questions@freebsd.org> Subject: Re: USB CF reader (SanDisk) epilog Message-ID: <01b301c19e55$f11330a0$0a00000a@atkielski.com> References: <15428.34332.870130.2946@guru.mired.org><00cc01c19e06$8dafddf0$0a00000a@atkielski.com><15428.38970.224790.33804@guru.mired.org><00ee01c19e0d$4c518960$0a00000a@atkielski.com> <15428.53337.168408.720031@guru.mired.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Mike writes: > True, but in my experience it's not the main > one. The main one is that debugging problems > remotely means you've got fragmentary and often > inaccurate information to work with. Yes, but the fragmentary and incomplete information refers to the vendor's own documentation. Most vendors document virtually nothing internally. You'd think that there would be stacks and stacks of special manuals for internal use explaining every single module written by a vendor for support purposes, but in fact there is usually nothing beyond the documentation already provided to end users. As a result, so-called technical support amounts to trial and error, with lots of guesswork. You try all sorts of things until you find something that works, and then you recommend that to the customer. The next time you see a problem that looks similar, you recommend the same thing and hope it will work again. If nothing seems to work, you recommend an upgrade to the latest version of anything, which, if nothing else, will get the customer out of your hair for a few weeks or months while he upgrades the software. > Even with the vendors complete documentation > and access to the source, you wind up having > to guess as to what really happened, then provide > a solution for that guess. Mainly because the "complete documentation" is sparse or nonexistent. The scary thing is that the internal workings of most commercial software (or indeed most software, period) are known only to the person(s) who wrote it, since they can't be bothered to write anything down, and vendors will not force them to write anything down because it doesn't generate revenue. > You don't care how error 123 is processed, > you want to know why it occurred. That's a > different question. I have to know why it occurred before I can determine whether or not the way it was processed was appropriate. Intuitively it seems inappropriate that an error should stall the system or prevent a reboot, as this one does, but I cannot be sure unless I know what the error means. > Since I never detach my usb devices, I don't > use usbd. I don't detach my usb devices, either (although I do remove and insert cards in the CF reader). Does this mean that I can remove usbd from rc.conf? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?01b301c19e55$f11330a0$0a00000a>