Courtesy of a recent Google+ post/Stack overflow answer, I stumbled upon ghc-gc-tune, a simple but nice tool which generates interesting graphs for Haskell programs. What is does is quite trivial: iterate over a range of arena and heap sizes, and run a specified program with those RTS options, then generate a graph comparing the performance (by default cpu time) across the combinations of the values. Note that for newer GHC versions, you'll need to link with -rtsopts to allow for the -A/-H custom sizes. The reason I mention it is that the graphs it generates can be quite interesting. For one of the Ganeti programs, hspace, run with the command line ./hspace --simu p,20,1t,96g,16,1 --disk-template drbd, it generates this graph: This picture, if I read it correctly, says that this program is actually well behaved (well, +RTS -s says "3 MB total memory in use" with default options), and that the optimum sizes actually relate to the (L1? L2?) cache size. But note that the maximum difference is only about ~1.6 . By changing the parameters to hspace and make it allocate more memory (./hspace --simu p,20,1t,128g,256,32 --disk-template plain --tiered=1g,128m,1, ~52MB reported by +RTS -s), the graph changes significantly: Now we have somewhat the opposite situation: very small arena sizes are detrimental (and by a big factor, 4.5 ), large arena/heap sizes are OK-ish, and the sweet spot is around 2-4MB arena size with heap sizes up to 4MB. Now maybe these particular examples were not very elightening (and they were definitely not well-conducted tests, etc.), but they should allow some intuition into how the program behaves. Plus, the tool can also generate other plots, for example peak memory usage.

Term::ANSIColor is a Perl core module that provides a few different interfaces to get at the ANSI color and text attribute escape sequences. It can be used to, for example, print out bold text or colorize output. This is a major new feature release, incorporating patches sent to me by Kurt Starsinic and Stephen Thirlwall. Kurt Starsinic contributed support for 256-color emulators. These hang special extended sequences off the otherwise-unused 38 and 48 sequences, providing an alternative naming of the base 16 colors, 216 colors arranged in an RGB namespace, and 24 shades of grey. Those colors are now available via all the normal Term::ANSIColor interfaces. He also contributed a program to print out test data for 256-color emulators that I enhanced to print out test data for the basic and 16-color sets as well, which allowed me to get rid of the static test files in the distribution. Stephen Thirlwall contributed support for creating aliases for the standard colors via an environment variable. I extended his patch to also provide a coloralias() function interface. This feature probably won't be that widely used, but it allows a user to set up custom color names for applications that take color names from user configuration (which might be handy for doing things like using the Solarized color scheme), or to define an alias like "alert" or "warning" in one place and then use it throughout the code. With the new 256-color support, it may be useful to set up more human-readable aliases for some of the RGB colors. Since I was working on this project anyway, I also redid the whole module in the new Perl coding style that I've been experimenting, based on Damian Conway's Perl Best Practices, and added a ton of new tests. There are a lot of great CPAN modules out there to do automated tests of various aspects of Perl code, and most of them don't require much effort to use. I'll probably write a separate post about that later. That sort of comprehensive review of course uncovered a bunch of microbugs and lack of clarity in the code, which is now hopefully much improved. I'm pleased to report that the test suite achieves 100% code coverage as reported by Devel::Cover (and in fact there's a maintainer-only test to ensure that it stays that way). You can get the latest version from the Term::ANSIColor distribution page.

Yesterday's initial upload of RcppClassicExamples was lacking a versioned Depends: to prevent builds on older versions of R. This has been added in a new upload 0.1.1. We also added a NEWS file (see below); no code changes were made.

Changes in version 0.1.1 (2012-12-30)

• Added versioned Depends: in DESCRIPTION to not build under older versions of Rcpp and RcppClassic

Changes in version 0.1.0 (2012-12-27)

• Initial release, split from package RcppExamples

Thanks to CRANberries, you can also look at a diff to the previous release 0.1.0. Questions, comments etc should go to the rcpp-devel mailing list off the R-Forge page.

I have been looking at backup solution for the last few days and I am stuck, so I am asking for pointers or suggestions.

Since all backup solutions are appropriate to various needs, here are my requirements for my home network (two laptops backup on a very low powered server with a 3TiB HDD):

• Free software/open source cross-platform solution - must be able to backup both Linux and Windows clients
• network backup (to a Debian server, storage on HDD)
• very low CPU and memory needs on the server side (server is a de-underclocked Linksys NSLU2 running Debian armel)
• automatic backups with low maintenance cost and easy setup and recovery (setup once, forget about it)
• easily accessible filesystem based storage
• clients should be smart enough to detect when they aren't in the home network and not try to backup when away
• available in Debian

These are the basic requirements, and bonus-points requirements include:

• Windows clients don't need Cygwin
• optional encryption (for storage)
• default sanity checking for stored files (detection/correction of corrupt backed-up files)
• unduplication (if present, sanity checking is mandatory)
• logarithmic storage is a plus
• Web/nice interface for both client and server is a plus

According to the info I found, candidates for these criteria are Amanda and BackupPC. I like the rsnapshot idea of deduplication and incremental backups, but it's not available for Windows. BackupPC seems to be OK-ish, but it sounds too much like a bunch of Perl scripts and Windows support sounds like an after-thought and I dislike the idea of installing Cygwin just to provide some *nix tools.

I discarded Bacula, because the general impression I got from what I read is that it is hard to set up, has its own storage and has heavy needs for both clients and server. It sounds like overkill.

So what do other people recommend for my setup? Is Amanda OK? Did I get the wrong impression regarding BackupPC?

MicroPeak Serial Interface Flight Logging for MicroPeak MicroPeak was original designed as a simple peak-recording altimeter. It displays the maximum height of the last flight by blinking out numbers on the LED. Peak recording is fun and easy, but you need a log across apogee to check for unexpected bumps in baro data caused by ejection events. NAR also requires a flight log for altitude records. So, we wondered what could be done with the existing MicroPeak hardware to turn it into a flight logging altimeter. Logging the data The 8-bit ATtiny85 used in MicroPeak has 8kB of flash to store the executable code, but it also has 512B (yes, B as in bytes ) of eeprom storage for configuration data. Unlike the code flash, the little eeprom can be rewritten 100,000 times, so it should last for a lifetime of rocketry. The original MicroPeak firmware already used that to store the average ground pressure and minimum pressure (in Pascals) seen during flight; those are used to compute the maximum height that is shown on the LED. If we store just the two low-order bytes of the pressure data, we d have room left for 251 data points. That means capturing data at least every 32kPa, which is about 3km at sea level. 251 points isn t a whole lot of storage, but we really only need to capture the ascent and arc across apogee, which generally occurs within the first few seconds of flight. MicroPeak samples air pressure once every 96ms, if we record half of those samples, we ll have data every 192ms. 251 samples every 192ms captures 48 seconds of flight. A flight longer than that will just see the first 48 seconds. Of course, if apogee occurs after that limit, MicroPeak will still correctly record that value, it just won t have a continuous log. Downloading the data Having MicroPeak record data to the internal eeprom is pretty easy, but it s not a lot of use if you can t get the data into your computer. However, there aren t a whole lot of interfaces avaialble on MicroPeak. We ve only got:

• The 6-pin AVR programming header. This is how we load firmware onto MicroPeak during manufacturing. It s not locked (of course), and the hardware supports reading and writing of flash, ram and eeprom.
• The LED. We already use this to display the maximum height of the previous flight, can we blink it faster and then get the computer to read it out?

First implementation I changed the MicroPeak firmware to capture data to eeprom and made a test flight using my calibrated barometric chamber (a large syringe). I was able to read out the flight data using the AVR programming pins and got the flight logging code working that way. The plots I created looked great, but using an AVR programmer to read the data looked daunting for most people as it requires:

• An AVR programmer. Adafruit sells the surprisingly useful USBtinyISP programmer. There are Windows drivers available for this, and you can get the necessary avrdude binaries from the usbtiny page above. The programmer itself comes in kit form, so you have to solder it together. There are other programmers available for a bit more than come pre-assembled, but all of them require that you wander around the net finding the necessary drivers and programming software.
• A custom MicroPeak programming jig. We have these for sale in the Altus Metrum web store but, because they need special pogo pins and a pile of custom circuit boards, they re not cheap to make.

With the hardware running at least $120 retail, and requiring a pile of software installed from various places around the net, this approach didn t seem like a great way to let people easily capture flight data from their tiny altimeter. The Blinking LED The only other interface available is the MicroPeak LED. It s a nice LED, bright and orange and low power. But, it s still just a single LED. However, it seemed like it might be possible to have it blink out the data and create a device to watch the LED and connect that to a USB port. The simplest idea I had was to just blink out the data in asynchronous serial form; a start bit, 8 data bits and a stop bit. On the host side, I could use a regular FTDI FT230 USB to serial converter chip. Those even have a 3.3V regulator and can supply a bit of current to other components on the board, eliminating the need for an external power supply. To see the LED blink, I needed a photo-transistor that actually responds to the LED s wavelength. Most photo-transistors are designed to work with infrared light, which nicely makes the whole setup invisible. There are a few photo-transistors available which do respond in the visible range, and ROHM RPM-075PT actually has its peak sensitivity right in the same range as the LED. In between the photo-transistor and the FT230, I needed a detector circuit which would send a 1 when the light was present and a 0 when it wasn t. To me, that called for a simple comparator made from an op-amp. Set the voltage on the negative input to somewhere between light and dark and then drive the positive input from the photo-transistor; the output would swing from rail to rail. Bit-banging async The ATtiny85 has only a single serial port , which is used on MicroPeak to talk to the barometric sensor in SPI mode. So, sending data out the LED requires that it be bit-banged directly modulated with the CPU. I wanted the data transmission to go reasonably fast, so I picked a rate of 9600 baud as a target. That means sending one bit every 104 S. As the MicroPeak CPU is clocked at only 250kHz, that leaves only about 26 cycles per bit. I need all of the bits to go at exactly the same speed, so I pack the start bit, 8 data bits and stop bit into a single 16 bit value and then start sending. Of course, every pass around the loop would need to take exactly the same number of cycles, so I carefully avoided any conditional code. With that, 14 of the 26 cycles were required to just get the LED set to the right value. I padded the loop with 12 nops to make up the remaining time. At 26 cycles per bit, it s actually sending data at a bit over 9600 baud, but the FT230 doesn t seem to mind. A bit of output structure I was a bit worried about the serial converter seeing other light as random data, so I prefixed the data transmission with MP ; that made it easy to ignore anything before those two characters as probably noise. Next, I decided to checksum the whole transmission. A simple 16-bit CRC would catch most small errors; it s easy enough to re-try the operation if it fails after all. Finally, instead of sending the data in binary, I displayed each byte as two hex digits, and sent some newlines along to keep the line lengths short. This makes it easy to ship flight logs in email or whatever. Here s a sample of the final data format:

MP
dc880100fec000006800f56d8f63b059
73516447273fa93728301927d91b7712
730bbf0491fe88f7c5ee8ee896e3fadc
9dd9d3d502d1afcea2cbafc6b4c34ec1
bfbfcabf10c03dc05dc070c084c08fc0
9cc0abc0b9c0c1c0ccc0dcc020c152c4
71c9a6cf45d623db7de05ee758edd9f2
b4f9fd00aa074311631a9221c4291330
c035873b2943084bbb52695c0c67eb6b
d26ee5707472fb74a4781f7dee802b84
09860a87e786ad868a866e8659865186
4e8643863e863986368638862e862d86
2f862d86298628862a86268629862686
28862886258625862486
d925

Making the photo-transistor go fast enough The photo-transistor acts as one half of a voltage divider on the positive op-amp terminal, with a resistor making the other half. However, the photo-transistor acts a bit like a capacitor, so when I initially chose a fairly large value for the resistor, it actually took too long to switch between on and off the transistor would spend a bunch of time charging and discharging. I had to reduce the resistor to 1k for the circuit to work. Remaining hardware design I prototyped the circuit on a breadboard using a through-hole op-amp that my daughter designed into her ultrasonic guided robot and a prefabricated FTDI Friend board. I wanted to use the target photo-transistor, so I soldered a couple of short pieces of wire onto the SMT pads and stuck that into the breadboard. Once I had that working, I copied the schematic to gschem, designed a board and had three made at OSHPark for the phenomenal sum of $1.35. Aside from goofing up on the FT230 USB data pins (swapping D+ and D-), the board worked perfectly. The final hardware design includes an LED connected to the output of the comparator that makes it easier to know when things are lined up correctly, otherwise it will be essentially the same. Host software Our AltosUI code has taught us a lot about delivering code that runs on Linux, Mac OS X and Windows, so I m busy developing something based on the same underlying Java bits to support MicroPeak. Here s a sample of the graph results so far: Production plans I ve ordered a couple dozen raw boards from OSH Park, and once those are here, I ll build them and make them available for sale in a couple of weeks. The current plan is to charge $35 for the MicroPeak serial interface board, or sell it bundled with MicroPeak for $75.

I don t like watching videos sitting in front of a computer, I usually store them into a USB key to plug into my Samsung LE37 TV set. It s not an easy task, though, as I have to fight with other components of my family who usually like watching something completely different than DebConf videos I could have invested 200 to buy a new one, but I tried a different approach first. Recycling a netbook I received a Tweety device as Christmas gift, and I tried to connect it to my netbook to see how it worked. I was quite impressed by the good quality of the sound (if compared to the really poor quality of the netbook speakers), and I realized I could have recycled the netbook as a brand new TV set with some little adjustments. I plugged my SyncMaster 920n PC monitor into the netbook VGA port, switched Totem to fullscreen mode, and here it is my TV set! Remote control OK, that was quite straightforward to accomplish. A real TV set has a remote control too, but my netbook is not equipped with an IrDA port, so I had to think about a different solution. My BlackBerry is equipped with a cool app called BBSSH, which allows you to connect to any SSH server, this could be a good starting point to implement a remote control device. Then, I had to write an interface to Totem using Python and DBus binding to allow my SSH remote control to issue commands to start and pause the player. I published a first working implementation: at the moment the only supported operations are play, pause, stop and volume adjustments, but there are a lot of opportunities by implementing full MPRIS specification. Just to avoid typing a long command each time, I finally created a set of bash aliases, one for each command, so I just have to type one letter to have the desired function, as much as a real remote control

Review: Countdown, by Mira Grant

Publisher:	Orbit
Copyright:	August 2011
ISBN:	0-316-20448-X
Format:	Kindle
Pages:	75

Countdown is a novella that tells the "origin story" of Grant's Newsflesh universe, the setting for Feed and sequels. It's the story of the initial creation of Kellis-Amberlee and the first zombie Rising, mixed with a small bit of backstory for the Mason family. There are two ways to read this novella that work. It's possible to read it prior to reading any of the Newsflesh books as a sort of teaser. It sets up the universe, shows the devastation of society, and raises the question of how society will respond. Alternately, and I think more effectively, it can be read as an appendix to the Newsflesh trilogy that fills in the backstory. Reading it after all three books led to some fun moments of "oh, that's how that happened." It shows the accidents and bad decisions that led to the Rising, and provides a bit of a counterbalance to some of Georgia and Shaun's snarky comments about the government, scientists, and the media. The way to read it that doesn't work is to try to read it as a stand-alone work. Countdown has very little in the way of a story. It's told in the disaster epic style of brief scenes following numerous characters, some who are only seen once. There are small plot arcs following the Kellis virus, the Amberlee virus, and the Masons, but none of them are satisfying when read as a traditional story. Some events, particularly in the Masons' thread, have no real meaning by themselves and only acquire significance as part of Georgia and Shaun's backstory. The reason to read this novella is because you're invested in the universe, either to whet your appetite for more or to fill in some of the background. With that caveat, I think Countdown is more effective as horror than the Newsflesh trilogy itself is. Feed and its sequels are more action novels that become political thrillers, and the confident first-person narration and snark undermines most of the sense of dread or horror in the world. (Please note: not being a horror fan, I consider this a feature.) Countdown doesn't have that strong narrative presence. Instead, it covers events that are both horrific and inevitable and towards which the characters are largely helpless. Some of the scenes towards the end are haunting. Grant still isn't very subtle, but I think she does a good job writing quiet desperation and leaving some of the emotions for the reader to interpolate. Countdown could be read after Feed, if you're interested enough in the world to want more, but I think it works best after Blackout (for reasons that are minor spoilers). It could be read before the whole series, but I recommend reading it as an appendix instead. Don't expect too much of it it's background filler rather than more story but I thought it was effective and enjoyed the additional filling-in of the world. Rating: 7 out of 10

The recent releases of Rcpp 0.10.2 and RcppClassic 0.9.3 had one more repercussion. On that dreaded OS, the linker no longer wanted to instantiate a symbol present in both packages; seems to me that the linker in the other two OSs is a little smarter. Anyway -- I didn't fight this but at long last moved all remnands of the long-deprecated older Rcpp API (which is still maintained by package RcppClassic) out of package RcppExamples and into a new package RcppClassicExamples. And the updated version 0.1.5 of the RcppExamples package appeared on CRAN and has now been joined by the initial version 0.1.0 of the new package RcppClassicExamples. No code changed were made; manual pages and descriptions where brushed up and that is about it. Thanks to CRANberries, you can also look at a diff to the previous release 0.1.4 of RcppExamples. Questions, comments etc should go to the rcpp-devel mailing list off the R-Forge page.

Review: Blackout, by Mira Grant

Series:	Newsflesh #3
Publisher:	Orbit
Copyright:	2012
ISBN:	0-316-20218-5
Format:	Kindle
Pages:	631

Blackout is the third book in the Newsflesh series that started with Feed. As with the second book, Deadline, you do not want to read this book out of order. All the emotional heavy lifting is done in Feed, and the book won't mean as much without that. Also, as with Deadline, be very careful about any information you read bout the sequels if you've not yet read Feed, since it's very easy to spoil that book and most information about subsequent books will do so. I'm going to try to write this review without spoilers. That's going to be a bit tricky due to events in Feed, so bear with me if I'm less specific than normal. This is the grand finale of the series, and it is a firm conclusion. As you might expect, particularly from Deadline, that involves a lot more politics, a few more big revelations, some reunions, escalating scale, and a lot of fighting. Unfortunately, it also involves setup. A lot of setup. I didn't expect that, given that Deadline ended at a run, but it takes about half of Blackout and a whole lot of pages before we get to the events that logically follow from the end of Blackout. And those pages dragged for me. There are some great moments. The banter continues to be strong, there are some deeply affecting scenes with Shaun, and Maggie continues to be wonderful. Grant also introduces some new secondary characters (Monkey and the rest of his household) who are brilliant and feel like they could have come directly from Borderlands. All of Blackout has a bit more of that mad scientist feel, full of slightly deranged people who take the fight to the world in their own ways. But it still drags. One branch of the book has the protagonists going here, there, and everywhere in several roundabout attempts to advance the plot. The other branch is more psychologically tense, but it takes too long to get moving and therefore turns into a repetition of the same emotions and the same complaints. I wanted to get to the key events that happen about halfway through the book in about half as many pages as they took. Thankfully, things do pick up when the two strands of the book come together. Some of the emotional dynamics strengthen as well, which I'd been missing. Grant does a great job here tying the whole series together in a way that shows the differences between Feed and Deadline and digs into their nature a bit more. There is one big reveal that I found disappointing, both because it had been obvious since early in Deadline and yet was treated as a big reveal and because I think it put the book and series onto slightly more conventional territory in a place where it had previously been interestingly distinct. (I'm being vague because of spoilers.) But that didn't bother me too much, and the surrounding character dynamics I think made up for it. The final ending isn't exactly bad, but neither did it entirely work for me. The whole series seems a touch too naive. This worked in Feed (at least for me; some other reviewers disliked it) since the naivete felt like part of the dynamic of the story and the characters, and the stakes were mostly kept small enough that it was believable. The stakes are large enough here that I needed the world to be a touch more complicated and the villains less hissable. (If there's been one consistent flaw throughout this series, it's that Grant's villains are too purely evil.) And, in the end, I didn't quite buy the conflict at the heart of the story; after everything that had happened, I wanted something more complex and nuanced. I'm a bit unsatisfied, but, like Deadline, Blackout is still a good book. Neither of them live up to Feed, but they're both enjoyable, action-filled, and creative looks at a zombie apocalypse. I think Blackout is at its best when it's being Fallout or Borderlands and emphasizing the mad scientist angle of Grant's world, and I would have happily read several more chapters about Monkey. The mix of wacky risk-taking and serious political idealism doesn't quite gel, and the latter never worked for me in Blackout, but I still had a lot of fun with the core character interactions. If you read Deadline, you certainly want to read Blackout. If you stopped at Feed, Blackout is probably not a persuasive argument to continue. Rating: 7 out of 10

After a quick rename, hy s back, and better then ever. I ve taken a slightly different approach, and I m now doing Python AST generation out of Lisp. I got things working so well, stack traces even make sense:

(defn foo []
    (raise (Exception "This isn't great")))
(foo)

And, when run:

(hy)[tag@leliel:~][01:28 PM]$ ~/dev/local/hy/bin/hython foo.hy 
Traceback (most recent call last):
  File "foo.hy", line 5, in <module>
    (foo)
  File "foo.hy", line 3, in foo
    (raise (Exception "This isn't great")))
