You keep using that word. I do not think it means what you think it means. -Inigo Montoya

Having worked in full-time management positions for some years now, I am increasingly convinced that management is widely misunderstood as a role, as a discipline and as a field, and that this makes a lot of lives more difficult and stressful than necessary. It is the subject of much speculation and misbelief, and I ve chosen a few of my favorite examples to deconstruct here. Misbelief #1: management is what managers do I ve noticed a trend among a certain class of companies, whose employees will tell anyone who will listen that there is no management in their organization, they never plan to have any, and neither should you. I think these statements are respectively a lie, a na ve belief, and a piece of bad advice. Usually, these companies are just a few years old and relatively small, most of the people in the company have been there for less than a year, and the speaker is trying to persuade us what a unique and innovative company they work for because nobody there is a manager . They invariably have not read The Tyranny of Structurelessness. Management is the practice of enabling people to effectively cooperate. A manager is someone whose job is to do that. It s that simple. It usually involves tasks such as sharing information, agreeing on a course of action, dividing up work, and figuring out what to do when there s a problem. They re things that every team needs to do, whether anyone is designated a manager or not. Teams can function without managers, but they can t function properly without management. Someone (or everyone) has to do the work to make cooperation possible. Modern management is a specialized discipline, which draws on a broad range of skills in communication, psychology, empathy, problem-solving, leadership, and more. These skills aren t unique to managers, but it often makes sense to designate certain people to do more of the management work, on behalf of the team. By devoting more of their time and attention to it, they free other members of the team to focus on other tasks. They can act as a coordinator to help the team stay in sync, and by focusing on this job, they may be able to do a better job of it, and acquire a higher level of skill through practice and study. But it remains an inherently collaborative practice. Misbelief #2: management is about telling people what to do There are many different varieties of management, each of which is oriented toward a particular type of team or organization. Factories are managed differently from design studios, large companies are managed differently from small companies, and every team has its own distinct management style which arises from the unique group of people involved. Some managers are specialists in a particular type of management, while others are more generalists. The telling people what to do style of management is called command and control . It s characterized by authority, hierarchy, and strict adherence to protocol. It s widely employed by military organizations, and by the managers we see in television and film. It has some advantages and disadvantages, which I won t discuss here. My point is that it is just one example, but this example is used to represent the general concept of management. Self-organization, where no one in particular is responsible for group decisions, is another, quite different, style of management. Small, self-organizing teams are capable of amazing feats of productivity. They re less difficult to manage because they re comparatively simple, and so simple tools and techniques work well. Everyone can be fully aware of what everyone else is doing, and new information propagates quickly throughout the team. But as the team or organization grows, it will often outgrow this way of working, and needs to adapt. There is no single management approach which works universally well. Misbelief #3: management is a promotion You know the story. When an employee is successful within their area of expertise, someone will eventually offer them a management role as a reward for their good work. This is utter nonsense. Management is not a promotion: it s a career change. It means starting over as a beginner in a new discipline and learning from the ground up. Domain expertise is important, as a manager needs to understand the work of the other people on their team, but it is no longer paramount. The team, the human system, becomes their focus. When organizations fail to provide career advancement within a discipline, people may turn to management as the only way to get promoted , only to discover that they are completely unprepared for this new field, and often their new job when they realize what they ve gotten into. If someone were promoted from a position as a financial analyst to a new job as a biochemist with no training or expertise, we would probably find this bizarre. But this is analogous to what happens to new managers all the time, and has become almost standard practice in many organizations and industries. So what? Management is misunderstood. So are science, engineering, and many other fields. What does it matter?

People leave managers not companies in the end, turnover is mostly a manager issue, - Marcus Buckingham & Curt Coffman, First, Break All the Rules

This mythology leads to massive organizational dysfunction, making it harder for everyone to do their jobs. It virtually guarantees incompetent management, which is a scourge on anyone who is exposed to it. It ruins days, weeks, jobs and careers. It leads talented people to leave companies, and it drives them out of their chosen professions. I recommend that we stop denigrating and ignoring management, and start doing a better job of it.

Weblate 1.8 has been released today. It comes with lot of improvements, especially in registration process where you can now use many third party services. Full list of changes for 1.8:

• Please check manual for upgrade instructions.
• Nicer listing of project summary.
• Better visible options for sharing.
• More control over anonymous users privileges.
• Supports login using third party services, check manual for more details.
• Users can login by email instead of username.
• Documentation improvements.
• Improved source strings review.
• Searching across all units.
• Better tracking of source strings.
• Captcha protection for registration.

You can find more information about Weblate on it's website, the code is hosted on Github. If you are curious how it looks, you can try it out on demo server. You can login there with demo account using demo password or register your own user. Ready to run appliances will be soon available in SUSE Studio Gallery. Weblate is also being used https://l10n.cihar.com/ as official translating service for phpMyAdmin, Gammu, Weblate itself and others. If you are free software project which would like to use Weblate, I'm happy to help you with set up or even host Weblate for you. Further development of Weblate would not be possible without people providing donations, thanks to everybody who have helped so far!

Filed under: English SUSE Weblate 2 comments Flattr this!

I ve been investigating the generation of WebID profiles for Debian project members for some time. After earlier experiments on webid.debian.net, in a static and very hackish manner, I ve investigated the use of Django. Django is no random choice, as it is being used in several ongoing efforts to rewrite some Debian Web services. Among these is a new LDAP UserDir, which could replace the current version which runs db.debian.org, started by Luca Filipozzi and Martin Zobel-Helas. I ve worked on integrating some of the LDAP querying code written by Luca together with the Django WebID provider app written by Ben Nomadic (both modified by me), and the result is a bit hackish for the moment. It s very early, but allows the generation of WebID profiles for Debian project members, using data queried in Debian s LDAP directory, and adding TLS certs to the profiles. The TLS certs could in principle be used later as a WebID + TLS authentication mechanism. There s plenty of work ahead, and this may never be deployed, but as an example see the kind of way such WebID profile documents may look (in Turtle format) :

@prefix cert: <http://www.w3.org/ns/auth/cert#> .
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix wot: <http://xmlns.com/wot/0.1/> .
@prefix xml: <http://www.w3.org/XML/1998/namespace> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
<> a foaf:PersonalProfileDocument ;
    foaf:primaryTopic <http://db.debian.org/olivier#me> .
<#gpgkey> a wot:Pubkey ;
    wot:fingerprint "ACE46EBD89F6656D6642660BE941DEDA7C5BB6A5" ;
    wot:pubkeyAddress <ttps://db.debian.org/fetchkey.cgi?fingerprint=ACE46EBD89F6656D6642660BE941DEDA7C5BB6A5> .
<http://db.debian.org/olivier#me> a foaf:Person ;
    cert:key [ a cert:RSAPublicKey ;
            rdfs:label "key made on [...] on my laptop" ;
            cert:exponent 65537 ;
            cert:modulus "bb7d5735181c7687a09abf3c88a064513badfe351f14fc2d738978a7f573d12eb831140a7a02c579f31f4617c14145493aeff4009832ba7fd1c579d6da92f68cd4437072266b000451d6eb45c03cd00b20e1f2230d83bdc3caeebb317e6618dd38a3f53abbbb2b6495a893495d3df685a2f0f599be8a74ef88841ce283dd8f65"^^xsd:hexBinary ],
        [ a cert:RSAPublicKey ;
            rdfs:label "key made on [...] on my laptop" ;
            cert:exponent 65537 ;
            cert:modulus "b078dedb61d215348adaa3315f478eca803513a8750753255f50fd335e3b6afdafd385afb62878edc412bbbc0c125d1805abef2920cb3dccb94d818b4973435f4f312ddfad960db7b7ec4522036e5c1fb1e5d7154756a97e924075b301cdf95e97e3bb665a97cdf0187c2aa229939962b0e9975dfb97c71ea60384af465aa40726fe8a2a1dd504da6a168e7f80fc37a1363d5f583a1a8d4f8253af0e7e5c0f3d2fabb61dd9cde17aba328022fd4be4e0214f407d83a95ec06b2d70c61835bb78ba3b46e8b82be3a4d6d53d88a94123144ef9b7a7c97e9396767505f34995488c62bcd697180f92244c82147a71a5b86a25f2c8ddf0ea965fc8ced8d6b84cff97"^^xsd:hexBinary ] ;
    foaf:homepage <http://www.olivierberger.org/> ;
    foaf:mbox "mailto:obergix@debian.org" ;
    foaf:name "Olivier Berger" ;
    foaf:nick "obergix" ;
    wot:hasKey <#gpgkey> .

If you re interested in WebID in the frame of Debian project services, see the discussion list.

This is a glue script to integrate git-buildpackage with cowbuilder or pbuilder. Guido G nther provided a patch to make it use the correct URL for the backports archive for wheezy and later when setting up a new build chroot. I also updated my email address, since I'm slowly transitioning to using a permanent email address I control for my various software projects. This script really should be rewritten in Python and just become part of the git-buildpackage package rather than having a separate existence, which I will get to in my copious spare time. (I do want to get back to using Python.) In the meantime, if you want to download a separate copy, you can still find the latest version on my scripts page.

TL;DR: don't put valuable passwords in ~/.netrc In the olden days, the ~/.netrc file was used for storing FTP usernames and passwords. These days we have clients of other protocols that use said file. Perhaps your IMAP or SMTP client use it. So you put your e-mail accounts password into ~/.netrc, and then meticulously configured the clients to always connect via TLS and to verify server certificates. You feel secure. But you shouldn't. Here's how an attacker capable of MiTM can exploit wget to steal ~/.netrc passwords: 1) Alice tries to download a file over HTTP:

$ wget http://xkcd.com/538/

2) Eve takes over the HTTP connection, sending a redirection response:

HTTP/1.1 303 See Other
Location: http://supersecuremail.example.net/

3) Alice's wget follows the redirection. 4) Eve takes over the connection to supersecuremail.example.net, requesting password authentication:

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Basic realm="moo"

5) Alice's wget sends the supersecuremail.example.net password straight to Eve.

Review: The Walls of Westernfort, by Jane Fletcher

Series:	Celaeno #2
Publisher:	Bold Strokes
Copyright:	2004
Printing:	March 2005
ISBN:	1-60282-349-9
Format:	Kindle
Pages:	320

