The libappindicator Story

Note: This post is part three of a series of thoughts on the relationship between Canonical and GNOME.

Tensions rose this week as claims were made and refuted — mostly as comments on blog posts about entirely different issues! — about the collaboration and relationship between Canonical and GNOME.

After actively participating in much of that discussion, Mark Shuttleworth (founder of Canonical and Ubuntu) responded in a strongly-worded blog post on Thursday morning.

He made a range of claims, but in this part of the series I will focus on his response to the release team’s stated reasons for the rejection of libappindicator:

The premier reason given for the rejection of [Unity's indicator] API’s is a reason that, as best we can tell, has never been used against an external dependency proposal before: “it’s different to Gnome”. At the heart of this statement is something deeper: “it’s competition with an idea someone in Gnome wants to pursue”.

Now, I can tell you that I was pretty disgusted with this result.

Please read Mark’s entire post to get a full appreciation for the depth, breadth and consequence of his criticism.

History

The history of “indicators” is quite long, but as that will be covered in the timeline for part four of this series, I will fast-forward to the introduction of libappindicator itself, during the Ubuntu Developer Summit for Lucid Lynx (UDS-Lucid).

November 18, 2009: Application Indicators are discussed at UDS, aiming to replace the notification area and present a single set of menus on the panel for consistency. The KNotificationItem specification is chosen as a basis for the protocol, but “the addition that we’ll need is the ability to define a menu”.

Actions include “develop the application library”, despite the fact that libappindicator development had already begun, privately, one month earlier (first commit: October 13, 2009). To be fair, it was still pretty raw immediately prior to UDS, but work had clearly begun.

December 3, 2009: The Ubuntu DX team’s ApplicationIndicators wiki page is created. One week later it is updated to include a very thorough set of use cases, architecture documents and a porting guide.

December 16, 2009: Canonical developer Ted Gould blogs about libappindicator, links to the StatusNotifier specification.

December 17, 2009: On the XDG mailing list, Canonical developer Aurélien Gâteau proposes the StatusNotifier specification, a reworking of the KNotificationItem spec first introduced as a draft on September 5, 2009.

January 13, 2010: Ted Gould emails GNOME’s desktop-developer-list (DDL) to request feedback on StatusNotifier. This is the first time libappindicator is raised on a GNOME mailing list. It is already too late to propose for inclusion in GNOME 2.30.

A few technical questions are asked about Canonical’s plan to port applications. Concluding the thread, Dan Winship states: “Anyway, we want a menubar-like tray for GNOME Shell too, and the new spec seems like a good plan.”

January 18, 2010: Dan Winship responds to the StatusNotifier proposal, raising his concerns about the specification, spawning a discussion almost exclusively with Aaron Seigo (which I will cover in another post).

(So rereading this, it comes across as kinda harsh, but it wasn’t supposed to be, so just add a “:-)” to the end of every line or something. :-)

February 6-17, 2010: Canonical developers blog about Application Indicators — including Jorge Castro’s Application Indicator Update, Jono Bacon’s KDE Application Indicators in GNOME and (contractor) Jan Arne Petersen’s Application Indicators — all of which note that patches for application support are already being submitted upstream, ie. GNOME’s Bugzilla.

February 15, 2010: The new module proposals period opens for GNOME 3.0.

February 18, 2010: Colin Walters, a Red Hat developer working on GNOME Shell, raises Canonical’s application indicators work for discussion on DDL.

First, +5000 that this change is being driven by designers, and +1000 that new useful code is being written. There are definite problems being solved here.

His questions revolve around how applications should use it, how it might fit in with the design plans for GNOME Shell, and suggests that it would make sense for the API to live in GTK+ rather than a separate library.

Ted Gould and Jorge Castro participate in the resulting 11 post thread (there was another subthread, but irrelevant to the proposal itself). Matthias Clasen contributes two grumpy points about Canonical’s approach to collaboration (not designing in the open and asking GNOME developers to discuss API issues on the Ayatana list).

Roughly 6 hours after his last post in that thread, Ted Gould proposes libappindicator as an external dependency for GNOME 3.0, strongly emphasising that the discussion focus only on its inclusion as an external dependency. He includes the key question about the library, raised earlier: “Does this fit the the design goals for GNOME Shell?”

Olav Vitters of the release team suggests that question must be answered before the release team can make a decision. Ted replies, “Obviously that’s a question that I can’t answer. Though, one that I’d love an answer and a discussion about.”

