Year 2013 has just started and it's time to think how to spend my free time during this year. Weblate Weblate was my toy project number one in last year and I expect it to stay for next year as well. I have several ideas for new features, but all that depends on free time. I will most likely spend my hackweek on that as well. phpMyAdmin I think my involvement will stay at about same level at phpMyAdmin - doing few random bugfixes, mostly security ones, taking care of infrastructure for translations and wiki and mentoring few GSoC students. Gammu and Wammu Gammu and Wammu has not seen much activity from me in past year and it will probably not change. I don't use the program anymore and this pretty much limits my interest in adding new features. In case somebody active will pop up on mailing list, I'd be happy to transfer the project ownership. Mobile apps I'd like to make some progress here, I was also thinking about making some of them working on Android as well, but this involves lot of learning and time is always an issue here. Anyway this might be good challenge for hackweek as well. Debian No changes expected here :-). Others I consider pretty much anything else from my software projects abandoned or finished.

Filed under: Debian English Gammu Phpmyadmin Suse Weblate 0 comments Flattr this!

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1,SHA512
I am transitioning GPG keys from an old 1024-bit DSA key to a new
4096-bit RSA key.  The old key will continue to be valid for some
time, but I prefer all new correspondance to be encrypted to the new
key, and will be making all signatures going forward with the new key.
This transition document is signed with both keys to validate the
transition.
If you have signed my old key, I would appreciate signatures on my new
key as well, provided that your signing policy permits that without
re-authenticating me.
The old key, which I am transitioning away from, is:
  pub   1024D/DFCA34A3 2007-10-07 [expires: 2013-10-24]
    Key fingerprint = FE23 BE62 DF18 72FB C58D  D637 FFAE 0427 DFCA 34A3
The new key, to which I am transitioning, is:
  pub   4096R/95206DD3 2013-01-02 [expires: 2016-01-02]
    Key fingerprint = DF0B FDFF 4A4D DA01 7944  1B8F 6906 4B01 9520 6DD3
To fetch the full new key from a public key server using GnuPG, run:
  gpg --keyserver keys.gnupg.net --recv-key 95206DD3
If you have already validated my old key, you can then validate that
the new key is signed by my old key:
  gpg --check-sigs 95206DD3
If you then want to sign my new key, a simple and safe way to do that
is by using caff (shipped in Debian as part of the "signing-party"
package) as follows:
  caff 95206DD3
Please contact me via e-mail at <richih.mailinglist@gmail.com>
if you have any questions about this document or this transition.
    Richard Hartmann
    richih.mailinglist@gmail.com
    2013-01-03
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iEYEARECAAYFAlDk27gACgkQ/64EJ9/KNKMGDgCeLyQy6yhEu3OB8UarJ6LYOfVY
ihgAnRSbYMrVxK+28souMHiLx4y0rSQ+iQIcBAEBCgAGBQJQ5Nu4AAoJEGkGSwGV
IG3TcbYP/je8mu+MCIiNNY8w/gN+/9S8gEGWd2p9LeN71xpCuSpBVSevAxxStV9R
2XRTfI8tf/nk27y+4073IscUTPaBkb2IhvIfCnFmOtZjP9slS2JMHOylqH3KLulQ
Cm/IbpKCAwTmQtRMzFxKoRjNPJDCVzZYpoD9r7TmIrs+iKtDQ/w/zQmtwEFWncYK
2JJqVEd+qN9REpWlKDDifcUDPGiugsICelAaUF8VMvp2ouVxQTGbz53IdAgvrX9G
vM+BAfel3W73nfF3L+08vgad0BGGMnEWcfcZ6r+DKu2WXgC8AXT0Y32sD8TiGJSd
JrWMqwec1iOd6lfOpFDdhSCFyMl5r1NiOLw5iNsETHYjysW2N1wZCicmF/8ukm/y
EpIXf3z8vtLrofGLN1jTC34Jugts8C5NNRil195Hkim36t2F97OJswNLhxt7nQ41
vhyXaBK3kwOZ1nVp6xM/yMnQzi5eVO1W/BE8Wr27O6pe3KqEx0Lv8zBzQjj4ly64
shyNRY3gzxs/KZ3p/3nrSn1AYOXIuCM3nILh89qQ/ynotrqYmpFkUorUSSOvraoQ
LN5IPH0wh8F2eDUCui2fGDEmnQ5S5mlHnIZmL3gkPVGLhNaoFQh0R8UwUO6HIxMQ
cTxv5TGL1YWtIvl0bvlEXK6MA4g0ZBXk15JZkWUD84zycr5cb79d
=DFzt
-----END PGP SIGNATURE-----