While this is the first book of the Celaeno series that I've read, it turns out to be the second book in the series. This is somewhat difficult to determine from sources on-line since the first three books in the series were published in the same year, but it's fairly obvious from reading synopses after having finished one of the books. I don't think it does any great damage to the story to read it out of order (indeed, it preserves the suspense around some plot elements), but you may want to seek out The Temple at Landfall first. Natasha Ionadis is a member of the Guard. The military services are divided into three parts in her world: the Rangers, who defend cities against bandits and others in the countryside; the Militia, who maintain law and order in the cities; and the Guard, who are responsible for guarding the temples and protecting the rituals and teachings of the state religion. She is a devout worshiper of Celaeno and delighted to be part of the Guard. But, as this book opens, she gets a very unexpected mission for a young private: a suicide mission into the heart of a heretic group in the wilds, heretics who have successfully defied the official religion and are in danger of setting up a self-sustaining community. The Walls of Westernfort has the surface trappings of a fantasy and does include some magic, but it slowly develops into more of a character story with a medieval (or, more accurately, medieval-inspired) backdrop. At the start, it appears that this mission will be an opportunity for Natasha to find the mentors and companions that she's never had before, but then her encounter with the heretics turns her world upside down. They're not the monsters that she had imagined, although their beliefs are still outrageous to her. One heretic in particular affects her deeply and introduces a strong lesbian romance element to the plot that dominates the rest of the book. I enjoyed the slow emergence of one aspect of the setting (that I'm about to spoil, so skip to the next paragraph if you don't want to hear it, although it would already be spoiled by reading the predecessor book or most of the blurbs). This is a world devoid of men; all the characters are women. This isn't part of the plot; it's just the unremarked normal. Fletcher tosses in a hand-waving explanation about halfway through, but it's only discussed in passing and never mentioned again. I really enjoy this technique, and enjoyed watching how long it took in the book before I noticed. There are so many books out there where men are the unremarked normal that it's a refreshing change to read the opposite (and notice how little it really matters), although it does require throwing in implausible magic to solve the problem of procreation. (That's apparently more the topic of The Temple at Landfall.) Plot-wise, The Walls of Westernfort is not complicated. The shape of the plot after Natasha's first encounter with the heretics is not likely to surprise any reader. But it's a simple plot well-executed, with distinct and fleshed-out characters and steady helpings of people being thoughtful and reasonable. The basic story carries plenty of natural conflict; Fletcher doesn't need to add much additional tension and wisely chooses not to, keeping the focus tightly on Natasha and her conflict between duty and conscience. I liked both of the people involved in the romance and could believe they'd fall in love, and I also liked that the romance was significant but not decisive. It's part of what helps Natasha expand her view of the world, but one could see how she would have made the right decision in the end even if the romance had not been present. The story does force some significant secret-keeping, but it doesn't draw cheap tension from mundane failure to communicate. All of the communication gaps here are believable and honest, driven by the characters' backgrounds, and absolutely necessary. I'm hypersensitive to romance plots based on communication failure, and I wasn't even grumbling. The series this book reminds me the most of is another lesbian romance in a fantasy-style setting: Catherine M. Wilson's When Women Were Warriors. The Walls of Westernfort is not as deep or philosophical, it's a bit more black and white in its morality, and I don't think it's quite as good of a book, but for me it had a similar tone of good people trying to do the right thing and finding one's way through ethical mazes. It's a bit slow to get started, but by the time Natasha's critical decision point arrived, I was fully invested in the story and had a hard time putting it down. Recommended if you're in the mood for a relatively light faux-medieval fantasy romance. I'm not rushing out to grab the other books in the series, but they went on my want list and I'll probably get them at some point. Followed by Rangers at Roadsend in the publication order sense, but apparently it's a prequel. Rating: 7 out of 10

---

---

Review: Fantasy & Science Fiction, May/June 2011

Editor:	Gordon van Gelder
Issue:	Volume 120, No. 5 & 6
ISSN:	1095-8258
Pages:	258

