The Software Freedom Conservancy is currently running a fundraising program in an attempt to raise enough money to continue funding GPL compliance work. If they don't gain enough supporters, the majority of their compliance work will cease. And, since SFC are one of the only groups currently actively involved in performing GPL compliance work, that basically means that there will be nobody working to ensure that users have the rights that copyright holders chose to give them.

Why does this matter? More people are using GPLed software than at any point in history. Hundreds of millions of Android devices were sold this year, all including GPLed code. An unknowably vast number of IoT devices run Linux. Cameras, Blu Ray players, TVs, light switches, coffee machines. Software running in places that we would never have previously imagined. And much of it abandoned immediately after shipping, gently rotting, exposing an increasingly large number of widely known security vulnerabilities to an increasingly hostile internet. Devices that become useless because of protocol updates. Toys that have a "Guaranteed to work until" date, and then suddenly Barbie goes dead and you're forced to have an unexpected conversation about API mortality with your 5-year old child.

We can't fix all of these things. Many of these devices have important functionality locked inside proprietary components, released under licenses that grant no permission for people to examine or improve them. But there are many that we can. Millions of devices are running modern and secure versions of Android despite being abandoned by their manufacturers, purely because the vendor released appropriate source code and a community grew up to maintain it. But this can only happen when the vendor plays by the rules.

Vendors who don't release their code remove that freedom from their users, and the weapons users have to fight against that are limited. Most users hold no copyright over the software in the device and are unable to take direct action themselves. A vendor's failure to comply dooms them to having to choose between buying a new device in 12 months or no longer receiving security updates. When yet more examples of vendor-supplied malware are discovered, it's more difficult to produce new builds without them. The utility of the devices that the user purchased is curtailed significantly.

The Software Freedom Conservancy is one of the only organisations actively fighting against this, and if they're forced to give up their enforcement work the pressure on vendors to comply with the GPL will be reduced even further. If we want users to control their devices, to be able to obtain security updates even after the vendor has given up, we need to keep that pressure up. Supporting the SFC's work has a real impact on the security of the internet and people's lives. Please consider giving them money.

comments

What does happiness signify to you, I asked him, if it isn t based on wealth and comfort? Happiness for me is a combination of feeling good about myself and having love, he said. And to feel good about myself, I have to do things that convince me I deserve it. ( ) The point is, even though it s sad to see people being foolish, there s no use giving up. Nothing good can come of giving up. That just means you lose completely, right away.

Richard Stallman on the 30th anniversary of the GNU Manifesto. It s amazing to think that a broken printer lead to the creation of the Free Software movement which, many years later, would give me a professional career, an education, and incredible friends around the world. Which reminds me I still keep the sticker Richard personally handed at the end of his first talk in Per , back in August 2003: Bonus: Enjoy The Free Software Song by The GNU/Stallmans.

# Copyright (C) YEAR Free Software Foundation, Inc. # This file is distributed under the same license as the PACKAGE package. # FIRST AUTHOR , YEAR. # #, fuzzy msgid "" msgstr "" "Project-Id-Version: PACKAGE VERSION\n" "POT-Creation-Date: 2015-12-21 15:00+0100\n" "PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" "Last-Translator: FULL NAME \n" "Language-Team: LANGUAGE \n" "Language: \n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" #. type: Title # #, no-wrap msgid "I want your input" msgstr "" #. type: Plain text #, no-wrap msgid "\n" msgstr "" #. type: Plain text #, no-wrap msgid "\n" msgstr "" #. type: Plain text msgid "You want to share an opinion with me, or raise a question?" msgstr "" #. type: Plain text msgid "Great, please do: I love exchanging opinions and ideas." msgstr "" #. type: Plain text msgid "" "You can [contact me discretely][]. Please consider, however, to speak in " "public instead, allowing others to benefit from our exchange." msgstr "" #. type: Plain text msgid "" "Don't worry if it is interesting to others - the World is big and someone " "somewhere always cares!" msgstr "" #. type: Plain text msgid "[contact me discretely]:" msgstr "" #. type: Title ## #, no-wrap msgid "Email - encourages reflection" msgstr "" #. type: Plain text msgid "Post to a public mailinglist." msgstr "" #. type: Plain text msgid "" "If uncertain that I am subscribed to the list, or if you want my special " "attention (but think twice if that's really needed!), add my [private " "mail](mailto:dr@jones.dk) as cc." msgstr "" #. type: Title ## #, no-wrap msgid "Chat - more casual" msgstr "" #. type: Plain text msgid "" "I am also [reachable via chat][]. Chat is nice for shorter " "questions/comments, and when you need to discuss what you want to say at " "all." msgstr "" #. type: Plain text msgid "[reachable via chat]:" msgstr "" #. type: Title ## #, no-wrap msgid "Blog - best for reuse" msgstr ""

