I started this blog over a decade ago. Over time, my priorities have changed family, work, home, etc. Many other avenues for online self-expression have also developed in the interim. I m done for now. Old entries remain online, but do not necessarily reflect any of my current views, and certainly do not reflect any views of any of my employers.

I got a beer bread kit from Mum for Christmas this year. It seems pretty easy, so for a pre-new-year treat, I gave it a go. Of course, for the beer I'm using one of my first batch of home brewed beer that I made just before the holidays. Chuck it in Mix it for around 30 seconds. Discover there is no bread tin here, so use cake tins instead. Flatter than it should be, but otherwise YUM YUM YUM

I've been at the cabin, on solar power, for a year now. I have a year of data! Everything went pretty well until last month. There was an April rainy spell where power felt slightly tight. Then over the summer, plenty of power, no need to conserve. The last month though had what seemed like weeks of continual grey clouds, where I never saw the sun.

high noon today

Of course, even on a sunny day in winter, it does not get far above the hills, and the peak production window is only a few hours. This bad combination had my battery power dipping below the 10 volts that I consider low, down to 9, and even to 8 volts. I use kerosine lamps in the winter. (I prefer the light anway.) I've also started unplugging my Thecus server at night to conserve power, meaning no internet late or early. For four or so nights, I had no power to run even my laptop after sunset. On one notable day, there was no power even in the daytime. Even when it turned sunny again, I found that the batteries would seem to charge to 12 volts during the day, but then precipitously drop to 10 and 9 volts at night. I think the problem was not damaged batteries, but that these Nicads charge most efficiently above 12 volts (14 volts is best), and there was never enough power saved up to get them full enough that they could charge really efficiently. So, I reluctantly spent three days away this week, to let the batteries soak up sun and recover. It seems to have worked; they've been holding a 12 volt charge overnight again.

Barry Ritholtz wrote an insightful post quoting Federal Reserve Bank of Kansas City President Thomas Hoenig, who warns that the nation s biggest banks are putting the U.S. capitalist society at risk [1]. Big banks oppose capitalism. Glenn Greenwald has written an insightful article for Salon about the modern definition of American excellence being the killing of supposedly bad people without any due process [2]. Mazuma Mobile buys used mobile phones [3]. They can send a post-pack to ship your old mobile to them. This is good for the environment and also saves some money. Sam Varghese has written an informative article about the Trans Pacific Partnership Agreement that will probably end up benefiting US corporations at the expense of Australian citizens [4]. Cory Doctorow has written an informative article for The Guardian about the BBC DRM plans[5]. He received information that was denied in a FOI request which shows how poor the BBC case is and how bad the Ofcom oversight is. Sam Harris has written an insightful blog post about self-defense [6]. He also has many other posts that are worth reading. Aparna Roa gave an interesting TED presentation about her robotic art [7].

• [1] http://www.ritholtz.com/blog/2011/06/hoenig-capitalism-at-risk/
• [2] http://www.salon.com/2011/10/22/a_remaining_realm_of_american_excellence/singleton/
• [3] http://www.mazumamobile.com.au/
• [4] http://wildcard.gnubies.com/?p=1433
• [5] http://www.guardian.co.uk/technology/2011/nov/14/bbc-hd-drm
• [6] http://www.samharris.org/blog/item/the-truth-about-violence/
• [7] http://www.ted.com/talks/aparna_rao_high_tech_art_with_a_sense_of_humor.html

I ve recently been reading the Sociological Images blog [1]. That site has lots of pictures and videos that are relevant to the study of Sociology (most of which have a major WTF factor) and it s run by people who have Ph.Ds in Sociology so the commentary is insightful. Since reading that I ve started photographing relevant things. I can t work out the logic behind the above advert for Energy Watch which was on a billboard near Ringwood Station in Melbourne, Australia. The only thing that it clear is that it spreads bad ideas about mental illness and psychiatric treatment. It doesn t make me want to do business with them. The above picture is a shop-front for the Antons clothing store (I m not sure if they are a tailor or if they sell ready to wear). It was taken on Lonsdale St, Melbourne where the store apparently used to be, now they are in Melbourne Central. The above pictures show more detail. Unfortunately the combination of lighting and my camera (Xperia X10 phone camera) wasn t adequate to show the apparent ethnic differences between the two men. It seems that the most likely Australian interpretation of the ethnic groups that are represented are African (maybe Afro-American), Southern-European or maybe American Hispanic, North-Western European, and Japanese. It s good to have mannequins representing the fact that not everyone in Australia is white, but different facial expressions for different races seems a strange choice (admittedly it might be a choice made by mannequin manufacturers). Also the Japanese woman with fan idea is rather outdated. I ve just started reading You May Ask Yourself: An Introduction to Thinking Like a Sociologist (Second Edition) by Dalton Conley. I ve only read the first chapter, but that was good enough that the entire book has to be good enough to recommend.

