systemd (Was Re: tmpfs for strategic directories)

James Findley sixy at
Wed May 26 13:40:59 UTC 2010

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


More information about the devel mailing list