systemd (Was Re: tmpfs for strategic directories)

[James Findley]

On 26/05/10 14:24, Simo Sorce wrote:
> On Wed, 26 May 2010 09:08:09 -0400 (EDT)
> Seth Vidal<skvidal at 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