De Utrecht Skate Parade ging deze vrijdag naar Kasteel De Haar buiten de stad. Goede reden om naar Utrecht te gaan en mee te rollen! De route was met ruim 27 kilometer iets langer dan normaal, en ik begrijp dat er 350 mensen meededen.
Deze keer durfde ik voor het eerst een camera mee te nemen, dus hier een aantal foto's.
Rond 1990, 1991 was ik vrijwilliger bij Lokatel, de lokale omroep in Den Haag. Lokatel had geloof ik iets van tweehonderd vrijwilligers en een handjevol betaalde krachten. Ik heb een enkele keer wat voor de radio en de televisie gedaan, maar ik was voornamelijk bezig met de kabelkrant.
In die tijd voor het World Wide Web hadden we wel teletekst, maar dat was nog niet zo ingeburgerd als het later zou worden. Bovendien zijn de grafische mogelijkheden van teletekst beperkt. Vandaar dat in die jaren het medium kabelkrant een zekere populariteit had. Een kabelkrant bestond uit een verzameling pagina's die één voor één in beeld kwamen op een (kabel-) televisiekanaal.
Ik vond nog een oude VHS-band terug met een stukje van de Lokatel Kabelkrant uit november of december 1989. Klik op het plaatje om naar de volgende pagina te gaan.
En ik ben reuze benieuwd welke Lokatelli's er straks allemaal naar de Lokatel-reünie in de bibliotheek/stadhuis gaan.
►
This July 30th, at 23:59:60, a leap second was added to Coordinated Universal Time (UTC). Dyn Research posted the following graph on Twitter that shows there was significant BGP update instability for five minutes after the leap second occurred:
▼
This July 30th, at 23:59:60, a leap second was added to Coordinated Universal Time (UTC). Dyn Research posted the following graph on Twitter that shows there was significant BGP update instability for five minutes after the leap second occurred:
Unfortunately, it's not clear why this happened. However, leap seconds have triggered all kinds of mishaps in the past. They're basically miniature Y2K problems. Time and time again, software engineers show that they can't be trusted to take corner cases into account properly.
This does remind me of a situation about a decade ago, where I had a customer that experienced BGP instability every night at the same time. They used Quagga running on Linux machines. We couldn't figure out what the problem was, until we realized that at that very moment, the ntpdate command was run from the cron. ntpdate synchronizes the system clock with an NTP server. As the machine in question had a very poor system clock, this meant that the system's time was adjusted a lot every night, I think a minute or more, but definitely more than 30 seconds.
Which meant that if Quagga had gotten a BGP keepalive message 8 seconds earlier, it now thought that was 38 seconds ago. If BGP is configured with a hold time of 30 seconds, this means that Quagga now thinks the other side has been quiet for longer than the hold time and it'll tear down the BGP session. This is what happened every night for a bunch of BGP sessions. We solved this by running the NTP daemon continuously, so there was never a big adjustment in system time. (Alternatively, just letting the time drift would also have worked.)
The minimum BGP hold time is 3 seconds, so adjusting for an (improperly handled) leap second shouldn't be able to make BGP think the hold time for a session is expired. However, there could be bug somewhere else that impacted BGP.
I'm not sure whether these kinds of issues are a good argument in favor of abandoning leap seconds, as the bugs won't go away, they'll just show up at a less predictable time. But I don't like the current leap second practice, as they're unpredictable, and you can't calculate the time difference in seconds between two dates without taking the entire list of leap seconds into account. I think it would be better to save the leap seconds up and apply them all at the end of a century.
Despite the blister on my foot I couldn't resist going out and trying out my new Powerslide Fothon wheels for my inline skates. I got a 4-pack of wheels with red LEDs:
The wheels contain a small generator that uses the rotation of the wheel to generate electricity for the LEDs, so they come on when the wheels turn. Because all of this slows down the wheels a bit, I'm only using one on each skate. They also come in white, blue and green.
And as always, iPhone slow motion video for the win!
At the NANOG meeting in San Francisco two weeks ago, there was a session on The benefits of deploying IPv6 only. Someone from T-Mobile explained that the latest Windows Mobile and Android support 464XLAT to allow IPv4-only applications to work over IPv6 with NAT64, so those devices now only get IPv6. Other devices only get IPv4, there's no dual stack. At that point, the panelists didn't know yet that Apple is requiring iOS 9 apps to work over IPv6 so those can work through NAT64 without 464XLAT.
Another interesting data point is the observation by Facebook that IPv6 tends to perform better than IPv4, with the margin being as large as 40%:
However, why this is is unclear: the RTTs are the same, yet the performance/bandwidth over IPv6 is better. There was some frustration because Apple's implementation of "happy eyeballs" only looks at the RTT to choose between IPv4 and IPv6, and thus lands on IPv4 a good deal of the time and doesn't enjoy the benefits of that better IPv6 performance.
I think yesterday's WWDC was the longest one I've seen at nearly 2.5 hours. Still, there wasn't much to get excited about. Apple Pay is coming to the UK, but not to the rest of the world. Apple Maps transit directions are coming to two handfuls of cities and all of China, but not to Holland. Apple's new news app is also limited to the US, the UK and Australia. The music stuff may or may not be interesting, but I'm afraid it's going to get in the way of simply playing the music I have on my computer and my iPhone.
But... reading the fine print, there is one thing I can get behind:
A customizable font for Safari Reader!
I must be getting old, but I really can't stand what the web has become these days. The trend to have fixed banners at the top and/or bottom of pages gets on my nerves, because that way you can't scroll a webpage one screen at a time. It's also visually distracting. As are the attention-grabbing ads, which are often animated or video. So there's hardly any text I read on the web without invoking Safari Reader.
However, Safari Reader itself isn't all that great: the width of the text is fixed, so in order to get avoid having too many words per line, which makes it hard to land on the next line, I need to keep the text size bigger than I'd like. (Funny, because 95% of web pages use text that is way too small.)
Safari Reader uses the Georgia font, which isn't terrible, but largish serif fonts just don't take advantage of high resolution displays. So I hope that in addition to the ability to configure a nice sans serif font, we also get to adjust the margins in Safari Reader.
