You are not logged in.
Pages: 1
I can't tell which init system Arch uses, is it considered System V or BSD-style? Could someone shed some light about this?
Offline
BSD Style (short and sweet answer
)
Offline
Ok, because when I read the article about init in wikipedia it said that System V looks at /etc/inittab, which is used in Arch, so I get kind of confused.
Offline
Pretty much every distro uses SystemV init, however, there are two styles of initscripts, BSD and SystemV. Arch uses BSD style init scripts with SystemV as the init system. How's that for confusing?
·¬»· i am shadowhand, powered by webfaction
Offline
So which one does it use after all?
:-P
Offline
Both. SysV is the init system. Think of it as the engine. BSD is the init script style. Think of that as the car. Does that analogy work for you?
Offline
That analogy works for me.
Offline
Both. SysV is the init system. Think of it as the engine. BSD is the init script style. Think of that as the car. Does that analogy work for you?
Good anology.
deficite++
·¬»· i am shadowhand, powered by webfaction
Offline
If we are already talking about the init system, what about initng. Is it well known to our devs and has anybody of you tested it already?
Offline
jakob: seen http://bbs.archlinux.org/viewtopic.php?t=25866 already?
1000
Offline
byte: i will remember the search next time before posting *lol*
Offline
Hmm didn't the devs say one time that initng would actually slow down the arch system boot instead of speed it up? Correct me if I am wrong.
Offline
Hmm didn't the devs say one time that initng would actually slow down the arch system boot instead of speed it up? Correct me if I am wrong.
Generally speaking, it probably would. initng and the various other new init systems are pretty much "solving" a problem that doesn't exist in Arch, due to Arch's very simple (and effective) BSD style init system. Because we've removed "run levels" from the init system, and can already background daemons, we have no need for an init replacement.
·¬»· i am shadowhand, powered by webfaction
Offline
Generally speaking, it probably would. initng and the various other new init systems are pretty much "solving" a problem that doesn't exist in Arch, due to Arch's very simple (and effective) BSD style init system. Because we've removed "run levels" from the init system, and can already background daemons, we have no need for an init replacement.
not quite, we still do have runlevels, we just utilise them differently.
0) shutdown
1) single user mode
3) text mode
5) x11 (take a look in /etc/inittab, there's XDM there - we boot to 3 by default)
6) reboot
in most cases, people just chuck their display manager in their DAEMONS line and ignore init 5, but a while back, display managers wouldnt work in the daemon line and you had to inittab them.
James
Offline
not quite, we still do have runlevels, we just utilise them differently.
Ah, right, by runlevels I mean runlevels like most other distros have, rc.2, rc.3, rc.8, etc (like you see in Fedora, Debian, etc) where each runlevel can change which daemons are running. (I always thought this was irritating and pointless, and I was overjoyed when I found out that Arch didn't use runlevels like this.)
·¬»· i am shadowhand, powered by webfaction
Offline
at first i thought this was a bad thing, considering we lacked many runlevels available to other distros.
but after running arch on my desktop/laptop, and putting up ubuntu on the server at work, i don't think i've ever had to use more than 3 runlevels...
1 for reboot (which doesn't really count methinks...)
1 for single root user
1 for regular system
Offline
twiistedkaos wrote:Hmm didn't the devs say one time that initng would actually slow down the arch system boot instead of speed it up? Correct me if I am wrong.
Generally speaking, it probably would. initng and the various other new init systems are pretty much "solving" a problem that doesn't exist in Arch, due to Arch's very simple (and effective) BSD style init system. Because we've removed "run levels" from the init system, and can already background daemons, we have no need for an init replacement.
Also, arch init scripts do no dependancy checking. initng just uses a mess of scripts and calculates the order to run them on boot.
Offline
shadowhand wrote:twiistedkaos wrote:Hmm didn't the devs say one time that initng would actually slow down the arch system boot instead of speed it up? Correct me if I am wrong.
Generally speaking, it probably would. initng and the various other new init systems are pretty much "solving" a problem that doesn't exist in Arch, due to Arch's very simple (and effective) BSD style init system. Because we've removed "run levels" from the init system, and can already background daemons, we have no need for an init replacement.
Also, arch init scripts do no dependancy checking. initng just uses a mess of scripts and calculates the order to run them on boot.
Well, hal does check if dbus is loaded. If not, de hal rc-script will load it for you.
Offline
phrakture wrote:Also, arch init scripts do no dependancy checking. initng just uses a mess of scripts and calculates the order to run them on boot.
Well, hal does check if dbus is loaded. If not, de hal rc-script will load it for you.
i believe portmap and fam have a similar relationship
Offline
if upstart turns out to be working good, is it possible arch might switch? it might not be faster than arch's current use of initscripts but the new way upstart is going is really interesting, imho.
Offline
if upstart turns out to be working good, is it possible arch might switch? it might not be faster than arch's current use of initscripts but the new way upstart is going is really interesting, imho.
I agree, upstart seems to be best of the "new breed" init systems.
·¬»· i am shadowhand, powered by webfaction
Offline
LB06 wrote:phrakture wrote:Also, arch init scripts do no dependancy checking. initng just uses a mess of scripts and calculates the order to run them on boot.
Well, hal does check if dbus is loaded. If not, de hal rc-script will load it for you.
i believe portmap and fam have a similar relationship
On a sidenote: not that I do not find it handy. On the contrary.
In the past situation when Arch didn't have this kind of "dep checking", dbus could be a huge bottleneck in terms of bootup performance. I mean, it wasn't possible to background dbus, because hal requires dbus to be started prior to it. So if dbus would take 5 seconds to start, bootup time would be increased by 5+ seconds.
In the current situation, however, you can just background hal and leave dbus out. Both daemons will now load in background, in seqential order. It basically follows the idea of someone on this forum who requested parenthesis to be made possible in the daemons array. Like ... @(dbus hal) ...
Offline
Pages: 1