GTG: Enabling missing plugins for Fedora 20

I Like Get Things Gnome and fedora 20 brings GTG 0.3.1; but after installing it I realized that some plugins were not available. Where are they? This question made me realize that the GTG package for Fedora needs to add a couple of dependencies. So here's how I managed to enable Remember the milk and mantis:

yum install -y python-dateutil python-suds

Unfortunately, the dependencies for the launchpad plugin are not available in the default Fedora repositories and RPMFusion is not available for Fedora 20 yet (as of Dec, 10, 2013).

As for the evolution plugin, I couldn't find any dependency that would provide the module named evolution in Python. I don't use Evolution at all, but someone else will feel disappointed.

Application Isolation

Morepath lets you create app objects like this:

app = morepath.App()

These app objects are WSGI applications, but also serve as registries for application configuration information. This configuration is specify used decorators. Typically apps consist of models and views:

@app.model(model=User, path='user/{username}',
           variables=lambda user: { 'username': user.username })
def get_user(username):
    return query_for_user(username)

@app.view(model=User)
def render_user(request, model):
    return "User: %s" % model.username

Here we've exposed the User model class under the path /user/{username}. When you go to such a URL, the default (unnamed) view will be found, and we've provided that too: it just renders "User: {username}".

What now if we have another app where we want to publish User in a different way? No problem, we can just create one:

other_app = morepath.App()
@other_app.model(model=User, path='different_path/{username}')
def get_user(username):
    return different_query_for_user(username)

@other_app.view(model=User)
def render_user(request, model):
    return "Differently Displayed User: %s" % model.username

Here we expose User to the web again, but use a different path and a different view. If you run this app (even in the same runtime), this will be separate.

This app isolation is nothing really special; it's kind of obvious that this is possible. But that's what we wanted. Let's look at a few more involved possibilities next.

Application Extension

Let's look at our first application app again. It exposes a single view for users (the default view). What now if we want to add a new functionality to this application so that we can edit users as well?

This is simple; we can add a new edit view to app:

@app.view(model=User, name='edit')
def edit_user(request, model):
    return 'Edit user: %s' % model.username

The string we return here is of course useless for a real edit view, but you get the idea.

But what if we have a scenario where there is a core application and we want to extend it without modifying it?

Why would this ever happen, you may ask? Well, it can, especially in more complex applications and reuse scenarios. Often you have a common application core and you want to be able to plug into it. Meanwhile, you want that core application to still function as before when used (or tested!) by itself. Perhaps there's somebody else who has created another extension of it.

This architectural principle is called the Open/Closed Principle in software engineering, and Morepath makes it really easy to follow it. What you do is create another app that extends the original:

extended_app = morepath.App(extends=[app])

And then we can add the view to the extended app:

@extended_app.view(model=User, name='edit')
def edit_user(request, model):
    return 'Edit user: %s' % model.username

Now when we publish extended_app using WSGI, the new edit view will be there, but when we publish app it won't be.

Kind of obvious, perhaps. Good. Let's move on.

Application Overrides

Now we get to a more exciting example: overriding applications. What if instead of adding an extension to a core application you want to override part of it? For instance, what if we want to change the default view for User?

Here's how we would do that:

@extended_app.view(model=User)
def render_user_differently(request, model):
    return 'Different view for user: %s' % model.username

We've now overridden the default view for User to a new view that renders it differently.

You can also do this for what is returned for model paths. We might for instance want to return a different user object altogether in our overriding app:

@extended_app.model(model=OtherUser, path='user/{username}')
def get_user_differently(username):
    return OtherUser(username)

To make OtherUser actually be published on the web under /user/{username} it either needs to be a subclass of User, for which we've already registered a default view, or we need to register a new default view for OtherUser.

Overriding apps actually doesn't look much different from how you build apps in the first place. Hopefully not so obvious that it's boring. Let's talk about something new.

Nesting Applications

Let's talk about application composition: nesting one app in another.

Imagine our user app allows users to have wikis associated with them. You would have paths like /user/faassen/wiki and /user/bob/wiki.

One approach might be to implement a wiki application within the user application we already have, along these lines:

@app.model(model=Wiki, path='user/{username}/wiki')
def get_wiki(username):
    return wiki_for_user(username)

@app.view(model=Wiki)
def wiki_default_view(request, model):
    return "Default view for wiki"

(this is massively simplified of course. we'd also have a Page model that's exposed on a sub-path under the wiki, with its own views, etc)

But this feels bad. Why?

• Why would we implement a wiki as part of our user app? Our wiki application should really be an app by itself, that we can use byitself and also test by itself.
• There's the issue of the username: it will appear in all paths that go to wiki-related models (the wiki itself, any wiki pages). But why should we have to care about the username of a user when we are thinking about wikis?
• It would also be nice if we can use the wiki app in other contexts as well, instead of only letting it be associated with users. What about associating a wiki app with a project instead, like you can do in github?

A separate app for wikis seems obvious. So let's do it. Here's the wiki app by itself:

wiki_app = morepath.App()

@wiki_app.model(model=Wiki, path='{wiki_id}')
def get_wiki(wiki_id):
    return query_wiki(wiki_id)

@wiki_app.view(model=Wiki)
def wiki_default_view(request, model):
    return "Default view for wiki"

This is an app that exposes wikis on URLs using wiki_id, like /my_wiki, /another_wiki.

But that won't work if we want to associate wikis with users. What if we want the paths we had before, like /user/faassen/wiki?

Morepath has a solution. We can mount the wiki app in the user app, like this:

@app.mount(app=wiki_app, path='user/{username}/wiki')
def mount_wiki(username):
    return {
       'wiki_id': get_wiki_id_for_username(username)
    }

We do need to adjust the wiki app a bit as right now it expects wiki_id to be in its paths, and the wiki id won't show up when mounted. This is a simple adjustment: we need to register the model so that its path is empty:

@wiki_app.model(model=Wiki, path='')
def get_wiki(wiki_id):
    return query_wiki(wiki_id)

But where does wiki_id come from now if not from the path? We already have it: it was determined when the app was mounted, and comes from the dictionary that we return from mount_wiki().

What if we want to use wiki_app by itself, as a WSGI app? That can be useful, also for testing purposes. It needs this wiki_id parameter now. We can construct this WSGI app from wiki_app by giving it a context explicitly:

wiki_app.context(wiki_id=5)

Application Reuse

Many web frameworks have mechanisms for overriding specific behavior and to support reusable applications. These tend to have been developed in an ad-hoc fashion as new needs arose.

Morepath instead has a general mechanism for supporting app extension and reuse. You use the same principles and APIs you already use to create new applications. Any normal Morepath app can without extra effort be reused. Anything registered in a Morepath app can be overridden. This is because Morepath builds on a powerful general configuration system.

This is because Morepath, like Grok or Pyramid, comes from the rich Zope heritage, where we've thought about this stuff. And Morepath wraps all that power in a small, easy, reusable little framework.

Let me know what you think!

Towards the First Grok Sprint

I got the idea for Grok in the summer of 2006. In the fall I still hadn't done anything yet about it. Then I gave a talk at a German Zope User Group (DZUG) conference (the video of that now appears to have sadly disappeared off the internet; if it's still somewhere I'd appreciate to get the link!). This was the series of conferences that a few years ago got broadened into the wider PyCon.DE (German PyCON) conferences. I chatted about Grok with Christian Theune of Gocept. He suggested we hold a sprint to build Grok at the Gocept offices.

So later on that fall I and my wife Felicia flew to Berlin and from there were taken by Christian to the Gocept offices in Halle. There were four of us at the sprint: myself, Christian, Philipp von Weitershausen, and Wolfgang Schnerring. The first three were very familiar with Zope both old and new. Wolfgang was new to it all, but had experience with Ruby on Rails, so could offer us an interesting different perspective.

Quadruple Programming

This sprint, we didn't do the pair programming that was pretty standard in Zope sprints, but quadruple programming. How did that work?

We used a video projector to project the screen of somebody's laptop onto the wall. The person at the keyboard was mostly either Philipp or Wolfgang. The rest would look at the projection and give directions. Christian made sure we didn't forget test cases by writing them down on a whiteboard. I sat or paced around and just talked. People who know me know I do that a lot anyway. I actually did not edit a single line of code during the entire weeklong sprint myself, but I'd seen all of it and was thoroughly familiar with it when I went home afterwards.

After a week of sprinting we got Grok from a design document to a working implementation. We built the traditional wiki application with it to try it all out in the end.

Starting Grok in a sprint like this made it a community project straight from the start. This was beneficial when we went home and had to cooperate online.

I wrote a report about the sprint and Grok to my blog back then; it may be interesting reading for some.

Grok the Caveman

None of the other sprinters liked my proposed name 'Grok' for the project. It was too nerdy, too obscure. Perhaps, it was proposed, we should name it something like "Easy Zope" (I forget the exact name proposed, but 'easy' was part of it). I protested and formulated what Philipp later dubbed "Faassen's law":

Don't use the name 'easy' or 'simple' in software, as it likely won't be and people will make fun of it.

Somehow during dinner we were discussing and imitating "Hulk talk", i.e. "Hulk smash". People are silly like that, especially people like me. I suddenly hit on the idea that Grok was actually a caveman, and that he talked like this: "me Grok smash ZCML". Everybody immediately liked this idea, as it had a sense of fun and fit the theme of Grok simplifying the new Zope.

We had the luck that my wife Felicia was there. She's a graphics designer, so we asked her Grok the Caveman, so we would have a mascot for the project. She made several drawings and showed them to the group. One of them was everybody's favorite. "But that one looks like me!" I protested. "Exactly," they said, grinning. And thus Grok the caveman was born.

Having a friendly caveman as a mascot/logo for your project actually helped attract people to it. Having such a character gives a project a face and gives people something to relate to. The web site theme was inspired by it, and even a stand-up wooden version of the caveman was made and used at various open source conventions.

I've been toying for a while with the idea of creating an elf character for the Obviel project...

While I did mention cave women in my original blog post on Grok, I wonder now whether our slogan "now even cavemen can use Zope 3" was sufficiently inclusive of women, given all the attention given to gendered language now... The word "cavepersons" would take away a bit of the charm of the ridiculously ahistorical but familiar caveman concept.

Grok Innovation

After I'd gone home from the first Grok sprint I could immediatetely pick up the code and continue working with it. I factored out a library, which contained what I think now was the most important innovation of Grok. This was the notion of scanning Python modules for things (classes, instances, decorators) that needed to be registered with the system. This, we discovered, allowed us to do metaclass-like things with Grok without the need for using actual metaclasses -- particularly picking up and registering relevant classes with the Zope configuration system. Avoiding metaclasses is good if you can get away with it, as they can lead to other unexpected behavior in subclasses. I called the library Martian, to fit the 'grok' theme.

When Chris McDonough started what later became the Pyramid project he used Martian to pick up configuration. Later on he reimagined Martian and he created the Venusian library, which I'm using today in Morepath. But that's another story.

Grok as an Open Source project

Grok as an open source project was moderately successful. A little community of people formed. It managed to attract a few people unfamiliar with Zope technology, and also made the new Zope technology more appealing to people who were already familiar with Zope. We got quite a few contributions, too.

We had regular Grok sprints that helped push Grok forward. We also participated in the Google summer of code for a few years, under the wider banner of the Zope project.

I was lucky enough that quickly after the initial creation of Grok I could start using Grok in my professional life on customer projects. I've been using it as the underpinnings in several large web applications since then.

Various contributors also refactored Grok technology so it could be plugged into the old Zope. From there the Plone community started using it; it's still widely used there today. This whole old Zope compatibility project was entirely pushed by contributors who weren't part of the original group -- a sign of open source success.

Grok and Zope

Grok was built on the new Zope. This gave Grok a running start and a built-in community to draw from, and this was definitely part of Grok's success. But many other Zope developers were not interested in Grok, and quite satisfied with the original ways of doing things. Grok could not have worked as a project to improve Zope itself -- there was insufficient consensus. To create something new, we had to go around the center.

Grok was successful at least for me personally: it made it possible for me to use the new Zope technology without much of the pain. But was Grok successful in being attractive to beginners? We certainly attracted some. But there were problems.

While Grok was simple enough on the surface, its learning curve was not as smooth as we'd have liked. Grok was too much like an iceberg; beneath the surface lurked the vast codebase of the new Zope. If we wanted to make Grok smaller and more comprehensible all the way down, we would need to fix this.

This blog entry is a part of a series on Zope and my involvement with it. Previous.

Lost at CERN

In the summer of 2006 I went to the EuroPython conference, which that year was held in CERN, Switzerland. There was to be a Zope sprint ahead of the conference, so I came a few days earlier.

I got there in the evening. The next morning I tried to look for likely Python programmers. Normally this is not a difficult task: programming geeks tend to have a special look about them. But at CERN this doesn't work: many people at CERN look like they could be a programmer, and many of them of course are, but they were not there for EuroPython.

I got slightly lost in the complex, and was given directions by some gentlemen. They could've been janitors or Nobel prize winners, I will never know. CERN is a special place.

I finally concluded I had planned things a bit wrong, and had arrived at CERN one day earlier than everybody else. So I had a day to kill.

I remember the weather was gloriously sunny and warm. I was hanging out in the cafetaria for a while. I started thinking about my experiences with the new Zope, and its frustrations, and what it would take to turn it into a web framework without these frustrations. A web framework that I would like to use myself and would hopefully also be a bit less intimidating to beginners. Zope was starting to have a problem attracting new people -- the old Zope was out of date, and the new Zope was too intimidating.

The Idea of Grok

I decided to call this new framework Grok, as one has to give things a name. Grok is a term originally from Stranger in a Strange Land, a science fiction novel by Robert Heinlein, and is supposed to be a martian verb for "to understand/to become one with/to drink in". From there the word had made it into programming jargon.

Ruby on Rails had made popular the idea of "convention over configuration"; if you just use some conventions (naming, placing in modules, etc) for the entities in your system, the framework will know what they are without you having to explicitly and verbosely having to tell it. Since the new Zope had a problem with verbose configuration, I figured we could apply convention over configuration to make things more succinct.

In Grok you can use base classes (grok.View, grok.Model, etc) to signal what type of class you're definining, and the system will deduce from that how to register them with the Zope configuration system. Just base classes by themselves aren't enough though -- many configuration actions need parameters. We solved this with Grok directives.

For an example of a directive, You could associate a view with a model using the grok.context() directive. Grok directives are special calls you could make inside your class definition, like this:

class MyView(grok.View):
    grok.context(MyModel)

grok.context would magically apply to the class it is called in, in this case MyView, and set some information on it. These days we'd use a class decorator for this instead, but Python didn't have those yet then.

So far not much convention over configuration was going on. What I had done was found a way to integrate configuration information directly into Python classes so that you wouldn't have to maintain separate XML files anymore for configuration. Convention over configuration came in because you could leave out grok.context and it would then automatically associate the view with a model that happened to be defined in the same module.

It turned out later that convention over configuration in Grok was not as important as I had thought it was then. Some of the magic, even created very deliberately and layered over a worked-out configuration system, intimidated people and sometimes (though rarely) lead to unexpected behavior. The reduction of verbosity by doing configuration in Python near the code being configured was the main win; reducing that configuration further was less important.

