I have a Macbook3,1 with the following SATA controller: 00:1f.2 SATA controller: Intel Corporation 82801HM/HEM (ICH8M/ICH8M-E) SATA Controller [AHCI mode] (rev 03) This chip can work either in AHCI or IDE mode. Even though (in numbers) AHCI and IDE should have similar performance, I have found that AHCI mode is much better. Specially when the disk is under heavy siege by more than one application. The catch is that Macbooks turn off AHCI when booting in BIOS mode, which is the mode I use for GNU/Linux. I understand this also affects Windows.

Pictured: a girl after enabling AHCI on her Linux Macbook After some googling I found this post that explains how to activate AHCI mode using GRUB2. The fix is to just add a setpci call on your GRUB configuration. To be safe you can test it by going into command line mode in GRUB, and doing something like this: > lspci
(check for the ID for IDE mode, in my case 8086:2828)
> setpci -d 8086:2828 90.b=40
> lspci
(The 2828 ID is now gone, replaced by 8086:2829, AHCI/SATA mode)
You can add this to your GRUB configuration, and avoid losing it on upgrades, by adding a script like this to /etc/grub.d/:

#!/bin/sh
set -e
## Enable SATA (AHCI) mode on macbook 3,1
echo "setpci -d 8086:2828 90.b=40"
I understand this is also relevant for newer Macbooks and standard PC hardware, so you might want to do some googling. The easy way to know if you are on the right mode is to run lspci -nn on a regular terminal (not GRUB) and see if you have a SATA controller that is in the wrong mode.

these are the RC bugs I've worked on during the last week:

• #575087 wbar: "On a default installation wbar will fail due dot.wbar"
  add comments to the bug report, severity lowered later by maintainer
• #652638 libuuid-perl: "libuuid-perl: conflict with older doc-base versions to fix upgrade problems"
  add Conflicts (pkg-perl)
• #656505 taxbird: "taxbird: build-dependency on libgeier-dev needs to be versioned"
  fix versioned build/runtime dependencies, upload to DELAYED/2
• #657465 conserver-client: "conserver-client: prompting due to modified conffiles which where not modified by the user"
  fix configuration file handling, upload to DELAYED/2
• #688206 pure-ftpd-common: "pure-ftpd-common: modifies conffiles (policy 10.7.3): /etc/default/pure-ftpd-common"
  fix configuration file handling, upload to DELAYED/2
• #688223 emacspeak: "emacspeak: modifies conffiles (policy 10.7.3): /etc/emacspeak.conf"
  fix configuration file handling, QA upload
• #688231 acgvision-agent: "acgvision-agent: modifies conffiles (policy 10.7.3): /etc/acgvision/agent.ini"
  add comments, and file #690170 while we're there
• #688796 src:libkdtree++: "libkdtree++: incomplete debian/copyright"
  sponsor maintainer upload
• #688891 psad: "psad: modifies conffiles (policy 10.7.3): /etc/psad/psad.conf"
  add thoughts and questions to bug report
• #689120 gstreamer0.10-gconf: "gstreamer0.10-gconf: does not really provide sinks and sources"
  send a patch to the BTS
• #690355 libfile-data-perl: "libfile-data-perl: (virtually) empty binary package"
  prepare a patch (pkg-perl)

this week, a new feature was merged into the NUT development tree: beside of the historical OpenSSL support (for more than 10 years), NUT now also provides SSL features using Mozilla NSS. I've already posted a lengthy mail on the NUT developers list. But there are still a few things to be told:

• for legal reasons, I won't detail, NUT (GPL v2+), can't be linked on OpenSSL without exiting from the 'main' Debian repository. Thus, NUT packages in Debian (and derivatives) don't provide NUT crypto features!

• to me, NSS has some advantages, compared to OpenSSL. Among these, NSS is distributed under 3 licenses, including GPL. So it will fix the situation for NUT in Debian! But there will be more things to come with NSS, such as client authentication, and more security for infrastructure power management.

