Search Results: "ana"

26 December 2012

Russ Allbery: Review: Code Name Verity

Review: Code Name Verity, by Elizabeth Wein
Publisher: Hyperion
Copyright: 2012
ISBN: 1-4231-5219-0
Format: Hardcover
Pages: 339
I don't read very much historical fiction, and I mostly avoid historical fiction from the 20th century. I'm particularly uninterested in reading about Nazis after the saturation programming in places like the History Channel and the number of alternative histories that involve them. I've read enough about World War II to last me a lifetime, and I also avoid books about people being tortured. When Code Name Verity showed up in reviews I read, I was therefore rather dubious: a book set during World War II featuring someone being tortured by Nazis seemed unlikely to appeal to me. But after two steller reviews from reviewers who don't give out top marks easily, I bought a copy with some trepidation. That was one of the best decisions that I've ever made. This is the sort of book that is severely hurt by spoilers. In a moment, I'm going to attempt the impossible dance of giving you a feeling for the book and why I love it so much without spoiling anything. But if you trust my taste in books, let me give you a short warning, and then I suggest you stop reading this review and just go read the book. I avoided as much information about it as possible before reading it and never regretted it. The short warning: This is a book that hurts. lightreads describes it as searing. I think that's a very good term. It's not that it's gruesome; there is torture, but most of it happens off-camera and the focus is on emotional reactions rather than physical description. But the story sneaks up on you with sudden flashes of insight, and parts of it are a gut punch. It's the kind of book that had me in tears for a quarter of the book. It's the kind of book that nearly has me in tears remembering it to write this review. So, you may want to save this one until you are in the mood for that kind of book. But, that warning aside, Code Name Verity is unspeakably brilliant. This is one of the best books I have ever read in my life. I will try to explain more, but if your tastes mostly align with mine, just stop here and go read it.
I AM A COWARD.
That's how Code Name Verity starts: the words of a captured female British agent in Nazi-occupied France. The book opens near the end of her interrogation (and torture). The important information has already been discussed, and now she's likely destined to be executed. For the last set of wireless codes, she's bought herself paper and two weeks to write, and is expected to record everything that she remembers about the British war effort. The pages of this book are that writing (quite literally in the frontpiece and part of the cover, which are beautifully designed). The way she chooses to approach that task is to tell a story about the person whose ID she had when she was captured, a story that becomes the recounting of how she ended up where she is. That story is the heart and soul of this book. It's about the war, yes, and about British operations during the war. But it's a story about airplanes, too, and about the Air Transport Auxiliary, and about women finding a place in the war (with just a bit of a fictional push, detailed by the author in an afterword, although not quite as much of one as you might expect). And it's a story of a friendship, an amazing friendship of two women who would have never met each other if it weren't for the war and its leveling and transcending of normal social separations. It's a story about a friendship of opposites, about two people who find ways to support each other, about two people who see the best in each other. This is quite possibly the best novel about a friendship that I've ever read. This story, by itself, is wonderful. The tone starts light and irreverant, with an undertone of complex despair and defiance that's hard to analyze. One wonders where it's going and whether any of this is relevant, and then it slowly draws in the reader and becomes utterly compelling. But that's only the start of what this book has in store. Wein does some amazing structural things here that turn and broaden and transform, things that absolutely should not be spoiled because experiencing them without advance knowledge is a breathtaking reading experience. And all the parts play off against each other with a confidence that lets Wein understate and even hint at deeper emotions and be completely confident that the reader is right where she wants them to be. It's not a one-trick book, nor is it one that's going to lose you in the structure, but it's a book that opens up layers as you read it and tempts you re-read it immediately with new eyes once you finish it. Except it hurts so much that re-reading it immediately might be more than your heart can take. Perhaps the most astonishing part of this book is the way it hits its emotional notes. It is a masterpiece of showing rather than telling. Wein undersells the emotions in exactly the right way to make them stronger and more effective, avoiding, in the process, multiple traps that I've rarely seen avoided. The ending is absolutely note-perfect to everything that's happened before in a way that I thought, five pages from the end, was going to be impossible to pull off, and gets even better the more that one thinks about it. And the whole book is like that. It's been a month and a half since I read this book, in part because I wasn't sure how to write this review, and I did not, in fact, manage to finish writing it without crying. If I didn't have to be on a train in eight hours from when I'm writing this (a few days before I post it), I'd start reading it again right now. I can't talk about most of the things that make it amazing with anyone who hasn't read it, but it really is that good. Rating: 10 out of 10

25 December 2012

Uwe Hermann: sigrok at the 29th Chaos Communication Congress (29c3)

29c3 logo Yup, it's been a while since my last blog post, but I'm not dead yet. Most of my spare time goes into sigrok development these days (open-source signal analysis suite for logic analyzers, oscilloscopes, multimeters, and lots more), but I'll try to revive my blog too. I have various microcontroller/embedded topics and devices I want to talk about in a small blog post series in the nearer future. But more on that later. Feel free to subscribe to the sigrok-devel mailing list, join us on IRC in #sigrok (Freenode) where most of the discussions take place, or follow our new sigrok blog (RSS) if you're interested in the ongoing sigrok developments. Anyway, for now just a quick announce: Same as last year, we will be at the Chaos Communication Congress (29c3), this time in Hamburg, Germany. The conference takes place from December 27th to 30th, 2012. We'll have a sigrok "assembly", likely in area 3b of the conference building, where we'll be hanging around, working on new sigrok features, new hardware drivers, new protocol decoders and various other things. We'll have lots of gear with us for demo and development purposes, including logic analyzers, oscilloscopes, MSOs, multimeters, and lots more. Bring your own device if you own models we don't yet support or know about. We'll be happy to have a look! Chat with us, give us your suggestions which features you'd like to see, which devices you want to be supported, which protocol decoders you'd like to have, or even help us write some drivers/decoders! Hope to see you there!

Russ Allbery: Review: A Paradise Built in Hell

