Building clouds for fun and profit

Monday, September 19th, 2011

So you’d like to spin up an internal cloud for hadoop or general development, shifting workloads from AWS to your own infrastructure or prototyping some new cloud services?

Call Canonical’s cloud infrastructure design and consulting team.

There are a couple of scenarios that we’re focused on at the moment, where we can offer standardised engagements:

  • Telco’s building out cloud infrastructures for public cloud services. These are aiming for specific markets based on geography or network topology – they have existing customers and existing networks and a competitive advantage in handling outsourced infrastructure for companies that are well connected to them, as well as a jurisdictional advantage over the global public cloud providers.
  • Cloud infrastructure prototypes at a division or department level. These are mostly folk who want the elasticity and dynamic provisioning of AWS in a private environment, often to work on products that will go public on Rackspace or AWS in due course, or to demonstrate and evaluate the benefits of this sort of architecture internally.
  • Cloud-style legacy deployments. These are folk building out HPC-type clusters running dedicated workloads that are horizontally scaled but not elastic. Big Hadoop deployments, or Condor deployments, fall into this category.

Cloud has become something of a unifying theme in many of our enterprise and server-oriented conversations in the past six months. While not everyone is necessarily ready to shift their workloads to a dynamic substrate like Ubuntu Cloud Infrastructure (powered by OpenStack) it seems that most large-scale IT deployments are embracing cloud-style design and service architectures, even when they are deploying on the metal. So we’ve put some work into tools which can be used in both cloud and large-scale-metal environments, for provisioning and coordination.

With 12.04 LTS on the horizon, OpenStack exploding into the wider consciousness of cloud-savvy admins, and projects like Ceph and CloudFoundry growing in stature and capability, it’s proving to be a very dynamic time for IT managers and architects. Much as the early days of the web presented a great deal of hype and complexity and options, only to settle down into a few key standard practices and platforms, cloud infrastructure today presents a wealth of options and a paucity of clarity; from NoSQL choices, through IAAS choices, through PAAS choices. Over the next couple of months I’ll outline how we think the cloud stack will shape up. Our goal is to make that “clean, crisp, obvious” deployment Just Work, bringing simplicity to the cloud much as we strive to bring it on the desktop.

For the moment, though, it’s necessary to roll up sleeves and get hands a little dirty, so the team I mentioned previously has been busy bringing some distilled wisdom to customers embarking on their cloud adventures in a hurry. Most of these engagements started out as custom consulting and contract efforts, but there are now sufficient patterns that the team has identified a set of common practices and templates that help to accelerate the build-out for those typical scenarios, and packaged those up as a range of standard cloud building offerings.


Surveying participation

Friday, September 9th, 2011

Just a brief note to celebrate Jono and team’s recent work on gathering insight into our membership and developer participation processes. Thanks also to those who took time to comment for the surveys. The results are worth a read if you care about the vibrancy and dynamism of our community. Kudos Jono, and thanks!

Dash takes shape for 11.10 Unity

Tuesday, August 16th, 2011

Our goal with Unity is unprecedented ease of use, visual style and performance on the Linux desktop. With feature freeze behind us, we have a refined target render of the Dash for Oneiric, and here it is:

click for the full size render.

Scopes and Lenses

We’ve moved from the idea of “Places” to a richer set of “Scopes and Lenses”. Scopes are data sources, and can tap into any online or offline data set as long as they can generate categorised results for a search, describe a set of filters and support some standard interfaces. Lenses are various ways to present the data that come from Scopes.

The Scopes have a range of filtering options they can use, such as ratings (“show me all the 5 star apps in the Software Center please”) and categories (“… that are games or media related”). Over time, the sophistication of this search system will grow but the goal is to keep it visual and immediate – something anyone can drive at first attempt.

This delivers on the original goal of creating a device-like experience that was search driven. Collaboration with the always-excellent Zeitgeist crew (quite a few of whom are now full time on the Unity team!) has improved the search experience substantially, kudos to them for the awesome work they’ve put in over the past six months. Since we introduced the Dash as a full screen device-like search experience, the same idea has made its way into several other shells, most notably Mac OS X Lion. While we’re definitely the outsider in this contest, I think we can stay one step ahead in the game given the support of our community.

The existing Places are all in the process of being updated to the Scopes and Lenses model, it’s a bit of a construction site at the moment so hard-hats are advised but dive in if you have good ideas for some more interesting scopes. I’ve heard all sorts of rumours about cool scopes in the pipeline 😉 and I bet this will be fertile ground for innovation. It’s pretty straightforward to make a scope, I’m sure others will blog and document the precise mechanisms but for those who want a head start, just use the source, Luke.

Panel evolution

In the panel, you’ll see that the top left corner is now consistently used to close whatever has the focus. Maximising a window keeps the window controls in the same position relative to the window – the top left corner. We have time to refine the behaviour of this based on user testing of the betas; for example, in one view, one should be able to close successive windows from that top left corner even if they are not maximised.

It’s taken several releases of careful iteration to get to this point. Even though we had a good idea where we were headed, each step needed to be taken one release at a time. Perhaps this might make a little clearer the reasons for the move of window controls to the left – it was the only place where we could ultimately keep them consistent all the way up to a maximised window with the title bar integrated into the panel. I’m confident this part will all be settled by 12.04.

As part of this two-step shuffle, the Dash invocation is now integrated in the Launcher. While this is slightly less of a Fitts-fantastic location, we consider it appropriate for a number of reasons. First, it preserves the top left corner for closing windows. Second, the Dash is best invoked with the Super key (sometimes erroneously and anachronistically referred to as the “Windows” key, for some reason ;-)). And finally, observations during user testing showed people as more inclined to try clicking on items in the Launcher than on the top left icon in the panel, unless that icon was something explicit like a close button for the window. Evidence based design rules.

Visual refinements

Rather than a flat darkening, we’re introducing a wash based on the desktop colour. The dash thus adjusts to your preferred palette based on your wallpaper. The same principle will drive some of the login experience – choosing a user will shift the login screen towards that users wallpaper and palette.

We’ve also integrated the panel and the dash, so indicators are rendered in a more holographic fashion inside the dash. Together with efforts to mute the contrast of Launcher icons the result is a more striking dash altogether: content is presented more dramatically.

Since we have raw access to the GL pipeline, we’re taking advantage of that with some real-time blur effects to help the readability and presentation of overlay content in the Dash, too. Both Nux in the case of Unity-3D and Qt in the case of Unity-2D have rich GL capabilities, and we’d like to make the most of whatever graphics stack you have on your hardware, while still running smoothly on the low end.

Growing community and ecosystem

A project like this needs diverse perspectives, talents and interests to make it feel rounded and complete. While Canonical is carrying the core load, and we’re happy to do so in order to bring this level of quality to the Ubuntu desktop user experience, what makes me particularly optimistic is the energy of the contributors both to Unity directly and to the integration of many other components and applications with the platform.

On the contribution front, a key goal for the Unity community is to maintain velocity in contributor patch flows. You should expect a rapid review and, all being well, landing, for contributions to Unity that are in line with the design goals. In a few cases we’ve also accepted patches that make it possible to use Unity in ways that are different to the design goals, especially where the evidence doesn’t lean very heavily one way or the other. Such contributions add some complexity but also give us the opportunity to test alternatives in a very rich way; the winning alternative would certainly survive, the other might not.

Contrary to common prognostication, this community is shaping up to be happy and productive. For those who do so for love and personal interest, participating in such a community should be fun and stimulating, an opportunity to exercise skills or pursue interests, give something back that will be appreciated and enjoyed by many, and help raise the bar for Linux experiences. I’d credit Jorge and others for their stewardship of this so far, and my heartfelt thanks to all of those who have helped make Unity better just for the fun of it.

Outside of the core, the growing number of apps that integrate sweetly with the launcher (quicklists), dash (scopes), indicators (both app-specific and category indicators) is helping to ensure that API’s are useful, refined and well implemented, as well as improving the experience of Ubuntu users everywhere. Now that we’re moving to Unity by default for both 2D and 3D, that’s even more valuable.

Under the hood

