RFC: a new init system for Arch

ekerazha · 2007-04-09 07:19:17

shining wrote:

ekerazha wrote:
hussam wrote:
Why venture into something new when the current init works very well?
Because there's something that works better
It isn't that clear that it works better (maybe in theory, but in practice?),

Also in pratice

and anyway it doesn't even matter. Even if it's better, it's not worth switching, because the current system works perfectly,

Yeah... sometimes it works, sometimes not ( http://bugs.archlinux.org/task/5560 ). However nobody is saying it doesn't work at all, we (I, actually ) are saying it could work better and it is improvable.

and its simplicity is one of arch strength.

Simplicity is given by BSD-styles scripts... however an event-based system would be simpler too.

I'm curious, there are so many distros out there, why don't you use one that uses upstart since you care that much? I already find that most of the linux distribs don't have anything great and particular that justify their existence. But here, we have a particularity, the init system. There are distribs with one init system, other distribs with another, so we can test them, make our choice, and pick the best for our need.
If all distributions made exactly the same choices, then it would be totally retarded to have so many distribs in the first place, wouldn't it?

Well... actually I know these distros that use upstart:
- Ubuntu -> slow (only the boot is pretty fast), not bleeding edge, no rolling release system
- NixOS -> nice but still not mature
- Frugalware (from 0.7) -> bloated (it has things like XGL installed by default), x86_64 release only for k8, no rolling release system, no JFS filesystem support

I think Arch is actually the best distro around... with the exception of the init system because it doesn't use upstart. I'd like to have my own distro but I don't have money to buy a "big" server to manage repositories etc.

Last edited by ekerazha (2007-04-09 07:40:36)

ekerazha · 2007-04-09 07:34:45

broch wrote:

I am not sure what bootchart has to do with removing upstart?

Upstart bootcharts are unuseful if you don't have a bootchart of the same system without upstart You want to compare upstart vs "not upstart", don't you?

You have provided earlier results for Frugalware boot time
http://www.alex-smith.me.uk/?p=59
I don't see anything unusually fast there.

Well... you don't have bootcharts of the same system "without upstart"

You are saying 15s shorter...
This only shows how bad default ubuntu setup is. Maybe this is not clear, but once you got everything out your system there is not much to improve in terms of speed, here are physical limitations. Arch does job very well, changing to upstart will not really improve anything.
15s is not really that much. I was able to cut down suse and ubuntu boot time 40-50s. This seems more effective than 15s.
And if you need 1/2 day to cut 15s off, that is really not feasible approach
I am not ignoring anything, I am asking about experimental proof. Simply post bootchart with upstart if you want. Bootchart is not a way of showing how fast something boots, but it shows how bad is boot config (sleep state for example).

It isn't a "bad setup", it is a "different setup": Ubuntu starts a lot of daemons... maybe Arch *with the same daemons* wouldn't boot so faster
However... you are ignoring that upstart isn't only for speed It is a more intelligent approach to manage the whole system, as I've already explained. Everybody can cut down boot times removing daemons... and if somebody needs every daemon Ubuntu has? You have to compare the init systems using the same configuration and the same machine.

Other advantages seems theoretical rather that anything else. Computer for me is only a tool. Arch once set works. Including the way it starts services. I don't see any real advantages of upstart on my laptop. Servers? well these stay on line as long as posible and nobody is interested in the "inteligent" way of starting different services. Nobody is playing with services on the servers.

"You don't need it" != "Everybody don't need it" != "It isn't better"
However... upstart also has things useful for servers (ex. survive management), plus the others useful mainly-desktop-oriented things.

Last edited by ekerazha (2007-04-09 07:42:50)

ekerazha · 2007-04-09 07:39:15

AlexExtreme wrote:

Well, as you all know probably, I've been messing with Upstart. I'll just point out a few things here: I may seem to be ranting on about the boot time, but boot time is simply an added bonus from switching to a more reliable init system. The main benefits of Upstart are it's ability to order startup based on dependencies rather than just defining a static order, and the ability to respond to events such as hardware being added, removed, etc. These events can then be used, for example, to reliably know when a device in fstab has been added to the system rather than just attempting to mount it no matter what.

I agree.

However, having used Arch, I do think that replacing the init system would be a little stupid in Arch since it's rc.conf system is very well suited to the type of distro that Arch is. I think the Arch initscripts are well designed and they are fairly quick. We're switching to Upstart in Frugalware because it's better suited to the type of distro Frugalware is, a distro for new/intermediate users.
Hope that helps

Well... just make an upstart-compat-bsd and if you want you could also have BSD-styled scripts But there are very few doubts on the better design of an event-based system like upstart.

ekerazha · 2007-04-09 07:40:02

Mr Green wrote:

Arch is one of the fastest booting distros around, if its not broke do not fix it ;-)

