I had been pondering to do an end-of-year bug stat post. Niels Thykier forced my hand, so here goes :) The UDD bugs interface currently knows about the following release critical bugs:

• In Total: 1353
  • Affecting Jessie: 476 That's the number we need to get down to zero before the release. They can be split in two big categories:
    • Affecting Jessie and unstable: 410 Those need someone to find a fix, or to finish the work to upload a fix to unstable:
      • 52 bugs are tagged 'patch'. Please help by reviewing the patches, and (if you are a DD) by uploading them.
      • 28 bugs are marked as done, but still affect unstable. This can happen due to missing builds on some architectures, for example. Help investigate!
      • 330 bugs are neither tagged patch, nor marked done. Help make a first step towards resolution!
    • Affecting Jessie only: 66 Those are already fixed in unstable, but the fix still needs to migrate to Jessie. You can help by submitting unblock requests for fixed packages, by investigating why packages do not migrate, or by reviewing submitted unblock requests.
      • 0 bugs are in packages that are unblocked by the release team.
      • 66 bugs are in packages that are not unblocked.

Graphical overview of bug stats thanks to azhag:

This package started as my collection of shared C utility code and has turned into the collection of all sorts of glue that I use across multiple packages. The primary changes in this release are to the network utility layer. In order to add proper IPv6 support, I adopted the network_bind_* functions to take the socket type, which changed all the APIs (hence the major version bump). While I was at it, I also cleaned up some of the error reporting in the various functions to make them easier to use. There's a new network_wait_any function that does the select part of network_accept_any, making it useful for UDP servers. This release also contains a new, generalized TAP add-on for spawning background processes used by test cases. Their standard output and standard error is now captured and merged into the test output stream using the new C TAP Harness support for files containing diagnostic messages. The remctl TAP add-on has been rewritten to use this framework. Julien LIE also adapted the Autoconf probes for Berkeley DB and zlib used in INN to the framework used for most probes in rra-c-util, and those probes are included in this release. Finally, the vector utility library's free functions now accept (and do nothing with) NULL, which makes it easier to write cleanup functions. You can get the latest release from the rra-c-util distribution page.

It s wedding week! Wedding week! Wedding week! Wedding week! Oh, also Christmas. Oh dad, it s wedding week! I can t believe it! It s finally here! Wedding week! Jacob, age 7, Sunday Oh dad, this is the best Christmas EVER! Jacob, Wednesday Dad, is the wedding TODAY? Oliver, age 4, every morning this week This has certainly been a Christmas like no other. I have never known something to upstage Christmas for Jacob, but apparently a wedding can! Laura and I got to celebrate our first Christmas together this year together, of course, with the boys. We enjoyed a wonderful day in the middle of a busy week, filled with play, family togetherness, warmth, and happiness. At one point, while I was helping the boys with their new model train components, Laura was enjoying playing Christmas tunes on the piano. Every time she d reach the end, Jacob paused, and said, That was awesome! , beating me to it. That s a few days before Christmas Jacob and Oliver demanding snow ice cream, and of course who am I to refuse? Cousins opening presents After his school Christmas program, Jacob has enjoyed singing. Here he is after the Christmas Eve program, where he excitedly ran up into the choir loft, picked up a hymnal, and pretended to sing. And, of course, opening of presents at home. Sometimes I think about how I didn t know life could get this good. Soon Laura and I will be married, and it will be even better. Truly we have been richly blessed.

Five weeks ago, I started a new job (Security Engineer, Eventbrite). I accepted the offer on a Friday evening at about 5:30 PM. That evening, my new boss and I traded emails to help me figure out what kind of computer I'd like. Time was of the essence because my start date was very next day, Tuesday. I wrote about how I value pixel count, and then RAM, and then a speedy disk, and then a speedy CPU. I named a few ThinkPad models that could be good, and with advice from the inimitable danjared, I pointed out that some Dell laptops come pre-installed with Ubuntu (which I could easily swap out for Debian). On Monday, my boss replied. Given the options that the IT department supports, he picked out the best one by my metrics: a MacBook Pro. The IT department would set up the company-mandated full-disk encryption and anti-virus scanning. If I wanted to run Linux, I could set up BootCamp or a virtualization solution. As I read the email, my heart nearly stopped. I just couldn't see myself using a Mac. I thought about it. Does it really matter to me enough to call up my boss and undo an IT request that is already in the works, backpedaling on what I claimed was important to me, opting for brand anti-loyalty to Apple over hardware speed? Yes, I thought to myself. I am willing to just not work there if I have to use a Mac. So I called $BOSS, and I asked, "What can we do to not get me a Mac?" It all worked out fine; I use a ThinkPad X1 Carbon running Debian for work now, and it absolutely does everything I need. It does have a slower CPU, fewer pixels, and less RAM, and I am the only person in the San Francisco engineering office not running Mac OS. But it all works. In the process, I thought it made sense to write up some text to $BOSS. Here is how it goes.

Hi $BOSS,

Thanks for hearing my concerns about having a Mac. It would basically be a fairly serious blow to my self image. It's possible I could rationalize it, but it would take a long time, and I'm not sure it would work.

I don't at all need to start work using the computer I'm going to be using for the weeks afterward. I'm OK with using something temporarily that is whatever is available, Mac or non-Mac; I could happily borrow something out of the equipment closet in the short term if there are plans in the works to replace it with something else that makes me productive in the long term.

For full-disk encryption, there are great solutions for this on Linux.

For anti-virus, it seems Symantec AV is available for Linux <http://www.symantec.com/business/support/index?page=content&id=HOWTO17995>.