podlators is the package that contains Pod::Man and Pod::Text and the pod2man and pod2text driver scripts, which convert Perl's POD documentation format into text and *roff (for man pages) output. This release is a "clearing the decks" release that rolls up various smallish feature requests and bug fixes that have been pending for a while. I want to do the same reworking to podlators that I did to Term::ANSIColor, but it's going to take longer since it's quite a bit more code. (And Term::ANSIColor took me about two days.) I didn't want to block the various pending issues on that work, so this tries to clean up all the open bugs I was aware of other than sorting out the defaults for Unicode output. (That's a much larger problem and will probably be fixed in a major release.) The primary change is that pod2man and pod2text now die by default if the POD contains syntax errors. This will hopefully flush out numerous POD documents around the world that have been carrying POD ERRORS sections around forever. I considered just warning by default but not failing, since this will also cause CPAN builds to fail, and I may fall back to that if there are too many complaints. But usually fixing the POD syntax is straightforward, and normally parsing programs will fail on syntax errors. Note that the defaults for the modules, Pod::Man and Pod::Text, continue to be to add a POD ERRORS section, since aborting inside a module isn't very friendly to the caller. There is a new option for both the modules and the driver scripts to set the error handling behavior, which can be set to die, report to standard error but continue, add a POD ERRORS section, or ignore errors entirely. Also in this release is a new nourls option that suppresses the URLs in text and *roff output for L<> codes that have anchor text, which can declutter some POD texts, and fixes for X<> formatting codes containing whitespace and small-caps handling of paragraphs consisting entirely of all-caps text. You can get the latest release from the podlators distribution page.

Yesterday was a busy Debian day for me with the release of not one but two packages. procps procps version 3.3.6 was released both as an upstream and a Debian package. While there were many bug fixes in this release, the main new feature for it was the top inspect feature. The top inspect feature allows you to run top in the normal way then you can inspect a specific process you have selected within top for more information. Examples of this include fuser or lsof type output to see what files or libraries are open but really the limit is how clever the operator is and how often you would need this information. Even scripts can be run off this feature if you have some customised or cooked output you need to see. Once the output is there, you can search for text. There will be a small hold-up with the Debian packages as the section for the library has been moved to libs, where it should be. At least I think that s why there is a delay. procps infrastructure procps currently has only an email list and a gitorious git repository. While this works most of the time, there are two main problems with this setup. The first is that the only two ways you can report bugs is send an email to the list or create a git merge request. The email has the problem with tracking and gathering history while the git sets the bar pretty high for reporting something has gone wrong. Second problem is there is no tarball file repository. gitorious does have the feature of downloading tarballs of the tag checkpoints, but this is the raw repository. When you make a tarball with make dist there are some generated files included in the tarball that don t appear in the gitorious ones, which means its not a simple for some as you expect. So I ll be creating a project for these two features soon. Not sure where they will be but I use sourceforge for both these for a few other projects so that might be where they end up. Mudlet Mudlet, the multi-user dungeon or MUD client, has finally made it to version 2.0! It looks a lot more stable and polished at least from the scripting side than the previous RC versions but has all the features that we ve come to expect with it. The most important thing is that the developers have finally put a line in the sand and said this is version 2.0 . The Debian package was uploaded yesterday and should be on its way to your local mirror soon.

Choices, options, selections if you rather. These are what set us all apart from our fellow man, perhaps it is only the appearance of free will and individuality but our world is full of choice.

In software it might be argued programming is nothing more than making thousands perhaps millions of choices which result in a list of instructions for a machine incapable of making decisions of its own.

On a more mundane level sometimes a programmer cannot make a choice suitable for all expected use cases and a user option is created. These options have become something of a cause for arguments within certain sections of the open source software community especially amongst the groups that influence the graphical user experience.

The discussion should be nuanced and varied (perhaps that is my age, or maybe I am more diplomatic than I thought?) but there seems to be little compromise on this discussion which (from an outsiders point of view) splits into two viewpoints:

• On one side of the argument, which I shall label reductionist, is that all options should be removed with the software just doing the correct thing
• On the other, whom I shall refer to as maximalist, is that users should be presented with options to customise everything.

The reductionist group is currently winning the argument in the popular graphical environments and seem to be removing functionality which requires user choice wherever they can find it. This results in the absurd "joke" that the UI will become a single button, which they are trying to remove.

Personally my view is that an option should be present only when an option cannot be satisfactorily selected by the computer and even then a default suitable for as many users as possible should be picked.

You may ask why I have raised this topic at all? well over the last few days I have been trying to fix the preferences selection for the GTK port of NetSurf. The NetSurf project follows my view on this subject pretty closely but being a browser its very difficult to do the right thing for everyone

NetSurf has numerous frontends for the core browser, I use the term frontend because in some places the toolkit and OS are conflated (windows, cocoa) and not in others (gtk). For each frontend NetSurf is a native application, this is an important distinction, the windows and widgets a user interfaces with are produced by that platforms toolkit.

Old NetSurf Preferences Dialog

This is a deliberate choice unlike other browsers which render their UI themselves as web content, this is a beguiling solution when the authors wish there to be a single browsing "experience" with a common look and feel. However NetSurf looks and feels like a native browser for each frontend, which is what the project decided it wanted to achieve.

Given this the gtk frontend (is it a Gnome application? not sure of the distinction TBH) has had no dedicated maintainer for some time it has suffered from a bad case of bitrot from both GTK library changes and general neglect.

I have slowly been improving this situation, the browser can now be compiled with GTK version 2 (2.12 onwards) or 3, the menus and other UI elements have been translated for the supported languages and now the turn has come for the options dialog.

Oh, right, its "Preferences" not options, fair enough a common semantic throughout all applications does give a degree of homogeneousness but the word choice does seem to indicate the users control has been reduced. At this point I gained an education in just how unfriendly GTK and its tools have become towards the casual programmer.

The dialog I wanted to construct was a pretty standard tabbed layout which reflected the current options and allowed the user to change them in an obvious way. Given that I have constructed and equivalent interface in idiomatic manner for cocoa and windows I thought this would be straightforward, I was very wrong.

The interface construction tool is called glade which used to be the name of the UI "resource" file and interfaces. However the tool is still called glade but the interface is now GtkBuilder which has a different (but similar) XML based file format. Then we discover that despite it being an extensible file format the UI files are specifically versioned against the GTK library. Also why on earth can these resources not be compiled into my program? OK make them over-ridable perhaps. Generally it is yet another file to distribute and update in step with the executable.

New NetSurf Preferences

So because I want to support back to version 2.12 of GTK I do not get to use any of the features from 2.16 in my UI unless I load a different UI builder file...oh and GTK3? requires a completely different version of glade and the UI files which are incompatible with gtk 2. Once this was worked round with having multiple UI files I then moved on to the next issue.

The GTK model uses function callbacks on events, these are known as signals. Perfectly reasonable but because the ui files are loaded at runtime and not compiled in there must be a way for the GTKBuilder to map the textural signal names to function pointers.

The way the GTK developers have chosen to do this is to search the global function table which means any signal handler function symbol has also to be global which means unnecessary overhead for the ELF loader increasing load times.

This lookup should have been confined to a single object or even placed in an alternative section to avoid these issues, this would not have seemed especially challenging to implement as all callback handlers have to use a preprocessor to define already (G_MODULE_EXPORT).

Another thing that makes developing GTK applications worse is the documentation, this seems to be a continuous complaint about may open source projects, which is taciturn or simply missing in many cases. GTK seems to suffer dreadfully from having multiple API versions all subtly different resulting in a lot of work on the developers part to simply find what they want.

A specific example of this is the signals and under what circumstance they occur I wanted to update all the widgets with the current configuration state whenever the options window is shown (using gtk_widget_show()) so I figured that would be the "show" signal...right? nope, never did find the right one to use, ended up with "realize" which occurs once when the dialog is created, not what I wanted, but is at least consistent and works.

NetSurf with Preferences Dialog

Overall my impression of developing just one small dialog (60 widgets total exclusing labels and containers) for a GTK program is that the toolkit and its tooling is missing the facilities to make developers life easier when doing the drudge work that a good proportion of graphical program development.

It is not the case that one cannot do things, just that everything has to be done manually instead of having the tools do the work, and because of the documentation that tedium is magnified.

I did eventually reach the stage that the thought of writing the boilerplate to add another check button to enable "do not track" had me thinking "do they really need this or can I avoid the work?" perhaps that is why they are all reductionist?

Yet another yearly summary of my running activities. It seems, indeed, that running has now slightly taken precedence over free software activities in my life and priorities for my free time. To my fellow free software friends: don't worry, I'm not on my way to stop investing my time in Debian. It's quite clear that I'm reducing my involvement, mostly because days only have 24 hours...not because I'm bored or tired by free software development. But, certainly, it became an important thing that running currently has a small priority over Debian nowadays, for me. So, what happened on that front in 2012 for running bubulle? I finally managed to run 2900 km during the year, which is over 400km more than 2011. This is mostly due to the increasing part of running in my daily commute : a typical work week can now be something like this:

• Monday morning, leave home with a big bag and clothes for up to 4 work days (including those I'm wearing) plus running clothes (and shoes).
• Monday evening: come back by running. Either 4km, then 30 minutes train ride, then 3km more....or "the long version": 10km, then 20 minutes train ride, then 3km more.
• Tuesday: go to work by run+train+run, shower, change clothes, work, come back by run+train+run
• Wednesday: ditto
• Thursday: let's have a break. I usually work in another facility where it's less convenient to go by running
• Friday morning: go to work by run+train+run
• Friday evening: come back home with a big bag of dirty clothes

With such an organization, I can end up with weeks where I run up to 50-60 kilometers in 5 days, with peaks that may include 26km in one *work* day. I also end up having room in trains between the runs, I wonder why..:-) And, of course, during week-ends, I spend some parts of my time running too..:-). Indeed, just like for many drugs, I feel sad during days where I haven't run at all and it's usually hard for me to spend more than 2 days without. Indeed, the longest time period without running, this year, has been 9 days, just after the Caen marathon, in June. Mostly because, at that time, I reached a moment where training (and believe me, very boring and hard training) consumed all my motivation. But these moments are indeed very rare and training is mostly *never* boring for me. Mostly because I like running in the nature, in forests, woods, fields, country. Never wearing an MP3 player or any kind of such device toplay music, but just enjoying the outside, whether it's raining, winding, sunny hot. Running (particularly my daily commute) is also the moment where I *think* about my work, my technical activities, my own life, whatever. I think I even sometimes translated some software, mentally, while running..:) Indeed, there have been 205 days in this year where I ran at least once. Last year was 181 so....drug addiction is increasing. So, 2900 kilometers. That's about the distance from my place to Moscow in Russia. 282 hours (11 days18 hours.....9d21h last year). Average speed: 10,3km/h (10,5km/h last year). Cumulated height difference: 33,400 meters (27700m last year). More distance, more time, a bit slower: this is an obvious consequence of more trail running (which includes more difficulties, such as running on volcanoes!). Most active month: November with 331km. Less active month: June with 141km. This year was also a year of records:

• personal best broken in September by....14 seconds....on half-marathon with 1h37'28" after failing a first time by 20 seconds in March
• personal best broken twice in the two marathons I ran. first in June, in Caen, after a very hard 8-week training and in difficult conditions (rain, wind, hard race profile) with 3h38'45". Then, I managed to run a stunning 3h33'35" in October in Val du Rueil (a small town in the Seine river valley). That one will be hard to break now.
• longest distance run, with the "80km" Paris Ecotrail run in March, in 11 hours
• great progress in my other "ultra" race (70km in November) which I ran in 8h22 instead of 9h15 last year

I ran 10 official races during the year : two "ultra" races (70km Le Puy-Firminy in November, by night and 80km Paris Ecotrail in March), two marathons (Caen and Val de Rueil), four half-marathons and two "short" (less than 30km) trail races. How about next^W this year? Well, my goals are currently being secured:

• more trail races than roads races
• Paris 80km Ecotrail again in March. Goal: beat last year's 11 hours
• Le Puy-Firminy 70km again in November. A very nice "small" race (small by number of participants....but the effort is not small!).
• Mont-Blanc "marathon" in late June. Indeed a 42km trail race in Chamonix, starting at 1000m, finishing at 1600m, with a peak at 2300m and 2500m positive vertical gain (1490m negative).
• Another "long" trail race (40-60km) somewhere in April/May
• A "classic" marathon in October/November. Probably somewhere in France. Maybe La Rochelle. That might be the only classic marathon I run this year...unless I decide for another challenge like running two marathons in two consecutive Sundays..:-)
• Do once again my own personal marathon which is just "come back from work by foot".....which nearly equals the distance of a marathon. Something I achieved for the first time in September, in about 5 hours
• Maybe try a 6 or 12 hour race (running for 6 or 12 hours...or more...on a small 1-2km loop). These ones are very friendly ones and the only races where lame runners like me can run along with the best ones, not only for the first 100 meters.

