Yesterday I played with LXC a bit, and I liked it, as LXC provides a very lightweight isolation of processes, much like enchanced chroot. However, I realised, I don t always need the chroot-like part of LXC, sometimes what I need is just to make sure the process is unable to see the other processes and talk to them in any other way except the filesystem, but I don t want a whole separate root file system for that. LXC provides a simple utility, lxc-unshare, which uses Linux-specific clone(2) call to run a process with new PID, IPC and other namespaces. However, this utility can t be used for running forking daemons, as the container is destroyed when its PID 1 exits. That s why I decided to add the support for process isolation to start-stop-daemon. I was careful enough to introduce minimal changes to it to make sure they can be merged back to the version as shipped with dpkg, and at the same time be buildable separately from the rest of it. Speaking of building, by the way, this version of start-stop-daemon uses mk-configure, a light-weight autotools replacement, as its build system. What I added, from a user s perspective, is a single --isolate option. When run with this option, start-stop-daemon calls clone(2) just before configuring the environment of a process it s going to run. The cloned process runs in a new namespace, and immediately remounts /proc, /dev/shm and /dev/mqueue. Then it forks, and a forked process executes the daemon. The parent process, which is PID 1 in the new PID namespace, uses waitpid(2) to monitor its child processes. As soon as its very first child exits, it talks via a pipe to the process outside of the container, so that it knows the container has a forked daemon and it needs to detach. In any case, the container s PID 1 does waitpid(2) in a loop, checking the process list every time a child terminates. As soon as it s left alone or a SIGTERM is received, it exits. The code is published at Bitbucket.

Or, "Why 2014 will NOT be the year of Linux in the desktop". So, it happens that my mum (66 yo) has been a Debian user for over a year now. With highs and lows, she manages to do what she needs; sometimes I need to intervene. Today I thought I could send her a quick email explaining how to download using BitTorrent, because of reasons. So, as I was writing, I realised that in many torrent sites, you only get a magnet link these days. No problem! Click on the magnet link, at it should work automagically. Then I remembered: it works on my computer, because I've spent a couple of hours some time ago researching how to make FireFox work with magnet links, creating a custom script, etc. I hoped that by now this must have been solved, at least in Debian unstable. Wrong again. I created a new user in my computer, launched IceWeasel/FireFox and boom: I get a dialog asking me to select a program, not from a list of desktop applications, taken from one of the gazillion sources where applications are defined, but just from any place on the file system! (At least, now you don't need to go tweaking with the hidden FireFox configuration editor). I was very angry at the brainiac at Mozilla who thought it was a great idea to ignore the host system and do their own MIMEtype handling. And then, tried Chromium to see what would happen... And I get first a scary message telling me that it is going to use the super-obscure xdg-open program to open my link, and that it could harm my computer! It was followed by another very helpful dialog telling me something like:

Unable to detect the URI-scheme of "magnet:?xt=urn:btih:diePh6iengei4quaep4shai8ahshahnae9 oolahtetheir2bohmu1eelaChui1ohdahruegh4wief6PusahDae4ho oshahjoogai7bae9shuvei9shufeX4boog8neichi3OoDee5ei9Uori c6aingairepon9gok8Mee7uRahphah4EucoopheiYin4xe4lahn0goh"

Then the real fun started... I starting looking around to understand how this is supposed to work, I wanted to provide a patch! So, it turns out that if you add some values to GConf this should work. So, try to find where would that be. Read about GConf schemas, default and mandatory values, and their 10 possible locations. Find that Azureus provides an schema, use that to create one for Transmission. Then find that in fact, Transmission was providing defaults, which are not the same but work the same, and that they had an error there: yes, problem found! (#741069) No! It turns out that the Gnome desktop does not use that any more, and now they scan the .desktop (who knows in which of the 100 directory tress where .destop files are present) files for MIME handlers, and the transmission-gtk.desktop file had that correctly. So why does it not work? Well, it turns out that if I used gvfs-open instead of xdg-open, it did work! The thing is, I am running XFCE here, which is GTK based, but it is not Gnome: instead of gvfs-open, I was getting exo-open, which is it's brain-dead cousin, and can't do anything but files, email and web. It is fecking 2014, and we still don't have a sensible, unified way to select preferred applications. We still have incompatible, duplicated, incomplete, competing implementations. We have FreeDesktop doing one thing to try and unify criteria, which is then ignored or mis-implemented up and down by some desktops and applications. Some days I get really angry at the Free Software world. PS: I guess I will tell mum to copy&paste the links from the browser to the torrent client, but not today. I have already lost 4 hours of sleep on this.

Brief Glamor Hacks Eric Anholt started writing Glamor a few years ago. The goal was to provide credible 2D acceleration based solely on the OpenGL API, in particular, to implement the X drawing primitives, both core and Render extension, without any GPU-specific code. When he started, the thinking was that fixed-function devices were still relevant, so that original code didn t insist upon modern OpenGL features like GLSL shaders. That made the code less efficient and hard to write. Glamor used to be a side-project within the X world; seen as something that really wasn t very useful; something that any credible 2D driver would replace with custom highly-optimized GPU-specific code. Eric and I both hoped that Glamor would turn into something credible and that we d be able to eliminate all of the horror-show GPU-specific code in every driver for drawing X text, rectangles and composited images. That hadn t happened though, until now. Fast forward to the last six months. Eric has spent a bunch of time cleaning up Glamor internals, and in fact he s had it merged into the core X server for version 1.16 which will be coming up this July. Within the Glamor code base, he s been cleaning some internal structures up and making life more tolerable for Glamor developers. Using libepoxy A big part of the cleanup was a transition all of the extension function calls to use his other new project, libepoxy, which provides a sane, consistent and performant API to OpenGL extensions for Linux, Mac OS and Windows. That library is awesome, and you should use it for everything you do with OpenGL because not using it is like pounding nails into your head. Or eating non-tasty pie. Using VBOs in Glamor One thing he recently cleaned up was how to deal with VBOs during X operations. VBOs are absolutely essential to modern OpenGL applications; they re really the only way to efficiently pass vertex data from application to the GPU. And, every other mechanism is deprecated by the ARB as not a part of the blessed core context . Glamor provides a simple way of getting some VBO space, dumping data into it, and then using it through two wrapping calls which you use along with glVertexAttribPointer as follows:

pointer = glamor_get_vbo_space(screen, size, &offset);
glVertexAttribPointer(attribute_location, count, type,
              GL_FALSE, stride, offset);
memcpy(pointer, data, size);
glamor_put_vbo_space(screen);

glamor_get_vbo_space allocates the specified amount of VBO space and returns a pointer to that along with an offset , which is suitable to pass to glVertexAttribPointer. You dump your data into the returned pointer, call glamor_put_vbo_space and you re all done. Actually Drawing Stuff At the same time, Eric has been optimizing some of the existing rendering code. But, all of it is still frankly terrible. Our dream of credible 2D graphics through OpenGL just wasn t being realized at all. On Monday, I decided that I should go play in Glamor for a few days, both to hack up some simple rendering paths and to familiarize myself with the insides of Glamor as I m getting asked to review piles of patches for it, and not understanding a code base is a great way to help introduce serious bugs during review. I started with the core text operations. Not because they re particularly relevant these days as most applications draw text with the Render extension to provide better looking results, but instead because they re often one of the hardest things to do efficiently with a heavy weight GPU interface, and OpenGL can be amazingly heavy weight if you let it. Eric spent a bunch of time optimizing the existing text code to try and make it faster, but at the bottom, it actually draws each lit pixel as a tiny GL_POINT object by sending a separate x/y vertex value to the GPU (using the above VBO interface). This code walks the array of bits in the font and checking each one to see if it is lit, then checking if the lit pixel is within the clip region and only then adding the coordinates of the lit pixel to the VBO. The amazing thing is that even with all of this CPU and GPU work, the venerable 6x13 font is drawn at an astonishing 3.2 million glyphs per second. Of course, pure software draws text at 9.3 million glyphs per second. I suspected that a more efficient implementation might be able to draw text a bit faster, so I decided to just start from scratch with a new GL-based core X text drawing function. The plan was pretty simple:

1. Dump all glyphs in the font into a texture. Store them in 1bpp format to minimize memory consumption.
2. Place raw (integer) glyph coordinates into the VBO. Place four coordinates for each and draw a GL_QUAD for each glyph.
3. Transform the glyph coordinates into the usual GL range (-1..1) in the vertex shader.
4. Fetch a suitable byte from the glyph texture, extract a single bit and then either draw a solid color or discard the fragment.

This makes the X server code surprisingly simple; it computes integer coordinates for the glyph destination and glyph image source and writes those to the VBO. When all of the glyphs are in the VBO, it just calls glDrawArrays(GL_QUADS, 0, 4 * count). The results were encouraging :

1: fb-text.perf
2: glamor-text.perf
3: keith-text.perf
       1                 2                           3                 Operation
------------   -------------------------   -------------------------   -------------------------
   9300000.0      3160000.0 (     0.340)     18000000.0 (     1.935)   Char in 80-char line (6x13) 
   8700000.0      2850000.0 (     0.328)     16500000.0 (     1.897)   Char in 70-char line (8x13) 
   6560000.0      2380000.0 (     0.363)     11900000.0 (     1.814)   Char in 60-char line (9x15) 
   2150000.0       700000.0 (     0.326)      7710000.0 (     3.586)   Char16 in 40-char line (k14) 
    894000.0       283000.0 (     0.317)      4500000.0 (     5.034)   Char16 in 23-char line (k24) 
   9170000.0      4400000.0 (     0.480)     17300000.0 (     1.887)   Char in 80-char line (TR 10) 
   3080000.0      1090000.0 (     0.354)      7810000.0 (     2.536)   Char in 30-char line (TR 24) 
   6690000.0      2640000.0 (     0.395)      5180000.0 (     0.774)   Char in 20/40/20 line (6x13, TR 10) 
   1160000.0       351000.0 (     0.303)      2080000.0 (     1.793)   Char16 in 7/14/7 line (k14, k24) 
   8310000.0      2880000.0 (     0.347)     15600000.0 (     1.877)   Char in 80-char image line (6x13) 
   7510000.0      2550000.0 (     0.340)     12900000.0 (     1.718)   Char in 70-char image line (8x13) 
   5650000.0      2090000.0 (     0.370)     11400000.0 (     2.018)   Char in 60-char image line (9x15) 
   2000000.0       670000.0 (     0.335)      7780000.0 (     3.890)   Char16 in 40-char image line (k14) 
    823000.0       270000.0 (     0.328)      4470000.0 (     5.431)   Char16 in 23-char image line (k24) 
   8500000.0      3710000.0 (     0.436)      8250000.0 (     0.971)   Char in 80-char image line (TR 10) 
   2620000.0       983000.0 (     0.375)      3650000.0 (     1.393)   Char in 30-char image line (TR 24)

This is our old friend x11perfcomp, but slightly adjusted for a modern reality where you really do end up drawing billions of objects (hence the wider columns). This table lists the performance for drawing a range of different fonts in both poly text and image text variants. The first column is for Xephyr using software (fb) rendering, the second is for the existing Glamor GL_POINT based code and the third is the latest GL_QUAD based code. As you can see, drawing points for every lit pixel in a glyph is surprisingly fast, but only about 1/3 the speed of software for essentially any size glyph. By minimizing the use of the CPU and pushing piles of work into the GPU, we manage to increase the speed of most of the operations, with larger glyphs improving significantly more than smaller glyphs. Now, you ask how much code this involved. And, I can truthfully say that it was a very small amount to write:

 Makefile.am             2 
 glamor.c                5 
 glamor_core.c           8 
 glamor_font.c         181 ++++++++++++++++++++
 glamor_font.h          50 +++++
 glamor_priv.h          26 ++
 glamor_text.c         472 +++++++++++++++++++++++++++++++++++++++++++++++++++++
 glamor_transform.c      2 
 8 files changed, 741 insertions(+), 5 deletions(-)

Let s Start At The Very Beginning The results of optimizing text encouraged me to start at the top of x11perf and see what progress I could make. In particular, looking at the current Glamor code, I noticed that it did all of the vertex transformation with the CPU. That makes no sense at all for any GPU built in the last decade; they ve got massive numbers of transistors dedicated to performing precisely this kind of operation. So, I decided to see what I could do with PolyPoint. PolyPoint is absolutely brutal on any GPU; you have to pass it two coordinates for each pixel, and so the very best you can do is send it 32 bits, or precisely the same amount of data needed to actually draw a pixel on the frame buffer. With this in mind, one expects that about the best you can do compared with software is tie. Of course, the CPU version is actually computing an address and clipping, but those are all easily buried in the cost of actually storing a pixel. In any case, the results of this little exercise are pretty close to a tie the CPU draws 190,000,000 dots per second and the GPU draws 189,000,000 dots per second. Looking at the vertex and fragment shaders generated by the compiler, it s clear that there s room for improvement. The fragment shader is simply pulling the constant pixel color from a uniform and assigning it to the fragment color in this the simplest of all possible shaders:

uniform vec4 color;
void main()
 
       gl_FragColor = color;
 ;

This generates five instructions:

Native code for point fragment shader 7 (SIMD8 dispatch):
   START B0
   FB write target 0
0x00000000: mov(8)          g113<1>F        g2<0,1,0>F                        align1 WE_normal 1Q  ;
0x00000010: mov(8)          g114<1>F        g2.1<0,1,0>F                      align1 WE_normal 1Q  ;
0x00000020: mov(8)          g115<1>F        g2.2<0,1,0>F                      align1 WE_normal 1Q  ;
0x00000030: mov(8)          g116<1>F        g2.3<0,1,0>F                      align1 WE_normal 1Q  ;
0x00000040: sendc(8)        null            g113<8,8,1>F
                render ( RT write, 0, 4, 12) mlen 4 rlen 0        align1 WE_normal 1Q EOT  ;
   END B0

As this pattern is actually pretty common, it turns out there s a single instruction that can replace all four of the moves. That should actually make a significant difference in the run time of this shader, and this shader runs once for every single pixel. The vertex shader has some similar optimization opportunities, but it only runs once for every 8 pixels with the SIMD format flipped around, the vertex shader can compute 8 vertices in parallel, so it ends up executing 8 times less often. It s got some redundant moves, which could be optimized by improving the copy propagation analysis code in the compiler. Of course, improving the compiler to make these cases run faster will probably make a lot of other applications run faster too, so it s probably worth doing at some point. Again, the amount of code necessary to add this path was tiny:

 Makefile.am             1 
 glamor.c                2 
 glamor_polyops.c      116 ++++++++++++++++++++++++++++++++++++++++++++++++++--
 glamor_priv.h           8 +++
 glamor_transform.c    118 +++++++++++++++++++++++++++++++++++++++++++++++++++++
 glamor_transform.h     51 ++++++++++++++++++++++
 6 files changed, 292 insertions(+), 4 deletions(-)

Discussion of Results These two cases, text and points, are probably the hardest operations to accelerate with a GPU and yet a small amount of OpenGL code was able to meet or beat software easily. The advantage of this work over traditional GPU 2D acceleration implementations should be pretty clear this same code should work well on any GPU which offers a reasonable OpenGL implementation. That means everyone shares the benefits of this code, and everyone can contribute to making 2D operations faster. All of these measurements were actually done using Xephyr, which offers a testing environment unlike any I ve ever had build and test hardware acceleration code within a nested X server, debugging it in a windowed environment on a single machine. Here s how I m running it:

$ ./Xephyr  -glamor :1 -schedMax 2000 -screen 1024x768 -retro

The one bit of magic here is the -schedMax 2000 flag, which causes Xephyr to update the screen less often when applications are very busy and serves to reduce the overhead of screen updates while running x11perf. Future Work Having managed to accelerate 17 of the 392 operations in x11perf, it s pretty clear that I could spend a bunch of time just stepping through each of the remaining ones and working on them. Before doing that, we want to try and work out some general principles about how to handle core X fill styles. Moving all of the stipple and tile computation to the GPU will help reduce the amount of code necessary to fill rectangles and spans, along with improving performance, assuming the above exercise generalizes to other primitives. Getting and Testing the Code Most of the changes here are from Eric s glamor-server branch:

git://people.freedesktop.org/~anholt/xserver glamor-server

The two patches shown above, along with a pair of simple clean up patches that I ve written this week are available here:

git://people.freedesktop.org/~keithp/xserver glamor-server

Of course, as this now uses libepoxy, you ll need to fetch, build and install that before trying to compile this X server. Because you can try all of this out in Xephyr, it s easy to download and build this X server and then run it right on top of your current driver stack inside of X. I d really like to hear from people with Radeon or nVidia hardware to know whether the code works, and how it compares with fb on the same machine, which you get when you elide the -glamor argument from the example Xephyr command line above.

Andrew Solomon gave an interesting TED talk about depression [1]. I ve had problems with depression at various times through my life, about 18 months ago I recognised it as depression after reading a list of depression symptoms on the Beyond Blue site. I think that they have changed their site recently they now have an interactive checklist for depression on their web site [2] (or maybe I just missed the interactive part last time). There is a strong correlation between Autism and depression, this is noted both in research and described on the web, Elspeth s article on Bluehackers is a good description of this [3]. Her experiences differ from mine in some ways, but it s within the common range of experiences you see described on Autism forums etc. Depression is getting more widely known, organisations such as Beyond Blue and Bluehackers are doing good work in spreading information to people who might be depressed and people who know them. The general advice is to see a psychologist, which is good advice for average people. Alexithymia and Choice of Psychologists One problem with such advice is that it doesn t apply so well to people with alexithymia (read the Wikipedia page) [4], that means most people on the Autism Spectrum. The Wikipedia page says psychosomatic illness or substance abuse is frequently exacerbated should these individuals enter psychotherapy . Based on people I know and accounts I ve read on the Internet I expect that anyone on the Autism Spectrum who sees a psychologist that doesn t specialise in Autism (which means most psychologists) will get a result that s about the opposite of what one might desire. In theory a psychologist could recognise someone as being possibly on the Autism Spectrum and refer them to an expert for assessment, but I haven t heard of that happening to an adult. I think that most people who have some degree of alexithymia will avoid psychologists, without ever seeing one you can just know that it s going to be unpleasant. So while you wouldn t want someone who has alexithymia to visit a random psychologist in practice that shouldn t happen too often as such people will be more likely to reject any advice about seeing a psychologist. My page of Autism self-diagnosis tests has a link to an Alexithymia test [5]. If you get a high score on that test (or if taking the test seems too unpleasant) then it s best to see a psychologist who specialises in Autism. Such psychologists are usually happy to work for people who don t quite meet the Autism diagnostic criteria, but they may strongly recommend an Autism assessment so that they can determine the best strategies for treatment. In terms of addressing such problems it seems that the best thing we can do is try and reduce the stigma associated with Autism. The vast majority of people on the Autism Spectrum have little in common with Rain Man. Many of the so-called Autism advocacy organisations make things worse by implying that everyone who is Autistic is unable to live an independent life which helps them in fundraising but doesn t help us.

• [1] http://www.ted.com/talks/andrew_solomon_depression_the_secret_we_share.html
• [2] http://tinyurl.com/oedkao7
• [3] http://bluehackers.org/2010/10/31/growing-alient-robot-among-humans
• [4] http://en.wikipedia.org/wiki/Alexithymia
• [5] http://doc.coker.com.au/aspie/asd-self-diagnosis-tests/

While in the process of polishing up a paper, I had to draw figures using a well-known proprietary program for drawing chemical formula whose name I will not write down, out of decency (but you know which one it is anyway). I'm using the mac version (yes, no version for Linux) which has a neat glitch in that the "Save As" button does not work at all: no way to export your chemical formula as a SVG/PDF/PNG picture or whatever ! So I resorted to the neat Print as PDF feature of macintosh. I had to edit the resulting PDF files by hand as some of the colors were wrong (great !), and when I tried to include the PDF, I realized they had a white background... No way !So I dug in ImageMagick's convert documentation, and came up with the following code that converts the PDF file into a PNG with a transparent background:

convert -density 600 figure.pdf -channel alpha \
  -fx '((r == 1 && g == 1 && b == 1) ? 0 : 1)' figure.png

There are still some few points that look white but are probably not that white (due to antialiased rendering of the PDF file ?). There are many more things that can be done using the -fx operator, this page was helpful to me !Edit: while the alpha channel seems to be on by default for PDF files, it is not necessarily the case for all images. If the above doesn't work, try adding -alpha Set before the -fx bit.

This week I received a logitech squeezebox radio, which is basically an expensive toy that allows you to listen to either "internet radio", or music streamed from your own PC via a portable device that accesses the network wirelessly. The main goal of this purchase was to allow us to listen to media stored on a local computer in the bedroom, or living-room. The hardware scans your network looking for a media server, so the first step is to install that:

• The slimdevices wiki has decent information.
  • Or you can find the code on github.com.

The media-server has a couple of open ports; one for streaming the media, and one for a user-browsable HTML interface. Interestingly the radio-device shows up in the web-interface, so you can mess around with the currently loaded playlist from your office, while your wife is casually listening to music in the bedroom. (I'm not sure if that's a feature or not yet ;) Although I didn't find any alternative server-implementations I did find a software-client which you can use to play music from the central server - slimp3slave - and again you can push playlists, media, etc, to this. My impressions are pretty positive; the device was too expensive, certainly I wouldn't buy two, but it is functional. The user-interface is decent, and the software being available and open is a big win. Downsides? No remote-control for the player, because paying an additional 70 is never going to happen, but otherwise I can't think of anything. (Shame the squeezebox product line seems to have been cancelled (?)) Procmail Alternatives?

Although I did start hacking a C & Lua alternative, it looks like there are enough implementations out there that I don't feel so strongly any more. I'm working in a different way to most people, rather than sort mails at delivery time I'm going to write a trivial daemon that will just watch ~/Maildir/.Incoming, and move mails out of there. That means that no errors will cause mail to be lost at SMTP/delivery time. I'm going to base my work on Email::Filter since it offers 90% of the primitives I want. The only missing thing is the ability to filter mails via external commands which has now been reported as a bug/omission.

Today was my "clean the house" day. I made a start, then went for my chiropractic assessment and adjustment. I now only need to see him fortnightly, which is nice. I knocked out most of the cleaning, and then went for a massage and had some lunch. The next thing I knew it was about time to pick up Zoe. I biked to Kindergarten, and she was asleep again. She woke up reasonably easily, but was grumpy not long after that. She was very uncooperative, and didn't want to go home on the bike, and wouldn't let me put sunscreen on her. After a bit of work, I managed to extract from her that she didn't like my "sweaty hands" from riding the bike there, so I washed my hands and then she let me sunscreen her up. I'll try doing pick ups in the car next week I think. We got home, and I needed to get some more kitty litter, so we went out to Pet Barn. Zoe had a great time checking out all the fish, and also playing with aquarium decor. It got me thinking that maybe an aquarium might be a good birthday present for her, if not this year, maybe next year. It turns out that fish aren't particularly expensive, so they'd make for easy presents for people. After that, we popped across to Bunnings, because I needed a couple of things. While we were there, Zoe announced she wanted to go to the toilet, so we started trekking off to where I thought the toilets were. Turned out I was wrong, and they were at the opposite end of the building, so we had to trek all the way back again. Zoe got all the way into the ladies bathroom and failed to make it onto the toilet in time, so that concluded our visit to Bunnings. We got home and she got changed, and I started making dinner. While dinner was cooking, Zoe watched a bit of TV, and then I decided to try making some lunch box pies, essentially a piece of buttered bread jammed into a muffin tray with some creamed corn and bacon in the bottom and beaten egg on top, thrown in the oven. Zoe helped sample the bacon and cracked the eggs for me, while I buttered bread and cut the crusts off and jammed slices into muffin trays. Bedtime was remarkably uneventful for a change.

I used to use Fetchmail and Gnus with its mail splitting capabilites and nnml backend to handle my private mail setup for many years. This worked pretty fine since I am used to accessing my home server through SSH. I have Gnus running inside of a GNU screen session. So I can check mail from remote by using a SSH terminal. This works fine as long as I have a good SSH terminal on a desktop or laptop computer. However, it does not work very well on tablets or smaller mobile devices. Additionally, mail splitting has become a performance burden over the years. I do not want to wait for Gnus to sort incoming mail into different folders while checking for new mail. That is something which should have been done in the background already, and thats what we are going to cover with the setup described below. So I had to change my simple setup to accomodate for the new trends in mobile computing. The obvious core of such a setup is an IMAP server which receives and stores your mail such that different clients can access it. So the time of my Gnus nnml storage are definitely over. Mail is no longer stored in and by my mail client.

I have just pushed our pseudo-monthly batch of keyring updates to Debian. I am happy to inform you that, while the situation described in Clint Adams' interesting assessment of the state of the Debian keyring (and the quite constructive conversation that followed) still holds, and we still have way too many weak (1024D) keys in the Debian keyring, we got a noticeable effect as a result of said thread: 20 key upgrade requests in somewhat over a one week period! (mostly from DDs, with two from DMs IIRC). So, for any DD or DM reading this and not following the debian-project list where this thread took place: As keyring maintainers, we no longer consider 1024D keys to be trustable. We are not yet mass-removing them, because we don't want to hamper the project's work, but we definitively will start being more aggressively deprecating their use. 1024D keys should be seen as brute-force vulnerable nowadays. Please do migrate away from them into stronger keys (4096R recommended) as soon as possible. If you have a key with not-so-many active DD signatures (with not-so-many 2) waiting to get it more signed, stop waiting and request the key replacement. If you do not yet have a 4096R key, create a new one as soon as possible and get some signatures on it. Once 2 DDs have signed it, please request us to replace your old key. If you cannot get to meet two DDs in person, please talk to us and we will find out what to do.

I get all excited when I load up Github's front-page and see something like:

"robyn has forked skx/xxx to robyn/xxx"

I wonder what they will do, what changes do they have in mind? Days pass, and no commits happen. Anti-social coding: Cloning the code, I guess in case I delete my repository, but not intending to make any changes.

This weekend I received my 17th certification (or Statement of Accomplishment) for MOOCs. In particular, this last MOOC that I took was Creative, Serious and Playful Science of Android Apps, offered by Lawrence Angrave of University of Illinois at Urbana-Champaign. While I certainly knew that the course was an Introduction to Programming, the reasons I took it were twofold:

1. For the "novelty" (for me, at least) of writing some Android Apps
2. To reacquaint myself with Java, which I have not touched since 1999, when I wrote a compiler, in the ages of JDK 1.0 being transitioned to JDK 1.1.

I think that the time the course took (and which I invested in) was really well spent. In fact, I learned some nice things which I would not have touched otherwise. For instance, I made the conscious effort to use an IDE (Eclipse), despite being a person that would do most of the things inside Emacs and compile the programs with command-line tools. Despite being huge, Eclipse has some really nice features and the auto-completion is amazing. Since Java is so strongly typed and Eclipse knows Java pretty well, it almost completely writes your programs for you. Of course, my interest also made me want to streamline the build process and use the command line tools (with ant, another tool that was "alien" to me, having used makefiles for everything that I needed). The use of Eclipse (and the Android development environment in general) in my Debian unstable computers was not without problems, but after spending more time trying to fix Eclipse than really doing the homework (and pulling the little hair that I still have left), one really helpful post nailed it. (Yes, I had to remove other packages like gimp, but such is life). While playing with the Android side of things, I put one badly written (and not really "android-ish") app in a github repository (which I think is aptly named "Toy Android Apps"), which served me the purpose of learning some Android-specific concepts. But the course was helpful not only to get in touch with the tools (Eclipse, ant, running Android virtual machines with the help of kvm), but also on the Java side. I lost a bit of the prejudice against it (even though I still think it is a verbose language, especially when compared to, say Python), and I, also intend to contribute to one apache project or another that have low-hanging fruits. Actually, I have signed their Contributor License Agreement and I even had my first patch accepted! Aside: Well, sadly SVN doesn't support different committer and author fields like git does and it seems that doing many small commits may not be the Apache way of doing things but the important part of all this is that the code is there and there is so much more to be done. Aside #2: After a lot of time spent converting the repository to git (which is, after all, what I use), I put a mirror of Apache's the commons graph project.

If you can read this, that means my transition to ikiwiki has happened. I've been interested in ikiwiki ever since Joey first wrote about it back in 2006, but it took me until just recently to finally bite the bullet and migrate to ikiwiki. The plan was to retain everything, including comments, and I've mostly achieved that. Still, a few things were lost along the way:

• There were a few blog entries that had special characters in their filename which blosxom didn't care about but ikiwiki didn't like. Since there were only a handful of them, I've ignored those for now. It does mean those are now dead links, but I decided it's not worth bothering about much.
• My previous setup had a fairly intricate way to choose a different stylescript which I'm fairly sure nobody (but me) ever used. To keep things simple, I've decided not to port that over to ikiwiki. Instead, only the most recent 'grass' stylesheet has been retained (though it required some changes to accomodate for the fact that elements have different class names and ids in ikiwiki as compared to my own stuff, obviously)
• My own comment system had threading support, which ikiwiki does not seem to have. I did consider adding it, but I've decided not to care much.

I should note that at this point I've only ported the blog itself, not the rest of my website. While ikiwiki can be used for that as well, the parts outside of my blog are fairly static and don't change all that often. In addition, those bits are set up in an even uglier way, and I didn't want to fix them up just yet. Things I've learned:

• ikiwiki does not track timestamps across git moves. Not sure whether this is a bug. It meant I couldn't rename the "special-characters entries" that I mentioned above, since the dates would be all wrong.
• You can cherry-pick an entire git branch onto another branch (without having to specify each and every commit individually), if you need/want to avoid a merge commit. Apparently ikiwiki got confused about the merge commit, and we ran in the above same issue; but with cherry-picking the commits from the git-svn branch on which they were, stuff was done correctly.

Review: Air Apparent, by Mark Monmonier

Publisher:	University of Chicago
Copyright:	1999
Printing:	2000
ISBN:	0-226-53423-5
Format:	Trade paperback
Pages:	232

Subtitled "how meteorologists learned to map, predict, and dramatize the weather," Air Apparent is a history of weather maps. Mapping the weather is a surprisingly new field, dating only from the early 19th century when a combination of scientific understanding and the ability to combine scattered observations made it practical. They're also a particularly tricky problem since weather is inherently three-dimensional, and even to the present day nearly all of our maps are two-dimensional. Monmonier starts with the earliest observational maps and the attempts to use them for prediction and tracks developments up to the late 1990s, with TV weathermen and (simple) interactive web data viewers. I got a copy of this book after Paul Krugman mentioned it. I don't know a lot about weather forecasting or weather maps, but I remembered finding the science of weather fronts and maps of them fascinating in high school, and I hoped I'd get the same feeling from this. Unfortunately, I probably need to stop reading Monmonier's books; they always sound interesting, but I don't enjoy reading them. One thing that's important to know is that this is not a history of meteorology. One can't hold that against the book, of course, because it never claimed to be. But it has just enough of a history of meteorology mixed into its history of map-making to make at least this reader wish he were reading that other book. I like maps, I really do, but I was hoping for either a book that melded a history of the science of weather forecasting with the maps that were used in that science, or a book that dove deep into the effective and ineffective ways to make weather maps (ideally, Edward R. Tufte for maps). This is neither; it's little more or less than a detailed history of the making of weather maps. Each time it gets close to a clear explanation of the underlying meteorology, it finds a map to examine and skips the rest of the explanation. I kept almost understanding the underlying science, but not enough to really understand the goals of the map makers, or why one presentation was better than another, or how those presentations were used to make forecasts or track weather data. I think I would have found this book more interesting in conjunction with a full history of meteorology, but I suspect that a history of meteorology would include enough about the maps to render this book largely redundant for the casual reader. The other problem I had with this book is that it's very dry. Monmonier is clearly trying, and clearly cares a lot about his topic, but the book has no flow. I kept getting lost in the barrage of names, arguments over technique, and struggles for government funding. It's hard to put a finger on why the book didn't grab me; the closest I can come is that it's a book stuffed full of facts. Monmonier did exhaustive historical research on weather map making, saved numerous quotes from original documents, and laid it all out chronologically. That's fine if you just want the information, but I was looking to be entertained in the process, and that didn't happen. I think the problems get worse in the second half of the book, when weather satellites and computers enter the picture and the laborious, manual map-making fall out, although maybe I was just exhausted with the book by then. The early history of weather maps at least has the benefit of showing the logistical struggles behind creating an effective weather service: insufficient observation points, slow communication methods, and the need for skilled map-makers to turn measurements into visual representations. Once computers and satellite photography enter the picture, the science matters even more, and I think the reader needs a better understanding of the underlying science to make sense of the results. Air Apparent has a tendency to provide a brief introduction to the type of data, a detailed chronological history, and then a discussion of the ways of presenting and representing that data, without ever getting the reader to care about the data itself or see how it ties into forecasting. Part of the problem, I suspect, is that the history of meteorology seems to be full of sensible, careful people who largely did sensible, careful things with the data they had available at the time. This is great for the advancement of science, and not so helpful at making a history engrossing. I wish I could say that I was glad I read this book for the information, if not the presentation, but unfortunately I didn't retain much. I needed some sort of structure or frame on which to hang all of the specifics, some sense of story or controversy or at least scientific understanding, and I didn't get it. It took me a couple of months to finish this book because I kept setting it down to read other things, and I only finished it out of a combination of stubbornness and knowledge that other people liked it. If the topic sounds interesting, well, this book exists, and it's gotten several good reviews. But I'm afraid I can't recommend it. Rating: 4 out of 10

So it may sound normal to receive compressed response for CSS/JS file from Apache2 but what I faced is completely different behavior, here I saw not just body of response but also header are getting compressed and send to browser and browser was unable to interpret the response there by leading page rendered without CSS and JS. That was long story short, so let me explain in detail the case and what I found out. I have hosted SILPA on my VPS using uWSGI. I had used till date using libapache2-mod-proxy-uwsgi plugin for which uWSGI should be using network socket and in Apache2 config I need ProxyPass directive pointing to uwsgi://host:port and everything used to work out of box. There is a drawback for using network socket in uWSGI that is limited amount of ports (65535) and possible clash with other services if we use wrong port number, additionally network sockets will be slower compared to the file socket so yesterday I thought of changing it to file socket and removed socket directive in the ini file for uWSGI application container for SILPA and here is where all problems started. My updated configuration can be seen in our documentation page that is if you are interested to look my configuration file :-).

Thanks to bernat on #debian @ irc.debian.org for helping me track down this bug and devise a workaround. When working on my wife s netbook, I noticed that when idling on Facebook in iceweasel 24.3.0esr-1, the process was taking far too much CPU. I then retested on a wheezy system with the release iceweasel from mozilla.d.n, which at that time was 26, and I later upgraded to 27. Same problem there, too, on both versions. In fact, it seems the slowdown was amplified by the fact that I was running iceweasel in vnc4server, not the worlds most efficient X implementation. Even with all these versions tested, I have yet to file a Debian bug, as I will need some time on a system where the slowdown is noticeable and I m using a current Debian version. But I wanted to post now to give props to bernat for his help. If you think you have this issue, go read his article linked above, which contains the workaround.

The Economist has an interesting and informative article about the lack of reproducability of scientific papers and the implications for scientific research [1]. Regina Dugan gave an interesting TED talk about some of the amazing DARPA projects [2]. Chris Anderson interviewed Elon Musk about the Tesla cars, SpaceX, and his new venture Solar City [3]. Elon has a lot of great ideas for improving humanity while also making money. Smart Planet has an interesting article about Bhutan s switch to electric vehicles [4]. Paul Piff gave an insightful and well researched TED talk about the ways that money makes people mean [5]. Maryn McKenna wrote an interesting article for Wired about what happens when the current anti-biotics stop working [6]. Unfortunately she lists increasing food prices as a consequence, really the unreasonably low price of meat is due to the misuse of anti-biotics that is causing this problem. Linda Walther Tirado wrote an interesting article about being poor titled Why I Make Terrible Decisions, or, Poverty Thoughts [7]. It gives a real insight into the situation of people who are trapped in poverty. When someone who is as obviously intelligent as Linda feels that it s impossible to escape poverty there is a real problem in the system. While Australia doesn t suck nearly as badly as the US in this regard (higher minimum wage and better health care) we still need to improve things, I know people in Australia who s experience bears some similarity to Linda s. Maxwell Neely-Cohen wrote an interesting article about peer pressure [8]. Some of the conclusions are dubious, but the ideas on the way the Internet changes peer relationships in high school are interesting. An English pediatrician wrote an article for The Daily Beast about why he won t accept anti-vac clients [9]. There are some decent people in the Liberal Party, Liberal MP Warren Entsch attacks Cory Bernardi on gay obsession [10]. AFAIK we haven t yet had a gay sex scandal involving a homophobic Australian politician

• [1] http://tinyurl.com/ovwctme
• [2] http://tinyurl.com/cz93dpq
• [3] http://www.ted.com/talks/elon_musk_the_mind_behind_tesla_spacex_solarcity.html
• [4] http://tinyurl.com/jwcyomu
• [5] http://www.ted.com/talks/paul_piff_does_money_make_you_mean.html
• [6] http://www.wired.com/wiredscience/2013/11/end-abx/
• [7] http://tinyurl.com/nucpwg2
• [8] http://thenewinquiry.com/essays/everybodys-doing-it/
• [9] http://tinyurl.com/qxptgvd
• [10] http://tinyurl.com/k69mqo9

Wow, today was pretty crazy in terms of the travel we managed to pack into one day. This morning, Zoe woke up at about 5:30am and jumped into bed with me for a snuggle and another half hour nap. After that we got up. Zoe had been eyeing off the egg cups in the house, and so I'd wanted to do soft-boiled eggs for breakfast. So we doused ourselves in mosquito repellent and raided the chicken coop. I don't think I've ever cooked soft-boiled eggs in my entire adult life, and today wasn't an exception. They came out hard-boiled. Zoe still ate them anyway, she just couldn't do the toast soldier thing. I need to buy some egg cups for home and we can try again. I hear the Thermomix can do boiled eggs. After breakfast and a shower, I got stuck into packing up and cleaning the house, and Zoe watched TV. At 8am she turned off the TV and declared she wanted to play in the yard. It was nice to see that she wanted to do something more than just veg out in front of the TV, without prompting. I had us all packed up by about 8:30am and we were only 5 minutes from where the barge docked, so we drove over to the other end of the island to take a look at the place at high tide. It was quite different from the two days before in the afternoon at low tide. The stick that we'd walked out to was barely above the waterline. Then we drove back to wait in the queue for the barge. The barge journey back was uneventful and we made it back home by 10am, which was about the time I was expecting, and rendezvoused with my girlfriend, and did a fast unpack and repack. We then headed to the airport, arriving comfortably with enough time to check our luggage and get some lunch to take onto the plane. Zoe was great for the flight down. She watched Brave on the in-flight WiFi entertainment on my phone, and got to fit the whole movie in before we landed, but this meant she skipped a nap. By the time we got to Melbourne Airport, she was in the post-tired manic state, but we weren't in any particular rush, so we had a very roundabout trip to baggage claim, and then after we'd acquired some Myki cards, caught a taxi to our accommodation in South Melbourne. After we'd unpacked and settled in, and I'd gotten some supplies from the local convenience store, we caught a tram into Bourke Street to go to Chinatown for dinner, after checking out the view from the observation deck on the 28th floor. We found a great dumpling place, and Zoe really enjoyed the pork dumpling and noodle soup that I ordered for her. She kept alternating between eating the noodles with her training chopsticks and the broth with one of the big spoons. She was getting really over-tired and over-stimulated by this point, so it was quite a bit of cat-herding to get to Chinatown, and more so getting back to a tram to come back. We got home, Zoe had a quick shower and went to bed without a peep. Her room is nice and dark, so I'm hoping that she'll have a bit of a sleep in tomorrow. (Wishful thinking). I'm really quite pleased with how smoothly today's travel went. Everything went off without a hitch.

Debian: watch your stats! Over the past few weeks, myself and Matthieu Caneill have worked quite a bit on Debsources. As we have now deployed most of the new features on http://sources.debian.net, it's time for another "What's new with Debsources?" blog post. Here is what's new:

• Debsources now knows about Debian suites, i.e. which package is in which "release" (stable, testing, unstable, ...). This knowledge is already useful for some of the other features below and will be used more in the future.
• since last summer Debsources has been running sloccount on all unpacked source packages, together with ctags and du, but the resulting information wasn't exposed on the Web. This is now fixed. Each package now has an infobox (example) which shows: disk usage, archive area, suites, and sloccount with per-language breakdown. The new infobox also subsumes the old puny list of package links. You can easily embed the infobox in other webapps if you need to (example). Check the URL scheme doc for more info.
• Debsources now gathers and plot accurate Debian sources statistics, both overall and per-suite, in both snapshot and historical trends flavors. (Yeah, I know, the charts are not particularly good looking ATM, but that's easy to change without impacting the rest. So if you're a matplotlib artist and willing to help, please step forward!)
• many changes have been going on also at the plumbing layer to make the service less resource hungry and more maintainable, in view of a migration to the official Debian infrastructure --- which I've in the meantime started discussing with DSA. Some highlights:
  • Debsources now has a rather comprehensive test suite, built using Nose. Most notably, we do test full update runs down to source unpacking (of a small subset of a Debian mirror), DB injection, and plugin execution --- which is quite neat.
  • the updater is now much faster (about 2x) and might require, in pathological cases, 10x less memory than before. Memory usage now caps at around 300MB, even when injecting ctags for large packages such as linux, chromium, and libreoffice.
  • the DB schema went through several refactoring cycles, and now uses a separate file table to index all known source file paths. In the past path information were duplicated across the checksums and ctags tables, not only wasting DB space, but also making the presence of file information conditional on the enablement of at least one of the two corresponding plugins. This is now fixed --- and migrating the full DB has been quite "fun". Unfortunately, we've also added quite a few large-ish indexes, resulting in no significant overall changes in DB size (currently at ~50GB), but at least in much faster queries The next step on this front will be the addition of path-based searches, using the excellent Postgres trigram indexes.

Want more? Sure, we'll be happy to! But it'll happen faster if you help. Speaking of which: we've got Debsources into the new contributors game (see announcement) and we're looking forward to mentor new contributors.

Following my blog post on the topic, I played a bit with various options. But let s explain my use case (which might be quite specific). I need to deal with three main sources of events:

• the Zimbra instance from my lab. It provides a CalDav interface.
• the ICS export from my University s teaching timetable.
• a calendar for personal stuff. I don t want to use my lab s Zimbra for that.

Additionally, I follow some ICS feeds for some colleagues and other events.
I tend to access my calendar mostly on my computer, and sometimes on my N900 phone. None of the web interfaces I looked at enabled me to (1) manage different calendars hosted on different CalDav servers; (2) subscribe to ICS feeds; (3) provide a CalDav interface to synchronize my phone. I ended up using a radicale instance for my personal calendar, which was extremely easy to set up. It s unfortunately a bit slow when there are many events (1600 since 2010 in my case), so I ended up importing only future events, and I will probably have to cleanup from time to time. I switched to using IceDove with the Lightning add-on to manage all my calendars and ICS feeds. It s unfortunately slower and less user-friendly than Google Calendar, but I ll live with it. On my N900, I used syncevolution to synchronize my various CalDav calendars. It works fine, but understanding how to configure it is rather tricky due to the number of concepts involved (templates, databases, servers, contexts, ). The synchronization is quite slow (several minutes for the 400-events Zimbra calendar), but works. I also wanted a way to export my calendars to colleagues (both in a free/busy version, and in a full information version). I quickly hacked something using ruby-agcaldav (which is not packaged in Debian, and required quite a few dependencies, but it was easy to generate packages for all of them using gem2deb the situation with other languages did not look better).
The resulting script is:
require 'agcaldav'
require 'date' cal = AgCalDAV::Client.new(:uri => 'LABCALDAVSERVER', :user => 'xx', :password => "xx")
ev = cal.find_events(:start => '2014-02-01', :end => '2200-01-01') cal = AgCalDAV::Client.new(:uri => 'RADICALESERVER', :user => 'xx', :password => "xx")
ev2 = cal.find_events(:start => '2014-02-01', :end => '2200-01-01') limit = (Time::now - 7*86400).to_datetime # create new empty calendars
ncpriv = Icalendar::Calendar.new
ncpub = Icalendar::Calendar.new (ev + ev2).each do e
next if e.end < limit # drop old events to keep the calendar small # build event for the free/busy calendar
pe = Icalendar::Event.new
pe.start = e.start
pe.end = e.end
pe.klass = "PRIVATE"
pe.transp = e.transp
ncpriv.add(pe) # build event for the calendar with event information
pube = Icalendar::Event.new
pube.start = e.start
pube.end = e.end
pube.transp = e.transp
if not e.klass == "PRIVATE"
pube.summary = e.summary
pube.location = e.location
end
ncpub.add(pube)
end # export free/busy calendar
fd = File::new('xx.ics', 'w')
fd.puts ncpriv.to_ical
fd.close # export calendar with event information
fd = File::new('yy-Zeeh9bie.ics', 'w')
fd.puts ncpub.to_ical
fd.close
So, mostly everything works. The only thing that doesn't is that I haven't found a way to subscribe to an ICS feed on my N900. Any ideas?