Spotify migrate 5000 servers from Debian to Ubuntu

Or yet another reason why it’s really important that we succeed with Debian LTS. Last year we heard of Dreamhost switching to Ubuntu because they can maintain a stable Ubuntu release for longer than a Debian stable release (and this despite the fact that Ubuntu only supports software in its main section, which misses a lot of popular software).

Spotify Logo

A few days ago, we just learned that Spotify took a similar decision:

A while back we decided to move onto Ubuntu for our backend server deployment. The main reasons for this was a predictable release cycle and long term support by upstream (this decision was made before the announcement that the Debian project commits to long term support as well.) With the release of the Ubuntu 14.04 LTS we are now in the process of migrating our ~5000 servers to that distribution.

This is just a supplementary proof that we have to provide long term support for Debian releases if we want to stay relevant in big deployments.

But the task is daunting and it’s difficult to find volunteers to do the job. That’s why I believe that our best answer is to get companies to contribute financially to Debian LTS.

We managed to convince a handful of companies already and July is the first month where paid contributors have joined the effort for a modest participation of 21 work hours (watch out for Thorsten Alteholz and Holger Levsen on debian-lts and debian-lts-announce). But we need to multiply this figure by 5 or 6 at least to make a correct work of maintaining Debian 6.

So grab the subscription form and have a chat with your management. It’s time to convince your company to join the initiative. Don’t hesitate to get in touch if you have questions or if you prefer that I contact a representative of your company. Thank you!

Convince your company to contribute to Debian Long Term Support

The press picked up the recent press release about Debian LTS but mainly to mention the fact that it’s up and running. The call for help is almost never mentioned.

It’s a pity because while it’s up, it’s not really running satisfactorily yet. As of today (2014-06-19), 36 packages in squeeze need a security update, yet squeeze-lts has only seen 7 updates.

debian-lts-periodsAs usual what we lack is contributors doing the required work, but in this specific case, there’s a simple solution: pay people to do the required work. This extended support is mainly for the benefit of corporate users and if they see value in Debian LTS, it should not be too difficult to convince companies to support the project.

With some other Debian developers, we have gone out of our way to make it super easy for companies to support the Debian LTS project. We have created a service offer for Debian-using companies.

Freexian (my company) collects money from all contributing companies (by way of invoices) and then uses the money collected to pay Debian contributors who will prepare security updates. On top of this we added some concrete benefits for contributing companies such as the possibility to indicate which packages should have priority, or even the possibility to provide functional tests to ensure that a security update doesn’t introduce a regression in their production setup.

To make a good job of maintaining Debian Squeeze, our goal is to fund the equivalent of a full-time position. We’re currently far from there with only 13 hours per month funded by 4 companies. That makes a current average of 3.25 hours/month funded by each contributing company, for a price of 276 EUR/month or 3315 EUR/year.

This is not much if you compare it with the price those companies would have to pay to upgrade all their Debian 6 machines now instead of keeping them for two supplementary years.

Assuming the average contribution level will stay the same, we only need the support of 50 other companies in the world. That’s really not much compared to the thousands of companies using Debian. Can you convince your own company? Grab the subscription form and have a chat with your company management.

Help us reach that goal, share this article and the link to Freexian’s Debian LTS offer. Long Term Support is important if we want Debian to be a good choice for servers and big deployments. We need to make Squeeze LTS a success!

Thank you!

Finding a new name for the Package Tracking System

The Google Summer of Code rewriting the Package Tracking System is approaching its end and I’m starting to think about deploying it on Its scope has expanded over the years and the rewritten PTS will continue this trend by bringing some new features for teams (like the possibility to subscribe to all packages of a team).

I believe that its current hostname (and name) doesn’t reflect properly the role of the PTS. Add to this the fact that there’s still some work left to be done to reach feature-parity with the current PTS, I’m considering deploying it in parallel to the current PTS under a new name.

“Package Tracking System” is also a bit too long for a name, and sounds more like a description than a name…

But if I get rid of “” and “Package Tracking System”, how should we call the new PTS? 🙂

The PTS is a sort of central place that brings together information from many parts of Debian. It’s currently mainly a consumer/dispatcher of information but I expect to integrate some of the external services that are useful for all Debian derivatives, and it will thus become more and more a producer of first-hand information as well.

To replace, Stefano Zacchiroli suggested me and I must say I like it, it’s short and relatively close to what the PTS actually is (and reminds me of DEP-2 — the new PTS will be an asset to make it a reality). My other ideas were,,,, … do you have better suggestions? what’s your preference?

Finding a better name is harder, but there’s room to build on the hub concept and similar images. I would like a full name that’s not too long and an associated abbreviation/short name for the top-level Python package (currently we use “pts” for that Python package). Can you come up with something original and satisfactory?

My latest thoughts end up with “DistroHub” as full name and “dhub” as Python package name. Still boring…

So, dear lazy web, I heard that we’re good at bikeshedding in Debian, so can you come up with something better? Share your suggestions in the comments!