A concern is raised about copyright assignment, and there’s a silly little subthread about versions of the GPL (much less likely to be a problem than the CLA).

The meat of the thread is a discussion about libappindicator’s use of GTK+ menu APIs, with suggestions from GTK+ developers for how to improve the libappindicator API.

Discussion peters out, without answers to the fundamental questions, with Ted Gould having sent a total of 5 emails to a 17 post thread. (Cody Russell also contributed, but not about technical issues.)

March & April, 2010: Two and a half months (Feb 19–May 6) pass without a single discussion about libappindicator on any GNOME mailing list.

Intermission! Let’s take a moment to recall Mark Shuttleworth’s comments about why GNOME developers rejected libappindicator:

Much of the language, and much of the decision making I’ve observed within Gnome, is based on the idea that Unity is competition WITH Gnome, rather than WITHIN Gnome.

The premier reason given for the rejection of [Unity's indicator] API’s is a reason that, as best we can tell, has never been used against an external dependency proposal before: “it’s different to Gnome”. At the heart of this statement is something deeper: “it’s competition with an idea someone in Gnome wants to pursue”.

What made this single statement heartbreaking for me to see was that it spoke clearly to the end of one of Gnome’s core values: code talks. Here we had API’s which were real, tested code, with patches to many Gnome apps available, that implemented a spec that had been extensively discussed on FreeDesktop.org. This was real code. Yet it was blocked because someone – a Gnome Shell designer – wanted to explore other ideas, ideas which at the time were not working code at all. There’s been a lot of commentary on that decision. Most recently, Aaron Seigo pointed out that this decision was as much a rejection of cross-desktop standards as it was a rejection of Canonical’s code.

It’s also saying that Unity is not “in GNOME”. Clearly, a lot of Unity work depends on the adoption of these API’s for a smooth and well-designed panel experience. So once again, we have a statement that Unity is “competition with Gnome” and not “competition within Gnome”.

Intermission over.


May 6, 2010: Last call for comments on module proposals. Dan Winship, a Red Hat developer working on GNOME Shell, replies to the libappindicator proposal with the final word on its relevance to the new shell:

The system status area needs numerous features that aren’t available in libappindicator [...] so libappindicator will not be useful here.

As for the trayicons in the message tray [...] the StatusNotifier protocol that the appindicator work is built on is just… designed to solve some problem other than ours. I still think we don’t want libappindicator.

So while Dan doesn’t think libappindicator fits with GNOME Shell’s system status or notification goals, he doesn’t close the door entirely to StatusNotifier/dbusmenu (the XDG protocol guts wrapped by libappindicator):

And at any rate, since gdbus will be landing soon, if we did want to support the StatusNotifier/dbusmenu protocol, we could just add that to GtkTrayIcon now.

Ted Gould replies, “Not to criticize your decision, but just to correct a couple of factual details in your e-mail”, noting that dbusmenu is included in KDE and the StatusNotifier spec, and that libappindicator would be ported to gdbus soon. He doesn’t object to Dan’s decision. There is no further discussion.

May 10, 2010: Mark Shuttleworth reveals the Unity netbook user experience to the world during his opening “keynote” at UDS Maverick, and writes about it later that day:

Unity and Gnome Shell are complementary for the Gnome Project. While Gnome Shell presents an expansive view of how people work in complex environments with multiple simultaneous activities, Unity is designed to address the other end of the spectrum, where people are focused on doing one thing at any given time.

May 16, 2010: The GNOME release team meets, and based on the feedback received, decides to reject libappindicator for GNOME 3.0.

June 2, 2010: The release team announces new module decisions for GNOME 3.0, stating the reasons why libappindicator is rejected as an external dependency.

No Canonical developers reply.

Excluding vala-list discussions about wrapping the API, there is a grand total of five pages of Google results for “libappindicator” in the GNOME list archives.

Understanding the decision

Mark is not a day-to-day participant in the GNOME community (he does run a company, after all), so it’s easy to understand why he has so misunderstood the process and motivations of the community — through the lens of the release team’s rejection reasons.

Let’s go through them:

  • it doesn’t integrate with gnome-shell

I hope I have demonstrated absolutely clearly in the timeline above that libappindicator was not rejected due to a sense of “competition” between Unity and GNOME Shell: The key advice to the release team was given four days before Unity was unveiled.

  • probably depends on GtkApplication, and would need integration in GTK+ itself

Unfortunately, this point is badly written, but it’s related to the suggestion that the API should actually be in GTK+ rather than a separate library. It demonstrates that while the library — conceived and designed without technical or strategic advice from the GNOME community — was rejected, the ideas behind it were not. Mailing list discussions reflected the same view, as shown above.

It’s important to recognise that this is not the behaviour you would expect of those who would discriminate against Canonical, or who had already made up their minds a long time ago.

  • we wished there was some constructive discussion around it, pushed by the libappindicator developers; but it didn’t happen

Mark’s response to this was, “We made the proposal, it was rejected.” Well, yes… but keep in mind that he is quoting the rejection itself! :-)

