On Friday 01 September 2006 22:06, Harm Geerts wrote: > On Friday 01 September 2006 17:21, Neil Bothwick wrote: > > > Speaking of which, you probably should see the shell used in the > > > scripts from the sys-apps/baselayout package. All shell scripts > > > use /bin/bash and not /bin/sh. > > > > > > So linking (d)ash as the default shell doesn't nearly have the impact > > > you'd like it to have. > > > > A 20% reduction in boot time is a reasonable impact IMO. > > Any chance that was a fluke? > > I've done a few reboots with bootchart to confirm this and I don't get any > speedup. In fact /bin/sh is never called because the gentoo init scripts > explicitly use bash. (sys-apps/baselayout-1.12.4-r7)
I can't do it right now, I'm doing an "emerge -e world" on my laptop, but tomorrow I'll do a grep and sed and change #!/bin/bash to #!/bin/dash on the relavant parts of the baselayout and see if it has any impact, other than performance. "Slapping right hand to forehead...", This something I never thought of! Thanks for the idea. The other thing to consider is, you don't have to use "all" the gentoo init scripts... Just this week, I evaluated minit, initng, runit and fcache. For me, initNG offered the best overall improvement. However, I got even better performance with my own solution. Basicly, I use the very minimum number gentoo startup scripts. All I use are those that initialize the disks and that's it. The rest of the bootup process is done in local.start. My local.start configures all the devices on my laptop, including the lo, eth0 services. It loads the modules in correct order, brings up portmap, nfs, samba, cups, fam, hal, dbus, alsa, etc., etc. Where possible I run the commands as detached processes for even more performance... My local.start is ugly as hell, but very fast as there's very little bash/python scripting involved... and none of the python bloat that gentoo has going on in /etc/init.d. I'm able to get to a fully functioning command prompt in like 10 seconds after the kernel is done loading. Some configuration still goes on in the background, but I never notice it. I've got a lot more testing to do, but at first blush I believe the generation of this type of local.start could be automated. What I see happening is, once a gentoo user is satisfied that the box is setup to their liking, they'd run a script that would evaluate /etc/runlevels, scoop the necessary setup information from /etc/conf.d and generate a local.start providing the new boot process. The runlevels could be pruned automatically and on the next reboot, the new boot process is used for a dramatic decrease in boot time. I dunno, this could be fun. ;') Cheers all, Jerry -- [email protected] mailing list
