AddThis:

Categories:

• Debian-Blog
• Technology
• Tools

Keywords:

• laptop-mode-tools

AltOS 1.4 TeleGPS support, features and bug fixes Bdale and I are pleased to announce the release of AltOS version 1.4. AltOS is the core of the software for all of the Altus Metrum products. It consists of firmware for our cc1111, STM32L151, LPC11U14 and ATtiny85 based electronics and Java-based ground station software. This is a major release of AltOS, including support for our new TeleGPS board and a host of new features and bug fixes AltOS Firmware TeleGPS added, new features and fixes Our new tracker, TeleGPS, works quite differently than a flight computer

• Starts tracking and logging at power-on
• Disables RF and logging only when connected to USB
• Doesn t log position when it isn t moving for a long time.

TeleGPS transmits our digital telemetry protocol, APRS and radio direction finding beacons. For TeleMega, we ve made the firing time for the additional pyro channels (A-D) configurable, in case the default (50ms) isn t long enough. AltOS Beeping Changes The three-beep startup tones have been replaced with a report of the current battery voltage. This is nice on all of the board, but particularly useful with EasyMini which doesn t have the benefit of telemetry reporting its state. We also changed the other state tones to Farnsworth spacing. This makes them all faster, and easier to distinguish from the numeric reports of voltage and altitude. Finally, we ve added the ability to change the frequency of the beeper tones. This is nice when you have two Altus Metrum flight computers in the same ebay and want to be able to tell the beeps apart. AltOS Bug Fixes Fixed a bug which prevented you from using TeleMega s extra pyro channel Flight State After configuration value. AltOS 1.3.2 on TeleMetrum v2.0 and TeleMega would reset the flight number to 2 after erasing flights; that s been fixed. AltosUI New Maps, igniter tab and a few fixes With TeleGPS tracks now potentially ranging over a much wider area than a typical rocket flight, the Maps interface has been updated to include zooming and multiple map styles. It also now uses less memory, which should make it work on a wider range of systems. For TeleMega, we ve added an Igniter tab to the flight monitor interface so you can check voltages on the extra pyro channels before pushing the button. We re hoping that the new Maps interface will load and run on machines with limited memory for Java applications; please let us know if this changes anything for you. TeleGPS All new application just for TeleGPS While TeleGPS shares the same telemetry and data logging capabilities as all of the Altus Metrum flight computers, its use as a tracker is expected to be both broader and simpler than the rocketry-specific systems. We ve build a custom TeleGPS application that incorporates the mapping and data visualization aspects of AltosUI, but eliminates all of the rocketry-specific flight state tracking.

This was another good week. This week I focused on cleaning up the merge implementation as well as learning about Debian packaging. As far as cleaning up the implementation, I got a few tests written to test the merge function. Additionally I rewrote the merge command code (the code responsible for the kdb merge command, it depends on the implementation of merge I wrote last week). Now the kdb merge command takes in a parent key for each keyset and creates a keyset containing all the keys under the parent key. It then invokes the KeysetMerge function I wrote on those keysets and saves the returned keyset to the key database. Most of the week I spent learning about Debian packaging. I was able to get some hand-on experience by creating a package for the augeas plugin for Elektra. I modified the control file to include the libaugeas0 dependency and adding in a description of the plugin. Also I created a new libelektra-augeas4.install file to install the share library to the correct location on the system. Then, I tried building the source using git-buildpackage but unfortunately it failed on packaging the plugin because the libelektra-augeas.so file was never built. It turned out that the augeas plugin had to be added to ElektraCache.cmake under plugins_dep (plugins with dependencies) so that the plugin would be built on make. So I fixed that and ran buildpackage again and voila! It worked! I successfully make my first Debian package! The other thing I looked into was how configuration files get updated during a package upgrade under Debian. It turns out, most package define their configurations as conffiles . These conffiles do not get overwritten during package upgrade if the user has edited them. Basically, during an upgrade, dpkg calculates a checksum on each conffile and if it has changed, prompts the user what to do. Instead, the goal of our project is to attempt an automatic merge of the conffile and if successful, used the merge version. If the merge is unsuccessful dpkg will prompt the user as usual. I need to figure out how to change dpkg s behavior during an upgrade with a conffile so I can build a prototype of a package upgrade merging a file. Lastly, this week I looked into adding tab completion to the kdb tool. Currently kdb does not try to complete commands using tab completion in bash. It turns out adding tab completion isn t that difficult. You basically just need to write rules for how tab completion should work for your program and add it to /etc/bash_completion.d/ I wrote a basic tab completion script for kdb that will complete the commands for kdb. It follows here: #Proof of concept bash completion for kdb. You must copy this file to /etc/bash_completion.d/kdb and load it with ". /etc/bash_completion.d/kdb"
_kdb()

local cur prev opts
COMPREPLY=()
cur="$ COMP_WORDS[COMP_CWORD] "
prev="$ COMP_WORDS[COMP_CWORD-1] "
opts="check convert cp export file fstab get getmeta import info ls lsmeta merge mount mv rm set setmeta sget shell test umount vset" if [[ $ cur == * ]] ; then
COMPREPLY=( $(compgen -W "$ opts " -- $ cur ) )
return 0
fi

complete -F _kdb kdb Its just a proof on concept but its a really neat feature and surprisingly easy to implement. One of the other students working on Elektra, Felix, is also working on tab completion. I think we will collaborate and have this feature implemented for kdb very soon. For next week I have a few goals I would like to accomplish. First of all I will have a working prototype of a package being upgraded with automatic conffile merging using kdb merge. Second, I want to continue working on the merge implementation to make it cleaner and work on more sophisticated keysets. I also need to add better error handling to tell if a merge was successful or not, and if not why. Third, I want to work on some of the lintan errors for the deb package of Elektra 0.8.6 and try to get some of those fixed to move closer toward release. Lastly I want to updated the kdb man page for Debian to make it more informative for the shell tool. I was able to get all my goals done for this week except the man page and getting some of the lintian errors fixed up. Overall though it was a very productive week. Until next week,
Ian S. Donnelly

It is unfortunate that some of the client libraries are inefficient, but I'm enjoying my exposure to Amazon's Route53 API. (This is unrelated to the previous post(s) about operating a DNS service..) For an idea of scale I host just over 170 zones at the moment. For the first 25 zones Amazon would charge $0.50 a month, then $0.10 after that. Which would mean:

25  * $0.50  +
150 * $0.10
             = $12.50

That seems reasonably .. reasonable.