# Copyright (C) YEAR Free Software Foundation, Inc. # This file is distributed under the same license as the PACKAGE package. # FIRST AUTHOR , YEAR. # #, fuzzy msgid "" msgstr "" "Project-Id-Version: PACKAGE VERSION\n" "POT-Creation-Date: 2015-12-21 15:00+0100\n" "PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" "Last-Translator: FULL NAME \n" "Language-Team: LANGUAGE \n" "Language: \n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" #. type: Title # #, no-wrap msgid "issues handling issues" msgstr "" #. type: Plain text #, no-wrap msgid "\n" msgstr "" #. type: Plain text #, no-wrap msgid "\n" msgstr "" #. type: Plain text msgid "" "I get lots of emails, some of which are "issues": Friends, colleagues, " "clients and machines tell me about stuff that is broken. and ask for new " "features." msgstr "" #. type: Plain text msgid "I currently handle issues somewhat like this:" msgstr "" #. type: Plain text #, no-wrap msgid "[[!graph src="""\n" msgstr "" #. type: Plain text #, no-wrap msgid "" "rankdir=LR\n" "inbox [label="incoming mails"]\n" "todobox [label="mail threads about issues"]\n" "issueboxes [label="issue-mails grouped by project" style=dotted]\n" "solve [label="fix issue"]\n" "archivebox [label="archived mails"]\n" "inbox -> todobox\n" "todobox -> issueboxes [style=dotted]\n" "todobox -> solve\n" "todobox -> archivebox\n" msgstr "" #. type: Plain text msgid "FIXME: Describe graf in steps." msgstr "" #. type: Plain text msgid "" "The idea was to organize issues in queues per project, but organizing emails " "requires understanding them, and that takes time: Too often I end up " "skipping that task, leading to weak overview of pending issues." msgstr "" #. type: Plain text msgid "Here's" msgstr "" #. type: Plain text #, no-wrap msgid "" "rankdir=LR\n" "inbox [label="incoming mails"]\n" "todobox [label="mail threads about issues"]\n" "new [label="unprocessed issues"]\n" "open [label="open issues"]\n" "solve [label="fix issue"]\n" "inbox -> todobox -> archivebox\n" "todobox -> new -> open\n" "open -> solve\n" "open -> done\n" msgstr ""

Umm. Somehow I thought this would be easier than learning about live-build. Probably I was wrong. There are probably many better tutorials on the web. Two useful observations: zeroing the key can eliminate mysterious grub errors, and systemd-nspawn is pretty handy. One thing that should have been obvious, but wasn't to me is that it's easier to install grub onto a device outside of any container. Find device

 $ dmesg

Count sectors

 # fdisk -l /dev/sdx

Assume that every command after here is dangerous. Zero it out. This is overkill for a fresh key, but fixed a problem with reusing a stick that had a previous live distro installed on it.

 # dd if=/dev/zero of=/dev/sdx bs=1048576 count=$sectors

Make file system. There are lots of options. I eventually used parted

 # parted
 (parted) mklabel msdos
 (parted) mkpart primary ext2 1 -1
 (parted) set 1 boot on
 (parted) quit

Make a file system

 # mkfs.ext2 /dev/sdx1
 # mount /dev/sdx1 /mnt

Install the base system

 # debootstrap --variant=minbase jessie /mnt http://httpredir.debian.org/debian/

Install grub (no chroot needed)

 # grub-install --boot-directory /mnt/boot /dev/sdx1

Set a root password

 # chroot /mnt
 # passwd root
 # exit

create up fstab

# blkid -p /dev/sdc1   cut -f2 -d' ' > /mnt/etc/fstab

Now edit to fix syntax, tell ext2, etc... Now switch to system-nspawn, to avoid boring bind mounting, etc..

# systemd-nspawn -b -D /mnt

login to the container, install linux-base, linux-image-amd64, grub-pc EDIT: fixed block size of dd, based on suggestion of tg.

The pressure of the post-modernism is establishing its bases on our general lack of ability to overcome a number of dualisms that have become ingrained in the modern way of thinking[1]. This is mainly due to the strong influence of past centuries scientific Reductionism , which postulated that any system to be understood had to be reduced to its minimum component elements.

However, a so defined system is a closed system, which does not interact with the surrounding environment and it can exist (not always) only in a reality-isolated laboratory. The logic of Complexity , instead, takes into account the open systems and all the interconnections and influences of the system itself with the world around it, in every physical, social, psychological and symbolic aspect

<Read more >

