Despite having worked on a number of ARM platforms I ve never actually had an ARM based development box at home. I have a Raspberry Pi B Classic (the original 256MB rev 0002 variant) a coworker gave me some years ago, but it s not what you d choose for a build machine and generally gets used as a self contained TFTP/console server for hooking up to devices under test. Mostly I ve been able to do kernel development with the cross compilers already built as part of Debian, and either use pre-built images or Debian directly when I need userland pieces. At a previous job I had a Marvell MACCHIATObin available to me, which works out as a nice platform - quad core A72 @ 2GHz with 16GB RAM, proper SATA and a PCIe slot. However they re still a bit pricey for a casual home machine. I really like the look of the HoneyComb LX2 - 16 A72 cores, up to 64GB RAM - but it s even more expensive. So when I saw the existence of the 8GB Raspberry Pi 4 I was interested. Firstly, the Pi 4 is a proper 64 bit device (my existing Pi B is ARMv6 which means it needs to run Raspbian instead of native Debian armhf), capable of running an upstream kernel and unmodified Debian userspace. Secondly the Pi 4 has a USB 3 controller sitting on a PCIe bus rather than just the limited SoC USB 2 controller. It s not SATA, but it s still a fairly decent method of attaching some storage that s faster/more reliable than an SD card. Finally 8GB RAM is starting to get to a decent amount - for a headless build box 4GB is probably generally enough, but I wanted some headroom. The Pi comes as a bare board, so I needed a case. Ideally I wanted something self contained that could take the Pi, provide a USB/SATA adaptor and take the drive too. I came across the pre-order for the DeskPi Pro, decided it was the sort of thing I was after, and ordered one towards the end of September. It finally arrived at the start of December, at which point I got round to ordering a Pi 4 from CPC. Total cost ~ 120 for the case + Pi.

The Bad First, let s get the bad parts out of the way. I managed to break a USB port on the Desk Pi. It has a pair of forward facing ports, I plugged my wireless keyboard dongle into it and when trying to remove it the solid spacer bit in the socket broke off. I ve never had this happen to me before and I ve been using USB devices for 20 years, so I m putting the blame on a shoddy socket. The first drive I tried was an old Crucial M500 mSATA device. I have an adaptor that makes it look like a normal 2.5 drive so I used that. Unfortunately it resulted in a boot loop; the Pi would boot its initial firmware, try to talk to the drive and then reboot before even loading Linux. The DeskPi Pro comes with an m2 adaptor and I had a spare m2 drive, so I tried that and it all worked fine. This might just be power issues, but it was an unfortunate experience especially after the USB port had broken off. (Given I ended up using an M.2 drive another case option would have been the Argon ONE M.2, which is a bit more compact.)

The Annoying The case is a little snug; I was worried I was going to damage things as I slid it in. Additionally the construction process is a little involved. There s a good set of instructions, but there are a lot of pieces and screws involved. This includes a couple of FFC cables to join things up. I think this is because they ve attempted to make a compact case rather than allowing a little extra room, and it does have the advantage that once assembled it feels robust without anything loose in it. I hate the need for an external USB3 dongle to bridge from the Pi to the USB/SATA adaptor. All the cases I ve seen with an internal drive bay have to do this, because the USB3 isn t brought out internally by the Pi, but it just looks ugly to me. It s hidden at the back, but meh. Fan control is via a USB/serial device, which is fine, but it attaches to the USB C power port which defaults to being a USB peripheral. Raspbian based kernels support device tree overlays which allows easy reconfiguration to host mode, but for a Debian based system I ended up rolling my own dtb file. I changed

#include "bcm283x-rpi-usb-peripheral.dtsi"

to

#include "bcm283x-rpi-usb-host.dtsi"

in arch/arm/boot/dts/bcm2711-rpi-4-b.dts and then I did:

cpp -nostdinc -I include -I arch -undef -x assembler-with-cpp \
    arch/arm/boot/dts/bcm2711-rpi-4-b.dts > rpi4.preprocessed
dtc -I dts -O dtb rpi4.preprocessed -o bcm2711-rpi-4-b.dtb

and the resulting bcm2711-rpi-4-b.dtb file replaced the one in /boot/firmware. This isn t a necessary step if you don t want to use the cooling fan in the case, or the front USB ports, and it s not really anyone s fault, but it was an annoying extra step to have to figure out. The DeskPi came with a microSD card that was supposed to have RaspiOS already on it. It didn t, it was blank. In my case that was fine, because I wanted to use Debian, but it was a minor niggle.

The Good I used Gunnar s pre-built Pi Debian image and it Just Worked; I dd d it to the microSD as instructed and the Pi 4 came up with working wifi, video and USB enabling me to get it configured for my network. I did an apt upgrade and got updated to the Buster 10.7 release, as well as the latest 5.9 backport kernel, and everything came back without effort after a reboot. It s lovely to be able to run Debian on this device without having to futz around with self-compiled kernels. The DeskPi makes a lot of effort to route things externally. The SD slot is brought out to the front, making it easy to fiddle with the card contents without having to open the case to replace it. All the important ports are brought out to the back either through orientation of the Pi, or extenders in the case. That means the built in Pi USB ports, the HDMI sockets (conveniently converted to full size internally), an audio jack and a USB-C power port. The aforementioned USB3 dongle for the bridge to the drive is the only external thing that s annoying. Thermally things seem good too. I haven t done a full torture test yet, but with the fan off the system is sitting at about 40 C while fairly idle. Some loops in bash that push load up to above 2 get the temperature up to 46 C or so, and turning the fan on brings it down to 40 C again. It s audible, but quieter than my laptop and not annoying. I liked the way the case came with everything I needed other than the Pi 4 and a suitable disk drive. There was an included PSU (a proper USB-C PD device, UK plug), the heatsink/fan is there, the USB/SATA converter is there and even an SD card is provided (though that s just because I had a pre-order). Speaking of the SD, I only needed it for initial setup. Recent Pi 4 bootloaders are capable of booting directly from USB mass storage devices. So I upgraded using the RPi EEPROM Recovery image (which just needs extracted to the SD FAT partition, no need for anything complicated - boot with it and the screen goes all green and you know it s ok), then created a FAT partition at the start of the drive for the kernel / bootloader config and a regular EXT4 partition for root. Copies everything over, updated paths, took out the SD and it all just works happily.

Summary My main complaint is the broken USB port, which feels like the result of a cheap connector. For a front facing port expected to see more use than the rear ports I think there s a reasonable expectation of robustness. However I m an early adopter and maybe future runs will be better. Other than that I m pretty happy. The case is exactly the sort of thing I wanted; I was looking for something that would turn the Pi into a box that can sit on my desk on the network and that I don t have to worry about knocking wires out of or lots of cables hooking bits up. Everything being included made it very convenient to get up and running. I still haven t poked the Pi that hard, but first impressions are looking good for it being a trouble free ARM64 dev box in the corner, until I can justify a HoneyComb.

Earlier this month Daniel, Lars and myself got together to discuss Bryan Cantrill s article Rust after the honeymoon. This is an overview of what keeps him enjoying working with Rust after having used it for an extended period of time for low level systems work at Oxide, we were particularly interested to read a perspective from someone who was both very experienced in general and had been working with the language for a while. While I have no experience with Rust both Lars and Daniel have been using it for a while and greatly enjoy it. One of the first areas we discussed was data bearing enums these have been very important to Bryan. In keeping with a pattern we all noted these take a construct that s relatively commonly implemented by hand in C (or skipped as too much effort, as Lars found) and provides direct support in the language for it. For both Daniel and Lars this has been key to their enjoyment of Rust, it makes things that are good practice or common idioms in C and C++ into first class language features which makes them more robust and allows them to fade into the background in a way they can t when done by hand. Daniel was also surprised by some omissions, some small such as the ? operator but others much more substantial the standout one being editions. These aim to address the problems seen with version transitions in other languages like Python, allowing individual parts of a Rust program to adopt potentially incompatible language features while remaining interoperability with older editions of the language rather than requiring the entire program to be upgraded en masse. This helps Rust move forwards with less need to maintain strict source level compatibility, allowing much more rapid evolution and helping deal with any issues that are found. Lars expressed the results of this very clearly, saying that while lots of languages offer a 20%/80% solution which does very well in specific problem domains but has issues for some applications Rust is much more able to move towards a much more general applicability by addressing problems and omissions as they are understood. This distracted us a bit from the actual content of the article and we had an interesting discussion of the issues with handling OS differences in filenames portably. Rather than mapping filenames onto a standard type within the language and then have to map back out into whatever representation the system actually uses Rust has an explicit type for filenames which must be explicitly converted on those occasions when it s required, meaning that a lot of file handling never needs to worry about anything except the OS native format and doesn t run into surprises. This is in keeping with Rust s general approach to interfacing with things that can t be represented in its abstractions, rather than hide things it keeps track of where things that might break the assumptions it makes are and requires the programmer to acknowledge and handle them explicitly. Both Lars and Daniel said that this made them feel a lot more confident in the code that they were writing and that they had a good handle on where complexity might lie, Lars noted that Rust is the first languages he s felt comfortable writing multi threaded code in. We all agreed that the effect here was more about having idioms which tend to be robust and both encourage writing things well and gives readers tools to help know where particular attention is required no tooling can avoid problems entirely. This was definitely an interesting discussion for me with my limited familiarity with Rust, hopefully Daniel and Lars also got a lot out of it!

The Turris Omnia router is not the first FLOSS router out there, but it could well be one of the first open hardware routers to be available. As the crowdfunding campaign is coming to a close, it is worth reflecting on the place of the project in the ecosystem. Beyond that, I got my hardware recently, so I was able to give it a try.

A short introduction to the Omnia project The Omnia router is a followup project on CZ.NIC's original research project, the Turris. The goal of the project was to identify hostile traffic on end-user networks and develop global responses to those attacks across every monitored device. The Omnia is an extension of the original project: more features were added and data collection is now opt-in. Whereas the original Turris was simply a home router, the new Omnia router includes:

• 1.6GHz ARM CPU
• 1-2GB RAM
• 8GB flash storage
• 6 Gbit Ethernet ports
• SFP fiber port
• 2 Mini-PCI express ports
• mSATA port
• 3 MIMO 802.11ac and 2 MIMO 802.11bgn radios and antennas
• SIM card support for backup connectivity

Some models sold had a larger case to accommodate extra hard drives, turning the Omnia router into a NAS device that could actually serve as a multi-purpose home server. Indeed, it is one of the objectives of the project to make "more than just a router". The NAS model is not currently on sale anymore, but there are plans to bring it back along with LTE modem options and new accessories "to expand Omnia towards home automation". Omnia runs a fork of the OpenWRT distribution called TurrisOS that has been customized to support automated live updates, a simpler web interface, and other extra features. The fork also has patches to the Linux kernel, which is based on Linux 4.4.13 (according to uname -a). It is unclear why those patches are necessary since the ARMv7 Armada 385 CPU has been supported in Linux since at least 4.2-rc1, but it is common for OpenWRT ports to ship patches to the kernel, either to backport missing functionality or perform some optimization. There has been some pressure from backers to petition Turris to "speedup the process of upstreaming Omnia support to OpenWrt". It could be that the team is too busy with delivering the devices already ordered to complete that process at this point. The software is available on the CZ-NIC GitHub repository and the actual Linux patches can be found here and here. CZ.NIC also operates a private GitLab instance where more software is available. There is technically no reason why you wouldn't be able to run your own distribution on the Omnia router: OpenWRT development snapshots should be able to run on the Omnia hardware and some people have installed Debian on Omnia. It may require some customization (e.g. the kernel) to make sure the Omnia hardware is correctly supported. Most people seem to prefer to run TurrisOS because of the extra features. The hardware itself is also free and open for the most part. There is a binary blob needed for the 5GHz wireless card, which seems to be the only proprietary component on the board. The schematics of the device are available through the Omnia wiki, but oddly not in the GitHub repository like the rest of the software.

Hands on I received my own router last week, which is about six months late from the original April 2016 delivery date; it allowed me to do some hands-on testing of the device. The first thing I noticed was a known problem with the antenna connectors: I had to open up the case to screw the fittings tight, otherwise the antennas wouldn't screw in correctly. Once that was done, I simply had to go through the usual process of setting up the router, which consisted of connecting the Omnia to my laptop with an Ethernet cable, connecting the Omnia to an uplink (I hooked it into my existing network), and go through a web wizard. I was pleasantly surprised with the interface: it was smooth and easy to use, but at the same time imposed good security practices on the user. For example, the wizard, once connected to the network, goes through a full system upgrade and will, by default, automatically upgrade itself (including reboots) when new updates become available. Users have to opt-in to the automatic updates, and can chose to automate only the downloading and installation of the updates without having the device reboot on its own. Reboots are also performed during user-specified time frames (by default, Omnia applies kernel updates during the night). I also liked the "skip" button that allowed me to completely bypass the wizard and configure the device myself, through the regular OpenWRT systems (like LuCI or SSH) if I needed to. Notwithstanding the antenna connectors themselves, the hardware is nice. I ordered the black metal case, and I must admit I love the many LED lights in the front. It is especially useful to have color changes in the reset procedure: no more guessing what state the device is in or if I pressed the reset button long enough. The LEDs can also be dimmed to reduce the glare that our electronic devices produce. All this comes at a price, however: at \$250 USD, it is a much higher price tag than common home routers, which typically go for around \$50. Furthermore, it may be difficult to actually get the device, because no orders are being accepted on the Indiegogo site after October 31. The Turris team doesn't actually want to deal with retail sales and has now delegated retail sales to other stores, which are currently limited to European deliveries.

A nice device to help fight off the IoT apocalypse It seems there isn't a week that goes by these days without a record-breaking distributed denial-of-service (DDoS) attack. Those attacks are more and more caused by home routers, webcams, and "Internet of Things" (IoT) devices. In that context, the Omnia sets a high bar for how devices should be built but also how they should be operated. Omnia routers are automatically upgraded on a nightly basis and, by default, do not provide telnet or SSH ports to run arbitrary code. There is the password-less wizard that starts up on install, but it forces the user to chose a password in order to complete the configuration. Both the hardware and software of the Omnia are free and open. The automatic update's EULA explicitly states that the software provided by CZ.NIC "will be released under a free software licence" (and it has been, as mentioned earlier). This makes the machine much easier to audit by someone looking for possible flaws, say for example a customs official looking to approve the import in the eventual case where IoT devices end up being regulated. But it also makes the device itself more secure. One of the problems with these kinds of devices is "bit rot": they have known vulnerabilities that are not fixed in a timely manner, if at all. While it would be trivial for an attacker to disable the Omnia's auto-update mechanisms, the point is not to counterattack, but to prevent attacks on known vulnerabilities. The CZ.NIC folks take it a step further and encourage users to actively participate in a monitoring effort to document such attacks. For example, the Omnia can run a honeypot to lure attackers into divulging their presence. The Omnia also runs an elaborate data collection program, where routers report malicious activity to a central server that collects information about traffic flows, blocked packets, bandwidth usage, and activity from a predefined list of malicious addresses. The exact data collected is specified in another EULA that is currently only available to users logged in at the Turris web site. That data can then be turned into tweaked firewall rules to protect the overall network, which the Turris project calls a distributed adaptive firewall. Users need to explicitly opt-in to the monitoring system by registering on a portal using their email address. Turris devices also feature the Majordomo software (not to be confused with the venerable mailing list software) that can also monitor devices in your home and identify hostile traffic, potentially leading users to take responsibility over the actions of their own devices. This, in turn, could lead users to trickle complaints back up to the manufacturers that could change their behavior. It turns out that some companies do care about their reputations and will issue recalls if their devices have significant enough issues. It remains to be seen how effective the latter approach will be, however. In the meantime, the Omnia seems to be an excellent all-around server and router for even the most demanding home or small-office environments that is a great example for future competitors.

Note: this article first appeared in the Linux Weekly News.

Hello folks! My team spent hours and hours beating our head against a Sonar deployment problem on Ubuntu Trusty (14.04 LTS). I thought I might share our findings so that you won t have to! As you probably know, Trusty only makes Java Development Kit 1.7 available on the stock installation. The current stable version of the Java is 1.8. The way we install this is to use the OpenJDK PPA, generously uploaded by our dear friend Matthias Klose. To make things even more exciting, a modern Maven is not available on this platform. And so we use the stock Maven 3.3.9 tarball distribution. This tarball distribution does not integrate well with Debian, and so, when we tell the system using sudo update-java-alternatives -s /usr/lib/jvm/java-1.8.0-openjdk-amd64 that we wish to use Java 1.8 as our default system JDK, it does not get the message. The only way to reliably let Maven know which java you wish to use is to set the JAVA_HOME environment variable. In order to do this within the Jenkins environment, one must select the JDK one wishes to use: To make things worse, this option is not, as one might expect, available for editing in a stock Jenkins 2.x installation. In Jenkins 1.x, one would be able to specify which java one wished to use just by specifying openjdk8 in a field. With Jenkins 2.x, the field does not exist unless a configuration option in an unrelated form is set. So! One should first select Manage Jenkins -> Global Tool Configuration: Once this form is open, look for the JDK installations button: Click it very thoroughly just once. You ll be presented with a form into which you may enter details about the various JDKs your build executors may have access to. You ll refer to them in your job configuration by the value of their Name field, and when executing the build, Jenkins will set JAVA_HOME to the value of the (you guessed it) JAVA_HOME field: Once these entries are made, they can be selected in two place. 1) on the ZMQ Event Publisher: 2) in the post-build actions under SonarQube analysis with Maven (advanced) And that s how it s done! Here s the details from my colleague, Thanh: https://lists.fd.io/pipermail/honeycomb-dev/2016-October/000387.html

The Background Story A year ago, or so, I took some time to search the internet for Free Software that can be used for controlling model railways via a computer. I was happy to find Rocrail [1] being one of only a few applications available on the market. And even more, I was very happy when I saw that it had been licensed under a Free Software license: GPL-3(+). A month ago, or so, I collected my old M rklin (Digital) stuff from my parents' place and started looking into it again after +15 years, together with my little son. Some weeks ago, I remembered Rocrail and thought... Hey, this software was GPLed code and absolutely suitable for uploading to Debian and/or Ubuntu. I searched for the Rocrail source code and figured out that it got hidden from the web some time in 2015 and that the license obviously has been changed to some non-free license (I could not figure out what license, though). This made me very sad! I thought I had found a piece of software that might be interesting for testing with my model railway. Whenever I stumble over some nice piece of Free Software that I plan to use (or even only play with), I upload this to Debian as one of the first steps. However, I highly attempt to stay away from non-free sofware, so Rocrail has become a no-option for me back in 2015. I should have moved on from here on... Instead... Proactively, I signed up with the Rocrail forum and asked the author(s) if they see any chance of re-licensing the Rocrail code under GPL (or any other FLOSS license) again [2]? When I encounter situations like this, I normally offer my expertise and help with such licensing stuff for free. My impression until here already was that something strange must have happened in the past, so that software developers choose GPL and later on stepped back from that decision and from then on have been hiding the source code from the web entirely. Going deeper... The Rocrail project's wiki states that anyone can request GitBlit access via the forum and obtain the source code via Git for local build purposes only. Nice! So, I asked for access to the project's Git repository, which I had been granted. Thanks for that. Trivial Source Code Investigation... So far so good. I investigated the source code (well, only the license meta stuff shipped with the source code...) and found that the main COPYING files (found at various locations in the source tree, containing a full version of the GPL-3 license) had been replaced by this text:

Copyright (c) 2002 Robert Jan Versluis, Rocrail.net
All rights reserved.
Commercial usage needs permission.

The replacement happened with these Git commits:

commit cfee35f3ae5973e97a3d4b178f20eb69a916203e
Author: Rob Versluis <r.j.versluis@rocrail.net>
Date:   Fri Jul 17 16:09:45 2015 +0200
    update copyrights
commit df399d9d4be05799d4ae27984746c8b600adb20b
Author: Rob Versluis <r.j.versluis@rocrail.net>
Date:   Wed Jul 8 14:49:12 2015 +0200
    update licence
commit 0daffa4b8d3dc13df95ef47e0bdd52e1c2c58443
Author: Rob Versluis <r.j.versluis@rocrail.net>
Date:   Wed Jul 8 10:17:13 2015 +0200
    update

Getting in touch again, still being really interested and wanting to help... As I consider such a non-license as really dangerous when distributing any sort of software, be it Free or non-free Software, I posted the below text on the Rocrail forum:

Hi Rob,
I just stumbled over this post [3] [link reference adapted for this
blog post), which probably is the one you have referred to above.
It seems that Rocrail contains features that require a key or such
for permanent activation.  Basically, this is allowed and possible
even with the GPL-3+ (although Free Software activists will  not
appreciate that). As the GPL states that people can share the source
code, programmers can  easily deactivate license key checks (and
such) in the code and re-distribute that patchset as they  like.
Furthermore, the current COPYING file is really non-protective at
all. It does not really protect   you as copyright holder of the
code. Meaning, if people crash their trains with your software, you  
could actually be legally prosecuted for that. In theory. Or in the
U.S. ( ;-) ). Main reason for  having a long long license text is to
protect you as the author in case your software causes t trouble to
other people. You do not have any warranty disclaimer in your COPYING
file or elsewhere. Really not a good idea.
In that referenced post above, someone also writes about the nuisance
of license discussions in  this forum. I have seen various cases
where people produced software and did not really care for 
licensing. Some ended with a letter from a lawyer, some with some BIG
company using their code  under their copyright holdership and their
own commercial licensing scheme. This is not paranoia,  this is what
happens in the Free Software world from time to time.
A model that might be much more appropriate (and more protective to
you as the author), maybe, is a  dual release scheme for the code. A
possible approach could be to split Rocrail into two editions:  
Community Edition and Professional/Commercial Edition. The Community
Edition must be licensed in a  way that it allows re-using the code
in a closed-source, non-free version of Rocrail (e.g.   MIT/Expat
License or Apache2.0 License). Thus, the code base belonging to the
community edition  would be licensed, say..., as Apache-2.0 and for
the extra features in the Commercial Edition, you  may use any
non-free license you want (but please not that COPYING file you have
now, it really  does not protect your copyright holdership).
The reason for releasing (a reduced set of features of a) software as
Free Software is to extend  the user base. The honey jar effect, as
practise by many huge FLOSS projects (e.g. Owncloud,  GitLab, etc.).
If people could install Rocrail from the Debian / Ubuntu archives
directly, I am  sure that the user base of Rocrail will increase.
There may also be developers popping up showing  an interest in
Rocrail (e.g. like me). However, I know many FLOSS developers (e.g.
like me) that  won't waste their free time on working for a non-free
piece of software (without being paid).
If you follow (or want to follow) a business model with Rocrail, then
keep some interesting  features in the Commercial Edition and don't
ship that source code. People with deep interest may  opt for that.
Furthermore, another option could be dual licensing the code. As the
copyright holder of Rocrail  you are free to juggle with licenses and
apply any license to a release you want. For example, this  can be
interesing for a free-again Rocrail being shipped via Apple's iStore. 
Last but not least, as you ship the complete source code with all
previous changes as a Git project  to those who request GitBlit
access, it is possible to obtain all earlier versions of Rocrail. In 
the mail I received with my GitBlit credentials, there was some text
that  prohibits publishing the  code. Fine. But: (in theory) it is
not forbidden to share the code with a friend, for local usage.  This
friend finds the COPYING file, frowns and rewinds back to 2015 where
the license was still  GPL-3+. GPL-3+ code can be shared with anyone
and also published, so this friend could upload the  2015-version of
Rocrail to Github or such and start to work on a free fork. You also
may not want  this.
Thanks for working on this piece of software! It is highly
interesing, and I am still sad, that it  does not come with a free
license anymore. I won't continue this discussion and move on, unless
you  are interested in any of the above information and ask for more
expertise. Ping me here or directly  via mail, if needed. If the
expertise leads to parts of Rocrail becoming Free Software again, the 
expertise is offered free of charge ;-).
light+love
Mike

Wow, the first time I got moderated somewhere... What an experience! This experience now was really new. My post got immediately removed from the forum by the main author of Rocrail (with the forum's moderator's hat on). The new experience was: I got really angry when I discovererd having been moderated. Wow! Really a powerful emotion. No harassment in my words, no secrets disclosed, and still... my free speech got suppressed by someone. That feels intense! And it only occurred in the virtual realm, not face to face. Wow!!! I did not expect such intensity... The reason for wiping my post without any other communication was given as below and quite a statement to frown upon (this post has also been "moderately" removed from the forum thread [2] a bit later today):

Mike,
I think its not a good idea to point out a way to get the sources back to the GPL periode.
Therefore I deleted your posting.

(The phpBB forum software also allows moderators to edit posts, so the critical passage could have been removed instead, but immediately wiping the full message, well...). Also, just wiping my post and not replying otherwise with some apology to suppress my words, really is a no-go. And the reason for wiping the rest of the text... Any Git user can easily figure out how to get a FLOSS version of Rocrail and continue to work on that from then on. Really. Now the political part of this blog post... Fortunately, I still live in an area of the world where the right of free speech is still present. I found out: I really don't like being moderated!!! Esp. if what I share / propose is really noooo secret at all. Anyone who knows how to use Git can come to the same conclusion as I have come to this morning. [Off-topic, not at all related to Rocrail: The last votes here in Germany indicate that some really stupid folks here yearn for another this time highly idiotic wind of change, where free speech may end up as a precious good.] To other (Debian) Package Maintainers and Railroad Enthusiasts... With this blog post I probably close the last option for Rocrail going FLOSS again. Personally, I think that gate was already closed before I got in touch. Now really moving on... Probably the best approach for my new train conductor hobby (as already recommended by the woman at my side some weeks back) is to leave the laptop lid closed when switching on the train control units. I should have listened to her much earlier. I have finally removed the Rocrail source code from my computer again without building and testing the application. I neither have shared the source code with anyone. Neither have I shared the Git URL with anyone. I really think that FLOSS enthusiasts should stay away from this software for now. For my part, I have lost my interest in this completely... References

• [1] http://wiki.rocrail.net/doku.php
• [2] http://forum.rocrail.net/viewtopic.php?t=12400&f=31#p125938
• [3] http://forum.rocrail.net/viewtopic.php?f=44&t=9848&p=93248&hilit=Lizenz#...

light+love,
Mike

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

Honey Mojito

• 12 oz. honey
• 7 medium limes
• bag crushed ice
• small bouquet fresh mint
• water
• light rum
• sparkling water

Combine 12 oz. of honey with 8 oz. of warm water. Stir mixture together until the honey has completely dissolved. Juice limes in a juicer and pour into the honey and water. Squeeze the bunch of mint sprigs and add to a pitcher of crushed ice. Pour the honey /lime mixture over the ice. Stir and top with sparkling water. Add more honey , water, limes, or rum to your taste. Enjoy! Serves 2

ApologyAs a twisted turn of fate, I need to start my platform with an apology. Last year, I withdrew my nomination, because my life turned upside down, and the effects of that are still felt today, and will continue to have a considerable footprint for the rest of my life. But this is not what I want to apologise for! I want to apologise because my nomination, my platform, and my plans are rather uncommon - or so I believe. Unlike past Project Leaders, if elected, I will not have as much time to travel, as some of them. Nor will I have the resources to do all the things one may expect from a Project Leader. But - as you'll read later - I consider this both the biggest weakness and the greatest strength of my platform.Furthermore, I will not be available from the second half of the voting period until after the new Project Leader's term starts: I'll be getting married, and will enjoy a nice honeymoon, and as such, my email will remain unread from the 9th of April until we're back on the 21st of April.On the mouse behind the keyboardMy name is Gergely Nagy, or algernon, for those of you who may know me by my online presence. I used to be a lot of things: a flaming youth, an application manager, package maintainer, upstream, ftp-assistant, a student, a mentor, a hacker. In the end, however, I am but a simple, albeit sometimes crazy person. I imagine, a lot of people reading this will not know me, and that is actually not only fine, but in my case, desirable.The Role of the Project LeaderThe role of the Project Leader, what people perceive about the role, and what is actually done by one single person changed dramatically over time. In some ways for the better, some ways for the worse. It should be sufficiently clear by now that if we combine all the things past Project Leaders have done, and what people expect the Project Leader to do, then not even all the time in the world would be enough to accomplish everything. On the other hand, we should not cut the responsibilities back to constitution-granted ones only.There has been some discussion about this very topic on debian-project@, back in February, with excellent observations by both past Project Leaders and the current one. I encourage my dear readers to stop reading this platform now, and read at least Lucas's mail. I'll be right here when you get back.Back? Good.You may notice that unlike in previous years, I do not have a Grand Vision, not in the same sense at least. No matter what I envision, however noble that vision may be, it is not the Project Leader's job to save the world, so to say. While I still believe that we have serious problems with motivation, inspiration and innovation within the project, the Project Leader is the wrong person to try and solve these issues with.Apart from the constitutionally required responsibilities, the primary purpose of the Project Leader in my opinion, is to be an enabler: the Project Leader is not a front runner to lead the herd to victory, but a gentle shepherd to make them happy.HappyThere are many ways to make people happy. One such way is to enable them to pursue their passion - and not just enable them, but encourage and fuel that passion, too! -, to remove barriers, to empower them, or in a lot of cases, to include them in the first place. My vision is a project that is greater than just an amazing distribution. More than a role model for technical excellence. I want to do away with territorial pissings (with which I don't mean to imply that this would be the general atmosphere within the project - far from it!), and would rather see a warm, welcoming culture within the project - the kind of "I'm home!" feeling I had at the DebConfs I had the privilege to attend -, on public and private media alike.That is the vision I have, but I can't do it. At best, I can hope to enable people much better at the these things to do what needs to be done. I wish to take the burden of administration, bureaucracy off their shoulders, so they can focus on what they do best. I feel that this is the most important part of being a Project Leader: to enable the project to grow. And this is why I feel that most of you not knowing my name is an advantage here: When you look at a beautiful flower, you admire the flower itself, rarely the gardener.In the endI wish to be the Project Leader no one remembers. I'd rather see people remember all the great things the Project - as a whole - accomplished, for there are many. My purpose is to let You pursue your passion, which in turn enables even more people to pursue their happiness, and allows the greater Free Software community to bask in the warm glow of accomplished dreams.

I love reading Linux Weekly News. It's a great source of high quality Linux and FOSS journalism, and I've been a subscriber for years. One mild annoyance I have with the site is the way articles are cross-linked. All the article URIs are in the format /Article/531114/, which isn't particularly descriptive about that article's content. When faced with an article that links to another article, with perhaps a word of anchor text, it's hard to tell if the new article is worth opening in a tab, is indeed already open in a tab, or has been previously read. (Yes, the "visited link" colour can help to a small degree, but even then, it doesn't tell you which previously read article it is). This is what God the W3C invented the title attribute for. Back in April 2011, I emailed Jonathan Corbet and asked if his content management system could just do this, but it was apparently a bit tricky, and it got filed in the "feature request" bucket. I was sufficiently irritated by this deficiency last Monday, when doing some heavy reading on a topic, and so I decided to take matters into my own hands, and also learn how to write a Chrome Extension into the bargain. I was delighted to have scratched the itch under 24 hours later and developed something that solved my particular problem - lwn4chrome I'm calling it. I'm just finalising an icon for it, and then I'll have a stab at putting it in the Chrome Web Store as a freebie. I might even have a crack at writing a Firefox extension as well for completeness, but I suspect the bulk of LWN's readership is using Chrome or Chromium.

When I first read that Linux kernel developer Valerie Aurora would be changing careers to work full-time on behalf of women in open source communities, I never imagined it would lead so far so fast. Today, The Ada Initiative is a non-profit organization with global reach, whose programs have helped create positive change for women in a wide range of communities beyond open source. Building on this foundation, imagine how much more they can do in the next four years! That s why I m pledging my continuing support, and asking you to join me. For the next 7 days, I will personally match your donations up to $4,096. My employer, Heroku (Salesforce.com), will match my donations too, so every dollar you contribute will be tripled! My goal is that together we will raise over $12,000 toward The Ada Initiative s 2014 fundraising drive. Since about 1999, I had been working in open source communities like Debian and Ubuntu, where women are vastly underrepresented even compared to the professional software industry. Like other men in these communities, I had struggled to learn what I could do to change this. Such a severe imbalance can only be addressed by systemic change, and I hardly knew where to begin. I worked to raise awareness by writing and speaking, and joined groups like Debian Women, Ubuntu Women and Geek Feminism. I worked on my own bias and behavior to avoid being part of the problem myself. But it never felt like enough, and sometimes felt completely hopeless. Perhaps worst of all, I saw too many women burning out from trying to change the system. It was often taxing just to participate as a woman in a male-dominated community, and the extra burden of activism seemed overwhelming. They were all volunteers, doing this work in evenings and weekends around work or study, and it took a lot of time, energy and emotional reserve to deal with the backlash they faced for speaking out about sexism. Valerie Aurora and Mary Gardiner helped me to see that an activist organization with full-time staff could be part of the solution. I joined the Ada Initiative advisory board in February 2011, and the board of directors in April. Today, The Ada Initiative is making a difference not only in my community, but in my workplace as well. When I joined Heroku in 2012, none of the engineers were women, and we clearly had a lot of work to do to change that. In 2013, I attended AdaCamp SF along with my colleague Peter van Hardenberg, joining the first allies track , open to participants of any gender, for people who wanted to learn the skills to support the women around them. We ve gone on to host two ally skills workshops of our own for Heroku employees, one taught by Ada Initiative staff and another by a member of our team, security engineer Leigh Honeywell. These workshops taught interested employees simple, everyday ways to take positive action to challenge sexism and create a better workplace for women. The Ada Initiative also helped us establish a policy for conference sponsorship which supports our gender diversity efforts. Today, Heroku engineering includes about 10% women and growing. The Ada Initiative s programs are helping us to become the kind of company we want to be.

I attended the workshop with a group of Heroku colleagues, and it was a powerful experience to see my co-workers learning tactics to support women and intervene in sexist situations. Hearing them discuss power and privilege in the workplace, and the various a-ha! moments people had, were very encouraging and made me feel heard and supported.
Leigh Honeywell

If you want to see more of these programs from The Ada Initiative, please contribute now:

A little more than 2 years ago, the Ceilometer project was launched inside the OpenStack ecosystem. Its main objective was to measure OpenStack cloud platforms in order to provide data and mechanisms for functionalities such as billing, alarming or capacity planning. In this article, I would like to relate what I've been doing with other Ceilometer developers in the last 5 months. I've lowered my involvement in Ceilometer itself directly to concentrate on solving one of its biggest issue at the source, and I think it's largely time to take a break and talk about it. Ceilometer early design For the last years, Ceilometer didn't change in its core architecture. Without diving too much in all its parts, one of the early design decision was to build the metering around a data structure we called samples. A sample is generated each time Ceilometer measures something. It is composed of a few fields, such as the the resource id that is metered, the user and project id owning that resources, the meter name, the measured value, a timestamp and a few free-form metadata. Each time Ceilometer measures something, one of its components (an agent, a pollster ) constructs and emits a sample headed for the storage component that we call the collector. This collector is responsible for storing the samples into a database. The Ceilometer collector uses a pluggable storage system, meaning that you can pick any database system you prefer. Our original implementation has been based on MongoDB from the beginning, but we then added a SQL driver, and people contributed things such as HBase or DB2 support. The REST API exposed by Ceilometer allows to execute various reading requests on this data store. It can returns you the list of resources that have been measured for a particular project, or compute some statistics on metrics. Allowing such a large panel of possibilities and having such a flexible data structure allows to do a lot of different things with Ceilometer, as you can almost query the data in any mean you want. The scalability issue We soon started to encounter scalability issues in many of the read requests made via the REST API. A lot of the requests requires the data storage to do full scans of all the stored samples. Indeed, the fact that the API allows you to filter on any fields and also on the free-form metadata (meaning non indexed key/values tuples) has a terrible cost in terms of performance (as pointed before, the metadata are attached to each sample generated by Ceilometer and is stored as is). That basically means that the sample data structure is stored in most drivers in just one table or collection, in order to be able to scan them at once, and there's no good "perfect" sharding solution, making data storage scalability painful. It turns out that the Ceilometer REST API is unable to handle most of the requests in a timely manner as most operations are O(n) where n is the number of samples recorded (see big O notation if you're unfamiliar with it). That number of samples can grow very rapidly in an environment of thousands of metered nodes and with a data retention of several weeks. There is a few optimizations to make things smoother in general cases fortunately, but as soon as you run specific queries, the API gets barely usable. During this last year, as the Ceilometer PTL, I discovered these issues first hand since a lot of people were feeding me back with this kind of testimony. We engaged several blueprints to improve the situation, but it was soon clear to me that this was not going to be enough anyway.

Thinking outside the box Unfortunately, the PTL job doesn't leave him enough time to work on the actual code nor to play with anything new. I was coping with most of the project bureaucracy and I wasn't able to work on any good solution to tackle the issue at its root. Still, I had a few ideas that I wanted to try and as soon as I stepped down from the PTL role, I stopped working on Ceilometer itself to try something new and to think a bit outside the box. When one takes a look at what have been brought recently in Ceilometer, they can see the idea that Ceilometer actually needs to handle 2 types of data: events and metrics. Events are data generated when something happens: an instance start, a volume is attached, or an HTTP request is sent to an REST API server. These are events that Ceilometer needs to collect and store. Most OpenStack components are able to send such events using the notification system built into oslo.messaging. Metrics is what Ceilometer needs to store but that is not necessarily tied to an event. Think about an instance CPU usage, a router network bandwidth usage, the number of images that Glance is storing for you, etc These are not events, since nothing is happening. These are facts, states we need to meter. Computing statistics for billing or capacity planning requires both of these data sources, but they should be distinct. Based on that assumption, and the fact that Ceilometer was getting support for storing events, I started to focus on getting the metric part right. I had been a system administrator for a decade before jumping into OpenStack development, so I know a thing or two on how monitoring is done in this area, and what kind of technology operators rely on. I also know that there's still no silver bullet this made it a good challenge. The first thing that came to my mind was to use some kind of time-series database, and export its access via a REST API as we do in all OpenStack services. This should cover the metric storage pretty well. Cooking Gnocchi

A cloud of gnocchis!

At the end of April 2014, this led met to start a new project code-named Gnocchi. For the record, the name was picked after confusing so many times the OpenStack Marconi project, reading OpenStack Macaroni instead. At least one OpenStack project should have a "pasta" name, right? The point of having a new project and not send patches on Ceilometer, was that first I had no clue if it was going to make something that would be any better, and second, being able to iterate more rapidly without being strongly coupled with the release process. The first prototype started around the following idea: what you want is to meter things. That means storing a list of tuples of (timestamp, value) for it. I've named these things "entities", as no assumption are made on what they are. An entity can represent the temperature in a room or the CPU usage of an instance. The service shouldn't care and should be agnostic in this regard. One feature that we discussed for several OpenStack summits in the Ceilometer sessions, was the idea of doing aggregation. Meaning, aggregating samples over a period of time to only store a smaller amount of them. These are things that time-series format such as the RRDtool have been doing for a long time on the fly, and I decided it was a good trail to follow. I assumed that this was going to be a requirement when storing metrics into Gnocchi. The user would need to provide what kind of archiving it would need: 1 second precision over a day, 1 hour precision over a year, or even both. The first driver written to achieve that and store those metrics inside Gnocchi was based on whisper. Whisper is the file format used to store metrics for the Graphite project. For the actual storage, the driver uses Swift, which has the advantages to be part of OpenStack and scalable. Storing metrics for each entities in a different whisper file and putting them in Swift turned out to have a fantastic algorithm complexity: it was O(1). Indeed, the complexity needed to store and retrieve metrics doesn't depends on the number of metrics you have nor on the number of things you are metering. Which is already a huge win compared to the current Ceilometer collector design. However, it turned out that whisper has a few limitations that I was unable to circumvent in any manner. I needed to patch it to remove a lot of its assumption about manipulating file, or that everything is relative to now (time.time()). I've started to hack on that in my own fork, but then everything broke. The whisper project code base is, well, not the state of the art, and have 0 unit test. I was starring at a huge effort to transform whisper into the time-series format I wanted, without being sure I wasn't going to break everything (remember, no test coverage). I decided to take a break and look into alternatives, and stumbled upon Pandas, a data manipulation and statistics library for Python. Turns out that Pandas support time-series natively, and that it could do a lot of the smart computation needed in Gnocchi. I built a new file format leveraging Pandas for computing the time-series and named it carbonara (a wink to both the Carbon project and pasta, how clever!). The code is quite small (a third of whisper's, 200 SLOC vs 600 SLOC), does not have many of the whisper limitations and it has test coverage. These Carbonara files are then, in the same fashion, stored into Swift containers. Anyway, Gnocchi storage driver system is designed in the same spirit that the rest of OpenStack and Ceilometer storage driver system. It's a plug-in system with an API, so anyone can write their own driver. Eoghan Glynn has already started to write a InfluxDB driver, working closely with the upstream developer of that database. Dina Belova started to write an OpenTSDB driver. This helps to make sure the API is designed directly in the right way. Handling resources Measuring individual entities is great and needed, but you also need to link them with resources. When measuring the temperature and the number of a people in a room, it is useful to link these 2 separate entities to a resource, in that case the room, and give a name to these relations, so one is able to identify what attribute of the resource is actually measured. It is also important to provide the possibility to store attributes on these resources, such as their owners, the time they started and ended their existence, etc.

Relationship of entities and resources

Once this list of resource is collected, the next step is to list and filter them, based on any criteria. One might want to retrieve the list of resources created last week or the list of instances hosted on a particular node right now. Resources also need to be specialized. Some resources have attributes that must be stored in order for filtering to be useful. Think about an instance name or a router network. All of these requirements led to to the design of what's called the indexer. The indexer is responsible for indexing entities, resources, and link them together. The initial implementation is based on SQLAlchemy and should be pretty efficient. It's easy enough to index the most requested attributes (columns), and they are also correctly typed. We plan to establish a model for all known OpenStack resources (instances, volumes, networks, ) to store and index them into the Gnocchi indexer in order to request them in an efficient way from one place. The generic resource class can be used to handle generic resources that are not tied to OpenStack. It'd be up to the users to store extra attributes. Dropping the free form metadata we used to have in Ceilometer makes sure that querying the indexer is going to be efficient and scalable.

The indexer classes and their relations

REST API All of this is exported via a REST API that was partially designed and documented in the Gnocchi specification in the Ceilometer repository; though the spec is not up-to-date yet. We plan to auto-generate the documentation from the code as we are currently doing in Ceilometer. The REST API is pretty easy to use, and you can use it to manipulate entities and resources, and request the information back.

Macroscopic view of the Gnocchi architecture

Roadmap & Ceilometer integration All of this plan has been exposed and discussed with the Ceilometer team during the last OpenStack summit in Atlanta in May 2014, for the Juno release. I led a session about this entire concept, and convinced the team that using Gnocchi for our metric storage would be a good approach to solve the Ceilometer collector scalability issue. It was decided to conduct this project experiment in parallel of the current Ceilometer collector for the time being, and see where that would lead the project to. Early benchmarks Some engineers from Mirantis did a few benchmarks around Ceilometer and also against an early version of Gnocchi, and Dina Belova presented them to us during the mid-cycle sprint we organized in Paris in early July. The following graph sums up pretty well the current Ceilometer performance issue. The more you feed it with metrics, the more slow it becomes.

For Gnocchi, while the numbers themselves are not fantastic, what is interesting is that all the graphs below show that the performances are stable without correlation with the number of resources, entities or measures. This proves that, indeed, most of the code is built around a complexity of O(1), and not O(n) anymore. Next steps

Cl ment drawing the logo

While the Juno cycle is being wrapped-up for most projects, including Ceilometer, Gnocchi development is still ongoing. Fortunately, the composite architecture of Ceilometer allows a lot of its features to be replaced by some other code dynamically. That, for example, enables Gnocchi to provides a Ceilometer dispatcher plugin for its collector, without having to ship the actual code in Ceilometer itself. That should help the development of Gnocchi to not be slowed down by the release process for now. The Ceilometer team aims to provide Gnocchi as a sort of technology preview with the Juno release, allowing it to be deployed along and plugged with Ceilometer. We'll discuss how to integrate it in the project in a more permanent and strong manner probably during the OpenStack Summit for Kilo that will take place next November in Paris.

Yves Rossy is the Jetman, he flys with a wing and four jet engines strapped to his body, he gave an interesting TED talk about flying along with some exciting videos [1]. Larry Brilliant gave an informative and inspiring TED talk about stopping pandemics [2]. I thought that Smallpox was the last disease to be eradicated but I was wrong. Michael Shermer gave an interesting TED talk about pattern recognition and self deception [3]. It s a pity that the kissing prank shown at the end only pranked women, they should be less sexist and prank men too. Raffaello D Andrea gave an interesting TED presentation about Athletic quadcopters [4]. It s very impressive and has the potential for several new human/machine sports. Lisa D wrote an insightful article about Prejudice Spillover discussing the way that people who aren t in minority groups only seem to care about injustice when a member of the majority is targetted by mistake [5]. Ron Garret wrote an insightful post about the Divine Right of Billionaires which debunks some stupid arguments by a billionaire [6]. Ron says that it s often instructive to examine incorrect arguments, especially when those arguments are advanced by smart people and demonstrates it in this post. Lisa D wrote an interesting post about her problems with financial aid bureaucracy [7]. She intended the post to be a personal one about her situation, but I think it illustrates problems with the various aid programs. If aid was available to her with less bureaucracy then she would be doing paid work, completing her studies, and heading towards post-graduate studies. Mark Shuttleworth wrote an insightful article about ACPI, security, and device tree [8]. It s the first time I ve seen a good argument for device tree. TED presented an interesting video-conference interview with Edward Snowden [9]. It s unusually long by TED standards but definitely worth watching. Tom Meagher (who s wife was raped and murdered two years ago) wrote an insightful article about rape culture [10]. Key Lay (the Victorian Chief Commissioner of Police) wrote a good article encouraging men to act to stop violence against women [11]. It s particularly noteworthy when a senior police officer speaks out about this given the difficulties women have had in reporting such crimes to police. Emily Baker wrote an insightful article about the lack of support for soldiers who survive war [12]. A lot of attention and money is spent remembering the soldiers who died in the field but little on those who live suffer afterwards, more soldiers die from suicide than enemy fire. Daniel Pocock wrote an informative article about the failings of SMS authentication for online banking [13]. While he has good points I think he s a little extreme. Stopping the least competent attackers is still a significant benefit as most potential attackers aren t that competent. Jess Zimmerman wrote an interesting article for Time about the Not All Men argument that is a current trend in derailing discussions about the treatment of women [14]. The Belle Jar has an insightful article Why Won t You Educate Me About Feminism about some ways that men pretend to care about the treatment of women [15]. Jon Evans wrote an article for Tech Crunch about the Honywell Bubble Count measure of diversity in people you follow on social media [16]. Currently on Twitter I follow 57 accounts of which 15 are companies and organisations, so I follow 42 people. I follow 13 women 31%, for a visible minority group other than my own it s 2/42 or 5%, for people who live in other countries I think it s 8/42 (although it s difficult to determine where some people live) which is 19%. So my Honywell number is 55. The Top Stocks forum has an interesting post by a Coal Seam Gas (CSG) worker [17]. It seems that CSG is even worse than I thought. Ashe Dryden wrote an informative post for Model View Culture about the backlash that members of minority groups (primarily women) receive when they speak out [18].

• [1] http://www.ted.com/talks/yves_rossy_fly_with_the_jetman
• [2] http://www.ted.com/talks/larry_brilliant_wants_to_stop_pandemics
• [3] http://www.ted.com/talks/michael_shermer_the_pattern_behind_self_deception
• [4] http://tinyurl.com/pwa7hwy
• [5] http://chaoticidealism.livejournal.com/131742.html
• [6] http://blog.rongarret.info/2014/02/the-divine-right-of-billionaires_22.html
• [7] http://chaoticidealism.livejournal.com/132730.html
• [8] http://www.markshuttleworth.com/archives/1332
• [9] http://www.ted.com/talks/edward_snowden_here_s_how_we_take_back_the_internet
• [10] http://www.abc.net.au/news/2014-04-18/meagher-the-danger-of-the-monster-myth/5399108
• [11] http://www.vicpolicenews.com.au/blogs/93-oursay/1302-ccp-ken-lay-on-family-violence.html
• [12] http://www.examiner.com.au/story/2248712/dont-forget-about-those-war-veterans-who-remain/
• [13] http://danielpocock.com/sms-logins-an-illusion-of-security
• [14] http://time.com/79357/not-all-men-a-brief-history-of-every-dudes-favorite-argument/
• [15] http://bellejar.ca/2014/02/22/why-wont-you-educate-me-about-feminism/
• [16] http://techcrunch.com/2014/04/26/whats-your-honeywell-bubble-count/
• [17] http://www.topstocks.com.au/stock_discussion_forum.php?action=show_thread&threadid=1106338
• [18] http://modelviewculture.com/pieces/dissent-unheard-of

Today was Playgroup. We had a pretty early start to the day, and Zoe wanted porridge for breakfast, so we made that together in the Thermomix, and she got dressed while it cooked. After a bit of TV, we biked over. I got to witness semi-firsthand my first mother-to-mother altercation. I said hi to a mother I'd met a previous week, and asked her how she was, and got "Pissed off" as the response. Apparently a reasonably large boy (I'd put him at about the 4 mark) had been in the face of her daughter, and distressed her daughter a bit, so she'd apparently politely told the boy to back off, and then been revved by the mother of the boy for talking to her son. The boy continued hanging around her daughter, and she left Playgroup not long after telling me all about it. I worked out later on that the mother of the boy was one of the women who helped run the Playgroup. Fun times. He was a bit out of control. He full on screamed at me at the end of Playgroup for no reason. His mother did make him apologise to me for that, without me requesting it. There were some dress ups (mostly skirts) today, so Zoe had a fabulous time cavorting around on the stage in a big pink lacy skirt, doing "ballet". She dragged me up on stage with her, and we danced around for a bit. It was quite fun. She was very helpful at pack up time, and was bringing a lot of equipment back to the storage room at the back of the hall. I was helping load stuff into the large crate in the storage room. After parachute time, I lost sight of her briefly, and after a quick search, deduced that she must have gotten herself locked in the storage room. Sure enough, that's where she was. She was only missing for as long as it took me to notice and search in all the other possible places, so she wasn't particularly distressed. Poor thing. After Playgroup, we biked back home, and I had another photo I wanted to print out, so we drove over to Officeworks and had a sausage sizzle after we got the photo printed out, and then drove back home. Zoe had a pretty good bedtime last night, so I decided to try skipping her nap today. I wanted to get the 5-8 player extension pack for Settlers of Catan, which Mind Games in the Myer Centre had, so we hopped on a bus to the city. When we've been on longer public transport rides, Zoe's asked me if she can play games on my phone. This of course keeps her amused, but leaves me with nothing to amuse myself (I need to remember to bring a book). I have this cupboard full of old Android phones, so I decided to blow the dust off my old Nexus S and make it a dedicated games phone for her when we're on public transport. This worked pretty well today. She also decided to bring her handbag, which was convenient. I think she was pretty excited at the idea of her "own phone", even if it lacked a SIM card. After we'd bought the extension pack, I thought we could do something slightly more fun than just traipse into the city and traipse back out again. I've been meaning to introduce her to bubble tea for a while, so took this opportunity to track some down in the Myer Centre. We settled on some honeydew milk tea. She liked the honeydew, but after a couple of mouth fulls, was over the tapioca balls. She was a good sport and gave them a good college try though. It was fun watching her play around with the phone on the way home, and just fumbling her way around the user interface. She found the alarm setting UI, and was having a great old time creating alarms. (I'm glad I cleared them all out when we got home, there was at least one set for 4am). She had fun exploring all the ring tones. Towards the end of the journey home she figured out the camera, and was having a fabulous time taking snaps out the bus window. She still needs to work on keeping her hands and fingers away from the lens. She watched some TV while I made dinner and then I joined her on the couch for a cuddle while I flicked through my copy of 50 Dangerous Things (you should let your children do) and 365 Science Experiments. My cousin Renata came around for dinner with us tonight. Zoe didn't have a particularly great dinner, but she did go to bed nice and easily. I'm not sure how she'll sleep tonight. I've gone back to having a light-weight doona on her, as it's possible last night's wake up was temperature-related.

I was bracing myself for a rough night, but Zoe slept through until almost 6am. Today was playgroup again, so we just took a slow start to the day and headed out on the bike a bit after 9am. There was a mix of new faces and people from last week. I packed a lunchbox this time instead of relying on the snack collection in my "Dad Bag" backpack. We worked on trying to approach other girls to get them to play. Unfortunately they're all that little bit younger and more shy, so we haven't had a huge success. Zoe's been pretty happy just playing with the various toys and playing with me. Parachute time was a big hit again. I think there were about 25 adults there (I was the only Dad this week), with many with multiple children. The youngest baby I saw was a 7 week old. Zoe had been asking me what a honeydew was, so after Playgroup we dropped by the Hawthorne Garage and grabbed half a honeydew and a couple of tomatoes and I made some fritters for lunch with leftover corned beef from dinner the other night. Zoe wasn't too impressed with them. I think she didn't like the diced tomato. She declared that the honeydew was just like rockmelon. We read a story in the hammock and she went down pretty easily for nap after that. I'd just started doing the dishes when my mate Steve gave me a call. He was in the area, and he dropped in. That worked out well, because I'd been meaning to pick his brain about my little electronics project. We geeked it up for a bit. Zoe's mini lab coat arrived in the mail, and when she finally woke up after 3pm, I asked her if she wanted to go out to Bunnings to get a pair of kids-sized safety glasses, but she said she wanted to do something "fun" instead. When I asked her what she wanted to do, she initially wanted to go to Wet and Wild, but that's an all day outing and we're going next Wednesday, so she settled on going to Colmslie pool again instead. So we quickly got organised and jumped on the bike and biked over to the pool. We started out in the kid's play area, which had a couple of small slides and some fountains and whatnot, and then we gravitated over to the 50 metre pool, where Zoe practised her diving for a bit and generally quite confidently navigated the 1.5m deep end of the pool. It was good, because at least I could just stand up instead of tread water while she practised diving in off the blocks. We had a post-swim ice cream and biked home, and then I whipped up dinner and it was bathtime and bedtime. I'm going to have to start tracking my weekly kilometres with Zoe on the bike, because I think it'll be a reasonable distance.

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.

Review: Honeyed Words, by J.A. Pitts

Series:	Sarah Beauhall #2
Publisher:	Tor
Copyright:	July 2011
ISBN:	0-7653-2907-7
Format:	Trade paperback
Pages:	412

Honeyed Words is a direct sequel to Black Blade Blues and probably doesn't make sense to read out of order. Sarah, Katie, their friends, and Katie's family are still recovering from the climactic events of Black Blade Blues and licking their wounds, but things are slowly looking up. Sarah is getting more comfortable openly expressing her sexuality, although there are still tensions, and her relationships are improving. The city of Vancouver also seems to be recovering. But major political shifts among the nonhuman races have echoes and ramifications, and after a kidnapped singer and a murdered dwarf, Sarah is pulled back into the turmoil. If you liked the world-building in Black Blade Blues, Honeyed Words is more of the same, but with more variety. Pitts adds elves to dwarves and dragons, shows considerably more of the supernatural world beneath the surface of human cities, and introduces Sarah to some new types of danger. There are a few more glimmers of the history of Sarah's sword and the nature of the gods in this universe, but still nothing conclusive. Pitts broadens the world-building rather than deepening it. But I liked the new characters. Teenage elves with obsessions make for great characters, and the demon who shows up about halfway through is delightful. As with the first book, this is mostly a story of things happening to Sarah while she tries to muddle through as best she can. There isn't much in the way of grand strategy or of seizing control of the plot. She just tries to do the right thing and gets lots of help from lots of friends. But the plot moves right along, and it's mixed with a healthy sense of normality that I find refreshing. She needs work as a blacksmith, she's trying to support a friend without having much money of her own, the living arrangements this forces are a bit of a strain for her own relationships, and her broken relationship with her family continues to lurk. Much urban fantasy is built around the premise of a regular person thrust into a fantasy world, but much of it then discards normal life once the supernatural starts. I think Pitts does a particularly good job of keeping his protagonist's life grounded in the ongoing mundane problems of living. It's also more fun to read about Sarah when she isn't quite as angstful. Over the course of Honeyed Words, she seems to be growing into a person who can accept who she is and feel secure about her place in the world. That's nice to see. The downside to this book is that, while it's full of quite a lot of stuff, not all of it coheres that horribly well. It has a certain "middle book" feel. The major plot resolves, but with some significant lingering consequences and something of a cliff-hanger last chapter. Most of the threads left open by the first book are still open here. There's character growth, and setup for some resolution, but not a lot of actual resolution. I still like this series, though. I like urban fantasy that isn't about vampires and werewolves; berserker blacksmiths and Norse legend has much more appeal, and I want to read more of it. Pitts's writing is a bit clunky and probably won't win many rewards, but it's serviceable and I think improving. If you enjoyed the first book, it's worth looking for this one as well. Followed by Forged in Fire. Rating: 7 out of 10

In November I resigned from Bytemark. In December I started working for a local company, here in Edinburgh, in a real office (rather than working from home). Unfortunately today I resigned from that new job, meaning I'm currently unemployed. I plan to take a 1-2 week vacation, then look for another job as a matter of some urgency. (I can live off savings for the next half-year, or so, if I need to, but I'd go crazy if I had nothing to do for that long.) It is unfortunate to have to resign from a new job after only five-six weeks, but much more honest to do so now than pretend everything was OK and do it at the point I'd passed my probationary period (of three months). The people were lovely, the office was lovely, the coffee machine was excellent, the work was interesting, but the nature of a large corporate job with the associated beaurocracy made it a less good fit for me than it looked on paper. I shall pretend that the next week or two of down-time is our honeymoon ;)

I got married! Sarah and I tied the knot on the 10th August this year. We married in a registry office where we live and had an evening reception on Tynemouth beach. A fantastic time was had by all. We honeymooned in Sorrento, Italy, which was fantastic. We spent one day visiting Pompeii (my fourth visit: about 6 hours on our feet this time, and we walked from one side right to the other); another day in Herculaneum (my second visit); one day visiting the village near where we were staying, where we visited a local food festival and bought the nicest Marmelade I've ever tasted; a few day and evenings in Sorrento town itself; but most of the time we just relaxed, swam, snoozed, read.

Finally.. My bee box has arrived. Initially I had planned to build it myself, but with current time constraints and in light of the fact that the commercial variant is built in a sheltered workshop, I decided to go for a pre-built one. The bee box is designed to give bees a natural habitat and allow them to get through the winter without the need for artificial sugar. Harvest is limited to about 15 kg in a good year as opposed to up to 50 kg in commercial beehives, but this method of beekeeping is less stressful for the bees. The trick is that there are two sections in every bee box; starting in the second year, you open the second section as soon as the bees have started to run out of space. As that's done relatively late in May, the bees will mainly build honey-only non-larvae honeycombs. During harvest, you remove only those secondary honeycombs; as a result, the bees will not need to defend their larvae and thus be a lot more relaxed. As those bees are under supervision of a human with access to oxalic acid, it's trivial to protect those bees against infestations by varroa destructor and to keep them safe form mice during winter. Bees are incredibly important for nature's cycle, so this is a hobby with a lot of positive impact on your local flora, and subsequently fauna. And hey.. free honey!

Review: The Borrowers, by Mary Norton

Series:	The Borrowers #1
Illustrator:	Beth Krush
Illustrator:	Joe Krush
Publisher:	Sandpiper
Copyright:	1953
Printing:	1986
ISBN:	0-15-204737-9
Format:	Trade paperback
Pages:	180

Arrietty is a 14-year-old girl who lives under the clock. Well, actually, she lives under the kitchen floor, but the entrance to her family's passageway is under the clock, from which they get their name. She sleeps in an old cigar box, her living room is wallpapered with strips cut from letters (and decorated with postage stamps), and she keeps a journal in a miniature book that's half the size she is. Arrietty, and her parents Pod and Homily, are Borrowers. The Borrowers is a classic series of children's books by Mary Norton about miniature people who, at least in this first book, live in the walls and take things. Not big things, but all the little things: the blotter paper, the pins, the stray sock, old postage stamps, empty matchboxes, and the occasional thimble. With these things, they build their furniture, their clothes, and their homes, safely hidden in the walls and other secret places, always wary of the "human beans" (as Arrietty's mother tends to call them). That life is, of course, a remarkable simulation of middle-class, class-conscious British life, which is much of the fun. Arrietty's family lives in the home of an elderly woman who's confined to bed, so it's quiet, safe, and driven entirely by routine. They only have to watch out for the maid and the gardener, and they keep regular schedules. That's just the way the Borrowers like it; predictable and quiet. Which is why they get caught entirely by surprise when a boy shows up, recovering from illness in the country, and spots Pod on one of his borrowing runs. This is technically a re-read, but I read the original series so long ago that I barely remembered it. Not that there is all that much to remember, at least in the way of plot. This first book follows one of the standard plots for children's books of this type (although it follows Arrietty as the viewpoint character rather than the more common choice of the boy): boy discovers hidden creatures, hidden creatures are afraid, boy turns out to want to make friends with them, they strike up a friendship, peril nonetheless ensues. If you've read many children's books, you've probably read this before; The Mouse and the Motorcycle is an obvious example (and, in terms of plot, a somewhat better book). Arrietty is a typical protagonist, her parents are silly (and a bit flighty, particularly her mother), and the boy is, disappointingly, almost a non-entity. But you don't read The Borrowers for the plot. The brilliance of this book is in the descriptions of what they use, how they use it, and how they construct their ingenious homes. Norton captures much of the wonder of other miniaturization stories (the movie Honey, I Shrunk the Kids is an obvious example), but takes it one step further into clever and thoughtful repurposing. The book is full of off-hand descriptions of how everyday objects become different everyday objects for miniature people, giving it the same delight that one gets from descriptions of how model railroad dioramas or hand-made doll houses are constructed. The detailed (if busy) illustrations by the Krushes help tremendously with visualization and make the descriptions even more fun. This is very much a children's book based on an exploration of a single great idea, so don't expect too much in the way of plot or deep characterization. It's also not science fiction; there isn't any realistic extrapolation of culture. The Borrowers all behave like perfectly ordinary English people without any further explanation because, of course, that's what they would do. Re-reading it as an adult, I wished there was a bit more meat to it. But the ingenuity is still a delight. It's great fun to spend a couple of hours imagining how one would construct the miniature accouterments of everyday life. Followed by The Borrowers Afield. Rating: 7 out of 10