All this of course is assuming that no injury comes up (my ankles are sometimes yelling outbut I'm fortunate enough to not have articulation problems that many runners have, particularly in knees). We'll see on January 1st 2014...:-)

Review: City of Diamond, by Jane Emerson

Publisher:	DAW
Copyright:	March 1996
ISBN:	0-88677-704-6
Format:	Mass market
Pages:	624

The setting is deep into the star-faring future of humanity. Humans have settled many other worlds, thanks largely to technology from a race named the Curosa. There is a thriving network of settlement based around a sort of warp conduit network. But, standing apart from most human settlements, are three huge ships: the City of Opal, the City of Pearl, and the City of Diamond. Their inhabitants are devout members of the Redemptionist faith, a merging of Christian (primarily Catholic) belief and Curosa religion. Their ships are gifts from the now-departed Curosa, featuring drives unknown to the rest of humanity that allows them to ignore the normal transport network. They are meant to witness and spread their religion, but now, six centuries later, they primarily trade. Much of this is not apparent at the start. City of Diamond opens with Adrian Mercati, chosen heir of the current dying Protector, dodging people in what seems to be an oddly-organized city. Impudent, occasionally flippant, utterly charming, and in love with danger, he inherits the position of Protector shortly after we meet him. Emerson slowly reveals more of the nature of the ship while Adrian is shocking (and charming) the nobility and the church, and consorting with demons. Or, at least, one demon: Tal, an entirely human-appearing creature except for his eyes, who the Redemptionists claim is born without a soul. Slowly, it becomes clear that he's actually the offspring of an alien and a human, a mating of species whose children cannot socialize as human and behave in ways that seem like human sociopaths. Tal is no exception, but his interests align with Adrian's for the time. To those two viewpoint characters, Emerson adds four more: a low-rank administrator named Spider who works for Tal after Tal saved him from death by recycling, Adrian's politically-arranged bride-to-be from the rival (and even more religious) ship City of Opal, a guard from a French-descended slum on City of Opal, and a dangerously honorable and literal mercenary from an off-shoot culture of humanity that's now only a legend. This is a book that tends to sprawl. There's quite a lot going on, starting with the negotiations between City of Diamond and City of Opal to put to rest the remnants of a civil war and leading to the search for a legendary Curosa artifact on the planet they're both visiting. All of the characters have their own agendas, their own history, and their own goals, and are pursuing them in parallel and occasionally in opposition. Emerson takes the time to let all of this build. Despite that, there is very little in this book that drags or bores, and that's due primarily to the strength of the characters. Every one of the viewpoint characters is unique, bringing a different perspective to the story, and every one of them changes and grow over the course of the story. They also play off of each other in delightful ways. This is a book that makes full use of the fact that three characters make seven character interactions. For example, Tal by himself is logical but just slightly askew, Tal seen by Spider is uncomfortable and worrisome, Tal and Adrian is a dance of mutual amusement and respect, and Tal and Keylinn finding points of commonality is just delightful. I did wish that there was a bit more Keylinn and Tal and a bit less of Spider, but once Emerson built her world, introduced her characters, and got the story moving, there aren't many weak pieces. Part of the fun is figuring out the world background. There are almost no infodumps here; Emerson just starts telling stories of characters in the surroundings in which they find themselves, and the reader is left to piece things together from background description, the occasional explanation from one character to another, and parallels with long-standing SF tropes. It's not a puzzle book, but it is a book of where the reader is dropped as an alien into a fully-developed culture. In both that way and in the use of nobility, religion, and formal hierarchy against a starfaring backdrop, City of Diamond reminds me of the sort of classic space opera that led up to Star Wars but isn't seen as much these days. It's also funny. I was unsurprised to discover that Emerson is a pseudonym for Doris Egan, who (in addition to writing some other SF) is an occasional writer and producer for House. The humor isn't entirely obvious at the start, although Adrian frequently provokes a grin from the start of the book, but Tal's perceptive but obliviously blunt comments become more and more fun as the book progresses, and both Iolanthe (Adrian's bride) and Keylinn (the mercenary, sort of) are a delight. I want to see more of both of them, but sadly the book ends just as they (particularly Iolanthe) are hitting their strides. And that's the biggest problem with City of Diamond: it's a failed (or at least postponed) trilogy. As with Walter Jon Williams's Metropolitan and City on Fire, there were supposed to be more books, but apparently either the publisher lost interest or other projects took precedence. The story does come to something of a conclusion, but most of the major story arcs aren't resolved. Emerson is still bringing more guns onto the set late in the book. None of the villains truly get their just desserts, nor do most of the character arcs fully resolve, although friendships and more have formed satisfyingly by the end of the book. There is obviously far more to both these characters and this universe, including an entire ship that was never visited and an alien whose presence should prove startling. This is a great book: warm, funny, full of interesting characters, and with a nicely complex background universe. If it were complete in itself, or if the sequels had materialized, I would recommend it unreservedly. As is, you will have to weigh your dislike of unfinished stories against its stand-alone merits. But I enjoyed it a great deal. Rating: 7 out of 10

