Oli Warner's blog

Arguments Against Rolling Release Ubuntu

Oli Warner — Fri, 01 Mar 2013 02:43:53 +0000

I've just read through Rick Spencer's argument for rolling releases in the Ubuntu Devel mailing list but I'm frankly less convinced than I was before.

Let's get one thing clear: The VP of Ubuntu Engineering at Canonical, Rick Spencer writes a mean proposal. Honestly. I deal with more than a fair amount of marketing copy-writing and I can tell you it's a great pitch. It's completely decided in its stance and it uses emotive and empowering power-words like converge, velocity and agility. You'll find nothing but the finest propaganda here.

Anyway, here's my interpretation — a paraquote, if you will — of Rick's whole argument:

We spend too much time supporting old, haggered software that no users actually want, and not enough on shiny new things.

We frustrate people by being up to six months behind the curve, we end up rushing new features and integrations because of the arbitrary time limit and we already rock at getting things right first time with Daily Quality... so why not move to a rolling release?

It's better for users, maintainers and the rest of us if we all just use one codebase for everything (including phones and all that). That will give us the time to improve things at a faster and more stable rate.

Again, that is just my interpretation. You can read the full post and make your own. I have some reservations based on what the post suggests to be true and some of the "remedies" for those problems also seem to carry risks and downsides. Here are my key problems with a rolling system:

Newer is not always better.

The biggest elephant in the room. Newer can mean fixes and features but it often means new bugs, freshly lapsing documentation and a new wave of angry users when their things just stop working.

A culture of constant-updates may also rely on waiting for the next upstream version instead of getting stuck in and fixing otherwise low hanging fruit.

Users can already upgrade any parts they want.

The relevant teams make sure that the latest graphics packages and wifi drivers are available and backported and for everything else PPAs have revolutionised the upgrade system.

If you want the latest version of PHP, Chrome or KDE, you just install a PPA and you accept the risk. If it doesn't work you can just ppa-purge it out of the system and you're back to solid, stable ground.

Rolling means a constantly moving target.

Developers don't know what they're building for. Users barely know what they're running on. Triagers need to work five times as hard to track down which version of which software a bug is coming from. What happens to bugs after the new release comes out? How on earth do you plan a multi-month project (eg: migrating Upstart to Systemd) when you have no way to freeze and force everything else to fit around you?

And what about the "stable ABI" we've been honking on about to app developers and ISVs?

It's hard enough for open-source developers to keep up but now you've got a bunch of closed source stuff sailing on this ship. This is only possible because we promised we'd remain a solid platform and be respectful with system changes.

The successful marketing of this feature (along with other things coming into alignment) mean gaming on Linux is right in the process of taking off. And you want to shoot it down with ABI instability? Awesome. Call off the year of the Linux Desktop!

The argument that ISVs only care about LTS is the funniest thing I've read all day. ISVs are paid to care about what their customers whine about. Take gamers as a market example. If developers don't support Ubuntu-NG, most of their market has just evaporated. You can't think about Ubuntu as a B2B software platform. The future is going to be full of B2C and I2C sales and if you can't support the developers, they're not going to support your platform.

Converge is a lie. There is no convergence yet.

Ubuntu Touch is possibly the least unified Ubuntu in the family. Different kernel. Different display server. Different interface. Different interface toolkit. Different application API. You can't jolly on about being from the same codebase when it's completely different stuff.

I'm sure this will change in the future but until desktop Unity runs on QML, offering similar API hooks to applications, I'm not even going to entertain the idea that there's convergence. It's a nice hopeful word but it has no relation to Ubuntu at the moment.

Daily Quality is good enough? Release quality still isn't good enough!

I deal with Joe the average user on a daily basis. They've downloaded Ubuntu and it doesn't work. Or they've upgraded and their sound doesn't work. Or they can't get a graphical environment. Or the wifi doesn't work. This is the staple of question on Ask Ubuntu. We'll get a few hundred of these every week without fail.

Joe still occasionally has a really bad time with Ubuntu because Joe wasn't there when Ubuntu was in its 6-month development phase. Joe could have downloaded the testing ISO or upgraded but they didn't so when the big upgrade finally happened on release day, they ran into a hardware-specific bug in the Kernel or X.

A rolling release is going to create a few thousand Joes every upgrade and will turn Ask Ubuntu and Launchpad into cesspits of poorly updated bug reports. Thanks.

We urgently need to look at improving how users handle their own hardware issues because the current models are unhelpful to developers and painful for both the users and the support team. Building new tools to automatically fix issues should be the focus.

So, back to your question, why now?

Ubuntu has proven itself. I don't agree with everything that's happened technically or in the community to date but the Ubuntu ecosystem appears to be the healthiest it has ever been. It isn't there yet and it needs to keep improving but why would you want to knock out the foundations at this point?