This isn't "fixing" this is "improving"

AlexExtreme · 2007-04-09 07:45:13

ekerazha wrote:

- Frugalware (from 0.7) -> bloated (it has things like XGL installed by default), x86_64 release only for k8, no rolling release system, no JFS filesystem support

Huh? Where do you see XGL installed by default? It'll only get installed "by default" if you choose it in the installer, and it's in extra, the extra groups aren't even selected by default. 0.7 x86_64 will be for any x86_64, you get a rolling release if you use -current </off-topic>

ekerazha wrote:

Well... you don't have bootcharts of the same system "without upstart"

http://www.alex-smith.me.uk/files/bootc … svinit.png - Yes, I know it's from a different machine so it's not entirely accurate. I'm going to do another one in a minute.

ekerazha · 2007-04-09 07:55:46

AlexExtreme wrote:

ekerazha wrote:
- Frugalware (from 0.7) -> bloated (it has things like XGL installed by default), x86_64 release only for k8, no rolling release system, no JFS filesystem support
Huh? Where do you see XGL installed by default? It'll only get installed "by default" if you choose it in the installer, and it's in extra, the extra groups aren't even selected by default. 0.7 x86_64 will be for any x86_64, you get a rolling release if you use -current </off-topic>

[OT]
Glad to hear it doesn't install XGL by default (I never installed Frugalware... I only read the release notes and I read "you can enable XGL simply typing this command etc."). Glad to hear 0.7 won't be k8-only for x86_64. I could add it doesn't have a thing like AUR so it has less packages available and it misses some important packages like "PulseAudio".

However... this 0.7 seems like an interesting release, I could try it when It will be released
[/OT]

anykey · 2007-04-09 08:24:42

broch,

we are talking a span from 10 to 20 seconds here at best (though I presume it to be much less). in practice, no one will have to "wait 5 min" for you to boot linux. I am not just a home user, I am a server guy; somehow I feel the need for super-fast-booting laptops is less common. Thanks for trying though.

AlexExtreme · 2007-04-09 08:41:52

http://www.alex-smith.me.uk/files/bootc … vinit2.png - That's the new one I promised from before switching to Upstart. Anyway, I'll stop going on now. I basically think that Arch should choose what's best for them, and that seems to be sysvinit, because you guys have put a lot of work into the current initscripts and rc.conf, and those are one of the things that make Arch what it is.

ekerazha · 2007-04-09 09:00:22

AlexExtreme wrote:

and that seems to be sysvinit, because you guys have put a lot of work into the current initscripts and rc.conf, and those are one of the things that make Arch what it is.

upstart-compat-bsd

bboozzoo · 2007-04-09 09:41:19