• other distros (mainly Redhat and Suse) have attempted (and are still attempting) to consolidate crypto features, using NSS. Debian has not taken any decision on this topic though. NUT now offers the choice between OpenSSL and Mozilla NSS.

• NSS support will be officially available with NUT 2.8.0. There is currently no release date since we're committed to a features set, not a release date. Some would say Debian old school. Everything would be different with more manpower, as everywhere else in our Free land...

For the braves who want to test, here is a small procedure, adapted to Debian. We will use an existing installation, and overwrite upsd, upsmon, libupsclient and few more. Beware that it will obviously breaks the MD5 sums of your nut packages!

• install NUT, if it's not already done:

# apt-get install nut

• download the source snapshot, and uncompress it:

$ tar xzvf nut-trunk-r3751.tar.gz

• install NSS development files:

# apt-get install libnss3-dev 

• change to NUT source directory and configure it using --with-nss, to force using NSS. For Debian, the following flags are needed:

./configure --without-all --with-nss \
        --prefix=/ --sysconfdir=/etc/nut  \
        --with-statepath=/var/run/nut \
        --with-altpidpath=/var/run/nut \
        --with-drvpath=/lib/nut \
        --with-pidpath=/var/run/nut \
        --datadir=/usr/share/nut \
        --with-pkgconfig-dir=/usr/lib/pkgconfig \
        --with-user=nut --with-group=nut

• now compile and install:

$ make && make install

• refer to the documentation, NSS backend usage chapter, for detailed configuration and usage instructions.

• if you're looking for a nice user interface to manage your certificate, check Firefox Key Manager or Fedora nss-gui.

• Enjoy

Before concluding, here is the traditional thank you guys:

• Emilien Kia, who developed the NSS support in NUT,
• Fr d ric Boh , for the validation testing,
• Charles Lepple, for handling the merge from github to our Alioth Subversion repository,
• and Eaton for sponsoring this development.

As a conclusion, cryptography integration and usability is still not on par with other proprietary OS. I would love to see the crypto situation improving in Debian (and friends obviously). So this was just my 2 cents (nuts ;-)) to the cause... cheers,
-- Arno

I recently worked on the following systemd-related issues:

• #686115 - CanReload is set to yes unconditionally for legacy SysV services
  I wrote a patch which uses a heuristic to figure out whether a SysV init script supports the reload option or not. Not perfect, but a whole lot better than defaulting to "yes" :-). This should also fix #650382 - force-reload translated to reload for SysV services.
• #688635 - Don t kill libvirt VMs when restarting libvirt
  I ported a patch from the Fedora systemd packaging which avoids killing all processes of a cgroup when restarting a service. This is necessary for libvirtd, otherwise all virtual machines get killed when you restart libvirt-bin.service. libvirt-bin 0.10.2-4 (experimental) ships systemd service files.
• #635777 - 90-seconds delay on reboot/shutdown when postfix is installed
  I tracked down the cause of several 90-second delay on shutdown causes and provided a patch (which is a workaround ).
• #624599 - systemd: DHCP hook scripts calling invoke-rc.d causes boot hang
  I tracked down the cause of a deadlock at boot time when dhcp hooks call invoke-rc.d (as does samba). Several workarounds are known but we have not yet taken any action.

1. It is important to rehearse your space carefully. Find a quantity of friends equal to the attendees you expect, lay out the intended room, and check that everybody has free and easy access to their chair.
2. Invest in a decent access point and some power strips with a decent cord length.
3. Relax. I cannot stress enough the importance of this step!

---

Tips for a successful BSP is a post from: jwiltshire.org.uk Flattr

Rcpp release 0.9.15 is now on CRAN and being uploaded to Debian. Martin Morgan provided a clever fix for a header search needed between clang++ (especially on OS X) and g++ (which still provided libstdc++ and headers for clang++). This should hopefully put the clang issues to bed. Ben North noticed an unprotected string conversion when exception messages are turned into R errors which got fixed, and I expanded the coverage of Date (and Datetime) types to deal properly with non-finite values NA, NaN and Inf. The complete NEWS entry for 0.9.15 is below; more details are in the ChangeLog file in the package and on the Rcpp Changelog page.

Changes in Rcpp version 0.9.15 (2012-10-13)

• Untangling the clang++ build issue about the location of the exceptions header by directly checking for the include file an approach provided by Martin Morgan in a kindly contributed patch as unit tests for them.
• The Date and Datetime types now correctly handles NA, NaN and Inf representation; the Date type switched to an internal representation via double
• Added Date and Datetime unit tests for the new features
• An additional PROTECT was added for parsing exception messages before returning them to R, following a report by Ben North

Thanks to CRANberries, you can also look at a diff to the previous release 0.9.14. 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

Recently we did a bit of clean up of our git repositories and now thanks to roberto's efforts we have a new shiny git repository on the inria forge and two mailing lists to discuss development and user questions. If you are a user, or interested in dose development, please sign up to these mailing lists:

• dose-discus :http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/dose-discuss
• dose-devel : http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/dose-devel

if you already have a copy of the latest git repository, you can change the upstream repository issuing the following command : If you are curious, you can clone dose git clone git://gforge.inria.fr/dose/dose.git and let us know what you think about it. The API documentation is available here. The man pages or various applications developed on top of the dose library are available here. We are still actively working on the documentation and any contribution is very much welcome. I'm working on a nice homepage... You can get the latest tar ball release here : https://gforge.inria.fr/frs/?group_id=4395 Old releases will be left on the old forge.

Update And now we are even social ! follow us on identi.ca : http://identi.ca/group/dose3

My last post explained how I retrieved and corrected data from snapshot.debian.org so that dose3 was able to parse it. In this post I will cover some surprising results I found when using my tools on those Packages and Sources files from 2005 until today. For each pair of Packages and Sources files I did the following:

1. created a reduced distribution
2. calculated the dependency graph

I call a reduced distribution the smallest set of binary and source packages with the following properties:

• all source packages can be built with the available binary packages
• all binary packages are built from the available source packages

Creating a reduced distribution first, greatly increases the execution speed of my algorithms as it reduces the amount of binary and source packages by an order of magnitude while still preserving the dependency cycle situation of the core packages. In many cases, once the packages of a reduced distribution are available, all the rest of Debian can be compiled from them without any dependency cycles. As also mentioned in earlier posts, there is always one central, big strongly connected component (SCC) in the dependency graph. I am especially interested in how the size of the reduced distribution and the SCC change over time as both are an indication of:

• the amount of interdependencies between core packages
• the amount of dependency cycles in the dependency graph

Lets look at the plots I did from the data I gathered. The gray data points indicate that at that point in time, one or more of the core source packages (the ones in the reduced distribution) in Debian Sid was not compilable. This means that the resulting values cannot be fully trusted. But as it is mostly only a single source package that doesnt compile, it doesnt influence the overall result much and therefor I included them anyways. Red and green data points represent a fully successful run. The only thing that I do not yet understand is what happened in 2007... So while a potential porter in 2005 only had to look at a graph of 150 nodes, he now needs to solve a graph of nearly 1000 nodes. The amount of edges in the dependency graph grew even more dramatic from about 500 to over 8000 edges. While the dependency situation for Debian Sid in 2005 can easily be printed using xdot and visually solved, this in not possible anymore in 2012. While dependencies of only a few dozen source packages had to manually be dropped in 2005, now even dropping build dependencies from a few hundred source packages doesnt solve the dependency situation. So my assumption is, that due to a growing amount of interdependencies between source and binary packages (as both gain more features), bootstrapping Debian for a new architecture becomes harder over time. Is this also the perceived subjective impression of people that ported Debian in the past? If my assumption is correct, then there is a growing need for official support of droppable build dependencies (or "stage builds" or "profile builds") to break dependency cycles during the bootstrapping process. Work of a porter would be much easier if source packages would already contain information about what build dependencies can be dropped (if so needed). In the best case, a machine could use those annotations to calculate a build order automatically. As one can see in the graph above, there are currently 370 source packages in the main SCC. This means that no more than this amount of packages (but probably much less) have to be annotated to break the SCC into a directed acyclic graph. Discussion about what syntax to use to mark potentially droppable build dependencies currently happens in bug#661538 but should maybe be discussed by a wider audience. The currently favored solution was proposed in said bugreport by Guillem Jover and is called "build profiles". It has the advantage that it is not only trivial to implement (a patch exist for dpkg and dose3 already supports them) but would also be useful for other purposes like embedded builds. The format is similar to how architecture restrictions for individual dependencies are specified but uses "triangular brackets":

Build-Depends: huge (>= 1.0) [i386 arm] <!embedded !bootstrap>, tiny

The work Patrick McDermott did for his GSoC project over the summer already uses above syntax.

Update for 06/10/2012 Well I had not written the weekly work log for the last week that is because the week was short (oh yeah thanks to all these bandhs our week got fluctuated and to be frank the week was only 4 days long) and second was my lazyness. Here goes the update * After a long discussion with Aravinda on "why productivity is reducing these days." We concluded the social network is eating up most of time. So decision was made and I closed all pinned tabs for Twitter Gmail Identi.ca and Friendica on my browser * After the above resolution I finished almost 4 chapters of Moder Perl within 2 hours!. Indeed Social networks kill the productivity. Update for 13/10/2012 I've really fallen in love with computerised bots, thanks to the wonderful KGB bot :-). So majority of my work on this week is on bots. Jabber Dictionary Redesign After thinking for a while I decided to re-write the dictionary bot which when release got an overwhelming response as see in the comments of above link. Few reason for re-write

1. Generalise the bot framework so single bot can handle multiple languages
2. Improve the data collection on bot side
3. Current code base was not very well organised and trying to add more feature it had become messy.
4. Provide XEP support to help in data collections

Few changes which are already implemented include

1. New code is now using pyxmpp2 library instead of GPLed xmppy used by current code.
2. Implemented XEP-0071 extension to properly format the meaning display by the bot
3. Current implementation was displaying all words in one set without distinguishing between adjectives,verbs proverbs etc. even though wiktionary displays meaning based on this. New implementation gives out meaning in same format as it is displayed on wiktionary.

Things remaining todo

1. Separating wiktionary parsing logic from bot code by providing some sort of intermediate interface between bot and wiktionary parsers.
2. Adding more language wiktionary parsers and teaching the bot to become multilingual :-)
3. Integrating XEP-0004 (Data Forms) for taking the meaning input from user. Current code requires user to enter data in particular format

suckless-tools fix for Wheezy Jakub Wilk suggested me to prepare a minimal version of suckless-tools for Wheezy which includes a patch to the bug #685611. And few minor changes which involve taking over the package and fixes in copyright file other than above mentioned bug. Hopefully release-team will be okay with these changes. I'm waiting for the upload to file an unblock-request. I did face a problem I was halfway through wit suckless-tools_39-1 when Jakub asked me about this change and current repository was fresh one prepared for 39-1 and didn't have history for 38 version. First I thought of preparing separate repository for 38 version which was not an correct option, but I even couldn't play with current repository. So finally I renamed current version of repository to suckless-tools-39.git on collab-maint and prepared fresh repository suckless-tools.git basing it on 38-1 version. From 39 version suckless-tools will be following 3.0 (quilt) source format and will not be working with git-buildpackage as the tool can't handle multi-tarball packages. Yes every tool involved in the package will have separate tarball from 39. More work on Bots Well today I again worked on Jabber bot, but not the dictionary bot. This time its an SMS Gateway bot for Jonas Smedegard and the coding was done in Perl. Thanks to jonas I finally could apply what I learnt in Perl. Code may not be very elegant but it works :-). And after hacking one full day in Perl now I'm not feeling very much interested to go back and hack on my own Python based dictionary bot :-). But I will anyway. Misc

• fonts-kalapi has been uploaded to unstable by Kartik finally :-). Only sad part is he couldn't use the home grown dh-make-font for this purpose.
• Finally Kartik is here in Bangalore and I'm just waiting when I can meet him.
• I ordered a RaspberryPi once it comes some hacking will be done on boxer again :-)
• Watched couple of Star Wars movie :-) (Still have 4 left)
• Expendables 2 movie is in watch list after this post.

So that's it folks. Quite longish post hope you are not bored reading it :-). Well time for movie C'ya all with next weeks log.

There may be a situation where you want to create a Debian source package without having to unpack the upstream source. One case is where you store your debian/ directory in a version control system of its own and to build your package, you pass the .dsc file to a tool like pbuilder or some remote builder. Now a modern debian source package is just a text file (the .dsc file) that references two tarballs, one being the upstream source and the other being the Debian directory. Thanks to Niels Thykier on #debian, I found the magic invocation of dpkg-source that allows you to create the .dsc directly from the two tarballs, the control file and the changelog:

> apt-get source --download-only -t experimental haskell-mtl
Reading package lists... Done
Building dependency tree       
Reading state information... Done
NOTICE: 'haskell-mtl' packaging is maintained in the 'Darcs' version control system at:
http://darcs.debian.org/darcs/pkg-haskell/haskell-mtl
Need to get 18.8 kB of source archives.
Get:1 http://http.debian.net/debian/ experimental/main haskell-mtl 2.1.2-1 (dsc) [1616 B]
Get:2 http://http.debian.net/debian/ experimental/main haskell-mtl 2.1.2-1 (tar) [13.7 kB]
Get:3 http://http.debian.net/debian/ experimental/main haskell-mtl 2.1.2-1 (diff) [3509 B]
Fetched 18.8 kB in 0s (22.3 kB/s)    
Download complete and in download only mode
> cp ./haskell-mtl_2.1.2-1.dsc ./haskell-mtl_2.1.2-1.dsc-orig
> tar xzf haskell-mtl_2.1.2-1.debian.tar.gz
> dpkg-source -cdebian/control -ldebian/changelog --format="3.0 (custom)" --target-format="3.0 (quilt)" -b / haskell-mtl_2.1.2.orig.tar.gz haskell-mtl_2.1.2-1.debian.tar.gz
dpkg-source: info: using source format  3.0 (custom)'
dpkg-source: info: building haskell-mtl in haskell-mtl_2.1.2-1.dsc
> diff  -u haskell-mtl_2.1.2-1.dsc haskell-mtl_2.1.2-1.dsc-orig
--- haskell-mtl_2.1.2-1.dsc	2012-10-13 15:09:00.031695856 +0200
+++ haskell-mtl_2.1.2-1.dsc-orig	2012-10-13 15:08:47.267696329 +0200
@@ -1,3 +1,6 @@
+-----BEGIN PGP SIGNED MESSAGE-----
+Hash: SHA1
+
 Format: 3.0 (quilt)
 Source: haskell-mtl
 Binary: libghc-mtl-dev, libghc-mtl-prof, libghc-mtl-doc
@@ -23,3 +26,11 @@
 Files: 
  943c110524d96126bfa0e61f7df1ebcd 13723 haskell-mtl_2.1.2.orig.tar.gz
  dda5ded58a8d009ecddeed68058ca787 3509 haskell-mtl_2.1.2-1.debian.tar.gz
+
+-----BEGIN PGP SIGNATURE-----
+Version: GnuPG v1.4.12 (GNU/Linux)
+
+iEYEARECAAYFAlBzRQIACgkQ9ijrk0dDIGwymwCfW87jwCv5ZvAXPBwh0LbvYLP9
+n+wAn3TCJwPRuBDEWRYmcv3Opn1Kb9+F
+=/Llc
+-----END PGP SIGNATURE-----

