...and yet another init replacement

Romashka · 2006-10-09 16:06:27

There were few topics about new inits already.
InitNG, Runit, Upstart, ..., and now FwInit is in development.

Personally I'm satisfied with BSD-style init, like in Arch. All these new init projects aim to resolve problems with SysV init but IMHO they make things even more complex.

PJ · 2006-10-09 16:28:58

And another one...
http://fedoraproject.org/wiki/FCNewInit

Romashka · 2006-10-09 16:31:09

Oh, missed that one. There are few others too, don't remember their names now.

phrakture · 2006-10-09 16:32:35

Here's my init system, called "solve-an-artifical-problem" .... link to come soon

twiistedkaos · 2006-10-09 16:51:26

Lmao, I like the BSD style initing system also. Seems simple enough to me. Back in my fedora days I have tried Initng and crap like that but I wasn't personally pleased with any of them that I tried.

shadowhand · 2006-10-09 16:59:13

Personally, I've looked at a lot of the new init systems, and Upstart seems to be the most ambitious, yet the most well-rounded and thought out.

bboozzoo · 2006-10-09 18:43:04

perhaps we should set up our own init system.. like there wouldn't be enough

Romashka · 2006-10-10 09:51:03

OMG, here is another one. :shock:

deficite · 2006-10-12 14:00:11

This is really getting ridiculous. On one hand, it's nice that there are a lot of people excited about coming up with better ways to do things. Ideas are flying around everywhere. On the other hand, this is going to make the Linux world even more confusing. Imagine a world in which every distro has its own init system. It's already like that to a degree, but imagine every distro having an init system with NOTHING in common with anybody else's. The only new init systems that I've read up on that I have liked have been Upstart and InitNG (I tried InitNG on Ubuntu and liked it. It sped up my boot process by huge margins).

edit: That Mudur thing is quite interesting now that I've read up on it. I've always like Python-based things (which is why I use SCons)

iphitus · 2006-10-12 23:37:46

deficite wrote:

This is really getting ridiculous. On one hand, it's nice that there are a lot of people excited about coming up with better ways to do things. Ideas are flying around everywhere. On the other hand, this is going to make the Linux world even more confusing. Imagine a world in which every distro has its own init system.

Realistically, they already do. Almost every distro has their own implementation and they all work differently

It's already like that to a degree, but imagine every distro having an init system with NOTHING in common with anybody else's. The only new init systems that I've read up on that I have liked have been Upstart and InitNG (I tried InitNG on Ubuntu and liked it. It sped up my boot process by huge margins).

You'll find that initng will make negligable speed benefits/losses on arch. The reason why it sped things up on ubuntu, is it resolved slowdowns that ubuntu suffers and problems in their scripts. On arch.... there's none of those problems that it will resolve.

edit: That Mudur thing is quite interesting now that I've read up on it. I've always like Python-based things (which is why I use SCons)

I read through an article about that, but it seemed very tied into the distro, and was constantly referring to other parts, under silly obscure names.

James

phrakture · 2006-10-13 15:45:40

iphitus wrote:

You'll find that initng will make negligable speed benefits/losses on arch. The reason why it sped things up on ubuntu, is it resolved slowdowns that ubuntu suffers and problems in their scripts. On arch.... there's none of those problems that it will resolve.

This is why I repeatedly claim that new init systems are "solving an artificial problem". It's trying to fix something by treating symptoms.... "Oh you're losing your hair because you have cancer? These pills will help your hair grow back!"

twiistedkaos · 2006-10-13 16:30:16

phrakture wrote:

iphitus wrote:
You'll find that initng will make negligable speed benefits/losses on arch. The reason why it sped things up on ubuntu, is it resolved slowdowns that ubuntu suffers and problems in their scripts. On arch.... there's none of those problems that it will resolve.
This is why I repeatedly claim that new init systems are "solving an artificial problem". It's trying to fix something by treating symptoms.... "Oh you're losing your hair because you have cancer? These pills will help your hair grow back!"

Lol, this is so true. But I do apploud the people who are trying to find new ways to do different things. But it is becomming quite confusing with all the new init systems comming out.

cromo · 2006-10-27 11:49:43

