We'll see | Matt Zimmerman

Calyx and I purchased a new ironing board recently.  Unlike any other I have seen, it came with a curious red rubber object attached to it with a ball chain.  It is roughly spherical in shape, with a hole through its center, and has resisted all attempts at analysis and experiment.

A Google search found only this entry on Yahoo! Answers, which is a mystery in itself:

• The “best answer” claims it is for hanging the ironing board in storage.  This seems preposterous to me, because:
  • the ball chain and fastener are not strong enough to safely hold the ironing board
  • the sphere is much thicker than necessary for this purpose, and would be awkward to fit a hook through
  • it’s attached near the long edge, at the center of the ironing board, when logic would suggest hanging it vertically from the short edge
• Another popular explanation is that it can be placed on the tip of the iron. This doesn’t make sense either, because:
  • it doesn’t fit on our iron
  • if it did fit some other iron, its shape and texture would prevent the iron’s surface from resting on the fabric, which would make it ineffective
  • there’s nothing to keep it attached there
• Some people say it’s for the cat to play with to keep it out of the way of your ironing. I like this explanation best, but not because I think it’s true.

Any other ideas? Does anyone else have one of these?

Update: It appears to be a safety mechanism, which fits over the lever which holds the legs in place. By placing the ball over the lever, the operator can prevent the ironing board from being inadvertently collapsed by a child or a wayward limb. Thanks to everyone who offered suggestions!

The gold master for Ubuntu 9.04 was finalized and released on Thursday, and remains a hot item for download today.  With the bits safely out the door, I paused to think about what made this release special, and soon realized that version 9.04 was the tenth release of Ubuntu.  With two Ubuntu releases each year, this means that it has been five years since I first became involved with the project.  A great deal of my time during those years has been spent working to enable Canonical and community developers to work together to produce a system that is a pleasure to use and share.

I am amazed at how much has happened in that time.  Here are some of the things which give me a sense of how far Ubuntu has come.

In 2004, Ubuntu itself was a single product which came in two parts: an installation CD and a live CD for 32-bit x86 computers.  Along the way, we’ve vastly expanded the number of ways to obtain, install and use free software through Ubuntu, having:

• added an official 64-bit edition (5.04) and six additional ports
• combined the installation and live CDs into a single medium which serves both functions (6.06)
• created the Server Edition (5.10) and Netbook Remix (9.04)
• developed a simple upgrade system which guides users to the next release when it becomes available
• inspired dozens of derivative products such as Kubuntu and Xubuntu (five of which released new versions in sync with 9.04)
• added installation DVDs (5.04) and support for USB flash media which can be used to install both desktops and servers
• added a long-term support (LTS) option  (6.06)

Launchpad barely existed when Ubuntu 4.10 was released.  We were using a modified Bugzilla for bug tracking, and Debian’s dak toolkit to build packages and manage the repository.  Today, Launchpad is a central piece of infrastructure for Ubuntu:

• hosting nearly 300,000 bug reports
• managing official repositories of hundreds of thousands of Ubuntu packages (with even more in PPAs)
• enabling translation of virtually every piece software in Ubuntu
• destined to become open source later this year
• hosting thousands of upstream projects
• soon to be providing revision control for the entire source code for Ubuntu using Bazaar
• providing a massive cross-referenced index of all of this data, including web APIs

The Ubuntu community, now an essential part of keeping Ubuntu going, was only just beginning in 2004.  We had a basic governance structure, a couple of public mailing lists and a wiki, mostly populated by ourselves and people we knew through the open source community.  Since then, some of the highlights for me have been:

• the establishment of the Ubuntu Forums for users to share experiences and help each other, now with over 800,000 users and 1,000,000 threads
• the incredible growth of local Ubuntu community teams, of which there are now over 70 worldwide and many more in the process of becoming official
• the growth and diversity of the Ubuntu blogosphere, as reflected in Planet Ubuntu, Planet Ubuntu Women, The Fridge and other aggregators
• the addition of over 500 official Ubuntu Members, acknowledging a sustained and significant contribution to the project
• seeing social networking groups on Facebook, LinkedIn and other sites with tens of thousands of members
• the celebration of Ubuntu releases through parties around the world, of which there were over 100 known for Ubuntu 9.04
• the emergence of Ubuntu community news publications such as the Ubuntu Weekly Newsletter and Full Circle Magazine
• the creation of Ubuntu Brainstorm to group and rank suggestions and feedback from Ubuntu users