It sounds like Apple and possibly Lenovo are the only brands that are available through the IT department, but it is worth mentioning that Dell sells perfectly great laptops with Linux pre-installed, such as the XPS 13. I would perfectly happily use that.

If getting me more RAM is the priority, and the T440s is a bad fit for $COMPANY, then the Lenovo X230 would be a great option, and is noticeably less expensive, and it fits 16GB of RAM.

BootCamp and the like are theoretical possibilities on Macs, but one worry I have is that if there were a configuration issue, it might not be worth me spending work time to have me fix my environment, but instead I would be encouraged for efficiency to use Mac OS, which is well-tested on Apple hardware, and then I would basically hate using my computer, which is a strong emotion, but basically how I would feel.

Another issue (less technical) is that if I took my work machine to the kinds of conferences that I go to, like Debconf, I would find myself in the extremely uncomfortable position of advertising for Apple. I am pretty strongly unexcited about doing that.

Relating to the self-image issue is that it means a lot to me to sort of carry the open source community with me as I do my technical work, even if that technical work is not making more open source software. Feeling part of this world that shares software, and Debian in particular where I have a strong feeling of attachment to the community, even while doing something different, is part of what makes using computers fun for me. So it clashes with that to use Mac OS on my main machine, or to feel like I'm externally indistinguishable from people who don't care about this sort of community.

I am unenthusiastic about making your life harder and looking like a prima donna with my possibly obscure requirements.

I am, however, excited to contribute to $COMPANY!

I hope that helps! Probably nothing you couldn't have guessed in here, but I thought it was worth spelling some of that out. Happy to talk more.

-- Asheesh.

I am very pleased to say that RC bug counter for Jessie finally dropped below 500 RC bugs. For comparison, we broke the 700 RC bug curve in the start of November, so that is about 200 RC bugs in about 7-8 weeks (or about 25-28 RC bugs per week). Today, we have about 162 RC bugs on the auto-removal list. Though, I suspect many of the affected packages have reverse dependencies, so their removal from testing may be up 30 days away. Nevertheless, by this time in January, we could be looking at no more than 350 RC bugs left for Jessie.

At the Mini-debconf in Cambridge back in November there was an ARM Sprint (which Hector wrote up as a Bits from ARM porters mail). During this there a brief discussion about using GRUB as a standard bootloader, particularly for ARM server devices. This has the advantage of providing a more "normal" (which in practice means "x86 server-like") as well as flexible solution compared with the existing flash-kernel tool which is often used on ARM. On ARMv7 devices this will more than likely involve chain loading from the U-Boot supplied by the manufacturer. For test and development it would be useful to be able to set up a similar configuration using Qemu. Cross-compilers Although this can be built and run on an ARM system I am using a cross compiler here. I'm using gcc-linaro-arm-linux-gnueabihf-4.8-2013.08_linux from Linaro, which can be downloaded from the linaro-toolchain-binaries page on Launchpad. (It looks like 2013.10 is the latest available right now, I can't see any reason why that wouldn't be fine). Once the cross-compiler has been downloaded unpack it somewhere, I will refer to the resulting gcc-linaro-arm-linux-gnueabihf-4.8-2013.08_linux directory as $CROSSROOT. Make sure $CROSSROOT/bin (which contains arm-linux-gnueabihf-gcc etc) is in your $PATH. Qemu I'm using the version packaged in Jessie, which is 1.7.0+dfsg-2. We need both qemu-system-arm for running the final system and qemu-user to run some of the tools. I'd previously tried an older version of qemu (1.6.x?) and had some troubles, although they may have been of my own making... Das U-boot for Qemu First thing to do is to build a suitable u-boot for use in the qemu emulated environment. Since we need to make some configuration changes we need to build from scratch. Start by cloning the upstream git tree:

$ git clone git://git.denx.de/u-boot.git
$ cd u-boot

I am working on top of e03c76c30342 "powerpc/mpc85xx: Update CONFIG_SYS_FSL_TBCLK_DIV for T1040" dated Wed Dec 11 12:49:13 2013 +0530. We are going to use the Versatile Express Cortex-A9 u-boot but first we need to enable some additional configuration options:

• CONFIG_API -- This enables the u-boot API which Grub uses to access the lowlevel services provided by u-boot. This means that grub doesn't need to contains dozens of platform specific flash, mmc, nand, network, console drivers etc and can be completely platform agnostic.
• CONFIG_SYS_MMC_MAX_DEVICE -- Setting CONFIG_API needs this.
• CONFIG_CMD_EXT2 -- Useful for accessing EXT2 formatted filesystems. In this example I use a VFAT /boot for convenience but in a real system we would want to use EXT2 (or even something more modern)).
• CONFIG_CMD_ECHO -- Just useful.

You can add all these to include/configs/vexpress_common.h:

#define CONFIG_API
#define CONFIG_SYS_MMC_MAX_DEVICE   1
#define CONFIG_CMD_EXT2
#define CONFIG_CMD_ECHO

Or you can apply the patch which I sent upstream:

$ wget -O - http://patchwork.ozlabs.org/patch/304786/raw   git apply --index
$ git commit -m "Additional options for grub-on-uboot"

Finally we can build u-boot:

$ make CROSS_COMPILE=arm-linux-gnueabihf- vexpress_ca9x4_config
$ make CROSS_COMPILE=arm-linux-gnueabihf-

The result is a u-boot binary which we can load with qemu. GRUB for ARM Next we can build grub. Start by cloning the upstream git tree:

$ git clone git://git.sv.gnu.org/grub.git
$ cd grub

By default grub is built for systems which have RAM at address 0x00000000. However the Versatile Express platform which we are targeting has RAM starting from 0x60000000 so we need to make a couple of modifications. First in grub-core/Makefile.core.def we need to change arm_uboot_ldflags, from:

-Wl,-Ttext=0x08000000

to

-Wl,-Ttext=0x68000000

and second we need make a similar change to include/grub/offsets.h changing GRUB_KERNEL_ARM_UBOOT_LINK_ADDR from 0x08000000 to 0x68000000. Now we are ready to build grub:

$ ./autogen.sh
$ ./configure --host arm-linux-gnueabihf
$ make

Now we need to build the final grub "kernel" image, normally this would be taken care of by grub-install but because we are cross building grub we cannot use this and have to use grub-mkimage directly. However the version we have just built is for the ARM target and not for host we are building things on. I've not yet figured out how to build grub for ARM while building the tools for the host system (I'm sure it is possible somehow...). Luckily we can use qemu to run the ARM binary:

$ cat load.cfg
set prefix=(hd0)
$ qemu-arm -r 3.11 -L $CROSSROOT/arm-linux-gnueabihf/libc \
    ./grub-mkimage -c load.cfg -O arm-uboot -o core.img -d grub-core/ \
    fat ext2 probe terminal scsi ls linux elf msdospart normal help echo

