On Sun, 28 Sep 2003, Felix Miata wrote: > 5-A usable normal boot and/or rescue floppy should be at least offered > for creation during install. After install, creating a boot and/or > rescue floppy should actually be possible on any system. Barring that, > the creation process that fails should offer some guidance on what to > change in order to enable success on future tries.
IMHO, there is very little need for this as every installation media allows the rescue boot. > > 6-Time. /var/log/boot.log shouldn't start a boot at 13:00, then back up > 4 hours to 09:00 for several startup items, then jump back to 13:01 to > finish up. If configuration is that the system clock is set to local > time, then all entries should be based upon that clock, and not adjusted > to anything else for any reason at any time. When a new system is > installed, no directory should be time stamped 4 hours before the > install started, which is the case now. And how is this supposed to be determined before any user interaction? Should thelog files be re-interpreted after changing the timezone? > > 7-rc ordering is dumb. If the system is configured to start in runlevel > 5, it nevertheless should finish init on runlevel 3 first. No one should > have to wait to get a prompt on vc[1-6] until substantially after the X > login manager has appeared, which is the case now. We have to wait for everything else. Making the dm start later only makes you wait longer for a graphical login, it doesn't make much difference to console logins. > Services that can't > be used in runlevel 2 shouldn't be started before all runlevel 2 > services have had their init. Run level has nothing to do with it, but if you have issues with certain packages, file bugs on them. IMHO, we need a more intelligent init (like serel or the make-based on recently shown on IBM's developer site). > > 8-Back to the old way with the installer. Used to be able to go back to > any particular step just by clicking on the item in the left column. > That was brilliant, and is missed. Pixel said this introdced many bugs which were difficult to fix. > > 9-NUMLOCK > I very much appreciate having this package installed by default, as it > makes me insane that any OS kernel feels compelled to switch NUM off > when in the BIOS it is set to ON. Well, I am sure the kernel developers will take patches to reliably detect the numlock setting and handle it intelligently. > That said, I have to guess there is a > more efficient way to do it than with an rpm package, as SuSE has the > same functionality, but without a package named numlock. I don't know > how they do it, but I do know it is configured through > /etc/sysconfig/keyboard, which is 2509 bytes and has, among others, the > following settings on my SuSE 8.1 machine: > > KBD_RATE="20.0" > KBD_DELAY="250" > KBD_NUMLOCK="bios" Does this (KBD_NUMLOCK="bios") work reliably in all settings for numlock? > > In contrast, this same file in 9.1 and cooker is all of 36 bytes, and > has nothing in it that explains what any of its three lines are for. > > Also, it needs to be fixed so that if enabled, it is in the ON state for > the X login manager so that I can use the NUM pad for password entry > without having to think "hmmm, is the NUM light on?". AFAIK, all VTs take the default setting set by numlock. (BTW, numlock on by default is very annoying on laptop keyboards, *especially* on login screens ... so this *must* be avoided) Regards, Buchan -- |----------------Registered Linux User #182071-----------------| Buchan Milne Mechanical Engineer, Network Manager Cellphone * Work +27 82 472 2231 * +27 21 8828820x121 Stellenbosch Automotive Engineering http://www.cae.co.za GPG Key http://ranger.dnsalias.com/bgmilne.asc 1024D/60D204A7 2919 E232 5610 A038 87B1 72D6 AC92 BA50 60D2 04A7 ***************************************************************** Please click on http://www.cae.co.za/disclaimer.htm to read our e-mail disclaimer or send an e-mail to [EMAIL PROTECTED] for a copy. *****************************************************************
