[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

[RFD] install criticisms

 * Please direct replies to -boot, please keep me Cc'd as I am not
 * subscribed to that list, thankyou.
 * ObDevelAnnounce: I want this to reach all developers so they are at
 * least aware of the criticisms raised.  Discussion from this point on
 * should happen in -boot, not -devel-announce for obvious reasons.
 * Hiya Bill, Cc'ing you so you know that your peeves have been heard.

Found someplace, probably irc I think though I could be wrong:


Okay, I agree with many of the criticisms found herein and I want to
selfishly bring attention to the pet peeves I have about the current
installation while people on -boot are allegedly revamping the whole boot
and install process.  From here on the indented stuff will be pasted from
lynx and the non-indented stuff will be my comments.

     * All is now ready to install the kernel and necessary modules, and
       I'm presented with a myriad of choices of media and installation
       options. I, obviously, choose CD-ROM, tell the program where the
       CD-ROM is (a strange step considering the program was RUN from the
       CD-ROM, but there you go) and things whir away.

Could this possibly be detected, hmm?  I mean at least it could look for
the obvious choices like cdrom.  You can at least with 2.2 kernels get it
to tell you which drives are cdroms and which are hard drives, etc.  It
would not be unreasonable to bring up the choices and make the most likely
candidate the default.

Also, selecting the location of the cdrom..  This SHOULD be able to be
automated now or the number of choices offered seriously limited to those
devices that really and truly are cdroms.  If it can be done it'd be nice
for it to know that the device booted was in fact one of the cdroms in the
system and pick it as the default cdrom, possibly not bothering to prompt
for a drive in that case.

Of course that requires somehow being able to figure out which device got
booted somehow and that's not something I know how to figure out or even
if it can be figured out.  If you know PLEASE email me privately, I'd like
to talk to you.  I'm gonna guess that all of this would be much easier
with devfs, but then I'm a major devfs advocate considering how much it
makes things easier...  (all right, put the tulips DOWN (you had to be at
LWE to understand))

   [complaints regarding interactive package installations]

We're all quite aware of these and we know it should get fixed.  It's
getting fixed, slowly but surely, so I won't go into it here.

     * First things first, get the net connection going. That's easy, of
       course, just run ppp-config. I run ppp-config, save the
       configuration file, run pon. (I have, of course, given my user
       account the correct permissions to do so; in Debian this means
       adding myself to the `dip' group. ILA[*].) The modem clicks, but
       doesn't dial out. Error messages in the logs are unhelpful.

Granted there's probably not much we could have done differently that
would prevent Bill's problem which turned out to be an onboard serial port
conflicting with the modem or something like that.  Where to go for
documentation could have been better of course, and I'd like to believe
wvdial would probably have had better luck with figuring things out.  When
we have kernel PnP his problem may go away entirely.

In any event my peeve is that the default PPP setup tools all suck.  =>
Could we possibly consider wvdial as the default?  Great little tool, very
nifty, works in more than 90% of cases and makes the whole process a
breeze without having to fight with chat or slattach or anything of the
sort, and it finds and figures out info about your modem too.  These
things impress people coming from windoze and they really do make PPP a
whole lot easier to set up.  And wvdial is far more reliable than even my
wonderful and paranoid chatscript.

     * I realize I should probably set up email, so I quickly setup
       fetchmail and have it run. Problem: fetchmail fetches and hands it
       off the the local mail system, but it doesn't deliver. I recall
       seeing some discussion of this problem on the Debian-user list, so
       I fire up lynx and check the archives for "exim fetchmail" and
       discover I need to have localhost inserted in the appropriate part
       of exim.conf. Once inserted, mail starts being delivered.

Can we please put an updated exim into stable that fixes this for r3 or
the "updated" slink release joeyh was talking about?  This is really
almost always wanted anyway and is certainly a sensible default.

   Installation of both Linux and Windows 98 had their good, bad, and
   ugly points. Getting the installation started for Windows 98 was
   ridiculous, while some of the finer points of the Debian GNU/Linux
   install were flawed - having to approve configuration questions for
   hundreds of programs during installation is, in my opinion, not a good
   way to do things. I certainly wouldn't expect a non-savvy person to be
   able to install either successfully.

I'd tend to agree.  The point is that people don't install windoze, system
vendors do.  Fortunately some system vendors are starting to install Linux
at long last.  This is A Good Thing.

We are planning to get rid of the installation question nightmare soon.
Almost everything could have a reasonable set of defaults and packages
will be updated to use them when installed once the configuration tools
are ready---joeyh is one of the people working on this.  Noteworthy is
that Corel and Storm both have Debian-based distributions in the works
which will not ask all these stupid questions.  =>

   On the one hand, they probably wouldn't have been able to get the
   Windows 98 installation STARTED, while the Debian installation
   required several steps that required a great deal of background
   knowledge (e.g., knowing that the server would have to be upgraded to
   support the video card being used and knowing where to get the
   appropriate files, knowing where to look for mail delivery solution,
   etc.) Both systems required significant knowledge about the tasks
   being accomplished.

We're also discussing an update of slink for several of the core packages
that need it (kernels and X included) for people in your boat to minimize
at least some of that needed background information.  Perhaps the install
instructions should include things like where to go for help and how to
get there?

All right people, you've read the complaints and my opinions of them.
What say you, the rest of the developers?  Is at least some of this
fixable in the slink update should that happen?  How about potato?  What
has to wait till after potato?

Joseph Carter <knghtbrd@debian.org>             Debian GNU/Linux developer
GnuPG: 2048g/3F9C2A43 - 20F6 2261 F185 7A3E 79FC  44F9 8FF7 D7A3 DCF9 DAB3
PGP 2.6: 2048R/50BDA0ED - E8 D6 84 81 E3 A8 BB 77  8E E2 29 96 C9 44 5F BE
<netgod> is it me, or is Knghtbrd snoring?
<joeyh> they killed knghtbrd!
<netgod> Kysh: wichert, gecko, joeyh, and I are in a room trying to ignore
<Kysh> netgod: Knghtbrd is hard to ignore.

Attachment: pgprfVGdAmnE8.pgp
Description: PGP signature

Reply to: