But Perl has taken an entirely undeserved beating in recent years, and so, in karmic balance, it deserves a round of outspoken championship, far more than others need right now. In pondering why Perl’s current reputation is so completely disjointed from the reality of the language, I’ve boiled it down to three “Big Bang Theory”-esque ideas: “The Cookie Slap! Effect”, “The Awkward Adolescence Fallacy”, and “The Singularity Paradox”.

The Cookie Slap! Effect

There’s a “Perl is Dead” meme floating around. It’s been around for a while, long enough that it’s picked up steam and plows along despite all evidence to the contrary. It’s so common, I won’t bother providing links, because you’ve seen more of them than I can count. It’s so common, I even heard it recently from a young MBA graduate, who was so entirely non-technical that he didn’t even know what HTML and CSS were, while working in sales for a web startup. But, he knew what Perl was, and he “knew” it was dead. Weird, but that’s how memes work. So, how did this meme start?

There’s a well-known gaming scenario often called “King of the Hill”, where one player has special status, and the goal of all the other players is to knock that player out of the privileged position and take it for themselves. There was a time when Perl owned the web. It was the duct tape that built the “Web 1.0 City”. There are a number of reasons why Perl succeeded so wildly, but most of them boil down to being in the right place, at the right time, with a fresh, dynamic take on what “programming” should be like, and what “programmers” should be like. There are many things that C excels at, but manipulating massive, variable-length strings is certainly not one of them. And, at the end of the day, no matter what abstractions you layer on it, Web development is essentially about dynamically building and pushing out very lengthy strings of HTML and CSS (and Javascript) to browsers that will decide how to render them. C sucked for that. Really sucked. Trust me, I’ve been-there-done-that.

So, Perl dropped into what was effectively an empty space, at a time when the demand for web services was sky-rocketing. Score! And established itself as the King of the Hill. Score! But then, as the dominant player, Perl also became “the one to beat”. Every upstart young programming language compared itself to Perl. “We’re better than Perl because…” And this is where the “Perl is dead” meme started. It was popular to put-down Perl, because Perl was “unbeatable”. Of course, it was never really unbeatable. The chances that any one language would continue to dominate the web are exceedingly tiny, effectively zero. The chances that any one language will ever again achieve the dominance Perl once had are equally tiny. Especially when you consider the fact that diversity is one of the single strongest cultural values of this miraculous, glorious, networked universe we now inhabit. A cultural value that it partially learned, BTW, from Perl’s TMTOWTDI (there’s more than one way to do it).

So, when you hear “Perl is dead”, remember this, the only reason the meme has strength is because Perl itself has strength. No one feels the need to loudly proclaim “Draco is dead”, because really, no one cares. And secondly, remember that at the root, the primary reason for declaring the untruthful “Perl is dead”, rather than the far simpler and truthful “Perl doesn’t have the domain dominance it once had”, is an insecurity about whatever language the speaker happens to love. Perl is an elder-statesman in a closed system. The shocking truth about the Tiobe Index isn’t that Perl has drifted down over the years (languages wax and wane, just look at C), it’s that all of the languages in the top 20 are OLD in technology-years. It’s like looking at Forbes’ list of billionaires from year-to-year: they shift in position, but once someone’s on the list they have an advantage over all the players who aren’t on the list (massive capital to invest in one case, massive numbers of users and lines of working production code in the other), which means they’re likely to stay on the list.

And, if you’ve ever said “Perl is dead”, my advice is to learn a lesson of tolerance, “live and let live”. Perl won’t plow your favorite language under the carpet, it’s not a threat to you, but I also guarantee your favorite language won’t plow Perl under the carpet. The best you can hope for is to be accepted as a member of “The Fellowship of the Languages”, so grant other languages the same respect you’d like to receive from them.

The Awkward Adolescence Fallacy

Around Perl’s 13th birthday, which just happened to also be the fiery heart of the dot-com bust, the child-prodigy suffered from a massive anxiety attack. As the Web 1.0 world went down in flames, the Perl community was quite literally tearing itself apart. There were a variety of factors, layers of complexity as in any human conflict, but one of the key factors was the nagging doubt that creeps into anyone’s head when things aren’t going as well as you’d hoped: “Maybe it’s my fault. Maybe I didn’t deserve success.” That line of thinking is generally not true, or at least wildly exaggerated, and generally not helpful.

One result of this early-life crisis was the birth of the Perl 6 idea, but I’ll punt that to the next section. Another more subtle (but also more powerful) result, was a growing obsession with things not being “good enough”. The calm confidence of Perl’s youth was replaced by fears that the syntax wasn’t good enough, the implementation wasn’t good enough, the community wasn’t good enough, the foundation wasn’t good enough, the license wasn’t good enough…

To a certain extent fear is a healthy thing, it drives you to push harder, to conquer the thing that you fear. And Perl did. The catastrophic flame-wars of the late 90′s were put to rest. The foundation was restructured and strengthened, and is now one of the most professionally run open source foundations I participate in, with solid, steady funding to run projects that are hugely beneficial to Perl. The Artistic 2 license was introduced as an improvement, but even the existing Artistic 1 license proved itself in court, in a way that no other open source license ever has, and in a way that benefited the entire open source community. The syntax, implementation, and libraries of Perl 5 have improved substantially, to the point that working with “Modern Perl” is really a very different experience than the Perl of 10 or 15 years ago, while still retaining the characteristics that make it a joyful language to code in.

But the bad side of that fear was an awkward, shy hesitation. Like a gawky teenager, Perl stood at the side of the room, afraid to dance because people might think he looks funny. So, I’ve got a news flash for you: no language is perfect, no syntax is perfect, no implementation is perfect, no community is perfect, no foundation is perfect, no license is perfect, nothing is perfect. Perl wasn’t perfect when it owned the web. Perfection is not the first step to success, it’s not even a milestone on the path. And if you really want to understand how irrelevant perfection is, pick any random language you admire, that you see as the pinnacle of success, and closely inspect its syntax, implementation, community, foundation, and license. You’ll find it’s flawed. Why? Because we’re all human, and we all produce things that are deeply creative, deeply wonderful, and yes, somewhat flawed.

It’s time for Perl to grow up. It’s not a teenager anymore. It’s time to accept what it is, accept what it isn’t, and walk on. And what it is, is pretty outrageously amazing. I’ve recently had the opportunity to help a wildly successful startup, in a domain that sorely needs the advantages of modern tech. Perl is the right tool for the job. If I explained the problem space you’d agree, even if Perl isn’t your favorite language. Perl is the right tool for a lot of jobs, all over the world, right now, stable and reliable, in production, with massive numbers of lines of code.

The Singularity Paradox

When Perl 6 was announced, it had a wonderful effect on the Perl community. It provided an “event horizon” to focus everyone’s attention on Perl’s future. It was an inspiration for new creativity, and a distraction from the flamewars to help kill them off. But over time, some things happened that we entirely didn’t expect. The most obvious is that it has taken rather longer that we anticipated. I remember a time when “6 months” was a completely reasonable project estimate for the Perl 6 production release. (Not “By Christmas”, but a real, project-planning 6 months, where I could map out what needed to happen each month.) 13 years later, that clearly didn’t happen. But the time factor is actually a side-effect of other things we didn’t anticipate. The single biggest thing we didn’t anticipate is that the “community rewrite of Perl” has, in fact, turned out to be a community fork. Perl 6 is not like Python 3, which really is a continuation of Python 2, with the same developers, same users, and same community values. (Sometime I’ll write about my interest and contributions toward the Python 3 migration effort, with its own unique successes and challenges.) What grew out of the Perl 6 idea is a new community, a new group of developers, and even a new identity, “Rakudo” rather than Perl (with a phase of “Pugs” along the way). The core Perl developers still work on Perl 5, and have little or no interest in Rakudo. Some of the Rakudo developers have a background in Perl, but many of them have a background in PHP, Java, C#, or other languages.

Rakudo is not an “upgrade” from Perl. It’s revolutionary and exciting, just like Perl was in 1987, but it is not Perl. Please note that I’m not commenting on the similarity or difference of syntax between Perl and Rakudo. If you take a long view over the history of programming languages, syntax is about as relevant to the success of a language as the color of the bike shed. And if you really, really get down to the nuts and bolts, the syntax and functionality of Perl, Python, Ruby, PHP, and Lua are all fundamentally quite similar. That doesn’t make them the same language, and more importantly it doesn’t make them the same community.

So, we stepped into Perl 6 expecting the full power of the mighty Perl community pushing it forward. What we actually got is a tiny band of free-thinkers, re-imagining what “programming” should be like, and what “programmers” should be like. That’s not a bad thing. As new languages go, Rakudo is among the most exciting. But, it’s in that thinly-stretched startup mode where you only get to pick one of “quick, cheap, or good” and it’s optimizing for “good”. In the long-run, that focus will be crucial to Rakudo’s success.

Back to the impact on Perl. Ultimately, the wonderful distraction of Perl 6 has proven… well.. distracting. What was once a very good thing for Perl, is paradoxically now bad for Perl. I recently explained this to a friend as a story of two brothers, Perl and Rakudo Wall:

Perl Wall has finished his advanced graduate degree, and is out building
his career. He was hugely successful for a while, but lately something
strange has been happening. When he goes on interviews, for some reason
people keep pulling up his younger brother’s resume by mistake, and then
tell him “Sorry kid, you don’t have the experience for this job”. But
really, he’s perfect for the job, if only they’d look at *his* resume,
instead of looking at his brother’s.

Rakudo Wall is still a teenager, and walks to the tune of a different
drummer. He’s smart, but he does things his own way. Sometimes
he takes a little longer than the other kids, and sometimes he
leap-frogs past them with a brilliant insight even the teachers don’t
understand. People keep telling him that he should be just like his
older brother. But he’s not, and he doesn’t *want* to be exactly like
his brother. He wants to be himself. Someday, he’ll be awesome, even
outshine his brother. But he’ll get there in his own time, and his own way.

Right now, Perl and Rakudo are getting in each other’s way. They’re like conjoined twins, trying to live separate lives, but always anchored to their brother. That doesn’t mean I love Rakudo any less than I love Perl. I love them both, and want them both to succeed. But their paths are very, very different, and they each need the freedom to walk their own path. The way to grant that freedom is stunningly simple: accept that it is what it is, and let each go its own way, with its own chosen identity. Let Perl be Perl and let Rakudo be Rakudo.

I sincerely hope to see Perl 7 released quite soon. No fuss, no bother, no long list of “blocking features”. Just BAM! ship the next version of Perl (5) as Perl 7. And I sincerely hope the greatest success for Rakudo. I don’t even care if it takes another 13 years to release, it’ll be worth the wait.

The King is dead. Long live the King!

With that context in mind, it’s no surprise that Ubuntu Foundations–the central core behind the many faces of Ubuntu–plays a starring role in this release, both in sessions here at the Ubuntu Developer Summit in Copenhagen, and in the upcoming 6 months of development work. Look for sessions on release roles and responsibilities, release planning including Edubuntu, Lubuntu, Xubuntu, and Kubuntu, archive maintenance and improvements to archive admin tools, reverting package regressions and immutable archive snapshots, cross-compilation, user access to UEFI setup and plans for secure boot, xz compression for packages, image creation tools for Flavors, auto-generated apparmor profiles, PowerPC bootloaders, OAuth for Python 3, “prototype” archives for new hardware, Android ROMs, user experience in distro upgrades, build daemon resources, boot time on ARM, and installation tools on ARM. Also training sessions on the error (crash) tracker, Python 3 porting, and how to contribute to upstart.

On the Cloud front, the big topics continue to center around OpenStack (integrating Grizzly, QA, packaging improvements), Juju (the Charm Store, Charm developer tools, contributor onramps, application servers like Ruby on Rails/Django, development process), and Ubuntu Cloud images (testing and roundtable). While the broader Ubuntu Server discussions range over Xen, LXC, libvert, QEMU, Ceph, MySQL, Nginx, Node.js, and MongoDB, Query2, bigdata filesystem support, and Power architecture virtualization.

The Client side is a harmonic chorus, with sessions on Ubuntu TV, mobile devices and installing Ubuntu on a Nexus 7, plus multiple sessions on Ubuntu as a gaming platform. Also look for the usual sorts of nuts and bolts that go into building a beautiful client experience, like accessibility, battery life, connectivity, config sync, choice of file managers, and consistent typography.

Don’t miss the Design Theatre on Wednesday, where all are welcome to participate and learn about design thinking, solving real-world design problems for apps submitted by the audience.

I can’t wait for tomorrow!

I’ve shuffled and reshuffled the sessions several times, looking for the “governing dynamic”, the thematic structure that holds the Quetzal together. I’ve settled, appropriately, on “quantization”. In general terms, quantization is a process of separating a continuous stream into significant values or “quanta”, such as image pixels from the continuous colors of real life, or discrete atomic energy levels. The theme applies on multiple levels. First, there’s the process attendees are going through right now (in person or remote), surfing the sea of sessions, determining how to divide their time for maximum value.

From a historical perspective, there was another UDS here in California not too long ago, where I recall the schedule was dominated by the desktop. We’re in a different world today, and what struck me reading through blueprints for Quantal is the segmentation of topics. Ubuntu has grown up, and while shipping a gorgeous desktop will always be important, other forms of hardware, both smaller and larger, have an equal (and sometimes greater) influence on Ubuntu’s direction into the future. How do you choose between cloud, metal, TV, and phones, when they’re all so interesting, and have so much potential as game-changers for Ubuntu (and Linux in general)? These different domains of use also lead to differentiation in design, development, and integration. Some significant quanta to watch are:

• Cloud: Juju (integration, charms, charm store, charm testing, charm workflow, release process, with upstart, world tour), Open Stack (roadmap, HA, ARM, charms, backporting, SRUs), Ubuntu Cloud images (roundtable, cloud-init and cloud-utils, publishing), Eucalyptus, Xen, Ceph
• Metal: MAAS (“metal as a service”), ARM server (enhancements, deployment, benchmarking, storage), MySQL (round table, utilities), Open Compute Project, libvert, Chef, XCP, OpenFlow, LXC, KVM, Hadoop, PowerNap, btrfs
• Client: mobile design, TV (control options, GStreamer, get involved), cloud printing, hybrid graphics, USB video, Kubuntu (roadmap, Active), backup enhancements, GNOME, Qt 5, X.org, Gwibber
• Apps: developer experience, events, documentation, developer portal, upstreams, promotion, Quickly

And like an atom that retains its fundamental structure at multiple energy levels, Ubuntu is still Ubuntu, unified at the core as a distribution and as a community, even across multiple “product” targets. Since this is the first release after an LTS, there’s more room than usual to re-examine the core at a fundamental level, with an eye to where we want to be by the next LTS.

• Intelligence: metrics, crash data (part 1, part 2), bug data (Arsenal, automated triage agents, release importance, shadow database)
• Precision: login speed, app startup time, +1 maintenance, automated desktop testing (including LibreOffice, migrations, HDA sound cards, kernel certification, harness), distributed hardware testing, ISO testing, Checkbox
• Scaling: apt at hyperscale (followup session TBA later in the week), large application performance
• Security: AppArmor (testing, development, integration), eCryptfs, desktop lockdown
• Leadership: summit, developer advisory team, code of conduct review, LoCo portal, MOTU developer membership board
• Process improvements: release (tech overview, meetings, infrastructure, schedule and interlocks), use of -proposed, UDD, third-party .debs, SRU process, archive admin API, archive reorg, phased package updates, buildd usage

And those are only the highlights. It’s going to be a great week, and a great cycle!

Over the years, I’ve started thinking that participating in the open source community is like traveling on a path, toward becoming not only better programmers, but also becoming better people by working together.

You might think of it as a path toward enlightenment, growing ourselves as human beings. So what follows is really my personal philosophy which I’d like to share with you.

The first thing is this: The most important part of every open source project is the people. While code is important, the center is always the people.

There are different kinds of people involved in a project: People who code, who write documentation, who write tests. People who use your software, too, are just as important for a project.

Also there are people who work on the software that your project uses — you’re likely using projects from other people in the upstream, and you might want to send them a patch from time to time.

Or maybe you’re writing a library or a module, and so other people will be using your software, and communicating with you as their upstream as well.

So why do people work on open source software? This is a very important question to ask, in order to understand how open source works.

For people’s day jobs, they may be working with software already. And why would they take the extra effort to work on open source? Part of it is that it involves working on exciting things and new technologies.

Sharing is also a large part of it; as we share with each other, we increase the amount of fun for everyone working together on an open source project.

People also work on open source in a spirit of giving to others; in doing that we’re reaching out as human beings, and this is a very important part of being human.

There are many rewards, too. A big one is respect: As we create something new, draw people in, and share software with them that they can work on too, they recognize who you are and what you are capable of, which gives you a sense of accomplishment.

Conversely, it means that we want to make sure that we show respect to people joining our projects in any way we can, because it helps them to stay involved.

Another important aspect is appreciation; as people publish their work, if you talk with them — Even just a simple thank-you email message saying “this meant a lot of me”, it helps bring about a culture that keeps everybody motivated.

Credit is also important. As you are presenting a project, be sure to mention other people around you, saying “this person did such a wonderful thing”, so we can build a feeling of community together.

One of the things that keeps people interested in open source is that, as we work together, we become stronger and can do more.

Part of it is simple math: 2x people makes at least 2x code, and 3x people makes 3x code, although there is much more to it than that.

When we work together, we can make each other stronger and better — part of that is encouraging each other; as you see people working on a very difficult problem, you can encourage them saying “you are doing great, and I see you will do great in the future”.

You can empower people just by talking and sharing with them.

And then also there’s the fact that, when you have many people together, they’ll have different sets of skills. When you are working together, maybe you know the five things the project needs, and they know the other five things, and so you have the complete set of skills to finish the project, which wouldn’t be possible if either of you worked alone.

So the effect is not only a linear increase in productivity; there’s a multiplication effect when people start working together.

Encouraging each other to look beyond, to look into the future, is also important — We can all inspire others to solve interesting problems. Sometimes just saying “I have an idea” is enough for someone else to make it into reality.

Sometimes you’d look at what someone else is doing — you have not done all the work, but you have the critical idea they needed, and so with that idea they can reach out and go much further.

The key thing about working on open source is that we’re not just standing alone. When you are working with other people, the main thing you’d want to improve is your communication skills.

We communicate about the plans we have: How we want to make the software, personal plans such as a feature you want to work on, and so on.

One of the things I observed in open source communities is this: People often have good plans to create software, but they sometimes clash and fail to communicate with each other about plans. If you work on one plan alone, without communication, you may end up hurting people working on other plans.

So it’s like a hive of bees — a constant buzz keeps us all functioning.

We’ll also often communicate about possible futures: What’s the best way to solve a technical problem? When this happens, you may communicate in a way that’s contentious and angry, making it very hard to make actual progress.

One of the things we’re learning in our process is how to embrace all possibilities. Keep working on the possibility you’ve imagined, but remain fully open to other possibilities other people may have.

And as you make progress, you’ll also be communicating constantly about what you have done — There’s email, there’s twitter… there are many ways to let people know about your progress.

Sometimes we may feel shy, or not wanting to be seen as bragging. But that’s not what it is! It’s good for the project, and for the people as well, because they can learn from what you have done.

Another aspect of communication skills is the ability to ask questions. The advantage of having a community is that some people might have solved your problem before, and asking a question on a forum or IRC may save you days of work.

In the same way, when others are learning, you can be responsive to them too, instead of putting them down like answering with “RTFM” for simple questions.

It’s true that answering “RTFM” maybe save you a bit of time, but it is also teaching that person that they shouldn’t ask those questions in the first place. That is not what you want to teach people at all — you want to teach them to communicate with others.

Also, learn how to make answers that are helpful to people, and help them see that they can also walk down the path as well, and take the path further in the future.

Sometimes you do have to criticize people; we should be open to many ways of doing things, but sometimes one technical solution really is more correct than others. However, the best way to get people to change their ways is to answer them kindly, so they can be open to learning from you.

You have to show some grace, even to people who do not respond very well. Some people may be harsh with you, but this is also part of the path. Sometimes it helps to have a thicker skin, and even in situations when other people should have said things nicer and better, maybe there’s a bit of truth in what they are saying, and you can still learn from that.

From this perspective, even if they speak in a way that is not polite, you can still respond politely.

The other half of communication is not talking, but listening. Instead of telling others what we think, sometimes all that’s needed is just sitting very quietly, and let others talk.

It’s not just listening, though — it’s important to have empathy. As the saying goes, “If you really want to understand someone, you have to walk a mile in their shoes” — perhaps so you can get the blisters they have experienced.

Now, some people think you have to be a genius to work on open source software, but that is simply not true. There are people like Larry and Guido and Linus, yes, but there are also so many different kinds of talents that any projects needs, too.

And no matter how smart you are, it’s important to stay humble. Because with humility, you will be open to other people, and see new ways of doing things. Humility lets you welcome other people into your project. Pride, on the other hand, is essentially telling people “I don’t need you; I can do things my way.”

By being humble, we also welcome people with diversity of genders, of different cultures, creating a richness in open source by opening to different kinds of people.

The diversity also appears between different projects; it’s almost like languages and cultures of different countries. For example, the community around Linux, Perl, Ruby, and Python all communicate and collaborate differently.