The editorial in this issue is about the investigation into the troubling death of long-time contributor F. Gwynplain MacIntyre (which was not his real name). It's disturbing, but to me it underscores one of the things that I love about the Internet: people for whom life isn't working very well can still find an outlet, make friendships, and control how they choose to present themselves to the world on-line. That's something quite valuable, and part of why the pushes for "real names" always gives me pause. Somewhat thematically related, this issue also features a non-fiction essay by Maria E. Alonzo about her investigation of Jesse Francis McComas, her great-uncle but better known to the SF community as one of the founding editors of F&SF and co-editor of the famous classic anthology Adventures in Time and Space. This is mostly a curiosity, but it's fun to read about the sense of triumph in tracking down lost family history. This issue also features a Chris Moriarty book review column, always a plus, as well as a few positive reviews of obscure superhero movies by Kathi Maio (plus the required grumbling about a more mainstream film). "The Final Verse" by Chet Williamson: This is more of a horror story than I would normally like, but I got pulled into the investigation of an old bluegrass song and the guesswork and footwork required to track down where it came from. Williamson does a good job with the tone and first-person narration, and the degree to which the protagonist cares about the song to the exclusion of the horrific happenings of the story blunts the horror. Not quite my thing, but I thought it was well-done and played well with the possible meanings of song lyrics. (6) "Stock Photos" by Robert Reed: This is well-written, like nearly all Reed stories, but it lacked enough clues for the reader for me. It's a very short story about a man who's out mowing his lawn when approached by two strangers who apparently want to take photographs of him for stock image collections. Then things get rather weird, but without any explanation, and the ending lost me completely. Frustrating. (It is partially explained by the later "The Road Ahead" story in this same issue.) (4) "The Black Mountain" by Albert E. Cowdrey: From one of F&SF's most reliable story-tellers to another, and this is a more typical story. Cowdrey offers an abandoned and very strange cathedral for an obscure religion, a conflict over a development project, and some rather creepy results, all told in Cowdrey's entertaining fashion. Some places you just don't mess with. (6) "Agent of Change" by Steven Popkes: Told Dos-Passos-style with news excerpts, web sites, and the transcript of an emergency committee, this story shows the discovery of Godzilla, or something akin to Godzilla, in the Pacific, where it's destroying whaling vessels. I do like this style of storytelling, and here it mixes well with humor and a bit of parody as Popkes shows how each different news outlet puts its own recognizable spin on the story. The story isn't particularly memorable, and it doesn't end so much as just stop, but it was fun. (7) "Fine Green Dust" by Don Webb: This story is dedicated to Neal Barrett, which will give SFF short story readers a warning of weirdness to come. In a near future where global warming as continued to make summers even more miserable, the protagonist happens across a naked woman painted green. The green turns out to be a sun block that claims to assist humans in metamorphosis into animals. Most of the story is the protagonist trying to decide what to think of that, interspersed with staring at his neighbor's naked daughter. It's mildly amusing if you don't think about it too much and don't mind the rather prominent male gaze. (5) "Rampion" by Alexandra Duncan: The novella of the story, this is set in Muslim Spain some time during the long fights between Muslims and Christians in the north. It's told as two parallel stories: one telling the protagonist's first meeting with his love, and the second following him as a blind man, some time later, deciding whether, and how, to re-engage with the world. The style feels like fantasy, but there's very little overt fantasy here, and the story could be read as historical adventure. It's good adventure, though; conventional in construction, but with some romance and some drama and a good ending. (7) "Signs of Life" by Carter Scholz: This is to science fiction what "Rampion" is to fantasy: not really SF in the classic sense, but fiction about the process of science. The protagonist works on gene sequencing and is mildly obsessed with a visualization of junk DNA in an attempt to find patterns in it. Like a lot of fiction about science, it's primarily concerned with office politics, grant funding, and an awful boss. There is a faint touch of the supernatural, but that strand of the story doesn't amount to much. There's a happy ending of sorts, but the story left me with a bad taste in my mouth, and I'd completely forgotten it by the time I sat down to write this review. (4) "Starship Dazzle" by Scott Bradfield: I've never seen much in Bradfield's ongoing series of stories about Dazzle, the talking dog. In this one, he's sent via rocket on a one-way trip into outer space and ends up making a bizarre sort of first contact. Like the other Dazzle stories, it's full of attempts at humor that don't really work for me, even though you'd think I'd be sympathetic to the mocking of our commercialization of everything. The ending is just silly, and not in a good way. (3) "The Old Terrologist's Tale" by S.L. Gilbow: I love the setup for this story. It's set in some sort of far future in which terraforming has become routine, and a group of people are telling each other stories over drinks. The first-person protagonist is a terrologist, someone who designs planets (and the technology is available to do this almost from scratch). The conversation is taking a turn towards the humiliating, with a politician belittling the work of terrologists, when an old terrologist who has been listening quietly starts telling a story about designing worlds, both mundane and dangerously beautiful. Gilbow does a great job here capturing blithe self-importance, the habit of belittling other people's technical work, and revenge via storytelling with a nasty barb. This was my favorite story of the issue. (7) "Altogether Elsewhere, Vast Herds of Reindeer" by Ken Liu: This is a rather odd but quite touching story about mothers, daughters, nature, connection, and uploading. It's set after a singularity, in a time when all humans are uploaded into computers and exploring higher dimensions, digital natives in a much deeper sense than is meant today. But Rene 's mother is an Ancient, from before the singularity and still three-dimensional, and she wants to spend some time with her daughter. That leads to a memorable moment of connection, without pulling Rene entirely out of her father's world. Well done. (7) "The Road Ahead" by Robert Reed: Two Reed stories in one issue! And this one is a sequel to "Stock Photos" from earlier, since apparently I wasn't the only one who found it hopelessly confusing. It provides some backstory and makes a bit more sense of the first story, and that also makes it a more interesting story in its own right. The stock photo concept wasn't entirely a lie, as I had thought it was after the first story. There is analysis, anticipation, and trends behind who the pair take pictures of. But this story explores some internal tension, some conflict between them and some knowledge that the woman has that the man doesn't. And in the process it makes everything creepier, but also more interesting, and provides a hint at a really dark way of viewing the news media. I would say that this salvages "Stock Photos," except that I don't think "Stock Photos" is necessary now that one can read this story. (7) "Music Makers" by Kate Wilhelm: This is another story about investigation of the history of music, mingled with the supernatural, but unlike the story that opened this issue, it's not horror. Rather, it's a gentle and sweet fantasy about the power of music and benevolent ghosts and a community coming together. It's a positive and happy note on which to end the issue. (6) Rating: 6 out of 10

