On Fri, Jul 19, 2002 at 10:25:43PM -0500, grante@visi.com wrote:
| In muc.lists.debian.user, you wrote:
|
| >| * With LILO broken, it's particularly annoying that the boot
| >| floppy created during the install takes 15 minutes to load
| >| the kernel from the floppy
| >
| > Wow. That's bad. I've never seen it take that long.
|
| I've seen it on all the systems I've installed in the past few
| months (each with it's own boot floppy). You can hear the
| floppy head stepper motor click once every 20 seconds or so as
| it steps to the next track.
I wonder if it has anything to do with the hardware you used. On all
the systems I've installed on, the floppy makes lots and lots of noise
as it reads 1.44MB of data in one shot. It seems to take a while, but
that's because floppies are slow, and it doesn't take longer than 'dd'
does to write the floppy in the first place.
| >| * We had to purge GPM in order to get the PS/2 mouse to work
| >| properly under X11.
| >
| > Why do people have _soooo_ much trouble with this?
|
| Because the way it gets installed by default is apparently
| broken on many systems.
If you tell it to be broken it will be :-). It really is PEBKAC.
| > It is NOT that hard. I've explained the procedure
|
| That's not the point.
|
| There shouldn't even be a "procedure" required.
The procedure is to answer the questions correctly. If you tell X
that your mouse is /dev/random, the mouse is not going to work.
Likewise if you tell X and gpm to fight over it.
| It should work as installed. If the X package and the GPM
| package conflict with each other then declare it in the package
| rules so that they don't get installed together.
They _don't_ conflict. The *only* time I've had "conflicts" was when
I set the configuration to do so.
| Better yet, if there's a simple procedure that makes them work
| together put that procedure into the postinst section of one rules
| files so that they do work as installed.
The procedure involves knowing what the user wants. Step 1 of the
procedure is to determine which device node the mouse is hooked into.
Step 2 is to determine what protocol the mouse uses. Step 3 is to
determine whether or not to run gpm. It goes like this :
1) point gpm at the mouse device (eg /dev/psaux but depends on
your hardware)
2) tell gpm the correct protocol to use
3) set it up in "raw" repeat mode (this _should_ be the default,
but I don't know if it is)
4) tell X to read from gpm's fifo -- /dev/gpmdata
(**this is where people create the conflict on their own,
by telling X to try and bully gpm out of the way, which
doesn't work**)
5) tell X to use the *same* protocol as you told gpm
(isn't this logical? if you mouse is a "foo" mouse, then
both gpm and X need to treat it as a "foo" not a "bar"
mouse)
| The GPM/X conflict is minor, and it's easy enough to fix.
It is, just like every PEBKAC configuration :-).
| The problem is that it's not just that. There are a whole series of
| things that don't work unless you know the "tricks". Tricks
| like:
| Edit source list by hand
This is only necessary if you don't want "stable". (eg when
installing a non-stable branch, which isn't a default anyways)
| Don't run tasksel
| Don't run dselect
Yeah, that should be fixed. I hope dselect is eliminated soon.
| Purge ldap-<whatever>
I've never had any ldap stuff involved until recently when I
explicitly installed it. I think that is a "woody vs. stable(potato)"
issue you had.
| Purge biff
Ditto. I've never installed biff nor have I had to deal with it.
| <whatever the fix is for GPM/X mouse issue>
Same as every other "problem" caused by misconfiguring things.
| Some of these are probably caused by the fact that for the past
| several months, woody boot media installed additional
| (non-base) packages from stable rather than woody. Hopefully
| that problem will be avoided when the next release cycle comes
| around, but from what I read on the devel list that's not
| likely.
The problem is that you were _not_ installing stable. The installer
is meant for stable, and that's the only thing wholly unexperienced
and unassisted people should be installing. The problem with woody
was that it hung in limbo being stable but not for so long. The fix
(which hopefully the next release will have) is to release sooner!
| replace LILO with Grub, etc.
I hope this is fixed in a future release as well :-). I understand
why lilo is the default (or was, it may ask you now, I don't
remember). LILO is old and has been "the" boot loader (on x86) for
ages. Grub is new to the seen, and I think even newer than potato.
However, at least on my old system and one other I tried installing
lilo on, lilo was a pain and didn't work well. OTOH grub worked
perfectly (when I finally found it, I used loadlin.exe for a long
time).
| I don't think Debian needs a fancy graphical installer.
I agree.
| I do think the installation ought to produce a working system when
| you accept the default choice at each step.
I think this is a good goal, and should be striven for as much as
possible. Certainly though, the installer doesn't need to magically
figure out every single hardware component you have and also read your
mind to know what you _meant_ to configure :-). Someone mentioned how
SuSE's (I think) installer is a "3-click" deal, whereby it
automagically gives you a very broken system. Seemingly confusing
questions are better than a broken system that doesn't tell you what
is wrong (IMO) :-). Also, if you are installing anything other than
"stable", then it is your responsibility to know what you are doing
beforehand (in particular redirecting sources.list to point at the
branch you are installing rather than at stable).
-D
--
Windows, hmmm, does it come with a GUI interface that works or just
pretty blue screens?
http://dman.ddts.net/~dman/
Attachment:
pgp7xepLuChjn.pgp
Description: PGP signature