It s likely that most people make things like comfort, style, and price the main criteria when purchasing clothes. But there are other things that can be more important such as the ability to fit a phone in the pocket. My last pair of jeans was from Rivers (one of the more affordable Australian clothing stores which also has online sales) [1]. They were the long leg version and have front pockets that are 28cm deep (measured from the bottom of the pocket to the lowest part of the lip) and 15cm wide (a 15cm ruler will barely fit sideways in the pocket). I ve just got some new jeans from Rivers which are the regular leg length, they have front pockets which are 21cm deep and slightly more than 16cm wide. The old pair could fit a Nexus 7 tablet in the front pocket. The new pair should more easily fit such a tablet in the pocket but it might be less comfortable to walk with the tablet in the pocket. I don t plan to try using my front pocket for a tablet (I d be more likely to use a backpack or my Scott e vest [2]), but a Galaxy Note 2 (which is about the largest device that most people would want in their pocket) would fit nicely. I find the Rivers jeans to be quite comfortable and I like the way they look. They also only cost $25 online or $30 in the store. When I bought my first pair before I even had a 4 phone they were good value and they will be even better value early next year when I get a bigger phone. Even though Rivers jeans may wear out faster than more expensive brands, for $30 it s easy to just buy a few pairs at a time. During an email discussion of geeky clothing the issue of women s clothes having fewer and smaller pockets was raised. Unfortunately I didn t think to measure the pockets in women s jeans when I was at the Rivers to discover whether they have big pockets too. I ll do that next time I m in the area.

• [1] http://rivers.com.au/
• [2] http://www.scottevest.com/

After my last post I got curious about booting the Macbook in EFI mode. Because, well, why not? So I googled for a while and found this blog post which served as a great reference and comment on two other. I understand EFI is somewhat buggy and what works for me might not work for you. So be careful, have a rescue disk at hand. On that topic, I should say that I could not get this to work with Debian sid s 3.2 kernel, but 3.5 from experimental worked fine for me.

Hopefully, you after booting EFI succesfully. My main question before doing this was What works? , I had heard some weird rumours and mentions that you had to run X in framebuffer mode and weird stuff like that. This is bullshit. Everything works fine, with the same standard software and setup. Features:

• GNOME Shell, hence acceleration, works
• All drivers work: wireless, bluetooth, etc.
• No need to force AHCI mode on the disk controller
• No graphic flicker during the boot process
• A feeling of catching up with the times

So, here we go. I am posting my notes in shell-like since I find little benefit in turning them into an essay or something more textual. Good luck! # Install grub-efi-$arch.
# Usually $arch depends on your processor.
# Best bet: you can use OSX to check for this:
#
# $ ioreg -l -p IODeviceTree grep firmware-abi
# It will print EFI32, or EFI64. You know what to do.
$ sudo apt-get install grub-efi-amd64 # Now we need to mount the system EFI partition for GRUB2 to install
# itself on it.
# NOTE: you have to do this, installing the package is NOT enough.
$ sudo mkdir /boot/efi
$ sudo mount /dev/sda1 /boot/efi # Did you get the right partition?
# It should have an EFI directory with an APPLE directory inside.
# DO NOT DELETE THE APPLE DIRECTORY, PRICK.
$ ls /boot/efi
EFI/
$ ls /boot/efi/EFI/
APPLE/ # Create a new directory, debian will do.
# Run grub-install so GRUB2 drops its EFI code in the new directory.
$ sudo mkdir /boot/efi/EFI/debian
$ sudo grub-install
$ ls /boot/efi/EFI/
$ ls /boot/efi/EFI/debian/ # Help rEFIt know this is a GNU/Linux boot.
# rEFIt assigns icons depending on the name of the EFI file, grub64x is not in its list
$ sudo mv /boot/efi/EFI/debian/grub64x.efi /boot/efi/EFI/debian/e.efi # IMPORTANT: Add the proper modeset.
# For EFI-only systems: efi_uga
# For UEFI systems: efi_gop
# Without this you won t have any graphics.
$ sudo vim /etc/default/grub
...
GRUB_VIDEO_BACKEND="efi_uga"
... # Update grub, reboot. Hope that everything worked.
$ sudo update-grub Extra credit
You can clean your MBR from the old GRUB2-pc installation (if you installed it to the hybryd-MBR, like a sane person) from OSX:
$ sudo fdisk -u /dev/disk(tab-to-complete, verify it is the right disk) (Read the man page for your fdisk to be sure -u still means fix MBR while keeping partitions )

Quite on updated schedule (ie. one month later than originally planned), Weblate 1.3 has been released today. It comes with lot of improvements, especially in support of non gettext files, new quality checks and improved performance. Full list of changes for 1.3:

• Compatibility with PostgreSQL database backend.
• Removes languages removed in upstream git repository.
• Improved consistency checks processing.
• Added new checks (BB code, XML markup and newlines).
• Support for optional rebasing instead of merge.
• Possibility to relocate Weblate (eg. to run it under /weblate path).
• Support for manually choosing file type in case autodetection fails.
• Better support for Android resources.
• Support for generating SSH key from web interface.
• More visible data exports.
• New buttons to enter some special characters.
• Support for exporting dictionary.
• Support for locking down whole Weblate installation.
• Checks for source strings and support for source strings review.
• Support for user comments for both translations and source strings.
• Better changes log tracking.
• Changes can now be monitored using RSS.
• Improved support for RTL languages.

You can find more information about Weblate on it's website, the code is hosted on Github. If you are curious how it looks, you can try it out on demo server. You can login there with demo account using demo password or register your own user. Ready to run appliances will be soon available in SUSE Studio Gallery. Weblate is also being used https://l10n.cihar.com/ as official translating service for phpMyAdmin, Gammu, Weblate itself and others. If you are free software project which would like to use Weblate, I'm happy to help you with set up or even host Weblate for you (this will be decided case by case as my hosting space is limited).

Filed under: English Phpmyadmin Weblate 0 comments Flattr this!

As I've mentioned before, there was a keysigning party in Prague yesterday. Though we were afraid that not so many people will arrive, in the end I have signed 19 keys and assured 13 people for CAcert. The nice outcome of this is that I can now give up to 25 points when assuring for CAcert and altogether we are able to give you over 50 points in the Prague SUSE office. Unfortunately this also reminded me my problems with Unicode on CAcert and quick look at the bug tracker showed me that my bugs 769 and 770 are still open, valid and did not receive any attention :-(. PS: Of course after key signing, we had some fun with the openSUSE beer.

Filed under: English Suse 0 comments Flattr this!

A few months ago, I wrote about my reverse engineering attempt to Logitech Unifying devices. Back then, I concluded my post with big hopes on the future after receiving a document with some part of the specification of the HID++ 2.0 from Logitech. A couple of weeks ago, some of my summer work has been merged to UPower, adding battery support for some Logitech devices. HID++ As I discovered late in my first reverse engineering attempt, Logitech developed a custom HID protocol named HID++. This protocol exists in two versions, 1.0 and 2.0. Some devices talk with version 1 of the protocol (like my M705 mouse) and some others talk with version 2 of the protocol (like my K750 keyboard). Recently, I've been able to be in touch with a Logitech engineer who worked on the Linux support for the Unifying receiver, and he has been really helpful and exposed me some details about this protocol. Logitech made the decision to publish their HID++ specification publicly about a year ago, but still didn't do it. The internal review needed to publish such documents hasn't be done yet. The only published draft is just an extract of the specification, with even some typo in it as I discovered. Some other documents have been recently published, but I didn't have the time to review them. They contains HID++ 1.0 specifications and some details I asked for about the K750 keyboard. UPower support It took me sometime to get a full understanding of the protocol, its different version etc. After reverse engineering my K750 keyboard, I've also reverse engineered the data stream used to get my M705 mouse battery status. I've also received some information about the HID++ 1.0 protocol, so I've been able to discover a bit more on what the packets mean. Most of my discoveries are now used to do proper #define in up-lg-unifying.c so the code makes more sense. My first patch implements a new property for UPower devices, named luminosity, that use with K750 keyboard to report the light level received. The second patch add support for Logitech Unifying devices (over USB only) and should work with at least Logitech M705 and K750 devices. This should be available with the next version of UPower, which should be 0.9.19. So far, Logitech has been kind enough to help me understanding part of the protocol and even sent me a few devices so I can play and test my work with them. Unfortunately, this will probably requires some work and time, and so far Logitech was not able to help with that. There should be enough information out there to at least add support for battery to HID++ 2.0 devices, and probably a few other things too. I hope I'd get the time do this at some point, but feel free to beat me in this race!

As a followup to my toy over at debtree, I ve taken some suggestions from my buddy Arno and found some time in the hotel during a visit for work up to Canada with the Open North folks hacking on open13. The hack is called debfriends (I need to purge personal details from the source tree before I can push it to VCS, since it uses the nm.d.o dump. Sorry, I should have been better about that.) I ve posted a cute front-end on my staging machine to play with over at graph.lucifer.pault.ag There s also an API, but it has all the data in the NM dump exposed. If you re a DD who will treat this data right, I can add a key (it s not secure, like, at all). I m going to publish the source ASAP so that others can stand up an instance if they d like. It s a cute toy, though! In the tradition of using nhandler for my examples, here s an example path from pabs to Nathan: pabs > nhandler

• nhandler was advocated by paultag
• paultag was advocated by mako
• micah was advocated by mako
• pabs was advocated by micah

Also, we re a shockingly well connected bunch. Well done :) Feel free to play with it!

Contrary to http://blog.einval.com/2012/11/13, I ve just been and voted (four times, or 2 2 one for me, one as a proxy) for a police and crime commissioner. I agree with much of what Steve writes and more besides. It s a very bad election. But I voted for three main reasons: Firstly, parties I don t like will get their core vote out anyway. If we don t turn put, the election becomes more about party structures, less the popular wish. Secondly, democracy is imperfect, but it s the best we ve got. I ve interacted with two appointed police authorities and they re rubbish and they re untouchable/unaccountable. Thirdly, I expect policing to be a hot topic here if the government do actually try to build the incinerator that 65,000 people/90+% voted against. Best try to get a non-gov commissioner now, I think. So that s why I ve voted and encouraged other members of our co-op to vote.

No sooner had Henrique de Moraes Holschuh announced the availability of improved microcode updating in Wheezy (sadly non-free) than Stephan Seitz pointed out that this support was broken for systems running Xen, which is unfortunate since as Henrique notes the impact of not applying such an update could be pretty much anything. There's a bit of a saga here: a patch has been available for several years which adds Xen support to the kernel's microcode driver in a nicely self contained way. However the Linux maintainers have decided that loading microcode from the kernel is too late and it should be done earlier (e.g. by the bootloader, or some shim between the bootloader and the kernel) in order to be effective and on that basis rejected the Xen patch implementing the existing kernel based scheme. In the meantime Xen has implemented early loading of microcode via an additional multiboot module passed by the bootloader and this was released in Xen 4.2 in September. (so far I've not seen any progress on making any change to the native side but that's by the by). However Wheezy is going to be shipping with Xen 4.1 which doesn't yet have this support in it. So we are basically faced with two choices, either we backport the support from Xen 4.2 or we apply the kernel patch. The downside of backporting rather than taking the kernel patch is that the backport is non-trivial (although not totally unwieldy) while the kernel patch is pretty much entirely self-contained. The other downside of early the early loading scheme in general (for either native or Xen) is the need to update tools (e.g. update-grub) as well as modifying the microcode packaging to put the files somewhere that the bootloader can see them (so /boot). This certainly can't happen for Wheezy at this stage which basically rules out the backport approach. So, the upshot is I've filed Debian bug #693053 and applied the kernel patch to our tree. It's all a bit unsatisfactory but at least microcode loading will work for users running Xen on Wheezy. With any luck for Jessie the native early microcode loading code will have landed as well and the pain of the infrastructure updates can be shared.

With python-dbusmock you can provide mocks for arbitrary D-BUS services for your test suites or if you want to reproduce a bug. However, when writing actual tests for gnome-settings-daemon etc. I noticed that it is rather cumbersome to always have to set up the skeleton of common services such as UPower. python-dbusmock 0.2 now introduces the concept of templates which provide those skeletons for common standard services so that your code only needs to set up the particular properties and specific D-BUS objects that you need. These templates can be parameterized for common customizations, and they can provide additional convenience methods on the org.freedesktop.DBus.Mock interface to provide more abstract functionality like add a battery . So if you want to pretend you have one AC and a half-charged battery, you can now simply do

  def setUp(self):
     (self.p_mock, self.obj_upower) = self.spawn_server_template('upower',  )
  def test_ac_bat(self):
     self.obj_upower.AddAC('mock_AC', 'Mock AC')
     self.obj_upower.AddChargingBattery('mock_BAT', 'Mock Battery', 50.0, 1200)

Or, if your code is not in Python, use the CLI/D-BUS interface, like in shell:

  # start a fake system bus
  eval  dbus-launch 
  export DBUS_SYSTEM_BUS_ADDRESS=$DBUS_SESSION_BUS_ADDRESS
  # start mock upower on the fake bus
  python3 -m dbusmock --template upower &
  # add devices
  gdbus call --system -d org.freedesktop.UPower -o /org/freedesktop/UPower \
      -m org.freedesktop.DBus.Mock.AddAC mock_ac 'Mock AC'
  gdbus call --system -d org.freedesktop.UPower -o /org/freedesktop/UPower \
      -m org.freedesktop.DBus.Mock.AddChargingBattery mock_bat 'Mock Bat' 50.0 1200

In both cases upower --dump or gnome-power-statistics will show you the expected devices (of course you need to run that within the environment of the fake $DBUS_SYSTEM_BUS_ADDRESS, or run the mock on the real system bus as root). Iftikhar Ahmad contributed a template for NetworkManager, which allows you to easily set up ethernet and wifi devices and wifi access points. See pydoc3 dbusmock.templates.networkmanager for details and the test cases for how this looks like in practice. I just released python-dbusmock 0.2.1 and uploaded the new version to Debian experimental. I will sync it into Ubuntu Raring in a few hours.

We released Rcpp 0.10.0 earlier today. This post will just provide a simple example for one of the smaller new features -- the new namespace for functions from Rmath.h -- and illustrate one of the key features (Rcpp attributes) in passing. R, as a statistical language and environment, has very well written and tested statistical distribution functions providing probability density, cumulative distribution, quantiles and random number draws for dozens of common and not so common distribution functions. This code is used inside R, and available for use from standalone C or C++ programs via the standalone R math library which Debian / Ubuntu have as a package r-mathlib (and which can be built from R sources). User sometimes write code against this interface, and then want to combine the code with other code, possibly even with Rcpp. We allowed for this, but it required a bit of an ugly interface. R provides a C interface; these have no namespaces. Identifiers can clash, and to be safe one can enable a generic prefix Rf_. So functions which could clash such as length or error become Rf_length and Rf_error and are less likely to conflict with symbols from other libraries. Unfortunately, the side-effect is that calling, say, the probability distribution function for the Normal distribution becomes Rf_pnorm5() (with the 5 denoting the five parameters: quantile, mean, std.deviation, lowerTail, logValue). Not pretty, and not obvious. So one of the things we added was another layer of indirection by adding a namespace R with a bunch of inline'd wrapper functions (as well as several handful of unit tests to make sure we avoided typos and argument transposition and what not). The short example below shows this for a simple function taking a vector, and returning its pnorm computed three different ways:

#include <Rcpp.h>
// [[Rcpp::export]]
Rcpp::DataFrame mypnorm(Rcpp::NumericVector x)  
    int n = x.size();
    Rcpp::NumericVector y1(n), y2(n), y3(n);
    for (int i=0; i<n; i++)  
        // the way we used to do this
        y1[i] = ::Rf_pnorm5(x[i], 0.0, 1.0, 1, 0);
        // the way we can do it now
        y2[i] = R::pnorm(x[i], 0.0, 1.0, 1, 0);
     
    // or using Rcpp sugar in one go
    y3 = Rcpp::pnorm(x);
    return Rcpp::DataFrame::create(Rcpp::Named("Rold")  = y1,
                                   Rcpp::Named("Rnew")  = y2,
                                   Rcpp::Named("sugar") = y3);
 

This example also uses the new Rcpp attributes described briefly in the announcement blog post and of course in more detail in the corresponding vignette. Let us just state here that we simply provide a complete C++ function, using standard Rcpp types -- along with one 'attribute' declaration of an export via Rcpp. That's it -- even easier than using inline. Now in R we simply do

R> sourceCpp("mypnorm.cpp")

to obtain a callable R function with the C++ code just shown behind it. No Makefile, no command-line tool invocation -- nothing but a single call to sourceCpp() which takes care of things --- and brings us a compiled C++ function to R just given the source file with its attribute declaration. We can now use the new function to compute the probaility distribution both the old way, the new way with the 'cleaner' R::pnorm(), and of course the Rcpp sugar way in a single call. We build a data frame in C++, and assert that all three variants are the same:

R> x <- seq(0, 1, length=1e3)
R> res <- mypnorm(x)
R> head(res)
      Rold     Rnew    sugar
1 0.500000 0.500000 0.500000
2 0.500399 0.500399 0.500399
3 0.500799 0.500799 0.500799
4 0.501198 0.501198 0.501198
5 0.501597 0.501597 0.501597
6 0.501997 0.501997 0.501997
R> all.equal(res[,1], res[,2], res[,3])
[1] TRUE
R> 

This example hopefully helped to illustrate how Rcpp 0.10.0 brings both something really powerful (Rcpp attributes -- more on this another time, hopefully) and convenient in the new namespace for statistical functions.

TL;DR: There s a summary at the end of the article. Today I wanted to see why a dependency in a .deb-package from an external APT repository changed so that it became uninstallable. While dpkg-deb --info foobar.deb easily shows the control information, the changelog is in the filesystem part of the package. I could extract that one dpkg-deb, too, but I d have to extract either to some temporary directory or pipe it into tar which then can extract a single file from the archive and sent it to STDOUT:

dpkg-deb --fsys-tarfile foobar.deb   tar xOf - ./usr/share/doc/foobar/changelog.Debian.gz   zless

But that s tedious to type. The following command is clearly less to type and way easier to remember:

acat foobar.deb ./usr/share/doc/foobar/changelog.Debian.gz   zless

acat stands for archive cat is part of the atool suite of commands:

als

lists files in an archive.

$ als foobar.tgz
drwxr-xr-x abe/abe           0 2012-11-15 00:19 foobar/
-rw-r--r-- abe/abe          13 2012-11-15 00:20 foobar/bar
-rw-r--r-- abe/abe          13 2012-11-15 00:20 foobar/foo

acat

extracts files in an archive to standard out.

$ acat foobar.tgz foobar/foo foobar/bar
foobar/bar
bar contents
foobar/foo
foo contents

adiff

generates a diff between two archives using diff(1).

$ als quux.zip
Archive:  quux.zip
  Length      Date    Time    Name
---------  ---------- -----   ----
        0  2012-11-15 00:23   quux/
       16  2012-11-15 00:22   quux/foo
       13  2012-11-15 00:20   quux/bar
---------                     -------
       29                     3 files
$ adiff foobar.tgz quux.zip
diff -ru Unpack-3594/foobar/foo Unpack-7862/quux/foo
--- Unpack-3594/foobar/foo      2012-11-15 00:20:46.000000000 +0100
+++ Unpack-7862/quux/foo        2012-11-15 00:22:56.000000000 +0100
@@ -1 +1 @@
-foo contents
+foobar contents

arepack

