Change. I made some.
2015 was pretty stable. I changed that in 2016.
In September I wrapped up three years of pushing IPv6 at Yahoo; I took trips to Arizona, New Orleans, and Panama City. I moved out of my apartment in San Francisco on November 20th. I arrived in Amsterdam on November 29th; I started work at RIPE NCC on December 1st.
Let’s talk about the other changes inherent in that: the role is research-focussed; the organisation is not-for-profit; the organisation is much smaller than Yahoo; the work is all network-oriented, not advertising-oriented; the research is pragmatic, operationally focussed; the work is much more public than corporate culture allowed. These are all good.
As I write this, I’m about to move into a more permanent apartment. My daily commute will be no longer than a 20 minute walk to or from the office. London is an hour away, Scotland not much more. I double my vacation allowance. It’s been winter, with some days dipping comfortably below freezing. This week, my belongings turned up after their transit from California. These changes are all good, and things are now settling down.
Last year I also managed trips to Berlin (IETF96), Portland (twice), Seattle (twice), Ottawa, and also back home to Scotland. Squeezing all that around limited vacation time on the West coast of the US is, to say the least, tiring. I’m pleased I’ve relocated somewhere more central.
And hopefully we’ll see! I’m planning on running Bay to Breakers again in 2017. This time, I’ll have gone through a winter and I’ll probably be running with some jet lag; should add to the challenge!
So, hey, 2017. We’re almost two months in already, but it’s going well so far. Hoping for more.
Last month we covered the 2015 leap second ahead of the insertion of a leap second at the very end of 2016. As stated previously, leap seconds can trigger poorly-tested code paths; leap second handling always unearths bugs and issues. This one was no exception!
On 31 December this year, we’re scheduled for another leap second. There are many stories about what leap seconds can do to infrastructure and applications, and rituals are built up around them. Such rituals stem from reality: leap seconds trigger poorly-tested code paths and run contrary to assumptions that system time always runs in one direction. It’s useful to be aware of how your infrastructure handles leap seconds and how NTP servers handle them, so you can plan around the event. Here, we look at some of the NTP measurements the RIPE Atlas platform took around the last leap second, and approaches for handling them.