[00:18] huh [00:18] I just realised how something combines nicely to make "manual" mode easy [00:19] echo manual >> /etc/init-override/something.conf ;-) [00:37] wow [00:37] so, err [00:37] really [00:37] ion: we *really* don't need udev [00:47] Nice [01:40] * Keybuk blames Caesar [02:38] You what? [02:38] Oh that [02:38] /etc/default for evar! [02:38] Hmm, /etc/init-override, do you really need to take another directory in /etc for this? [02:39] Can't you have it in /etc/init? [02:40] /etc/init is where normal configs go [02:40] maybe /etc/init/apache.override ? [06:48] Yeah, that sounds reasonable [07:01] .conf [07:01] .custom [07:01] ;-) [07:03] /lib/init, /etc/init ;-) [07:05] (Yeah, i see major reasons for that not to be desirable unless /etc/init provides a syntax to make any arbitrary changes to what /lib/init says.) [07:09] /Library/Init/Daemons [07:09] /System/Library/Init/Agents [07:09] Hah [07:10] can't remember the third one off hand [07:10] it's Daemons, Agents and something else [07:10] Does MacOSX have a case-insensitive filesystem? [07:10] case sensitive iirc [07:10] In that case, the capital letters are insane. :-P [07:11] no more insane than lower case letters ? [07:11] it's quite justifiable in fact [07:12] same justification for "Makefile" etc. [07:12] /S gives you something systemy, not a file or other directory [07:15] /v/l/d/i expands to /var/lib/dpkg/info. I’d personally find having to type /V/L/D/I instead just annoying. :-) The shell can be made to do a case-insensitive match, of course, but i’d find a case-insensitive filesystem a nicer solution. [07:19] zsh is the default shell in OS X isn't it? [07:21] Dunno [07:24] haraldh: hey [07:24] moin [07:24] how goes? [07:24] fine :) [07:24] and for you? [07:25] will you adopt dracut? [07:26] Will you adopt update-initramfs? ;-) [07:26] :) [07:26] hmmm... no [07:27] maybe assimilate :) [07:27] haraldh: I would have thought dracut would be based on systemd now? [07:27] I’m actually ignorant about their differences. For all i know, dracut may be amazingly better. [07:28] ion, "better" is maybe not the right word [07:28] more flexible maybe [07:28] Keybuk, no [07:28] Keybuk, will not happen [07:29] not in the near future [07:30] Keybuk, so, I guess you are well informed about systemd :) [07:32] I know it exists ;-) [07:32] but haven't seen the code yet? [07:33] ing-commander systemd% ls [07:33] 99-systemd.rules device.h ratelimit.h [07:33] CODING_STYLE execute.c securebits.h [07:33] LICENSE execute.h service.c [07:33] Makefile.am fdset.c service.h [07:33] ... [07:33] ;-) [07:33] :) [07:33] and what are your feelings about it? [07:34] you mean aside from the fact it's basically launchd? [07:34] yes [07:35] none really [07:35] it's a different approach, I think Lennart is wrong for a number of reasons, but I don't have any resentment over him working on it [07:35] ok [07:36] because he was worried about it [07:36] if he was worried, he would have talked to me about it early on ;) [07:36] well he did sort of [07:37] tried to talk you into implementing cgroups and stuff [07:37] yeah, and I told him what's wrong with them - and he didn't listen :p [07:37] but *shrug* Lennart ;P [07:37] :-) [07:38] I think Fedora people have more cause to have feelings than me [07:38] I hope not .) [07:39] from my POV, I have guaranteed Upstart users in the form of Ubuntu [07:39] so even if none of the other distros used it, I could still entertain myself maintaining it [07:40] as long as I thought I was right, that is :p [07:40] true [07:40] use what works for you [07:40] that's my credo [07:41] but I think Lennart is in for more of a struggle there than he raelises [07:41] it's taken four years to get Upstart into other distributions [07:41] and it had to be proven rock solid stable [07:42] he's facing quite an uphill battle ;) [07:42] true [07:43] anyway, yeah [07:43] I'm quite froody about the whole thing ;) [07:43] I've known about it since November [07:43] so it's not exactly a surprise, though the timing was awkward - as want to make sure we get a positive response out straight after he announces to avoid any community member mudslinging [07:44] on dracut [07:44] I don't think I'll have time to do anything about it this cycle [07:44] kk [07:45] I'd still like to talk to you about it though, as been thinking about what you said at Plumbers, and increasingly think that the right way to go is going to be to include init itself in the initramfs - and pass state into the full system [07:48] hmm [07:48] I concur [07:48] me2 [07:51] Having a completely different ‘init’ based on whether we have a / mounted yet would seem quite arbitrary in hindsight at the point there’s an init implementation that can handle the switch. [07:52] And completely different ways of getting network up and partitions – root or not – mounted. [07:59] right, they'd become the same [07:59] and if my hunch is correct that we don't need udevd anymroe [07:59] it makes the initramfs really simple [07:59] Indeed [08:02] how would you load drivers without udevd? [08:02] Md: so, I was drawing a diagram of the plumbing layer [08:02] explaining what each bit did [08:02] and identify raid signatures? [08:02] and I realised I'd missed udevd off [08:02] and it still worked [08:03] think about it, what does udevd actually *do* [08:04] it doesn't make device nodes anymore, those are made by the kernel [08:04] it (mostly) doesn't do permissions anymore, those are done by the ConsoleKit ACL helper [08:04] it doesn't directly talk to apps, apps just listen on the netlink socket [08:05] and we have two daemons (init & udevd) listening on the netlink socket and running stuff [08:05] well udevd broadcasts on the netlink socket [08:05] giving more infos about devices [08:05] sure, but that info is already in the db [08:06] so an app using libudev has it anyway [08:06] true, but it has to be created [08:06] with all the udev helpers [08:06] ah, but does it [08:06] what if the udev helpers were instead run the first time an app queried the db? [08:06] on the device? [08:06] that's a bit more "on demand" than "probe every damned device on boot" [08:06] hmm [08:06] it's like upstart vs systemd :) [08:07] on demand vs event driven :) [08:07] ;-) [08:07] I was actually talking to Apple guys it turns out [08:07] comparing notes on our respective layers [08:08] so it's no surprise it sounds bit like launchd, err, systemd ;) [08:08] :) [08:10] still, you have not explained what will load the drivers [08:10] Md: as I said, we have *two* daemons *today* that can run things on kernel events [08:11] upstart is quite capable of running modprobe [08:11] maybe assuming a perfect kernel which does not need any fixup rules [08:13] it'd be easier to write those in shell than in udev's evil rules syntax :p [08:15] interesting thought experiment anyway :p [08:15] I'm not going to start a "de-udev-ification" in maverick [08:15] though I may experiment towards the end of the timeframe once everything else is stable [08:16] (in a consider for 11.04 kinda way) [08:24] right bed === shan3 is now known as librano [21:53] how does one control which services are started at boot time?