I can tell you that the people who worked on the proposal consider themselves Gnome people, and they feel they did what was required, and stopped when it was clear they were not going to be accepted. I’ve had people point to this bullet and say “you should have pushed harder”.

I believe the timeline above clearly demonstrates that Canonical did not do “what was required”. Unpaid volunteers regularly do more to get their work into GNOME than Canonical did in this case. I can barely describe how little effort was invested pursuing this proposal.

Ted Gould is not at fault, by the way. If Canonical wanted it done, it could have assigned different people to the task, more people to the task, or anyone at all during March and April.

The flip side to this is that Aurélien Gâteau engaged with the KDE community early and often in his work to update specifications to reflect Canonical requirements, bring in dbusmenu support, etc. I don’t believe the key difference here is between GNOME and KDE, it is in Canonical’s approach to engagement, and its commitment of developers to the task.

  • there’s nothing in GNOME needing it.

Mark’s response:

This is a very interesting comment. It’s saying “no Gnome apps have used these API’s”. But the Gnome apps in question were looking to this very process for approval of their desire to use the API’s. You cannot have a process to pre-approve API’s, then decline to do so because “nobody has used the API’s which are not yet approved”.

This is a simple misunderstanding: No process exists to “pre-approve APIs”. So that’s not the process libappindicator was submitted to… or rejected by.

Any GNOME module can add an optional (or “soft”) build dependency at any time. Jorge, Jono and Jan even blogged about libappindicator support patches being sent upstream… prior to the proposal!

An “external dependency” in GNOME release parlance describes a particular version of a library that is not maintained by the GNOME community, but acceptable as a required (or “hard”) dependency. DBus is a good example: it’s not a GNOME project, but we can rely on a particular version’s API, ABI and protocol being consistent.

The irony is: libappindicator did not need to be listed as an external dependency for Mark to have achieved his goals. Canonical needn’t have engaged at all! (Sure, that would have created all sorts of different problems…)

Conclusion

Mark’s extraordinary criticisms were made without understanding the process, without understanding the quotes he was using as evidence, and frankly, without understanding the GNOME community’s motivations or intentions.

Key points:

  • Canonical barely made an effort to have libappindicator “accepted into GNOME” (which, in the context of his criticism, Mark believed was important or necessary)
  • It did not even need to go through this process anyway, because it did not need to be an “external dependency” in order to achieve Mark’s stated goals (ie. application adoption of the API)
  • So the rejection of libappindicator, for all the sturm und drang, is essentially meaningless — it had no bearing on the opportunity for collaboration between Canonical and GNOME
  • Unity did not exist in the public sphere when libappindicator was declared irrelevant to GNOME Shell, and was not ever the reason why: (a) there wasn’t much interest in libappindicator, or (b) GNOME Shell developers decided they were on a different path
  • Not proven in this part of the series, but worth noting: the person Mark specifically chose to attack, Jon McCann, did not decide to exclude libappindicator because — being a design contributor to GNOME Shell — he felt threatened by Unity. In fact, he had no part in the decision, and didn’t know Unity existed!

But libappindicator is just one chapter in a much longer story… see you in part four! :-)

Disclosure: I enjoyed working for Canonical from 2004-2006, and although I have occasionally been accused of shilling for Ubuntu since then, I suspect few at Canonical would regard me as their #1 fan at the moment. I haven’t been involved in GNOME for quite some time, and generally try to avoid thinking about it very often.

Posted in General | Tagged , , , , , | 97 Comments

Thoughts on GNOME

Note: This post is part two of a series of thoughts on the relationship between Canonical and GNOME.

