Search Results: "will"

25 December 2012

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

Wouter Verhelst: m68k: back from the dead

It's been a few years coming, but the day has finally arrived. Contrary to some rumours which I've had to debunk over the years, the m68k port did not go into limbo because it was kicked out of the archive; instead, it did because recent versions of glibc require support for thread-local storage, a feature that wasn't available on m68k, and nobody with the required time, willingness, and skill set could be found to implement it. This changed a few years back, when some people wrote the required support, because they were paid to do so in order to make recent Linux run on ColdFire processors again. Since ColdFire and m68k processors are sufficiently similar, that meant the technical problem was solved. However, by that time we'd fallen so far behind that essentially, we needed to rebootstrap the port all over again. Doing that is nontrivial, and most of the m68k porters team just didn't have the time or willingness anymore to work on this; and for a while, it seemed like the m68k port was well and truly dead. But then, two things happened. The first thing that happened was called "ARAnyM", short for "Atari Running on Any Machine". An atari emulator, it started supporting running Linux at some point, allowing us to work on the port while on the road, using a laptop something not possible beforehand. While there were some bugs in the emulation of early versions of aranym, these were all fairly quickly fixed, and before long we could run Debian/m68k in the emulator. However, that was still the etch-m68k port on debian-ports.org, some time after Debian etch wasn't even supported anymore; this still required work. The second "thing" that happened was called "Thorsten Glaser". A fresh DD and maintainer of the "mksh" shell, he wanted to make sure his shell would work on all Debian architectures, including the ones on debian-ports.org. When he found out that the m68k port was in a pretty bad shape, he did not, like many before him, shrug and move on; instead, he took it upon himself to start compiling things, just so he could compile his shell. How's that for dedication. Anyway, fast-forward two years, and we're now, finally, at a point where I spent most of today getting buildd up and running on arrakis, one of our oldest buildd hosts. There were some issues while trying that, but it looks like everything is in working order now; and the first package to start building on the first functioning buildd host since a long time (the build of which is still ongoing at the time of this writing) is "babl". Of course, with only one buildd, we'll have no hope whatsoever of ever catching up. But that can be remedied easily by using more than one buildd host... Update: It built! Party!

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.

Julien Danjou: Ceilometer bug squash day #1

In order to start the year in a good mood, what's the best than squashing some bugs on OpenStack? Therefore, the Ceilometer team is pleased to announce that it organizes a bug squashing day on the Friday 4th January 2013. We wrote an extensive page about how you can contribute to Ceilometer, from updating the documentation, to fixing bugs. There's a lot you can do. We've good support for Ceilometer built into Devstack, so installing a development platform is really easy. The main goal on this bug day will be put Ceilometer in the best possible shape before the grizzly-2 milestone arrives (10th January 2013). This version of Ceilometer will aim to keep compatibility with Folsom, so early deployers can enjoy some of our new features before upgrading to Grizzly. After that date, we'll start merging more extensive changes. We'll be hanging out on the #openstack-metering IRC channel on Freenode, as usual, so feel free to come by and join us!

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

Russ Allbery: Review: Alpha and Omega

Review: Alpha and Omega, by Patricia Briggs
Series: Alpha and Omega #1
Publisher: Berkley
Copyright: 2007
ISBN: 1-101-41379-4
Format: Kindle
Pages: 112
Alpha and Omega is a novella set in Briggs's Mercy Thompson universe, an urban fantasy world that started with Moon Called. There's a limited edition hardcover version which is, at this point, ridiculously expensive, but it's available relatively inexpensively on the Kindle. (The page count in the sidebar may be high, since that's from the hardcover version; the Kindle version doesn't have page numbers.) It's the prequel novella to the novel Cry Wolf. You don't have to have read any of the Mercy Thompson novels to follow the story; it stands alone fairly well. I actually read Cry Wolf first, but (as I was warned) that proved to be a mistake, so I'm publishing my reviews in the "correct" reading order. Unusually for a niche novella leading into a regular series, Cry Wolf leans heavily on Alpha and Omega and works best if you've read it first. Anna is a werewolf, but not a very happy one. She's been a werewolf for three years, cutting herself off from everything before at the insistance of her pack, and she's at the bottom of the pecking order: abused, mistreated, and ordered about (although some of the abuse has gotten mildly better). That makes it startling that, when she sees a photograph in the paper of a missing teenager that she recognizes, she's willing to call the Marrok, the ruler of all wolves in North America, to report her pack's possible involvement. The Marrok sends his enforcer, Charles, to investigate. As soon as he arrives, he can tell that far more is wrong than anyone had realized. Anna's pack is completely dysfunctional, and Anna herself... well, that's the point of the story. Alpha and Omega has one of the more appealing qualities of novellas: a clear narrative drive that goes from point A to point B without many sidetracks or digressions. It's told in alternating tight third person perspectives, a traditional choice for this sort of story. Very little here will surprise an urban fantasy reader. It's the hurt/comfort story that one expects from the early going, but it's one that moves right along and hits most of the right notes. The biggest drawback for me was that I'm not horribly fond of Briggs's werewolf mythology. There are some parts that I like, such as Anna herself and the role that she discovers, but there's rather a lot of characters wrestling with their instinctive reactions or finding pack hierarchy enforced via means that appear to be magic. Given that the sort of absolute dominance hierarchy portrayed here is now considered dubious or refuted even in wild wolves, and given that I have a knee-jerk dislike of simplified, absolute structures, that part of Briggs's world-building makes my teeth itch. But, if you can get past that, and if you're not looking for any complex plotting (it is just a novella, after all), this isn't a bad way to spend an afternoon. It's comfort reading: things go roughly as you would expect them to go, and you can have the emotional satisfaction of seeing Anna's growth with very little risk. Followed by Cry Wolf. Rating: 7 out of 10

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:

Cyril Brulebois: d-i hacking recipe #3: Debugging debconf

Problem #3: How to find out what s going on with debconf? Slightly longer version: As reported in #679327, the grub prompt during the installation process is entitled Configuring man-db , which isn t exactly great. Given man-db is a known dpkg trigger, I suspected this would be the reason for the broken title, and here s how I debugged it. For starters, using d-i basically means asking a lot of questions, which is implemented using the debconf mechanism. One should note that two implementations are available:
  1. the historic implementation, in Perl: debconf
  2. the C reimplementation: cdebconf
d-i uses cdebconf udebs, but joy begins when packages get installed in /target: debconf is used there. We ll see why that matters. Recipe #3: Set DEBCONF_DEBUG=developer and read logs!
  1. Both implementations support the DEBCONF_DEBUG environment variable. The installer supports passing that as a kernel parameter; example from the syslinux prompt: select the Graphical install entry, press Tab , remove -- quiet and put DEBCONF_DEBUG=developer there instead.
  2. Let s look at /var/log/syslog; there s a tail -f on it in VT4, but one can run grep and friends on it in VT2 or VT3. There, one can see what happens at the debconf level (the debconf protocol is documented in debconf-devel(7)). Tiny excerpt (timestamps removed for clarity):
    frontend: --> GET preseed/early_command
    frontend: <-- 0
     
    frontend: --> GET debian-installer/framebuffer
    frontend: <-- 0 true
     
    debconf: --> GET debconf/language
    debconf: <-- 0 en
    debconf: --> SET debconf/language en
    debconf: Setting debconf/language to en
    debconf: <-- 0 value set
    debconf: --> GET debconf/priority
    debconf: <-- 0 high
    debconf: --> GET rescue/enable
    debconf: <-- 0 false
    
  3. The interesting point was titles, right? So let s look at the last TITLE occurrences:
    debconf: --> SETTITLE debian-installer/main-menu-title
    debconf: --> SETTITLE debian-installer/grub-installer/title
    in-target: debconf (developer): ----> TITLE Configuration de man-db
    debconf: --> TITLE Configuration de man-db
    in-target: debconf (developer): <-- TITLE Configuration de man-db
    in-target: debconf (developer): ----> TITLE Configuration de man-db
    in-target: debconf (developer): ----> TITLE Configuration de grub-pc
    debconf: --> TITLE Configuration de grub-pc
    in-target: debconf (developer): <-- TITLE Configuration de grub-pc
    in-target: debconf (developer): ----> TITLE Configuration de grub-pc
    in-target: debconf (developer): ----> TITLE Configuration de man-db
    debconf: --> TITLE Configuration de man-db
    in-target: debconf (developer): <-- TITLE Configuration de man-db
    in-target: debconf (developer): ----> TITLE Configuration de man-db
    in-target: debconf (developer): ----> TITLE Configuration de grub-pc
    debconf: --> TITLE Configuration de grub-pc
    in-target: debconf (developer): <-- TITLE Configuration de grub-pc
    in-target: debconf (developer): ----> TITLE Configuration de grub-pc
    debconf: --> SETTITLE debian-installer/grub-installer/title
    
    Bad news: the last one is about grub, so the title should be correct, right?
  4. At this point, it might be the Gtk frontend behaving strangely. It s shipped in cdebconf-gtk-udeb, built from the cdebconf source. Let s look:
    • src/modules/frontend/gtk/ui.c has cdebconf_gtk_update_frontend_title(), which does what the function name suggests.
    • src/modules/frontend/gtk/di.c has cdebconf_gtk_di_run_dialog(), which calls the first function.
    • src/modules/frontend/gtk/progress.c has cdebconf_gtk_show_progress() (also calls the first function), which comes with the following comments:
      /** Show the progress widgets.
        *
        * This will actually add the widgets to the corresponding containers.
        * The main title saved when starting the PROGRESS operation will be restored
        * from the value saved when START was called.  This is needed when GO is
        * called during a PROGRESS operation.
      
    Now that s something! Even if the last entry is about grub, some previous value could be restored and could be the reason for the bad behaviour (that is easily confirmed by adding some debug_printf() calls on fe->title in cdebconf, thanks to an extra "debug.h" include). Maybe that s what needs fixing!
  5. Now it s time to take a step back. A d-i environment is nice, but testing things can easily become a burden. Taking a random wheezy or sid chroot, and installing/removing a tiny package shipping a manpage should be enough to run into the man-db trigger. Exporting DEBCONF_DEBUG=developer there too, let s either install or remove x11-apps (the trigger does the same job, and the debconf trace is the same), here s the output:
    Processing triggers for man-db ...
    debconf (developer): frontend started
    debconf (developer): frontend running, package name is man-db
    debconf (developer): starting /var/lib/dpkg/info/man-db.config configure /usr/share/man
    debconf (developer): <-- VERSION 2.0
    debconf (developer): --> 0 2.0
    debconf (developer): <-- INPUT medium man-db/install-setuid
    debconf (developer): --> 30 question skipped
    debconf (developer): <-- GO
    debconf (developer): --> 0 ok
    debconf (developer): starting /var/lib/dpkg/info/man-db.postinst triggered /usr/share/man
    debconf (developer): <-- VERSION 2.0
    debconf (developer): --> 0 2.0
    debconf (developer): <-- GET man-db/auto-update
    debconf (developer): --> 0 true
    
    Even if one didn t know about the cdebconf/debconf thing, the frontend started bit in the d-i syslog would have been the key: it s only found in debconf, in the frontend script. That one has several ways to determine the package being acted on, and it finally calls:
    debug developer => "frontend running, package name is $package";
    $frontend->default_title($package) if length $package;
    
    Tada, that s likely to be the issue.
  6. Tweaking that frontend script, it s easy to make sure that the code path for this use case is:
    elsif ($ARGV[0]=~m!^.*/(.*?)\.(?:postinst postrm prerm)$!)  
            $package=$1;
     
    
    Since $ARGV[1] is the action being passed to the maintainer script, one can intercept the triggered action, and avoid emitting a title update in this case; I ve therefore reassigned #679327 to the debconf package, and proposed a patch implementing that, which Joey Hess seems to find reasonable.
In my message to the bug report I wrote I actually tested it in a d-i environment, and made sure the issue had gone away. How I did that will likely be described in the next d-i hacking recipe.