I might be completely wrong and rolling might work but we lose nothing if we stick with the 6-month cadence... What is the risk of switching to rolling? Embarrassment? Losing users? Collapsing the community? *Is any of that really worth it?*

Migrating Django's database

Oli Warner — Mon, 17 Sep 2012 16:06:42 +0100

Django is awesome but there's one job that can be a bit trickier than you're used to: moving from one database to another.

So let's pretend that you want to move from SQLite3 to PostgreSQL. It's a fairly common move for Django developers and I recently went through the process for one of my larger projects.

Your project's settings should have something a little bit like this, pointing at the current database:

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.sqlite3',
        'NAME': 'database.sqlite3',
    }
}

Sidebar: If you don't have this, you're still running on the old style of configuration. Take some time to upgrade everything to the latest Django. This tutorial assume you're at version 1.4 and won't work with the old style of database definition.

We need to add in the new database. We need to do this inline (as a new database) for reasons I'll get to:

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.sqlite3',
        'NAME': 'database.sqlite3',
    }
    'new': {
        'ENGINE': 'django.db.backends.postgresql_psycopg2',
        'NAME': 'database_name',
        'USER': 'username',
        'PASSWORD': 'password',
        'HOST': ''
    },
}

From here Django can access both databases.

Normally you should be able to run the following:

./manage.py dumpdata --database=default > data.json

./manage.py syncdb --all --database=new
./manage.py loaddata --database=new data.json

However, I ran into issues with this. contenttypes was schitzing-out. I had many errors but the main one was ContentType matching query does not exist. and I wasn't getting anywhere.

All I needed to do was handle things separately. Migrate contenttypes first and then handle the rest of my data:

./manage.py dumpdata --database=default contenttypes > ctypes.json
./manage.py dumpdata --database=default --exclude contenttypes > data.json

./manage.py syncdb --all --database=new
./manage.py loaddata --database=new ctypes.json 
./manage.py loaddata --database=new data.json

After that, just edit your settings. Rename new to default and then you can either remove the old default or rename it to something like old so you can quickly have access to it in the future.

Some people may have problems with some primary keys. You can include the argument --natural to use string-based keys but in my cases, I've only run into more problems with this method. Just splitting the data up has worked for me so far.

Why you should never log in with your Facebook account just to read news

Oli Warner — Mon, 20 Aug 2012 15:49:33 +0100

I've noticed a growing trend when you click an external link on Facebook from a desktop computer: you're asked to log in. While this might seem like it's only a minor inconvenience, in the long run this could be extremely dangerous.

If you've used Facebook in the past year, you've almost certainly seen something like this after clicking a particularly outrageous looking "Trending Article":

The old curmudgeon that I am, I swear every time I see one of these because I'm never ever going to click the Okay button. I hope you don't either.

If you do, you're what's wrong with kids these days Facebook

The dialogue's description would have you believe you're joining some hip social experiment --and I suppose you are-- but I have some spoilers for you: precisely two parties gain from you logging in like this and you're neither one of them.

The newspaper gets a ton of "basic" information about you from Facebook. Now they know roughly who you are, what you like, what your friends are like (and their public information). It's not rocket science to drop you into a very precise demographic.

They can also now track you around their site with complete immunity from all the fancy new laws to help stop websites tracking you against your will. It's actually worse than that because this is highly personalised tracking. All in all, they can now advertise at you with at least 1000% increased efficiency. And they can post on your wall to advertise to your friends.
Facebook gets all this and more. They already know your pets' names, shoe size, school, best friends, holiday locations, how often you get drunk, and everything else that happens to you.

Now when you're logged into a Trending Article partner, what you read is being broadcast to Facebook. Now Facebook has political information about its users, and the power to direct them to new political media. They might not own you but they can certainly make sure you're exposed to certain articles.

I see my personal information being tossed back and forth but where in this privacy-destroying-reach-around do I get something back?

You get to read the article, that's it.
You're trading the keys to your soul for something that is freely available.
You don't have to log in to view the content directly through their website.
You don't have to log in if you click the link from the Facebook app on your phone.

So why would you let them have all that information just because you're on a real computer? Just go to the newspapers website and search for the title. You get to read it without the colonoscopy.

The same applies to a vast number of sites where you have the option to "Connect with Facebook". Unless it's something I trust, I'm not handing over my papers just to log in. If you're still not sure, consider the following questions:

Why would you want this site to know your public information?
Would you tell a complete stranger what you're about tell this website?
Why would you want Facebook to know even more than it already does?

Sometimes I really miss the old, disjointed internet.

P.S. If you read this and it made any impression, you can nuke the relationships your Facebook account has with publishers using Facebook's Application Settings screen.

P.P.S Even if you want the media to know everything about you, it's worth checking that page to make sure there aren't any dodgy applications in there.