In this round, Unity-3D and Unity-2D have grown together and become twin faces on the same underlying model. They now share a good deal of common code and common services and – sigh – common bugs :-). But we’re now at the point where we can be confident that the Unity experience is available on the full range of hardware, from lightweight thin client systems made of ARM or Atom CPU’s to CADstations with oodles of GPU horsepower.

There’s something of a competition under way between proponents of the QML based Unity-2D, who believe that the GL support here is good enough to compete both at the high end and on the low end, and the GL-heads in Unity-3D, who think that the enhanced experiences possible with raw GL access justify the additional complexity of working in C++ and GL on the metal. Time will tell! Since a lot of the design inspiration for Unity came from game interfaces, I lean to the “let’s harness all the GL we can for the full 3D experience” side of the spectrum, but I’m intrigued with what the QML team are doing.

11.04, a leap forward

Friday, April 29th, 2011

Users first, on free software. That has always been our mission: we set out to bring the joys and freedoms and innovation and performance and security that have always been part of the Linux platform, to a consumer audience. And yesterday marked the biggest leap forward in that mission that Ubuntu has ever taken, because in addition to the work we always do to make sure that the world’s best free software is polished and integrated, we brought something new to the very core of the user experience of the free platform: Unity.

We put user’s first because we committed to test and iterate Unity’s design with real users, and evolve it based on those findings. We’ve documented the process we’re following in that regard, so that other free software projects can decide for themselves if they also want to bring professional design into their process. I very much hope that this will become standard practice across all of free software, because in my view the future of free software is no longer just about inner beauty (architecture, performance, efficiency) it’s also about usability and style.

In the design of Unity we chose to be both humble and bold. Humble, because we have borrowed consciously from the work of other successful platforms, like Windows and MacOS. We borrowed what worked best, but then we took advantage of the fact that we are unconstrained by legacy and can innovate faster than they can, and took some bold leaps forward. In category indicators, the dash, overlay scrollbars and other innovations we are pioneering desktop experiences that I am sure will be emulated elsewhere, in both the free and proprietary platforms. This is the public “1.0”, there are rough points which will affect some users more than others, but we will iterate and polish them up one by one. Our goal should be to continue to set the pace and push free software to the forefront of usability and experience, growing the awesome Ubuntu and Unity community that shares those values and is excited by those ideas.

Ubuntu’s killer feature remains that community. The spirit of Ubuntu is about understanding that the measure of our own lives is in the way we improve the lives of others. Ubuntu has both economic and human dimensions: it is unique in bringing those together in a way which enables them to support one another. The fact that so many people recognise that their time, energy and expertise can have the biggest possible impact when expressed through Ubuntu is what makes their individual contributions so much more valuable. By recognising that it’s not just about bits, or licenses, or artwork, or documentation, or advocacy, or support, or assurance, or services, but that it’s about the whole of those in synthesis, we make something different to what the world has ever seen before. So to everyone who has helped bring Ubuntu 11.04 to fruition: thank you, and well done.

Of course, Ubuntu is far bigger than Unity. And the needs of the Ubuntu community, and users of Ubuntu, are far more diverse than simply Unity could address. So I’m proud of the fact that the Ubuntu community publishes the whole expression of software freedom across its archives. Kubuntu continues to improve and set a very high standard for the KDE experience. Lubuntu, the LXDE based expression of Ubuntu, is moving towards being 100% integrated. There is unique work being done in Ubuntu for users of the cloud and other server-oriented configurations. While we can be proud of what’s been achieved in Unity, we are equally proud of the efforts that go into ensuring that the full range of experiences is accommodated, to the extent possible with the effort put in by our huge community, under the Ubuntu umbrella.

We’re committed to keeping that the case. By welcoming all participants, and finding ways to accommodate and celebrate their differences rather than using them as grounds for divisiveness, we make something that is bigger than all our individual dreams.

Next after Natty?

Monday, March 7th, 2011

The naming of cats is a difficult matter
It isn’t just one of your holiday games.
– T S Eliot, The Naming of Cats

For the next cycle, I think we’ll leave the oceanic theme behind. The “oddball octopus”, for example, is a great name but not one we’ll adopt this time around. Perhaps in 13 years time, though!

The objective is to capture the essence of our next six months work in a simple name. Inevitably there’s an obliquity, or offbeat opportunism in the result. And perhaps this next release more than most requires something other than orthodoxy – the skunkworks are in high gear right now. Fortunately I’m assured that if one of Natty’s successors is a skunk, it would at least be a sassy skunk!

So we’re looking for a name that conveys mysterious possibility, with perhaps an ounce of overt oracular content too. Nothing too opaque, ornate, odious or orotund. Something with an orderly ring to it, in celebration of the crisp clean cadence by which we the community bring Ubuntu forth.

There’s something neat in the idea that 11.10 will mark eight years since Ubuntu was conceived (it took a little longer to be born). So “octennial” might suit… but that would be looking backwards, and we should have an eye on the future, not the past. Hmm… an eye on the future, perhaps ocular? Or oculate? We’re certainly making our way up the S-curve of adoption, so perhaps ogee would do the trick?

Alternatively, we could celebrate the visual language of Ubuntu with the “orange okapi”, or the welcoming nature of our community with the “osculant orangutan”. Nothing hugs quite like dholbach, though, and he’s no hairy ape.

What we want is something imaginative, something dreamy. Something sleek and neat, too. Something that has all the precision of T S Eliot’s poetry, matched with the “effable ineffability” of our shared values, friendship and expertise. Something that captures both the competence of ubuntu-devel with the imagination of ayatana.

Which leads us neatly to the Oneiric Ocelot.

Oneiric means “dreamy”, and the combination with Ocelot reminds me of the way innovation happens: part daydream, part discipline.

We’ll need to keep up the pace of innovation on all fronts post-Natty. Our desktop has come together beautifully, and in the next release we’ll complete the cycle of making it available to all users, with a 2D experience to complement the OpenGL based Unity for those with the hardware to handle it. The introduction of Qt means we’ll be giving developers even more options for how they can produce interfaces that are both functional and aesthetically delightful.

In the cloud, we’ll have to tighten up and make some firm decisions about the platforms we can support for 12.04 LTS. UDS in Budapest will be full of feisty debate on that front, I’m sure, but I’m equally sure we can reach a pragmatic consensus and start to focus our energies on delivering the platform for widespread cloud computing on free and flexible terms.

Ubuntu is now shipping on millions of systems from multiple providers every year. It makes a real difference in the lives of millions, perhaps tens of millions, of people. As MPT said, “what we do is not only art, it’s performance art”. Every six months the curtains part, and we have to be ready for the performance. I’d like to thank the thousands of people who are actively participating in the production of Natty: take the initiative, take responsibility, take action, and your work will make a difference to all of those users. There are very few places in the world where a personal intellectual contribution can have that kind of impact. And very few places where we have such a strong social fabric around those intellectual challenges, too. We each do what we do for our own reasons, but it’s the global impact of Ubuntu which gives meaning to that action.

Natty is a stretch release: we set out to redefine the look and feel of the free desktop. We’ll need all the feedback we can get, so please test today’s daily, or A3, and file bug reports! Keep up the discipline and focus on the Narwhal, and let’s direct our daydreaming to the Ocelot.

We made some mistakes in our handling of the discussion around revenue share with the Banshee team. Thanks to everyone who helped make sure we were aware of ’em 😉

Money is particularly contentious in a community that mixes volunteer and paid effort, we should have anticipated and been extra careful to have the difficult conversations that were inevitable up front and in public, at UDS, when we were talking about the possibility of Banshee being the default media player in Ubuntu. We didn’t, and I apologise for the consequential confusion and upset caused.

The principles from which we derive our policy are straightforward:

The bulk of the direct cost in creating the audience of Ubuntu users is carried by Canonical. There are many, many indirect costs and contributions that are carried by others, both inside the Ubuntu community and in other communities, without which Ubuntu would not be possible. But that doesn’t diminish the substantial investment made by Canonical in a product that is in turn made available free of charge to millions of users and developers.