22 December 2012

Dirk Eddelbuettel: Kurt Elling Quintet at the Green Mill

Kurt Elling is back in Chicago for two gigs at the Green Mill (where I last saw him in a wonderful big-band setting), along with his long-time collaborator Laurence Hobgood on piano, Clark Sommers on bass, Chicago's own John McLean on guitar, and the new kid Bryan Carter on drums. And they were, of course, awesome. Great mix of standards as well as new stuff from the Grammy-nominated new recording. If you can see Kurt Elling live, go. Now. They return for another gig tonight and I will have to see if I can swing that.

Bartosz Fe&#324;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!

Russell Coker: Everyone Needs a Tablet

Care2 has an interesting article about people being offended by a picture of a poor Afro-American boy using an iPad [1]. It seems that people object to poor people having what is in many ways the greatest educational tool available because it can also be seen as a status symbol. I wonder if one of the cheaper Android tablets (at 1/3 the price of an iPad or less) would get the same response. Dvice has an inspiring article by Evan Ackerman about an experiment where a large quantity of Motorolla Xoom tablets were delivered to Ethiopian kids who couldn t read and didn t know English [2]. The kids learned printed English and learned to hack the devices to enable all the hardware features! I don t expect that kids in first-world countries would get the same benefits as kids in countries such as the US and Australia are distracted by TV, games consoles, and other forms of entertainment that aren t readily available in Ethiopian villages. But the potential benefits for widespread deployment of tablets in the poorer parts of first-world countries seems significant. I think that the government of every first-world country should give a voucher to every resident who is more than two years old for a $100 discount off the list price of a tablet. If someone is happy with a cheap Android tablet then $100 will cover the prices. If they want something better then they can pay more. I m happy for wealthy people to get a $100 discount on the price of one of the more expensive tablets, it seems that means testing such government subsidies just causes political issues without saving much money. Apart from the obvious educational benefits for people who own tablets (which means adults as well as children) there are also benefits in having everyone own a tablet. If everyone owned a tablet then the resale price of a low-end tablet would approach zero and the resale price of even more desirable tablets such as the iPad would drop a lot. This would reduce the incentive to steal tablets and allow people to use them in situations where there is less safety. If most people felt safe to use a tablet computer on public transport and started doing educational things instead of reading newspapers then it would improve the overall education of the population. Newspapers generally aren t educational and in the case of News Corp publications and other tabloids you can become less well informed by reading them I believe that on average newspapers have a negative educational value in Australia. The cost of giving a $100 tablet voucher to every resident of Australia would be about $2,200,000,000 (plus administrative costs) which seems like a lot of money. But when compared to the costs of building infrastructure it s not significant. I ve just read some government announcements regarding transport budget which includes items such as $6,500,000 to determine the best route for a new rail line. So if we were to get 350 new rail lines (and we need more than this) then merely determining the routes would cost as much as getting a tablet for everyone in the country!

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

Dirk Eddelbuettel: Rcpp 0.10.2