A new package pkgKitten is now on CRAN in its infant version 0.1.0. It does only one thing: create R packages that do not suck. Or at least not as much as those created by the (R default) function package.skeleton() which creates files which the very standard, and very recommended, R CMD check then complains about. That is silly. Because each time R CMD check complains, something bad happens to a kitten somewhere. So pkgKitten offers a wrapper function kitten() which creates neat little packages which do not upset R CMD check. A complete little demo is on the pkgKitten webpage which also has pointers to the pkgKitten GitHub repo.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

So, it seems that for a lot of people using unstable, hardware-related permissions (shutdown/reboot, suspend/hibernate, devices mount/umount etc.) have been broken since some times. That's usually the case for people using GNOME with lightdm display manager, Xfce with either gdm or lightdm. It seems that recently, policykit (which is used by GNOME and Xfce) switched from consolekit backend to logind backend (yeah, systemd-logind). So applications using policykit needs to handle that correctly, and that means beeing sure a logind session is correctly setup, which is done by installing the package libpam-systemd. For now, it's still possible to not switch to systemd as init system, by installing the systemd-shim package before libpam-systemd. Be aware that (at least with the current state of affairs), this is only true with logind before 204. When systemd maintainers start transitionning to a later version, only systemd-sysv (so, systemd as init system) will work. For people reluctant to switch to systemd, they can use systemd-shim for now. Then when systemd 205+ enters the archive, either lose those hardware permissions, or try to improve systemd-shim to handle that situation. There's not much we (Xfce/LightDM maintainers) can do about that.

RcppRedis, another new package of mine, appeared on CRAN a few weeks ago just in time for our annual R/Finance conference. And as of today, we also have Windows binaries thanks to generous help from John Buonagurio who help building the required 32- and 64-bit libraries for Windows, and Uwe Ligges who now installed them for the CRAN and win-builder machiness. Binaries for release 0.1.1 should be available within a day. To describe the package, I also just set up a page about RcppRedis so rather than repeating everything here I invite you to follow the link. The ever-so-brief NEWS entry for the two first uploads follows.

Changes in version 0.1.1 (2014-06-09)

• Now with Windows support thanks to the installation of builds of the hiredis library (created by John Buonagurio) at CRAN / win-builder (thanks to Uwe Ligges)
• Added support for new command zcount

Changes in version 0.1.0 (2014-05-10)

• Initial CRAN upload

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

