Discussion:
Why simpleinit-msb ?
(too old to reply)
Dragan Stanojevic - Nevidljivi
2005-06-14 14:57:20 UTC
Permalink
Hello folks,

I'm new to this distro, but I'd like to help.

I don't know the reason why have you abandoned sysVinit. First of all
simpleinit-msb is not longer maintained. It's successor LFSinit has not
been changed since 01/2005. And not to say the reasons in
WHY_SYSVINIT_SETUPS_SUCK file in simpleinit-smb tarball are childish to
say the least. simpleinit demonstrates why sysvinit was created!

I think the sysvinit is a way to go. simpleinit is hard to understand at
first, makes smgl boot process as complex as it gets, and all SA are
already quite familiar with sysv init. You're making smgl a lot less
desirable because of it :(

Is there some explanation why have you abandoned it?

bye,
N::
Andrew "ruskie" Levstik
2005-06-14 15:40:08 UTC
Permalink
Post by Dragan Stanojevic - Nevidljivi
Hello folks,
I'm new to this distro, but I'd like to help.
I don't know the reason why have you abandoned sysVinit. First of all
simpleinit-msb is not longer maintained. It's successor LFSinit has not
been changed since 01/2005. And not to say the reasons in
WHY_SYSVINIT_SETUPS_SUCK file in simpleinit-smb tarball are childish to
say the least. simpleinit demonstrates why sysvinit was created!
I think the sysvinit is a way to go. simpleinit is hard to understand at
first, makes smgl boot process as complex as it gets, and all SA are
already quite familiar with sysv init. You're making smgl a lot less
desirable because of it :(
Is there some explanation why have you abandoned it?
bye,
[ Part application/x-pkcs7-signature; name="smime.p7s" (smime.p7s) : S/MIME Cryptographic Signature ]
(not shown)
_______________________________________________
SM-Discuss mailing list
http://lists.ibiblio.org/mailman/listinfo/sm-discuss
lemme first get biased here... I have sysVinit atleast rh style...
I love bsd style init system scripts...
But for modularity and runtime depends simpleinit is the best atm.

it's not hard to get used to... it's easier then rh style sysVinit.
Not sure but I think simpleinit was created after sysvinit...
So go ask yourself why... if sysvinit is supposed to be so good.
--
Andrew "ruskie" Levstik

http://ruskie.dtdm.org/blog/
Andrew "ruskie" Levstik
2005-06-14 16:40:51 UTC
Permalink
Post by Andrew "ruskie" Levstik
lemme first get biased here... I have sysVinit atleast rh style...
Erm that should be hate not have... lol /me tries to wakeup
--
Andrew "ruskie" Levstik

http://ruskie.dtdm.org/blog/
Seth Alan Woolley
2005-06-14 17:17:44 UTC
Permalink
Post by Dragan Stanojevic - Nevidljivi
Hello folks,
I'm new to this distro, but I'd like to help.
I don't know the reason why have you abandoned sysVinit.
1) Automated init script handling required lots more code and wasn't
predictable upon user modification. Sorcery needs to be able to
optionally install an and enable an init script within the context of
user-installed init scripts. Sysvinit doesn't make this simple and
transparent.

2) sysvinit has no parallel startup capability

3) sysvinit has no inherent dependency information, which helps 1 and 2
Post by Dragan Stanojevic - Nevidljivi
First of all
simpleinit-msb is not longer maintained.
We maintain our version ourselves. I've provided at least one patch
myself, for example. The core simpleinit-msb is only a small fraction
of our entire init system. We're considering making it even more
simple, as well.
Post by Dragan Stanojevic - Nevidljivi
It's successor LFSinit has not
been changed since 01/2005. And not to say the reasons in
WHY_SYSVINIT_SETUPS_SUCK file in simpleinit-smb tarball are childish to
say the least. simpleinit demonstrates why sysvinit was created!
I'm not sure what you mean by sysvinit being more powerful than
simpleinit. sysvinit was abandoned for legitimate reasons.