mksh made quite some waves (machine translation of the third article) recently. Let s state it s not just Amigas ara5 is a buildd running the Atari kernel, an emulated though. On the other hand, the bare-metal Ataris used to be the fastest buildds, so I expect we get them back online soonish. I m currently fighting with some buildd software bugfixes, but once they re in, we will make more of them. Oh, and porterboxen! Does anyone want to host a VM with a porterbox? Requirements: wheezy host system (can be emulated), 1 GiB RAM, one CPU core with about 6500 BogoMIPS or more (so the emulated system has decent speed; an AMD Phenom II X4 3.2 GHz does just fine). Oh, and mksh is ported to more and more platforms, like 386BSD 0.0 with GCC 1.39, and QNX 4 with Watcom and more bugfixes are also being worked on. And let s not forget features! jupp got refreshed: it s got a bracketed paste mode, which is even auto-enabled on xterm-xfree86 (though the xterm(1) in MirBSD s a tad too old to know it; will update that later, just imported sendmail(8) 8.14.6 and lynx(1) 2.8.8dev.15 into base, more to come) and will be enhanced later (should disable auto-indent, wordwrap, status line updates, and possibly more), lots of new functions and bindings, now uses mkstemp(3) to create backup files race-free, and more (read the NEWS file). In MirBSD, Benny and I just added a number of errnos, mostly for SUSv4 compliance and being able to compile more software from pkgsrc without needing to patch. This is being tested right now (although I should probably go out and watch fireworks in less than a half-hour), together with the new imports and the bunch of small fixes we accumulate (even though most development in MirBSD is currently in mksh(1) and similar doesn t mean that all is, or worse, we were dead, which we aren t). I ll publish a new snapshot some time in January. The Grml 2012.12 also contains a pretty up-to-date MirBSD, with a boot(8/i386)loader that now ignores GUID partition table entries when deciding what to use for the a slice. If you haven t already done so, read Benjamin Mako Hill s writings!