Today I'm recuperating, and almost back to full health. Unfortunately I made the mistake of online-shopping, oops. Good job I stopped myself from registaring all the domains, but I did get two that I liked: spare.io & edinburgh.io. I've updated my database to record them, but I wonder what do other people use to remind them about expiration dates of domains, SSL-certificates, & etc? I googled and didn't find a definitive free/paid service, but it seems like something lots of people need to be reminded about.. Maybe people just rely on registrars sending strident emails. (Of course the redemption period for domains make it reasonably safe to forget for a day or two, until your customers complain and your emails start to bounce..)

Spam trap Dear lazyweb, I am considering to implement spam traps and evaluate their efficiency. The idea as rather simple:

1. publish some real-looking email addresses on websites, in ways that no human would use them to send legitimate mail, for instance in hidden texts, or in texts clearly stating they should not be used;
2. when my mail server receives a message for one of these address, blacklist the originating server for some time so it cannot spam real recipients.

Practical implementation Now, I have to decide on how to implement that with my Postfix server. I am thinking of using fail2ban to simply detect attempts to send mail to my spam traps and blocking these spammers at iptables-level, but I do not think that will give me much tuning possibilities. Do you have other suggestions? Implementation details I also have to think about some specific details. Here is what I identified so far, do you think I am missing something that may be useful?

• Blacklisting time: since no legitimate mail can ever be sent to an explicit spam trap address, everyone sending mail to these addresses is by definition a spammer, so I can block them for months, if not forever. There is, however, a risk of blocking large scale services mostly used by regular users but sometimes abused by spammers, like Hotmail or Gmail
• Server response: a spam trap address is only efficient if it gets included in a spammer's address list and if it stays there, so I should make sure my server answers the first attempt in a way that does not make him think that address is problematic and should be removed from his list. Defining a /dev/null alias should do it.

I've just closed my LinkedIn account, in reaction to the recent announcements on their ill behaviour re. their user's data (in particular emails). Even if I didn't allow my mail to ever pass through their servers, I think I've been their product long enough. If I ever am looking for a job in the future, I do hope that my track record in various code repositories will speak better than my resume in LinkedIn database. From time to time I've had the need to check on someone's profile there... but I guess I'll have to do without it. I shall update my WebID in the next days, to complement the move