What can you do in sysvinit that can't be done in a simpleinit setup?
Post by Dragan Stanojevic - Nevidljivi
I think the sysvinit is a way to go. simpleinit is hard to understand at
first,
And sysvinit isn't? Granted, I'm quite used to both styles, but
sysvinit is a hack implementation in search of problems.
Post by Dragan Stanojevic - Nevidljivi
makes smgl boot process as complex as it gets,
Simpleinit init scripts are a fraction of the size of regular init
scripts and mostly backwards compatible except for a line or two about
dependency and runlevel information that were already included extras in
our old sysvinit setup. simpleinit merely formalizes what we were
including already plus adds dependency information for parallel init.
Post by Dragan Stanojevic - Nevidljivi
and all SA are
already quite familiar with sysv init. You're making smgl a lot less
desirable because of it :(
Has it been causing problems for you; in what way does it cause problems?
Post by Dragan Stanojevic - Nevidljivi
Is there some explanation why have you abandoned it?
Yes, as I explain above.
Post by Dragan Stanojevic - Nevidljivi
bye,
Seth
--
Seth Alan Woolley [seth at positivism.org], SPAM/UCE is unauthorized
Key id 00BA3AF3 = 8BE0 A72E A47E A92A 0737 F2FF 7A3F 6D3C 00BA 3AF3
Quality Assurance Team Leader; Security Team Member, Leader Emeritus
Linux so advanced, it may as well be magic http://www.sourcemage.org
Elected Coordinating Committee Member, Secretary, and Finances Chair
Pacific Green Party of Oregon - Peace - http://www.pacificgreens.org
Chris Dombroski
2005-06-14 20:35:16 UTC
Permalink
Post by Seth Alan Woolley
What can you do in sysvinit that can't be done in a simpleinit setup?
Just to throw my two cents in, I have had no luck getting intelligent ups
shutdown working with simpleinit.

I have not been able to find a way to get the computer most of the shut down
(mostly everything unmounted or mounted read-only) and then turn off
the ups so
that when power is restored, the ups turns back on and causes all the
computers
plugged into it to start.
Seth Alan Woolley
2005-06-14 20:51:51 UTC
Permalink
Post by Chris Dombroski
Post by Seth Alan Woolley
What can you do in sysvinit that can't be done in a simpleinit setup?
Just to throw my two cents in, I have had no luck getting intelligent ups
shutdown working with simpleinit.
I wish it to be known that this has nothing to do with the type of init
system. Simpleinit requires the same type of work one would do in
sysvinit for this.
Post by Chris Dombroski
I have not been able to find a way to get the computer most of the shut down
(mostly everything unmounted or mounted read-only) and then turn off
the ups so
that when power is restored, the ups turns back on and causes all the
computers
plugged into it to start.
I believe what you want to do is put it in the DEV runlevel and give it
stuff to do on stop() and make an empty start() function. That will
linearize it to happen after mountall.sh stops. We're going to be using
mountall.sh's stop() routine instead of simpleinit's as well since
simpleinit is not using an adequately powerful unmount process for all
filesystem types. I'm not sure how far along this has been done yet,
though.

You can also make the ups script itself unmount the filesystems, too.

Seth
--
Seth Alan Woolley [seth at positivism.org], SPAM/UCE is unauthorized
Key id 00BA3AF3 = 8BE0 A72E A47E A92A 0737 F2FF 7A3F 6D3C 00BA 3AF3
Quality Assurance Team Leader; Security Team Member, Leader Emeritus
Linux so advanced, it may as well be magic http://www.sourcemage.org
Elected Coordinating Committee Member, Secretary, and Finances Chair
Pacific Green Party of Oregon - Peace - http://www.pacificgreens.org
David Kowis
2005-06-14 21:43:20 UTC
Permalink
Post by Seth Alan Woolley
Post by Chris Dombroski
Post by Seth Alan Woolley
What can you do in sysvinit that can't be done in a simpleinit setup?
Just to throw my two cents in, I have had no luck getting intelligent ups
shutdown working with simpleinit.
I wish it to be known that this has nothing to do with the type of init
system. Simpleinit requires the same type of work one would do in
sysvinit for this.
Just the works already done for sysvinit, and most UPS programs (nut for
example) explain how to set it up for sysvinit and we had difficulty figuring
out how to do it for simpleinit.
Post by Seth Alan Woolley
I believe what you want to do is put it in the DEV runlevel and give it
stuff to do on stop() and make an empty start() function. That will
linearize it to happen after mountall.sh stops. We're going to be using
mountall.sh's stop() routine instead of simpleinit's as well since
simpleinit is not using an adequately powerful unmount process for all
filesystem types. I'm not sure how far along this has been done yet,
though.
That was the major draw back with UPS support and simpleinit. We had no way of
guaranteeing that the system had been almost completely shut down before
attempting to send the powerdown signal to the ups.
Post by Seth Alan Woolley
You can also make the ups script itself unmount the filesystems, too.
True, but that's not quite as nice. And it should be done inplace of calling
the Kernel Power Off.

There goes swoolley being a genius again, Always solving the worlds
problems... :)

