The music problem

▼ 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.

Permalink - posted 2015-07-30

5 minutes of BGP instability after leap second

▼ 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.

Permalink - posted 2015-07-06