In the beginning, of course, Ubuntu was known to few people other than its own developers.  Today, the fact that Ubuntu has touched so many lives is an important motivation for many of us to continue our work on the project.

• we can’t be certain how many people are using Ubuntu globally, but estimate the number to be over ten million based on Internet traffic
• Ubuntu has received extensive press coverage, including appearances in mainstream publications such as The New York Times
• Ubuntu community members report frequent recognition of Ubuntu in public (for example when wearing an Ubuntu T-shirt) in countries around the world
• Ubuntu has been ranked the most popular distribution in surveys of Linux users, including the Linux Foundation client survey
• Many of our friends and family members, who are not particularly interested in tinkering with their computers, use it and love it too

Canonical, the company which has made Ubuntu possible, has changed dramatically as well.  From its inception as a startup comprised mainly of a small engineering team, Canonical has grown to:

• over 200 employees, with over 20 open positions at the time of this writing
• a service portfolio including award-winning technical support, custom engineering for OEMs, professional training and more
• tens of millions of dollars in revenue
• hundreds of local partners offering products and services around Ubuntu

Such rapid growth has brought about great challenges in all of these areas, and provided plenty of opportunity for personal development.  I’ve had the opportunity to work with the most talented and dedicated team of my career, a team which spans corporate, national and social boundaries.  Together, we’ve broken new ground in realizing the potential of free software.

Here’s to the next ten releases!

To celebrate the stabilization and release of Ubuntu 9.04, I’ve destabilized my primary (work and personal) laptop a bit by migrating from ext3 to ext4, following (more or less) the procedure I found on the ext4 wiki.  I created a fresh 9.04 USB stick with usb-creator, booted it, ran the procedure, mounted the filesystem, updated /etc/fstab, and rebooted from the internal disk.

In order to try out the delayed allocation feature, I re-allocated (via cp/mv) some parts of my disk which I thought might benefit from being less fragmented, such as:

• *.sqlite in my Firefox profile directory (urlclassifier3.sqlite went from hundreds down to 3 extents)
• the .iso files I use for testing Ubuntu in KVM (ubuntu-9.04-desktop-i386.iso went from 2391 down to 71)
• my mutt cache (discovering in the process that it now uses a different format, so I couldn’t compare)

(note: filefrag(8) will tell you how fragmented a file is)

I expect that defragmenting my system libraries and other startup data would get my system booting a bit faster, but I think I’ll just let that happen naturally when I upgrade to Karmic.

I did some stress testing by running a large offlineimap update while starting up Firefox and deleting some large files, and was rewarded with a solidly frozen system (no network response, no caps lock, no response to SysRq).  I could not get any information about the cause of the crash, though the proximity to the ext4 switch is certainly suspicious…

Onward to Karmic!

Last Friday, an unfortunate individual in Boston had their civil rights violated when their property was seized, due to suspicious behavior including an aptitude with computers and the use of a command-line interface.

This prompted a round of email in my inbox, because the above article was written by Matt Zimmerman, senior staff attorney at the EFF. Although we know some of the same people, and our work is somewhat related, we are decidedly not the same person. I am not moonlighting as an attorney, and although I am a member of the EFF, I am not a member of its staff.

Indeed, I have never met the other Matt Zimmerman, though perhaps one day I will. Hopefully, we won’t turn out to be evil twins, or annihilate each other in an anti-Matter reaction.

It’s a phrase I hear every day: “I don’t have enough time to do that.”

Recently, I’ve been thinking a lot about the trivial things we say, particularly when a poor choice of words can obscure our meaning.  Conventional wisdom supports “calling it like it is,” but taking an objective view is rarely as easy as that.  Our use of language is inescapably tied to our personal experience of the world, and therefore pure objectivity in speech is virtually absurd.  Perhaps instead we should “call it by its true name,” which is sufficiently mystical and subjective to get to the heart of the matter.