The business model which justifies this investment, and which we hope will ultimately sustain that effort for the desktop without dependence on me, is that fee-generating services which are optional for users provide revenue to Canonical. This enables us to make the desktop available in a high quality, fully maintained form, without any royalties or license fees. By contrast, every other commercial Linux desktop is a licensed product – you can’t legally use it for free, the terms for binaries are similar to those for Windows or the MacOS. They’re entitled to do it their way, we think it’s good in the world that we choose to do it our way too.

We know that we need a healthy and vibrant ecosystem of application developers. We think services should work for them too, and we’re committed to sharing revenue with them. We want to be entirely aligned in our interests: better code means a better result for both of us, better revenue means more resources to do what we love even better. Our interests, and upstream interests, should be perfectly aligned in this. So we have consistently had the view that revenue we can attribute to a particular upstream should create a revenue share for that upstream. We support Mozilla in this way, for example. The numbers are not vast, but nor are they insubstantial, and while we are not obliged to do so, we do so happily.

Those are the principles, the policy is straightforward: Canonical seeks to earn revenue from services delivered to Ubuntu, and we will share a portion of that revenue with relevant projects who help make that possible. Our interests, and those of the projects, should be aligned to the greatest extent possible.

In engaging with Banshee leads at UDS, we should have been absolutely clear about our expectations and commitment. Apparently, we weren’t, and for that I apologise. There was certainly no conspiring or maliciousness, it apparently just never came up. But it was my expectation that we would share revenue with Banshee, I mentioned it briefly to someone closer to the conversation, but I failed to follow up until I heard rumours of a potential disagreement on the subject in recent days.

We also made a mistake, I believe, as this blew up in private conversations, when a well-meaning person presented a choice to the Banshee developers, who then of course made a choice. But our position isn’t at all what was communicated. Our position is that we’ll deliver the best overall experience to users, we’ll derive services revenue from that, and we’ll share it with upstreams where we can attribute it efficiently. It wasn’t in the mandate of that person to offer a choice outside of that framework, but it was an honest mistake.

So, every free software project out there should be confident of a few things:

Canonical would like you to succeed, would like to make it as easy as possible for many, many users to adopt your software, and is willing to share the benefits of that with you. Whether your software is promoted as the default in Ubuntu, or simply neatly packaged for easy consumption, we’d like our interests to be well aligned. We have a bug tracker that helps us pass issues to you if they are reported in Ubuntu first, we have a revenue model which matches that with passing through a share of revenues, too. And that goes for any kind of revenue that we can attribute to your project; for example, if we offer a support service specially tailored to people using your code, you can reasonably expect to agree a revenue share of that with us.

Canonical invests heavily in creating a big, addressable ecosystem that you can easily reach. That’s worth something. We also want a big, vibrant upstream community that innovates and makes its own investments. We know that contributions come both from volunteers and paid staff, and it’s good to be able to have a bit of both in the mix, for the sake of both the volunteers and the paid staff!

Documenting this position is obviously a priority; we should have done so previously, but we just relied on internal precedent, which is a dumb idea when you’ve grown as quickly as we have in the past few years. So we’ll do that.

As for the revenue share we’ve offered the Banshee team, I would love to see them use that to make Banshee even better. That’s what it should be for. Don’t be shy, don’t be nervous of taking the money and using it for your own project. Canonical has already provided much more in the way of funding to the Gnome Foundation than this is likely to, through initiatives like the work that we funded, and many other forms of support. I think money generated by an app should go towards making that app rock even harder. But the offer stands for Banshee devs to take up if they’d like, and use as they’d like. If they don’t want it, we’ll put it to good use.

This certainly won’t be the last word on the subject. I expect these situations to become more common, not less. But I think that represents a great opportunity to see sustained investment in desktop free software, which we have been sorely lacking. I think our model gives projects a nice, clear roadmap: build awesome stuff, partner with Canonical and be confident you will share in the success of Ubuntu. This is the model which catalysed the founding of Ubuntu, seven years ago, this is what we’re here to do: make free software available freely, in the best quality, to the widest audience we can. That’s an opportunity for every project that cares about how many people get to use their stuff, and under what terms.

Qt apps on Ubuntu