I finally published a short essay I wrote about a year ago: Freedom for Users, Not for Software. Anybody who has hung around the free software community for a while will be familiar with the confusion created by the ambiguity between "free as in price" versus "free as freedom." In the essay I argue that there is a less appreciated semantic ambiguity that arises when we begin to think that what matters is that software is free. Software doesn't need freedom, of course; Users of software need freedom. My essay looks at how the focus on free software, as opposed to on free users, has created challenges and divisions in the free software movement. The essay was recently published in Wealth of the Commons: A World Beyond Market and State, a book edited by David Bollier and Silke Helfrich and published by Levellers Press. The book includes essays by 73 authors that include some other folks from the free software and free culture communities along with a ton of people working on very different types of commons. My essay is short and has two parts: The first is basically a short introduction to free software movement. The second lays out what I see as major challenges for free software. I will point out that these are some of the areas that I am working most closely with the FSF who are having their annual fundraiser at the moment to support and build advocacy programs around.

A while ago I wrote a blog post debunking the idea that swap should be twice as large as RAM [1]. The issue of swap size has come up for discussion in a mailing list so it seems that it s worth another blog post. Swap Size In my previous post I suggested making swap space equal to RAM size for systems with less than 1G of RAM and half RAM size for systems with 2-4G of RAM with a maximum of 2G for any system. Generally it s better to have the kernel Oom handler kill a memory hungry process than to have the entire system go so slow that a hardware reset is needed. I wrote memlockd to lock the important system programs and the shared objects and data files they use into RAM to make it easier to recover from some bad paging situations [2], but even that won t always make it possible to login to a thrashing system in a reasonable amount of time. But it s not always good to reduce swap size. Sometimes if you don t have enough swap then performance sucks in situations where it would be OK if there was more swap. One factor in this regard is that pages mapped read-only from files are discarded when there is great memory pressure and no swap space to page-out the read-write pages. This can mean that you get thrashing among memory for executables and shared objects while there s lots of unused data pages in RAM that can t be paged out. One noteworthy corner case in this regard is Chromium which seems to take a lot of RAM if you have many tabs open for a long time. Another factor is that there is a reasonable amount of memory allocated which will almost never get used (EG all the X based workstations which have 6 gettys running on virtual consoles which will almost never be used). So a system which has a large amount of RAM relative to it s use (EG a single-user workstation with 8G of RAM) can still benefit from having a small amount of swap to allow larger caches. One workstation I run has 8G of RAM for a single user and typically has about 200M of the 1G swap space in use. It doesn t have enough swap to make much difference if really memory hungry programs are run, but having 4G of memory for cache instead of 3.8G might make a difference to system performance. So even systems which can run without using any swap can still be expected to give better performance if there is some swap space for programs that are very inactive. I have some systems with as much 4G of swap, but they are for corner cases where swap is allocated but there isn t a lot of paging going on. For example I have a workstation with 3G of RAM and 4G of swap for the benefit of Chromium. Hardware Developments Disk IO performance hasn t increased much when compared to increases in RAM size over the last ~15 years. A low-end 1988 era hard drive could sustain 512KB/s contiguous transfer rates and had random access times of about 28ms. A modern SATA disk will have contiguous transfer rates getting close to 200MB/s and random access times less than 4ms. So we are looking at about 400* the contiguous performance and about 10* the random access since 1988. In 1988 2MB was a lot of RAM for a PC, now no-one would buy a new PC with less than 4G so we are looking at something like 2000* the RAM size in the same period. When comparing with 1993 (when I first ran a Linux server 24*7) it was 4M of RAM, maybe 15ms random access, and maybe 1MB/s contiguous IO approximately double everything I had in 1988. But I ll use the numbers from 1988 because I m more certain of them even though I never ran an OS capable of proper memory management on the 1988 PC. In the most unrealistically ideal situation paging IO will be a factor of 5* more expensive now relatively than it was in 1988 (RAM size increase by a factor of 2000 divided by contiguous IO performance increase by a factor of 400). But in a more realistic situation (random IO) it will be 200* more expensive relatively than it was. In the early 90s a Linux system with swap use equal or greater than RAM could perform well (my recollection is that a system with 4M of RAM and 4M of active swap performed well and the same system with 8M of active swap was usable). But nowadays there s no chance of a system that has 4G of RAM and 4G of swap in active use being usable in any way unless you have some corner case of an application allocating RAM and not using it much. Note that 4G of RAM doesn t make a big system by today s standards, so it might be reasonable to compare 2M in 1988 to 8G or 16G today. But I think that assuming 4G of RAM for the purpose of comparison makes my point. Using Lots of Swap It is probably possible to have some background Chromium tabs using 4G of paged out RAM with good system performance. I ve had a system use 2G of swap for Chromium and perform well overall. There are surely many other ways that a user can launch processes that use a lot of memory and not use them actively. But this will probably require that the user know how the system works and alter their usage patterns. If you have a lot of swap in use and one application starts to run slowly you really don t want to flip to another application which would only make things worse. If you use tmpfs for /tmp then you need enough swap to store everything that is written to /tmp. There is no real upper limit to how much data that could be apart from the fact that applications and users generally don t want to write big data files that disappear on reboot. I generally only use a tmpfs for /tmp on servers. Programs that run on servers tend not to store a large amount of data in /tmp and that data is usually very temporary, unlike workstation users who store large video files in /tmp and leave them there until the next reboot. Are there any other common corner cases that allow using a lot of swap space without serious performance problems? My Swap Space Allocation When I setup Linux workstations for other people I generally use 1G of swap. For a system that often has multiple users (via the user-switch feature) I use 2G of swap if it only has 3G of RAM (I run many systems which are limited to 3G of RAM by their chipset). For systems that I personally use I generally allocate 4G of swap, this is to cater to excessive RAM use by Chromium and also because I test out random memory hungry programs and can t easily predict how much swap space will be needed a typical end-user desktop system is a lot more predictable than a workstation used for software development. For servers I generally allocate 512M of swap space. That s enough to page out things that aren t used and make space for cache memory. If that turns out to be inadequate then it s probably best to just let the watchdog daemon reboot the system.