When the other sprinters arrived at CERN, I explained some of these ideas to them and received some useful feedback. But it all remained just an idea.

After the Python conference, I was lucky enough to get to see the first web server (the web having been invented at CERN), and the Large Hadron Collider, which, they told us, was going to collide hadrons Real Soon Now.

This blog entry is a part of a series on Zope and my involvement with it. Previous. Next_.

Plone CMS

import fileinput

for line in fileinput.input(somefilename, inplace=True):
    line = 'additional information ' + line.rstrip('\n')
    print line

from contextlib import contextmanager
import io
import os


@contextmanager
def inplace(filename, mode='r', buffering=-1, encoding=None, errors=None,
            newline=None, backup_extension=None):
    """Allow for a file to be replaced with new content.

    yields a tuple of (readable, writable) file objects, where writable
    replaces readable.

    If an exception occurs, the old file is restored, removing the
    written data.

    mode should *not* use 'w', 'a' or '+'; only read-only-modes are supported.

    """

    # move existing file to backup, create new file with same permissions
    # borrowed extensively from the fileinput module
    if set(mode).intersection('wa+'):
        raise ValueError('Only read-only file modes can be used')

    backupfilename = filename + (backup_extension or os.extsep + 'bak')
    try:
        os.unlink(backupfilename)
    except os.error:
        pass
    os.rename(filename, backupfilename)
    readable = io.open(backupfilename, mode, buffering=buffering,
                       encoding=encoding, errors=errors, newline=newline)
    try:
        perm = os.fstat(readable.fileno()).st_mode
    except OSError:
        writable = open(filename, 'w' + mode.replace('r', ''),
                        buffering=buffering, encoding=encoding, errors=errors,
                        newline=newline)
    else:
        os_mode = os.O_CREAT | os.O_WRONLY | os.O_TRUNC
        if hasattr(os, 'O_BINARY'):
            os_mode |= os.O_BINARY
        fd = os.open(filename, os_mode, perm)
        writable = io.open(fd, "w" + mode.replace('r', ''), buffering=buffering,
                           encoding=encoding, errors=errors, newline=newline)
        try:
            if hasattr(os, 'chmod'):
                os.chmod(filename, perm)
        except OSError:
            pass
    try:
        yield readable, writable
    except Exception:
        # move backup back
        try:
            os.unlink(filename)
        except os.error:
            pass
        os.rename(backupfilename, filename)
        raise
    finally:
        readable.close()
        writable.close()
        try:
            os.unlink(backupfilename)
        except os.error:
            pass

import csv

with inplace(csvfilename, 'rb') as (infh, outfh):
    reader = csv.reader(infh)
    writer = csv.writer(outfh)

    for row in reader:
        row += ['new', 'columns']
        writer.writerow(row)

import csv

with inplace(csvfilename, 'r', newline='') as (infh, outfh):
    reader = csv.reader(infh)
    writer = csv.writer(outfh)

    for row in reader:
        row += ['new', 'columns']
        writer.writerow(row)

Mockup documentation

As first I would like to thank Peter Lamut for tackle, for me, one of the most needed corners which Mockup project needs some love. Documentation. He was working on Hello world example and stepping through whole process from What a pattern is? to How to create a new pattern? and how to use Mockup in your custom project. His work needs a bit of organizing and after-reading, but every newcomer will appreciate this Thank you.

Barceloneta theme - new theme for Plone 5

Since current coredev installation is not themed Ramon Navarro started to work on a new theme. He already wrote blogpost about it and already got quite a lot of responses.

There are few things I would like to point out which were maybe not clear in his blog post:

• Barceloneta theme is a needed middle step before we get plone.app.toolbar ready. But even when plone.app.toolbar is going to be in Plone there will still be a possibility to not use iframe (with a little of customizing).
• For me (as a developer) biggest and most important change in Plone 5 is going to be Mockup. We will be finally able to sanely use latest tools in front end Javascript development on top of Plone. Mockup, as told many times, will provide us with modern way how front-ends are built and will be a requirement when contributing Javascript to Plone's core code. But, and please make sure you read this part as well, will be not required for add-ons developers developing their add-on.
• We need a nice reusable theme. If you care about this, then please get involved and don't only speak at all about it. Seriously I'm getting a bit tired of people writing lengthy emails explaining what next Plone theme should do and look like. Stop complaining and just do it! Now is the time.

PLIP 13476 - mockup in coredev

After finishing his work on removing <base/> tag (PLIP 13705) Franco Pellegrini started the process of removing packages which will be obsolete when plone.app.widgets work is merged into coredev. He ended up removing all widgets except Products.TinyMCE, which hopefully will also happen soon.

In the week after the sprint David Glick joined me cleaning up failing tests which happen after the removal of so much code. And yes! Initial work on mockup PLIP is ready for framework team to review it. Hopefully we can get it merged tomorrow.

New releases of plone.app.widgets and plone.app.toolbar

Rob Gietema helped me close last few bugs which were waiting to be fixed before releasing. Then Johannes Raggam did a hell of a work and cut new plone.app.event release in the middle of the sprint. Few days ago last critical ticket was closed by Jamie Lentin for plone.app.contenttypes migration from previous version and Timo Stollenwerk cut a release for it, which make it possible for me to release plone.app.widgets and plone.app.toolbar. More on this later this week.

Final thoughts

I'm just overwhelmed by the number of developers which are contributing to Plone 5. Look above how many developers I mentioned and this was only about one sprint work on one PLIP. If you're reading this and you're not sure how to get involved, just book your ticket and come to next sprint.

Plone 5 is happening and is happening very soon!

Introduction

I can't sleep because some weird Twitter interaction I had earlier. I shouldn't let it bother me, but it did. I received a retweet from someone I didn't know, saying: "Linux doesn't work. There. I said it."

There was a link to a blog entry describing various frustrating problems the author had with Linux, who was sincerely trying it out; applications that didn't do what was asked of them, things generally not cooperating, and intimations that others had experienced pain as well. Constructive feedback all. It also said Linux doesn't work. It said Mac OS X and Windows do work.

Heh, I thought, "Linux doesn't work" isn't really right. I've been using this Linux thing since 1995. Obviously Linux works for me. So I replied: "Heh, Linux works for me. Linux doesn't work for you."

