[gentoo-dev] Init replacement

[gentoo-dev] Init replacement

[Wouter van Kleunen]

I wrote a new init system that has numerous advantages over the old script
based init system. Please have a look at:

pinit.sf.net

I am a gentoo user, and i converted my scripts -> services for my system.
I would like to have feedback on this system. Please try it out on your
system (safely from your home directory).


Wouter




--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Init replacement

[Paul de Vrieze]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 682 bytes --]

On Friday 02 May 2003 11:34, Wouter van Kleunen wrote:
> I wrote a new init system that has numerous advantages over the old script
> based init system. Please have a look at:
>
> pinit.sf.net
>
> I am a gentoo user, and i converted my scripts -> services for my system.
> I would like to have feedback on this system. Please try it out on your
> system (safely from your home directory).
>

My main objection is the dependency on glib and libxml2. Those are 
dependencies that are too IMHO too strong for an init system. I think shell 
scripts are much safer.

Paul

-- 
Paul de Vrieze
Researcher
Mail: pauldv@cs.kun.nl
Homepage: http://www.cs.kun.nl/~pauldv

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Init replacement

[Wouter van Kleunen]

libxml2 and glib are small libraries (1.5bm in total). It is not as
heavy as (for example) python or perl. Libxml2 can be dropped, but i
probably will not. Glib is a convenient library for C programming that
more programs should use nowadays. The advantages that you get from this
system are pretty large.
Providing the same functionality with shell scripts is pretty difficult.

Concerning security, i only see the socket as a possible security problem.
What else can be exploited ? You should not run the init or control
program suid root offcourse.


On Fri, 2 May 2003, Paul de Vrieze wrote:

> On Friday 02 May 2003 11:34, Wouter van Kleunen wrote:
> > I wrote a new init system that has numerous advantages over the old script
> > based init system. Please have a look at:
> >
> > pinit.sf.net
> >
> > I am a gentoo user, and i converted my scripts -> services for my system.
> > I would like to have feedback on this system. Please try it out on your
> > system (safely from your home directory).
> >
>
> My main objection is the dependency on glib and libxml2. Those are
> dependencies that are too IMHO too strong for an init system. I think shell
> scripts are much safer.
>
> Paul
>
> --
> Paul de Vrieze
> Researcher
> Mail: pauldv@cs.kun.nl
> Homepage: http://www.cs.kun.nl/~pauldv
>


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Init replacement

[Terje Kvernes]

Wouter van Kleunen <kleunen@cs.utwente.nl> writes:

> I wrote a new init system that has numerous advantages over the old script
> based init system. Please have a look at:
> 
> pinit.sf.net
> 
> I am a gentoo user, and i converted my scripts -> services for my
> system.  I would like to have feedback on this system. Please try it
> out on your system (safely from your home directory).

  converting init-scripts to XML is a scary process.  init-scripts
  should IMHO be human readable, as atomic as possible, and testable
  without depending on much more than having a generic shell.  in
  addition to verboseness and lack of readability, XML makes it
  "interesting" to integrate more complex scripts, like autofs.

  yes, XML is easier to generate for a machine, but you generally
  don't generate init-scripts, if you do you probably build them from
  templates, which aren't XML friendly either.  

-- 
Terje

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Init replacement

[Wouter van Kleunen]

local res="$(cat /proc/modules | egrep 'serial' | cut -f1 -d" ")"

remaining="$(cat /proc/mounts | awk `( print $3 " " $2 )'| \
     grep -E ^'code|nfs|ncpfs|smbfs' | awk '( print $2 | '| sort -r)"

human readable, i see... hmmmm

how can you test something like this ? it will break very easily.

and writing a init script for a daemon is very simple with my system. Not
all daemons have an ready to run gentoo init script you know.


On 2 May 2003, Terje Kvernes wrote:

> Wouter van Kleunen <kleunen@cs.utwente.nl> writes:
>
> > I wrote a new init system that has numerous advantages over the old script
> > based init system. Please have a look at:
> >
> > pinit.sf.net
> >
> > I am a gentoo user, and i converted my scripts -> services for my
> > system.  I would like to have feedback on this system. Please try it
> > out on your system (safely from your home directory).
>
>   converting init-scripts to XML is a scary process.  init-scripts
>   should IMHO be human readable, as atomic as possible, and testable
>   without depending on much more than having a generic shell.  in
>   addition to verboseness and lack of readability, XML makes it
>   "interesting" to integrate more complex scripts, like autofs.
>
>   yes, XML is easier to generate for a machine, but you generally
>   don't generate init-scripts, if you do you probably build them from
>   templates, which aren't XML friendly either.
>
> --
> Terje
>
> --
> gentoo-dev@gentoo.org mailing list
>


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Init replacement

[Terje Kvernes]

Wouter van Kleunen <kleunen@cs.utwente.nl> writes:

> On 2 May 2003, Terje Kvernes wrote:
> 
> > converting init-scripts to XML is a scary process.  init-scripts
> > should IMHO be human readable, as atomic as possible, and testable
> > without depending on much more than having a generic shell.  in
> > addition to verboseness and lack of readability, XML makes it
> > "interesting" to integrate more complex scripts, like autofs.
> >
> > yes, XML is easier to generate for a machine, but you generally
> > don't generate init-scripts, if you do you probably build them
> > from templates, which aren't XML friendly either.
>
> local res="$(cat /proc/modules | egrep 'serial' | cut -f1 -d" ")"
> 
> remaining="$(cat /proc/mounts | awk `( print $3 " " $2 )'| \
>      grep -E ^'code|nfs|ncpfs|smbfs' | awk '( print $2 | '| sort -r)"
> 
> human readable, i see... hmmmm

  it's readable, yes.  
 
> how can you test something like this? 

  by running it bit by bit on the command line, and testing each
  command.  of course, you can clean up stuff like the above as well
  to make it more readable.  then again, how would you achieve the
  same as what the script does without doing just the same thing?

> it will break very easily.

  not really.  there are reasons why one doesn't change the format of
  proc mounts.  it looks complex, and it is, but it's also very much
  tried and true.  one could argue about the lack of 'trap' or
  something similar tools in the scripts though.
 