• [1] http://etbe.coker.com.au/2007/09/28/swap-space/
• [2] http://doc.coker.com.au/projects/memlockd/

Installing an operating system When you want to install a new operating system, the first thing to do is to get an installer medium, which usually involves two steps: downloading an image, and writing it to a medium. There are two major types of media usable for that purpose: optical discs and USB sticks. There used to be a third one, floppy disks, but it is no longer used, and it was conceptually very similar to USB sticks.Power-user If you are a power-user, you probably use USB stick, to be able to reuse them and because they are easier to carry. For you, writing an optical disc or an USB drive is almost the same:

$ wodim image.iso
$ dd if=image.img of=/dev/sdc

Regular user But what would you suggest to a normal user? USB stick? You should not: while it is technically much easier to write an USB stick (just copy blocks from the image to the peripheral file, without any need to use any specific function), desktop file manager make it much harder. Indeed, for a desktop user, burning an ISO image to an optical disk is quite simple: right-click on the image file and choose the burn option. But writing an image to an USB stick? There is no similar option, so that will involve calling a power-user friend, which will tell you to open a terminal and type dd if= . Moral

Power-users

Continue using USB sticks as installation media, but tell regular users to use optical discs until desktop file managers adapt.

Regular users

Use optical discs. If your computer does not have an optical reader, either invite a power user friend, or buy an USB optical reader.