repacks archives to a different format. It does this by first extracting all files of the old archive into a temporary directory, then packing all files extracted to that directory to the new archive. Use the --each (-e) option in combination with --format (-F) to repack multiple archives using a single invocation of atool. Note that arepack will not remove the old archive.

$ arepack foobar.tgz foobar.txz
foobar.tgz: extracted to  Unpack-7121/foobar'
foobar.txz: grew 36 bytes

apack

creates archives (or compresses files). If no file arguments are specified, filenames to add are read from standard in.

aunpack

extracts files from an archive. Often one wants to extract all files in an archive to a single subdirectory. However, some archives contain multiple files in their root directories. The aunpack program overcomes this problem by first extracting files to a unique (temporary) directory, and then moving its contents back if possible. This also prevents local files from being overwritten by mistake.

(atool subcommand descriptions from the atool man page which is licensed under GPLv3+. Examples by me.) I though miss the existence of an agrep subcommand. Guess why? atool supports a wealth of archive types: tar (gzip-, bzip-, bzip2-, compress-/Z-, lzip-, lzop-, xz-, and 7zip-compressed), zip, jar/war, rar, lha/lzh, 7zip, alzip/alz, ace, ar, arj, arc, rpm, deb, cab, gzip, bzip, bzip2, compress/Z, lzip, lzop, xz, rzip, lrzip and cpio. (Not all subcommands support all archive types.) Similar Utilities There are some utilities which cover parts of what atool does, too: Tools from the mtools package Yes, they come from the handle MS-DOS floppy disks tool package, don t ask me why. :-)

uz

gunzips and extracts a gzip d tar d archives

Advantage over aunpack: Less to type. :-)

Disadvantage compared to aunpack: Supports only one archive format.

lz

gunzips and shows a listing of a gzip d tar d archive

Advantage over als: One character less to type. :-)

Disadvantage compared to als: Supports only one archive format.

unp unp extracts one or more files given as arguments on the command line.

$ unp -s
Known archive formats and tools:
7z:           p7zip or p7zip-full
ace:          unace
ar,deb:       binutils
arj:          arj
bz2:          bzip2
cab:          cabextract
chm:          libchm-bin or archmage
cpio,afio:    cpio or afio
dat:          tnef
dms:          xdms
exe:          maybe orange or unzip or unrar or unarj or lha 
gz:           gzip
hqx:          macutils
lha,lzh:      lha
lz:           lzip
lzma:         xz-utils or lzma
lzo:          lzop
lzx:          unlzx
mbox:         formail and mpack
pmd:          ppmd
rar:          rar or unrar or unrar-free
rpm:          rpm2cpio and cpio
sea,sea.bin:  macutils
shar:         sharutils
tar:          tar
tar.bz2,tbz2: tar with bzip2
tar.lzip:     tar with lzip
tar.lzop,tzo: tar with lzop
tar.xz,txz:   tar with xz-utils
tar.z:        tar with compress
tgz,tar.gz:   tar with gzip
uu:           sharutils
xz:           xz-utils
zip,cbz,cbr,jar,war,ear,xpi,adf: unzip
zoo:          zoo

So it s very similar to aunpack, just a shorter command and it supports some more exotic archive formats which atool doesn t support. Also part of the unp package is ucat which does more or less the same as acat, just with unp as backend. dtrx From the man page of dtrx:

In addition to providing one command to extract many different archive types, dtrx also aids the user by extracting contents consistently. By default, everything will be written to a dedicated directory that s named after the archive. dtrx will also change the permissions to ensure that the owner can read and write all those files. Supported archive formats: tar, zip (including self-extracting .exe files), cpio, rpm, deb, gem, 7z, cab, rar, and InstallShield. It can also decompress files compressed with gzip, bzip2, lzma, or compress.

dtrx -l lists the contents of an archive, i.e. works like als or lz. dtrx has two features not present in the other tools mentioned so far:

• It can extract metadata instead of the normal contents from .deb and .gem files.
• It can extract archives recursively, i.e. can extract archives inside of archives.

Unfortunately you can t mix those two features. But you can use the following tool for that purpose: deepfind deepfind is a command from the package strigi-utils and recursively lists files in archives, including archives in archives. I ve already written a detailed blog-posting about deepfind and its friend deepgrep. tardiff tardiff was written to check what changed in source code tarballs from one release to another. By default it just lists the differences in the file lists, not in the files contents and hence works different than adiff. Summary atool and friends are probably the first choice when it comes to DWIM archive handling, also because they have an easy to remember subcommand scheme. uz and lz and the shortest way to extract or list the contents of a .tar.gz file. But nothing more. And you have to install mtools even if you don t have a floppy drive. unp comes in handy for exotic archive formats atool doesn t support. And it s way easier to remember and type than aunpack. dtrx is neat if you want to extract archives in archives or if you want to extract metadata from some package files with just a few keystrokes. For listing all files in recursive archives, use deepfind.

Wishing everyone reading this a happy Gujarati New Year (Vikram Samvat 2069, called Krodhin,) Diwali was a bit of a squib this year thanks to the aftermath of Hurricane Sandy but we survived relatively unscathed so I pray that in the upcoming year Lakshmi Ma will give a portion of my good fortune to those who are still suffering.

Here is another interview with one of the people in the Debian Edu and Skolelinux community. I am running short on people willing to be interviewed, so if you know about someone I should interview, Please send me an email. After asking for many months, I finally managed to lure another one of the people behind the German "IT-Zukunft Schule" project out from maternity leave to conduct an interview. Give a warm welcome to Angela Fu . :) Who are you, and how do you spend your days? I am a 39-year-old woman living in the very north of Germany near Denmark. I live in a patchwork family with "my man" Mike Gabriel, my two daughters, Mikes daughter and Mikes and my rather newborn son. At the moment - because of our little baby - I am spending most of the day by being a caring and organising mom for all the kids. Besides that I am really involved into and occupied with several inner growth processes: New born souls always bring the whole familiar system into movement and that needs time and focus ;-). We are also in the middle of buying a house and moving to it. In 2013 I will work again in my job in a German foundation for nature conservation. I am doing public relation work there. Besides that - and that is the connection to Skolelinux / Debian Edu - I am working in our own school project "IT-Zukunft Schule" in North Germany. I am responsible for the quality assurance, the customer relationship management and the communication processes in the project. Since 2001 I constantly have been training myself in communication and leadership. Besides that I am a forester, a landscaping gardener and a yoga teacher. How did you get in contact with the Skolelinux / Debian Edu project? I fell in love with Mike ;-). Very soon after getting to know him I was completely enrolled into Free Software. At this time Mike did IT-services for one newly founded school in Kiel. Other schools in Kiel needed concepts for their IT environment. Often when Mike came home from working at the newly founded school I found myself listening to his complaints about several points where the communication with the schools head or the teachers did not work. So we were clear that he would not work for one more school if we did not set up a structure for communication between him, the schools head, the teachers, the students and the parents. Together with our friend and hardware supplier Andreas Buchholz we started to get an overview of free software solutions suitable for schools. One day before Christmas 2010 Mike and I had a date with Kurt Gramlich in G tersloh. As Kurt and I are really interested in building networks of people and in being in communication we dived into Skolelinux and brought it to the first grammar schools in Northern Germany. For information about our school project you can read the interview with Mike Gabriel. What do you see as the advantages of Skolelinux / Debian Edu? First I have to say: I cannot answer this question technically. My answer comes rather from a social point of view. The biggest advantage of Skolelinux / Debian Edu I see is the large and strong international community of Debian Developers in the background which is very alive and connected over mailinglists, blogs and meetings. My constant feeling for the Debian Community is: If something does not work they will somehow fix it. All is well ;-). This is of course a user experience. What I also get as a big advantage of Skolelinux / Debian Edu is that everybody who uses it and works with it can also contribute to it - that includes students, teachers, parents... What do you see as the disadvantages of Skolelinux / Debian Edu? I will answer this question relating to the internal structure of Skolelinux / Debian Edu. What I see as a major disadvantage is that there is a gap between the group of developers for Debian Edu and the people who make the marketing, that means the people that bring Skolelinux to the schools. There is a lack of communication between these two groups and I think that does not really work for Skolelinux / Debian Edu. Further I appreciate that Skolelinux / Debian Edu is known as a do-ocracy. Nevertheless I keep asking myself if at some points a democracy or some kind of hierarchical project structure would be good and helpful. I am also missing some kind of contact between the Skolelinux / Debian Edu communities in Europe or on an international level. I think it would be good if there was more sharing between the different countries using Skolelinux / Debian Edu. Which free software do you use daily? On my laptop I am still using an Ubuntu 10.04 with a Gnome Desktop on. As applications I use Openoffice.org, Gedit, Firefox, Pidgin, LaTeX and GnuCash. For mails I am using Horde. And I am really fond of my N900 running with Maemo. Which strategy do you believe is the right one to use to get schools to use free software? I am really convinced that in our school project "IT-Zukunft Schule" we have developed (and keep developing) a great way to get schools to use Free Software. We have written a detailed concept for that so I cannot explain the whole thing here. But in a nutshell the strategy has three crucial pillars:

• We really take time to get what sort of stories, questions and concerns the schools head and the teachers have about using different kinds of IT and we take time to enrol them into Free Software.
• Our solution for schools is never just technical. In the centre are always the people who are going to use the software. From the very beginning of the planning for a school, we tell the schools head that they are paying us not only for a technical solution for their school, they also pay us for leading all the communication processes needed. If they do not want that, we are not working with them because we cannot give a guarantee for the quality of our work then.
• Another focus lies in the training of teachers and students in co-administrating the IT-System at their school. They start getting in contact with the Skolelinux / Debian Edu community and they get the offer to become more and more independent from us.

Tomorrow (Thursday 15th November), there will be a PGP key signing and CAcert assurance party in Prague. It will be held in SUSE offices and it will start at 17:00. If you are interesting in having your PGP key signed, bring papers with your key fingerprint (you can use for example these slips) and some government issued ID. For CAcert assurance it is recommended to bring printed out assurance papers (you can get them from CAcert website) and of course IDs as well. You can find more information on Facebook or Google+ event pages.

Filed under: English Suse 2 comments Flattr this!

I am organizing two signing parties in France:

• Saturday, November 17th at 12:15 at the JDLL in Lyon;
• Sunday, November 25th at 11:45 at the Mini-DebConf in Paris.

Lyon, November 17th This will be an informal key signing party: just come with your ID documents and paper strips with your public key fingerprint. The signing party will occur at 2012-11-17 12:15+01:00 in the Maison Pour Tous in Lyon, France.

Paris, November 25th This will be a formally organized key signing party. If you want to participate, you should follow the indications given in the event wiki page. Basically:

1. send me your public key;
2. print some copies of your key fingerprint for people that did not register;
3. print the attendees list I shall send you before the event;
4. come to the signing party with all that, ID documents and a pen.

The signing party will occurr at 2012-11-25 11:45+01:00 in the pita school in Le Kremlin-Bic tre, France.

Tips To print strips with your public key fingerprint, you can use the utility gpg-key2ps from the package signing-party. If you are a user of the CAcert.org SSL certification authority, you can come to these signing parties with some copies of the accreditation form: it will be an opportunity to get or give CAcert.org accreditation.

I do like the way programmers think in terms of DRY, for instance, among other forms of optimization. A couple of days ago I wanted to test different implementations of the same algorithm in C++. The usual approach would be to implement those algorithms, call them in main() and see the results. A more interesting approach would be to write a validator for each function and print whether the result is correct or not. Since both are boring and break the rule of DRY, I ve decided to go complicated but productive, so I ve implemented a function testing method using function pointers that will allow me to write a single function and use it to test the algorithms using different input and expected results. Let s say I have 3 algorithms that implement Modular Exponentiation.
uint64 modexp1new(const uint64 &a, const uint64 &_p, const uint64 &n)
...


uint64 modexp2(const uint64 &_a, const uint64 &_p, const uint64 &_n)
...


uint64 modexp3(const uint64 &a, const uint64 &p, const uint64 &n)
...

If you are not familiar with the syntax, const means that the parameter is constant, thus it will not be modified inside the function. The & means that the parameter is passed as a reference, read the memory address of the calling variable, so we don t overload RAM with new variables. Now, the testing part. For my very own purposes I just want to test those particular functions and know whether if the result they output conforms what I do expect. Some people call this unit testing.
I do also want to test it in different scenarios, meaning input and output. So, I m creating a function that will get the three parameters required to call the functions, and a fourth parameter that is the value I do expect to be the correct answer. Now, since I don t want to repeat myself writing a call for each case, I m going to create a function pointer that is an array and has the function s address as their value. That way I can call them in a loop, and voila! we are done. Finally, after calling the function I check the result with the expected value and print an OK or FAIL. Tricky part for this could be understanding the function pointer. Two things to consider: the returning value from the referenced functions has to be the same for all. Second: the input definition for each function has to be similar too. This is important because function pointers are just pointers and they need to know the size of the data type in order to navigate the memory. For this sample code the uint64 is a typedef for long long, of course. Full code is below.
void testAlgos(const uint64 &a, const uint64 &e, const uint64 &n, const uint64 &r)
uint64 (*fP[3])(const uint64&, const uint64&, const uint64&) = &modexp1new, &modexp2, &modexp3 ;
uint64 t; for(int i=0; i<3; i++) t = fP[i](a, e, n); std::cout < < "F(" << i << ") " << t << "\t";
if (t == r)
std::cout << "OK";
else
std::cout << "FAIL";

std::cout << std::endl;

Now that I have this, I can use it in main this way.
int main() uint64 a = 3740332;
uint64 e = 44383;
uint64 n = 3130164467;
uint64 r = 1976425102; testAlgos(a, e, n, r); a = 404137263;
r = 2520752541; testAlgos(a, e, n, r); a = 21;
e = 3;
n = 1003;
r = 234;
testAlgos(a, e, n, r); return 0;
Resulting in:
F(0) 657519405 FAIL
F(1) 1976425102 OK
F(2) 657519405 FAIL
F(0) -2752082808 FAIL
F(1) 2520752541 OK
F(2) -2752082808 FAIL
F(0) 234 OK
F(1) 234 OK
F(2) 234 OK
I m happy about not having to write tests like this for all use cases:
std::cout < < "f1: " << modexp1new(a, e, n) << std::endl;
std::cout << "f2: " << modexp2(a, e, n) << std::endl;
std::cout << "f3: " << modexp3(a, e, n) << std::endl;
Now, happiness can be more exciting if I do use templates so I can test any function independent of the data type for the returning and input values. You know, more abstraction. Homework if time allows! Have fun!
Related posts:

1. Compute Clusters Integration for Debian Development and Building Report 4 Hello, this is the fourth report for the project. First,...
2. Compute Clusters Integration for Debian Development and Testing Report 3 Hello this is the third report regarding my project. As...
3. Compute clusters for Debian development and building final report Compute clusters for Debian development and building final report...

