On Wed, May 26, 2010 at 6:07 PM, Adam Williamson <awilliam(a)redhat.com> wrote:
On Wed, 2010-05-26 at 12:42 +0200, drago01 wrote:
> On Wed, May 26, 2010 at 5:02 AM, Casey Dahlin <cdahlin(a)redhat.com> wrote:
> > On Tue, May 25, 2010 at 05:45:07PM +0200, Lennart Poettering wrote:
> >> On Tue, 25.05.10 10:21, Casey Dahlin (cdahlin(a)redhat.com) wrote:
> > [...]
> > 3) Cutting down on the forking by replacing some of the shell scripts... cool
> > 3a) With C code... really?
>
> This does make a lot of sense to me, initscripts being scripts is a
> major slowdown factor
> by itself.
>
> It is not like you want to edit the scripts all the time, so there is
> no reason for them being scripts.
I beg to differ. I've had to create or modify initscripts quite often,
either as a sysadmin or a packager.
Again the sysadmin case just implies that something *else* is broken.
Well if changing over to C does only get rid of this "disease" it
would be enough of a gain.
It would force broken apps to be fixed, and let admins edit
*configuration* files and not source code.
Why don't people try to configure lets say X by editing its code'?
Does this sound wrong to you? If yes than why would initscripts be different?
If this is now going to require C
coding skills, I'm not going to be able to do it. I don't think it's
safe to assume that everyone who needs to write or modify an initscript
is going to know C
Well if you want to write and modify something you have to know the
language it is written in,
in case you don't it isn't a problem either just ask for help.
It is not rocket science or something that would required hundreds of man hours.
What about people who write apps that need
initscripts in some other language?
See above.