Here we create load.cfg which is the setup script which will be built into the grub kernel, our version just sets the root device so that grub can find the rest of its configuration. Then we use qemu-arm-static to invoke grub-mkimage. The "-r 3.11" option tells qemu to pretend to be a 3.11 kernel (which is required by the libc used by our cross compiler, without this you will get a fatal: kernel too old message) and "-L $CROSSROOT/..." tells it where to find the basic libraries, such as the dynamic linker (luckily grub-mkimage doesn't need much in the way of libraries so we don't need a full cross library environment. The grub-mkimage command passes in the load.cfg and requests an output kernel targeting arm-uboot, core.img is the output file and the modules are in grub-core (because we didn't actually install grub in the target system, normally these would be found in /boot/grub). Lastly we pass in a list of default modules to build into the kernel, including filesystem drivers (fat, ext2), disk drivers (scsi), partition handling (msdos), loaders (linux, elf), the menu system (normal) and various other bits and bobs. So after all the we now have our grub kernel in core.img. Putting it all together Before we can launch qemu we need to create various disk images. Firstly we need some images for the 2 64M flash devices:

$ dd if=/dev/zero of=pflash0.img bs=1M count=64
$ dd if=/dev/zero of=pflash1.img bs=1M count=64

We will initialise these later from the u-boot command line. Secondly we need an image for the root filesystem on an MMC device. I'm using a FAT formatted image here simply for the convenience of using mtools to update the images during development.

$ dd if=/dev/zero of=mmc.img bs=1M count=16
$ /sbin/mkfs.vfat mmc.img

Thirdly we need a kernel, device tree and grub configuration on our root filesystem. For the first two I extracted them from the standard armmp kernel flavour package. I used the backports.org version 3.11-0.bpo.2-armmp version and extracted /boot/vmlinuz-3.11-0.bpo.2-armmp as vmlinuz and /usr/lib/linux-image-3.11-0.bpo.2-armmp/vexpress-v2p-ca9.dtb as dtb. Then I hand coded a simple grub.cfg:

menuentry 'Linux'  
        echo "Loading vmlinuz"
        set root='hd0'
        linux /vmlinuz console=ttyAMA0 ro debug
        devicetree /dtb
 

In a real system the kernel and dtb would be provided by the kernel packages and grub.cfg would be generated by update-grub. Now that we have all the bits we need copy them into the root of mmc.img. Since we are using a FAT formatted image we can use mcopy from the mtools package.

$ mcopy -v -o -n -i mmc.img core.img dtb vmlinuz grub.cfg ::

Finally after all that we can run qemu passing it our u-boot binary and the mmc and flash images and requesting a Cortex-A9 based Versatile Express system with 1GB of RAM:

$ qemu-system-arm -M vexpress-a9 -kernel u-boot -m 1024m -sd mmc.img \
    -nographic -pflash pflash0.img -pflash pflash1.img

Then at the VExpress# prompt we can configure the default bootcmd to load grub and save the environment to the flash images. The backslash escapes (\$ and \;) should be included as written here so that e.g. the variables are only evaluated when bootcmd is evaluated and not immediately when setting bootcmd and the bootm is set as part of bootcmd instead of executed immediately:

VExpress# setenv bootcmd fatload mmc 0:0 \$ loadaddr  core.img \; bootm \$ loadaddr 
VExpress# saveenv

Now whenever we boot the system it will automatically load boot grub from the mmc and launch it. Grub in turn will load the Linux binary and DTB and launch those. I haven't actually configure Linux with a root filesystem here so it will eventually panic after failing to find root. Future work The most pressing issue is the hard coded load address built in to the grub kernel image. This is something which needs to be discussed with the upstream grub maintainers as well as the Debian package maintainers. Now that the ARM packages have hit Debian (in experimental in the 2.02~beta2-1 package) I also plan to start looking at debian-installer integration as well as updating flash-kernel to setup the chain load of grub instead of loading a kernel directly.

I always enjoy this time of year: lots of peace and quiet and time to work on whatever I feel like focusing on. That's been watching a lot of speedrunning and League of Legends, but also experimenting with systemd and upstart. I've now ported lbcd to both "properly," meaning that I make full use of their features as far as I currently understand them. I have some more packaging work to do, and need to make a release, but of course I started fixing various other things since I was in the code anyway, and now I don't want to release it without some testing. And that prompted another digression, since I didn't have a good test framework for spawning the server and pounding on it. That finally brings this journal entry to its actual topic: a new release of C TAP Harness. This release adds a new pair of functions, diag_file_add() and diag_file_remove(), which tell the TAP library to take the contents of log files as an additional source of diag() messages. This produces much nicer, and more readable, output from test cases that involve forking a background server that produces output to standard output and standard error. That output can be directed to a file and then included in the test output stream, properly tagged and in sequence with the result messages. You can get the latest release from the C TAP Harness distribution page.

sorry for not posting, life s been getting in the way. Here s an update of what I did the last few weeks: I hacked more on Hy. A lot more. Tons of new stuff is coming through, and I got a slot to talk about Hy at PyCon US! I worked a bit on Debian stuff. I got Debile a bit more in shape, and did more NEW queue work. Hopefully I can get some more in. I just bought another keyboard to supplement my Das Keyboard - the Tex Beetle. I m thinking of getting some pimped out keycaps. Get at me if you know anything about this. Merry christmas!

Follow me also on Twitter Just in time for this 2013 Christmas, the Brebis Project released Brebis "Bouddhinette" 0.9. Hope you ll enjoy our X-mas present Reminder: Brebis is the fully automated backup checker, a CLI software developed in Python, allowing users to verify the integrity of archives (tar,gz,bz2,lzma,zip) and the state of the files inside the archives. You will find more information about Brebis features on the Brebis Project homepage. What s new? The major features for this release are:

• support of the apk archive
• the cli offers new options to store the configuration file (-C), the list of files (-L) or both (-O) in custom locations

The extensive list of the supported features is available on the Brebis Project homepage. Get Brebis The official archive of Brebis 0.9 is available here. Feedback about Brebis What do you think about the Brebis project ? We at the Brebis Project welcome any feedback about Brebis. Feel free to comment on this blog, to subscribe to the Brebis-users mailing list, by Twitter or email me directly at carl.chenet@brebisproject.org

Official website: http://www.brebisproject.org
Mailing-list: http://lists.sourceforge.net/lists/listinfo/brebis-users

For a number of weeks now, I have been forwarding traffic being sent to codesearch.debian.net to an instance of Debian Code Search running at Rackspace s public cloud offering. I feel like it s overdue to announce how they have been supporting the project and what that means. Context First of all, let s provide some context. Debian Code Search was launched in November 2012, hosted entirely on my private server. Since DebConf 13, I am in contact with DSA in order to get Code Search running on a DSA-provided machine and make it an official Debian service. Code Search runs best on flash storage, and only with adequate resources can we enable some use cases (e.g. package-level results) and make sure the existing use cases work at all (we currently have timeouts for some queries). Unfortunately, flash storage is scarce in Debian, hence we couldn t get any for Code Search. At some point, I got the suggestion to ask Rackspace for help, since they are quite friendly to the Open Source community. They agreed to help us out with a generous amount of resources in their public cloud offering! This means I can run Code Search at Rackspace the way it is meant to be run: with the index sharded onto 6 different machines and the source code being searched on fast flash storage. Concerns Now, when using third-party infrastructure, there are always two big concerns: proprietary infrastructure and vendor lock-in. As for the proprietary aspect, Rackspace s public cloud offering is based on OpenStack, which is FOSS. Granted, they have a couple of extensions that are not (yet?) released in OpenStack, but those are minor details and any automation that we use can trivially be ported to any other OpenStack offering. Who knows, maybe in the future we use OpenStack in Debian, too? Given the OpenStack situation, I am not concerned about vendor lock-in. However, to specifically address this concern and err on the side of caution, attention will be paid to keep Code Search able to run on non-cloud infrastructure, such that we can run our own instance on DSA-provided hardware. My current intention is that this instance will be the fall-back that we can use should there ever be problems with Rackspace. So far, however, I am very happy with Rackspace s stability. Future There are a number of improvements waiting: for users in the United States, traffic first goes to my server in Europe and then back to Rackspace in the US. Eventually, we should get rid of this indirection. Perhaps we can also spin up another instance in Europe eventually. Furthermore, Rackspace recently announced new available hardware, which we are not yet making use of. I expect a big speed-up, but will have to do some careful benchmarking. Also, I have some interesting performance data, which will be shared in subsequent blog posts. Stay tuned :). Conclusion I d like to thank Rackspace very much for their generous support of the Debian project and Code Search in particular. I hope you look forward to the upcoming posts with more details. Also, to be perfectly clear about it: I also thank DSA for their help, and hope they will continue working with me to have our independent (yet slower) instance of Code Search running on Debian hardware.

My Internet connection is too flaky to use dput(-ng) reliably, so I use this tiny replacement instead:

#!/bin/sh
dcmd rsync --chmod=0644 -P "$@" ssh.upload.debian.org:/srv/upload.debian.org/UploadQueue/

The Debian Edu / Skolelinux project consist of both newcomers and old timers, and this time I was able to get an interview with a newcomer in the project who showed up on the IRC channel a few weeks ago to let us know about his successful installation of Debian Edu Wheezy in his School. Say hello to Dominik George. Who are you, and how do you spend your days? I am a 23 year-old student from Germany who has spent half of his life with open source. In "real life", I am, as already mentioned, a student in the fields of Computer Science, Electrical Engineering, Information Technologies and Anglistics. Due to my (only partially voluntary) huge engagement in the open source world, these things are a bit vacant right now however. I also have been working as a project teacher at a Gymasnium (public school) for various years now. I took up that work some time around 2005 when still attending that school myself and have continued it until today. I also had been running the (kind of very advanced) network of that school together with a team of very interested and talented students in the age of 11 to 15 years, who took the chance to learn a lot about open source and networking before I left the school to help building another school's informational education concept from scratch. That said, one might see me as a kind of "glue" between school kids and the elderly of teachers as well as between the open source ecosystem and the (even more complex) educational ecosystem. When I am not busy with open source or education, I like Geocaching and cycling. How did you get in contact with the Skolelinux / Debian Edu project? I think that happened some time around 2009 when I first attended FrOSCon and visited the project booth. I think I wasn't too interested back then because I used to have an attitude of disliking software that does too much stuff on its own. Maybe I was too inexperienced to realise the upsides of an "out-of-the-box" solution ;). The first time I actively talked to Skolelinux people was at OpenRheinRuhr 2011 when the BiscuIT project, a home-grewn software used by my school for various really cool things from timetables and class contact lists to lunch ordering, student ID card printing and project elections first got to a stage where it could have been published. I asked the Skolelinux guys running the booth if the project were interested in it and gave a small demonstration, but there wasn't any real feedback and the guys seemed rather uninterested. After I left the school where I developed the software, it got mostly lost, but I am now reimplementing it for my new school. I have reusability and compatibility in mind, and I hop there will be a new basis for contributing it to the Skolelinux project ;)! What do you see as the advantages of Skolelinux / Debian Edu? The most important advantage seems to be that it "just works". After overcoming some minor (but still very annoying) glitches in the installer, I got a fully functional, working school network, without the month-long hassle I experienced when setting all that up from scratch in earlier years. And above that, it rocked - I didn't have any real hardware at hand, because the school was just founded and has no money whatsoever, so I installed a combined server (main server, terminal services and workstation) in a VM on my personal notebook, bridging the LTSP network interface to the ethernet port, and then PXE-booted the Windows notebooks that were lying around from it. I could use 8 clients without any performance issues, by using a tiny little VM on a tiny little notebook. I think that's enough to say that it rocks! Secondly, there are marketing reasons. Life's bad, and so no politician will ever permit a setup described as "Debian, an universal operating system, with some really cool educational tools" while they will be jsut fine with "Skolelinux, a single-purpose solution for your school network", even if both turn out to be the very same thing (yes, this is unfair towards the Skolelinux project, and must not be taken too seriously - you get the idea, anyway). What do you see as the disadvantages of Skolelinux / Debian Edu? I have not been involved with Skolelinux long enough to really answer this question in a fair way. Thus, please allow me to put it in other words: "What do you expect from Skolelinux to keep liking it?" I can list a few points about that:

• always strive to get all things integrated into Debian upstream
• be open to discussion about changes and the like, even with newcomers
• be helpful at being helpful ;)

I'm really sorry I cannot say much more about that :(! Which free software do you use daily? First of all, all software I use is free and open. I have abandoned all non-free software (except for firmware on my darned phone) this year. I run Debian GNU/Linux on all PC systems I use. On that, I mostly run text tools. I use mksh as shell, jupp as very advanced text editor (I even got the developer to help me write a script/macro based full-featured student management software with the two), mcabber for XMPP and irssi for IRC. For that overly coloured world called the WWW, I use Iceweasel (Firefox). Oh, and mutt for e-mail. However, while I am personally aware of the fact that text tools are more efficient and powerful than anything else, I also use (or at least operate) some tools that are suitable to bring open source to kids. One of these things is Jappix, which I already introduced to some kids even before they got aware of Facebook, making them see for themselves that they do not need Facebook now ;). Which strategy do you believe is the right one to use to get schools to use free software? Well, that's a two-sided thing. One side is what I believe, and one side is what I have experienced. I believe that the right strategy is showing them the benefits. But that won't work out as long as the acceptance of free alternatives grows globally. What I mean is that if all the kids are almost forced to use Windows, Facebook, Skype, you name it at home, they will not see why they would want to use alternatives at school. I have seen students take seat in front of a fully-functional, modern Debian desktop that could do anything their Windows at home could do, and they jsut refused to use it because "Linux sucks". It is something that makes the council of our city spend around 600000 to buy software - not including hardware, mind you - for operating school networks, and for installing a system that, as has been proved, does not work. For those of you readers who are good at maths, have you already found out how many lives could have been saved with that money if we had instead used it to bring education to parts of the world that need it? I have, and found it to be nothing less dramatic than plain criminal. That said, the only feasible way appears to be the bottom up method. We have to bring free software to kids and parents. I have founded an association named Teckids here in Germany that does just that. We organise several events for kids and adolescents in the area of free and open source software, for example the FrogLabs, which share staff with Teckids and are the youth programme of the Free and Open Source Software Conference (FrOSCon). We do a lot more than most other conferences - this year, we first offered the FrogLabs as a holiday camp for kids aged 10 to 16. It was a huge success, with approx. 30 kids taking part and learning with and about free software through a whole weekend. All of us had a lot of fun, and the results were really exciting. Apart from that, we are preparing a campaign that is supposed to bring the message of free alternatives to stuff kids use every day to them and their parents, e.g. the use of Jabber / Jappix instead of Facebook and Skype. To make that possible, we are planning to get together a team of clever kids who understand very well what their peers need and can bring it across to them. So we will have a peer-driven network of adolescents who teach each other and collect feedback from the community of minors. We then take that feedback and our own experience to work closely with open source projects, such as Skolelinux or Jappix, at improving their software in a way that makes it more and more attractive for the target group. At least I hope that we will have good cooperation with Skolelinux in the future ;)! So in conclusion, what I believe is that, if it weren't for the world being so bad, it should be very clear to the political decision makers that the only way to go nowadays is free software for various reasons, but I have learnt that the only way that seems to work is bottom up.

Someone made my day today. On Friday, I bought something online, hoping that it gets delivered before Christmas. It wasn't something extraordinary, just some paper (no, I'm not joking). This should have arrived on Monday if shipped by PostPac Priority, but it didn't, so I assumed it was Economy, so arriving "sometime". On Sunday, knowing that it's already quite late, I made another (online) order, at a webshop that normally (i.e. not during holidays) delivers the next day. Not something too extraordinary again, some more paper (A3+ size this time ) and a gadget. After ordering, I saw the Swiss post website with "latest time to ship packages so that they arrive before Christmas". At that moment I realised I was too late, and that I won't get my present(s) in time. Today, I waited at home until about noon knowing that it's unlikely that I'll get my packages, but still hoping; nothing arrived, so I went into the city to do some errands. When I arrived home around 4 o'clock, there was nothing in my mailbox, and no notice that my delivery was attempted and that I need to pick up things at the post office. At this moment, I had to give up, but I was a bit down, just like a little boy who was told no present this time. I was hoping that I get at least one package, so I was double disappointed, to say so (spoiled much? first world problem as well, I know, but this post is not about that). As I got up the stairs, and reaching the door to the apartment, surprise! Not one, but both packages were waiting for me at the door. This happens very, very rarely - normally, I just get the "delivery failed" notice, and I pick the package up next day at the post office. Today, the postman was very nice. Dear postman: I don't know who you are, but you had a nice thought and made an effort so that I (a quite spoiled little boy) would get my presents in time. Thanks, and I hope someone gave you a nice present as well! And happy holidays (of whatever kind you celebrate) to everyone!

Fighting with passwords have always been one of my favorite battles in the past and unfortunately the former always won. I never liked using the root user that much for administering a machine and made a massive use of sudo, I won t list all the benefits of using sudo, but the following wiki page has a pretty nice overview of them. Said that, when using sudo it s definitely ideal to combine a strong password that is also easy to remember and type again when prompted. Sadly strong passwords that are also easy to remember can be considered an oxymoron. How hard would it be to recall a 30+ chars long password? Honestly that would be close to impossible for an human being but what if a little software available on the major GNU/Linux distributions could handle that for us? That s where pass comes handy, but what is pass? from the pass manpage itself:

pass is a very simple password store that keeps passwords inside gpg2(1) encrypted files inside a simple directory tree residing at ~/.password-store. The pass utility provides a series of commands for manipulating the password store, allowing the user to add, remove, edit, synchronize, generate, and manipulate passwords.

I m sure that a lot of you guys have been looking for a tool like this one for ages: pass allows you to generate very strong passwords with pwgen, GPG encrypt them with your GPG Key, store them safely on your disk and make them available whenever you need them with a single command. But let s move to the practice, give the following steps a try and enjoy how powerful your pass setup will be. First setup 1. Install the software:

yum/apt-get install pass

2. Generate a GPG Key if you don t have one already, a detailed guide can be found here. 3. Initialize your passwords storage. (GPGKEYID can be retrieved by running gpg list-keys and then looking for a line similar to this one: pub 4096R/B3A6223D 2012-06-25)

pass init GPGKEYID

4. Generate your first password and call it sudo_password given you are going to make use of it as your brand new sudo password. (we want it at least 30+ chars long)

pass generate sudo_password 30

5. (Optional) Create as much passwords as you need and make sure to save them with unique names, that way you will be able to identify what a password is used for easily.

pass generate gmail_password 30

Additional maintenance commands on your password database 1. Look at the existing passwords on your database.

pass ls

Result:

Password Store
  gmail_password
  sudo_password
  root_password

2. Manually edit a password.

pass edit password_name

3. Remove a password from your database.

pass rm password_name

4. Copy a password on your clipboard and paste it.

pass -c password_name

Are you wondering if pass supports a VCS? Yeah, it does, it currently allows you to manage your passwords database with Git, so that each applied change to the database will be tracked through a VCS so that you won t forget when and how you updated a specific password.