Tuesday, January 18th, 2011

As part of our planning for Natty+1, we’ll need to find some space on the CD for Qt libraries, and we will evaluate applications developed with Qt for inclusion on the CD and default install of Ubuntu.

Ease of use, and effective integration, are key values in our user experience. We care that the applications we choose are harmonious with one another and the system as a whole. Historically, that has meant that we’ve given very strong preference to applications written using Gtk, because a certain amount of harmony comes by default from the use of the same developer toolkit. That said, with OpenOffice and Firefox having been there from the start, Gtk is clearly not an absolute requirement. What I’m arguing now is that it’s the values which are important, and the toolkit is only a means to that end. We should evaluate apps on the basis of how well they meet the requirement, not prejudice them on the basis of technical choices made by the developer.

In evaluating an app for the Ubuntu default install, we should ask:

* is it free software?
* is it best-in-class?
* does it integrate with the system settings and preferences?
* does it integrate with other applications?
* is it accessible to people who cannot use a mouse, or keyboard?
* does it look and feel consistent with the rest of the system?

Of course, the developer’s choice of Qt has no influence on the first two. Qt itself has been available under the GPL for a long time, and more recently became available under the LGPL. And there’s plenty of best-in-class software written with Qt, it’s a very capable toolkit.

System settings and prefs, however, have long been a cause of friction between Qt and Gtk. Integration with system settings and preferences is critical to the sense of an application “belonging” on the system. It affects the ability to manage that application using the same tools one uses to manage all the other applications, and the sorts of settings-and-preference experience that users can have with the app. This has traditionally been a problem with Qt / KDE applications on Ubuntu, because Gtk apps all use a centrally-manageable preferences store, and KDE apps do things differently.

To address this, Canonical is driving the development of dconf bindings for Qt, so that it is possible to write a Qt app that uses the same settings framework as everything else in Ubuntu. We’ve contracted with Ryan Lortie, who obviously knows dconf very well, and he’ll work with some folks at Canonical who have been using Qt for custom development work for customers. We’re confident the result will be natural for Qt developers, and a complete expression of dconf’s semantics and style.

The Qt team have long worked well in the broader Ubuntu community – we have great Qt representation at UDS every six months, the Kubuntu team have deep experience and interest in Qt packaging and maintenance, there is lots of good technical exchange between Qt upstream and various parts of the Ubuntu community, including Canonical. For example, Qt folks are working to integrate uTouch.

I’d draw a distinction between “Qt” and “KDE” in the obvious places. A KDE app doesn’t know anything about the dconf system configuration, and can’t easily integrate with the Ubuntu desktop as a result. So we’re not going to be proposing Amarok to replace Banshee any time soon! But I think it’s entirely plausible that dconf, once it has great Qt bindings, be considered by the KDE community. There are better people to lead that conversation if they want, so I’ll not push the idea further here :-). Nevertheless, should a KDE app learn to talk dconf in addition to the standard KDE mechanisms, which should be straightforward, it would be a candidate for the Ubuntu default install.

The decision to be open to Qt is in no way a criticism of GNOME. It’s a celebration of free software’s diversity and complexity. Those values of ease of use and integration remain shared values with GNOME, and a great basis for collaboration with GNOME developers and project members. Perhaps GNOME itself will embrace Qt, perhaps not, but if it does then our willingness to blaze this trail would be a contribution in leadership. It’s much easier to make a vibrant ecosystem if you accept a certain amount of divergence from the canonical way, so to speak 😉 Our work on design is centered around GNOME, with settings and preferences the current focus as we move to GNOME 3.0 and gtk3.

Of course, this is a perfect opportunity for those who would poke fun at that relationship to do so, but in my view what matters most is the solid relationship we have with people who actually write applications under the GNOME banner. We want to be the very best way to make the hard work of those free software developers *matter*, by which we mean, the best way to ensure it makes a real difference in millions of lives every day, and the best way to connect them to their users.

To the good folks at Trolltech, now Nokia, who have made Qt a great toolkit – thank you. To developers who wish to use it and be part of the Ubuntu experience – welcome.