Desktop developers

Please, fix that! Writing an image to an USB stick should not be harder than burning it to an optical disc! People are using more and more computers without an optical reader, and that situation is certainly not new, as it is only similar to that of the time when we were using floppy disks.

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.

People seemed interested in my mini-reviews of static-site generators. I promised to review more in the future, and so to shame myself into doing so I present:

• https://github.com/skx/static-site-generators

As you can see I've listed my requirements, and I've included a project for each of the tools I've tested. I will continue to update as I go through more testing. As previously mentioned symlink-handling is the thing that kills a lot of tools.

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

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

The Microsoft Surface is a fairly attractive bit of tablet hardware, and as a result people have shown interest in running Linux on it. The immediate problem is that (like many ARM devices) it has a locked-down firmware that will only run signed binaries - unlike many other ARM devices, this is implemented using an existing standard (UEFI Secure Boot). Microsoft provide a signing service for UEFI binaries, so it's tempting to think that getting around this restriction would be as simple as taking an existing Linux bootloader, signing it and then booting. Unfortunately Microsoft's signing service signs binaries using a different key (the "Microsoft Windows UEFI Driver Publisher" key) to the one used to sign Windows, and the Surface doesn't carry that key. Booting Linux on these devices would involve finding a flaw in the firmware and using that to run arbitrary code.

Could this also be a problem on x86? In theory - Microsoft don't require that vendors carry the driver publisher key, and so a system could be Windows 8 certified and still not carry it. It's unlikely to occur in practice, though, since any third party expansion hardware will then fail on that device. As a result, anything with PCIe or Expresscard slots is effectively certain to have this key. If anyone finds any counterexamples, please let me know.

comments

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

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!

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.