Review: A Paradise Built in Hell, by Rebecca Solnit
Publisher: Penguin
Copyright: 2009
Printing: 2010
ISBN: 0-14-311807-2
Format: Trade paperback
Pages: 319
A Paradise Built in Hell is a book with an agenda. Solnit's goal is to convince the reader that nearly everything we're shown in movies and popular culture about human behavior during disasters is wrong. Not only is destructive mass panic unusual verging on nonexistent, spontaneous cooperation and acts of startling courage and resourcefulness are commonplace. The heroes that we hear about afterwards are more the norm than the exception. Disasters are far more likely to bring out the best in people than the worst. They break down barriers and form spontaneous human communities that survivors remember for a lifetime. Rather than natural disasters leading inevitably to an exacerbating human crisis in the absence of strong authority, Solnit argues that they are an amazing human opportunity, and that the most negative and destructive human behavior during crises is not from untrained victims but from the panic of the elites who are supposedly responsible for protecting the public. I think her analysis and presentation is both deeply appealing and deeply flawed. The flaws involve extrapolation and generalization beyond the applicability of her research, and I'll say more about that in a moment. But the appeal is still surprising and satisfying, and I think there's a lot of truth in this book despite its one-sided presentation. I like to tell people, half-jokingly, that I'm an anarchosyndicalist. It's my political alliegance of the heart: the political structure that I know would never work, but that matches the world I want to live in. (I suspect much of the belief in libertarianism is of this form.) Now I have a book to point people at when they ask what the appeal of anarchosyndicalism is. The sense of spontaneous community, of bonding, of reaching out to other people to do something necessary, together, that Solnit describes here in the aftermath of a disaster matches that vision of a world without imposed economic authority, where people spontaneously collaborate to solve problems. A Paradise Built in Hell is structured by disaster, providing a tour of major disasters and their aftermath interspersed with extended musings on what the human reactions mean and how disaster communities functioned. The major disasters discussed are the 1906 San Francisco earthquake, the Halifax explosion, the 1985 Mexico City earthquake, 9/11, and Hurricane Katrina. Solnit moves through them in chronological order, closing the book with Katrina, which had (at least for me) the most infuriating and uplifting mixes of community bonding and elite panic. But both of those factors are present from the beginning in the 1906 earthquake: spontaneous human organization that (from multiple first-hand accounts) transformed people's lives mixed with a military reaction and elite panic that possibly did more damage to the city than the earthquake did. Elite panic is the dark side of Solnit's celebration of human altruism and spontaneous community organization. The primary picture she paints is of ordinary people responding with great courage and creativity and finding, in their reaction, a transformative experience and a sense of purpose that often becomes the most powerful and positive experience of their life. But this is at odds with a deeply-entrenched elite belief in mass panic, in the necessity of keeping information from the public to suppress their reaction, and in the need to re-establish "order." And with that, Solnit is absolutely scathing, and with some justification. Along with detailed accounts of these major disasters, Solnit also gives the reader a tour of the research literature on disasters, research that has shown that the panic and chaos that is at the center of practically every disaster movie ever made is essentially a myth. Mass panic in disasters is not only rare, it's close to non-existent. As you might expect, the handling of Katrina by both the government and by neighboring white communities is the subject of the harshest attacks. The material on Katrina presented here is enough to make anyone want to throw out the current playbook on how we react to disasters (and lest one think Solnit is unfair, her research matches very closely with other research and journalism on Katrina that I've seen from a wide variety of sources). But Solnit shows that this is a pattern: the combination of our media-driven belief in how people will react to disasters combined with the elite need to re-establish control plays out in many major disasters, and almost always negatively. Even in 9/11, the official response in some cases hampered and undermined an already-effective unofficial response. This is very interesting and has concrete implications for public policy around disasters. But where Solnit moves onto thinner anarchosyndicalist ice is the story that she tells about disasters as dramatic upheavals of the established social order that could point to a revolution in how we interact with each other. Solnit is deeply inspired by human altruism during disasters, and her enthusiasm is somewhat contageous, but it was useful to read this book shortly after Bruce Schneier's Liars and Outliers. I think Solnit, in her understandable eagerness to find a way to extend disaster behavior to general life, does not understand the relationships between what Schneier terms moral, reputational, and institutional pressures. And that's the core of why we need to both enable spontaneous human response in disasters and have organized first responders and supporting infrastructure, and why disaster communities will break down when extended beyond the disaster. When I first mentioned A Paradise Built in Hell to my mother, her first reaction was dubiousness due to her memory of the 1977 New York City blackout. There was a disaster that resulted in widespread looting and destruction, rather than the positive reaction Solnit describes. Solnit does have a cogent argument for why looting is poorly analyzed (we don't, for example, distinguish between breaking into stores to get desperately needed supplies and doing so for personal gain) and should not be a priority in a life-threatening disaster. But it's not completely convincing; in some disasters, particularly ones like the 1977 power outage that were not particularly life-threatening, the looting has been the most destructive part of the disaster. Schneier provides what I think is the missing piece, both to this and to why the wonderful behavior during disasters doesn't last into everyday life. During a life-threatening disaster, moral pressures are massively increased. Nearly all of us have self-images and moral beliefs that provide very strong incentives to help others and collaborate in the face of life-threatening emergencies, incentives that override other motives and lead to the sort of behavior that Solnit celebrates. But moral pressures have inherent limitations. That moral reaction applies most strongly to small groups (such as bands of survivors), and will start to break down as larger society re-establishes itself. And disasters, like a power outage, that are not immediately life-threatening will not provoke the same intensification of moral pressures: we don't have strong moral beliefs and internal stories about staying quietly at home during power outages the way that we do for saving people from burning buildings or pulling them out of rubble. Once larger communities have reformed and that short-term emergency reaction has dissipated, the need for institutional pressures (police, law, and formal authority structures) will return. I wish Solnit had been able to read Schneier's book before writing hers. I think his analysis structure provides a healthy dose of realism and perspective to her desire for a self-organizing communal world, and might have blunted her enthusiastic but somewhat unrealistic hopes for finding some key to a revolution in human organization in the heart of disasters. But if A Paradise Built in Hell is unlikely to lead to a radical change in how we organize societies, it should at least provoke a radical rethinking of some of our unnecessary pessimism about our fellow humans. The evidence is substantial and compelling: crisis brings out the best in people, not the worst, and the ordinary people who happen to be around are capable of becoming some of the most amazing disaster response teams that we can imagine. This has numerous mundane implications for social policy. We should consider simple training for the general public, for example, to strengthen that reaction, should allow for it in legal structures and training of first responders (around looting, for instance), and should do everything we can to kill the destructive myth that people cannot be trusted in disasters or that mass panic will be as much of a threat as the disaster. But the best part of this book is that it provides a concrete, well-documented, and well-defended reason to let go of some of our cynicism and to extend a bit of trust to our fellow humans. There sadly aren't earth-shaking implications for everyday society, but there is a wealth of evidence that shows that we're better people in the crunch than we believe we are, or that we expect of others. And the more that we can embrace the dissolution of boundaries and social hierarchies in the middle of disasters, the more we are likely to be surprised by deep human connection and a sense of shared, focused purpose. Solnit is a bit long-winded with her agenda, but that bright hope has stuck with me. Recommended. Rating: 8 out of 10

Ingo Juergensmann: Resurrecting m68k - We're on track again!

Mid of November I already wrote about "Resurrecting m68k" - and went on holidays right after that writing. So, nothing really happened until December. But then things happened rather quickly one after one. First, I got Elgar up and running. Then I upgraded Arrakis and Vivaldi again. And then it was a lucky coincedence that my parents made a short trip to Nuremberg. Back then there were another buildd located in that city: Akire, which was operated by Matthias "smurf" Urlichs. So I mailed him and asked, if Akire still do exists and he answered surprising quickly that it is - but he wanted to take it to the garbage soon. I asked Smurf if my parents could pick it up and we managed to exchange contact addresses/phone numbers. To all of our surprise the Hotel, where my parents were staying, was just 180m away from Smurfs home! So it was really easy for my parents to pick up the machine, until they continued their trip to visit me in Rostock. That way I had just another machine to upgrade! Whoohoo! I used most of the time in December to upgrade the machines, migrating to larger disks, setting up everything as someone on debian-68k list popped up to offer a hosting facility in Berlin. That was really perfect timing! I took Elgar from NMMN in Hamburg, where it was hosted until August, and had now a second machine, Akire, where I didn't know where to host. So the offer made it easy to decide: Elgar & Akire will go to Berlin whereas Kullervo & Crest will move back to NMMN, when those two boxes got upgraded. That way we have some kind of redundancy. Perfect! Except that we would still need a running Buildd on those machines. During the last few years, I think 4-5 years, the sbuild/buildd suite did change in a great way. Nothing worked any longer as it did. So I concentrated on getting sbuild ready to pick a source and build it. But I got faced with some segfaults of various stuff. After all, it happened to be a somewhat broken kernel that caused all the problems. After upgrading the kernel, schroot suddenly did work and I could continue in setting up sbuild. After some days things got clearer and finally it worked: 6tunnel was the first newly build package by sbuild on m68k on 20. December 2012! During the next days I tried to get a larger disk (18G) for Spice, another machine, working, so I could use the big disk (36G) for Akire, instead of the old 2 & 4G disks and tried to deploy the sbuild config to Arrakis and Vivaldi. That was about two days ago. The missing part was an updated buildd config. This was addressed by Wouter today (well, actually yesterday in the meantime) and now we have a working buildd again since years! Hooray! :-)) Now we are back on track with the m68k port and will add more buildds, as well native as emulated ones, to come down from that "Needs-Build : 5261" number. So, very big thanks to all that made this possible:
  • Wouter for configuring the buildd setup on Arrakis
  • Aurelien for adding the m68k buildd back to debian-ports.org.
  • John Paul Adrian Glaubitz for offering the hosting
  • Matthias "smurf" Urlichs for keeping care of Akire all of these years
  • NMMN in Hamburg for willing to continue the hosting for Kullervo & Crest
  • adb@#debian-68k for donating 4x 32MB PS/2 RAM
and finally, last but not least, a very, very BIG THANKS to Thorsten Glaser who acted all these years as a human buildd and for solving the TLS problem on m68k and keeping the port alive in some kind of one-man-show!
Kategorie:

24 December 2012

Bastian Blank: Relaying e-mail over unreliable connections

Introduction I still prefer to handle all my mails at home. I got backup set-up on my own and have anything in direct access. This network is connected to the internet via an end-user DSL connection without a static IP-address and without any useful SLA. However relaying mails over such an unreliable connection is still an unsolved problem. There exists a lot of solutions for this problem. I'm currently building a new e-mail setup, so I tried to collect all the used and maybe possible solutions for the relay problem. I will show some of them.
Don't do it The easiest solution is to just don't try to collect mails at home. This solution is somewhat against the rules, but I know people who prefers it. Access to the mails is usually done with IMAP and a copy is made if needed. This is not really a solution, but it works for many people.
SMTP SMTP is the mail protocol used in the internet. It is used for all public mail exchanges. By itself it can't be used to submit mails to remote destinations With some preparations it can be used to relay mail over unreliable connections. There are three different turn commands in SMTP that can be used to start the mail flow. Two of them will be
VPN or dynamic DNS with TLS with or without extended turn (ETRN) Using SMTP themself is an easy solution. It can relay mails without much hasle But it needs either a fixed or authenticated connection. SMTP can use a fixed connection. This is usually provided by some sort of VPN. The VPN can be encrypted, but does not need to. This allow the MTA to connect to the downstream server if it is available. The other solution is to authenticate the downstream server. Authentication is available via TLS and X.509 certificates. It still needs some way to find it, but with dynamic DNS this is no real problem. Both variants can be combined with the extended turn command. Extended turn allows to request a queue flush for a domain. It can be used to request mails only to be delivered if the downstream server is available at all. This reduces the load on the MTA.
Authenticated turn (ATRN) On-demand mail relay is a rarely supported ESMTP feature. The Authenticated turn command effectively reverses the SMTP connection and allows, after authentication, the flow of mails from the server to the client via standard SMTP. There exists some stand-alone implementations, but no widely used MTA includes an implementation.
POP3/IMAP and fetchmail/getmail All e-mails can be delivered to mailboxes and retrieved by the end-users system and re-injected into the delivery system. Both fetchmail and getmail are able to retrieve mail from POP3 and IMAP servers. They are either directly delivered via a MDA like procmail or maildrop. Otherwise they are submitted via the sendmail interface or SMTP and delivered by the MTA. Neither POP3 nor IMAP have support for meta data like the real recipient or sender.
Mailbox per address The mails for each address are delivered to its own mailbox. This allows proper identification of the recipient address. It still have no real idea of the sender address. Because it needs to poll one mailbox per address, this highers the resources needed on both sides dramatically.
Multi-drop mailbox The mails for all addresses are delivered into one mailbox. The original recipient must be saved in a custom header to allow this information to be restored. Only one mailbox needs to be polled for mail addresses.
UUCP One of the oldest transports used for mail is UUCP. It effectively copies a file to a different system and pipes it into a program. UUCP can be used to transport mails in various ways.
rmail Each mail is copied verbatim to the client. It saves the sender address in form of a "From" pseudo header in the mail itself and supplies the recipient on the command-line. So it have access to both sender and recipient address.
Batched SMTP Batched SMTP transfers old-style SMTP transactions over UUCP The MTA (Exim supports this) or a special tool (in the bsmtpd package) writes this files and after a given time or size they are dispatched via UUCP to the remote system. The bsmtpd packages was removed from Debian some years ago.
Dovecot synchronization Dovecot support bi-directional synchronization of mailbox contents. It holds all data on both sides. The internal log is used to merge changes done on both sides, so it should not loose any data. This synchronization can be used to work with the data on both sides (via Dovecot of cause) or create backups. It needs shell access to the user owning the data on both sides.
Conclusions There is no one size fits all solution for this problem. If you admin the remote system, you can implement any of this solutions If it is managed by someone else you need good luck. Almost all solutions does not support current SMTP features. The one I'm really missing is DSN, aka configurable delivery notices. POP3 and IMAP handle already delivered mail and have no need for this. All UUCP variants does not handle it, because they are much older anyway. Only SMTP itself supports all of its features. I still use rmail over UUCP for my mails at home and it works flawless. UUCP itself runs over SSH, it can compress data on the fly and authenticate using private keys.

Russ Allbery: Review: Cry Wolf

Review: Cry Wolf, by Patricia Briggs
Series: Alpha and Omega #2
Publisher: Ace
Copyright: August 2008
ISBN: 0-441-01615-4
Format: Mass market
Pages: 310
Cry Wolf is a sequel to the novella Alpha and Omega. This was originally included in the anthology On the Prowl, which I had no particular interest in, but it's now available as a standalone novella if you have an ebook reader. I recommend reading it first if you have any interest in this series; it's not particularly expensive, and piecing together what happened in it while reading the beginning of Cry Wolf is not particularly enjoyable. There are some mild spoilers for Alpha and Omega here, so if you're planning on reading the novella first, you may want to do that before reading on. Anna is an Omega, an extremely rare form of werewolf who does not fall into the normal pack hierarchy. With normal werewolves, either the wolf is dominant or is submissive, and the most dominant wolf leads the pack and can force their will on the other pack members. Omegas are strange. Normal pack dominance doesn't really work on them, but neither are they dominant themselves. At the start of Cry Wolf, Anna has very little idea what any of this means. She's been rescued from a horribly abusive situation and is being brought to Montana by Charles, the enforcer and son of the leader of all North American werewolves. And, apparently, her mate, according to both of their wolf natures, but she's not entirely sure what that means either. She doesn't have a lot of time to find out, since the local pack is immediately threatened by a rogue werewolf and she's pulled into both pack politics and that hunt. Cry Wolf, despite being the first full book of the Alpha and Omega series, is set in the same world as Briggs's Mercy Thompson series. (At a guess, somewhere around Iron Kissed.) This is not just a vague link within the universe, unfortunately. The characters here refer frequently to Mercy and previous events in her series in that way that implies the reader should have read them, without explaining fully what happened. If, like me, you're more interested in this series than the Mercy Thompson series (I preferred it because there are no vampires and I'm sick of vampires), be aware that starting here will feel like starting in the middle of a series. This will be even worse if you don't read Alpha and Omega first, making the first section of the book feel like constant namedropping when you don't know any of the references. The story, otherwise, is basically hurt/comfort with a side of coming of age. Whether you will enjoy this will depend on whether you're in the mood for a fairly predictable story that hits those buttons. Anna is a mess, thrown into survival mode after years of abuse and hating what she's become. (She is, actually, somewhat less of a mess than I think she should be given what happened to her, although Briggs has both her Omega nature and her wolf as outs there.) Charles wants to comfort her and isn't sure how. She misreads things, he misreads things, there's lots of missed communication... you've probably read this story before and have a pretty good idea how it will go. They are somewhat less stupid about their communication problems than the typical novel of this type, but they still don't use words very well. The rest of the plot felt like mostly an excuse to throw Anna and Charles together doing something external to their relationship and to give Anna a chance to use her unique talents. It takes a bit to get going, since most of the early book is introductions and setting up all the connections to the Mercy Thompson stories, but there is some meat to it, including fleshing out the mythology of werewolves in Briggs's world. (And some passable descriptions of Montana wilds.) I'm not a big fan of how power struggles and combat seem binary and very hierarchical, but that seems to be the way that Briggs differentiates her werewolves, and it does form a sharp contrast with Anna's ability. I think Omegas could have been even more subtle than they are here, but the interplay between the conflict-driven approach of everyone else and Anna's inherent calm can be fun. The biggest problem I had with Cry Wolf, apart from the general predictability of the story and relationships, is that the hurt/comfort angle never felt adequately resolved. Hurting a character very badly and then having others offer comfort is a very common story technique that brings with it some reader expectations in terms of emotional payoff. The point at which the comfort finally works can be very empowering and very affecting. I don't think Briggs hit the payoff as well as she could have. Anna recovers, but she does so rather more easily than felt correct, and without the emotional punch that I was waiting for. It seems odd to complain about this sort of urban fantasy novel having too little angst, and maybe I was just hoping for a story other than the one I was reading, but I wanted a story that dug a bit deeper into Anna's psyche. I think the best word for Cry Wolf is okay. If this is the story you're in the mood for, it delivers that story. Briggs's werewolves are mildly interesting, and the Omega concept is a good one, although not as thoroughly or convincingly explored as I would have liked. I would have preferred more intensity in the hurt/comfort plot and a more difficult healing, but I still enjoyed the book. Followed by Hunting Ground. Rating: 6 out of 10

23 December 2012

Ben Hutchings: What's in the Linux kernel for Debian 7.0 'wheezy', part 1

As you may know, Debian 7.0 (codename 'wheezy') includes Linux 3.2. I'm maintaining the 3.2.y stable series at kernel.org which will collect bug fixes and some new hardware support as nominated by kernel developers and distributors, following the usual stable kernel rules. The Debian package has some additional features not present in mainline Linux 3.2. Union filesystem Debian Live needs a union filesystem to allow writing files on top of the read-only live system image. To support this, we include Aufs developed by Junjiro R. Okajima. I hope that Linux will gain union mount or union filesystem support in time for the next release, but currently it doesn't take much work on our part to integrate. Security hardening Bufferbloat I backported two big pieces of the solution to bufferbloat:

Russell Coker: Finding an ATM Skimmer

A member of SAGE-AU [1] found two ATM skimmers [2] and gave me permission to publish his description and analysis of the situation. I ve lightly edited this from a mailing list post to a blog format with permission from the author. This Courier-Mail article refers to the skimmers in question [3]. People were wondering what gave the skimmers away so here goes, NB this is only about the 2 I discovered.
  1. The actual atms in question were the free standing type (but even this doesn t matter in the scheme of things because they can be on those in a bank of the things).
  2. I d actually conducted transaction and was waiting for my card to come out of the machine these things looked that good. The colours matched especially in the 3/4 or less light that you typically have on the fascia s of such machine. The backing plate grey matched atm fascia as did the green bubble where the card goes.
  3. WHAT REALLY CAUSED SUSPICION my card was having difficulty coming out of the atm at end of transaction i.e. card coming out extra slow then only the end couple of mm, I had to physically grab my card with fingertips to get it out and there was barely perceptible movement of skimmer due to my fingers using the green bubble as purchase point, THAT was what made me suspect. I then really had close look and found that I could move the bubble with its backing plate I pulled it off the machine and then looked at the atm next to it and found it to look exactly the same. These things are held on by double sided tape.
  4. Grabbed the cleaning lady wandering past showed her the device and asked her to get security. Security and centre operations manager subsequently showed up, while waiting for them I had to stop people from using either machine (everyone amazed at how good these things looked). Centre ops guy went and checked other machines in the centre, I left my details and they called the cops I went straight to my credit union and reported what had happened and they cancelled my card and ordered a new one on the spot for me.
  5. Coincidently (or not) the centre ops and security lady told me that the machines had been serviced (refilled) not too much earlier that day i.e. I wondered if the bad guys did the service or were tracking armaguard servicing types.
Quick side notes:
  1. 3 more skimmers have been found since then.
  2. Subsequently, I found out these were the type that needed to be picked up for the bad guys to retrieve the data i.e. these weren t the type that transmitted to some-one sitting near by via Bluetooth/wireless i.e. in this instance I need not have cancelled my card and gotten a new one from my credit union.
    HOWEVER, it is best practice if you discover one and you ve used that machine to immediately have your financial institution cancel your card and issue you a new one though getting the new one can take up to a week.
  3. As I understand it, These 2 devices (i.e. others could be different) have 2 usb ports one for the reader and the other to a pinhole camera (commercially available type removed from it s original housing). The magnetic stripe data is held on the audio track associated with the video and there was an 8GB storage card to hold it all i.e. it makes things easier for the bad guys to match PINs to card details.
  4. If you do find a skimmer DO NOT touch the insides (non public facing parts) of it this is where the cops can really try lift dna and prints from; gathering prints from externally is far more fraught as everyone and their dog has probably touched the exterior of the skimmer.
  5. In the lead up to Xmas these things or similar are highly likely to become more prevalent as we all go about parting with dosh while gift shopping SO BE AWARE AND CAREFUL.

22 December 2012

Bartosz Feński: Two full-time days to work on Debian

My current employer as a benefit offers two days of paid volunteer time every calendar year. In September I decided to devote this time for Debian project. It wasn t easy to convince HR and my manager (hi Gloria ;) ) that such activity can be considered as volunteering but I eventually did it! So last Thursday and Friday were days I could spent working on my packages and other stuff related to Debian ;) Let s talk about effects. 5 packages updated, 16 bugs closed, more than 50 lintian warnings/errors solved. Here goes changelogs from updated packages:
calcurse (3.1.2-1) unstable; urgency=low
* The Akamai Technologies paid volunteer days release.
* Package made from scratch (this was funny experience):
- uses new quilt source format
- uses new copyright format
- uses debhelper compatibility level 9 w/hardening options
- uses the newest Standards-Version
* New upstream version:
- supports UTF8 (Closes: #558671)
- hopefully fixes problem with accented characters (Closes: #466010) -- Bartosz Fenski <fenio> Thu, 20 Dec 2012 13:51:08 +0100 httpie (0.3.1-1) unstable; urgency=low * The Akamai Technologies paid volunteer days release.
* Includes manual page (Closes: #673067)
Courtesy of Khalid El Fathi <khalid>. Thanks!
* New upstream version. (Closes: #693810)
- handles binary transfers properly (Closes: #689974) -- Bartosz Fenski <fenio> Thu, 20 Dec 2012 14:27:59 +0100 skipfish (2.10b-1) unstable; urgency=low * The Akamai Technologies paid volunteer days release.
* New upstream version.
* Bumped Standards-Version (no changes needed).
* Various path fixes because of upstream changes.
* Added new libpcre3-dev build dependency.
* Totally rewritten copyright file to comply with new copyright standard. -- Bartosz Fenski <fenio> Thu, 20 Dec 2012 14:59:36 +010 ipcalc (0.41-3) unstable; urgency=low * The Akamai Technologies paid volunteer days release.
* ACK previous NMU, thanks Christopher!
* Documents some missing features in the manpage (Closes: #588143)
Thanks Tanguy Ortolo <tanguy>!
* Fixes other minor problems in manpage (Closes: #688148)
* Description now says it's tool IPv4 only (Closes: #628955)
* Fixes lack of </table> tag when printing supernets (Closes: #600251)
* The following changes are courtesy of Jari Aalto <jari.aalto>:
- Remove deprecated dpatch and upgrade to packaging format "3.0 quilt".
- Update to Standards-Version to 3.9.3 and debhelper to 9.
- Add build-arch and build-indep targets; use dh_prep in rules file.
- Patch 03: update with "quilt refresh" to make it apply cleanly.
Thanks to these changes (Closes: #670737) -- Bartosz Fenski <fenio> Fri, 21 Dec 2012 12:30:11 +0100 netw-ib-ox-ag (5.39.0-1) unstable; urgency=low * The Akamai Technologies paid volunteer days release.
* New upstream version.
* Uses Homepage header. (Closes: #615219, #615294, #615321, #615436, #645522)
* Bumped Standards-Version (no changes needed).
* Switch to dpkg-source 3.0 (quilt) format)
* Fixes FTBFS on s390x and sparc64 (Closes: #639493)
* Fixes 29 (sic!) lintian warnings/errors thus many small changes
in packaging scripts.
-- Bartosz Fenski <fenio> Fri, 21 Dec 2012 15:38:29 +0200
Despite this I did something else. I sent end of the world joke-mail to debian-mentors mailing list stating (ignore the fact that my own server marked me as spammer; fixed already ;P) that I m going to review and try to upload every package that will be send to me during end-of-the-world day.
That action was quite successful although no package has been uploaded yet. I reviewed 4 of them and two more are yet to come. So it looks that these two days sponsored by Akamai motivated me enough to spent few more days or even months and help other people to contribute to Debian. Thank you Akamai!

Russ Allbery: Review: Regenesis

Review: Regenesis, by C.J. Cherryh
Series: Cyteen #2
Publisher: DAW
Copyright: January 2009
ISBN: 0-7564-0592-0
Format: Mass market
Pages: 682
Regenesis is a direct sequel to Cyteen, picking up very shortly after the end of that book and featuring all of the same characters. It would be absolutely pointless to read this book without first reading Cyteen; all of the emotional resonance and world-building that make Regensis work are done there, and you will almost certainly know whether you want to read it after reading the first book. Besides, Cyteen is one of the best SF novels ever written and not the novel to skip. Because this is such a direct sequel, it's impossible to provide a good description of Regenesis without spoiling at least characters and general plot developments from Cyteen. So stop reading here if you've not yet read the previous book. I've had this book for a while, and re-read Cyteen in anticipation of reading it, but I've been nervous about it. One of the best parts of Cyteen is that Cherryh didn't belabor the ending, and I wasn't sure what part of the plot could be reasonably extended. Making me more nervous was the back-cover text that framed the novel as an investigation of who actually killed the first Ari, a question that was fairly firmly in the past by the end of Cyteen and that neither I nor the characters had much interest in answering. Cyteen was also a magical blend of sympathetic characters, taut tension, complex plotting, and wonderful catharsis, the sort of lightning in a bottle that can rarely be caught twice. I need not have worried. If someone had told me that Regenesis was another 700 pages of my favorite section of Cyteen, I would have been dubious. But that's exactly what it is. And the characters only care about Ari's murderer because it comes up, fairly late in the novel, as a clue in another problem. Ari, and Justin, are back in the safe laboratory environment of Reseune, safe now that politics are not trying to kill or control them. Yanni has taken over administration. There is a general truce, and even some deeper agreement. Everyone can take a breath and relax, albeit with the presence of Justin's father Jordan as an ongoing irritant and hostile factor. But broader Union politics are not as stable: there is an election in progress for the Defense councilor that may break the tenuous majority in favor of Reseune and the Science Directorate, Yanni is working out a compromise to gain more support by turning a terraforming project loose on a remote world, and Ari isn't sure she likes that Eversnow idea at all. Then, just as things seem to be turning Reseune's way, politics and interpersonal relationships abruptly deteriorate, tensions with Jordan sharply worsen, and there may be moles in Reseune's iron-clad security. Navigating the crisis while keeping her chosen family safe will once again tax all of Ari's abilities. The third section of Cyteen, where Ari finally has the tools to take fate into her own hands and starts playing everyone off against each other, is one of my favorite sections of any book. If it was yours as well, Regenesis is another 700 pages of exactly that. As an extension and revisiting, it does lose a bit of immediacy and surprise from the original, and Regenesis is much less concerned with the larger questions of azi society, the nature of thought and personality, loyalty and authority, and the best model for the development of human civilization. It's somewhat less far-thinking and more of a political thriller. But it's a political thriller that recaptures much of the drama and tension of Cyteen and is full of exceptionally smart and paranoid people thinking through all angles of a problem, working fast on their feet, and successfully navigating tricky and treacherous political landscapes. And, like Cyteen but unlike others of Cherryh's novels I've read, it's a novel about empowerment, about seizing control of one's surroundings and effectively using all of the capability and leverage at one's fingertips. That gives it a thrilling catharsis that's almost as good as Cyteen. It's also, like its predecessor, a surprisingly authoritarian novel. I think it's in that, more than anything else in these books, that one sees the impact of the azi. Regenesis makes it clear that the story is set, not in a typical society, but inside a sort of corporation, with an essentially hierarchical governance structure. There are other SF novels set within corporations (Solitaire comes to mind), but normally they follow peons or at best mid-level personnel or field agents, or otherwise take the viewpoint of the employees or the exploited. When they follow the corporate leaders, the focus usually isn't down inside the organization, but out into the world, with the corporation as silent resources on which the protagonist can draw. Regenesis is much more of a balance. It's about decisions of the future of humanity that characters feel they can make undemocratically (in part because they or their predecessors have effectively engineered the opinions of the democratic population), but it's also about how one manages a top-down organization. And, most vitally, how one secures it. Reseune is, as in the previous novel, a paranoid's suspicions come true; everyone is out to get everyone else, or at least might be, and the level of omnipresent security and threat forces a close parsing of alliances and motivations that elevates loyalty to the greatest virtue. In Cyteen, we had long enough with Ari to see the basic shape of her personality and her slight divergences from her predecessor, but her actions are mostly driven by necessity. Regenesis gives us more of a picture of what she's like when her actions aren't forced, and here I think Cherryh manages a masterpiece of subtle characterization. Ari has diverged substantially from her predecessor without necessarily realizing it, but in ways that are firmly grounded in the differences she found or created between her life and the first Ari's. Specifically, she has friends, confidents, and a community, which combined with past trauma has made her fiercely, powerfully protective, and it's that protective instinct that weaves the plot together. It's probably the most significant way in which so much of the events of Cyteen and Regenesis are driven by people's varying reactions to trauma. If you, like me, loved the last third of Cyteen, read this, because Regenesis is more of exactly that. Cherryh finds new politics, new challenges, and a new and original plot within the same world and with the same characters, but it has the same feel of maneuvering, analysis, and decisive action. You will, as with Cyteen have to be comfortable with pages of internal monologue from really smart people thinking through all sides of a problem. If you didn't like that in the previous book, avoid this one; if you loved it, here's the sequel you didn't know you were waiting for. Rating: 9 out of 10

21 December 2012

Wouter Verhelst: BSP postmortem

This post is a bit late, but still interesting: Last weekend, I held a Bug Squashing Party at my company's offices in Mechlin, Belgium. This is the first time I've attended, let alone hosted, such an event; so I'm not that experienced in figuring out what I can and cannot do with other people's packages yet. As a result, our success rate was a bit lower than I'd hoped for. Still we closed two bugs, figured out that one more bug required just some binNMUs, that one should probably be tagged wheezy-ignore (as it was tagged squeeze-ignore too, and hasn't seen updates since then), and touched three more bugs. Having said that, I did have a bit of a hidden agenda, in that I've been wanting to build a stronger Debian community in Belgium; we are ranked fairly highly on the Debian Developer per capita list, but us Belgian DDs never meet up, in contrast to DDs from three of the four countries that surround Belgium. In that, I did have some success, too; some local people showed up who'd never (directly) contributed to Debian before. While I'm not silly enough to think that just showing up to a BSP once makes you suddenly an active member of a community, it's still a good first step. Unfortunately, however, I did not manage to get any other active Belgian DDs to show up. Apart from myself, only Dutch DD Joost Van Baal and DD Emeritus Joost Damad were present. If I can't find a way to improve on that, I'm not sure this BSPing will have a long life in Mechelen. At any rate, though, I did have a lot of fun doing this. Surely that, if nothing else, counts as "success".

20 December 2012

Wouter Verhelst: Installing Debian to the network with NBD

As I've blogged about before, wheezy will be the first release since I've started maintaining NBD for Debian to feature NBD support in the installer. That is, you'll be able to install wheezy to the network, simply by adding "modules=partman-nbd" to the kernel command line: obligatory screenshot While I'm happy and, in fact, a bit proud about that fact, there are still a few minor issues that make the whole process a bit less smooth than it could be: In my plan to take over the world of network storage, I plan to work on that last point during the jessy release cycle, at least for x86 architectures; I envision a system which would mount /boot on NFS, and write pxelinux.cfg files, where the name of this config file would be configurable (so it can be configured to only boot the system on which the file was written, or to boot any system on the local network). If done well, it will also fix the point about installing the bootloader to local hard disk when doing a network installation, since we'll have a "install netbootloader" or some such option.

Francois Marier: Keeping GMail in a separate browser profile

I wanted to be able to use the GMail web interface on my work machine, but for privacy reasons, I prefer not to be logged into my Google Account on my main browser. Here's how I make use of a somewhat hidden Firefox feature to move GMail to a separate browser profile. Creating a separate profile The idea behing browser profiles is simple: each profile has separate history, settings, bookmarks, cookies, etc. To create a new one, simply start Firefox with this option:
firefox -ProfileManager
to display a dialog which allows you to create new profiles:
Once you've created a new "GMail" profile, you can start it up from the profile manager or directly from the command-line:
firefox -no-remote -P GMail
(The -no-remote option ensures that a new browser process is created for it.) To make this easier, I put the command above in a tiny gmail shell script that lives in my ~/bin/ directory. I can use it to start my "GMail browser" by simply typing gmail. Tuning privacy settings for 2-step authentication While I initially kept that browser profile in private browsing mode, this was forcing me to enter my 2-factor authentication credentials every time I started the browser. So to avoid having to use Google Authenticator (or its Firefox OS cousin) every day, I ended up switching to custom privacy settings and enabling all cookies:
It turns out however that there is a Firefox extension which can selectively delete unwanted cookies while keeping useful ones. Once that add-on is installed and the browser restarted, simply add accounts.google.com to the whitelist and set it to clear cookies when the browser is closed:
Then log into GMail and tick the "Trust this computer" checkbox at the 2-factor prompt:
With these settings, your browsing history will be cleared and you will be logged out of GMail every time you close your browser but will still be able to skip the 2-factor step on that device.

Russ Allbery: WebAuth 4.4.0

WebAuth is a site-wide web authentication system with single sign-on support. We use it extensively at Stanford for most of our user-facing web applications that need to authenticate people. This is the culmination of the last four months of work, so it's rather nice to finally get it out the door. Even if not everything I wanted to get done is done. That's always how it is with software releases. This release fixes a bug in the encoding of delegated Kerberos credentials when Heimdal is used as the Kerberos library. If you're building WebAuth against Heimdal, upgrade any mod_webauth modules that receive delegated credentials before upgrading mod_webkdc on the WebKDC. Otherwise, the flags of delegated tickets won't be sent correctly. The major new feature in this version is support for authorization identities separate from authentication identities. This can be used for testing, for administrators to proxy into an application as another user, or in other cases where there's a mismatch between the canonical concept of users and the capabilities of an application. The WebLogin server and WebKDC now support an ACL file that controls what alternative identities users can assert to specific web sites, and there is a new flow on the WebLogin side to set or change identities. All of this is disbled by default in each component. There is a new WebKDC directive to enable this support and specify the identity ACL file, and there is a new directive in mod_webauth to tell it to trust the authorization identity. There is a new environment variable that will be set to the authorization identity (trusted or not), and REMOTE_USER will be set to the authorization identity only if it is trusted. WEBAUTH_USER will always remain the authentication identity, so both identities can be logged and web applications can distinguish. To address one of the edge cases required by this support, there's a new mod_webkdc Apache directive, WebKdcLoginTimeLimit, which controls how long a multi-step login process can take, and also how recent a login has to be to contribute its authentication factors to the session factors for an authentication. This is also now used for WebAuthForceLogin, which means that forced logins won't require re-authentication if they're within the WebKdcLoginTimeLimit interval of the last login. This allows that feature to work properly in conjunction with authorization identities and with some multifactor authentication methods. Also in this release, optional replay detection and rate limiting of failed logins has been added to the WebLogin server. Either or both can be enabled in the configuration file. This support requires a memcached server (shared across any pool of WebLogin servers) be available to store the necessary state. There are new parameters in the error template to handle the error messages generated by these features. The WebLogin server also has a few more minor improvements: single sign-on cookies are now set even when displaying error pages if any are available, fixing some looping issues with some scenarios around restricting users to authenticate to specific sites, and the @REMUSER_REALMS setting has been broken into two settings so that its two properties can be changed independently. The old setting is still supported for backward compatibility. Multiple bugs in Kerberos ticket encoding have been fixed, some that were introduced in 4.3.0 and some that have been present since the first days of Heimdal support. Other fixes include the mapping of WebKDC error codes to names in WebLogin (which previously resulted in Perl warnings in the error log) and the missing documentation for the WebAuthRequireSSL directive. Finally, the thing that I'm the happiest about in this release is that I finished my complete refactoring of the libwebauth library. Most of the low-level interfaces are gone in favor of higher-level manipulation of WebAuth protocol objects. The last pieces of code that used the old token encoding system have been replaced with the new data-driven encoder. And the last parts of the library have been converted to APR, so there is no longer a mix of traditional memory management and APR pools. This comes with lots of simplification of the API and removal of old cruft from the public headers. You can get the latest release from the official WebAuth distribution site or from my WebAuth distribution pages.

19 December 2012

Clint Adams: Then nobody played Bingo

No, Simon, not yet. [Things on paper]

18 December 2012

Russ Allbery: Review: Liars and Outliers

Review: Liars and Outliers, by Bruce Schneier
Publisher: John Wiley
Copyright: 2012
ISBN: 1-118-14330-2
Format: Hardcover
Pages: 285
One of the perils of buying a book written by a blogger one reads regularly is that the book may be little more than a rehashing of their blog, with insufficient original material to warrant the time investment. Sometimes it's still nice to support them financially, but it may not make sense to read the book. I've been following Schneier's blog for years (as should anyone with an interest in security), including through the entire process of writing Liars and Outliers, and was a bit worried that might be the case here. Thankfully, I can reassure any other worried potential readers that is not the case. This is substantial new material establishing a firm framework for thinking about incentives and controls in any society or organization. Liars and Outliers talks about security mechanisms, but it's not, at its core, a book about security. Rather, it's a book about incentives, order, and how order is established. It's a comprehensive reductionist analysis of how societies create predictability and compliance to allow us to trust other people who we have never met before and will never meet again. It's a unique (at least in my experience) combination of anthropology, sociology, security analysis, and political science. Schneier cuts across fields in an idiosyncratic but illuminating way that reminded me of (on an entirely separate topic) Jane Jacobs. This is not a prescriptive book, nor is a collection of answers, solutions, or even deep analysis of particular problems. Rather, it's an attempt to construct a general framework for analyzing societal dilemmas: conflicts between individual desires and social good, how those conflicts are resolved, and how societies can weigh the scales and influence the statistical outcomes. The closest Schneier comes to telling the reader how to solve problems is a checklist, at the end of the book, for designing effective societal pressures. Its primary contribution is vocabulary and structure. It also passes one of my litmus tests for any book about human behavior: Schneier complicates, broadens, deepens, and expands understanding, and points out complex interactions and complex feedback in effects we're inclined to consider simple, rather than simplifying or eliminating human complexity. One point I found refreshing about this book is that Schneier is scrupulous in refusing to define either society or individuals as good or bad, to the point of carefully defining terminology used in all of the social dilemmas. Following societal rules is called compliance; not following those rules is called defection. In some cases, defection is morally correct (Schneier's most frequent example is in the civil rights struggles of the 1960s in the United States). In all cases, social pressures are tools, which can be used to encourage compliance with moral or immoral systems, and which are deployed by totalitarian dictatorships and utopian communes alike. Schneier explicitly puts out of scope for this book the questions of how societal goals should be determined, how they change, and whether any given societal rule or interest is moral or immoral. He focuses, rather, only on the mechanisms, with a primary goal of informing and deepening debates over how best to encourage behavior that societies want to encourage and discourage behavior societies want to discourage. He also emphasizes discourage, as opposed to eliminate. Early on, Schneier shows some of the results of game theory, as well as basic common sense, that indicate that no healthy society can totally eliminate defection. Not only would that stifle valuable and important reform, such as changes in civil rights, but the degree of pressure required is immense. Defectors are natural and will always exist, and are sometimes valuable and necessary. Rather, the goal of a society is to reduce defectors to a level where most people can ignore their existence most of the time, a state that leads to the level of risk and trust required to have a functioning and healthy society. The word society, similarly, is intentionally broad, and can refer to just about any collection of people, from a circle of friends to a corporation, institution, or country. However, as Schneier points out early in the book, small societies rarely need much in the way of formal pressure and appear almost magically self-governing. That's the first property that he disassembles, resulting in a general classification of societal pressures into four categories: moral, reputational, institutional, and security systems. The last is an odd category that's partly orthagonal to the other three. Moral pressure is internalized conscience: the normal tendency of nearly everyone to follow their own moral code, a code that's at least partly constructed and certainly heavily influenced by the surrounding society. Reputational pressure is, in a sense, externalized morality: it's the informal reactions of others around one to one's past actions. Included in reputational pressure is shunning of every kind, from cutting off a friendship to boycotts against corporations, but it also includes confrontation from another member of one's society, the more subtle effects of our individual desires to be liked and respected, and all the various aspects of "face", honor, and respect within a community. Small communities are frequently self-governing, in Schneier's model, because they're small enough that moral and reputational pressures are sufficient and no other pressures are required. We're so used to applying moral and reputational pressure to other humans almost unconsciously that we sometimes don't even notice its existence, leading to that "magical" self-governing property. But Schneier puts pressures in a sequence: pressures that work extremely well with small groups often don't scale. Moral pressure works best with small groups and reputational pressure with somewhat larger groups, but when societies scale beyond the limits of reputational pressure when, for example, one frequently interacts with people whose reputations are unknown to you and whose subsequent opinion of you will not be relevant institutional pressure is required to force compliance. Institutional pressure is the sort of pressure that we all tend to think of first when we look for ways to enforce rules: laws, policies, contracts, and other codes of behavior that carry with them formal punishments and some enforcement mechanism. But even in societies so large that institutional pressures are frequently required, such as whole countries, moral and reputational pressures still exist and are extremely important. One of Schneier's most interesting points is his analysis of how institutional pressures can paradoxically undermine reputational and moral pressures, resulting in more defection than if the institutional pressure hadn't existed. This is just the basic framework of Schneier's analysis, hopefully giving you a feel for the structure of the book. He goes much deeper into the complicated interactions between the various levels of pressure, and then dives into an extensive look at competing societal dilemmas: cases where there is more than one society in play simultaneously, possibly demanding contradictory actions. Liars and Outliers also includes a wonderful analysis of organizational entities within the same framework, including their much-different reactions to moral, reputational, and institutional pressures. One of the most cogent analyses of the difficulties of regulating both corporations and governmental institutions falls out of that analysis, once one looks at them in light of Schneier's basic framework. Pressures quickly become complex and multi-layered, and human reactions to pressures are frequently counter-intuitive. Schneier draws extensively on game theory to show that some counter-intuitive responses are actually emergent properties of logical analysis of the situation, but that others are more uniquely human and have little or nothing to do with a mathematical cost-benefit analysis. I haven't even mentioned his discussion of security systems, and how they can extend moral, reputational, and institutional pressures, as well as add a new type of pressure (making a defecting action impossible) that scales even better than institutional pressures. Liars and Outliers has all of the supporting infrastructure you would expect in a scholarly book: notes, extensive references, and a good index. I suspect it will end up being used as at least additional reading in college classes. The notes are, unfortunately, end notes, making the full context of the book much harder to read than was necessary, but at least Schneier does separate the notes from the references so that one doesn't chase notes for further explanation and find a simple citation. As with any book like this, one always wishes it could end in a simple prescription to fix everything, but of course it doesn't. But that's also a measure of a good scholarly work. Human and organizational motivations are complex and tricky, and any framework for analyzing them needs to be able to represent that complexity. Schneier here has constructed a very powerful one, one that I started using in discussions before I'd even finished the book. Perhaps the most valuable contribution of Liars and Outliers to public discussion is clear terminology and categories, which can be of great help in finding the core components of a problem. Liars and Outliers can be slow going, particularly early on when Schneier is still defining terms and setting up the background of his analysis. One can get a bit tired of the analysis matrices of societal dilemmas. But stick with it through the groundwork, since the analyses of competing societal dilemmas and of the impact of societal pressures on organizations are exceptional. Highly recommended, particularly for anyone who is designing or implementing societal pressures: managers, political activists, or anyone in a security-related field. Rating: 8 out of 10

Dirk Eddelbuettel: R / Finance 2013 Call for Papers

The text below just went out to r-sig-finance along with updates to the R/Finance website and its Call for Papers page.
Call for Papers: R/Finance 2013: Applied Finance with R
May 17 and 18, 2013
University of Illinois, Chicago, IL, USA
The fifth annual R/Finance conference for applied finance using R will be held on May 17 and 18, 2013 in Chicago, IL, USA at the University of Illinois at Chicago. The conference is expected to cover topics including portfolio management, time series analysis, advanced risk tools, high-performance computing, market microstructure, and econometrics. All will be discussed within the context of using R as a primary tool for financial risk management, portfolio construction, and trading. Over the past four years, R/Finance has included attendees from around the world. It featured presentations from prominent academics and practitioners, and we anticipate another exciting line-up for 2013. We invite you to submit complete papers in pdf format for consideration. We will also consider one-page abstracts (in txt or pdf format) although more complete papers are preferred. We welcome submissions for full talks and abbreviated "lightning talks". Both academic and practitioner proposals related to R are encouraged. Presenters are strongly encouraged to provide working R code to accompany the presentation/paper. Data sets should also be made public for the purposes of reproducibility (though we realize this may be limited due to contracts with data vendors). Preference may be given to presenters who have released R packages. The conference will award two (or more) $1000 prizes for best papers. A submission must be a full paper to be eligible for a best paper award. Extended abstracts, even if a full paper is provided by conference time, are not eligible for a best paper award. Financial assistance for travel and accommodation may be available to presenters at the discretion of the conference committee. Requests for assistance should be made at the time of submission. Please send submissions to: committee at RinFinance.com. The submission deadline is February 15, 2013. Submitters will be notified of acceptance via email by February 28, 2013. Notification of whether a presentation will be a long presentation or a lightning talk will also be made at that time. Additional details will be announced at this website as they become available. Information on previous year's presenters and their presentations are also at the conference website. For the program committee:
Gib Bassett, Peter Carl, Dirk Eddelbuettel, Brian Peterson,
Dale Rosenthal, Jeffrey Ryan, Joshua Ulrich
So see you in Chicago in May!

17 December 2012

Ian Campbell: Foreign Chroots with schroot and qemu

Since I've been working on qcontrol I've had need of a way to build packages in an ARM environment. Since all my native ARM hardware is "production" (at least so far as something can be production in a home environment) I prefer to avoid installing development tools on them. When I started looking into this all my ARM systems ran from relatively small flash devices which also ruled out the possibility of a development chroot. After search the web a bit I discovered that it is possible to use qemu-user-static together with [[!binfmt-support ]] to create cross architecture chroots which can be entered mostly transparently. It is also possible to combine this with schroot and sbuild which makes the day to day use pretty much the same as a native or biarch chroot. Since I've now had to rediscover how to do this twice (once for Sid and then again when I realized I also needed a Wheezy environment) I thought I should write it down for the benefit of my future self. First things first lets install the various packages which we need. As well as debootstrap to create the chroot we need qemu-user-static and binfmt-support to allow us to run ARM binaries:
$ sudo apt-get install debootstrap qemu-user-static binfmt-support
I'm using schroot's lvm-snapshot mode so we need an LVM volume, formatted with a filesystem and mounted in a temporary location:
$ sudo lvcreate -L8G -n sbuild-wheezy-armel /dev/VG
$ sudo mkfs.ext3 /dev/VG/sbuild-wheezy-armel
$ sudo mount /dev/VG/sbuild-wheezy-armel /mnt/
Next we need to create the chroot. For this we use debootstrap in foreign mode which does a 2 stage setup, firstly by using the --foreign option:
$ sudo debootstrap --variant=buildd --include=fakeroot,build-essential \
        --arch=armel --foreign \
        wheezy /mnt http://<DEBIAN-MIRROR>/debian/
Now we (temporarily) copy the qemu-arm-static binary into the chroot (at the place where binfmt-support expects it), change into the chroot and run debootstrap's second stage to finish the basic chroot setup:
$ sudo cp /usr/bin/qemu-arm-static /mnt/usr/bin/
$ sudo chroot /mnt
(chroot)# ./debootstrap/debootstrap --second-stage
(chroot)# exit
Now that we have a basic chroot in place it needs a little bit of tailoring. I've found the easiest way to do this is to use sbuild-createchroot and then tweak the result:
$ sudo sbuild-createchroot --arch=armel --foreign --setup-only \
    wheezy /mnt http://<DEBIAN-MIRROR>/debian/
If we were building a native chroot then we could have skipped the debootstrap stuff and let sbuild-createchroot handle things. Unfortunately this doesn't seem to play nicely with --foreign. Now we can remove the qemu-arm-static binary from the chroot. schroot will automatically bind mount the version from the host into the chroot which ensures it remains up to date. We can also unmount the chroot since we will let schroot manage that from here on:
$ sudo rm /mnt/usr/bin/qemu-arm-static
$ sudo umount /mnt
Next we need to tweak the resulting schroot/sbuild configuration since sbuild-createchroot assumes the use of schroot's directory mode. First remove the symlink to /mnt which it created:
$ sudo rm /etc/sbuild/chroot/wheezy-armel-sbuild
Lastly we need to edit /etc/schroot/chroot.d/wheezy-armel-sbuild-<SUFFIX> (where is randomly generated) and reconfigure it to use lvm-snapshot mode, by apply the following changes:
 [wheezy-armel-sbuild]
-type=directory
-directory=/mnt
+type=lvm-snapshot
+device=/dev/VG/sbuild-wheezy-armel
+lvm-snapshot-options=--size 2G
 description=Debian wheezy/armel autobuilder
 groups=root,sbuild
 root-groups=root,sbuild
 profile=sbuild
That's it, we now have a chroot which we can trivially invoke via sbuild to build armel packages:
$ sbuild --arch=armel --dist=wheezy <... other options...>
We can also use sbuild-update to keep the chroot up to date:
$ sudo sbuild-update -udcar wheezy-armel
You can also use schroot to login to the chroot directly, although for that case you'll likely want to create a different chroot using schroot's directory or block-device mode instead lvm-snapshot and drop some of the sbuild specific setup. I expect I'll blog about this configuration in some more detail at some point in the future since I'll want to document it to give a more convenient build environment for Xen on ARM than the build farm which we have at work.

Dominique Dumont: Be wary of optimised for devices

Hello This story began with linphone having a weird behavior: every now and then, the mouse pointer would become stuck: the pointer moves, but clikcking on it always activate the same widget. Since this always happened in the middle of phone conference done for work, this was infuriating. Long story short, I finally found that my plantronics USB headset was responsible for this weird behavior. This headset is connected to the USB bus and is seen by the computer as a USB sound card. The bug was triggered by pressing the mute button provided by the headset. Suspicious of this usb device, I used lsusb to find the features provided by the heaset: $ lsusb -v -s 1:3 2>&1 grep InterfaceClass
bInterfaceClass 1 Audio
bInterfaceClass 1 Audio
bInterfaceClass 1 Audio
bInterfaceClass 1 Audio
bInterfaceClass 1 Audio
bInterfaceClass 3 Human Interface Device
Audio devices were expected, but why a HID device ? This device is a headset, not a keyboard or a mouse Testing further, I also saw some number poping up on my screen whenever I pressed the the mute button. The only way to get the mouse back was to unplug the headset. A quick google search gave a solution to setup X11 to ignore the headset. Problem solved. But this did not answer the question regarding the HID device. Then I got a hint in the form of a sticker glued on the headset USB plug: Optimized for Microsoft Lync . This page gave the answer: an optimised for Lync device provides mute/unmute across PC and device . I can only guess that when the mute button is pressed, some data is sent from the HID interface. Unfortunately, the window manager does not like to be on the receiving end of this data. The moral of this story is: optimized for something actually means not standard .
ok. There s a bug somewhere. The comments of this blog have convinced me that I went too far with the moral of this story. It s now overstriked instead of plainly remvoed so the comments still make sense. Thanks everybody for the constructive comments.
All the best
Tagged: wtf

Jaldhar Vyas: Heads Up: Latest Dovecot Package Loses Features

Sometimes it's easy to forget that Debian's unstable branch is...unstable. Unfortunately today I have to remind you of that unpleasant fact. Dovecot 2.1.7-6 which I just uploaded has removed some features present in -5. The reason for this is that I am trying to get dovecot in shape for Wheezy. Unfortunately, as I have been severely pressed for time these past few months, the process did not take place in quite as orderly a fashion as I had hoped. My -5 packages were deemed by the release managers to have too drastic changes for this stage of the pre-Wheezy freeze and this is an attempt to make things more acceptable to them. Hopefully this version will pass into testing without incident and as soon as it does, I will prepare -7 which will put these features back. So if you need any of them, you are advised to skip -6 and stay at -5 until that happens. If you are following testing there is another possible problem you might encounter. When -1 of this version was uploaded, certain extra conf files were accidently omitted from the package. This is also true of -2 which is currently in testing. It was fixed in -3 but that version (or -4 or -5) never made it into testing so -6 is potentially the first time you might be dealing with the conf file fix. If you have manually made changes to files in /etc/dovecot/conf.d make sure you have backups because they may get overriden (as dpkg will be unaware at that point that they are conffiles.) This is a one time only packaging error and will not be a problem going forward but I apologize in advance for any inconvenience caused. And this is a good time to ask anyone interested in Dovecot on Debian (and Ubuntu etc.) to volunteer to help maintain it. It is getting more and more popular at a time when I can give it less and less attention. It is vital that an important package like this needs is team-maintained and it kind of is but so far other people who have expressed an interest in joining the team have been similarly strapped for time so we still need more recruits. All the code is publically accessible at git://git.debian.org/git/collab-maint/dovecot.git and I would be happy to sponsor any non-DD/DMs who need it.

Next.

Previous.