I'd better have decent support for suspend/hibernation than ultra fast boot time. Anyway, though the current init layout arch uses is just fine, it's always nice to see some 'research' activity going on. Say you had an init system which could be controlled by DBUS interface, and of course use DBUS also internally.
A scenario 1:
1. user wants to start nfsd
2. dependencies for nfs > portmap & rpc.mountd
3. we have 3 elements to start, begin transaction (in this meaning it's single service start/stop request)
4. start 3 threads, wait for notifications of services becoming available, ie. in nfsd thread wait for rpc.mountd, rpc.mountd waits for portmap
5. main thread waits for notifiction of transaction being finished
6. present user with result for instance by displaying notification in gnome (perhaps by sending a message to some system control daemon in gnome)

Scenario 2:
1. user has policy to provide nfs services over the network
2. network becomes available -> recevei notification from hal that link is down (does hal provides one?)
3. stop services
4. notify the user
Now one can imagine scenario 2 with network going up

I do not really know how upstart works, perhaps it's quite similiar. Doing a mockup in python shouldn't be that hard, then one could go for C/C++ and provide functionality for gnome/kde desktops.
I say it such project could be quite interesting.

BTW, one may provide interface almost identical to one used now, it's not a problem to parse rc.conf or have scripts in rc.d actually interface with new init.

broch · 2007-04-09 13:17:05

@ekerazha
bootchart is useful without comparing "before and after". Otherwise one can use stop watch. Bootchart is a chart with quite detailed info regarding events that take place during boot process.
I asked few times about experimental (not theoretical proof) that "intelligent" unstart will in fact do something useful with services. Except repeating what you read about upstart I have not seen anything proving that upstart will practically better manage services and devices

@anykey
no. There is a difference between 2:30 (latest ubuntu with upstart. Slow boot problems caused by device mapper (see ubuntu forums) or 1:55 suse (1:55) and 15s.
150s vs 15s this is - what - 10x difference?

If one boots box once a 3 month then this does not matter. When you need to boot it several times a day, then boot speed matters too.

Anyway, seems that this discussion goes nowhere

anykey · 2007-04-09 16:16:53

broch,

I didnt mean to throw anyone offcourse here, I was just curious. Thanks for your explanation anyway -- you might have a point there.

ekerazha · 2007-04-09 16:40:53

broch wrote:

@ekerazha
bootchart is useful without comparing "before and after". Otherwise one can use stop watch. Bootchart is a chart with quite detailed info regarding events that take place during boot process.

Exactly... if you want to see the "speed" of a complete boot process, you could also use a clock You can't see the speed delta with and without upstart if you run it on different machines with different configurations.

I asked few times about experimental (not theoretical proof) that "intelligent" unstart will in fact do something useful with services. Except repeating what you read about upstart I have not seen anything proving that upstart will practically better manage services and devices.

Well... practically it does what has been said, what "proves" do you want? Try it yourself: this is the best prove you could have.

broch · 2007-04-09 17:45:57

"Exactly... if you want to see the "speed" of a complete boot process, you could also use a clock wink You can't see the speed delta with and without upstart if you run it on different machines with different configurations. "
what the hell are you talking about? Bootchart shows how something behaves during boot process, you don't need before and after. so be hero and show bootchart with upstart enabled, no need to deinstall, re-install, switch gears. Nothing like this.

Practically there is nothing interesting in upstart judging from your posts.

ekerazha · 2007-04-10 07:23:08

broch wrote:

what the hell are you talking about? Bootchart shows how something behaves during boot process, you don't need before and after. so be hero and show bootchart with upstart enabled, no need to deinstall, re-install, switch gears. Nothing like this.

Well... if you need to measure the "speed", it doesn't matter "how something behaves during boot process". Speed... delta position/delta time, did you remember? Do you want to see if there's a speed improvement with upstart? You have to use the same system with the same configuration with and without upstart. If you want to see if there's a speed improvement with "special shoes", you have to test these shoes on the same person... you can't see if there are improvements comparing "guy A with special shoes" and "guy B without special shoes": you have to use A OR B.

Practically there is nothing interesting in upstart judging from your posts.

This is a problem of yours Instead of "judging", try it yourself.

iphitus · 2007-04-10 09:19:51

People, this thread has gone full circle and is repeating so many times i'm dizzy.

If nobody has any intention to implement upstart or any other alternative, then this thread is just a time sink.

If anybody has any intention to implement it, please do so and *then* post it.

Otherwise, stop flogging the dead horse.

James

ekerazha · 2007-04-10 10:33:10

iphitus wrote:

If anybody has any intention to implement it, please do so and *then* post it.

And if will there be patches to apply to other packages to take advantage of the new event-system?
At that point maybe there should be a different Linux distro (or an update of the needed official Arch packages?). However I hope applications will be updated "upstream".

iphitus · 2007-04-10 12:19:15

ekerazha wrote:

iphitus wrote:
If anybody has any intention to implement it, please do so and *then* post it.
And if will there be patches to apply to other packages to take advantage of the new event-system?

You would just create a PKGBUILD of that application, patched to take advantage of it, and provide it in a seperate repository along with upstart. Patches would only be merged if upstart were chosen and adopted (somewhat unlikely).

Anyway, as said before, discussion has become circular and im dizzy. Someone implement something and back themselves up, or just let it rest.

From what i've seen while using Arch. Discussion often leads nowhere but flames until someone starts implementing and coding.

James

ekerazha · 2007-04-10 15:53:23

iphitus wrote:

ekerazha wrote:
iphitus wrote:
If anybody has any intention to implement it, please do so and *then* post it.
And if will there be patches to apply to other packages to take advantage of the new event-system?
You would just create a PKGBUILD of that application, patched to take advantage of it, and provide it in a seperate repository along with upstart. Patches would only be merged if upstart were chosen and adopted (somewhat unlikely).

Well... so maybe I'll have to find somebody who can mirror my repositories (I've a low traffic limit on my servers): however, as soon as possible I'll begin to work on arch+upstart

Last edited by ekerazha (2007-04-10 15:58:17)

deficite · 2007-04-10 22:31:36

cactus · 2007-04-10 22:42:47

his arm! it moves so fast!

hussam · 2007-04-11 00:39:06

cactus, I think it's because firefox or Gecko rendering engine incorrectly calculates gif aminations frame per second speed so it just plays it at top speed.

Dusty · 2007-04-11 01:04:15

ekerazha wrote:

Well... so maybe I'll have to find somebody who can mirror my repositories (I've a low traffic limit on my servers): however, as soon as possible I'll begin to work on arch+upstart

