| View previous topic :: View next topic |
| Author |
Message |
VeXocide
Tux's lil' helper
Joined: 02 Jul 2004
Posts: 131
Location: Netherlands, the
|
 Posted: Mon Jan 15, 2007 7:34 pm Post subject: einit vs. init-ng |
 |
|
einit vs. init-ng. I have lost track, what are the pro / cons of each, and which would you pick ?
VeXocide
_________________
Read your RSS Feeds: http://www.vexocide.org |
|
| Back to top |
|
 |
thestick
Guru
Joined: 07 Apr 2006
Posts: 531
Location: /dev/urandom
|
| Posted: Mon Jan 15, 2007 8:30 pm Post subject: |
|
|
i`m not trying to flame you but there`s almighty google just waiting to be used.
and , in the worst case , you could try them both to form an opinion ... |
|
| Back to top |
|
|
mdeininger
Veteran
Joined: 15 Jun 2005
Posts: 1740
Location: Emerald Isles, observing Dublin's docklands
|
| Posted: Mon Jan 15, 2007 9:54 pm Post subject: |
|
|
well, not sure if i'm qualified to answer this, since i'm the main dev of einit, but i'll try to throw some things in, seeing your thread didn't get that many answers yet...
initng (afaik):
pros:
* fast
* presumably reliable
* older
* more users
* more native service definitions available
cons:
* doesn't support fallback services (afaik)
* apparently slower than einit
einit:
pros:
* even faster (i think there's some benchmarks by einit+initng users on einit's wiki)
* a lot more modular (will probably be able to use initng .ii and .i files sooner or later)
* could work with gentoo's init scripts (provided someone would finally write an alias table and you're using a patched baselayout  )
* visual (text-based) and aural feedback
cons:
* doesn't support a framebuffer splash (yet)
* needs expat at boot-time (manual copying if you use a separate /usr partition)
neither-good-nor-bad:
* configuration files are in xml (nice to read, imho, but some think xml to be annoying)
not sure if everything i said about initng is 100% correct or still holds true; don't take my word for it: ask an initng user
the main difference with the two projects is the *focus*: einit is trying to be both modular and minimalistic. you can activate and disable all manner of features. the intended target devices for einit are embedded devices, which means very tight timing constraints due to rather limited cpu power (doesn't actually work on non-x86 embedded boards, though, i'm working on getting it back to work on arm)
if there's any specific questions on einit, don't hesitate to ask, i'm around
_________________
"Confident, lazy, cocky, dead." -- Felix Jongleur, Otherland
( Twitter | Blog | GitHub ) |
|
| Back to top |
|
|
VeXocide
Tux's lil' helper
Joined: 02 Jul 2004
Posts: 131
Location: Netherlands, the
|
| Posted: Tue Jan 16, 2007 8:48 am Post subject: |
|
|
Thanks mdeininger, this sumup was pretty much what I was looking for.
The lacking support for the framebuffer splash 'll have to put me on the init-ng side at the moment, but I'll sure have a look at einit later and change my mind (I have a habit of completely changing my mind every month, one month it might me kde, the next fluxbox).
_________________
Read your RSS Feeds: http://www.vexocide.org |
|
| Back to top |
|
|
mdeininger
Veteran
Joined: 15 Jun 2005
Posts: 1740
Location: Emerald Isles, observing Dublin's docklands
|
| Posted: Tue Jan 16, 2007 8:58 am Post subject: |
|
|
heh, that's okay, i'm looking into an evas/edje splash, so you should get enough eye-candy on bootup sooner or later
_________________
"Confident, lazy, cocky, dead." -- Felix Jongleur, Otherland
( Twitter | Blog | GitHub ) |
|
| Back to top |
|
|
ppurka
Advocate
Joined: 26 Dec 2004
Posts: 3256
|
| Posted: Tue Jan 16, 2007 8:30 pm Post subject: |
|
|
| mdeininger wrote: | | heh, that's okay, i'm looking into an evas/edje splash, so you should get enough eye-candy on bootup sooner or later |
Patiently waiting for the wonderful (evas+edje) animated splash screens  |
|
| Back to top |
|
|
rmh3093
Advocate
Joined: 06 Aug 2003
Posts: 2138
Location: Albany, NY
|
| Posted: Tue Jan 16, 2007 9:51 pm Post subject: |
|
|
| VeXocide wrote: | Thanks mdeininger, this sumup was pretty much what I was looking for.
The lacking support for the framebuffer splash 'll have to put me on the init-ng side at the moment, but I'll sure have a look at einit later and change my mind (I have a habit of completely changing my mind every month, one month it might me kde, the next fluxbox). |
whoa hold on... when mdeininger says there is no splash suport that not exactly true... you can still use fbsplash to in silent and verbose mode... the only thing that there is no support for so far is updating the progress bar, yet... that would a simple feature to implement
_________________
Do not meddle in the affairs of wizards, for they are subtle and quick to anger. |
|
| Back to top |
|
|
mdeininger
Veteran
Joined: 15 Jun 2005
Posts: 1740
Location: Emerald Isles, observing Dublin's docklands
|
| Posted: Tue Jan 16, 2007 10:08 pm Post subject: |
|
|
| rmh3093 wrote: | | VeXocide wrote: | Thanks mdeininger, this sumup was pretty much what I was looking for.
The lacking support for the framebuffer splash 'll have to put me on the init-ng side at the moment, but I'll sure have a look at einit later and change my mind (I have a habit of completely changing my mind every month, one month it might me kde, the next fluxbox). |
whoa hold on... when mdeininger says there is no splash suport that not exactly true... you can still use fbsplash to in silent and verbose mode... the only thing that there is no support for so far is updating the progress bar, yet... that would a simple feature to implement |
hmmm, true again, the splash itself works...
ryan: if you can find the commands, i could make a small feedback plugin that could run shell commands to provide feedback...
ppurka: uberpinguin might create a template for me to model after
_________________
"Confident, lazy, cocky, dead." -- Felix Jongleur, Otherland
( Twitter | Blog | GitHub ) |
|
| Back to top |
|
|
rmh3093
Advocate
Joined: 06 Aug 2003
Posts: 2138
Location: Albany, NY
|
| Posted: Tue Jan 16, 2007 11:19 pm Post subject: |
|
|
| mdeininger wrote: | | ryan: if you can find the commands, i could make a small feedback plugin that could run shell commands to provide feedback... |
i believe the fbsplash kernel patch creates a /proc entry that you can write the init progress to... i think its as simple as an number 0-100...
... i will into it further
EDIT: I was wrong, emerge splashutils... then use 'splash_util -p' to set the progress state
_________________
Do not meddle in the affairs of wizards, for they are subtle and quick to anger. |
|
| Back to top |
|
|
mdeininger
Veteran
Joined: 15 Jun 2005
Posts: 1740
Location: Emerald Isles, observing Dublin's docklands
|
| Posted: Wed Jan 17, 2007 12:07 am Post subject: |
|
|
well, that'd be pretty easy then... i just created code that can estimate how far into a modeswitch we are... gonna look into closer details tomorrow, probably going to write a new module that should handle this.
_________________
"Confident, lazy, cocky, dead." -- Felix Jongleur, Otherland
( Twitter | Blog | GitHub ) |
|
| Back to top |
|
|
rmh3093
Advocate
Joined: 06 Aug 2003
Posts: 2138
Location: Albany, NY
|
| Posted: Wed Jan 17, 2007 12:18 am Post subject: |
|
|
| mdeininger wrote: | | well, that'd be pretty easy then... i just created code that can estimate how far into a modeswitch we are... gonna look into closer details tomorrow, probably going to write a new module that should handle this. |
there are a few more options you can play around with also, like switch from verbose to silent mode needs to be handled by einit also... for example, i can boot with the cmdline options "splash=silent,theme:gentoo" and the silent splash will show while the kernel is booting but once einit starts it filps over to the verbose splash, i think you need to read /proc/cmdline to get the specified state and return to it... then einit has to listen to an escape key to switch to verbose mode
_________________
Do not meddle in the affairs of wizards, for they are subtle and quick to anger. |
|
| Back to top |
|
|
mdeininger
Veteran
Joined: 15 Jun 2005
Posts: 1740
Location: Emerald Isles, observing Dublin's docklands
|
| Posted: Wed Jan 17, 2007 12:22 am Post subject: |
|
|
| rmh3093 wrote: | | mdeininger wrote: | | well, that'd be pretty easy then... i just created code that can estimate how far into a modeswitch we are... gonna look into closer details tomorrow, probably going to write a new module that should handle this. |
there are a few more options you can play around with also, like switch from verbose to silent mode needs to be handled by einit also... for example, i can boot with the cmdline options "splash=silent,theme:gentoo" and the silent splash will show while the kernel is booting but once einit starts it filps over to the verbose splash, i think you need to read /proc/cmdline to get the specified state and return to it... then einit has to listen to an escape key to switch to verbose mode |
the escape key's going to be the worst bugger, but we'll need something for that anyway to switch to "debug mode" . those variables you pass to the kernel are passed to init (and einit) as environment variables, so checking for that should be easy.
i'm kinda glad it's no proc interface, that might've gotten messy.
this could get interesting... 
EDIT:
VeXocide: sorry for hijacking your thread like that, but thanks for getting that discussion fired up again
_________________
"Confident, lazy, cocky, dead." -- Felix Jongleur, Otherland
( Twitter | Blog | GitHub ) |
|
| Back to top |
|
|
VeXocide
Tux's lil' helper
Joined: 02 Jul 2004
Posts: 131
Location: Netherlands, the
|
| Posted: Thu Jan 18, 2007 3:29 pm Post subject: |
|
|
Oh well, enjoy my thread
_________________
Read your RSS Feeds: http://www.vexocide.org |
|
| Back to top |
|
|
mirojira
l33t
Joined: 18 Feb 2006
Posts: 685
|
| Posted: Tue Feb 27, 2007 4:04 pm Post subject: |
|
|
| mdeininger wrote: | | if there's any specific questions on einit, don't hesitate to ask, i'm around |
I am initng user and I am satisfied. But reading that einit is faster I would like to test it. My questions:
- Does exist any howto like for initng ? In gentoo-wiki I did not find anything.
- | Quote: | | * even faster (i think there's some benchmarks by einit+initng users on einit's wiki) |
Where is it? |
|
| Back to top |
|
|
buddabrod
Apprentice
Joined: 15 Oct 2006
Posts: 241
Location: Germany
|
| Posted: Tue Feb 27, 2007 4:26 pm Post subject: |
|
|
| Everything is here |
|
| Back to top |
|
|
cruzki
Tux's lil' helper
Joined: 13 Dec 2005
Posts: 137
|
| Posted: Tue Feb 27, 2007 4:29 pm Post subject: |
|
|
I think you might see in the sing of mdeininger
or just wiki , web
EDIT: i'm 3 minutes late :S |
|
| Back to top |
|
|
predatorfreak
l33t
Joined: 13 Jan 2005
Posts: 708
Location: USA, Michigan.
|
| Posted: Tue Feb 27, 2007 5:44 pm Post subject: |
|
|
Both are doing it wrong in my opinion! They both have problems I'd like to avoid, such as large numbers of dependencies at boot (BAAAAD, /sbin/init should be a STATICALLY LINKED FILE, no external dependencies), horribly annoying configuration systems that make almost no sense to me (einit is better on this, I can read XML, but if I format the file wrong, bam I could nuke my boot process, I don't like that), etc.
I sampled them both awhile ago and came to the conclusion neither suited me, so I went with runit. It's even more extensible than einit, I guarantee it, since all the configuration is done in shell scripts. You could just have it replace init and not monitor services or you could have it monitor services, restarting services that go down and such. Minit could work too, but runit is my pick, it's beautifully simple and configurable.
_________________
System: predatorbox
Distro: Arch Linux x86_64
Current projects: blackhole, convmedia and anything else I cook up. |
|
| Back to top |
|
|
rmh3093
Advocate
Joined: 06 Aug 2003
Posts: 2138
Location: Albany, NY
|
| Posted: Tue Feb 27, 2007 6:05 pm Post subject: |
|
|
| predatorfreak wrote: | | Both are doing it wrong in my opinion! They both have problems I'd like to avoid, such as large numbers of dependencies at boot (BAAAAD, /sbin/init should be a STATICALLY LINKED FILE, no external dependencies) |
I made a real half assed effort at getting einit to build statically but it failed so I need to educate myself some on static linking.... finishing that is on my todo list
| predatorfreak wrote: | | horribly annoying configuration systems that make almost no sense to me (einit is better on this, I can read XML, but if I format the file wrong, bam I could nuke my boot process, I don't like that), etc. |
yes, the configuration to einit leaves things to be desired.... but the project is still alpha, we are still trying to figure out a better way to handle the configuration i think, if you have any suggestions let mdeininger or me know
_________________
Do not meddle in the affairs of wizards, for they are subtle and quick to anger. |
|
| Back to top |
|
|
mdeininger
Veteran
Joined: 15 Jun 2005
Posts: 1740
Location: Emerald Isles, observing Dublin's docklands
|
| Posted: Tue Feb 27, 2007 6:16 pm Post subject: |
|
|
| predatorfreak wrote: | | Both are doing it wrong in my opinion! They both have problems I'd like to avoid, such as large numbers of dependencies at boot (BAAAAD, /sbin/init should be a STATICALLY LINKED FILE, no external dependencies) |
einit needs glibc and expat, that's not really much, isn't it?
i'm still looking into something to fix the expat issue, but the bugger won't link statically and i don't want to redistribute all of expat
i chose expat because most systems will have it available these days. i might've settled for flat files to store the configuration, but i decided to go with xml because it's easier to write GUI editors for that.
| predatorfreak wrote: | | , horribly annoying configuration systems that make almost no sense to me (einit is better on this, I can read XML, but if I format the file wrong, bam I could nuke my boot process, I don't like that), etc. |
that's what the flag --wtf to einit is good for: if you format the file wrong, it will tell you where and why it's badly formatted. + it'll try to point out common mistakes that may or may not have occurred when configuring.
besides, you could well use anything else to configure it. if you have any specific suggestions, let me know and i'll add a module to parse that as a source, einit isn't limited to the xml files for configuration.
in fact, with the new gentoo compatibility module, it can at least read gentoo's runlevel descriptions and include the gentoo's init.d scripts in its dependency calculations. with the experimental modules and some rules, you could also use some of the sh-scripts as a configuration source.
| predatorfreak wrote: | | I sampled them both awhile ago and came to the conclusion neither suited me, so I went with runit. It's even more extensible than einit, I guarantee it, since all the configuration is done in shell scripts. |
so, how would you go about dbus integration using shell scripts?
| predatorfreak wrote: | | You could just have it replace init and not monitor services or you could have it monitor services, restarting services that go down and such. |
you could do that with einit as well...
not trying to convince anyone to use einit here, just setting some things straight.
_________________
"Confident, lazy, cocky, dead." -- Felix Jongleur, Otherland
( Twitter | Blog | GitHub ) |
|
| Back to top |
|
|
predatorfreak
l33t
Joined: 13 Jan 2005
Posts: 708
Location: USA, Michigan.
|
| Posted: Tue Feb 27, 2007 6:32 pm Post subject: |
|
|
| mdeininger wrote: | | predatorfreak wrote: | | Both are doing it wrong in my opinion! They both have problems I'd like to avoid, such as large numbers of dependencies at boot (BAAAAD, /sbin/init should be a STATICALLY LINKED FILE, no external dependencies) |
einit needs glibc and expat, that's not really much, isn't it?
i'm still looking into something to fix the expat issue, but the bugger won't link statically and i don't want to redistribute all of expat ;)
i chose expat because most systems will have it available these days. i might've settled for flat files to store the configuration, but i decided to go with xml because it's easier to write GUI editors for that.
| predatorfreak wrote: | | , horribly annoying configuration systems that make almost no sense to me (einit is better on this, I can read XML, but if I format the file wrong, bam I could nuke my boot process, I don't like that), etc. |
that's what the flag --wtf to einit is good for: if you format the file wrong, it will tell you where and why it's badly formatted. + it'll try to point out common mistakes that may or may not have occurred when configuring.
besides, you could well use anything else to configure it. if you have any specific suggestions, let me know and i'll add a module to parse that as a source, einit isn't limited to the xml files for configuration.
in fact, with the new gentoo compatibility module, it can at least read gentoo's runlevel descriptions and include the gentoo's init.d scripts in its dependency calculations. with the experimental modules and some rules, you could also use some of the sh-scripts as a configuration source.
| predatorfreak wrote: | | I sampled them both awhile ago and came to the conclusion neither suited me, so I went with runit. It's even more extensible than einit, I guarantee it, since all the configuration is done in shell scripts. |
so, how would you go about dbus integration using shell scripts? ;)
| predatorfreak wrote: | | You could just have it replace init and not monitor services or you could have it monitor services, restarting services that go down and such. |
you could do that with einit as well...
not trying to convince anyone to use einit here, just setting some things straight. |
I'll go over this one at a time.
1. Expat has a history of breaking ABI compatibility between versions, this is VERY bad for an init system, if an ABI change occurs and someone forgets to rebuild einit, they can't boot without reverting to standard init or a shell.
2. Okay, not as big of a deal as the above, but personally I like a rather idiot proof configuration system with init, mostly to protect me from my own stupidity.
3. I don't, I don't see the NEED for D-Bus integration at boot. The boot process should be kept simple, streamlined and minimalist. The more complexity we add to it, the harder it becomes to tweak it and mangle it to your own taste.
I know a lot of people don't CARE about being able to mangle their init scripts or boot system, but I do, I like being able to dictate how it works, telling it "No, you will do this before that". In fact I cannot even use Arch's standard shutdown script... I had to modify it just for it to be usable for me and I'm already working on rewriting the whole thing in a minimalist fashion, removing excess and simplifying it, I'll be providing my own init-scripts for basic tasks like bringing up the network and such and handling the rest with runit.
4. I'm fully aware that einit can be used as a simple init replacement, I just wanted to state that runit can be used in such a way aswell.
Edit: I'm not TRYING to start a flamewar, I'm saying WHY I don't use either and prefer runit.
_________________
System: predatorbox
Distro: Arch Linux x86_64
Current projects: blackhole, convmedia and anything else I cook up. |
|
| Back to top |
|
|
no4b
Bodhisattva
Joined: 18 Jan 2004
Posts: 774
Location: Tarnów, Poland
|
| Posted: Tue Feb 27, 2007 7:11 pm Post subject: |
|
|
| Quote: | | I don't, I don't see the NEED for D-Bus integration at boot. |
I agree.
BTW. if you want to matter on desktop market you have to support more apps. Init-system that can't start 90% of apps without writing "rules/modules/whatever" is totally useless for an average user.
_________________
GTK2/GNOME - The weakest link! |
|
| Back to top |
|
|
mdeininger
Veteran
Joined: 15 Jun 2005
Posts: 1740
Location: Emerald Isles, observing Dublin's docklands
|
| Posted: Tue Feb 27, 2007 7:43 pm Post subject: |
|
|
| predatorfreak wrote: | | 1. Expat has a history of breaking ABI compatibility between versions, this is VERY bad for an init system, if an ABI change occurs and someone forgets to rebuild einit, they can't boot without reverting to standard init or a shell. |
as i said, i'm still looking into some way to get this statically linked. i'm not happy about that part either, but there's not much choice in low-profile xml parsers.
| predatorfreak wrote: | | 2. Okay, not as big of a deal as the above, but personally I like a rather idiot proof configuration system with init, mostly to protect me from my own stupidity. |
it's still alpha, it's not like i want it to stay that way.
in fact, i want the thing to do most of the configuration on its own by default, while having an option to optimise and customise as much as a user could possible want, if he does want to do so. it's just that i have to get it working stable before i can do that.
| predatorfreak wrote: | | 3. I don't, I don't see the NEED for D-Bus integration at boot. The boot process should be kept simple, streamlined and minimalist. The more complexity we add to it, the harder it becomes to tweak it and mangle it to your own taste. |
i simply used dbus as an example for anything else that could be more complex and is pretty much impossible using shell scripts alone. i could've also said "fancy framebuffer library X for fancy bootup screens" (evas comes to mind). or i could've said "fancy network boot coordination over network link". i've just been trying to state that i doubt runit is really that more extensible, more likely both are au-par. they're just different.
| predatorfreak wrote: | | I know a lot of people don't CARE about being able to mangle their init scripts or boot system, but I do, I like being able to dictate how it works, telling it "No, you will do this before that". In fact I cannot even use Arch's standard shutdown script... I had to modify it just for it to be usable for me and I'm already working on rewriting the whole thing in a minimalist fashion, removing excess and simplifying it, I'll be providing my own init-scripts for basic tasks like bringing up the network and such and handling the rest with runit. |
so, then what's to stop you from writing a script and telling either einit or initng to run one script before the other?
| predatorfreak wrote: | | 4. I'm fully aware that einit can be used as a simple init replacement, I just wanted to state that runit can be used in such a way aswell. |
i rather meant the other thing: you can use any init you like and use einit to keep track of daemons and things after that.
| predatorfreak wrote: | | Edit: I'm not TRYING to start a flamewar, I'm saying WHY I don't use either and prefer runit. |
sure, and i'm just trying to point out why i disagree at parts and why i don't.
you see. actually einit's target environment isn't desktops anyway. that it works pretty fast on desktops is more of a really great side-effect. but since it's working so very nice on desktops, i'm extending here first.
| no4b wrote: | | BTW. if you want to matter on desktop market you have to support more apps. Init-system that can't start 90% of apps without writing "rules/modules/whatever" is totally useless for an average user. |
--> gentoo compatibility module.
can handle anything gentoo's baselayout can handle. it's a pretty simple install too, considering einit is alpha: unmask it, emerge it, be happy with all of gentoo's init.d scripts.
by saying it couldn't start 90% of apps without writing modules, you're implying gentoo's baselayout couldn't either, and to that i kind of have to disagree
(and for non-gentoo users there's compatibility for regular init.d scripts for quite some time as well. it's just in a different pack of modules.)
i guess "init" is going the same way wms were for years... diversity ftw.
_________________
"Confident, lazy, cocky, dead." -- Felix Jongleur, Otherland
( Twitter | Blog | GitHub ) |
|
| Back to top |
|
|
predatorfreak
l33t
Joined: 13 Jan 2005
Posts: 708
Location: USA, Michigan.
|
| Posted: Tue Feb 27, 2007 10:42 pm Post subject: |
|
|
| mdeininger wrote: | | predatorfreak wrote: | | 3. I don't, I don't see the NEED for D-Bus integration at boot. The boot process should be kept simple, streamlined and minimalist. The more complexity we add to it, the harder it becomes to tweak it and mangle it to your own taste. |
i simply used dbus as an example for anything else that could be more complex and is pretty much impossible using shell scripts alone. i could've also said "fancy framebuffer library X for fancy bootup screens" (evas comes to mind). or i could've said "fancy network boot coordination over network link". i've just been trying to state that i doubt runit is really that more extensible, more likely both are au-par. they're just different.. |
You can setup an external script to handle it, start an application in your init scripts to handle it, etc. The point of runit is to be minimalist and simple, the fancy things are handled by an external application. The init executable it's self is called, runit starts your main boot script for that run-level (single-user runlevel), then the script can setup any fancy crap by calling external stuff, then it passes it to the second runlevel (multiuser), where you start the services monitored by runit and then the tty's.
To be honest you just seem to like to complain about me pointing out that I like something minimalist, simple and effective, which I can configure to my hearts content without resorting to using XML. Both einit and init-ng ARE more complex than runit, compare the code. You sacrifice for the fancy features of both by producing larger executables and binaries. I prefer minimalist, simple things that do as I instruct with as little fluff as possible, I do NOT require XML configuration, I want it to run my standard scripts per runlevel and be done with it! The rest I handle within my init-scripts, as I believe THAT is the proper place for such work to be done, NOT the init system it's self.
_________________
System: predatorbox
Distro: Arch Linux x86_64
Current projects: blackhole, convmedia and anything else I cook up. |
|
| Back to top |
|
|
Naib
Watchman
Joined: 21 May 2004
Posts: 6051
Location: Removed by Neddy
|
| Posted: Tue Feb 27, 2007 11:35 pm Post subject: |
|
|
ok a couple of question to distinguish them both
1) How hard/involved is setting up either einit or initng
2) I have tried initng a couple of times (and loved the boot-speed!!!).
I stopped using it the 1st time when a schedualed fsck occured and basically the screen just flooded with the progress (ie the increasing progress bar wasn't updates in-line, a new line was printed every increment!!!! annoying. Bug post after bug post ignored). I switched away.
I then tried again a few months later and it was nice to see that the fsck bug wasn't fixed  but what really stopped me was wifi was a real hack to get working.
So how easy is wifi (kinda related to #1) and how does einit cope with fsck at boottime
_________________
| Quote: | | Removed by Chiitoo |
|
|
| Back to top |
|
|
mdeininger
Veteran
Joined: 15 Jun 2005
Posts: 1740
Location: Emerald Isles, observing Dublin's docklands
|
| Posted: Tue Feb 27, 2007 11:46 pm Post subject: |
|
|
sorry, that post got longer than i hand intended... no need to read much but the last paragraph.
| predatorfreak wrote: | | You can setup an external script to handle it, start an application in your init scripts to handle it, etc. The point of runit is to be minimalist and simple, the fancy things are handled by an external application. The init executable it's self is called, runit starts your main boot script for that run-level (single-user runlevel), then the script can setup any fancy crap by calling external stuff, then it passes it to the second runlevel (multiuser), where you start the services monitored by runit and then the tty's. |
i might be mistaken, but isn't that pretty much exactly the way sysvinit does things?
i mean, start up, call script, let script do things...
| predatorfreak wrote: | | To be honest you just seem to like to complain about me pointing out that I like something minimalist, simple and effective, which I can configure to my hearts content without resorting to using XML. Both einit and init-ng ARE more complex than runit, compare the code. You sacrifice for the fancy features of both by producing larger executables and binaries. I prefer minimalist, simple things that do as I instruct with as little fluff as possible, I do NOT require XML configuration, I want it to run my standard scripts per runlevel and be done with it! The rest I handle within my init-scripts, as I believe THAT is the proper place for such work to be done, NOT the init system it's self. |
i don't want to complain about anything. yes einit is more complex than runit. einit is also more complex than sysvinit. it might be more complex than initng, that i don't know.
the core most definitely is more complex. it provides events, can parse xml configuration files in flexible ways, use regular expressions for some things, load .so files to provide the actual features and it does complex dependency calculations. however, there's no actual functionality in the core. the core itself only provides a very minimal subset of what is expected to be useful. the core itself can't even run a shell, because not all environments are expected to have a shell available.
all the fancy bits and features are provided using modules. you want the feature, you load the module. you don't want the fancy shiny bitsy feature, you don't load it. of course, by default einit is greedy and will load all modules it can find, as most users like that. i'm a minimalist myself, i can relate to not wanting that (hey, i run e17 with only keyboard commands; no bars, no icons, no pager. screw that, i don't use anything but alt+esc anyway).
i'm just trying to say that "minimalist" is something that is hard to argue with, especially with something like that. you see, you may say that it's more minimalistic if your init is only used to run a shell script.
that's certainly correct, but what is the shell doing? it parses rather complex files and calls binaries.
you're saying runit was smaller than einit and less complex. that's correct, but what about bash?
you're saying it has smaller binaries... that's correct, runits binary is smaller. but runit needs a shell, and the shell needs binaries to do anything useful...
einit could do without a shell and those binaries...
example: setting the hostname.
with runit, it's trivial:
runit -> call shell to parse shell script -> hostname whatever
thus we need... runit, /bin/sh, and /bin/hostname. that's on my box: 17k(runit) + 744k(bash) + 12k(hostname)
with einit it's not that much harder either:
write down hostname into configuration file
einit+expat -> parse xml file -> find hostname service and enable it (which will call the C function hostname())
thus in this case we need... einit+expat and einit-hostname.so... that's 93k(einit) + 139k(expat) + 9k(einit-hostname.so)
so now, einit has larger binaries... how?
yes, on a regular desktop system it will occupy more space (since a shell, basic utilities and einit are installed), but what about something like a pda, a pvr or a radio? who said you needed shell scripts on that thing in general... might as well write everything in C and not install a shell right away.
so, just trying to say that "minimalist" and "binary size" are very subjective at best. and i'm not trying to flame you or anything, just trying to get that across. if you like runit, that's cool. heck, i wouldn't recommend anyone use einit on a mission critical box right now myself (seeing as it is still alpha).
again, i'm _not trying to start a flame war_ either, and i'm _not complaining about things_. i'd just like to point out that what's "minimal" depends on the context. that, and adding fancy features does _not_ make einit itself any bigger, nor does it influence its runtime complexity.
P.S.: you've gotten me some nice ideas actually, i think i will... outsource... some of the core functionality into modules. like, parsing the configuration files and doing dependency calculations
_________________
"Confident, lazy, cocky, dead." -- Felix Jongleur, Otherland
( Twitter | Blog | GitHub ) |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Unsupported Software
