To compile namecoind remember to fetch the following dependencies (at least on debian):

• libboost-dev
• libssl-dev
• libdb++-dev
• libboost-system-dev
• libboost-filesystem-dev
• libboost-program-options-dev
• libboost-thread-dev
• libglib2.0-dev

Completing the DRI3 Extension This week marks a pretty significant milestone for the glorious DRI3000 future. The first of the two new extensions is complete and running both full Gnome and KDE desktops. DRI3 Extension Overview The DRI3 extension provides facilities for building direct rendering libraries to work with the X window system. DRI3 provides three basic mechanisms:

1. Open a DRM device.
2. Share kernel objects associated with X pixmaps. The direct rendering client may allocate kernel objects itself and ask the X server to construct a pixmap referencing them, or the client may take an existing X pixmap and discover the underlying kernel object for it.
3. Synchronize access to the kernel objects. Within the X server, Sync Fences are used to serialize access to objects. These Sync Fences are exposed via file descriptors which the underlying driver can use to implement synchronization. The current Intel DRM driver passes a shared page containing a Linux Futex.

Opening the DRM Device Ideally, the DRM application would be able to just open the graphics device and start drawing, sending the resulting buffers to the X server for display. There s work going on to make this possible, but the current situation has the X server in charge of blessing the file descriptors used by DRM clients. DRI2 does this by having the DRM client fetch a magic cookie from the kernel and pass that to the X server. The cookie is then passed to the kernel which matches it up with the DRM client and turns on rendering access for that application. For DRI3, things are much simpler the DRM client asks the X server to pass back a file descriptor for the device. The X server opens the device, does the magic cookie dance all by itself (at least for now), and then passes the file descriptor back to the application.

 
    DRI3Open
    drawable: DRAWABLE
    driverType: DRI3DRIVER
    provider: PROVIDER
       
    nfd: CARD8
    driver: STRING
    device: FD
 
    Errors: Drawable, Value, Match
    This requests that the X server open the direct rendering
    device associated with drawable, driverType and RandR
    provider. The provider must support SourceOutput or SourceOffload.
    The direct rendering library used to implement the specified
    'driverType' is returned in 'driver'. The file
    descriptor for the device is returned in 'device'. 'nfd' will
    be set to one (this is strictly a convenience for XCB which
    otherwise would need request-specific information about how
    many file descriptors were associated with this reply).

Sharing Kernel Pixel Buffers An explicit non-goal of DRI3 is support for sharing buffers that don t map directly to regular X pixmaps. So, GL ancillary buffers like depth and stencil just don t apply here. The shared buffers in DRI3 are regular X pixmaps in the X server. This provides a few obvious benefits over the DRI2 scheme: In the kernel, the buffers are referenced by DMA-BUF handles, which provides a nice driver-independent mechanism.

1. Lifetimes are easily managed. Without being associated with a separate drawable, it s easy to know when to free the Pixmap.
2. Regular X requests apply directly. For instance, copying between buffers can use the core CopyArea request.

To create back- and fake-front- buffers for Windows, the application creates a kernel buffer, associates a DMA-BUF file descriptor with that and then sends the fd to the X server with a pixmap ID to create the associated pixmap. Doing it in this direction avoids a round trip.

 
    DRI3PixmapFromBuffer
    pixmap: PIXMAP
    drawable: DRAWABLE
    size: CARD32
    width, height, stride: CARD16
    depth, bpp: CARD8
    buffer: FD
 
    Errors: Alloc, Drawable, IDChoice, Value, Match
    Creates a pixmap for the direct rendering object associated
    with 'buffer'. Changes to pixmap will be visible in that
    direct rendered object and changes to the direct rendered
    object will be visible in the pixmap.
    'size' specifies the total size of the buffer bytes. 'width',
    'height' describe the geometry (in pixels) of the underlying
    buffer. 'stride' specifies the number of bytes per scanline in
    the buffer. The pixels within the buffer may not be arranged
    in a simple linear fashion, but 'size' will be at least
    'height' * 'stride'.
    Precisely how any additional information about the buffer is
    shared is outside the scope of this extension.
    If buffer cannot be used with the screen associated with
    drawable, a Match error is returned.
    If depth or bpp are not supported by the screen, a Value error
    is returned.

To provide for texture-from-pixmap, the application takes the pixmap ID and passes that to the X server which returns the a file descriptor for a DMA-BUF which is associated with the underlying kernel buffer.

 
    DRI3BufferFromPixmap
    pixmap: PIXMAP
       
    depth: CARD8
    size: CARD32
    width, height, stride: CARD16
    depth, bpp: CARD8
    buffer: FD
 
    Errors: Pixmap, Match
    Pass back a direct rendering object associated with
    pixmap. Changes to pixmap will be visible in that
    direct rendered object and changes to the direct rendered
    object will be visible in the pixmap.
    'size' specifies the total size of the buffer bytes. 'width',
    'height' describe the geometry (in pixels) of the underlying
    buffer. 'stride' specifies the number of bytes per scanline in
    the buffer. The pixels within the buffer may not be arranged
    in a simple linear fashion, but 'size' will be at least
    'height' * 'stride'.
    Precisely how any additional information about the buffer is
    shared is outside the scope of this extension.
    If buffer cannot be used with the screen associated with
    drawable, a Match error is returned.

Tracking Window Size Changes When Eric Anholt and I first started discussing DRI3, we hoped to avoid needing to learn about the window size from the X server. The thought was that the union of all of the viewports specified by the application would form the bounds of the drawing area. When the window size changed, we expected the application would change the viewport. Alas, this simple plan isn t sufficient here a few GL functions are not limited to the viewport. So, we need to track the actual window size and monitor changes to it. DRI2 does this by delivering invalidate events to the application whenever the current buffer isn t valid; the application discovers that this event has been delivered and goes to as the X server for the new buffers. There are a couple of problems with this approach:

1. Any outstanding DRM rendering requests will still draw to the old buffers.
2. The Invalidate events must be captured before the application sees the related ConfigureNotify event so that the GL library can react appropriately.

The first problem is pretty intractable within DRI2 the application has no way of knowing whether a frame that it has drawn was delivered to the correct buffer as the underlying buffer object can change at any time. DRI3 fixes this by having the application in control of buffer management; it can easily copy data from the previous back buffer to the new back buffer synchronized to its own direct rendering. The second problem was solved in DRI2 by using the existing Xlib event hooks; the GL library directly implements the Xlib side of the DRI2 extension and captures the InvalidateBuffers events within that code, delivering those to the driver code. The problem with this solution is that Xlib holds the Display structure mutex across this whole mess, and Mesa must be very careful not to make any Xlib calls during the invalidate call. For DRI3, I considered placing the geometry data in a shared memory buffer, but my future plans for the Present extension led me to want an X event instead (more about the Present extension in a future posting). An X ConfigureNotify event is sufficient for the current requirements to track window sizes accurately. However, there s no easy way for the GL library to ensure that ConfigureNotify events will be delivered to the application other application code may (and probably will) adjust the window event mask for its own uses. I considered adding the necessary event mask tracking code within XCB, but again, knowing that the Present extension would probably need additional information anyhow, decided to create a new event instead. Using an event requires that XCB provide some mechanism to capture those events, keep them from the regular X event stream, and deliver them to the GL library. A further requirement is that the GL library be absolutely assured of receiving notification about these events before the regular event processing within the application will see a core ConfigureNotify event. The method I came up with for XCB is fairly specific to my requirements. The events are always XGE events, and are tagged with a special event context ID , an XID allocated for this purpose. The combination of the extension op-code, the event type and this event context ID are used to split off these events to custom event queues using the following APIs:

/**
 * @brief Listen for a special event
 */
xcb_special_event_t *xcb_register_for_special_event(xcb_connection_t *c,
                                                    uint8_t extension,
                                                    uint16_t evtype,
                                                    uint32_t eid,
                                                    uint32_t *stamp);

This creates a special event queue which will contain only events matching the specified extension/type/event-id triplet.

/**
 * @brief Returns the next event from a special queue
 */
xcb_generic_event_t *xcb_check_for_special_event(xcb_connection_t *c,
                                                 xcb_special_event_t *se);

This pulls an event from a special event queue. These events will not appear in the regular X event queue and so applications will never see them. There s one more piece of magic here the stamp value passed to xcbregisterforspecialevent. This pointer refers to a location in memory which will be incremented every time an event is placed in the special event queue. The application can cheaply monitor this memory location for changes and known when to check the queue for events. Within GL, the value used is the existing dri2 stamp value. That is checked at the top of the rendering operation; if it has changed, the drawing buffers will be re-acquired. Part of the buffer acquisition process is a check for special events related to the window. For now, I ve placed these events in the DRI3 extension. However, they will move to the Present extension once that is working.

 
    DRI3SelectInput
    eventContext: DRI3EVENTID
    window: WINDOW
    eventMask: SETofDRI3EVENT
 
    Errors: Window, Value, Match, IDchoice
    Selects the set of DRI3 events to be delivered for the
    specified window and event context. DRI3SelectInput can
    create, modify or delete event contexts. An event context is
    associated with a specific window; using an existing event
    context with a different window generates a Match error.
    If eventContext specifies an existing event context, then if
    eventMask is empty, DRI3SelectInput deletes the specified
    context, otherwise the specified event context is changed to
    select a different set of events.
    If eventContext is an unused XID, then if eventMask is empty
    no operation is performed. Otherwise, a new event context is
    created selecting the specified events.

The events themselves look a lot like a configure notify event:

 
    DRI3ConfigureNotify
    type: CARD8         XGE event type (35)
    extension: CARD8        DRI3 extension request number
    length: CARD16          2
    evtype: CARD16          DRI3_ConfigureNotify
    eventID: DRI3EVENTID
    window: WINDOW
    x: INT16
    y: INT16
    width: CARD16
    height: CARD16
    off_x: INT16
    off_y: INT16
    pixmap_width: CARD16
    pixmap_height: CARD16
    pixmap_flags: CARD32
 
    'x' and 'y' are the parent-relative location of 'window'.

Note that there are a couple of odd additional fields offx, offy, pixmapwidth, pixmapheight and pixmap_flags are all place-holders for what I expect to end up in the Present extension. For now, in DRI3, they should be ignored. Synchronization The DRM application needs to know when various X requests related to its buffers have finished. In particular, when performing a buffer swap, the client wants to know when that completes, and be able to block until it has. DRI2 does this by having the application make a synchronous request from the X server to get the names of the new back buffer for drawing the next frame. This has two problems:

1. The synchronous round trip to the X server isn t free. Other running applications may cause fairly arbitrary delays in getting the reply back from the X server.
2. Synchronizing with the X server doesn t ensure that GPU operations are necessarily serialized between the application and the X server.

What we want is a serialization guarantee between the X server and the DRM application that operates at the GPU level. I ve written a couple of times (dri3k first steps and Shared Memory Fences) about using X Sync extension Fences (created by James Jones and Aaron Plattner) for this synchronization and wanted to get a bit more specific here. With the X server, a Sync extension Fence is essentially driver-specific, allowing the hardware design to control how the actual synchronization is performed. DRI3 creates a way to share the underlying operating system object by passing a file descriptor from application to the X server which somehow references that device object. Both sides of the protocol need to tacitly agree on what it means.

 
    DRI3FenceFromFD
    drawable: DRAWABLE
    fence: FENCE
    initially-triggered: BOOL
    fd: FD
 
    Errors: IDchoice, Drawable
    Creates a Sync extension Fence that provides the regular Sync
    extension semantics along with a file descriptor that provides
    a device-specific mechanism to manipulate the fence directly.
    Details about the mechanism used with this file descriptor are
    outside the scope of the DRI3 extension.

For the current GEM kernel interface, because all GPU access is serialized at the kernel API, it s sufficient to serialize access to the kernel itself to ensure operations are serialized on the GPU. So, for GEM, I m using a shared memory futex for the DRI3 synchronization primitive. That does not mean that all GPUs will share this same mechanism. Eliminate the kernel serialization guarantee and some more GPU-centric design will be required. What about Swap Buffers? None of the above stuff actually gets bits onto the screen. For now, the GL implementation is simply taking the X pixmap and copying it to the window at SwapBuffers time. This is sufficient to run applications, but doesn t provide for all of the fancy swap options, like limiting to frame rate or optimizing full-screen swaps. I ve decided to relegate all of that functionality to the as-yet-unspecified Present extension. Because the whole goal of DRI3 was to get direct rendered application contents into X pixmaps, the Present extension will operate on those X objects directly. This means it will also be usable with non-DRM applications that use simple X pixmap based double buffering, a class which includes most existing non-GL based Gtk+ and Qt applications. So, I get to reduce the size of the DRI3 extension while providing additional functionality for non direct-rendered applications. Current Status As I said above, all of the above functionality is running on my systems and has booted both complete KDE and Gnome sessions. There have been some recent DMA-BUF related fixes in the kernel, so you ll need to run the latest 3.9.x stable release or a 3.10 release candidate. Here s references to all of the appropriate git repositories: DRI3 protocol and spec:

git://people.freedesktop.org/~keithp/dri3proto      master

XCB protocol

git://people.freedesktop.org/~keithp/xcb/proto.git  dri3

XCB library

git://people.freedesktop.org/~keithp/xcb/libxcb.git dri3

xshmfence library:

git://people.freedesktop.org/~keithp/libxshmfence.git   master

X server:

git://people.freedesktop.org/~keithp/xserver.git    dri3

Mesa:

git://people.freedesktop.org/~keithp/mesa.git       dri3

Next Steps Now it s time to go write the Present extension and get that working. I ll start coding and should have another posting here next week.

here's the overview about my RC bug fixing activities for the last week:

• #666799 libapache2-reload-perl: "libapache2-reload-perl: sourceful transition towards Apache 2.4"
  prepare adaption to apache 2.4 in git (pkg-perl)
• #666800 libapache-singleton-perl: "libapache-singleton-perl: sourceful transition towards Apache 2.4"
  prepare adaption to apache 2.4 in git (pkg-perl)
• #666807 libapache-authenhook-perl: "libapache-authenhook-perl: sourceful transition towards Apache 2.4"
  prepare adaption to apache 2.4 in git (pkg-perl)
• #666822 libapache2-mod-perl2: "libapache2-mod-perl2: sourceful transition towards Apache 2.4"
  upload the package to unstable, most of the work done by Niko Tyni (pkg-perl)
• #666837 libapache2-authcookie-perl: "libapache2-authcookie-perl: sourceful transition towards Apache 2.4"
  try to prepare adaption to apache 2.4 in git (pkg-perl)
• #678380 remotetea: "remotetea: FTBFS with Java7 as default java"
  apply patch from Ubuntu / James Page, upload to DELAYED/2
• #684296 tomcat-maven-plugin: "tomcat-maven-plugin: Drop build dependency on openjdk-6-jdk"
  apply patch from Ubuntu / James Page, upload to DELAYED/2
