▼
After reading stuff like this and even like this, I'm so glad I didn't sign up for Apple's new music service.
I regularly hear about people with more than 25000 songs in their iTunes library. Compared to them, my music library is tiny at only 3500 songs. Still, that's more than 9 days worth of music, or about 200 CDs or 300 LPs. (It's insane that these days this will fit on an SD card the size of a postage stamp.) So there's an entire universe of music out there for me to discover. But it turns out that, not unexpectedly, my prime music discovery days seem to be behind me. These are the numbers of songs per decade in my music library:
1900 - 1909: 1
1920 - 1929: 1
1940 - 1949: 4
1950 - 1959: 102
1960 - 1969: 421
1970 - 1979: 766
1980 - 1989: 897
1990 - 1999: 526
2000 - 2009: 379
2010 - 2015: 8
(And the 2000 - 2009 number is inflated quite a bit because a lot of purchased music has the year field set to the year of (re-) issue rather than the year of original recording.)
Still, after the whole Taylor Swift thing, I considered doing the three month trial for Apple Music. Until I realized that if I did that, my local music library would become intermingled with music from the cloud, with too many corner cases to have any hope that Apple will handle all of them correctly.
I'm not even particularly happy with buying songs from the iTunes Store. Despite the 30 second preview (it's often longer now), I managed to buy the wrong version of a number of songs. I also somehow managed to buy songs that I end up never listening to. Then remember all the issues people have had with iTunes Match. And Apple Music is much more complex than what came before. So I'm not at all surprised that people are having problems combing existing music libraries with Apple Music.
For a while, I've been hoping that Apple's opening up of various aspects of iOS would lead to a more liberal approach to music on iOS devices, rather than the current system where there is only one way to get your (local) music on a device in a workable way: through iTunes. But now that Apple has redoubled its music efforts, that probably isn't going to happen any time soon. Too bad.
Many people have called for breaking up iTunes (on the Mac) into smaller applications that handle more limited tasks better. I can see the appeal: an Apple Music app would be much simpler than bolting on yet another function to iTunes. However, previous experience has shown that any change to iTunes only serves to make it worse. (I'm still on iTunes 12.1, and I'm not sure I'm going to upgrade to 12.2.) Some kind of super ambitious, super radical rethinking of the whole system is certainly going to make some parts of it a lot worse. Remember Final Cut X and iWork '13?
A better approach would be to freeze iTunes as it is today (well, as it was a few years ago, really) and then create new apps for new stuff such as Apple Music. This way, both the people who like the old stuff and people who like the new stuff get something that works well for them. That still doesn't solve the use case of having both the old and the new stuff side-by-side, but then, the current approach doesn't really solve that either.
►
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.