> and writing a init script for a daemon is very simple with my
> system. Not all daemons have an ready to run gentoo init script you
> know.

  and a lot of scripts require a great deal of "magic" before they
  run.  why do you think the initscript for autofs looks the way it
  does?  because start-stop-daemon automount works?  :-)
 
-- 
Terje

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Init replacement

[Wouter van Kleunen]

I updated the "About" page on the website. I hope that will explain why i
prefer a compiled language over a shell script.

Wouter

On 2 May 2003, Terje Kvernes wrote:

> Wouter van Kleunen <kleunen@cs.utwente.nl> writes:
>
> > On 2 May 2003, Terje Kvernes wrote:
> >
> > > converting init-scripts to XML is a scary process.  init-scripts
> > > should IMHO be human readable, as atomic as possible, and testable
> > > without depending on much more than having a generic shell.  in
> > > addition to verboseness and lack of readability, XML makes it
> > > "interesting" to integrate more complex scripts, like autofs.
> > >
> > > yes, XML is easier to generate for a machine, but you generally
> > > don't generate init-scripts, if you do you probably build them
> > > from templates, which aren't XML friendly either.
> >
> > local res="$(cat /proc/modules | egrep 'serial' | cut -f1 -d" ")"
> >
> > remaining="$(cat /proc/mounts | awk `( print $3 " " $2 )'| \
> >      grep -E ^'code|nfs|ncpfs|smbfs' | awk '( print $2 | '| sort -r)"
> >
> > human readable, i see... hmmmm
>
>   it's readable, yes.
>
> > how can you test something like this?
>
>   by running it bit by bit on the command line, and testing each
>   command.  of course, you can clean up stuff like the above as well
>   to make it more readable.  then again, how would you achieve the
>   same as what the script does without doing just the same thing?
>
> > it will break very easily.
>
>   not really.  there are reasons why one doesn't change the format of
>   proc mounts.  it looks complex, and it is, but it's also very much
>   tried and true.  one could argue about the lack of 'trap' or
>   something similar tools in the scripts though.
>
> > and writing a init script for a daemon is very simple with my
> > system. Not all daemons have an ready to run gentoo init script you
> > know.
>
>   and a lot of scripts require a great deal of "magic" before they
>   run.  why do you think the initscript for autofs looks the way it
>   does?  because start-stop-daemon automount works?  :-)
>
> --
> Terje
>
> --
> gentoo-dev@gentoo.org mailing list
>


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Init replacement

[Jon Kent]

hmmm, interesting idea, but I have a lot of issues
with this type of approach, namely:

init scripts really need to be easy to maintain with
external requirements kept to a minimum

script, generally, are the easiest, more readable
approach to init scripts.  You don't modify init
scripts every day so remembering how you did things is
a pain if its not script based

I really do not want to learn yet another
language/approach just to get daemons etc up and
running on boot up

I really do not see boot up speed as a problem, on
servers and workstations you do not spend you life
rebooting the things.  I've had servers running for
years without a reboot.

I must be honest and say that the Gentoo init system
is not easiest in the world, I prefer the old
rcX.d/Sxx[name] approach myself as its simple, but I'd
still prefer the current approach over the proposed
approach.

My pennies worth

Jon


__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Init replacement

[Paul de Vrieze]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 2053 bytes --]

On Friday 02 May 2003 19:08, Jon Kent wrote:
> hmmm, interesting idea, but I have a lot of issues
> with this type of approach, namely:
>
> init scripts really need to be easy to maintain with
> external requirements kept to a minimum
>

Also the sample scripts are not quite normal XML, as with normal xml all 
newlines get interpreted (Yes, I know you can use CDATA instead of PCDATA to 
keep newlines) as normal whitespace. Also, the main advantage of xml is ease 
of parsing and generation by DIFFERENT programs of complicated formats. Init 
scripts are not complicated formats and need only be run/parsed by one 
program that is the shell that it is a script for.

> script, generally, are the easiest, more readable
> approach to init scripts.  You don't modify init
> scripts every day so remembering how you did things is
> a pain if its not script based

Quite my point
>
> I really do not want to learn yet another
> language/approach just to get daemons etc up and
> running on boot up
>


> I really do not see boot up speed as a problem, on
> servers and workstations you do not spend you life
> rebooting the things.  I've had servers running for
> years without a reboot.

Init scripts could be faster, but the time lost is not spend waiting for init 
scripts to be parsed. It is spend waiting for programs to actually start. For 
that reason paralel init scripts can be useful, but a compiled init process 
can add little in this.

> I must be honest and say that the Gentoo init system
> is not easiest in the world, I prefer the old
> rcX.d/Sxx[name] approach myself as its simple, but I'd
> still prefer the current approach over the proposed
> approach.

I find the Gentoo init system quite useful myself, but indeed it is a bit more 
complicated than the S??[name] system. The tricks that redhat uses, to be 
able to automate configuration though are a lot less clean than gentoo's.

Paul

-- 
Paul de Vrieze
Researcher
Mail: pauldv@cs.kun.nl
Homepage: http://www.devrieze.net

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Init replacement

[Wouter van Kleunen]

On Fri, 2 May 2003, Paul de Vrieze wrote:

> On Friday 02 May 2003 19:08, Jon Kent wrote:
> > hmmm, interesting idea, but I have a lot of issues
> > with this type of approach, namely:
> >
> > init scripts really need to be easy to maintain with
> > external requirements kept to a minimum
> >
>
> Also the sample scripts are not quite normal XML, as with normal xml all
> newlines get interpreted (Yes, I know you can use CDATA instead of PCDATA to
> keep newlines) as normal whitespace. Also, the main advantage of xml is ease
> of parsing and generation by DIFFERENT programs of complicated formats. Init
> scripts are not complicated formats and need only be run/parsed by one
> program that is the shell that it is a script for.
>

For example firewall generators generate init scripts. And sysvinit
frontends (KDE has a frontend) uses it. I think also mandrake has a
frontend for selecting which services get booted. I dunno about suse or
red hat. I don't say these distro's should immediatly start using this
init. But your claim that only 1 program parses these files is not true.

> > script, generally, are the easiest, more readable
> > approach to init scripts.  You don't modify init
> > scripts every day so remembering how you did things is
> > a pain if its not script based
>
> Quite my point

The same goes for all these init methods. Every distro uses a different
init method