• [1] http://thesocietypages.org/socimages

On the 1st of August I noticed that the server which runs my blog among other things was having an occasional SEGV from a sshd process. Unfortunately I was busy and didn t pay much attention to this, which turned out to be a big mistake. On the 12th of September I started investigating this properly and noticed that when someone tried to connect to ssh with password authentication sshd would SEGV after it was denied access to a shared memory region or a semaphore which had a SE Linux type of unconfined_t. I added some SE Linux auditallow rules and discovered that the memory region in question was created by the ssh client. Shortly after that I came to the conclusion that this wasn t some strange feature of ssh (or one of the many shared objects it uses) but hostile activity. The ssh client appeared to be storing passwords that it used in a shared memory region and sshd was also collecting passwords in the same region and presumably offering them to a ssh client which uses some extension to the ssh protocol. The sshd process was crashing because it couldn t handle EPERM on access to shared memory or semaphores. Presumably if the system in question wasn t running SE Linux then the exploit would have remained undetected for a lot longer. At this stage we don t know how the attacker got in. Presumably one of the people with root access ran a ssh client on a compromised system and had their password sniffed. One such client system was mysteriously reinstalled at about that time, the sysadmin of the system in question claimed to have no backups which made it impossible to determine if that system had been compromised. I believe that the sysadmin of the client system knew that their system was compromised, kept that information secret, and allowed other systems to become and remain compromised. The attacker made no good effort to conceal their presence, they replaced ssh, sshd, and ssh-add and didn t bother changing the Debian checksums so the debsums program flagged the files as modified. Note that I have kept copies of the files in question and am willing to share them with anyone who wants to analyse them. Steinar H. Gunderson has named this trojan Ebury [1]. Recovery By the evening of the 13th of September I had the system mostly working again. Jabber still isn t working because ejabberd is difficult to get working at the best of times, I am now investigating whether there is a better Jabber server to use, but as I don t use Jabber often this hasn t been a priority for me. Some of the WordPress plugins I use and all of the WordPress themes that are installed were outside the Debian packaging system, as I couldn t be sure that they hadn t been altered (because the people who wrote WordPress plugins don t keep old versions online) I had to upgrade to the newer versions. Of course the newer versions weren t entirely compatible so I had to use a different theme and I couldn t get all plugins working. Link Within no longer works, not that it ever worked properly [2], I wanted to try Outbrain again but their web site won t let me login (and they haven t responded to my support request). Does anyone know of a good WordPress plugin to provide links to related content? Either related content on my blog or on the Internet in general will be OK. Some people have asked me about the change in appearance of my blog. It was simply impossible (for someone with my PHP skills) to get my blog looking the same way as it did before the server was cracked. I think that the new look is OK and don t mind if people think it looks likw a VW advert VW make great cars, I was very satisfied with the VW Passat I used to drive. Future Plans I had bought some Yubikeys (USB devices that generate one-time passwords) [3] to control access to that server, if I had configured the software to use them then this might not have happened. The use of one-time password devices can prevent passive password-sniffing attacks. It would still allow active attacks (such as using ControlPath/ControlMaster options on the ssh client to allow a hostile party to connect later (EG the -M, -S, and -o ControlPersist options for the ssh client). It s a pity that there doesn t seem to be a way to configure the ssh server to disable ControlMaster. Conclusion It would be good to have some changes to sshd to allow more restrictions on what a client can request, as ControlMaster functionality isn t needed by most users it should be possible to disable it. SE Linux doesn t protect against a compromised client system or any other way of stealing passwords. It did do a good job of stopping Ebury from doing all the things it wanted to do and thus making me aware of the problem. So I count this as a win for SE Linux. Yubikeys are the cheapest and easiest way of managine one-time passwords. I had already bought some for use on the system in question but hadn t got around to configuring them. I have to make that a priority.

• [1] http://be-geek.com/linux/2011/11/15/steinar-h-gunderson-ebury-a-new-ssh-trojan
• [2] http://etbe.coker.com.au/2010/04/30/link-within/
• [3] http://www.yubico.com/

A minor new release of the RcppExamples package is now on CRAN. RcppExamples contains a few illustrations of how to use Rcpp. It grew out of documentation for the classic API (now in its own package RcppClassic), and while we added a few more functions documenting how to do the same with the new API, the package is still nowhere near completion. The two ChangeLog entries since the last release are below. One new example was added, and some things were changed in order to make R CMD check (and the CRAN gate keepers) happy.

2011-12-28  Dirk Eddelbuettel  <edd>
        * DESCRIPTION: Release 0.1.3
        * src/newRcppDateExample.cpp: switch from std::cout to the new
        Rcpp::Rcout device available since Rcpp 0.9.8
        * src/classicRcppDateExample.cpp: idem
        * DESCRIPTION: Depends on Rcpp (>= 0.9.9) for Rcpp::Rcout
2011-04-08  Dirk Eddelbuettel  <edd>
        * R/RcppDataFrame.R: Added new example for Rcpp::DataFrame
        * src/RcppDataFrame.cpp: C++ source for new example
        * man/RcppDataFrame.Rd: Documentation
        * man/RcppParams.Rd: Small change to suppres a warning

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

The bug webinterface of the Ultimate Debian Database currently knows about the following release critical bugs:

In Total:	1586
Affecting Wheezy:	960
Wheezy only:	163
Remaining to be fixed in Wheezy:	797

Of these 797 bugs, the following tags are set:

Pending in Wheezy:	49
Patched in Wheezy:	117
Duplicates in Wheezy:	50
Can be fixed in a security Update:	26
Contrib or non-free in Wheezy:	9
Claimed in Wheezy:	0
Delayed in Wheezy:	8
Otherwise fixed in Wheezy:	49

Ignoring all the above (multiple tags possible) 552 bugs need to be fixed by Debian Contributors to get Debian 7.0 Wheezy released. However, with the view of the Release Managers, 862 need to be dealt with for the release to happen. Please see Interpreting the release critical bug statistics for an explanation of the different numbers.

* Some months back, we (Mark Hills is main culprit here) decided to fork xosview codebase and released new version 1.9.0. I had no luck contacting main authors and there were 23 Debian patches pending. Mark did amazing job here and we ve one major and one minor releases in two months. Kudos to him again. You can always grab latest Debian packages from unstable and code from Mark s Github xosview project page. Temporary homepage until we take over SF.net project is here. Feel free to send patches! (This post is bought to you by myself that this blog exists )

Backups are something I don't do well. I hope to write a more thorough article about them at some point. For now, here are some tips. Like most home users, I don't have access to a tape drive or jukebox for backups. I'm therefore looking for a solution that backs up to a local block device. I haven't ruled out a solution that backs up to DVD-Rs, but I haven't found a suitable one. I first tried rsnapshot, which uses hard link trees to represent increments. I found that this resulted in enormous filesystem metadata, sufficient to cause the machine I was running it on (an embedded ARM system) to slow to a crawl. I'd recommend to avoid anything using this technique. I more recently have been using rdiff-backup. This has appeared to work quite well for a number of years. However, it does not gracefully handle the backup volume being full, spewing python backtraces. This is compounded with some confusing use of temporary directies and not honouring $TMPDIR. This has been known about for years (1, 2). I've just independently discovered these problems for the second time. Aside from that, because it does not de-duplicate files, it is sensitive to large files being moved around in the source being backed up. It also cannot do a dry-run estimate of the disk space required for the next increment. So: time to move on. Back in 2010 I discovered bup, an intriguing backup tool that used a git-style backing store. It's interesting enough that I packaged it and use it in a few situations, but I wouldn't rely on it for my main backups, for two reasons: one, it's not tried-and-tested enough yet (but that is rapidly being resolved), two: you can't get rid of old increments, so your backup volume will always increase in size over time, and never throw away old data. So, for now: move on. Next on my list to try is Lars Wirzenius' obnam.

Hello, World! Today s hacks come remotely, on the first day of my long trek to Cleveland. As many debian readers know, debian URLs are usually transmitted over IRC or email with some snappy abbreviations. Usually, you ll see something like:

Feel free to check out information about frob at wiki.d.o/Frob

or something like:

I have uploaded package bar onto mentors.d.n for review

What bugs me most about this is that I have to expand URLs by hand. Which is lame. Enter libolla (a fitting name as well as a graceful nod to my alma mater John Carroll University s crest). When LD_PRELOAD d, it ll intercept and expand calls to getaddrinfo transparently. It seems to work fine on SSH, and chrome (but I can t test well, since I m not on a real line). This was all hacked up in a few hours I had to spare, and without any sort of internet love, so I m willing to bet there are some bits that can be cleaned up (after all, the name of the blog is Peace, Love and C++ , not Peace, Love and C - I don t clam to be a c expert ;) ) So, feel free to fork the project on github (or as I can now do - http://g.c/paultag/libolla) Now, I just need to find a way to globally pre-load this for apps that I start in my DE. Should be easy enough fiddling with some env-var files.

So there are two servers; let's call them srv1 and srv2. Srv1 contains a bunch of subversion repositories, but these are to be migrated to srv2. Since the repositories are not (just) used for ascii-only files, they're fairly big (several tens of gigabytes, altogether), so copying them from one server to the other would take a while. In order to make sure this would happen quickly, we had already copied them over to the new server, so that on the final switch would be quick (an rsync that would copy over just the new done transactions). That final switch was today. Only I didn't know that instead of just testing, the customer had already started using one of the repositories (and they'd forgotten to remind me), so the subversion repository suddenly jumped backwards in time. In addition, the new server wasn't being backed up yet (at least not for the subversion bits), so restoring from backups wasn't an option. Oops. Luckily the solution is fairly simple. You see, fsfs stores each revision in a unique file; that means that as long as nobody has committed to the repository yet (which they couldn't, since system users aren't the same on both servers, so the webserver didn't have write permissions on the repository after the rsync), nothing is lost. One only needs to manually change the repository so that whatever subversion thinks is the latest commit, actually is the latest commit. That information is stored in a file called db/current inside the repository. What's in that file depends on the repository version, which is stored in a file called db/format in the repository. For versions 1 and 2, the format is a single line with three space-separated values, of which the first is the last revision number used in the repository. The other two are counters that are used to give transactions unique names; and they, too, need to be up-to-date. For version 3 and above, the file contains only the revision number; there, the other two are derived from that instead of having their own unique number. Figuring out the last used revision number in an fsfs repository is ridiculously easy:

ls -v db/revs tail -n1

So if you've got a repository of fsfs version 3 or above, just change the revision number in the db/current file (after taking backups and making sure nobody can access the repository while you're doing this, of course), and you're all set. Unfortunately, in my case, the repository was still in fsfs version 2, which meant I could not change just the revision number and not expect trouble. I suppose it should've been possible to figure out what the last transaction numbers are, somehow, so that I could fix the current file completely, but I reasoned that upgrading to a newer repository format might have other advantages too, so I just dumped the repository and reloaded it, and everything worked at that point.

