[dev] a suckless init system?

[Calvin Morrison]

Hey all,

Recently on the Arch mailing list there has been much discussion of
different init systems. I was just wondering which init system, y'all
approve of. SysV or OpenRC pretty suckless and unix-y to me.

What do you think?

Calvin

[Hugues Moretto-Viry]

That's a really good question!
Maybe, I already know what suckless thinks about SystemD.

--
Envoyé d'Archlinux

[Kurt H Maier]

Both are crap. openrc in particular is some serious amateur-hour
garbage. Crux's init has good bones, but lacks finishing. More distros
should focus on using init to bring up the system and then leave
userspace daemons to daemontools or such.

[Calvin Morrison]

maybe I will work on a new init system :p

[hiro]

first initiate sanity in your brain

[Sam Watkins]

There are dependency based init systems, should use mk for it.

net: 1
inetd: net
2: getty inetd

mk 2 # go to runlevel 2
# inetd crashes
mk 2 # bring it back to life

It would need some sort of procfs view with process names, where unlink
sends a term signal, and some extra features for mk, to remove
objects in various ways. That could be done in a separate program.

mk -rm inetd # stop inetd (and anything that depends on it)
mk -rmdeps 1 # go back to just runlevel 1

Ok, now I should install some sanity into my brain.

I wonder if people get kicked off the list for posting stuff like this?

Sam

[pancake]

Using mk takes sense as long as init scripts are a dependency based system. Please go on. That looks fun

Looks like doing suckless software implies surviving to troll comments.

Your software will be suckless when trolls stop throwing rocks at it.

[Jens Staal]

There is a mk-based init system that was initially presented here:

http://9fans.net/archive/2009/10/375

perhaps a start?

[David Tweed]

I'll just note that, regardless of code quality, etc, there's the
question of what the end-user usability goals for an init system
should be.

Is it just to bring up the system, or is it to bring up the system
fast enough to use in an "quickbooting" environment (<5s off an SSD)?
I'm very inclined towards the later, but that's partly because I use
net-tops in impromptu settings (and it seems like resume from
hibernate (due to suspend-to-ram for 8 hours eating too much battery)
is slower than a reboot from scratch).

--
cheers, dave tweed__________________________
high-performance computing and machine vision expert: david...@gmail.com
"while having code so boring anyone can maintain it, use Python." --
attempted insult seen on slashdot

[Kurt H Maier]

On Thu, Aug 16, 2012 at 12:00:03PM +0100, David Tweed wrote:
> I'll just note that, regardless of code quality, etc, there's the
> question of what the end-user usability goals for an init system
> should be.

No. An "end user" should not even be aware init exists. The people an
init system has to impress are systems administrators.

[Robert Ransom]

On 8/14/12, Kurt H Maier <khm-su...@intma.in> wrote:
> More distros
> should focus on using init to bring up the system and then leave
> userspace daemons to daemontools or such.

Does Plan 9 need a service supervision service (like daemontools on Unixoids)?

If it does need one, what should it look like?


Robert Ransom

[David Tweed]

Well, yes-and-no. The end user (who in the case of many linux desktops
and laptops is also the sys admin) may not be aware of how things are
structured "under the hood", but they can perceive "laptop X spends a
lot of time doing stuff when I turn it on, while laptop Y is usable
almost instantly". The only reason I mentioned it (I otherwise try and
stay out of "religiously" tinted discussions was that there was
discussion about how to do it but no mention of what the important
"externally visible" (if you don't like "end-user") goals should be.

[Kurt H Maier]

On Thu, Aug 16, 2012 at 02:39:43PM +0100, David Tweed wrote:
> Well, yes-and-no. The end user (who in the case of many linux desktops
> and laptops is also the sys admin) may not be aware of how things are
> structured "under the hood", but they can perceive "laptop X spends a
> lot of time doing stuff when I turn it on, while laptop Y is usable
> almost instantly". The only reason I mentioned it (I otherwise try and
> stay out of "religiously" tinted discussions was that there was
> discussion about how to do it but no mention of what the important
> "externally visible" (if you don't like "end-user") goals should be.

For init systems, speed is a natural consequence of correct design.
Only an incompetent would have to explicitly list it as a design goal.

[David Tweed]

Maybe I have no claim to real competence..., but I always tend to find
that if the software design goals aren't pretty concrete listing even
the "obvious" things then either (a) someone else will consider
something I find obvious to be a "why do you want that" or (b) someone
else's obvious is my "why on earth would you want that".

Anyway, here's a comment that I remembered reading the first time round

http://lwn.net/Articles/300955/

Note that the point isn't whether fast boot is an important enough
goal to impact in other trade-off's (I think it is, others may think
it's less important than simplicity), as much as that it's something
where it's better to come to an explicit design goal decision.

[Jukka Ruohonen]

On Tue, Aug 14, 2012 at 01:50:53PM -0400, Kurt H Maier wrote:
> Both are crap. openrc in particular is some serious amateur-hour

I love it when suckless talks about amateur hours.

Maybe it is time to rewrite cat again?

- Jukka

[Kurt H Maier]

On Sat, Aug 18, 2012 at 12:11:47PM +0300, Jukka Ruohonen wrote:
>
> I love it when suckless talks about amateur hours.
>
> Maybe it is time to rewrite cat again?
>

Are you saying there is no value to be gained in simple implementations,
are you saying that there are problems you wish fixed in sbase cat and
that you have a patch, or are you just being a whining loser because
I wasn't impressed with some awful init system?

Just trying to ascertain if you have ever sent an email worth reading.

[Anselm R Garbe]

init should just execute /etc/rc and leave it up to the script.

Cheers,
Anselm

[pancake]

Executables in etc? :)

[s...@9front.org]

> Executables in etc? :)

Aside from the historical precedent, even OpenBSD runs scripts located in /etc.

-sl

[Calvin Morrison]

I don't really care where my executables are as long as my paths are
setup correctly. Which they are.

[Anselm R Garbe]

On 30 August 2012 20:37, pancake <pan...@youterm.com> wrote:
> Executables in etc? :)

I don't mind breaking the rules and moving it to /bin/, but I need the
system running first to get a feel for it.