Exception

In addition, I ve added a few new syntax bits, and did some speed tests. Check out the gist it turns out Hy is on-par with Python (whereas Clojure-Py (although much more featureful) is quite a bit slower) To just show off a few things, here s a small script to scrape NEW packages off the website

; NEW scraper
(import "lxml.html"
        "urllib2")
(def xpath "//tr[contains(@class, 'sourceNEW')]//td[@class='package']")
(def url "http://ftp-master.debian.org/new.html")
(def page (lxml.html.fromstring (.read (urllib2.urlopen url))))
(for [row (page.xpath xpath)]
  (print "NEW:" (row.text_content)))

More to come, methinks!

I recently had a chance to briefly play with the new Samsung Galaxy Camera [1]. The Galaxy Camera is an Android device with a 4.8 display (the same size as the Samsung Galaxy S3) that has a fairly capable camera (IE nothing like a typical phone camera). It runs Android 4.1 (Jelly Bean) and the camera has 21* zoom with a 16 megapixel sensor. Camera Features It seems that professional photographers are often annoyed when they see someone with a DSLR set in auto mode. It s widely regarded that auto mode is a waste of a good camera, although the better lenses used with DSLRs will usually give a better result than any compact camera even when it s in auto mode. The problem is that photography is quite complex, in an earlier post about digital cameras I summarised some of the technical issues related to cameras and even without any great detail it became a complex issue [2]. The Galaxy Camera has a reasonably friendly GUI for changing camera settings which even includes help on some of the terms, I expect that most people who use it will end up using most of the features which could make it a good training camera for someone who is going to move to a DSLR. A DSLR version of the Galaxy Camera could also be an interesting product. The camera also has modes such as Waterfall and Panorama , hopefully the settings for those would be exposed to the user so they could devise their own similar groups of settings. I ve seen the phone criticised for the lack of physical controls as the expert mode in software is inherently slower than manually turning dials on a DSLR. But it seems obvious to me that anyone who knows how to use the controls manually should be using a DSLR or bridge camera and anyone who doesn t already know how to do such things will be better suited by the software controls. It supports 120fps video at 720*480 resolution (with a file format stating that it s 30fps to give 1/4 speed) which could be useful. I used to have a LG Viewty smart-phone that did 120fps video but the resolution was too low to be useful. 720*480 is enough resolution to see some detail and has the potential for some interesting video, one use that I ve heard of is filming athletes to allow them to analyse their performance in slow motion. It also does 60fps video at 720p (1280*720) resolution. One down-side to the device is that the lens cover doesn t seem particularly sturdy. It s quite OK for a device that will be stored in a camera case but not so good for a device that will be used as a tablet. I didn t get to poke at the lens cover (people don t like it if you mess with their Christmas presents) but it s design is a couple of thin flaps that automatically retract when the camera is enabled which looks quite weak. I d like to see something solid which doesn t look like it will slide back if the device is treated as roughly as a phone. I think that the lack of a solid lens cover could be the one factor that prevents it from being used as a replacement for a smart phone. Apart from that a Galaxy Camera and a cheap GSM phone could perform all the functions of a high end phone such as the Galaxy S3 while also producing great pictures. It would probably make sense for retailers to bundle a cheap phone with a Galaxy Camera for this purpose. Tablet Features The device boasts WiFi Direct to allow multiple cameras and phones to talk to each other without a regular WiFi access point [3]. I didn t test this and I don t think it would be particularly useful to me, but it seems like a handy feature for less technical users. It can connect to the Internet via Wifi or 3G, supports automatic upload of pictures (it comes with Dropbox support by default like the Galaxy S3), and has a suite of photo and video editing software. I don t expect that any photo editing software that runs on an Android device would be much good (I think that you really need fine cursor control with a mouse and a high resolution screen), but it would probably be handy for sending out a first draft of photos. Most Android apps should just work, the exceptions being apps that rely on a camera that faces the user or full phone functionality. So the Galaxy Camera can do almost anything that an Android phone or tablet can do. Value The RRP for the Galaxy Camera is $599, that puts it in the same price range as a DSLR with a single lens. While that s not a bad price when compared to smart-phones (it s cheaper than the LTE version of the Galaxy S3 phone) it s still quite expensive for a camera that s not a DSLR. Fortunately Kogan is selling it for $469 and has free shipping at the moment [4]. This still makes it more expensive than some of Bridge Cameras which probably have significantly better optical features, but in terms of what the typical user can do with a camera the Galaxy Camera will probably give a much better result. The sensor in the Galaxy Camera is smaller than that in the Nokia 808 PureView [5] (1/2.3 vs 1/1.2 ) so the Nokia PureView should be able to take better pictures in some situations. Unfortunately the Nokia 808 doesn t run Android, I d probably own one if it did. Some of the reviews are rather harsh, the Verge has a harsh but fair review by Aaron Souppouris which makes a number of negative comparisons to cheaper cameras [6]. I really recommend reading Aaron s review as there s a lot of good information there. But I think that Aaron is missing some things, for example he criticises the inclusion of ebook software by saying that he wouldn t read a book on a camera. But the device is a small tablet computer which also has a compact camera included. I can easily imagine someone reading a book or playing Angry Birds on their camera/tablet while in transit to where they are will photograph something. I can also imagine a Galaxy Camera being a valuable tool for a journalist who wants to be able to write short articles and upload pictures and video when out of the office. Aaron concludes by suggesting that the Galaxy Camera is a $200 camera with $300 of editing features. I think of it as $200 in camera hardware with software that allows less skilled users to take full advantage of the hardware and the ability to do all the software/Internet things that you would do on a $450+ smart-phone. Would I Buy One? No. The Galaxy Camera is among other things a great toy, I d love to have one to play with but I can t spare $469 on one. Part of the reason for this is that my wife just bought a DSLR and is getting lessons from a professional photographer, so I really won t get better pictures from a Galaxy Camera. The DSLR on auto mode will allow me to take pictures that will usually be better than a Galaxy Camera can achieve (sometimes you just can t beat a good lens). For more demanding pictures my wife can tweak the DSLR. The 120fps video is a really nice feature, I don t know if my wife s DSLR can do that, but it s a toy feature not something I really need. I ve just bought a Galaxy S3 which is a great little tablet computer (most of the time it won t be used for phone calls). I don t need another 4.8 tablet so a significant part of the use of the Galaxy Camera doesn t apply to me. I recommend the Galaxy Camera to anyone who wants to take good photos but can t get a DSLR and lessons on how to use it properly. But if you would rather get a 35mm camera with interchangeable lenses that runs Android then it might be worth waiting. I expect that the Galaxy Camera will be a great success in the market (it s something you will love when you see it). That will drive the development of similar products, if Samsung doesn t release a 35mm Android camera soon then someone else will (for example Sony develops both high end cameras and Android phones). If my wife didn t have a DSLR then I d probably have bought a Galaxy Camera already. I will recommend it to my parents and many other people I know who want an OK camera and can benefit from a tablet, but don t know how to use a DSLR properly (or don t want to carry a bulky camera).

