Making init scripts use dash
During some tests I've performed, I've found that making the init
scripts run with dash as default shell instead of bash makes the boot
time a 10% faster (6 seconds in a 60 second boot).
To make this speed up available to everyone, we have 2 main choices:
1. Make /bin/sh point to /bin/dash
2. Change #!/bin/sh for #!/bin/dash in the scripts
There are arguments for and against both of them. I'm summarizing
what I've gathered during Debconf, but I do want to hear other
people's opinions.
Option (1) implies making dash base and Essential: yes (currently dash
is optional), and that would imply that until no Essential package
depends on bash, we would have two shells in Essential. Moving bash
out of Essential would probably imply two release cycles (i.e. it
couldn't be out of Essential until etch+2).
This option also might imply some extra bugs, but it's believed that
not so many, since there are already quite a number of people with
/bin/sh -> /bin/dash, and they do file bugs when "bashisms" appear.
Option (2), on the other hand, implies that package maintainers have
to manually edit init scripts (or apply patches) and add the correct
dependency. This would mean quite a number of uploads, that might
take quite a lot of time.
Even though this second option is less disruptive than the first one,
if we afterwards decide to move /bin/sh to /bin/dash, it would mean
changing all this yet again, so it would be quite a lot of duplicate
work.
There might be a third option, and that would be make bash run faster.
I still need to talk about this with bash's maintainer, but I'm not
sure if it can be done without removing any functionalities.
Also, I've heard other options being posed, such as writing all init
scripts (including /etc/init.d/rc) in python. But I do want to
concentrate on what's possible to do for etch or etch+1.
So, mainly the question that I want to ask of the rest of the Debian
community is if there are more arguments for or against these options,
and what do you think would be the best route on implementing this.
--
Besos,
Marga
Reply to: