Other posts related to paper-cuts

 | August 17, 2010 7:07 pm

Though I love Ubuntu, there is one aspect of its package management that I am significantly less than thrilled with, the pace of incremental updates.

Prior to release, Ubuntu (and other software manufacturers) spend a great deal of time testing, tweaking and otherwise ensuring that the software they ship is of high quality.  This is a good thing, it ensures that the platform is stable and works well.

However, there is also a downside.  It means that, other than very minor security upgrades, software only gets updated during Ubuntu’s six month refresh cycle,  and, if you don’t upgrade to the newest Ubuntu, you will often get stuck using older versions.  (Even if those older versions have known bugs and issues.)

Most of the time, this isn’t a tremendously big deal.  After all, Ubuntu is completely free and upgrades are mostly painless.  Sometimes it is, though, and there is one case is currently having a negative impact on Ubuntu (10.04) users who use LyX.

Show me more… »

 | July 20, 2010 4:45 pm

imageOpen Source is unique in that much of it arises from a desire to scratch one’s own itches.  Or at least the very best Open Source does.  It’s written by the very people who will use it, and as a result, meets a real rather than perceived need.  This lets it bypass any inane stupidity associated with Average Joe User.

Unfortunately, there is also a downside.  A great deal of open source software is only developed to the point of being “Good Enough.”  The program’s authors know exactly what they need to accomplish and do not extend the capabilities of the code much beyond their own front doors, which is a true shame.

I certainly understand their rationale.  “Going the last mile” to a fully polished utility is a hell of a lot of work.  In fact, the last mile may account for up to 60% of the man-hours (based on an unscientific survey of my work on LyX-Outline and Time Drive).  It involves tracking down bugs, optimizing/refactoring code, and extensive testing.  Underestimating challenges associated with the “last mile” have lead to delays in my projects, and I’ve heard the same thing from other developers.

What this often means is that the testing, polishing, and the other fine-tuning needed for superb software doesn’t happen.  Even worse, many of the minor annoyances and inconsistencies never get addressed and are subsequently passed downstream to other projects and users.

Of course, what is a minor annoyance to upstream becomes a major headache to those downstream.  After all, such projects (like Linux distributions) not only have to deal with the “minor” problems of one upstream source, but of thousands.  Moreover, the annoyances build upon one another until they become paralyzing and impede forward progress.

The Ubuntu project has a term for these annoyances/inconsistencies that I quite like.  It refers to them as “paper cuts”.  In the real world, a paper cut is a trivial wound that hurts far more than it should.  Ditto for the software equivalent.  In the big picture, the problem shouldn’t be a big deal; but it is, and whenever you run into it, it stings.

Here’s Ubuntu’s formal definition:

A paper cut is a trivially fixable bug.  They may be an unintended problem occurring within an existing piece of software, the presence of which makes a computer more difficult or less pleasant to use, that is easy to fix [and really shouldn’t be there].

As you can probably tell, I think that resolving these annoyances is important.

To users, Paper Cuts influence their perception of the platform, and may be responsible for driving people away from Linux; and overcoming a first impression is ludicrously difficult.  If someone has had a poor experience with Linux (or Open Source) in the past, it is not only likely to influence their own future choices, but also what recommendations they make to friends and colleagues.  Put another way, the effect of poor impressions (such as those created by paper cuts) isn’t linear, it’s exponential, and far out of proportion to their overall severity.  For this reason, the resolution of paper cuts might be the most important contribution that Ubuntu has made to the world of Open Source.

Now, before someone takes me task, let me explain.  I’m not talking about the actual bug fixes themselves – even together, the fixes are trivial.  I’m talking about the culture that has begun to permeate the Ubuntu project.  You’ve probably run into evidence of it.  It’s the culture that prompted to Mark Shuttleworth to get on stage at OSCON 2008 and encourage developers to out-prettify Apple within two years; the culture that values a highly polished product and says that we should refine existing functionality before piling on new features; and the culture that has caused Linux to hit its stride as an operating system.

And it’s a spectacularly Good Thing.  Due to the culture shifts that Ubuntu (and related projects) have caused, there is finally some impetus for up-stream developers (like me) to polish our releases and create superb software.  With impetus comes incentive, and incentive has the ability to actually change behavior.

(Which reminds me, I should probably get back to work on LyX-Outline.)

 | July 9, 2010 10:30 pm

Ubuntu-BlackSeveral weeks ago, the Ubuntu related blog OMG! Ubuntu! published an extremely interesting piece entitled, “Many Hands Make Light the Work; Few Make It Shine” by Benjamin Humphrey (of Ubuntu Manual fame).  The article repeated and expanded upon several mantras currently popular in the Ubuntu community right now, specifically:

  • Developers should give very careful thought to the features they add to their programs and ensure that they integrate with the desktop as a whole
  • Linux desktop has a large number of minor issues (often referred to as papercuts) which detract from its consistency and usability; these need to be fixed
  • It’s not the ideas that matter, but their implementation; and if you’re going to do something half-assed, it’s worse than if you don’t do it at all

Overall, I agree with the message of the article.  It shows that the design philosophy and attention to detail of the Mac  community is starting to permeate the Linux community; and that is a spectacularly Good Thing.