And by being humble with each other, maybe we can see that our project is not the only way, and maybe we can appreciate the ways of other communities.

Now, open source is not all about fun — it’s fun, of course, but it’s also a responsibility. When you agree to participate in a project, you’re taking a weight on your shoulders, and it’s a good thing, as it teaches us to improve ourselves and become better humans.

But life can get in the way — significant others, parents, children, jobs — we may accept responsibility for a time, but there may also be a day where we can’t carry so much responsibility anymore.

So there is a cycle, where you start by assuming more and more of a role in a community, and as life goes on, you gradually take on less and less responsibility. This is entirely natural, and it’s bound to happen in a project’s life cycle.

So it’s worth keeping this question in your mind: “Who will continue my work when I no longer have the time?”

To make sure other people can continue our work, we can think of it as a continuous process: Teaching and sharing the knowledge we’ve learned, and at the same time learning more and more from other people — a continuous process of gaining and sharing knowledge.

Finally, as you work on open source, please be happy, with a smile on your face, and make other people happy! Because this happiness is what gives us the power to make great things.

Do you feel happier now?

I created it using Rick Spencer’s Quickly templates (GTK, Glade, and Python). I went for a streamlined workflow for the way I use tasklists, so I’m curious if it will map well to others. It appears as a simple text file, with a search box at the top of the window. Clicking on a tag performs a search for the tag (these are similar to Twitter tags, any word that starts with “@” or “+”). The list sorts tasks by priority (marked with “A”, “B”, “C”, etc) and then alphabetically. When the list is limited to search results, the search terms are highlighted in the tasks.

Clicking on the text of a task brings up an editor window, with a checkbox for “Done” tasks, a field to edit the task, and clickable palettes for task priorities and all the tags you’ve used previously in your tasklist. It’s streamlined with shortcuts, so typing Space, Enter marks a task as done, saves it, and closes the editor window.

I’ve started using Tody as my primary task manager, after dumping all my old tasks from other task managers into one text file. I’d like to tweak the search feature, right now it does a completely literal string search, but I’ll change it to split up search terms (so it’s not sensitive to order of terms). Then the next step is to link it up with my Todo Lens, so the edit window for Tody pops up as the action for clicking on a task in the Lens.

The Tody app is up on my PPA, let me know if you try it out and have any requests for features that fit your workflow:

https://launchpad.net/~allison/+archive/ppa

I like Thymer’s simple task creation, twitter-like tagging of tasks, and the smooth drag-and-drop motion for prioritization. But, at the end of the day, it’s just a massive web page of “things I should be doing” and gives me no assistance in taming the beast. I have to manually prioritize each task, and if I want the priorities assigned to tasks to be at all relevant, I have to go on manually gardening them every day. And, while task creation is as easy as tweeting, task editing is a clunky collection of buttons and drop-down menus. The tags are handy in small numbers (and projects really are just tags with a slightly different display), but any more than about 10 unique tags/projects across my whole data set becomes a jumble at the top of the screen and not at all helpful in finding anything. Thymer offers some reporting features, but I never found them particularly useful.

I like Rypple’s social features, it’s got a good take on sharing thanks and feedback, and the 1:1 pages (a collection of tasks you share with another person) are incredibly useful for weekly meetings with co-workers. I like the organization of tasks by goal rather than by project, it encourages grouping tasks into larger sequences toward an overall purpose. But, I found that I still needed some goals that were really just projects or a collection of semi-related tasks, so the construct was a little artificial. Rypple offers a tagging feature, but tag links don’t do anything useful (like take you to a page listing tasks with the same tag), and a task can’t live in more than one goal at the same time, so there isn’t really any good way to pull up a group of cross-cutting tasks. And, Rypple also gives me little help in managing the mass, though it has drag-and-drop priority setting similar to Thymer.

The worst thing about both of them is that they’re neither open source nor open data. Philosophical considerations aside, this is an immediate practical problem, since my access to Rypple was only a free trial which is now ending.  I started with the best intentions of only putting in a few things to try it out, but it quickly became an integrated part of my working life, and I now have well over a hundred little individual blobs of data (tasks) that I’m tracking there. Because it’s not open source, I can’t fire up my own instance of it. And because it’s not open data, I can’t get a dump of my tasks. So, I’ll have to manually copy every bit to some other task management system. Which means I’m in the market for a new task management tool, with a very immediate enlightened self-interest in picking something that’s both open source and open data.