When you think about the huge mainstays of the Open Source world, GNOME is right up there with the likes of Mozilla, Apache, KDE, the Linux kernel and Debian.

These are the titans of Software Freedom. Massive teams of co-developers, who regard themselves as a family… including the occasional creepy uncle. Individual volunteers work alongside paid contributors with corporate affiliations. Structures are formed to deal with differences of opinion, and facilitate productive collaboration between different kinds of contributors — individuals, corporate stakeholders, hackers, designers. Small teams grow within the larger project. Conferences are established to bring everyone together. Eventually, you’ll even find cliques.

Such communities carry immense history beyond code, such as development tools and processes, community conventions, and as with any large team, the (“we should really document that”) unwritten wisdom of experience. And in-jokes. Always with the in-jokes.

It’s easy to find fault with GNOME. It is, after all, a massive, lumbering project.

Who leads GNOME? Originally, Miguel de Icaza founded and led the project as a benevolent dictator, with maintainers of individual pieces as trusted lieutenants. As GNOME transitioned from science project to core infrastructure, growth in stakeholders demanded more structured decision-making, which eventually led to the GNOME Foundation and then the Release Team.

Today, as in 2000, the Foundation supports the goals of the project, but does not provide technical leadership. Mostly it manages the resources available to the project, maintains relationships with organisational stakeholders and provides a venue to resolve disputes. It may intervene when the project is unable to make a decision or move forward — the most notable cases of that happening include the formation of the GNOME 2.0 release team in 2001, and instigation of a plan for GNOME 3 in 2008 and 2009.

The release team is delegated with a fairly narrow set of technical leadership responsibilities: what to ship and when. Everything else is up to the maintainers of individual GNOME components, and a lot — a lot — of negotiation on the unwieldy general discussion mailing lists. :-)

GNOME has always been terrible at flag-posting places to pitch in. It’s difficult to figure out where and how to get involved, especially if you just “want to help”. Documentation of bite-sized, easy-fixes for new contributors is reliably miserable. Even with the rigorous release process, few developers write down their agenda for the next cycle, which makes it hard to know what they care about and how you might help.

The GNOME community is absolutely shithouse at mentoring and motivation. It takes a lot of perseverance and banging on doors to bring big new ideas to fruition, and most of it has to be done under your own motivational steam. Much of the time, this is is the result of process over people. The words GNOME people use to describe what’s “in” and “out”, “accepted” and “rejected” sound terrible.

There is a deep irony here, because GNOME was founded by the greatest Open Source motivator of all time, Miguel de Icaza. You could send Miguel a completely misguided and broken patch and he’d rewrite the whole damn thing, explain why (in the most encouraging of terms), tell you how much you rocked for contributing, and then… after all of that… he’d praise you effusively in the credits of the next release! Yes, I wish GNOME were more like its father. :-)

There are people in GNOME who are difficult to approach. There are people in GNOME who are of a grumpy or abrasive disposition. There are people in GNOME who are jerks. But throw a brick at any large group of people and there’s a good chance you’ll hit a fuckwit. Of course, there are great people in GNOME too, as well as procedures to deal with problems.

Ideas that were once bold and terrifying have become assumptions, seeping into the DNA of the project. An example: Ten years ago the idea of a six-month, time-based release schedule was wildly controversial. Who doesn’t have a time-based release schedule today, and what are they smoking? GNOME is actually behind the curve now, because the wide adoption of time-based schedules and rise of agile development means “six months” sounds grandfatherly!

Since the beginning, most GNOME developers have regarded their creation as a coherent whole, in two pieces: a desktop user experience and a developer platform. This was practically written in stone during the process of creating GNOME 2.0, when we defined the separate “desktop” and “platform” release sets. GNOME is not a miscellany of parts, occasionally thrown over the fence — it is intended to be an integrated, considered stack. More than the sum of its parts. Decisions are made on this basis, which may sometimes be confusing to new contributors.

Since 2.0, a particular angle on usability took hold, which is loudly criticised as often as it is misunderstood. I don’t feel the need to defend it here, but must note the impact it has on recruitment and approachability. GNOME developers are more likely to reject a new option or feature (different things!) on the grounds of usability, applicability to vision, or consistency across broader goals than many other projects. Not only can that be difficult for contributors to understand, it can be challenging for GNOME developers to describe!

