[02:28] <sadmac> Keybuk: ping
[12:26] <Keybuk> sadmac: pong
[16:57] <sadmac> Keybuk: I was wanting to ask about your current thoughts for the profiles system
[17:44] <Keybuk> sadmac: sure
[17:51] <sadmac> Keybuk: What does your design for it look lik?
[17:51] <Keybuk> I don't have one
[17:51] <sadmac> s/lik/\0e/
[17:51] <Keybuk> AlexExtreme has been doing one, iirc
[17:51] <Keybuk> the idea being to define profiles in a file
[17:51] <Keybuk> that look something like
[17:51] <Keybuk>   disable apache
[17:51] <Keybuk>   disable squid
[17:51] <Keybuk> or
[17:51] <Keybuk>   disable *
[17:51] <Keybuk>   enable foo
[17:51] <Keybuk>   enable bar
[17:52] <sadmac> hmm
[17:52] <sadmac> I had another idea for it
[17:53] <sadmac> my idea was to add a stanza to the job definitions, one of either "disable unless" or "disable if"
[17:53] <sadmac> followed by a series of flag names.
[17:53] <sadmac> we could then load a list of set flags off the filesystem at boot time.
[17:59] <sadmac> that does get kind of messy if you have flags with large effects, like single user mode.
[18:08] <Keybuk> yeah, that's more in line with the "flags" idea
[18:09] <Keybuk> flags and profiles are two competing ideas for the same functionality
[18:09] <Keybuk> profiles implies that profile is a first-class object which includes or excludes jobs
[18:09] <Keybuk> and maybe that you only have one profile active at one time
[18:09] <Keybuk> flags is that jobs disable/enable themselves in their own configuration depending on which flags are set
[18:09] <Keybuk> with the implication that multiple flags can be set at one time
[18:10] <Keybuk> the profiles idea is better for a sysadmin, since they don't need to edit the job definitions
[18:10] <Keybuk> flags is vaguely better for a distro
[18:22] <sadmac> Keybuk: with enough flags built into the jobs they become logically equivalent
[18:23] <Keybuk> that's somewhat true
[18:23] <Keybuk> one of the other inits has a feature whereby kernel arguments turn on/off jobs
[18:24] <sadmac> thats easy to do. Doesn't even have to be done in code.
[18:25] <sadmac> an early job definition that takes a peak at /proc could do it.
[19:59] <Torne> does upstart work if it's not PID 1?
[19:59] <Torne> as the child of another init?
[20:00] <Keybuk> no
[20:01] <Torne> aw. how come? :)
[20:03] <Keybuk> you can run it as another pid by disabling a couple of its features
[20:03] <Keybuk> (supervision of forking daemons, mostly)
[20:04] <Torne> nothing i run forks anyway :)
[20:04] <Torne> is that compile time?
[20:04] <Keybuk> why do you want to run it under another init?
[20:05] <Torne> i'm switching distribution
[20:05] <Keybuk> it's "edit the source and recompile" time
[20:05] <Keybuk> basically comment out the getpid() check
[20:06] <Torne> ah, right. i'll experiment in a bit then
[20:06] <Torne> thanks. was just wondering if there was an easier way
[20:07] <Keybuk> not really
[20:07] <Keybuk> it's not something I want to support
[20:07] <Keybuk> since people will complain when things don't work because they're not init
[20:08] <Torne> hm. if it's just a matter of turnign a few thigns off and disabling the check, surely that's a reasonable compile time option
[20:08] <Torne> and anyone who builds one with that on will presumably know what they're getting
[20:09] <Keybuk> adding an option means supporting it ;)
[20:09] <Keybuk> "blah doesn't work when not pid 1" ... "so run as pid 1" ... "but there's an option to not run as pid 1"
[20:10] <Torne> i think you're overestimating the chance of that happening, but hey :)
[20:12] <Keybuk> perhaps
[20:12] <Torne> thanks anyway. i'll fiddle with it.