Click packages and how they’ll empower upstreams

As the pieces start to come together and we get closer to converging mobile and desktop in Ubuntu, Click packages running on the desktop start to feel like they will be a reality soon (Unity 8 brings us Click packages). I think it’s actually very exciting, and I thought I’d talk a bit about why that is.

First off: security. The Ubuntu Security team have done some pretty mind-blowing work to ensure Click packages are confined in a safe, reliable but still flexible manner. Jamie has explained how and why in a very eloquent manner. This will only push further an OS that is already well known and respected for being a safe place to do computing for all levels of computer skills.
My second favorite thing: simplification for app developers. When we started sketching out how Clicks would work, there was a very sharp focus on enabling app developers to have more freedom to build and maintain their apps, while still making it very easy to build a package. Clicks, by design, can’t express any external dependencies other than a base system (called a “framework”). That means that if your app depends on a fancy library that isn’t shipped by default, you just bundle it into the Click package and you’re set. You get to update it whenever it suits you as a developer, and have predictability over how it will run on a user’s computer (or device!). That opens up the possibility of shipping newer versions of a library, or just sticking with one that works for you. We exchange that freedom for some minor theoretical memory usage increases and extra disk space (if 2 apps end up including the same library), but with today’s computing power and disk space cost, it seems like a small price to pay to empower application developers.
Building on top of my first 2 favorite things comes the third: updating apps outside of the Ubuntu release cycle and gaining control as an app developer. Because Click packages are safer than traditional packaging systems, and dependencies are more self-contained, app developers can ship their apps directly to Ubuntu users via the software store without the need for specialized reviewers to review them first. It’s also simpler to carry support for previous base systems (frameworks) in newer versions of Ubuntu, allowing app developers to ship the same version of their app to both Ubuntu users on the cutting edge of an Ubuntu development release, as well as the previous LTS from a year ago. There have been many cases over the years where this was an obvious problem, OwnCloud being the latest example of the tension that arises from the current approach where app developers don’t have control over what gets shipped.
I have many more favorite things about Clicks, some more are:
– You can create “fat” packages where the same binary supports multiple architectures
– Updated between versions is transactional so you never end up with a botched app update. No more holding your breath while an update installs, hoping your power doesn’t drop mid-way
– Multi-user environments can have different versions of the same app without any problems
– Because Clicks are so easy to introspect and verify their proper confinement, the process for verifying them has been easy to automate enabling the store to process new applications within minutes (if not seconds!) and make them available to users immediately

The future of Ubuntu is exciting and it has a scent of a new revolution.

4 responses to “Click packages and how they’ll empower upstreams”

  1. As you give owncloud as a an example of things wrong with the current way, does that mean owncloud could be deployed as a click package?

    I’ve had the impression that web applications depending on a webserver and a database, like owncloud, would need to be a traditional deb package while only simpler ‘user apps’ could be deployed with click packages.

    Or would a click package allow you to bundle a webserver and database with a webapp and install all of it as a system daemon securely? That would be awesome…

    Like

  2. It will eventually have to be a click package. It’ll take a bit of time I think to make cover cases like these properly, making sure they are well confined and such.
    On the phone, long-running processes tend to be bad, so we try and mediate those via different hubs.
    On the desktop, long-running processes are more common, so it’s more likely we can change the rules for what click packages can do on a desktop.

    I can tell you that this is something that will be solved, I don’t know for sure how soon, though 🙂

    Like

  3. What about when a popular dependency bundled in lots of separate click packages has a security vulnerability (not sure if openssl is a good example here). Instead of the Ubuntu maintainers preparing a fix for release on the disclosure day (because they had advanced warning) which solves the problem for any process using that dependency, we have lots of small independent “non-openssl-expert” developers who have to patch each and every one of the applications? Is there something I’m missing, or could this be a really bad scenario?

    Like

    1. Yes, that’s one of the trade-offs. The key is for the system to provide enough that applications don’t generally need to bundle things like SSL. The fact that applications are confined goes a long way to minimising the risk of security issues in the applications themselves.

      Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: