Archive for the 'ubuntu' Category

Every detail matters, and building great software means taking time to remove the papercuts. Ubuntu has over the past 5 years been refined in many ways to feel amazingly comfortable on the cloud. In the very early days of EC2 growth the Ubuntu team recognised how many developers were enjoying fast access to infrastructure on demand, and we set about polishing up Ubuntu to be amazing on the cloud.

This was a big program of work; the Linux experience had many bad assumptions baked in – everything had been designed to be installed once on a server then left largely untouched for as long as possible, but cloud infrastructure was much more dynamic than that.

We encouraged our team to use the cloud as much as possible, which made the work practical and motivated people to get it right themselves. If you want to catch all the little scratchy bits, make it part of your everyday workflow. Today, we have added OpenStack clouds to the mix, as well as the major public clouds. Cloud vendors have taken diverse approaches to IAAS so we find ourselves encouraging developers to use all of them to get a holistic view, and also to address any cloud-specific issues that arise. But the key point is – if it’s great for us, that’s a good start on making it great for everybody.

Then we set about interviewing cloud users and engaging people who were deep into cloud infrastructure to advise on what they needed. We spent a lot of time immersing ourselves in the IAAS experience through the eyes of cloud users – startups and industrial titans, universities and mid-sized, everyday companies. We engaged the largest and fastest-moving cloud users like Netflix, who have said they enjoy Ubuntu as a platform on the cloud. And that in turn drove our prioritisation of paper-cuts and significant new features for cloud users.

We also looked at the places people actually spend time developing. Lots of them are on Ubuntu desktops, but Windows and MacOS are popular too, and it takes some care to make it very easy for folks there to have a great devops experience.

All of this is an industrial version of the user experience design process that also powers our work on desktop, tablet and phone – system interfaces and applications. Devops, sysadmins, developers and their managers are humans too, so human-centric design principles are just as important on the infrastructure as they are on consumer electronics and consumer software. Feeling great at the command line, being productive as an operator and a developer, are vital to our community and our ecosystem. We keep all the potency of Linux with the polish of a refined, designed environment.

Along the way we invented and designed a whole raft of key new pieces of Ubuntu. I’ll write about one of them, cloud-init, next. The net effect of that work makes Ubuntu really useful on every cloud. That’s why the majority of developers using IAAS do so on Ubuntu.

The very best edge of all

Saturday, March 8th, 2014

Check out “loving the bottom edge” for the most important bit of design guidance for your Ubuntu mobile app.

This work has been a LOT of fun. It started when we were trying to find the zen of each edge of the screen, a long time back. We quickly figured out that the bottom edge is by far the most fun, by far the most accessible. You can always get to it easily, it feels great. I suspect that’s why Apple has used the bottom edge for their quick control access on IOS.

progresion

We started in the same place as Apple, thinking that the bottom edge was so nice we wanted it for ourselves, in the system. But as we discussed it, we started to think that the app developer was the one who deserved to do something really distinctive in their app with it instead. It’s always tempting to grab the tastiest bit for oneself, but the mark of civility is restraint in the use of power and this felt like an appropriate time to exercise that restraint.

Importantly you can use it equally well if we split the screen into left and right stages. That made it a really important edge for us because it meant it could be used equally well on the Ubuntu phone, with a single app visible on the screen, and on the Ubuntu tablet, where we have the side stage as a uniquely cool way to put phone apps on tablet screens alongside a bigger, tablet app.

The net result is that you, the developer, and you, the user, have complete creative freedom with that bottom edge. There are of course ways to judge how well you’ve exercised that freedom, and the design guidance tries to leave you all the freedom in the world while still providing a framework for evaluating how good the result will feel to your users. If you want, there are some archetypes and patterns to choose from, but what I’d really like to see is NEW patterns and archetypes coming from diverse designs in the app developer community.

Here’s the key thing – that bottom edge is the one thing you are guaranteed to want to do more innovatively on Ubuntu than on any other mobile platform. So if you are creating a portable app, targeting a few different environments, that’s the thing to take extra time over for your Ubuntu version. That’s the place to brainstorm, try out ideas on your friends, make a few mockups. It’s the place you really express the single most important aspects of your application, because it’s the fastest, grooviest gesture in the book, and it’s all yours on Ubuntu.

Have fun!

OpenStack has emerged as the consensus forum for open source private cloud software. That of course makes it a big and complex community, with complex governance and arguably even more complex politics, but it has survived several rounds of competition and is now settling down as THE place to get diverse vendors to work together on a IAAS that anybody can deploy for themselves. It is a big enough forum with sufficient independent leadership that no one vendor will ever control it (despite some fantastically impressive efforts to do so!). In short, OpenStack is what you want if you are trying to figure out how to build yourself a cloud.

And by quite a large majority, most of the people who have actually chosen to deploy OpenStack in production, have done so on Ubuntu.

At the latest OpenStack summit, an official survey of production OpenStack deployments found 55% of them on Ubuntu, a stark contrast with the 10% of OpenStack deployments on RHEL.

Canonical and Ubuntu play an interesting role in OpenStack. We do not seek to control any particular part of the project, although some of our competitors clearly think that would be useful for them to achieve, we think OpenStack would be greatly diminished in importance if it was perceived to be controlled by a single vendor, and we think there are enough contributors and experts around the table to ensure that the end result cannot actually be controlled by a single party. To a certain extent, the battle for notional control of key aspects of OpenStack just holds the project back; it’s a distraction from the real task at hand, which is to deliver a high quality, high performance open cloud story. So our focus is on supporting the development of OpenStack, supporting the broadest range of vendors who want to offer OpenStack solutions, components and services, and enabling a large ecosystem to accelerate the adoption of OpenStack in their markets.

It’s a point of pride for us that you can get an OpenStack cloud built on Ubuntu from just about every participant in the OpenStack ecosystem – Dell, HP, Mirantis, and many more – we think the healthiest approach is for us to ensure that people have great choices when it comes to their cloud solution.

We were founding members and are platinum sponsors of the OpenStack Foundation. But what’s more important to us, is that most OpenStack development happens on Ubuntu. We take the needs of OpenStack developers very seriously – for 14.04 LTS, our upcoming bi-annual enterprise release, a significant part of our product requirements were driven by the goal of supporting large-scale enterprise deployments of OpenStack with high availability as a baseline. Our partners like HP, who run one of the largest OpenStack public cloud offerings, invest heavily in OpenStack’s CI and test capabilities, ensuring that OpenStack on Ubuntu is of high quality for anybody who chooses the same base platform.

We publish stable, maintained archives of each OpenStack release for the LTS releases of Ubuntu. That means you can ALWAYS deploy the latest version of OpenStack on the current LTS of Ubuntu, and there is a clear upgrade path as new versions of both OpenStack and Ubuntu are released. And the fact that the OpenStack release cadence and the Ubuntu release cadence are perfectly aligned is no accident – it ensures that the OpenStack developers can always deliver their latest code straight to a very large audience of developers and operators. That’s important because of the extraordinary pace of innovation inside OpenStack; there are significant and valuable improvements in each six-month release, so customers, even enterprise customers, find themselves wanting a more aggressive upgrade schedule for OpenStack than is normal for them in platform environments. We support that and have committed to continue doing so, though we do expect the urgency of those upgrades to diminish as OpenStack matures over the next three years.

For commercial support of OpenStack, we are happy for industry to engage either with our partners who can provide local talent combined with an escalation path to Canonical for L3 support of the whole solution, or directly with Canonical if the circumstances warrant it. That means building on Ubuntu opens up a wide range of solution providers who can make the same high commitment to SLAs and upgrades.

For Canonical itself, our focus is on scale and quality. Our direct customers run the very largest production deployments of OpenStack, both private and public, and we enjoy collaborating with their architects to push the limits of the stack as it stands today. That gives us a lot of insight into the approaches being taken by a wide range of architects in telco, finance and media. We ourselves invest very heavily in testing, continuous integration, and interoperability, with the largest OpenStack interop program (OIL) that gives us the ability to speak with confidence about what combinations of vendor offerings will actually work, and in many cases, how they will perform together for different applications.

The fact that the traditional enterprise Linux vendors have now joined OpenStack is a tremendous validation of the role that OpenStack has assumed in industry: THE open cloud forum. But for all the reasons outlined above, most of the actual production deployments of OpenStack are not on traditional, legacy enterprise Linux. This mirrors the public cloud, where even the largest and most mission-critical deployments tend not to be on proprietary Linux offerings; the economics of HA single-node solutions just don’t apply in a scale-out environment. So just as Ubuntu is by far the most widely used platform for public cloud guests, it is also on track to be the enterprise choice for scale-out infrastructure like IAAS, storage, and big data. Even if you have always done Linux a particular way, the transition to scale-out thinking is an opportunity to reset expectations about your base OS; and for the fastest-moving players in telco, media and finance, Ubuntu turns out to be a great way to get more done, more efficiently.

In a series of 12 posts, I’ll make the case for Ubuntu as the platform of choice for public clouds, enterprise clouds and related scale-out initiatives.

Cloud computing is largely being defined on public clouds today. There are a range of initiatives for private cloud computing – some proprietary, some open – but for sheer scale and traction, the game today is all about public cloud services. Azure, AWS, a range of offerings from telco’s and service providers together with innovative takes on the concept from hardware OEMs have been the leading edge of the cloud market for the past five years. We do expect private clouds to flourish around OpenStack, but we expect the gene pool of innovation to stay on the public clouds for some time.

And what do people run on public clouds? By substantial majority, most of that innovation, most of that practical experience and most of the insights being generated are on Ubuntu.

Digital Ocean, the fastest growing new challenger in the US public cloud market, published definitive statistics on the share of operating systems that customers choose on their cloud:

Ubuntu has 67% share of the Digital Ocean public cloud

Ubuntu is the most popular OS on public clouds, by far.

AWS hasn’t spoken publicly on the topic but there are a number of measurements by third parties that provide some insight. For example,  SCALR offer a management service that is used by enterprises looking for more institutional management control of the way their teams use Amazon. One might think that an enterprise management perspective would be skewed away from Ubuntu towards traditional, legacy enterprise Linux, but in fact they find that Ubuntu is more than 70% of all the images they see, three times as popular as CentOS.

There is no true safety in numbers, but there is certainly reassurance. Using a platform that is being used by most other people means that the majority of the content you find about how to get things done efficiently is immediately relevant to you. Version skew – subtle differences in the versions of components that are available by default on your platform of choice – is much less of an issue if the guidebook you are reading assumes you’re on the same platform they used.

There is also the question of talent – finding people to get amazing things done on the cloud is a lot easier if you let them use the platforms they have already grown comfortable with. They can be more productive, and there are many more of them around to hire. Talking to companies about cloud computing today it’s clear their biggest constraint is knowledge acquisition; the time it takes to grow own internal skills or to hire in the necessary skills to get the job done. Building on Ubuntu gives you a much broader talent and knowledge base to work with. Training your own team to use Ubuntu if they are familiar with another Linux is a relatively minor switch compared to the fundamental challenge of adopting a IAAS-based architecture. Switching to Ubuntu is the fastest way to tame that dragon, and the economics are great, too.

That’s why we see many companies that have been doing Linux one way for a decade switching to Ubuntu when they switch to the cloud. Even if what they are doing on the cloud is essentially the same as something they already do on another platform, it’s “easier with Ubuntu on the cloud”, so they switch.

Losing graciously

Friday, February 14th, 2014

With Bdale Garbee’s casting vote this week, the Debian technical committee finally settled the question of init for both Debian and Ubuntu in favour of systemd.

I’d like to thank the committee for their thoughtful debate under pressure in the fishbowl; it set a high bar for analysis and experience-driven decision making since most members of the committee clearly took time to familiarise themselves with both options. I know the many people who work on Upstart appreciated the high praise for its code quality, rigorous testing and clarity of purpose expressed even by members who voted against it; from my perspective, it has been a pleasure to support the efforts of people who want to create truly great free software, and do it properly. Upstart has served Ubuntu extremely well – it gave us a great competitive advantage at a time when things became very dynamic in the kernel, it’s been very stable (it is after all the init used in both Ubuntu and RHEL 6 ;) and has set a high standard for Canonical-lead software quality of which I am proud.

Nevertheless, the decision is for systemd, and given that Ubuntu is quite centrally a member of the Debian family, that’s a decision we support. I will ask members of the Ubuntu community to help to implement this decision efficiently, bringing systemd into both Debian and Ubuntu safely and expeditiously. It will no doubt take time to achieve the stability and coverage that we enjoy today and in 14.04 LTS with Upstart, but I will ask the Ubuntu tech board (many of whom do not work for Canonical) to review the position and map out appropriate transition plans. We’ll certainly complete work to make the new logind work without systemd as pid 1. I expect they will want to bring systemd into Ubuntu as an option for developers as soon as it is reliably available in Debian, and as our default as soon as it offers a credible quality of service to match the existing init.

Technologies of choice evolve, and our platform evolves both to lead  (today our focus is on the cloud and on mobile, and we are quite clearly leading GNU/Linux on both fronts) and to embrace change imposed elsewhere. Init is contentious because it is required for both developers and system administrators to understand its quirks and capabilities. No wonder this was a difficult debate, the consequences for hundreds of thousands of people are very high. From my perspective the fact that good people were clearly split suggests that either option would work perfectly well. I trust the new stewards of pid 1 will take that responsibility as seriously as the Upstart team has done, and be as pleasant to work with. And… onward.

All Star ‘Buntu

Wednesday, February 12th, 2014

As prep for the upcoming 14.04 LTS release of Ubuntu I spent some quality time with each of the main flavours that I track – Kubuntu, Ubuntu GNOME, Xubuntu, and Ubuntu with the default DE, Unity.

They are all in really great shape! Thanks and congratulations to the teams that are racing to deliver Trusty versions of their favourite DE’s. I get the impression that all the major environments are settling down from periods of rapid change and stress, and the timing for an LTS release in 14.04 is perfect. Lucky us :)

The experience reminded me of something people say about Ubuntu all the time – that it’s a place where great people bring diverse but equally important interests together, and a place where people create options for others of which they are proud. You want options? This is the place to get them. You want to collaborate with amazing people? This is the place to find them. I’m very grateful to the people who create those options – for all of them it’s as much a labour of love as a professional concern, and their attention to detail is what makes the whole thing sing.

Of course, my testing was relatively lightweight. I saw tons of major improvements in shared apps like LibreOffice and Firefox and Chromium, and each of the desktop environments feels true to its values, diverse as those are. What I bet those teams would appreciate is all of you taking 14.04 for a spin yourselves. It’s stable enough for any of us who use Linux heavily as an engineering environment, and of course you can use a live boot image off USB if you just want to test drive the future. Cloud images are also available for server testing on all the major clouds.

Having the whole team, and broader community, focus on processes that support faster development at higher quality has really paid off. I’ve upgraded all my systems to Trusty and those I support from afar, too, without any issues. While that’s mere anecdata, the team has far more real data to support a rigorous assessment of 14.04′s quality than any other open platform on the planet, and it’s that rigour that we can all celebrate as the release date approached. There’s still time for tweaks and polish; if you are going to be counting on Trusty, give it a spin and let’s make sure it’s perfect.

Rigor and its results

Friday, December 20th, 2013

Perhaps the biggest change in Ubuntu since 12.04 LTS has been our shift, under Rick’s leadership, towards rigorous, highly automated, test-based QA across all of Ubuntu – server, desktop and mobile.

And what I love about the process is:

  • it’s completely transparent – check out http://ci.ubuntu.com/ and drill down to see the individual test runs
  • it spans every product – server, desktop and mobile, across a wide and growing range of hardware
  • the team takes it absolutely seriously and “stops the line” to fix issues on a regular basis

This is the result of two years hard work by an amazing team – at the package testing and system test level – to help us raise the bar for free software platforms.

This is what the 64-bit x86 server test run looks like today:

Automated testing of the Ubuntu Server platform gives us quick feedback on breaking changes.

Automated testing of the Ubuntu Server platform gives us quick feedback on breaking changes.

 

Over time, thanks to contributions of tests by community, partners and Canonical folks, the number of tests has grown substantially. In the mobile environment we run over 400 smoke tests on every build of every image:

 

Automated test results on a Nexus device.

Automated test results on a Nexus device.

 

In addition to the system image testing you see here, there is a growing portfolio of package-level tests, and processes that test changes both for problems inside the modified package AND for packages that depend on it. So increasingly, we are able to pick up on a problem before it spreads to any developer desktops that are tracking the tip of development.

Testing makes us smarter

It’s significantly more challenging to create test harnesses than code itself. Building this capability exercised our best contributors for the better part of two years; every team has had to figure out how to “get meta” on the parts of Ubuntu they care about. And in the process, we come to a deeper understanding of what it is that users care about, how our platform fits together, and the magic that lives inside the kernel that enables much of this work to happen at scale and in an automated fashion. Grappling with hard problems is like training; the more you do it, the better you understand what’s possible.

Testing helps us go faster

It’s a curious phenomenon that taking time to work on the stuff around the code helps to get the code done faster. But in something as large and complex as a free software platform, change is both your friend and your enemy. Every week thousands of changes flow into Ubuntu from a huge range of sources, and it’s impossible for any on person to anticipate the consequences of every change in advance. Having a rigorous, automated test framework tells us immediately when a change causes a problem somewhere else. Greater confidence that problems will be caught lets us move faster with changes, knowing we can either revert them quickly or stop the line to concentrate everyone’s attention on the issue when it touches a broad swath of the platform.

Testing brings more eyeballs

I run the tip of development – Trusty today – because I can trust the team to spot a problem before it affects me almost every time. That gives me a better view on how Ubuntu is evolving day by day and the ability to ask questions when they are relevant, not right before release. For developers at upstreams or in companies where Trusty is going to be a key platform, the ability to exercise it personally is a huge advantage; you can directly influence the trajectory best if you know where things stand at any given moment. So more rigour translates into more eyeballs which translates into a better result for everybody down the line.

 

We expect to ship our first Ubuntu mobile devices in 2014, and this initiative gives me confidence that we can bring new features and capabilities and improvements to those users fast. And that’s one of the things that makes Ubuntu great.

Mistakes made and addressed

Sunday, November 10th, 2013

Occasionally we make mistakes. When we do it’s appropriate to apologise, address them, and take steps to ensure they don’t happen again.

Last week, someone at Canonical made a mistake in sending the wrong response to a trademark issue out of the range of responses we usually take. That has been addressed, and steps are being taken to reduce the likelihood of a future repeat.

By way of background, there are a number of trademarks around the Ubuntu name and logo which we are required to “enforce” or risk losing them altogether. In normal companies, the rule is that nobody else gets to use your logo. In Canonical, we have a policy that says that there are lots of cases where people DO get to use our name and logo; this is because our policy takes the internet-friendly view that communities need to have rights to a name if they want to feel like they are part of something; we go even further and explicitly allow the use of our name for elements of satire and mirth around Ubuntu. Every country has different rules about trademarks and free speech, we have a global policy that is more generous than most jurisdictions by default.

We do have to “enforce” those trademarks, or we lose them. That means:

  • we have an email address, trademarks@ubuntu.com, where people can request permission to use the name and logo
  • we actively monitor, mostly using standard services, use of the name and logo
  • we aim to ensure that every use of the name and logo is supported by a “license” or grant of permission

As you can imagine, that is a lot of work. A lot of what we find out there is fine, fun, harmless or constructive. Sometimes however it’s pretty nasty: we have had OEMs forging Ubuntu certifications to meet requirements for government tenders, for example.

In order to make the amount of correspondence manageable, we have a range of standard templates for correspondence. They range from the “we see you, what you are doing is fine, here is a license to use the name and logo which you need to have, no need for further correspondence”, through “please make sure you state you are speaking for yourself and not on behalf of the company or the product”, to the “please do not use the logo without permission, which we are not granting unless you actually certify those machines”, and “please do not use Ubuntu in that domain to pretend you are part of the project when you are not”.

Last week, the less-than-a-month-at-Canonical new guy sent out the toughest template letter to the folks behind a “sucks” site. Now, that was not a decision based on policy or guidance; as I said, Canonical’s trademark policy is unusually generous relative to corporate norms in explicitly allowing for this sort of usage. It was a mistake, and there is no question that the various people in the line of responsibility know and agree that it was a mistake. It was no different, however, than a bug in a line of code, which I think most developers would agree happens to the best of us. It just happened to be, in that analogy, a zero-day remote root bug.

The internets went wild, Wired picked a headline accusing Canonical of a campaign to suppress critics, Debian started arguing about whether it should remove all references to the distro-that-shall-not-be-named but then decided to argue about whether it should enforce its own trademarks which lead to an argument about… oh never mind. The point is, people are judging Canonical over this, which is fine and correct in my view, because I am judging Canonical over this too.

Here’s how I’m judging Canonical. Your framework may vary, but I think this is quite a defensible one.

Judge the policy. In this case Canonical has a trademark policy that enables community members to use the marks (good) and allows for satire and sucks sites even in jurisdictions where the local law does not (great!). Failing to have a policy would not be a bonus point in this review :)

Judge the execution of the policy. Canonical does the work needed to maintain the marks; it monitors and responds to requests and notifications around the marks (good). In this case, the wrong action was taken – a new employee was clearly not properly briefed about policy and sensitivities in a key audience for the company (bad).

Judge the response to the incident. Within hours of the publication of a response to our letter, the CEO, COO and legal team reviewed the decision, corrected the action and addressed the matter publicly. I apologised the moment I was made aware of the incident. And I’m reassured that the team in question is taking steps in training and process to minimise the risk of a recurrence.

For those carrying pitchforks and torches on this issue, ask yourself if that would be appropriate to a bug in a line of code in one of many thousands of changes being made monthly by a large team. No? Think about it.

 

On another, more personal note, I made a mistake myself when I used the label “open source tea party” to refer to the vocal non-technical critics of work that Canonical does. That was unnecessary and quite possibly equally offensive to members of the real Tea Party (hi there!) and the people with vocal non-technical criticism of work that Canonical does (hello there!).

For the record, technical critique of open source software is part of what makes open source software so good. It is welcome and appreciated very much at Canonical; getting reviews and feedback and suggestions for improvement from smart people who care is part of why we enjoy writing open source software. There isn’t anything in what I said to suggest that I don’t welcome such technical feedback, but some assumed I was rejecting all feedback including technical commentary. I was not – I was talking about criticism of software which does not centre on the software itself, but rather on some combination of the motivations of the people who wrote it, or the particular free  software license under which it is published, or the policies of the company, or the nationality of the company behind it. Unless critique is focused on improving the software in question it is pretty much a waste of the time of the people who are trying to improve the software in question. That waste of time is what I had in mind with the comment; nevertheless, it was a thoughtless use of an irrelevant label. Please accept my apologies if you have been a vocal non-technical critic of Canonical’s software and felt offended by the label.

Quantal, raring, saucy…

Friday, October 18th, 2013

Before I launch into the tongue-twisting topic of t-series terminology I would like to say a few thank-you’s.

Saucy, now officially known as Ubuntu 13.10, is a wonderful achievement by a very large and diverse collection of teams and individuals. Each of us is motivated by something different – in fact, we might have very different visions of what the ideal desktop looks like or what the default set of applications should be. But we manage, in the spirit of ubuntu, to work together to make something wonderful like 13.10, which serves the needs and goals of a very large number of people and communities.

This release had plenty to put it under pressure. It’s the preview-LTS, in a sense, which means we need to get a lot of the “big rocks” in. That means a willingness to lead change, and doing so in such a complex inter-dependent environment is very challenging. I would like to thank all the teams who have done their part to shape that change into something that worked for them. To the KDE, XFCE and GNOME-focused communities in Ubuntu, thank you for bringing your perspective and I’m delighted that you are all making such great releases now as well.

13.10 is a very special release for me because I think we are leading the GNU/Linux world into a very important arena, which is mobile personal computing. Canonical has its fair share of competitors and detractors who love to undermine the work it does, but I think that wiser heads appreciate the magnitude of the effort required to break this ice, and the extent to which it has taken courage and grace under fire for this team to deliver such a sharp 1.0 of the mobile experience for Ubuntu. It is a reflection of the widespread interest and enthusiasm for that work that we had such diverse participation in the core applications that make up this 1.0 of Ubuntu-for-phones. Multiple teams formed spontaneously to explore new territory: a new mobile design paradigm, new SDK, new visual language. And wow, you guys pulled it off beautifully.  So many contributions from a fresh free software community is testament to the work and style of guys like Michael Hall, who epitomise collaborative development and friendly exchanges of views, motivating guys like me and a hundred others to make sure we deliver something great.

Designers, shell engineers, browser engineers, app engineers, people who built app review and publication mechanisms, security experts… I could not be more proud of what these teams have achieved together.

For the technologists there are some very significant milestones, what Rick Spencer calls “the big rocks”, that made it into 13.10.

Image based updates is really important work. For the first time we can guarantee the integrity of a device running Ubuntu, knowing exactly what version of the OS is installed. I can’t wait to get that on my laptop. Yes, it will be a big change, but I can already see how it’s going to make things easier for me. And I’ll still have the full power of raw Ubuntu inside for all my cloud development needs. Well done to the guys who conceived and delivered the mechanism and the machinery that make it possible. Image 100 is, as they say, the cake.

Mir is really important work. When lots of competitors attack a project on purely political grounds, you have to wonder what THEIR agenda is. At least we know now who belongs to the Open Source Tea Party ;) And to put all the hue and cry into context: Mir is relevant for approximately 1% of all developers, just those who think about shell development. Every app developer will consume Mir through their toolkit. By contrast, those same outraged individuals have NIH’d just about every important piece of the stack they can get their hands on… most notably SystemD, which is hugely invasive and hardly justified. Watch closely to see how competitors to Canonical torture the English language in their efforts to justify how those toolkits should support Windows but not Mir. But we’ll get it done, and it will be amazing.

I can tell you what the agenda of the Mir team is: speed, quality, reliability, efficiency. That’s it. From what I’ve seen on the smartphone, Mir is going to be a huge leap forward for gaming performance, battery life and next-generation display capabilities. So thank you for the many contributions we had to Mir, and to everyone who is testing it in more challenging environments than the smartphone. I’m enjoying it on my laptop and loving the gaming benchmarks for native Mir. So to that team, and the broader community who are helping test and refine Mir, thank you.

App containers and the associated mechanisms for application update are hugely important too. We now have a much better way for app developers to deliver an app to Ubuntu users, giving them much more control of the libraries and dependencies and updates that will affect them. We also make it much easier for developers to deliver newer versions of their app on older versions of the OS. I know that’s a top ask for many of our users, and we’ve done it for the smartphone. It will be available for the desktop as soon as we converge the two. I love seeing those app updates flow onto the phone, and I’m told the developer review and publication process is really sweet. Well done.

So yes, I am very proud to be, as the Register puts it, the Ubuntu Daddy. My affection for this community in its broadest sense – from Mint to our cloud developer audience, and all the teams at Canonical and in each of our derivatives, is very tangible today. It’s had its ups and downs this cycle :) but I feel we’ve pulled together. What the Register misses in that description is that so many of you are in fact the progenitors of Ubuntu’s goodness. Its a privilege to provide the conduit, but the generosity of all of you in making something wonderful to share through that conduit is what’s most touching.

So – saucy is in the can, and it’s time to turn our tactical talk to 14.04, which will of course be an LTS.

As such, our focus is going to be on performance, refinement, maintainability, technical debt. It would be entirely appropriate for us to make conservative choices in this upcoming vUDS, so please join us in those discussions as we shape 14.04 as a platform for long-term deployments on the PC and the cloud and the server. In particular, we will be providing OpenStack I, J and K on 14.04 for LTS deployments, so we need to make sure we meet the needs of that community for a solid core. On the desktop, 13.10 has benefited greatly from the fact that it has a team just focused on improving quality. We’ll do the same again and more for 14.04. On the mobile front, we’re going to keep racing forward, the platform is too new for an LTS and we’re excited to complete the journey of full convergence. We won’t get there in one cycle but given the pace of improvement of the phone and tablet in the last month I think it’s going to be a fantastic cycle there.

vUDS is where those core decisions are made. We’ve broken new ground on public consultation and discussion: anyone can participate by voice or video, discussions are fast and open-minded, results are communicated in the same week. It’s worth taking time out from work, play or sleep to bring your perspective to bear on what 14.04 needs to deliver, and what commitments you want to make to achieve that.

But… what will we call it? As TS Eliot put it, “the naming of cats is a difficult matter, it isn’t just one of your everyday games…”

It’s no trifling matter to tap the well of tempting tautological taxa in search of just the right mascot for something like 14.04. So many bad options! There’s the “tasty tailless tenrec” (wait for the letters from PETA), the “toxic taipan” (hello again my Aussie mates), and the  ”tantric tarantula” (hold very still…). The “trigamous tayra” (bendy!) and “trippy tegu” just won’t do. We need something a bit more serious than the “twinkle-toed tamarin”, something a bit more transcendent than the the “toric terrapin”, a bit more thematic than the “thermic tamandua” (though I do like the reference to HEAT, something new in the OpenStack world) and a bit cooler than the “thermobaric thornytail”. There are quite a few good options too… Consider the “timely testudo”, that famous winning tortoise, or the “tenacious tapir” who always gets the job done, those might do. And who could resist the “telegenic tamias” other than, perhaps, the developers who have to type “telegenic” every time they make an upload!

Themes therianthropic seem a touch tub-thumping, and tigers Tasman a touch extinct. That tarsier is tactile but titchy too, the toad a bit witchy the the tree shrew, too-too. For a tip-top release nothing tepid will do.

So our titular totem, our tamper-proof taboo, our tranquil memento of mission and dues, our topical target of both cry and hue, the name for our LTS thoughtful and true: I give you, as Seuss would, with hullabaloo, the temperate and thrifty, the talented and tactful but ultimately, and tellingly, trusty tahr.

