I have officially published my doctoral thesis Lazy Evaluation: From natural semantics to a machine-checked compiler transformation (DOI: 10.5445/IR/1000054251). The abstract of the 226 page long document that earned me a summa cum laude reads

In order to solve a long-standing problem with list fusion, a new compiler transformation, 'Call Arity' is developed and implemented in the Haskell compiler GHC. It is formally proven to not degrade program performance; the proof is machine-checked using the interactive theorem prover Isabelle. To that end, a formalization of Launchbury s Natural Semantics for Lazy Evaluation is modelled in Isabelle, including a correctness and adequacy proof.

and I assembled all relevant artefacts (the thesis itself, its LaTeX-sources, the Isabelle theories, various patches against GHC, raw benchmark results, errata etc.) at http://www.joachim-breitner.de/thesis/. Other, less retrospective news: My paper on the Incredible Proof Machine got accepted at ITP in Nancy, and I was invited to give a keynote demo about the proof machine at LFMTP in Porto. Exciting!

I ve recently been setting up more monitoring etc to increase the reliability of servers I run. One ongoing issue with computer reliability is any case where a person enters the same data in multiple locations, often people make mistakes and enter slightly different data which can give bad results. For DNS you need to have at least 2 authoritative servers for each zone. I ve written the below Makefile to extract the zone names from the primary server and generate a config file suitable for use on a secondary server. The next step is to automate this further by having the Makefile copy the config file to secondary servers and run rndc reload . Note that in a typical Debian configuration any user in group bind can write to BIND config files and reload the server configuration so this can be done without granting the script on the primary server root access on the secondary servers. My blog replaces the TAB character with 8 spaces, you need to fix this up if you want to run the Makefile on your own system and also replace 10.10.10.10 with the IP address of your primary server. all: other/secondary.conf other/secondary.conf: named.conf.local Makefile
for n in $$(grep ^zone named.conf.local cut -f2 -d\" sort) ; do echo "zone \"$$n\" \n type slave;\n file \"$$n\";\n masters 10.10.10.10; ;\n ;\n" ; done > other/secondary.conf

Yeah, another book finished in Japanese, the third Harry Potter book, Prisoner of Azkaban. Took me quite some time, but thanks to a good Kobo ebook reader and my own enriched dictionary reading is getting more and more fun, even if the book is in Japanese.
I guess I don t have to tell the story of the book, as it is sufficiently well known. Just a good recommendation to students k of Japanese (at a bit higher level) get some books you like and start reading, the sooner the better. And read on an ebook reader with a good dictionary. This way your Japanese will improve quickly. My next book will be , as I think I actually prefer the original (English) Harry Potter, and want to read Japanese authors in Japanese. Now if Murakami would only allow to have Japanese ebooks of his works

A list by Nikki Steele of the 100 best SF and fantasy novels by female authors (in her subjective take), published on BookRiot, has been making the rounds, with people noting which of those they've read. These crop up from time to time, and I've always been tempted to do the work to track the list over time the way that I track award winners. I had some free time this afternoon, so went ahead and set that up (although I badly need to refactor or rewrite a lot of my review posting code). An extra advantage is that I can publish the list as a separate web page so that I don't spam RSS readers with a huge list. The list, annotated with ratings and reviews where I've read the books, is under the reviews section of my web site. As I have time, I may add more lists. I'm also (slowly) working on the project of adding all the nominees for major awards and annotating those, since often the short lists contain a lot of interesting material too. One big caveat for this list: Steele only lists the first book of series, and in many cases the first book isn't very good and is far from the best of the series. So you'll see some anomalous low ratings here for first books that improve later on.

I'm using 256 color configuration in my terminal now but I need more. Colors look different between my emacs in X and inside terminal.

A new release of Rblpapi is now on CRAN. It provides a direct interface between R and the Bloomberg Terminal via the C++ API provided by Bloomberg Labs (but note that a valid Bloomberg license and installation is required). This marks the fifth release since the package first appeared on CRAN last year. Continued thanks to all contributors for code, suggestions or bug reports. This release contains a lot of internal fixes by Whit, John and myself and should prove to be more resilient to 'odd' representations of data coming back. The NEWS.Rd extract has more details:

Changes in Rblpapi version 0.3.4 (2016-05-08)

• On startup, the API versions of both the headers and the runtime are displayed (PR #161 and #165).
• Documentation about extended futures roll notation was added to the bdh manual page.
• Additional examples for overrides where added to bdh (PR #158).
• Internal code changes make retrieval of data in unusual variable types more robust (PRs #157 and #153)
• General improvements and fixes to documentation (PR #156)
• The bdp function now also supports an option verbose (PR #149).
• The internal header Rblpapi_types.h was renamed from a lower-cased variant to conform with Rcpp Attributes best practices (PR #145).

Courtesy of CRANberries, there is also a diffstat report for the this release. As always, more detailed information is on the Rblpapi page. Questions, comments etc should go to the issue tickets system at the 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.

I just submitted another patch series to improve Britney for review. If accepted, they will probably be merged into master within 2 weeks. The changes this time are probably most exciting for people that run/maintain Britney. Key highlights include:

• Britney will be able to use a regular mirror (without partial suites) as data source
  • Previously you would have to decompress and merge the Packages/Sources for each component.
  • Partial suite support is still not added, but I hope to add it eventually. I know it is feature used by at least Ubuntu.
  • This change implies renaming some input files around (Dates, Urgency and BugsV files) as Britney expected these next to the Packages files.
• More machine parsable facts added to excuses.yaml . It will cover almost all excuses currently in use.
• Britney will support two use cases for faux packages natively.
  • I hope to use this to eliminate our need to injecting fake packages into Britney s data source.

I would like to dwell a moment on the faux packages . We have had a helper script generate and inject fake packages into the list of packages (called faux packages ). They generally serve two purposes, which Britney will support:

1. Whitelist of fake packages to satisfy dependencies of other packages.
   • These are generally stand-in for non-free machine configuration packages, where the end-user system would also fetch packages from the vendor s repository.
   • Packages relying on faux packages are generally not in main as Debian s main component is required to be self-contained.
   • These are (still) be called faux packages in/after the patch series
2. Ensuring that certain packages are present and installable in testing.
   • We have a lot of d-i related packages here to avoid accidental breakage of d-i.
   • These are now referred to as a constraint (assuming there is no bike-shedding over the name).

Since Britney will now distinguish between these two use cases, I also make Britney enforce the second use case slightly better. Mind you, it can still be overruled by force-hints and BREAK_ARCHES, so there still enough rope to hang yourself. The other exciting part of this patch set (for me, at least) is that Britney will hopefully become simpler to deploy. No doubt there are still some missing features and paper cuts left, but I suspect we are not far from a:

1. Fill out a template config file pointing Britney to your mirror
2. Run britney -c britney.conf
3. Make your archive kit update your target suite based on Britney s output.
4. Put step 2+3 in crontab/jenkins/task scheduler of choice
5. Profit

There will certainly be some features that requires extra steps. An example is the anti rc-bugs regression feature, which requires you to feed Britney with the list of RC bugs for your source and target suite. But even without, Britney would still protect your target suite from most installability issues.
Filed under: Debian, Release-Team

Petter and Elena both talk enthusiastically about the Pyra. I am currently waiting for the shipment of my C.H.I.P. kit I pre-ordered my kit when it was still in kickstarter phase, and got the PocketC.H.I.P. level. It is clearly not the same nor equivalent to the Pyra The PocketC.H.I.P. is a convenient packaging for what is chiefly an System-on-a-chip; the C.H.I.P. is a small system by today's standards (single-core ARM, 512MB RAM, not meant to be expanded), but still it looks quite usable as a very portable and usable Unix system. Oh, and of course It's also Debian by default. I got quite interested in what the Pyra was like. However, the pricing does not make much sense to me. OK, the Pyra is quite a bigger machine, but... While the PocketC.H.I.P. costs officially US$70 (and before June, according to the site, US$50), the Pyra starts at 500 (plus taxes)... It is just too much! Anyway, I hope to have mine in time to go to DebConf. I also hope Petter and/or Elena can make it this year. And I hope we can compare the systems. I guess the Pyra will sit closer to a regular laptop... But anyway, my two last laptops have been at the bottom of the price scale (both from the Acer Aspire One line). I bought both for around US$300, used the first one as my main laptop for over five years, and have been three with the current one, completely happy.

Good news. The Debian Continuous Integration system is just awesome.

If a developer of a package prepares and declares tests for a given package, this CI system will trigger these test from time to time.
These tests are intended to check packages 'as installed', i.e, test what the end user is going to use in a final system.

The CI system is being improved, and now it supports 2 architectures: amd64 and arm64. Also, it now implements LXC as a backend, so the level of isolation available to run tests is very good, allowing us developers to launch even more elaborated tests.

This is the case of the HA stack (pacemaker, corosync, crmsh...), and the good news is that Debian is now continuously testing these packages.

At the time of this blog post, these are the tests:

• corosync: start the system service (the daemon) with the default Debian configuration
• pacemaker: start the system services (corosync and pacemaker daemons) with the default Debian configuration.
• crmsh: start the system services (corosync, pacemaker) and then add a basic resource (a virtual IP address) and do some tests (start the resource, stop, delete...)

We love to go exploring as a family. Last year, we gave Jacob and Oliver a theme: find places older than Grandpa. They got creative really quick, realizing that any state park counts ( dirt is older than grandpa! ) as did pretty much any museum. Probably our hit from last year was the visit to the tunnels under Ellinwood, KS. Beatrice, NE This year, our theme is places we can fly to . A couple of weeks ago, Laura had a conference in the beautiful small town of Beatrice, NE. So all four of us flew up, and Jacob, Oliver, and I found fun activities while Laura was at her conference. We walked around Beatrice a bit, and I noticed this rails-to-trails area. Jacob and Oliver were immediately interested (since it was railroad-related). They quickly turned it into a game of kick-the-dandelion, trying to kick dandelions off their stems and see how high in the air they could get them. The answer: pretty high. Of course, you can t go wrong with swimming. Here s Oliver getting ready for some swimming. Right near Beatrice is the Homestead National Monument. Of course, the bales decorated like a minion got their attention. Like the other national parks, this one has a junior ranger program. You complete a few things in an activity book and take a pledge to protect the park, and then you get a badge and some stickers. Here s Oliver proudly taking his pledge, holding the new raccoon he bought in their gift shop. Canyon, TX Laura and I have been to Canyon, TX, twice the first was for our honeymoon. Yes, we did get some strange looks when we told people we were going to Amarillo for our honeymoon. But it was absolutely perfect for us. We both enjoy the simple gifts of nature. We kept thinking we ve got to take the boys here . So this weekend, we did. We flew a Cessna out there. Almost every little general aviation airport seems to have a bowl of candy, a plate of cookies, or some such thing for people that are flying through. I often let Jacob and Oliver choose ONE item. They hit the jackpot when we stopped at West Woodward, Oklahoma for fuel and a break. Two whole fridges stocked with stuff: cans of pop in one, and all sorts of snacks in the other. In typical GA fashion, there was a jar in the fridge asking for $1 if you took something. And it clearly hadn t been emptied in awhile. They also had a nice lounge and a patio. Perfect for munching while watching the activities on the ramp. After landing at the beautiful little Tradewind Airport in Amarillo, we ate dinner at Feldman s Wrong-Way Diner in Canyon, TX. Oh my, was that ever popular with the boys. The eagerly looked around to find anything that was wrong a plane hanging upside down from the ceiling, a direction sign saying Tattoine 30 parsecs , movie posters hung upside down, whatever it might be. The fact that model trains were whirring past overhead certainly didn t hurt either. They had a giant bin of crayons by the entrance. Jacob and Oliver each grabbed a fistful, and decided it would be fun to do some math problems while we wait. Oliver particularly got into that, and was quite accurate on his large addition problems. Impressive for a first-grader! Of course, the big highlight of the area is Palo Duro Canyon. Jacob and Oliver were so eager to explore the canyon that they were just about bubbling over with excitement the night before. They decided that we should explore one of the most difficult trails in the canyon one that would take us from the bottom of the canyon all the way to the top and back, about 2.5 miles each way. And they LOVED it. We d stop every few minutes to climb on some rocks, smash up some pieces of sandstone, munch on a snack, or even watch a lizard scurry past. At the trading post in the canyon, both boys explored the gift shop. Jacob happily purchased a Texas magnet and Palo Duro Canyon keychain, which he carried around the rest of the weekend. Oliver loves stuffed animals, and he bought a cuddly little (but long) snake. When we got back to the hotel, he tied a couple of knots in it, and it became snake airlines . Here is the snake airline taking off. He named it Rattletail the friendly snake , which I thought was a pretty nifty name. The hotel s waffle maker made Texas-shaped waffles, clearly a hit! Saturday, we explored the absolutely massive Panhandle-Plains Historical Museum. (How does something that huge wind up in Canyon, TX?) Both boys enjoyed spending hours there. Here s Oliver in Pioneer Town (an indoor recreation of a 1900s town) sending a telegraph message. Oliver wanted to help with the plane. He helped me tie it down in Amarillo, helped check it over during preflight, basically got involved in every part of it. Jacob studied aviation maps (sectionals) with me, planning our flight, figuring out how fast we d go. I loaded Avare (an Android app) on an old tablet for him, so he had aviation maps in the cockpit just like me. He would be telling us how fast we were going every so often, pointing out landmarks, etc. When it was time to head back home, both boys wanted to stay longer a sure sign of a good trip. They wanted to hike another trail in the canyon, go back to the museum, and eat at Feldman s 18 more times. (We got there twice, which was plenty for Laura and me!) On our drive home, Oliver said, Dad-o, will you teach me to be a pilot? You should be my flight instructor. Then I could fly everywhere with you. Now that just makes a dad s day.

This is the first blog post among series of posts which I will be writing throughout the summer about Google Summer of Code 2016 under Debian Reproducible Builds Experience. Introduction: I am Satyam Zode I am a final year Computer Science student (Satyam_z on IRC). I live in Pune, India (GMT +5:30). I am pursuing my undergraduate degree in Computer Engineering from Pune Institute of Computer Technology, Pune. I have been programming for the past 4 years. I am well versed in C/C++, Python3, and Golang. My Alioth and Github handles are satyamz-guest and satyamz respectively. I have been using GNU/Linux and free software from last four years. I am an open source enthusiast and I have been following Hacker culture since past three years. Accepted into Google Summer of Code 2016 under Debian Project: I am glad that I have got an opportunity to contribute to the Debian Project via Google Summer of Code 2016. I am accepted for project Improving diffoscope tool and reproducibility of Debian packages. This Summer and beyond I will be working with Debian Reproducible Builds team to improve the debbugging tool called Diffoscope (previously known as debbindiff). Thanks a bunch to Debian community, Lunar, Holger Levsen, Reiner Herrmann, Mattia Rizzolo and reproducible-builds folks for giving me this opportunity. Here is my GSoC'16 Proposal. And Yay! It really feels great :smile: Project details: I will be working on Diffoscope tool which is debbugging tool developed under reproducible-builds effort. Basically, Diffoscope compares two files and shows the difference in text and html format. Diffoscope is mainly developed to compare two Debian packages which may consist of binary files, tar files, text files etc. Diffoscope helps to identify difference between two Debian packages with respect to timestamps, file ordering etc. Diffoscope will try to get to the bottom of what makes files or directories different. It will recursively unpack archives of many kinds and transform various binary formats into more human readable form to compare them. It can compare two tarballs, ISO images, Debian packages or PDF just as easily. Diffoscope helps to identify the reproduciblity of Debian packages. During this summer I will be improving Diffoscope. I will be mainly working on:

• Finish Parallel processing part.
• Add command line option - -ignore-profile to allow users to ignore arbitrary differences.
• perform fuzzy-matching across archives.
• Add new file comparators to extend support of diffoscope for new file types.

My next blog post will be regarding community bonding. Thanks for reading :)

Debian LTS April marked the twelfth month I contributed to Debian LTS under the Freexian umbrella. I only spent 2 hours (instead of expected 11,25) working on LTS things:

• Uploaded gtk+3.0 to wheezy-proposed-updates to fix CVE-2013-7447 (#818090).
• Further work on figuring out how to support Xen and QEMU in Wheezy LTS including writing up a summary and a interview with one prospective company
• Prepared a patch for Jessie's nss to fix CVE-2016-1950, CVE-2016-1979, CVE-2016-1978, CVE-2016-1938 based on Antiones work for Wheezy. This is currently pending review by the security team.
• Started to look into CVE-2014-7210 in pdns

The missing hours will be caught up during May - hopefully also by working on a QEMU/libvirt update in Wheezy should there be any interest - so I've you're relying on QEMU/KVM in wheezy now would be a good time to comment on it. Other Debian things

• Attended the 9th Debian Groupware Meeting in the LinuxHotel in Essen resulting in a new upload of calypso to unstable.
• Uploded libvirt and python-libvirt 1.3.3, virt-sandbox 0.5.1+git20151113-3 and virt-manager 1.3.2-3 to unstable and libvirt 1.3.4~rc1 to experimental

Where I set out to figure out which multimedia player in Debian claim support for most file formats. A few years ago, I had a look at the media support for Browser plugins in Debian, to get an idea which plugins to include in Debian Edu. I created a script to extract the set of supported MIME types for each plugin, and used this to find out which multimedia browser plugin supported most file formats / media types. The result can still be seen on the Debian wiki, even though it have not been updated for a while. But browser plugins are less relevant these days, so I thought it was time to look at standalone players. A few days ago I was tired of VLC not being listed as a viable player when I wanted to play videos from the Norwegian National Broadcasting Company, and decided to investigate why. The cause is a missing MIME type in the VLC desktop file. In the process I wrote a script to compare the set of MIME types announced in the desktop file and the browser plugin, only to discover that there is quite a large difference between the two for VLC. This discovery made me dig up the script I used to compare browser plugins, and adjust it to compare desktop files instead, to try to figure out which multimedia player in Debian support most file formats. The result can be seen on the Debian Wiki, as a table listing all MIME types supported by one of the packages included in the table, with the package supporting most MIME types being listed first in the table. The best multimedia player in Debian? It is totem, followed by parole, kplayer, mpv, vlc, smplayer mplayer-gui gnome-mpv and kmplayer. Time for the other players to update their announced MIME support?

The primary change in this release is porting the remctl extension to PHP 7. PHP 7.0 included a major change to the PHP API for binary extensions, which required quite a lot of porting (contributed by Nish Aravamudan). Due to the depth of the changes, the extension has been forked and the PHP 5 version of the extension should be considered frozen. Currently, they both provide the same functionality, but expect new functionality to be released only for PHP 7 or later. This release also includes numerous portability fixes for older versions of Heimdal and numerous fixes to the RPM spec, both thanks to Jeffrey Hutzelman. You can get the latest release from the remctl distribution page.

Quite some time ago, I added strlcat and strlcpy functions to my portability C library. I've subsequently become convinced that those functions are a bad idea, and have been moving all of my code to asprintf and other functions. This release completes that change for all the code provided by rra-c-util and removes strlcpy and strlcat from rra-c-util. network_set_freebind, network_set_reuseaddr, and network_set_v6only, to set various socket options, are now public functions, since INN wanted to use them directly rather than only as part of other interfaces. This release also has new Autoconf probes for Perl that assist with linking with embedded Perl, checking the Perl version, and checking for Perl modules, and a fix to the OpenSSL Autoconf macros for 1.1.0. It also adds a replacement for gss_oid_equal for older versions of Heimdal that lack it. Finally, rra-c-util 6.0 implements the transition in C TAP Harness 4.0 from SOURCE and BUILD to C_TAP_SOURCE and C_TAP_BUILD for all the test suite helper code provided by this package. You can get the latest version from the rra-c-util distribution page.

When I originally wrote my test framework for C, I used SOURCE and BUILD as the preprocessor symbols and environment variables that pointed to the source and build directories of the software being tested. Subsequent discussion and thought convinced me that I should have used some sort of prefix on those variables to distinguish from other uses. This release starts the process of changing to C_TAP_SOURCE and C_TAP_BUILD instead. You now have to use the new names when setting preprocessor directives when building the test harness. For now, the test harness will set all four environment variables, but test code should switch to the new environment variables, since I'll drop the old SOURCE and BUILD variables in a later release. I also fixed a missing va_end() call in is_double(), thanks to a report from Julien LIE. You can get the latest release from the C TAP Harness distribution page.

Pyra preorders

If you've met me at a conference you may have noticed that instead of a laptop I was using a handeld which looks like a laptop scaled down to nintendo DS size, the https://en.wikipedia.org/wiki/Openpandora.

I've used it as my main computing device while travelling for a few years, even for work (as a programmer)so happily that when EvilDragon announced at FOSDEM (link points to youtube video) https://www.youtube.com/watch?v=4T-w1KqrVsM that he was working on a successor device I started saving money for it even before I knew many details about the specs, other that they would have been way better than the Pandora ones (which is getting painful to use a browser on, because of its 256MB RAM).

http://social.gl-como.it/photos/valhalla/image/5a9fdfadf33e40e9e3517b18ca7cba68

Now this successor device is almost ready, they have opened the preorders https://www.dragonbox.de/en/45-pyra, and they have already reached the absolute minimum number of orders for mass production and are almost there for a more reasonable number of 1000 devices, so if you want a chance to get one of the first batch devices now it's time to visit their store.

A few highlights, from my point of view, include:

* It will run Debian with just a custom kernel/bootloader (and a few configuration only packages): most of the kernel mods are being submitted upstream, so maybe one day there won't even be a need for this kernel (but e.g. with Pandora upstream didn't accept the custom way they managed the keyboard; on the Pyra the keyboard is managed in a more standard way, but there may be other similar issues).

* It has been designed with modularity in mind: the CPU board is socketed on the main board and in the future upgrades may require just replacing the CPU board. I haven't read the details on the actual licensing, but it seems that the hardware design will be open enough that 3rd party boards may also be a possibility.

* just like on Pandora: real keyboard. hardware analog volume wheel. Huge user-replaceable battery (I don't think that there are any independent reviews of the pyra battery yet, but the one on the Pandora is still able to go through a day of FOSDEM i.e. alternating often between on with wifi and suspendend and only go down to 50% or so charge). Stylus (and 3d-printed quill) friendly touchscreen. Long term support from the producer.

* The 4G version has been designed in such a way that the GSM modem can be actually turned off (just like on the https://neo900.org/)

There are of course a few bad parts:

* PowerVR. The good news is that there is a risk that no 3d drivers will be available at all, and this means that the Pyra has been tested and considered good enough with just (FOSS) software acceleration.

* The price: yes, it is expensive. I'm happy I've saved money in advance for it, otherwise I wouldn't have been able to afford it. Some of it is a problem of small production, some is actual product quality. If you consider that it can take the place of both a laptop (and small ones are getting quite expensive, now that netbooks have disappeared) and a smartphone (I don't do lots of voice calls) it will start going down from "oh so **** high" to "high, but not unreasonably so"

Disclaimer: I have preordered one, so I am interested in the success of the project because it will mean better software and better support for the device.

Edit: forgot the link to the press kit the images comes from http://cloud.openpandora.org/index.php/s/a0Q0TXV8gh5NLAC?path=%2F, which also includes more infos on specs etc.

Memory management is hard, but RAM management may be even harder. Most people know the vague overall concept of how memory usage is displayed within Linux. You have your total memory which is everything inside the box; then there is used and free which is what the system is or is not using respectively. Some people might know that not all used is used and some of it actually is free. It can be very confusing to understand, even for a someone who maintains procps (the package that contains top and free, two programs that display memory usage). So, how does the memory display work? What free shows The free program is part of the procps package. It s central goal is to give a quick overview of how much memory is used where. A typical output (e.g. what I saw when I typed free -h ) could look like this:

      total   used    free   shared  buff/cache  available
Mem:    15G   3.7G    641M     222M         11G        11G
Swap:   15G   194M     15G

I ve used the -h option for human-readable output here for the sake of brevity and because I hate typing long lists of long numbers. People who have good memories (or old computers) may notice there is a missing -/+ buffers/cache line. This was intentionally removed in mid-2014 because as the memory management of Linux got more and more complicated, these lines became less relevant. These used to help with the not used used memory problem mentioned in the introduction but progress caught up with it. To explain what free is showing, you need to understand some of the underlying statistics that it works with. This isn t a lesson on how Linux its memory (the honest short answer is, I don t fully know) but just enough hopefully to understand what free is doing. Let s start with the two simple columns first; total and free. Total Memory This is what memory you have available to Linux. It is almost, but not quite, the amount of memory you put into a physical host or the amount of memory you allocate for a virtual one. Some memory you just can t have; either due to early reservations or devices shadowing the memory area. Unless you start mucking around with those settings or the virtual host, this number stays the same. Free Memory Memory that nobody at all is using. They haven t reserved it, haven t stashed it away for future use or even just, you know, actually using it. People often obsess about this statistic but its probably the most useless one to use for anything directly. I have even considered removing this column, or replacing it with available (see later what that is) because of the confusion this statistic causes. The reason for its uselessness is that Linux has memory management where it allocates memory it doesn t use. This decrements the free counter but it is not truly used . If you application needs that memory, it can be given back. A very important statistic to know for running a system is how much memory have I got left before I either run out or I start to serious swap stuff to swap drives. Despite its name, this statistic will not tell you that and will probably mislead you. My advice is unless you really understand the Linux memory statistics, ignore this one. Who s Using What Now we come to the components that are using (if that is the right word) the memory within a system. Shared Memory Shared memory is often thought of only in the context of processes (and makes working out how much memory a process uses tricky but that s another story) but the kernel has this as well. The shared column lists this, which is a direct report from the Shmem field in the meminfo file. Slabs For things used a lot within the kernel, it is inefficient to keep going to get small bits of memory here and there all the time. The kernel has this concept of slabs where it creates small caches for objects or in-kernel data strucutures that slabinfo(5) states [such as] buffer heads, inodes and dentries . So basically kernel stuff for the kernel to do kernelly things with. Slab memory comes in two flavours. There is reclaimable and unreclaimable. This is important because unreclaimable cannot be handed back if your system starts to run out of memory. Funny enough, not all reclaimable is, well, reclaimable. A good estimate is you ll only get 50% back, top and free ignore this inconvenient truth and assume it can be 100%. All of the reclaimable slab memory is considered part of the Cached statistic. Unreclaimable is memory that is part of Used. Page Cache and Cached Page caches are used to read and write to storage, such as a disk drive. These are the things that get written out when you use sync and make the second read of the same file much faster. An interesting quirk is that tmpfs is part of the page cache. So the Cached column may increase if you have a few of these. The Cached column may seem like it should only have Page Cache, but the Reclaimable part of the Slab is added to this value. For some older versions of some programs, they will have no or all Slab counted in Cached. Both of these versions are incorrect. Cached makes up part of the buff/cache column with the standard options for free or has a column to itself for the wide option. Buffers The second component to the buff/cache column (or separate with the wide option) is kernel buffers. These are the low-level I/O buffers inside the kernel. Generally they are small compared to the other components and can basically ignored or just considered part of the Cached, which is the default for free. Used Unlike most of the previous statistics that are either directly pulled out of the meminfo file or have some simple addition, the Used column is calculated and completely dependent on the other values. As such it is not telling the whole story here but it is reasonably OK estimate of used memory. Used component is what you have left of your Total memory once you have removed:

• Free memory because free is not used!
• The Cached value recall this is made up of the Page Cache plus the Reclaimable part of Slab
• The buffers

Notice that the unreclaimable part of slab is not in this calculation, which means it is part of the used memory. Also note this seems a bit of a hack because as the memory management gets more complicated, the estimates used become less and less real. Available In early 2014, the kernel developers took pity on us toolset developers and gave us a much cleaner, simpler way to work out some of these values (or at least I d like to think that s why they did it). The available statistic is the right way to work out how much memory you have left. The commit message explains the gory details about it, but the great thing is that if they change their mind or add some new memory feature the available value should be changed as well. We don t have to worry about should all of slab be in Cached and are they part of Used or not, we have just a number directly out of meminfo. What does this mean for free? Poor old free is now at least 24 years old and it is based upon BSD and SunOS predecessors that go back way before then. People expect that their system tools don t change by default and show the same thing over and over. On the other side, Linux memory management has changed dramatically over those years. Maybe we re all just sheep (see I had to mention sheep or RAMs somewhere in this) and like things to remain the same always. Probably if free was written now; it would only need the total, available and used columns with used merely being total minus available. Possibly with some other columns for the wide option. The code itself (found in libprocps) is not very hard to maintain so its not like this change will same some time but for me I m unsure if free is giving the right and useful result for people that use it.

A new minor release of BH is now on CRAN. BH provides a large part of the Boost C++ libraries as a set of template headers for use by R, possibly with Rcpp as well as other packages. This release uses the same Boost 1.60.0 version of Boost as the last release, but adds three more library: bimap, flyweight and icl. A brief summary of changes from the NEWS file is below.

Changes in version 1.60.0-2 (2016-05-06)

• Added Boost bimap via GH pull request #24 by Jim Hester.
• Added Boost icl via GH pull request #27 by Jay Hesselbert.
• Added Boost flyweight as requested in GH ticket #26.

Courtesy of CRANberries, there is also a diffstat report for the most recent release. Comments and suggestions are welcome via the mailing list or the issue tracker at the GitHubGitHub 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.