I have recently switched my http server from Apache to nginx. The switch was mostly painless thanks to the good documentation available on the nginx wiki. I have been able to move all my public virtual hosts, and have already noticed the improvement on how fast the pages load. Here is a sample graph of the disk I/O rates of my linode showing before/after the switch to nginx: I only had an issue with StatusNet due to the default behavior of spawn-cgi to not spawn any PHP child except if told otherwise. I also had to fix the OpenID plugin for WordPress, as per this commit. For now, I keep apache running for the DSPAM Web UI, which requires suexec. I know I can easily run the CGI through a different user, but still have to polish my setup for FastCGI.

A recent trip to Switzerland made me dig out my prepaid card for UMTS usage again. This resulted in some minor enhancements for Prepaid Manager. The new release handles disabled and missing modems more reliably. It also has some visual feedback if we know the length of the top up code: This blog is flattr enabled.

Symbol files are a nice little feature to reduce dependencies of packages. Before there were symbol files libraries in Debian just had shlibs files (both to be found in /var/lib/dpkg/info/. A shlibs file says for each library which packages to depend on when using this library. When a package is created, the build scripts will usually call dpkg-shlibdeps, which then looks which libraries the programs in the library use and then calculate the needed dependencies. This means the maintainers of most packages do not have to care what libraries to depend on, as it is automatically calculated. And as compiling and linking against a newer version of a library can cause the program to no longer work with an older library, it also means those dependencies are correct regardless of which version of a library is compiled against. As shlibs files only have one dependency information per soname, that also means they are quite strict: If there is any possible program that would not work with an older version of a library, then the shlibs file must pull in a dependency for the newer version, so everything needing that library ends up depending on the newer version. As most libraries added new stuff most of the time, most library packages (except some notable extremely API stable packages like for example some X libs) just chose to automatically put the latest package version in the shlibs file. This of course caused library packages to be quite strict: Almost every package depended on the latest version of all libraries, including libc, so practically no package from unstable or testing could be used in stable. To fix this problems, symbols files were introduced. A symbols file is a file (also finally installed in /var/lib/dpkg/info/ alongside the shlibs file) to give a minimum version for each symbol found in the library. The idea is that different programs use different parts of a library. Thus if new functionality is introduced, it would be nice to differentiate which functionality is used and give dependencies depending on that. As the only thing programmatically extractable from a binary file is the list of dynamic symbols used, this is the information used for that. But this only means the maintainer of the library package has now not only one question to answer ("What is the minimal version of this library a program compiled against the current version will need?"), but many questions: "What is the minimal version of this library a program compiled against the current version and referencing this symbol name will need?". Given a symbols file of the last version of a library package and the libraries in the new version of the package, there is one way to catch obvious mistakes: If a symbol was not in the old list but is not in the current library, one needs at least the current version of the library. So if dpkg-gensymbols finds a missing symbol, it will add it with the current version. While this will never create dependencies too strict, it sadly can have the opposite effect of producing dependencies that are not strict enough: Consider for example some library exporting the following header file:

enum foo_action   foo_START, foo_STOP ;
void do_foo_action(enum foo_action);

Which in the next version looks like that:

enum foo_action   foo_START, foo_STOP, foo_RESTART ;
void do_foo_action(enum foo_action);

As the new enum value was added at the end, the numbers of the old constants did not change, so the API and ABI did not change incompatibly, so a program compiled against the old version still works with the new one. (that means: upstream did their job properly). But the maintainer of the Debian package faces a challenge: There was no new symbol added, dpkg-gensymbols will not see that anything changed (as the symbols are the same). So if the maintainer forgets to manually increase the version required by the do_foo_action symbol, it will still be recorded in the symbols file as needing the old version. Thus dpkg will not complain if one tries to install the package containing the program together with the old version of the library. But if that program is called and calls do_foo_action with argument 2 (foo_RESTART), it will not behave properly. To recap:

• Symbols files are a way to minimize dependencies by looking at which symbols of a library a program uses.
• A symbol file lists for each symbol the minimal version of the library a program referencing that symbol needs
• dpkg-gensymbols can detect added functionality if it adds new symbol names
• it's the duty of the maintainer to ensure added functionality not visible by symbol references is properly recorded in the symbols file

There has been a lot of discussion recently about the recent Microsoft ideas regarding secure boot, in case you have missed it Michael Casadevall has written a good summary of the issue [1]. Recently I ve seen a couple of people advocate the concept of secure boot with the stated idea that root should be unable to damage the system, as Microsoft Software is something that doesn t matter to me I ll restrict my comments to how this might work on Linux. Restricting the root account is something that is technically possible, for much of the past 9 years I have been running SE Linux Play Machines which have UID 0 (root) restricted by SE Linux such that they can t damage the system [2] there are other ways of achieving similar goals. But having an account with UID 0 that can t change anything on the system doesn t really match what most people think of as root , I just do it as a way of demonstrating that SE Linux controls all access such that cracking a daemon which runs as root won t result in immediately controlling the entire system. As an aside my Play Machine is not online at the moment, I hope to have it running again soon. Root Can t Damage the System One specific claim was that root should be unable to damage the system. While a secure boot system can theoretically result in a boot to single user mode without any compromise that doesn t apply to fully operational systems. For a file owned by root to be replaced the system security has to be compromised in some way. The same compromise will usually work every time until the bug is fixed and the software is upgraded. So the process of cracking root that might be used to install hostile files can also be used at runtime to exploit running processes via ptrace and do other bad stuff. Even if the attacker is forced to compromise the system at every boot this isn t a great win for the case of servers with months of uptime or for the case of workstations that have confidential data that can be rapidly copied over the Internet. There are also many workstations that are live on the Internet for months nowadays. Also the general claim doesn t really make sense on it s own. root usually means the account that is used for configuring the system. If a system can be configured then the account which is used to configure it will be able to do unwanted things. It is theoretically possible to run workstations without external root access (EG have them automatically update to the latest security fixes). Such a workstation configuration MIGHT be able to survive a compromise by having a reboot trigger an automatic update. But a workstation that is used in such a manner could be just re-imaged as it would probably be used in an environment where data-less operation makes sense. An Android phone could be considered as an example of a Linux system for which the root user can t damage the system if you consider root to mean person accessing the GUI configuration system . But then it wouldn t be difficult to create a configuration program for a regular Linux system that allows the user to change some parts of the system configuration while making others unavailable. Besides there are many ways in which the Android configuration GUI permits the user to make the system mostly unusable (EG by disabling data access) or extremely expensive to operate (EG by forcing data roaming). So I don t think that Android is a good example of root being prevented from doing damage. Signing All Files Another idea that I saw advocated was to have the secure boot concept extended to all files. So you have a boot loader that loads a signed kernel which then loads only signed executables and then every interpreter (Perl, Python, etc) will also check for signatures on files that they run. This would be tricky with interpreters that are designed to run from standard input (most notably /bin/sh but also many other interpreters). Doing this would require changing many programs, I guess you would even have to change mount to check the signature on /etc/fstab etc. This would be an unreasonably large amount of work. Another possibility would be to change the kernel such that it checks file signatures and has restrictions on system calls such as open() and the exec() family of calls. In concept it would be possible to extend SE Linux or any other access control system to include access checks on which files need to be signed (some types such as etc_t and bin_t would need to be signed but others such as var_t wouldn t). Of course this would mean that no sysadmin work could be performed locally as all file changes would have to come from the signing system. I can imagine all sorts of theoretically interesting but practically useless ways of implementing this such as having the signing system disconnected from the Internet with USB flash devices used for one-way file transfer because you can t have the signing system available to the same attacks as the host system. The requirement to sign all files would reduce the use of such a system to a tiny fraction of the user-base. Which would then raise the question of why anyone would spend the effort on that task when there are so many other ways of improving security that involve less work and can be used by more people. Encrypted Root Filesystem One real benefit of a secure boot system is for systems using encrypted filesystems. It would be good to know that a hostile party hasn t replaced the kernel and initrd when you are asked for the password to unlock the root filesystem. This would be good for the case where a laptop is left in a hotel room or other place where a hostile party could access it. Another way of addressing the same problem is to boot from a USB device so that you can keep a small USB boot device with you when it s inconvenient to carry a large laptop (which works for me). Of course it s theoretically possible for the system BIOS to be replaced with something that trojans the boot process (EG runs the kernel in a virtual machine). But I expect that if someone who is capable of doing that gets access to my laptop then I m going to lose anyway. Conclusion The secure boot concept does seem to have some useful potential when the aim is to reboot the system and have it automatically apply security fixes in the early stages of the boot process. This could be used for Netbooks and phones. Of course such a process would have to reset some configuration settings to safe defaults, this means replacing files in /etc and some configuration files in the user s home directory. So such a reboot and upgrade procedure would either leave the possibility that files in /etc were still compromised or it would remove some configuration work and thus give the user an incentive to avoid applying the patch. Any system that tries to extend signature checks all the way would either be vulnerable to valid but hostile changes to system configuration (such as authenticating to a server run by a hostile party) or have extreme ease of use issues due to signing everything. Also a secure boot will only protect a vulnerable system between the time it is rebooted and the time it returns to full operation after the reboot. If the security flaw hasn t been fixed (which could be due to a 0-day exploit or an exploit for which the patch hasn t been applied) then the system could be cracked again. I don t think that a secure boot process offers real benefits to many users.

• [1] http://ncommander.blogspot.com/2011/11/secure-boot-its-here-and-been-here-for.html
• [2] http://www.coker.com.au/selinux/play.html

Release 0.9.9 of Rcpp is now on CRAN and getting into Debian too. This is mainly a bug fix release: our addition of int64 support in 0.9.8 came at the expense of support for long and unsigned long which broke some packages using Rcpp, and expecting those types. Ooops. The complete NEWS entry for 0.9.9; more details are in the ChangeLog file in the package and on the Rcpp Changelog page.

0.9.9   2012-12-25
    o   Reverting the 'int64' changes from release 0.9.8 which adversely
        affect packages using Rcpp: We will re-apply the 'int64' changes in a 
        way which should cooperate more easily with 'long' and 'unsigned long'.
    o   Unit test output directory fallback changed to use Rcpp.Rcheck
    o   Conditioned two unit tests to not run on Windows where they now break
        whereas they passed before, and continue to pass on other OSs

Thanks to CRANberries, you can also look at a diff to the previous release 0.9.8. As always, even fuller details are on the Rcpp Changelog page and the Rcpp page which also leads to the downloads, the browseable doxygen docs and zip files of doxygen output for the standard formats. A local directory has source and documentation too. Questions, comments etc should go to the rcpp-devel mailing list off the R-Forge page

So, I intended to be completely away from my computer during my vacations, but hey. I have been interested in this new extension Apple added to the C language a little while ago which introduces the equivalent of closures to C. Today I spent a few minutes looking into it and writing a few tests with the help of clang. Here s something I came up with, to use a block as the callback for a GIO asynchronous call:

#include <Block.h>
#include <gio/gio.h>
typedef void (^Block)();
static void async_result_cb(GObject* source,
                            GAsyncResult* res,
                            gpointer data)
 
    Block block = (Block)data;
    block(res);
 
int main(int argc, char** argv)
 
    g_type_init();
    if (argc != 2)  
        g_error("Blah.");
        return 1;
     
    GMainLoop* loop = g_main_loop_new(NULL, TRUE);
    GFile* file = g_file_new_for_path(argv[1]);
    g_file_query_info_async(file,
                            G_FILE_ATTRIBUTE_STANDARD_CONTENT_TYPE,
                            G_FILE_QUERY_INFO_NONE, G_PRIORITY_DEFAULT,
                            NULL, async_result_cb, (gpointer) ^ (GAsyncResult* res)  
        GError* error = NULL;
        GFileInfo* info = g_file_query_info_finish(file, res, &error);
        if (error)  
            g_error("Failed: %s", error->message);
            g_error_free(error);
            return;
         
        g_message("Content Type: %s",
                  g_file_info_get_attribute_string(info, G_FILE_ATTRIBUTE_STANDARD_CONTENT_TYPE));
        g_object_unref(info);
        g_main_loop_quit(loop);
     );
    g_main_loop_run(loop);
    g_object_unref(file);
    return 0;
 

Pretty neat, don t you think? To build you need to use clang and have the blocks runtime installed (libblocksruntime-dev in Debian). Here s the command I use:

$ clang -fblocks -o gio gio.c -lBlocksRuntime  pkg-config --cflags --libs gio-2.0 

Since I got my Kindle a bit more than a year ago, I have finally been able to slake my thirst for reading materials, something that was prohibitively expensive when ordering English language books via Amazon.co.uk, and took lots of time to boot. Here are some of the interesting books I've happened on in the past year: The big one was "Start Small, Stay Small": which has tons of ideas on how to do small, niche startups, "for the rest of us". Those of us who aren't in Silicon Valley, who aren't seeking millions in VC funding, those who don't want to aim for "astronomically rich", but just a comfortable lifestyle with more control over our own destiny. This book gets special mention for being a big inspiration for LiberWriter. Here is a list of the others.

• Thinking, Fast and Slow: http://amzn.to/sXQGSR - probably makes my list because I just finished it, and as he writes, "what you see is all there is" - we're biased towards things that come to mind easily. Actually, it is a pretty good book even looking through all the others I've read.
• 1491: http://amzn.to/uaR0yf - about the Americas prior to the arrival of "Cristoforo Colombo". I have the sequel, 1493 in my reading list, but haven't gotten to it just yet.
• Built to Sell: http://amzn.to/ukmyNP - how to create a business that is something that you can sell because it can exist without you. Not quite so relevant to startups working on a product, but some good concepts nonetheless. A good summary is probably just as good as reading the book, as the core concepts are fairly simple.
• A History of the World in 6 Glasses: http://amzn.to/vF9FgN and An Edible History of the World: http://amzn.to/w1kTg3 - two interesting looks at the history of the world based on what we drink and eat.
• Empires of the Word: A Language History of the World: http://amzn.to/tVvltK the history of the world as seen through languages. It's interesting to read about why some languages lasted so long even though their speakers were conquered, why others swept all before them and disappeared, and so on.
• The Long Divergence: How Islamic Law Held Back the Middle East: http://amzn.to/spQCF7 - a look at how the legal systems of 'the west' and the middle east differed and the results those systems led to. Limited liability companies are an important innovation. The book can be a bit dry and repetitive at times, but the material is very interesting.
• Warlord: http://amzn.to/spjf73 - Winston Churchill's "war years".
• Positioning: http://amzn.to/sSJRnw - a classic about branding.
• The Intelligent Investor: http://amzn.to/tffzgJ and A Random Walk Down Wall Street: http://amzn.to/vXIsTT two classics on investing. I'm more inclined towards the 'random' view of things myself.
• The Great Stagnation: http://amzn.to/vccI3c about "what ails us" as a country. One of the recommendations is that we need to "raise the social status of scientists."
  
• The Party: http://amzn.to/tWX1hA an interesting, and balanced (well, it seemed that way to me, but knowing essentially nothing about the place I could be completely wrong) book on how China is run.

And for fun, a variety of Sci fi and Western books, but nothing particularly noteworthy. Neal Stephenson's REAMDE was fun, but I'm not sure I'd read it more than once, like some of his other books. Here are my Amazon wishlists of things I'm considering reading at some point in the future. Comments welcome on the value of the books listed. "Regular" books: http://amzn.com/w/20I0Y1YGD1FUB and random fun books and movies. Business books: http://amzn.com/w/5B2JQOP8VZEW - although some of them are not strictly business books. Yes, if you're curious, the book links do have referral codes in them, to help sustain my reading habit.

PostgreSQL's libpq5 package got its symbols file somewhere around version 8.4, so the symbols in there were all marked with version "8.4~" or greater. As I'm working on pgapt.debian.net aiming at providing packages for all upstream-supported PG versions (currently 8.3 and up), this made packages incompatible with 8.3's libpq5. There didn't seem to be a ready program to feed a series of .deb files which would then run dpkg-gensymbols and build a symbols file, so I wrote this shell script:

#!/bin/sh
set -eu
[ -d tmp ]   mkdir tmp
i=1
for pkg in "$@" ; do
    echo "$pkg"
    test -e "$pkg"
    name=$(dpkg-deb -I "$pkg"   perl -lne 'print $1 if /^ Package: (.+)/')
    version=$(dpkg-deb -I "$pkg"   perl -lne 'print $1 if /^ Version: (.+)/')
    out=$(printf "tmp/%03d_%s" $i "$version")
    dpkg-deb -x "$pkg" "$out"
    dpkg-gensymbols -P"$out" -p"$name" -v"$version" \
        $ oldsymbols:+-I"$oldsymbols"  -O"$out.symbols"   \
        tee "$out.symbols.diff"
    test -s "$out.symbols.diff"   rm "$out.symbols.diff"
    oldsymbols="$out.symbols"
    rm -rf "$out"
    i=$(expr $i + 1)
done

To use it, do the following:

• debsnap -a i386 libpq5
• ls binary-libpq5/*.deb > files
• edit "files" to have proper ordering (~rc versions before releases, remove bpo versions, etc.)
• ./walk-symbols $(cat files)

The highest-numbered *.symbols file in tmp/ will then have symbol information for all packages. I then did some manual post-processing like s/~rc1-1/~/ to get nice (and backportable) version numbers. Another nice trick (pointed out by jcristau) is to replace the lowest version number of that package (8.2~ here, where libpq changed SONAME) by 0 which will make dpkg-shlibdeps omit the >= version part. (Most packages depending on libpq5 will profit from that.) I'm still pondering whether this script is non-trivial enough add to devscripts. (The people I asked so far only made comments about the mkdir call...)