• #684305 umlet: "umlet: Transition package to use default java implementation"
  apply patch from Ubuntu / James Page, upload to DELAYED/2
• #709055 netmrg: "netmrg: FTBFS with multiarch net-snmp"
  apply patch from Ubuntu / Colin Watson, upload to DELAYED/2
• #709183 librep: "librep: FTBFS on kfreebsd-amd64"
  apply patch from Steven Chamberlain, upload to DELAYED/2
• #710416 courier-filter-perl: "courier-filter-perl: postinst uses /usr/share/doc content (Policy 12.3)"
  fix installation of config file (pkg-perl)

Cameron Russell (who works as an underwear model) gave an interesting TED talk about beauty [1]. Ben Goldacre gave an interesting and energetic TED talk about bad science in medicine [2]. A lot of the material is aimed at non-experts, so this is a good talk to forward to your less scientific friends. Lev wrote a useful description of how to disable JavaScript from one site without disabling it from all sites which was inspired by Snopes [3]. This may be useful some time. Russ Allbery wrote an interesting post about work and success titled The Why? of Work [4]. Russ makes lots of good points and I m not going to summarise them (read the article, it s worth it). There is one point I disagree with, he says You are probably not going to change the world . The fact is that I ve observed Russ changing the world, he doesn t appear to have done anything that will get him an entry in a history book but he s done a lot of good work in Debian (a project that IS changing the world) and his insightful blog posts and comments on mailing lists influence many people. I believe that most people should think of changing the world as a group project where they are likely to be one of thousands or millions who are involved, then you can be part of changing the world every day. James Morrison wrote an insightful blog post about what he calls Penance driven development [5]. The basic concept of doing something good to make up for something you did which has a bad result (even if the bad result was inadvertent) is probably something that most people do to some extent, but formalising it in the context of software development work is a cencept I haven t seen described before. A 9yo boy named Caine created his own games arcade out of cardboard, when the filmmaker Nirvan Mullick saw it he created a short movie about it and promoted a flash mob event to play games at the arcade [6]. They also created the Imagination Foundation to encourage kids to create things from cardboard [7]. Tanguy Ortolo describes how to use the UDF filesystem instead of FAT for USB devices [8]. This allows you to create files larger than 2G while still allowing the device to be used on Windows systems. I ll keep using BTRFS for most of my USB sticks though. Bruce Schneier gave an informative TED talk about security models [9]. Probably most people who read my blog already have a good knowledge of most of the topics he covers. I think that the best use of this video is to educate less technical people you know. Blaine Harden gave an informative and disturbing TED talk about the concentration camps in North Korea [10]. At the end he points out the difficult task of helping people recover from their totalitarian government that will follow the fall of North Korea. Bruce Schneier has an interesting blog post about the use of a motherboard BMC controller (IPMI and similar) to compromise a server [11]. Also some business class desktop systems and laptops have similar functionality. Russ Allbery wrote an insightful article about the failures of consensus decision-making [12]. He compares the Wikipedia and Debian methods so his article is also informative for people who are interested in learning about those projects. The TED blog has a useful reference article with 10 places anyone can learn to code [13]. Racialicious has an interesting article about the people who take offense when it s pointed out that they have offended someone else [14]. Nick Selby wrote an interesting article criticising the Symantic response to the NYT getting hacked and also criticises anti-viru software in general [15]. He raises the point that most of us already know, anti-virus software doesn t do much good. Securing Windows networks is a losing game. Joshua Brindle wrote an interesting blog post about security on mobile phones and the attempts to use hypervisors for separating data of different levels [16]. He gives lots of useful background information about how to design and implement phone based systems.

• [1] http://tinyurl.com/be6eel3
• [2] http://www.ted.com/talks/ben_goldacre_battling_bad_science.html
• [3] http://levlafayette.com/node/383
• [4] http://www.eyrie.org/~eagle/journal/2013-01/021.html
• [5] http://www.sorced.com/2012/03/penance-driven-development.html
• [6] http://cainesarcade.com/
• [7] http://www.imagination.is/
• [8] http://tanguy.ortolo.eu/blog/article93/usb-udf
• [9] http://www.ted.com/talks/bruce_schneier.html
• [10] http://www.youtube.com/watch?v=8SAWKDRHZuw
• [11] http://www.schneier.com/blog/archives/2013/01/the_eavesdroppi.html
• [12] http://www.eyrie.org/~eagle/journal/2013-01/026.html
• [13] http://blog.ted.com/2013/01/29/10-places-where-anyone-can-learn-to-code/
• [14] http://tinyurl.com/q2vl2fv
• [15] http://tinyurl.com/awtv7ka
• [16] http://securityblog.org/2013/02/11/security-anti-pattern-mobile-hypervisors/

like last week, I was working on the preparation of the Perl 5.18 transition. besides that I also uploaded some RC bug fixes, mostly by taking patches that came from Ubuntu (kudos!):

• #683512 biogenesis: "biogenesis: Transition package to use default java implementation"
  apply patch from Ubuntu / James Page, upload to DELAYED/2
• #683519 bytecode: "bytecode: Transition package to default java implementation"
  apply patch from Ubuntu / James Page, upload to DELAYED/2
• #683522 coco-java: "coco-java: Transition package to use default java implementation"
  apply patch from Ubuntu / James Page, upload to DELAYED/2
• #683525 collectd: "collectd: Transition package to use default java implementation"
  apply patch from Ubuntu / James Page, upload to DELAYED/2
• #683543 jasmin-sable: "jasmin-sable: Transition package to default java implementation"
  apply patch from Ubuntu / James Page, upload to DELAYED/2, then uploaded by maintainer
• #683550 jfractionlab: "jfractionlab: Transition package to default java implementation; fix java7 compatibility"
  apply patch from Ubuntu / James Page, upload to DELAYED/2
• #684154 libusb-java: "libusb-java: Transition package to use default java implementation + java 7 compatibility"
  apply patch from Ubuntu / James Page, upload to DELAYED/2
• #684155 mockito: "mockito: Drop BD on openjdk-6-jdk"
  apply patch from Ubuntu / James Page, upload to DELAYED/2
• #684162 neobio: "neobio: Transition package to default java implementation"
  apply patch from Ubuntu / James Page, upload to DELAYED/2
• #684378 x11vnc: "x11vnc: Transition package to use default java implementation"
  apply patch from Ubuntu / James Page, upload to DELAYED/2
• #708766 libimager-qrcode-perl: "libimager-qrcode-perl: Update for newer libimager-perl needed"
  upload with my patch from last week to DELAYED/2
• #708840 src:owl: "owl: FTBFS: configure: error: No terminfo found for this system"
  upload with my patch from last week to DELAYED/2
• #709676 src:libapache-authenhook-perl: "libapache-authenhook-perl: FTBFS on i386: $Config ccflags lost"
  fix *FLAGS in debian/rules (pkg-perl)

as a side note (or better: question): why are the bugs for the upcoming Apache 2.4 and openjdk-7 transitions classified as 'serious', instead of as 'important', like the Perl 5.18 ones?

I usually try to avoid administering printers whenever possible. As a result I end of flailing around the CUPS web interface before I figure out how to re-enable a printer. And, when I get a call to help debug a printer, I can't easily tell people what to do. When I try to do what I need via the command line, I end up spending at least 10 or 15 minutes re-reading man pages before I piece together the steps. Here's my attempt to document the steps so I don't have to re-read man pages. Setup In these examples, the printer name in question is: stability and it is a network printer, with local DNS that properly resolves the hostname stability to an IP address. The cups commands in these examples can be run as a non-root user if that user is in the lpadmin group. Type:

