Wednesday 1st

At the G20 protests, Londoner Ian Tomlinson collapses and is attended to by the emergency services; Metropolitan Police claim "during this time a number of missiles - believed to be bottles - were being thrown at them". Tomlinson dies that evening.

Thursday 2nd

The Evening Standard reports that "police were bombarded with bricks, bottles and planks of wood" as they helped Tomlinson.

Saturday 4th

Postmortem of Tomlinson finds he died of a heart attack.

Monday 6th

The EC Data Retention Regulations 2009 comes into force requiring internet service providers to retain details of emails, internet phone calls and other web traffic.

Tuesday 7th

The Guardian publishes a video of a police officer assualting Tomlinson on 1st April.

Wednesday 8th

Twelve Pakistani students are arrested on suspicion of planning terror attacks over the Easter holiday weekend.

Thursday 9th

The Guardian publishes a second video of Tomlinson's assualt, contributing that no missiles were thrown.

Monday 13th

Police arrest 114 climate protestors on conspiracy to cause criminal damage at Nottingham power plant. [ref]

Tuesday 14th

A video of a seperate assualt at the G20 protests is published.

Thursday 16th

Police claim tourist's photography of transport-related buildings is "strictly forbidden" and demand the photos are deleted. [ref]

Friday 17th

A second postmortem of Iam Tomlinson finds the cause of death to be an abdominal haemorrhage. A policeman is interviewed under caution on suspicion of manslaughter. [ref]

Saturday 18th

The Times reveals MP Damian Green private emails were searched by the police using the keywords "Shami Chakrabarti" (director of Liberty) after his arrest last year.

Monday 20th

The Guardian reveals police intelligence was given to E.On before the Nottingham climate demonstration, including movements of protesters and their meetings.

Tuesday 21st

Another video of the Tomlinson assault is revealed showing his head hitting the pavement. The Independent Police Complaints Commission fails to obtain an injunction to prevent broadcast.

Wednesday 22nd

Nine Pakistani students arrested during anti-terror raids are released after 13 days without charge and are passed to UK Border Agency custody for deportation. [ref]

Monday 27th

Home Secretary Jacqui Smith announces that ISPs and telecoms companies will be asked to record usage "to track murderers and paedophiles" without a warrant. [ref]

Tuesday 28th

Emails are revealed of the Home Office asking Phorm, the behavioural targeted advertising service, whether they are falling outside the law. Home Office claim Phorm would be legal if consent is obtained and that "providers of goods and services need only ensure they are compliant with relevant legislation". [ref]

Wednesday 29th

The Guardian documents the friends of the 7/7 bombers were denied bail on secret evidence - "the appellant asked the judge the question: why are you sending me to prison? To which the judge replied: 'I cannot tell you that.'"

(The much-delayed part 2 in an ongoing series: shiny things in telepathy-glib) Over a year ago I explained my first major round of work on telepathy-glib, with which it could be used to implement D-Bus services. I started to write this post shortly after, but then got distracted by a bee or something; recent discussion about having a D-Bus binding in GLib has finally prompted me to finish it. The second major round of work on telepathy-glib dealt with implementing client code, and went sufficiently well that telepathy-qt4 (currently under development) uses essentially the same model. Again, while telepathy-glib is intended for Telepathy implementors, I think TpProxy's ideas are generically useful, particularly for "large" D-Bus APIs.

Some background: dbus-glib and libtelepathy

The life-cycle of a DBusGProxy (PD clipart credit: karderio and Andy)

The API provided by dbus-glib for client code is, er, rather less than ideal. The basic object is DBusGProxy, which has a few problems. There's one per interface, rather than one per object; this leads to a maze of twisty GObjects, all suspiciously similar. Our old client library, libtelepathy, got round this by subclassing DBusGProxy to make helper objects called TpChan, TpConn etc., which were simultaneously the proxy for the "main" interface (Channel, Connection etc.), and a factory for proxies for the other interfaces (like Channel.Type.Text and Channel.Interface.Password). This still wasn't ideal, but it was a start. If you use a DBusGProxy in any way after it has emitted the destroy signal, this is considered to be invalid use of the API, and dbus-glib asserts all over the place. We'd rather it didn't do that - remote objects becoming invalid is a fact of life, and if you don't immediately discard all your references to those objects, remote operations on them should just give you a runtime error. You have to be prepared to handle such runtime errors already, because any IPC call can fail at any time. The main API for calling methods uses varargs and is rather subtle. Notably, the calling convention for variant parameters (of D-Bus signature 'v') is not consistent with the calling convention for any other container. For any other container, for instance a GPtrArray *, you pass in a GPtrArray ** pointing to a GPtrArray * variable containing NULL; on success, a pointer to a new GPtrArray is written into that variable. For variant parameters, though, you must pass in a GValue * pointing to a zero-filled GValue, and the result will be written into that GValue. dbus-binding-tool generates thin wrappers around this method-calling API which provide type-safety, although they can't directly specify a non-default timeout. As for signals, before binding to a signal, you have to tell dbus-glib about its signature. This tells dbus-glib how it should push the signal arguments onto the C stack (in GObject terminology: how it should marshal them), to match the signature of the signal-handler function. The documentation claims that this isn't necessary for objects supporting the Introspect method, but that's untrue - on the other hand, if the documented behaviour actually happened, I would consider this to be a critical bug in dbus-glib, since it would enable remote objects to crash dbus-glib clients (by causing signal arguments to be pushed onto the stack in a way that does not match the signature of the signal handler). Of course, the signal-adding function takes varargs, and has to be called exactly once per signal per object. If you don't, dbus-glib asserts when you connect to the signal; if you call it twice, dbus-glib asserts anyway.

TpProxy TpProxy is a GObject subclass vaguely inspired by Python's dbus.proxy.ProxyObject. It isn't a subclass of DBusGProxy, which lets us encapsulate dbus-glib almost completely - in fact, all the references to DBusGProxy are in a separate header, proxy-subclass.h, only used by subclasses of TpProxy (as opposed to normal library API users). TpProxy instances are per-remote-object (per-object-path) like in dbus-python, rather than per-interface like in dbus-glib or QtDBus. As explained below, I believe that this is the most natural object mapping for D-Bus interfaces; in practice it tends to lead to clearer code for us, since one remote object often maps nicely to one UI element (of course, if your objects only have one interface, this approach is no better or worse than dbus-glib's). TpProxy provides support for the following common D-Bus things:

• Calling methods
• Connecting to signals
• Objects becoming invalid
• Objects with optional interfaces
• Extensibility

It doesn't currently provide any particular help with Properties - the Properties interface is just another interface as far as we're concerned. We find that, in practice, that's not a problem (even though we use D-Bus properties extensively). In telepathy-qt4 we basically reinvented TpProxy in C++, as Tp::DBusProxy. I've put in some comments below illustrating how the general ideas we used in TpProxy translate into a different object mapping.

Calling methods Method calls on TpProxy are done through auto-generated wrapper functions, much like DBusGProxy. These look something like this:

typedef void (*tp_cli_channel_callback_for_close) (TpChannel *proxy,
    /* any 'out' arguments would go here - Close() doesn't have any */
    const GError *error, gpointer user_data,
    GObject *weak_object);
TpProxyPendingCall *tp_cli_channel_call_close (TpChannel *proxy,
    gint timeout_ms,
    /* any 'in' arguments would go here - Close() doesn't have any */
    tp_cli_channel_callback_for_close callback,
    gpointer user_data,
    GDestroyNotify destroy,
    GObject *weak_object);

Methods for some interfaces, like DBus.Properties, are available on TpProxy itself; others, like Telepathy's Channel.anything, are only available on a particular subclass, like TpChannel. Things to note here:

• It's an asynchronous call with a callback. General design principle: "this is IPC, get over it". We don't try to hide the fact that IPC is taking place by doing pseudo-blocking calls.
• The timeout is explicit (although you can always pass -1 to let libdbus pick a "reasonable" default for you). This is because the remote service might not respond, and API users should be at least vaguely aware of this: "this is IPC, get over it".
• The callback isn't a GCallback; it has an explicit signature, for some semblance of type-safety (it's not much, but it's better than nothing).
• The callback takes a GError, because any IPC call can fail for any reason.
• A TpProxyPendingCall * is returned. This is a pointer to an object that only exists until just after the callback is called (so you can ignore it if you don't want it), with a method you can call to cancel the method call (with hindsight this is not ideal, and if I was writing this API now, I'd use gio's GCancellable). "Cancel" is perhaps slightly misleading: the method call still takes place (it was already in libdbus's outgoing queue) but the result gets ignored and the callback isn't called. This is mostly so you an object can forget all the calls it was busy making at the time that the results become irrelevant (e.g. the object is destroyed).
• There is an extra weak_object argument, which is weakly referenced and is passed to the callback: in practice, most users of telepathy-glib use this as well as or instead of user_data. If the weak_object runs out of references, the callback is automatically cancelled, which means that in practice, explicit cancellation is almost never needed.
• The generated code has as its first argument a suitable subclass of TpProxy, in this case TpChannel (we tell the code generator about subclasses).
• You can't see it in the API, but the TpProxy gains an extra ref while a method call is in progress, so you never have to worry about what happens if the proxy gets unreffed during a method call.
• There's an explicit destructor for the user_data, which is called even if you "cancel" the method call.

In telepathy-qt4, these methods are on small generated helper classes similar to dbus-python's dbus.Interface, one per interface (we provide accessors for them on the non-generated DBusProxy subclass). Instead of using callbacks, we return a temporary QObject per call, which emits a Qt signal on success or failure (that's how all async calls in QtDBus work).

Connecting to signals Similarly, signals have some generated functions:

typedef void (*tp_cli_channel_signal_callback_closed) (TpChannel *proxy,
    /* any arguments would go here - Closed doesn't have any */
    gpointer user_data, GObject *weak_object);
TpProxySignalConnection *tp_cli_channel_connect_to_closed (TpChannel *proxy,
    tp_cli_channel_signal_callback_closed callback,
    gpointer user_data,
    GDestroyNotify destroy,
    GObject *weak_object,
    GError **error);

API notes for these:

• The callback doesn't take a GError any more, because signals can't fail; the weak_object and the user_data are the same as for method calls
• This isn't actually a GObject signal at all: those aren't particularly typesafe, and lack namespacing. This might not be very binding-friendly, we haven't tried doing that yet... it might be worth introducing a signal with details, like in dbus-glib, for which these functions are "C bindings".
• The returned TpProxySignalConnection lets you disconnect from the signal, just like the TpProxyPendingCall above; it can safely be ignored
• Similarly, if the weak_object dies, then the signal automatically disconnects
• It is possible for connecting to a signal to fail: this happens if the proxy doesn't actually have the requested interface. If this happens, it's graceful, not a crash. In practice, the flow of code is almost always such that error can safely be NULL because the interfaces are already known.

In telepathy-qt4 the per-interface generated helper classes emit Qt signals. In many cases, we end up proxying these signals by responding to them in the hand-written Tp::DBusProxy subclass by emitting a different signal, in order to give them a nicer representation.

Becoming invalid This is IPC, and any error can happen to you at any time. We found that it was useful to have a general concept of "this object is no longer useful", so we introduced the concept of an object becoming invalidated. The invalidation reason is stored on the object as a GError. If this GError is NULL (as it is initially), then the object is still expected to be valid; if it's non-NULL, the remote object has vanished and the local proxy no longer works. There are several ways a TpProxy can become invalid:

• its bus name falls off the bus (the process exited or crashed)
• application-specific reasons (usually triggered by a D-Bus signal in a subclass, like the Telepathy Channel's Closed signal)
• the GObject gets disposed

Method calls on an invalidated object always fail, with the invalidation reason as the error. This means that calling a method on a TpProxy should never crash your process. The method's callback has to be prepared to handle an error in any case, because this is Sparta^WIPC, so there's no loss in giving it another error. Connecting to signals on an invalidated object always fails, and any existing signal connections are disconnected when it becomes invalidated. This means that if a new remote object appears, and it happens to have the same object path, bus name etc. as the old one, you won't get its signals. A TpProxy can either be bound to a unique bus name or a well-known bus name. In the equivalent code in telepathy-qt4, we call this "stateful" or "stateless" - these names don't capture the intention perfectly, but they're the best we could come up with. A proxy for a stateful API like Telepathy's Channel should always bind to a unique name - when the unique name falls off the bus, the TpProxy becomes invalidated automatically, representing the fact that the Channel you had no longer exists, and nothing can be a perfect replacement for it (the VoIP call has already been terminated, you've already left the chatroom, or whatever - if you make another Channel, that's e.g. a distinct VoIP call). A proxy for a stateless API like Telepathy's ConnectionManager, where an exiting process can disappear, be service-activated again, and still have exactly the same API, should bind to the well-known name. Proxies for well-known names aren't invalidated when the process exits. Qt doesn't have a natural equivalent for GError, so the invalidation reasons in telepathy-qt4 are just a pair of strings, the namespaced name and the message - basically a libdbus DBusError. The principle is the same, though.

Optional interfaces As mentioned above, TpProxy instances are per-remote-object (per-object-path) like in dbus-python, rather than per-interface like in dbus-glib or QtDBus. I believe that this is the most natural object mapping for the D-Bus object model, because the D-Bus interfaces on a remote object can behave like any of these:

• classes and subclasses (Telepathy.Channel.Type.Text is a Telepathy.Channel)
• shared interfaces (some Telepathy.Channel objects, of many Types, implement Telepathy.Channel.Interface.Group; any D-Bus object can implement DBus.Properties)
• optional features (some Telepathy.Channel.Type.Text objects implement Telepathy.Channel.Interface.ChatStates, some do not)
• discoverable extensions (some Telepathy.Channel.Type.Text objects implement Telepathy.Channel.Interface.Messages, which is more or less Text 2.0)

The way in which interfaces are discovered is also variable. The "classic" D-Bus way to discover interfaces would be to call Introspect. Telepathy services still support that style of introspection, but we don't use it for anything beyond d-feet:

• Introspect returns a blob of XML, which you have to parse into something useful; if it was in a D-Bus data structure, you'd already have some sensible data structure.
• Finding out more information about the supported interfaces than their names isn't very useful: in a static language like C you already need to know the methods, signals, properties and their signatures in order to write and compile your code, and in a dynamic language like Python consumers of Introspect end up being remotely crashable by services with unexpected method signatures (this is one of dbus-python's big mistakes in my opinion).
• If a method that you want to call turns out to be missing, the worst that can happen (in a competently written service) is that it fails with a D-Bus error - and you have to handle D-Bus errors anyway, because this is IPC and anything could fail.
• Static bindings like dbus-glib have poor support for removing interfaces for which C code exists at runtime, whereas Telepathy needs features like an IM connection that might or might not support avatars (we don't get to find out until we've successfully connected to the server).

Instead, our older interfaces have a method on the "base class" (Channel, Connection etc.) called GetInterfaces, which just returns an array of strings. Newer interfaces (like Account), and older interfaces that have been ported (like Channel), have a property called Interfaces which is, again, an array of strings - this lets us combine the download of the interfaces list with downloading other basic information in a GetAll call. To cater for all these ways to use interfaces, the TpProxy base class has very basic support for interface discovery - you can ask it whether it supports an interface, and you can tell it that it does, in fact, support an interface. Asking which interfaces are supported is directly useful for library users; it's also used as a check by the generated method-call and signal-connection stubs, which return a canned error (Telepathy.Error.NotImplemented in Telepathy's case) if the object isn't known to have the interface. Telling TpProxy that it does support an interface is intended for use by subclasses, and might have been protected if we were writing C++: what happens in practice is that a concrete subclass like TpChannel knows how to discover the fully supported interfaces for this particular object, does so, and calls methods on the TpProxy to tell it which interfaces can work.

Extensibility The API stubs used by TpProxy to call methods and bind to signals are generated from XML documents containing an augmented form of D-Bus introspection data. These XML documents contain various Telepathy-specific extensions, but none of the extensions are language-specific - telepathy-glib, telepathy-python and telepathy-qt4 all operate from exactly the same XML specification. telepathy-qt4's different object-mapping did require us to tighten up some rules that were previously only conventions, but even so, the format is the same. I think this is vitally important - it just doesn't scale to have one set of language-specific annotations in a D-Bus API for each language that will have bindings. One thing that we make heavy use of is what I call "Ugly_Case", which is camel-case with underscores at word boundaries. This gives us a simple, unambiguous and foolproof rule to use in code generators whenever we generate any of the popular conventions for identifiers:

• CamelCase: delete underscores
• javaCamelCase: force everything before the first underscore to lower case, then delete underscores
• lower_case: force everything to lower case, retain underscores
• UPPER_CASE: force everything to upper case, retain underscores

dbus-glib, by contrast, applies a complex and subtly buggy algorithm to the CamelCase D-Bus names, which results in our SendDTMF method being mapped into GLib as send_dt_mf, and requires that telepathy-glib's Python reimplementation of dbus-binding-tool uses a bug-for-bug compatible implementation (we ended up reimplementing dbus-binding-tool in order to generate the TpProxy-based bindings). Our code generation tools are still rather ad-hoc, because so is our spec format, but for draft interfaces it's possible to copy them into individual projects and use them to generate additional methods for TpProxy or any subclass. This is how we implement unfinished APIs like geolocation in Empathy, for instance. The Interfaces or GetInterfaces hook described above is entirely usable for these extension interfaces, and in fact that's how they're set up. In telepathy-qt4, the generated method stubs are genuine C++ methods, so we can't just append methods to an existing class: this is why we have one helper class per interface, so individual clients can generate a helper class for their particular version of an unfinished API, and instantiate an object of this class attached to a particular Tp::DBusProxy. When an interface becomes stable, it can be added to the set of interfaces for which code is generated in telepathy-glib or telepathy-qt4, at which point any client or service that was already using the final draft of that interface can easily be ported to the library version using sed (the API remains the same).

Becoming ready The concept of being "ready" does not directly exist in TpProxy, but is implemented in TpChannel, TpConnection and TpConnectionManager. The idea is that a freshly created proxy object isn't really fully usable yet - you have to connect to basic signals and recover the initial state of the remote object, as well as checking which extension interfaces are supported. In many well-designed D-Bus APIs you can do this initial setup with a few signal connections and a DBus.Properties.GetAll call. After doing that initial setup (which has to be done asynchronously, because it's IPC), the TpProxy subclass has a local cache of the remote object's state (not necessarily in the same format as the representation on the bus), which can be accessed synchronously at any time, and will be updated in response to change-notification signals. TpChannel and subclasses like it have explicit support for checking for readiness, and having a callback called when the object is ready or invalidated (whichever happens first). The "ready" property also supports the GObject notify signal. telepathy-qt4 took this concept and ran with it - there is library support for objects that can become ready, including a mixin. If I had as much time to work on telepathy-glib as I wish I had, this would be one of the first telepathy-qt4 features to be added to telepathy-glib.

Features becoming ready Going beyond that, in an extensible framework like Telepathy it's probable that not every client understands (or wants to understand) every feature of every object, so it's highly inefficient for every proxy object to subscribe to all the change notification signals and cache all the remote state on the off-chance that the library user wants them. In the API for TpContact (which is not actually a TpProxy for various reasons) we introduced the concept of optional features; telepathy-qt4 extended this idea throughout the library. The idea is that each library user knows which of the optional features are "interesting" to it, and makes a single asynchronous call (which expands into a series of D-Bus calls inside the library) to download the state for core functionality plus all of the selected features, and subscribe to change notification for all of those. This is another telepathy-qt4 thing that telepathy-glib still needs to catch up with; until someone works out how to make the clone() syscall apply to programmers, I fear all libraries are doomed to lag behind how their designers want them to look :-) (license: CC-BY-3.0 / LGPL-2.1+)

Dear readers, I m looking for a simple CMS, that would be usable by a non-programmer to write a simple website with less than 10 pages, not updated too frequently. Requirements:
- maintained/supported, but won t force me to upgrade for security reasons every month
- good wysiwyg editor (including positioning of images). Wiki-like markup is not an option.
- easy to learn, easy to use.
- doesn t look like a CMS or a blog for the visitors.
- usable by a non-programmer. Please suggest something that your parents would be able to use :-) Bonus points if:
- documentation available in french
- available as a Debian package
- doesn t expose many complex about publication workflow, user management, etc So, suggestions ?

Last few months since I got my EeePC have been a lot of fun. Playing and tweaking the little bastard is a joy in the end of a busy day. Besides, since I loaded it with the most useful SysAdmin tools, it became a powerful device in my tool belt . Unfortunately, I ve been stupid enough to drink a glass of orange juice while messing with it. I know, I know! Silly thing to do. I should know better! But life is like that I spilled a few drops over it. Of course, the web is pouring off information on what to do in cases like this, so I ll just summarize what I did:

1. Imediatelly, without thinking or questioning, I turned it upside down and removed the battery. It was a clumsy thing to do I ended up spilling the rest of my orange juice on the floor while worrying about the EeePC. Concearns about filesystem corruption (or whatever) crossed my mind, but I can always deal with that later First things first!
2. I went online in another computer and found out how to disassemble it. For me it was easy, since I got other two computers at home but if I needed to leave it there while looking for information, I would! If it s upside down and has no power whatsoever (the battery was removed), it s safe, I think. The information was easily found. I decided I didn t need to disassemble all of it, but having those information at hand was pretty useful.
3. I began by removing the keyboard. It s tricky but not difficult. The secret relies on the spring-mounted tabs near the screen. I checked for spills under it and cleaned with a cotton swab.
4. I was not very confortable to open the case, but I decided that turning it back on without checking the electronic parts first was too risky. So I said goodbye to my warranty and unscrewed the 6 screws from the bottom and the 9 from the silver casing under the keyboard.
5. There I found some little drops! Good decision to open it up! I dried it using cotton swabs again.
6. Before putting it all together, I decided to leave it open until the next day. I was pretty sure everything was dry again, but better safe than sorry . The next day I successfully assembled it and turned it on. Great! Everything worked fine.

Now that was just what worked for me. My EeePC is back, fully restored but, of course, the warranty is void :-( So I cannot recommend you to do the same. Best advice I can tell you: Keep liquids away your EeePC!

Do you use GPG or PGP to sign or encrypt your emails and/or files? This is a reminder to those who answered yes: make sure you have a revocation certificate, as well as backups of your private/public key pair, ideally in multiple safe locations. It s always a good idea to keep backups. But what is more important with GPG is the revocation certificate. That s your emergency brake. If someone ever gains control over your key, this is the only way for you to minimise (further) abuse of your key and your identity. However, even a revocation certificate won t be able to prevent all abuse, by nature of the design of the GPG Web of Trust. You also need to exercise utmost care in protecting your key and making sure third parties cannot gain control over it. Do not keep it on machines you don t trust, and make sure to use a safe, non-guessable passphrase! With GnuPG, generating a revocation certificate is as easy as this; replace $KEYID with your 8 or 16 digit hexadecimal key ID:

gpg --gen-revoke $KEYID > $KEYID.revoke.asc

and store it away. Do not import it until you need to revoke your key! In my case, the process was this; lines requiring my input are prefixed with an arrow ( ):

  sec  1024D/330C4A75 2001-06-20 Martin F. Krafft <mail@martin-krafft.net>
  Create a revocation certificate for this key? (y/N) y
  Please select the reason for the revocation:
    0 = No reason specified
    1 = Key has been compromised
    2 = Key is superseded
    3 = Key is no longer used
    Q = Cancel
  (Probably you want to select 1 here)
  Your decision? 1
  Enter an optional description; end it with an empty line:
  > 
  Reason for revocation: Key has been compromised
  (No description given)
  Is this okay? (y/N) y
  You need a passphrase to unlock the secret key for
  user: "Martin F. Krafft <mail@martin-krafft.net>"
  1024-bit DSA key, ID 330C4A75, created 2001-06-20
  ASCII armored output forced.
  Revocation certificate created.
  Please move it to a medium which you can hide away; if Mallory gets
  access to this certificate he can use it to make your key unusable.
  It is smart to print this certificate and store it away, just in case
  your media become unreadable.  But have some caution:  The print system of
  your machine might store the data and make it available to others!

I then printed the file, put it in the safe, stored it on a removable disk and hid it away. Even though I exercise great care over my key material, I can now sleep better at night, knowing that I can at least minimise any damage done by an attacker who compromises my key. Also, that way I can make sure to declare unused keys as such, since there is no other way to revoke a published key for which you ve lost the private key or forgotten its passphrase. I ve left such traces in my past and wish I had known what I was doing at the time: A8FA196E, C22D1C01, 1EF0975C. This is your chance to do it right. Make yourself a revocation certificate now (along with backups)! And always exercise care and keep your key secure. NP: Mono: One More Step and You Die

Call for papers: JITP-2010
The Politics of Open Source
May 6-7, 2010 - Amherst, Massachusetts Full Paper Submission Due Date: January 10, 2010 Approach
Free/Libre and Open Source Software (FOSS) has made significant advances, both technically and organizationally, since its emergence in the mid-1980s. Over the last decade, it has moved from a software development approach involving mostly volunteers to a more complex ecology where firms, nonprofit organizations, government agencies and volunteers may be involved. Moreover, the production paradigm continues to expand to other areas of digital content (e.g., Creative Commons, Wikipedia, Connexions, etc.). In this conference we use the phrase open source to capture this broader phenomenon. The Program Committee encourages disciplinary and interdisciplinary approaches to the study of open source, broadly defined. Politics in the conference title, can have many interpretations. Political issues closely tied to the free and open source software movement(s) include: national government policies related to the adoption of open source technologies or questions related to interoperability and open standards, software patents, vendor lock-in, and copyright. These are central themes we expect may be discussed in this forum. In this context, we welcome international submissions since differences in the political perspective appear in international contexts. However, topics related to how the concept of openness has led to various interpretations, adaptations, and applications of open source in other domains, and political issues that surround these broader innovations, are also welcome. Specific topics might include, but are not limited to: General topics related to the politics of open source:
+ How open source software or its principles are changing politics
+ Emerging transparencies in software, systems and society
+ Open source in the developing world and other international contexts
+ The political economy of open source
+ Digital divides and open source Open source and the public sector:
+ Open source software and transparency in government
+ Government policies toward open source and open standards
+ Regulation and open source Open source and democracy:
+ Open source and democratic engagement
+ Open source voting systems
+ Activism, political mobilization and open source The expansion of open source into other domains:
+ Understanding how open source collaboration works and how it can be extended into other areas of collective action
+ Policy areas, such as the effects of free textbooks on education policy or the politics of One Laptop Per Child
+ The political implications of open source in other cultural domains Keynote Speakers
We are pleased to confirm Eric von Hippel (MIT) and Clay Johnson (Sunlight Labs) as the daily keynote speakers for JITP-2010. Paper Submissions
Authors are invited to prepare and submit to JITP a manuscript following one of the six submission formats by January 10, 2010. These formats include research papers, policy viewpoints, workbench notes, review essays, book reviews, and papers on teaching innovation. The goal is to produce a special issue, or double issue, of JITP with a wide variety of approaches to the broad theme of The Politics of Open Source.

How to Submit
Everything you need to know about how to prepare and submit a strong JITP paper is documented at http://www.jitp.net/. Papers will be put through an expedited blind peer review process by the Program Committee, and authors will be notified about a decision by March 10, 2010. A small number of papers will be accepted for presentation at the conference. Other paper authors will be invited to present a poster during the Friday evening reception. All posters must include a YouTube version of their research findings. Best Paper and Poster Cash Prizes
The author (or authors) of the best research paper will receive a single $1,000 prize. The creator (or creators) of the best poster/research presentation will also receive a single prize of $1,000. Program Committee
M.V. Lee Badgett, University of Massachusetts Amherst
Paul M.A. Baker, Georgia Institute of Technology
Deborah Bryant, Oregon State University Open Source Lab
Andrea Calderaro, European University Institute
Mark Cassell, Kent State University
Edward Cherlin, Earth Treasury
Gabriella Coleman, New York University
Doug Downham, University of Massachusetts Amherst
Robert English, Daystar Computing & University of Massachusetts Amherst
Joseph Feller, University College Cork
Jelena Karanovic, Rutgers University
Dave Karpf, University of Pennsylvania/Miller Center for Public Affairs
Jeremy Hunsinger, Virginia Tech
Andrea Kavanaugh, Virginia Tech
Jose Marichal, California Lutheran University
Jens Hardings Perl, Pontificia Universidad Cat lica de Chile
Charlie Schweik, University of Massachusetts Amherst, co-chair
Stuart Shulman, University of Massachusetts Amherst, co-chair
Megan Squire, Elon University
Krishna Ravi Srinivas, Research Information System For Developing Nations
Louis Suarez-Potts, Sun Microsystems, Inc. & OpenOffice.org
Anas Tawileh, Cardiff University & Meedan.net

Call for papers: JITP-2010
The Politics of Open Source
May 6-7, 2010 - Amherst, Massachusetts Full Paper Submission Due Date: January 10, 2010 Approach
Free/Libre and Open Source Software (FOSS) has made significant advances, both technically and organizationally, since its emergence in the mid-1980s. Over the last decade, it has moved from a software development approach involving mostly volunteers to a more complex ecology where firms, nonprofit organizations, government agencies and volunteers may be involved. Moreover, the production paradigm continues to expand to other areas of digital content (e.g., Creative Commons, Wikipedia, Connexions, etc.). In this conference we use the phrase open source to capture this broader phenomenon. The Program Committee encourages disciplinary and interdisciplinary approaches to the study of open source, broadly defined. Politics in the conference title, can have many interpretations. Political issues closely tied to the free and open source software movement(s) include: national government policies related to the adoption of open source technologies or questions related to interoperability and open standards, software patents, vendor lock-in, and copyright. These are central themes we expect may be discussed in this forum. In this context, we welcome international submissions since differences in the political perspective appear in international contexts. However, topics related to how the concept of openness has led to various interpretations, adaptations, and applications of open source in other domains, and political issues that surround these broader innovations, are also welcome. Specific topics might include, but are not limited to: General topics related to the politics of open source:
+ How open source software or its principles are changing politics
+ Emerging transparencies in software, systems and society
+ Open source in the developing world and other international contexts
+ The political economy of open source
+ Digital divides and open source Open source and the public sector:
+ Open source software and transparency in government
+ Government policies toward open source and open standards
+ Regulation and open source Open source and democracy:
+ Open source and democratic engagement
+ Open source voting systems
+ Activism, political mobilization and open source The expansion of open source into other domains:
+ Understanding how open source collaboration works and how it can be extended into other areas of collective action
+ Policy areas, such as the effects of free textbooks on education policy or the politics of One Laptop Per Child
+ The political implications of open source in other cultural domains Keynote Speakers
We are pleased to confirm Eric von Hippel (MIT) and Clay Johnson (Sunlight Labs) as the daily keynote speakers for JITP-2010. Paper Submissions
Authors are invited to prepare and submit to JITP a manuscript following one of the six submission formats by January 10, 2010. These formats include research papers, policy viewpoints, workbench notes, review essays, book reviews, and papers on teaching innovation. The goal is to produce a special issue, or double issue, of JITP with a wide variety of approaches to the broad theme of The Politics of Open Source.

How to Submit
Everything you need to know about how to prepare and submit a strong JITP paper is documented at http://www.jitp.net/. Papers will be put through an expedited blind peer review process by the Program Committee, and authors will be notified about a decision by March 10, 2010. A small number of papers will be accepted for presentation at the conference. Other paper authors will be invited to present a poster during the Friday evening reception. All posters must include a YouTube version of their research findings. Best Paper and Poster Cash Prizes
The author (or authors) of the best research paper will receive a single $1,000 prize. The creator (or creators) of the best poster/research presentation will also receive a single prize of $1,000. Program Committee
M.V. Lee Badgett, University of Massachusetts Amherst
Paul M.A. Baker, Georgia Institute of Technology
Deborah Bryant, Oregon State University Open Source Lab
Andrea Calderaro, European University Institute
Mark Cassell, Kent State University
Edward Cherlin, Earth Treasury
Gabriella Coleman, New York University
Doug Downham, University of Massachusetts Amherst
Robert English, Daystar Computing & University of Massachusetts Amherst
Joseph Feller, University College Cork
Jelena Karanovic, Rutgers University
Dave Karpf, University of Pennsylvania/Miller Center for Public Affairs
Jeremy Hunsinger, Virginia Tech
Andrea Kavanaugh, Virginia Tech
Jose Marichal, California Lutheran University
Jens Hardings Perl, Pontificia Universidad Cat lica de Chile
Charlie Schweik, University of Massachusetts Amherst, co-chair
Stuart Shulman, University of Massachusetts Amherst, co-chair
Megan Squire, Elon University
Krishna Ravi Srinivas, Research Information System For Developing Nations
Louis Suarez-Potts, Sun Microsystems, Inc. & OpenOffice.org
Anas Tawileh, Cardiff University & Meedan.net

It s generally accepted that certain things need redundancy. RAID is generally regarded as essential for every server except for the corner case of compute clusters where a few nodes can go offline without affecting the results (EG the Google servers). Having redundant network cables with some sort of failover system between big switches is regarded as a good idea, and multiple links to the Internet is regarded as essential for every serious data-center and is gaining increasing acceptance in major corporate offices. Determining whether you need redundancy for a particular part of the infrastructure is done on the basis of the cost of the redundant device (in terms of hardware and staff costs related to installing it), the cost of not having it available, and the extent to which the expected down-time will be reduced by having some redundancy. It s also regarded as a good idea to have more than one person with the knowledge of how to run the servers, jokes are often made about what might happen if a critical person fell under a bus , but more mundane things such as the desire to take an occasional holiday or a broken mobile phone can require a backup person. One thing that doesn t seem to get any attention is redundancy in the machine used for system administration. I ve been using an EeePC [1] for supporting my clients, and it s been working really well for me. Unfortunately I have misplaced the power supply. So I need to replace the machine (if only for the time taken to find the PSU). I have some old Toshiba Satellite laptops, they are quite light by laptop standards (but still heavier than the EeePC) and they only have 64M of RAM. But as a mobile SSH client they will do well. So my next task is to set up a Satellite as a backup machine for my network support work. It seems that this problem is fairly widespread. I ve worked in a few companies with reasonably large sysadmin teams. The best managed one had a support laptop that was assigned to the person who was on-call outside business hours. That laptop was not backed up (to the best of my knowledge, it was never connected to the corporate LAN so it seems that no-one had an opportunity to do so) and there was no second machine. One thing I have been wondering is what happens to laptops with broken screens when the repair price exceeds the replacement cost. I wouldn t mind buying an EeePC with a broken screen if it comes with a functional PSU, I could use it as a portable server.

• [1] http://etbe.coker.com.au/2008/07/21/review-of-the-eeepc-701/

Quoting MSDN on the CSS "clip" property:

As of Internet Explorer 8, the required syntax of the clip attribute is identical to that specified in the Cascading Style Sheets (CSS), Level 2 Revision 1 (CSS2.1) specification; that is, commas are now required between the parameters of the rect() value.
...
In Internet Explorer 7 and earlier (and in Internet Explorer 8 or later in IE7 mode, EmulateIE7 mode, or IE5 mode), the commas should be omitted.

... and if you want to support both?I see a few options:

• Giving both rules, hoping that the browsers will just ignore one they can't parse (and not revert to no clipping) - untested
• Use Conditional Comments to use a "ie7fixes.css" file (works)
• Do not use clipping (the most commonly used solution)
• Ignore the existance of Internet Exploder 7 and just follow the CSS 2.1 standard (that's the way it should be)

This is primarily a bug-fix release, cleaning up a bunch of accumulated minor stuff. The largest single fix saves all the error output from tar in the various places that Lintian runs it and analyzes it to turn it into Lintian tags, which suppresses the occasional annoying record size messages from tar and should provide better handling of other tar problems. There are also fixes, several from Raphael Geissert, for various packages that failed in the lintian.d.o log. My tentative plan is for the next verison to be 2.3.0, incorporating more infrastructure work by Raphael Geissert to work towards getting rid of the separation between unpack and collection and make the data collection more fully dependency-driven. I'd also like to take another pass through the wishlist bugs and try to knock off a few more of them. I'm going to try to get 2.3.0 started and get up-to-date on merging major patches over the next couple of days, and then will probably take another break from Lintian work for a while to work on Policy (and on finishing the USEPRO RFC).

So, when I like something, I tend to yap about it for weeks and weeks. Take Icelandic Yogurt, for example. After re-discovering it a month ago, I went on a mini-binge (not a mega as it is too expensive) and spread the word to anyone who would listen. The stuff, especially with fun flavors like ginger and orange, just made my morning. Another fine fine thing out there is the performance group What We Know So Far who give performance-based lectures that mix intellectual insight with artistic flair. They put us regular academics to shame who are a bit more staid, to put it mildly. After seeing them a few weeks ago at the 3rd Ward, I snagged them to give a version of their A-mazing talk on Memes in my class and am organizing a much larger event at NYU for the fall of 2009. This is a sort of long winded way of announcing their up and coming show on April 27th the Hannah Complex, which entertains, among other topics, the nature of common sense: Can there be more than one common sense? they ask on their site. And I can t wait to hear the answer as this is a recurrent topic that anthropologists like to entertain. And in fact one of my favorite essays to teach is on this topic, Clifford Geertz Common Sense as Cultural System, a short excerpt which I found here and below is his thesis in a nutshell:

There are a number of reasons why treating common sense as a relatively organized body of considered thought, rather than just what anyone clothed and in his right mind knows, should lead on to some useful conclusions; but perhaps the most important is that it is an inherent characteristic of common-sense thought precisely to deny this and to affirm that its tenets are immediate deliverances of experience, not deliberated reflections upon it. Knowing that rain wets and that one ought to come in out of it, or that fire burns and one ought not to play with it (to stick to our own culture for the moment) are conflated into comprising one large realm of the given and undeniable, a catalog of in-the-grain-of-nature realities so peremptory as to force themselves upon any mind sufficiently unclouded to receive them. Yet this is clearly not so. No one, or no one functioning very well, doubts that rain wets; but there may be some people around who question the proposition that one ought to come in out of it, holding that it is good for one s character to brave the elements hatlessness is next to godliness. And the attractions of playing with fire often, with some people usually, override the full recognition of the pain that will result. Religion rests its case on revelation, science on method, ideology on moral passion; but common sense rests its on the assertion that it is not a case at all, just life in a nutshell. The world is its authority.

So, when I like something, I tend to yap about it for weeks and weeks. Take Icelandic Yogurt, for example. After re-discovering it a month ago, I went on a mini-binge (not a mega as it is too expensive) and spread the word to anyone who would listen. The stuff, especially with fun flavors like ginger and orange, just made my morning. Another fine fine thing out there is the performance group What We Know So Far who give performance-based lectures that mix intellectual insight with artistic flair. They put us regular academics to shame who are a bit more staid, to put it mildly. After seeing them a few weeks ago at the 3rd Ward, I snagged them to give a version of their A-mazing talk on Memes in my class and am organizing a much larger event at NYU for the fall of 2009. This is a sort of long winded way of announcing their up and coming show on April 27th the Hannah Complex, which entertains, among other topics, the nature of common sense: Can there be more than one common sense? they ask on their site. And I can t wait to hear the answer as this is a recurrent topic that anthropologists like to entertain. And in fact one of my favorite essays to teach is on this topic, Clifford Geertz Common Sense as Cultural System, a short excerpt which I found here and below is his thesis in a nutshell:

There are a number of reasons why treating common sense as a relatively organized body of considered thought, rather than just what anyone clothed and in his right mind knows, should lead on to some useful conclusions; but perhaps the most important is that it is an inherent characteristic of common-sense thought precisely to deny this and to affirm that its tenets are immediate deliverances of experience, not deliberated reflections upon it. Knowing that rain wets and that one ought to come in out of it, or that fire burns and one ought not to play with it (to stick to our own culture for the moment) are conflated into comprising one large realm of the given and undeniable, a catalog of in-the-grain-of-nature realities so peremptory as to force themselves upon any mind sufficiently unclouded to receive them. Yet this is clearly not so. No one, or no one functioning very well, doubts that rain wets; but there may be some people around who question the proposition that one ought to come in out of it, holding that it is good for one s character to brave the elements hatlessness is next to godliness. And the attractions of playing with fire often, with some people usually, override the full recognition of the pain that will result. Religion rests its case on revelation, science on method, ideology on moral passion; but common sense rests its on the assertion that it is not a case at all, just life in a nutshell. The world is its authority.

I was invited to talk about Free Software at yesterday's FLISOL. Yesterday? Aren't FLISOLs organized on Saturday? Well, not this one, for various reasons which I won't quote here. And no, I am not a supporter of the installfests idea, but I went gladly to talk about what is Free Software all about - The philosophy behind Free Software. Besides, the talk was at FES Iztacala, where I worked for four happy years, 1999-2003. I have not been often to Iztacala since 2003 (probably I have visited only three or four times), partly because of the distance (~25Km from home in a straight line, but the city's Northern part is quite poorly communicated). The last time I was there, last October, I went by bike, just to test my endurance and... because I could. Yesterday, I also did, not to be outdone by my fellow Debianers Christian and Dirk. Think they are so cool because they can run for 43Km? Well, I had my 55Km yesterday, and I was not even in a competition! (yes, yes, running and biking is not the same. So sue me. I just didn't want to stand still and let them walk away with all of the fun!) I took slightly different routes (my route to get there on Nokia Sportstracker and OpenStreetMap trace, my route back on Nokia Sportstracker and OpenStreetMap trace), crossing diagonally Azcapotzalco, a region of the city (delegaci n) I hardly know... The Sourthern of it seems like a continuation of Tacuba to the North, small and not-very-well-communicated prior villages engulfed by our hungry, huge city. The Northern half is a mostly industrial area, with very sparse population, lots of trucks, and streets that are not in the best shape. You can end up feeling lonely in those regions, and I am glad not to have crossed back by night. And the trip back was interesting as well... Mexico City is home to many more bikers you would expect given its size, and it is very common to find other people doing nice long stretches. In this case, I started cycling quite close to another guy in a white bike more or less when I got to Calzada Camarones. Possibly we had passed each other over and over until after Tlatelolco, arriving to Guerrero, where I approached him at a stoplight:
Hi! Where to?
Near Vocacional 7, Iztapalapa!
Nice! I'm just going to Copilco Every now and then we crossed each other... Turns out he does this ~30Km commute daily between Iztapalapa and Azcapotzalco. Quite admirable, to be honest. I also crossed my road with Sergio Mendoza, fellow Debianer (and co-administrator of our Mexican mirror) around Centro M dico (about 7Km north from my destination), whom I had only seen before around the University. Nice surprise. And yes, getting to know the city by bike is the best way to go! Back to the conference... my first thought when I was invited was to present Qu es el Software Libre?, a talk I have given over and over since... 2002 (although, yes, with updates). I must say it's one of the best structured talks I have prepared and has almost always been very successful - But give the same talk based on the same script over and over (AFAICT, around 20 times), and you will be fed up with it. And yes, yesterday I didn't take my laptop along, and didn't put my presentation on a USB stick - I took a pen and some paper, and during the presentation prior to mine, wrote some points to go over. And yes, it was a refreshing change. The talk was as successful as expected, and it's much more refreshing to talk about the same topics bot on a different way, and without being constrained to a predefined script. I know that organizing formally your ideas makes sure you don't miss out important points and that the audience is sometimes encouraged to pay attention by having some bullet points to look at - But on the other hand, it is much easier to follow your audience's interest if you are not bound by the script. And the few times I've spoken that way, it has felt refreshing and nice.

dput + mini-dinstall to ease people.d.o uploads As DDs we often want to offer unofficial packages, but still preserving a bit of "authoritativeness". A widespread solution is to upload somewhere under http://people.debian.org/~LOGIN as an APT repository. I've been using that solution too since ... ever, but I've never been happy about how to advertise the packages, probably just because I've never liked dpkg-scan packages,sources and hackish scripts built on top of them. My goal, as simple as it can be, is to work as I do to prepare "real" packages to be uploaded to the Debian archive, and just upload to people.d.o as the final step. Thanks to DSA which satisfied a request of mine by installing a while ago mini-dinstall on ravel, today I've finally set up a work-flow that enabled me to reach my goal. This post is a quick howto to implement that setup. If you have suggestions about where (wiki.d.o? devref?) to paste these info so that other DDs can more easily find them in the future, please let me know, via comments or mailing me. Step 1: configure mini-dinstall on people.debian.org On people.debian.org, create a ~/.mini-dinstall.conf file containing something like the following:

    [DEFAULT]
    mail_to = zack
    incoming_permissions = 0750
    architectures = all, i386, amd64
    archive_style = flat
    dynamic_reindex = 1
    archivedir = /home/zack/public_html/debian/
    generate_release = 1
    release_origin = Zack
    release_label = Zack
    release_description = Unofficial Debian packages maintained by Stefano Zacchiroli
    [zack-unstable]
    release_suite = zack-unstable

Highlights of that conf:

• "flat" archive style means "all in one dir", a more structured alternative is "simple-subdir"
• you request to generate a Release file, which is needed for the secure APT machinery; various fields of that file are specified by the release_* options
• you call your suite "zack-unstable" (well, I do ). That suite must match the distribution in your debian/changelog entries. In theory you can use legacy names such as "unstable", but as we are humans and we make mistakes, better to use invalid suite names that will be refused by dak if you upload to the wrong queue

The resulting repository will be accessible using the following /etc/apt/sources.list lines:

    deb http://people.debian.org/~zack/debian zack-unstable/
    deb-src http://people.debian.org/~zack/debian zack-unstable/

Step 2: configure dput The default incoming dir of mini-dinstall, relative to the configured archivedir, is mini-dinstall/incoming. The following entry for your ~/.dput.cf (on the machine you upload from) will therefore setup your dput for uploads:

    [people.debian.org]
    fqdn = people.debian.org
    method = scp
    login = *
    incoming = /home/zack/public_html/debian/mini-dinstall/incoming
    post_upload_command = ssh people.debian.org mini-dinstall -b

The only interesting detail here is the post upload command, which will run a "pulse" of mini-dinstall on people.d.o just after the upload, to process the uploaded file. Alternatively, you can leave mini-dinstall running on people.d.o, but I consider it unnecessary (because usually you are the only one able to upload to your home dir), unelegant, and complicated (because you then need to verify mini-dinstall is running). Step 3: enjoy (i.e., upload) Now you can prepare your packages as you always do (which means using cowbuilder!) and, when you are done with your foo_1.0-1_amd64.changes, upload it doing:

    $ dput people.debian.org foo_1.0-1_amd64.changes

Signing the Release file The above setup does not sign Release files, which means your APT users will receive complaints from the secure APT machinery. To fix that you must sign the Release file with some key and distribute the key to your users to be processed by apt-key add. You have a couple of ways to sign the release file automatically:

1. (/me doesn't like this) use a GPG key created for the occasion, store that key (including the private part) on people.d.o, and use the mini-dinstall contrib script sign-release.sh by adding something like the following to your mini-dinstall.conf:

     release_signscript = ~/bin/sign-release.sh
   
   

2. (/me likes this) use some script to sign the Release file remotely and send the resulting deatched signature back to people.d.o just after the mini-dinstall pulse; that way you can sign with your own private key, which will be reasonably felt as more trustworthy, being part of the Debian keyring. To achieve that, the most elegant way would be to fix debsign wishlist #465240 (volunteers? ). As I'm lazy, I'm using my own sign-remote script, which is a bit more generic. Remote signing should be attached to dput upload hook as well. All in all, here is my actual ~/.dput.cf stanza:

     [people.debian.org]
     fqdn = people.debian.org
     method = scp
     login = *
     incoming = /home/zack/public_html/debian/mini-dinstall/incoming
     post_upload_command = ssh people.debian.org "mini-dinstall --batch" && sign-remote people.debian.org:~/public_html/debian/zack-unstable/Release
   
   

Enjoy! Update: do both mini-dinstall run and signing in post_upload_command, following gregoa's suggestion via comment

For a very long time, I use mutt with emacsclient as configured editor and a single GNU Emacs instance started from either .screenrc or .Xsession, depending on the system. And I m very used to switching the virtual desktop or the screen window after starting a mail in mutt. Since Debian 5.0 Lenny and Emacs 22, Emacs automatically grabs the focus and switches to the right virtual desktop. So after telling mutt recipient and subject of a new e-mail, it invokes emacsclient and immediately the focus has moved to the running Emacs instance. Because I was used to switch one virtual desktop to the right at that point, I often found my self two desktops to the right until I got used to it. :-) I usually hate applications which grab the focus without being asked. But in this case I basically asked for it. And there s no delay like with starting up an application which has to read in some database first think of Liferea or Rhythmbox which take many seconds to minutes to start up, even on my 2.2 GHz dual core ThinkPad. In the meanwhile I got so used to that automatic desktop switch that I forget to switch the screen window in the second scenario where I use this combination: My screen doesn t automatically switch to the Emacs window (window 1) after I told mutt recepient and subject in window 2. Knowing that screen is quite scriptable, I found out that only a very small change is needed to my mutt configuration to get that desktop feature to my everyday screen session. I simply replaced the editor setting in my .muttrc with the following line:

set editor="screen -X select 1;emacsclient"

Now mutt tells screen to switch to window 1 (where Emacs is running) and then tells Emacs to open the appropriate file to edit my new mail. Update Friday, 2009-04-24, 18:22 Even though Zack surely is right with his comment about the multi-terminal feature of the upcoming GNU Emacs 23, I still have Etch (and therefore GNU Emacs 21) on the server where I have my screen session. So the next step was to switch back to the mutt window (window 2) after I m finished with editing the mail. Since mutt gives the the file to edit as argument to the contents of $editor, simply adding ;screen -X select 2 at the end of $editor doesn t suffice. So I wrote a small shell script (named ~/.mutt/editor.sh) as wrapper which calls all the commands and passes the parameters to the right command:

#!/bin/sh
screen -X select 1
emacsclient -a ~/.mutt/alteditor.sh "$@"
screen -X select 2

Of course, $editor is now set to that script:

set editor="/home/abe/.mutt/editor.sh"

Emacsclient of GNU Emacs 21 already supports the -a option to call another editor in case of not being able to connect to a running Emacs instance. Since I don t want to switch to another screen window in that case, I wrote a second shell script (named ~/.mutt/alteditor.sh) which switches back to the mutt window and then calls GNU Zile, my preferred low-end emacs clone:

#!/bin/sh
screen -X select 2
zile "$@"
screen -X select 1

I love it!

---

This is a continuation from before. I am digressing a little in this post. One of the things I want to get out of this exercise is to learn more about Ontologies and Ontology editors, and on the principle that you can never learn something unless you build something with it (aka bone knowledge), so this is gathering my thoughts to get started on creating an Ontology for package building. Perhaps this has been done before, and better, but I ll probably learn more trying to create my own. Also, I am playing around with code, an odd melange of my package building porcelain, and gitpkg, and other ideas bruited on IRC, and I don t want to blog about something that would be embarrassing in the long run if some of the concepts I have milling around turn out to not meet the challenge of first contact with reality. I want to create a ontology related to packaging software. It should be general enough to cater to the needs any packaging effort in a distribution agnostic and version control agnostic manner. It should enable us to talk about packaging schemes and mechanisms, compare different methods, and perhaps to work towards a common interchange mechanism good enough for people to share the efforts spent in packaging software. The ontology should be able to describe common practices in packaging, concepts of upstream sources, versioning, commits, package versions, and other meta-data related to packages. I am doing this ontology primarily for myself, but I hope this might be useful for other folks involved in packaging software. So, here follow a set of concepts related to packaging software, people who like pretty pictures can click on the thumbnail on the right:

• software is a general term used to describe a collection of computer programs, procedures and documentation that perform some tasks on a computer system.
• software is what we are trying to package
• software has names
• software may exist as
  • source code
  • executable code
  • packaged code
• source code is any collection of statements or declarations written in some human-readable computer programming language.
• source code is usually held in one or more text files (blobs).
• A large collection of source code files may be organized into a directory tree, in which case it may also be known as a source tree.
• The source code may be converted into an executable format by a compiler, or executed on the fly from the human readable form with the aid of an interpreter.
• executable format is the form software must be in in order to be run. Running means to cause a computer to perform indicated tasks according to encoded instructions.
• software source code has one or more lines of development. Some Common specific lines of development for the software to be packaged are:
  • upstream line of development
  • feature branch is a line of development related to a new feature under development. Often the goal is to merge the feature branches into the upstream line of development
  • usually, all feature branches are merged into the integration branch, and the package is created from the integration branch.
  • integration branch is the line of development of software that is to be packaged
• some software lines of development have releases
• releases have release dates
• some releases have release versions
• source code may be stored in a version control repository, and maintain history.
• Trees are a collection of blobs and other trees (directories and sub-directories). A tree object describes the state of a directory hierarchy at a particular given time.
• Blobs are simply chunks of binary data - they are the contents of files.
• a tree can be converted into an archive and back
• In git, directories are represented by tree object. They refer to blobs that have the contents of files (file name, access mode, etc is all stored in the tree), and to other trees for sub-directories.
• Commits (or changesets ) mark points in the history of a line of development, and references to parent commits.
• A commit refers to a tree that represents the state of the files at the time of the commit.
• HEAD is the most recent commit in a line of development or branch.
• A working directory is a directory that corresponds, but might not be identical, to a commit in the version control repository
• Commits from the version control system can be checked out into the working directory
• uncommitted changes are changes in the working directory that make it different from the corresponding commit. Some call the working directory to be in a dirty state.
• uncommited changes be checked in into the version control system, creating a new commit
• The working directory may contain a ignore file
• ignore file contains the names of files in the working directory that should be ignored by the version control system.
• In git, a commit may also contains references to parent commits.
  • If there is more than one parent commit, then the commit is a merge
  • If there are no parent commits, it is an initial commit
• references, or heads, or branches, are movable references to a commit. On a fresh commit, the head or branch reference is moved to the new commit.
• lines of development are usually stored as a branch in the version control repository.
• A new branch may be created by branching from an existing branch
• a patch is a file that contains difference listings between two trees.
• A patch file can be used to transform (patch) one tree into another (tree).
• A quilt series is a method of representing an integration branch as a collection of a series of patches. These patches can be applied in sequence to the upstream branch to produce the integration branch.
• A tag is a named reference to a specific commit, and is not normally moved to point to a different commit.
• A package is an archive format of software created to be installed by a package management system or a self-sufficient installer, derived by transforming a tree associated with an integration branch.
• packages have package names
• package names are related to upstream software names
• packages have package versions
• package versions may have
  • an upstream version component
  • a distribution or packaging specific component
• package versions are related to upstream software versions
• helper packages provide libraries and other support facilities to help compile an integration branch ultimately yielding a package

While I'm not a fan of cut-n-paste coding, on the odd occasion it's handy to grab a snippet of code out of someone else's blog and plop it in. Jeff Atwood of Coding Horror has a solution to some of the downsides of ripping a bit of code from somewhere on the Internet: publishers of code snippets generate a new GUID, tag each code snippet with a GUID, and you paste that comment in with the rest of the code when you take it. Then, if you (or someone else) needs to look at the context of the chunk of code, find it's author, look for improvements or commentary, or see who else has used that snippet in their own projects, you can search for that GUID and you should come up with only that GUID as a result.

What I propose is this:

// codesnippet:1c125546-b87c-49ff-8130-a24a3deda659
- (void)fadeOutWindow:(NSWindow*)window 
        // code
 

Attach a one line comment convention with a new GUID to any code snippet you publish on the web. This ties the snippet of code to its author and any subsequent clones. A trivial search for the code snippet GUID would identify every other copy of the snippet on the web:

http://www.google.com/search?q=1c125546-b87c-49ff-8130-a24a3deda659

How very, very cunning. He also proposes that if you modify a snippet and republish it, you should keep the old GUID and also add one of your own, so you can track the origin and help other people find your alternate version. Attaching unique identifiers to chunks of code and sending them all around the Internet. Does this sound like distributed revision control to anyone else? A lot easier to master than Git's UI, too...