On 26/05/10 14:24, Simo Sorce wrote:
On Wed, 26 May 2010 09:08:09 -0400 (EDT)
Seth Vidal<skvidal(a)fedoraproject.org> wrote:
>
>
> On Wed, 26 May 2010, Chuck Anderson wrote:
>
>>
>> -21 million.
>>
>> Scripts are a crutch to avoid properly designed daemons and
>> configuration systems. I never edit initscripts to "configure"
>> daemons, because they would just be overwritten at the next package
>> upgrade. Configuration should be separate from code.
>
> And given my experience dealing with actual real-world designed
> daemons and other such things, I'd say we've shown no ability to
> 'properly' design them and won't be showing that anytime soon. So
> since we have to live in the world, let's not go shooting our feet
> off.
>
> -sv
>
If people are really keen on "C init scripts", then a compromise could
be to make it optional to use a bash script when the admin wants to do
something. It would be a change and require re-training to understand
how to do that, but it will be at least possible.
Simo.
I think a better compromise, if people care about speed (which is the
only reason given for using C in the first place), is to clean up the
bash code in our initscripts.
As I demonstrated in another post, you can get virtually all of the
speed of C initscripts by getting rid of basic coding errors.
For example, I have one initscript here that does:
family=`grep "^cpu family" /proc/cpuinfo | head -n1 | awk -F ": "
'{
print $2 }'`
this much slower (on this system about 3 times slower) than simply writing:
family=$(awk -F: '/^cpu family/{print $2;exit}' /proc/cpuinfo)
Unfortunately, for some reason, fixing bad bash is often perceived as
nitpicking rather than usefully contributing. Not sure why this is as
the same isn't really true of any other language.
-siXy