A couple of weeks ago, I walked in to a nice, sit-down restaurant, with a smile on my face. It s the kind of restaurant with folded cloth napkins on the tables. Table for three, please as Jacob and Oliver were with me. This much isn t unusual. I have periodically taken them out to eat for quite some time, and they enjoy it. But there were a few unusual things about this particular day. I suppose the main one is that they had just been doing this. Yes, painting your own face can be a lot of fun. And also serious business. The boys and I were in Santa Fe, NM on a train trip. It had been a year since their last train trip, and that s longer than they are typically used to. I d taken Jacob on a train trip with just the two of us before, but this was the first trip with just the two boys and me. And one of the places we visited was the excellent Santa Fe Children s Museum. It may be the best children s museum I ve ever seen. Not the largest, or the flashiest, but that s part of the reason I say best . They had chimes (and many other percussive instruments to produce different pitches, including mounted hubcaps and varying length wooden planks). They had a great magnets table with washers and nuts, so children can build their own bridges, stairs, etc. using magnetism. A giant bubble table, tunnels to crawl in outside, etc. A great place. And, apparently, the thing they were really known for I did not know this in advance is the paint your own face station. Jacob and Oliver really got into it. Oliver informed me he was a lion and I heard ROAR! ROAR! periodically all afternoon. Jacob asked me to help paint a J, and the spirals, on his cheeks. After some careful thought, he informed me that he was spiral man . Next to the paint your own face area was a clean your own face area. Most kids were being helped to clean their own face by their parents on their way out. Jacob and Oliver protested that plan, so I figured, if they want to enjoy painted faces all day, why not? And this, of course, led into lunch with self-painted faces. Nobody at the restaurant commented, but the owner had a huge grin when he saw them. (It was a Mediterranean place, and I m sure the owner would have commented had there not been a language barrier.) Incidentally, the boys became quite the fans of souvlaki. Later, as we walked around Santa Fe Plaza and another museum, they drew smiles all over the place. Several kind people asked them, Did you enjoy the children s museum? Yes, everyone in Santa Fe seemed to know precisely where kids with painted faces had been that day. Santa Fe is an amazing and beautiful city. It was warm and friendly, and the architecture and layout was fun to see and pedestrian-friendly. We walked past the Cathedral Basilica of St. Francis of Assisi several times, and went in once. For some reason I could never fully explain, I could often smell their incense even a block or two away. It added to the crisp wintry feel of the plaza. The point of the trip wasn t Santa Fe, though. It was Jacob and Oliver on Amtrak, which is the thing they were really most excited about of course. They were excited as usual, and despite the fact that the train comes through this area only at around 3AM, were plenty excited to be on the train. And, in fact, didn t fall asleep again until about 5 due to the excitement (though they did an excellent job of being quiet). Of course, 6AM was morning so they were wide awake by then. Jacob had been planning what he d eat on the train for days already, and had announced he would be having French toast for breakfast and pizza at lunch. He was a bit disappointed to see that French toast wasn t on the menu this time, but pancakes saved the day. While waiting for the dining car to open at 6:30, we went to the lounge car for awhile. I had brought along various things for them to do on the train, of course, and among them was a notebook and some markers. Jacob loved drawing suns and stars, and sometimes writing short notes. He gave notes to several friendly people that happened to be visiting with us on the train. Oliver enjoyed it too, but he was more intrigued by the cheap set of multi-colored post-it notes. There were two happy, and somewhat tired, boys getting off that train in the middle of the night when we returned.

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