TeleLaunchTwo A Smaller Wireless Launch Controller I've built a wireless launch control system for NAR and OROC. Those are both complex systems with a single controller capable of running hundreds of pads. And, it's also complicated to build, with each board hand-made by elves in our Portland facility (aka, my office). A bunch of people have asked for something simpler, but using the same AES-secured two-way wireless communications link, so I decided to just build something and see if we couldn't eventually come up with something useful. I think if there's enough interest, I can get some boards built for reasonable money. Here's a picture of the system; you can see the LCO end in a box behind the pad end sitting on the bench. Radio Link Each end has a 35mW 70cm digital transceiver (so, they run in the 440MHz amateur band). These run at 19200 baud with fancy forward error correction and AES security to keep the link from accidentally (or maliciously) firing a rocket at the wrong time. Using a bi-directional link, we also get igniter continuity and remote arming information at the LCO end. The LCO Box In the LCO box, there's a lipo battery to run the device, so it can be completely stand-alone. It has three switches and a button -- an arming switch for each of two channels, a power switch and a firing button. The lipo can be charged by opening up the box and plugging it into a USB port. The Pad Box The pad box will have some cable glands for the battery and each firing circuit. On top, it will have two switches, a power switch and an arming switch. The board has two high-power FETs to drive the igniters. That should be more reliable than using a relay, while also allowing the board to tolerate a wider range of voltages -- the pad box can run on anything from 12V to 24V. The Box Unlike the OROC and NAR systems, these boards are both designed to fit inside a specific box, the Hammond 1554E, and use the mounting standoffs provided. This box is rated at NEMA 4X, which means it's fairly weather proof. Of course, I have to cut holes in the box, but I found some NEMA 4X switches, will use cable glands for the pad box wiring and can use silicone around the BNC connector. The result should be pretty robust. I also found a pretty solid-seeming BNC connector, which hooks around the edge of the board and also clips on to the board. Safety Features. There's an arming switch on both ends of the link, and you can't fire a rocket without having both ends armed. That provides an extra measure of safety while working near the pad. The pad switch is a physical interlock between the power supply and the igniters, so even if the software is hacked or broken, disarming the box means the igniters won't fire. The LCO box beeps constantly when either arming switch is selected, giving you feedback that the system is ready to fire. And you can see on any LED whether the pad box is also armed.

What happened in the reproducible builds effort between December 13th to December 19th: Infrastructure Niels Thykier started implementing support for .buildinfo files in dak. A very preliminary commit was made by Ansgar Burchardt to prevent .buildinfo files from being removed from the upload queue. Toolchain fixes

• Niels Thykier uploaded debhelper/9.20151219 which sorts files read by dh_installinit. Patch by Reiner Herrmann.
• Jo Shields uploaded mona/4.2.1.102+dfsg2-4 which lands upstream changes making GUID reproducible in unstable.
• Niko Tyni uploaded perl/5.22.1-1 which makes support for SOURCE_DATE_EPOCH in podlators available in unstable.

Mattia Rizzolo rebased our experimental debhelper with the changes from the latest upload. New fixes have been merged by OCaml upstream. Packages fixed The following 39 packages have become reproducible due to changes in their build dependencies: apache-mime4j, avahi-sharp, blam, bless, cecil-flowanalysis, cecil, coco-cs, cowbell, cppformat, dbus-sharp-glib, dbus-sharp, gdcm, gnome-keyring-sharp, gudev-sharp-1.0, jackson-annotations, jackson-core, jboss-classfilewriter, jboss-jdeparser2, jetty8, json-spirit, lat, leveldb-sharp, libdecentxml-java, libjavaewah-java, libkarma, mono.reflection, monobristol, nuget, pinta, snakeyaml, taglib-sharp, tangerine, themonospot, tomboy-latex, widemargin, wordpress, xsddiagram, xsp, zeitgeist-sharp. The following packages became reproducible after getting fixed:

• 4ti2/1.6.7+ds-2 uploaded by Jerome Benoit, original patch by Reiner Herrmann.
• clblas/2.8+ds1-3 by Ghislain Antony Vaillant.
• config-manager/0.4-2.2 by Mattia Rizzolo.
• cvs-fast-export/1.35-1 by Anthony Fok.
• dgedit/0~git20151217-1 by V ctor Cuadrado Juan.
• genometools/1.5.7-7 by Sascha Steinbiss.
• gnome-blog/0.9.1-7 uploaded by Frederic Peters, based on an NMU by Mattia Rizzolo.
• guava-libraries/19.0-1 by Emmanuel Bourg.
• kwave/0.9.0-1-1 uploaded by Pino Toscano, fixed upstream.
• libandroid-json-org-java/20121204-20090211-2 by Emmanuel Bourg.
• libchado-perl/1.23-5 uploaded by Andreas Tille, original patch by Niko Tyni.
• libffi/3.2.1-4 by Matthias Klose.
• mksh/52-1 by Thorsten Glaser.
• monit/1:5.15-3 uploaded by Sergey B Kirpichev, original patch by Chris Lamb.
• ntlmaps/0.9.9.0.1-11.5 by Mattia Rizzolo.
• perl/5.22.1~rc3-2 by Niko Tyni.
• picolisp/15.11-1 by Kan-Ru Chen.
• qelectrotech/1:0.5-1 uploaded by Denis Briand, fixed upstream.
• tomcat8/8.0.30-1 by Emmanuel Bourg.
• xfonts-ayu/1:1.7a-1 by Hideki Yamane with a patch from Chris Lamb.
• xfonts-kaname/1.1-10 by Hideki Yamane with a patch from Chris Lamb.
• xfonts-kappa20/1:0.396-1 by Hideki Yamane with a patch from Chris Lamb.

Some uploads fixed some reproducibility issues, but not all of them:

• bup/0.27-2 uploaded by Robert Edmonds, patch by Chris Lamb.
• cain/1.10+dfsg-1 uploaded by Andreas Tille, original patch by Chris Lamb.
• liblouisutdml/2.5.0-2 by Samuel Thibault.
• mariadb-10.0/10.0.22-5 by Otto Kek l inen.

Patches submitted which have not made their way to the archive yet:

• #807837 on lxc by Reiner Herrmann: use time of latest debian/changelog entry for LXC_GENERATE_DATE.
• #807838 on graphite2 by Reiner Herrmann: tell dblatex to use a static path.
• #808032 on python-genpy by Chris Lamb: sort list of generated modules.
• #808388 on buzztrax by Chris Lamb: implement support for SOURCE_DATE_EPOCH.

reproducible.debian.net Packages in experimental are now tested on armhf. (h01ger) Arch Linux packages in the multilib and community repositories (4,000 more source packages) are also being tested. All of these test results are better analyzed and nicely displayed together with each package. (h01ger) For Fedora, build jobs can now run in parallel. Two are currently running, now testing reproducibility of 785 source packages from Fedora 23. mock/1.2.3-1.1 has been uploaded to experimental to better build RPMs. (h01ger) Work has started on having automatic build node pools to maximize use of armhf build nodes. (Vagrant Cascadian) diffoscope development Version 43 has been released on December 15th. It has been dubbed as epic! as it contains many contributions that were written around the summit in Athens. Baptiste Daroussin found that running diffoscope on some Tar archives could overwrite arbitrary files. This has been fixed by using libarchive instead of Python internal Tar library and adding a sanity check for destination paths. In any cases, until proper sandboxing is implemented, don't run diffosope on unstrusted inputs outside an isolated, throw-away system. Mike Hommey identified that the CBFS comparator would needlessly waste time scanning big files. It will now not consider any files bigger than 24 MiB 8 MiB more than the largest ROM created by coreboot at this time. An encoding issue related to Zip files has also been fixed. (Lunar) New comparators have been added: Android dex files (Reiner Herrmann), filesystem images using libguestfs (Reiner Herrmann), icons and JPEG images using libcaca (Chris Lamb), and OS X binaries (Clemens Lang). The comparator for Free Pascal Compilation Unit will now only be used when the unit version matches the compiler one. (Levente Polyak) A new multi-file HTML output with on-demand loading of long diffs is available through the --html-dir option. On-demand loading requires jQuery which path can be specified through the --jquery option. The diffs can also be simply browsed for non-JavaScript users or when jQuery is not available. (Joachim Breitner) Portability toward other systems has been improved: old versions of GNU diff are now supported (Mike McQuaid), suggestion of the appropriate locale is now the more generic en_US.UTF-8 (Ed Maste), the --list-tools option can now support multiple systems (Mattia Rizzolo, Levente Polyak, Lunar). Many internal changes and code clean-ups have been made, paving the way for parallel processing. (Lunar) Version 44 was released on December 18th fixing an issue affecting .deb lacking a md5sums file introduced in a previous refactoring (Lunar). Support has been added for Mozilla optimized Zip files. (Mike Hommey). The HTML output has been optimized in size (Mike Hommey, Esa Peuha, Lunar), speed (Lunar), and will now properly number lines (Mike Hommey). A message will always be displayed when lines are ignored at the end of a diff (Lunar). For portability and consistency, Python os.walk() function is now used instead of find to perform directory listing. (Lunar) Documentation update Package reviews 143 reviews have been removed, 69 added and 22 updated in the previous week. Chris Lamb reported 12 new FTBFS issues. News issues identified this week: random_order_in_init_py_generated_by_python-genpy, timestamps_in_copyright_added_by_perl_dist_zilla, random_contents_in_dat_files_generated_by_chasen-dictutils_makemat, timestamps_in_documentation_generated_by_pandoc. Chris West did some improvements on the scripts used to manage notes in the misc repository. Misc. Accounts of the reproducible builds summit in Athens were written by Thomas Klausner from NetBSD and Hans-Christoph Steiner from The Guardian Project. Some openSUSE developers are working on a hackweek on reproducible builds which was discussed on the opensuse-packaging mailing-list.

For the last week I have been stuck in England. For the vast majority of that time, I've had nothing to do except work on Debian and this blog post documents some of the things I worked on. Obviously spending a whole week on Debian, there's going to be some packaging involved. The following packages got new versions in unstable this last week:

• cowdancer
• debian-installer-launcher
• chirp
• python-flask-rdf

Packaging updates were one of the simpler tasks tackled this week though. I spent a lot of time this week on Debian Live along with others in the #debian-live IRC channel. Over the last week we achieved a number of things, possibly the most important being that all the generic live support packages (i.e. live-boot, live-config and live-tools) have now been converted into native packages, have their VCS repositories hosted on Alioth and have seen a good number of patches merged from the BTS and from the old patch system. All future patches will be managed via the BTS for Debian Live, as with other Debian projects. We've also put effort into getting documentation online again now that the live.debian.net server has been turned off and we now have the live-build documentation and the live-wrapper documentation hosted on the project's Alioth webspace. The live-wrapper user documentation was mostly written this week so may not be amazing. On the smaller task list for Debian Live, the KGB bots are now present in the channel and reporting on git commits, a number of the more popular URLs from live.debian.net are now being redirected to their new locations (although we've had to recover these URLs from web.archive.org, the list of redirections is certainly not complete) and we've made updates to the wiki pages about how to contribute to the project. Unfortunately, no one has stepped forwards as a new lead for live-build and so this package has been orphaned. This does not necessarily mean that the package will be removed from Debian any time soon, just that it does not currently have a maintainer. If you're interested in taking over maintainence of live-build, see #808048. For testing the core live support packages, new live images for stretch have been built using live-wrapper and are available here. There are known issues with the syslinux configuration and these are not isohybrid images. My other major project this week has been my efforts to form a Debian Metadata team. The Debian Metadata team would produce the frameworks and run the services that make data about Debian available in a number of formats to make the data as accessible as possible and to encourage its use both within Debian and in external projects. Currently this includes two experimental services: rdf.debian.net and map.debian.net. We're don't plan to duplicate any of the work done by UDD, but make the data aggregated in UDD more accessible to users and developers. This means publishing that data in JSON/JSONP, KML, RDF, iCalendar and any other format that makes sense. There may be instances where it makes sense to augment the published data with live data, for example mirror availability should probably be live and not just a recent snapshot. If you're interested in participating in the Debian Metadata team, you can register your interested on bug #808049. This is not a complete summary of all my activities over the last week, but for those interested, it should give you an idea of what I've been up to. Finally, for those of you that have been waiting for my write-up on the airgapped GnuPG master key, I decided in the end that my blog was not the right place for this. You can find the guide in two parts: key generation and key export to the YubiKey. I've tried to keep these guides as generic as possible while still being as useful as possible. While writing these up on the wiki, I've also created pages for OpenPGP and GnuPG and I've almost entirely rewritten the DebianKeyring wiki page. I discovered this awesome guide to OpenPGP concepts which I would recommend to anyone that is new to OpenPGP.

I just donated to Software Freedom Conservancy as a supporter. They do great, important work in GPL enforcement, and they need some money to continue it. You can help, too: https://sfconservancy.org/supporter/. See also, https://bits.debian.org/2015/12/conservancy-fundraising-campaign.html.

So, lately I've been on a telephoto lens learning curve; after the 300mm prime, I said to test a zoom lens. As I found the prime reasonably easy to adapt to (compared to shorter focal length lenses), I thought that a zoom (heavier, bigger) will be the same. Oh, I was wrong. My keeper rate for the first outdoors test was quite bad around 50% only, which (when talking only about focus/sharpness) is much below my standards. I started easy; some close or medium range shots, nothing special: But then, moving to further distances, things became less straightforward. Shooting two pictures each time meant that usually one of them was sharp, but the other not. I got really confused at this step; the shutter speed was 1/2000s and I also had VR on; either VR was unneeded (i.e. contributing blur instead of helping) or something else was going on. After much head scratching, I think it's a combination of the following factors:

• shooting at long range; for the pictures I'm talking about, the subject was between 800m and 1.2km; at this range, haze and atmospheric disturbances start to play a role.
• lens is heavy 2.3kg and adding the camera (1kg) it means that I was hand-holding 3.3kg, which is much more than I'm used to; the focal length of the lens, at that distance, means that any small movement (rotation or shift) translates into significant subject movement, especially when viewed at 1:1 magnification on a 36Mp body.
• there might still be some interplay between VR and shooting at this shutter speed, although not sure.

So, for such style of shooting, I need to train more both photographic technique and arm strength at the gym In the meantime, it is possible to get such shots reasonably sharp, for example this picture of the (start of the) Alps taken from what is technically still Z rich city: I'm happy with the detail (at this distance), however I was not able to correct the colour due to the haze between me and the mountains; note that the trees on the bottom of the distance were not near me, but on the next or after-next hill. This picture confirms that with more practice things will get better. Coming back to shorter distances, and shorter focal lengths, things are looking better. We were passing somewhat near some people playing with RC-controlled planes not near enough to hear them, but near enough to see the plane quickly flying. Switched camera quickly to AF-C and Dynamic-21 focus, and - to my surprise - I was able to capture four good pictures, two so-so and four more clearly out of focus. But, for such a heavy length, hand-held and on the short notice, I was happy; the first picture is one of the so-so ones, but I kept it as I like the way the propeller is seen. All pictures at 290mm plus some cropping, 1/1250s, ISO between 900 and 1800, f/5.6 (i.e wide open): From this exercise, the conclusion is that the lens is OK-ish for tracking, although the not-so good keeper rate tells me that I need to be careful; I'll have to see how a subject moving not left-right, but instead approaching or moving away from the camera would be tracked. But enough pictures of small planes. At 500mm, but still somewhat close, trees: At this step I'm starting to wonder if stopping down a bit would help with the sharpness; I'll have to test that in the future. Walking some more, finally a bird in flight; one of the hopes when I took the camera/lens out was that I'll see some birds, but this was the first. 500mm, heavily cropped, but quite good result for myself (same autofocus settings as before): The only problem here is, as always with crows (I think these are crows), is the black bird against the light-blue sky (not even strong blue), which means the picture has a high dynamic range; recovering the shadows on the bird is difficult. But in any case, it's clear the lens can deliver, if the photographer is good. Next, a helicopter was gracious enough to pass by (pretty close): Two minutes later, it was quite far, but since it was going in the direction of the Alps, it gave the opportunity for a nice shot: This picture is less sharp, but still I like it due to composition; not successful on small screens though, only if you see it full screen. Light is very difficult though and about 10 seconds earlier would have been even better (more separation between the helicopter and the mountain). And since we're talking about planes, let's see a plane at 500m, directly overhead, and quite high: This picture (@500mm, cropped, 1/2000s) has the most detail of a plane flying high enough to have trails (not sure how to estimate, but at least 5km, maybe more around 7-8 I'd say) that I ever took. So yes, the lens can deliver, but it's not easy. This shot, being shot more or less straight up, had the least distance through low-altitude atmosphere, so it has less problems compared to the mountains pictures. It's still not really sharp (lens wide open), but the amount of detail I'm sold And to finish on a more close note: A long focal length lens allows one to get "close" without getting close, which means animals are not disturbed. The first picture with the cat (not shown) had the cat less alert; ears not fully up, although eyes were still seeking; this picture shows it fully alert and concentrated, like it was a wild cat hunting for its survival, and not a city cat, out just for fun. So, summary:

• lens is nice (optically), although fully open (f/5.6) and hand-held and at long distance it doesn't yet give me full satisfaction; I will need to improve my technique and learn how to properly handle it.
• in combination with a high-megapixel body (D810), it allows fun although pointless feats; pointless doesn't stop hobbies, though
• I need to go to the gym; not "more often", just start going!

All the best to everybody for the coming holidays, and thanks for reading.

In September, The FUUG Foundation gave me a grant to buy some hardware for Obnam development. I used this money to buy a new desktop-ish machine, see below for details. It's sat in a corner, and I use it as a server: it's not normally connected to a monitor or keyboard. It runs Obnam benchmarks. Before this, I ran Obnam benchmarks and experiments on my laptop, or on BigV virtual servers donated by Bytemark. The hardware The parts:

• CPU: Intel Core i7 4790K 4.0 GHz (4 cores, total of 8 hyperthreads)
• RAM: Kingston HyperX Beast 32 GB
• Mainboard: 46400 Asus H97M-Plus Intel H97 LGA 1150 micro-ATX
• SSD: Samsung 850 EVO SSD 120 GB
• HDD: 4 x WD Red 4 TB
• PSU: Corsair CX750M ATX
• Case: BitFenix Phenom micro-ATX

Not to brag, but it's a nice machine. Much more power than my 2012 era laptop. The SSD is the system drive, the HDDs are for running Obnam benchmarks on. The HDDs are not RAIDed. Each drive is a PV for LVM2. All the data on those drives is scratch data: it's not valuable, and I do not care if it is lost. In fact, most of the data gets created and deleted during a benchmark run, and usually the disks are empty. The SSD contains the host operating system, and the virtual disks for all the virtual machines. I assembled the machine myself, with the help of a friend, and installed Debian jessie on it. The Debian installation is pretty bare bones, just enough to run and manage a bunch of virtual machines using libvirt and ansible. All the actual work, including benchmarks, are run in virtual machines. The benchmarks The benchmarks are run by a kludge, called obbench, and the results are published at http://benchmark.obnam.org/. Here's a snapshot of the results so far:

date	many files	one big file
2015-09-28	2165.0	1381.9
2015-12-06	1461.6	384.0

In a bit over two months, I've made some significant progress, I think. The two benchmarks that I currently run are:

• A million tiny files, containing a single, random byte.
• A single, 10 GB file.

These are two extreme cases of what a backup needs to deal with: either the file metadata, or its content. They incur different costs for a backup program. Thus, two benchmarks. In both cases, the benchmark consists of an initial backup, a restore, and a second backup, without changes to the live data. The second backup is an extreme case of what backups usually do: most data usually doesn't change, so keeping that in mind for optimisation is important. The above benchmarks are synthetic: they use data that's generated by a program (genbackupdata), so that they can be reproduced. Synthetic benchmarks are useful, especially for looking at particular aspects of a program's operation for optimisation. However, they do not necessarily reflect how a program behaves in actual use. I also run, by hand, experiments with real data. I have a snapshot of our home file server and my laptop on the benchmark machine. The snapshots are static, and do not get updated. I experiment by running Obnam backups manually, the initial full backup and a no-change incremental one. In early October, I couldn't finish the initial full backups. They took too long, more than a week. Now I can finish them in about a day. This remarkable change is not evident from the synthetic benchmarks. In numbers: 572986 files in the live data, containing 4.5 TiB. Initial backup, about 18.5 hours. Incremental backup, 4m13s. This is from a local disk to a local disk. In addition to these, I've run numerous experiments on the new machine. These would have been much less easy to run on my laptop, and so I probably wouldn't have. Running benchmarks was always painful on my laptop, since it does not have the necessary disk space, and I'd really rather like to use it for other things. The results Thanks to the benchmarks and experiments I've been able to take the in-development version of Obnam from being quite impractical for real use to being in experimental use for real data. I now use the new version as my primary backup of my laptop, with two secondary backups (with the old Obnam version, and rsync) in parallel. This would not have happened this year without the extra hardware. In addition to the Obnam work, I've used the new machine to develop a test suite for vmdebootstrap. My actual development still happens on my laptop, except for things that are heavy enough to be slow on the laptop. I've made sure I can do most development purely on my laptop, while offline, including running a CI system, and testing things on two architecture and three releases of Debian. I do not want my development to be dependent on incidental things such as network access, unless I'm doing things that by their nature depend on the network, such as publishing changes or releases.

In my previous post, I talked about the udev hack I had used with the YubiKey and how it was not the correct way to do things. I recieved a lot of feedback on this post, and here I'm hoping to summarise what the correct way to do it is. The rule I was originally using was:

SUBSYSTEMS=="usb", ATTRS idVendor =="1050",ATTRS idProduct =="0111", OWNER="irl"  

The problem with this rule was that it always made my own username the owner of the YubiKey. For my use on my laptop, this was fine, as I'm the only user ever logged into my laptop, but this is not the right way to do this. On a multi-user system you would want the user logged into the console, and so the one that has plugged in the USB device by implication, to be the owner of the device. Sam Morris followed up to my last post by e-mail to suggest the following rule:

SUBSYSTEMS=="usb", ATTRS idVendor =="1050", ATTRS idProduct =="0111", TAG+="uaccess"  

The difference here is that instead of explicitly setting an owner, the uaccess tag is added to the device. This tag has meaning to systemd-logind and will add the necessary ACLs to the device to allow the console user to access it. The ACL should also be removed by systemd-logind when you log out. He also suggested using getfacl (from the acl package) to check the ACLs that have been assigned to devices.

irl@orbiter$ getfacl /dev/hidraw0  
# file: hidraw0
# owner: irl
# group: root
user::rw-  
user:irl:rw-  
group::---  
mask::rw-  
other::---  

Here we can see that the device has been set to being owned by my username. (Note that on your system, the YubiKey may have a different path, check your dmesg output to see what device name it is assigned.) If you don't have systemd-logind available, fear not as there is an alternative approach you can take that was suggested by Simon Josefsson, who actually wrote a blog post in 2014 about using an offline GnuPG master key with subkeys on a YubiKey. If you install the pcscd package this will provide you with a daemon that runs as root and provides access to the smartcard for ordinary users. I haven't looked at how pcscd handles limiting access to the device for other users as this isn't an approach I've taken. Thanks to everyone who gave feedback, I feel like I've learnt something and taken another step closer to doing things The Right Way .

Around three years ago, I created the isenkram system to get a more practical solution in Debian for handing hardware related packages. A GUI system in the isenkram package will present a pop-up dialog when some hardware dongle supported by relevant packages in Debian is inserted into the machine. The same lookup mechanism to detect packages is available as command line tools in the isenkram-cli package. In addition to mapping hardware, it will also map kernel firmware files to packages and make it easy to install needed firmware packages automatically. The key for this system to work is a good way to map hardware to packages, in other words, allow packages to announce what hardware they will work with. I started by providing data files in the isenkram source, and adding code to download the latest version of these data files at run time, to ensure every user had the most up to date mapping available. I also added support for storing the mapping in the Packages file in the apt repositories, but did not push this approach because while I was trying to figure out how to best store hardware/package mappings, the appstream system was announced. I got in touch and suggested to add the hardware mapping into that data set to be able to use appstream as a data source, and this was accepted at least for the Debian version of appstream. A few days ago using appstream in Debian for this became possible, and today I uploaded a new version 0.20 of isenkram adding support for appstream as a data source for mapping hardware to packages. The only package so far using appstream to announce its hardware support is my pymissile package. I got help from Matthias Klumpp with figuring out how do add the required metadata in pymissile. I added a file debian/pymissile.metainfo.xml with this content:

<?xml version="1.0" encoding="UTF-8"?>
<component>
  <id>pymissile</id>
  <metadata_license>MIT</metadata_license>
  <name>pymissile</name>
  <summary>Control original Striker USB Missile Launcher</summary>
  <description>
    <p>
      Pymissile provides a curses interface to control an original
      Marks and Spencer / Striker USB Missile Launcher, as well as a
      motion control script to allow a webcamera to control the
      launcher.
    </p>
  </description>
  <provides>
    <modalias>usb:v1130p0202d*</modalias>
  </provides>
</component>

The key for isenkram is the component/provides/modalias value, which is a glob style match rule for hardware specific strings (modalias strings) provided by the Linux kernel. In this case, it will map to all USB devices with vendor code 1130 and product code 0202. Note, it is important that the license of all the metadata files are compatible to have permissions to aggregate them into archive wide appstream files. Matthias suggested to use MIT or BSD licenses for these files. A challenge is figuring out a good id for the data, as it is supposed to be globally unique and shared across distributions (in other words, best to coordinate with upstream what to use). But it can be changed later or, so we went with the package name as upstream for this project is dormant. To get the metadata file installed in the correct location for the mirror update scripts to pick it up and include its content the appstream data source, the file must be installed in the binary package under /usr/share/appdata/. I did this by adding the following line to debian/pymissile.install:

debian/pymissile.metainfo.xml usr/share/appdata

With that in place, the command line tool isenkram-lookup will list all packages useful on the current computer automatically, and the GUI pop-up handler will propose to install the package not already installed if a hardware dongle is inserted into the machine in question. Details of the modalias field in appstream is available from the DEP-11 proposal. To locate the modalias values of all hardware present in a machine, try running this command on the command line:

cat $(find /sys/devices/ grep modalias)

To learn more about the isenkram system, please check out my blog posts tagged isenkram.

After a short hiatus, a new version of the (wonderfully useful, if I dare say so ;-) RcppTOML package is now on CRAN. RcppTOML lets R read the (absolutely awesome) TOML configuration file format--which is simply fabulous as it emphasizes strong readability for humans while at the same time supporting strong typing as well as immediate and clear error reports. At work, we're all fans now. The new version on CRAN mostly updates to an updated version of the underlying cpptoml library by Chase. Nothing much changed on the R side. Courtesy of CRANberries, there is a diffstat report for this release More information and examples are on the RcppTOML 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.

travis.debian.net is my new hosted utility to make it easier and cleaner to test your Debian packages on the Travis CI continuous integration platform, without duplicating configuration or scripts across mulitiple repositories. You can read more about how it works, as well as follow the quick setup instructions. As ever, patches welcome.

Dear lazyweb, TL;DR version Why does ioctl(fd, SG_IO, &sg_io_hdr) return EINVAL, but an immediate retry after reopening the /dev/sdX fd succeeds? I'm not sure if reopening the fd is relevant, but the code only holds the fd open long enough to do perform the ioctl. The frequency of EINVAL seems to increase in correlation with the number of IO threads, where none are seen with a single IO thread. Background At work, I've been adding Linux support to an internal Windows tool we use to perform data integrity testing of block storage devices. It's a heavily multi-threaded program:

• 1 test thread per targeted LUN (up to 255 LUNs)
• N IO threads per test thread (from 1 to as many as can be sustained within the constraints of a 32-bit process)

The user has the ability to use either SCSI pass-thru or read/write file to perform reads/writes to the LUN, as well as various other purely SCSI pass-thru commands. The IO portion of the code can be boiled down to basically the following pseudo code:

start IO thread  
    If SCSI pass-thru or command which requires SCSI pass-thru
        build sg_io_hdr_t struct
        open /dev/disk/by-path/  (O_RDWR   O_NONBLOCK)
        issue ioctl(fd, SG_IO, &sg_io_hdr)
        close fd
        return massaged ioctl status and scsi_status
     else
        open /dev/disk/by-path/  (O_RDWR   O_NONBLOCK)
        seek to LBA
        issue write/read
        close fd
        return massaged write/read status 
wait for IO thread completion  
check status and potentially retry operation

Problem As the number of target LUNs or IO threads scale, we're seeing increasing amounts of EINVAL errors when we issue the SG_IO ioctl. According to the sg documentation, there are only a couple situations where EINVAL should be seen:

• Both direct and mmap flags are set
  • We use neither of these flags
• If none of the high/mid/low level SCSI drivers understand the ioctl
  • This clearly isn't the case, since it works fine with fewer threads and on retry

I wouldn't have been surprised to get EDOM (exceeding SG_MAX_QUEUE), but I'm at a loss as to where/why EINVAL is coming from. Granted, I'm opening an sd device instead of an sg device, so the error may be coming from a different layer in the stack. If you have any ideas, please let me know.

Personal projects:

• db2twitter 0.3 released build and send tweets with values from a database now fully featured and in production on linuxjobs.fr official documentation
  
• retweet 0.6 released new parameter only_if_hashtags to only retweet if a given hashtag is in the tweet text official documentation
• FOSS first-time contributors I created dedicated bugs in both Github Retweet and db2twitter bug tracking systems for people contributing to a Free and Open Source Software. Retweet won its first external contributions thanks to that system :)

