Review: The Making of the Indebted Man, by Maurizio Lazzarato

Translator:	Joshua David Jordan
Publisher:	Semiotext(e)
Copyright:	2011, 2012
Printing:	2012
ISBN:	1-58435-115-2
Format:	Trade paperback
Pages:	199

This is a continuation of my effort to catch up on Marxist thought while pondering workplace governance, this time following the recommendations of a friend after a related conversation (about pension systems and basic income guarantee in a Usenet group Usenet isn't dead yet). As opposed to Democracy at Work, which is a popularization, The Making of the Indebted Man has more of the density of a scholarly text. The version I'm reading is also in translation, which I suspect makes it even harder going in places. The basic thesis, though, is clear: debt is far more central to the way that we construct not only economic systems but social systems and even internal models of our own nature than is often realized. We prefer to think of societies as structured around mutual exchange, but in practice they're more often constructed around concepts of debt and credit that have been fully internalized and used to construct a moral code for a responsible debtor. And this is not a neutral construction; rather, it is a key support mechanism of capitalism and of the financial and economic status quo, used (both intentionally and accidentally) to reduce uncertainty and to support exploitation and economic domination. This is one of those perspectives that didn't occur to me prior to reading this book but which is startlingly obvious in retrospect. Once Lazzarato starts pointing it out, the prevelance and universality of debt as a basic structure of social and economic life is striking. The creditor and debtor concept extends not just to obvious examples, such as consumer credit or mortgages, but also to education (via student loans), law enforcement ("pay one's debt to society"), employment (most employers, particularly during economic downturns, have successfully inverted the natural direction of the creditor relationship and have made employees feel in debt to the employer for having a job), and social services (unemployment and welfare benefits come with significant, if often unstated, debt-like requirements). Debt is also the great leveller. It now cuts across race, gender, and social class. Apart from a small handful of extremely rich individuals and corporations, Lazzarato claims, convincingly, that nearly everyone is enmeshed to some extent in a network of debt, or at least in in attitudes and moral pressures of a debtor. Nor is this a static situation. The role of debt in our social lives seems to be constantly increasing. The past fifteen years in particular have seen drastic increases in debt during a debt-funded economic boom combined with debt-funded asset bubbles. Even after the financial collapse, much of that growth of debt persists. Lazzarato, probably in part because he's Italian, focuses on national debt (more on that in a moment); as an American, I'd identify student loan debt as a more compelling example in the United States. Other countries probably have their own examples. For a system to be this widespread, it must serve some social purpose. Lazzarato sees it as an instrument of control. Debt has been very effectively built up as a moral obligation, and (unlike a society of mutual support) it's a very one-sided moral obligation that strongly favors existing power. The debtor is held to a tight moral standard of repayment of debts, and is morally condemned by all of society, including their peers, for a failure to repay. But there is little or no corresponding moral pressure on the creditor: perhaps a half-hearted dislike of high interest rates or occasional pressure to not change previously agreed terms, but nothing like the moral pressure applied to the debtor. To be a creditor is to have an agreed-upon, one-sided right to dictate to the debtor the terms on which they must conduct a portion of their life, and the larger the debt, the larger the portion. The debtor is expected to realign their life, at least in part, around paying off the debt, including choice of profession, decisions about when to quit a job, about how to prioritize personal spending, and so forth. This is all so automatic and so deeply ingrained that, even while writing this, I'm nodding along and thinking "well, of course." Lazzarato offers an opportunity to take a step back and think about the implications, particularly of the deeply one-sided web of obligations this creates. A Marxist analysis adds another level of consideration. One of the basic questions of Marxist thought is why workers put up with exploitation by capitalists. In a Marxist analysis, workers provide the productive output of society, which is then redirected and controlled by a relatively small capitalists. The workers massively outnumber the capitalists. Why would they be content for this situation to continue? Marx, of course, thought they wouldn't be, that the periodic crises of capitalism would eventually result in a socialist revolution by the workers. But by and large this hasn't happened. Why? Lazzarato offers debt as a partial explanation. The profits redirected by capitalists are returned to workers to some extent, but as debt rather than payment. This allows workers to participate to some extent in the growth of societal wealth from constantly increasing productivity, while simultaneously entangling workers in a system of moral control. Company stores, starvation wages, and other confiscatory practices are clear mechanisms of external control that provoke directed outrage. Debt is something that the debtor has nominally agreed to (however much the situation is manipulated to make that agreement almost inevitable), and to which attaches a deep tradition of moral responsibility. The worker has respected grounds on which to object to inequitable treatment; the debtor is wholly responsible for repayment, and is rarely considered to have grounds to complain about the debt. Most of the historical attempts to balance those scales, such as laws and religious rules against usury or the historical Jewish rule of Jubilee, have fallen by the wayside. This is a rather extended summary of what I got out of the book. I'm doing that in part because the book itself is somewhat heavy going. Lazzarato makes extensive use of specialized terms (often not defined) and fills the book with references to other works without much in the way of useful summary. It's the sort of book where, if you're not already well-versed in the field, you may need to just keep reading through some passages to find a point of reference that makes the argument retroactively make sense. I had a particular difficulty with "subjectivation," a term that Wikipedia tells me is from the writings of Michel Foucault (a major source for this book), which Lazzarato uses extensively but never adequately defines. Some external research indicates that this is a very difficult term to define, which explains why I was never quite comfortable with my understanding. I think Lazzarato is using it to get at the process of internalization of the morality of debt and the way that a debt society forces individuals into a mode of economic individualism in which many of their personal choices are bent towards making themselves better (more reliable, more trustworthy) debtors. But I'm not completely sure. There are also places in which I think Lazzarato takes his argument too far, although one of those, I think, reflects a difference in national economic status. He makes quite a lot of national debt in this book, placing it in the universal position of the overarching debt that turns every citizen into a debtor even if they've avoided other debts. This is possibly true in countries whose national debts are held in other currencies, or in countries like Italy that are part of the Euro (which, if one is not Germany or France, amounts to much the same thing). It's a dubious assertion for countries like the UK, Japan, or the United States, where the national debt is held in their own free-floating currency and is largely owed domestically, and partly plays into some frustratingly incorrect political rhetoric. One of the key dynamics of debt, namely the extreme power imbalance between debtor and creditor, is missing in countries with sovereign debt in their own currency, since those countries can always (if they're willing to pay the inflation price) simply print money to pay off national debt. Creditors know this, and therefore interest rates are much lower, the amount of leverage the creditor has is quite limited, and the sorts of debt crises seen in Italy and elsewhere in the Euro periphery are not seen. Lazzarato is understandably writing from the Italian perspective, but I think he weakens his argument by lumping national debt so completely into the same category as the other types of exploitative debt he discusses. The principle does feel universal to me, but the best examples of debt vary by country, so one has to be careful about generalizing specific examples. Another place where I simply disagree with his conclusions is around some of the more dramatic presentations of subjectivation. Lazzarato talks, at one point, about how debt reduces debtors to mechanical components, and uses as an example an ATM machine, which he portrays as uniquely dehumanizing through the mechanical process that someone has to follow to withdraw money. There may be some point here about the dehumanization of debt and its subsumption into the foundation of day-to-day social interaction, but he lost me entirely with the unwarranted technophobia of the specific example. The idea that machines and automation make us less human is an old argument that's orthogonal to the thrust of his argument. It reminded me of old contentions that human relationships made on-line aren't real, which is nonsense. Overall, this is a fascinating and insightful discussion hampered by a difficult and sometimes overly elliptical presentation, a bit too much drama and grand theorizing, and a few poor choices of examples. I found the basic idea extremely valuable, but the amount of work required to extract it occasionally irritating. (This could be partly due to the limits of translation, but I suspect most of the difficulty was present in the original.) I'm not sure that I would recommend the book, but I definitely recommend considering the underlying ideas. Debt now works alongside the employment relationship as a primary means of reinforcing economic and social control and hierarchy. This is likely via accidental development rather than any grand plan, but it's now being actively exploited by the creditors of society, large corporations most notably. Viewed in that light, the explosive growth of student loan debt in the United States is particularly frightening. After Lazzarato's extensive examination of the distortive effects of permanent debt, not just on economics and society but on our own conceptions of our selves and our duties and roles in life, the idea of trapping a generation in debt from the moment of their financial independence is deeply troubling, even nauseating. Rating: 6 out of 10

For a long time it was widely regarded that SCSI was the interface for all serious drives that were suitable for Enterprise Use or for anything else which requires reliable operation. On the other hand IDE was for cheap disks that were only suitable for home use. The SCSI vs IDE issue continues to this day but now we have SAS and SATA filling the same market niches with the main difference between the current debate and the debate a decade ago being that a SATA disk can be connected on a SAS bus. Both SAS and SATA have a single data cable for each disk which avoids the master/slave configuration on IDE and the issue of bus device ID number (from 0-7 or 0-15) and termination on SCSI. Termination When a high speed electrical signal travels through a cable some portion of the signal will be reflected from any cable end point or any point of damage. To prevent the signal reflection from the end of a cable you can have a set of resistors (or some other terminating device) at the end of the cable, see the Terminator(electrical) Wikipedia page [1] for a brief overview. As an aside I think that page could do with some work, if you are an EE with a bit of spare time then improving that page would be a good thing. SCSI was always designed to have termination while IDE never was. I presume that this was largely due to the cable length (18 for IDE vs 1.5m to 25m for SCSI) and the number of devices (2 for IDE vs 7 or 15 for SCSI). I also presume that some of the problems that I ve had with IDE systems have been related to signal problems that could have been avoided with a terminated bus. My first encounter with SCSI was when working for a small business that focused on WindowsNT software development. Everyone in the office knew a reasonable amount about computers and was happy to adjust the hardware of their own workstation. A room full of people who didn t understand termination who fiddled with SCSI buses tended to give a bad result. On the up-side I learned that a SCSI bus can work most of the time if you have a terminator in the middle of the cable and a hard drive at the end. There have been two occasions when I ve been at ground zero for a large deployment of servers from a company I ll call Moon Computers. In both cases there were two particularly large and expensive servers in a cluster and one of the cluster servers had data loss from bad SCSI termination. This is particularly annoying as the terminators have different colours, all that was needed to get the servers working was to change the hardware to make them look the same. As an aside the company with no backups [2] had one of the servers with bad SCSI termination. Heat SCSI disks and now SAS disks tend to be designed for higher performance, this usually means greater heat dissipation. A disk that dissipates a lot of heat won t necessarily work well in a desktop case with small and quiet fans. This can become a big problem if you have workstations running 24*7 in a hot place (such as any Australian city that s not in Tasmania) and turn the air-conditioner off on the weekends. One of my clients lost a few disks before they determined that IDE disks are the only option for systems that are to survive Australian heat without any proper cooling. Differences between IDE/SATA and SCSI/SAS In 2009 I wrote about vibration and SATA performance [3]. Rumor has it that SCSI/SAS disks are designed to operate in environments where there is a lot of vibration (servers with lots of big fans and fast disks) while IDE/SATA disks are designed for desktop and laptop systems in quiet environments. One thing I d like to do is to test performance of SATA vs SAS disks in a server that vibrates. SCSI/SAS disks have apparently been designed for operation in a RAID array and therefore will give a faster timeout on a read error (so another disk can return the data). While IDE/SATA disks are designed for a non-RAID situation and will spend longer trying to read the data. There are also various claims about the error rates from SCSI/SAS disks being better than those of IDE/SATA disks. But I think that in all cases the error rates are small enough not to be a problem if you use a filesystem like ZFS or BTRFS but they are also large enough to be a significant risk with modern data volumes if you have a lesser filesystem. Data Loss from Storage Failure In the data loss that I ve personally observed from storage failures the loss from SCSI problems (termination and heat) is about equal to all the hardware related data loss I ve seen on IDE disks. Given that the majority of disks I ve been responsible for have been IDE and SATA that s a bad sign for SCSI use in practice. But all serious data loss that I ve seen has involved the use of a single disk (no RAID) and inadequate backups. So a basic RAID-1 or RAID-5 installation will solve most hardware related data loss problems. There was one occasion when heat caused two disks in a RAID-1 to give errors at the same time, but by reading from both disks I managed to get almost all the data back, RAID can save you from some extreme error conditions. That situation would have been ideal for BTRFS or ZFS to recover data. Conclusion SCSI and SAS are designed for servers, using them in non-server systems seems to be a bad idea. Using SATA disks in servers can have problems too, but not typically problems that involve massive data loss. Using technology that is too complex for the people who install it seems risky. That includes allowing programmers to plug SCSI disks into their workstations and whoever it was from Moon computers or their resellers who apparently couldn t properly terminate a SCSI bus. It seems that the biggest advantage of SAS over SCSI is that SAS is simple enough for most people to be able to correctly install it. Making servers similar to the systems that the system administrators use at home seems like a really good idea. I think that one of the biggest benefits of using x86 systems as servers is that skills learned on home PCs can be transferred to administration of servers. Of course it would also be a good idea to have test servers that are identical to servers in production so that the sysadmin team can practice and make mistakes on systems that aren t mission critical, but companies seem to regard that as a waste of money apparently the risk of down-time is cheaper.

• [1] http://en.wikipedia.org/wiki/Terminator_(electrical)
• [2] http://etbe.coker.com.au/2013/05/21/no-backups-wtf/
• [3] http://etbe.coker.com.au/2009/04/22/vibration-strange-sata-performance/

So it's been about a year since I started running. In that time, I've gone from just being able to run 5K, to comfortably doing 10K in just under an hour. In that same time, my weight has gone from 77.5 kg to around 69 kg. The thing that started all of this off was the 5K Packard Summer Scamper, and next month I'm going to run in my first 14K fun run, the City2South. I thought I'd have a go at fund raising too, so if you'd like to make a donation, here's my page. I'm raising money for the Heart Foundation. I've constantly surprised myself with my progress. Just the last time I went for a run, I managed to set personal records on 1 km, 1 mile, 5 km and 10 km, which really blew me away. Once upon a time, I had this crazy idea to try and get into the Queensland Police Service, and one of the fitness requirements for applying was you had to be able to run 2.4 km in under 12 minutes, and I remember training away on the treadmill at the gym and only just scraping in under that time on a treadmill. Then I tried it on a running track, and I have these vague memories of it being a total slog. That was probably 10 years or more ago now. Now I could do that easily. I've got quite a nice 10 km running course in my local neighbourhood, so I'm thinking now that I'm comfortably running 10 km on this course, I should try and go for a half-marathon distance, so one of these weekends I'll just try running the same course twice plus a little bit more, just to see if I have it in me. Then maybe I'll consider entering a half-marathon, just for shits and giggles. I'll probably do it after I run 14 km, which will be the longest distance I've run to date. I only learned about the City2South run yesterday. The run that I've been planning on doing since returning to Brisbane is the Bridge to Brisbane. It looks like they've just opened up entries for it now, so I guess I should go sign up for it too.

I wrote a small wiki page for botch. It includes links to some hopefully useful resources like my FOSDEM 2013 talk or my master thesis about botch. The final goal of botch is to generate a build order with which Debian can be bootstrapped from zero to more than 18000 source packages. But such a build order can only be generated once enough source packages (by now the number is around 70) incorporate build profiles which allow to compile them with less build dependencies and thereby break all build dependency cycles. So an intermediary goal of botch is, to find a "good" (i.e. a close to minimal amount) selection of such build dependencies that should be dropped from their source packages. So far, the results of all heuristics we use for this task were just dumped to standard output. Since this textual format was hard to read for a human developer and even worse machine readable, that tool now outputs its results in JSON. This data is then converted by another tool to a more human readable format. One such format is HTML and with the help of javascript for sortable and pageable tables, the data can then be presented without producing too much visual clutter (at least compared to the initial textual format). Another advantage of HTML is, that the data can now easily be shared with other developers without them having to run botch or install any other program first. So without further ado, please find the result of running our heuristics on Debian Sid as of 2013-01-01 here: http://mister-muffin.de/bootstrap/stats/ Here is a screenshot of what you can expect (you can see part of the table of edges with most cycles through them): As a developer uses this information to add build profiles to source packages, this HTML page can be regenerated and will show which strongly connected components are now left in the graph and how to best make them acyclic as well. Besides other improvements I also updated the data I used to generate the graphs from this post. I found this update to be necessary since we found and fixed several implementation bugs since October 2012, so this new plot should be more accurate. Here a graph which shows the amount of vertices in the biggest strongly connected component of Debian Sid by date. Some datapoints are missing for dates for which important source packages in Sid were not compilable.

Review: Advanced Perl Programming, by Sriram Srinivasan

Publisher:	O'Reilly
Copyright:	August 1997
ISBN:	1-56592-220-4
Format:	Trade paperback
Pages:	392

The problem with buying lots of books is that one frequently doesn't read them soon after purchase. And while nearly all fiction and most non-fiction doesn't have a time limit, technical books are more of a problem. As you might have guessed from the publication date and subject matter of this book, it's one I waited too long to read. I picked up Advanced Perl Programming not too long after it was first published in 1997. I bought it primarily for the chapters on XS programming, since I was just starting to develop and help maintain code that built Perl interfaces for C libraries. And then it sat on my bookshelf in the office, and then at home, until it was 16 years old. That's problematic for a general Perl programming guide; it's particularly troublesome for a book that dives deep into internals. That said, I still got some interesting information from it. Advanced Perl Programming is something of a grab bag of different and largely unrelated topics. It starts with a data structures overview (which is mostly about references), covers typeglobs and the Perl symbol table, briefly discusses closures, and then dives deeper into eval. That's followed by an overview of modules and object-oriented programming in Perl. The general Perl topics close with a solid (if outdated) discussion of tied objects and a somewhat rambling and remarkably general discussion of persistance. Srinivasan then covers some recommended module APIs for networking and graphics (Tk, specifically) while working through some complex examples, takes a deeper dive into eval and code generation, and concludes with three chapters on XS and embedded Perl interpreters. This is all solid material, but a lot of it is at least partly obsolete. The chapters on modules and object-oriented programming fare the worst; you'll find much better guides to those topics elsewhere. Data structures also fare poorly, partly because Srinivasan is still happy to use symbolic references, now considered bad style due to lack of compile-time checking. (That does mean, though, that this is one of the best introductions to symbolic references that you'll find, since few other Perl programmers discuss them.) But the rest of the book is fairly solid, if limited by age. If I'd read it when I first started with XS, it would have indeed helped. Advanced Perl Programming contains a succinct and clear overview of Perl internals and data representation (assuming, of course, it's not changed drastically, but I didn't notice any significant issues from what I know of internals from quite a lot of XS programming), particularly when combined with the earlier chapter on typeglobs and the symbol table. It is interesting, though, to see how much accepted Perl style has changed. Srinivasan is quite fond of eval with a scalar argument to construct code at runtime, something that most current authors recommend against when it can be avoided. The loss of static syntax checking means the technique is often hard to debug and can cause surprising runtime errors. Several of the more advanced tricks in this book are built on that framework, including a moderately interesting templating system that he constructs from scratch in this book. The examples here are also missing the focus on use strict, warnings, and avoiding special variables and unusual constructs that you see in more recent Perl books. This is a very thoughtful book, with several structural techniques that I appreciated and would like to see more technical writers use. One is the comparisons to the approaches of other languages at the end of most chapters. It puts Perl's approach in a broader context and encourages thought about alternative ways to view a particular feature and implementation tradeoffs in Perl's choices. Another is the careful discussion of design approaches and possibilities during the construction of larger examples. I think there's a tendency in technical books to spend a lot of time developing the best possible implementation of something and then show that completed example. Even with a detailed analysis of its construction, this can be less useful than a broader discussion of possible approaches, including dead ends. The problem, of course, is that 16 years is a long time, even for a relatively mature programming language, and Perl has changed. There are significant improvements not only to the standard library but to Perl core functionality that have happened since this book was written. The chapter on tying, which is otherwise excellent, is badly out of date on what functionality and methods are available and is no longer a reliable guide to using that feature except for simple cases. Similar problems plague the chapter on persistence, which develops the concept from basics that most programmers reading an advanced book no longer need, and which has been rendered mostly obsolete by further developments in the Perl module ecosystem. I think the best parts of this book, the ones that cover material that I think is still relatively accurate and that are not well-covered by other resources, are the chapters on typeglobs and on XS. The typeglob discussion is both clear and informative, covering material and techniques that are used in a few core Perl modules and that I've never seen adequately addressed elsewhere. I'd subsequently picked up XS and Perl embedding the hard way: lots of trial and error and reading difficult POD documentation. I wish I'd read this book earlier, since Srinivasan does a great job of basic orientation. He doesn't go far enough for me (the book I probably wanted was Extending and Embedding Perl by Jenness and Cozens, published five years later), but I would have been up and running with basic XS much faster by starting here. If this were 1997, or even 2000, I would probably recommend this book, albeit with a few caveats. Higher Order Perl is the place you should go for discussion of closures, rather than here (although of course it didn't exist then). I wasn't fond of string eval even in 1997, and I still think it produces code that, while efficient and quite powerful, is horribly difficult to understand. And the introduction to modules is adequate but not compelling; most other introductions to object-oriented programming and module construction in Perl are better. But even discarding those chapters (and the mostly unnecessary Tk reference), there's a lot of great material here that would have been quite helpful in 2000. Unfortunately, this is not the sort of technical book that ages well, and while I did pick up some useful background knowledge and a much better understanding of typeglobs, I mostly read this book because I wanted to salvage some knowledge from a book that sat for far too long on my shelves. There's really no reason to buy it today. If you run across it in a library, there are a few chapters that are still worth reading, but by and large if you know enough Perl to know where to be careful of landmines due to changes in Perl since the book was written, you also know enough Perl to not really need this book. Rating: 5 out of 10

I've been slow lately in writing these up (and, for that matter, in doing most other things related to reading; things have been rather busy lately). This is a bunch of here-and-there purchases over the last few months, including Powell's Indiespensible shipments. Sandra Barret Face of the Enemy (sff)
Anne Bishop Written in Red (sff)
Lois McMaster Bujold Captain Vorpatril's Alliance (sff)
Cary Caffrey The Girls from Alcyone (sff)
Jenni Fagan The Panopticon (mainstream)
Niels Ferguson, et al. Cryptography Engineering (non-fiction)
Jen Kirchner The Fourth Channel (sff)
Anothony Marra A Constellation of Vital Phenomena (mainstream)
Steve McConnell Code Complete (non-fiction)
Seanan McGuire Velveteen vs. The Junior Super-Patriots (sff)
Patrick Nielsen Hayden, et al. (ed.) Some of the Best from Tor.com: 2012 (sff anthology)
Lisa O'Donnell The Death of Bees (mainstream)
Susan Palwich Flying in Place (sff)
Kim Stanley Robinson 2312 (sff)
John Scalzi Redshirts (sff)
Ian Tregillis Bitter Seeds (sff)
Leon Trotsky The History of the Russian Revolution (non-fiction)
Simon Van Booy The Illusion of Separateness (mainstream)
Chris Anne Wolfe Shadows of Aggar (sff)
Barbara Ann Wright The Pyramid Waltz (sff) That's a lot of stuff. It includes a couple of non-fiction O'Reilly books from sales, a few months of Powell's Indiespensible subscriptions, a variety of books I picked up after a discussion of good lesbian fiction on Tor.com (romance without the obnoxious gender tropes, or at least as many of them), and the rest of the Hugo nominees for the year. I got a ton of reading done earlier this month. I wish I could say the same thing about reviews, but I only wrote a few. That's something that I want to try to catch up on soon, so there will probably be a flurry of those posted soon. I've already read Blackout and Redshirts of this year's nominees (a review of the latter is coming), so at least I'm not too far behind on the reading. Throne of the Crescent Moon is in progress now.

The fifth internation R/Finance conference was held last weekend. As one of the founding co-organizers, I may well be accussed of a little bias, but we think we once again pulled off a very nice and successful weekend-long event. Participants had kind words to say during the conference, and a few first posts have appeared such as Joe Rickert's post over at the REvo blog. Some participants, myself included, had already posted on their personal websites (though had forgotten to mention it here). In any event, I just updated the website with links to the pdf (or ppt) slides of all presenters who shared their material with us. Supplemental material may be made available too at a later date. We hope you find these slides useful. Please do spread the word about the R/Finance conference as we expect to have a sixth edition in May 2014---and we do look forward to receiving even more outstanding submissions. Dates, details, call for papers, etc will be forthcoming over the next few months.

I recently had a TeX itch to scratch: I am working on a paper that has several multi-line continued equalities where, depending on the size of the expressions and the explanations of each step, I chose among a few layouts. But implementing the layout together with the actual code was inefficient, as switching the layout involved changing every line. So I came up with the package conteq which allows you to typeset continued equations in a simple declarative manner, e.g.

\begin conteq 
  e^ \pi\cdot i  \\
= -1               & Euler's formula \\
< 0                & this is an inequality \\ 
< \sqrt 3 \\
= \int e^ -x^2  dx & this is due to Gauss.
\end conteq 

and allows you to select the layout via an parameter to the environment, or globally, or either. Also, the styling of the explanations (italics? wrapped in ... ?) can be configured simply by redefining a macro. For more details and an overview of the various styles, check out the package documentation.
If this sounds useful to you, fetch the conteq package from CTAN. But beware: It uses quite current features of the expl3 package, so you need at least the version from 2012/07/02 (TeXLive 2013 is good). You can file bug reports at the GitHub mirror of my git repository.
I d like to thank Bruno Le Floch and Joseph Wright, who made me aware of expl3 on various TeX Exchange questions. I haven t heard of this term before, but supposedly it is the right translation for the German word Gleichungskette .

Wouter still does not like the 3.0 (quilt) packaging format. And as he writes on his blog, I shall answer on mine. And what if one of the blogs becomes unreachable with time? Aha! That's one of the weaknesses, Wouter, on yuor closing comment:

I have all my packages stored in git with a proper Vcs-Git: header; if people really want to look at individual patches, they can just use debcheckout, kthxbye.

I am aware this would not be so much of an argument, or so much of a change. But the way I view a shipped package is that it should, by itself, be as a snapshot with its whole, full description. Say that three years from now Apple has scrubbed your brain and you went to work with them. And you decided to pull all of your non-iOS repositories. They have convinced you working for Debian is bad for mankind. So you erase all of your Git repos, including those in Alioth or whatever. But Debian Wheezy has some of your packages. And three years from now, I decided to be the maintainer. So, having fully commented and individually marked patches is a sort-of-way to avoid a situation akin to the tentacles of evil. Now, it's not that I'm criticizing your workflow. I have sen many ways to manage patches in quite a natural way, and I undestand it might be way easier when dealing with complex packages (FWIW I usually deal with very little complexity). Still, it is an argument.

If you see a bunch of X.org packages upgrades pending in your Squeeze or brand new Wheezy system, don't panic! Ilja van Sprundel, a security researcher from IOActive, has discovered a large number of issues in the various X client libraries and he has worked with X.Org's security team to analyze, confirm, and fix these issues. You can find more information in the security avisory from X.org. The Debian Security and X.org teams have quickly updated all the affected packages in Squeeze and Wheezy. You can see the full list of updates in the debian-security-announce mailing list archives.

I ve been hacking on some static analyses stuff for debuild.me, and i ve been involved in a multi-year long yak shaving exercise. As today s fun part, I wrote python-schroot to help run commands in a schroot chroot (say that 10 times fast!) After a while, I got some neat stuff working. Here s an honest example:

from schroot import schroot
with schroot('unstable-amd64') as chroot:
    chroot.copy('/etc/issue', '/etc/issue', user='root')

This will copy a file (/etc/issue) from the host system into the schroot chroot. Neat! Now, to run something:

with schroot('unstable-amd64') as chroot:
    out, err, ret = chroot.run("whoami")
    print(out)    

Then, in an effort to make a DSL, I set out to create the following syntax:

with schroot('unstable-amd64') as chroot:
    "apt-get update" in chroot

but, hit some issues with implementing it, and got the following to work:

with schroot('unstable-amd64') as chroot:
    "apt-get update" > chroot // "root"  # apt-get update as root

More later!

I want a CLI WebDAV client that's better than cadaver or hdav. I want a program that can sync an .ics file with a CalDAV server, by dividing it up into events and individually synchronizing each of those. I don't have a clue how deletions would be handled, but that would be nice too. Then I want a program that can synchronize the .ics file with org-mode files. I want a SIP client that works as well as Twinkle but has the architecture of SFLphone or is a library upon which an arbitrary UI can be constructed. I want an HTML-rendering library that has callbacks or hooks for security- and privacy-relevant things like cookies and SSL certificates. I want at least one browser built on this library. I want it to support vi-like keybindings. I want an HTTP(S) proxy that can be dynamically-configured per-client or per-connection through a standardized protocol that web browsers or their plugins can speak. I want it to be able to handle all the relevant things covered by AdBlock Plus, RequestPolicy, and NoScript. I want HTTPS authentication through Monkeysphere and mod_gnutls. I want a git-annex backend for Ogg Vorbis files that treat the audio streams independently of the metadata yet stores them together in the same file so that everything behaves as usual but the annex doesn't bloat by 400Go after I run beets. I want a file transfer queuing system that can work over any sort of transport mechanism, direct or asynchronous, that handles partial transfers and throttling, and is generally magical. I want all kinds of accounting software improvements. I want sane PBX software. I want an OpenStack that doesn't use libvirt for KVM. I want backup software that behaves some weird hybrid of BoxBackup and Dirvish. I want a peer-to-peer card- and board-game platform that uses cryptographic assurance. I want everyone to use YAML instead of XML. I want a phone that's not running a doomed operating system. I want lots of other stuff.

For a while now, I've been plagued with this ridiculous problem of the keyboard becoming "stuck" in my Fedora 17 VM running under VirtualBox. Keys would stop working until you held them down for several seconds, making typing close to impossible. Of course, my first thought was to blame VirtualBox, since it has a lot to do with the keyboard. I found out some interesting things, like you can send scan-codes directly to virtual-machines with something like

$ VBoxManage controlvm UUID keyboardputscancode aa

(get the UUID via VBoxManage list vms; figuring out scan-codes is left to the reader!). I noticed the problem primarily happening while emacs was in the foreground, meaning I was working on code or an email ... my theory was when I typed too fast some race got hit and put the keyboard into a weird state that a reboot fixed. Well it turns out the problem is almost the exact opposite. Luckily, today I noticed "slow keys enabled" warning that sprung-up and went away quickly just before the keyboard stopped. Once I saw that the game was up; turns out this is a well-known bug that is easily fixed with xkbset -sl. It happens because I was typing too slowly; holding down the shift-key while I thought about something probably. Hopefully this saves someone else a few hours!

Some years ago I was working on a project that involved a database cluster of two Sun E6500 servers that were fairly well loaded. I believe that the overall price was several million pounds. It s the type of expensive system where it would make sense to spend adequately to do things properly in all ways. The first interesting thing was the data center where it was running. The front door had a uniformed security guard and a sign threatening immediate dismissal for anyone who left the security door open. The back door was wide open for the benefit of the electricians who were working there. Presumably anyone who had wanted to steal some servers could have gone to the back door and asked the electricians for assistance in removing them. The system was poorly tested. My colleagues thought that with big important servers you shouldn t risk damage by rebooting them. My opinion has always been that rebooting a cluster should be part of standard testing and that it s especially important with clusters which have more interesting boot sequences. But I lost the vote and there was no testing of rebooting. Along the way there were a number of WTFs in that project. One of which was when the web developers decided to force all users to install the latest beta release of Internet Explorer, a decision that was only revoked when the IE install process broke MS-Office on the PC of a senior manager. Another was putting systems with a default Solaris installation live on the Internet with all default services running, there s never a reason for a database server to be directly accessible over the Internet. No Backups At All But I think that the most significant failing was the decision not to make any backups. This wasn t merely forgetting to make backups, when I raised the issue I received a negative reaction from almost everyone. As an aside I find it particularly annoying when someone implies that I want backups because I am likely to stuff things up. There are many ways of proving that there s a general lack of competence in the computer industry. But I think that one of the best is the number of projects where the person who wants backups has their competence questioned instead of all the people who don t want backups. A decision to make no backups relies on one of two conditions, either the service has to be entirely unimportant or you need to have no bugs in the OS or hardware defects that can corrupt data, no application bugs, and a team of sysadmins who never make mistakes. The former condition raises the question of why the service is being run and the latter is impossible. As I m more persistent than most people I kept raising the issue via email and adding more people to the CC list until I got a positive reaction. Eventually I CC d someone who responded with What the fuck which I consider to be a reasonable response to a huge and expensive project with no backups. However the managers on the CC list regarded the use of profanity in email to be a much more serious problem. To the best of my knowledge there were never any backups of that system but the policy on email was strongly enforced. This is only a partial list of WTF incidents that assisted in my decision to leave the UK and migrate to the Netherlands. Not Doing Much About a year after leaving I returned to London for a holiday and had dinner with a former colleague. When I asked what he was working on he said Not much . It turned out that proximity to the nearest manager determined the amount of work that was assigned. As his desk was a long way from the nearest manager he had spent about 6 months getting paid to read Usenet. That wasn t really a surprise given my observations of the company in question.

You may not know this, but I am a huge PowerDNS fan. This may be because it is so simple to use, supports different databases as backends or maybe just because I do not like BIND, pick one. I also happen to live in Germany where ISPs usually do not give static IP-addresses to private customers. Unless you pay extra or limit yourself to a bunch of providers that do good service but rely on old (DSL) technology, limiting you to some 16MBit/s down and 1MBit/s up. Luckily my ISP does not force the IP-address change, but it does happen from time to time (once in a couple of month usually). To access the machine(s) at home while on a non-IPv6-capable connection, I have been using my old (old, old, old) DynDNS.com account and pointing a CNAME from under die-welt.net to it. Some time ago, DynDNS.com started supporting AAAA records in their zones and I was happy: no need to type hostname.ipv6.kerker.die-welt.net to connect via v6 just let the application decide. Well, yes, almost. It s just DynDNS.com resets the AAAA record when you update the A record with ddclient and there is currently no IPv6 support in any of the DynDNS.com clients for Linux. So I end up with no AAAA record and am not as happy as I should be. Last Friday I got a mail from DynDNS:

Starting now, if you would like to maintain your free Dyn account, you must now log into your account once a month. Failure to do so will result in expiration and loss of your hostname. Note that using an update client will no longer suffice for this monthly login. You will still continue to get email alerts every 30 days if your email address is current.
Yes, thank you very much

Given that I have enough nameservers under my control and love hacking, I started writing an own dynamic DNS service. Actually you cannot call it a service. Or dynamic. But it s my own, and it does DNS: powerdyn. It is actually just a script, that can update DNS records in SQL (from which PowerDNS serves the zones). When you design such a service , you first think about user authentication and proper information transport. The machine that runs my PowerDNS database is reachable via SSH, so let s use SSH for that. You do not only get user authentication, server authentication and properly crypted data transport, you also do not have to try hard to find out the IP-address you want to update the hostname to, just use $SSH_CLIENT from your environment. If you expected further explanation what has to be done next: sorry, we re done. We have the user (or hostname) by looking at the SSH credentials, and we have the IP-address to update it to if the data in the database is outdated. The only thing missing is some execution daemon or cron(8). :) The machine at home has the following cron entry now:

*/5 * * * * ssh -4 -T -i /home/evgeni/.ssh/powerdyn_rsa powerdyn@ssh.die-welt.net

This connects to the machine with the database via v4 (my IPv6 address does not change) and that s all.
As an alternative, one can add the ssh call in /etc/network/if-up.d/, /etc/ppp/ip-up.d/ or /etc/ppp/ipv6-up.d (depending on your setup) to be executed every time the connection goes up. The machine with the database has the following authorized_keys entry for the powerdyn user:

no-agent-forwarding,no-port-forwarding,no-pty,no-X11-forwarding,no-user-rc,\ 
command="/home/powerdyn/powerdyn/powerdyn dorei.kerker.die-welt.net" ssh-rsa AAAA... evgeni@dorei

By forcing the command, the user has no way to get the database-credentials the script uses to write to the database and neither cannot update a different host. That seems secure enough for me. It won t scale for a setup as DynDNS.com and the user-management sucks (you even have to create the entries in the database first, the script can only update them), but it works fine for me and I bet it would for others too :) Update: included suggestions by XX and Helmut from the comments.

3 comment(s) this blog is flattr enabled

Howdy, i m sure most people are aware of the recent release of Moblin 2.0; a user experience for netbooks. I m going to write a few blog posts about how the Moblin user experience is built on the awesome technologies in the GNOME platform. So first up, let s look at the Myzone, we re starting here since this is the first thing I really worked on in the Moblin UX and i ve been able to see it through from early ideas to the 2.0 and 2.1 releases. So, deep breath, the idea behind the Myzone is to provide a springboard to things that matter to you most: your recent files and web pages you ve visited, your upcoming events and things you need to do, things that are happening on social web services and your favourite applications. Now then, that s the theory, how does it work:

• Recent files: Recent file information is pulled from the GtkRecentManager and the thumbnails are pulled from the XDG thumbnail specification directory. Metadata for the file comes courtesy of gio which I presume comes from shared-mime-info. Yay. By using the GtkRecentManager for all our recent activity metadata across the platform we re allowing legacy GNOME applications to just work. Sweet.
• Events and tasks: These are pulled from EDS using libjana, a calendaring library primarily developed by Chris Lord (of Dates fame.) A couple of months back (well, uh, March) I enhanced libjana to support tasks and thus we are able reuse the existing Tasks/Dates apps for interacting with the calendar.
• Favourite apps: Here I let the side down. I use some quite crazy custom format for doing this which frankly stinks. I m going to try and sit down with the GNOME shell guys to see if we can come up with some better way for dealing with user originated application metadata.
• Social networking/web service integration: This comes courtesy of Mojito and librest, two projects that I and the esteemed Ross Burton have been working on. Mojito is a project that pulls in content from a variety web services into a centralised place, abstracting some of the complexity and the makes it trivial to query. librest is a library for to keep developers happy even though they re having to deal with web services. It does this by making requests and parsing the result simple.

I ve been part of many conference calls for work and found them seriously lacking. Firstly there s a lack of control over the call, so when someone does something stupid like putting an unmuted phone handset near a noise source there s no way to discover who did it and disconnect them. Another problem is that of noise on the line when some people don t mute their phones, which is related to the lack of control as it s impossible to determine who isn t muting their phone. Possibly the biggest problem is how to determine who gets to speak next. When group discussions take place in person non-verbal methods are used to determine who gets to speak next. With a regular phone call (two people) something like the CSMACD algorithm for network packets works well. But when there are 8+ people involved it becomes time consuming to resolve issues of who speaks next even when there are no debates. This is more difficult for multinational calls which can have a signal round trip time of 700ms or more. I think that we need a VOIP based conference call system for smart phones to manage this. I think that an ideal system would be based on the push to talk concept with software control that only allows one phone to transmit at a time. If someone else is speaking and you want to say something then you would push a button to indicate your desire but your microphone wouldn t go live while the other person was speaking. The person speaking would be notified of your request and one of the following things would happen:

• You are added to the queue of people wishing to speak. When the other person finished speaking the next person in the queue gets a turn.
• You are added to the queue and the moderator of the call chooses who gets to speak next. This isn t what I d prefer but would probably be desired by managers for corporate calls.
• You get to interrupt the person who s speaking. This may not be ideal but is similar to what currently happens.