Yesterday, I tried out Todo.txt. The biggest appeal is the simple open data format, so simple that it would work just fine as a manually edited plain text file. But, it offers a GPL licensed command-line client for easier task creation, searching, sorting, grouping by project, priority, or “context” (a notion from “Getting Things Done“). It also offers a GPL licensed Android client, which is in the process of being ported to the iPhone. On the downside, it doesn’t offer any collaborative features, so I can manage my own tasks, but can’t share tasks with others, or even provide visibility to others on a subset of my tasks or projects. And while creating tasks on the command-line is clean and simple, actually viewing/managing my 100+ tasks on the command-line (or Android client) feels a bit like viewing an elephant through a pinhole. It doesn’t have a desktop GUI client, though the wiki offers some suggestions on ways to integrate the simple plain text format into other desktop tools like Conky. The results weren’t thrilling (not really any better than the command-line), but they did give me an idea: how about a Unity Todo Lens?

I spent a few hours hacking on that, parsing the Todo.txt format in Vala and displaying the results in a Unity Lens with a general search box and filters for Project, Priority, and Context. I’m pleased with the result for a short experiment, but there are some drawbacks. The Lens really wanted my filters to be statically compiled in advance, while I wanted to create the filter sets on-the-fly from the Todo.txt file (i.e. let me filter by Projects that are in my tasks, not for some list of projects determined in advance). I may be able to hack around that with more time or a Python Lens instead of Vala. Also, a Unity Lens is a great interface for searching tasks, but not great for managing tasks. There’s only one “action hook” for a task, when you click on the icon/title. You can make that one action do anything you want, but it’s still only one action. I could make that one action mark a task as done (that seems most logical), but I’d still have to go back to the command-line to add new tasks, and edit task descriptions, priorities, projects, contexts, etc… Which takes me back to the original problem that the command-line isn’t a great interface for those tasks. What I really want is a slick, simple GUI client that the Lens could launch whenever a task is clicked in the search interface. Possibly a project for another weekend.

That’s all the time I have to work on the idea right now. While I leave it sitting for a bit, any suggestions on free software+open data task management tools you love? Or hate?

I’d like to thank the entire Ubuntu community for renewing my faith in the humanity of free software. When I stumbled on Ubuntu all those years ago, I had already been working in free software for what felt like a century, and was…well, tired. Your joy and delight in bringing free software to the world inspired me, and restored my passion for contributing. The heart and soul of free software is people like you, changing the world for the better every day. Thank you all!

1) When I run through the standard install process with the Kubuntu 11.10 amd64 CD, I get exactly the same problem as James: I end up with a machine that has Kubuntu installed on a partition, but will still only boot into Windows. (I also get an explicit error message during the install saying “The ‘grub-efi’ package failed to install into /target/. Without the GRUB boot loader, the installed system will not boot.”)

2) Installing from the Kubuntu CD and wiping the HD has the same problem as (1), and the same error message.

3) Installing from the Ubuntu 11.10 amd64 CD into the same dual-boot configuration as (1) also won’t boot the Ubuntu partition, but it gives no explicit error message about the grub install failure.

4) When I install from the Ubuntu 11.10 amd64 CD and completely wipe the HD and replace it with Ubuntu, the install works perfectly, and the machine boots into Ubuntu afterwards with no problems. I can also install the ‘kubuntu-desktop’ package on the working system, and get a working Kubuntu desktop. This tells me that we’re not dealing with a UEFI or hardware compatibility issue here, just an issue with partitioning and the bootloader. Which is what James and I suspected last week, but it’s nice to have explicit confirmation (without wiping his friend’s machine).

5) Back to the Windows/Ubuntu dual-boot scenario in 3. Installing EasyBCD doesn’t quite work. It does give me a prompt in the “Windows Boot Manager” to choose between Windows and Ubuntu, but when I choose Ubuntu it just takes me to the grub prompt. That’s progress anyway. At the grub prompt, I type:

grub> root (hd0, 4)
grub> kernel /boot/vmlinuz-3.0.0-12-generic root=/dev/sda5
grub> initrd /boot/initrd.img-3.0.0-12-generic
grub> boot

And, it boots fine from the Ubuntu partition.