But even though I agree with the message of the piece, I found myself in opposition to it.  I wrote several diatribes in the comments, and then proceeded to defend those positions to the death.  (Even though a few of them were pretty extreme.)  That’s not something I do very often.

Since I can already see the strange looks and hear the unasked question, I’ll just go ahead and give it voice:

What on earth could set you off like that?  (Especially in such an innocuous article.)

There is both a simple and complex answer to this question.  Here’s the simple version.

You might say that the article (and especially some of the comments) touched a nerve.  Actually, that’s not quite right.  The article didn’t just touch a nerve, it scraped it raw, stretched it out, and encouraged Michael Flatley and his troupe to Irish stepdance all over it.

Ready for the more complicated version?

Show me more… »

 | July 3, 2010 5:00 pm

Java-IconIn general, I don’t really care for Java.  I think it’s slow, clunky, ugly … and, well, you get the picture.  But even though Java may not be my favorite computer language, I do recognize a fundamental reality: it’s a pretty essential component of any operating system, especially on Linux.

The amount of stuff that requires Java is absolutely staggering, and you don’t begin to really appreciate how important Java is until it stops working.  Which brings me to the main point of this posting, it seems like every time I upgrade my Ubuntu distribution, it wants to stop working.  Unfortunately, my recent upgrade to Ubuntu 10.04 was no exception.

Now – in an ironic turn of fate — I actually understand the reason for that Java breaks whenever you upgrade to the newest version of Ubuntu.  From an ideological standpoint, I even agree with it; somewhat.  But consciously appreciating the rationale behind something and having to clean up its mess are two very different things; and I dislike adjusting my daily routine because of ideology.

Here’s the problem.  Ubuntu, like most Linux operating systems, strives to be Open Source.  As I said, part of the reason for this is ideological  — Ubuntu wants to include only the best Open software available – but part of it is also practical and legal, meaning that any GPL software package more or less requires that related software also be GPL.  And therein lies the problem with Java, and why it seems to break every time you update to a new version of Ubuntu.

There isn’t just one version of Java.  Really, there are two.

One is the Java VM, distributed by Sun Microsystems (now Oracle), that you’ve come to appreciate and love on every major platform.  Even though it is everywhere, the Oracle version of Java isn’t completely Pure; and for that reason, a few narrow minded zealots individuals feel that it shouldn’t be included in Ubuntu by default.

The other Java version, in contrast, is a true open source implementation that doesn’t require you to give up any of your free-software rights.  I’ll refer to it as Open-Java.  As I said above, there are good ideological reasons to support and use Open-Java.  But even so, there is also a big technological reason not to: they haven’t quite ironed out the kinks yet.

Every time I upgrade Ubuntu, I have high hopes for Open-Java.  And every time I upgrade Ubuntu, I re-learn my lesson: Open-Java is still not ready for prime time.  This morning, I learned it in particularly painful fashion while trying to finish a chapter in my book on the Zotero Cite-While-You-Write plug-in.

After performing flawlessly for months (nearly seven of them, in fact); the plug-in simply refused to work.  I would Open Zotero in Firefox, and that worked fine.  Then, I would launch OpenOffice Writer, and that would work too.  But when I tried to insert a new citation, my computer would beep and say, “Unable to connect.”

Zotero-LogoWhat the hell?

This was very frustrating to me.  Unable to connect to what?  OpenOffice was running and working.  Zotero was running and working.  There shouldn’t be a problem. Yet, there was.

I’m a control freak.  Random breakages annoy and anger me, and this particular breakage was absurdly frustrating because Zotero had worked just fine the previous week, prior to upgrading to Ubuntu 10.04

Now, at the time, I had absolutely no idea what was wrong.  I hadn’t yet realized that Canonical, in the interests of ideological purity, had replaced my carefully installed Sun Java with the Open-Java implementation.

Therefore, I turned to the Great Oracle of Google; and I it was there that I discovered the answer: my Java installation wasn’t working correctly.  Ah, Java.  Bane of my existence and annoyance of my computing.  As I said, I’ve been here before; twice actually.  When I upgraded to Ubuntu 9.10, and when upgrading to Ubuntu 9.04 before that.  You’d think I would keep better notes.

But, at least I’m not the only one.  So far, I’ve received two different emails from others having the very same problem.  Which is why I’m writing this blog post.

Should you find that your Java programs have stopped working, here are the steps needed to fix it.

  1. Enable the Ubuntu partners repository.
  2. Next, install the java-virtual machine package and browser plug-in.
  3. Finally, set the Sun Java Machine as the default.

Here’s what it looks like from the command line:

sudo apt-get install sun-java6-jre sun-java6-jre-plugin
sudo update-java-alternatives –s java-6-sun

And as far as Canonical is concerned: please only make upgrades to my system that improve the user experience.  I dislike having to fix things.  I would much rather focus on my work.  To say this actually pains me, because, for the most part, Ubuntu offers the best “It Just Works” experience of any of the major operating systems.  So, Canonical, why would you do anything to screw that up?

_____________________________________________

Note: The Java icon used for this post was adapted from Java $PSD by VSX47.