GNOME developers are more likely to take a long term view of improving infrastructure from the ground up than to accept a quick fix hack. Consider the range improvements to the entire Linux desktop network stack spawned by Network Manager. This is why, for much the same reason, Havoc Pennington founded FreeDesktop.org way back in 2000: To promote practical cross-desktop interoperability.

The funny thing is, despite external commentators suggesting that the GNOME community is unaware of or does not accept its faults, GNOME participants are painfully aware of them all. Conversations along these lines were rife long before and long after I was actively involved in the project. Some of these problems are merely a matter of manpower. Some of them involve big decisions being made. Some of them are the fundamental challenges of volunteer-driven and leaderless societies.

Assumptions calcify. Processes calcify. Code calcifies. You can fix a hardening of ideas, but it takes people to do so. Individuals or a small team. Getting involved. Defining a vision. Making decisions. Communicating and compromising. Pushing the needle. That’s how you get things done.

It’s hard work being a contributor, and GNOME sure has its fair share of quirks, but it’s not especially different to any other large FLOSS project with thousands of stakeholders, and most importantly, it’s an open, independent, meritocratic, co-development community.

GNOME is People.

Disclosure: I enjoyed working for Canonical from 2004-2006, and although I have occasionally been accused of shilling for Ubuntu since then, I suspect few at Canonical would regard me as their #1 fan at the moment. I haven’t been involved in GNOME for quite some time, and generally try to avoid thinking about it very often.

Posted in General | Tagged , , , , | 18 Comments

On the relationship between Canonical and GNOME

I can’t count the number of times over the last three years (!) that I have written and deleted a post about Canonical’s worsening relationship with GNOME. Having worked for Canonical and held a leadership role in GNOME, I’ve felt a weight of responsibility (probably unfounded) to contribute to this ongoing debate — and do so constructively.

My hope in finally publishing my thoughts is to raise the tone of the discussion, document what has happened over the last few years, illustrate why we’ve reached this low point in the relationship between Canonical and GNOME, and consider the options for resolution and next steps.

Unfortunately, what began as a short clarification has grown into a research project over the last few days, and is bordering on the length of a novel. So rather than deliver a single, epic post about everything — in dangerous TL;DR territory — I have decided to split my comments into a series of posts:

  1. On the relationship between Canonical and GNOME (a series)
  2. Thoughts on GNOME
  3. The libappindicator Story (timeline)
  4. Love flies under the radar
  5. The Greatest Show on Earth (timeline)
  6. Moving the needle in GNOME
  7. It’s 2009… and they have a plan (timeline)
  8. The timeline continues…
  9. … TBD (still have to figure out how to split the rest of it!)

Enjoy!

Disclosure: I enjoyed working for Canonical from 2004-2006, and although I have occasionally been accused of shilling for Ubuntu since then, I suspect few at Canonical would regard me as their #1 fan at the moment. I haven’t been involved in GNOME for quite some time, and generally try to avoid thinking about it very often.

Posted in General | Tagged , , , , | 6 Comments

Happy birthday, Mister Po!

This is Po, celebrating his second birthday earlier tonight… he’s such a big boy now! Not quite as cute as his very young self, but still beautiful. :-)

I had planned to celebrate with a big family dinner, but because Po didn’t want to make a big deal about getting older (typical two year old), he just ate a toothbrush instead.

Posted in General | Tagged , , , | 3 Comments

Modern Browsers Ship

What makes for a truly modern browser?

Check out the interactive browser release chart.

The chart illustrates the most significant releases of each browser, regardless of arbitrary major/minor/micro version number changes. For instance, minor version bumps such as Firefox 3.6 were as significant in the Firefox timeline as major bumps were in Chrome’s.

Posted in General | Tagged , , , , , , , | 20 Comments

Linux Australia puts a lid on the linux.conf.au 2011 distraction

Two weeks ago I wrote about the unfortunate controversy and aftermath of a keynote speech given at linux.conf.au 2011. I am pleased and impressed by the Linux Australia statement, released today, which should put a lid on the distraction. Well, one can hope.

There were a couple of thoughts in the statement that I wanted to highlight:

“[Our] policies have enabled us to respond in a manner which we believe reinforces [our values and principles].”

and,

“Like the software that our community is founded on, our policies are works in progress and can always be improved.”

Great stuff. None of that senseless hooey people spout like “Open Source is about choice” or equating the “freedom” in Software Freedom with absence of rules, responsibility or respect.