I read a post titled "Free software is NOT Free", and that triggered a few thoughts, which I would like to share here. While the post has some good thoughts, there are points in it which I disagree with strongly. You see, I've been writing free software almost half my life, most of the things I contributed to various projects, and the vast majority of my own projects, were made because it made me feel good. Because I scratched an itch, and sharing filled me with a sense of accomplishment.I always had bills to pay, and I have a day job to get that kind of thing sorted, yet, I do not believe that the quality of my free software work suffers because of that. Do I have less time? Yes, I do. But slower pace does not mean lesser quality - more often than not, I found that slower pace leads to better considerations, more care given to each change, because fixing it later, fast, is much more costly, so you make sure that your improvements will stand the trial of time.But I digress. I want to share a different view on the topic, based on my own experiences.When I first got into free software, I was young, bright-eyed, full of hopes and illusions of grandieur. I did my part of small contributions here and there, and every bit of "Thanks!", every bit of feedback - be it criticism or rejection - contributed to my development. This part of the free software culture is still important to me, and remains a major factor behind my desire to work on free software. Later on, there came another revelation: people actually use the stuff I write! That's an awesome feeling too, but with it, comes a burden too: supporting users, and trying to cater to every need that arises. To combat this, to not drown, you need to learn to say "No". It is hard, but as maintainer of a project, it's your task to keep it maintainable, and you need to know your limits. Would it be better if you could fulfil every wish? If you could do everything you ever dreamed of? You may think the answer is yes, but you're wrong. The answer is "No".Not everything needs to be done, not every wish needs to come true. As always, there's a balance. Limiting the amount of time that can be spent on a project helps keep that balance. And when balance is found, the project becomes more mature, maintenance stops being a chore you do not want to do, but have to, and instead becomes something you actually enjoy. We are human beings, we dream and wish for a lot, and we have a hard time realising our limits. That makes us feel sad, sometimes even inadequate. Having less time puts us into a different position, where were are forced to reevaluate how we spend the little free time we have. In the long run, I believe that is good for free software.But there's an even better way to approach the problem! You want to work on your projects, right? Yet, you also want to pay your bills. And you are a fan of free (as in freedom) software. When I found myself in a position like that, when I was looking for work, I was looking at companies which are friendly towards free software, and even have a few on their portfolio. Working for such a company allows me to be happy with myself, by not betraying my own beliefs, and on the side, still spend time on my own things.When I spend my day working on free software, I feel energised, and during lunch break, I can look through my plans for my own projects (some of which are related to my work too, which makes it even easier to spend time on them), plan ahead, and go home with a head full of ideas. No exhaustion after a daunting day of hacking proprietary software, with a sinking heart. No feeling guilty of not taking good care of your projects, because you do take care! You just do it on your own terms.So this is my suggestion to independent free software hackers: find a free software friendly company, that allows - or even encourages - you to work on your own things too. That way, you can pay your bills, and work on your hobbies, and best of all: keep them as hobbies, so it does not become a burden. When a hobby becomes your job, that often leaves a sour taste behind, when you can't fulfil every need, or fix every issue.Get a free software day-job, and keep your hobby as such, and everyone benefits. You get to keep your sanity, and users will receive better care, because the developers do what they love, and not what they have to.You give up some of your freedoms, yes, by not being independent. But being independent is not always the right choice. For some people, it may well be, for some, not so much. My experience over the past 15 years or so, is that independence brings a lot more headache than I'm willing to deal with. I'd rather work for a free software friendly company, where, after three years, I get paid to write and contribute to free software, and take care of my personal projects on the side, than try do all of it on my own.None of the software I wrote is worth a full salary, and none of them requires me to work full time on them, either. I could, mind you, I have enough ideas lined up to keep me busy for years. But do I want to? Do I want to burn myself out?No. The day job satisfies my hunger for contributing to a widely used piece of software, and my hobby projects satisfy my exploratory needs. I'm happy this way, and I'm very happy that thanks to the work and dedication of some amazing people, we got this far, that one can have a day job and independent projects too, that are all free software, without having to depend on fairly unreliable sources, such as donations (mind you, donations are a nice extra).There are, of course, different situations, and different people. What works for one, may not work for the other. This is what worked for me, and I felt the need to share it, lest anyone thinks that the world's darker than it really is.

Over the last few weeks I have been working on getting the Ziggurat normal random number generator updated and available in R. The Ziggurat generator provides a pretty unique combination of speed and good statistical properties for (standard) normal random numbers (as opposed to uniform draws as is commonn for most RNGs). Generation of N(0,1) draws may not by itself be the dominant slowdown in a simulation, yet when large number of draws are required it may be helpful to have a generator that is faster than the defaults in R (which have excellent properties, but not the fastest speed). A first release 0.0.1 went to CRAN a couple of weeks ago. This was followed up by a more thorough release 0.1.0 this last weekend which, as it happens, needed a minor follow-up 0.1.1 to clean up some dependencies on the right R version, as well as vignette building procedures. I added a web page about RcppZiggurat to group together some basic information, but the single best starting point may be the detailed pdf vignette included in the package. Courtesy of CRANberries, there are diffstat reports for the most recent release as well as for the preceding release two days earlier. More detailed information is on the RcppZiggurat 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.

Review: The Death of Bees, by Lisa O'Donnell

Publisher:	HarperCollins
Copyright:	2012
Printing:	2013
ISBN:	0-06-220984-1
Format:	Hardcover
Pages:	309