In recent times we have worked quite a bit to improve the NM process, i.e. the process newcomers go through to become members of the Debian Project. As it happens, I've just read Nathan's recent post on his NM experience and I think it is a perfect example of the joining experience we are trying to offer to all newcomers. But examples, be them positive or negative, are only anecdotal. To evaluate a process one needs actual data and someone analyzing them, ideally with a scientific approach. This is why I'm happy to host below a guest blog post by Kevin Carillo, who is doing a pretty thorough scientific study about how newcomers join a wide range of Free Software projects, including KDE, OpenSUSE, GNOME, and Debian, of course! TL;DR: if you started contributing to Debian after January 2010, there's a survey for you; participating will help us improving the NM process even further. Kevin's guest blog post follows.

---

Newcomer experience in Debian and other FOSS communities - Survey My name is Kevin Carillo. I am a PhD student currently living in Wellington (New Zealand) and I am doing some research on Free/Open Source Software communities. If you have started contributing to the Debian project after January 2010 (within approximately the last 3 years), I would like to kindly request your help. I am interested in hearing from people who are either technical or non-technical contributors, and who have had either positive or negative newcomer experiences. The purpose of the research is to work out how newcomers to a FOSS community become valued sustainable contributors. The survey is online and will be available until Tuesday, 27 November, 2012. Inspiration from Debian New Member Debian is a successful community that keeps attracting new contributors and that relies on a very unique way to handle the integration of new contributors: the New Member process. The idea behind the NM process is that it is some sort of filtering procedure allowing to only retain the individuals who have the potential to become valued sustainable contributors in Debian. Within Debian, there is a lot of enthusiasm and pride around the NM process as it seems to be functioning pretty well but the question is: Is this really enough to ensure that Debian remains a healthy and growing community? How does it compare to the way newcomers are integrated in other large projects such as KDE, GNOME, or in other non-Linux related communities such as Mozilla? I have to admit that the Debian NM process has been among the main sources of inspiration that made me embark in this research project. I have kept being quite impressed when talking to people who had gone through the process as all of them came out of it with a real passion for the project and love for its community. When reflecting on the reasons why the NM process succeeds, I have a feeling it is some instance of ritualized socialization. In other words, barriers and initiation rituals that require some effort from newcomers, generate members with higher commitment and sense of identification towards the Debian community. What do newcomers really experience? The main assumption that motivated this project is that attracting new members has become crucial for a large majority of FOSS communities but this is not a sufficient condition to ensure the success and prosperity of a project. A proportion of a community's newcomers must contribute to the well-being and growth of the community. Keeping all that in mind, FOSS projects have thus to do a good job at "socializing" their newcomers and turning them into 'good' contributors. Doing a good job here means that FOSS projects shall ensure that they help generate citizenship-like behaviors from newcomers by designing appropriate newcomer programs and procedures. FOSS communities rely on a wide array of initiatives to facilitate the integration of newcomers but it seems like the other side of the coin is less understood: What do newcomers really experience? And how does this influence their contributions and actions within a project? How is this study going to help Debian? The data will help gain insights about the experience of newcomers within the Debian community. In addition, it will allow to understand how to design effective newcomer initiatives to ensure that Debian will remain a successful and healthy community. The dataset will be released under a share-alike ODbL license so that Debian contributors can extract as much value as possible from the data. Since this survey also involves other large FOSS projects such as Mozilla, KDE, Gnome, Ubuntu, Gentoo, OpenSUSE, and NetBSD, it will also be possible to compare practices across projects in order to identify what works from what does not work when facilitating the integration of newcomers. About the survey This survey is anonymous. The raw dataset of everything one fills in the survey will be released under the ODbL. Since all the questions but one are optional, one is free to control the amount of information they are giving away about themselves. I expect the survey to take around 20 minutes of your time. If you know members of the Debian community who you think would be interested in completing it, please do not hesitate to let them know about this research. I will post news about my progress with this research, and the results on my blog. Don't hesitate to contact me. --- Kevin Carillo

For the last couple of years, one of the topics I have tackled with several columns and a couple of articles published, several presentations on conferences and many comments wherever I can is raising awareness on why security experts around the world oppose electronic voting. Slightly over a year ago, I started gathering all the published news (in Spanish, with some notes in English if I feel them relevant enough) that came to my greedy hands and archiving them, categorized as well as I could, into what I came to call an Electronic voting observatory. I don't feed it with the frequency I'd like, but overall I do feel there is an interesting amount of information in there. About a month and a half ago, via Twitterfeed, I set up a Twitter account where my bot echoes everything I get on that regard. So, while you can follow the observatory via RSS (as probably most readers of my blog will do), I know there are many Twitter users among you @e_voto might be interesting to you if you speak Spanish and are interested in the topic. I try not to be partisan on the information I copy there; of course I am subjective (I try not to refer to news which don't provide new insight or data points, or to obvious repeats), but I am doing this effort to follow the development as it unfolds, not to push my viewpoints.