> >
> > I really do not want to learn yet another
> > language/approach just to get daemons etc up and
> > running on boot up
> >
>
>
> > I really do not see boot up speed as a problem, on
> > servers and workstations you do not spend you life
> > rebooting the things.  I've had servers running for
> > years without a reboot.
>
> Init scripts could be faster, but the time lost is not spend waiting for init
> scripts to be parsed. It is spend waiting for programs to actually start. For
> that reason paralel init scripts can be useful, but a compiled init process
> can add little in this.
>
> > I must be honest and say that the Gentoo init system
> > is not easiest in the world, I prefer the old
> > rcX.d/Sxx[name] approach myself as its simple, but I'd
> > still prefer the current approach over the proposed
> > approach.
>
> I find the Gentoo init system quite useful myself, but indeed it is a bit more
> complicated than the S??[name] system. The tricks that redhat uses, to be
> able to automate configuration though are a lot less clean than gentoo's.
>
> Paul
>
> --
> Paul de Vrieze
> Researcher
> Mail: pauldv@cs.kun.nl
> Homepage: http://www.devrieze.net
>


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Init replacement

[Evan Powers]

On Friday 02 May 2003 03:23 pm, Wouter van Kleunen wrote:
> For example firewall generators generate init scripts. And sysvinit
> frontends (KDE has a frontend) uses it. I think also mandrake has a
> frontend for selecting which services get booted. I dunno about suse or
> red hat. I don't say these distro's should immediatly start using this
> init. But your claim that only 1 program parses these files is not true.

I'm not sure if those are particularly good counter examples. I'm not totally 
familiar with KDE's frontend, but I was, at a time, familiar with the 
Linuxconf equivalent.

Sysvinit frontends probably do not actually look inside the init scripts; all 
they care about is the filename. The menus for selecting which service to run 
at boot are really asking which script files you want in which runlevels. 
Most frontends serve only to manipulate the symlinks. So the script's format 
is still parsed by only one program.

As for firewall generators...what sort of generated script are you talking 
about? I'd imagine you mean that the program merely generates a sequence of 
iptables commands which initialize the tables correctly, since iptables 
doesn't have a file format of it's own. I'm not sure how wrapping the 
sequence of commands in XML markup is accomplishing anything....

That said, don't take my criticisms too harshly. I think there's much that can 
be done to improve Gentoo's init system (despite it's being quite good, 
compared to other systems, at present), and I think your direction is 
interesting. But there are a number of things in your approach which give me 
pause.

Good luck in any case,
Evan

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Init replacement

[Wouter van Kleunen]

On Fri, 2 May 2003, Evan Powers wrote:

> On Friday 02 May 2003 03:23 pm, Wouter van Kleunen wrote:
> > For example firewall generators generate init scripts. And sysvinit
> > frontends (KDE has a frontend) uses it. I think also mandrake has a
> > frontend for selecting which services get booted. I dunno about suse or
> > red hat. I don't say these distro's should immediatly start using this
> > init. But your claim that only 1 program parses these files is not true.
>
> I'm not sure if those are particularly good counter examples. I'm not totally
> familiar with KDE's frontend, but I was, at a time, familiar with the
> Linuxconf equivalent.
>
> Sysvinit frontends probably do not actually look inside the init scripts; all
> they care about is the filename. The menus for selecting which service to run
> at boot are really asking which script files you want in which runlevels.
> Most frontends serve only to manipulate the symlinks. So the script's format
> is still parsed by only one program.
>
Yes that is true. In my program that would be equivalent with editing a
profile in xml format.

> As for firewall generators...what sort of generated script are you talking
> about? I'd imagine you mean that the program merely generates a sequence of
> iptables commands which initialize the tables correctly, since iptables
> doesn't have a file format of it's own. I'm not sure how wrapping the
> sequence of commands in XML markup is accomplishing anything....
>
I could think of writing a module that will read the firewall rules from a
xml config file. That config file will be edited by a frontend

> That said, don't take my criticisms too harshly. I think there's much that can
> be done to improve Gentoo's init system (despite it's being quite good,
> compared to other systems, at present), and I think your direction is
> interesting. But there are a number of things in your approach which give me
> pause.
>
> Good luck in any case,
> Evan
>
> --
> gentoo-dev@gentoo.org mailing list
>
>


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Init replacement

[Paul de Vrieze]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 1113 bytes --]

On Friday 02 May 2003 21:23, Wouter van Kleunen wrote:
>
> For example firewall generators generate init scripts. And sysvinit
> frontends (KDE has a frontend) uses it. I think also mandrake has a
> frontend for selecting which services get booted. I dunno about suse or
> red hat. I don't say these distro's should immediatly start using this
> init. But your claim that only 1 program parses these files is not true.

Firewall generators generate scripts to stard firewalls. As long as they just 
output a simple script, any kind of init system can be used to execute them. 
selecting frontends do not generate scripts. They do not look into them, they 
just make symlinks

> The same goes for all these init methods. Every distro uses a different
> init method