As you can see, the resulting .dsc file is identical to the original one, so this approach works. The parameter to -b does not matter as long as it is some existing directory. Of course you can easily shoot yourself and others in the foot, almost as easily as hand-editing the .dsc file... but if you know what you are doing, then this can be quite handy. Next to do: Write a tool that takes an unpacked Debian directory as an argument, packs it, finds the original tarball using uscan and creates the .dsc file. Would this be something that people would want in the devscripts package?

Interactively installing Debian virtual machines with virt-install without having to download anything in advance can already be done by pointing it to a Debian mirror via --location. But you can also add files to the initrd after downloading using --initrd-inject. Upstreams intended use is for kickstart files but we can also feed it a preseed.cfg to automate the whole installation:

virt-install --connect=qemu:///system \
             --location=http://ftp.us.debian.org/debian/dists/stable/main/installer\-i386 \
             --initrd-inject=/path/to/preseed.cfg \
             --extra-args="auto" \
             --name d-i --ram=512 \
             --disk=pool=default,size=5,format=qcow2,bus=virtio

preseed.cfg is a regular preseed file (as described in the Debian Wiki) in your local filesystem. I'm using this one for Squeeze and Wheezy VMs. It must be named preseed.cfg in order for d-i to pick it up from the initrd. This also works for URLs like qemu+ssh://<remotehost>/system/ since virt-install uses libvirt's streaming API to upload the kernel and modified initrd to the remote host. In case you're running this on an i386 you'll need this fix which already sits in experimental. This blog is flattr enabled.

Software

I've been using redis for a while now. It is a fast in-memory storage system which offers persistence (unlike memcached), as well as several primitive data-types such as lists & hashes. Anyway it crossed my mind that I don't have a backup of the data it contains, so I knocked up a simple script to dump the contents in plain-text:

• redis-dump

In other software-news I've had some interesting and useful feedback and made two new releases of my slaughter sysadmin tool - it now contains a wee test suite and more robustness.

Hardware

I received an email last night to say that my Raspberry PI has shipped. Ordered 24/05/2012, and dispatched 12/10/2012 - I'd almost forgotten about it. My plan is to make it a media-serving machine, SNES emulator, or similar. Not 100% decided yet. Finally I've taken the time to repaint my office. When I last wrote about working from home I didn't include pictures - I just described the process of using a "work computer" and a "personal computer". So this is what my office used to look like. As you can see there are two machines and a huge desk. With a few changes I now have an office which looks like this - the two machines are glued-together with a KVM. and I have much more room behind it for another desk, more books, and similar toys. Additionally my dedication is now enforced - I simply cannot play with both computer as the same time. The chair was used to mount the picture - usually I sit on a kneeling chair, which is almost visible. What inspired the painting? Partly the need for more space, but mostly water damage. I had a leaking ceiling. (Local people will know all about my horrible leaking roof situation).

The end?

