Date: Wed, 30 Sep 1998 15:10:39 -0500 From: Karl Denninger <karl@Denninger.Net> To: "Justin T. Gibbs" <gibbs@plutotech.com> Cc: scsi@FreeBSD.ORG Subject: Re: Long IDE probes? Message-ID: <19980930151039.A4848@Denninger.Net> In-Reply-To: <199809301957.NAA21005@pluto.plutotech.com>; from Justin T. Gibbs on Wed, Sep 30, 1998 at 01:51:13PM -0600 References: <19980930141056.A4656@Denninger.Net> <199809301957.NAA21005@pluto.plutotech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Sep 30, 1998 at 01:51:13PM -0600, Justin T. Gibbs wrote: > > >The point I'm making here is that anything reasonably current in the SCSI > >world will respond to an INQUIRY - at least - within specs. If it doesn't > >then its broken. We should endeavor to fix that, yes, but at what price? > > > >Where is the line drawn? That's the issue here - we make everyone wait for > >2% of users. > > My main concern is about system installation and tech support load. The > defaults on the installation media should be extremely conservative. My main concern is that people consider things like this (boot time) to be critical for other than server machines. I personally don't care - First, I leave my FreeBSD machine at home up all the time - its a server (screw NT, I reformatted my last NT Server system and replaced it with FreeBSD + Samba - 3x the I/O speed, all the features, and by God, no more blue screens of death!) However, I'm not the majority (how many people have a network in their home and a laptop in the bedroom for night-time surfing, along with an office with a couple of systems there too!) If I were a novice and loading this on a portable machine, I'd go back to Windows. Why? Because that minute-long extra delay sucks, and I won't want to wait for it on the plane. Nor (in the case of IDE in particular) will I know how to get rid of it. > >Why not put this thing in the kernel config screen, and > >default it to the SCSI standard values. If someone needs to tune it (we > >can document that) then tune it. But for the rest of us, its a LOT faster. > > 1) The technology to put it in the kernel config screen is not quite there > yet. This is another item for the generic "fix FreeBSD's configuration > system" task that comes post 3.0R. Well, ok. > 2) Even if you had it in the configuration screen I would still argue, > from a tech support load and usability standpoint, that the default > should be conservative. No. The default should be to the specs. Put something in the startup screen that says "if you have problems with SCSI devices not showing up, select THIS and then please read the FAQ" and selecting <THIS> ups the timeout to 15 seconds. > 3) Post install, there should be a series of options to "better tune your > system". This allows you to educate the user and give them the option > of experimenting with different system tweaks, while falling back to the > previous settings if a failure occurs. Yes. > Wrong. Joe new user looks at the configuration screen, decides that it's > too complicated, and goes with the defaults. The system doesn't see his > SCSI devices. Why? He doesn't know. Maybe this FreeBSD thing is simply > broken. Linux worked okay. So did NT. Hmmm. [ sound of CDROM going > into trash bin ]. Not if Joe New User has a screen starting him in the face that says "If your disk and CDROM don't show up, hit <THIS>" > >(2) don't respond to INQUIRY within specs after a RESET, and > > I am constantly amazed at the number of devices that come on the > market every year that don't follow the spec. On this issue? C'mon Justin - I know of one really major example - old Exabyte 8200s. > >(3) are actually needed to *boot and load*. > > >From a tech support standpoint, having a usable system after installation > is also important. Yep. Which is why the "SELECT HERE" option is the right one. > It is a supported installation method. There is no optional or default > about it. Non-complient devices are "supported"? They may work, but "supported"?! > >You can't possibly get there from here, since there are dozens of > >permutations and you can't know what is and isn't possible in a given > >machine with a given set of boards. > > Win95/98 can do it on 99% of all machines. That satisfies my definition > of possible. But its not there today Justin. FreeBSD may some day get there. It may also not get there. Right now its massively not there for anyone who has ISA bus cards in their machine. PCI makes it easy, really. But if you have ISA cards in the system the story changes quite a bit. > >Fine. Make it an option. > > It is a kernel option. The default is wrong. > >Don't penalize the rest of the users on every boot (many of who have NO IDEA > >how to build kernels and fix this) because 2% of the users have hardware > >which is non-complient with the SCSI (or IDE) standards. > > If we provide an option via user config to limit the SCSI delay (won't > happen for 3.0R) then the people who are annoyed by the delay can > experiment with lower settings without rebuilding their kernel. If you say > that most users that can't build a kernel will not be able to find this > option, then you've made my point about novice installs for me. No. Most novices can read. Most novices have no idea how to use "vi" to edit the config file and rebuild a kernel. > Installation must be conservative as 50% of the people that install for the > first time will not read the documentation until after they've completed > the install, if ever. Installation should provide options for people who may have non-complient devices. The rest of the user population, who must be assumed to be just as incapable of kernel building and such, should not be penalized to cover the 1% cases. Unless, of course, the intent is to make FreeBSD only a "hackers" OS. -- -- Karl Denninger (karl@denninger.net) http://www.mcs.net/~karl I ain't even *authorized* to speak for anyone other than myself, so give up now on trying to associate my words with any particular organization. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19980930151039.A4848>