That's true, I guess its basically because the s??[name] way sucks in 
combination with tools (as there are only 100 positions, and there is no 
standardized way to know at which position a package should be 
started/stoped. 

Paul

-- 
Paul de Vrieze
Researcher
Mail: pauldv@cs.kun.nl
Homepage: http://www.devrieze.net

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Init replacement

[Sven Vermeulen]

[-- Attachment #1: Type: text/plain, Size: 961 bytes --]

On Fri, May 02, 2003 at 10:08:03AM -0700, Jon Kent wrote:
> I must be honest and say that the Gentoo init system
> is not easiest in the world, I prefer the old
> rcX.d/Sxx[name] approach myself as its simple, but I'd
> still prefer the current approach over the proposed
> approach.

It's not a proposal to change Gentoo's default init-system (or at least I
hope so). I fully support the OP with his work because one can never know
what it provides untill it's available. 

So, keep up the development. 

Wkr,
	Sven Vermeulen

PS I'm against non-shellscript based initscripts, but I'll vote in favor of
   choices above anything else!

-- 
Thanks to DRM, you know that something has been built in environment of 
unspecified degree of security, from source you cannot check, written by 
programmers you don't know, released after passing QA of unknown quality and 
which is released under a license that disclaims any responsibility...

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Init replacement

[Jim Bowlin]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Friday 02 May 2003 02:34 am, Wouter van Kleunen wrote:

> I wrote a new init system that has numerous advantages over the old script
> based init system. Please have a look at:

Wow.  I think this is a great idea, especially if it significantly speeds
up the booting process.  It would be great to boot 4x faster. We would
save hundreds of hacker-hours.  I am not a big fan of XML, but I think
you are using it wisely here.

In order to make acceptance easier, would it be possible to run both
systems side by side (or one controlling the other)?  That way people
could use your system for standard services that have been converted
but they are not locked out from using services that have not yet
been converted.  

The Gentoo init system is the best and simplest I've seen.  It looks
like you are building on top of the ideas developed there.  This
is a good thing.

Peace.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+sl4adVDVBNqCHikRAiHzAJ4vn7NncnxrNrSTOhw8D9dZobTaywCdGJai
38QX5YXrn8vLlRfFx2q2TTI=
=trXg
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Init replacement

[leon j. breedt]

hi,

i as well looked into doing this, and came to the conclusion that the
following are desirable attributes for a replacement init:

    1. secure daemon startup (i.e. as different user, in chroot, etc).
basically,
       incorporating the functionality of start-stop-daemon into init.
    2. daemon monitoring/controlling at an init level. i.e. you have a
guaranteed
       working way of checking service status, sending signals, etc.
very useful
       would be the ability to execute configurable commands/scripts on
status
       change. basically, incorporating similar functionality to djb's
daemontools.
    3. standardized, controllable output to TTY. i.e. be able to
suppress anything
       that a daemon/service tries to output, but log it somewhere. it
should be
       possible to flag something that could be interactive though, like
fsck.
       abstracting this would make it trivial to support different
startup displays,
       like a progress bar, or graphical/icon based startup.
    4. deep dependency checking when determining what to start up/stop.
and when restarting,
       only start up dependant things which were running when stopped.

it seems like you've thought of most of these cases. don't throw away
the wisdom
incorporated in sysvinit though. i'd recommend trying to make your init
have the same
semantics from an external point of view where possible so that
userspace utilities
such as wall, shutdown, etc, keep on working.

i'm not entirely sure i'd want to use XML for everything though. i think
a nice
approach would be to put the *metadata* about a service in XML, but the
actual
mechanics of starting/stopping the service in a seperate script. of this
script,
you expect things like that if it starts a daemon, its pid will be the
pid you get
when you exec it. have a well-defined interface you expect from the
scripts,
either return codes or text they output on success/failure, but scripts
are
very useful for executing a collection of commands. have the script
start with
#!/sbin/your-interpreter so that executing the script on its own still
executes
it in its managed environment.

i'm extremely interested in development of this, don't stop development
:)

regards,
leon.


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Init replacement

[Wouter van Kleunen]

On Sat, 3 May 2003, leon j. breedt wrote:

> hi,
>
> i as well looked into doing this, and came to the conclusion that the
> following are desirable attributes for a replacement init:
>
>     1. secure daemon startup (i.e. as different user, in chroot, etc).
> basically,
>        incorporating the functionality of start-stop-daemon into init.
this is definitly a good option, i'll definitly add this

>     2. daemon monitoring/controlling at an init level. i.e. you have a
> guaranteed
>        working way of checking service status, sending signals, etc.
> very useful
>        would be the ability to execute configurable commands/scripts on
> status
>        change. basically, incorporating similar functionality to djb's
> daemontools.
Yes, that is already in there

>     3. standardized, controllable output to TTY. i.e. be able to
> suppress anything
>        that a daemon/service tries to output, but log it somewhere. it
> should be
>        possible to flag something that could be interactive though, like
> fsck.
>        abstracting this would make it trivial to support different
> startup displays,
>        like a progress bar, or graphical/icon based startup.
Yup, that is also supported.

>     4. deep dependency checking when determining what to start up/stop.
> and when restarting,
>        only start up dependant things which were running when stopped.
>
Yes. Well, for the moment, you can only stop services that do not have
dependent services running. I plan to make that stronger

> it seems like you've thought of most of these cases. don't throw away
> the wisdom
> incorporated in sysvinit though. i'd recommend trying to make your init
> have the same
> semantics from an external point of view where possible so that
> userspace utilities
> such as wall, shutdown, etc, keep on working.
That is definitly possible. sysvinit uses a fifo to communicate. I could
write an IO part in pinit that could handle these commands. But i could
also write a pinit alternative.

 >
> i'm not entirely sure i'd want to use XML for everything though. i think
> a nice
> approach would be to put the *metadata* about a service in XML, but the
> actual
> mechanics of starting/stopping the service in a seperate script. of this
> script,
> you expect things like that if it starts a daemon, its pid will be the
> pid you get
> when you exec it. have a well-defined interface you expect from the
> scripts,
> either return codes or text they output on success/failure, but scripts
> are
> very useful for executing a collection of commands. have the script
> start with
> #!/sbin/your-interpreter so that executing the script on its own still
> executes
> it in its managed environment.
>
Yes. I have thought of adding a script-service. But i removed it, because
i do not like scripts. I agree that they are convenient for executing a
collection of commands, but bash is a very weak programming language.

I will think about adding scripts. Maybe just to lower the difference
between my init and sysvinit. But rather not bash, bash is ugly :-(

it would be nice if people wrote more scripts using functional languages.
(haskell, miranda, etc...)

> i'm extremely interested in development of this, don't stop development
> :)
>
> regards,
> leon.
>


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Init replacement

[Martin Schlemmer]

[-- Attachment #1: Type: text/plain, Size: 1568 bytes --]

On Sat, 2003-05-03 at 11:08, Wouter van Kleunen wrote:

> Yes. I have thought of adding a script-service. But i removed it, because
> i do not like scripts. I agree that they are convenient for executing a
> collection of commands, but bash is a very weak programming language.
> 
> I will think about adding scripts. Maybe just to lower the difference
> between my init and sysvinit. But rather not bash, bash is ugly :-(
> 
> it would be nice if people wrote more scripts using functional languages.
> (haskell, miranda, etc...)
> 

Point is, where say 80% people can code in sh/bash, much less can do
that in python, haskell, whatever.  Thus dropping the 'user' interface
to the init system being in bash/sh, will make it unusable for many
users.

Having the startup scripts/modules binary though, means you cannot
do quick changes, etc as well.

And like many others did say, python/whatever have too large
dependencies.  For example, having python initscripts will make
an initrd/diet_system a PITA to get running.

Having SVC support build into init, now that is a reason why I would
change init.

Another question that bothers me ... if everybody is so against bash
being slow, why don't they spent time to get bash's IO more optimised?
For example, getting bash to read the whole script, and then executing
it, and not reading line by line should already add much improvement.


Anyhow, just a few quick thoughts,

-- 

Martin Schlemmer
Gentoo Linux Developer, Desktop/System Team Developer
Cape Town, South Africa



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Init replacement

[Wesley Leggette]

On Sat, 2003-05-03 at 05:05, Martin Schlemmer wrote:
> On Sat, 2003-05-03 at 11:08, Wouter van Kleunen wrote:
> 
> > Yes. I have thought of adding a script-service. But i removed it, because
> > i do not like scripts. I agree that they are convenient for executing a
> > collection of commands, but bash is a very weak programming language.
> > 
> > I will think about adding scripts. Maybe just to lower the difference
> > between my init and sysvinit. But rather not bash, bash is ugly :-(
> > 
> > it would be nice if people wrote more scripts using functional languages.
> > (haskell, miranda, etc...)
> > 
> 
> Point is, where say 80% people can code in sh/bash, much less can do
> that in python, haskell, whatever.  Thus dropping the 'user' interface
> to the init system being in bash/sh, will make it unusable for many
> users.

Oh come on. Like XML is really than difficult. I'm sure 80% know the
syntax, and Wouter's keywords are a lot simpler than Bash's. Besides,
80% is completly off for people who know bash (and XML syntax too).
Let's face it. Wouter's XML is a lot easier for newbies to learn. It has
actual english in it. I don't see why everyone is so defensive about
their beloved bash scripts. 

> 
> Having the startup scripts/modules binary though, means you cannot
> do quick changes, etc as well.
> 
> And like many others did say, python/whatever have too large
> dependencies.  For example, having python initscripts will make
> an initrd/diet_system a PITA to get running.
> 
> Having SVC support build into init, now that is a reason why I would
> change init.
> 
> Another question that bothers me ... if everybody is so against bash
> being slow, why don't they spent time to get bash's IO more optimised?
> For example, getting bash to read the whole script, and then executing
> it, and not reading line by line should already add much improvement.
> 
> 
> Anyhow, just a few quick thoughts,
-- 
Wesley Leggette <wleggette@gate.net>


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Init replacement

[Martin Schlemmer]

[-- Attachment #1: Type: text/plain, Size: 2338 bytes --]

On Sun, 2003-05-04 at 18:05, Wesley Leggette wrote:
> On Sat, 2003-05-03 at 05:05, Martin Schlemmer wrote:
> > On Sat, 2003-05-03 at 11:08, Wouter van Kleunen wrote:
> > 
> > > Yes. I have thought of adding a script-service. But i removed it, because
> > > i do not like scripts. I agree that they are convenient for executing a
> > > collection of commands, but bash is a very weak programming language.
> > > 
> > > I will think about adding scripts. Maybe just to lower the difference
> > > between my init and sysvinit. But rather not bash, bash is ugly :-(
> > > 
> > > it would be nice if people wrote more scripts using functional languages.
> > > (haskell, miranda, etc...)
> > > 
> > 
> > Point is, where say 80% people can code in sh/bash, much less can do
> > that in python, haskell, whatever.  Thus dropping the 'user' interface
> > to the init system being in bash/sh, will make it unusable for many
> > users.
> 
> Oh come on. Like XML is really than difficult. I'm sure 80% know the
> syntax, and Wouter's keywords are a lot simpler than Bash's. Besides,
> 80% is completly off for people who know bash (and XML syntax too).
> Let's face it. Wouter's XML is a lot easier for newbies to learn. It has
> actual english in it. I don't see why everyone is so defensive about
> their beloved bash scripts. 
> 

Why are you so defensive about XML ?  Anyhow, you missed the point
totally, as I have not even talked about XML.

> > 
> > Having the startup scripts/modules binary though, means you cannot
> > do quick changes, etc as well.
> > 
> > And like many others did say, python/whatever have too large
> > dependencies.  For example, having python initscripts will make
> > an initrd/diet_system a PITA to get running.
> > 
> > Having SVC support build into init, now that is a reason why I would
> > change init.
> > 
> > Another question that bothers me ... if everybody is so against bash
> > being slow, why don't they spent time to get bash's IO more optimised?
> > For example, getting bash to read the whole script, and then executing
> > it, and not reading line by line should already add much improvement.
> > 
> > 
> > Anyhow, just a few quick thoughts,
-- 

Martin Schlemmer
Gentoo Linux Developer, Desktop/System Team Developer
Cape Town, South Africa



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Init replacement

[Wesley Leggette]

On Sun, 2003-05-04 at 13:12, Martin Schlemmer wrote:
> On Sun, 2003-05-04 at 18:05, Wesley Leggette wrote:
> > On Sat, 2003-05-03 at 05:05, Martin Schlemmer wrote:
> > > On Sat, 2003-05-03 at 11:08, Wouter van Kleunen wrote:
> > > 
> > > > Yes. I have thought of adding a script-service. But i removed it, because
> > > > i do not like scripts. I agree that they are convenient for executing a
> > > > collection of commands, but bash is a very weak programming language.
> > > > 
> > > > I will think about adding scripts. Maybe just to lower the difference
> > > > between my init and sysvinit. But rather not bash, bash is ugly :-(
> > > > 
> > > > it would be nice if people wrote more scripts using functional languages.
> > > > (haskell, miranda, etc...)
> > > > 
> > > 
> > > Point is, where say 80% people can code in sh/bash, much less can do
> > > that in python, haskell, whatever.  Thus dropping the 'user' interface
> > > to the init system being in bash/sh, will make it unusable for many
> > > users.
> > 
> > Oh come on. Like XML is really than difficult. I'm sure 80% know the
> > syntax, and Wouter's keywords are a lot simpler than Bash's. Besides,
> > 80% is completly off for people who know bash (and XML syntax too).
> > Let's face it. Wouter's XML is a lot easier for newbies to learn. It has
> > actual english in it. I don't see why everyone is so defensive about
> > their beloved bash scripts. 
> > 
> 
> Why are you so defensive about XML ?  Anyhow, you missed the point
> totally, as I have not even talked about XML.

Is your point that bash is easy to use and that changing things will
make the system unusable? Both are valid, sure. It is important for any
new system to work well with the old bash scripts until everything is
available in both formats (or forever, for that matter), so an XML based
system should work well with the older one. On the other matter, I can
see why you're saying that bash scripts are easy.

My point is that I think that bash scripts aren't as easy and human
readable as people give them credit for. Sure, a lot of people know how
to read bash, so to them it's easy. But I'd argue that bash has a higher
learning curve than XML does, since XML has a lot more english in it.

As for the other scripting languages you mention, I don't think that's
relavant because nobody's suggesting converting to python or haskell. As
far as I can tell, the suggestion is to use XML. That's why I brought it
back up.


> 
> > > 
> > > Having the startup scripts/modules binary though, means you cannot
> > > do quick changes, etc as well.
> > > 
> > > And like many others did say, python/whatever have too large
> > > dependencies.  For example, having python initscripts will make
> > > an initrd/diet_system a PITA to get running.
> > > 
> > > Having SVC support build into init, now that is a reason why I would
> > > change init.
> > > 
> > > Another question that bothers me ... if everybody is so against bash
> > > being slow, why don't they spent time to get bash's IO more optimised?
> > > For example, getting bash to read the whole script, and then executing
> > > it, and not reading line by line should already add much improvement.
> > > 
> > > 
> > > Anyhow, just a few quick thoughts,
-- 
Wesley Leggette <wleggette@gate.net>


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Init replacement

[foser]

Wesley Leggette wrote:

> As for the other scripting languages you mention, I don't think that's
> relavant because nobody's suggesting converting to python or haskell. As
> far as I can tell, the suggestion is to use XML. That's why I brought it
> back up.
> 

I'd say all of this dicussion is not relevant, the Gentoo init is not 
questioned here. The guy just tried to promote his new init system and 
that shouldn't have been done on this ml, it does not belong here. Don't 
tie this in vs. the Gentoo init system, that works fine as it is and 
maybe in the future something better pops up. pinit wasn't meant as a 
replacement, don't start discussing it here like it was.

- foser


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Init replacement

[Wesley Leggette]

On Mon, 2003-05-05 at 07:33, foser wrote:
> Wesley Leggette wrote:
> 
> > As for the other scripting languages you mention, I don't think that's
> > relavant because nobody's suggesting converting to python or haskell. As
> > far as I can tell, the suggestion is to use XML. That's why I brought it
> > back up.
> > 
> 
> I'd say all of this dicussion is not relevant, the Gentoo init is not 
> questioned here. The guy just tried to promote his new init system and 
> that shouldn't have been done on this ml, it does not belong here. Don't 
> tie this in vs. the Gentoo init system, that works fine as it is and 
> maybe in the future something better pops up. pinit wasn't meant as a 
> replacement, don't start discussing it here like it was.
> 
> - foser

I agree whole heartedly. It's just an idea some guy came up with. It's
not the end of the world.

> 
> 
> --
> gentoo-dev@gentoo.org mailing list
-- 
Wesley Leggette <wleggette@gate.net>


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Init replacement

[leon j. breedt]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sat, May 03, 2003 at 11:08:55AM +0200, Wouter van Kleunen wrote:
> Yes. I have thought of adding a script-service. But i removed it, because
> i do not like scripts. I agree that they are convenient for executing a
> collection of commands, but bash is a very weak programming language.
well, you don't really need a programming language for init scripts themselves,
conceptually you're not doing anything complex enough in them to warrant
it. especially not if you have a compiled program doing all the calculations
requiring data structures.

for execution of commands, manipulating files quickly, and all the kinds of
housekeeping things you typically want to do to start a "difficult" daemon,
something which cannot be neatly done with a one line command like
start-stop-daemon, a shell script is actually the most suitable solution,
in my opinion. i really would not recommend requiring that it be an
actual programming language, that would really limit adoption of your program
to a far too small audience...

how i planned to implement my version, was to have
a file /etc/svc.d/<name>, which described the service. in this file, you
would declare dependencies, security attributes, etc. and also specify the
command to start and to stop the service, which could refer to seperate
scripts or just be oneliner commands.

something like:

start: /usr/sbin/exim -q15m -bd

or

script: exim

where the first would start the daemon, and to stop it, send a KILL signal
(implied by a missing stop: keyword). and the second would expect the script
(located in /etc/svc.d/scripts) to accept 'start' or 'stop' arguments.

a symlink in /etc/init.d/<name> => /sbin/svc would emulate the current behaviour
of init scripts by running as if you'd executed 'svc <action> <name>', where
<action> would be the argument you supplied when executing it.

there will always be daemons which require more care and feeding than
well-behaved ones, at some point to handle these you're going to have to
allow execution of scripts, or reinvent your own scripting language again :)

another thing which i think may be useful, include or exclude at your
discretion, is to allow execution of scripts on entering/exiting a profile
(or runlevel as sysvinit calls it).

for example, if i drop down to single user profile, maybe i have some
commands i want to execute before the shell appears.

just some ideas...

leon

- -- 
in the beginning, was the code.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+s8IsRWcl5mzp4f4RAgpLAJsFL+W/JZYRdHUBp6DJ36o6IBX5pQCfUzvM
dZjX/0Gzge4Dp93aH2Ne36A=
=Cx6r
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Init replacement

[Paul de Vrieze]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 724 bytes --]

On Saturday 03 May 2003 15:20, leon j. breedt wrote:
> how i planned to implement my version, was to have
> a file /etc/svc.d/<name>, which described the service. in this file, you
> would declare dependencies, security attributes, etc. and also specify the
> command to start and to stop the service, which could refer to seperate
> scripts or just be oneliner commands.

Why not use the current gentoo init scripts. They are able to provide all 
things you want. Just rewrite /sbin/runscript to be a wrapper to your program 
and you can do all you want while keeping compatibility from the user 
perspective.

Paul

-- 
Paul de Vrieze
Researcher
Mail: pauldv@cs.kun.nl
Homepage: http://www.devrieze.net

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-dev] Re: Init replacement

[Robert Wittams]

Wouter van Kleunen wrote:

> 
> 
> I wrote a new init system that has numerous advantages over the old script
> based init system. Please have a look at:
> 
> pinit.sf.net
> 
> I am a gentoo user, and i converted my scripts -> services for my system.
> I would like to have feedback on this system. Please try it out on your
> system (safely from your home directory).
> 
> 
> Wouter
> 
> 
> 
> 
> --
> gentoo-dev@gentoo.org mailing list

If changing the init system is on the cards, it would be far better to go
for minit. 

http://www.fefe.de/minit/

It is as small as possible, does not require massive unaudited libraries,
programmed with security in mind, does not impose a language requirement -
it will work with shell scripts just fine, but encourages the use of just
simple sym links. It wouldn't be overly arduous to make it work with
gentoos current system. 

It can be linked against diet libc too, giving better performance and
reducing code bloat. 

Robert Wittams


--
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Init replacement

[A.Waschbuesch]

Wouter van Kleunen wrote:
> [...] 
> I wrote a new init system that has numerous advantages over the old
> script based init system. Please have a look at:
> 
> pinit.sf.net
> [...]

Did You ever try runit (http://smarden.org/runit/)?



--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Init replacement

[Joshua Brindle]

>On Fri, May 02, 2003 at 10:08:03AM -0700, Jon Kent wrote:
>> I must be honest and say that the Gentoo init system
>> is not easiest in the world, I prefer the old
>> rcX.d/Sxx[name] approach myself as its simple, but I'd
>> still prefer the current approach over the proposed
>> approach.
>
>It's not a proposal to change Gentoo's default init-system (or at least I
>hope so). I fully support the OP with his work because one can never know
>what it provides untill it's available. 
>
>So, keep up the development. 
>

I agree. Everyone here should know very well that gentoo is about
choices. We provide the user with choices every opportunity we have,
though some places it's difficult to do. When a choice presents itself
don't scrutinize it, we do not ever attempt to lock users into a single
solution, and we make every attempt to provide as many choices as possible.

On the subject of init scripts, I recall having a conversation with seemant
about this init system which used tree based dependancies and could start 
init scripts simaltaeneously if their dependancy trees didn't collide (for faster
bootups), does this solution provide this? we'd really like to get something 
that will take some of the overhead out of the init system...



Joshua Brindle

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Init replacement

[Martin Schlemmer]

[-- Attachment #1: Type: text/plain, Size: 1359 bytes --]

On Fri, 2003-05-02 at 22:34, Joshua Brindle wrote:

> On the subject of init scripts, I recall having a conversation with seemant
> about this init system which used tree based dependancies and could start 
> init scripts simaltaeneously if their dependancy trees didn't collide (for faster
> bootups), does this solution provide this? we'd really like to get something 
> that will take some of the overhead out of the init system...
> 

The problem mostly with an approach like this, is that without going the
extreme python/C_with_glib_or_xml, you will prob have more overhead in
the poor bash engine figuring this out, than the speed you will get with
then starting one or two services in parallel.

I have said in the past that I will have a look at parallel startup, but
currently there are other points that is more critical and a factor
influencing the speed that needs attention.

Also, it would be nice if somebody who have used Gentoo for a while, and
are better than me at writing, would make some effort to get the docs
updated, more clear, and maybe add some of the missing man pages.  This
should already take some of the sting out of it all.  If somebody is
interested, I will gladly answer questions, etc.


-- 

Martin Schlemmer
Gentoo Linux Developer, Desktop/System Team Developer
Cape Town, South Africa



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Init replacement

[George Shapovalov]

I totaly agree with the choice argument. 
Then, personally I have a mixed feeling about this system. On one hand I have 
all the same arguments about introducing unnecessary dependencies, tightness 
and non-compliance (not that our present way is completely "compliant", but 
this one is much further away.).
On the other hand this is quite a nice approach to automation of init scripts 
handling and looks to be a clean way to parallelize the process. The former 
should allow creation of nicely looking front ends for init sequence 
manipulation, which even a newbie user should be able to apply for simplistic 
manipulation, but that should also allow a more involved edits for the 
inclined user.

This makes me think, that both approaches have a room to existance as they are 
targeting diferent situations (namely small goal-specific systems, where 
tightness and hands-on controll are a must vs desktop and ease-of-abuse).
Thus the only sensible way of going about adding this to gentoo I see is to 
create a new (experimental) profile.

Wouter: this apparently requires:
1. impementation to stabilize
2. finding large enough group of interested people, who would provide support 
and maintaince to the profile (and this is apparently pointless without some 
backing on a user side)
3. appropriate packaging of all related software, so that it could be 
effectively handled by the profile..

As you see not too small amount of work ;), but who knows, may be some time 
this will become more popular than our present way?

George


On Friday 02 May 2003 13:34, Joshua Brindle wrote:
> >On Fri, May 02, 2003 at 10:08:03AM -0700, Jon Kent wrote:
> >It's not a proposal to change Gentoo's default init-system (or at least I
> >hope so). I fully support the OP with his work because one can never know
> >what it provides untill it's available.
> >
> >So, keep up the development.
>
> I agree. Everyone here should know very well that gentoo is about
> choices. We provide the user with choices every opportunity we have,
> though some places it's difficult to do. When a choice presents itself
> don't scrutinize it, we do not ever attempt to lock users into a single
> solution, and we make every attempt to provide as many choices as possible.
>
> On the subject of init scripts, I recall having a conversation with seemant
> about this init system which used tree based dependancies and could start
> init scripts simaltaeneously if their dependancy trees didn't collide (for
> faster bootups), does this solution provide this? we'd really like to get
> something that will take some of the overhead out of the init system...
>
> Joshua Brindle


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Init replacement

[Wouter van Kleunen]

On Fri, 2 May 2003, George Shapovalov wrote:

> I totaly agree with the choice argument.
> Then, personally I have a mixed feeling about this system. On one hand I have
> all the same arguments about introducing unnecessary dependencies, tightness
> and non-compliance (not that our present way is completely "compliant", but
> this one is much further away.).
> On the other hand this is quite a nice approach to automation of init scripts
> handling and looks to be a clean way to parallelize the process. The former
> should allow creation of nicely looking front ends for init sequence
> manipulation, which even a newbie user should be able to apply for simplistic
> manipulation, but that should also allow a more involved edits for the
> inclined user.
>
> This makes me think, that both approaches have a room to existance as they are
> targeting diferent situations (namely small goal-specific systems, where
> tightness and hands-on controll are a must vs desktop and ease-of-abuse).
> Thus the only sensible way of going about adding this to gentoo I see is to
> create a new (experimental) profile.
>
> Wouter: this apparently requires:
> 1. impementation to stabilize
Yup. I believe it is usable now, but only for people who know what they
are doing.

> 2. finding large enough group of interested people, who would provide support
> and maintaince to the profile (and this is apparently pointless without some
> backing on a user side)
I cannot write all the services myself, so indeed i need people to back me
up on this. The same goes for sysvinit, the author of sysvinit did not
write all the init scripts in the world.

> 3. appropriate packaging of all related software, so that it could be
> effectively handled by the profile..
>
> As you see not too small amount of work ;), but who knows, may be some time
> this will become more popular than our present way?
>
> George
>
>
> On Friday 02 May 2003 13:34, Joshua Brindle wrote:
> > >On Fri, May 02, 2003 at 10:08:03AM -0700, Jon Kent wrote:
> > >It's not a proposal to change Gentoo's default init-system (or at least I
> > >hope so). I fully support the OP with his work because one can never know
> > >what it provides untill it's available.
> > >
> > >So, keep up the development.
> >
> > I agree. Everyone here should know very well that gentoo is about
> > choices. We provide the user with choices every opportunity we have,
> > though some places it's difficult to do. When a choice presents itself
> > don't scrutinize it, we do not ever attempt to lock users into a single
> > solution, and we make every attempt to provide as many choices as possible.
> >
> > On the subject of init scripts, I recall having a conversation with seemant
> > about this init system which used tree based dependancies and could start
> > init scripts simaltaeneously if their dependancy trees didn't collide (for
> > faster bootups), does this solution provide this? we'd really like to get
> > something that will take some of the overhead out of the init system...
> >
> > Joshua Brindle
>
>
> --
> gentoo-dev@gentoo.org mailing list
>


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Init replacement