Did I miss any obvious ways for the system to react to a talk request? Is there any free software to do something like this? A quick search of the Google Play store didn t find anything that seems to match.

Dear all, DebConf13 sponsorship application date extended As communicated through the debconf-announce@lists.debconf.org mailing list, the deadline to apply for DebConf13 sponsorship has been extended to the end of this week, May 19th. If you intend to attend DebConf13 in August and would like to apply for sponsored registration, now is the time to register in Penta! After this deadline you will no longer be able to apply for sponsored food, accomodation or travel. Please refer to the announcement and to the registration documentation for details. Please contact us on the debconf-discuss mailing list if you have any questions. DebConf12 final report The DebConf team is also happy to announce the release of the DebConf12 Final Report. It s a 39-page document which gives the reader an idea about the conference as a whole. It includes descriptions of talks, DebCamp and Debian Day activities, personal impressions, attendee and budgeting numbers, the work of various teams, social events and so on. If you attended Debconf12, the report may refresh some of your memories and bring you closer to the organization team work. If not, it will certainly encourage you to be part of future Debian events. We thank the Universidad Centroamericana, the Government of Nicaragua, Google and all other DebConf12 sponsors for their support that made the event possible. The DebConf team

In my professional life I am sometimes required to provide technical support to one of our salesmen. I find this an interesting change in pace though sometimes challenging.

Occasionally I fail to clearly convey the solution we are trying to sell because of my tendency to focus on detail the customer probably does not need to understand but I think is the interesting part of the problem.

Conversely sometimes the sales people gloss over important technology choices which have a deeper impact on the overall solution. I was recently in such a situation where as part of a larger project the subject of internationalisation (you can see why it gets abbreviated to i18n) was raised.

I had little direct personal experience with handling this within a project workflow so could not give any guidance but the salesman recommended the Transifex service as he had seen it used before, indicated integration was simple and we moved onto the next topic.

Unfortunately previous experience tells me that sometime in the near future someone is going to ask me hard technical questions about i18n and possibly how to integrate Transifex into their workflow (or at least give a good estimate on the work required).
LearningBeing an engineer I have few coping strategies available for situations when I do not know how something works. The approach I best know how to employ is to give myself a practical crash course and write up what I learned...so I did.

I proceeded to do all the usual things you do when approaching something unfamiliar (wikipedia, google, colleagues etc.) and got a basic understanding of internationalisation and localisation and how they fit together.

This enabled me to understand that the Transifex workflow proposed only covered the translation part of the problem and that, as Aldrich observed in my title quote, there is an awful lot more to translation than I suspected.
PlatformsMy research indicated that there are numerous translation platforms available for both open source and commercial projects and Transifex is one of many solutions.