David
Andrew
2005-06-14 21:45:06 UTC
Permalink
Post by Dragan Stanojevic - Nevidljivi
Hello folks,
I'm new to this distro, but I'd like to help.
Thank you for your feedback.
Post by Dragan Stanojevic - Nevidljivi
I don't know the reason why have you abandoned sysVinit. First of all
simpleinit-msb is not longer maintained. It's successor LFSinit has not
been changed since 01/2005. And not to say the reasons in
WHY_SYSVINIT_SETUPS_SUCK file in simpleinit-smb tarball are childish to
say the least.
As far afaik those are their views, not ours, however, having lived
through the times when we tried to make the sysvinit scripting style
work with what we wanted, I have to politely disagree with you and say
that sysvinit is pretty lousy for what we wanted.
Post by Dragan Stanojevic - Nevidljivi
simpleinit demonstrates why sysvinit was created!
I think you have this backwards, although i could be wrong, our simpleinit
setup was created after the sysvinit style was thought up.
Post by Dragan Stanojevic - Nevidljivi
I think the sysvinit is a way to go. simpleinit is hard to understand at
first, makes smgl boot process as complex as it gets, and all SA are
already quite familiar with sysv init. You're making smgl a lot less
desirable because of it :(
I really think thats percieved complexity from it being new, and not
actual complexity. Life at smgl got a whole lot nicer when our init
script setup was simplified and predictible, unlike it was with sysvinit.

Pretty much any SA is familar with rh and rpm, does that mean we should
abandon sorcery and start using rpm? No. Just because others are using
(what we think is) inferior technology, doesn't mean that we should
settle for it. We think what we have is better, and I believe that any
SA who knows whats good for them recognizes that the sysvinit script
style is a far cry from ideal for many tasks. I'll also point out that
another more popular source based distro uses python for their init
system, I can't imagine why they made that decision.
Post by Dragan Stanojevic - Nevidljivi
Is there some explanation why have you abandoned it?
Let us draw a line between the init program (/sbin/init) and the
init scripts (/etc/init.d). In many respects the two are independent.
Lets not get confused between the sysvinit script style (symlink forest
with [SK]\d+name), and the actual sysvinit program which knows nothing
of this.

Is your complaint about the fact that we have a different binary
program as /sbin/init or that we have our own scripting setup layered
on top of the program?

I do not think sysvinit scripting style lends itself well to automation
with user intervention, inter-script dependencies, both on bootup and on
shutdown, or handling parallel init script execution like our setup does.

Keep in mind that our setup requires very little modification to existing
sysvinit style init scripts. In many cases, ours are actually smaller
due to common code being factored into libraries.

That being said, it certainly would be possible to switch back to using
the sysvinit /sbin/init program with our current scripts layered on
top. The facilities simpleinit-msb provides would simply need to be
written in bash. In fact, an even simpler init than simpleinit-msb or
sysvinit could be used if that were to be done. Really, all the init
program has to do is execute a known script, and then wait() on orphaned
processes, so in that regard, just about anything would do.

-Andrew
--
__________________________________________________________________________
|Andrew D. Stitt | astitt at sourcemage.org |
|irc: afrayedknot | afrayedknot at t.armory.com |
|aim: thefrayedknot or iteratorplusplus | acedit at armory.com |
|Sorcery Team Lead | ftp://t.armory.com/ |
--------------------------------------------------------------------------
Sergey A. Lipnevich
2005-06-15 09:10:57 UTC
Permalink
I like the new init much better, it actually works now. So I have to
agree with
Andrew here. Also, LSB init probably didn't change much because it Just
Works(tm).

Not that it matters much, but there's another contender, cinit
(http://freshmeat.net/projects/cinit/). I don't know how much similar it is to
either sysvinit or simpleinit. It apears to be maintated.

Sergey.
On Tue, Jun 14, 2005 at 04:57:20PM +0200, Dragan Stanojevic -
Post by Dragan Stanojevic - Nevidljivi
Hello folks,
I'm new to this distro, but I'd like to help.
Dragan Stanojevic - Nevidljivi
2005-06-15 13:44:49 UTC
Permalink
Hi there,

I'll just reply here, since it would be tiresome to answer to all of you
separately.
Post by Andrew
Post by Dragan Stanojevic - Nevidljivi
simpleinit demonstrates why sysvinit was created!
I think you have this backwards, although i could be wrong, our simpleinit
setup was created after the sysvinit style was thought up.
My point is. You are transferring all the boot process to /etc/init.d/rc
script, which is way different to how sysvinit does it. Early unices did
it just like sm does it now, an rc script. Almost as you would boot
linux with init=/etc/init.d/rc ?!? [ lets forget the respawning aspect
for simplicity :) ]

It was written that we don't have to keep up with the bad practices of
other unices, and so we went to simpleinit. But! sysvinit IS maintained,
and it is maintained at least 30 years. Simpleinit died rather quickly,
didn't it? If sysvinit was so bad, don't you thing other major
distributions would leave it years ago?

Also about dependices... I don't think it is really UNIXish to rely to
much on the others. If the program needs ldap server up and running, is
it so hard to script it in its startup script? Moreover, numbering
scheme user in sysvinit doesn't have to be unique. It is completely
irrelevant will the sshd, or apache2 start first. In such cases you can
reuse these numbers over and over again (ie. S050sshd and S050apache2).
As for parallel script execution, I don't know much about it. I just
know that smgl-0.9.4-test3 doesn't use it.
Post by Andrew
Let us draw a line between the init program (/sbin/init) and the
init scripts (/etc/init.d). In many respects the two are independent.
Lets not get confused between the sysvinit script style (symlink forest
with [SK]\d+name), and the actual sysvinit program which knows nothing
of this.
This is a valid point. I don't like init.d scripts more than init itself.

The reason I picked on init first was that my network support is not
brought up. So, off I went with:
runlevel - but no such command ?
vi /etc/inittab - and I was greeted with something unfamiliar, but ok
vi /etc/init.d/rc - and there was the problem

The problem is, to get the runlevel I am, I need to find it in
/etc/sysconf/*, and I'm used to find it in inittab.

Moreover. In sysvinit runelevels are completely separate, but in
simpleinit you use them all, from 1st to 2nd, 3rd... which is strange.
Post by Andrew
I do not think sysvinit scripting style lends itself well to automation
with user intervention, inter-script dependencies, both on bootup and on
shutdown, or handling parallel init script execution like our setup does.
I thought of this distribution as returning decisions to the SA (which,
by the way, increases complexity), not "users". I don't see the
problem here. If an SA breaks init.d scripts, it's his/hers doing. With
sysvinit SA gets the choice of what is started when, and as I've seen
with simpleinit, simpleinit itself sorts what its starts when based on
dependices. That sound more as loosing control than gaining it.
Post by Andrew
Keep in mind that our setup requires very little modification to existing
sysvinit style init scripts. In many cases, ours are actually smaller
due to common code being factored into libraries.
Yeah, that's the second problem. SysVinit executes subshells for any
script, and therefore they are correctly written but in sgml there are a
lot of errors, since you don't use subshells but source other scripts.
Just for example:

In /etc/inittab you set PATH:
PATH = /sbin:/bin:/usr/sbin:/usr/bin

This is then put in the environment for /etc/init.d/rc, BUT! in that
script you reset it:

PATH=/sbin:/bin
also you set the variable RUNLEVELS_DIR

then you source the /etc/sysconfig/init, and reset RUNLEVELS_DIR with
the same value

following that you source the /etc/init.d/sgml_functions and yet again
reset PATH

export PATH=/bin:/usr/bin:/sbin:/usr/sbin

Now after that I stopped looking...

I didn't even got to the network part which was the real problem for
which I went to this hunt...

While I'm at it, I doubt I would put something like simpleinit at my
production server... ever... I don't mind learning it, I don't mind
learning anything, but this is, IMO, a wrong way to do it.

IMHO simpleinit was created because sysvinit was not understood at that
time... It is reinventing the wheel in the bad way...

That said, the newest Mac OS X - Tiger has created completely new bootup
process called launchd...

- thank for all your replies -
N::
Seth Alan Woolley
2005-06-15 21:37:06 UTC
Permalink
Post by Dragan Stanojevic - Nevidljivi
Hi there,
I'll just reply here, since it would be tiresome to answer to all of you
separately.
Post by Andrew
Post by Dragan Stanojevic - Nevidljivi
simpleinit demonstrates why sysvinit was created!
I think you have this backwards, although i could be wrong, our simpleinit
setup was created after the sysvinit style was thought up.
My point is. You are transferring all the boot process to /etc/init.d/rc
script, which is way different to how sysvinit does it. Early unices did
it just like sm does it now, an rc script. Almost as you would boot
linux with init=/etc/init.d/rc ?!? [ lets forget the respawning aspect
for simplicity :) ]
Here's a quick smgl init concepts overview that might allow you to parse
the code easier:

The init program stores the linked list of spawned services (see the
display-services command) fed to it via a /dev/initctl fifo using the
"need" command, which will "block" until the "need" is satisfied in
init's linked list record. It handles tty spawning and calls wait() on
zombied processes it inherits to reap them and handles ctrl-alt-del
logic. Everything else is very, very simply handled by /etc/init.d/rc,
but it's more than the BSD-style init you are referring to.

To get the system booted, you "need" the default runlevel and the
runlevel need logic goes down to the first runlevel since it's needed
first. Each runlevel script then "needs" everything within the runlevel
it represents that is enabled. It's actually quite elegant for handling
dependencies.
Post by Dragan Stanojevic - Nevidljivi
It was written that we don't have to keep up with the bad practices of
other unices, and so we went to simpleinit. But! sysvinit IS maintained,
and it is maintained at least 30 years. Simpleinit died rather quickly,
didn't it? If sysvinit was so bad, don't you thing other major
distributions would leave it years ago?
Binary distros like to be 100% compatible with the status quo. Source
distros have a lot more freedom to move around and thus can be a little
more creative. Another major source distro, as was already mentioned,
doesn't use sysvinit, either, although that might be because they prefer
to write in Python rather than C.
Post by Dragan Stanojevic - Nevidljivi
Also about dependices... I don't think it is really UNIXish to rely to
much on the others. If the program needs ldap server up and running, is
it so hard to script it in its startup script?
How do you do this in sysvinit generally?
Post by Dragan Stanojevic - Nevidljivi
Moreover, numbering
scheme user in sysvinit doesn't have to be unique. It is completely
irrelevant will the sshd, or apache2 start first.
simpleinit doesn't enforce a consistent ordering because it doesn't
pre-flatten the dependency information. It's handled at run-time.
What's relevant is described in the script itself. Isn't better to
describe what you want rather than the way it will happen? That's
source code for you -- what you want rather than the exact way it will
happen.
Post by Dragan Stanojevic - Nevidljivi
In such cases you can
reuse these numbers over and over again (ie. S050sshd and S050apache2).
Yes, we're all (well at least I am) quite familiar with sysvinit.
Post by Dragan Stanojevic - Nevidljivi
As for parallel script execution, I don't know much about it. I just
know that smgl-0.9.4-test3 doesn't use it.
It's not enabled by default, but can be enabled by a one-line config
option in /etc/sysconfig/init. For multiprocessor systems, I always
turn it on because it is noticably faster to boot not to mention it's
always nice to know you're actually using the processors you paid for.
For single-processor systems it's not much of a gain except for filling
in little holes of emptiness here and there.
Post by Dragan Stanojevic - Nevidljivi
Post by Andrew
Let us draw a line between the init program (/sbin/init) and the
init scripts (/etc/init.d). In many respects the two are independent.
Lets not get confused between the sysvinit script style (symlink forest
with [SK]\d+name), and the actual sysvinit program which knows nothing
of this.
This is a valid point. I don't like init.d scripts more than init itself.
I'll be considering the two together, since, while there is a
distinction, I think you were meaning to talk about entire init systems.
Post by Dragan Stanojevic - Nevidljivi
The reason I picked on init first was that my network support is not
runlevel - but no such command ?
vi /etc/inittab - and I was greeted with something unfamiliar, but ok
vi /etc/init.d/rc - and there was the problem
The problem is, to get the runlevel I am, I need to find it in
/etc/sysconf/*, and I'm used to find it in inittab.
does "telinit runlevel" not work?

does /etc/sysconfig/init not tell you your default runlevel?
Post by Dragan Stanojevic - Nevidljivi
Moreover. In sysvinit runelevels are completely separate, but in
simpleinit you use them all, from 1st to 2nd, 3rd... which is strange.
I'm not sure what you mean here. telinit switch will let you change
runlevels. telinit help will give you more commands.
Post by Dragan Stanojevic - Nevidljivi
Post by Andrew
I do not think sysvinit scripting style lends itself well to automation
with user intervention, inter-script dependencies, both on bootup and on
shutdown, or handling parallel init script execution like our setup does.
I thought of this distribution as returning decisions to the SA (which,
by the way, increases complexity), not "users". I don't see the
problem here. If an SA breaks init.d scripts, it's his/hers doing. With
sysvinit SA gets the choice of what is started when, and as I've seen
with simpleinit, simpleinit itself sorts what its starts when based on
dependices. That sound more as loosing control than gaining it.
Runlevels still operate alphabetically when parallel init is disabled.
If you prefix all the init scripts with 00 or with z-00 you can move
them to wherever you want them.

If the init script is renamed and sorcery doesn't find it installed
again, sorcery will not install them by default during a rebuild.
Exceptions are for REQUIRED init scripts -- and these are only in the
init.d spell which is our specific init.d code.

If you desire, you can use sysvinit yourself and remove init.d and
simpleinit-msb from basesystem. Sorcery will not trample on your init
system outside of those two spells. Just use scribbler to copy the
basesystem spell to a local grimoire and edit it by hand -- you'll never
have to worry about sorcery messing with init scripts again (in theory,
it would be a definite bug otherwise).
Post by Dragan Stanojevic - Nevidljivi
Post by Andrew
Keep in mind that our setup requires very little modification to existing
sysvinit style init scripts. In many cases, ours are actually smaller
due to common code being factored into libraries.
Yeah, that's the second problem. SysVinit executes subshells for any
script, and therefore they are correctly written but in sgml there are a
lot of errors, since you don't use subshells but source other scripts.
We're bash people, we subshell only when needed (typically when we
desire scope enforcement) because forks are more expensive than for
example source or {; }.
Post by Dragan Stanojevic - Nevidljivi
PATH = /sbin:/bin:/usr/sbin:/usr/bin
This is then put in the environment for /etc/init.d/rc, BUT! in that
PATH=/sbin:/bin
also you set the variable RUNLEVELS_DIR
then you source the /etc/sysconfig/init, and reset RUNLEVELS_DIR with
the same value
following that you source the /etc/init.d/sgml_functions and yet again
reset PATH
export PATH=/bin:/usr/bin:/sbin:/usr/sbin
Yeah, that might be cruft laying around from when it was first written.
We could easily clean those up, though. The paths aren't meant to be
edited by the SA, though. If you want to clean it up, we take patch
submissions well. That might make init's PATH editable easier. I might
add that PATH is actually hardcoded in most init systems, even sysvinit
last I checked, so it's really no different if you include that code to
be inside the init system proper.
Post by Dragan Stanojevic - Nevidljivi
Now after that I stopped looking...
I didn't even got to the network part which was the real problem for
which I went to this hunt...
Mostly, I think you ran into an ISO bug and I'll note that we are still
pre-1.0 and thus don't expect people to be running source mage on
mission critical systems. In fact, I will disclaim the use of Source
Mage on mission-critical systems. Debian is for those. Anybody running
an OS on their mission-critical system must check all upgrades in a
redundant test framework anyways as a matter of sane policy. Nobody
does live upgrades to mission critical systems and stays employed for
long. This is especailly true of all source-based systems. The
increase in customization makes complexity too high for that type of
work.
Post by Dragan Stanojevic - Nevidljivi
While I'm at it, I doubt I would put something like simpleinit at my
production server... ever... I don't mind learning it, I don't mind
learning anything, but this is, IMO, a wrong way to do it.
I'm running it on a number of production servers without problems. I am
the QA lead because we're not quite stabilized. We've undergone rapid
development recently and I took the role on to bring sanity to all the
recent infrastructure development. That being said, my preference is to
fix things the way they are rather than to rewrite things -- rewrites
don't tend to stabilize, despite the other gains that can be had.
Post by Dragan Stanojevic - Nevidljivi
IMHO simpleinit was created because sysvinit was not understood at that
time... It is reinventing the wheel in the bad way...
We understand sysvinit quite well. That's why we switched. We didn't
all sit around and twiddle our thumbs wishing we knew how sysvinit
worked. The main thing is: there is very little "order" to sysvinit
across systems. Sysvinit is not really standardized across distros and
there's really no simple init script installation mechanism.

Many upstream authors will even include init scripts designed for each
of the different binary distro vendors despite their use of sysvinit.
So really, there's not much to lose in rolling your own init system.
And if you do understand simpleinit as much as you do sysvinit,
modifying a sysvinit script for simpleinit can take a minute or two.
Post by Dragan Stanojevic - Nevidljivi
That said, the newest Mac OS X - Tiger has created completely new bootup
process called launchd...
Is this a suggestion? If it's as easy as simpleinit and has definite
tangible benefits, we could move to it. I doubt it though.
Post by Dragan Stanojevic - Nevidljivi
- thank for all your replies -
Thanks for the feedback,

Seth
--
Seth Alan Woolley [seth at positivism.org], SPAM/UCE is unauthorized
Key id 00BA3AF3 = 8BE0 A72E A47E A92A 0737 F2FF 7A3F 6D3C 00BA 3AF3
Quality Assurance Team Leader; Security Team Member, Leader Emeritus
Linux so advanced, it may as well be magic http://www.sourcemage.org
Elected Coordinating Committee Member, Secretary, and Finances Chair
Pacific Green Party of Oregon - Peace - http://www.pacificgreens.org
Dragan Stanojevic - Nevidljivi
2005-06-17 17:27:03 UTC
Permalink
Hi,

Thank you Seth for your reply... Unfortunately I don't have enough time
right now to assist you in this distribution, since I have one personal
project to make before it.

But I'll be back in a while.

First impressions about this distribution is that I like the package
management a lot, but I dislike some decisions which are a skeleton of a
Linux system as I see them...

Thank you all again...
N::
Dragan Stanojevic - Nevidljivi
2005-06-18 04:48:06 UTC
Permalink
Hi all,

after reading simpleinit docs/examples, talking with some of you on the
IRC today, and after I browsed a few hours on the web about the need for
the new Linux init process, I can conclude that I was probably wrong.

Most of the not-so-well-known distributions are striving to create the
boot process shorter, and the init scripts more manageable.

Simpleinit is but one of those projects, and although I don't like the
way it is done, if is better than sysvinit I was for.

The problem may lay in the following facts:

- my install process didn't run very well, and all scripts in
/etc/init.d/runlevels/%[123] were not enabled.

- reasons for creating simpleinit were written in a angry and ugly way

- simpleinit is abandoned in favor of LFSinit

- I don't like the script which runs the service and it's "needs" to be
in the same file, but this is the practical approach, I know...

bye,
N::

Loading...