Relase 0.10.2 of Rcpp provides the second update to the 0.10.* series, and has arrived on CRAN and in Debian. It brings another great set of enhancements and extensions, building on the recent 0.10.0 and 0.10.1 releases. The new Rcpp attributes were rewritten to not require Rcpp modules (as we encountered on issue with exceptions on Windows when built this way), code was reorganized to significantly accelerate compilation and a couple of new things such as more Rcpp sugar goodies, a new timer class, and a new string class were added. See below for full details. We also tested this fairly rigorously by checking about two thirds of the over 90 CRAN packages depending on Rcpp (and the remainder required even more package installs which we did not do as this was already taking about 12 total cpu hours to test). We are quite confident that no changes are required (besides one in our own RcppClassic package which we will update. The complete NEWS entry for 0.10.2 is below; more details are in the ChangeLog file in the package and on the Rcpp Changelog page.
Changes in Rcpp version 0.10.2 (2012-12-21)
  • Changes in Rcpp API:
    • Source and header files were reorganized and consolidated so that compile time are now significantly lower
    • Added additional check in Rstreambuf deletetion
    • Added support for clang++ when using libc++, and for anc icpc in std=c++11 mode, thanks to a patch by Yan Zhou
    • New class Rcpp::String to facilitate working with a single element of a character vector
    • New utility class sugar::IndexHash inspired from Simon Urbanek's fastmatch package
    • Implementation of the equality operator between two Rcomplex
    • RNGScope now has an internal counter that enables it to be safely used multiple times in the same stack frame.
    • New class Rcpp::Timer for benchmarking
  • Changes in Rcpp sugar:
    • More efficient version of match based on IndexHash
    • More efficient version of unique base on IndexHash
    • More efficient version of in base on IndexHash
    • More efficient version of duplicated base on IndexHash
    • More efficient version of self_match base on IndexHash
    • New function collapse that implements paste(., collapse= "" )
  • Changes in Rcpp attributes:
    • Use code generation rather than modules to implement sourceCpp and compileAttributes (eliminates problem with exceptions not being able to cross shared library boundaries on Windows)
    • Exported functions now automatically establish an RNGScope
    • Functions exported by sourceCpp now directly reference the external function pointer rather than rely on dynlib lookup
    • On Windows, Rtools is automatically added to the PATH during sourceCpp compilations
    • Diagnostics are printed to the console if sourceCpp fails and C++ development tools are not installed
    • A warning is printed if when compileAttributes detects Rcpp::depends attributes in source files that are not matched by Depends/LinkingTo entries in the package DESCRIPTION
Thanks to CRANberries, you can also look at a diff to the previous release 0.10.1. As always, even fuller details are on the Rcpp Changelog page and the Rcpp page which also leads to the downloads, the browseable doxygen docs and zip files of doxygen output for the standard formats. A local directory has source and documentation too. Questions, comments etc should go to the rcpp-devel mailing list off the R-Forge page

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.

Russell Coker: Samsung Galaxy S3 First Review with Power Case

My new Samsung Galaxy S3 arrived a couple of days ago. Kogan added to the weirdness in their shipping that I documented in a previous post [1] by shipping the two phones on consecutive days with separate invoices for $789 each (as opposed to the $449 that I paid). This means that if customs were to track this down they could bust me for import duties (which apply whenever you order more than $1000 of electronics from another country) as multiple shipments in a small period of time are aggregated for tax purposes. It also means that it would be easy to defraud the tax office or an employer about the cost of the devices if I didn t blog about it Phone and Case Review back of power case with S3 installed next to back plastic of S3S3 and case next to each other To install the Samsung Galaxy S3 in the power case I bought from Kogan the back of the S3 has to be removed. One annoying implication of this is that when using the phone in it s case I will either have to carry the back of the phone with me or have no option of removing the case during the day. The phone has to slide in to the case from a small angle and if it s removed carelessly there seems to be a risk of breaking the power connector on the case. S3 on power case standedge view of S3 in power case stand The above photos show the kick-stand on the power case in use, I haven t yet had an opportunity to use the stand for anything other than photography and as it s made of thin plastic there s a reasonable chance that it will break off before I ever use it properly. One major deficiency of the power case is that it has no protection for the screen. The typical gel case will extend by about 2mm above the screen which means that you can place the phone screen-down on a table without a risk of scratching the screen. Also if a phone in a gel case is dropped on a hard surface it seems likely that the chance of the screen hitting a bump and cracking will be lower although I m not aware of any research regarding how well this theory works in practice. This combined with the fact that the power case is smooth and difficult to grip makes it quite unsuitable for regular use. I am concerned that the added mass of the power case would increase the risk of serious phone damage if it s dropped screen-down. I plan to buy a gel case ASAP which I will use most of the time. I will swap the gel case for the power case on the occasions when I expect to spend an extended period of time away from home or an office where I can charge my phone. The power case really should have been designed with a flange that extends above the level of the screen on all sites. It also shouldn t be smooth on the outside. Phone Review The Galaxy S3 equals the Galaxy S for the title of the most slippery phone I ve ever owned. This combined with the fact that the Galaxy S3 is slightly thinner and also 10% wider and longer makes it a more difficult phone to hold. It s a phone that really needs a case with a lot of grip. The camera is reasonable given the fact that any device that is 8.6mm thick will have a very small focal length and also a very small CCD for receiving light. The laws of physics just don t allow something the size of the Galaxy S3 to have a half-decent camera. My ideal mobile phone would be about the size of the Galaxy S3 with the power case, it would use the extra thickness for a big battery as well as a much longer focal length for the camera. I d like a phone to be about 16mm thick over most of it s area with a section that s 20mm for the camera. The burst shot mode (which allows you to take 20 pictures rapidly) is good for capturing certain types of relatively slow movement (EG someone s mouth moving when they talk). But it s no good at all if you try to pan the camera while doing burst mode. When I first started using the phone it gave me lots of hints about using various functions. This wasn t particularly useful for me as most things are obvious to anyone who has much experience with computers and the non-obvious things are probably going to be forgotten if you are doing something else when the help system prompts you. It will be useful for my sister in law who s getting the other phone, but the down-side of this is that I can t configure her phone before delivering it. She needs to use it first to see all the tips. The Galaxy S3 has a screen that s 4.8 diagonally which is slightly larger than the 4.0 screens of my previous Android phones (Sony Ericsson Xperia X10 and Samsung Galaxy S). That gives 44% more screen area which is a good thing. Unfortunately many apps seem to display the same amount of data, I had hoped that 44% more area and 140% more pixels would result in most apps displaying more data by default. Fortunately ConnectBot (my SSH client of choice) gives me 60 rows and 120 columns on the Galaxy S3 as opposed to the mere 31 rows and 80 columns on the Xperia X10. I don t use ConnectBot that often (a phone is a really bad ssh client no matter how you do it), but when I do it s really important and the extra space matters. The down-side of the larger screen for me is that the distance from the center of the palm of my hand to the end of my thumb is slightly less than 4.8 . This means that I can t hold the Galaxy S3 with one corner in the palm of my hand and still reach the far corner of the screen. So I am forced to hold the sides of the phone for one-handed use which means that it would be easier for it to slip out of my hand. A further complication is that the settings and back buttons are very close to the edge of the phone and can be hit by accident very easily. Hopefully a gel case will alleviate that. But I have never owned a hand-held device which was so difficult to hold in a stock configuration. According to AndroSensor (one of my favorite demo programs for showing useless things that a phone can do) the Galaxy S3 lacks support for measuring humidity and external temperature but it has all the other sensors. I think I can survive without knowing how hot and humid my pockets are, but it would still be nice to have every possible feature. The default partitioning of the phone storage is to have all internal storage used for applications and none used for a VFAT filesystem accessible over USB. It s nice that I won t run out of application storage space (a problem I ve had with every other Android device) but it does mean that I ll have to buy a micro SD card before I can use the phone properly. Micro SD storage costs about $1.50 per gig in the size range from 8G to 32G, it s not particularly expensive but it s annoying to have the phone not be fully usable right from the start. Without using a SD card I have to use gphoto2 to download pictures from the phone so it s fully usable in every way. But the cost of the power case, the gel case I m about to buy, and an SD card make the phone less of a bargain. The phone has more RAM, a faster CPU, and Android 4.1. These are all really good things, but nothing worth writing about in a review. Conclusions The power case is very poorly designed, I probably wouldn t buy it if I knew then what I know now. For one-handed phone use by someone like me with longer than average fingers a 4.0 phone is about the largest possible. This doesn t mean that phones should stay small, but it does mean that Apple weren t being entirely silly when they released all the 3.5 iPhones. Presumably a large portion of the population would find a 3.5 phone to be as usable as a 4.0 phone is for me. It now seems to me that as a 4.8 screen is going to be impractical for one-hand use by almost everyone the phone designers should concentrate more on larger phones similar to the Samsung Galaxy Note. I think that the 4.8 screen size may be ideal for some young children who could use it the way an adult might use a 7 tablet an Android phone seems to be a relatively common present for children in the 6-12 age range. Generally I think that no-one should ever buy a new phone or tablet without trying one of the same size. While I am happy with the S3 it really doesn t work in the way I expected. Having 2.9* as many characters on screen for ConnectBot is a massive benefit. If I ever write another magazine article on a hand-held device the extra size and resolution will really help if I found a suitable editor (please make suggestions in the comments). For the WordPress client to write long blog posts on it then the screen could potentially be reasonably useful, but so far it seems that it s more suited to reviewing posts and comments than to writing posts. Generally the Samsung Galaxy S3 is a good phone and I think it s great value for money when it s less than $500.

Joachim Breitner: GHCi integration for GHC.HeapView

Given the very positive feedback for Dennis Felsing s tool ghc-vis, which visualizes the heap representation of a Haskell value, including all the gory details such as thunks, values retained by thunks indirections, sharing etc, I saw the need to provide this information also directly in GHCi, without having to load a graphics library or opening extra libraries. So I added the required features (traversing the heap and pretty-printing the results) to my ghc-heap-view package and, also following ghc-vis s lead, added a ghci file that, when loaded, provides you with a :printHeap command. Here you can see it in action: A plain value
Prelude> :script /home/jojo/.cabal/share/ghc-heap-view-0.4.0.0/ghci
Prelude> let x = [1..10]
Prelude> x
[1,2,3,4,5,6,7,8,9,10]
Prelude> :printHeap x
_bh [S# 1,S# 2,S# 3,S# 4,S# 5,S# 6,S# 7,S# 8,S# 9,S# 10]
Note that the tools shows us that the list is a list of S# constructors, and also that it is still hidden behind a blackhole. After running System.Mem.performGC, this disappears. A thunk
Prelude> let x = Just (1 + 1)
Prelude> :printHeap x
Just _bco
Prelude> x
Just 2
Prelude> System.Mem.performGC
Prelude> :printHeap x
Just (S# 2)
Here, we see how the calculation was deferred until forced by showing the value of x. The name _bco stands for a bytecode object as used by the interpreter. Getting useful information from them is a bit harder than for compiled thunks, so for more accurate results put the code in a Haskell source file, compile it and use the GHC.HeapView API to print the interesting parts. A partial application
Prelude> let a = "hi"
Prelude> let partial = (a ++)
Prelude> partial ""
"hi"
Prelude> System.Mem.performGC
Prelude> let x = (a, partial)
Prelude> :printHeap x
let x1 = "hi"
in (x1,_fun x1)
The information <emph>which</emph> function is called there (++ in this case) is lost at runtime, but we still see that the second element of the tuple is a partial application of <emph>some</emph> value to the first element. A cyclic structure
Prelude> let s = "ho"
Prelude> let x = cycle s
Prelude> length (take 100 (show x))
100
Prelude> System.Mem.performGC
Prelude> :printHeap x
let x0 = C# 'h' : C# 'o' : x0
in x0
Prelude> let y = map Data.Char.toUpper x
Prelude> length (take 100 (show y))
100
Prelude> :printHeap y
C# 'H' : C# 'O' : C# 'H' : C# 'O' : C# 'H' : C# 'O' : C# 'H' : C# 'O' : C# 'H' : C# 'O' : _bh (C# 'H' : C# 'O' : C# 'H' : C# 'O' : C# 'H' : C# 'O' : C# 'H' : C# 'O' : ... : ...)
The cyclic, tying-the-knot structure of cycle is very visible. But can also see how easily it is broken, in this case by mapping a function over the list. Mutual recursion
Prelude> let  x = 'H' : y ; y = 'o' : x  
Prelude> length (show (take 10 x, take 10 y))  seq  return ()
Prelude> System.Mem.performGC
Prelude> :printHeap (x,y)
let x1 = C# 'H' : x3
    x3 = C# 'o' : x1
in (x1,x3)
If you want to look at multiple variables at once, just pass a tuple to printHeap In the hope that this will be a useful tool for you, I uploaded version 0.4.0.0 of ghc-heap-view to hackage.

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.

Next.

Previous.