But what about upstart? I'd say the idea is quite different: it aims to simplyfy the things, not make them more complex. And it addas some functionality, too. I personally like the idea of the daemons beeing able to start automatically when I connect some device, e.g. cups to start when I connect my usb printer. acpid events + cron integration with init scripts really makes lots of sense for me.

phrakture · 2006-10-27 15:20:33

cromo wrote:

I personally like the idea of the daemons beeing able to start automatically when I connect some device

udev can do this in one line:

BUS=="usb", SYSFS{serial}=="my printer serial number", RUN+="/etc/rc.d/cups start"

Of course, more complex would be to maintain a count of _all printers_, if it's 0, run 'start' increment/decrement, and when we get down to 0 again, 'stop' it.

Romashka · 2006-10-27 17:25:53

You mean

SUBSYSTEMS=="usb", ATTRS{serial}=="my printer serial number", RUN+="/etc/rc.d/cups start"

of course.

phrakture · 2006-10-27 18:05:27

Romashka wrote:

You mean

SUBSYSTEMS=="usb", ATTRS{serial}=="my printer serial number", RUN+="/etc/rc.d/cups start"

of course.

I'm guessing this means udev syntax changed since I last wrote a rule 8)

Romashka · 2006-10-27 18:11:29

phrakture wrote:

Romashka wrote:
You mean
SUBSYSTEMS=="usb", ATTRS{serial}=="my printer serial number", RUN+="/etc/rc.d/cups start"
of course.
I'm guessing this means udev syntax changed since I last wrote a rule 8)

Yep, /etc/udev/readme-udev-arch.txt and there were two news at main page.

chrismortimore · 2006-10-27 18:15:59

Out of curiosity, what exactly is wrong with sysvinit? I've never had trouble from it myself...

Romashka · 2006-10-27 18:37:42

chrismortimore wrote:

Out of curiosity, what exactly is wrong with sysvinit? I've never had trouble from it myself...

Me too.
Some of Use Cases for upstart make sense, but there are other solutions for these.

For me, Arch's init system is the best.

chrismortimore · 2006-10-27 19:28:21

Romashka wrote:

Some of Use Cases for upstart make sense, but there are other solutions for these.

That was a dull read... And very cheesy with the whole "Joe is a system administrator...". All seems a little Blind Date to me.

jnengland77 · 2006-10-27 22:34:57

Here is another one
I tend to like this one in comparison to upstart. I this project is cool cause it's C/C++ program plus xml(I find it easy to read) and seems to be partial event-based.

The current *BSD-init is fine tho. After einit matures a bit I might try it.

~jnengland77

cactus · 2006-10-27 23:38:02

Cactus hates it when application config files use XML...
film at 11.

Arch Linux

#1 2006-10-09 16:06:27

...and yet another init replacement

#2 2006-10-09 16:28:58

Re: ...and yet another init replacement

#3 2006-10-09 16:31:09

Re: ...and yet another init replacement

#4 2006-10-09 16:32:35

Re: ...and yet another init replacement

#5 2006-10-09 16:51:26

Re: ...and yet another init replacement

#6 2006-10-09 16:59:13

Re: ...and yet another init replacement

#7 2006-10-09 18:43:04

Re: ...and yet another init replacement

#8 2006-10-10 09:51:03

Re: ...and yet another init replacement

#9 2006-10-12 14:00:11

Re: ...and yet another init replacement

#10 2006-10-12 23:37:46

Re: ...and yet another init replacement

#11 2006-10-13 15:45:40

Re: ...and yet another init replacement

#12 2006-10-13 16:30:16

Re: ...and yet another init replacement

#13 2006-10-27 11:49:43

Re: ...and yet another init replacement

#14 2006-10-27 15:20:33

Re: ...and yet another init replacement

#15 2006-10-27 17:25:53

Re: ...and yet another init replacement

#16 2006-10-27 18:05:27

Re: ...and yet another init replacement

#17 2006-10-27 18:11:29

Re: ...and yet another init replacement

#18 2006-10-27 18:15:59

Re: ...and yet another init replacement

#19 2006-10-27 18:37:42

Re: ...and yet another init replacement

#20 2006-10-27 19:28:21

Re: ...and yet another init replacement

#21 2006-10-27 22:34:57

Re: ...and yet another init replacement

#22 2006-10-27 23:38:02

Re: ...and yet another init replacement

Board footer