I ve just downloaded and installed the Debian AMD64 package of the Google Apache Pagespeed module [1]. To see if it worked I used the Google PageSpeed insights tool which gave my blog a rating of 93% (and 88% for mobile) [2]. After installing mod_pagespeed I received the same scores. So it appears that Pagespeed isn t doing any good according to Google s analysis! etbe.coker.com.au 10.11.12.13 - [13/Oct/2012:05:22:31 +0000] "GET /wp-content/plugins/openid/f/W.openid.css,qver=519.pagespeed.cf.Bbu1gxRjUE.css HTTP/1.0" 200 2165 "http://etbe.coker.com.au/" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.1 (KHTML, like Gecko) Chrome/21.0.1180.89 Safari/537.1" 0
etbe.coker.com.au 10.11.12.13 - [13/Oct/2012:05:22:31 +0000] "GET /wp-content/themes/atahualpa/js/DD_roundies.js,qver=0.0.2a.pagespeed.jm.4gw5yluag0.js HTTP/1.0" 200 3679 "http://etbe.coker.com.au/" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.1 (KHTML, like Gecko) Chrome/21.0.1180.89 Safari/537.1" 0
etbe.coker.com.au 10.11.12.13 - [13/Oct/2012:05:22:31 +0000] "GET /wp-includes/js/jquery/jquery.js,qver=1.7.2.pagespeed.jm.XZwfunyK-6.js HTTP/1.0" 200 33587 "http://etbe.coker.com.au/" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.1 (KHTML, like Gecko) Chrome/21.0.1180.89 Safari/537.1" 0
etbe.coker.com.au 10.11.12.13 - [13/Oct/2012:05:22:33 +0000] "GET /wp-content/themes/atahualpa/images/xlogo.png.pagespeed.ic.ICWmaHBME5.png HTTP/1.0" 200 2267 "http://etbe.coker.com.au/" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.1 (KHTML, like Gecko) Chrome/21.0.1180.89 Safari/537.1" 0 The above sample of web logs shows that the string pagespeed is appended to some URLs with a hash of the file contents which apparently allows much longer cache times without making it difficult to change content. So Pagespeed is obviously doing something. Is Google analysis expected to say that there is no change? Note that my speed scores are 93% and 88% so my site is was apparently quite good before mod_pagespeed was installed maybe the analysis would report a difference on a site that didn t perform so well. Now even if mod_pagespeed has given a benefit to real users but not Google tests it still means that I won t get the SEO benefits that Google apparently gives to fast sites. Also to make things even more exciting the W3.org HTML validator [3] now says that there s an error in my blog. So not only has mod_pagespeed failed to improve performance in a way that Google notices but it has also broken something!

• [1] https://developers.google.com/speed/pagespeed/mod
• [2] https://developers.google.com/speed/pagespeed/insights#url=etbe.coker.com.au&mobile=false
• [3] http://validator.w3.org/

Related posts:

1. More About Google Earth I recently wrote about problems with Google Earth [1]. In...
2. A Strange Attempt to Trick Google I just noticed that my post about LED Headlights in...
3. google-bank Currently many people have Google advertising on their web sites,...

deb http://www.coker.com.au wheezy wordpress I maintain Debian packages of a number of WordPress themes and plugins for my personal use which I am not planning to upload to Debian due to the maintenance and security issues. Generally the way things work with WordPress packages (and apparently most things in PHP) is that new versions are released whenever the author feels like it with little documentation and often now way of determining whether it s a security issue. When there is a security issue it s often fixed in a new version that includes new features giving no good option for someone who was happy with the old functionality and just wants a secure system. This isn t the way we like to do things in Debian. The result of this is that I maintain a number of packages for my personal use (and for the benefit of any interested people on the Internet) that often get new updates. I ve written the below script to create a new version of a Debian package. It searches my repository for the most recent .debian.tar.gz file for the package, applies that, runs dch -i to update the changelog, and then builds the package. So far this has only been tested on one package, I expect that I ll have to put a sed command in there to cover the case where the zip file name doesn t match what I want as the package name and I ll probably find other bugs in future, but I think it s good enough to publish now. #!/bin/bash
set -e
REPOSITORY=/home/whatever
unzip $1
FILE=$(basename $1)
PACKAGE=$(echo $FILE sed -e "s/\..*$//")
LEN=$(($(echo $PACKAGE wc -c)+1))
VER=$(echo $FILE cut -c $ LEN -200 sed -e s/.zip//)
DIRNAME=wordpress-$ PACKAGE -$ VER
mv $PACKAGE $DIRNAME
tar czf wordpress-$ PACKAGE _$ VER .orig.tar.gz $ DIRNAME
cd $DIRNAME
tar xzf $(ls -tr $ REPOSITORY /wordpress-$ PACKAGE _*.debian.tar.gz tail -1)
dch -i
dpkg-buildpackage Any suggestions for improvement will be welcome, I don t claim to be the world s greatest shell scripter. But please note that I generally aim to write shell scripts that can be understood by people who aren t experts. So if you can replace the program with a single line of Perl I will be impressed but I won t implement your solution. Related posts:

1. WordPress Maintainability For a while I ve been maintaining my own WordPress packages....
2. permalinks in wordpress, Apache redirection, and other blog stuff When I first put my new blog online I didn t...
3. WordPress Plugins I ve just added the WordPress Minify [1] plugin to my...

Thanks to a blog post by Eddy Petri or, I became aware of yet another "alternative medicine" company using legal intimidation tactics to scare off critics. According to the originating blog post about the detox "cure" ColonHelp and its producers Zenyth Pharmaceuticals actions, the producer sues Wordpress to get rid of the critical information. To check if the story was for real, I contacted Automattic, the company behind wordpress.com, and they reply was "We can confirm that Zenyth is seeking a court order against WordPress / Automattic. However, we don't believe the Terms of Service have been violated in this matter". The story seem to be simply that a blogger checked the scientific foundation for a popular health product in Rumania, ColonHelp, and reported that there was no reason at all to believe it improved the health of its users. This caused the company behind the product, Zenyth Pharmaceuticals, to use legal intimidation to try to silence the critic, instead of presenting its views and scientific foundation to argue its side. This is the usual story, and the Zenyth Pharmaceuticals company deserve everyone to know how it failed to act properly. Lets hope the Streisand effect can make it rethink its strategy. What is the harm, you might think. I suggest you take a look at a list of victims of detoxification.

When I wanted to use my dependency graph analysis tools to analyze earlier states of Debian Sid, I naturally used snapshot.debian.org to retrieve the Packages and Sources files from which my tools retrieve the dependency information. The problem is, that many of those Packages and Sources files contain syntax errors that make the dose3 parser choke. This leads to my tools being unable to parse the affected files. The following script does not only download all Packages and Sources files in a five day interval (4460 MB from 2005/03/12 to 2012/10/11) but also cleans all the syntax errors that were not parsable by dose3. This includes invalid version naming, architecture lists separated by commas, disjunctions in Conflict fields and incorrect braces/bracket usage. Maybe this helps others who also want to profit from Packages and Sources files from the past. Fun fact #1: starting from June 2010, there were no more syntax errors in the Packages and Sources files of Debian Sid. Fun fact #2: starting from December 2009, there are no more mismatches between versions of binary packages in the Packages file and the versions of the corresponding source packages in the Sources file. <script src="https://gist.github.com/3880904.js"> </script>

After 6 months of development, we are proud to release the first release of Ceilometer, the OpenStack Metering project. Ceilometer. This is a first and amazing milestone for us: we follow all other projects by releasing a version for Folsom! Using Ceilometer, you should now be able to meter your OpenStack cloud and retrieve its usage to build statistics or bill your customer! You can read our announcement on the OpenStack mailing list. Architecture We spent a good amount of time defining and refining our architecture. One of its important point, is that it has been designed to work without modifying any of the existing core components. Patching OpenStack components in an intrusive way to meter them was not an option for now, simply because we had no legitimacy to do so. This may change in the future, and this will likely be discussed next week during the OpenStack Summit. Meters Initially, we defined a bunch of meters we'd like to have for a first release, and in the end, most of them are available. Some of them are still missing, like OpenStack Object Storage (Swift) ones, mainly due to lack of interest from the involved parties so far. Anyhow, with this first release, you should be able to meter your instances, their network usage, memory, CPU. Images, networks and volumes and their CRUD operations are metered too. For more detail, you can read the complete list of implemented meters. REST API The HTTP REST API has been partially implemented. The provided methods should allow basic integration with a billing system. DreamHost is using Ceilometer in their deployment architecture and coupling it with their billing system! Towards Grizzly We don't have a clear and established road-map for Grizzly yet. We already have a couple of patches waiting in the queue to be merged, like the use of Keystone to authenticate API request and the removal of Nova DB access. On my side, these last days I've been working on a small debug user interface for the API. Ceilometer API server will return this interface if your do an API request from a browser (i.e. requesting text/html instead of application/json). I hope this will help to discover Ceilometer API more easily for new comers and leverage it to build powerful tools! Anyhow, we have tons of idea and work to do, and I'm sure the upcoming weeks will be very interesting. Also, we hope to be able to become an OpenStack incubated project soon. So stay tuned!