Hopefully hiding this post will work this time. Apologies if not. The UDD bugs interface currently knows about the following release critical bugs:

• In Total: 1080
  • Affecting Jessie: 276 That's the number we need to get down to zero before the release. They can be split in two big categories:
    • Affecting Jessie and unstable: 217 Those need someone to find a fix, or to finish the work to upload a fix to unstable:
      • 30 bugs are tagged 'patch'. Please help by reviewing the patches, and (if you are a DD) by uploading them.
      • 20 bugs are marked as done, but still affect unstable. This can happen due to missing builds on some architectures, for example. Help investigate!
      • 167 bugs are neither tagged patch, nor marked done. Help make a first step towards resolution!
    • Affecting Jessie only: 59 Those are already fixed in unstable, but the fix still needs to migrate to Jessie. You can help by submitting unblock requests for fixed packages, by investigating why packages do not migrate, or by reviewing submitted unblock requests.
      • 0 bugs are in packages that are unblocked by the release team.
      • 59 bugs are in packages that are not unblocked.

How do we compare to the Squeeze release cycle?

Week	Squeeze	Wheezy	Diff
43	284 (213+71)	468 (332+136)	+184 (+119/+65)
44	261 (201+60)	408 (265+143)	+147 (+64/+83)
45	261 (205+56)	425 (291+134)	+164 (+86/+78)
46	271 (200+71)	401 (258+143)	+130 (+58/+72)
47	283 (209+74)	366 (221+145)	+83 (+12/+71)
48	256 (177+79)	378 (230+148)	+122 (+53/+69)
49	256 (180+76)	360 (216+155)	+104 (+36/+79)
50	204 (148+56)	339 (195+144)	+135 (+47/+90)
51	178 (124+54)	323 (190+133)	+145 (+66/+79)
52	115 (78+37)	289 (190+99)	+174 (+112/+62)
1	93 (60+33)	287 (171+116)	+194 (+111/+83)
2	82 (46+36)	271 (162+109)	+189 (+116/+73)
3	25 (15+10)	249 (165+84)	+224 (+150/+74)
4	14 (8+6)	244 (176+68)	+230 (+168/+62)
5	2 (0+2)	224 (132+92)	+222 (+132/+90)
6	release!	212 (129+83)	+212 (+129/+83)
7	release+1	194 (128+66)	+194 (+128/+66)
8	release+2	206 (144+62)	+206 (+144/+62)
9	release+3	174 (105+69)	+174 (+105/+69)
10	release+4	120 (72+48)	+120 (+72/+48)
11	release+5	115 (74+41)	+115 (+74/+41)
12	release+6	93 (47+46)	+93 (+47/+46)
13	release+7	50 (24+26)	+50 (+24/+26)
14	release+8	51 (32+19)	+51 (+32/+19)
15	release+9	39 (32+7)	+39 (+32/+7)
16	release+10	20 (12+8)	+20 (+12/+8)
17	release+11	24 (19+5)	+24 (+19/+5)
18	release+12	2 (2+0)	+2 (+2/+0)

Graphical overview of bug stats thanks to azhag:

I like Drupal. It's a very, very flexible CMS that evolved into a full-fledged Web development framework. Mind you, it's written in PHP, and that makes it a nightmare to develop for (in ~6 years I have used it for all of my important websites I have only got around to develop a set of related modules for it once). PHP programming sucks and makes my eyes and fingers bleed, but happily there are people who disagree with me And they tend to write code. All the better! Minor upgrades with Drupal are quite easy to handle. Not as easy as I'd like (i.e. whenever I upgrade the core system or a module, I have to log in as root^Wadmin^WUser #1 to ~15 different sites and run http://someurl/update.php It very seldom causes any pain. The updates that have to be run via this URL are usually on the database's structures, so I understand they have to be started (and watched) by a human. And yes, I know I could do that with Drush, the Drupal shell, but it is not very friendly to Debian-packaged Drupal... But easy enoguh. But major updates are a royal pain, and they usually amount to quite a bit. First, disable all of the modules and revert to a known-safe theme. Ok, it makes sense. Second, check whether the modules exist for the newer version (as they won't work Drupal changes enough between major versions that not only it's API-incompatible, I'd classify it as API-unrecognizable). Ok, all set? Now for the live migration itself... It has to be triggered from the browser. So yes, I am now staring at a window making clever AJAX status updates. I am sitting at 46 of 199, but following the lovely ways of programmers, it's impossible to forsee whether update #47 will just be an UPDATE foo SET bar=0 WHERE bar IS NULL or a full-scale conversion between unspeakable serialized binary structures while rearranging the whole database structure. And yes, while the meter progresses I stand in fear that update #n+1 will bomb giving me an ugly red error. I must keep the magic AJAX running, or the update might be botched. And, of course, the update has sat at #69 all while I wrote the last two paragraphs. Sometimes the updates can progress after an interruption... And it seems I have no choice but to interrupt it. /me crosses fingers... [update] Wow... I am happy I got bored of looking at the meter and decided to write this blog post: After several minutes, and just as I was about to launch a second update session (130 updates to go), the meter advanced! I'm now sitting watching it at #75. Will it ever reach 199? [update] And so it had to be... At around 115, I now got: *sigh* The update process was aborted prematurely while running update #7000 in biblio.module...

Attachment	Size
drupal_updating.png	39.5 KB
drupal_updating_failed.png	64.72 KB

There is still a lot of things going on inside me and turning, and I'd like to share two words that I grow attached to, one a fair amount longer now than the other, but both are terms that I seem to had lacking in my vocabulary which I tried to explain in a different way. After finding out about them, I noticed that both what I felt and believed were actual things that were not totally uncommon concepts, even though most people wouldn't know about them. The first term that I stumbled upon years ago was the term of pansexuality. (Do not dare to read the German Wikipedia article. It's ridiculous wrong, insulting and shows that they don't understand the topic at all.) I always had issues to explain my intimate preference to others. Especially after they found out about me being female on the inside. Questions arose (if they understood that I'm open about these things when I post the poem publicly) along the lines of "what are you now: gay, lesbian, hetero and if the latter, what does that mean?". My usual answer was that I fall in love with people, not with their bodies, and that things will eventually work out if meant to be. And thus even though I love my "Bi" shirt, it doesn't really describe properly how I swing, so to say. The latter term I discovered just recently. A friend of mine with whom I chat every now and then told me about it, and when we met again last autumn, they wore a button of the Italian community for Polyamory (I so much prefer the Italian logo to the "widely used symbol", to be honest). It was an eye opening moment for me. I often mentioned to people that I felt like I have a big heart, being able to store multiple people in it. It always puzzled me that when I'm together with someone (and I always was faithful) why I should feel bad and especially keep it a secret when there is someone else who touches my heart, too. Society seems to see this already as a breach of trust, no matter whether it gets pursued or not, just the thought is enough. But it never changed anything with respect to the person I was together with, so what's the deal? Finding out about this term explained so much to me and made a lot of sense. It is about honesty and communication, which I see lagging in a lot of relationships these days... So here you are, getting another inside view on me. And I'm sure that there will be again the one or the other person who considers to use this as ammunition against me, but you know, being open about it acts as a shield. It's not embarrassing for me, never was. And like always, I hope that I can help others feeling similar being lost for words or an understanding that it's not as weird as it might feel. Enjoy!

/personal permanent link Comments: 9 Flattr this

Yesterday, the first milestone of the Havana developement branch of Ceilometer has been released and is now available for testing and download. This means the first quarter of the OpenStack Havana development has passed! New features Ten blueprints have been implemented as you can see on the release page. I'm going to talk through some of them here, that are the most interesting for users. Ceilometer can now counts the scheduling attempt of instances done by nova-scheduler. This can be useful to eventually bill such information or for audit (implemented by me for eNovance). People using the HBase backend can now do requests filtering on any of the counter fields, something we call metadata queries, and which was missing for this backend driver. Thanks to Shengjie Min (Dell) for the implementation. Counters can now be sent over UDP instead of the Oslo RPC mechanism (AMQP based by default). This allows counter transmission to be done in a much faster way, though less reliable. The primary use case being not audit or billing, but the alarming features that we are working on (implemented by me for eNovance). The initial alarm API has been designed and implemented, thanks to Mehdi Abaakouk (eNovance) and Angus Salkled (RedHat) who tackled this. We're now able to do CRUD actions on these. Posting of meters via the HTTP API is now possible. This is now another conduct that can be used to publish and collector meter. Thanks to Angus Salkled (RedHat) for implementing this. I've been working on an somewhat experimental notifier driver for Oslo notification that publishes Ceilometer counters instead of the standard notification, using the Ceilometer pipeline setup. Sandy Walsh (Rackspace) has put in place the base needed to store raw notifications (events), with the final goal of bringing more functionnalities around these into Ceilometer. Obviously, all of this blueprint and bugfixes wouldn't be implemented or fixed without the harden eyes of our entire team, reviewing code and advising restlessly the developers. Thanks to them! Bug fixes Thirty-one bugs were fixed, though most of them might not interest you so I won't elaborate too much on that. Go read the list if you are curious. Toward Havana 2 We now have 21 blueprints targetting the Ceilometer's second Havana milestone, with some of them are already started. I'll try to make sure we'll get there without too much trouble for the 18th July 2013. Stay tuned!

Give me a few days and I'll stop writing about Lumail, but tomorrow I intend to make the first stable source & binary release. From that point onwards you'll not need to track the github repository to getu pdates. The website has had an overhaul in advance of the release, but could still benefit from a logo. As usual I've written the website using my templer static-site generator. I hacked up a couple of plugins to make it easy to generate the pages of Lua primitive documentation, and handle cross-links suitably. (The source is available for reference.) The first binary release of the mail-client is obviously something of a big deal. I've been using the client daily for the past week or so, as a read-only mail-viewer. But now that the compose() and reply() primitives are present it is usable "for real". Having real scripting present is also allowing me to do interesting things, which are kinda/sorta demonstrated on the examples page. Now its a case of fixing up a couple of display-related glitches, and implementing things that are both missing and desirable. Happily the list of missing things is actually surprisingly small. I think the biggest outstanding issue is that the defaults are Steve-friendly, for example the colour-setup should probably be configurable. Beyond the personal-defaults I think the next biggest issue is the lack of threading support. Messages are displayed in oldest->newest order. Always. The other omission is that it is impossible to tag-things, in the mutt-sense, so you can't reply to two messages at once. That's a design decision I might have to revisit. The balance of course is that you can open multiple folders at once, and that rocks! Happy days.

Today, May the 30th, was my last day as a Mozilla employee. In a couple weeks, my wife, my cat and I will be on board of a flight heading about ten thousand kilometers east, and most of our stuff will be in some container on a boat. We re moving to Japan. As adventurous as this may sound, I m not venturing into unknown territory. My wife is Japanese, and I ve lived there for close to 15 months. A long time ago, arguably. I m not actually leaving Mozilla. I ll be back as a contractor, hopefully around the 25th of June. So as far as my fellow coworkers are concerned, I ll be going on a long-ish vacation and changing timezone (but I ll probably be around in the meanwhile on irc or bugmail, with high latency). Jump-starting in a different country is not something really easy to pull off, and working for Mozilla as a remotee has been a key element in being able to do so. Although I ve made it clear when I joined Mozilla that this would eventually happen, I m thankful I can now actually do it.

Review: Get Everything Done, by Mark Forster

Publisher:	Hodder & Stoughton
Copyright:	2000
ISBN:	0-340-74620-3
Format:	Trade paperback
Pages:	190

Mark Forster is the author of my (current) favorite time management book, Do It Tomorrow, and several excellent blog posts. I've therefore been rather curious about some of his earlier books, and finally decided to order this one. It appears to only have been published in the UK, so it can be a bit expensive in the US unless you can find it used. The main reason why I like Forster's writing so much is that he's a theory and neat trick sort of author instead of a single system author. A lot of time management writing (such as Getting Things Done) presents a single system that's supposedly universal. If that system happens to work for you, great. If it doesn't, the usefulness of the book drops off rapidly. You have to work through the basic principles, which are often sidelined in the book, and come up with variations on your own. Forster is the other sort of time management author: he throws out a flurry of tricks and tactics and lets you see which ones stick. He doesn't have a single system; indeed, one of the most entertaining parts of Get Everything Done is a parable about following many of the common time management systems and having one's life get worse and worse. Instead, he talks about the underlying theory, about the different approaches he's tried and their tradeoffs, and about lots of little tricks that he's found help in one situation or another. It's more of a toolkit than a system. This is, of course, only as good as the clarity of presentation. In both Do It Tomorrow and here, the clarity is excellent. For example, one of the most eye-opening ideas he explores in this book is that time management is a horrible name for the field. Time continues on no matter what you do; you can't increase it, and you can't save it. Rather, what you're actually doing is attention management: for each moment, you're deciding where to direct your attention. Things to which you turn your attention will change; things that you don't pay attention to will not change (except possibly for the worse). I'm quite fond of this reframing of the problem. Forster's thinking about time, or, rather, attention management is not as fully-developed here as in the later Do It Tomorrow. Much of the latter book is about the theory and practice of to-do lists. The techniques presented here were, at least for me, less immediately inspiring, although still thought-provoking. Much of the book focuses on internal resistance and procrastination, on the concept of self-control and decision-making as a mental "muscle" that has to be exercised, and on a philosophy of attention management that slowly builds up to doing whatever one is resisting the most at the moment. I haven't had a chance to work through the exercises that he offers (Forster's books tend to be full of illuminating exercises), so I don't have a fully-formed opinion on their efficacy. I was able to put Do It Tomorrow into practice more immediately. However, one thing this book does do is tackle directly the problem of trying to do too many things. Since this, more than organization, is the heart of my personal attention management problems, I was delighted to see this. Most attention management books at least give lip service to the problem, but they provide little useful guidance. David Allen's Getting Things Done effectively rules it out of scope: the goal of the system is to free you to act on your decisions, but there's little or no attention paid to the practical problem of making those decisions. As a result, I had serious trouble with GTD when I tried to use it. My project and next action lists would simply grow without bound, and GTD offered no useful assistance with culling them. Deciding what to do is, of course, a hard problem, but Forster here offers some specific and useful techniques and spends some time on the necessity of culling one's backlog. He also states directly the problem that everyone else seems to dance around: if you don't cull your committments, no attention management system will actually help you. It will just enable you to do trivia more efficiently, and therefore allow you to fill your life with even more of it, while still feeling just as overwhelmed as before. The bluntness is refreshing, and the exercises in cataloging commitments with time values and then forcing yourself to reduce the commitment list to the doable look quite helpful. I would still start with Do It Tomorrow rather than this book, since I think some practical approaches to to-do list management are one of the best places to start with attention management. But I'm glad I picked up this book as well, despite the cost of the UK import, and I plan on working through the exercises in it. Unlike David Allen, who has one basic system and whose other book was interesting but not as helpful, Forster's toolkit approach means that more books mean more ideas and more possible tools. He doesn't stick with one concept and polish it; he tries a lot of different ideas and then analyzes their strengths and weaknesses. If Do It Tomorrow spoke to you, I recommend grabbing this one as well. (Yes, it's somewhat amusing for me to read and review this book immediately after The Making of the Indebted Man, since to an extent attention management is part of the remaking of the self that's the obligation of the debtor in Lazzarato's construction of the nature of debt. It was something that occurred to me while reading this book. But I think Forster does a good job of showing attention management as a tool to direct one's efforts towards an internal goal rather than externally-imposed goals.) Rating: 8 out of 10

One thing that s always bugged me is this schism between graphic designers and hackers. Seeing as how most graphic designers learn how to code even if it s just JavaScript / CoffeeScript, HTML5, CSS3 / LessCSS or ActionScript / Flash. Almost no hackers learn how to design. And that s a problem. As a result, I ve started a real effort to learn the basics / fundamentals of design, in hopes that I can better communicate with my peers, create things that don t look like a 1992 timewarp and be able to finish a project and feel proud of what it is, as it is, even without a designer s help. I can only hope that it goes well, and others do the same.

A few days ago we the Qt/KDE team uploaded a new tool in the Qt ecosystem: qtchooser.

This tool is a wrapper tool used to select between different Qt versions. Of course, the first and easiest example is choosing between Qt4 and Qt5. But it doesn't end there: it can also be used to select a user's build of Qt.

To experienced Debian users, at first sight, it might resemble Debian's alternatives system. But it goes much further than that, allowing users (not sysadmins) to decide their defaults, and even adding new ones, user-wide. All this can be done using different methods like command line arguments, environment variables and configuration files.

Apart from all that, this is the recommended upstream way of managing Qt, being picked up by several (if not all) distributions, so it can easily be supported by upstream in their documentation.

My Qt4 package in Debian does not uses qtchooser, do I need to change anything?No, we have tried to make things as smooth as possible. Your Qt4 packages should be safe. There will be more info on this later.

My wife has had a LG Nexus 4 for about 4 months now so it s time for me to review it and compare it to my Samsung Galaxy S3. A Sealed Case The first thing to note about the Nexus 4 is that it doesn t support changing a battery or using micro-SD storage. The advantage of these design choices is that it allows reduced weight and greater strength compared to what the phone might otherwise be. Such choices would also allow the phone to be slightly cheaper which is a massive advantage, it s worth noting that the Nexus 4 is significantly cheaper than any other device I can buy with comparable specs. My wife s phone has 8G of storage (not RAM thanks Robin) and cost $369 at the start of the year while the current price is $349 for the 8G version and $399 for the 16G version. Of course one down-side of this is that if you need 16G of storage then you need to spend an extra $50 on the 16G phone instead of buying a phone with 8G of storage and inserting a 16GB micro-SD card which costs $19 from OfficeWorks. Also there s no option of using a 32G SD card (which costs less than $50) or a 64G SD card. Battery etc The battery on the Nexus 4 isn t nearly big enough, when playing Ingress it lasts about half as long as my Galaxy S3, about 90 minutes to fully discharge. If it was possible to buy a bigger battery from a company like Mugan Power then the lack of battery capacity wouldn t be such a problem. But as it s impossible to buy a bigger battery (unless you are willing to do some soldering) the only option is an external battery. I was unable to find a Nexus 4 case which includes a battery (which is probably because the Nexus 4 is a lot less common than the Galaxy S3) so my wife had to buy an external battery. If you are serious about playing Ingress with a Nexus 4 then you will end up with a battery in your pocket and cable going to your phone from the battery, this is a real annoyance. While being a cheap fast phone with a clear screen makes it well suited to Ingress the issue of having a cable permanently attached is a real down-side. One significant feature of the Nexus 4 is that it supports wireless charging. I have no immediate plans to use that feature and the wireless charger isn t even on sale in Australia. But if the USB connector was to break then I could buy a wireless charger from the US and keep using the phone, while for every other phone I own a broken connector would render the phone entirely useless. Screen Brightness I have problems with my Galaxy S3 not being bright enough at midday when on auto brightness. I have problems with my wife s Nexus 4 being too bright in most situations other than use at midday. Sometimes at night it s painfully bright. The brightness of the display probably contributes to the excessive battery use. I don t know whether all Nexus 4 devices are like this or whether there is some variance. In any case it would be nice if the automatic screen brightness could be tuned so I could make it brighter on my phone and less bright on my wife s. According to AndroSensor my Galaxy S3 thinks that the ambient light in my computer room is 28 lux while my wife s Nexus 4 claims it s 4 lux. So I guess that part of the problem is the accuracy of the light sensors in the phones. On-Screen Buttons I am a big fan of hardware buttons. Hardware buttons work reliably when your fingers are damp and can be used by feel at night. My first Android phone the Sony-Ericsson Xperia X10 had three hardware buttons for settings, home, and back as well as buttons for power, changing volume, and taking a photo which I found very convenient. My Galaxy S3 has hardware buttons for power, home, and volume control. I think that Android phones should have more hardware buttons not less. Unfortunately it seems that Google and the phone manufacturers disagree with me and the trend is towards less buttons. Now the Nexus 4 only has hardware buttons for power, and volume control. One significant advantage of the Galaxy S3 over the Nexus 4 is that the S3 s settings and back buttons while not implemented in hardware are outside the usable screen area. So the 4.8 1280*720 display is all for application data while the buttons for home, settings, and back on the Nexus 4 take up space on the screen so only a subset of the 4.7 1280*768 is usable by applications. While according to specs the Nexus 4 has a screen almost as big as the Galaxy S3 and a slightly higher resolution in practice it has an obviously smaller screen with fewer usable pixels. Also one of the changes related to having the buttons on-screen means that the settings button is often in the top right corner which I find annoying. I didn t like that aspect of the GUI the first time I used a tablet running Android 3.0 and I still don t like it now. GPS My wife s Nexus 4 seems to be much less accurate than my Galaxy S3 for GPS. I don t know how much of this is due to phone design and how much is due to random factors in manufacturing. I presume that a large portion of it is due to random manufacturing issues because other people aren t complaining about it. Maybe she just got unlucky with an inaccurate phone. Shape and Appearance One feature that I really like in the Samsung Galaxy S is that it has a significant ridge surrounding the screen. If you place a Galaxy S face-down on a desk that makes it a lot less likely to get a scratch on the screen. The LG U990 Viewty also had a similar ridge. Of course the gel case I have bought for every Android phone has solved this problem, but it would really be nice to have a phone that I consider usable without needing to buy such a case. The Nexus 4 has a screen that curves at the edges which if anything makes the problem worse than merely lacking a ridge around the edge. On the up-side the Nexus 4 looks and feels nice before you use it. The back of the Nexus 4 sparkles, that s nice but when you buy a gel case (which doesn t seem to be optional with modern design trends) you don t get to see it. The Nexus 4 is a very attractive package, it s really a pity that they didn t design it to be usable without a gel case. Conclusion Kogan is currently selling the Galaxy S3 with 16G of storage for $429. When comparing that to the 16G version of the Nexus 4 at $399 that means there s a price of $30 to get a SD socket, the option of replacing a battery, one more hardware button, and more screen space. So when comparing the Google offers for the Nexus 4 with the Kogan offer on the Galaxy S3 or the Galaxy Note which also has 16G of storage and sells for $429 the Google offer doesn t seem appealing to me. The Nexus 4 is still a good phone and is working well for my wife, but she doesn t need as much storage as I do. Also when she got her phone the Galaxy S3 was much more expensive than it is now. Also Kogan offer the 16G version of the Nexus 4 for $389 which makes it more appealing when compared to the Galaxy S3. It s surprising that they can beat Google on price. Generally I recommend the Nexus 4 without hesitation to anyone who wants a very capable phone for less than $400 and doesn t need a lot of storage. If you need more storage then the Galaxy S3 is more appealing. Also if you need to use a phone a lot then a Galaxy S3 with a power case works well in situations where the Nexus 4 performs poorly.

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

There's now no shortage of Linux distributions that support Secure Boot out of the box, so that's a mostly solved problem. But even if your distribution supports it entirely you still need to boot your install media in the first place.

Hardware initialisation is a slightly odd thing. There's no specification that describes the state ancillary hardware has to be in after firmware OS handover, so the OS effectively has to reinitialise it again. This means that certain bits of hardware end up being initialised twice, and that's slow in some cases. The most obvious is probably USB, which has various timeouts as you wait for hardware to settle. Full USB support in the firmware probably adds a couple of seconds to boot time, and it's arguably wasted because the OS then has to do the same thing (but, thankfully, can at least do other things at the same time). So, looking for USB boot media takes time, and since the overwhelmingly common case is that users don't want to boot off USB, it's time that's almost always wasted.

One of the requirements for Windows 8 certified hardware is that it must complete firmware initialisation within a specific amount of time, something that Microsoft refer to as "Fast Boot". Meeting these requirements effectively makes it impossible to initialise USB, and it's likely that certain other things will also be skipped. If you've got a USB keyboard then this obviously means that your keyboard won't work until the OS starts, but even i8042 setup takes time and so some laptops with traditional PS/2-style keyboards may not set it up. That means the system will ignore the keyboard no matter how much you hammer it at boot, and the firmware will boot whichever OS it finds.

For a newly purchased device, that's going to be Windows 8. It's not too much of a problem with a fully installed Windows 8, since you can hold down shift while clicking the reboot icon and get a menu that lets you reboot into the firmware menu. Windows sets a flag in a UEFI variable and reboots the system, the firmware sees that flag and does full hardware initialisation and then drops you into the setup environment. It takes slightly longer to get into the firmware, but that's countered by the time you save every time you don't want to get into the firmware on boot.

So what's the problem? Well, the Windows 8 setup environment doesn't offer that reboot icon. Turn on a brand new Windows 8 system and you have two choices - agree to the Windows 8 license, or power the machine off. The only way to get into the firmware menu is to either agree to the Windows 8 license or to disassemble the machine enough that you can unplug the hard drive[1] and force the system to fall back to offering the boot menu.

I understand the commercial considerations that result in it ranging from being difficult to impossible to buy new hardware without Windows pre-installed, but up until now it was still straightforward to install an alternative OS without agreeing to the Windows license. Now, installing alternative operating systems on many new systems will require you to give up certain rights even if you want nothing other than to reach the system firmware menu.

I'm firmly of the opinion that there are benefits to Secure Boot. I'm also in favour of setups like Fast Boot. But I don't believe that anyone should be forced to agree to a EULA purely in order to be able to boot their own choice of OS on a system that they've already purchased.

[1] Which is a significant and probably warranty-voiding exercise on many systems, and that's assuming that it's not an SSD soldered to the motherboard

comments

Almost every bug tracker for free software projects has a section for wishlist bugs. Often this results in ever growing lists of wishes, most of which will never be fulfilled. A long list of bugs, even if it is wishlist bugs, is rarely useful. It's hard to keep track of what is there, and so the information is not kept up to date when things change. Even if a wishlist bug gets implemented, the bug is often overlooked, and remains on the list. Joel Spolsky calls this a software inventory. Carrying a large inventory has costs, and usually results in slowed-down development. It increases the friction of doing things in a project. I have some quite old wishlists for my own projects. I have even more wishlists hidden in my own GTD system. I am not happy about either, and I'm going to have to do something about that. Just closing all wishlist bugs immediately would be bad manners. Keeping them open indefinitely, just in case someone will some day decide to look through the list in order to hack on something, is wishful thinking: that rarely happens. So I'm thinking of a compromise: keep wishlist bugs open for a while, perhaps a few months, and if nothing is happening to them, close them with an apology.