[14:55] <sadmac2> Keybuk: how's the code?
[16:04] <Keybuk> sadmac2: finished the refactoring
[16:04] <Keybuk> just got to finish d-bus stuff
[16:04] <sadmac2> very nice
 Keybuk: I'm still unhappy with the idea of nfs-server having content in portmaps' job file.
[17:06] <wasabi>  I just cann't imagine how packagers will deal with it.
[17:06] <wasabi> Make my fears go away!
[17:07] <ion_> Are they just additions or larger changes?
[17:07] <Keybuk> well, it does anyway, since it needs to be in the portmap maps file
[17:08] <Keybuk> portmap is _really_ the only example of this kind of job I can think of
[17:09] <wasabi> It fails with more than one thing depending on portmap, doesn't it?
[17:09] <ion_> Have update-portmap-job within the portmap package, which combines files from .../portmap/job.d/* to /etc/init/jobs.d/portmap?
[17:09] <wasabi> You know. I guess it doesn't really matter. Mine as well just run portmap when portmap is installed, period.
[17:10] <wasabi> And just rely on the package manager to enable/disable it.
[17:10] <ion_> Or have upstart read /etc/init.d/jobs.d/portmap.d/* as a single job? :-)
[17:11] <Keybuk> wasabi: why would it fail?
[17:12] <Keybuk> there _is_ a much more entertaining way to do it
[17:12] <Keybuk> /etc/init/jobs.d/nfs-server:
[17:12] <Keybuk>     env REQUIRE_PORTMAP=1
[17:12] <Keybuk>     export REQUIRE_PORTMAP
[17:12] <Keybuk> /etc/init/jobs.d/portmap:
[17:12] <Keybuk>     start on starting REQUIRE_PORTMAP=1
[17:13] <Keybuk> you don't _have_ to match on the job name ;)
[17:13] <wasabi> oh that's crazy
[17:13] <wasabi> dude. that's slick.
[17:13] <wasabi> though how do you make it stop? :0
[17:13] <Keybuk> if there's really a large number of jobs that should behave like this, we can codify that
[17:13] <Keybuk> ie. have a "depends portmap" type syntax
[17:13] <Keybuk> which adds to the job event environment
[17:13] <wasabi> oh you could also have portmap's job file keep a ref count.
[17:13] <wasabi> or something
[17:13] <Keybuk> yeah
[17:14] <Keybuk> that'd work with states too
[17:14] <Keybuk>   state portmap-dependency
[17:14] <Keybuk>       from starting REQUIRE_PORTMAP=1
[17:14] <wasabi> start could increment the count, and run the daemon. pre-stop could decrement it and only allow stopping when it hits 0
[17:14] <Keybuk>       until stopped $JOB
[17:14] <Keybuk>   end state
[17:14] <Keybuk> then portmap would have
[17:14] <Keybuk>   while portmap-dependency
[17:15] <Keybuk> (theoretical)
[17:15] <wasabi> that is intriguing. i have yet to read about states.
[17:15] <Keybuk> I've yet to invent them properly
[17:15] <Keybuk> you and I did the ground work back in SF
[17:15] <wasabi> I remember that much
[17:15] <Keybuk> over very hot thai
[17:16] <wasabi> The next morning was not pleasant.
[17:16] <Keybuk> when I realised that upstart's design allows it to do dependency-based init with _no_ special contortions, I knew we'd reached elegance
[17:16] <Keybuk> events can be used to emulate them just fine
[17:17] <wasabi> design nirvana.
[17:31] <ion_> A bit like doing sequential code with side-effects using monads in a functional programming language. Good, clean architecture that doesn't restrict your choices when you need to have something the worse architecture does well. :-)
[19:09] <sadmac2> Keybuk: get a chance to look at that email I sent?
[19:14] <Keybuk> not yet
[19:14] <Keybuk> this week is performance review week
[19:14] <Keybuk> and UDS planning
[19:14] <sadmac2> Ahh
[19:15] <Keybuk> and I wanted to get 0.5.0 out before worrying too much about what comes after ;)
[19:15] <Keybuk> I'm stuck in a hotel in london next week, so bar going out skating, I'll have plenty of time to code that and reply to mails :)
[19:17] <sadmac2> sweet
[19:17] <sadmac2> what's still loose in the dbus code?
[19:19] <Keybuk> just the writing of the functions now
[19:19] <Keybuk> it registers the objects on the bus
[19:19] <Keybuk> and maintains a connection to the bus, dropping it and reopening when necessary
[19:19] <Keybuk> so just need to write the actual methods ;)
[19:30] <sadmac2> heh. cool
[19:33] <ion_> So Upstart will be the first program ever not to crap itself when dbus goes for a short walk? :-)
[19:37] <wasabi> You writing the dbus integrating in pid 1?
[19:38] <Keybuk> wasabi: yeah
[19:38] <wasabi> scary.
[19:38] <wasabi> linking to libdbus?
[19:39] <ion_> Scary?
[19:40] <Keybuk> wasabi: yup
[19:40] <wasabi> That sounds frightening for some reason.
[19:41] <ion_> Frightening?
[19:41] <wasabi> Uh huh. Just ot have that much complexity in pid 1.
[19:44] <ion_> Well, for it to talk with other processes, there must be *some* implementation of *some* protocol anyway in pid 1. :-)
[19:47] <Keybuk> wasabi: libdbus is nice enough
[19:48] <Keybuk> having our own ipc implementation was scarier, since it's not as audited
[19:52] <wasabi> It might scare people who don't want dbus on their systems (server installs)
[19:52] <ion_> Do you mean dbus-the-protocol or dbus-the-daemon?
[19:53] <wasabi> I have no practical claims. Only political claims.
[19:56] <Keybuk> wasabi: those people won't get a choice?
[19:59] <wasabi> Well, is libdbus.so required?
[20:03] <Keybuk> yes
[20:12] <AlexExtreme> libdbus.so? surely it would be safer to statically link /sbin/init to libdbus.a rather than use the shared library?
[20:18] <Keybuk> why safer?
[20:18] <Keybuk> shared libraries are safer since they can be updated for security updates
[20:35] <AlexExtreme> Keybuk: libdbus upgrade, .so version changes (e.g. from .so.3 to .so.4), upstart package isn't upgraded, reboot, *won't boot because of missing lib*
[20:36] <Keybuk> that's what we have package managers for
[20:36] <Keybuk> upstart would depend on libdbus3 and so libdbus.so.3 would be still installed
[20:36] <Keybuk> while libdbus4 containing libdbus.so.4 would be used by the other apps
[20:36] <ion_> Yeah, soname bumps never break anything.
[20:36] <AlexExtreme> but then again I'm speaking from my experience in a smaller distro where maintainers didn't get dependencies right and sometimes forgot to rebuild packages :)
[20:37] <Keybuk> happily dbus isn't due for a soname change
[20:37] <ion_> It's not their job to get the dependencies right, the packaging tools make the shlibdeps.
[20:37] <Keybuk> and if it were, it's maintainers have very very carefully made sure it would not be a problem
[20:37] <Keybuk> even the include files are parallel installable
[20:38] <AlexExtreme> ion_: debian's packaging tools may do that, pacman's packaging tools don't
[20:39] <ion_> alexextreme: Just copy the functionality from $other_distro. :-)
[20:39] <AlexExtreme> hah
[21:01] <sadmac2> that was interesting
[21:11] <ion_> alexextreme: Well, nothing prevents you from linking statically, it's just safer the other way. :-)
[21:14] <suihkulokki> the main worry of linking external libraries to process runnning pid 1, is that pid 1 should never ever crash
[21:14] <suihkulokki> so one needs to be sure the libraries linked to are rock solid
[21:14] <suihkulokki> and aren't built on assumptations like "it's ok to crash if malloc() fails"
[21:21] <Keybuk> suihkulokki: see also, Why Keybuk Does Not Like GLib :)
[21:22] <Keybuk> the only doofus assumption in libdbus was that it could call exit() if the connection to the bus was dropped
[21:22] <Keybuk> and that was at least an option
[21:22] <Keybuk> (but the code that set the option for bus connection was in the wrong place, which I had to fix)
[22:16] <wasabi> I think limiting scope of exposure is important. If every libdbus version upgrade is vetted by a team of trained professionals before being deployed, so as not to break upstart, then it's good.
[22:16] <wasabi> But I think in reality that does not happen, and it could break.
[22:16] <wasabi> Hence you'd limit scope in order to reduce the maintenance burden on the maintainer. upstart is super critical.
[22:26] <Keybuk> not so much
[22:26] <Keybuk> if every Upstart upgrade was vetted by the team of trained professionals
[22:26] <Keybuk> who carefully read through my IPC codfe
[22:27] <Keybuk> then I might feel happy ;)
[22:27] <Keybuk> since they don't, using a shared IPC protocol that has had more eyes over it is better
[22:28] <ion_> ...or just switch to a language that simply won't have any buffer overflows or stuff like that. :-)
[22:28] <Keybuk> then I'd have to put my faith into that language interpreter
[22:28] <Keybuk> and they really don't tend to be great ;)
[22:29] <ion_> :-)
[22:31] <Keybuk> D-Bus over homebrew IPC is compelling for several reasons
[22:32] <Keybuk> 1) security - D-Bus is used more widely and has had more people look at the code, including NSA verification, it's less likely to have extant security flaws than the homebrew
[22:32] <Keybuk> 2) response to flaws when they are found - D-Bus has active maintainership, when flaws are found the response will be rapid and a matter of replacing the library
[22:33] <Keybuk> 3) maintainability - homebrew IPC is a bitch to maintain, and touches lots of areas of UNIX that are unpleasant ;)
[22:33] <Keybuk>    much better to let someone else worry about those issues
[22:33] <Keybuk> 4) compatibility - there are already bindings for d-bus in most languages, and it's well known
[22:33] <Keybuk>    means more people will write software that talks to upstart
[22:33] <ion_> (I actually didn't mean an interpreted language, but the same of course applies to higher-level language compilers.)
[22:34] <Keybuk> 5) authentication - D-Bus already solved the authentication issues for individual connections *and* for messages
[22:34] <Keybuk> ion_: are there higher level compilers that remove the risk of buffer overflows?
[22:34] <ion_> As i said, the same (what you mentioned) applies to them. :-)
[22:34] <Keybuk> well, that and they don't exist? :p
[22:35] <Keybuk> I'm not writing Upstart in Pascal <g>
[22:35] <ion_> I've been trying to study Haskell recently with great interest, incidentally.
[22:36] <ion_> The more bits and pieces about it i get into my blob of grey matter, the more awesome it seems. :-)
[22:36] <ion_> Still, i have no idea whether the compiler (well, the glasgow compiler in this case, probably) contains bugs that could lead to security holes.
[22:36] <Keybuk> hmm, Haskell
[22:37] <Keybuk> that's basically writing in spreadsheets isn't it? :)
[22:37] <ion_> Well, something like that. :-P
[22:39] <Keybuk> I've yet to see someone implement something useful in Haskell that doesn't have very very scary end-of-the-universe problems
[22:40] <ion_> end-of-the-universe? :-)
[22:41] <Keybuk> as in, there's no point the program saying "Please wait"
[22:41] <Keybuk> it won't be done before you are
[22:42] <ion_> Sorry, i don't see what you mean.
[22:43] <Keybuk> that it's easy to write programs that have very difficult upper bounds
[22:44] <Keybuk> and can end up stuck resolving their next course of action
[22:44] <Keybuk> they do complete
[22:44] <Keybuk> but it can, in extreme cases, be calculated to require billions of years
[22:44] <ion_> Oh, ok
[23:09] <Amaranth> you could use ada :P