I thought it's about time to write a short report on my RC bug squashing activities again; nothing spectacular, but maybe it motivats others *hint*

• #558272 libdate-calc-perl: "Date::Calc::Decode_Month(): argument is not a string"
  upload package prepared by ansgar (pkg-perl)
• #578458 src:libcoro-perl: "libcoro-perl: FTBFS: E: Caught signal 'Terminated': terminating immediately"
  more mails to the BTS (pkg-perl)
• #590652 src:megahal: "megahal: build depends on obsolete Tcl/Tk 8.3"
  sponsor QA upload prepared by ansgar
• #591111 src:libdbd-sqlite3-perl: "libdbd-sqlite3-perl: FTBFS: failed tests"
  upload package prepared by carnil with a patch from ntyni (pkg-perl)
• #591678 greylistd: "greylistd-setup-exim4 causes excessive callouts and cause the server to be blacklisted"
  add a comment in the BTS
• #592506 libtest-harness-perl: "libtest-harness-perl: Serious regressions in 3.20-1 solved in upstream Git, probably blocker for stable"
  propose removal from testing (pkg-perl)
• #593145 chrony: "chrony: fails to configure on installation"
  fix init script and upload to DELAYED/2, later cancelled on maintainer's request
• #594708 emerillon: "emerillon: FTBFS due to librest transition 0.6 -> 0.7"
  tag and comment on the BTS
• #596257 libanyevent-perl: "libanyevent-perl: architecture specific constants in an arch:all package"
  upload as arch:any, analysis by ntyni (pkg-perl)

