systemd (Was Re: tmpfs for strategic directories)

[drago01]

On Wed, May 26, 2010 at 6:07 PM, Adam Williamson <awilliam at 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 at 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 at 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.