Re: [dev] a suckless init system?

2012-08-30 Thread Anselm R Garbe
On 14 August 2012 19:36, Calvin Morrison mutanttur...@gmail.com wrote: 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?

Re: [dev] a suckless init system?

2012-08-30 Thread pancake
Executables in etc? :) On Aug 30, 2012, at 20:26, Anselm R Garbe garb...@gmail.com wrote: On 14 August 2012 19:36, Calvin Morrison mutanttur...@gmail.com wrote: Recently on the Arch mailing list there has been much discussion of different init systems. I was just wondering which init system,

Re: [dev] a suckless init system?

2012-08-30 Thread sl
Executables in etc? :) Aside from the historical precedent, even OpenBSD runs scripts located in /etc. -sl

Re: [dev] a suckless init system?

2012-08-30 Thread Calvin Morrison
On 30 August 2012 14:40, s...@9front.org wrote: Executables in etc? :) Aside from the historical precedent, even OpenBSD runs scripts located in /etc. -sl I don't really care where my executables are as long as my paths are setup correctly. Which they are.

Re: [dev] a suckless init system?

2012-08-30 Thread Anselm R Garbe
On 30 August 2012 20:37, pancake panc...@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.

Re: [dev] a suckless init system?

2012-08-18 Thread 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

Re: [dev] a suckless init system?

2012-08-16 Thread Jens Staal
torsdagen den 16 augusti 2012 06.59.45 skrev 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

Re: [dev] a suckless init system?

2012-08-16 Thread 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

Re: [dev] a suckless init system?

2012-08-16 Thread 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

Re: [dev] a suckless init system?

2012-08-16 Thread Robert Ransom
On 8/14/12, Kurt H Maier khm-suckl...@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

Re: [dev] a suckless init system?

2012-08-16 Thread 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

Re: [dev] a suckless init system?

2012-08-16 Thread 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

Re: [dev] a suckless init system?

2012-08-16 Thread David Tweed
On Thu, Aug 16, 2012 at 3:19 PM, Kurt H Maier khm-suckl...@intma.in wrote: 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

Re: [dev] a suckless init system?

2012-08-15 Thread 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. On Aug 15, 2012, at 6:02, Sam Watkins

[dev] a suckless init system?

2012-08-14 Thread 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

Re: [dev] a suckless init system?

2012-08-14 Thread Hugues Moretto-Viry
That's a really good question! Maybe, I already know what suckless thinks about SystemD. -- Envoyé d'Archlinux

Re: [dev] a suckless init system?

2012-08-14 Thread Kurt H Maier
On Tue, Aug 14, 2012 at 01:36:55PM -0400, Calvin Morrison wrote: 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

Re: [dev] a suckless init system?

2012-08-14 Thread Calvin Morrison
On 14 August 2012 13:50, Kurt H Maier khm-suckl...@intma.in wrote: On Tue, Aug 14, 2012 at 01:36:55PM -0400, Calvin Morrison wrote: 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.

Re: [dev] a suckless init system?

2012-08-14 Thread hiro
first initiate sanity in your brain

Re: [dev] a suckless init system?

2012-08-14 Thread 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