What do we mean when we say that we don’t have time?  If a task would require two hours, but is due in an hour, then we don’t have time to do it.  Who could argue with that?  However, more frequently, we mean “I can’t do that in addition to everything else I’m doing.”  If I have a full week’s work to do, and something new comes in which would require a whole day to complete, I might say that I “can’t” do it this week because “I don’t have the time.”  I clearly have enough time, though, because a day is less than a week.  If the task were important enough, I would do it instead of something else.

This brings us a step closer to what we really mean, which is “that is less important than my other obligations.”  What a difference it makes to consider the situation in this way!  I have shifted from a position of powerlessness (“I can’t”) to one of decisiveness (“I choose not to”).  Nothing about my circumstances has changed, but I’m now communicating a different view of the world, one in which I’m taking responsibility for my choice.  This also opens the way for discussing what your priorities are, and making adjustments if circumstances have changed.

In other news, I’m told that London youth have taken to saying “I have a lot of time for that” to mean that they like something.

When a bug is filed in a free software project’s bug tracker, a social exchange takes place.  Bug reporters give their time and attention to describing, debugging and testing, in exchange for a fair chance that the problem will be fixed.  Project representatives make the effort to listen and understand the problem, and apply their specialized knowledge, in exchange for real-world testing and feedback which drive improvements in their software.  This feedback loop is one of the essential benefits of the free software development model.

Based on the belief that this exchange is of mutual benefit, the people involved form certain expectations of each other.  When I report a bug, I expect that:

• the bug will be reviewed by a project representative
• they will make a decision about the relative importance of the bug
• project developers will fix the most important bugs in future releases of the software

When I receive a bug report, I expect that:

• if more information is needed, the bug reporter will supply it
• if I can’t diagnose the problem independently, the bug reporter will help with the analysis
• if I need help to test and verify a fix for the bug, the bug reporter will provide it

Naturally, everything works best when the system is in equilibrium: there is a steady flow of testing and bug reports, and users feel satisfied with the quality of the software.  Everybody wins.  Ideally, much of this activity takes place around pre-release snapshots of the software, so that early adopters experience the newest features and fixes, and developers can fix bugs before they release a new version for mainstream use.  This state produces the best quality free software.

Unfortunately, that isn’t always the case.  When our expectations aren’t met, or sufficient progress is not made, we feel misled.  If a bug report languishes in the bug tracker without ever being looked at, the bug reporter’s time and effort have been wasted.  If the report lacks sufficient detail, and a request for more information goes unanswered, the developer’s time and effort have been wasted.  This feeling is magnified by the fact that both parties are usually volunteers, who are donating their time in good faith.

The imbalance can often be seen in the number of new (unreviewed) bug reports for a particular project.  At one extreme (“left”) is a dead project which receives a flood of bug reports, which are never put to good use.  At the other extreme is a very active project with no users (“right”), which suffers from a lack of feedback and testing.  Most projects are somewhere in the middle, though a perfect balance is rare.

Ubuntu currently receives too many bug reports for its developers to effectively process, putting it well left of center.  It has a large number of enthusiastic users willing to run unstable development code, and actively encourages its users to participate in its development by testing and reporting bugs, even to the point of being flooded with data.  A similar distance to the right of center might be the Linux kernel, which receives comparatively few bug reports.  Kernel developers struggle to encourage users to test their unstable development code, because it’s inconvenient to build and install, and a bug can easily crash the system and cost them time and work.  There are a huge number people who use the Linux kernel, but very few of them have relationships with its developers.

So, what can a project do to promote equilibrium?  Users and developers need to receive good value for their efforts, and they need to keep pace with each other

The Linux kernel seems to need more willing testers, which distributions like Fedora and Ubuntu are helping to provide by packaging and distributing snapshots of kernel development to their users.  The loop isn’t quite closed, though, as bug reports don’t always make their way back to the kernel developers.

Ubuntu, perhaps, needs more developers, and so we’ve undertaken a number of projects to try to make it easier to contribute to Ubuntu as a developer, and to help our developers work more efficiently.  Soon, it should be possible to commit patches directly into Launchpad without any special privileges, so that they can be easily reviewed and merged by project developers.  This isn’t a fix, but we hope it will help move us closer to a balance.

What else could we try?  I’m particularly interested in approaches which have worked well in other projects.