[08:03] <AStorm> Any good C programmer around?
[08:03] <AStorm> I mean _damn good_.
[08:04] <AStorm> cmpdir.c:125: error: invalid operands to binary &
[08:05] <AStorm> line:
[08:05] <AStorm>         if ((!(difftype & 5) || untrusted_size) && S_ISREG(st))
[08:05] <AStorm> difftype is unsigned
[08:11] <AStorm> Gah!
[08:11] <AStorm> Now I've got it.
[08:11] <AStorm> Wrong parameter to the macro.
[08:11] <AStorm> Should be st->st_mode
[08:12] <AStorm> C preprocessor is smarter than me :P
[08:16] <AStorm> Can't just say "Possibly the argument 1 to macro XYZ is of invalid type", heh?
[08:18] <AStorm> Macros are phun :P
[04:09] <Keybuk> editing the eINIT wiki is probably cheeky ;p
[04:33] <pkt> Keybuk: yeah, with a bit of kernel tweaking and UPX compression I could make a *386sx/25* boot in ~30s
[04:34] <pkt> the challenge is to boot to *something useful* fast :-)
[04:47] <Amaranth> funny, i thought sysvinit compatibility was a nice demo of how flexible the system was
[04:47] <Amaranth> according to eINIT it's something that holds you back
[04:54] <AStorm> It is, but only sometimes.
[04:54] <AStorm> SysVInit is a good system, but has no dependency support.
[04:54] <AStorm> And thus no parallelism.
[04:54] <AStorm> A bit not scalable.
[05:23] <Keybuk> but how does compatibility with that hold you back?
[05:24] <Keybuk> pkt: that's the thing that concerns me about the approach of removing shell scripts in favour of C modules
[05:24] <Keybuk> you throw away a lot of flexibility
[05:25] <Keybuk> the point of the boot sequence being written in shell is that it's easy to change it
[05:26] <pkt> Keybuk, exactly
[05:26] <pkt> and especially shell scripts instead of other languages because you can also get an interactive shell if you screw up
[05:27] <pkt> which is surprisingly easy in super-complex installations
[05:36] <Keybuk> at some point, I'm going to get around to implementing a "UNIX Script" language that has direct access to syscalls :p
[05:36] <Md> perl?
[05:37] <Keybuk> true, Perl probably suffices
[05:38] <AStorm> Keybuk, no, they won't remove shell scripts.
[05:38] <Keybuk> "remove" ?
[05:39] <AStorm> remove support :>
[05:39] <AStorm> There will be a "shell" module.
[05:39] <AStorm> Some other things will be also optionally in C.
[05:39] <AStorm> (actually, the defaults will be in C)
[05:40] <Keybuk> I'm not convinced by the whole C-vs-Shell argument anyway
[05:40] <Keybuk> I can't see it making any measurable difference on desktop-class machines
[05:41] <Md> what was the point of what ubuntu did to udev then? :-)
[05:42] <Keybuk> which bits?
[05:42] <Keybuk> the fact some of the helpers are written in C not Sh?
[05:42] <Md> yes
[05:42] <Keybuk> the ones we did in C had bugs which couldn't be "nicely" cured in Sh
[05:43] <Keybuk> 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] <pkt> 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] <pkt> The reason I 'm keeping an eye to upstart is the typicall "root in usb disk" bug
[05:47] <Keybuk> oh, don't worry; my focus right now is to get the "when a job runs" problem solved
[05:47] <pkt> 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] <pkt> yep, please stay focused on that, the other stuff is much easier
[06:12] <AStorm> Keybuk, eInit is geared towards embedded, not desktop.
[06:14] <Keybuk> 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] <Keybuk> their example distribution is Gentoo
[06:14] <Keybuk> etc.
[06:14] <Keybuk> the eINIT *design* is perfect for embedded systems
[06:14] <AStorm> :>
[06:14] <Keybuk> the marketing isn't :p
[06:14] <AStorm> Well, Gentoo on Arm works great.
[06:14] <AStorm> :>
[06:14] <AStorm> Actually, it's not Gentoo, it's a snapshot of it, crosscompiled.
[06:16] <Keybuk>  29 files changed, 4515 insertions(+), 3530 deletions(-)
[06:17] <Keybuk> (since 0.3.5 ... ouch; I must get more into the hang of making releases :p)
[06:19] <Keybuk> trouble is, I tend to break things immediately after a release and take ages to get around to fixing them again
[06:22] <AStorm> Keybuk, what about a nice test suite?
[06:24] <Keybuk> AStorm: how do you mean?
[06:25] <AStorm> If you know something is broken, write a test against that functionality.
[06:25] <AStorm> That will remind you to fix it.
[06:25] <Keybuk> have you ever looked at the upstart source code? :P
[06:25] <mbiebl> iirc, that is exactly how keybuk does it ;-)
[06:26] <AStorm> Keybuk, yep
[06:26] <AStorm> Looks nice, clean and understandable.
[06:27] <Keybuk> AStorm: ever looked in the tests sub-directory? :p
[06:27] <AStorm> Nope? :P
[06:27] <Keybuk> around 60% of the upstart source code is the test suite
[06:27] <AStorm> I'm currently creating a new distro, so am a bit busy. :>
[06:27] <Keybuk> run "make check" :p
[06:28] <AStorm> Hehe.
[06:31] <Keybuk> Today's problem is how to communicate the new job structure over IPC
[06:31] <Keybuk> e.g. when you do "emit foo", it currently notifies you of the jobs started or stopped by that
[06:31] <Keybuk> should it just say "frodo started", or should it say "frodo started, now running, pid 456"
[06:31] <Keybuk> ?
[06:32] <Keybuk> (likewise, if it causes an action to be run, should it say "frodo reload invoked, pid 1234" ?
[06:32] <Keybuk> or should that be included in above)
[06:32] <Keybuk> etc.
[06:37] <AStorm> I'd suggest going for verbose output.
[06:37] <AStorm> It's an internal command anyway.
[06:38] <Keybuk> it's how to lay out the messages that's fun
[06:39] <AStorm> Pass some nice packed struct, maybe?
[06:39] <Keybuk> the trouble with packed structs is extending them later ;)
[06:40] <Keybuk> ie. what happens if I add an extra field to the JobProcess struct
[06:40] <AStorm> Not for you.
[06:40] <Keybuk> how do older versions of initctl know to skip over that so they can find the start of the next one
[06:40] <AStorm> Older versions are obsolete :P
[06:40] <Keybuk> I don't agree there <g>
[06:40] <Keybuk> you shouldn't have to update all your software just to update init
[06:40] <AStorm> When you install upstart, you should also install up-to-date initctl
[06:41] <AStorm> It's a bundle, right?
[06:41] <Keybuk> and up-to-date udev, acpid, network manager, etc.?
[06:41] <AStorm> Structs are for internals!
[06:41] <Keybuk> how about up to date gnome services manager?
[06:41] <Keybuk> ah, but the IPC isn't internal
[06:41] <Keybuk> that's the point
[06:41] <AStorm> Text output is for externals :>
[06:41] <AStorm> Hmmmmm.
[06:41] <Keybuk> it's supposed to be a stable API for other applications
[06:41] <AStorm> Why use IPC and not FIFO?
[06:41] <Keybuk> FIFO is a form of IPC
[06:42] <AStorm> IPC for me means SysV IPC.
[06:42] <Keybuk> upstart uses an abstract-domain datagram unix socket
[06:42] <Keybuk> which is a kind of fifo, I guess
[06:43] <Keybuk> preserves message boundaries and ordering
[06:52] <mbiebl_> Keybuk: for tools like a gnome service manager, a upstart D-Bus interface would be much better imo
[06:52] <Keybuk> mbiebl_: yes, that's the actual plan
[06:52] <Keybuk> but then you'd have to upgrade the upstart d-bus interface :)
[06:53] <Keybuk> and a console service manager might not want to use the d-bus interface, but the direct one
[06:53] <mbiebl_> Sure, but the gnome program wouldn't notice
[06:54] <Keybuk> if it's only a little more effort to maintain a stable API, I think it's worthwhile
[06:54] <mbiebl_> Why not use D-Bus for the console too?
[06:54] <mbiebl_> I don't mean, for the core tools like initctl
[06:54] <Keybuk> because that introduces d-bus as a base-system dependency
[06:54] <mbiebl_> but for a service manager, i thinks it'd be fine.
[06:55] <Keybuk> server people won't like that
[06:55] <Keybuk> you don't normally have dbus or hal on a web server
[07:24] <wasabi> That's always confused me. I don't particularily care what goes on most of the servers I use. heh
[07:50] <Keybuk> heh
[07:50] <Keybuk> we used to be really paranoid at Demon, even removed compilers, etc. from the servers
[07:51] <Keybuk> (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] <wasabi> Most of the world doesn't particularily care, as evidenced by the rise of wIndows based servers.
[08:10] <wasabi> And I mostly fall in that camp. I'd like the system to just get the job done so I can go play. =)