It is not as prestigious as Chicago half-marathon, but it turns out that the day Dirk ran one of his slowest halves in years (but, eh, I'm happy for him as ha had a very disappointing running year), I ran my fastest and completed the 600-runners Bois d'Arcy half-marathon, finishing 181th ou the 573 finishers. That one was planned to be one of the peaks in my preparation for the Seine-Eure marathon, my second official marathon run of the year (and my third marathon). 1h37'27", that's 4 minutes better than my best time as of now (this year's Paris half, back in March). So, it seems that now, I can safely target 3h35-3h40 for October 17th (3h30? A bit far, still...). We'll see... Anyway, it seems that my crazy summer (730km ran between June 1st and Sept 10th) is giving results. Not Dirk's "run less, run faster"....but it seems that it's working for me..:-)

Gnash 0.8.8 was released on the 23rd of August, a bit more than two weeks after the freeze. There are very important features in this new release that made 0.8.8 by far a better option than buggy 0.8.7 for Squeeze:

• 100% of all YouTube videos should work now. If you have problems, delete all YouTube cookies and refresh.
• Gnash can switch at runtime between the Cairo, OpenGL, and AGG renderers.
• It can also switch media handlers at runtime, between FFmpeg and GStreamer.
• Gnash can now decode video quickly on hardware compatible with the VAAPI library (a few NVidia, ATI, and Intel graphics processors). Debian packages by default do not have this feature activated until FFmpeg in Debian supports VAAPI, so that will be in Wheezy.
• It compiles faster due to reduced internal dependencies.
• It has Scriptable Plugin support so Javascript in the browser can work with ActionScript in Gnash.
• There is an improved input device handling when using a raw framebuffer.
• Lots of bugs fixed.

Today, the Release Team has unblocked 0.8.8-2, which has already reached Testing, so I m proud to announce that Squeeze will be released with latest Gnash. Thanks guys!

Second Sunday in September -- time for the annual Chicago Half Marathon now in its fourteenth edition (and I have been running it in 2003, 2004, 2005, 2006, 2007, 2008 and 2009 making this and the JPM Chase Corporate Challenge the races I've run most often). And the course was altered this year, alongside with an earlier start as the Bears have their season home opener today. So we started north towards 57th, then running down to 67th, turning east towards the lake at around three miles --- and having the remaining ten miles along the lakefront running up to 31st (the usual turn) and back down to 63rd. I like this course better; let's hope it sticks. Race conditions were fantastic. We had a rainy and gray day yesterday but today is pure bliss. Temperatures around 60 degrees at the 7:00am start, no wind, sunshine and not a cloud in the sky. The race itself went well. I had a pretty brutal running year suffering most of the time from some archilles tendon inflammation. It has gotten better in the last few weeks possibly thanks to some heel cups I now put in the shoes. But I had exactly one run longer than ten miles since the Boston Marathon. So I lost a lot of speed, as well as endurance and was a little nervous as to how I'd do. And considering all this, it went pretty well. I fininished in 1;41:50 or a 7:47 pace. While is easily the slowest half in a number of years, at least I got to run it evenly, pain free and with a negative split (== faster second half) and some gas left for a fast last half mile or so. So maybe I don't have to retire from running just yet. We'll see if I get some speed back in 2011.

Most people won't need this, but for testing things like Debian bug #596009, it is very handy. A few posts on the internet say this doesn't work, or not reliably, so here is my recipe. System: VirtualBox from sid (3.2.8), and VMs created with Enable IO APIC, Enable PAE/NX, Enable VT-x/AMD-V (I have an AMD Phenom II 940), and finally Enable Nested Paging. I don't know if all these are absolutely needed, but with this config the final guest runs nicely for some quick tests. There are just a few gotchas that I stumbled upon:

• having CPU hotplug enabled will break Xen, so run vboxmanage modifyvm $VM --cpuhotplug off
• using virtio NICs softlocks the CPU as soon as any traffic is done; while this is not the default, some people might have it enabled. I've tested the Intel server NIC and it works fine
• I've seen one hang when dom0 was assigned more than one CPU, so for best results, even if the whole VirtualBox VM has more than one CPU assigned, restrict dom0 to one (either via maxcpus=1 or via xm vcpus-set 0 1)

If however dom0 hangs, you should activate the first serial port in the VirtualBox config (raw file), and then you can get at least a kernel trace. As for the pure CPU, speed, the results are interesting; I've used openssl speed rsa to do a quick test. Host (non-virtualized):

                  sign    verify    sign/s verify/s
rsa  512 bits 0.000089s 0.000009s  11176.2 116018.4
rsa 1024 bits 0.000422s 0.000024s   2370.9  41914.3
rsa 2048 bits 0.002643s 0.000075s    378.4  13255.5
rsa 4096 bits 0.017623s 0.000272s     56.7   3680.9

And domU guest (double-virtualized, that is):

                  sign    verify    sign/s verify/s slowdown
rsa  512 bits 0.000051s 0.000009s  19620.1 111644.0    3.78%
rsa 1024 bits 0.000390s 0.000026s   2561.1  38929.4    7.13%
rsa 2048 bits 0.002752s 0.000080s    363.4  12566.9    5.20%
rsa 4096 bits 0.018628s 0.000288s     53.7   3474.3    5.62%

So we have less than 10% for pure CPU work, nice. I'm not able to do I/O testing since my VirtualBox machines are using write-back cache, not write-through, so I end with this unrealistic speed:

# dd if=/dev/zero of=big-file bs=1024k count=127 oflag=direct
127+0 records in
127+0 records out
133169152 bytes (133 MB) copied, 1.21597 s, 110 MB/s

So no, this should not be used for any kind of benchmarking; but for testing and debugging issues, it's a good way to fire up a Xen box without having to change any config or risk breaking your main machine

Now that Squeeze is frozen, and release date is approaching, removing unused and buggy packages from the archive is a nice task to save maintenance burden which often involves several people (QA guys and Release Managers, mostly). A lot of removal bugs are coming to ftp.debian.org pseudo-package, so I d like to thank fellow contributors who spent part of their time on this task. A special thank goes to Moritz Muehlenhoff, who filed tons of bugs, and contributed to remove a lot of unused packages. If you re interested too, you could look at these guidelines. Keep up the good work, guys!

A lot is being said on how Ruby is packaged in Debian and Ubuntu. In this post, I m trying to go through the most common myths and give my position as a Debian Ruby maintainer. Note that those are my views, not necessarily those of the other Debian Ruby maintainers. Myth: Ruby is completely outdated in Debian and Ubuntu There s a culture in the Ruby community of always using the latest bleeding-edge version. There s also a culture (though this one has recessed a bit, I think) that it s perfectly fine to change APIs in incompatible ways if it makes the software slightly better. In Debian (and Ubuntu) stable releases, we try to provide a rock-solid version of Ruby that won t be allowed to change API during the support lifetime of a release. Bugfixes for important bugs can be applied, but that s basically all. So it s not surprising that Ruby in released versions of Debian and Ubuntu is behind the latest upstream version. In development branches, we are following the latest upstream versions quite closely. Debian 6.0 squeeze , to be released by the end of the year, includes Ruby 1.8.7-p302, and will include 1.9.2-p0 (the currently of Ruby 1.9.2 in squeeze is currenty a SVN snapshot from beginning of august). There are people interested in installing a packaged Ruby that just works, and other people interested in installing their own version of Ruby (through RVM and such). People in the Ruby community tend to forget about the first category, and consider that, because they install Ruby from source or with RVM, that should be the solution for everybody. We need the Ruby community to respect that different people have different ways of using Ruby, and to stop recommending that everyone using Debian and Ubuntu should install Ruby from source. We also need to leverage the backports services for both Debian and Ubuntu to provide a way to install the latest upstream version on stable releases. The only reason why we are not doing it yet is lack of time. Myth: Ruby is split into a myriad of packages in Debian In the past (pre-2005), a decision was made to split some libraries from the standard library into separate packages. This was motivated by:

• the size of some libraries, like REXML
• the fact that some libraries, like OpenSSL, readline, gdbm and tk require other library packages to be installed
• licensing concerns about shipping some code (a .so) linked with OpenSSL, and some other code (another .so) linked with readline, in the same package.

Most of the split was undone a very long time ago, and the readline and openssl splits were undone this year. The current package in Debian squeeze has:

• ruby1.8: binaries (ruby itself, irb, rdoc)
• libruby1.8: the standard library, except ruby-tk
• libtcltk-ruby1.8: ruby-tk (merging it with libruby1.8 would add several megabytes)
• ri1.8: contains both the ri binary and documentation
• ruby1.8-dev: development headers (to build applications or gems linked against the Ruby C API), and statically built version of the library
• ruby1.8-elisp: Ruby emacs mode
• ruby1.8-examples: Examples
• libruby1.8-dbg: debug symbols

It is always possible to merge more packages, but merging any of the other packages would significantly increase the size of what you get by default, and might discourage people to use it in some contexts (disk space is not always cheap. Think embedded systems and smartphones). Myth: Rubygems is crippled in Debian There are two differences in the rubygems Debian packages. First, gems are installed in /var/lib/gems, not /usr/local/lib/gems. That is because rubygems are seen as state for the Rubygems package, not independant software installed separately. A change for this is currently being discussed, and should be done after the squeeze release. (I don t think that it s reasonable to push that change now). A consequence of installing to /var/lib/gems is that gems binary are outside of $PATH. After the change, gems binary would also be installed in /usr/local/bin. Second, gem update --sytem is disabled in the Debian package, because that would replace code from the Rubygems Debian package with code downloaded from the Internet, and can break your system in subtle ways. We have changed this (in SVN, not in any package in the archive yet) to allow gem update --system if a specific environment variable is set, which gives us the opportunity to display a warning message. Myth: Ruby is slow on Debian Ruby is built with the pthread threading code, because not using it breaks many native Ruby libraries (Ruby-gnome2, for example). And other Linux distributions are doing the same. There are some very old benchmark results floating around in some blogs that show that the pthread code has a performance impact of about 20%. There are been patches for that for a long time (applied in Ruby Enterprise Edition), but they were never properly sent back. Actually, all the discussions about this issue were rumors and blog posts, and there wasn t even a bug report about it! After the bug was reported properly, it was fixed in a timely manner. The fix is not yet included in the Ruby 1.8.7, but is being applied as a patch to the Debian package since 1.8.7.299-2. (So the Debian package is actually newer and faster than upstream Ruby in that regard). What makes Ruby so difficult to maintain in Debian? The main problems we have with Ruby are portability issues. The only officially supported platform for Ruby is IA32 (i386 in Debian), and everything else is best effort. It means that it is not even supported officially on x86_64/amd64! Debian supports a dozen of architectures, and the Ruby package has to work on each of them. Ruby 1.8 is mostly OK nowadays thanks to the help of Debian porters, but we still have serious problems with 1.9.2, since the test suite fails on sparc, hppa, ia64 and Debian GNU/kFreeBSD. Why doesn t Ruby use the alternatives system on Debian? The alternatives system provides a way to switch between different software providing the same functionality. Currently, if you want to use Ruby 1.9.2, you need to use the ruby1.9.1 executable (1.9.1 = ruby compatibility version here). The alternatives system would allow to switch ruby to ruby1.9.1 on a system-wide basis. However, the situation of applications and libraries working only with Ruby 1.8 should be clarified: those should use /usr/bin/ruby1.8 instead of /usr/bin/ruby. Another problem is that the way to specify packages dependencies still need to be determined. There s nothing impossible to do about that, it just needs someone to do the work. Where do we go from here? The Ruby developers (or expert users) community is generally very hostile towards Debian. Many harsh words and insults are used in discussions mentioning Debian in the ruby-core@ mailing list, and there are frequent recommendations to avoid the Debian packages and install from sources, which is quite demotivating (Actually, what prompted that blog post is someone calling Debian-specific changes unforgivable). This atmosphere makes it hard to recruit people, and the Debian Ruby teams are completely understaffed, which is clearly the major blocker to improving the situation further. We are 3 co-maintainers for the interpreter packages, and I m the only Debian Developer that is really active on a regular basis in the pkg-ruby-extras team (that does libraries and applications packaging). We desperately need help, but at the same time I have no time to improve our documentation and make it easier to join the team. While I haven t reached a final decision yet, I am also likely to stop doing Ruby work in Debian after squeeze is released, as I am getting increasingly tired and demotivated.

I've heard, over the years, of people spending insane amounts of money on office chairs. On the one hand I accept that you spend a lot of time sitting in chairs when you're working upon a computer. On the left I find the idea of spending 750+ on a chair a little insane. For the past few years I've had a kneeling chair over time this has gotten pretty "squished" and "flat". (Specifically the part where my knees go.) So I decided to get a new chair. What did I buy? a large rubber ball! It's a little weird to walk into the room and see this green ball in front of the keyboard, but it's actually pretty great to sit on. I'm gonna ignore all claims of "excercise" and "healthyness". Sure I find myself shifting around slightly to retain balance, but I'm not at all convinced that such small movements, even over the course of many days, will make any appreciable different to my muscles. Anyway .. That is all I have to say today. ObQuote: "Don't tell anyone we went to war over a woman. " - Mongol (2007)

I'm just back from ExoClimes 2010: Exploring the Diversity of Planetary Atmospheres. An excellent conference: the PDFs of the talks and posters are now online, and they are putting the videos of the talks up soon. But in particular the organizers deserves thanks for bringing exoplanetary scientists and observers together with climate modelers doing Earth (and Mars, Titan, Venus, ...) models. The last talk on Friday was by Peter Cox on Climate change and exoplanet sciences that was far better than expected for the "graveyard shift". One theme of the conference was the need for a 'heirarchy' of models, from simple energy-balance models to full circulation (GCM) models: using progressively more complex models to understand more bits of whats going on. Exoplanet workers mostly use simpler models, progressing now to GCMs, while Earth modellers are moving beyond GCMs to "Earth system" models including biology, etc. Peter pointed out the two styles of work: the exoplanet modelers are short of data, and risk being too speculative. We know little of what the planets are like, and concentrate on implementing physics in the models to see what they might be like. Earth modelers on the other hand are if anything swamped with data: the tendency here is to make the model fit the data, by adjusting parameters until it does so. The danger of this approach is that the model will then not work away from current present-Earth conditions. Tim Lenton pointed out some work that was done with the Met Office model, where they took the radiative transfer part of the model and tested it for other planets, and paleo-Earth conditions. The model blew up : it wasn't capable of x2 or x4 current CO2 levels. (This has since been corrected). Over dinner there were interesting discussions on the different styles within the communities. While the underlying GCMs used come from the Earth sciences, its quite common within the exoplanetary community for a researcher to work on all parts of the model: dynamics one day, radiative transfer the next. In Earth climate work people have become more specialized and someone is a 'radiative transfer' person, and won't touch other parts of the code (even if they can follow them in the huge codes we have today!). On the other hand, there is a greater tradition of model inter-comparison in Earth sciences, where we compare the model outputs to each other for some known test cases ( Held & Suarez, the CMIP5 project, etc.) Apart from some initial work by Emily Rauscher, little has been done on this in exoplanetary models; it was agreed more of this would be a good idea. Radiative transfer (the interaction of 'sunlight' with the atmosphere, where it gets absorbed, scattered and re-radiated) in particular seems to be an area that could benefit from this. In this middle ground Francois Forget showed the work on the LMDZ model and applying GCMs to terrestrial planets. They've successfully applied this model to Mars, Titan, and partially to Venus (a much tougher problem, due to its heavy clouds giving a long radiative timescale). There are problems with correctly explaining super-rotation though. This is where the atmosphere rotates faster than the planet: on Venus for example the planet rotates every 243 days, while the clouds rotate around the planet every 4 days. Sebastian Lebonnois described the possible mechanisms for Venus and Titan; Johnathan Mitchell so did some interesting work on this recently. Different regimes are involved for different rotation rates of the planet. Ralph Lorenz pointed out the lack of "real paleo-Earth" climate work at the moment. While geology has inspired a lot of work on the atmospheric composition, what with the different gas mixtures (meaning earth-model radiative transfer codes don't work) and the faster dynamics meaning super-rotation could apply (Earth's day was about 8 hours long in the Archean era), we don't have a model of the climate yet. It looks like we should treat Earth as an exoplanet. Tags astronomy, climate, exoplanets, conferences

dosfstools did not correctly handle LFN (see Debian bug #596329 for more information) and had some false positives with bad filenames (see Debian bug #596327 for more information). Todays release of version 3.0.10 fixes this. Source tarballs can be downloaded as usual from its homepage.

Now that the root DNS servers are signed, I thought it was time I started using DNSSEC on my own PC. However, not wanting to wait for my ISP to enable it, I decided to setup a private recursive DNS resolver for myself using Unbound.

Installing UnboundBeing already packaged in Debian and Ubuntu, unbound is only an apt-get away:

apt-get install unbound

though if you are running lenny, I suggest you grab the latest backport.

Once unbound is installed, follow these instructions to enable DNSSEC.

Optional settingsIn my /etc/unbound/unbound.conf, I enabled the following security options:

harden-referral-path: yes
use-caps-for-id: yes

and turned on prefetching to hopefully keep in cache the sites I visit regularly:

prefetch: yes
prefetch-key: yes

Finally, I also enabled statistics:

extended-statistics: yes
control-enable: yes
control-interface: 127.0.0.1

and ran sudo unbound-control-setup to generate the necessary keys.

Once unbound is restarted (sudo /etc/init.d/unbound restart) stats can be queried to make sure that the DNS resolver is working:

unbound-control stats

Overriding DHCP settingsIn order to use my own unbound server for DNS lookups and not the one received via DHCP, I added this line to /etc/dhcp/dhclient.conf:

supersede domain-name-servers 127.0.0.1;

and restarted dhclient:

sudo killall dhclient
sudo killall dhclient
sudo /etc/init.d/network-manager restart

If you're not using DHCP, then you simply need to put this in your /etc/resolv.conf:

nameserver 127.0.0.1

Testing DNSSEC resolutionOnce everything is configured properly, the best way I found to test that this setup was actually working is to use a web browser to visit these sites:

• http://www.dnssec.cz/ should show a green key
• http://www.rhybar.cz/ should not be reachable

and using dig:

$ dig +dnssec A www.dnssec.cz   grep ad
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 1

Are there any other ways of making sure that DNSSEC is fully functional?

(update: yesterday's version was using http://wiki.debian.org/Teams/ReleaseTeam as reference, while http://www.debian.org/intro/organization is the one that's up-to-date. Those watching the current traffic in debian-release can probably realize the huge *thank you* deserved by the entire release team for the work they're doing. So, how about spamming the release team members with (private!) "thank you" messages when they unblock a package of yours? And (even more difficult) also one when they don't unblock your package...but spent time reviewing it and more time to explain you why they prefer not unblocking it... In any case, thank you, Neil Maulkin, Adam adsb, Dann dannf, Felipe faw, Jurij trave11er, Luk luk, Mehdi mehdi, Pierre MadCoder, Julien jcristau (doh, French Cabal!)...and Martin zobel (who's apparently forgotten on the page). Not to forget Adam adsb and Phil phil for managing stable releases....and the Wise Release Wizards (vorlon, aba, luk, HE). Hat off, guys (only guys there, yet another place for d-w to show up).

A brand new and shiny release of RProtoBuf, now at version 0.2.0, arrived on CRAN earlier today. RProtoBuf provides GNU R bindings for the Google Protobuf data encoding library used and release by Google and others. This is only the second release after 0.1-0 more than six months ago. Given that Rcpp is such a key ingedrient for RProtoBuf, and that Rcpp underwent so many exciting changes itself, Romain and I never got around to releasing new versions of RProtoBuf. This version is now much closer to the actual C++ API and fairly feature rich. We summarised a few of these new things in the presentation at useR! 2010. There is more information at the RProtoBuf page; there is 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.

Today I went to HantsLUG at IBM Hursley. I delivered a talk on the Debian Perl team aimed at end users, which was well received - I got a head start by getting people in #debian-perl to review the slides beforehand, which was very helpful. I'm told there will be a video uploaded in a month or so. I also plugged SmoothWall Express on Debian to some new people, and there was interest. My most recent discovery is that I probably need to extend netcfg in the debian installer to allow configuring more than one network interface.

While SSDs are all the rage nowadays (and for good reason), I don't trust them yet for my important storage, as I'm not familiar with their failure behaviour. So when one of my hard-drives recently started misbehaving, I bought the new WD Raptor model. Since some people might be interested in how it performs in some synthetic tests under Linux, here are some fio results. Now, I admit that 10K RPM for desktop is a want versus need discussion, but nevertheless, these hard-drives are (for their capacity) quite affordable, compared to SSDs, and faster than a regular 7200 RPM drive. So:

# smartctl -i /dev/ 
 
Device Model:     WDC WD6000HLHX-01JJPV0
Serial Number:    WD-WXA1C20U0627
Firmware Version: 04.05G04
User Capacity:    600,127,266,816 bytes

The older hard-drive I'm comparing to is also a WD Raptor, the WD3000GLFS model (yes, I'm a sucker for shiny hardware). A few of the SMART capabilities seems to have changed (e.g. a new Phy Event Counter has been added, CRC errors within host-to-device FIS, and the SCT Status Version is now 3 instead of 2, the Temperature History Size is now 478 instead of 128), but nothing significantly different that I can see. First, the IOPS test: nothing changed here. To be honest, even the WD3000 model had pretty good performance. The fio job definition is:

[global]
filename=$ DRIVE 
iodepth=$ IODEPTH 
bs=$ BS 
ramp_time=10
runtime=120
[rate-iops]
rw=randread
ioscheduler=noop
ioengine=libaio
direct=1

I did tests for block sizes of 512 and 4096 bytes (but the results were so close that I only used the 512 bytes ones), and at queue depths of 1, 2, 4, 8, 16 and 24 (not 32 as AFAIK the SATA protocol only allows a max queue depth of 31, and I wanted to test only the drive's queue). So: As I said, nothing really changed, but starting at 130 IOPS and reaching more than 200 IOPS at queue depth 8 (which again, is not so much used at home) is nice. Next, the bandwidth tests. This uses the standard disk-zone-profile job shipped with fio:

[global]
bs=64k
direct=1
rw=read
ioengine=libaio
iodepth=2
zonesize=256m
zoneskip=2g
write_bw_log
[disk_zoning]
filename=$ DRIVE 

Here the changes are significant. Whereas the previous generation topped at around 110MB/s, the new model tops at over 140MB/s: I'm not sure what makes the old model vary so much at the start of the test (I repeated the measurement twice, and it looks the same), but in any case, there a few conclusions to be drawn:

• the new model is fast; the logs tell me that in the first 30 entries (zones), there are 10 entries with speeds of over 150000 KB/s (147MB/s)
• even though the capacity has been doubled, the time to read the entire drive (in zones) has only increased by ~62%, which is good
• I'll need more than Gigabit Ethernet to be able saturate just one of these drives in my storage box; even at the slowest, the drive is over 90MB/s

So, I can say I'm pretty happy. The 300GB model was a tiny bit too small for me, but the new size is great, and it seems the sequential read/write speed is also good. Let's see how long they will last though, HDD failures are (unwanted) friends of mine

If so, please tell me in the comments, how and for what purpose. I m pondering if this configurability is unnecessary baggage.

Those watching the current traffic in debian-release can probably realize the huge *thank you* deserved by the entire release team for the work they're doing. So, how about spamming the release team members with (private!) "thank you" messages when they unblock a package of yours? And (even more difficult) also one when they don't unblock your package...but spent time reviewing it and more time to explain you why they prefer not unblocking it... In any case, thank you, Neil Maulkin, Adam adsb, Dann dannf, Felipe faw, Jurij trave11er, Luk luk, Mehdi mehdi, Pierre MadCoder, Julien jcristau (doh, French Cabal!). Not to forget Adam adsb and Phil phil for managing stable releases....and the Wise Release Wizards (vorlon, aba, HE). Hat off....

In the spur of the moment, I cycled over to Dominican, one of the two small colleges in town, to see if I could snag a remaining ticket to see Billy Bragg perform. Turned out I could, and it became a nice evening out. Darren Hanlon started up the evening as the opener for a good half hour, and was quite decent; somewhat charming in a good natured way, not taking himself too too seriously. I'd gladlt see him again. After a longer-than-needed break Billy Bragg came on stage and played for two straight hours, alternating between an electric and acoustic guitar. And also alternating between some newer material and (especially towards the end and the encore) some old crowd-pleasure. I don't know his material all that well but have of course know of his career over these last 25 years and am quite glad I went to see him. Nice way to end the week.

---

As mentioned in my last blog post the GuruPlug Server Plus needs some major refactoring before it can be used. Not doing so will make you end up with a fried brick. There are various stories in the forums about cooling it properly, so you might want to have a look first instead of following mine blindly. And of course - whatever you do - it is your fault when you end up with a brick, not mine!.

Replacing the power supply As I would never ever trust the PSU (see my last blog post for the gory details) and some additional free space in the case is necessary, it is time to rip it out. As replacement I've ordered an external 5V/20W PSU. To connect it to the plug I've drilled a hole into the case and added a proper connector after soldering the original cable from the old PSU to it. Make sure to add some retainer to stop the cable from touching the CPU/memory heat sinks later.

Proper heatsinks One of the biggest problems in the original GuruPlug design is the heat spreading and collecting piece of alloy, which probably makes things even worse than better. After some discussion in #debian-devel the idea came up, that the board should be able to run fine without a heatsink - at least when idling. That is the case, indeed. So let's get rid of that piece of alloy, together with the holders and springs. Unfortunately heat things are necessary to handle some work load. To mount them make sure you get some good thermal glue as you don't want to insulate the chips from their heat sinks. I've used Arctic Silver II thermal glue - not cheap, but working well. Make sure to clean the heat sinks and chips properly with alcohol (2-Propanol is my favourite for that), so there is no fat and dust left. When you use the glue be careful to read the documentation properly and make sure you apply only as much as necessary - a thin coating is enough. After applying the glue and mounting the heat sink you need a clamp to put some pressure on it while the glue dries.

Heat sinks for the memory As there is a lot of space around the memory chips, I've got some 14x14x6mm heat sinks. Luckily there are only small parts on the other side of the board, so it was not hard to attach clamps to ensure the glue is able to dry properly. In case largish amounts of glue are squeezing out between heat sink and chip you probably want to start from scratch and clean everything (quickly!) with alcohol again.

Gigabit Ethernet PHY and CPU heatsinks PHY and CPU need proper heatsinks as they're becoming pretty hot under load. Due to space limitations I had to stick with a 17x17x20mm heat sink for the PHY. I've tried to get a largish heat sink with BGA mount for the CPU, but I was not able to find one in short time and without ordering 1000 of them. So I've got another one of the 17x17x20mm model for the CPU. Later I found two other heat sinks which might fit on the GuruPlug's CPU: Malico 19x19x25mm or a Advanced Thermal Solutions Maxigrip. But for now the smaller one will have to do the job, also I'm scared to removed it without destroying the CPU. To mount the heat sink on the PHY a bit of preparation is necessary to ensure that the glue doesn't result in short cuts on the IC's pins. The arctic silver documentation recommends to use silicone on the pins to stop the glue. As I neither had the proper silicone nor did I want to make such a mess, I've decided to get a sticky insulating tape and some tooth picks to mount it properly on the IC pins. Make sure to do a proper job here! With good clamps you can work on the PHY while the memory heat sink glue is still drying. The other problem on this side of the board is that some higher parts are mounted on the lower side of the board, so make sure to get some foam to protect them from your clamps. Except of the size of the heat sinks there is no real difference to the small ones: add glue, mount the heat sink and fix it with a clamp. Before the glue dries completely make sure you remove the duct tape strips again. Be careful not to wipe any excess glue onto the IC pins. If you manage to do so you might want to remove and clean everything properly. So just be careful and everything should be fine. Mounting the heat sink on the CPU is easier as the CPU is a nice BGA package. No need to protect pins an there are none.

Finished As you're able to see on the photo I did not the very perfect job, but fine enough to work properly.

First tests with the new heatsinks Some tests with stress and some heavy network traffic showed quickly that the heat sinks are working well! But not well enough to be able to mount them into the original closed case (how the hell was this supposed to work before!?). Without any air to breath the temperature on the CPU heat sink went up to 85 deg C quickly. So on the CPU's die are > 100 deg C, which is at least close to the max allowed temperature.

Adding air holes Obviously some additional air holes are necessary. After meeting my drill and cutter, the original case looks a bit like a piece of cheese now. Some more tests show that the temperature sticks around 76 deg C under heavy load now. That is still pretty hot, especially when the temperature in the room becomes hotter in summer. As I'm not going to run a lot of traffic trough it (my cable connection is limited to 20 MBit/s anyway), I guess it will work. Below is a graph I've recorded with my multimeter and qtdmm. It shows that the temperature rises to ~76 deg C and stays there. Not sure if I could introuce some more load, the CPU had a load of 6 running stress. Network traffic was around 2x100MBit/s again. I could imagine with 2xGBit the CPU and PHY would become much hotter (no idea if it would be able to handle it at all, though). The PHY was usually a bit cooler than the CPU, so I didn't spend time to measure the temperature properly.

Conclusion My opinion is still the the original design of the plug is an insane QA and design failure. There is no way that it could ever work as shipped originally. If I'd have to design a new case for it, it should have a single insulated compartment for a PSU to ensure that no contact with high voltage is possible. The case around all other parts should be made of alloy with a lot of air holes. So the case could be used as heat sink (properly done, not with these insulating duct tape strips) and at the same time allow air circulation and a nice view on the LEDs on the board. Of course the case would be much more expensive than, but I'm sure it would work properly and would be worth the money. And if done peoperly, it would look much better than this blinking plastic thing. I could imagine it would sell well! So at the end I'm wondering what GlobalScale Technologies will do. I doubt it will be possible to create the 'professional upgrade kit' as they had announced before. Replacing all units is the only proper way. We'll see what happens. At least my GuruPlug is working well now and it will be used as replacement for my OpenWRT router soon. WiFi is not working, but that will be handled by my media center anyway.