Posted in General | Tagged , , | 1 Comment

The Elopocalypse: Nokia chooses Microsoft

At the outset, I must admit that I have no real interest in Nokia these days. What I can muster is entirely related to their impact on the FLOSS world, my friends who work there and at the various Open Source companies who do contract work for them.

So, because today’s announcement has consequences for a lot of great FLOSS people, I have felt guilty waiting to see what happens purely for entertainment value. A little bit guilty. Lord knows there’s a metric fuckton of kickarse Open Source jobs out there at the moment anyway! :-)

The Elopocalypse

The gist of the Elopocalypse is that Nokia will team up with Microsoft to use Windows Phone 7 as its primary smartphone platform. No fucking around, Nokia is going all the way: Platform, developer tools, search, advertising, application marketplace, etc.

They are pissing practically everything away into the Microsoft hole. While Nokia has said this as a “new strategic direction”, I think it’s better described as “outsourcing”.

Let us recall the long line of successful and happy Microsoft platform development “strategic partners”: *crickets* (Update: Horace Dediu made a list! In memoriam: Microsoft’s previous strategic mobile partners.)

Under new leadership imported directly from Microsoft, Nokia has chosen the route most damaging to itself in the long term, and most advantageous to Microsoft in the short term.

Most importantly: Who has four fingers and desperately needs a major hardware vendor to ship his brand new smartphone platform? This guy!

MeeGo

What of their Open Source platform ambitions? According to the press release, Nokia intends to continue working on MeeGo and ship a product using it:

Under the new strategy, MeeGo becomes an open-source, mobile operating system project. MeeGo will place increased emphasis on longer-term market exploration of next-generation devices, platforms and user experiences. Nokia still plans to ship a MeeGo-related product later this year.

So it sounds like MeeGo will be used for tablets, mobile Internet devices (if that category even exists in 2011) and perhaps other form-factors… but then, check out the choice of words: “project”, “exploration”, “related product”. Elop all but confirmed the loose end nature of the project during the CEO Q&A.

There’s no commonality whatsoever between MeeGo and the Windows Phone 7 platform (unless Nokia do something very clever with Mono, but I can’t see Microsoft allowing it), so now Nokia has Symbian, MeeGo and Windows Phone 7 for different device profiles… a confusing story for developers, don’t you think?

I just buried the lede, didn’t I? Yes, you read that correctly: Nokia has added Windows Phone 7 without dumping any of its platforms, and will continue maintenance of — and ask developers to understand the difference between, and at least a subset of them to embrace — Symbian, MeeGo and Windows Phone 7.

What’s the app store strategy for Nokia MeeGo devices? It won’t be Microsoft’s Windows Phone Marketplace, that’s for sure!

Then you have to consider Nokia’s partners in the MeeGo project: Intel and the Linux Foundation.

Intel have lost their 800lb smartphone hardware gorilla… does it make sense to continue investing in MeeGo? Just for tablets or netbooks? Who else is going to jump on board, particularly since the HP webOS announcement this week?

… and what possessed the Linux Foundation to get into this mess in the first place? :-) So far, no response to Nokia’s announcement from the Linux Foundation, by the way.

Update: A quick thought from Ryan Paul:

I think the Linux Foundation can still salvage MeeGo by making it a generic upstream for low-level embedded Linux stack for set-tops, IVI, etc.

That would probably be worth it for Intel, too — consider Yocto and friends. They’re working hard to build great tools for embedded Linux developers.

Update: Jim Zemlin, Executive Director of the Linux Foundation has made a statement:

The Linux Foundation is disappointed in Nokia’s decision today to choose Microsoft as the primary platform for its mobile phones. Tough times give birth to difficult decisions that we don’t always agree with, but open source is — at its core — about choice. We believe that open source software is more than a sum of its parts, and the market is currently bearing that out. The Linux Foundation is here to enable collaboration among its members and the Linux community, and we invite participation in MeeGo and any of our other many projects and programs. In its 20th anniversary year, Linux is a significant underpinning in every computing segment. Full steam ahead.

(Yes, that’s the ED of LF saying “open source is about choice”… blërg.)

After not-so-quietly dumping the first MeeGo smartphone, I’ll wager the MeeGo device they’re talking about (rumoured to be shown for the first time at Mobile World Congress) releasing “later this year” will be closer to a “mobile internet device” and the N800 family than a smartphone, even if it can do 3G and voice.