Linaro at work: porting, testing, and Android

Thursday, November 11th, 2010

Congratulations to Team Linaro on their first full release yesterday. For those not yet in the know, Linaro is a collaborative forum with dedicated engineers making sure that Linux rocks on ARM (and potentially other architectures). Staffed by a combination of Canonical and new Linaro engineers, together with secondees from the major ARM silicon vendors, it’s solving the problems of fragmentation in Linux across that ecosystem and reducing the time to market for ARM devices.

Linaro uses the same cadence as Ubuntu and we’re able to collaborate on the selection, integration and debugging of key components like the kernel, toolchain, (still ;-)), and hundreds of small-but-important libraries and tools in between. Team Linaro was @UDS and it was very cool to see the extent to which their sessions drew attendance from the wider Ubuntu community – I think there’s a growing interest in efficient computing across the Ubuntu landscape.

The Linaro team is pleased to announce the release of Linaro 10.11.
10.11 is the first public release that brings together the huge amount
of engineering effort that has occurred within Linaro over the past 6
months. In addition to officially supporting the TI OMAP3 (Beagle
Board and Beagle Board XM) and ARM Versatile Express platforms, the
images have been tested and verified on a total of 7 different platforms
including TI OMAP4 Panda Board, IGEPv2, Freescale iMX51 and ST-E U8500.

The advances that have happened in this cycle are numerous but include a
completely rebuilt archive using GCC 4.4.4 and the latest ARM optimised
tool chain, the Linux kernel version 2.6.35, support for
cross-compiling, a new hardware pack way of building images, 3D
acceleration improvements, u-boot enhancements and initial device tree
support, a new QA tracking structure, the list goes on.

Android in the house

The road ahead looks even more interesting. For the next cycle, the Linaro team is going to build an Android environment on the same kernel and toolchain that we collaborate on with Ubuntu. For folks building devices, picking a board that’s part of the Linaro process means you’ll be able to get either an Ubuntu-style or Android-style core environment up and running at Day 1, which should reduce time to market for everyone.

If the Linaro team pulls this off, it will mean that Linaro provides an intersection point for the majority of the consumer electronics x86 and ARM ecosystem, regardless of the end OS. I’m sure over time we’ll find more groups that are interested in joining the process, and I see no reason why they couldn’t be accommodated in this cadence-driven model.

More players, more diversity in services

It was also good to see folks from Montavista and Mentor at Linaro@UDS this year. Whether the Linaro kernel and toolchain plug into their own distros, or they start to offer their services around the Linaro/Ubuntu/Android BSP’s, the result is a healthier ecosystem with fewer snags and gotchas for device makers.

One group asked me explicitly if Linaro was a Canonical show, and I was glad to say it isn’t. Canonical can’t possibly do everything that embedded Linux needs done, but our competence in cadence and release management makes us good custodians of a public project, which is what we do with Ubuntu itself. Participation and collaboration are at the heart, and they benefit from being partnered with a commitment to delivery and deadlines. We can’t do everything in a single cycle, but we can provide a roadmap for things like kernel defragmentation, the device-tree work, enablement of an ever-increasing cross-section of the ARM ecosystem, and transitions between versions of GCC or Python or X or even Wayland. So Canonical makes a good anchor, but Linaro has room for lots of other service-providers. Having multiple companies participate in Linaro means that the products we’re all shipping get better, faster.


The Linaro team is also going to focus on repeatable, rigorous testing of the core platform in the next cycle. That harmonises nicely with our growing focus on quality in Ubuntu, and the need for better quality and testing in open source in general. I’m interested to see what tools and results the Linaro team can produce in the next six months. Open source *can* be bulletproof, but it can also degrade in quality if we don’t put the right processes in place upstream and downstream, so this is a very welcome initiative.

I spent a lot of time observing our community, this release. For some reason I was curious to see how our teams work together, what the dynamic is, how they work and play together, how they celebrate and sadly, also how they mourn. So I spent a fair amount more time this cycle reading lists from various Ubuntu teams, reading minutes from governance meetings for our various councils, watching IRC channels without participating, just to get a finger on the pulse.

