| sadmac2 | Keybuk: how's the code? | 14:55 |
|---|---|---|
| Keybuk | sadmac2: finished the refactoring | 16:04 |
| Keybuk | just got to finish d-bus stuff | 16:04 |
| sadmac2 | very nice | 16:04 |
| wasabi | <wasabi> 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:06 |
| 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:07 |
| Keybuk | portmap is _really_ the only example of this kind of job I can think of | 17:08 |
| 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:09 |
| 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:10 |
| Keybuk | wasabi: why would it fail? | 17:11 |
| 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:12 |
| 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:13 |
| 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:14 |
| 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:15 |
| 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:16 |
| wasabi | design nirvana. | 17:17 |
| === Amaranth_ is now known as Amaranth | ||
| 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. :-) | 17:31 |
| sadmac2 | Keybuk: get a chance to look at that email I sent? | 19:09 |
| Keybuk | not yet | 19:14 |
| Keybuk | this week is performance review week | 19:14 |
| Keybuk | and UDS planning | 19:14 |
| sadmac2 | Ahh | 19:14 |
| 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:15 |
| sadmac2 | sweet | 19:17 |
| sadmac2 | what's still loose in the dbus code? | 19:17 |
| 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:19 |
| sadmac2 | heh. cool | 19:30 |
| ion_ | So Upstart will be the first program ever not to crap itself when dbus goes for a short walk? :-) | 19:33 |
| wasabi | You writing the dbus integrating in pid 1? | 19:37 |
| Keybuk | wasabi: yeah | 19:38 |
| wasabi | scary. | 19:38 |
| wasabi | linking to libdbus? | 19:38 |
| ion_ | Scary? | 19:39 |
| Keybuk | wasabi: yup | 19:40 |
| wasabi | That sounds frightening for some reason. | 19:40 |
| ion_ | Frightening? | 19:41 |
| wasabi | Uh huh. Just ot have that much complexity in pid 1. | 19:41 |
| ion_ | Well, for it to talk with other processes, there must be *some* implementation of *some* protocol anyway in pid 1. :-) | 19:44 |
| Keybuk | wasabi: libdbus is nice enough | 19:47 |
| Keybuk | having our own ipc implementation was scarier, since it's not as audited | 19:48 |
| 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:52 |
| wasabi | I have no practical claims. Only political claims. | 19:53 |
| Keybuk | wasabi: those people won't get a choice? | 19:56 |
| wasabi | Well, is libdbus.so required? | 19:59 |
| Keybuk | yes | 20:03 |
| AlexExtreme | libdbus.so? surely it would be safer to statically link /sbin/init to libdbus.a rather than use the shared library? | 20:12 |
| Keybuk | why safer? | 20:18 |
| Keybuk | shared libraries are safer since they can be updated for security updates | 20:18 |
| 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:35 |
| 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:36 |
| 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:37 |
| AlexExtreme | ion_: debian's packaging tools may do that, pacman's packaging tools don't | 20:38 |
| ion_ | alexextreme: Just copy the functionality from $other_distro. :-) | 20:39 |
| AlexExtreme | hah | 20:39 |
| sadmac2 | that was interesting | 21:01 |
| ion_ | alexextreme: Well, nothing prevents you from linking statically, it's just safer the other way. :-) | 21:11 |
| 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:14 |
| Keybuk | suihkulokki: see also, Why Keybuk Does Not Like GLib :) | 21:21 |
| 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) | 21:22 |
| 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:16 |
| 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:26 |
| 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:27 |
| 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:28 |
| ion_ | :-) | 22:29 |
| Keybuk | D-Bus over homebrew IPC is compelling for several reasons | 22:31 |
| 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:32 |
| 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:33 |
| 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:34 |
| 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:35 |
| 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:36 |
| Keybuk | that's basically writing in spreadsheets isn't it? :) | 22:37 |
| ion_ | Well, something like that. :-P | 22:37 |
| 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:39 |
| ion_ | end-of-the-universe? :-) | 22:40 |
| Keybuk | as in, there's no point the program saying "Please wait" | 22:41 |
| Keybuk | it won't be done before you are | 22:41 |
| ion_ | Sorry, i don't see what you mean. | 22:42 |
| Keybuk | that it's easy to write programs that have very difficult upper bounds | 22:43 |
| 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 | 22:44 |
| Amaranth | you could use ada :P | 23:09 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!