Date: Sun, 11 Oct 1998 07:40:52 +1000 From: Sue Blake <sue@welearn.com.au> To: Eivind Eklund <eivind@yes.no> Cc: Justin Clift <vapour@digitaldistribution.com>, freebsd-doc@FreeBSD.ORG, kpielorz@tdx.co.uk Subject: Re: *very* important addition to the installation instructions Message-ID: <19981011074052.21400@welearn.com.au> In-Reply-To: <19981010201235.49795@follo.net>; from Eivind Eklund on Sat, Oct 10, 1998 at 08:12:35PM %2B0200 References: <003c01bdf366$880b5620$0100a8c0@knight> <19981009153722.39381@follo.net> <19981010005055.28099@welearn.com.au> <19981010201235.49795@follo.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Oct 10, 1998 at 08:12:35PM +0200, Eivind Eklund wrote:
> On Sat, Oct 10, 1998 at 12:50:55AM +1000, Sue Blake wrote:
> > On Fri, Oct 09, 1998 at 03:37:22PM +0200, Eivind Eklund wrote:
> > > On Fri, Oct 09, 1998 at 07:23:50PM +1000, Justin Clift wrote:
> > > > Hiyas,
> > > >
> > > > I've had a significant amount of trouble installing FreeBSD onto an old 486
> > > > system I'm had hanging around for ages. Finally though, I solved the
> > > > problem, and found out what caused it.
> > > >
> > > > I think this problem is common enough to warrant inserting this additional
> > > > one-sentence entry into the installation instructions...
> > > >
> > > > "If you have to boot with '-c' on a first time install, DO NOT remove the
> > > > Syscon Console Driver even if it displays as a conflict. This will leave
> > > > you with a blank screen and no installation."
> > >
> > > This problem has been resolved by at least allowing the console driver
> > > to conflict;
> >
> > But... the conflict is what causes some people to remove it.
>
> By _allowing_ it to conflict, it will not be shown as in conflict.
Oops, that's the opposite meaning! Now I agree :-)
> > > I don't remember if we also marked it non-removable.
> >
> > I hope not.
>
> As Doug said - those people that don't want a console driver even
> though they have a graphics card should be sophisticated enough to
> know about the kernel config file.
I now realise that sc0 can be disabled during installation by using
KernelConfig in non-visual mode. That's a relief, coz it's hard to
build a new kernel before installation.
> > > Better tech instead of better docs for this case - people don't always
> > > read docs, so if it can be resolved technically, so much the better :-)
> >
> > Fortunately we do not all hold the same views or we would have no docs
> > and more technical fixes than users know how to use :-)
>
> If a problem can be fully resolved technically (ie, we make it
> impossible to shoot oneself in the foot without this being in the way
> of shooting that mouse by the foot), then that is better than
> documenting the way to shoot your foot and saying "DON'T DO THIS".
>
> True technical fixes are IMO always better than documenting around the
> brokenness (and the brokenness that conflict caused was resolved years
> ago, so not marking it as conflicting is quite fine).
That makes sense in this case, where it wasn't actually a bug and it
does seem to be impossible to make that mistake now. Your first
response sounded a bit heartless until you explained.
In general, there is still one problem when a technical fix replaces
documentation that makes me nervous. I don't see a worthwhile solution
for it either.
Anyone who installs an earlier version has neither the technical fix
nor the docco. These people include those who have been given slightly
older CDs to try FreeBSD, purchasers of books with CDs that have been
sitting on the shelf a while, and people in other countries where new
releases arrive slowly and the level of Internet access is poor.
For example, over the next few months 50 people that I have spoken to
will be installing 2.2.6 with little assistance and few resources. The
CDs placed in schools and libraries could reach hundreds more.
Upgrading to escape a mysterious undocumented problem might be less
palatable than trying a more popular OS that is easy to obtain locally.
If they were to find something that has become an undocumented
"technical fix" in a later version, we must assume they will find their
way to freebsd-questions and be treated kindly there by those with good
memories.
--
Regards,
-*Sue*-
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-doc" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19981011074052.21400>