A new minor release 0.11.2 of Rcpp is now on the CRAN network for GNU R, and binaries for Debian have also been uploaded. The release smoothes a few edges on both the Rcpp side itself, as well as on the interaction between Rcpp and R which since release 3.1.0 offers a few new features related to C++11. Kevin added a couple of neat extensions related to vectors, a new ListOf templated list class, as well as a new option to warn on implicit casts. We decided not to make this option the default as it may be too common in some packages. JJ took care of a few buglets related to the wonderful Rcpp Attributes. See the NEWS file section below for details, or the ChangeLog file in the package and on the Rcpp Changelog page. Note that the diffstat reported by CRANberries is very large as Kevin also committed a whitespace cleanup which touched almost all files. As before, we tested this release by building against all CRAN packages which depend upon Rcpp. In fact we did three such runs leading up to the release. Only one package was blacklisted (as I currently don't have CUDA set-up), two had what may be internal errors or tests which were too restrictive, sixteen suffered from missing packages or RGL devices --- but the remaining 202 packages all built and tested cleanly. Detailed results of those tests (and the scripts for it) are in the rcpp-logs repo GitHub. There are a number of other fixes, upgrades and other extensions detailed in NEWS file extract below, in the ChangeLog file in the package and on the Rcpp Changelog page.

Changes in Rcpp version 0.11.2 (2014-06-06

• Changes in Rcpp API:
  • Implicit conversions, e.g. between NumericVector and IntegerVector, will now give warnings if you use #define RCPP_WARN_ON_COERCE before including the Rcpp headers.
  • Templated List containers, ListOf<T>, have been introduced. When subsetting such containers, the return is assumed to be of type T, allowing code such as ListOf<NumericVector> x; NumericVector y = x[0] + x[1] + x[2].
  • In a number of instances, returned results are protected and/or cast more carefully.
• Changes in Rcpp Attributes
  • Trailing line comments are now stripped by the attributes parser. This allows the parser to handle C++ source files containing comments inline with function arguments.
  • The USE_CXX1X environment variable is now defined by the cpp11 plugin when R >= 3.1. Two additional plugins have been added for use with C++0x (eg when using g++ 4.6.* as on Windows) as well as C++1y for compilers beginning to support the next revision of the standard; additional fallback is provided for Windows.
  • compileAttributes() now also considers Imports: which may suppress a warning when running Rcpp.package.skeleton().

Thanks to CRANberries, you can also look at a diff to the previous release. 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

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

According to the Free Software Foundation, the Debian distribution is not a Free System Distribution. While I, as a Debian Developer, disagree with that point of view, it should be obvious that the opinion of an organization that engages in politics (or, at the very least, in political lobbying) and of which I am not a member should not be my concern. However, it has long irked me the wrong way that these claims exist. A few weeks ago, I found the System distribution commitments page on Wikipedia. This does change the situation somewhat; I cannot say that a page explaining an opinion of the FSF is wrong; but if that opinion is copied nearly verbatim to a website which claims neutrality as one of its "Core content policies", then the situation is significantly different. When I originally found that page, it was immediately obvious where the content came from, but there was no reference listed, so I added a "citation needed" tag, the first time I ever did so on Wikipedia. Now, a few weeks later, a reference has been added, and the "citation needed" tag removed. However, as expected, the only reference which has been added is the highly opinionated document on the FSF's website, which is hardly neutral. I've added another tag (this time a "which" tag, asking for more clarification) and added a Talk page listing my concerns with the article. But I can't really explain in Wikipedia why I think the whole premise is wrong; that's what a blog is for. So, here goes. The FSF lists two reasons why they do not endorse Debian:

1. The non-free and contrib repositories
2. An unsubstantiated claim that "the installer in some cases recommends [...] non-free firmware files for the peripherals on the machine."

Let's have a look at them, each in turn.

Non-free and contrib It is true that Debian provides non-free software in separate repositories, and that software in these repositories does not comply with either the Debian Free Software Guidelines (DFSG) or the FSF's Free Software Definition. However, the non-free and contrib repositories are fairly small:

wouter@carillon:/var/lib/apt/lists$ awk -F':' 'BEGIN total=0 /^Size/ total+=$2 END print total ' ftp.be.debian.org_debian_dists_sid_non-free_binary-amd64_Packages
4398812934

That is, the non-free repository contains just over 4G of software (after installation). Contrib is even smaller:

wouter@carillon:/var/lib/apt/lists$ awk -F':' 'BEGIN total=0 /^Size/ total+=$2 END print total ' ftp.be.debian.org_debian_dists_sid_contrib_binary-amd64_Packages 
306578636

While, combined, this is approximately the same size as some other distributions, free and non-free together, it pales in comparison with the "main" repository:

wouter@carillon:/var/lib/apt/lists$ awk -F':' 'BEGIN total=0 /^Size/ total+=$2 END print total ' ftp.be.debian.org_debian_dists_sid_main_binary-amd64_Packages
60025033622

i.e., the "main" repository contains just shy of 60G of software. Of course, whether non-free is large or not should not matter at all; the fact that it exists in the first place is a problem for free software advocates. But of those 4 gigabytes, what exactly is the non-free repository used for? For that, the Debian popularity contest has a page specifically for the non-free section. Looking at this page, and ignoring the packages that are listed as "Not in sid" (which either means they were installed from third-party suppliers and therefore cannot be attributed to Debian, or were only available in older distributions so should not be held against the Debian of today anymore), we see three main uses of non-free:

1. Various implementations of non-free algorithms (unrar, libfaac0, etc)
2. A lot of packages containing non-free firmware
3. A number of packages containing non-free documentation

The first package which does not fit any of those descriptions is iozone3, currently on the 64th position of the popularity contest (including packages "Not in sid"). The first item in this list is something which most free software advocates will try to avoid. After all, for all of those algorithms, alternatives exist, and so there is no real reason why one would want to use such software, other than "someone sent me a file encoded according to that algorithm, and I want to decode it". Debian gives you the option to do so, but a valid case could be made for not doing so. The second item in that list is really an alternate version of "the installer recommends non-free software", so I'll come back on that in the next section. The 3rd item in the above list deserves some special attention. Just over 10 years ago, Debian clarified its position where it clearly specified that documentation and programs (as both are interpreted as "software") should follow the same set of guidelines regarding freedom. The FSF disagrees with this position, and chose to release some of its documentation under the GFDL with invariant sections, which Debian decided is a non-free license in 2006. Since then, such GNU documentation would no longer be available were Debian to ditch the non-free repository.

Recommending non-free firmware As I said above, the FSF's page claims that the Debian installer recommends non-free firmware "in some cases", without going into much detail. Special care should be taken in understanding the word "recommend" here; wiktionary defines it as follows:

recommend (third-person singular simple present recommends, present participle recommending, simple past and past participle recommended)

1. (transitive) To bestow commendation on; to represent favourably; to suggest, endorse or encourage as an appropriate choice.

The board recommends Philips, given his ample experience in similar positions.

1. (transitive) To make acceptable; to attract favor to.
2. (transitive) To advise, propose, counsel favorably

The therapist recommends resting the mind and exercising the body.

1. (transitive, archaic) To commit, confide to another's care, confidence or acceptance, with favoring representations

A medieval oblate's parents recommended the boy for life to God and the monastery

However, according to the FSF, merely showing a firmware filename in unencrypted form counts as a recommendation. I've always found that use of the word "recommendation" to be dubious, at best. Ignoring that part, we can make the following observations: The debian-installer module ("udeb") which is responsible for configuring apt is called apt-mirror-setup (code in the apt-setup git repository). The actual debconf templates which allow the user to enable the non-free or contrib repositories are the apt-setup/non-free and apt-setup/contrib templates, and they look like this:

Template: apt-setup/non-free
Type: boolean
Default: false
# :sl1:
_Description: Use non-free software?
 Some non-free software has been made to work with Debian. Though this
 software is not at all a part of Debian, standard Debian tools can be used
 to install it. This software has varying licenses which may prevent you
 from using, modifying, or sharing it.
 .
 Please choose whether you want to have it available anyway.
Template: apt-setup/contrib
Type: boolean
Default: false
# :sl1:
_Description: Use contrib software?
 Some additional software has been made to work with Debian. Though this
 software is free, it depends on non-free software for its operation. This
 software is not a part of Debian, but standard Debian tools can be
 used to install it.
 .
 Please choose whether you want this software to be made available to you.

Note the lines Default: false, which imply that the default answer to these questions is to disable the non-free and contrib repositories. A question which defaults to false isn't a recommendation, nor do I read the text as any form of recommendation to install these repositories (quite the contrary, in fact). More important than whether the default is to enable or disable these repositories is whether this question is even shown to the user in normal installations. Whether this is the case isn't decided by any template; instead, it is decided by the code that calls the templates. That code currently looks like this:

STATE=1
while true; do
        case "$STATE" in
            1)
                db_input low apt-setup/non-free   true
                ;;
            2)
                # If they chose not to use non-free, ask about
                # contrib, with a default of no. If they chose to
                # use non-free, they get contrib too..
                db_get apt-setup/non-free
                if [ "$RET" = false ]; then
                        db_fget apt-setup/contrib seen
                        if [ "$RET" = false ]; then
                                db_set apt-setup/contrib false
                        fi
                        db_input low apt-setup/contrib   true
                else
                        db_fget apt-setup/contrib seen
                        if [ "$RET" = false ]; then
                                db_set apt-setup/contrib true
                        fi
                fi
                ;;
            *)
                break
                ;;
        esac
        if db_go; then
                STATE=$(($STATE + 1))
        else
                STATE=$(($STATE - 1))
        fi
done

Note the "low" in the db_input lines; it means the question is only shown at low priority, i.e., in "expert" mode. The result is that, unless you enable expert mode, you won't even see the question about the non-free repository, and it will be disabled by default. There won't even be any mention of it in your sources.list file. Of course, the above isn't about firmware files, which is what the FSF website claims. So, there is a second part to this story. If you run a system with hardware for which there is a non-free firmware package in the non-free repository, and you provided firmware for this hardware to the installer through various means, then the hw-detect module comes into play. This has code which currently looks like this:

# install cached firmware debs
if [ -d /var/cache/firmware ]; then
    for deb in /var/cache/firmware/*.deb; do
            if [ -f "$deb" ]; then
                    cp -a "$deb" /target/tmp
                    # TODO debconf passthrough
                    if ! in-target dpkg -i "/tmp/$(basename "$deb")"; then
                            # dpkg failed, force removal of package
                            in-target dpkg --force-depends --remove "$(deb_package "$deb")"   true
                    fi
                    rm -f "/target/tmp/$deb"
                    need_nonfree=1
            fi
    done
fi
if [ "$need_nonfree" ]; then
    db_set apt-setup/non-free true
fi

As can bee seen, if any firmware .deb files exist under /var/cache/firmware in the installer environment, then these will be installed on the target system and default answer to the apt-setup/non-free question will be changed to enable the non-free repository. How do such packages end up there? Well, that's done by the same hw-detect udeb, in a different script. The code there is a bit too long to quote in this already far too long blog post, but it boils down to:

• If the installer detects missing firmware, the user is asked whether (s)he wants to install firmware, with the following template:

  Template: hw-detect/load_firmware
  Type: boolean
  Default: true
  # :sl2:
  _Description: Load missing firmware from removable media?
   Some of your hardware needs non-free firmware files to operate. The
   firmware can be loaded from removable media, such as a USB stick or
   floppy.
   .
   The missing firmware files are: $ FILES 
   .
   If you have such media available now, insert it, and continue.
  

• If the user agreed to doing so (and to me, the above template does not read as a recommendation), any firmware .deb files that are provided to the installer are tested for the missing firmware files.
• If any of those files are found, these .deb files are copied to the /var/cache/firmware directory, and the firmware files are made available to the running kernel.

Conclusion In my opinion, while some of the claims on the FSF website are correct, others are at the very least misleading. Debian does not recommend the use of non-free software; and while providing non-free firmware to the installer isn't too difficult, it isn't documented very well; and as such installing a system with non-free enabled isn't something you can easily do by accident. Debian and the FSF clearly disagree on certain things, and this disagreement, not any policies by the Debian project, is the main reason why the FSF won't encourage Debian as a free distribution. I don't think the Debian project will easily agree to get rid of the non-free repository while the FSF still produces non-free documentation or while non-free firmware is still a fact of life in this world. However, I do think the following should happen:

1. The FSF should relicense its non-free documentation so it becomes truly free.
2. Once that has happened, Debian should rename its non-free repository to a "hardware-support" repository (or something along those lines), and remove everything that does not exist solely for the support of proprietary hardware (i.e., non-free drivers, non-free firmware, etc).
3. The installer could be clearer on the fact that if non-free firmware is found to be in use for the system, the user is using software that cannot be properly supported by the Debian project.

While the above wouldn't necessarily bring the opinions of the FSF and Debian 100% in line, it would at least bring their positions closer to eachother. Unfortunately, however, I doubt that this will happen; and that's a shame, because in the end, both Debian and the FSF want the same thing: a world where Free Software is the norm, not the exception.

Update

• The first version of this text said that providing firmware is not very easy. As was pointed out to me, it isn't too hard, but it's not very well documented and not part of the 'regular' installer images.
• Add contrib too, when we compare non-free and main
• Clarify when GFDL is non-free

ISC has issued an operational notification advising the use of the -fno-delete-null-pointer-checks flag when compiling current versions of BIND with GCC 4.9:

Beginning with GCC 4.9.0, code optimization in GCC now includes (by default) an optimization which is intended to eliminate unnecessary null pointer comparisons in compiled code. Unfortunately this optimization removes checks which are necessary in BIND and the demonstrated effect is to cause unpredictable assertion failures during execution of named, resulting in termination of the server process. Future versions of BIND will be modified so that the optimizer does not incorrectly remove necessary checks when building from source, and until those versions are available multiple immediate workarounds are available.

According to the GCC documentation, -fdelete-null-pointer-checks performs the following optimization, and is enabled by default even when compiling with -O0:

Assume that programs cannot safely dereference null pointers, and that no code or data element resides there. This enables simple constant folding optimizations at all optimization levels. In addition, other optimization passes in GCC use this flag to control global dataflow analyses that eliminate useless checks for null pointers; these assume that if a pointer is checked after it has already been dereferenced, it cannot be null.

This optimization dates back to 1999 but it recently became more aggressive in the GCC 4.9 release:

GCC might now optimize away the null pointer check in code like:

int copy (int* dest, int* src, size_t nbytes)  
  memmove (dest, src, nbytes);
  if (src != NULL)
    return *src;
  return 0;
 

The pointers passed to memmove (and similar functions in <string.h>) must be non-null even when nbytes==0, so GCC can use that information to remove the check after the memmove call. Calling copy(p, NULL, 0) can therefore deference a null pointer and crash. The example above needs to be fixed to avoid the invalid memmove call, for example:

if (nbytes != 0)
  memmove (dest, src, nbytes);

It's interesting that the ISC operational advisory labels this an "incorrect" optimization. I wonder if this is a similar case to the Glibc optimization which exposed incorrect usage of memcpy() in many applications, including BIND. Fortunately, few users should be affected by this bug, since GCC 4.9 is fairly new. (The upcoming Fedora 21 release will probably be the first mainstream distribution to ship with GCC 4.9 as the default compiler.) Update: Debian bug #750760 filed.

My last update about ongoing development of botch, the bootstrap/build ordering tool chain, was four months ago and about several incremental updates. This post will be of similar nature. The most interesting news is probably the additional data that bootstrap.debian.net now provides. This is listed in the next section. All subsequent sections then list the changes under the hood that made the additions to bootstrap.debian.net possible.

bootstrap.debian.net The bootstrap.debian.net service used to have botch as a git submodule but now runs botch from its Debian package. This at least proves that the botch Debian package is mature enough to do useful stuff with it. In addition to the bootstrapping results by architecture, bootstrap.debian.net now also hosts the following additional services:

• History of graph size shows how the dependency graph developed over time for a normal self-contained repository plus for both minimizing strategies, updated every five days
• Crossbuild dependency satisfaction gives an overview of reasons why the crossbuild dependency situation cannot yet be analyzed with bug numbers where applicable
• Crossbuild order modifies the metadata of a repository so that the crossbuild dependency situation can be analyzed and then outputs an overview page as it is done for every architecture on the main page
• Source package importance calculates the port metric for source packages on a daily basis

Further improvements concern how dependency cycles are now presented in the html overviews. While before, vertices in a cycle where separated by commas as if they were simple package lists, vertices are now connected by unicode arrows. Dashed arrows indicate build dependencies while solid arrows indicate builds-from relationships. For what it's worth, installation set vertices now contain their installation set in their title attribute.

Debian package Botch has long depended on features of an unreleased version of dose3 which in turn depended on an unrelease version of libcudf. Both projects have recently made new releases so that I was now able to drop the dose3 git submodule and rely on the host system's dose3 version instead. This also made it possible to create a Debian package of botch which currently sits at Debian mentors. Writing the package also finally made me create a usable install target in the Makefile as well as adding stubs for the manpages of the 44 applications that botch currently ships. The actual content of these manpages still has to be written. The only documentation botch currently ships in the botch-doc package is an offline version of the wiki on gitorious. The new page ExamplesGraphs even includes pictures.

Cross By default, botch analyzes the native bootstrapping phase. That is, assume that the initial set of Essential:yes and build-essential packages magically exists and find out how to bootstrap the rest from there through native compilation. But part of the bootstrapping problem is also to create the set of Essential:yes and build-essential packages from nothing via cross compilation. Botch is unable to analyze the cross phase because too many packages cannot satisfy their crossbuild dependencies due to multiarch conflicts. This problem is only about the dependency metadata and not about whether a given source package actually crosscompiles fine in practice. Helmut Grohne has done great work with rebootstrap which is regularly run by jenkins.debian.net. He convinced me that we need an overview of what packages are blocking the analysis of the cross case and that it was useful to have a crossbuild order even if that was a fake order just to have a rough overview of the current situation in Debian Sid. I wrote a couple of scripts which would run dose-builddebcheck on a repository, analyze which packages fail to satisfy their crossbuild dependencies and why, fix those cases by adjusting package metadata accordingly and repeat until all relevant source packages satisfy their crossbuild dependencies. The result of this can then be used to identify the packages that need to be modified as well as to generate a crossbuild order. The fixes to the metadata are done in an automatic fashion and do not necessarily reflect the real fix that would solve the problem. Nevertheless, I ended up agreeing that it is better to have a slightly wrong overview than no overview at all.

Minimizing the dependency graph size Installation sets in the dependency graph are calculated independent from each other. If two binary packages provide A, then dependencies on A in different installation sets might choose different binary packages as providers of A. The same holds for disjunctive dependencies. If a package depends on A C and another package depends on C A then there is no coordination to choose C so to minimize the overall amount of vertices in the graph. I implemented two methods to minimize the impact of cases where the dependency solver has multiple options to satisfy a dependency through Provides and dependency disjunctions. The first method is inspired by Helmut Grohne. An algorithm goes through all disjunctive binary dependencies and removes all virtual packages, leaving only real packages. Of the remaining real packages, the first one is selected. For build dependencies, the algorithm drops all but the first package in every disjunction. This is also what sbuild does. Unfortunately this solution produces an unsatisfiable dependency situation in most cases. This is because oftentimes it is necessary to select the virtual disjunctive dependency because of a conflict relationship introduced by another package. The second method involves aspcud, a cudf solver which can optimize a solution by a criteria. This solution is based on an idea by Pietro Abate who implemented the basis for this idea back in 2012. In contrast to a usual cudf problem, binary packages now also depend on the source packages they build from. If we now ask aspcud to find an installation set for one of the base source packages (I chose src:build-essential) then it will return an installation set that includes source packages. As an optimization criteria the number of source packages in the installation set is minimized. This solution would be flawless if there were no conflicts between binary packages. Due to conflicts not all binary packages that must be coinstallable for this strategy to work can be coinstalled. The quick and dirty solution is to remove all conflicts before passing the cudf universe to aspcud. But this also means that the solution does sometimes not work in practice.

Test cases Botch now finally has a test target in its Makefile. The test target tests two code paths of the native.sh script and the cross.sh script. Running these two scripts covers testing most parts of botch. Given that I did lots of refactoring in the past weeks, the test cases greatly helped to assure that I didnt break anything in the process. I also added autopkgtests to the Debian packaging which test the same things as the test target but naturally run the installed version of botch instead. The autopkgtests were a great help in weeding out some lasts bugs which made botch depend on being executed from its source directory.

Python 3 Reading the suggestions in the Debian python policy I evaluated the possibility to use Python 3 for the Python scripts in botch. While I was at it I added transparent decompression for gzip, bz2 and xz based on the file magic, replaced python-apt with python-debian because of bug#748922 and added argparse argument parsing to all scripts. Unfortunately I had to find out that Python 3 support does not yet seem to be possible for botch for the following reasons:

• no soap module for Python 3 in Debian (needed for bts access)
• hash randomization is turned on by default in Python 3 and therefore the graph output of networkx is not deterministic anymore (bug#749710)

Thus I settled for changing the code such that it would be compatible with Python 2 as well as with Python 3. Because of the changed string handling and sys.stdout properties in Python 3 this proved to be tricky. On the other hand this showed me bugs in my code where I was wrongly relying on deterministic dictionary key traversal.

A new minor / bug fix release 4.300.8 of Armadillo, the templated C++ library for linear algebra, was tagged by Conrad in his SVN repo a few days ago, following earlier snapshots in the 4.300.* series. We had prepared two earlier releases for GitHub but not CRAN in order to accomodate the CRAN maintainer's desire of "a release every one to two months" expressed in the CRAN Repo Policy. However, two actual bugs in the interaction between MinGW and C++11 were reported on the rcpp-devel mailing list, and this releases addresses these. Hence time for new release 0.4.300.8.0 of RcppArmadillo which is now on CRAN and in Debian. This release brings a few upstream changes detailed below such as nice new upstream changes such as more robust norm() (and related) functions, and fixes related to matrix and cube interactions. From our end, we added a better detection of Windows via both _WIN32 and WIN32 (as the former apparently gets undefined by MinGW in C++11 mode). We also added the ability to turn on C++11 support from R (possible since R 3.1.0) yet also turn it off for Armadillo. This is needed as the prescribed compiler on Windows is g++ 4.6.2 -- which offers a subset of C++11 which is good enough for a number of things from the C++11 standard, but not advanced enough for everything which Armadillo uses when C++11 support is turned on. As Armadillo continues to offer a choice of C++ standards, we can use the ability to deploy C++11 only outside of its internals. It is worth repeating that this issue should only affect Windows users wishing to use C++11; other platforms are fine as they generally have more modern compilers.

Changes in RcppArmadillo version 0.4.300.8.0 (2014-05-31)

• Upgraded to Armadillo release Version 4.300.8 (Medieval Cornea Scraper)
  • More robust norm-related functions
  • Fixes between interactions between cube and vector types.
• Adds a #define ARMA_DONT_USE_CXX11 to provide an option to turn C++11 off for Armadillo (but client packages may still use it)
• More robust Windows detection by using _WIN32 as well as WIN32 as the latter gets diabled by MinGW with C++11
• On Windows, C++11 can be turned off as the Armadillo code base uses more features of C++11 than g++ 4.6.2 version in Rtools implements

Changes in RcppArmadillo version 0.4.300.5.0 (2014-05-19)

• Upgraded to Armadillo release Version 4.300.5 (Medieval Cornea Scraper)
  • Handle possible underflows and overflows in norm(), normalise(), norm_dot()
  • Fix for handling of null vectors by norm_dot()

Changes in RcppArmadillo version 0.4.300.2.0 (2014-05-13)

• Upgraded to Armadillo release Version 4.300.2 (Medieval Cornea Scraper)
  • faster find()

Courtesy of CRANberries, there is also a diffstat report for the most recent release As always, more detailed information is on the RcppArmadillo page. Questions, comments etc should go to the rcpp-devel mailing list off the R-Forge page.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

Perfection We like perfection. Perfection is the ultimate achievement, there is nothing beyond. Perfection is fully understood. It is not going to change, it is fact, we can rely upon it. Perfection is final. Perfection is death. Ideas can be perfect, and perfect ideas are easy to understand. Perfect ideas are final and unchangeable. Perfect ideas are hard to correct, hard to refute. Perfect ideas spread easily. They are helpful. They shed light on a little corner of our world, give it shape. They bring stability. They can be relied upon. Perfect ideas make good memes. Perfect ideas are shared standards through which we act, interact, coordinate, cooperate. They don't change, so they are a solid base for habits, that make a bit of our life a little easier. That we should not kill, is a perfect idea. So is racism. So are the ten commandments, so, for many, is love. Thanks Lynoure for saying the right thing at the right time.

In recent years Android devices have been the most expensive things I ve purchased apart from airline tickets and other travel/holiday expenses. As they are expensive I d like to use them for as long as possible to get the most value for money. Also as I give my devices to relatives when they no longer work for me I d like to avoid having relatives hassling me about their phone not working as desired. So I ve been thinking about the features that I need to make it possible to use a phone or tablet for a long time. RAM The way Android works is that when an application in the foreground requests more memory background applications may be closed to free some memory. Android doesn t use swap by default, there is some documentation on how to enable it (and it s not difficult to figure out for anyone who has used Linux before) but generally it s not done. If you run a larger application the chances of apps closing in the background (causing delays when you switch back to them and possibly a loss of context if the app is buggy and doesn t preserve all state) are increased. As a general trend apps tend to get bigger to provide more features and also because users who own newer bigger devices don t complain as much about memory use. Also to make things worse new versions of Android tend to use more RAM. So a phone that runs well can suddenly start performing badly when you upgrade to a new version of Android (which incidentally usually can t be reversed) and upgrade to new versions of apps (which can t be reversed through the Google Play Store). The Sony Ericsson Xperia X10 was a very nice phone when it was released, it ran Android 2.1 very quickly. When I upgraded the Xperia X10s that my wife and I used to Android 2.3 (which was necessary to have the phone run as a Wifi access point) performance dropped considerably. The Android upgrade combined with newer larger apps means that those phones are barely usable now. 384M of RAM was plenty in early 2011 when I first used the Xperia X10 but it s not nearly enough now. Recently 2G of RAM has been the minimum for a mid-range or high-end phone. It seems difficult to imagine a new Android feature as compelling as the addition of Wifi access point support in Android 2.3 that would drive an upgrade to a future memory hogging version of the OS. It also seems difficult to imagine Android apps needing enough memory to destroy the performance of a phone with 2G of RAM. But then I couldn t imagine the 384M in an Xperia X10 becoming inadequate or the 512M in a Samsung Galaxy S becoming barely usable either. Storage Until fairly recently storage in an Android device was divided into USB attached storage (a VFAT filesystem that could be directly mounted on a PC) and a Linux filesystem that was used for all internal operations of the phone. On such devices it typically wasn t possible to change partition sizes without a lot more skill than most users possess and most of the storage space was reserved for USB attachment. If you only had a few Android apps and lots of photos, movies, etc then this worked well. But if you wanted to install larger Android apps then you would have big problems. Even with Android 4.x devices (which all seem to have a single filesystem) you can easily run out of space. Modern games often take several hundred megs of storage. Games that take 500M+ for the Android package install (which also requires the same amount of temporary space for installation and upgrade) are common. Sometimes games download data files after they have been installed for a total size approaching 2G (such as The Sims Freeplay). When I bought a Nexus 4 for my wife I got the version with 8G of storage because paying an extra $50 for the 16G version seemed unreasonable. 8G was fine for my wife, but when she got a new phone I gave the Nexus 4 to a relative who wanted to play The Sims and other big games. That relative isn t so happy about having a limited number of games on their phone and I have to fix it when storage space runs out and things start aborting (when storage runs out the Google App Store program aborts and uses lots of space for temporary files). I recently bought a tablet with 32G of storage and filled 16G on the first day (tablets are good for watching
TV and TV shows are big). Fortunately the tablet in question has a SD socket so that when space becomes a problem in a year or two I can buy an SD card and keep using it. An unfortunate recent decision by Google was to prevent apps from being run from a SD card. So even if you have a device with a SD socket you still need to have enough internal storage for all apps and their private data. At 500M+ for a modern game that means a device with 8G of storage (which includes space for the OS) will be lucky to get 8 games installed. If you want to use a phone to it s full capacity (playing various media files, games, etc) then it seems that the minimum storage capacity would be 8G of internal storage and a SD socket. For a device without an SD socket (such as the Nexus 5 with 16G or 32G of storage) your future use will be limited. 32G is probably enough for a phone given that you can recode movies to use less space (the FullHD screen on the Nexus 5 is nice but 720p movies will probably look good enough). But the larger screens of tablets demand better video quality so the Nexus tablets are probably a bad choice due to lack of storage space. Screen Size and Resolution I have previously written about the sizes of devices and how they may be used by people of various ages [1]. That should be of use for anyone who plans to use their old phone as an educational device for their children (which appears to be very common). But apart from that I can t think of any reason why size would suddenly make an old phone obsolete. Only young children will have their hands change size in any significant way. Resolution also shouldn t be a huge problem, the 480*854 screen on the Xperia X10 is fairly good for a 4 screen. While a higher resolution makes text more readable at a small size for most users the availability of a higher resolution screen isn t going to make their old phone obsolete. CPU The only Android devices I owned that appeared to develop CPU speed issues late in life were the Xperia X10 phones, and that might be more due to RAM limits and the OS upgrade. All the other devices were either obviously slow at purchase time or are still performing well now. CPU speed may make it difficult or impossible to play new games, but shouldn t affect other uses of a phone or tablet. Conclusion It seems to me that if you want to use an Android device for more than 2 years then storage capacity should be a major factor in choosing which device to purchase. It seems that lack of storage space is in many cases the main factor that makes older devices annoying or impossible to use.

• [1] http://etbe.coker.com.au/2013/02/11/phone-tablet-sizes/

A new package of mine appeared on CRAN today: RPushbullet. A few days ago, I had tweeted about a first version available via its GitHub repo. The package is now on CRAN which will make it easier to install for many. You still need an API key (free, after registration at Pushbullet) and one or more target devices to message to: an modern smartphone (Android, iPhone, ...) or a Chrome browser provided you also installed the corresponding app. I also set up a short web page on my server with some more information and an example. So pushbullet away...

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

If you follow my blog closely, you noticed that I skipped all my usual monthly summaries in 2014. It s not that I stopped doing free software work, instead I was just too busy to be able to report about what I did. As an excuse, let me tell you that we just moved into a new house which was in construction since may last year. The lack of visible activity on my blog resulted in a steady decrease of the amount of donations received (January: 70.72 , February: 71.75 , March: 51.25 , April: 39.9 , May: 40.33 ). Special thanks to all the people who kept supporting my work even though I stopped reporting about it. So let s fix this. This report will be a bit less detailed since it covers the whole period since the start of the year. Debian France Preparations related to general assemblies. The year started with lots of work related to Debian France. First I took care of setting up limesurvey with Alexandre Delano to handle the vote to pick our new logo:
I also helped Sylvestre Ledru to finalize and close the accounting books for 2013 in preparation for the general assembly that was due later in the month. I wrote the moral report of the president to be presented to the assembly. And last step, I collected vote mandates to ensure that we were going to meet the quorum for the extraordinary assembly that was planned just after the usual yearly assembly. The assemblies took place during a two days mini-debconf in Paris (January 17-18) where I was obviously present even though I gave no talk besides announcing the logo contest winner and thanking people for their participation. It s worth noting that the extraordinary assembly was meant primarily to enshrine in our bylaws the possibility to act as a trusted organization for Debian. This status should be officialized by the Debian project leader (Lucas Nussbaum) in the upcoming weeks since we answered satisfactorily to all questions. Our paypal donation form and the accounting tools behind it are ready. Galette packaging and members map. I managed to hand over the package maintenance of galette to Fran ois-R gis Vuillemin. I sponsored all his uploads and we packaged a new plugin that allows to create a map with all the members who accept to share their location. The idea was to let people meet each other when they don t live far away with the long term goal to have Debian France organized activities not only in Paris but everywhere in France. New contributor game. Last but not least, I organized a game to encourage people to do their first contribution to Debian by offering them a copy of my book if they managed to complete a small Debian project. We got many interesting projects but the result so far seem to be very mixed. Many people did not complete their project (yet) that said for the few that did substantial work, it was rather good and they seem to be interested to continue to contribute. Debian France booth at Solutions Linux in Paris. Like each year, I spent two days in Paris to help man the Debian France booth at Solutions Linux. We had lots of goodies on sale and we made more than 2000 EUR in earnings during the two days. I also used this opportunity to try to convince companies to support the new Debian LTS effort. The Debian Administrator s Handbook In the last days of 2013, we released the wheezy update of the book. Then I quickly organized everything needed so that the various translation teams can now focus their efforts on the latest release of the book. Later (in February) I announced the availability of the French and Spanish translations. Debian Squeeze LTS When the security team called for help to try to put in place long term support for Squeeze, I replied positively because I m convinced that it s very important if Debian wants to stay an acceptable choice in big deployments and because I knew that some of my customers would be interested Thus I followed all the discussions (on a semi-private list first and then on debian-lts@lists.debian.org) and contributed my own experience. I have also taken up the responsibility to coordinate with the Debian contributors who can be hired to work on Squeeze LTS so that we have a clear common offer for all the companies who have offered financial support towards Squeeze LTS. Expect further news on this front in the upcoming days/weeks. Tryton I have been a long time user of SQL-Ledger to manage the accounting of my company Freexian. But while the license is free software, the project is not. It s the work of a single developer who doesn t really accept help. I have thus been considering to move to something else for a long time but never did anything. This year, after some rough evaluation, I decided to switch to Tryton for my company. It s probably not a wise choice from a business perspective because that migration took me many hours of unpaid labor but from a free software perspective it s definitely better than everything else I saw. I contributed a lot of bug reports and a few patches already (#3596, #3631, #3633, #3665, #3667, #3694, #3695, #3696, #3697) mainly about problems found in the French chart of accounts but also about missing features for my use case. I also accepted to sponsor Matthias Berhle, who is maintaining the official Debian packages of Tryton. He s already a Debian maintainer so it s mainly a matter of reviewing new source packages and granting him the required rights. Misc Debian work

• Updated publican to version 4 and then 4.1.2. Required a new perl module that I requested to the Perl team in
  #736816.
• Updated to python-django-debug-toolbar and python-django-jsonfield for Django 1.6 compatibility.
• Filed bugs on packages depending against linux-image that got dropped (on request of Ben Hutchings)
• Filed #734866 and #734869 against bash/dash to request that they properly drop privileges in setuid context.
• Updated gnome-shell-timer.
• Created Services pages on the wiki for the PTS and its replacement.
• Worked on distro-tracker together with the participants of the new contributor game.
• Orphaned feed2omb with #742601.
• Tried in vain to fight against silliness of Debian specific changes in syslinux (see #742836).
• Preliminary EFI support in live-build (see #731709).
• Updated python-django to 1.6.5 in unstable, 1.4.5+deb7u7 in wheezy-security and 1.6.5-1~bpo70+1 to wheezy-backports.
• Sponsored dolibarr, python-suds, a zim backport, a ckeditor NMU to fix an RC bug, libapache2-mod-form, ledgersmb.
• Filed bugs on the fly: #749332 (new upstream release of libjs-jquery-cookie), #749498 (problem with Files-Excluded and https URL for copyright-format 1.0), #747354 (bug in clamav-milter init script), #747101 (git-import-orig should offer a download option).
• Filed tickets on mirrorbrain to make it work better with Debian mirrors: update to #26 (avoid error 404 on files still available on some mirrors) and #150 (auto-disable outdated mirrors).

Thanks See you next month for a new summary of my activities.

2 comments Liked this article? Click here. My blog is Flattr-enabled.

Work on the ROS/Blender robotics control pipeline has culminated in the integration of the system with the tiny robotic Einstein head that had been living at Polytechnic University under the watchful eye of the OpenCog group. Back at Hanson Robotics, tiny Einstein was mercilessly ripped apart and his head attached to an absurdly long robot snake neck apparatus that mimics the configuration of the upcoming Dmitroid robot system. Once suitably mutated, tiny Einstein was able to make a few statements and even sing a couple of tunes.

Review: Debt, by David Graeber

Publisher:	Melville House
Copyright:	2011, 2012
Printing:	October 2012
ISBN:	1-61219-129-0
Format:	Trade paperback
Pages:	453

You probably remember this story from introductory economics. Originally, people exchanged things through barter. I needed grain but had a cow. You had a farm but needed milk. I gave you milk for your grain. But this was tedious and awkward, and required finding the right combination of people who needed something the other person had on hand. Then, people invented money: small objects with an agreed-upon value that you could keep and use later when you needed something else. In other words, both a medium of exchange and a store of value. And that improved matters for a long time, although war-torn societies or societies that collapsed (the supposed "Dark Ages" often raises its head) would sometimes "revert to barter" for some period of time until things were stable enough for currency to reappear. Following that story was usually some story about the emergence of money based on credit: goldsmith shops that started a side business in storing other people's coins and giving them receipts, leading to the receipts trading like the coins since the shops were trustworthy, and from there into the Bank of England and eventually the fractional reserve banking system, fiat money, and all the modern machinery of finance. All of this was dated from the early Enlightenment and the development of modern finance in Europe. It's a very neat story, and it makes a great deal of intuitive sense. That barter system does feel like what you'd have to do without money, but one can immediately see how obnoxious and limiting it would be. These stories play into our intuitive sense of history: people started with emergent properties of the physical world (different people have different goods and different skills and want to exchange them) and then develop layers of abstraction on top of them, eventually leading to the sophistication of modern societies. However, David Graeber is not an economist. He's an anthropologist: the profession devoted to understanding how people actually do things rather than how we've reconstructed our history based on our modern perspective. And, as he points out, engagingly and comprehensively, in chapter two of Debt, there is no evidence that this story about economic history has anything whatsoever to do with reality. And quite a bit of evidence that it does not. As best as we've been able to determine, not only is there no society in the world that deals with routine, day-to-day needs like grain and milk through barter, there never has been such a society in human history. Instead, history and anthropology shows that credit is, in a sense, older than currency: the earliest recorded economic transactions were built on a rich system of credit, but in the form of purchases from shopkeepers on credit, or credit clearinghouses through the local government or temple. Those credit records were often denominated in some standardized commodity so many cattle or bushels of grain that could create the impression that the economy worked on barter. But the anthropological evidence indicates that this was more an accounting technique than a practical currency. People rarely brought the named commodity to the temple to pay off some debt. Rather, there was an agreed conversion from various other goods to that standardized commodity, and its primary purpose was consistent bookkeeping. Specie minted coins appear to come later, and wax and wane throughout history depending on local circumstance. For example, Europe did not "revert to barter" after the collapse of the Roman Empire, but the inhabitants did stop using specie and returned to a system of credit and record-keeping... records that continued to be denominated in Roman currency, even though few people still used the actual coins. That's one fascinating observation with which Graeber begins this book. The other is the question of why we have such a strong social and moral belief that people must pay their debts. This moral belief is ever-present in discussions about the 2008 financial collapse, and more broadly in discussions about the modern economy, but it's not as obvious of a belief as it might appear on the surface. After all, the banking and investment system is founded on the principle that not everyone will repay their debts, and therefore lenders receive a risk premium based on the likelihood that the debt won't be repaid. But, despite building the possibility of non-repayment into the system, debt forgiveness or intentional default is almost unthinkable and considered a huge moral problem. To this, Graeber brings the perspective of historical anthropology: human societies have struggled with the problems of debt and repayment from the beginning of recorded history, and have attempted a wide variety of solutions to those problems, including massive debt forgiveness. The jubilee described in the Bible was not novel; rather, it reflected a common practice to keep abuses of debt under control in ancient Sumer. The subtitle of Debt is The First 5,000 Years, and this book is a historical survey. But Graeber puts off the history to first lay an intellectual groundwork for our understanding of debt, and I found that preliminary discussion extremely valuable. Most memorable was the way Graeber divides human economic relationships into communism (in the old sense, not the political sense), exchange, and hierarchy. Capitalism has consumed our economic analysis to such a degree that exchange is the only economic basis that gets much discussion, but the other two are both obvious and pervasive once Graeber points them out. Human civilization could not exist without all three. And Graeber also points out one aspect of exchange-based economics that had not previously occurred to me: it's the economic relationship that one creates with strangers. Debt has the unique characteristic that it can be discharged, at which point the relationship ceases. This has far more complex and far-reaching moral and social implications than one might initially realize, and Graeber did a wonderful job opening my eyes to some of the subtleties. Debt is clearly a scholarly work, but Graeber's writing is clear and engaging. I found most of this book to be surprisingly easy reading. The hardest going was Graeber's discussion of societies that use a form of currency to arrange relationships between people (marriages, births, and deaths, primarily), but not day-to-day economic transactions. I suspect this area is closer to Graeber's areas of personal research and field work, which resulted in more technical detail. I'm still not sure I completely grasp the principles that Graeber was trying to communicate. But I was struck by the observation of alienation's role in turning a human being into a commodity, and how that links with debt's role as the economic transaction one has with strangers. Graeber covers slavery only glancingly, but makes some memorable points about the use of violence to rip someone out of their social context, and how that is necessary in human cultures before humans can be reduced to a commodity. There's a lot here, and I've only scratched the surface. I haven't mentioned, for example, the fascinatingly elegant theory that coining money and then requiring taxes be paid in the same money is a simple and highly effective way of funding armies, an explanation for specie that is largely unproven but that I find more compelling than the ones I've previously heard. Approaching debt from an anthropological instead of economic perspective is surprisingly enlightening. Debt is primarily a historical and cultural discussion rather than a set of proposed solutions, but Graeber does effectively show that debt as a moral obligation is not an unquestionable moral stance, but rather has a long history as one side of a two-sided political debate. I also came away from this book more conscious of the social implications and costs of debt-structured interactions, and wanting to push more of the language of debt out of my day-to-day dealings. Graeber is well known as one of the supporters of Occupy Wall Street, and Debt, while a well-defended academic work, certainly does advocate a position. But the academic analysis is more prominent than the advocacy, and I found his positions well-defended and well-argued. I do need to give the caveat that I don't have the anthropological background to distinguish the statements from Graeber that are well-established common knowledge in anthropology from the ones that are more controversial, and I would be a bit leery of taking this book as the final word on the topic. But it fully deserves its popularity and reputation as a thought-provoking and valuable contribution to the conversation. It's another book that I want to re-read someday to digest further, and the sort of book whose observations keep occurring to me in subsequent discussions or news stories. If you're at all interested in the way in which we construct the morality around economics and debt, I think this is a book that you should read. It's thoughtful, challenging, and surprising, and it passes my acid test for books of this sort with flying colors: after reading it, you realize that many things are more complicated, more historical, and less novel than you had originally thought. Highly recommended. Rating: 9 out of 10