I ve now had a Sony Ericsson Xperia X10 for almost two months (here is a link for my first review) [1]. This is a phone that people seem to really dislike because the battery life is poor and Sony doesn t allow replacing the kernel. I m happy with mine, happy enough that after buying one for my wife and trying it out I bought one for myself. I knew about it s problems in advance and wanted a relatively cheap phone with a large high resolution screen, and the Xperia X10 was the best match for my criteria.ChargingThere has been a recent trend towards using USB for charging devices. Sony provides a tiny wall-wart PSU which has a USB socket and a short (1m) USB cable that can be used to charge the phone from it s PSU or from a PC. The size is really convenient, as the phone has a short battery life I ll probably want to take the PSU to more places than I would for other phones I ve owned.The short USB cable saves weight and tangle when travelling, but can be inconvenient. I m currently working on the phone while it s plugged into my laptop, that works well and I can make calls while it s connected. If the phone was connected to a USB port on a tower computer that was on the ground then the cable could be too short to make a call, if it was charging on a power point near the floor then I wouldn t even be able to use the computer functionality let alone make calls without kneeling. My Viewty has a 175cm charging cable which alleviates these problems. I ve got a 50cm USB extension cable that I use for charging my phone while I m in bed that is just long enough to allow me to check my email without getting out of bed!The socket for connecting the USB cable is protected by a plastic lid that is connected by a strip of rubber. For a socket that will be used at least twice a day this isn t a good mechanical design. The plastic slide on the LG U990 Viewty seems like a much better design.As an aside it s a pity that they aren t designing cars with USB charging sockets built in. Some new cars have a socket for one USB flash drive to be attached to the radio, but really they need at least one USB charging port per seat. It would also be nice if they made power points with USB charging sockets built in, I d buy a few of those if they made them.Preserving the BatteryI ve been running Juice Defender to reduce the battery use, at the moment it is claiming to have extended battery life by 69%. That combined with turning off things that aren t needed (such as WiFi) has made the phone reasonably usable. I can survive more than 12 hours during which I use the phone a lot without charging it.XperiaX10.net has an interesting review of replacement batteries [5]. I m not going to buy them because the largest battery requires a replacement back case which prevents using an external case to prevent damage and the smaller one doesn t provide enough of a benefit and the design of the phone makes it difficult to change batteries so carrying a spare battery isn t a good option.Cursor Control KeysThe HP/Compaq iPaQs that I own from ~10 years ago have a single button that can be moved up/down/left/right to act as a cursor, it can also be pressed inwards to act as an ENTER key (or whatever the application might want for a fifth function). Having some sort of hardware cursor control is really handy, I often end up deleting several characters when I want to replace one because getting the cursor onto the desired character is too difficult.Adding more hardware keys would require making the phone bigger, but that would be fine by me. As described in my previous post about phone cameras I d like to have a phone that s thicker to have a better camera with a greater focal distance for a larger lens [2].Core Phone FunctionalityI really miss having separate green and red buttons for making/answering calls and for rejecting/ending calls.A really common operation is to call back the last person who called. To do this on my LG U990 Viewty I press the green button twice on my home screen which took less than a second. On the Xperia this involves selecting the phone icon from the home screen, then the call log icon, then the call that is desired, then the Call user line. That is four presses in different parts of the screen compared to pressing the same hardware button twice. I m investigating dialer applets right now, the Dialler One applet has a good interface for calling people who have called or been called recently but it still requires two presses on different parts of the screen. With my old Viewty I could call back the last person by feel without even looking at the phone!In the last 6 years the standard functionality of phones has been to include multiple profiles for noises. My Viewty has profiles named Normal , Silent , Vibrate only , Outdoor , Headset (automatically selected when a headset is connected), and three customised ones. The Xperia has only one setting, and that is three icon presses away from the home screen. It does allow changing the volume by hardware switches on the side which includes going to vibrate-only and silent mode. While this is useful, it s not the best way that two precious hardware keys could be used. It also doesn t allow control over all the different notifications, I d like to be able to activate a noise profile and have every application respond to it in an appropriate manner. This is a deficiency in Android 2.1 not in the phone itself.In many ways this phone has the worst phone functionality of any mobile phone I ve ever owned, I think that this is more the fault of the Android designers than Sony Ericsson.Android UpdatesSony had previously claimed that they wouldn t support Android later than 2.1. Now Sony has announced that they will support Gingerbread Android 2.3 [3]. So one of the major complaints about the Xperia will soon be addressed.TetheringThe build of Android that the Xperia runs at the moment doesn t support Wifi tethering. I m currently using with Easy Tether for USB tethering [4]. It s not free software and requires it s own code to run as root on your Linux system that is being tethered (which is easily locked down with SE Linux), but it basically works. The down-side with Easy Tether is that it proxies all the connections so you can t run traceroute etc and in the free version you can t use UDP.K9 MailK9 Mail fixes some of the problems in the default Android email program that I described in my previous post. It allows selection of SSL with a default port of 993 for IMAPs. It uses mail.example.com as the mail server address for an email address of user@example.com (so I ll add a mail CNAME to the domains I run). When I connected initially it told me that the SSL key was not signed by a CA and asked if I wanted to save it or reject it this is the correct and desired functionality. It also correctly parses URLs from the email (or at least has fixed the bug that I discovered in the default email app).One problem I ve found with K9 is that it seems to timeout on large folders. This is probably partly the fault of Virgin Mobile being slow for IP access, but I wonder whether K9 doesn t pipeline IMAP commands as Virgin can do bulk transfer at reasonable speeds (80KB/s) and it mainly fails on latency (900ms being typical). The result is that a folder with more than 500 messages that need to be copied to the phone will never get synchronised. When I started reading mail on my phone I had to move mail from some of the bigger folders into other folders to avoid timeouts. As an aside the amount of time I ve saved by reading email on the go has already paid for the phone.MediascapeThe Sony Mediascape software is used for categorising photos. One function of this is to assign names to photos, the names come from the contact list so if you photograph someone who you can t phone then you need to add a contact list entry for them. This also means that you couldn t conveniently add names to non-humans, I guess I could have added a contact list entry Mr Crash Dump for photos of system crash logs. But a bigger problem is that it decides what is a picture of a person, a picture of someone who is not centered in the photo or a profile picture can be regarded as not a photo of a person and therefore not subject to being associated with a contact list. Finally when selecting a name for a picture it displays the entire contacts list in a small font instead of displaying favorites, I have the phone numbers of many clients in my contacts list who I will never photograph Mediascape just isn t much good. If I feel the need to do something serious in this regard I ll search the app store for something free that s better.ProtectionFor $15 each I bought one grey and one clear Gel Case from J2K. This case covers the sides and back of the phone with a firm rubber layer that will hopefully allow it to bounce rather than break. It also extends slightly higher than the screen which should stop the screen being scratched if the phone is left face-down on a hard surface on the vibrate setting.One problem with the Gel Case is that by it s design it has to cover the buttons on the sides, due to a design or manufacturing problem the clear case that my wife uses can press slightly on the shutter button which disables the three main buttons on the front. So when the menu or back button stops working she has to slightly move the Gel Case out from the side. I m thinking of just cutting out a section of the Gel Case there, that will make it difficult to press the shutter button, but you can use the touch screen to take photos and there doesn t seem to be any other use for the shutter button so this shouldn t be a problem. The clear and grey cases have different designs, the grey one has a hole over the raised Sony logo which makes it fit a little better as well as not having the shutter problem, so it seems to be a later design I don t know whether all clear cases have the same problem but I recommend that someone who only has one Xperia X10 get the grey case just in case.Web BrowsingI m experimenting with using my own web proxy to compress the data sent to the phone. Unfortunately the Android settings for a web proxy only apply to the main web browser, not to all the other applications that use web services. Also the built-in web browser requires pressing the settings hardware button followed by at least two touch-screen presses to change between windows or close a window and it doesn t seem to support making the short-press action be to open a link in a new window. So I will have to find another web browser to use.Bandwidth UseThe 3G Watchdog applet is really good for tracking the data transfer and optionally cutting off 3G access before the quota is exceeded. Unfortunately Virgin has already sent me a bill with $234 in extra charges for bandwidth use because I used 1.6G instead of my 1.5G quota. A Virgin representative had told me over the phone that the billing period would be based on the end of the month, so while every calendar month has had less than 1.5G used because I used more than average in the end of March and the start of April that counts as excess data in the 14th March to 13th April period.I m going to appeal this to the Telecommunications Industry Ombudsman, I don t think that it s reasonable that I should be billed almost 7* the normal bill for exceeding the quota by 7.4% based on following the instructions of a Virgin employee. While I could have read the previous bill that they sent me to discover the end of billing period dates, I don t think that I should be expected to distrust everything that a Virgin employee says. If they billed me an extra $20 then I d just pay it, but $234 is unreasonable.ConclusionSince using the phone I ve found significant benefits in web browsing and reading email with the major limitation being the small screen (relative to a Netbook or Laptop). So if I was to buy another phone I would probably consider a Dell Streak which seems to be the largest Android phone on the market at the moment.Given the amount of use that I ve got I would be happy to spend more money and therefore consider a more expensive phone. But I don t regret the decision to save money by getting an Xperia X10.Finally when a telco tries to stick me with a $234 excess charge it really detracts from the value of having a phone contract. If I end up having to pay that then it s half the value of a smart-phone lost in one telco scam. This is enough to make a contract with Virgin a bad option, after this contract expires I may use VOIP and a pre-paid SIM from Telstra NextG if their network is still the best. Another possibility is to just use a small tablet and skip having a mobile phone, email and Jabber plus SMS from the people who lack net access will probably do.

• [1] http://etbe.coker.com.au/2011/02/18/xperia-x10i-first-experience/
• [2] http://etbe.coker.com.au/2010/11/26/quality-of-cameras-in-phones/
• [3] http://blogs.sonyericsson.com/products/2011/03/25/update-on-xperia%E2%84%A2-x10/
• [4] http://www.mobile-stream.com/easytether/android.html
• [5] http://www.xperiax10.net/2010/08/02/mugen-power-xperia-x10-battery-review-%E2%80%93-part-1/

I've read bits and pieces of the recent "Network Manager as default" thread on debian-devel. I have a strong personal preference towards one side, but that's not the point of this post (and I hope I can keep the tone neutral, hence why I didn't get into the mailing list discussion). I think this discussion is just a proxy flame-war to a bigger issue that lurks behind the scenes. That is, what is the most efficient way to configure systems. On one side, we have the sysadmins, with their toolbox, and who desire the most reliable way to configure systems. In the other corner, we have people whose problem is how to configure systems with the least amount of human involvement. Whether it's ifupdown versus NetworkManger, or explicit groups versus things like PolicyKit, it's basically the same thing: do we want to have an OS that is slimmer, more customisable and more stable, but needs hand-holding, or do we accept some degradation in flexibility/customisation in exchange for decreasing the cost of administration? I have personal preferences to one side, and practical preferences to another side. I'm not sure which is best in 2011, and it depends on many factors, but looking forward in 20 years: I don't think we will afford to hand-hold a Linux machine as mach as we were doing it 10 years or even 5 years ago. Presuming that software capabilities advance, it should be possible to hand-over responsibility of autoconfiguration to software, rather than hand-configuring config files (doing it via configuration management systems is beside the point, as it is a mixed setting; I'm discussing only the extremes). So in any case, we'll have to accept that at one point we will have to rely on automated stuff for some parts of the system. The question is when we as sysadmins will be ready to do that, and when the software will be mature enough to bear that kind of responsibility. And then there's my next gripe: what is good for a few systems (dpkg/apt-get) might not be good for many. I find lately that relying on dpkg plus a configuration management tool to keep many machines in sync is not the best way. Keeping with the time means changes, whether we want it or not. PS: for the record, not even my laptop(s) run NetworkManager

Recently, I've had the pleasure of having to write many short documents in LaTex (short as in 1 to 6 pages). I haven't written a lot in LaTex since my school time, so this was a very nice flashback to those times. However, since then PDF is the new "standard" format, not PostScript, so I had to do a bit of adjustement. The biggest change is that pdflatex doesn't "like" EPS files for images, so what to do? As usual, the road to enlightenment has many turns First, reading docs, I said simple, create a PNG file, scaled at high resolution, then include it scaled down so that it kind of loses the ugly scaled-bitmap feel. But that's not a nice solution: it is still bitmap, just looks like aliased. So I wanted another solution and threw gnuplot's set terminal png and fig2dev's -L png out the door. Next was, of course, embedding PDFs, since pdflatex supports that. However, gnuplot's pdfcairo output is not as nice as I wanted. It works, but only kind of. Issues with font consistency and scaling, etc. Then I remembered the nice pslatex output from xfig, and learned that there's a pdftex output. And that gnuplot also can generate .fig output. So I went and redid my Makefiles and gnuplot command files and everything, and suddenly all looked almost right. There are still a few issues:

• if you select an invalid font in gnuplot (set terminal fig font "foo"), it will simply ignore that font, without any warning
• while you can tell it to set the "special" fig flag on the emmitted text (set terminal fig textspecial) , you can't give gnuplot a LaTex font name, since it only has definitions for the normal PostScript fonts; this can be worked around via giving it a PostScript font that has the same index as the desired LaTex font
• the font size specified in gnuplot is not really influencing the actual fonts used in LaTex
• as xfig doesn't know the actual font rendering box as computed by LaTex, you lose the (simple, but good) WYSIWYG features, and need to go back and forth between the created PDF and xfig to change the actual layout
• if you use a \resizebox around the inclusion of the pdf_t file, the fonts are scaled too, which is plain wrong

So while this setup has some drawbacks, it works well enough. I was happy to simply have a well defined workflow. But then I wanted to do a simple graph (of a 3-wire sorting network), and I realised that positioning all of that using xfig will be painful. I kept stumbling upon pgf and tikz during my previous investigations, and I said I should check it out. Wow. tikz and pgfplot. While you lose a bit on the graphing capabilities, you also gain a lot. Basically one can replace both xfig (instead of hand-drawn diagrams you can actually write them in code, programatically, no more guessing) and gnuplot (so that you have consistent fonts/scaling). I was so amazed at this excellent combination that I've converted for all my new docs to this. And now I have the problem that I keep wanting to write LaTex code in ikiwiki PS: Yes, I've been busy lately, so busy that my Debian work has mostly been suspended. Should be back in about a month or so.

Theres an ongoing thread on the Debian mailing lists about making network-manager installed by default on new Debian installations. I won't say much about the thread. Its just a prototype example for Debian project discussions: Discuss everything to death and if its dead discuss a little more. And - very important - always restate the same arguments as often as you can. Or if its not your own argument you restate, restate the arguments of others. Ending with 100 times stated the same argument. Even if its already disproved.

I don't have a strong opinion about the topic in itself. However there is something I find kinda funny. A statement brought up by the people who strongly oppose network-manager as a default.
A statetement I've heard so often that I can't count it anymore.

The last time I've tried network-manager it sucked.

It often comes in different masquerades, like:

• network-manager is crap.
• network-manager is totally unusable
• network-manager does not even manage to keep the network connection during upgrades

When did you test network-manager the last time?

A long time ago. Must have been around Etch.

A maintenance release 0.2.3 of RProtoBuf is now on CRAN. RProtoBuf provides GNU R bindings for the Google Protobuf data encoding library used and released by Google. The NEWS file entry follows below:

0.2.3   2011-04-12
   o    Protect UINT64 and INT64 with '#ifdef RCPP_HAS_LONG_LONG' which
        itself is valid with either g++ <= 4.4, or newer versions if the 
        -std=c++0x is used
    o   The documentation Makefile now uses the $R_HOME environment variable
    o   The documentation Makefile no longer calls clean in the all target

And courtesy of CRANberries, here is the diff to the previous release 0.2.2:

Diff between RProtoBuf versions 0.2.2 dated 2011-01-12 and 0.2.3 dated 2011-04-13
 RProtoBuf-0.2.2/RProtoBuf/inst/doc/RProtoBuf-quickref.Rnw                      only
 RProtoBuf-0.2.3/RProtoBuf/ChangeLog                                               23 
 RProtoBuf-0.2.3/RProtoBuf/DESCRIPTION                                              8 
 RProtoBuf-0.2.3/RProtoBuf/R/with.R                                                12 
 RProtoBuf-0.2.3/RProtoBuf/cleanup                                                  3 
 RProtoBuf-0.2.3/RProtoBuf/inst/NEWS                                               10 
 RProtoBuf-0.2.3/RProtoBuf/inst/doc/Makefile                                       42 
 RProtoBuf-0.2.3/RProtoBuf/inst/doc/RProtoBuf-quickref.pdf                      binary
 RProtoBuf-0.2.3/RProtoBuf/inst/doc/RProtoBuf-unitTests.pdf                     binary
 RProtoBuf-0.2.3/RProtoBuf/inst/doc/RProtoBuf.pdf                                1267 +++++-----
 RProtoBuf-0.2.3/RProtoBuf/inst/doc/unitTests-results/RProtoBuf-unitTests.html     20 
 RProtoBuf-0.2.3/RProtoBuf/inst/doc/unitTests-results/RProtoBuf-unitTests.txt      14 
 RProtoBuf-0.2.3/RProtoBuf/src/extractors.cpp                                      44 
 RProtoBuf-0.2.3/RProtoBuf/src/mutators.cpp                                        55 
 RProtoBuf-0.2.3/RProtoBuf/src/wrapper_FieldDescriptor.cpp                         24 
 15 files changed, 819 insertions(+), 703 deletions(-)

As always, there is more information at the RProtoBuf page which has a draft package vignette, a 'quick' overview vignette and a unit test summary vignette. Questions, comments etc should go to the rprotobuf mailing list off the RProtoBuf page at R-Forge.

As I got some e-mails about this: if you're on amd64 and Wine complains that it couldn't find a 3D acceleration card, then this is no bug in my wine-unstable packages but #614805. The short-term workaround for you is to use LIBGL_DRIVERS_PATH=/usr/lib32/dri. You can either put it in front of every Wine invocation or you can export the variable in a specific shell session (don't export it globally), in which you'll run Wine or other programs needing the 32 bit libraries. #614805 should be fixed automatically by the next ia32-libs upload, if it contains a version of Mesa containing Git commit cdd1912f.

R 2.13.0 will be released tomorrow. It contains a new package by R Core member Luke Tierney: compiler. What a simple and straightforward name, and something that Luke has been working on for several years. The NEWS file says

    o Package compiler is now provided as a standard package.  See
      ?compiler::compile for information on how to use the compiler.
      This package implements a byte code compiler for R: by default
      the compiler is not used in this release.  See the 'R
      Installation and Administration Manual' for how to compile the
      base and recommended packages.

so the compiler is not yet used for R's own base and recommended packages. While working on my slides for the upcoming Rcpp workshop preceding R/Finance 2011, I thought of a nice test example to illustrate the compiler. Last summer and fall, Radford Neal had sent a very nice, long and detailed list of possible patches for R performance improvements to the development list. Some patches were integrated and some more discussion ensued. One strand was on the difference in parsing between normal parens and curly braces. In isolation, these seem too large, but (as I recall) this is due some things 'deep down' in the parser. However, some folks really harped on this topic. And it just doesn't die as a post from last week demonstrated once more. Last year, Christian Robert had whittled it down to a set of functions, and I made a somewhat sarcastic post argueing that I'd rather use Rcpp to get 80-fold speed increase than spend my time argueing over ten percent changes in code that could be made faster so easily. So let us now examine what the compiler package can do for us. The starting point is the same as last year: five variants of computing 1/(1+x) for a scalar x inside an explicit for loop. Real code would never do it this way as vectorisation comes to the rescue. But for (Christian's) argument's sake, it is useful to highlight differences in the parser. We once again use the nice rbenchmark package to run, time and summarise alternatives:

> ## cf http://dirk.eddelbuettel.com/blog/2010/09/07#straight_curly_or_compiled
> f <- function(n, x=1) for (i in 1:n) x=1/(1+x)
> g <- function(n, x=1) for (i in 1:n) x=(1/(1+x))
> h <- function(n, x=1) for (i in 1:n) x=(1+x)^(-1)
> j <- function(n, x=1) for (i in 1:n) x= 1/ 1+x 
> k <- function(n, x=1) for (i in 1:n) x=1/ 1+x 
> ## now load some tools
> library(rbenchmark)
> ## now run the benchmark
> N <- 1e6
> benchmark(f(N,1), g(N,1), h(N,1), j(N,1), k(N,1),
+           columns=c("test", "replications",
+           "elapsed", "relative"),
+           order="relative", replications=10)
     test replications elapsed relative
5 k(N, 1)           10   9.764  1.00000
1 f(N, 1)           10   9.998  1.02397
4 j(N, 1)           10  11.019  1.12853
2 g(N, 1)           10  11.822  1.21077
3 h(N, 1)           10  14.560  1.49119

This replicates Christian's result. We find that function k() is the fastest using curlies, and that explicit exponentiation in function h() is the slowest with a relative penalty of 49%, or an absolute difference of almost five seconds between the 9.7 for the winner and 14.6 for the worst variant. On the other hand, function f(), the normal way of writing things, does pretty well. So what happens when we throw the compiler into the mix? Let's first create compiled variants using the new cmpfun() function and then try again:

> ## R 2.13.0 brings this toy
> library(compiler)
> lf <- cmpfun(f)
> lg <- cmpfun(g)
> lh <- cmpfun(h)
> lj <- cmpfun(j)
> lk <- cmpfun(k)
> # now run the benchmark
> N <- 1e6
> benchmark(f(N,1), g(N,1), h(N,1), j(N,1), k(N,1),
+           lf(N,1), lg(N,1), lh(N,1), lj(N,1), lk(N,1),
+           columns=c("test", "replications",
+           "elapsed", "relative"),
+           order="relative", replications=10)
       test replications elapsed relative
9  lj(N, 1)           10   2.971  1.00000
10 lk(N, 1)           10   2.980  1.00303
6  lf(N, 1)           10   2.998  1.00909
7  lg(N, 1)           10   3.007  1.01212
8  lh(N, 1)           10   4.024  1.35443
1   f(N, 1)           10   9.479  3.19051
5   k(N, 1)           10   9.526  3.20633
4   j(N, 1)           10  10.775  3.62673
2   g(N, 1)           10  11.299  3.80310
3   h(N, 1)           10  14.049  4.72871

Now things have gotten interesting and substantially faster, for very little cost. Usage is straightforward: take your function and compile it, and reap more than a threefold speed gain. Not bad at all. Also of note, the difference between the different expressions essentially vanishes. The explicit exponentiation is still the loser, but there may be an additional explicit function call involved. So we do see the new compiler as a potentially very useful addition. I am sure more folks will jump on this and run more tests to find clearer corner cases. To finish, we have to of course once more go back to Rcpp for some <emph>real</emph> gains, and some comparison between compiled and byte code compiled code.

> ## now with Rcpp and C++
> library(inline)
> ## and define our version in C++
> src <- 'int n = as<int>(ns);
+         double x = as<double>(xs);
+         for (int i=0; i<n; i++) x=1/(1+x);
+         return wrap(x); '
> l <- cxxfunction(signature(ns="integer",
+                            xs="numeric"),
+                  body=src, plugin="Rcpp")
> ## now run the benchmark again
> benchmark(f(N,1), g(N,1), h(N,1), j(N,1), k(N,1),
+           l(N,1),
+           lf(N,1), lg(N,1), lh(N,1), lj(N,1), lk(N,1),
+           columns=c("test", "replications",
+           "elapsed", "relative"),
+           order="relative", replications=10)
       test replications elapsed relative
6   l(N, 1)           10   0.120   1.0000
11 lk(N, 1)           10   2.961  24.6750
7  lf(N, 1)           10   3.128  26.0667
8  lg(N, 1)           10   3.140  26.1667
10 lj(N, 1)           10   3.161  26.3417
9  lh(N, 1)           10   4.212  35.1000
5   k(N, 1)           10   9.500  79.1667
1   f(N, 1)           10   9.621  80.1750
4   j(N, 1)           10  10.868  90.5667
2   g(N, 1)           10  11.409  95.0750
3   h(N, 1)           10  14.077 117.3083

Rcpp still shoots the lights out by a factor of 80 (or even almost 120 to the worst manual implementation) relative to interpreted code. Relative to the compiled byte code, the speed difference is about 25-fold. Now, these are of course entirely unrealistic code examples that are in no way, shape or form representative of real R work. Effective speed gains will be smaller for both the (pretty exciting new) compiler package and also for our C++ integration package Rcpp. Before I close, two more public service announcements. First, if you use Ubuntu see this post by Michael on r-sig-debian announcing his implementation of a suggestion of mine: we now have R alpha/beta/rc builds via his Launchpad PPA. Last Friday, I had the current R-rc snapshot of R 2.13.0 on my Ubuntu box only about six hours after I (as Debian maintainer for R) uploaded the underlying new R-rc package build to Debian unstable. This will be nice for testing of upcoming releases. Second, as I mentioned, the Rcpp workshop on April 28 preceding R/Finance 2011 on April 29 and 30 still has a few slots available, as has the conference itself.

With all the buzz around GNOME 3, I really wanted to try it out for real on my main laptop. It usually runs Debian Unstable but that s not enough in this case, GNOME 3 is not fully packaged yet and it s only in experimental for now. I asked Josselin Mouette (of the pkg-gnome team) when he expected it to be available and he could not really answer because there s lots of work left. Instead Roland Mas gently answered me Sooner if you help . First steps as a GNOME packager This is pretty common in free software and for once I followed the advice, I spent most of sunday helping out with GNOME 3 packaging. I have no prior experience with GNOME packaging but I m fairly proficient in Debian packaging in general so when I showed up on #debian-gnome (irc.debian.org) on sunday morning, Josselin quickly added me to the team on alioth.debian.org. Still being a pkg-gnome rookie, I started by reading the documentation on pkg-gnome.alioth.debian.org. This is enough to know where to find the code in the SVN repository, and how to do releases, but it doesn t contain much information about what you need to know to be a good GNOME packager. It would have been great to have some words on introspection and what it changes in terms of packaging for instance. Josselin suggested me to start with one of the modules that was not yet updated at all (most packages have a pre-release version usually 2.91 in experimental, but some are still at 2.30). Packages updated and problems encountered (You can skip this section if you re not into GNOME packaging) So I picked up totem. I quickly updated totem-pl-parser as a required build-dependency and made my first mistake by uploading it to unstable (it turns out it s not a problem for this specific package). Totem itself was more complicated even if some preliminary work was already in the subversion repository. It introduces a new library which required a new package and I spent a long time debugging why the package would not build in a minimalistic build environment. Indeed while the package was building fine in my experimental chroot, I took care to build my test packages like the auto-builders would do with sbuild (in sid environment + the required build-dependencies from experimental) and there it was failing. In fact it turns out pkg-config was failing because libquvi-dev was missing (and it was required by totem-pl-parser.pc) but this did not leave any error message in config.log. Next, I decided to take care of gnome-screensaver as it was not working for me (I could not unlock the screen once it was activated). When built in my experimental chroot, it was fine but when built in the minimalistic environment it was failing. Turns out /usr/lib/gnome-screensaver/gnome-screensaver-dialog was loading both libgtk2 and libgtk3 at the same time and was crashing. It s not linked against libgtk2 but it was linked against the unstable version of libgnomekbdui which is still using libgtk2. Bumping the build-dependency on libgnomekbd-dev fixed the problem. In the evening, I took care of mutter and gnome-shell, and did some preliminary work on gnome-menus. Help is still welcome There s still lots of work to do, you re welcome to do like me and join to help. Come on #debian-gnome on irc.debian.org, read the documentation and try to update a package (and ask questions when you don t know). Installation of GNOME 3 from Debian experimental You can also try GNOME 3 on your Debian machine, but at this point I would advise to do it only if you re ready to invest some time in understanding the remaining problems. It s difficult to cherry-pick just the required packages from experimental, I tried it and at the start I ended up with a bad user experience (important packages like gnome-themes-standard or gnome-icon-theme not installed/updated and similar issues). To help you out with this, here s a file that you can put in /etc/apt/preferences.d/gnome to allow APT to upgrade the most important GNOME 3 packages from experimental:

Package: gnome gnome-desktop-environment gnome-core alacarte brasero cheese ekiga empathy gdm3 gcalctool gconf-editor gnome-backgrounds gnome-bluetooth gnome-media gnome-netstatus-applet gnome-nettool gnome-system-monitor gnome-system-tools gnome-user-share baobab gnome-dictionary gnome-screenshot gnome-search-tool gnome-system-log gstreamer0.10-tools gucharmap gvfs-bin hamster-applet nautilus-sendto seahorse seahorse-plugins sound-juicer totem-plugins remmina vino gksu xdg-user-dirs-gtk gnome-shell gnome-panel dmz-cursor-theme eog epiphany-browser evince evolution evolution-data-server file-roller gedit gnome-about gnome-applets gnome-control-center gnome-disk-utility gnome-icon-theme gnome-keyring gnome-menus gnome-panel gnome-power-manager gnome-screensaver gnome-session gnome-settings-daemon gnome-terminal gnome-themes gnome-user-guide gvfs gvfs-backends metacity mutter nautilus policykit-1-gnome totem yelp gnome-themes-extras gnome-games libpam-gnome-keyring rhythmbox-plugins banshee rhythmbox-plugin-cdrecorder system-config-printer totem-mozilla epiphany-extensions gedit-plugins evolution-plugins evolution-exchange evolution-webcal gnome-codec-install transmission-gtk avahi-daemon tomboy network-manager-gnome gnome-games-extra-data gnome-office update-notifier shotwell liferea epiphany-browser-data empathy-common nautilus-sendto-empathy brasero-common
Pin: release experimental
Pin-Priority: 500
Package: *
Pin: release experimental
Pin-Priority: 150

The list might not be exhaustive and sometimes you will have to give supplementary hints to apt for the upgrade to succeed, but it s better than nothing. I hope you find this useful. I m enjoying my shiny new GNOME 3 desktop and it s off for a good start. My main complaint is that hamster-applet (time tracker) has not yet been integrated in the shell.

21 comments Liked this article? Click here. My blog is Flattr-enabled.

As already blogged by Riku, getting replaced by script is really great! Until now, I ve had a crontab fetching my supporting-very-big-mails (up to 100MB or so) mailbox every few minutes, and looking into my =incoming-buildd/ maildir on a very regular fashion. With some simple mutt maildir hooks, replying to a Successful log would trigger extracting the changes file from there, setting some options, like PGP inline signing, and the mail would be ready to go back to the buildd. That part was just about being a GPG-signing monkey, so really not a funny part. Since we no longer have to worry about this boring and time-consuming task, I ve switched to a crontab firing up 4 times a day, and I try to deal with all incoming mails at once. Coupled with the new filters (e.g. on out-of-date packages on the buildd status page), I started using my time to file FTBFS bugs again, so that maintainers notice their packages fail to build without having to wait for a non-happening testing migration. After 10 days, the following mutt filter in =debian-bts/ lists 69 bugs:

~s "Bug#.*FTBFS" ~P ~d 01/04/2011-

(Subject contains Bug#.*FTBFS, mails from me, starting from 01/04/2011.) Figuring out whether that s due to another package s bug, an outdated chroot, a temporary glitch, etc. might take some time; that s why it s a bit hard to stay on top of things; and when the backlog grows up, motivation to go through this tedious task can be pretty low, especially when one sees repeated mistakes. I hope the amount of (possible) use cases for #620686 will decrease over time; instead, I d be very happy if maintainers could at least check what s mentioned in configure.ac/configure.in. Keeping an eye on its diff between upstream versions should be easy enough. ;)

About a week ago, I wrote about doing cross package checks in Lintian. At that time I had only played with looking up manpages in direct dependencies, which I hope will greatly improve the current binary-without-manpage stats (around 677 packages and 2750ish tags incl. overrides). Today, I decided to take on another challenge. Detection of circular dependencies between binary packages (created from the same source). We already have a little library for building dependency relationships; however I ended up not using it, since it has an important limitation. It cannot tell how the circular dependencies relate to each other. Let me demonstrate what I mean with an example. Suppose we have a couple packages that depend on each other like this:
pkg-core => pkg-A, pkg-D
# circle 1: A, B, C
pkg-A => pkg-B
pkg-B => pkg-C
pkg-C => pkg-A # circle 2: D, E, F
pkg-D => pkg-E
pkg-E => pkg-F
pkg-F => pkg-D
In this case, our current tool will be able to tell that all packages (possibly except root I did not check) are in a circular relationship. However, we can find better results by pretending we are trying to find Strongly Connected Components (actually that is exactly what we are trying to do here). So today, I implemented Tarjan s algorithm in Perl to solve this particular issue and committed it to my Lintian branch. If this branch is merged into the Lintian master branch, we can close #316283.

This is the ninth Debian XSF News issue. As can be seen below, I m not yet decided how to present various items. This time, I ll try to gather all updated packages since the previous issue, grouped by category, with a single line summary. Lengthy comments come after that list of updated packages.

1. Here come the updated packages, with contributors/uploaders between square brackets (Timo = Timo Aaltonen, JVdG = Julien Viard de Galbert, Robert = Robert Hooker). Protocol:
   • [KiBi] x11proto-core: new upstream release, bringing Sinhala support experimental.
   Libraries:
   • [Timo,KiBi] libx11: new upstream release, fixing some hang issues unstable.
   • [KiBi] libxi: new upstream release unstable.
   • [KiBi] libxkbcommon: finally accepted by ftpmasters, needed for wayland experimental.
   Server:
   • [KiBi] xorg-server: stable release 1.9.5, unlikely to cause regressions from the previous release candidate; in other words: a good candidate for testing if the Linux kernel migrates some day unstable.
   • [KiBi] xorg-server: first release candidate for the first stable bugfix release in the 1.10 series, which finally builds experimental.
   Drivers:
   • [KiBi] xserver-xorg-input-mouse: two cherry-picks of upstream commits to fix Hurd support, thanks to Samuel Thibault unstable.
   • [KiBi] xserver-xorg-input-mouse: rebuild of the unstable version against experimental s server experimental.
   • [KiBi] xserver-xorg-video-ati: new upstream release experimental.
   • [KiBi] xserver-xorg-video-intel: new upstream release candidate experimental.
   • [JVdG] xserver-xorg-video-openchrome: new upstream snapshot, and build fix for Hurd unstable.
   Others:
   • [KiBi] xorg: originally a few tweaks to make it possible to install X on Hurd unstable
   • [KiBi] xorg: but wkhtmltopdf failed on several buildds, so I disabled PDF generation, and completed the switch to asciidoc mentioned in DXN#8 unstable.
   • [KiBi] xorg-sgml-doctools: new upstream release, adds support for docbook external references unstable.
   • [Robert,KiBi] xutils-dev: new util-macros release, and a version lookup file unstable.
2. Why am I carefully uploading video driver packages to experimental only? Because bad regressions happen, on a regular basis; so it seems quite nice to keep well-tested versions in unstable for now. Once the X stack has migrated to testing (which as explained in DXN#7 and DXN#8 is waiting for the Linux kernel to migrate), new versions in unstable are welcome, so that one can tell easily whether bugs with those versions are regressions from the versions available in testing. In the meanwhile, one can build packages from the git repositories, using the debian-unstable branch (which is the default).
3. Why am I so rash then, uploading input drivers to unstable as they are released? First of all, our waiting for the kernel means we have no issues on the 10-day delay front. Second of all, input bugs are usually fixed very quickly upstream (you can go there and thank Peter Hutterer in particular). So staying very close to whatever upstream ships makes some sense.
4. Why am I uploading drivers twice? Since it isn t specific to the current situation, but a general question when it comes to supporting two versions of the server in parallel, I decided to document that in an handling multiple server versions thanks to experimental page. The answer to this specific question is available in the note at the bottom of that page.

See you in a few days for a follow-up Debian XSF News issue.

Although I often don t agree with Erich (especially if GNOME is involved ;-), he recently posted something on Planet Debian which I found very helpful. I also own a netbook where disk space is sacre. It s an ASUS EeePC 701 with just 4GB disk space. And it runs Debian Sid, so dependencies change often, leaving packages installed which formerly had hard dependencies on, but are now left with just recommendations pointing to it. Quite a few times I asked myself if it s possible to find those packages and if so, how to do it. Well, I don t have to ask myself that anymore, since Erich recently posted the appropriate filter patterns for my favourite package manager aptitude for this task in his posting Finding packages for deinstallation . Thanks, Erich! Since those filters aren t very easy to remember, I d like to extend the usefulness of his posting towards the commandline. I for myself added the following aliases to my shell setup:

alias aptitude-just-recommended='aptitude -o "Aptitude::Pkg-Display-Limit=!?reverse-depends(~i) ~M !?essential"'
alias aptitude-also-via-dependency='aptitude -o "Aptitude::Pkg-Display-Limit=~i !~M ?reverse-depends(~i) !?essential"'

As youam suggested on IRC, I also added the filter !?essential since we won t touch essential packages when cleaning up the list of installed packages anyway. Hope this helps further.

It's incredible how many people are of the misguided belief that just because I happen to run a company, I am automatically interested in their newsletter about whatever it is that they are doing, no matter how far it is removed from the kinds of things my company actually does. Are these people spammers? Yes, definitely, and I don't want to do business with them. But there's a major difference between this kind of mails and your common nigerian scammer or counterfeit blue pill "salesperson". Unlike the latter, some newsletter spammers are interested in forming a genuine business relationship with my company. They're going about it the wrong way, but that doesn't necessarily mean they're trying to trick me into doing something that would not be in my best interest they're not just after my money. Although their methods are wrong, that does not mean they're entirely clueless. Some of these unwanted newsletters are sent with VERP-style return paths, which suggests that if the mail bounces at SMTP time, I would no longer receive their junk. So bouncing them is what I do. Exim makes this very easy:

acl_check_mail:
  deny
	message = Your domain has been blacklisted
	log_message = domain blacklisted
	condition = $ 
			lookup $sender_address_domain 
			wildlsearch /etc/exim4/blacklist-domains 
			 true 
			 false 
		      
  accept

What this does is use a wildlsearch lookup to verify whether the domain of the envelope sender (i.e., as specified in the MAIL FROM: SMTP command) exists in the /etc/exim4/blacklist-domains file. Since we use a wildlsearch, we can use the * as a wildcard *grep.be would mean 'grep.be, or any of its subdomains', whereas *.grep.be would mean 'any of the grep.be subdomains'. This is because at least one of the people I've blacklisted that way sends their newsletter through a distributed service, and the VERP-style header is based upon the server that actually communicates with my system; and others have a subdomain for the newsletter, but don't use it (or use a different one) for regular mail. If I'm not interested in their spam, I'm probably also not interested in their other mail, so therefore the wildcard (is this overkill? Maybe, but I don't care I don't do business with spammers). This ACL is then activated for the SMTP MAIL FROM: command (search for acl_smtp_mail variable in the exim specification). This makes it impossible for the spammer to reach postmaster@ from the same domain, too, but that doesn't matter; they can always use a different address. One might be wondering why I'm using this kind of domain-based blacklisting rather than a regular bayesian spamfilter, or anything of the sorts. The reason is fairly simple: because the general format of these newsletters is distinctly different from regular spam. For instance, some of these newsletter spammers are in fact competitors who didn't bother to check who they're sending mail to. As a result, their newsletters would contain key words that would appear in mails which I send to my regular customers, too; if I were to classify them as spam in my bayesian classifier, that would increase the chance of the classifier misclassifying a mail from an actual customer as spam. Most of these are very similar in format to newsletters that I did consciously subscribe to, and which are therefore not spam, etc. Finally, bouncing mail rather than blackholing it or filing it in a separate folder (as I have spamassassin do) has the added advantage of making it clear to a newsletter spammer that their junk is not wanted. Most (though certainly not all) will then remove me from their newsletter, saving me bandwith and processing power. And since we do this at MAIL FROM: time, rather than upon completion of the RCPT TO: or DATA commands, I'm not actually giving away any information that they don't have, either.

Volume 40 of of the (electronic) Journal of Statistical Software just came out. It contains my short review of Josef Adler's already pretty popular R in a Nutshell from O'Reilly. You can my review as a pdf via this local preprint, or by visiting the JSS page of the review and its official copy.

Adam D. Barratt is a Debian developer since 2008, in just a few years he got heavily involved to the point of being now Release manager , a high responsibility role within the community. He worked hard with the other members of the release team to make Squeeze happen. You could expect the release managers to have some rest after a big release, but it s not really the case. With the long freeze, loads of transitions have accumulated and they are now busy to get all those updated packages in the new testing (wheezy). Despite this Adam took some time to answer my questions. He shares with us his impression on the Squeeze release, his opinion on time-based freezes (regular/predictable freeze) and much more. Read on. My questions are in bold, the rest is by Adam. Who are you? I m a 31 year old software developer and part-time sysadmin for a software and IT services company based in the south of England. I have no children, no pets and a long-suffering partner who puts up with me spending far too much time tinkering with things and people making fun of her Macbook during Debconf. As well as being on the release team, I m a member of the maintainer teams for devscripts and lintian. Can you describe your journey in Debian and in the release team? I was introduced to Debian as part of an infrastructure upgrade at work, moving from a set of Red Hat and Solaris-based systems. As part of that, we submitted some bugs for issues we found during the upgrade and for small patches we included in some software to add extra functionality we wanted. From that starting point I became more interested in Debian in general and began following some of the mailing lists and IRC channels. When Julian Gilbey asked for help with the maintenance of devscripts, I submitted some patches for some of the outstanding bug reports and was invited to join the team which was being created to handle maintenance for the package. One of the then Release Managers was also on the team and asked if I d be interested in working on a couple of updates they wanted to the scripts which generate the proposed-updates overview pages. I added the new functionality which was merged in to the live scripts and a little while later I was invited to join the team, shortly before Debconf 9. As most readers will be aware, we unfortunately reached a point during last year where we didn t have anyone filling the Release Manager role. During that period, I became more active in handling transitions and requests for updates to stable and as time went on more people started to suggest that I should put myself forward for the position, or refer to me as already being RM. I procrastinated over the decision for some time but after discussions during Debconf 10 I came round to the idea that we should have the RM role filled again and agreed to take it on, together with Neil. The rest, as they say How much time do you usually spend working for the release team ? I ve been trying to work out how to usefully answer this question. My initial answer was approximately two hours each day , but the longer I thought about it the more I started debating exactly what I should include under the umbrella of release work; after some to-and-fro I ve decided to stick with my initial answer. During periods when Debian is frozen and particularly in the lead up to the release that time commitment increases significantly, particularly over weekends. I m reliably informed that at that point the correct answer to the question is too much time . What s your own retrospective of the Squeeze release? What went well and what needs to be improved? Overall, I believe the release went well and that we should all be proud of the Squeeze release. The parts of the release cycle which highlighted the need for improvement all share, imo, a single root cause communication, particularly around freeze-related plans. We worked hard during the freeze itself to improve our communication with the rest of the project and want to continue in that vein during the Wheezy cycle. One thing that I personally found quite difficult at times before the freeze was keeping track of the transitions which were still waiting for a place in the queue; it s also something that we could improve on at this early stage of the Wheezy cycle. In order to help us keep a clear overview of requests for transitions, stable updates and binNMUs, it would be helpful if they could be filed as appropriately user-tagged bugs. This not only allows us to easily get an overview of the status of requests from the BTS but also aids transparency by allowing anyone else to do so; as a useful additional feature, it means that we can use the BTS s blocking functionality to indicate reasons why a request cannot be fulfilled right now. Are you in favor of time based freeze? I think there s merit in having a time frame that we can work towards in order to achieve the goals which we set ourselves for the release, as individual maintainers, maintenance teams and a project. I do have concerns that even with such a time frame in place there will still be uploads made very close to the proposed freeze point and transitions which may be unfinished, for example because of an unforeseen entanglement with or reliance on the transition of another package. One thing I m interested in is how exact and specific that time frame should be and the balance between predictability and being able to achieve everything we want for a great release; this is something we can cover in the debate on this subject which I know many people have strong opinions about. What are your plans for Debian Wheezy? The Wheezy to-do list I started before the final Squeeze release begins multiarch, multiarch, multiarch . It looks like we re finally going to get that achieved during this release cycle, thanks to a great deal of hard work from various people. I m also interested in seeing the C.UTF-8 locale standardised throughout Debian and continuing to work on our tools and processes to make tracking of transitions and stable updates simpler (or at least appearing to be so and more transparent. With my package maintenance hats on, I d like to help ensure that both devscripts and lintian are able to keep pace with changes in the development landscape in Debian (e.g. more useful package diffing for source format v3 packages) and continue to be tools that are an integral part of package development in Debian. Some people (including me) would like a rolling distribution constantly usable by end-users. Do you think that the release process currently geared towards producing stable can be accommodated to support this? I m not yet convinced that the concept of a rolling, constantly usable distribution can be easily integrated in to the workflow that exists around preparing stable releases in Debian. The testing distribution was created as, and continues to be used as, a tool to enable the release team to create the next stable release that it happens to be something that people can use every day for much of the time is mostly a happy side-effect of the fact that we don t gratuitously break it, but is by no means guaranteed to be the case early in the release cycle or during large, disruptive, transitions. It s been suggested that testing and rolling could be basically the same for most of the cycle, with rolling then continuing to be updated when testing is frozen. This would essentially mean an extra suite which is only used for a few months every couple of years or so, which is one of the things that testing was intended to avoid (i.e. the old frozen suite) and seems like a lot of overhead to introduce in order to reduce disruption to some users during the freeze. The early part of the release cycle also tends to include a number of larger transitions which often require packages to either be removed from testing or broken as part of migrating the transition, if they are not able to be successfully updated in time. What s the biggest problem of Debian? The thing that I ve been noticing myself becoming frustrated by recently is a tendency to debate the minor details of proposals, rather than concentrating on getting the key points right to begin with. Clearly for some projects such as multiarch the details may be as important as the big picture, but in most cases the people working on a development should be allowed to look after the smaller details themselves. That s not meant to imply that feedback from other parts of the project should not be welcomed, simply that if we consider Debian to be a do-ocracy then we need to permit people the freedom to do . Is there someone in Debian that you admire for their contributions? All previous release managers, for making the job look much easier than it seems when you re in the hot seat . Outside of the release team, Joey Hess for his contributions to various parts of the Debian development environment over the years, such as debhelper and debian-installer, and Colin Watson for his enviable willingness to tackle a wide variety of different projects within Debian.

---

Thank you to Adam for the time spent answering my questions. I hope you enjoyed reading his answers as I did. Subscribe to my newsletter to get my monthly summary of the Debian/Ubuntu news and to not miss further interviews. You can also follow along on Identi.ca, Twitter and Facebook.

No comment Liked this article? Click here. My blog is Flattr-enabled.

A pure maintenance release of RcppGSL---our interface package between R and the GNU GSL using our Rcpp package for seamless R and C++ integration---is now on CRAN It contains no new code, but smoothes one or two edges in the build process and noticed by the newest versions of R CMD check. It also adds vignette from the unit tests as some of our other packages do. The short NEWS file extract follows below.

0.1.1   2011-04-05
    o   Unit tests produce a summary vignette as for some of the other packages
    o   The documentation Makefile now uses the $R_HOME environment variable
    o   The documentation Makefile no longer calls clean in the all target

And courtesy of CRANberries, here are the changes to the previous release.

Diff between RcppGSL versions 0.1.0 dated 2010-12-01 and 0.1.1 dated 2011-04-06
 ChangeLog                          22 ++++++++++++++++++++
 DESCRIPTION                         8 +++----
 inst/NEWS                           8 +++++++
 inst/doc/Makefile                  28 ++++++++++++++++++++------
 inst/doc/RcppGSL-unitTests.Rnw  only
 inst/doc/RcppGSL-unitTests.pdf  only
 inst/doc/RcppGSL-unitTests.tex  only
 inst/doc/RcppGSL.pdf            binary
 inst/doc/RcppGSL/RcppGSL.Rnw       43 ++++++++++++++++++-----------------------
 inst/doc/unitTests              only
 src/Makevars.in                     2 -
 11 files changed, 75 insertions(+), 36 deletions(-)

More information is on the RcppGSL page. Questions, comments etc should go to the rcpp-devel mailing list off the R-Forge page.

The Background If you weren't online last Friday you probably have missed the big news announcement on the various community distribution websites. The main pages of them got replaced by a placeholder announcing the birth of The Canterbury Project. People started to wonder whether it is an April fool's prank or for real. This blog post is meant to shine a bit more light on it and address one comment received about it. If you go to the news item on the Debian site you'll get your answer about that it indeed was an April fool's prank. The idea for doing something in coordination with other distributions came to me when I thought about last year's (or was it already two year's ago?) prank that the various web cartoon sites pulled: they replaced their main page with the page of another cartoonist. My original idea was actually along that lines. So I started to dig up website contacts from different distributions, I was aiming at the big names in the community distribution sector. Given that my time is pretty limited these days with renovating the house we plan to live in soonish I knew I had to let in others in within Debian. I though didn't want to involve too many people, for several reasons: it should be a surprise to as many as possible, but more importantly, I didn't want to shy away other distributions by an overwhelming Debian involvement. That's also part of the reason why I didn't contact many Debian based distributions. So first contacts where made, a dedicated IRC channel used for coordination, and people involved joined in. Then the thing happened which the Free Software community is so well known for: additional ideas came in, two people independently addressed me whether it wouldn't be better that instead of a circle replacement of the frontpage, why not display the same page on all of them. And one of them added that a corresponding news item might make sense. So there we were, having to think about text to put into two things: the news item and the replacement page itself. At this stage Alexander threw in a project name with a background that was adopted. Francesca started with an idea for the news item, I started to put quotes in and asked for ones from the other involved people that fit their distribution well. Klaas came up with a template for the replacement page that we tweaked. Fortunately we ended up being five distributions and the colors of the banner did match the distribution ones rather well (except for one, we had to tweak the color of one banner). The Credits We were all set, and actually everything went fine. And it definitely caught the attention. This blog post goes out in thanks to the following people:

• For Arch Linux: Pierre Schmitz and Dieter Plaetinck thanks for joining in on such a short notice!
• For Debian: Alexander Reichle-Schmehl (thanks for the name!), David Pr vot, Francesca Ciceri (thanks for gathering contact information!) and Martin Zobel-Helas (thanks for webserver setting tweaks).
• For Gentoo: Robin H. Johnson thanks for the best quote for the news item!
• For Grml: Michael Prokop thanks for the great live CD and your input!
• For openSUSE: Thomas Schmidt and Klass Freitag thanks for the perfect website theme and the best mocked up news item!
• ... and most of all, to the to be left unnamed person from the distribution that didn't join in in the end: a lot of thanks has to go in that direction because of the invaluable input. The actual idea about the additional news item is to be accounted to that person, and the Canterbury logo was tweaked there too.

I hopefully haven't forgotten anyone. There surely were some more people involved in the other distributions, and I guess the named people weren't aware of all the ones involved inside Debian. Feel free to drop missing names in the comments. Addressing Feedback Finally, let me address one concern raised: someone claimed that the real joke with this prank was that we would consider collaboration to be a joke. Actually, the total opposite is the case here. That it was possible to pull it off should be proof enough that Collaboration Across Borders actually is possible. And the background information put into the news section of the replacement site is real. Also, my personal quote in the news item was meant dead honest. I do believe that DEX has a limited point of view and only tackles part of the problem. Unfortunately, for such efforts to really come to life it takes people with a really long breath and dedication to it. Efforts like the VCS-PKG and the Freedesktop Games effort are more or less stalled. Even though a lot of people do believe in stronger collaboration to be a good thing, the basis is not working out too well. I'm in the fortunate position that for some of the packages I maintain there is exchange between packagers from different distributions to avoid common troubles. If it can't be done in the big it should at least be tried in the small. I want to specifically highlight again one part of the updates in the replacement page: the CrossDistro track at this year's FOSDEM. This one was more than fruitful, on several levels. From what I've heard a lot of discussion happened besides the talks too, and connections got established. It doesn't sound unlikely like this might be done again next year. So again, thanks for enjoying this April fool's prank, thanks to everyone who helped to deliver it, and especially a lot of thanks to the people who this might have got thinking of possibilities to improve on the collaboration front!

/debian permanent link Comments: 8 Flattr this

Looking at current state of some phpMyAdmin translations, I came to conclusion that some are not worth shipping, because they really do not translate reasonable amount of the interface. The problematic question is where to draw the line. For 3.4.0-rc1 I drew it at 50% of messages, what means that 25 languages currently pass. It might look too strict and the threshold will most likely change for final 3.4.0, but we need to start somewhere. While discussing this topic on mailing list, Tyron Madlener came with idea to tell users of incomplete translations about it and point them to information how to contribute. I quickly implemented this idea and it is now in git and live on demo server. I deliberately decided not to remove incomplete translations on demo server, maybe they will attract new contributors thanks to new warning on main page.

Filed under: English Phpmyadmin 2 comments Flattr this!

I recently set up debian on a Thecus N8800Pro. It seems to be a decent rackmount 2U chassis with 8 3.5" hot-swap SATA drives, dual gigabit NICs, a standard DB9 RS-232 serial port, one eSATA port, a bunch of USB 2.0 connectors, and dual power supplies. I'm happy to be able to report that Thecus appears to be attempting to fulfill their obligations under the GPL with this model (i'm fetching their latest source tarball now to have a look). Internally, it's an Intel Core 2 Duo processor, two DIMMS of DDR RAM, and a PCIe slot for extensions if you like. It has two internally-attached 128MiB SSDs that it wants to boot off of. The downsides as i see them:

BIOS

The BIOS only runs over VGA, which is not easy to access. I wish it ran over the serial port. It's also not clear how one would find an upgrade to the BIOS. dmidecode reports the BIOS as:

        Vendor: Phoenix Technologies, LTD
        Version: 6.00 PG
        Release Date: 02/24/2009

RAM

The mainboard has only two DIMM sockets. It came pre-populated with two 2GiB DDR DIMMs. memtest86+ reports those DIMMs clearly, but sees only 3070MiB in aggregate. The linux kernel also sees ~3GiB of RAM, despite dmidecode and lshw reporting that the two DIMM modules each are only 1GiB in size. I'm assuming this is a bios problem. Anyone know how to get access to the full 4GiB? Should i be reporting bugs on any of these packages?

SSDs

The internal SSDs are absurdly small and very slow for both reading and writing. This isn't a big deal because i'm basically only using them for the bootloader, kernel, and initramfs. But i'm surprised that they could even find 128MiB devices in these days of $10 1GiB flash units.

processor

/proc/cpuinfo reports two cores of a Intel(R) Core(TM)2 Duo CPU T5500 @ 1.66GHz, each with ~3333 bogomips, and apparently without hardware virtualization support. It's not clear to me whether the lack of virtualization support is something that could be fixed with a BIOS upgrade.

I used Andy Millar's nice description of how to get access to the BIOS -- I found i didn't need a hacksaw to modify the VGA cable i had. just pliers to remove the outer metal shield on the side of the connector i plugged into the open socket. lshw sees four SiI 3132 Serial ATA Raid II Controller PCI devices, each of which appears to support two SATA ports. I'm currently using only four of the 8 SATA bays, so i've tried to distribute the disks so that each of them is attached to an independent PCI device (instead of having two disks on one PCI device, and another PCI device idle). I don't know if this makes a difference, though, in the RAID10 configuration i'm using. There's also a neat 2-line character-based LCD display on the front panel which apparently can be driven by talking to a serial port, though i haven't tried. Apparently there are also LEDs that might be controllable directly from the kernel via ICH7 and GPIO, but i haven't tried that yet either. Any suggestions on how to think about or proceed with a BIOS upgrade to get access to the full 4GiB of RAM, BIOS-over-serial, and/or enable hardware virtualization?Tags: n8800pro, thecus

A brand new and shiny 0.9.3 release of Rcpp is now on CRAN and Debian. This version contains an actual bug fix for Rcpp modules and a few build improvements, including for both clang/llvm and g++-4.6 (which, being in Debian, is already used for conformance checks on CRAN's incoming directory) and g++-4.5. We also updated the main introductory vignette Rcpp-introduction to the content of what should be a forthcoming paper in the Journal of Statistical Software. The complete NEWS entry is below; more details are in the ChangeLog file in the package and on the Rcpp Changelog page.

0.9.3   2011-04-05
    o   Fixed a bug in which modules code was not behaving when compiled 
        twice as can easily happen with inline'ed version
    o   Exceptions code includes exception_defines.h only when g++ is 4.5 or
        younger as the file no longer exists with g++-4.6
    
    o   The documentation Makefile now uses the $R_HOME environment variable
    o   The documentation Makefile no longer calls clean in the all target
    o   C++ conformance issue found by clang/llvm addressed by re-ordering
        declarations in grow.h as unqualified names must be declared before
        they are used, even when used within templates
    o   The 'long long' typedef now depends on C++0x being enabled as this
        was not a feature in C++98; this suppresses a new g++-4.5 warning
    o   The Rcpp-introduction vignette was updated to the forthcoming JSS paper

Thanks to CRANberries, there is also a diff to the previous release 0.9.2:

Diff between Rcpp versions 0.9.2 dated 2011-02-24 and 0.9.3 dated 2011-04-05
 ChangeLog                                                      60 
 DESCRIPTION                                                     8 
 R/00_classes.R                                                  5 
 R/01_show.R                                                    44 
 R/Module.R                                                      1 
 cleanup                                                         2 
 inst/NEWS                                                      23 
 inst/doc/Makefile                                              74 
 inst/doc/Rcpp-FAQ.pdf                                       binary
 inst/doc/Rcpp-FAQ/Rcpp-FAQ.Rnw                                  2 
 inst/doc/Rcpp-extending.pdf                                 binary
 inst/doc/Rcpp-introduction.Rnw                               1355 +++++++------
 inst/doc/Rcpp-introduction.pdf                              binary
 inst/doc/Rcpp-modules.pdf                                   binary
 inst/doc/Rcpp-package.pdf                                   binary
 inst/doc/Rcpp-quickref.pdf                                  binary
 inst/doc/Rcpp-sugar.pdf                                     binary
 inst/doc/Rcpp-unitTests.pdf                                 binary
 inst/doc/Rcpp.bib                                              99 
 inst/doc/jss.bst                                            only
 inst/doc/unitTests-results/Rcpp-unitTests.html                 18 
 inst/doc/unitTests-results/Rcpp-unitTests.txt                  46 
 inst/include/Rcpp/Module.h                                     40 
 inst/include/Rcpp/Vector.h                                      6 
 inst/include/Rcpp/config.h                                      2 
 inst/include/Rcpp/grow.h                                       91 
 inst/include/Rcpp/module/Module_generated_ctor_signature.h     18 
 inst/include/Rcpp/vector/RangeIndexer.h                         5 
 inst/include/RcppCommon.h                                       6 
 inst/unitTests/runit.Module.R                                  19 
 inst/unitTests/testRcppModule/src/stdVector.cpp                 7 
 src/exceptions.cpp                                              2 
 32 files changed, 1167 insertions(+), 766 deletions(-)

As always, even fuller details are on the Rcpp Changelog page and the Rcpp page which also leads to the downloads, the browseable doxygen docs and zip files of doxygen output for the standard formats. A local directory has source and documentation too. Questions, comments etc should go to the rcpp-devel mailing list off the R-Forge page