It has been a while since I wrote about bitcoin, the decentralised peer-to-peer based crypto-currency, and the reason is simply that I have been busy elsewhere. But two days ago, I started looking at the state of bitcoin in Debian again to try to recover my old bitcoin wallet. The package is now maintained by a team of people, and the grunt work had already been done by this team. We owe a huge thank you to all these team members. :) But I was sad to discover that the bitcoin client is missing in Wheezy. It is only available in Sid (and an outdated client from backports). The client had several RC bugs registered in BTS blocking it from entering testing. To try to help the team and improve the situation, I spent some time providing patches and triaging the bug reports. I also had a look at the bitcoin package available from Matt Corallo in a PPA for Ubuntu, and moved the useful pieces from that version into the Debian package. After checking with the main package maintainer Jonas Smedegaard on IRC, I pushed several patches into the collab-maint git repository to improve the package. It now contains fixes for the RC issues (not from me, but fixed by Scott Howard), build rules for a Qt GUI client package, konqueror support for the bitcoin: URI and bash completion setup. As I work on Debian Squeeze, I also created a patch to backport the latest version. Jonas is going to look at it and try to integrate it into the git repository before uploading a new version to unstable. I would very much like bitcoin to succeed, to get rid of the centralized control currently exercised in the monetary system. I find it completely unacceptable that the USA government is collecting transaction data for almost all international money transfers (most are done in USD and transaction logs shipped to the spooks), and that the major credit card companies can block legal money transactions to Wikileaks. But for bitcoin to succeed, more people need to use bitcoins, and more people need to accept bitcoins when they sell products and services. Improving the bitcoin support in Debian is a small step in the right direction, but not enough. Unfortunately the user experience when browsing the web and wanting to pay with bitcoin is still not very good. The bitcoin: URI is a step in the right direction, but need to work in most or every browser in use. Also the bitcoin-qt client is too heavy to fire up to do a quick transaction. I believe there are other clients available, but have not tested them. My experiment with bitcoins showed that at least some of my readers use bitcoin. I received 20.15 BTC so far on the address I provided in my blog two years ago, as can be seen on the blockexplorer service. Thank you everyone for your donation. The blockexplorer service demonstrates quite well that bitcoin is not quite anonymous and untracked. :) I wonder if the number of users have gone up since then. If you use bitcoin and want to show your support of my activity, please send Bitcoin donations to the same address as last time, 15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b.

I have been dealing with an interesting forking issue at work. It happens to involve Perl, but don't let that put you off. So, suppose you need to perform an I/O-bound task that is eminently parallelizable (in our case, generating and sending lots of emails). You have learnt from previous such attempts, and broken out Parallel::Iterator from CPAN to give you easy fork()ing goodness. Forking can be very memory-efficient, at least under the Linux kernel, because pages are shared between the parent and the children via a copy-on-write system. Further suppose that you want to generate and share a large data structure between the children, so that you can iterate over it. Copy-on-write pages, should be cheap, right?

my $large_array_ref = get_data();
my $iter = iterate( sub  
    my $i = $_[1];
    my $element = $large_array_ref->[$i];
    ...
 , [0..1000000] );

Sadly, when you run your program, it gobbles up memory until the OOM killer steps in. Our first problem was that the system malloc implementation was less good for this particular task than Perl's built-in malloc. Not a problem, we were using perlbrew anyway, so a quick few experimental rebuilds later and this was solved. More interesting was the slow, 60MB/s leak that we saw after that. There were no circular references, and everything was going out of scope at the end of the function, so what was happening? Recall that Perl uses reference counting to track memory allocation. In the children, because we took a reference to an element of the large shared data structure, we were effectively writing to the relevant page in memory, so it would get copied. Over time, as we iterated through the entire structure, the children would end up copying almost every page! This would double our memory costs. (We confirmed the diagnosis using 'smem', incidentally. Very useful.) The copy-on-write semantics of fork() do not play well with reference-counted interpreted languages such as Perl or CPython. Apparently a similar issue occurs with some mark-and-sweep garbage-collection implementations - but Ruby 2.0 is reputed to be COW-friendly. All was not lost, however - we just needed to avoid taking any references! Implement a deep copy that does not involve saving any intermediate variables along the way. This can be a bit long-winded, but it works.

my $large_array_ref = get_data();
my $iter = iterate( sub  
    my $i = $_[1];
    my %clone;
    $clone id   = $large_array_ref->[$i] id ;
    $clone foo  = $large_array_ref->[$i] foo ;
    ...
 , [0..1000000] );

This could be improved if we wrote an XS CPAN module that cloned data structures without incrementing any reference counts - I presume this is possible. We tried the most common deep-copy modules from CPAN, but have not yet found one that avoids reference counting. This same problem almost certainly shows up when using the Apache prefork MPM and mod_perl - even read-only global variables can become unshared. I would be very interested to learn of any other approaches people have found to solve this sort of problem - do email me.

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

The gaffe Please note that the historic data had a bug which is fixed and the correct value highlighted below. On the plus side, this means that the delta is not as large as I feared. On the negative side, the gap between the Squeeze and Wheezy release cycles keeps widening slowly but steadily. The gist The UDD bugs interface currently knows about the following release critical bugs:

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

How do we compare to the squeeze cycle ?