Qt

Now we’re in bat country. Check out Nokia’s letter to developers:

Qt will continue to be the development framework for Symbian and Nokia will use Symbian for further devices; continuing to develop strategic applications in Qt for Symbian platform and encouraging application developers to do the same.

Extending the scope of Qt further will be our first MeeGo-related open source device, which we plan to ship later this year. [...] That device will be compatible with applications developed within the Qt framework and so give Qt developers a further device to target.

So let’s get this straight: Symbian won’t be Nokia’s primary smartphone platform, but Qt will continue to be used on it, and (fuck knows why) Nokia still plans to ship Symbian devices. MeeGo won’t be Nokia’s primary smartphone platform (though will continue to be developed for future non-smartphone devices), but Qt will continue to be used on it, and Nokia still plans to ship at least one MeeGo-based device.

Who’s on first?

As part of its restructuring, Nokia has returned to having two phone-related divisions: Smart Devices (where the Windows Phone 7, Symbian and MeeGo stuff will happen) for smartphones and presumably other high-end devices of various form-factors and Mobile Phones for the historically large (but now-shrinking) dumbphone market.

There’s always the chance that Nokia takes MeeGo seriously, either as an escape route for the future or for new, non-smartphone devices. The “first MeeGo-related open source device” they plan to ship “later this year” sounds like a “keeping developers happy” play.

But Qt on Symbian might not be the inevitable deathmarch it sounds like… sure, Symbian won’t be the smartphone platform of choice, but it might play a role in Nokia’s attempts to take back the low-end market.

Then again, Nokia has announced that it will help bring Windows Phone 7 down to lower-end devices.

Bottom line for Qt: I would not like to be a Troll today. They’ll be facing layoffs, reduced investment, and for the foreseeable future, life in non-strategic-focus limbo. Unpleasant.

Other options: I can’t see Nokia selling off Trolltech while still relying on Qt for Symbian (although an ongoing development agreement could cheapen the deal). And anyway, who in the Open Source market would want to acquire or poach the core developers?

Intel? Only if their interest in MeeGo survives, and they could just as easily pivot back to GTK+ and/or Clutter (where they have development expertise) given that it was Nokia pushing Qt in the first place.

Canonical? Mark announced only very recently that they’d commit to better Qt support in Ubuntu, mostly for third-party application developers. I can’t see Canonical or any third-party developers being particularly encouraged by Nokia’s decision. I wouldn’t want to second-guess the range of bizarre avenues Mark might pursue, but shovelling money into Qt doesn’t sound like something he’d jump on.

It sounds like a shit sandwich, but there might be a silver lining in this for KDE: Despite never accepting the premise of the criticism, KDE has been stuck under the heel (and on the shifting sands) of Trolltech and Nokia for a long time… could Nokia’s Elopocalypse be KDE’s Independence Day?

Conclusion

Posted in General | Tagged , , , , , , , | 14 Comments

A few thoughts on the aftermath of a linux.conf.au 2011 keynote

During the final keynote of linux.conf.au 2011, Mark Pesce used some images in his slides which breached speaker guidelines and conference policy. Linux Australia and the lca2011 team responded quickly, announcing an apology at the next available whole-of-conference plenary event.

As incidents like this go, it wasn’t a big deal. Although it did distract everyone from the message of Mark’s talk. Hopefully a lesson learned.

The problem was what happened next… here are some thoughts about the aftermath which I originally sent to the attendees’ mailing list.

A few thoughts on the aftermath

  • The response to the keynote was not “blown out of proportion”. There was a breach of policy and an apology was offered by Linux Australia (LA) and the linux.conf.au 2010 team (LCA). The speaker also offered his apology. Done.
  • No “censure” was made, despite the unfortunate subject of an early reaction on the conference attendees’ mailing list, and wilful mischaracterisation by a single, ambulance-chasing opinion writer. Consider that neither LA or LCA have publicly criticised the speaker.
  • We’ve heard some reasonable, well-stated criticism aimed at improving future events and experiences.
  • We’ve seen a fair amount of silly, predictable, confected outrage on the attendees’ mailing list, with debate about censorship, “sexual images” and so on. Here’s an easy answer to those contributors: It’s not your call. Linux Australia and the conference team define the parameters for linux.conf.au, ran the show, and took responsibility for what happened.
  • There has been a small but vocal group who have chosen to debate more general issues, such as how real or prevalent harassment might be. I do hope these people — particularly the more prominent members of our community engaging in it — receive a short, sharp talking-to from their less Neanderthal friends.

