I m a geek. I enjoy playing with different filesystems, version control systems, and, well, for that matter, radios. I have lately started to worry about the risks of silent data corruption, and as such, looked to switch my personal systems to either ZFS or btrfs, both of which offer built-in checksumming of all data and metadata. I initially opted for btrfs, because of its tighter integration into the Linux kernel and ability to shrink an existing btrfs filesystem. However, as I wrote last month, that experiment was not a success. I had too many serious performance regressions and one too many kernel panics and decided it wasn t worth it. And that the SuSE people got it wrong, deeply wrong, when they declared btrfs ready for production. I never lost any data, to its credit. But it simply reduces uptime too much. That left ZFS. Before I build a system, I always want to make sure I can repair it. So I started with the Debian Live rescue image, and added the zfsonlinux.org repository to it, along with some key packages to enable the ZFS kernel modules, GRUB support, and initramfs support. The resulting image is described, and can be downloaded from, my ZFS Rescue Disc wiki page, which also has a link to my source tree on github. In future blog posts in the series, I will describe the process of converting existing Debian installations to use ZFS, of getting them to boot from ZFS, some bugs I encountered along the way, and some surprising performance regressions in ZFS compared to ext4 and btrfs.

A bug fix release of Armadillo came out and was turned into a new RcppArmadillo release which is now on CRAN and will go shortly to Debian. The complete list of changes is below.

Changes in RcppArmadillo version 0.4.000.2 (2014-01-21)

• Upgraded to Armadillo release Version 4.000.2
  • fix for randi() generating out-of-interval values
  • workaround for a bug in the Intel compiler

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.

One week before the wedding, to Laura: Mono won t just clear up right away. One week before the wedding, to me: That s going to need stitches. Yes, not long before the wedding, Laura had come down with mononucleosis and I had cut into my finger with a very sharp knife while cutting bread requiring a trip to the emergency room to get stitches. Two days before we got married, instead of moving furniture, I was getting stitches out of my finger. It wasn t the kind of week we had planned. But it was the happiest, most amazing occasion I could have ever imagined. As I wrote last month, I am richly blessed indeed. Our wedding was three days after Christmas. The church was still decorated for Christmas, with the tree in on corner, glittering stars suspended in mid-air on cables from the walls, wreaths and candles in the windows, and it was a joy-filled day. Before the ceremony, we took pictures the only part of the day Jacob and Oliver weren t thrilled with. Nevertheless, we got some fun ones. Laura and I seem to know quite a few pastors between us and not just because Laura is a pastor. My brother officiated with the wedding vows, his wife with scripture and a prayer of blessing, and the church s pastor gave the message. Laura and I wrote in our wedding program, Music has long been a thread running through both our lives. We have enjoyed singing together, playing piano and pennywhistle duets, attending concerts, and even exploring old hymnals. Music is also one of the best ways to have a conversation even a conversation with God. We wrote a page in the program about each of the hymns that were a part of the wedding, and why we picked them. The combined church choirs of my home church and Laura s church sang John Rutter s beautiful arrangement of For the Beauty of the Earth (click here to listen to a different choir). Hearing For the beauty of each hour , For the joy of human love , and Lord of all, to thee we raise this our joyful hymn of praise was perfect for the day. It was with such great happiness that we walked out of the sanctuary, a married couple, to the sound of the congregation singing Joy to the World! Jacob and Oliver were so very excited on our wedding day. They happily explored the church while waiting for things to happen. We had them help us light our unity candle, and they were pleased with that. Jacob loved his suit, which made him look just like me. And they were, of course, delighted with the cake and in the middle of it all. For our honeymoon, we managed to get two weeks of vacation, and spent about half of it at home. We had looked at various options for retreats in the country, but eventually concluded that our house is a retreat in the country, so might as well enjoy it at home. We also went to the Palo Duro Canyon area near Amarillo in the Texas panhandle, staying in a small B&B in Canyon, TX. Palo Duro is the second-largest canyon in North America, and quite colorful year-round. What a beautiful place to go for our honeymoon! By the time we got there, Laura was getting past mono, and we went for hikes in the canyon on two different days hiking a total of 10 miles, including a hike up the side of the canyon. After we got back home, on the last weekday of our honeymoon, we went back to the Flint Hills of Kansas, to some of the same places we had spent our third date. We climbed the windy staircase at the Chase County Courthouse, the oldest courthouse still in use in Kansas. And peered out its famous oval window. We found the last remnant of the old ghost town of Elk, ate at the same restaurant we had that day. It brought back wonderful memories, and it was a good day in itself. Because even though it was a gold, drizzly, overcast day in January, this time, we were married. And this year, Thanksgiving is all year.

Quest for a terminal emulator The requirements I need a terminal emulator. This is a checklist of the features that I need:

• Foreground colour: #aaaaaa.
• Background colour: black.
• "Linux console" colour palette.
• Font: Monospace-10.
• Alt+Fnn to directly switch to one of the first 12 terminals, like in the Linux console.
• F11 to toggle fullscreen.
• Alt+'+', Alt+'-', Alt+'0' to control font sizes.
• All other keybindings disabled, so that terminal programs are free to use them.
• I occasionally need to switch to black-on-white for presentations.
• Tabs.
• When I open a new tab it needs to contain a shell opened inside the same directory of the last tab I was in. The way I normally start working is something like: cd workdir; x-terminal-emulator -e vim todolist and then I start opening new tabs.
• I need -e to work. In fact, I need the terminal to work as x-terminal-emulator -e cmd args...
• I need to conveniently pick a URL in a terminal and open it in Chromium, and not any other browser. Even better, open it in x-www-browser

My experience is that getting all of this to work is not being as easy as it seems, so I'm creating this page to track progress. gnome-terminal I've been happily using this for years, and it did everything I needed, until some months ago it started to open new tabs in the terminal's working directory instead of the last tab's working directory. This is a big point of frustration for me. It also started opening https urls with Firefox, although the preferred browser was Chromium. There seemed to be no way to control it: I looked for firefox or iceweasel in all gconf and dconf settings and found nothing. The browser issue was fixed by accident when I used Xfce4's settings application to change the browser from Chromium to Firefox and then back to Chromium. update, thanks to Mathieu Parent, Josh Triplett, Peter De Wachter, Julien Cristau, and Charles Plessy: It is also possible to restore the "new tab opened inside the same directory of the last tab I was in" behaviour, by enabling "run command as a login shell" so that /etc/profile.d/vte.sh is run (thanks Mathieu Parent for the link). That in turn spawned extra cleanup work in my .bashrc/.bash_profile/.profile setup, which has been randomly evolving since even before my first Debian "buzz" system. I found that it was setting PROMPT_COMMAND to something else to set the terminal title, conflicting with what vte.sh wants to do. With regards to loading /etc/profile.d/vte.sh by default, Peter De Watcher sent pointers to relevant bugs: here, here, and here. An alternative strategy is to work using the prompt rather than PROMPT_COMMAND; an example is in Josh Triplett's .bashrc from git://joshtriplett.org/git/home. Josh Triplett also said:

To fix the browser launched for URLs, you either need to use a desktop environment following GNOME's mechanism for setting the default browser, or edit ~/.local/share/applications/mimeapps.list and make sure x-scheme-handler/http, x-scheme-handler/https, and x-scheme-handler/ftp are set to your preferred browser's desktop file basename under [Added Associations].

All my issues with gnome-terminal are now gone and I'm only too happy to go back to it. rxvt-unicode-256color urxvt took some work. This is where I got with configuration:

URxvt.font: xft:Monospace-10:antialias=true
URxvt.foreground: #aaaaaa
URxvt.background: black
URxvt.scrollBar_right: true
URxvt.cursorBlink: true
URxvt.perl-ext-common: default,matcher,tabbedex
URxvt.url-launcher: /usr/bin/x-www-browser
URxvt.matcher.button: 1
URxvt.perl-lib: /home/enrico/.urxvt/perl
URxvt.color0: black
URxvt.color1: #aa0000
URxvt.color2: #00aa00umask
URxvt.color3: #aa5500
URxvt.color4: #0000aa
URxvt.color5: #aa00aa
URxvt.color6: #00aaaa
URxvt.color7: #aaaaaa
URxvt.color8: #555555
URxvt.color9: #ff5555
URxvt.color10: #55ff55
URxvt.color11: #ffff55
URxvt.color12: #5555ff
URxvt.color13: #ff55ff
URxvt.color14: #55ffff
URxvt.color15: #ffffff

I got all of the tab behaviour that I need by "customizing" the tab script (yuck github ). Missing

• Bold fonts only work if I set TERM=rxvt
• The implementation for opening a new tab in the directory of the current tab is rather fragile.
• Resizing the terminal window causes an annoying flicker

sakura Configuration is in .config/sakura/sakura.conf and these bits help:

colorset1_fore=rgb(170,170,170)
colorset1_back=rgb(0,0,0)
colorset1_opacity=99
colorset2_fore=rgb(0,0,0)
colorset2_back=rgb(254,254,254)
colorset2_opacity=99
font=Monospace 10
show_always_first_tab=No
scrollbar=false
fullscreen_key=F11
palette=linux

Missing

• Alt+Fnn to directly switch to one of the first 12 terminals, like in the Linux console. Sakura hardcodes using numbers for switching, and only allows to change the modifier.
• Alt+'+', Alt+'-', Alt+'0' to control font sizes.
• Tabs are huge and take way too much screen space.

lxterminal Configuration is in .config/lxterminal/lxterminal.conf and this is relevant to me:

[general]
fontname=DejaVu Sans Mono 10
fgcolor=#aaaaaaaaaaaa
disallowbold=false
cursorblinks=true
tabpos=top
hidescrollbar=false
hidemenubar=true
hideclosebutton=true
disablef10=true
disablealt=true

Also, to open a url directly you control+click it. Missing

• Alt+Fnn to directly switch to one of the first 12 terminals, like in the Linux console.
• F11 to toggle fullscreen.
• Alt+'+', Alt+'-', Alt+'0' to control font sizes.
• I occasionally need to switch to black-on-white for presentations: this is inconvenient, as it requires to set foreground and background separately each time.

terminator Configuration is in .config/terminator/config and this is relevant to me:

[global_config]
  use_custom_url_handler = True
  custom_url_handler = x-www-browser
  inactive_color_offset = 1.0
[keybindings]
  close_term = None
  close_window = None
  copy = None
  cycle_next = None
  cycle_prev = None
  go_down = None
  go_next = None
  go_prev = None
  go_up = None
  group_all = None
  group_tab = None
  hide_window = None
  move_tab_left = None
  move_tab_right = None
  new_tab = None
  new_terminator = None
  new_window = None
  next_tab = None
  paste = None
  prev_tab = None
  reset_clear = None
  reset = None
  resize_down = None
  resize_left = None
  resize_right = None
  resize_up = None
  rotate_ccw = None
  rotate_cw = None
  scaled_zoom = None
  search = None
  split_horiz = None
  split_vert = None
  switch_to_tab_1 = <Alt>F1
  switch_to_tab_2 = <Alt>F2
  switch_to_tab_3 = <Alt>F3
  switch_to_tab_4 = <Alt>F4
  switch_to_tab_5 = <Alt>F5
  switch_to_tab_6 = <Alt>F6
  switch_to_tab_7 = <Alt>F7
  switch_to_tab_8 = <Alt>F8
  switch_to_tab_9 = <Alt>F9
  switch_to_tab_10 = <Alt>F10
  toggle_scrollbar = None
  toggle_zoom = None
  ungroup_all = None
  ungroup_tab = None
[profiles]
  <span class="createlink">default</span>
    palette = "#000000:#aa0000:#00aa00:#aa5500:#0000aa:#aa00aa:#00aaaa:#aaaaaa:#555555:#ff5555:#55ff55:#ffff55:#5555ff:#ff55ff:#55ffff:#ffffff"
    copy_on_selection = True
    icon_bell = False
    background_image = None
    show_titlebar = False

Missing

• I need -e to work. In fact, I need the terminal to work as x-terminal-emulator -e cmd args.... #734655 but should be fixed soon
• New windows start with the title bar visible, even if I configured it not to show. It disappears as soon as the window gets focused, causing the terminal contents to resize. It is just a glitch, but oh so annoying!

update: Richard Hartmann pointed out that terminator's upstream maintainer now changed after the old one didn't have time any more, and it should have a release with a ton of improvements anytime soon. xfce4-terminal Configuration is in .config/xfce4/terminal, and this is relevant to me: terminalrc:

[Configuration]
FontName=Monospace 10
MiscAlwaysShowTabs=FALSE
MiscBell=FALSE
MiscBordersDefault=TRUE
MiscCursorBlinks=FALSE
MiscCursorShape=TERMINAL_CURSOR_SHAPE_BLOCK
MiscDefaultGeometry=80x24
MiscInheritGeometry=FALSE
MiscMenubarDefault=FALSE
MiscMouseAutohide=FALSE
MiscToolbarDefault=FALSE
MiscConfirmClose=TRUE
MiscCycleTabs=TRUE
MiscTabCloseButtons=TRUE
MiscTabCloseMiddleClick=TRUE
MiscTabPosition=GTK_POS_TOP
MiscHighlightUrls=TRUE
ShortcutsNoMenukey=TRUE
ShortcutsNoMnemonics=TRUE
ColorForeground=#aaaaaaaaaaaa

accels.scm:

(gtk_accel_path "<Actions>/terminal-window/goto-tab-1" "<Alt>F1")
(gtk_accel_path "<Actions>/terminal-window/goto-tab-2" "<Alt>F2")
(gtk_accel_path "<Actions>/terminal-window/goto-tab-3" "<Alt>F3")
(gtk_accel_path "<Actions>/terminal-window/goto-tab-4" "<Alt>F4")
(gtk_accel_path "<Actions>/terminal-window/goto-tab-5" "<Alt>F5")
(gtk_accel_path "<Actions>/terminal-window/goto-tab-6" "<Alt>F6")
(gtk_accel_path "<Actions>/terminal-window/goto-tab-7" "<Alt>F7")
(gtk_accel_path "<Actions>/terminal-window/goto-tab-8" "<Alt>F8")
(gtk_accel_path "<Actions>/terminal-window/goto-tab-9" "<Alt>F9")
(gtk_accel_path "<Actions>/terminal-window/goto-tab-10" "<Alt>F10")
(gtk_accel_path "<Actions>/terminal-window/goto-tab-11" "<Alt>F11")
(gtk_accel_path "<Actions>/terminal-window/goto-tab-12" "<Alt>F12")

update: Yves-Alexis Perez points out that to disable the F1 for help in the terminal, you need to remove the accelerator. I tried this and this and didn't have success, but I confess I did not dig too much into it. Although xfce4-terminal -e does not work as I expect, xfce4-terminal registers a wrapper for x-terminal-emulator that does the right thing with respect to -e (also thanks Yves-Alexis Perez). Missing

• Alt+'+', Alt+'-', Alt+'0' to control font sizes.
• All other keybindings disabled, so that terminal programs are free to use them. I could not find a way to disable F1 for help.
• I occasionally need to switch to black-on-white for presentations. I can switch to a "Black on white" preset, but there is no "Gray on black" to switch back to. I can switch back to "White on black", but then I need to manually set the text colour to #aaaaaa. update: Yves-Alexis Perez found that you can add presets to .local/share/colorthemes taking examples from /usr/share/xfce4/terminal/colorschemes; next time I consider switching to xfce4-terminal I'll try that.

roxterm Configuration is in .config/roxterm.sourceforge.net/ split in several files corresponding to profiles. This is a reasonable starting point for me: Profiles/Default:

[roxterm profile]
colour_scheme=Default
disable_menu_access=1
disable_menu_shortcuts=1
disable_tab_menu_shortcuts=0
tab_close_btn=0
hide_menubar=1
always_show_tabs=0

Colours/Default:

[roxterm colour scheme]
0=#000000000000
1=#aaaa00000000
2=#0000aaaa0000
3=#aaaa55550000
4=#00000000aaaa
5=#aaaa0000aaaa
6=#0000aaaaaaaa
7=#aaaaaaaaaaaa
8=#555555555555
9=#ffff55555555
10=#5555ffff5555
11=#ffffffff5555
12=#55555555ffff
13=#ffff5555ffff
14=#5555ffffffff
15=#ffffffffffff
palette_size=16
foreground=#aaaaaaaaaaaa
background=#000000000000
cursor=#cccccccccccc
bold=
dim=

Shortcuts/Default:

[roxterm shortcuts scheme]
File/New Window=
File/New Tab=
File/Close Window=
File/Close Tab=
Tabs/Previous Tab=
Tabs/Next Tab=
Edit/Copy=
Edit/Paste=
View/Zoom In=<Control>plus
View/Zoom Out=<Control>minus
View/Normal Size=<Control>0
View/Full Screen=F11
View/Scroll Up One Line=
View/Scroll Down One Line=
Help/Help=
Edit/Copy & Paste=
Search/Find...=
Search/Find Next=
Search/Find Previous=
File/New Window With Profile/Default=
File/New Tab With Profile/Default=
Tabs/Select_Tab_0=<Alt>F1
Tabs/Select_Tab_1=<Alt>F2
Tabs/Select_Tab_2=<Alt>F3
Tabs/Select_Tab_3=<Alt>F4
Tabs/Select_Tab_4=<Alt>F5
Tabs/Select_Tab_5=<Alt>F6
Tabs/Select_Tab_6=<Alt>F7
Tabs/Select_Tab_7=<Alt>F8
Tabs/Select_Tab_8=<Alt>F9
Tabs/Select_Tab_9=<Alt>F9
Tabs/Select_Tab_10=<Alt>F10
Tabs/Select_Tab_11=<Alt>F11
Tabs/Select_Tab_12=<Alt>F12

Global:

[roxterm options]
edit_shortcuts=0
prefer_dark_theme=1
colour_scheme=Default
warn_close=1

Missing Nothing of my initial requirements seems to be missing, really, so I'm sticking to it for a while to see what happens. The first itch to scratch is that when the menubar is hidden, the popup menu becomes the entire menubar contents, which does not fit the general use case to have a contextual menu with the most common shortcuts. I'll just declare it useless and get myself used to some new hotkey for starting a new terminal. update: after fixing my issues with gnome-terminal I've switched back to gnome-terminal: its interface feels less clunky as I'm already used to it. Other references Guillem Jover made a similar analysis in 2009, it can be found here. Thomas Koch mentioned that termit should be able to do all I need, and is scriptable in Lua. I like the sound of that, and it's definitely one I should look next time I find myself shopping for terminal emulators.

A new major release 0.4.0 of RProtoBuf, is now on CRAN. RProtoBuf provides GNU R bindings for the Google Protocol Buffers ("Protobuf") data encoding library used and released by Google, and deployed as a language and operating-system agnostic protocol by numerous projects. With this release, we are welcoming Jeroen Ooms to the team. Jeroen had already worked on some RProtoBuf extensions in the context of his OpenCPU project; we have now integrated those Protocol Buffers functions. And Jeroen pushed all the right buttons to finally get RProtoBuf built on everybody's least-favourite operating system by provding a static library for use by win-builder and CRAN. Murray once again did a lot of work on internals. His use of the LLVM tool llvm-format was particular helpful to make our coding style a little more consistent. The complete NEWS file entry for this release follows:

Changes in RProtoBuf version 0.4.0 (2014-01-14)

• Changes to support CRAN builds for MS Windows.
• Added functions serialize_pb, unserialize_pb, and can_serialize_pb plus documentation from Jeroen Ooms RProtoBufUtils package.
• New dir inst/python with some Python examples.
• Added Jeroen Ooms as author.
• Vignettes have been converted to the R 3.0.0 or later use of external vignette builders, no longer need a Makefile
• Added missing methods to dollar completion list for Message, Descriptor, EnumValueDescriptor, and FileDescriptor classes.
• Add missing export for .DollarNames EnumValueDescriptor to allow completion on that class.
• Add more than 15 additional pages to the main Intro vignette documenting better all of the S4 classes implemented by RProtoBuf, updating the type mapping tables to take into account 64-bit support, and documenting advanced features such as Extensions.
• Added better error checking in EnumDescriptors to catch the case when wrong types are provided.
• Updated the FileDescriptor name() method to accept a boolean for full paths just like the generic name() method.
• Correct a bug that incorrectly dispatched as.character() when as.list() was called on Descriptor objects.
• Update FileDescriptor $ dispatch to work properly for the names of fields defined in the FileDescriptor, instead of just returning NULL even for types returned by $ completion.
• Added a reservation for extension fields in the example tutorial.Person schema.
• Support setting int32 fields with character representations and raise an R-level stop() error if the provided string can not be parsed as a 32-bit integer, rather than crashing the R instance.
• Update the project TODO file.
• Add better documentation and tests for all of the above.
• Corrected the handling of uint32 and fixed32 types in protocol buffers to ensure that they work with numbers as large as 2^32 - 1, which is larger than an integer can hold in R since R does not have an unsigned integer class. These values are stored as doubles internally now to avoid losing precision.
• Added unit tests to verify behavior of RProtoBuf with extreme values for uint32 types.
• Removed old exception handling code and instead rely on the more modern Rcpp::stop method maintained in Rcpp.
• Add better error messages when setting a repeated field of messages to inform the user which element index was of the wrong type and what the expected type was.
• Add an optional 'partial' argument to readASCII allowing uninitialized message fragments to be read in.
• (internal) Added const qualifiers in more places throughout the C++ code for type safety.
• (internal) Standardize coding conventions of the C++ files and run them through clang-format for consistency. A STYLE file has been submitted to R-Forge with details about the coding standards and how they are enforced with Emacs and clang-format.
• Applied changes suggested by Kevin Ushey to the S4 class handling to support both the currently released Rcpp as well as the currently pending next version.

CRANberries also provides a diff to the previous release 0.3.2. More information is at the RProtoBuf page which has a draft package vignette, a 'quick' overview vignette and a unit test summary vignette. Questions, comments etc should go to the rprotobuf mailing list off the RProtoBuf page at R-Forge.

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 was back at my parents' over Christmas, like usual. Before I got back my Dad had mentioned they'd been having ADSL stability issues. Previously I'd noticed some issues with keeping a connection up for more than a couple of days, but it had got so bad he was noticing problems during the day. The eventual resolution isn't going to surprise anyone who's dealt with these things before, but I went through a number of steps to try and improve things. Firstly, I arranged for a new router to be delivered before I got back. My old Netgear DG834G was still in use and while it didn't seem to have been the problem I'd been meaning to get something with 802.11n instead of the 802.11g it supports for a while. I ended up with a TP-Link TD-W8980, which has dual band wifi, ADSL2+, GigE switch and looked to have some basic OpenWRT support in case I want to play with that in the future. Switching over was relatively simple and as part of that procedure I also switched the ADSL microfilter in use (I've seen these fail before with no apparent cause). Once the new router was up I looked at trying to get some line statistics from it. Unfortunately although it supports SNMP I found it didn't provide the ADSL MIB, meaning I ended up doing some web scraping to get the upstream/downstream sync rates/SNR/attenuation details. Examination of these over the first day indicated an excessive amount of noise on the line. The ISP offer the ability in their web interface to change the target SNR for the line. I increased this from 6db to 9db in the hope of some extra stability. This resulted in a 2Mb/s drop in the sync speed for the line, but as this brought it down to 18Mb/s I wasn't too worried about that. Watching the stats for a further few days indicated that there were still regular periods of excessive noise, so I removed the faceplate from the NTE5 master BT socket, removing all extensions from the line. This resulted in regaining the 2Mb/s that had been lost from increasing the SNR target, and after watching the line for a few days confirmed that it had significantly decreased the noise levels. It turned out that the old external ringer that was already present on the line when my parents' moved in was still connected, although it had stopped working some time previously. Also there was an unused and much spliced extension in place. Removed both of these and replacing the NTE5 faceplate led to a line that was still stable. At the time of writing the connection has been up since before the new year, significantly longer than it had managed for some time. As I said at the start I doubt this comes as a surprise to anyone who's dealt with this sort of line issue before. It wasn't particularly surprising to me (other than the level of the noise present), but I went through each of the steps to try and be sure that I had isolated the root cause and could be sure things were actually better. It turned out that doing the screen scraping and graphing the results was a good way to verify this. Observe: The blue/red lines indicate the SNR for the upstream and downstream links - the initial lower area is when this was set to a 6db target, then later is a 9db target. Green are the forward error correction errors divided by 100 (to make everything fit better on the same graph). These are correctable, but still indicate issues. Yellow are CRC errors, indicating something that actually caused a problem. They can be clearly seen to correlate with the FEC errors, which makes sense. Notice the huge difference removing the extensions makes to both of these numbers. Also notice just how clear graphing the data makes things - it was easy to show my parents' the graph and indicate how things had been improved and should thus be better.

The radio silence here on my blog has been not from lack of activity, but the inverse. Linux.conf.au chewed up the few remaining spare cycles I have had recently (after family and work), but not from organising the conference (been there, got the T-Shirt and the bag). So, let s do a run through of what has happened LCA2014 Perth has come and gone in pretty smooth fashion. A remarkable effort from the likes of the Perth crew of Luke, Paul, Euan, Leon, Jason, Michael, and a slew of volunteers who stepped up not to mention our interstate firends of Steve and Erin, Matthew, James I, Tim the Streaming guy and others, and our pro organisers at Manhattan Events. It was a reasonably smooth ride: the UWA campus was beautiful, the leacture theatres were workable, and the Octogon Theatre was at its best when filled with just shy of 500 like minded people and an accomplished person gracing the stage. What was impressive (to me, at least) was the effort of the AV team (which I was on the extreme edges of); videos of keynotes hit the Linux Australia mirror within hours of the event. Recording and live streaming of all keynotes and sessions happend almost flawlessly. Leon had built a reasonably robust video capture management system (eventstreamer on github) to ensure that people fresh to DVswitch had nothing break so bad it didn t automatically fix itself and all of this was monitored from the Operations Room (called the TAVNOC, which would have been the AV NOC, but somehow a loose reference to the UWA Tavern the Tav crept in there). Some 167 videos were made and uploaded most of this was also mirrored on campus before th end of the conference so attendees could load up their laptops with plenty of content for the return trip home. Euan s quick Blender work meant there was a nice intro and outro graphic, and Leon s scripting ensured that Zookeepr, the LCA conference manegment software, was the source of truth in getting all videos processed and tagged correctly. I was scheduled (and did give) a presentation at LCA 2014 about Debian on Amazon Web Services (on Thursday), and attended as many of the sessions as possible, but my good friend Michael Davies (LCA 2004 chair, and chair of the LCA Papers Committee for a good many years) had another role for this year. We wanted to capture some of the hallway track of Linux.conf.au that is missed in all the videos of presentations. And thus was born LCA TV. LCA TV consisted of the video equipment for an additional stream mixer host, cameras, cables and switches, hooking into the same streaming framework as the rest of the sessions. We took over a corner of the registration room (UWA Undercroft), brought in a few stage lights, a couch, coffee table, seat, some extra mics, and aimed to fill the session gaps with informal chats with some of the people at Linux.conf.au speakers, attendees, volunteers alike. And come they did. One or two interviews didn t succeed (this was an experiment), but in the end, we ve got over 20 interviews with some interesting people. These streamed out live to the people watching LCA from afar; those unable to make it to Perth in early January; but they were recorded too and we can start to watch them (see below) I was also lucky enough to mix the video for the three keynotes as well as the opening and closing, with very capable crew around the Octogon Theatre. As the curtain came down, and the 2014 crew took to the stage to be congratulated by the attendees, I couldn t help but feel a little bit proud and a touch nostalgic memories from 11 years earlier when LCA 2003 came to a close in the very same venue. So, before we head into the viewing season for LCA TV, let me thank all the volunteers who organised, the AV volunteers, the Registration volunteers, the UWA team who helped with Octogon, Networking, awesome CB Radios hooked up to the UWA repeated that worked all the way to the airport. Thanks to the Speakers who submitted proposals. The Speakers who were accepted, made the journey and took to the stage. The people who attended. The sponsors who help make this happen. All of the above helps share the knowledge, and ultimately, move the community forward. But my thanks to Luke and Paul for agreeing to stand there in the middle of all this madness and hive of semi structured activity that just worked. Please remember this was experimental; the noise was the buzz of the conference going on around us. There was pretty much only one person on the AV kit my thanks to Andrew Cooks who I ll dub as our sound editor, vision director, floor manager, and anything else. So who did we interview?

• Alan Robertson (Assim Proj)
• Arjen Lentz (twice well, two topics!)
• Daniel (A student at LCA for the first time)
• Dave Chinner (XFS)
• Erin Walsh (Rego desk manager)
• Jason Nicholls (AV Director LCA 2014)
• Jeremy Kerr (Kernel Developer)
• Jessica Smith (Astronomy Mini Conf)
• Jono Oxer (Audosat)
• Karen Sandler (Gnome)
• Keith Packard (X) and BDale Garbee (Freedom Box, Debian)
• Kevin Vinsen (ICRAR, Square Kilometer Array)
• Lennart Poettering (SystemD)
• Linus Torvalds (Yet another Kernel Developer)
• Matthew Wilcox (Another Kernel dev, and a Debian Dev as well)
• Michael Still (OpenStack)
• Paul Weyper (Canberra Linus Users Group)
• Paul Wise (Debian)
• Pia Waugh (Open Government)
• Rusty Russel (Yet another Kernel Developer! Oh, and started LCA in 1999)

One or two talks did not work, so appologies to those that are missing. Here s the playlist to start you off! Enjoy.

This is mostly a repost of my ubuntu-devel mail for a wider audience, but see below for some additions. I'd like to upgrade to GRUB 2.02 for Ubuntu 14.04; it's currently in beta. This represents a year and a half of upstream development, and contains many new features, which you can see in the NEWS file. Obviously I want to be very careful with substantial upgrades to the default boot loader. So, I've put this in trusty-proposed, and filed a blocking bug to ensure that it doesn't reach trusty proper until it's had a reasonable amount of manual testing. If you are already using trusty and have some time to try this out, it would be very helpful to me. I suggest that you only attempt this if you're comfortable driving apt-get directly and recovering from errors at that level, and if you're willing to spend time working with me on narrowing down any problems that arise. Please ensure that you have rescue media to hand before starting testing. The simplest way to upgrade is to enable trusty-proposed, upgrade ONLY packages whose names start with "grub" (e.g. use apt-get dist-upgrade to show the full list, say no to the upgrade, and then pass all the relevant package names to apt-get install), and then (very important!) disable trusty-proposed again. Provided that there were no errors in this process, you should be safe to reboot. If there were errors, you should be able to downgrade back to 2.00-22 (or 1.27+2.00-22 in the case of grub-efi-amd64-signed). Please report your experiences (positive and negative) with this upgrade in the tracking bug. I'm particularly interested in systems that are complex in any way: UEFI Secure Boot, non-trivial disk setups, manual configuration, that kind of thing. If any of the problems you see are also ones you saw with earlier versions of GRUB, please identify those clearly, as I want to prioritise handling regressions over anything else. I've assigned myself to that bug to ensure that messages to it are filtered directly into my inbox. I'll add a couple of things that weren't in my ubuntu-devel mail. Firstly, this is all in Debian experimental as well (I do all the work in Debian and sync it across, so the grub2 source package in Ubuntu is a verbatim copy of the one in Debian these days). There are some configuration differences applied at build time, but a large fraction of test cases will apply equally well to both. I don't have a definite schedule for pushing this into jessie yet - I only just finished getting 2.00 in place there, and the release schedule gives me a bit more time - but I certainly want to ship jessie with 2.02 or newer, and any test feedback would be welcome. It's probably best to just e-mail feedback to me directly for now, or to the pkg-grub-devel list. Secondly, a couple of news sites have picked this up and run it as "Canonical intends to ship Ubuntu 14.04 LTS with a beta version of GRUB". This isn't in fact my intent at all. I'm doing this now because I think GRUB 2.02 will be ready in non-beta form in time for Ubuntu 14.04, and indeed that putting it in our development release will help to stabilise it; I'm an upstream GRUB developer too and I find the exposure of widely-used packages very helpful in that context. It will certainly be much easier to upgrade to a beta now and a final release later than it would be to try to jump from 2.00 to 2.02 in a month or two's time. Even if there's some unforeseen delay and 2.02 isn't released in time, though, I think nearly three months of stabilisation is still plenty to yield a boot loader that I'm comfortable with shipping in an LTS. I've been backporting a lot of changes to 2.00 and even 1.99, and, as ever for an actively-developed codebase, it gets harder and harder over time (in particular, I've spent longer than I'd like hunting down and backporting fixes for non-512-byte sector disks). While I can still manage it, I don't want to be supporting 2.00 for five more years after upstream has moved on; I don't think that would be in anyone's best interests. And I definitely want some of the new features which aren't sensibly backportable, such as several of the new platforms (ARM, ARM64, Xen) and various networking improvements; I can imagine a number of our users being interested in things like optional signature verification of files GRUB reads from disk, improved Mac support, and the TrueCrypt ISO loader, just to name a few. This should be a much stronger base for five-year support.

Being a bit hyperactive, I have been involved in the organization of two events. I am the main organizer with Alexandre Delano of the Mini Debconf 2014 in Paris, January 18 & 19th. The (great) planning is available here:
https://france.debian.net/events/minidebconf2014/
Saturday morning presentations will be general public, the beginning of Saturday afternoon will be used by the Debian France association to vote the new status (1901 law and Debian Trusted Organization).
Sunday will be more focused on Debian itself.
During the week end, I will be talking about the Debile project, the finance of Debian France and be part of the round table on compiler selection for Debian.
The (mandatory) registration should be done on the Wiki or meetup.com In parallel, with Tobias Grosser, we organized the LLVM devroom track at FOSDEM (Bruxelles), February 2nd (Sunday).
The schedule is a mix between core developers, third party software using LLVM / Clang and academic users.
https://fosdem.org/2014/schedule/track/llvm/
I will be talking on how to become a LLVM contributor. Both events should be recorded.

Somalia's chief exports appear to be morally-ambiguous Salon articles about piracy and sophomoric evidence against libertarianism. However, it is the former topic that Captain Phillips concerns itself with, inspired by the hijacking of the Maersk Alabama container ship in 2009. What is truth? In the end, Captain Phillips does not rise above Pontius Pilate in providing an answer, but it certainly tries using more refined instruments than irony or leaden sarcasm. This motif pervades the film. Obviously, it is based on a "true story" and brings aboard that baggage, but it also permeates the plot in a much deeper sense. For example, Phillips and the US Navy lie almost compulsively to the pirates, whilst the pirates only really lie once (where they put Phillips in greater danger). Notice further that Phillips only starts to tell the truth when he thinks all hope is lost. These telling observations become even more fascinating when you realise that they must be based on the testimony of the, well, liars. Clearly, deception is a weapon to be monopolised and there are few limits on what good guys can or should lie about if they believe they can save lives. Futhermore, there is an utterly disarming epilogue where Phillips is being treated for shock by clinical efficient medical staff. Not only will this scuttle any "blanket around the shoulders" clich but is probably a highly accurate portrayal of what actually happens post-trauma. This echoes the kind of truth Werner Herzog aims for in his filmmaking as well his guilt-inducing duality between uncomfortable lingering and compulsive viewing. Lastly, a starter for a meta-discussion: can a film based on real-world events even be "spoilered"? Hearing headlines on the radio before you read your newspaper hardly robs you of a literary journey... Captain Phillips does have some quotidian problems. Firstly, the only tool for ratcheting up tension is for the Somalians to launch verbal broadsides at the Americans, with each compromise somehow escalating the situation. This technique is effective but well before the climatic rescue scene where it is really needed it has been subject to the most extreme diminishing returns. (I cannot be the first to notice the "Africans festooned with guns shouting incomphensively" trope I hope it is based on a Babel-esque mechanism of disorientation from miscommunication rather than anything more unsavoury.) Secondly, the US Navy acts like a teacher with an Ofsted inspector observing quietly from the corner of the classroom; far too well-behaved it suspends belief, with no post-kill gloating or even the tiniest of post-arrest congratulations. Whilst nobody wants to see the Navy overreact badly to other military branches getting all the glory, nobody wants to see a suspiciously bland recruitment vehicle either. Paradoxically, this hermetic treatment made me unduly fascinated by them as if they were part of some military "uncanny valley". Two quick observations:

• All US Somali interactions are recorded by a naval officer. No doubt a value-for-money defense against a USS Abu Ghraib, but knowing the plot is based on factual events, it was perhaps a little too Baudrillardian to ponder how the presence of the Navy's cameras in a scene actually lent weight to the film's version of events, crucially without me even knowing whether the parallel "real-life" footage is verifiable or not.
• The navigational computers not only seem to require lines to drawn repeatedly between points of interest, but the Maersk Alabama's arbitrary relabelling as MOTHERSHIP seems to imply that an officer could humourously rename a radar contact to something unbecoming of a 12A classification.

Finally, despite the title, the film is actually about two captains; the skillful liar Phillips and ... well, that's the real problem. Whilst Captain Muse is certainly no caricatured Hook, we are offered little depth beyond a "You're not just a fisherman" faux-revelation that leads nowhere. I was left inventing reasons for his akrasia so that he made any sense whatsoever. One could charitably argue that the film attempts to stay objective on Muse, but the inability for the film to take any obvious ethical stance actually seems to confuse and then compromise the narrative. What deeper truth is actually being revealed? Is this film or documentary? Worse still, the moral vacuum is invariably filled by the viewer's existing political outlook: are Somali pirates victims of circumstance who are forced into (alas, regrettable) swashbuckling adventures to pacify plank-threatening warlords? Or are they violent and dangerous criminals who habour an irrational resentment against the West, flimsily represented by material goods in shipping containers? Your improvised answer to this Rorschach test will always sit more haphazardly in the film than any pre-constructed treatment ever could. 6/10

Somalia's chief exports appear to be morally-ambiguous Salon articles about piracy and sophomoric evidence against libertarianism. However, it is the former topic that Captain Phillips concerns itself with, inspired by the hijacking of the Maersk Alabama container ship in 2009. What is truth? In the end, Captain Phillips does not rise above Pontius Pilate in providing an answer, but it certainly tries using more refined instruments than irony or leaden sarcasm. This motif pervades the film. Obviously, it is based on a "true story" and brings aboard all that well-travelled baggage, but it also permeates the plot in a much deeper sense. For example, Phillips and the US Navy lie almost compulsively to the pirates, whilst the pirates only really lie once where they put Phillips in greater danger. Notice further that Phillips only starts to tell the truth when he thinks all hope is lost. These telling observations become even more fascinating when you realise that they must be based on the testimony of the, well, liars. Clearly, deception is a weapon to be monopolised and there are few limits on what good guys can or should lie about if they believe they can save lives. Lastly, there is an utterly disarming epilogue where Phillips is being treated for shock by clinical efficient medical staff. Not only will it scuttle any "blanket around the shoulders" clich but is probably a highly accurate portrayal of what actually happens post-trauma. This echoes the kind of truth Werner Herzog often aims for in his filmmaking as well his guilt-inducing duality between uncomfortable lingering and compulsive viewing. Another angle worthy of discussion: can a film based on real-world events even be "spoilered"? Hearing headlines on the before you read the newspaper hardly robs you of a literary journey... Captain Phillips does have some quotidian problems. Firstly, the only tool for ratcheting up tension is for the Somalians to launch verbal broadsides at the Americans, with each compromise somehow escalating the situation further. This technique is genuinely effective but well before the climatic rescue scene where it is really needed it has been subject to the most extreme diminishing returns. (I cannot be the first to notice the "Africans festooned with guns shouting incomphensively" trope I hope it is based on a Babel-esque mechanism of disorientation and miscommunication rather than anything, frankly, unsavoury.) Secondly, the US Navy acts like a teacher with an Ofsted inspector observing quietly from the corner of the classroom; far too well-behaved it suspends belief, with no post-kill gloating or even the tiniest of post-arrest congratulations. Whilst nobody wants to see the Navy overreact badly to other military branches getting all the glory, nobody wants to see a suspiciously bland recruitment vehicle either. Paradoxically, this hermetic treatment made me unduly fascinated by them, as if they were part of some military "uncanny valley". Two quick observations:

• All US Somali interactions are recorded by a naval officer. No doubt a value-for-money defense against a USS Abu Ghraib, but knowing the plot is based on a factual events, it was perhaps a little too Baudrillardian to ponder how the presence of the Navy's cameras in a scene actually lent weight to the film's version of events, crucially without me even knowing whether the parallel "real life" footage is verifiable or not.
• The navigational computers not only seem to require lines to drawn repeatedly between points of interest, but the Maersk Alabama's arbitrary relabelling as MOTHERSHIP seems to imply that an officer could humourously rename a contact to something unbecoming of a 12A classification.

Finally, despite the title, the film is actually about two captains; the skillful liar Phillips and ... well, that's the real problem. Whilst Captain Muse is certainly no caricatured Hook, we are offered little depth beyond a "You're not just a fisherman" faux-revelation that leads nowhere. I was left inventing reasons for his akrasia so that he made any sense whatsoever. One could charitably argue that the film attempts to stay objective on Muse, but the inability for the film to take any obvious ethical stance actually seems to confuse and then compromise the narrative. What deeper truth is actually being revealed? Is this film or documentary? Worse still, the moral vacuum is invariably filled by the viewer's existing political outlook: are Somali pirates victims of circumstance who are forced into (alas, regrettable) swashbuckling adventures to pacify plank-threatening warlords? Or are they violent and dangerous criminals who habour an irrational resentment against the West, flimsily represented by material goods in shipping containers? Your improvised answer to this Rorschach test will always sit more haphazardly in the film than any pre-constructed treatment ever could. 6/10

I haven't been doing Debian work for a while now, due to various reasons. However, I try to keep reading (but not posting to) the mailing list, such as to keep in touch (in a virtual way). What surprises me is how the community evolves: in some ways not at all (was there an init-system flamewar this week already or not?), in some ways a lot (mailing list bans!). Since I don't post to the mailing lists, consider this post as my +1 towards the listmaster's work: yes, we should limit the damage that abusive people do to the project. I'm surprised at how some people call list bans as censorship (it's not, IMHO), and how they treat abuse as something light. Another thing that surprises me is how abuse and arrogance go hand in hand. In the explanations for bans, I've seen not just one example where the abusive person is not only, well, abusive, but also considers themselves superior (morally, technically, etc.). If you're already so much superior, why hit on people? If you already know so much, why the personal attacks? And no, being immature is not the whole or even the only explanation This page has a nice collection of quotes around the same motive: how you treat other people, especially people whom you regard less knowledgeable than you, tells a lot about your character. One quote is nice in how succinct and how applicable it is to the kind of abuse I've seen:

To insult or to abuse those who cannot resist, or dare not resent the injury, is a sure mark of cowardice, [ ].

From 1852 September 30, Farmer s Cabinet, Courtesy to Inferiors, Page 1, Column 2, Volume 51, Number 8, Amherst, New Hampshire. The rest of the quote also contains a somewhat sexist remark, so I've left that part out (but I'm surprised they still talked about swords in the 1850s). And yes, I hope that this spring I'll be able to get back to my Debian work.

Recently, North Tyneside Council circulated the beginnings of a regional development plan. This consisted of a detailed map of the borough, complete with various areas marked out as sites for potential housing development. Included amongst the sites for potential development was Whitley Bay Ice Rink and the surrounding leisure facilities: a football pitch, a cricket pitch, and more. Whitley Bay Ice Rink has been a fixture in the cultural history of the region and it would be a terrible shame if it were to close. Many people seemed to agree: a petition calling for the site to be excluded from the plan received over 7,000 signatures. Residents were also able to write comments on the plan itself. The specific paragraph for the Ice Rink had attracted over 100 comments when I looked at it on the last day that comments were open. I hurredly put together one of my own:

Whitley Bay Ice Rink is about to celebrate it s 60th birthday as both a key part of the history and culture of the borough and a unique leisure facility in the wider area. Sadly the Rink has seemed, historically, to be somewhat neglected, rather like the other large cultural landmark in the region - Whitley Bay s Spanish City and Dome. I argue you should no sooner consider closing or redeveloping the Rink site than the Dome itself. Rather, both should be cherished and invested in, particularly if (as rumoured) the current owners are keen to retire or pass it on. In recognising the need to increase the amount of housing in the area, one should consider what facilities will be available to the new residents within the region. Removing facilities to provide housing is slaying the golden goose. Whitley Bay Ice Rink is one of the few rinks left in the country and the nearest permanent ice rink within 30 miles. Ice skating has become a fond and lasting memory for many of the adults who have grown up in the region, many of whom enjoy or look forward to their own children experiencing it. I look forward to taking my niece and nephew there, when they are old enough, as well as my own future children. It is a traditional spot for School trips; the sports teams operating from the rink have a proud history and fearsome reputation. It s an attraction for the large numbers of University students that travel to the two nearest Universities. The borough is blighted with rotting seaside hotels which (following the recent development of the Idols site) should be converted into attractive flat or maisonette housing as a priority.

Coverity is a nice tool to find problems in C, C++ and Java code using static source code analysis. It can detect a lot of different problems, and is very useful to find memory and locking bugs in the error handling part of the source. The company behind it provide check of free software projects as a community service, and many hundred free software projects are already checked. A few days ago I decided to have a closer look at the Coverity system, and discovered that the gnash and ipmitool projects I am involved with was already registered. But these are fairly big, and I would also like to have a small and easy project to check, and decided to request checking of the chrpath project. It was added to the checker and discovered seven potential defects. Six of these were real, mostly resource "leak" when the program detected an error. Nothing serious, as the resources would be released a fraction of a second later when the program exited because of the error, but it is nice to do it right in case the source of the program some time in the future end up in a library. Having fixed all defects and added a mailing list for the chrpath developers, I decided it was time to publish a new release. These are the release notes: New in 0.16 released 2014-01-14:

• Fixed all minor bugs discovered by Coverity.
• Updated config.sub and config.guess from the GNU project.
• Mention new project mailing list in the documentation.

You can download the new version 0.16 from alioth. Please let us know via the Alioth project if something is wrong with the new release. The test suite did not discover any old errors, so if you find a new one, please also include a test suite check.

Abstract I recently moved our primary nameserver from orff.debian.org, which is an aging blade in Greece, to a VM on one of our ganeti clusters. In the process, I rediscovered a lot about our DNS infrastructure. In this post, I will describe the many sources of information and how they all come together.

Introduction The Domain Name System is the hierarchical database and query protocol that is in use on the Internet today to map hostnames to IP addresses, to map the reverse thereof, to lookup relevant servers for certain services such as mail, and a gazillion other things. Management and authority in the DNS is split into different zones, subtrees of the global tree of domain names. Debian currently has a bit over a score of zones. The two most prominents clearly are debian.org and debian.net. The rest is made up of debian domains in various other top level domains and reverse zones, which are utilized in IP address to hostname mappings.

Types and sources of information The data we put into DNS comes from a wide range of different systems:

• Classical zonefiles maintained in git. This represents the core of our domain data. It maps services like blends.debian.org to static.debian.org or specifies the servers responsible for accepting mail to @debian.org addresses. It also is where all the ftp.CC.debian.org entries are kept and maintained together with the mirror team.
• Information about debian.org hosts, such as master, is maintained in Debian's userdir LDAP, queryable using LDAP¹.
  • This includes first and foremost the host's IP addresses (v4 and v6).
  • Additionally, we store the server responsible for receiving a host's mail in LDAP (mXRecord LDAP attribute, DNS MX record type).
  • LDAP also has some specs on computers, which we put into each host's HINFO record, mainly because we can and we are old-school.
  • Last but not least, LDAP also has each host's public ssh key, which we extract into SSHFP records for DNS.
• LDAP also has per-user information. Users of debian infrastructure can attach limited DNS elements as dnsZoneEntry attributes to their user².
• The auto-dns system (more on that below).
• Our puppet also is a source of DNS information. Currently it generates only the TLSA records that enable clients to securely authenticate certificates used for mail and HTTPS, similar to how SSHFP works for authenticating ssh host keys.

Debian's auto-dns and geo setup We try to provide the best service we can. As such, our goal is that, for instance, user access to www or bugs should always work. These services are, thus, provided by more than one machine on the Internet. However, HTTP did not specify a requirement for clients to re-try a different server if one of those in a set is unavailable. This means for us that when a host goes down, it needs to be removed from the corresponding DNS entry. Ideally, the world wouldn't have to wait for one of us to notice and react before they can have their service in a working manner. Our solution for this is our auto-dns setup. We maintain a list of hosts that are providing a service. We monitor them closely. Whenever a server goes away or comes back we automatically rebuild the zone that contains the element. This setup also lets us reboot servers cleanly since one of the things we monitor is "is there a shutdown running", we can, simply by issuing a shutdown -r 30 kernel-update, de-rotate the machine in question from DNS. Once the host is back it'll automatically get re-added to the round-robin zone entry. The auto-dns system produces two kinds of output:

• In service-mode it generates a file with just the address records for a specific service. This snippet is then included in its zone using a standard bind $INCLUDE directive. Services that work like this include bugs and static (service definition for static).
• In zone-mode, auto-dns produces zonefiles. For each service it produces a set of zonefiles, one for each out of a set of different geographic regions. These individual zonefiles are then transferred using rsync to our GEO-IP enabled nameservers. This enables us to give users a list of security mirrors closer to them and thus hopefully faster for them.

Tying it all together Figure 1: The Debian DNS Rube Goldberg Machine. Once all the individual pieces of source information have been collected, the dns-update and write_zonefile scripts from our dns-helpers repository take over the job of building complete zonefiles and a bind configuration snippet. Bind then loads the zones and notifies its secondaries. For geozones, the zonefiles are already produced by auto-dns' build-zones and those are pulled from the geo nameservers via rsync over ssh, after an ssh trigger.

and also DNSSEC All of our zones are signed using DNSSEC. We have a script in dns-helpers that produces, for all zones, a set of rolling signing keys. For the normal zones, bind 9.9 takes care of signing them in-process before serving the zones to its secondaries. For our geo-zones we sign them in the classical dnssec-signzone way before shipping them. The secure delegation status (DS set in parent matches DNSKEY in child) is monitored by a set of nagios tests, from both [dsa-nagios] and dns-helpers. Of these, manage-dnssec-keys has a dual job: not only will it warn us if an expiring key is still in the DSset, it can also prevent it from getting expired by issuing timly updates of the keys metadata.

Relevant Git repositories

• domains
• auto-dns
• mini-nag
• dns-helpers
• puppet
• nagioschecks

-- Peter Palfrader

---

1. ldapsearch -h db.debian.org -x -ZZ -b dc=debian,dc=org -LLL 'host=master'
2. ldapsearch -h db.debian.org -x -ZZ -b dc=debian,dc=org -LLL 'dnsZoneEntry=*' dnsZoneEntry

I have written a number of scripts to create Debian foreign architecture (mostly armel and armhf) rootfs images for SD cards or NAND flashing. I started with putting Debian on my Openmoko gta01 and gta02 and continued with devices like the qi nanonote, a marvel kirkwood based device, the Always Innovating Touchbook (close to the Beagleboard), the Notion Ink Adam and most recently the Golden Delicious gta04. Once it has been manufactured, I will surely also get my hands dirty with the Neo900 whose creators are currently looking for potential donors/customers to increase the size of the first batch and get the price per unit further down. Creating a Debian rootfs disk image for all these devices basically follows the same steps:

1. create an disk image file, partition it, format the partitions and mount the / partition into a directory
2. use debootstrap or multistrap to extract a selection of armel or armhf packages into the directory
3. copy over /usr/bin/qemu-arm-static for qemu user mode emulation
4. chroot into the directory to execute package maintainer scripts with dpkg --configure -a
5. copy the disk image onto the sd card

It was not long until I started wondering why I had to run all of the above steps with superuser privileges even though everything except the final step (which I will not cover here) was in principle nothing else than writing some magic bytes to files I had write access to (the disk image file) in some more or less fancy ways. So I tried using fakeroot+fakechroot and after some initial troubles I managed to build a foreign architecture rootfs without needing root priviliges for steps two, three and four. I wrote about my solution which still included some workarounds in another article here. These workarounds were soon not needed anymore as upstream fixed the outstanding issues. As a result I wrote the polystrap tool which combines multistrap, fakeroot, fakechroot and qemu user mode emulation. Recently I managed to integrate proot support in a separate branch of polystrap. Last year I got the LEGO ev3 robot for christmas and since it runs Linux I also wanted to put Debian on it by following the instructions given by the ev3dev project. Even though ev3dev calls itself a "distribution" it only deviates from pure Debian by its kernel, some configuration options and its initial package selection. Otherwise it's vanilla Debian. The project also supplies some multistrap based scripts which create the rootfs and then partition and populate an SD card. All of this is of course done as the superuser. While the creation of the file/directory structure of the foreign Debian armel rootfs can by now easily be done without superuser priviliges by running multistrap under fakeroot/fakechroot/proot, creating the SD card image still seems to be a bit more tricky. While it is no problem to write a partition table to a regular file, it turned out to be tricky to mount these partition because tools like kpartx and losetup require superuser permissions. Tools like mkfs.ext3 and fuse-ext2 which otherwise would be able to work on a regular file without superuser privileges do not seem to allow to specify the required offsets that the partitions have within the disk image. With fuseloop there exists a tool which allows to "loop-mount" parts of a file in userspace to a new file and thus allows tools like mkfs.ext3 and fuse-ext2 to work as they normally do. But fuseloop is not packaged for Debian yet and thus also not in the current Debian stable. An obvious workaround would be to create and fill each partition in a separate file and concatenate them together. But why do I have to write my data twice just because I do not want to become the superuser? Even worse: because parted refuses to write a partition table to a file which is too small to hold the specified partitions, one spends twice the disk space of the final image: the image with the partition table plus the image with the main partition's content. So lets summarize: a bootable foreign architecture SD card disk image is nothing else than a regular file representing the contents of the SD card as a block device. This disk image is created in my home directory and given enough free disk space there is nothing stopping me from writing any possible permutation of bits to that file. Obviously I'm interested in a permutation representing a valid partition table and file systems with sensible content. Why do I need superuser privileges to generate such a sensible permutation of bits? Gladly it seems that the (at least in my opinion) hardest part of faking chroot and executing foreign architecture package maintainer scripts is already possible without superuser privileges by using fakeroot and fakechroot or proot together with qemu user mode emulation. But then there is still the blocker of creating the disk image itself through some user mode loop mounting of a filesystem occupying a virtual "partition" in the disk image. Why has all this only become available so very recently and still requires a number of workarounds to fully work in userspace? There exists a surprising amount of scripts which wrap debootstrap/multistrap. Most of them require superuser privileges. Does everybody just accept that they have to put a sudo in front of every invocation and hope for the best? While this might be okay for well tested code like debootstrap and multistrap the countless wrapper scripts might accidentally (be it a bug in the code or a typo in the given command line arguments) write to your primary hard disk instead of your SD card. Such behavior can easily be mitigated by not executing any such script with superuser privileges in the first place. Operations like loop mounting affect the whole system. Why do I have to touch anything outside of my home directory (/dev/loop in this case) to populate a file in it with some meaningful bits? Virtualization is no option because every virtualization solution again requires root privileges. One might argue that a number of solutions just require some initial setup by root to then later be used by a regular user (for example /etc/fstab configuration or the schroot approach). But then again: why do I have to write anything outside of my home directory (even if it is only once) to be able to write something meaningful to a file in it? The latter approach also does not work if one cannot become root in the first place or is limited by a virtualized environment. Imagine you are trying to build a Debian rootfs on a machine where you just have a regular user account. Or a situation I was recently in: I had a virtual server which denied me operations like loop mounting. Given all these downsides, why is it still so common to just assume that one is able and willing to use sudo and be done with it in most cases? I really wonder why technologies like fakeroot and fakechroot have only been developed this late. Has this problem not been around since the earliest days of Linux/Unix? Am I missing something and rambling around for nothing? Is this idea a lost cause or something that is worth spending time and energy on to extend and fix the required tools?

Valve Software s Steam is the number one digital game distribution service, with more than 65 million registered accounts. Steam runs on Windows, Mac OS, and Linux x86/amd64 computers, and provides access to several thousand games, at varying price points an enormous growth from less than a dozen games for Windows only about a decade ago. Valve s latest endeavour has been to bring their storefront into the living room, with a three-pronged attack: a new game controller, a programme of licensed x86 consoles to plug into the family TV, and an OS to run on the Steam Machines to tie it all together. December saw the first public release of their SteamOS which, as it turns out, is basically just a preconfigured desktop Linux. Specifically, it s a Debian Wheezy derivative, comprising a subset of 502 source packages from Wheezy; 8 of Valve s own source packages; and 51 source packages which have been either patched compared to Wheezy, backported from post-Wheezy, or both. For example, the compiler used by default is gcc-4.7 (rather than Wheezy s 4.6) and the libc version postdates Wheezy too. Valve s official instructions and installer release concerned quite a few people who had planned to try SteamOS on an older PC, by mandating a large (500GB) hard disk and a PC with UEFI firmware. Very quickly a number of instructions started appearing from people trying to fix what people felt were real issues specifically provision for BIOS-based computers, and installation from optical media. After being assured that redistribution of derivatives of SteamOS were entirely authorized (and, in fact, encouraged) I decided to produce my own variant, calling upon my own experience with debian-installer modification from past and present jobs, as well as calling upon the skills and experience of the UK Debian community as needed. The end result is Ye Olde SteamOSe. This weekend saw the third release of Ye Olde SteamOSe, a derivative designed to greatly widen the pool of computers capable of running Valve s OS. And unlike the first two releases, the public response this time has been crazy. Like, totally crazy. Combined score across several subreddits totals about 1700. 7 pages of Google search results. Hundreds of tweets. Mentions in dozens of blogs around the world. Coverage on the Linux Action Show. Unilaterally added to Softpedia s list of distributions. Almost 2000 views of a video installation walkthrough I posted on YouTube. Crazy. Sadly the idea to try and track visitors to the page didn t occur to me until long after the initial rush subsided, but 1000 visitors on Tuesday for a news story which landed on Sunday is still pretty hot in my book. It s also interesting to observe the demographics of site visitors the #1 referrer on Tuesday was Dutch PC site Tweakers.net, and StumbleUpon outranks reddit for referrals. About 66% of visitors interested in installing my Debian Wheezy derivative derivative came using Windows (20% using Linux), which suggests there s a lot of potential Linux users out amongst the Windows gamer masses. So what s the purpose of this self-congratulatory blog post? Just dick-waving? Well, there s an element of that (I m only human), but I think it might be nice to alert the audience on Planet Debian/Ubuntu, many of whom are not big gamers, to the next big thing in embedded Linux except this time a real GNU/X.org/sysVinit distribution, not some NIH thing like Android. So now you know!