Week	Squeeze	Wheezy	Diff
43	284 (213+71)	468 (332+136)	+184 (+119/+65)
44	261 (201+60)	408 (265+143)	+147 (+64/+83)
45	261 (205+56)	425 (291+134)	+164 (+86/+78)
46	271 (200+71)	401 (258+143)	+130 (+58/+72)
47	283 (209+74)	366 (221+145)	+83 (+12/+71)
48	256 (177+79)	378 (230+148)	+122 (+53/+69)
49	256 (180+76)	360 (216+155)	+104 (+36/+79)
50	204 (148+56)	339 (195+144)	+135 (+47/+90)
51	178 (124+54)	323 (190+133)	+145 (+66/+79)
52	115 (78+37)
1	93 (60+33)
2	82 (46+36)
3	25 (15+10)
4	14 (8+6)
5	2 (0+2)
6	release!

Graphical overview of bug stats thanks to azhag:

I run mpd on debian on "igor", an NSLU2 -- a very low-power ~266MHz armel machine, with no FPU and a scanty 32MiB of RAM. This serves nicely to feed my stereo with music that is controllable from anywhere on my LAN. When playing music and talking to a single mpd client, the machine is about 50% idle. However, during a recent upgrade, something wanted to pull in pulseaudio, which in turn wanted to pull in libasound2-plugins, and i distractedly (foolishly) let it. With that package installed, after an mpd restart, the CPU was completely thrashed (100% utilization) and music only played in stutters of 1 second interrupted by a couple seconds of silence. igor was unusable for its intended purpose. Getting rid of pulseaudio was my first attempt to fix the stuttering, but the problem remained even after pulse was all gone and mpd was restarted. Then i did a little search of which packages had been freshly installed in the recent run:

grep ' install .* <none> ' /var/log/dpkg.log

and used that to pick out the offending package. After purging libasound2-plugins and restarting mpd, the igor is back in action. Lesson learned: on low-overhead machines, don't allow apt to install recommends!

echo 'APT::Install-Recommends "0";' >> /etc/apt/apt.conf

And it should go without saying, but sometimes i get sloppy: i need to pay closer attention during an "apt-get dist-upgrade" Tags: alsa, apt, low-power, mpd

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".

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: 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:

• If you install your system to an NBD device but it's not a diskless system, then we'll still write a bootloader to disk. I think this is a bug; if we're not touching the hard disk for the rest of the installation, we should also not touch it during the final stages of the installation. Unfortunately that's not something that can easily be avoided in the current state of affairs.
• If you install your system to an NBD device and it is a diskless system, the installer will hang for about 30 seconds currently when it's trying to find a hard disk and can't. After that, you have to hit "continue without using a hard disk" to have it work. This isn't a major issue for people with patience, but it's a bit annoying.
• Additionally, when installing to a diskless system, you'll get a spurious error message at the end about the system not being able to install grub to local hard disk. This is the same issue as the first one, really, but it shows in a different way.
• There's a minor bug in partman-nbd where the NBD menu will lag behind reality until the next update. This isn't a major issue (all functionality is still there, the information to the user is just not alwyas up-to-date), and the fix might be somewhat complex, so I won't fix it before wheezy is out the door.
• If you install a desktop system onto an NBD device, then currently network-manager will also be installed, which will try restarting the network at boot time. This will cause the kernel to panic, as the system will suddenly lose all access to its root device when that happens.
• Most importantly, there is currently no way in Debian to configure a network bootloader from the installed system (other than copying and editing files manually). What this means is that while it'll be possible to install a Debian system to an NBD device with wheezy, it won't be possible to reboot into that newly-installed system without performing some manual steps.

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.

Wow, that was nice.
I just finished this game after playing it for the last two days. When watching at the final scene, I just had to post about it, for others to read but mainly for me to remember how I enjoyed playing this masterpiece.
There is probably enough information out there about how stunning and unique the look is, so I ll skip that.
Some might complain about the short playtime (it took me about three hours) but that worked perfectly for me, so it got on my recommended games list without restrictions.

Hi, I am interested in your opionions! If you would setup today an new server for a (business) project, would you use Debian Squeeze or Wheezy? Personal and already in most business cases we have decided for Wheezy, because the pros are:

• Enhanced hardening
• More up to date technologies and scripting languages
• Longer security support, because..
• .. you do not have to dist-upgrade within the next year(?)

The cons:

• It is not stable yet

What is your (business) opionion about it?

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 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. 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.

• [1] http://etbe.coker.com.au/2012/12/11/dependencies-in-online-ordering/

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.

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.

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.