groups

To see if lpadmin is listed. If not:

sudo adduser <your-user-name> lpadmin

Then, to gain access to the new group without logging out and logging in again:

newgrp lpadmin

Network access First, try to ping the printer:

ping stability

If this fails, restart the printer and/or check network cables. No point in doing anything else until it responds to pings. Can't submit new jobs to the printer Next, if the problem is that the printer is greyed out when you try to print a document or your application tells you that the printer is rejecting jobs, confirm this status with:

lpstat -a stability

It will either output:

stability accepting requests since Mon 20 May 2013 10:28:57 AM EDT

Or

stability not accepting requests since Mon 20 May 2013 10:28:57 AM EDT -
  Rejecting Jobs

If it is rejecting jobs, try:

/usr/sbin/cupsaccept stability

Accepts new jobs, but just doesn't print On the other hand, if the printer is accepting jobs, but the jobs are not printing, find out if the printer is enabled with:

lpstat -p stability

You should get either:

printer stability is idle.  enabled since Mon 20 May 2013 10:28:57 AM EDT

Or:

printer stability disabled since Mon 20 May 2013 10:35:10 AM EDT -
  Paused

If it is disabled, you should first see what queued jobs there are:

lpq

If you have a list of duplicate pending jobs, be sure to delete the duplicates to avoid having your print job come out multiple times. To delete a queued job, type the following (n should be the number in the Job column of the lpq output):

cancel <n>

After you have deleted duplicate jobs, try "enabling" it:

/usr/sbin/cupsenable stability

Then, re-rerun the lpq command and see if it's now "ready." At this point, the jobs should start printing. Review of concepts For review... a few important concepts:

• cupsaccept/cupsreject: controls whether a printer will accept or reject new jobs. It doesn't matter whether the printer is enabled or disabled.
• cupsenable/cupsdisable: controls whether a printer will print existing jobs. It doesn't matter whether the print is accepting or rejecting new jobs.

I use RSS feeds to keep up with academic journals. Because of an undocumented and unexpected feature (bug?) in my (otherwise wonderful) free software newsreader NewsBlur, many articles published over the last year were marked as having been read before I saw them. Over the last week, I caught up. I spent hours going through abstracts and downloading papers that looked interesting or relevant to my research. Because I did this for hundreds of articles, it gave me an unusual opportunity to reflect on my journal reading practices in a systematic way. On a number of occasions, there were potentially interesting articles in non-open access journals that neither MIT nor Harvard subscribes to and that were otherwise not accessible to me. In several cases where the research was obviously important to my work, I made an interlibrary request, emailed the papers authors for copies, or tracked down a colleague at an institution with access. Of course, articles that look potentially interesting from the title and abstract often end up being less relevant or well executed on closer inspection. I tend to cast a wide net, skim many articles, and put them aside when it s clear that the study is not for me. This week, I downloaded many of these possibly relevant papers to, at least, give a skim. But only if I could download them easily. On three or four occasions, I found inaccessible articles at this margin of relevance. In these cases, I did not bother trying to track down the articles. Of course, what appear to be marginally relevant articles sometimes end up being a great match for my research and I will end up citing and building on the work. I found several suprisingly interesting papers last week. The articles that were locked up have no chance at this. When people suggest that open access hinders the spread of scholarship, a common retort is that the people who need the work have or can finagle access. For the papers we know we need, this might be true. As someone with access to two of the most well endowed libraries in academia who routinely requests otherwise inaccessible articles through several channels, I would have told you, a week ago, that locked-down journals were unlikely to keep me from citing anybody. So it was interesting watching myself do a personal cost calculation in a way that sidelined published scholarship and that open access publishing would have prevented. At the margin of relevance to ones research, open access may make a big difference.

I love maps something that became clear to me when I was looking at the tag cloud of my bookmarks a few years back. One of my favorite blogs (now a book) is Frank Jabobs Strange Maps. So it s no coincidence that a number of my favorite MIT Mystery Hunt puzzles are map based. Trying to connect the two worlds, I sent Jacobs a write-up of the hunt and of a particularly strange sound-based map puzzle called White Noise that I worked with Don Armstrong to solve in the 2006 hunt. While I wasn t paying attention, Jacobs did a very nice writeup of my writeup of the puzzle for Strange Maps!

Well, I put out crappy predictions for Google IO related to Android. So here are my crappy predictions for Appengine:

• PHP runtime support - 95% (I would not have guessed this 3 weeks ago)
• Memory increase for at least python - 50%
• Instance hour price cut - 40%
• Premium memcache pricing - 10%
• Python 3 support - 5%

It should be obvious, but I really have no clue what Appengine related things could be announced. If PHP is not there then the Appengine team deserves some applause for their slight of hand. The rest is mostly my wishlist :)

I don't work at Google, so I can play to Google IO prediction game. Here are my Android predictions:

1. New android version -- 99%
2. New Nexus 7 -- 90%
3. Upgraded storage on the Nexus 4 -- 70%
4. T-mobile LTE for Nexus 4 -- 40%
5. AT&T LTE for Nexus 4 -- 30%
6. Verizon Nexus 4 -- 15%

So I think that means there is a (0.99 * 0.9 * 0.7 * 0.4 * 0.3 * 0.15) a 1% chance of all of these things happening.

This post was written with Andr s Monroy-Hern ndez. It is a summary of a paper just published in American Behavioral Scientist. You can also read the full paper: The remixing dilemma: The trade-off between generativity and originality. It is part of a series of papers I have written with Monroy-Hern ndez using data from Scratch. You can find the others on my academic website.

Remixing the reworking and recombination of existing creative artifacts represents a widespread, important, and controversial form of social creativity online. Proponents of remix culture often speak of remixing in terms of rich ecosystems where creative works are novel and highly generative. However, examples like this can be difficult to find. Although there is a steady stream of media being shared freely on the web, only a tiny fraction of these projects are remixed even once. On top of this, many remixes are not very different from the works they are built upon. Why is some content more attractive to remixers? Why are some projects remixed in deeper and more transformative ways?

We try to shed light on both of these questions using data from Scratch a large online remixing community. Although we find support for several popular theories, we also present evidence in support of a persistent trade-off that has broad practical and theoretical implications. In what we call the remixing dilemma, we suggest that characteristics of projects that are associated with higher rates of remixing are also associated with simpler and less transformative types of derivatives.

Our study is focused on two interrelated research questions. First, we ask why some projects shared in remixing communities are more or less generative than others. Generativity a term we borrow from Jonathan Zittrain describes creative works that are likely to inspire follow-on work. Several scholars have offered suggestions for why some creative works might be more generative than others. We focus on three central theories:

1. Projects that are moderately complicated are more generative. The free and open source software motto release early and release often suggests that simple projects will offer more obvious opportunities for contribution than more polished projects. That said, projects that are extremely simple (e.g., completely blank slates) may also uninspiring to would-be contributors.
2. Projects by prominent creators are more generative. The reasoning for this claim comes from the suggestion that remixing can act as a form of cultural conversation and that the work of popular creators can act like a common medium or language.
3. Projects that are remixes themselves are more generative. The reasoning for this final claim comes from the idea that remixing thrives through the accumulation of contributions from groups of people building on each other s work.