That’s all the time I had so far. A few observations about the system as it shipped from the factory. Windows is booting using a custom bootloader, the Windows Boot Manager which bypasses UEFI. In the dual-boot configuration that doesn’t work, the UEFI “BIOS” configuration and the efibootmgr command-line utility both recognize that the machine has a UEFI boot option for “ubuntu”, but choosing that during startup from the boot options still diverts straight to Windows. The machine didn’t ship with GPT partitions (which are one of the advantages of UEFI), instead it shipped with an old-fashioned MBR partition scheme (limited to 4 physical partitions). The working Ubuntu configuration (total machine wipe) does set up proper GPT partitions.

I copied my iPod music library over to Rhythmbox’s local library, just to try it out. It copied 3,249 tracks out of the 3,359 that were on my iPod. I got a few errors about duplicate files during the copy, all with generic file names like “01 – Track 01.mp3″. There were ~4-5 CDs like this, each with ~19-25 tracks, so that seems to account for the missing 110 tracks, though I didn’t keep exact notes, or do an exact comparison to see which files were missed. I’m guessing a handful of CDs I had loaded on the iPod were ripped with generic file names rather than specific titles, and that the iPod was separating them by directory structure, while Rhythmbox was loading them all in one directory so the file names conflicted. Just a guess, I’ll look into it more later if it ends up being useful.

Things I wish for in Rhythmbox:

• The ability to copy a playlist from the iPod to the local music library, instead of recreating it.
• The ability to synchronize my music and playlists between different computers/devices (will look into Ubuntu One for this later, it has some relevant features, though possibly not yet the full user journey I’m looking for).
• A way to split up my local library into Music, Audiobooks, and Language Learning. Shuffle mode is pretty useless when it brings up random chapters of “The Hitchhiker’s Guide to the Galaxy” or snippets of Afrikaans language drills. I found suggestions that it’s possible to configure multiple Libraries for Rhythmbox in gconf even though it’s not displayed in the GUI, but there was no ‘library_locations’ key in /apps/rhythmbox, so I’ll have to poke around a bit more later to see if it’s still a valid key in current versions of Rhythmbox. (Separating libraries is a problem on the iPod itself, so this is just a same-old existing irritation repeated in a new piece of software.)
• A shinier user interface, that makes it easier to find artists, albums, or songs I want to listen to.
• More informative error messages when failing to copy files.
• I found one work-in-progress on integration between Rhythmbox and the Music Lens, I’d like to see that complete.

It’s important to distinguish between UEFI in general and the new secure boot feature. UEFI has been around for a while, starting its life as the “Intel Boot Initiative” in the late ’90s. It has a number of advantages over old BIOS, including substantially faster boot times, the ability to boot from a drive larger than 2.2 TB, and the ability to handle more than 4 partitions on a drive. The UEFI specification is developed by the members of the UEFI Forum, a non-profit trade organization with various levels of free and paid memberships. UEFI is not a problem for Linux. At the UEFI Plugfest in Taipei last week, Alex Hung (Canonical) tested Ubuntu 11.10 on a number of machines, with success even on pre-release chipsets. The few failures seemed to be related to displays, and not particularly to UEFI.

The secure boot feature of UEFI is a concern for Linux, but not because of the specification. The features outlined in the 2.3.1 specification are general enough to easily accommodate the needs of Linux. But, within the range of possible implementations from that specification, some alternatives could cause problems for Linux. For full details, I recommend reading the two whitepapers released by Canonical and Red Hat and by The Linux Foundation. The short version is that secure boot uses signed code in the boot path in much the same way you might use a GPG signed email message: to verify that it came from someone you know and trust. The beneficial ways of implementing this feature allow the individual (or administrator) who owns the machine to add new keys to their list, so they get to choose who to trust and who not to trust. The harmful ways of implementing this feature don’t allow the user to change the keys, or disable the secure boot feature, which means they can’t boot anything that isn’t explicitly approved by the hardware manufacturer (or OS vendor). This would mean users couldn’t just download and install any old image of Debian, Fedora, Red Hat, SuSE, Ubuntu, etc. So, there’s real potential for a future problem here, but we’re not there yet. At this point, it’s a matter of encouraging the hardware companies to choose the beneficial path.

I’ve been chatting with the Ubuntu user who had the install problem, to see if we can find the real bug. It’s a friend’s machine rather than his own, so he doesn’t have easy access to it. I’ve arranged to get access to a similar machine next week to play with it. I’ll post back here if I find anything useful or interesting.