[Wesley Leggette]

On Sat, 2003-05-03 at 04:14, Wouter van Kleunen wrote:
> On Fri, 2 May 2003, George Shapovalov wrote:
> 
> > I totaly agree with the choice argument.
> > Then, personally I have a mixed feeling about this system. On one hand I have
> > all the same arguments about introducing unnecessary dependencies, tightness
> > and non-compliance (not that our present way is completely "compliant", but
> > this one is much further away.).
> > On the other hand this is quite a nice approach to automation of init scripts
> > handling and looks to be a clean way to parallelize the process. The former
> > should allow creation of nicely looking front ends for init sequence
> > manipulation, which even a newbie user should be able to apply for simplistic
> > manipulation, but that should also allow a more involved edits for the
> > inclined user.
> >
> > This makes me think, that both approaches have a room to existance as they are
> > targeting diferent situations (namely small goal-specific systems, where
> > tightness and hands-on controll are a must vs desktop and ease-of-abuse).
> > Thus the only sensible way of going about adding this to gentoo I see is to
> > create a new (experimental) profile.
> >
> > Wouter: this apparently requires:
> > 1. impementation to stabilize
> Yup. I believe it is usable now, but only for people who know what they
> are doing.
> 
> > 2. finding large enough group of interested people, who would provide support
> > and maintaince to the profile (and this is apparently pointless without some
> > backing on a user side)
> I cannot write all the services myself, so indeed i need people to back me
> up on this. The same goes for sysvinit, the author of sysvinit did not
> write all the init scripts in the world.