Our second question focuses on the originality of remixes and asks when more or less transformative remixing occurs. For example, highly generative projects may be less exciting if the projects produced based on them are all near-identical copies of antecedent projects. For a series of reasons including the fact that increased generativity might come by attracting less interested, skilled, or motivated individuals we suggest that each of the factors associated with generativity will also be associated with less original forms of remixing. We call this trade-off the remixing dilemma. We answer both of our research questions using a detailed dataset from Scratch, where young people build, share, and collaborate on interactive animations and video games. The community was built to support users of the Scratch programming environment, a desktop application with functionality similar to Flash created by the Lifelong Kindergarten Group at the MIT Media Lab. Scratch is designed to allow users to build projects by integrating images, music, sound, and other media with programming code. Scratch is used by more than a million users, most of them under 18 years old. To test our three theories about generativity, we measure whether or not, as well as how many times, Scratch projects were remixed in a dataset that includes every shared project. Although Scratch is designed as a remixing community, only around one tenth of all Scratch projects are ever remixed. Because more popular projects are remixed more frequently simply because of exposure, we control for the number of times each project is viewed. Our analysis shows at least some support for all three theories of generativity described above. (1) Projects with moderate amounts of code are remixed more often than either very simple or very complex projects. (2) Projects by more prominent creators are more generative. (3) Remixes are more likely to attract remixers than de novo projects. To test our theory that there is a trade-off between generativity and originality, we build a dataset that includes every Scratch remix and its antecedent. For each pair, we construct a measure of originality by comparing the remix to its antecedent and computing an edit distance (a concept we borrow from software engineering) to determine how much the projects differ. We find strong evidence of a trade-off: (1) Projects of moderate complexity are remixed more lightly than more complicated projects. (2) Projects by more prominent creators tend to be remixed in less transformative ways. (3) Cumulative remixing tends to be associated with shallower and less transformative derivatives. That said, our support for (1) is qualified in that we do not find evidence of the increased originality for the simplest projects as our theory predicted. We feel that our results raise difficult but important challenges, especially for the designers of social media systems. For example, many social media sites track and display user prominence with leaderboards or lists of aggregate views. This technique may lead to increased generativity by emphasizing and highlighting creator prominence. That said, it may also lead to a decrease in originality of the remixes elicited. Our results regarding the relationship of complexity to generativity and originality of remixes suggest that supporting increased complexity, at least for most projects, may have fewer drawbacks. As supporters and advocates of remixing, we feel that although highly generative works that lead to highly original derivatives may be rare and difficult for system designers to support, understanding remixing dynamics and encouraging these rare projects remain a worthwhile and important goal. Benjamin Mako Hill, Massachusetts Institute of Technology
Andr s Monroy-Hern ndez, Microsoft Research For more, see our full paper, The remixing dilemma: The trade-off between generativity and originality. Published in American Behavioral Scientist. 57-5, Pp. 643 663. (Official Link, Pay-Walled ).

Shared Memory Fences In our last adventure, dri3k first steps, one of the future work items was to deal with synchronization between the direct rendering application and the X server. DRI2 handles this by performing a round trip each time the application starts using a buffer that was being used by the X server. As DRI3 manages buffer allocation within the application, there s really no reason to talk to the server, so this implicit serialization point just isn t available to us. As I mentioned last time, James Jones and Aaron Plattner added an explicit GPU serialization system to the Sync extension. These SyncFences serializing rendering between two X clients, but within the server there are hooks provided for the driver to use hardware-specific serialization primitives. The existing Linux DRM interfaces queue rendering to the GPU in the order requests are made to the kernel, so we don t need the ability to serialize within the GPU, we just need to serialize requests to the kernel. Simple CPU-based serialization gating access to the GPU will suffice here, at least for the current set of drivers. GPU access which is not mediated by the kernel will presumably require serialization that involves the GPU itself. We ll leave that for a future adventure though; the goal today is to build something that works with the current Linux DRM interfaces. SyncFence Semantics The semantics required by SyncFences is for multiple clients to block on a fence which a single client then triggers. All of the blocked clients start executing requests immediately after the trigger fires. There are four basic operations on SyncFences:

• Trigger. Mark the fence as ready and wake up all waiting clients
• Await. Block until the fence is ready.
• Query. Retrieve the current state of the fence.
• Reset. Unset the fence; future Await requests will block.

SyncFences are the same as Events as provided by Python and other systems. Of course all of the names have been changed to keep things interesting. I ll call them Fences here, to be consistent with the current X usage. Using Pthread Primitives One fact about pthreads that I recently learned is that the synchronization primitives (mutexes, barriers and semaphores) are actually supposed to work across process boundaries, if those objects are in shared memory mapped by each process. That seemed like a great simplification for this project; allocate a page of shared memory, map into the X server and direct rendering application and use the existing pthreads APIs. Alas, the pthread objects are architecture specific. I m pretty sure that when that spec was written, no-one ever thought of running multiple architectures within the same memory space. I went and looked at the code to check, and found that each of these objects has a different size and structure on x86 and x86_64 architectures. That makes it pretty hard to use this API within X as we often have both 32- and 64- bit applications talking to the same (presumably 64-bit) X server. As a last resort, I read through a bunch of articles on using futexes directly within applications and decided that it was probably possible to implement what I needed in an architecture-independent fashion. Futexes Linux Futexes live in this strange limbo of being a not-quite-public kernel interface. Glibc uses them internally to implement locking primitives, but it doesn t export any direct interface to the system call. Certainly they re easy to use incorrectly, but it s unusual in the Linux space to have our fundamental tools locked away for our own safety . Fortunately, we can still get at futexes by creating our own syscall wrappers.

static inline long sys_futex(void *addr1, int op, int val1,
                 struct timespec *timeout, void *addr2, int val3)
 
    return syscall(SYS_futex, addr1, op, val1, timeout, addr2, val3);
 

For this little exercise, I created two simple wrappers, one to block on a futex:

static inline int futex_wait(int32_t *addr, int32_t value)  
    return sys_futex(addr, FUTEX_WAIT, value, NULL, NULL, 0);
 

and one to wake up all futex waiters:

static inline int futex_wake(int32_t *addr)  
    return sys_futex(addr, FUTEX_WAKE, MAXINT, NULL, NULL, 0);
 

Atomic Memory Operations I need atomic memory operations to keep separate cores from seeing different values of the fence value, GCC defines a few such primitives and I picked _syncboolcompareandswap and _syncvalcompareandswap. I also need fetch and store operations that the compiler won t shuffle around:

#define barrier() __asm__ __volatile__("": : :"memory")
static inline void atomic_store(int32_t *f, int32_t v)
 
    barrier();
    *f = v;
    barrier();
 
static inline int32_t atomic_fetch(int32_t *a)
 
    int32_t v;
    barrier();
    v = *a;
    barrier();
    return v;
 

If your machine doesn t make these two operations atomic, then you would redefine these as needed. Futex-based Fences These wake-all semantics of Fences greatly simplify reasoning about the operation as there s no need to ensure that only a single thread runs past Await, the only requirement is that no threads pass the Await operation until the fence is triggered. A Fence is defined by a single 32-bit integer which can take one of three values:

• 0 - The fence is not triggered, and there are no waiters.
• 1 - The fence is triggered (there can be no waiters at this point).
• -1 - The fence is not triggered, and there are waiters (one or more).

With those, I built the fence operations as follows. Here s Await:

int fence_await(int32_t *f)
 
    while (__sync_val_compare_and_swap(f, 0, -1) != 1)  
        if (futex_wait(f, -1))  
            if (errno != EWOULDBLOCK)
                return -1;
         
     
    return 0;
 

The basic requirement that the thread not run until the fence is triggered is met by fetching the current value of the fence and comparing it with 1. Until it is signaled, that comparison will return false. The compareandswap operation makes sure the fence is -1 before the thread calls futex_wait, either it was already -1 in the case where there were other waiters, or it was 0 before and is now -1 in the case where there were no waiters before. This needs to be an atomic operation so that the fence value will be seen as -1 by the trigger operation if there are any threads in the syscall. The futex_wait call will return once the value is no longer -1, it also ensures that the thread won t block if the trigger occurs between the swap and the syscall. Here s the Trigger function:

int fence_trigger(int32_t *f)
 
    if (__sync_val_compare_and_swap(f, 0, 1) == -1)  
        atomic_store(f, 1);
        if (futex_wake(f) < 0)
            return -1;
     
    return 0;
 

The atomic compareandswap operation will make sure that no Await thread swaps the 0 for a -1 while the trigger is changing the value from 0 to 1; either the Await switches from 0 to -1 or the Trigger switches from 0 to 1. If the value before the compareandswap was -1, then there may be threads waiting on the Fence. An atomic store, constructed with two memory barriers and a regular store operation, to mark the Fence triggered is followed by the futex_wake call to unblock all Awaiting threads. The Query function is just an atomic fetch:

int fence_query(int32_t *f)
 
    return atomic_fetch(f) == 1;
 

Reset requires a compareandswap so that it doesn t disturb things if the fence has already been reset and there are threads waiting on it:

void fence_reset(int32_t *f)
 
    __sync_bool_compare_and_swap(f, 1, 0);
 

A Request for Review Ok, so we ve all tried to create synchronization primitives only to find that our obvious implementations were full of holes. I d love to hear from you if you ve identified any problems in the above code, or if you can figure out how to use the existing glibc primitives for this operation.

