Review: Democracy at Work, by Richard WolffPublisher: Haymarket Copyright: 2012 ISBN: 1-60846-247-1 Format: Kindle Pages: 220
I've been reading (mostly on-line) and thinking quite a bit lately about workplace governance models, economic structure, and why the current organization of the US workplace bothers me so intensely, partly triggered by reading John Kenneth Galbraith's The Affluent Society. The economic monoculture has made that process particularly frustrating. It's rare to find a discussion, even in the context of organizational strategies that are considered radical, that avoids the standard frame of productivity and business value. Most discussion is long on tactics and short on strategy and examination of goals. Wolff's appearance on Moyers & Company was a rare breath of fresh air, enough so that I grabbed his book shortly afterwards.
Wolff is a Marxian economist (meaning that he makes use of Marxist analysis of economics and capitalism while separating them from Marxist politics and Marx's advocacy of revolutionary socialism), which for me was part of the interest. Marxist thought of any branch is not common in the United States; we're regularly deprived of several sides in the international conversation on economic models. I was taught Marxist theory in elementary and high school (in retrospect, surprisingly even-handedly and well, despite the biases of my schooling), but none of the later developments of Marxist thought. I think that's a typical experience here; in the United States, Marxism culminated in Mao and Stalin, and no further development of the underlying theories is ever mentioned.
Democracy at Work is subtitled A Cure for Capitalism and does indeed advocate a concrete alternative to capitalist business structures. But this is only the last third of the book (and in some ways the least useful, as I'll discuss in a moment). The first two-thirds of the book is basically a remedial education in modern, as opposed to historic, Marxian economics for US readers like myself who have never heard it before, cast in the context of the current financial crisis. This may well be old hat for Europeans, but if you've been wondering what (at least some) modern-day Marxists actually believe, or are saying to yourself "there are modern-day Marxists after the collapse of the Soviet Union?", I recommend this book to your attention. It's an excellent summary, which I read with the delightful feeling of an expanding viewpoint and the discovery of new directions from which to look at a problem.
There's quite a bit in this section that's worth thinking about, including another take on the nature of the recent economic collapse and how that fits into a Marxian analysis of capitalist crises. But there was one point in Wolff's explanation that I found particularly helpful. He completely restructured my understanding of the Marxian analysis of worker exploitation and profit allocation.
There are two angles of Marxist economic thought and socialist economics that get a great deal of attention, at least in the United States, in history and economics classes: the role (or lack thereof) of markets in price setting, and the ownership of the means of production. Defenders of capitalism like to focus on the former, since it's quite easy to identify the advantages of theoretical free markets in finding ideal prices and balancing supply and demand, whereas central planning of prices and production has resulted in some catastrophic and deadly failures. (Although I will note, with passing interest, that those failures predate large-scale computing, and there are now large corporations that manage budgets larger than some countries via centralized command-and-control economic practices.) Defenders of socialism are more likely to focus on the ownership of the means of production, since it's easy to show prima facie unfairness in owners of capital extracting vast profits without having to do any work themselves, only be lucky enough to start with large quantities of money.
Wolff, however, argues that both of these focuses misses a core critique by Marx of the workplace structure in capitalism, and that, by ignoring that critique, supposedly Marxist countries did not create anything that was actually Marxist in implementation. The Soviet Union was just as much a capitalist country as the United States is. It was state capitalism rather than private capitalism, but the core capitalist structure was intact.
Wolff arrives at this conclusion, which may be well-trodden ground in parts of the world that include active Marxist thought but which was quite startling to this American, by treating the ownership of capital as a partial distraction. He focuses on a more direct question and practical question: who determines what a worker does on a day-to-day basis and how that product is used? Who determines what profits are collected and how they are spent? In private capitalism, this is done by the owners of the capital: large shareholders, major investors, and the managerial class that they hire. In Soviet state capitalism, this is done by national politicians, bureaucrats, and the managerial class that they hire. In neither model is it done by the workers themselves. The Soviet model gives theoretical ownership of the capital to the workers, but that ownership is diffused, centralized, and politicized, redirected through the mechanisms of the state, and therefore is effectively ignored. Ownership and control is entirely captured by the political class.
Both of these systems are capitalist in Wolff's view of Marx: there is a class of owners and managers, who control the terms and nature of work and who allocate the profits, and a class of workers, who have to do what they're told, are not paid full value for their labor, and don't have a say in how the profits their work generates are spent. At the most important level of day-to-day autonomy and empowerment, they are functionally identical. They are both equally hierarchical and exploitative; the only difference is in whether the system is controlled by rich individuals or by well-connected politicians. (And, as any study of modern politics quickly reveals, the distinction between those two groups in most countries is murky at best.)
Wolff convincingly recasts modern economic history as a constant pendulum swing between private capitalism and state capitalism. Crises in one system push countries towards the other system; subsequent crises push the country back towards the first system. Regulation grows and shrinks, companies are nationalized and then privatized, but both systems are united in excluding the worker from any meaningful control over their work life.
The first two-thirds of the book was full of insights like this for me. I didn't agree with all of it, but all of it was worthwhile and thought-provoking. But I was a bit leery of Wolff's proposed solution. My past experience with critics of capitalism is that the critique is often quite compelling, but the proposed solution is much less believable. And, sadly, that concern was warranted here as well.
The core of Wolff's proposal is predictable but possibly sound: a restructuring of the workplace to be radically democratic. The business would be owned entirely and exclusively by the people who work for it, equally regardless of the job of the worker, and the workers would decide democratically or via elected repesentatives from among the workers how to allocate the profits of the business, what standards and business practices should be followed, and how the work is to be done. I was particularly interested to hear that this model (workers' self-directed enterprises) has apparently been successful in Spain in the form of the Mondragon Cooperative. Given all the tricky, small details that have to be resolved in an actual workplace, an existence proof is worth more than pounds of theory.
Unfortunately, like a lot of proposed alternatives, Wolff's description of WSDEs is quite fuzzy and involves a lot of hand-waving. I was never able to build, from this book, a coherent and complete mental model of how such a workplace would function. Wolff tends to surround every specific in a halo of contingencies, possibilities, and alternative models, and is maddeningly nonspecific on such practical matters as how line management would work, how such a business would do financial planning or project approval, how competing interests in different parts of the organization would be balanced, and other practical governance matters that fill my work life. Maybe the answer to all of that is just "democracy," but I'm dubious.
Democracy has a number of well-known flaws that I thought weren't adequately addressed. For example, democracies are often quite happy to further and reinforce existing prejudice (such as sexism or racism), and are prone to yielding control to the most charismatic. Democracies also have an informed voter problem, which seems like it would be particularly acute if democracy is going to make detailed business decisions. And, for larger organizations, control by pre-existing money could re-enter the equation via propaganda and campaigning around votes. Some of this gap in the book could be addressed via a more in-depth look at how Mondragon and any other real-life examples work, but that is sadly missing here. (I am interested enough now, though, that I'd read a good popular treatment of the history and methodology of Mondragon, although I don't think I'm up to working through an academic study.)
The hierarchical, dictatorial management structure imposed by capitalism is so awful that WSDEs don't have a particularly high bar to meet to be fairer and more empowering than what we have today. The question, rather, is would they function sufficiently well that the business would be able to make effective decisions, and that's unclear to me from this book. This is, as Wolff spends some time discussing, particularly difficult when in direct competition with capitalist enterprises. This sort of endeavor will probably trade some degree of economic efficiency and raw marketplace power for improvements to fairness and empowerment, but that means it's going to require support from the surrounding society, which is a huge obstacle. I doubt there's a free lunch here: true fairness and equity also leading to improved economic efficiency in a capitalist context is a nice dream, but not horribly practical.
Wolff also seems to suffer from something else I associate with Marxist thought: a preferential focus on a very narrowly-defined type of productive worker, apparently left over from Marx's original critique in the context of industrialization. Wolff inserts a very odd and quite awkward distinction in his WSDE model between workers who directly produce the product that's sold, and who in his model therefore produce the profits of the business, and all other workers in the business. He then gives special privileges to the former group to decide how much profit to return in worker compensation and how much to use for other purposes, thus making the supporting workers second-class citizens within this supposedly equal workplace.
Speaking as someone who works in IT, and hence would be classified by Wolff into the supporting rather than directly productive category, I do not find this division at all convincing, and Wolff never provides a coherent explanation for why he introduced it. He only says that it's necessary for the governance of the business to not be exploitative, which seems to assume that there is a special economic role played by the workers who work directly on a saleable product. Maybe there is some analysis that could convince me of this, but, if so, it's not present in this book. It struck me as a recipe for continuing the exploitation of the most invisible and powerless workers in capitalism: janitors, groundskeepers, and other low-paid service jobs.
I wish the whole book were as insightful and pointed as the first two-thirds, but alas I found the WSDE discussion to be somewhat muddled and utopian. "How do we get there from here" is always the hardest part of this type of discussion, and Wolff has no special skill in that department. But, despite that, I got a lot of fascinating ideas and new conceptual frameworks out of this book, and I'm tempted to read it again. I suspect some of this, similar to my discovery of promises and infinite streams in programming, is filling in of odd gaps in my personal education rather than a discovery of unusual, new ideas. But if you too have gotten your political education within the US capitalism über alles bubble, this book may fill in similar gaps in your knowledge. If so, it's a very rewarding experience.
If you're curious about a preview of Wolff's perspective without paying for the book, I recommend watching the first episode of Moyers & Company in which he appeared. Wolff is a clear and engaging speaker, and his interview provides a good feel for his discussion style and his general perspective.
Rating: 8 out of 10
Comparing this to 2012, this curve is much more flat in the beginning but exponentially increasing towards the end. Why is that? We didn't change the way we engaged with students (even though we tried to improve the instructions and added lots of entrance tagged tasks to github issues). We still require patches to be submitted to even be considered. So it is similarly tough to get into gsoc 2013 with us as it was in the previous year.
What is interesting though is that various organizations complained about a slow uptake in the beginning. And it turns out that google did limit the number of student applications from 20 (last year) to 5 (in 2013). This might explain the shape of the curve: Students are more cautious to apply but once the deadline is near the apply to the maximum of 5 to improve their chances. This goes hand-in-hand with the observation that the quality of newly submitted student applications tends to decrease towards the deadline.
So did this new limit hurt? To the contrary! In the end the quality of proposals increased a lot and we were able to even way before the student application deadline start to score/rank students. We are happy to have many very strong candidates this year again. Lets hope we get enough slots to accommodate all of the excellent students and then lets start the fun :)
For (at least) the third time, I managed to register for debconf before registration was actually open. Oops.
I found out that unfortunately, it's not quite certain yet that there will actually be a debcamp this year—and if there is going to be a debcamp, it won't be a full week. Pity. At any rate, I'll be there the whole time, whatever the duration of debcamp.
Since Vaumarcus is closer to Mechelen than Edinburgh (by about 250km), this is going to be the closest debconf for me, ever. And if I could go to Banja Luka by car, I can certainly go to Vaumarcus by car.
Anyone care to join me?
Tomorrow morning at around 0900 UTC, a lot of very dedicated people will start working on the actual release of Debian 7.0 (wheezy).
A huge thank you to everyone who worked on getting Debian to this point.
I for one welcome our new penguin overlord!Housekeeping
These will obviously be the last rc bug stats in this release cycle. I am still unsure what to do with this particular series until the next freeze and feedback would be appreciated. Possible approaches are continuing as is, putting this into its own specific feed, decreasing the frequency to once a month, or to simply stop until jessie is frozen. An ikiwiki poll may be overkill. Or not.Remaining bugs
As of right now, there are two bugs open:
- #645713 - "apt" - many squeeze->wheezy upgrades fail with "Could not perform immediate configuration"
- #706641 - "apt, libgd-text-perl" - apt, libgd-text-perl: fails to upgrade from squeeze: Could not perform immediate configuration on 'libgd-gd2-perl'.
Both relate to weird behaviour by apt when upgrading from squeeze to wheezy. These bugs will not be truly closed, but merely ignored, for wheezy's release. If you happen to encounter the message above, it's best to consult the release notes for possible workarounds.Stats
The UDD bugs interface currently knows about the following release critical bugs:
- In Total:
- Affecting wheezy:
2 That's the number we need to get down to zero before
the release. They can be split in two big categories:
- Affecting wheezy and unstable:
2 Those need someone to find a fix, or to finish the
work to upload a fix to unstable:
- 0 bugs are tagged 'patch'. Please help by reviewing the patches, and (if you are a DD) by uploading them.
- 0 bugs are marked as done, but still affect unstable. This can happen due to missing builds on some architectures, for example. Help investigate!
- 2 bugs are neither tagged patch, nor marked done. Help make a first step towards resolution!
- Affecting wheezy only: 0 Those are already fixed in unstable, but the fix still needs to migrate to wheezy. You can help by submitting unblock requests for fixed packages, by investigating why packages do not migrate, or by reviewing submitted unblock requests.
- Affecting wheezy and unstable: 2 Those need someone to find a fix, or to finish the work to upload a fix to unstable:
- Affecting wheezy: 2 That's the number we need to get down to zero before the release. They can be split in two big categories:
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:
There were two competing free software projects, doing more or less the same thing. Project B was in active development 3 years before Project R showed up, and then the two competed for quite some time.
While Project B seemed to operate as part of the gift economy, Project R was developed by folks who had received some monetary funding, and once their funding began to wane, they began to complain. Eventually fundraising campaigns were held.
The community was happy to participate in polite fictions: Project B didn't really exist; the only people who could possibly fix the bugs in Project R were the people demanding money; there would be no conflict of interest between the gatekeepers of Project R.
Gradually, all development ceased on Project B and never resumed. The leader of Project R kept jumping up and down and demanding more money, until finally he declared it insufficient.
Then there were two dead codebases.
It shows a smiling, attractive man, with text next to him saying something like "I told 9000 people what smartphone to buy".
What happened here?
- A TV channel bought an ad on the side of a bus
- trying to demonstrate to other advertisers
- about how good their viewers are at providing advertising-by-proxy
- on services that themselves are mostly advertising platforms
- to sell devices that are themselves often used for advertising delivery.
And almost all of these steps count as positive economic activity when we try to measure whether the US economy is healthy.
I am depressed by this tremendous waste of time and effort.
Registration is now open for DebConf13, which will take place in Le Camp near Vaumarcus, Switzerland, from Sunday 11 August to Saturday 17 August 2013. The registration deadline for those who wish to make sponsorship applications is Wednesday 15 May 2013. After this date, you can still register, but you will need to pay for accommodation and food.Registration
If you want to attend DebConf13, go to the Registration page and follow the procedure outlined there. Please even read the website page if you attended previous conferences, because it explains some important changes with respect to previous years.DebCamp
We are planning to prepend the current DebConf week with additional DebCamp days, but we need some more time to sort out the details. We also need more money to be able to fully sponsor DebCamp for everyone or to extend it to more than a few days. If you would like this to happen, please contact us and help find additional sponsorship. We will send another announcement about DebCamp as soon as registration for DebCamp opens.Thank you
We look forward to welcoming you to Le Camp in August!
The DebConf team
DebConf team: The DebConf13 matching fund completes, raising 2500 USD, twice (Posted by Didier Raboud)
The DebConf13 matching fund announced previously is now complete. The matching sponsor, Brandorr Group will match the collected amount of 2513 USD, resulting in 5026 USD of sponsoring money for DebConf13, for the benefit of all attendees.
Despite raising only slightly more than half of the expected money, this first experience of raising funds through this matching fund mechanism can be considered successful.DebConf is very important to the health of Debian, and Debian is very important to our team, so we’re doing what we can to help. In this case we really wanted to see if we could provide an incentive for individual users of Debian to donate to the project. It seems like it worked well, and we’d love to do something like this again in the future. Brian Gupta, Brandorr Group
Registration for DebConf13 will be opening shortly: stay tuned!
We look forward to welcoming you to Vaumarcus!
Debian wheezy includes a bunch of excellent new Haskell libraries. I'm going to highlight one that should be interesting to non-Haskell developers, who may have struggled with writing non-buggy threaded programs in other languages: libghc-stm-dev
I had given up on most threaded programs before learning about Software Transactional Memory. Writing a correct threaded program, when multiple threads needed to modify the same state, needed careful uses of locking. In my experience, locking is almost never gotten right the first time.
A real life example I encountered is an app that displays a queue of files to be downloaded, and a list of files currently downloading. Starting a new download would go something like this:
startDownload = do file <- getQueuedFile startDownloadThread file push file currentDownLoads
But there's a point in time in which another thread, that refreshes the display, could then see an inconsistent state, where the file is in neither place. To fix this, you'd need to add lock checking around all accesses to the download queue and current downloads list, and lock them both here. (And be sure to always take the locks in the same order!)
But, it's worse than that, because how is getQueuedFile implemented? If the queue is empty, it needs to wait on a file being added. But how can a file be added the queue if we've locked it in order to perform this larger startDownload operation? What should be really simple code has become really complex juggling of locks.
STM deals with this in a much nicer way:
startDownload = atomically $ do file <- getQueuedFile startDownloadThread file push file currentDownLoads
Now the two operations are performed as one atomic transaction. It's not possible for any other thread to see an inconsistent state. No explicit locking is needed.
And, getQueuedFile can do whatever waiting it needs to, also using STM. This becomes part of the same larger transaction, in a way that cannot deadlock. It might be implemented like this:
getQueuedFile = atomically $ if empty downloadQueue then retry else pop downloadQueue
When the queue is empty and this calls "retry", STM automatically waits for the queue to change before restarting the transaction. So this blocks until a file becomes available. It does it without any locking, and without you needing to explicitly tell STM what you're waiting on.
I find this beautiful, and am happier with it the more I use it in my code. Functions like getQueuedFile that run entirely in STM are building blocks that can be snapped together without worries to build more and more complex things.
For non-Haskell developers, STM is also available in Clojure, and work is underway to add it to gcc. There is also Hardware Transactional Memory coming, to speed it up. Although in my experience it's quite acceptably fast already.
However, as far as I know, all these other implementations of STM leave developers with a problem nearly as thorny as the original problem with locking. STM inherently works by detecting when a change is made that conflicts with another transaction, throwing away the change, and retrying. This means that code inside a STM transaction may run more than once.
Wait a second.. Doesn't that mean this code has a problem?
startDownload = atomically $ do file <- getQueuedFile startDownloadThread file push file currentDownLoads
Yes, this code is buggy! If the download thread is started, but then STM restarts the transaction, the same file will be downloaded repeatedly.
The C, Clojure, etc, STM implementations all let you write this buggy code.
Haskell, however, does not. The buggy code I showed won't even compile. The way it prevents this involves, well, monads. But essentially, it is able to use type checking to automatically determine that startDownloadThread is not safe to put in the middle of a STM transaction. You're left with no choice but to change things so the thread is only spawned once the transaction succeeds:
startDownload = do file <- atomically $ do f <- getQueuedFile push f currentDownLoads return f startDownloadThread file
If you appreciate that, you may want to check out some other #newinwheezy stuff like libghc-yesod-dev, a web framework that uses type checking to avoid broken urls and XSS attacks, and also makes heavy use of threading, so is a great fit for using with STM. And libghc-quickcheck2-dev, which leverages the type system to automatically test properties about your program.
Here’s the next bunch, this time web browsers:
- surf and xxxterm
- Surf and XXXTerm are both simple and minimalistic webkit-based browsers. Surf is easy to embed in other applications and XXXTerm features vi-like keybindings for heavy keyboard users.
To be continued… ;-)
There are (at least) two new SSH related tools new in Debian Wheezy:
- is the “mobile shell”, an UDP based remote shell terminal which works better than SSH in case of lag, packet loss or other forms of bad connection. I wrote about mosh in more detail about a year ago. mosh is also available for Debian Squeeze via squeeze-backports.
- is somewhere between port-forwarding and VPN. It allows forward arbitrary TCP connections over an SSH connection without the need to configure individual port forwardings. It does not need root access on the server-side either. I wrote about sshuttle in more detail about a year ago.
To be continued… ;-)
Following up on the #newinwheezy game: Debian/wheezy is the first Debian release which ships packages from the Grml system. Grml became an official Debian Derivative and I’m very happy that three major projects of Grml found their official way into Debian:
- grml2usb: install Grml system / ISO to usb device
- grml-debootstrap: wrapper around debootstrap for installing pure Debian
- grml-rescueboot: Integrates Grml ISO booting into GRUB
As the description states grml2usb is interesting for getting Grml onto a USB device when the dd(1) approach (“dd if=grml.iso of=/dev/sdX“) just isn’t flexible enough.
grml-debootstrap provides a decent way to install Debian systems from the command line. As its author I might be biased but I’ve to mention that it’s working so nice that it is in use at several of my customers for automated roll-outs without any worries at all, and I got reports from other companies that they are very happy users of it as well.
Finally the grml-rescueboot packages provides a very simple and nice way to boot a rescue system from within GRUB (short version: throw a Grml ISO to /boot/grml/, run update-grub and be done).
PS: Thanks everyone for joining the #newinwheezy game over at planet.debian.org.
Compared to the numbers from last year, today Debian is being served via http by about 370 mirrors world-wide, and is also available via ftp from 330 mirrors. So that's an increase of 40 mirrors in one year!
The number of countries with Debian mirrors also increased to 76, 3 more since last year.
This has only been possible thanks to the sponsors hosting the mirrors.
During this year some sponsors have had to retire their mirrors, sometimes ceasing years of contributions to the project and its community.
A big thanks is deserved to past and current sponsors.
Review: The System of the World, by Neal StephensonSeries: The Baroque Cycle #3 Publisher: William Morrow Copyright: 2004 ISBN: 0-06-052387-5 Format: Hardcover Pages: 892
This is the third book of the three-volume Baroque Cycle. I think you could, if you really wanted, read it without reading the previous volumes; Stephenson is certainly long-winded enough that you can pick up most of what's going on while you read. It's been a year since I read the second volume, and I only resorted to Wikipedia a couple of times to remember plot elements (and mostly from the first book). However, I wouldn't recommended starting here. Many of the character relationships, and most of the underpinning of the plot, is established in the previous volumes and given more significance by them. You would also miss The Confusion, which is the best book of the series, although none of this series rises to the level at which I'd recommend it except under specific circumstances.
Quicksilver establishes the characters of Daniel Waterhouse, a fictional Puritan whose family was close to Cromwell and who became a friend to Isaac Newton in the days following the Restoration; Jack Shaftoe, a vagabond who wanders Europe in a sequence of improbable adventures; and Eliza, who becomes a friend to Leibniz and a spy for William of Orange. The Waterhouse sections are prominent in Quicksilver: full of the early history of the Royal Society, alchemy, and a small amount of politics. Of those three characters, Eliza is by far the most interesting, which meant that I was delighted when The Confusion dropped Waterhouse almost entirely and mixed Eliza's further story with more improbable but entertaining sea adventures of Jack Shaftoe.
You will immediately sense my root problem with The System of the World when you hear that it is almost entirely about Daniel Waterhouse. While Eliza and Jack both appear, they play supporting roles at best, and Eliza's wonderful sharp intelligence and pragmatic survival skills are left out almost entirely.
Instead, this is a novel about Waterhouse's return to England after spending quite a bit of time in the American colonies working on calculating machines. He is almost immediately entangled in dangerous politics from multiple directions: the precarious national politics in England near the end of the reign of Queen Anne, Isaac Newton's attempts to maintain the currency of England as Master of the Mint, and a bombing attempt that may have been aimed at him, may have been aimed at Newton, and may have been aimed at someone else entirely. Much of the book consists of an extended investigation of this bombing plot, skullduggery involving counterfeiters, and attempts to use the currency and the Mint as part of the political conflict between Whigs and Tories, mixed in with attempts to construct a very early computer (this is Stephenson, after all). Leibniz and Eliza come into this only as confidants of the Hanoverians.
All this may sound exciting, and there are parts of it that hold the attention. But this book sprawls as badly as Quicksilver did. There's just too much detail without either enough plot or enough clarity. Stephenson tries to make you feel, smell, and hear the streets of London and the concerns of an idiosyncratic group of semi-nobles during one of the more interesting junctures of British history, but he does that by nearly drowning you in it, and without providing enough high-level guidance. For most of the book, I felt like I was being given a tour of a house on my hands and knees with a magnifying glass. It's a bad sign when the reader of a historical novel is regularly resorting to Wikipedia, not to follow interesting tangents of supporting material, but to try to get a basic sense of the players and the politics involved because the author never explains them clearly.
If you're more familiar with the details of British history than I am, and can more easily follow the casual intermixing of two or three forms of address for the same historical figure, you may not have that problem. But I think other structural issues remain, and one of the largest is Waterhouse himself.
Jack Shaftoe, and particularly Eliza, are more interesting characters because they're characters. They're not always particularly believable, but they attack the world with panache and are constantly squirming into the center of things. Stephenson's portrayals of Newton, Leibniz, the Duke of Marlborough, Sophia of Hanover, Peter the Great, and the other historical figures who show up here are interesting for different reasons: Stephenson has history to draw on and elaborate, and it's fascinating to meet those people from a different angle than dry lists of accomplishments. History has a way of providing random details that are too bizarre to make up; Isaac Newton, for example, actually did disguise himself to infiltrate London criminal society in pursuit of counterfeiters while he was Master of the Mint!
Waterhouse, for me, has none of these advantages. He is an invented character in whom I have no pre-existing interest. He drifts through events largely through personal connections, all of which seem to be almost accidental. He's welcome in the councils of the Royal Society because he's apparently a scientist, but the amount of actual science we see him doing is quite limited. His nonconformist background allies him squarely with the Whigs, but his actual position on religious matters seems much less set than the others around him. What he seems to want, more than anything else, is to help Leibniz in the development of a computer and to reconcile Newton and Leibniz. And he's not particularly effective at either.
In short, he has little in the way of memorable character or dynamism, despite being the primary viewpoint character, and seems to exist mostly to know everyone and be everywhere that's important to the story. He feels like an authorial insertion more than a character. It's quite easy to believe that Stephenson himself would have loved to be in exactly the role and situation that Waterhouse finds himself in throughout the book, in the middle of the councils of the wise and powerful, in just the right position to watch the events of history. I can sympathize, but it doesn't make for engrossing reading. Novels live and die by the strength of their characters, particularly their protagonists; I want more than just a neutral viewpoint.
The third major structural problem that I had with this book is that I think Stephenson buries his lede. After finishing it, I think this is a book with a point, a central premise around which all the events of the story turn, and which is the philosophical culmination of The Baroque Cycle as a whole. But Stephenson seems oddly unwilling to state that premise outright until the very end of the book. For the first half, one could be forgiven in thinking this is a story about alchemy and the oddly heavy gold that's been a part of the story since The Confusion, or perhaps about foundational but forgotten work on computation that preceded Babbage by a century. But those all turn out to be side stories, sometimes even without a proper conclusion. I appreciate honoring the intelligence of the reader, and I presume that Stephenson would like to guide the reader through the same process of realization that the characters go through, but I think he takes this much too far and fails to make the realization clear.
I'll therefore state what I believe is the premise outright, since I think it's a stronger book with this idea in mind: The System of the World is a continuation of the transformational economics shown in The Confusion into the realm of politics. Specifically, it's about the replacement of people with systems, about the journey towards Parliamentary supremacy, central banking, and the persistent state, and about the application of scientific principles of consistency and reproducibility to politics and economics (however fitfully and arbitrarily). Quicksilver was about the rise of science; The Confusion was, in retrospect, about the rise of economics; and The System of the World tries to be about the rise of technocratic modern politics, barely perceptible among the squabbles between Tories and Whigs.
I think that's a fascinating premise, and I would have loved to read a book that tackles it head-on. That's a concept that is much more familiar from the late 19th and early 20th centuries in the context of Marxism, early socialism, technological utopianism, and similar attempted applications of scientific analysis to political and human behavior for the betterment of human civilization. Shifting that 200 years earlier and looking at a similar question from the perspective of the giants of the Enlightenment feels full of of potential. There are moments when I think Stephenson captures the sense of a seismic shift in how economies are run, knowledge is established, and civilizations are knit together. But, most of the time, it just isn't clear. There's so much other stuff in this book, and in the whole series: so many false starts, digressions, abandoned plots, discarded characters, and awkward attempts at romance (as much as I like the characters, Stephenson's portrayal of the relationship between Eliza and Jack is simply ridiculous and not particularly funny) that the whole weight of the edifice crushes what I think is the core concept.
Stephenson is never going to be sparse. When you start a Stephenson novel, you know it's going to be full of chunks of partly digested encyclopedia and random research findings that may have nothing to do with the plot. But his best books (Snow Crash, The Diamond Age, even Cryptonomicon) have an underlying structure off of which all of those digressions are hung. You can see the bones beneath the flesh, and the creature they create is one you want to get to know.
I'm not sure there are any bones here, and that may be the peril, for Stephenson, of writing historical fiction. I wonder if he felt that the structure of history would provide enough structure by itself that he could wrap a few plots around the outside of it and call it good. If so, it didn't work, at least for me. A lot of things happen. Some of them are even exciting and tense. A lot of people meet, interact, and show off their views of the world. A great deal of history, research, and sense of place is described in painstaking detail. But at the end of the book, I felt like I had to reach for some sort of point and try to retrofit it to the story. Lots happened, but there wasn't a novel. And that makes it quite hard to get enthused by the book.
If you adored Quicksilver, I suspect you will also like this. I think they're the most similar. If, like I did, you thought The Confusion was a significant step up in enjoyment in the series and were hoping the trend will continue, I'm sad to report that it didn't.
If you were considering whether to read the whole series and were waiting to see what I thought of the end, my advice is to give The Baroque Cycle a pass unless you absolutely love Stephenson's digressions, don't care if they're about history instead of current technology, and cannot live without 3,000 pages of them. It's not that they're bad books, but they're very long books, they take a significant investment of time and attention, and I think that, for most readers, there are other books that would repay a similar investment with more enjoyment.
Rating: 5 out of 10
Recently, some folks have brought it to my attention that I’m not so good at making my work with Ubuntu known.
I’d like to clarify my role. Yes, I’m still an Ubuntu member. Yes, I’m still active. Yes, I care about Ubuntu. A lot. To insinuate otherwise is wholly wrong. I’ve been with Ubuntu for just about 5 years now, and to misrepresent that would be a damn shame.
I mostly do work in Debian these days, where I make sure packages upstream support Ubuntu, and work to help create a solid Debian, which provides a strong base for Ubuntu to work from.
Every Debian developer is also an Ubuntu developer, because one way to contribute to Ubuntu is to contribute to Debian.
I also spend time to make sure Ubuntu / Debian relations remain strong, and that Debian folks know they can count on a friendly face to interface with the Ubuntu’ers, or the Ubuntu’ers knowing they can count on a friend to help.
To be clear; I’m not active in the Ubuntu community channels anymore. I’m still very much active with Ubuntu on the whole.
Hope that clears things up for folks.
Unfortunately, as always seems to happen with large releases, one of the features that we added in WebAuth 4.5.0 wasn't adequately tested and had some lingering issues.
In this case, it was a last minute change: from a UI perspective, we decided it was better to present the user with a checkbox (checked by default) saying "remember my login on this computer" instead of a checkbox (off by default) saying "this is a public computer; don't remember me." People are much more familiar with the former than the latter. Unfortunately, due to how HTML checkboxes work, this required changing the default in the code, and that turned out to break single sign-on completely. We were assuming we should not maintain single sign-on credentials by default, so all the WebLogin interactions that never passed through the forms so that the form could establish a default would delete the cookies.
This should be all sorted out in this release, along with a few other edge cases that became apparent when I thought harder about this. The documentation also makes clearer the required template changes when upgrading from versions prior to 4.5.0. We also snuck in one new feature: the user information service can pass a message to the user through to the confirmation page.
SIP is widely implemented in free software, in standalone products such as Lumicall and in Linux distributions such as Debian that carry a wide variety of SIP servers, SIP proxies and SIP clients, including the default chat client Empathy
It remains to be seen whether they will engage in a similar attack on related protocols like XMPP / Jabber
Many of the VoIP companies under attack are heavy users of free software
This is my monthly summary of my free software related activities. If you’re among the people who made a donation to support my work (102.70 €, thanks everybody!), then you can learn how I spent your money. Otherwise it’s just an interesting status update on my various projects.Debian France
Work on Galette. I spent quite some time on Debian France’s galette installation (the web application handling its member database), first converting its Postgres database to UTF-8, then upgrading to 0.7.4 while working-around many known problems.
But every time I use galette, I tend to find something to report. This month I filed 5 tickets:
- #588: galette should offer a way to send a test mail while setting up the mail notifications
- #589: CSV export page contains an invalid download link
- #590: confirmation page of a successful PayPal payment contains empty fields
- #591: problem with the selection of recipients of a mailing
- #595: galette should put a proper recipient in the “To:” field of automatically generated mails.
I tested quite some fixes prepared by the upstream author (3 of the above bugs are already fixed) and this lead to the 0.7.4.1 bugfix release.
Preliminary work on new bylaws. I have setup a git repository to make it easier to collaborate on new versions of our bylaws and internal rules. The goal is to make Debian France a trusted organization of Debian and to update everything to be compliant with the “association 1901” law (we currently have a special statute reserved to associations from Alsace/Moselle).Kali Linux
Improve accessibility support in Debian Wheezy. Offensive Security wanted Kali Linux to be fully accessible to disabled people. Since Wheezy was suffering from some serious regressions in that area, we hired Emilio Pozuelo Monfort to fix #680636 and #689559 in gdm3. On my side, I updated debian-installer’s finish-install to correctly pre-configure the system when you make an install with speech synthesis (patch submitted in #705599).
Thanks to accommodating release managers, this work has already been integrated in Wheezy and won’t have to wait the first point release.
Fix bugs in Debian’s live desktop installer. We also wanted to enable the desktop installer in the Kali live DVD. While our first tries a few months ago failed, this time it worked almost out of the box (thanks to Ben Armstrong who fixed it). I still identified a few issues that I fixed in debian-installer-launcher’s git repository.Packaging and misc Debian work
- I reviewed the work of Charles Plessy who drafted an important update of the Debian Policy to document dpkg triggers (see #582109)
- I reviewed the libwebsockets package prepared by Peter Pentchev (ITP 697671)
- I discovered Tanglu and joined their mailing list because I want to watch its evolution (and maybe use it as a test-bed for some future infrastructure developments).
- I reviewed and committed a patch of Robert Spencer on debian-cd (see #703431).
- I packaged version 3.3 of cpputest (in experimental). I tested a new upstream snapshot converted to autotools.
I also spent a significant number of hours to answer questions of students who want to participate in Google’s summer of code and who are interested by the rewrite of the Package Tracking System with Python and Django. Some of the discussions happened on email@example.com.Thanks
See you next month for a new summary of my activities.