Review: Why We Fail, by Victor Lombardi

Publisher:	Rosenfeld Media
Copyright:	2013
ISBN:	1-933820-17-9
Format:	Kindle
Pages:	248

Subtitled Learning from Experience Design Failures, Why We Fail is a case study book. It defines experience design, discusses the usefulness of analyzing failure, and then walks through ten marketplace failures attributed to failures of user experience (as opposed to engineering or user interface) and tries to draw some conclusions about those failures and how they could have been prevented. Lombardi then presents a more general (if fairly simple) framework for iterative experience design, along with some discussion of how that approach could have helped in these cases. Hardware and software designs can work properly but still fail with users and customers because the overall experience isn't right. Sometimes this is because something else got there first with more market share and people got used to it, sometimes it's because a system is too complicated, sometimes it's too simple, sometimes it's just uninspiring. Most of the news media coverage and many of the blog posts on this topic look to inspirational examples of successes. Lombardi points out here that successes can be accidental and failures are often more informative, a concept already common in many more mature areas of engineering. His hope, with Why We Fail, is to push a broader industry practice of taking apart and analyzing the failures. User experience design is still in its infancy, since many of the complex interactions now possible in modern hardware and software have just recently crossed into levels of complexity that qualify as experiences rather than interactions, and could benefit from more rigor. The concept sounds great. The approach in Why We Fail is at least interesting; Lombardi tells good stories, and I think they do tell some useful lessons. Drawing general principles is harder, which is always the weakness of case-study books. Lombardi's own attempt doesn't go far beyond a familiar mantra of the scientific method, small and responsive teams, cross-functional teams with flexibility to address a whole range of technical and business issues, and honest and forthright analysis of and iteration after failure. All of this is doubtless good advice; none of it should surprise anyone with even a smattering of engineering background or familiarity with current software design philosophy. The heart of the book is in the stories, and I did like that Lombardi captured a wide range of different designs. Included are embedded systems (BMW's iDrive), traditional software packages, web services of various types, and even a protocol (OAuth). Some were vaguely familiar and some were not familiar at all, although I don't follow UI and UX discussions to any large extent. In each case, Lombardi gives a short but effective introduction to the problem space and the product, walks through the design choices, and then talks about the failure. Usefully, he doesn't stop with the failure but continues the story through the reaction of the company to the failure and any subsequent actions they took, which in some cases contain their own useful lessons. All of this, I should note, is a bit far afield of my own area of expertise (architectural building blocks and sub-surface components without as much direct interaction with the user), so I'm not the best person to judge the quality and originality of the analysis. But I liked Lombardi's approach and his analysis of multiple possible failure causes, and all of his conclusions seemed quite plausible and sensible given the case studies as described. I'm best-qualified to judge the chapter on OAuth, since I've worked extensively on web authentication systems, and his analysis of the challenges and user experiences in that case closely match my own. I didn't notice any significant errors, which is hopefully a good sign for the rest of the book. As one might expect from a short book about a complex field aimed mostly at starting a conversation, there isn't much here that's earth-shattering, nor are there simple extractable principles that will make your experience designs better. As always, the takeaway boils down to "invest time and resources into this and try to think about it systematically," which of course is true of every possible axis of improvement for any product. (The challenge is usually where to spend those limited resources.) I will also note in passing that Lombardi assumes an entirely market-driven metric for success, and all of the case studies are exclusively commercial not unexpected, since that's where most of the money and a lot of the resources are, but not that helpful for bespoke work where the nature of the problem is subtlely different. But, despite the expected shortcomings and the inherent weakness of the case study approach to analysis, which tries to pluralize anecdote to get data I enjoyed this book. I also got at least one useful trick out of it: the premortem, to look for potential failure points in the experience before rolling out, or even designing, the product. It's a fairly light-weight book, but I think it's moderately inspirational, and I wholeheartedly concur with Lombardi on the merits of failure analysis as an engineering approach. Rating: 7 out of 10

A vision wanted Today Richard Stallman mailed all Italian LUGs asking that tomorrow's LinuxDay be called "GNU/Linux Day" instead. I wonder how that is ever going to help a community so balkanised, that the only way Italian LUGs manage to do something together, is to say "let's not care what we all do, let's just do it on the same day and call it a national event". Of course a few LUGs still make a point of not doing anything on that day, because you know, Judean People's Front. Cawk. Today a friend asked me if I could help her support people in installing Citrix Whatsit to set up a video conference to network meetings that will take place in a month in different cities. Those meetings are something I look forwad to. It wasn't much of a problem to say "no, I can't do that"; it was a problem to be unable to come up with some viable, Free alternatives. I sometimes have to use Skype to talk with friends who also are Debian Developers, because I still haven't managed to make VoIP work unless I go through a commercial proxy. There was the happy news that our regional administration is switching from MS Word to OpenOffice. It soon became a flamewar, because some people loudly complained that they should have used LibreOffice instead. At DebConf, after spending an hour getting frustrated with the default formatting of bullet points in WhateverOffice Impress, I did my Debian Contributors talk using a text file in vim. And it was a success! Thanks Francois Marier for maintaining cowsay. I can't sync contact lists and appointments between my N900, which runs a Debian derivative, and my laptop, because I don't want to have a Google account, and nothing else would work out of the box. I don't even know how to keep a shared calendar with other DDs, without using a 3rd party cloud service that I don't want to trust with my life's personal schedule. I need to do a code review of every vim plugin I need to use, because you can only get them by cloning GitHub repositories over plain http, and they don't even provide signed tags. That code is run with my own privileges every time I start a text editor, which is, like, all the time. I'm frightened at the idea of how many people blissfully don't think about what that means. Vim users. Programmers. Cool chaps. Yet the most important thing in Debian today seems to be yet another crusade between upstart and systemd. But we haven't had a lengthy discussion on why, although the excellent OpenStreetMap exists and many of us contribute to it, it seems to still be more immediate to hit Google Maps to get a route computed. How can we change that? We haven't had a lengthy discussion on what can we offer to allow anyone to set up some social platform that won't get swamped with spam the first day and cracked open the second; that would allow people to share some photos with their friends only, and some with the rest of the world; that won't required a full-time paid person to maintain. That won't be obsolete and require a migration to a new platform in a year. That isn't Facebook or Google Plus. I stopped taking photos because it's too much work to show them to people. Other people use Instagram. Whatever the hipster trend is for photo sharing today, October 25, 2013, I'm pretty sure it's not a Free platform. But we can do something. We technology leaders. We are those who drive technological change! For example, today I invested two hours of hard effort trying to figure out why libbuffy's test suite fails on kfreebsd. All while wondering why I was doing that, since I know all buffy's users personally, and none of them uses kfreebsd. And I will take a day off work to study the library symbols file specification, so that next time I'll know right away if the new version of a C++ compiler decides that a template-generated symbol isn't worth adding to a library anymore. What is this effort really about? It sometimes feel like micromanaging to me. It's good to have excellent quality standards. But not without a vision. Not until "reliable network printing with all PDF viewers and print servers we ship" is among our release goals. Not until we commit to making sure that "sharing files between Debian users" will work out of the box, without the need of going through a 3rd party website, or email. I'm not interested in spending energy discussing init systems. I'm interested in spending energy sharing stories of what cool stuff we can do in Debian today, out of the box. And what cool stuff we'll be able to do tomorrow. Let's spend time on IRC, on mailing lists, and at the next Debian events, talking about why we are really into this. Talking about a vision! Note: Please don't spend time telling me how to fix the problems I mentioned above. I'm not interested in help fixing some problems for me today. I'm interested in asking help fixing problems for everybody, right in the next stable release. Remember, remember, the 5th of November, 2014.