Time to finally release three months of work! This is a very large feature release for the multifactor support in WebAuth and for the integration with the user information service, which is the way that WebAuth interacts with local site policy. (Currently, you still have to write your own to a well-defined protocol, although we do hope to provide Perl modules to help with this in the future.) The major driving motivation for this release is to add the infrastructure required to set long-lived persistent cookies in a browser that contribute factors to authentications, which allows WebAuth to support "remember this device" functionality and to only require multifactor from devices from which a user has not previously authenticated. This includes a new token type, new attributes the user information service can send (including a way to invalidate such tokens), and new data that's sent back to the user information service. The user information service also now has the ability to add arbitrary additional factors to the current authentication, something that is intended to provide a hook for a local help desk to bypass multifactor for a user for some time if required. This release also contains substantial contributions by Benjamin Coddington at UVM to improve multifactor interactions, including sending the OTP type back to the user information service if WebLogin knows it, a mechanism for the user information service to communicate a message to the user that's displayed on the multifactor login page, opaque state that can be sent back and forth between WebLogin and the user information service, and the ability for the user information service to add specific authentication factors to the required set for a particular authentication. Other improvements in multifactor handling include the ability to set a lifetime on factors obtained via OTP login, a fix for a long-standing bug where an initial multifactor factor would satisfy a session requirement for random multifactor, and logging of even ignored errors when contacting the user information service. There are other changes too. This release touches almost every part of WebAuth. The change to WebAuthForceLogin in 4.4.0 was reverted since, on further consideration, the original semantics seemed more useful. Password change handling in WebLogin was fixed (it's been broken for some time). Apache 2.4 error logging for all modules is much improved, and mod_webauth and mod_webkdc now produce better error logs for all versions of Apache. And WebLogin now communicates password expiration times to its templates in seconds since epoch in addition to a pre-formatted English time for better localization support. William Orr contributed a new WebAuthLdapOperationalAttribute directive for mod_webauthldap that allows it to query operational attributes and include them in the environemnt. There are two backward-incompatible changes for WebLogin. First, WebAuth now supports a user checkbox indicating either to remember their login on that device or to not remember their login (local site templates can present it either way). However, proper implementation of this matching the normal expected wording of "remember me on this device" required changing the default, so a straight upgrade from an earlier version will result in no single sign-on. To preserve behavior, either a template change to add the checkbox (checked by default) or a configuration change are required. Second, support for getting password expiration times directly with remctl to a kadmin-remctl backend has been removed in favor of using data from the user information service by way of the WebKDC. Finally, I got to do a lot of cleanup of the API, fix diagosis of undef passed to Perl XS functions, and fixed a compilation error with Heimdal. You can get the latest release from the official WebAuth distribution site or from my WebAuth distribution pages.

na ir slavena ne tikai ar savu akmens m ri valsts zieme os, bat ar ar Di o nas Ugunsm ri apk rt visam s valsts Internetam, kas blo visu p c k rtas un iebremzina visu p r jo. Man pirm person g saskarsme ar o pakalpojumu notika jau anhajas lidost , kad tri vien izr d j s, ka valst blo ts ir ne tikai Facebook, bet ar Twitter, kas iev rojami apgr tin ja manas iesp jas tri un viegli apzi ot visus, ka es esmu v l joproj m esmu dz vs un vesels. P c p ris eksperimentiem izr d j s, ka, lai ar no telefona nav pieejama Google+ m jas lapa un nav lejupl d jama Google+ (un WhatsApp) programma uz Android, tom r, ja t s jau ir telefon , ie abi servisi turpina no telefona str d t. T p c es s ku rakst t ce ojuma piez mes Google+ un da as dienas p c ce ojuma s kuma man pat izdev s nokonfigur t If This Then That servisu, lai tas pa em manus Google+ ierakstus un uztaisa no tiem Twitter ierakstus (kas jau t l k pa citiem kan liem izplat s uz Facebook un Draugiem un ar par d s k ned as kopsavilkums aj blog ). Google+ ir savi plusi, bet ar savi m nusi. Galvenais m nuss, ko es aj ce ojum paman ju ir tas, ka Google+ Android aplik cij nav iesp jams sagatavot vair kus ierakstu melnrakstus (v lams katru ar savu geolok ciju) bez Interneta var rakst t tikai vienu ierakstu un t ieraksta GPS koordin tes b s t s kur viet p c tam Internets par d sies. Es jau uzrakst ju Googlei par o probl mu. Galvenais pluss Google plusam (no pun intended) ir Instant Upload ja bild t fotogr fijas ar Android telefonu, s fotogr fijas autom tiski tiks aug upiel d tas un par d sies jaun ieraksta izveides interfeis , kur t s var pievienot ierakstam ar vienu klik i bez jebk das gaid anas. Diem l tas nestr d ar norm laj m kamer m. Pagaid m Ta u es neb tu sts datori is, ja es nepam in tu uzlaust vai apiet o nelielo nas probl mu, ne? Visvienk r akais veids k apiet nas Lielo Ugunsm ru ir izmantot jebk du VPN, kas at auj ne tikai piek t VPN t kla resursiem, bet ar at auj laist visu trafiku caur o VPN savienojumu. dus VPN piesl gumus var nopirkt, vai (ja ir Linux serveris vai routeris rpus nas) izveidot pa am. Man gad jum tas bija ar vienu klik i iesl gts OpenVPN uz Fonera routera, kas st v man s m j s. Diem l na ir sav da. Blo to lapu, portu un protokolu saraksts main s gan da dos rajonos, gan ar atkar b no t vai Internets ir mob lais vai wifi vai ar piesl gumu, gan ar vienk r i no dienas dien . Liel da gad jumu blo to lietu sarakst iekr t ar VPN savienojumi. Bie i vien ar priv tie. Man kaut k ne iet, ka mana m jas IP adrese ir nas ugunsm ra sarakstos, ta u da reiz ar tam VPN pievienoties es nevar ju. Un t d s situ cij s, lai apskat tu k du YouTube video, atliek tikai viens, eni ls risin jums sshuttle! is eni lais r ks izveido ko l dz gu VPN savienojumam caur parasto SSH portu un protokolu. Uz lok l s ma nas ir nepiecie ams Python un root ties bas, bet uz servera ir vajadz gas tikai ties bas palaist Python programmas. sshuttle pats aizs ta sevi uz serveri un palai s tur, pat ie ifr un p rs ta visus savienojumus un ar DNS piepras jumus, ja vi am to paprasa. Var p rs t t konkr tus t klus vai visu trafiku. Un trums man pieredz tas ir bija pat tr ks par parasto VPN. Kopum Interneta blok de un t visp r gais l nums ir viens oti spec gs m nuss nai. Aizskrienot mazliet uz priek u st st jum pateik u, ka Hong Kong das probl mas nav tur Internets ir lielisks! L k t ds t zeris san ca

DRI3K First Steps Here s an update on DRI3000. I ll start by describing what I ve managed to get working and then summarize discussions that happened on the xorg-devel mailing list. Private Back Buffers One of the big goals for DRI3000 is to finish the job of moving buffer management out of the X server and into applications. The only thing still allocated by DRI2 in the X server are back buffers; everything else moved to the client side. Yes, I know, this breaks the GLX requirement for sharing buffers between applications, but we just don t care anymore. As a quick hack, I figured out how to do this with DRI2 today allocate our back buffers separately by creating X pixmaps for them, and then using the existing DRI2GetBuffersWithFormat request to get a GEM handle for them. Of course, now that all I ve got is a pixmap, I can t use the existing DRI2 swap buffer support, so for now I m just using CopyArea to get stuff on the screen. But, that works fine, as long as you don t care about synchronization. Handling Window Resize The biggest pain in DRI2 has been dealing with window resize. When the window resizes in the X server, a new back buffer is allocated and the old one discarded. An event is delivered to invalidate the old back buffer, but anything done between the time the back buffer is discarded and when the application responds to the event is lost. You can easily see this with any GL application today resize the window and you ll see occasional black frames. By allocating the back buffer in the application, the application handles the resize within GL; at some point in the rendering process the resize is discovered, and GL creates a new buffer, copies the existing data over, and continues rendering. So, the rendered data are never lost, and every frame gets displayed on the screen (although, perhaps at the wrong size). The puzzle here was how to tell that the window was resized. Ideally, we d have the application tell us when it received the X configure notify event and was drawing the frame at the new size. We thought of a cute hack that might do this; track GL calls to change the viewport and make sure the back buffer could hold the viewport contents. In theory, the application would receive the X configure notify event, change the viewport and render at the new size. Tracking the viewport settings for an entire frame and constructing their bounding box should describe the size of the window; at least it should describe the intended size of the window. There s at least one serious problem with this plan applications may well call glClear before calling glViewport, and as glClear does not use the current viewport, instead clearing the whole window, we couldn t use the viewport as an indication of the current window size. However, what this exercise did lead us to realize was that we don t care what size the window actually is, we only care what size the application thinks it is. More accurately, the GL library just needs to be aware of any window configuration changes before the application, so that it will construct a buffer that is not older than the application knowledge of the window size. I came up with two possible mechanisms here; the first was to construct a shared memory block between application and X server where the X server would store window configuration changes and signal the application by incrementing a sequence number in the shared page; the GL library would simply look at the sequence number and reallocate buffers when it changed. The problem with the shared memory plan was that it wouldn t work across the network, and we have a future project in mind to replace GLX indirect rendering with local direct rendering and PutImage which still needs accurate window size tracking. More about that project in a future post though X Events to the Rescue So, I decided to just have the X server send me events when the window size changed. I could simply use the existing X configure notify events, but that would require a huge infrastructure change in the application so that my GL library could get those events and have the application also see them. Not knowing what the application is up to, we d have to track every ChangeWindowAttributes call and make sure the event_mask included the right bits. Ick. Fortunately, there s another reason to use a new event we need more information than is provided in the ConfigureNotify event; as you know, the Swap extension wants to have applications draw their content within a larger buffer that can have the window decorations placed around it to avoid a copy from back buffer to window buffer. So, our new ConfigureNotify event would also contain that information. Making sure that ConfigureNotify event is delivered before the core ConfigureNotify event ensures that the GL library should always be able to know about window size changes before the application. Splitting the XCB Event Stream Ok, so I ve got these new events coming from the X server. I don t want the application to have to receive them and hand them down to the GL library; that would mean changing every application on the planet, something which doesn t seem very likely at all. Xlib does this kind of thing by allowing applications to stick themselves into the middle of the event processing code with a callback to filter out the events they re interested in before they hit the main event queue. That s how DRI2 captures Invalidate events, and it works , but using callbacks from the middle of the X event processing code creates all kinds of locking nightmares. As discussed above, I don t care when GL sees the configure events, as long as it gets them before the application finds about about the window size change. So, we don t need to synchronously handle these events, we just need to be able to know they ve arrived and then handle them on the next call to a GL drawing function. What I ve created as a prototype is the ability to identify specific events and place them in a separate event queue, and when events are placed in that event queue, to bump a sequence number so that the application can quickly identify that there s something to process. Making the Event Mask Per-API Instead of Per-Client The problem described above about using the core ConfigureNotify events made me think about how to manage multiple APIs all wanting to track window configuration. For core events, the selection of which events to receive is all based on the client; each client has a single event mask, and each client receives one copy of each event. Monolithic applications work fine with this model; there s one place in the application selecting for events and one place processing them. However, modern applications end up using different APIs for 3D, 2D and media. Getting those libraries to cooperate and use a common API for event management seems pretty intractable. Making the X server treat each API as a separate entity seemed a whole lot easier; if two APIs want events, just have them register separately and deliver two events flagged for the separate APIs. So, the new DRI3 configure notify events are created with their own XID to identify the client-side owner of the event. Within the X server, this required a tiny change; we already needed to allocate an XID for each event selection so that it could be automatically cleaned up when the client exited, so the only change was to use the one provided by the client instead of allocating one in the server. On the wire, the event includes this new XID so that the library can use it to sort out which event queue to stick the event in using the new XCB event stream splitting code. Current Status The above section describes the work that I ve got running; with it, I can run GL applications and have them correctly track window size changes without losing a frame. It s all available on the dri3 branches of my various repositories for xcb proto, libxcb, dri3proto and the X server. Future Directions The first obvious change needed is to move the configuration events from the DRI3 extension to the as-yet-unspecified new Swap extension (which I may rename as Present , as in please present this pixmap in this window ). That s because they aren t related to direct rendering, but rather to tracking window sizes for off-screen rendering, either direct, indirect or even with the CPU to memory. DRI3 and Fences Right now, I m not synchronizing the direct rendering with the CopyArea call; that means the X server will end up with essentially random contents as the application may be mid-way through the next frame before it processes the CopyArea. A simple XSync call would suffice to fix that, but I want a more efficient way of doing this. With the current Linux DRI kernel APIs, it is sufficient to serialize calls that post rendering requests to the kernel to ensure that the rendering requests are themselves serialized. So, all I need to do is have the application wait until the X server has sent the CopyArea request down to the kernel. I could do that by having the X server send me an X event, but I think there s a better way that will extend to systems that don t offer the kernel serialization guarantee. James Jones and Aaron Plattner put together a proposal to add Fences to the X Sync extension. In the X world, those offer a method to serialize rendering between two X applications, but of course the real goal is to expose those fences to GL applications through the various GL sync extensions (including GLARBsync and GLNVfence). With the current Linux DRI implementation, I think it would be pretty easy to implement these fences using pthread semaphores in a block of memory shared between the server and application. That would be DRI-specific; other direct rendering interfaces would use alternate means to share the fences between X server and application. Swap/Present The Second Extension By simply using CopyArea for my application presentation step, I think I ve neatly split this problem into manageable pieces. Once I ve got the DRI3 piece working, I ll move on to fixing the presentation issue. By making that depend solely on existing core Pixmap objects as the source of data to present, I can develop that without any reference to DRI. This will make the extension useful to existing X applications that currently have only CopyArea for this operation. Presentation of application contents occurs in two phases; the first is to identify which objects are involved in the presentation. The second is to perform the presentation operation, either using CopyArea, or by swapping pages or the entire frame buffer. For offscreen objects, these can occur at the same time. For onscreen, the presentation will likely be synchronized with the scanout engine. The second form will mean that the Fences that mark when the presentation has occurred will need to signaled only once the operation completes. A CopyArea operation means that the source pixmap is ready immediately after the Copy has completed. Doing the presentation by using the source pixmap as the new front buffer means that the source pixmap doesn t become ready until after the next swap completes. What I don t know now is whether we ll need to report up-front whether the presentation will involve a copy or a swap. At this point, I don t think so the application will need two back buffers in all cases to avoid blocking between the presentation request and the presentation execution. Yes, it could use a fence for this, but that still sticks a bubble in the 3D hardware where it s blocked waiting for vblank instead of starting on the next frame immediately. Plan of Attack Right now, I m working on finishing up the DRI3 piece:

• Replace the DRI2 buffer allocation kludge with actual local buffer allocation, mapping them into pixmaps using FD passing.
• Replace the DRI2 authentication scheme with having the X server open the DRI object, preparing it for rendering and passing it back to the application.
• Working on the XCB pieces to get the split event-queue stuff landed upstream.
• Implementing the Fencing stuff to correctly serialize access to the pixmap.

The first three seem fairly straight forward. The fencing stuff will involve working with James and Aaron to integrate their XSync changes into the server. After that, I ll start working on the presentation piece. Foremost there is figuring out the right name for this new extension; I started with the name Swap as that s the GL call it implements. However, Swap is quite misleading as to the actual functionality; a name more like Present might provide a better indication of what it actually does. Of course, Present is both a verb and a noun, with very different connotations. Suggestions on this most complicated part of the project are welcome!

I bought a ScanJet N6350 a few years back, in the belief that it would work. After all, you write free Linux drivers for all your printers, and when those printers are multifunctional printers with scanners, you do make sure the scanner bits of those printers work too. So it shouldn't be too hard to write a Linux driver for that scanner too, right? Apparently it is. For some reason that I can't imagine, you decided that my money is worth more than my stress levels.

• The HP ScanJet N6350 is a combination USB/network scanner. That's great; I don't need it to be right next to my laptop all the time. Having the ability to get it sent to me by email (as your product page claims it can do) reduces my workload. Unfortunately, what you didn't mention on the product page is that the scanner is pretty dumb; it does network, yes, but the only way in which it can send emails is by using some application running on a system on the other end of the network connection. That's pretty silly. It wouldn't be so bad, however, except...
• ... the system on the other end of the network connection has to be running Windows. That's right, you didn't write a Linux driver for some reason. You also didn't publish the network protocol, and even the USB connection seems undocumented. So I can't use Linux to scan my documents. It wouldn't be so bad, however, since I already have a Windows XP virtual machine lying around somewhere, mainly because there's this satellite navigation system builtin to my car that also requires it; I just installed your scanners oftware on that machine, and I can scan. Except...
• ... whenever an error occurs in the scanning process, the UI locks up completely. I can't retry the last page that I was trying to scan, and often I can't even save the document anymore, either; I have to rescan the whole document. That wouldn't be so bad, except...
• ... the ADF is total crap. If I put more than a few pages on the feeder, and they've got some horizontal folds in them (as is likely with snail mail that came out of an envelope), I'm very likely to end up with a paper jam, or with multiple pages sucked into the feeder at once, causing an error and a loss of my scanned document. That wouldn't be so bad, except...
• ... the process for finishing one scan and starting the next involves stopping and starting your whole scanning software, which takes a rather long time. As such, I'd prefer to just scan a whole stack of incoming snail mail in one go, and then use pdfsam to split up the PDF file. But then I have to babysit the scanning process so that I don't get any errors; but I fail at that about as often as I succeed, meaning, it usually takes a long time to get through the stack.

Dear HP, you suck. I fail to understand how the basic loss of functionality after a failed scan managed to get through your testing. I fail to understand why you think Linux users should be able to print, but not scan. And I especially fail to understand why I should waste my time with such an expensive device that can't even perform its basic functionality with more than 10% success rate.

On the weekend of April 20-21, Students for Free Culture is going to be holding its annual conference, FCX2013, at New York Law School in New York City. As a long-time SFC supporter and member, I am enormously proud to be giving the opening keynote address. Although the program for Sunday is still shaping up, the published Saturday schedule looks great. If previous years are any indication, the conference can serve as an incredible introduction to free culture, free software, wikis, remixing, copyright, patent and trademark reform, and participatory culture. For folks that are already deeply involved, FCX is among the best places I know to connect with other passionate, creative, people working on free culture issues. I ve been closely following and involved with SFC for years and I am particularly excited about the group that is driving the organization forward this year. If you will be in or near New York that weekend or if you can make the trip you should definitely try to attend. FCX2013 is pay what you can with a $15 suggested donation. You can register online now. Travel assistance especially for members of active SFC chapters may still be available. I hope to see you there!

Antonia came into the room. Where's Alieta? she asked. We don't know, replied Luda. It was true; we hadn't seen Alieta in quite some time, and we had no idea where she was. Antonia left. Varvara eyed me mischievously and said, You could call her. How? I asked. Touch the grandmother clock and you will figure it out. I touched the clock trepidly. Nothing happened. I opened my mouth to speak, but the word I had been about to say resonated in my mind as if spoken through a comb filter. I concentrated. Alieta, dozens of human-like voices sang over and over in different harmonies. I let go. What was that? I demanded. Clock, Varvara said dismissively. Come on, let's do laundry, Luda grunted. We carried our laundry out to the garage, which is where the washer and dryer lived. Alieta slipped in through one of the open garage doors, and surreptitiously pulled Varvara over for a whispered conversation. Antonia wandered in and squinted in Alieta's general direction. Luda quickly pulled Varvara in front of her. It's just Varvara, she announced. Antonia's eyes glazed over and she went back into the house. Alieta pursed her lips and studied the wall as if there might be some reflective object that had alerted her mother to her presence. Then she grabbed Varvara by the hand, pulled her over to push the buttons that closed the garage doors, and dragged her into the house. I watched the garage doors close. Then I watched the one on the left reverse direction. I opened my mouth to notify someone of this, but the doors reversed direction again, and proceeded to partially open and close as if possessed. I tried to hide behind Luda, without success. Now she was watching as well, as reality seemed to to shimmer and bend. The roof became arched, and there were loud mechanical noises as our environs transformed. When it finished, the place where the garage doors had been was now a wall of screens displaying video as you might encounter in a television store. More disconcertingly, we were in front of a railing which overlooked what appeared to be a car dealership showroom. Luda sucked in her breath. Benjamin Snow, you were into some serious shit, she muttered.