Although the specific platform used was Transifex most of these observations apply to all these other platforms. The main lesson though is that all platforms are special snowflakes and once a project invests effort and time into one platform it will result in the dreaded lock in. The effort to move to another platform afterwards is at least as great as the initial implementation.

It became apparent to me that all of these services, regardless of their type, boil down to a very simple data structure. They appear to be a trivial table of Key:Language:Value wrapped in a selection of tools to perform format conversions and interfaces to manipulate the data.

There may be facilities to attach additional metadata to the table such as groupings for specific sets of keys (often referred to as resources) or translator hints to provide context but the fundamental operation is common.

The pseudo workflow is:

• Import a set of keys
• Provide a resource grouping for the keys.
• Import any existing translations for these keys.
• Use the services platform to provide additional translations
• Export the resources in the desired languages.

The Transifex service does at least allow for the Key values to be arbitrary although the resources are separated by language.

Even assuming a project uses gettext PO files and UTF-8 character encoding (and please can we kill every other character encoding and move the whole world to UTF-8) the tools to integrate the import/export into the project must be written.

A project must decide some pretty important policies, including:

• Will they use a single service to provide all their translations.
• Will they allow updates to the files in their revision control system and how those will be integrated.
• Will there be a verification step and if so who and how will that be performed. Especially important is the question of a reviewer understanding the translated language being integrated and how that is controlled.
• Will the project be paying for translations
• Will the project allow machine translations, if not can they be used as an initial hint (sometimes useful if the translators are weak in the "default" language

These are project policy decisions and, as I discovered, just as difficult to answer as the technical challenges.

Armed with my basic understanding it was time to move on and see how the transifex platform could be integrated into a real project workflow.
ImplementingProof of conceptMy first exercise was to take a trivial command line tool, use xgettext to generate a PO file and add the relevant libintl calls to produce gettext internationalised tool.

A transifex project was created and the english po file uploaded as the initial resource. A french language was added and the online editor used to provide translations for some strings. The PO resource file for french was exported and the tool executed with LANGUAGE=fr and the french translation seen.

This proved the trivial workflow was straightforward to implement. It also provided insight into the need to automate the process as the manual website operation would soon become exceptionally tedious and error prone.
Something more usefulTo get a better understanding of a real world workflow I needed a project that:

• Already internationalised but had limited language localisation
• Did not directly use gettext
• Had a code base I understood
• Could be modified reasonably easily.
• Might find the result useful rather than it being a purely academic exercise.

I selected the NetSurf web browser as it best fit this list.

Internally NetSurf keeps all the translated messages in a simple associative array this is serialised to an equally straightforward file named FatMessages. The file is UTF-8 encoded with keys separated from values by a colon. The Key is constrained to be ASCII characters with no colons and is structured as language.toolkit.identifier and is unique on identifier part alone.

This file is processed at build time into a simple identifier:value dictionary for each language and toolkit.

Transifex can import several resource formats similar to this, after experimenting with YAML and Android Resource format I immediately discovered a problem, the services import and export routines were somewhat buggy.

These routines coped ok with simple use cases but having more complex characters such as angle brackets and quotation marks in the translated strings would completely defeat the escaping mechanisms employed by both these formats (through entity escaping in android resource format XML is problematic anyway)

Finally the Java property file format was used (with UTF-8 encoding) which while having bugs in the import and export escaping these could at least be worked around. The existing tool that was used to process the FatMessages file was rewritten to cope with generating different output formats and a second tool to merge the java property format resources.

To create these two tools I enlisted the assistance of my colleague Vivek Dasmohapatra as his Perl language skills exceeded my own. He eventually managed to overcome the format translation issues and produce correct input and output.

I used the Transifex platforms free open source product, created a new project and configured it for free machine translation from the Microsoft service, all of which is pretty clearly documented by Transifex.

Once this was done the messages file was split up tinto resources for the supported languages and uploaded to the transifex system.

I manually marked all the uploaded translations as "verified" and then added a few machine translations to a couple of languages. I also created spanish as a new language and machine translated most of the keys.

The resources for each language were then downloaded and merged and the resulting FatMessages file checked for differences and verified only the changes I expected appeared.

I quickly determined that manually downloading the language resources every time was not going to work with any form of automation, so I wrote a perl script to retrieve the resources automatically (might be useful for other projects too).

Once these tools were written and integrated into the build system I could finally make an evaluation as to how successful this exercise had been.
ConclusionsThe main things I learned from this investigation were:

• Internationalisation has a number of complex areas
• Localisation to a specific locale is more than a mechanical process.
• The majority of platforms and services are oriented around textural language translation
• There is a concentration on the gettext mode of operation in many platforms
• Integration to any of these platforms requires both workflow and technical changes.
• At best tools to integrate existing resources into the selected platform need to be created
• Many project will require format conversion tools, necessitating additional developer time to create.
• The social issues within an open source project may require compromise on the workflow.
• The external platform may offer little benefits beyond a pretty user interface.
• External platforms introduce an external dependency unless the project is prepared and able to run its own platform instance.
• Real people are still required to do the translations and verify them.

The Linux init systems are a bit in flux at the moment. That is, they're in flux in Debian; outside Debian, most other distributions have stepped away from sysvinit and towards something else (systemd, openrc, or upstart). I've not been a proponent of any switch, though I understand the reasoning, and it probably makes sense for us to switch at some point. But yesterday, the fact that this customer's system was running sysvinit and not systemd or upstart saved me quite a bit. There's a server. It has one quadcore processor. For reasons that I won't go into here, the customer wants an extra quadcore processor to be added to the system. After having done so, I power on the system... only to see it power itself off at some point during boot. I did notice some kernel messages fly by just moments before the system would power itself off, but it was impossible for me to read them. So what did I do?

• Boot the system with init=/bin/bash,
• After having booted the system, go to /etc/rcS.d and manually run each and every one of the scripts there in turn. When the system powers off, I know what the problem is.
• Disable the init script that causes the problem, and boot the system normally.

That last bit is, obviously, a bit of an ugly workaround; the better way to fix this issue would have been to debug what the actual issue was, and implement a proper fix. However, I didn't have time for that (the fact that there was need for a second quadcore chip explains how much this system is in use), and the workaround was acceptable for the customer. It is not the first time that this ability to single-step the init system has saved me. The fact that sysvinit is so simplistic is what makes this possible, and I consider that one of its most important features. Recently, I came into contact with a distribution that uses systemd as its init system (in casu, Arch Linux). I had made a mistake in configuration; I had installed and enabled a graphical login system, but had no xterm or similar available, and had done something else wrong through which I couldn't get a regular shell on the console anymore, either. To fix this, I tried doing something like the above (running with init=/bin/bash and single-stepping the init system), but found that doing so with systemd is nigh impossible. In the end, I knew what exactly the problem was and could disable automatically starting the login manager through removing a symlink, but it brought home the issue that debugging a similar issue when running systemd rather than sysvinit might be a lot harder to do. We'll see what the future brings.