Its good that you're going to start. Just put it on a personal repo for now, you'll find that the open source community is like magic. Only a few users will be interested at first, which won't tax your servers. As it becomes more popular, somebody somewhere will simply offer to host or mirror it for you. (If it doesn't become popular or you give the project up before somebody else decides to take it on, it will just die, still not taxing your servers). Its really amazing how this works. Try it before further discussion and you'll be impressed with response.

Dusty

deficite · 2007-04-11 21:36:46

cactus wrote:

his arm! it moves so fast!

Well, if you used upstart, it'd move at the proper speed

superstoned · 2007-04-12 09:13:40

ekerazha wrote:

Practically there is nothing interesting in upstart judging from your posts.
This is a problem of yours Instead of "judging", try it yourself.

Well, ekerazha, I must agree with him. What does upstart do? Start services. Just like the current system. Now most of us only have a few services defined in their rc.conf, and most of these won't benefit from upstart at all. It won't be faster, either, as you can (and again, most of us do) use @ to start things in paralel.

Upstart is great for Ubuntu users, as those not just can't use the @, but their distribution starts all services they might ever need (eg cups and even hplip on a system without printer). So upstart will ensure they don't start cups without a printer, and hplip only if the printer is a hp one. Great for them, but arch just doesn't need that, and that's what the ppl here are trying to tell you.

There is nothing wrong with upstart, and in the future, when computers become more and more dynamic, it might have benefits even for arch. But at this moment, there aren't many (if any) practical reasons to use it.

Arch Linux

#76 2007-04-09 07:19:17

Re: RFC: a new init system for Arch

#77 2007-04-09 07:34:45

Re: RFC: a new init system for Arch

#78 2007-04-09 07:39:15

Re: RFC: a new init system for Arch

#79 2007-04-09 07:40:02

Re: RFC: a new init system for Arch

#80 2007-04-09 07:45:13

Re: RFC: a new init system for Arch

#81 2007-04-09 07:55:46

Re: RFC: a new init system for Arch

#82 2007-04-09 08:24:42

Re: RFC: a new init system for Arch

#83 2007-04-09 08:41:52

Re: RFC: a new init system for Arch

#84 2007-04-09 09:00:22

Re: RFC: a new init system for Arch

#85 2007-04-09 09:41:19

Re: RFC: a new init system for Arch

#86 2007-04-09 13:17:05

Re: RFC: a new init system for Arch

#87 2007-04-09 16:16:53

Re: RFC: a new init system for Arch

#88 2007-04-09 16:40:53

Re: RFC: a new init system for Arch

#89 2007-04-09 17:45:57

Re: RFC: a new init system for Arch

#90 2007-04-10 07:23:08

Re: RFC: a new init system for Arch

#91 2007-04-10 09:19:51

Re: RFC: a new init system for Arch

#92 2007-04-10 10:33:10

Re: RFC: a new init system for Arch

#93 2007-04-10 12:19:15

Re: RFC: a new init system for Arch

#94 2007-04-10 15:53:23

Re: RFC: a new init system for Arch

#95 2007-04-10 22:31:36

Re: RFC: a new init system for Arch

#96 2007-04-10 22:42:47

Re: RFC: a new init system for Arch

#97 2007-04-11 00:39:06

Re: RFC: a new init system for Arch

#98 2007-04-11 01:04:15

Re: RFC: a new init system for Arch

#99 2007-04-11 21:36:46

Re: RFC: a new init system for Arch

#100 2007-04-12 09:13:40

Re: RFC: a new init system for Arch

Board footer