Advogato blog for wingo

the economy, stupid

Fri, 26 Sep 2008 18:13:00 GMT

Modern finance tries as hard as it can to be obtuse, opaque, and unintelligible.

You can even hear this from establishment sources, as they cry out for "transparency in the markets". But still, without active government intervention, transparency is on the decline: nobody knows what is going on in the commodities market, in the securitized bonds market, even in the stock market. Speculators pump and dump. This is the "free market" tendency.

All of this seems to be irrational, an aberration from the "free market" ideals. (The quotations are to indicate that this is a marketing term, that liberty does not necessarily proceed from mercantile exchange.) This fact is a bit strange if you come from an orthodox economic training, such as that which is propagated in the newspapers or in Econ 201 classes across the US.

However, lack of transparency in economic discourse follows directly if you understand economics as a struggle between class interests. It is simply that the explanation that fits best with the facts is too empowering to propagate. Broad understanding of the essentials is not to the advantage of the dominant class in society. Anyone caught discussing class is accused of being corrosive or divisive. You will not find "class" in 7th grade textbooks.

Simply put, a class-based understanding of economics and society has a higher explanatory, expressive, and predictive power than a "free market-based" ideology. Furthermore, it aligns with a moral imperative to abolish class itself.

To me, the moment in which this clicked for me was in college, when an old socialist teaching a sort of russian studies class mentioned that the socialists, the communists, and the anarchists knew that World War I was coming, that they wrote about it, that it was an inevitable consequence of the expansion of finance capital (as opposed to land/agricultural or industrial capital).

When your primary interest is financial capital, you form part of the non-productive economy, of the equestrian class; and capital's imperative being to grow at all costs, you must choose where to invest (not whether to invest). The highest profits have traditionally been found via exploitation (use or utilization, esp. for profit) of the undeveloped world. Rubber from Africa, coffee from Latin America, tea from Asia -- not to mention petroleum.

As Eduardo Galeano notes, capital does not go to Latin America because Latin America is poor -- it goes because Latin America is rich, it goes to exploit, to bleed off the "excess value".

When two sugar-frenzied gunpowder-toting finance-laden World Powers happen to coincide -- well from there we have the detentes, the German South-West Africas, leading to war as an externalization of financial conflict. The losers, of course, are the ones on whose land the fight occurs -- the Hereros, the Balkans, the Iraqis (our armies do not come into your cities and lands as conquerors or enemies, but as liberators).

a return

So, the wine from lunch led me a bit off track. My point is that all real revolutionary analysis and action has taken aim at, among other things, the financial system. Witness the Populists of the 1890s, which gave broad understanding of monetary policy to ordinary people, gave them tools with which to critique the machinations of the Morgans and the Chases. The Wobblies, the anarchists, even the reformers of the 30s knew this.

Now we are at a point where broad understanding of monetary policy is essential -- both understanding of the current situation, and knowing what our options are. There has been some excellent economic analysis in Z Magazine recently, in a series by Jack Rasmus.

Fannie Mae, Freddie Mac -- Phase two of financial crisis (Sept 08)
Emerging Epic Recession? (Jun 08)
From Financial Crisis to Recession, Part II -- Symptoms appear of a fundamental financial instability (Apr 08)
From Global Financial Crisis to Global Recession, Part I -- Precipitating the fall (Mar 08)

I believe that first and the last articles are freely available, but the middle two need at least a free registration and possibly a subscription.

subscribe already mkay

Here's where I get on the stump: If you claim to be a radical, if you want to be a radical, you must subscribe to radical media. It is completely necessary. Z Magazine, for example, is a great one. Its quality varies, but the high points are pretty high. (It took me some time to appreciate the cartoons.)

More importantly, such fora are crucial for getting out the word about important, constructive things happening on the left -- from Parecon to the IVAW Winter Soldier events, to fights for ecologically sustainable patterns of food, transport, and housing, to checking on what's going on in other facets of the movement -- GLBT rights, anti-racism, etc.

Radical media are a crucial point of bridge-building and solidarity between parts of the radical left. Without them, we are left feeling like we are on our own. So subscribe to Z already!

breaking silence, innocuously

Thu, 18 Sep 2008 23:07:05 GMT

Greeting, faerie webfolk.

I have a number of things in yon backlog, but as they build up, they stop up, so I figured with a bottle of wine behind me I could loose the gates on a topic: continuations.

Now, friends of mine: you may not be interested in this topic. If this is the case, treat this as the gristle: it is perhaps not tasty, but it comes with the meat.

But if the topic of call/cc and continuations interests you, you may treat this as the fat in panceta (I do not agree with their spelling): delicious.

If you bristle at the double-dot: that's ok too.

My point when I started all of this was, Scheme weenies extol the benefits of call-with-current-continuation. (Not until the most recent standard, the controversial r6rs, did the establishment deign to accept the popular spelling, call/cc. Such is the Scheme culture.) Weenies of other languages (Ruby, although Google denies me the references: searching while tipsy, the cop said) also relish in their esoteric delight.

But with all of the literature in the Scheme community about continuations and compilation, with all the talk about continuation-based web platforms, it's still basically intractable.

The reasons are two, basically. One, you cannot represent all of the continuation of an operation; there is always a level beyond which you cannot represent. This is most basically evident in the state of the connection of the continuation-aware system to the outside world, for example as indicated in the file descriptor table in the kernel.

The second reason is that you almost always grab more information than you want, making call/cc a quite heavy-weight operation. The most brute-force method simply copies the entire C stack from the point of the call/cc on down to some root address, and reinstates on reinvocation -- yet you almost never touch the bottom stack frames in such a continuation. I think stack-copying is a perfectly valid implementation strategy for continuations, in many contexts, but not of the entire C stack down to arbitrary depth.

Now, delimited continuations and prompts: there is where the actual useful possibilities are. As always, Oleg has lots to say on that, including a number of very interesting analogies to processes and operating systems.

I suppose it was Felleisen that first came up with the analogy, and I'm sure he was thinking of it in operating-system contexts -- the REPL is after all a boundary between an operating system and user-space. I'd link to his paper if the ACM weren't a pack of scrooge mcducks. (The theory and practice of first-class prompts, if that's your thing.)

This post brought to you by Miguel Torres, S.A and the need to compile r4rs.scm, about which more later.

on the many roads to perdition

Sat, 2 Aug 2008 14:11:37 GMT

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!

introducing griddy

Thu, 31 Jul 2008 15:12:42 GMT

5m50s, 2.5 MB, Theora

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

so you want to build a compositor

Sat, 26 Jul 2008 22:09:10 GMT

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.

á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!

equanimity

Tue, 22 Jul 2008 23:07:20 GMT

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.

guile ? clutter ? quoi ?

Fri, 11 Jul 2008 14:09:03 GMT

Well, given that I have not figured out how to traverse the great firewall of Bahçeş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

how to choose between equivalent options

Thu, 10 Jul 2008 15:09:34 GMT

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.)

notes from the bosphorus

Wed, 9 Jul 2008 12:11:11 GMT

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.

stable guile-gnome released

Thu, 3 Jul 2008 18:07:34 GMT

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