=== khermans__ [i=administ@nat/cisco/x-e8084fb6ef72d835] has joined #upstart === khermans__ [i=administ@nat/cisco/x-e8084fb6ef72d835] has joined #upstart === mbiebl [n=michael@e180099068.adsl.alicedsl.de] has joined #upstart === theCore [n=alex@ubuntu/member/theCore] has joined #upstart === pkt [n=pantelis@athedsl-136147.otenet.gr] has joined #upstart === Md [i=md@freenode/staff/md] has joined #upstart === AStorm [n=astralst@chello084010114027.chello.pl] has joined #upstart === wasabi [n=wasabi@ubuntu/member/wasabi] has joined #upstart === Amaranth [n=travis@ubuntu/member/Amaranth] has joined #upstart === _ion [i=johan@kiviniemi.name] has joined #upstart === nakee [n=nakee@grok.cs.huji.ac.il] has joined #upstart === cortana [n=sam@62-31-146-25.cable.ubr12.azte.blueyonder.co.uk] has joined #upstart === wasabi_ [n=jhaltom@ubuntu/member/wasabi] has joined #upstart === benmur [n=benmur@friends.sukria.net] has joined #upstart === AlexExtreme [n=AlexExtr@frugalware/developer/AlexExtreme] has joined #upstart === mbiebl [n=michael@e180099068.adsl.alicedsl.de] has joined #upstart === mbiebl [n=michael@e180099068.adsl.alicedsl.de] has joined #upstart === j_ack [n=rudi@p508DBA65.dip0.t-ipconnect.de] has joined #upstart === khermans__ [i=administ@nat/cisco/x-55cf71a4a3b3fd41] has joined #upstart [08:03] Any good C programmer around? [08:03] I mean _damn good_. [08:04] cmpdir.c:125: error: invalid operands to binary & [08:05] line: [08:05] if ((!(difftype & 5) || untrusted_size) && S_ISREG(st)) [08:05] difftype is unsigned [08:11] Gah! [08:11] Now I've got it. [08:11] Wrong parameter to the macro. [08:11] Should be st->st_mode [08:12] C preprocessor is smarter than me :P [08:16] Can't just say "Possibly the argument 1 to macro XYZ is of invalid type", heh? [08:18] Macros are phun :P === int0x0c [n=ben@161.253.46.197] has joined #upstart === juergbi [n=juerg@80-219-17-102.dclient.hispeed.ch] has joined #upstart === pkt [n=pantelis@athedsl-285482.otenet.gr] has joined #upstart === cortana [n=sam@62-31-146-25.cable.ubr12.azte.blueyonder.co.uk] has joined #upstart === cortana [n=sam@62-31-146-25.cable.ubr12.azte.blueyonder.co.uk] has joined #upstart === Md [i=md@freenode/staff/md] has joined #upstart === _ion_ [i=johan@kiviniemi.name] has joined #upstart === Md [i=md@freenode/staff/md] has joined #upstart === juergbi [n=juerg@80-219-17-102.dclient.hispeed.ch] has joined #upstart === binary-zero [n=Shakeel@203.81.202.104] has joined #upstart === binary-zero [n=Shakeel@203.81.202.104] has left #upstart ["Leaving"] === j_ack [n=rudi@p508DC1D4.dip0.t-ipconnect.de] has joined #upstart === Keybuk [n=scott@wing-commander.netsplit.com] has joined #upstart [04:09] editing the eINIT wiki is probably cheeky ;p === Keybuk just corrected someone's "look eINIT boots in 15s compared to sysvinit's 52s" bullshit page [04:33] Keybuk: yeah, with a bit of kernel tweaking and UPX compression I could make a *386sx/25* boot in ~30s [04:34] the challenge is to boot to *something useful* fast :-) [04:47] funny, i thought sysvinit compatibility was a nice demo of how flexible the system was [04:47] according to eINIT it's something that holds you back [04:54] It is, but only sometimes. [04:54] SysVInit is a good system, but has no dependency support. [04:54] And thus no parallelism. [04:54] A bit not scalable. [05:23] but how does compatibility with that hold you back? [05:24] pkt: that's the thing that concerns me about the approach of removing shell scripts in favour of C modules [05:24] you throw away a lot of flexibility [05:25] the point of the boot sequence being written in shell is that it's easy to change it [05:26] Keybuk, exactly [05:26] and especially shell scripts instead of other languages because you can also get an interactive shell if you screw up [05:27] which is surprisingly easy in super-complex installations [05:36] at some point, I'm going to get around to implementing a "UNIX Script" language that has direct access to syscalls :p [05:36] perl? [05:37] true, Perl probably suffices [05:38] Keybuk, no, they won't remove shell scripts. [05:38] "remove" ? [05:39] remove support :> [05:39] There will be a "shell" module. [05:39] Some other things will be also optionally in C. [05:39] (actually, the defaults will be in C) [05:40] I'm not convinced by the whole C-vs-Shell argument anyway [05:40] I can't see it making any measurable difference on desktop-class machines [05:41] what was the point of what ubuntu did to udev then? :-) [05:42] which bits? [05:42] the fact some of the helpers are written in C not Sh? [05:42] yes [05:42] the ones we did in C had bugs which couldn't be "nicely" cured in Sh [05:43] e.g. the "look at /proc/ide" one, which in Sh had a massive race condition if /proc/ide didn't turn up in time [05:46] Keybuk, anyway you *please* only focus in correctness (as you have so far), it is much easier to add speed (at least for site-specific configurations) [05:46] The reason I 'm keeping an eye to upstart is the typicall "root in usb disk" bug [05:47] oh, don't worry; my focus right now is to get the "when a job runs" problem solved [05:47] where with something like sysvinit you can only wait for an arbitrary time slowing down boot rediculously for other users and *still* not being correct [05:48] yep, please stay focused on that, the other stuff is much easier [06:12] Keybuk, eInit is geared towards embedded, not desktop. [06:14] AStorm: except their website seems to suggest they're entirely gearing it as an alternative to sysvinit and/or upstart, and that it's ideal for desktop deployment [06:14] their example distribution is Gentoo [06:14] etc. [06:14] the eINIT *design* is perfect for embedded systems [06:14] :> [06:14] the marketing isn't :p [06:14] Well, Gentoo on Arm works great. [06:14] :> [06:14] Actually, it's not Gentoo, it's a snapshot of it, crosscompiled. [06:16] 29 files changed, 4515 insertions(+), 3530 deletions(-) [06:17] (since 0.3.5 ... ouch; I must get more into the hang of making releases :p) [06:19] trouble is, I tend to break things immediately after a release and take ages to get around to fixing them again === mbiebl [n=michael@e180102211.adsl.alicedsl.de] has joined #upstart [06:22] Keybuk, what about a nice test suite? [06:24] AStorm: how do you mean? [06:25] If you know something is broken, write a test against that functionality. [06:25] That will remind you to fix it. [06:25] have you ever looked at the upstart source code? :P [06:25] iirc, that is exactly how keybuk does it ;-) [06:26] Keybuk, yep [06:26] Looks nice, clean and understandable. [06:27] AStorm: ever looked in the tests sub-directory? :p [06:27] Nope? :P [06:27] around 60% of the upstart source code is the test suite [06:27] I'm currently creating a new distro, so am a bit busy. :> [06:27] run "make check" :p [06:28] Hehe. [06:31] Today's problem is how to communicate the new job structure over IPC [06:31] e.g. when you do "emit foo", it currently notifies you of the jobs started or stopped by that [06:31] should it just say "frodo started", or should it say "frodo started, now running, pid 456" [06:31] ? [06:32] (likewise, if it causes an action to be run, should it say "frodo reload invoked, pid 1234" ? [06:32] or should that be included in above) [06:32] etc. [06:37] I'd suggest going for verbose output. [06:37] It's an internal command anyway. [06:38] it's how to lay out the messages that's fun [06:39] Pass some nice packed struct, maybe? [06:39] the trouble with packed structs is extending them later ;) [06:40] ie. what happens if I add an extra field to the JobProcess struct === mbiebl_ [n=michael@e180102211.adsl.alicedsl.de] has joined #upstart [06:40] Not for you. [06:40] how do older versions of initctl know to skip over that so they can find the start of the next one [06:40] Older versions are obsolete :P [06:40] I don't agree there [06:40] you shouldn't have to update all your software just to update init [06:40] When you install upstart, you should also install up-to-date initctl [06:41] It's a bundle, right? [06:41] and up-to-date udev, acpid, network manager, etc.? [06:41] Structs are for internals! [06:41] how about up to date gnome services manager? [06:41] ah, but the IPC isn't internal [06:41] that's the point [06:41] Text output is for externals :> [06:41] Hmmmmm. [06:41] it's supposed to be a stable API for other applications [06:41] Why use IPC and not FIFO? [06:41] FIFO is a form of IPC [06:42] IPC for me means SysV IPC. [06:42] upstart uses an abstract-domain datagram unix socket [06:42] which is a kind of fifo, I guess [06:43] preserves message boundaries and ordering [06:52] Keybuk: for tools like a gnome service manager, a upstart D-Bus interface would be much better imo [06:52] mbiebl_: yes, that's the actual plan [06:52] but then you'd have to upgrade the upstart d-bus interface :) [06:53] and a console service manager might not want to use the d-bus interface, but the direct one [06:53] Sure, but the gnome program wouldn't notice [06:54] if it's only a little more effort to maintain a stable API, I think it's worthwhile [06:54] Why not use D-Bus for the console too? [06:54] I don't mean, for the core tools like initctl [06:54] because that introduces d-bus as a base-system dependency [06:54] but for a service manager, i thinks it'd be fine. [06:55] server people won't like that [06:55] you don't normally have dbus or hal on a web server === khermans__ [i=administ@nat/cisco/x-4b8a275ec0c5e08f] has joined #upstart === cortana [n=sam@62-31-146-25.cable.ubr12.azte.blueyonder.co.uk] has joined #upstart [07:24] That's always confused me. I don't particularily care what goes on most of the servers I use. heh [07:50] heh [07:50] we used to be really paranoid at Demon, even removed compilers, etc. from the servers [07:51] (right, my dinner's on now -- just need to keep feeding it every now and then) [07:56] <_ion> Dinner is a security hole. Viruses can attain access to the system via ingestion. [08:09] Most of the world doesn't particularily care, as evidenced by the rise of wIndows based servers. [08:10] And I mostly fall in that camp. I'd like the system to just get the job done so I can go play. =) === urban [n=urban@xa147.internetdsl.tpnet.pl] has joined #upstart === mbiebl_ [n=michael@e180102211.adsl.alicedsl.de] has joined #upstart === j_ack [n=rudi@p508D9216.dip0.t-ipconnect.de] has joined #upstart === _ion [i=johan@kiviniemi.name] has joined #upstart