This release is a rollup of a variety of miscellaneous features and bug fixes that have accumulated since September. It takes the first few steps towards the general Perl coding style revision that I'm working on, but only a few. I've yet to move some generic Perl test frameworks into this package (hopefully soon). In the new feature department, there's a new portability wrapper around sys/statvfs.h that converts statvfs code to statfs code for older systems, and a lot of enhancements to the portable/apr.h header to fix up some more constants for APR 0.9 compatibility. In the bug fix department, the Kerberos and GSS-API probes now probe for Heimdal's libroken by looking for a function that it has provided since at least 0.4 instead of one that's new in 1.3, fixing some portability issues to BSD systems. The Kerberos header probes also now check for headers using file existence checks instead of the compiler in some cases to fix problems with detecting the wrong header when using one of several different Kerberos library installations on a system. In the test suite department, this release updates the POD and POD spelling checks to be generic and use more modern modules and techniques, and adds a new set of generic Perl tests that will be useful for any of my packages that contain Perl code. There's also a new valgrind suppression file for assisting with valgrind testing in packages that use Kerberos. You can get the latest version from the rra-c-util distribution page.

For the last 7 years I've been involved in the Bazaar project. Since I am slowly stepping down, I recently wrote a retrospective on the project as I experienced it for the last 7 years. Thanks to a few kind people for proofreading earlier drafts; if you spot any errors, please let me know in the comments.

Well known, yet easy to find just about everywhere: using the "test"/"[" commands to test for equality with two equals signs (==).

Contrary to many programming languages, if you want to test for equality in a shell script you must only use the equals sign once.

Try to keep this in mind: under a shell that implements what is required by POSIX:2001, you may hit the unexpected in the following code.

if [ foo == foo ]; then
    echo expected
else
    echo unexpected
fi

Hang tight folks, this is a trippy one: As many have noted in my most recent post, I ve taken a shine to lisps hosted in Python. While clojure-py is badass, it s not fit for using from python. I hit some problems in the way it handles atomic variable access (well atomic , it s actually not ;) ), so I ve decided to give it a shot myself. That s right. I wrote a Lisp. A very basic, unmacroed lisp, but a lisp. So, let s take a look a trivial hy file pair The first file (really_lisp.hy), is as follows:

; vim: tabstop=2 expandtab shiftwidth=2 softtabstop=2 filetype=lisp
; Copyright (c) Paul Tagliamonte, in sofar as any of this is at all
;  copyrightable.
(def hello "World!")
(def square (fn [arg]
  (* arg arg)))
(def factorial (fn [n]
  (if (<= n 1)
   1
   (* n (factorial (- n 1))))))
(def fib (fn [n]
  (if (< n 2)
    n
    (+ (fib (- n 1)) (fib (- n 2))))))

And, the example Python script example.py is as follows:

import hy.lang.importer
import really_lisp
print really_lisp.hello
# "World!"
print really_lisp.square(4)
# 16
print really_lisp.factorial(10)
# 3628800
print [really_lisp.fib(x) for x in range(1, 20)]
# [1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144,
#        233, 377, 610, 987, 1597, 2584, 4181]

Please note two awesome things firstly, we re importing a non-python script into a Python module. Awesome. Secondly, we re able to access symbols natively, as well as functions. Let s also demonstrate the other way (just hython this time):

; vim: tabstop=2 expandtab shiftwidth=2 softtabstop=2 filetype=lisp
; Copyright (c) Paul Tagliamonte, in sofar as any of this is at all
;  copyrightable.
(puts "Hello, World!")
; "Hello, World!"
(import ["os"
         "sys"])
(puts (os.path.abspath "."))
; "/home/tag/tmp"
(puts sys.argv)
; ['/home/tag/.virtualenvs/hy/bin/hython', 'test.hy']
(sys.stdout.write "Fuggn' test\n")
; "Fuggn' test"

Naturally, not to be outdone, I decided to amp it up. Django in Lisp While insane, the big stuff looks like this: I ve replaced urls.py with urls.hy:

; vim: tabstop=2 expandtab shiftwidth=2 softtabstop=2 filetype=lisp
(import ["django.conf.urls"])
(def urlpatterns (django.conf.urls.patterns ""
  (django.conf.urls.url "^$" "djlisp.hellisp.views.home")
))

And, views.py with views.hy:

; vim: tabstop=2 expandtab shiftwidth=2 softtabstop=2 filetype=lisp
(import ["django.shortcuts"])
(def home (fn [request]
  (django.shortcuts.render_to_response "home.html"  )))

And lastly, the settings.hy file. I m not going to paste it because it s huge. But, it works!

No, Simon, not yet.