Recent blog entries for wingo

software failure modes

Reflecting earlier today on some crappiness in a software project I'm involved in, my brain started to enumerate the ways that free software projects can fail.

The maintainer can go AWOL. The major culprits for this are babies, university thesis advisors, and Google.

This is pernicious in two ways: one, the person with the most knowledge about a project is no longer commenting on efforts by others to contribute. Patches go unreviewed, questions go unanswered.

Secondly, the maintainer is in a privileged position -- they typically have sole administrative access to the mailing list, the revision control system, and sometimes the web page. No one else can intervene to fix e.g. a spam problem on the list. But maintainers' privileged position extends to a kind of moral authority as well: "OK, she's been away for three months now... can I make a release without her permission?" The result is that in the meantime, the project's momentum decays, contributors spend their time elsewhere where they are more appreciated.

Even in the lack of a strange interstitial period of limbo, a maintainer's departure usually leads to the badness, as other less familiar, possibly less skilled contributors take control. As prudent as they might be, some bad patches probably slip in. The project enters a time of increasing entropy, of bitrot.

In addition, you have failure modes that have nothing to do with people involved in the project. API changes in a core system library can bitrot reams of dependent code in one commit. It's not enough for the old libraries to be available on the intertubes, they have to be installable on a contemporary computer. Your language specification or runtime could change. And of course those core libraries have dependencies as well: glibc versions, kernel syscalls, not to mention the ever-changing soup of hardware interfaces.

Ultimately behind those changes you will find human desires, "market forces", and even such things as global warming.

Any other failure modes come to mind? Follow on in yon comment bucket!

