On 26/05/10 14:24, Simo Sorce wrote:
> On Wed, 26 May 2010 09:08:09 -0400 (EDT)
> Seth Vidal<skvidal@xxxxxxxxxxxxxxxxx> 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
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