Everywhere I looked I saw goodness: organised, motivated, cheerful and constructive conversations. Building a free OS involves an extraordinary diversity of skills, and what’s harder is that it requires merging the contributions from so many diverse disciplines and art forms. And yet, looking around the community, we seem to have found patterns for coordination and collaboration that buffer the natural gaps between all the different kinds of activities that go on.

There are definitely things we can work on. We have to stay mindful of the fact that Ubuntu is primarily a reflection of what gets done in the broader open source ecosystem, and stay committed to transmitting their work effectively, in high quality (and high definition :-)) to the Ubuntu audience. We have to remind those who are overly enthusiastic about Ubuntu that fanboyism isn’t cool, I saw a bit of “We rock you suck” that’s not appropriate. But I also saw folks stepping in and reminding those who cross the line that our values as a community are important, and the code of conduct most important of all.

So I have a very big THANK YOU for everyone. This is our most valuable achievement: making Ubuntu a great place to get stuff done that has a positive impact on literally millions of people. Getting that right isn’t technical, but it’s hard and complex work. And that’s what makes the technical goodness flow.

In particular, I’d like to thank those who have stepped into responsibilities as leaders in large and small portions of our Ubuntu universe. Whether it’s organising a weekly newsletter, coordinating the news team, arranging the venue for a release party, reviewing translations from new translators in your language, moderating IRC or reviewing hard decisions by IRC moderators, planning Kubuntu or leading MOTU’s, the people who take on the responsibility of leadership are critical to keeping Ubuntu calm, happy and productive.

But I’d also like to say that what made me most proud was seeing folks who might not think of themselves as leaders, stepping up and showing leadership skills.

There are countless occasions when something needs to be said, or something needs to get done, but where it would be easy to stay silent or let it slip, and I’m most proud of the fact that many of the acts of leadership and initiative I saw weren’t by designated or recognised leaders, they were just part of the way teams stayed cohesive and productive. I saw one stroppy individual calmly asked to reconsider their choice of words and pointed to the code of conduct by a newcomer to Ubuntu. I saw someone else step up and lead a meeting when the designated chairman couldn’t make it. That’s what makes me confident Ubuntu will continue to grow and stay sane as it grows. That’s the really daunting thing for me – as it gets bigger, it depends on a steady supply of considerate and thoughtful people who are passionate about helping do something amazing that they couldn’t do on their own. It’s already far bigger than one person or one company – so we’re entirely dependent on broader community commitment to the values that define the project.

So, to everyone who participates, thank you and please feel empowered to show leadership whenever you think we could do better as a community. That’s what will keep us cohesive and positive. That’s what will make sure the effort everyone puts into it will reach the biggest possible audience.

With that said, well done everyone on a tight but crisp post-LTS release. Maverick was a challenge, we wanted to realign the cycle slightly which compressed matters but hopefully gives us a more balanced April / October cadence going forward based on real data for real global holiday and weather patterns :-). There was an enormous amount of change embraced and also change deferred, wisely. You all did brilliantly. And so, ladies an gentlemen, I give you Mr Robbie Williamson and the Maverick Release Announcement. Grab your towel and let’s take the Meerkat out on a tour of the Galaxy 😉

GMailWatcher for webmail lovers

Thursday, September 16th, 2010

Owais Lone wanted this mentioned on Planet Ubuntu, so I’m proxying for his blog announcement since he isn’t yet an Ubuntu Member:

In case you don’t already know, GmailWatcher is a Gmail notifier specifically designed for the Ubuntu Operating System. It relies heavily on Ubuntu specific packages like MeMenu, Notifications, DesktopCouch but I’m planning a stock Gnome version also so that people on Fedora, Suse and other rocking distribution can use it too.

Most notable features are:

  • Multiple Accounts
  • Google Apps support
  • Secure password storage using Gnome-Keyring support
  • Themable unread emails page
  • Preferences sync using U1

Right now, my target is to make it stable/usable enough in time for Maverick.

This post is essentially a call for user feedback. I would like to know what you don’t like about the way GmailWatcher works. Bugs, usability issues, appearance, anything that doesn’t count as a new feature.