Debian :

• db2twitter 0.3 Debian package now in Debian Sid
• retweet 0.6 Debian package now in Debian Sid

Others:

• feedDiasp does not work with Diaspora 0.5.4.0 any more break Journal du hacker forwarding to D* :(

That s all folks! See you next month!

Today was a nice day with a surprising number of early Christmas presents:

• I submitted my Ph.D. thesis Lazy Evaluation: From formal semantics to to a machine-checked compiler transformation about an Isabelle formalisation of Launchbury s natural semantics (also found in the Launchbury entry in the Archive of Formal Proofs), about the GHC optimization Call Arity that I developed (see the TFP 2014 paper) and a formal proof that it is indeed an optimization (Haskell Symposium 2015 paper, AFP entry). After 243 pages, it is finally done and I can now turn to new things. Speaking of something new : I m hunting jobs right now. I am in particular interested in academic post-doc positions in my field (functional programming languages and/or interactive theorem proving), but I d also like to hear about attractive non-academic positions that fit my profile.
• Someone who I value and respect a lot asked me to co-author a paper with him. I am not sure whether further details at this stage belong to a public blog post, so I ll keep them back. But nevertheless this is very nice.
• A paper on information flow control by my colleagues J rgen Graf, Martin Hecker and Martin Mohr, my advisor Gregor Snelting and (although only marginally) me was accepted at POST 2016, and the notification reached us today.
• Together with Carsten Podszun, I have written an article about the Ravensburger Tip-toi pen and how to create your own books for that using the tttool program that I have created for the German magazine Make:, and it is included in issue 6/2015, which arrived today in my mailbox.
• The Incredible Proof Machine attracts new contributors. Well, one. But a few days ago, I heard that a 11 year old girl has great fun with it!
• Tonight, my group is having their Christmas party and I can expect to be fed well by home-cooked Mexican something. Got to go...