I'll definitly help out writing scripts. Your system is so much easier
to read than sysvinit. And it's a lot easier to write for. It's more
english like. And, hey, if you can't write for XML, I don't know WHAT
you've been doing all these years. Everybody should know HTML, and XML's
syntax is the exact same. There's only about five new words to learn to
get your XML down pat. I don't understand why people are being such a
stick in the mud about all this.

> 
> > 3. appropriate packaging of all related software, so that it could be
> > effectively handled by the profile..
> >
> > As you see not too small amount of work ;), but who knows, may be some time
> > this will become more popular than our present way?
> >
> > George
> >
> >
> > On Friday 02 May 2003 13:34, Joshua Brindle wrote:
> > > >On Fri, May 02, 2003 at 10:08:03AM -0700, Jon Kent wrote:
> > > >It's not a proposal to change Gentoo's default init-system (or at least I
> > > >hope so). I fully support the OP with his work because one can never know
> > > >what it provides untill it's available.
> > > >
> > > >So, keep up the development.
> > >
> > > I agree. Everyone here should know very well that gentoo is about
> > > choices. We provide the user with choices every opportunity we have,
> > > though some places it's difficult to do. When a choice presents itself
> > > don't scrutinize it, we do not ever attempt to lock users into a single
> > > solution, and we make every attempt to provide as many choices as possible.
> > >
> > > On the subject of init scripts, I recall having a conversation with seemant
> > > about this init system which used tree based dependancies and could start
> > > init scripts simaltaeneously if their dependancy trees didn't collide (for
> > > faster bootups), does this solution provide this? we'd really like to get
> > > something that will take some of the overhead out of the init system...
> > >
> > > Joshua Brindle
> >
> >
> > --
> > gentoo-dev@gentoo.org mailing list
> >
> 
> 
> --
> gentoo-dev@gentoo.org mailing list
-- 
Wesley Leggette <wleggette@gate.net>


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Init replacement

[C. Brewer]

[-- Attachment #1: Type: text/plain, Size: 884 bytes --]

On 04 May 2003 11:02:24 -0500
Wesley Leggette <wleggette@gate.net> wrote:

> And, hey, if you can't write for XML, I don't know WHAT
> you've been doing all these years. Everybody should know HTML, and XML's
> syntax is the exact same. There's only about five new words to learn to
> get your XML down pat. I don't understand why people are being such a
> stick in the mud about all this.

I'm sorry I missed the memo that required me to learn HTML and XML. Terribly
boorish of me. I should probably go resign on on all my development projects
because I have only bothered to script in bash. Silly me.

Also I have noticed that pinit is copyrighted in several inflections of the
word, and although maybe not in the one it's intended, you know how touchy
people get.


-- 
Chuck Brewer
Registered Linux User #284015
Get my gpg public key at pgp.mit.edu!! Encrypted e-mail preferred.



[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]