This is the first definite hit from my Powell's Indiespensable subscription, and a good example of why I subscribe. I never would have read or even heard of this book without it, and I thoroughly enjoyed it. Marnie and Nellie are sisters living in a housing estate in Glasgow's Maryhill district. Neither of their parents ever held regular jobs, although one does quickly learn their father had been earning money distributing drugs. The story opens, rather shockingly, with the death of both parents: their father smothered in his bed, and their mother, a day later, after refusing to notify anyone of their father's death, by hanging herself in the garden shed. In fear of being taken by social services and then separated, particularly given Nellie's unusual way of interacting with the world (she talks, and writes, like a woman in the 1950s trying to sound high-class), the girls bury both bodies in the back garden and tell everyone their parents just went on an unannounced trip without them. It wouldn't be the first time. Marnie is 15 and a year away from being legally an adult, at which point she can take custody of Nellie (who is 12) and keep them together. In the meantime, they just have to keep their parents' deaths secret and figure out how to keep food on the table and social services away. Their next-door neighbor is a formerly-closeted older gay man named Lennie who is known as the neighborhood pervert after he was arrested getting a blow job from an underage male prostitute. Both girls are quite understandably suspicious of him, but he's also the first person to notice that something is wrong and to start trying to help. The book is told in many short chapters, each written by one of Marnie, Nellie, or Lennie in their own voice. You might have guessed from the plot summary that this book needs a few warnings, but I want to emphasize that more. This is a book that opens with decaying corpses, including a few rather-too-vivid images from its transport and from Marnie's later (unnamed) post-traumatic stress. Marnie is quite sexually active, and both girls have had a nasty background full of things that I preferred not to think too much about. Most of the worst bits are only alluded to and are kept off-camera, but there's still quite a lot of background nastiness and desperation here. The Death of Bees is blunt and forthright to the point that it repeatedly made me cringe, and that sort of thing usually doesn't bother me in books. That said, this is not a horror novel, even though it contains horror. You could describe it as darkly comic, although none of the comedy is the sort that makes one laugh, except perhaps in startled surprise. The adjectives that come to mind are fierce, compassionate, empathetic, tough, and courageous. The author is completely on the side of the three protagonists, all of whom are deeply hurt in their own ways but all of whom are trying as hard as they can to support each other. I have rarely read a book that made me care as much about the characters. It's the kind of story that makes one want to passionately defend them, particularly once the one real villain, in the form of a do-gooding outsider, makes his appearance. And the reader and the author aren't alone. One of the things I loved about this book is that it doesn't artificially isolate the characters. Marnie has friends, and while Marnie doesn't always notice for Marnie, this is just her life, and many things of significance to the reader are just more of daily life for her this book is full of unexpected acts of small kindness. The surrounding characters are themselves all dealing with their own troubles and not in a great position to help anyone, and yet somehow they manage. Even Nellie, who has a great deal of difficulty interacting with other people her own age, gets unexpected help from people she thinks can't stand her. I think it's very telling that about the only character here who is entirely unsympathetic is the one who claims to be the most moral and virtuous. Unfortunately, from my perspective, this book has one major flaw: the ending. Thankfully, the ending isn't bad; if it were, it would have completely destroyed my enjoyment of the book. By the time one gets through this story, having something bad happen to these girls would break your heart. The ending does deliver the necessary catharsis, but it is far, far too short. O'Donnell builds up tension mercilessly, pushing the story down a path that's clearly desperately wrong for both of the girls, and doesn't let the story climax happen until about ten pages from the end. We get all of a page or two of denouement, and then the novel is over. I am, admittedly, a "Scouring of the Shire" sort of person. I like long denouements, particularly if I've gone through hell with the characters. I like getting to spend some happy time with them. But even for those who don't enjoy that as much as I do, I think this ending was too short. O'Donnell does an amazing job building sympathy and empathy throughout the story, and I didn't want to have to fill in all of the happily ever after from my own imagination. Maybe it would have been hard to do without getting too sentimental or without dulling some of the sharp edges of the story, but I would have really appreciated another ten pages. As is, it felt like the novel abruptly and unceremoniously dumped me out on the ground. But, that aside, this is an excellent character story. It's one that I would be careful about recommending; parts of it are extremely dark and nasty, and you have to take Marnie on her own terms for the story to work. But it's beautifully written and thoroughly engaging, and I'm very glad to have read it. Rating: 8 out of 10

Yesterday, I have managed to finish up an old pet peeve of mine. I wrote a series of patches to have harness reprocess all packages, which were last checked by an older version of Lintian than the current. It is not completed to the level I would like, but it is good enough for now. The implementation works by processing up to 1024 groups after each daily run. It also have a timer to skip this, if the run has taken more than 4 hours. Packages to be reprocessed are sorted by the version they were last processed should a new version of Lintian be upload before all packages have been reprocessed, the oldest results are refreshed first. A rough estimate suggests than in about 3-4 weeks, the entire archive will have been reprocessed with Lintian 2.5.20. It is by no means faster than a full run (which is about a week), but it is automatic and removes the human factor in keeping Lintian results up to date.

available from unstable, and hopefully soon from testing, too! The longer story: The xbmc package has been uninstallable and unbuildable in Debian unstable for quite some time. Mainly due to differing preferences of the XBMC project and Debian. Original XBMC source includes several embedded libraries, some patched to work with XBMC perfectly and to provide the best user experience the XBMC project prefers building XBMC with those libraries. In Debian, on the other hand, the recommended practice is not embedding libraries, but using the packaged versions instead to reduce the amount of security updates in case a library needs a security related fix, to save space on mirrors and to avoid divergence between the embedded versions of the libraries. One consequence of using externally packaged libraries is the need for making XMBC work with newer versions of the external libraries even when the embedded one would still work perfectly or (in some cases) there are even breakages due to changing APIs or new bugs in the library. XBMC depends on many libraries and the changes to them in Debian used to break one or another XBMC use case from time to time. The XBMC project received many direct bug reports from users of the Debian-shipped XBMC package which were harder than necessary to handle due to the lack of clear differentiation from the .deb packages provided directly by
them and using the embedded libraries. To help both users and developers the xbmc package starts using the XBMC from Debian name on the main screen and in the logs, the version number used inside the application is set to the Debian package s version, and README.Debian directs users of the package to Debian s BTS instead of XBMC s forums. The most notable difference between XBMC and XBMC from Debian is that XBMC uses
its embedded patched FFmpeg, while XBMC from Debian uses libav. If movies play too slow, too fast, without sound or too loud, you should definitely check BTS first. Happy Holidays and don t stay too much in front of the screen if XBMC from Debian happens to work for hours without any crash!