Re: [gentoo-user] Re: Dash as /bin/sh?

[Jerry McBride <mcbrides9@comcast.net>]

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



-- 
gentoo-user@gentoo.org mailing list