(To be clear, I'm not saying that guile-lib failed, but the mailing list situation is pretty terrible.)

summertime

Beaches, bars, and outdoor cinema. Quiet afternoons on the terrace, poking around the house, the neighborhood, a bit hobbitlike.

I'm about to head off travelling in August -- in Seattle for the week of the 11th, down to Portland OR for a few days, overnight train to San Fran, for a few days, then down to LA for the 27th, and back home to BCN on the 5th or so. Amtrak ho!

<center>
5m50s, 2.5 MB, Theora</center>

The linked video shows my hackbaby of the last couple months, a hackable 3D compositing window manager written in Scheme. It's not much code, but it's rather fun. I'm still not dogfooding with it yet -- you can see a pause around minute 4:30 or so where I have to unstick keys that Xephyr thinks are pressed.

And it's still a bit hard to compile, because you need bzr guile-gnome, and the latest guile-clutter release, and a guile 1.8 compiled as --with-threads if you want the emacs integration. But if you want to join in on the fun, or read some interesting code, check:

bzr branch http://wingolog.org/bzr/griddy

a dialog with someone i don't know

One way to think about it is that it's like driving a car down the road, and suddenly swapping the steering wheel and brakes out for a tiller and gear shifter. And having to downshift for braking until you learn that the brakes moved to the turn indicator lever. By trial and error.

That's the internet's Joey Hess, a wonderful writer, who recently switched window managers.

A while back I discussed some new interaction possibilities, and a lot of them hinged on the relation between people and the set of tasks that they do on the computer -- not just the tasks themselves, but the relationships between the tasks, and with focus.

In the free desktop, the locus of this experience is in the window manager. Again, Joey tries to give analogies:

Another way to look at it is adopting a new philosophy. Or, in some cases a cult. (In some cases, with crazy cult leaders.) Whether they use Windows or a Mac, or Linux, most computer users are members of a big established religion, with some implicit assumptions, like "thy windows shall be overlapping, like papers on the desktop, and thou shalt move them with thy mouse".

The obvious step if you want to apostatize yourself from the "desktop metaphor", then, is to start hacking window managers. That's how I spent my hack-time in the last month and a half; this writing is an attempt at exegesis.

descent from the mountain, source in hand

I wanted to make a 3D compositing window manager. By 3D, I mean that I wanted the pixels behind the monitor glass to come entirely from one process' OpenGL. By "compositing", I mean that the graphical output from other programs should be redirected through my program. (Compositors don't necessarily need to be implemented with OpenGL; xcompmgr and metacity's compositor are implemented with XRender.)

As an implementation strategy, I took this opportunity to check out Clutter, a GL-based canvas library. What follows is a minimal translation into C of the basic concepts, a broken but fun-to-hack substrate for experimentation.

int main (int argc, char *argv[])
{
    prep_clutter (&argc, &argv);
    prep_root ();
    prep_overlay ();
    prep_stage ();
    prep_input ();

    g_main_loop_run (g_main_loop_new (NULL, FALSE));

    return 0;
}

The main function is pretty simple. We'll be looking at the various functions one by one, but out of order. Let's start with prep_root:

Display *dpy;
Window root;
void prep_root (void)
{
    dpy = clutter_x11_get_default_display ();
    root = DefaultRootWindow (dpy);

    XCompositeRedirectSubwindows (dpy, root, CompositeRedirectAutomatic);
    XSelectInput (dpy, root, SubstructureNotifyMask);
}

This function does two things of interest: first, it tells the X server to redirect output of all windows into backing pixmaps, such that the contents of all mapped windows are available, even if the X server does not think that they are visible. Second, we ask the X server to give us notification when windows come and go, and when they change size.

Window overlay;
void prep_overlay (void)
{
    overlay = XCompositeGetOverlayWindow (dpy, root);
    allow_input_passthrough (overlay);
}

The Composite extension, which allows us to redirect window output, also provides for the existence of an "overlay" window, one that is above all other windows. You can draw directly to the overlay window, but the normal way that you use it is as a parent window -- you create your own window, then reparent it to the overlay.

Composite is pretty cool, except that it is only for output -- that is, you can put the output of a window anywhere, like on the corner of a Compiz cube, but you can't redirect input. By that I mean to say that when you have a rotated compiz cube, you can't interact with the window.

The reason for this is that in order to interact with a window, for example to click a button in it, the X server needs to know how to map the pointer position to a position inside a certain window. This is a tricky problem which needs to be done inside the X server, and no solution to this problem has been merged yet.

This upshot is that what happens today with compositing window managers is that the compositor is very careful to make sure that the underlying X window is exactly positioned behind where the compositor is drawing it. Then, when the user clicks on what essentially is the redirected image of the button, the click actually falls behind the overlay to the actual X window.

Hence, the need to allow events (clicks, pointer motion, etc) to pass through the overlay:

void allow_input_passthrough (Window w)
{
    XserverRegion region = XFixesCreateRegion (dpy, NULL, 0);
 
    XFixesSetWindowShapeRegion (dpy, w, ShapeBounding, 0, 0, 0);
    XFixesSetWindowShapeRegion (dpy, w, ShapeInput, 0, 0, region);

    XFixesDestroyRegion (dpy, region);
}

Basically we call a few undocumented functions, whose goal is to tell the X server that the window in question is not to receive pointer input events.

ClutterActor *stage;
Window stage_win;
void prep_stage (void)
{
    ClutterColor color;

    stage = clutter_stage_get_default ();
    clutter_stage_fullscreen (CLUTTER_STAGE (stage));
    stage_win = clutter_x11_get_stage_window (CLUTTER_STAGE (stage));
    clutter_color_parse ("DarkSlateGrey", &color);
    clutter_stage_set_color (CLUTTER_STAGE (stage), &color);
    
    XReparentWindow (dpy, stage_win, overlay, 0, 0);
    XSelectInput (dpy, stage_win, ExposureMask);
    allow_input_passthrough (stage_win);
    
    clutter_actor_show_all (stage);
}

The next step is to create the clutter "stage", the GLX window to which all of our output will go. We reparent the stage to the overlay, so that it will always be on top, then we allow input events to pass through it as well.

Window input;
void prep_input (void)
{
    XWindowAttributes attr;

    XGetWindowAttributes (dpy, root, &attr);
    input = XCreateWindow (dpy, root,
                           0, 0,  /* x, y */
                           attr.width, attr.height,
                           0, 0, /* border width, depth */
                           InputOnly, DefaultVisual (dpy, 0), 0, NULL);
    XSelectInput (dpy, input,
                  StructureNotifyMask | FocusChangeMask | PointerMotionMask
                  | KeyPressMask | KeyReleaseMask | ButtonPressMask
                  | ButtonReleaseMask | PropertyChangeMask);
    XMapWindow (dpy, input);
    XSetInputFocus (dpy, input, RevertToPointerRoot, CurrentTime);

    attach_event_source ();
}

So if the events fall through the stage, and fall through the overlay, what happens if they don't fall onto a window? Well, you probably want the stage to get the last crack at them, instead of the root window. So hence this terrible trick, making a separate fullscreen input-only window, located below all windows except the root window. We select for all input on this window, so that we get e.g. key presses as well.

Then we install a GSource to process pending X events, redirecting events from the input window to the stage window:

GPollFD event_poll_fd;
static GSourceFuncs event_funcs = {
    event_prepare,
    event_check,
    event_dispatch,
    NULL
};
void attach_event_source (void)
{
    GSource *source;

    source = g_source_new (&event_funcs, sizeof (GSource));

    event_poll_fd.fd = ConnectionNumber (dpy);
    event_poll_fd.events = G_IO_IN;

    g_source_set_priority (source, CLUTTER_PRIORITY_EVENTS);
    g_source_add_poll (source, &event_poll_fd);
    g_source_set_can_recurse (source, TRUE);
    g_source_attach (source, NULL);
}

The prepare() and check() functions are a bit boring, but the dispatch() is worth a look:

static gboolean
event_dispatch (GSource *source, GSourceFunc callback, gpointer user_data)
{
    ClutterEvent *event;
    XEvent xevent;

    clutter_threads_enter ();

    while (!clutter_events_pending () && XPending (dpy)) {
        XNextEvent (dpy, &xevent);
        
        /* here the trickiness */
        if (xevent.xany.window == input) {
            xevent.xany.window = stage_win;
        }

        clutter_x11_handle_event (&xevent);
    }
    
    if ((event = clutter_event_get ())) {
        clutter_do_event (event);
        clutter_event_free (event);
    }

    clutter_threads_leave ();

    return TRUE;
}

We just pick off events, translating the input to the stage window, then give the events to clutter.

Obviously this is a crapload of code just to shunt events around; normally with clutter this is not necessary, but with the X compositing architecture being like it is, we have to roll our own GSource to do the event translation.

This brings me back to the beginning, prep_clutter:

GType texture_pixmap_type;
void prep_clutter (int *argc, char ***argv)
{
    clutter_x11_disable_event_retrieval ();
    clutter_init (argc, argv);
    clutter_x11_add_filter (event_filter, NULL);
    
    if (getenv ("NO_TFP"))
        texture_pixmap_type = CLUTTER_X11_TYPE_TEXTURE_PIXMAP;
    else
        texture_pixmap_type = CLUTTER_GLX_TYPE_TEXTURE_PIXMAP;
}

Here we see that you have to turn off event retrieval before calling clutter_init. Then, we tell Clutter to call a event_filter whenever it gets an X event. I'll get back to that function in a minute.

I suppose that this is as good a time as any to speak of getting window contents into OpenGL. The basic idea is that since we're already storing all of the window's pixels into a backing pixmap (because we are redirecting all output), we don't actually need to transfer the pixels back over the wire to the compositor to have the compositor show the window on the screen. There is a GLX extension, texture from pixmap or TFP, which tells the libGL implementation to get a texture's contents from a pixmap that it already knows about, automatically updating when the pixmap updates.

I digress for a moment to mention something that I did not know when I was getting into all of this. There are two kinds of GLX rendering, direct and indirect. Perhaps you recall these words from running glxinfo to see whether your GL implementation has hardware acceleration or not. In fact, direct vs. indirect exists on a different axis as accelerated vs. software rendering. What "indirect rendering" means is that instead of talking directly to the graphics card through the kernel, a GL application is sending all of its commands over the wire to the X server, which then does the rendering.

But that server-side rendering may be accelerated; indeed, that was the whole point of AIGLX. Technically, with free drivers, this is implemented via having the server's GLX rendering use the same DRI library as libGL does when doing direct rendering. It is the DRI library which does the accelerated communication with the hardware-specific kernel module (the DRM module).

Indirect rendering is slower, however, and it is advantageous to use direct rendering when possible. The problem comes when wanting to use TFP and direct rendering; if I want to bind a GL texture to a pixmap corresponding to some other application, and I am not going to go through the X server to do so, then obviously the kernel itself has to know about X drawables. If I have a named pixmap open from one process that was created from another process, there needs to be a unified memory manager in the kernel:

It's a crude approximation but the most crucial difference between the nvidia architecture and DRI/DRM is that nvidia actually have a memory manager - and a unified one at that. Without a memory manager it's impossible to allocate offscreen buffers (hence, no pbuffers or fbos) and without a unified memory manager it's impossible to reconcile 2D and 3D operations (hence no redirected Direct Rendering). The Accelerated Indirect GLX feature that the freetards were busy raving about is an endless source of confusion - and ultimately a hack to workaround their lack of a memory manager.

(That from Linux hater, someone I have warmed to in recent weeks -- I basically agree with Jeremy Allison's position.)

Anyway. You can't do direct TFP with free drivers, is the conclusion of that digression. That's OK, because you can always force indirect rendering via setting LIBGL_ALWAYS_INDIRECT=1 in your environment. But you can't do indirect rendering in Xephyr, only direct, so it's tough to test out window managers. Fortunately, you can get window contents into clutter without TFP, using the fallbacks -- hence the NO_TFP check in prep_clutter.

&#xE1;nimo, peregrino

OK, at this point we're almost there. Here's the event handler:

static ClutterX11FilterReturn
event_filter (XEvent *ev, ClutterEvent *cev, gpointer unused)
{
    switch (ev->type) {
    case CreateNotify:
        window_created (ev->xcreatewindow.window);
        return CLUTTER_X11_FILTER_REMOVE;

    default:
        return CLUTTER_X11_FILTER_CONTINUE;
    }
}

It's pretty simple, an X event is a tagged union. We respond to the CreateNotify events, which come because we selected for SubstructureNotifyMask on the root window. It turns out we don't need any more events, because clutter handles the rest:

static void
window_created (Window w)
{
    XWindowAttributes attr;    
    ClutterActor *tex;

    if (w == overlay)
        return;

    XGetWindowAttributes (dpy, w, &attr);
    if (attr.class == InputOnly)
        return;
    
    tex = g_object_new (texture_pixmap_type, "window", w,
                        "automatic-updates", TRUE, NULL);

    g_signal_connect (tex, "notify::mapped",
                      G_CALLBACK (window_mapped_changed), NULL);
    g_signal_connect (tex, "notify::window-x",
                      G_CALLBACK (window_position_changed), NULL);
    g_signal_connect (tex, "notify::window-y",
                      G_CALLBACK (window_position_changed), NULL);

    {
        gint mapped, destroyed;
        g_object_get (tex, "mapped", &mapped, NULL);
        if (mapped)
            window_mapped_changed (tex, NULL, NULL);
    }
}

Once we create the window, Clutter will listen for changes in its state -- resizes, maps or unmaps, and ultimately its destruction. (Or at least it will, once #1020 is applied.) Here we connect with the minimum bits necessary to make a window usable. Finally, the functions to show, hide, and resize windows:

static void
window_position_changed (ClutterActor *tex, GParamSpec *pspec, gpointer unused)
{
    gint x, y, window_x, window_y;
    g_object_get (tex, "x", &x, "y", &y, "window-x", &window_x,
                  "window-y", &window_y, NULL);
    if (x != window_x || y != window_y)
        clutter_actor_set_position (tex, window_x, window_y);
}

static void
window_mapped_changed (ClutterActor *tex, GParamSpec *pspec, gpointer unused)
{
    gint mapped;
    g_object_get (tex, "mapped", &mapped, NULL);

    if (mapped){
        clutter_container_add_actor (CLUTTER_CONTAINER (stage), tex);
        clutter_actor_show (tex);
        window_position_changed (tex, NULL, NULL);
    } else {
        clutter_container_remove_actor (CLUTTER_CONTAINER (stage), tex);
    }
}

final notes

Code is here, compile as:

 gcc `pkg-config --cflags --libs clutter-glx-0.8` \
     -o mini-clutter-wm mini-clutter-wm.c 

You might want to run it in a Xephyr; do it with the script here:

 ./run-xephyr ./mini-clutter-wm

Joey again:

So ideally, "I switched to a new window manager" doesh't mean "my screen has some different widgets on it now". It means "I'm looking at the screen with new eyes."

This blog is already way too long, so I'll revisit interface concepts at some point in the future. For now I just wanted to pull together this knowledge in one place. Happy hacking!

word

Equanimous \E*quan"i*mous\, a.
[L. aequanimus, fr. aequus equal + animus mind.]

Of an even, composed frame of mind; of a steady temper; not easily elated or depressed.
[1913 Webster]

Delightful. Makes me think of Medialens folk.

words

I have a new favorite orator: Michael Parenti.

A brief search on the interwebs will only find you his web site, which is a bit off-putting, and doesn't really show to his strengths. But take a listen to Land of Idols (40 minutes), then check out the other talks in that same directory (search for "parenti").

wheels

Set off on what must have been a 100 km loop last Sunday on the bike, after coming back from GUADEC; Google thinks the distance was significantly less. Perhaps I should report a bug?

Meanwhile at home, yet another broken spoke.

sense

It was so quiet walking home this evening that even smelling the street odors made me feel like I was eavesdropping.

Well, given that I have not figured out how to traverse the great firewall of Bah&#xE7;e&#x15F;ehir for SMTP+TLS, or, that is, no mail sending... may I claim "first post" for language bindings for Clutter 0.8!

Guile-Clutter 0.8 is out! Download it here: ftp.gnu.org/pub/gnu/guile-gnome/blah/dee/blah/dee/blah

Or check the fledgling, love-needing docs.

Hack hack hack hack hack

All the time we are presented with options. Should I get my vegetables from the greengrocer's, the supermarket, or the farmer's market? Should I buy a PC or a Mac? Should I start my new project in Ruby or C#? All of these options are equivalent: they're just vegetables, they're just computers, they're just languages. So how to choose?

Some people make choices on technical grounds: for example, "I'm going to buy a Mac because it has a video editor." This is rational, but its rationality degrades over time. The next time you go to buy a computer, you just buy a Mac because it's what you got last time.

To take another example that Robert Collins mentioned on Monday, if you choose bzr over subversion because bzr does merges, what happens in a few months when subversion finally gets merge support? So you make your decision for a reason that turns out not to mean anything. If people go massively for git because of git's workflow and in-place branching, you can be sure that bzr will get the same workflow in the future, and in fact has some of it now.

What I would suggest is that we should make choices not on strictly technical bounds. Instead we should make a choice based on culture. When you choose something to be a part of your future, it affects your culture, the world around you. You invite a tool, a set of people, a set of social relations into your life and into your future.

Technical considerations form a part of culture. Anyone who knows something about Silverlight and Mozilla knows that the technical differences in the projects reflect different values. These values translate into different futures: a world where technology flows from Microsoft, out to the world, or a world in which hackers collaborate in the open to shape their own destiny, our own destiny.

It is especially important not to make decisions about perceived market share, perceived uptake, or the like. For one, these perceptions are easily manipulated. This is the task of the propaganda industry, euphemistically referred to as "public relations". For another, when we choose to invite e.g. GNU into our lives, we affect the future, and especially that part of the future that is in our immediate surroundings.

So in conclusion, and for the GNOME audience, we as hackers build the structures that we are going to live in for a long time. When we make decisions about technology, we begin relationships with people, and to some degree take their values on as our own. We should make sure that we recognize this, and that the values of the technologies we choose mesh with our own, as individuals and as a community.

(For another take on "what makes us the same are not technical similarities, but cultural similarities", and especially in relation to a possible GUADEC / aKademy joint event, see Lambda, the ultimate political party.)

My camera broke; I have only words.

the golden horn

Istanbul is a town full of wonder. And wander: around the cobbled streets of the old town, in the morning, in the evening, alive at all hours.

Last night I shared a water-pipe under the bridge, looking back on the night silhouette of the old town, smoke rings dissipating over the water. As we were walking back to the hostel some hours later, Dimitris noted the waft of baking bread, the start of a new day.

I stepped out on Sunday morning to the GStreamer mini-summit, but was waylaid by the Blue Mosque. Outside it is grey, hard stone and spired; inside it is lush and tactile, the carpet creeping up between your toes. I believe that space can have rhythm. In that place there was a rich visual soundscape, tiled motifs repeating on the macro level, fractally recursing into micro-vegetation, a symphony of space and lines. I stumbled out into the blue sky.

gstreamer, breakage

The GStreamer summit was pretty good. We decided to switch to git (from CVS), once some issues are ironed out regarding history and our "common" submodule. We also decided that at some point we should do a new development cycle, but that we needed reasons for doing so; the idea would be to develop a number of features that cannot be done with 0.10 in experimental branches, and once there are enough branches, we pull them together in a quick 0.11 and from there to 0.12 or 1.0. This would be a process that could take a year or two.

In that regard, some interesting points were brought up regarding GLib and GTK+'s plan to break ABI for version 3. The problem is that any library that depends on GLib will break ABI as well, and that includes GStreamer. So given that we will need to break ABI to depend on GLib 3, that gives us a good timetable for a next development series, corresponding to GLib 3's release in about 16 months. I suspect that many projects will want to do the same.

Hackers, slackers, countrymen and countrywomen:

Guile-Gnome-Platform, that beast of the dual hyphen, has finally reached stability. You might say that the API and the ABI are as stable as the hills, but we like to put it like this: "Write once, run anywhen"

(Amused tittering)

From the release notes:

There are several things that are the awesome about this code:

• It's fully integrated!
  Instances of GObject are objects in Scheme; you can query their properties, class hierarchies, etc at runtime. You can derive new types yourself, with signals, properties, and the like. Good stuff!

• It's fully documented!
  Start with the tutorial/reference docs for the core GObject wrapper, then branch out into individual modules.

• Fully extensible!
  Guile-Gnome-Platform also provides a good base off of which to bind other libraries based on GLib. For example, Guile-Clutter binds almost all of the new Clutter library, with documentation, and most of that work was done in a day.

• Stable!
  Write once, run anywhen! Guile-Gnome's API and ABI will never be changed incompatibly.

• Scheme!
  You will be assimilated, or alternately, gnawed to death by fingernail clippings.

More info at the homepage. DANGER CAPTAIN: ASSIMILATION IMMINENT

Good evening!

Here the evening is good indeed -- tepid air, the kind where you don't know it's there until it moves, or you move: skin temperature. We don't get too many colored cloud sunsets, but today there was sky-drama over the wasteland of la Sagrera.

q

I have a question, to those in the know. It's nargery. I have a machine with intel graphics, a GM965. It claims to support the texture_from_pixmap extension, but I have not been able to make it work, neither in my own code nor in that of others. I whine about it more in the fedora bugzilla. What's the dilly?

conversations

I'm in a fortunate position to have readers that might just be able to answer that question. This is mostly a result of being syndicated on Planet GNOME, although Advogato and individual subscribers do play a role. But it is good to write for an audience.

In that regard, I think that Advogato is a much more appropriate system for publishing and reading, for conversation, than are the various planets out there. Advo has no barrier to entry; anyone can start writing. You can syndicate your writings from elsewhere, like you can with a planet, or write them there if you feel like it. If your writings are good, or interesting, then folks will read them. If some people don't like them, they don't have to see them. If no one likes them, no one will see them.

Granted, present-day advogato does have its problems. It seems that its model of trust has drifted too far from the root nodes; my ratings never affect someone's rank, even to go from observer to apprentice. "Apprentice", while it does correspond to reality in some sense, is seen as demeaning; everyone wants to be a journeyer, if not a master. The front-page articles have been of low quality for a long time. But the diary "interesting-ness" ratings do seem to have stood the test of time.

Project-specific aggregators like Planet GNOME are great. They're wonderful for community, and good for communication too: "this is who we are". But I do miss the easy anarchy of Advogato. Maybe it's time to make an antiplanet, running on mod_virgule. Thoughts?

I am, in some sense, relieved that Obama won the Democratic primaries this year, defeating the Clinton machine and its +47 cloak of inevitability. It is possible that Obama effect some meaningful change in the US, and in the world.

But.

As an attendee of the recent National Conference for Media Reform noted (edited slightly),

Although there can be something invigorating about being in such a large crowd of like-minded people, I feel more passion and energy in a march, where we are more participants than audience.

Strangely, as I wrote those very words, Naomi Klein spoke of the need to stop treating politicians &#x201C;as celebrities, as rock stars&#x201D; - that is, that the public should have an active relationship with their politicians, pushing back and shaping their actions and policies. As she puts it, &#x201C;the greatest gift you can give Barack Obama&#x201D; is to keep the pressure on, so when he talks with Wall Street backers he can say &#x201C;Look: I've got no choice. They&#x2019;re crazy out there!&#x201D;

We're crazy out here: being realistic, demanding the impossible!

It is with this perspective that we should approach the upcoming Obama election. Let's cut the rock star crap (in politics and elsewhere: here's looking at you, Jono), and start to focus on organizing to get what we want, on direct action. Obama is an instrument of the people, not an agent for the people; any other formulation is anti-democratic.

Klein continues, in a riveting speech that starts at about minute 43 in this 30 MB MP3:

The hard truth is this: Obama may have the energy, and the anger, and the networks of the anti-war vote, but he does not have a plan to get us out of Iraq.

What he has is a plan to downsize the occupation of Iraq, not to end it.

He talks about keeping the "green zone" intact and calls it ending the war. Let me tell you, you cannot keep the "green zone", which is the symbol of the foreign occupation of Iraq, without a massive troop presence, which includes the military contractors like Blackwater as well.

He may have the very real rage at the income equality that has opened up in this country and around the world, but I am sad to say that he does not have a real plan to close that gap.

And he may have the incredible, inspiring idealism of young environmentalists, who are terrified about the future of this planet, but he does not have a green agenda that is a match to our climate crisis.

the cooling out of america, or: "we, the marks"

I can understand that people want to support Obama. I hope he wins. But how can Big Pharma give $700K to a candidate that will do what needs to be done to US healthcare? (What the hell is a "Health Product" anyway?) Or what about the bankers, the authors of the recent and ongoing securitization debacle and subsequent commodities speculation?

Or, to take things from the other side, where is the money going? Well, it's basically funneling back into the institutions that sold us the Iraq war in the first place: according to my readings of the interwebs, about half a million a day just on television, an American institution so shameful it makes Berlusconi jealous.

Back in the Clinton years, former computer programmer Richard Moore used the red pill / blue pill metaphor of The Matrix to write of the state of popular delusion:

When I started tracing historical forces, and began to interpret present-day events from a historical perspective, I could see the same old dynamics at work and found a meaning in unfolding events far different from what official pronouncements proclaimed. Such pronouncements are, after all, public relations fare, given out by politicians who want to look good to the voters. Most of us expect rhetoric from politicians, and take what they say with a grain of salt. But as my own picture of present reality came into focus, "grain of salt" no longer worked as a metaphor. I began to see that consensus reality -- as generated by official rhetoric and amplified by mass media -- bears very little relationship to actual reality. "The matrix" was a metaphor I was ready for.

Escaping the Matrix, 2000; best listened to over mp3, but also available as text

Among the chief strategies for construction of a humane, red-pill future has to be a creation of new media. The apparati through which we perceive the world must belong to us, and work for our interests, instead of trying to sell us cars and pan bimbo.

In recent months, my most consistent source of political analysis has been Unwelcome Guests. Lyn Gerry is sharp, and caring. I've grown rather fond of her plodding voice. And she's an old hacker of sorts: with a few other folks back in 1996, she founded radio4all, an interwebby place to exchange radio clips for broadcast on community radio. Also, "[t]he Radio Project supports the Free Software Movement, and uses free software wherever possible."

But I digress. Gerry is great. I've probably listened to 400 hours of her shows over the past six months, easily worth more in mind-expansion and education that a number of classes I endured in college, put together. She is my red pill.

a mar revuelto, ganancia de pescadores?

The red pill, once taken, opens the mind past the current Oceania-vs-Eastasia sports-like rivalries that the media take as the gamut of allowable political participation. Obama is not some crazy human hope, object of mystery and fervor -- he is merely a tool, a tool of the people, a stake in the ground in a much larger fight. Gerry says:

It makes me crazy every time I hear some talking head or pundit or politician pretend they didn't know from jump street that, for example, the Bush administration lied about WMD in Iraq. You and I knew it was a lie, and if I, a radio producer with a budget of 0, and a staff of 1, who lives in a rural town with a population slightly above 2000, can find that out and report on it, you bet those well-funded networks can. The people that run them may be craven and they may be cowards, but they're not stupid. They lie to us because they want us to be ignorant and subservient. Knowledge is power, and that's why a free press matters.

So if you find yourself with 20 or 100 bucks, and in an impassioned or drunken moment want to use it to change the world, think twice before clicking "submit" on barackobama.com. Maybe your local community radio or your radical press or Z communications or radio4all.net could use it more.