• [1] http://en.wikipedia.org/wiki/Galaxy_Camera
• [2] http://etbe.coker.com.au/2011/08/24/digital-cameras/
• [3] http://en.wikipedia.org/wiki/WiFi_Direct
• [4] http://www.kogan.com/au/buy/samsung-galaxy-camera-ek-gc100-white/
• [5] http://en.wikipedia.org/wiki/Nokia_808
• [6] http://www.theverge.com/2012/12/3/3706206/samsung-galaxy-camera-review

A couple of days ago I made a new release of slaughter, to add a new primitive I was sorely missing:

if ( 1 != IdenticalContents( File1 => "/etc/foo" ,
                             File2 => "/etc/bar" ) )
 
   # do something because the file contents differ
 

This allows me to stop blindly over-writing files if they are identical already. As part of that work I figured I should be more "visible", so on that basis I've done two things:

• Mirrored the repository to github
• Shared my live policies, again on github
  • These live policies augment, and expand upon, the existing examples and primitive documentation.

After sanity-checking my policies I'm confident I'm not leaking anything I wish to keep private - but there is some news being disclosed ;) Now that is done I think there shouldn't be any major slaughter-changes for the forseeable future; I'm managing about ten hosts with it now, and being perl it suits my needs. The transport system is flexible enough to suit most folk, and there are adequate facilities for making local additions without touching the core so if people do want to do new things they don't need me to make changes - hopefully. ObQuote: "Yippee-ki-yay" - Die Hard, the ultimate Christmas film.

