Tim wrote: > On Sun, 2008-12-21 at 01:26 -0800, NiftyFedora Mitch wrote: >> There are two places to pay critical attention to first: >> >> A. hardware initialization. >> >> For a system to boot all hardware has to be known in advance. >> NO probes that time out for this and that... SCSI timers are LONG... >> No probe of USB this and that. >> >> To that end building a kernel with "your" devices built in it >> can help. Exclude any driver that you do not have hardware for..... > > It strikes me that that sort of thing ought to be the default action any > time you install a kernel - auto customising to suit your hardware, > particularly the non-changing aspects of it (on board chipsets, and > things plugged into them, like internal hard drives). > Unless you want to compile a new kernel every time you install an update, you are kind of stuck the way it is now - a kernel with the minimum built in, and modules loaded as the system boots. The initrd is set up with the modules you need at boot time. > Though I tend to favour the microkernel approach: The kernel has the > bare minimum needed, you load extras as needed. One motherboard with > the usual peripherals ought to only load a handful of modules, which > should be less elephantine than a kernel carrying hundreds of them. > Isn't this what we have. The exception is that the modules loaded tend to be more the a handful because of the different layers - but it means that more then one hardware driver can use the same mid-level drivers. That way, you are not building the same same mid-level code into several drivers that may be loaded at the same time. (SCSI hardware module, usb_storage module, etc all talking to the same SCSI module.) > But it should be something like: Customise my system now (when > installing a kernel, or whenever deliberately invoked). Subsequent > bootups will probably bootup the same way, so they can use your > preconfigurations, and don't need so much probing next time (find my > boot drive now, boot from it, poke around for other removable external > drives while booting, but don't delay booting while you look, since I've > already set what's needed to boot). You still have various rescue > options to handle a system that fails to boot, so customising shouldn't > lock you out. > >> B. Network timers. >> >> Network timers are much longer than we all expect... Ensure that >> all name servers and network knowledge that can be "hardwired" is. No >> DHCP no discovery of name servers. Snoop the net (dumb hub, second >> machine) and watch for timeouts and other traffic you do not expect. > > This shouldn't really be a major bottleneck. Your DHCP servers ought to > be quickly responsive. If they aren't, then that's something else that > should be tackled. > It depends on the DHCP server. Most home router/firewalls I have run into tend to be a bit slow in responding... > Wireless is a pain, though. It takes time for that to get organized, > and for some annoying reason, it takes longer to discover my wireless > router than it does to find the neighbor's. > I tend to configure the default SSID, so it only has to do a search if it can not find my router. On the other hand, it is more work when I am out and about and need to connect. >> For example X11 takes a lot longer to start than I expect.. in part >> because the window manager desktop has all sorts of live buttons and >> widgets. > > I find I sit there looking at GDM spinning its "wait a moment" indicator > for far longer than it should do. Here, the full X starts faster than > GDM does. I'm inclined to be suspicious about the superfluous feature > that loads different pictures at different times of day. The previous > GDM, which didn't do that, was easily and conveniently reconfigurable, > and didn't drag its heels. > >> Clean up as much as you can without X11 i.e. login on a simple text >> window... and use 'startx'... > > If you have to log in, then start X manually, that's adding a delay. So > I don't see a real benefit there. > > I had considered the notion of not using GDM (thanks to *its* holding up > delay), starting in a text mode, and scripting something to start X as > soon as I log in. However, my experience has been that without GDM and > Gnome (i.e. forgo one of them), and you find you're using a system > without sound, or network, or auto mounting, or something else that's > become dependent on one or the other of them. > Try XDM - it doesn't have all the fancy "bells and whistles", but I believe it is Gnome or KDE that takes care of sound, network, and auto mounting. Mikkel -- Do not meddle in the affairs of dragons, for thou art crunchy and taste good with Ketchup!
Attachment:
signature.asc
Description: OpenPGP digital signature
-- fedora-list mailing list fedora-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