Don't reply stuff to strangers on Twitter! The original person didn't reply (and hasn't yet. probably still resting in all innocence of this whole thing), but someone else jumped in and said I sounded dismissive and unhelpful. So I tried to clarify and defend myself. I didn't mean to dismiss the original writer's negative experiences with Linux, I was just nitpicky about language. "Linux doesn't work" sounded sensationalist to me. What works for one person might not work for another. This lead to a bevvy of tweets back and forth that make me understand Twitter rage a lot better. Maybe Twitter doesn't work. For me. Tonight.

More context

One IRC discussion later with yet more people, I understood the context a bit better. It turned out that the original author was a woman, something I had been completely unaware of, though I started to suspect something was up when the word "mansplaining" was uttered by yet another person. And here I thought I was just being a nitpicker. There are real issues women face in tech, and I had just obliviously stepped into a bit of a hornet's nest. I have more reading to do.

So after I calmed down I reviewed my words; getting caught up in unreasonable defensiveness in 140 line texts about nothing. I sent a few clarifications and "sorry didn't mean to be dismissive of your experience" back to the original writer. At the very least I could have been construed as "not constructive". Sure, it was a pretty mindless nitpicky tweet.

I'm sure this blog entry is part of that defensiveness too, but let's turn it into something constructive instead. Let's have a conversation about Linux, and why it works for me. And to tell some stories. Hopefully nothing sounds mansplainy.

A Very Brief History of Linux Troubles

I have been struggling with issues on Linux so long that I feel quite spoiled these days. Mostly when I install Linux things just work. I remember back in 2000 or so I would have to work hard getting my mouse to work. Back in 2004 or so I remember having to wrestle with nsdiswrapper to install a Windows driver just to make the wireless work. And I remember struggling to hear sound.

Back then I had to be my own sysadmin, or worse. Whatever is worse than being your own sysadmin.

Topsy-Turvy World

These days the hardware support is so much better. Generally after installation the graphics, sound and wireless work. I guess this astounds me so much given my past experience I'm too easily pleased, perhaps.

I was spoiled with Linux graphics support for some years. I'd been using the (properietary) NVidia drivers and they worked quite well on my previous laptop and my current desktop.

In fact, on my previous laptop it worked better than on Windows and Mac OS X, a rare story of a topsy-turvy world that I'll share. My wife got a new Mac OS X laptop at about the same time. It turned out almost all the hardware, from motherboard to video card, was the same as on my laptop. It was just my laptop was cheaper and didn't look very cool. But, you'd say, Mac OS X works out of the box, and with Linux you need to tinker a lot. True usually. Not this time.

With Linux, I could just install the NVidia driver from the repository, reboot, and things worked. On the dual boot Windows partition that I was maintaining for games and rarely used (I've since given it up), I had to find a hacked NVidia driver as for some reason laptop support wasn't officially in there. I think that got fixed since then. Annoying, but tolerable.

With Mac OS X, my wife would start a 3d application that she'd bought the Mac for, and that worked on the previous one, and after a few minutes the laptop would crash horribly. Hard reboot required. In desperation we eventually installed a separate Windows partition and it worked just fine there -- the hardware was fine.

No fix was possible; there was some bug somewhere in the NVidia driver. But it was impossible to upgrade. We had to wait half a year or so for Apple to create an update of their operating system including NVidia driver, and then buy the upgrade to get this bug fixed.

Topsy-turvy world. Not usually true. But a good story.

Present Day Troubles

So last year I got a new laptop, and mindlessly got NVidia again, as it had worked so well for me before, and then was thrust into a chaos of installation issues I just wasn't used to anymore. The reason is NVidia Optimus, a technology to let your laptop save power by using Intel graphics unless demanding 3d applications are run.

That really sucked. I was really frustrated. I didn't need nonsense like that. Eventually I got it sorted out, switching from Fedora back to Ubuntu, but it was painful. I must report that the support has much improved -- I recently reinstalled my laptop and while I still had to do some special installation, it started working then.

Then there was the wireless on the laptop. For some reason when not plugged in the wireless driver would magically decide it was going to go into Ultimate Power Saving Mode and slow my internet down to an absolute crawl. I found a fix which was to turn the powersaving off, but it was annoying. I can report again that this got fixed in more recent versions.

My desktop is usually pretty stable, but I got into the habit of using its suspend feature instead of shutting it down. That worked fine for a long time, but after one update the desktop would come back from suspend, pretend everything was fine for hours on an end, and then suddenly crash. I'm not used to hard freezes on Linux. I hear reports that this finally got fixed too, but I haven't dared to try yet, and switched to shutdowns. It boots up very fast these days too, anyway.

Why?

Why go through this trouble? While Linux is pretty good at it these days, generally speaking Windows and Mac OS X come with better hardware support. Why this Linux desktop? Is this free software ideology?

I don't think so. I'm not really a Linux advocate. I used to be more passionate about it. I do still appreciate the freedom it gives me, where I as a developer or power user can really dig down deep if I'm willing to invest the time.

But now that it's finally finally yes this year for real the year of the Linux desktop, I'm not going to try to convert people. I think software freedoms are important, and wish more people would care, but people care about convenience, which makes total sense, so am not an activist about it.

I'm not a Linux desktop developer either. If I were I'd want to use my own stuff, obviously, and others too, but that's not it.

The reason why Linux works for me is that I'm a developer. And I think Linux is a kick-ass system to develop on, especially web applications, where I know my code is likely to get deployed on Linux servers as well.

Back to 1995

Back in 1995 I first installed Linux on my PC at home. I remember lugging a lot of slackware floppies around, as I didn't have an Internet connection at home yet either. Why did I go through the trouble? Because Linux, for me who didn't have the money to buy software, made for a much better development environment than MSDOS. If I wrote a C program on MSDOS and I made a mistake, the machine would hang, and I'd had to reboot it. If I wrote a C program with Linux, and I made a mistake, I could shut down the process with control-C. Linux simply was a better operating system than MSDOS; it made better use of my hardware at the time. And it came with all these development tools.

Back to the present

Windows and Mac OS X have caught up in the stability department. While Windows Vista, the last Windows I'm somewhat familiar with, made you jump through hoops and reboot a thousand million times if you wanted to upgrade it after a year or more of no upgrades (something I went through last year. Hopelessly confusing and even scary to people unfamiliar with computers, like the ones I was helping), it generally does not crash all that often.

But with Linux I can download and install a huge range of programming environments and libraries and tools, from mainstream to obscure, within seconds. Windows and Mac OS X don't match that. Modern Linux package repositories are awesome for this purpose. I know I could get stuff like that set up with Mac OS X or even Windows, but it'd entail more tinkering than I have patience for. So the scales balance the other way, for me.

Otherwise it's a matter of familiarity and "makes no difference". I'm familiar with Linux. I think the modern deskop environments are pretty slick. Linux makes me comfortable. I'd feel lost if I have to use something else. The other stuff feels clunky. I'm sure I could get used to it, but I don't see a reason to.

The web browser works. That's important. I remember a period in the early 00s when Microsoft had won the browser wars, and Netscape 4.7 on Linux was aging and sites started to be developed for IE only. Thank goodness Firefox brought us out of that situation. The basic freedom of the web is pretty safe now in our multi-browser world.

Even playing games is getting so much better that I dumped Windows entirely. No more dual booting. Thanks Humble Indie Bundle, and thanks Steam! And Kerbal Space Program. I can't play all games available, but enough to keep me happy. It's really awesome, actually; I never thought it'd get this far.

It's now so much easier to maintain a Linux desktop, I barely have to touch a global config file anymore. I don't really feel like I have to play sysadmin anymore. But I'm sure my perspective on it is warped by the years of difficulty that has gone before.

Linux for non-developers?

Can the Linux deskop work for non-developers too? I think it does sometimes, and has. I suspect in some ways a modern Linux desktop can be less confusing in the amount of popups and warnings it gives you than at least Windows Vista could be. It's just that trouble starts when people want to install familiar Windows software. Learning the replacements takes time, and while some stuff will work better, some of it will be worse.

So let me end this with a story. About ten years ago, I was staying with my parents over Christmas. My mother's competent with computers, now so more so than ten years ago, but not an expert by any means.

I was playing with a Linux distribution that could be booted directly from cdrom, without installation, which was new at the time. I had it inserted into my parents laptop, and forgot to take it out when I went up to bed at night. The next morning I came downstairs to find my mother had started the computer, and it had booted into Linux. She was happily playing the games that came with it. I told her how amazing that was; mom, you're using Linux! My mom is using Linux. It just worked.

2003, the year of the Linux desktop. Briefly. We took the cdrom out. She uses Windows again. I haven't pushed Linux on her.

Because while I'm okay with being a sysadmin sometimes, I don't want to be her permanent tech support. That might indeed be worse than being your own sysadmin.

(not because it's my mom! she's great! and she doesn't read this blog, so I'm not just saying that. and tech support people! it's just not for me, that's all! thank goodness this isn't Twitter; didn't fit in 140 characters, this)

There. That's out of my system now. I shouldn't really let this stuff bother me, but what can you do when it does? Hopefully now I can finally sleep. A 7 year old and a 4 year old are visiting in a few hours, joining our toddler in generating energy and activity, demanding my attention. Good night! Zzzz.