Got your attention? Don t hold your breath, we re not there yet, but we re a step closer: it s now possible to build Firefox from the Iceweasel package, since version 17.0.1-2 in experimental as of writing, 18.0~b6-1 from the iceweasel-beta repository, or 19.0~a2+20121228042015-1 from the iceweasel-aurora repository. Before letting you know how you can get yourself a packaged Firefox based on the Iceweasel source, I ll remind you that redistribution of Firefox packages requires a trademark license from Mozilla, so please keep the packages you build for yourself for now. That being said, now it s clear that such Firefox packages are not official, you can still test them for yourself. First download the Iceweasel source version of your liking, and extract it, then rename all source files from iceweasel_* to firefox_* (rename s/iceweasel/firefox/ iceweasel_* should do it). Edit debian/changelog so that the first line reads:

firefox (x.y.z-r) distribution; urgency=low

instead of:

iceweasel (x.y.z-r) distribution; urgency=low

and run the following command:

$ debian/rules debian/control

Now you re all set. You can build the package the usual way. Note there are a few differences between the xulrunner packages you get from building Iceweasel vs. from building Firefox that need to be addressed, and a few other details to sort out.

Review: Dragonhaven, by Robin McKinley

Publisher:	Ace
Copyright:	September 2007
Printing:	October 2008
ISBN:	0-441-01643-X
Format:	Mass market
Pages:	338

