[13:47] <rick_h_> bwuhahahaha, waterproof camera arrival. You'll all get a lot more pics of the fish catch now!
[13:54] <jrwren> waterproof but not underwater? do you dislike phone cameras?
[13:55] <rick_h_> I don't trust my phone in a kayak out in the open
[13:55] <rick_h_> this thing has a floating strap and can be submerged floating while I fish it out of the lake if I drop it
[13:55] <jrwren> ah, cool!
[13:56] <rick_h_> paying full price for cell phones makes you a little bit more cautious about where you stick it :)
[13:57] <devinheitmueller> I don’t know if you’re interested but Lennart Poettering did a systemd talk last night here at NYLUG.  https://www.youtube.com/watch?v=PDHTcB63NXs&feature=youtu.be
[13:58] <devinheitmueller> Might be worth Scott taking a look prior to MUG’s talk on July 14th to see if he wants to steal any materials.  :-)
[14:00] <jrwren> full price? You mean like $599 instead of free or $99 ?
[14:00] <jrwren> who does that? :)
[14:09] <cmaloney> Good morning pt. 2
[14:10] <cmaloney> devinheitmueller: Thanks for the link
[14:10] <devinheitmueller> np.  Hope it helps.
[14:12] <jrwren> 2h40m. anyone got a summary?
[14:13] <cmaloney> "Hi, I'm Lennart and I wrote systemd. Here's why it's awesome"
[14:13] <devinheitmueller> I think the video was a livestream so it started before the actual talk.  Hence you can likely fast forward through the parts where people are just standing around drinking beer and finding their seats.
[14:14] <devinheitmueller> I’ve personally had some unpleasant exchanges with Lennart in the past, and I have to say though that I was actually pretty impressed.
[14:16] <devinheitmueller> Having some background behind the motivation behind some of the design decisions, and why they just didn’t extend Upstart was pretty useful.  I came out of it feeling less like there’s a consipiracy for systemd to take over the world.
[14:22] <cmaloney> Yeah, same with pulseaudio
[14:22] <cmaloney> there's some good thinking in there.
[14:23] <jrwren> all that is in the systemd FAQ. I read it, and was no longer anti-systemd
[14:24] <jrwren> err, not faq, but this: http://0pointer.de/blog/projects/the-biggest-myths.html
[14:25] <devinheitmueller> I think for many it was just a huge shift from the traditional sysvinit thinking (and there is lots of added complexity with any parallel init system).  Hence I can appreciate people trying systemd, running into to some case where it didn’t behave the way they would have expected, and then been bewildered with the process of debugging what went wrong.
[14:25] <jrwren> i never understood what "traditional sysvinit thinking" was. There was always init pid 1 and it did whatever it did. That changed a lot over the years.
[14:26] <devinheitmueller> Plus many were/are irked by systemd’s importing of functionality that was previously done by standalone processes (udev, networking, etc).  That said, I came out of the talk appreciating that there was some pretty good rationale for some of these decision.
[14:26] <jrwren> Maybe because I admined BSD for years along with linux, I was thinking about things differently? I don't know.
[14:27] <devinheitmueller> I think many are still of the mindset where they think about runlevels and linear startup (i.e. init scripts running in order).  Plus it was relatively easy to hack an existing init script to add debugging when things didn’t do what you expected.
[14:27] <jrwren> could be.
[14:27] <jrwren> it hasn't been that way for many years.
[14:28] <devinheitmueller> Who hasn’t jammed “set -x” into the top of an init script so they could see what it was doing at boot?  That sort of thing can be harder with systemd.
[14:28] <jrwren> upstart has been in ubuntu for 4+yrs, right?
[14:28] <jrwren> and upstart was in at least 1 debian release.
[14:28] <jrwren> and iirc upstart was in a rhel release and a few fedora releases.
[14:28] <jrwren> it has been harder with upstart just the same :)
[14:29] <devinheitmueller> I think upstart better preserved some of the older conventions though by being able to run things like the existing “service” commands and reliance on shell scripts for the actual business logic.
[14:29] <devinheitmueller> Some of this is certainly a comfort issue.  People get set in their ways and learn a subset of commands they use regularly, and then along comes this thing that is totally different and requires to you learn a whole new set of commands to manage.
[14:30] <jrwren> you are wrong on teh second point.
[14:30] <devinheitmueller> Am I?
[14:30] <jrwren> on teh first point, yes, making service _ start/stop work is great.
[14:31] <jrwren> devinheitmueller: yes, there is fallback to /etc/init.d/ scripts, but it did not rely on them.
[14:31] <jrwren> in fact, it was often very confusing to see if /etc/init.d script was being used v. /etc/init upstat job because both would exist.
[14:32] <jrwren> you had to know that the /etc/init job would be used and /etc/init.d script ignored.
[14:32] <devinheitmueller> Entirely possible.  I’ll be the first to admit I haven’t done any Linux server admin in several years, and the use cases for my Ubuntu desktop have “just worked”.
[14:32] <jrwren> yes, its nice.
[14:32] <jrwren> and systemd is nice too.
[14:32] <jrwren> so if you have used upstart, systemd is not much of a change.
[14:33] <jrwren> even the shell scripts thing is being worked around in the complex cases, so services still use shell scripts to start.
[14:39] <jrwren> e.g. a systemd service with ExecStart=/etc/init.d/yourservice systemd-start
[14:39] <jrwren> looks to be the pattern from debian/ubuntu
[14:40] <jrwren> and that way you can have service packages which work with 3+ init systems easily.