What’s next

  • There will be a shit-fight over whether or not the video of the keynote should be published. If it is published, LA/LCA will be criticised for promoting the breach or being complicit in it. If it is not, LA/LCA will be criticised for censorship. Both of these conclusions are bullshit, but I’m sure there’ll be someone willing to give them a red hot go. Either way: It’s not your call. I hope everyone can imagine the range of problems this situation might pose for LA/LCA (including venue, sponsor and hosting considerations), but we entrust them with the responsibility for doing so, and self-righteous indignation won’t help. Those concerned about a gap in the historical record will be relieved to know that Mark has published his slides and an essay based on the talk to his blog: Smoke Signals.
  • We don’t want future events to end on a sour note due to continued haranguing over an issue like this on the mailing list, so there are some bugs to fix.

My suggestions

  • Dump the anti-harassment policy. Apologies to the authors, but it’s badly written (both the lca2011 and Geek Feminism Wiki versions) and unhelpful as an expression of policy or communication, both of which are important. It’s well worth including in references though (as the 2010 team did by mentioning LinuxChix in their T&Cs).
  • Although the lca2011 team adopted Andrew and Susanne’s T&Cs, they were still relegated to the “registration” section of the website, and largely forgotten. This is the right document for policy, and it already very capably expresses the pointy/policy end of the principles LA has adopted. It should be more visible.
  • Pia suggested a Code of Conduct. That’s a great way to adopt a communications document to go with the existing policy (T&Cs), and we already know that Codes of Conduct have found success in other communities. The trick is to ensure it is clearly understood to be a statement of principles, not a policy document.
  • The guidelines provided to speakers regarding slides were already crystal clear: “Please be aware, and ensure your Co-Presenters are aware, of the Terms and Conditions to ensure that Presenters’ material and behaviour is appropriate for the LCA2011 audience, that includes keeping slide-decks G-rated.”

If only “Be excellent to each other” would suffice.

Posted in General | Tagged , , | 9 Comments

Speaking at linux.conf.au 2011 about HTML5 and node.js

Later this month I will speak about “HTML5 web applications with node.js” (see, I’ve already filled half your buzzword bingo card) at linux.conf.au 2011 in Brisbane.

In the presentation I will give a brief introduction to node.js, but mainly focus on building cool stuff with it. Like Denby. I will also attempt to answer the question,

WHY SO ASYNCHRONOUS?

Posted in General | Tagged , , , | 2 Comments

How to mount a VirtualBox VDI image

Don’t believe the hype! It is entirely possible to mount a VirtualBox VDI image, just like a loopback filesystem… all you need are the right tools and know-how. Allow me to illustrate.

My apologies, that was the wrong illustration. Onward!

Before we start, it should be noted that you don’t want to do this while your disk image is already in use. That is to say, if you’re running a virtualised host using this image, GTFO.

First, install the QEMU tools. In Ubuntu, you’ll find them in the qemu-kvm package. Whatever package your distribution ships which contains the qemu-nbd binary should be fine.

Load the nbd kernel module. Yes, I’m serious, the network block device module! (Note: All of the following commands require superuser permissions, so escalate your privileges in whatever way makes you most comfortable.)

modprobe nbd

Then run qemu-nbd, which is a user space loopback block device server for QEMU-supported disk images. Basically, it knows all about weird disk image formats, and presents them to the kernel via nbd, and ultimately to the rest of the system as if they were a normal disk.

qemu-nbd -c /dev/nbd0 <vdi-file>

That command will expose the entire image as a block device named /dev/nbd0, and the partitions within it as subdevices. For example, the first partition in the image will appear as /dev/nbd0p1.

Now you could, for instance, run cfdisk on the block device, but you will most likely want to mount an individual partition.

mount /dev/nbd0p1 /mnt

Gadzooks! Now you can muck around inside the filesystem to your heart’s content. Go ahead and copy stuff in or out, or if you’re feeling fruity, have some chrooty: chroot /mnt.

When you’re done, unmount the filesystem and shut down the qemu-nbd service.

umount /mnt
qemu-nbd -d /dev/nbd0
Posted in General | Tagged , , , , , | 71 Comments