With a title like Dragonhaven from a well-established fantasy author like Robin McKinley, one's first expectations are probably some variety of medieval fantasy, perhaps with a boy or girl who encounters a rare dragon and befriends them. To some extent, those expectations are right: there is a boy, a rare dragon, and a friendship. But they're mostly wrong. Dragonhaven could easily pass for science fiction if one allowed a bit of handwaving, and the setting is contemporary. Jake is the first-person narrator and the center of this story. He lives with his father and a small group of park rangers and other scientists at Smokehill National Park, one of the few remaining reserves for dragons in the world. McKinley's world is much like ours, with the same politics and governments, except that dragons exist: huge, flying dragons that breathe fire. But they've been hunted to near-extinction, including via an actual war in Australia, and are now dwindling in a small handful of isolated reserves. No one is entirely sure how many are left since, for huge creatures, they're remarkably hard to find and document. The Smokehill staff mostly estimate them from prey kills and other indirect signs. This book is Jake's telling of his story, and McKinley goes to quite a bit of effort to find the right tone for a teenage boy. It's more verbal than written in style, with lots of capital letters, italics, tangents, digressions, and short sentences. He's also trying to tell the story in order without skipping ahead but sometimes failing, which turns into a mechanism to do foreshadowing as he slips in comments or mentions things he wasn't aware of at the time. The voice McKinley constructs is very strong and makes this book read unlike any other books of hers I've read. How much you enjoy the book will probably depend heavily on your opinion of Jake's storytelling style. The story proper starts when Jake, on his first overnight trip in the park, encounters a dying dragon and a dead poacher. This is a catastrophe for the park: the dead poacher will provide ammunition for everyone who thinks dragons are too dangerous and should be wiped out. But for Jake, it's a more immediately life-changing event. The dragon was a mother with newborn infants, one of whom has survived and who promptly bonds with Jake. This may sound like it's moving back into traditional fantasy territory, but it's not. Jake's relationship with Lois (the name he gives the baby dragon) is very unlike fantasy bonds with baby hatchlings and quite a bit like taking care of an actual infant. Except the infant is hot enough to burn the skin. And wants to be in a pouch (McKinley's dragons are marsupial, sort of) and therefore needs to crawl inside Jake's clothing and press against skin. And that's not mentioning the smell. Or the excretions. The vast majority of the book is concerned with Jake raising Lois, so you'd better be prepared for lots of description of this. Thankfully, Jake is not the sort to describe in gruesome detail (at least most of the time), and some of the description is quite funny. I was particularly fond of his account of the Smell being so intense and overwhelming that it became a third person in the room. But still, it is a lot of pages of, essentially, child-rearing, and I got tired of it before it was over. Also frustrating is that Jake obviously has never read any science fiction or fantasy. He doesn't even guess at certain aspects of the situation that are immediately obvious to any experienced SFF reader early on. One of those reveals is dragged out until nearly the end of the book. (I'll refrain from spoiling it, but I'll be very surprised if any regular reader of my reviews takes long to pick up on it.) McKinley does a good job with that part of the plot when Jake finally figures out what's going on, but it was still exasperating to have it take so long. Dragonhaven is already somewhat slow-paced due its detailed descriptions of Lois's rearing, and adding an obvious plot element that the protagonist is too dense to figure out makes the pace feel even slower. About a third of the way into this book, I didn't care for it. It was sort of gross, Lois wasn't very interesting, Jake was more frustrating than entertaining, and nothing was happening. But then it started to win me over, and the last part of the book wasn't bad at all. McKinley's best talent is her ability to mix the fantastic with the quotidian and give them equal weight and importance, to embed the reader so thoroughly with the character that one thinks about all the day-to-day impact of fantastic events that is normally skimmed over in books of this type. If you get engrossed in that angle of Jake and Lois's story, Dragonhaven can be quite enjoyable. When you're waiting for the plot to advance, it's a bit painful. Probably the best thing to do with this book, if you can, is read the first chapter or so and see what you think of Jake's voice. If you enjoy reading it, that's probably a good sign for the rest of the book. I do like McKinley's dragons: she avoids the traps of both making them too human and making them too much like animals, and manages to give Lois (once she's a bit older) a sort of intelligence that's inhuman but still canny and clearly sharper than a dog's. You'll likely get tired, as I did, of Jake's omnipresent headache and Lois's endless upbringing, but there is a payoff in the end. Rating: 7 out of 10

Sometimes an attic is all it takes to delight children. This afternoon, the boys and I made cookies. Jacob has been talking about setting out milk and cookies for Santa Claus for several days, and of course the fact that we had made cookies reminded him of this as I figured it would. So after the boys got into their pajamas and all ready for bed, we set out milk and cookies for Santa. The boys have always known that Santa is pretend, but love the stories and traditions anyhow. Never mind that Christmas was 3 days ago, and they ve already opened their presents. It s SANTA! It s magic! It doesn t matter! I asked Jacob, Would you like me to pretend to be Santa tonight? A big grin, then Oh yes, dad! Do it! So after I read them their bedtime story, sang them a song (Jacob chose a Latin hymn that s my boy!), and tucked them into bed, I pretended to be Santa. I went back downstairs. I drank the milk and ate the cookies. Then I went to my small future present stash, selected a few small items, and put them under the tree. I gave it a few minutes. Then I crept up to the attic. I snuck along the wood floors quietly, until I was above the boys room. Then I jumped. And I scraped a wood chair along the floor. And then I yelled out HO HO HO! Merry Christmas! I had a brief conversation with Rudolph, then made some sliding noises. I was silent for a few seconds, then made some more noise and said, Wow, Rudolph, Jacob and Oliver left some great milk and cookies! Let s go deliver the rest of our presents! And made some vague sleigh taking off from the roof of a house noises. I crept back down the stairs. I put my ear to the outside of the closed door to the boys bedroom. I heard Jacob excitedly jabbering, He said milk and cookies! He liked them! He really liked them! Ooo butterfly, he was here! (Butterfly is a stuffed, er, butterfly that he sleeps with.) I gave it a minute or two, then I went in. Jacob, did you hear something? Yes! What was it? Well, it was a loud thud! I sat straight up like this. [ he demonstrates ] Then I heard ho ho ho ! And milk and cookies ! And I was excited like this! [ more demonstrations ] What do you think happened? I don t know! Dad, what did you do? I told him. It only increased his delight. Did it sound like Santa s sleight landing? (annoyed) No, dad. It sounded like a crash. (brightening) And then Santa coming down the chimney with presents! Oh, it is so exciting! (We don t have a chimney) It was still magical, even though he knew exactly what happened. For his part, Oliver slept through it all. He will still discover the empty plate, empty cup, and slightly less empty area underneath the tree. And neither boy knows about the thank you note from Santa yet. I anticipate smiles in the morning!

The UDD bugs interface currently knows about the following release critical bugs:

• In Total: 846
  • Affecting wheezy: 289 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:
      • 36 bugs are tagged 'patch'. Please help by reviewing the patches, and (if you are a DD) by uploading them.
      • 5 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: 99 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)	289 (190+99)	+174 (+112/+62)
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:

Running Debian on the WeTab with GNOME Shell without an external keyboard works pretty nicely. The on screen keyboard - if enabled via the accessibility menu - folds out automatically in the shell itself within text input fields. To have this within GTK+3/GTK+2 applications you need libcaribou-gtk3-module and libcaribou-gtk-module installed. For other cases I stitched together a small extension that puts a keyboard "Button" prominently into the middle of the panel. Clicking/touching it will fold it out, clicking again will hide it again. You can fetch it from

git clone git://honk.sigxcpu.org/git/gnome-shell-oskb-extension.git ~/.local/share/gnome-shell/extensions/OnScreenKeyboardButton@sigxcpu.org

and activate it via

 gsettings set org.gnome.shell enabled-extensions "['OnScreenKeyboardButton@sigxcpu.org']"

For kinetic scrolling in Iceweasel I'm currently using Grab and Drag which is not yet packaged for Debian. Thanks to the Debian's GNOME packaging team gnome-shell 3.6 is already available in experimental. This blog is flattr enabled.