The tahr navigates Himalayan heights, shaggily suited, sure-footed and steady. A small tourist tahr population lived on my favourite Table Mountain, and while they’ve made way for indigenous animals, for a long time they symbolised hardiness and fearlessness, perched as they were against the cliffs. We’ll do well together. Let’s get cracking!

Two weeks with Mir

Tuesday, July 9th, 2013

Mir has been running smoothly on my laptop for two weeks now. It’s an all-Intel Dell XPS, so the driver stack on Ubuntu is very clean, but I’m nonetheless surprised that the system feels *smoother* than it did pre-Mir. It might be coincidence, Saucy is changing pretty fast and new versions of X and Compiz have both landed while I’ve had Mir running. But watching top suggests that both Xorg and Compiz are using less memory and fewer CPU cycles under Mir than they were with X handling the hardware directly.

Talking with the Mir team, they say others have seen the same thing, and they attribute it to more efficient buffering of requests on the way to the hardware. YMMV but it’s definitely worth trying. I have one glitch which catches me out – Chromium triggers an issue in the graphics stack which freezes the display. Pressing Alt-F1 unfreezes it (it causes Compiz to invoke something which twiddles the right bits to bring the GPU back from it’s daze). I’m told that will get sorted trivially in a coming update to the PPA.

The overall impression I have is that Mir has delivered what we hoped. Perhaps it had the advantage of being able to study what went before – SurfaceFlinger, Wayland, X – and perhaps also the advantage of looking at things through the perspective of a mobile lens, where performance and efficiency are a primary concern, but regardless, it’s lean, efficient, high quality and brings benefits even when running a legacy X stack.

We take a lot of flack for every decision we make in Ubuntu, because so many people are affected. But I remind the team – failure to act when action is needed is as much a failure as taking the wrong kind of action might be. We have a responsibility to our users to explore difficult territory. Many difficult choices in the past are the bedrock of our usefulness to a very wide audience today.

Building a graphics stack is not a decision made lightly – it’s not an afternoon’s hacking. The decision was taken based on a careful consideration of technical factors. We need a graphics stack that works reliably across a very wide range of hardware, that performs predictably, that provides a consistent quality of user experience on many different desktop environments.

Of course, there is competition out there, which we think is healthy. I believe Mir will be able to evolve faster than the competition, in part because of the key differences and choices made now. For example, rather than a rigid protocol that can only be extended, Mir provides an API. The implementation of that API can evolve over time for better performance, while it’s difficult to do the same if you are speaking a fixed protocol. We saw with X how awkward life becomes when you have a fixed legacy protocol and negotiate over extensions which themselves might be versioned. Others have articulated the technical rationale for the Mir approach better than I can, read what they have to say if you’re interested in the ways in which Mir is different, the lessons learned from other stacks, and the benefits we see from the architecture of Mir.

Providing Mir as an option is easy. Mir is a very focused part of the stack, it has far fewer tentacles and knock-on consequences for app developers than, say, the init system, which means we should be able to work with a very tight group of communities to get great performance. It’s much easier for a distro to engage with Mir than to move to SystemD, for example; instead of an impact on every package, there is a need to coordinate in just a few packages for great results. We’ve had a very positive experience working with the Qt and WebKit communities, for example, so we know those apps will absolutely fly and talk Mir natively. Good upstreams want their code widely useful, so I’ve no doubt that the relevant toolkits will take patches that provide enhanced capabilities on Mir when available. And we also know that we can deliver a high-performance X stack on Mir, which means any application that talks X, or any desktop environment that talks X, will perform just as well with Mir, and have smoother transitions in and out thanks to the system compositor capabilities that Mir provides.

On Ubuntu, we’re committed that every desktop environment perform well with Mir, either under X or directly. We didn’t press the ‘GO’ button on Mir until we were satisfied that the whole Ubuntu community, and other distributions, could easily benefit from the advantages of a leaner, cleaner graphics stack. We’re busy optimising performance for X now so that every app and every desktop environment will work really well in 13.10 under Mir, without having to make any changes. And we’re taking patches from people who want Mir to support capabilities they need for native, super-fast Mir access. Distributions should be able to provide Mir as an option for their users to experiment with very easily – the patch to X is very small (less than 500 lines). For now, if you want to try it, the easiest way to do so is via the Ubuntu PPA. It will land in 13.10 just as soon as our QA and release teams are happy that its ready for very widespread testing.