A new minor release 5.100.1 of Armadillo was released by Conrad yesterday. Armadillo is a powerful and expressive C++ template library for linear algebra aiming towards a good balance between speed and ease of use with a syntax deliberately close to a Matlab. Our corresponding RcppArmadillo release 0.5.100.1.0 also reached CRAN and Debian yesterday. See below for the brief list of changes.

Changes in RcppArmadillo version 0.5.100.1.0 (2015-05-01)

• Upgraded to Armadillo release 5.100.1 ("Ankle Biter Deluxe")
  • added interp1() for 1D interpolation
  • added .is_sorted() for checking whether a vector or matrix has sorted elements
  • updated physical constants to NIST 2010 CODATA values

Courtesy of CRANberries, there is also a diffstat report for the most recent CRAN release. As always, more detailed information is on the RcppArmadillo page. Questions, comments etc should go to the rcpp-devel mailing list off the R-Forge page.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

It was quite an experience to partake in the Jessie release and also a rather long Saturday . This post is mostly a time line of how I spent my release day with doing the actual release. I have glossed over some details the post is long enough without these. :) We started out at 8 (UTC) with a final dinstall run, which took nearly 2 hours. It was going to take longer, but we decided to skip the synchronisation to coccia.debian.org (the server hosting the DD-accessible mirror of release.debian.org). The release itself started with the FTP masters renaming the aliases of Squeeze, Wheezy and Jessie to oldoldstable, oldstable and stable respectively. While they worked, the release team reviewed and double checked their work. After an hour (~11), the FTP masters reported that the stable releases were ready for the final review and the SRMs signed the relevant Release files. Then the FTP masters pushed the stable releases to our CD build server, where Steve McIntyre started building the installation images. While Steve started with the CDs, the FTP masters and the release team continued with creating a suite for Stretch. On the FTP/release side, we finished shortly before 12:30. At this point, our last ETA from Steve suggested that the installation media would take another 11 and a half hours to complete. We could have opened for mirror synchronisation then, but we decided to wait for the installation media. At 12:30, there was a long intermission for the release team in the release process. That was an excellent time to improve some of our tools, but that is for another post. :) We slowly started to resume around 22:20, where we tried to figure out when to open for the mirror synchronisation to time it with the installation media. We agreed to start the mirror sync at 23:00 despite the installation media not being completely done then. They followed half an hour later, when Steve reported that the last CD was complete. At this point, all that was left was to update the website and send out the press announcement. Sadly, we were hit by some (minor) issues then. First, I had underestimated the work involved in updating the website. Secondly, we had no one online at the time to trigger an out of band rebuild of the website. Steve and I spent an hour and a half solving website issues (like arm64 and ppc64el not being listed as a part of the release). Unsurprisingly, I decided to expand our the release checklist to be slightly more verbose on this particular topic. My Saturday had passed its 16th hour, when I thought we had fixed all the website issues (of course, I would be wrong) and we would now just be waiting for the an automatic rebuild. I was tempted to just punt it and go to bed, when Paul Wise rejoined us at about 01:25. He quickly got up to speed and offered to take care of the rest. An offer I thankfully accepted and I checked out 15 minutes later at 01:40 UTC. That more or less covers the Jessie release day from my PoV. After a bit of reflection inside the release team, we have found several points where we can improve the process. This part certainly deserves its own post as well, which will also give us some time to flesh out some of the ideas a bit more. :)
Filed under: Debian, Release-Team

I just took a few minutes to write up my preferred Debian packaging practices. The basic gist is that i like to use git-buildpackage (gbp) with the upstream source included in the repo, both as tarballs (with pristine-tar branches) and including upstream's native VCS history (Joey's arguments about syncing with upstream git are worth reading if you're not already convinced this is a good idea). I also started using gbp-pq recently -- the patch-queue feature is really useful for at least three things:

• rebasing your debian/patches/ files when a new version comes out upstream -- you can use all your normal git rebase habits! and
• facilitating sending patches upstream, hopefully reducing the divergence, and
• cherry-picking new as-yet-unreleased upstream bugfix patches into a debian release.

My preferred packaging practices document is a work in progress. I'd love to improve it. If you have suggestions, please let me know. Also, if you've written up your own preferred packaging practices, send me a link! I'm hoping to share and learn tips and tricks around this kind of workflow at debconf 15 this year. Tags: git, git-buildpackage, packaging

Many years ago, a friend of mine calculated how much it would cost to store the sound of all phone calls in Norway, and came up with the cost of around 20 million NOK (2.4 mill EUR) for all the calls in a year. I got curious and wondered what the same calculation would look like today. To do so one need an idea of how much data storage is needed for each minute of sound, how many minutes all the calls in Norway sums up to, and the cost of data storage. The 2005 numbers are from digi.no, the 2012 numbers are from a NKOM report, and I got the 2013 numbers after asking NKOM via email. I was told the numbers for 2014 will be presented May 20th, and decided not to wait for those, as I doubt they will be very different from the numbers from 2013. The amount of data storage per minute sound depend on the wanted quality, and for phone calls it is generally believed that 8 Kbit/s is enough. See for example a summary on voice quality from Cisco for some alternatives. 8 Kbit/s is 60 Kbytes/min, and this can be multiplied with the number of call minutes to get the storage requirements. Storage prices varies a lot, depending on speed, backup strategies, availability requirements etc. But a simple way to calculate can be to use the price of a TiB-disk (around 1000 NOK / 120 EUR) and double it to take space, power and redundancy into account. It could be much higher with high speed and good redundancy requirements. But back to the question, What would it cost to store all phone calls in Norway? Not much. Here is a small table showing the estimated cost, which is within the budget constraint of most medium and large organisations:

Year	Call minutes	Size	Price in NOK / EUR
2005	24 000 000 000	1.3 PiB	3 mill / 358 000
2012	18 000 000 000	1.0 PiB	2.2 mill / 262 000
2013	17 000 000 000	950 TiB	2.1 mill / 250 000

This is the cost of buying the storage. Maintenance need to be taken into account too, but calculating that is left as an exercise for the reader. But it is obvious to me from those numbers that recording the sound of all phone calls in Norway is not going to be stopped because it is too expensive. I wonder if someone already is collecting the data?

Hi everyone! As you might know Qt4 has been deprecated (in the sense "you better start to port your code") since Qt5's first release in December 19th 2012. Since that point on Qt4 received only bugfixes. Upstream is about to release the last point release, 4.8.7. This means that only severe bugs like security ones will get a chance to get solved.

Moreover upstream recommended keeping Qt4 until 2017. If we get a Debian release every 2 years that will make Jessie oldstable in 2017 and deprecated in 2018. This means we should really consider starting to port code using Qt4 to Qt5 during Stretch's developing life cycle.

It is important to note that Qt4 depends on a number of dependencies that their maintainers might want to get removed from the archive for similar reasons. In this case we will simply don't hesitate in removing their support as long as Qt4 keeps building. This normally doesn't mean API/ABI breakage but missing plugins that will diminish functionality from your apps, maybe even key ones. As an example let's take the **hypothetical** case in which the libasound2 maintainers are switching to a new libasound3 which is not API-compatible and removing libasound2 in the process. In this case we will have no choice but to remove the dependency and drop the functionality it provides. This is another of the important reasons why you should be switching to Qt5.

Qt4's webkit removalWebkit is definitely not an easy piece of code to maintain. For starters it means having a full copy of the code in the archive for both Qt4 and Qt5. Now add to that the fact that the code evolves quickly and thus having upstream support even for security bugs will be getting harder and harder. So we decided to remove Qt4's webkit from the archive. Of course we still have a lot of KDE stuff using Qt4's webkit, so it won't disappear "soon", but it will at some point.

PortingSome of us where involved in various Qt4 to Qt5 migrations [0] and we know for sure that porting stuff from Qt4 to Qt5 is much much easier and less painful than it was from Qt3 to Qt4.

We also understand that there is still a lot of software still using Qt4. In order to ease the transition time we have provided Wheezy backports for Qt5.

Don't forget to take a look at the C++ API changes page [1] whenever you start porting your application.

[0] http://pkg-kde.alioth.debian.org/packagingqtstuff.html
[1] http://doc.qt.io/qt-5/sourcebreaks.html

Temporarily shipping both Qt4 and Qt5 builds of your libraryIn case you maintain a library chances are that upstream already provides a way to build it using Qt5. Please note there is no point in shipping an application built with both flavours, please use Qt5 whenever possible. This double compilation should be left only for libraries.

You can't mix Qt4 and Qt5 in the same binary, but you may provide libraries compiled against one or the other. For example, your source package foo could provide both libqt4foo1 and libqt5foo1. You need to mangle your debian/rules and/or build system accordingly to achieve this.

A good example both for upstream code allowing both styles of compilation and debian packaging is phonon. Take a look at the CMakeLists.txt files for seeing how a source can be built against both flavours and another to debian/rules to see an example of how to handle the compilation. Just bear in mind that you
need to replace $(overridden_command) with the command itself, that variable substitution comes from internal stuff from our team and you should not be using it without a very good reason. If in doubt, feel free to ask us on IRC [2] or on the mailing list [3].

[2] irc.debian.org #debian-kde
[3] debian-kde@lists.debian.org

TimelineWe plan to start filing wishlist bugs soon. Once we get most of KDE stuff running with Qt5's webkit we will start raising the severities.

It has been recently discussed in Debian-Women and Debian-Games mailing lists, but for all of you who don t read those mailing lists and might have kids or use free games with kids in the classroom, or stuff like that, I thought it might be good to talk about it here. SuperTuxKart is a free 3D kart racing game, similar to Mario Kart, with a focus on having fun over realism. The characters in the game are the mascots of free and open source projects, except for Nolok, who does not represent a particular open source project, but was created by the SuperTux Game Team as the enemy of Tux. On April 21, 2015, version 0.9 (not yet in Debian) was released which used the Antarctica graphics engine (a derivative of Irrlicht) and enabled better graphics appearance and features such as dynamic lighting, ambient occlusion, depth of field, and global illumination. Along with this new engine comes a poster with a sexualized white woman is wearing an outfit that can be depicted as a mix of Native american clothes from different nation and a halo of feathers, as well as many models of her in a bikini swim suit, all along the game, even in the hall of the airport. They say an image is worth more than a thousand words, don t they?

The Machine Architecture Here's a brief introduction to some of the hardware concepts within The Machine. As the team at HP that I'm working with are busy working on Linux kernel changes motivated by the hardware, I'm hoping that providing this kind of documentation will help Linux kernel developers outside of HP evaluate that work, and work by others in related areas. Joining HP and learning about The Machine In January, I joined HP to work on Linux for The Machine. I'd watched Martin Fink's video and read other articles on the new hardware coming out of HP labs. I had hints of what they were up to, and the possibilities seemed exciting enough to entice me to go back to HP. When I arrived at HP, one of the first things I got to read was the external reference specification for The Machine. 170 pages detailing a more significant shift in computer architecture than I had been given any hints of, both in my interviews at HP and from what I could see in the press. Since then, I've been eager to tell people about what we're doing, and I'm happy to say that we're finally ready to start the conversation with this brief description. A Short Outline of Storage within The Machine The basic unit of The Machine is a collection of hardware grouped in a Load Store Domain. A Load Store Domain consists of:

• Multiple independent Compute Nodes
  • Independent operating systems
  • Local memory
  • Load/store access to shared, in-memory storage
• Shared byte-addressable persistent memory:
  • Non-volatile wrt operating system life cycle
  • Global address space
  • Hardware access control
  • Accessed with standard CPU load/store instructions

Here's a diagram of how the various bits of the hardware are hooked together: And, a brief description of the elements within the picture:

• Compute Node. A set of processing cores, caches and various ancillary peripherals.
• Local Store. Memory directly connected to the processing cores.
• Firewall. Hardware access control between the compute node and shared memory.
• Shared Byte-addressable Persistent Memory. This is the storage within The Machine. It is accessed directly via normal CPU load/store instructions in units as small as one byte.

I've intentionally drawn the shared memory in a large box to emphasize the notion that this machine is more "memory-centric" and less "processor-centric". The shared byte-addressable persistent memory forms the sole persistent storage within The Machine. More to Come I'll continue to publish information about The Machine and our related Linux work as we work on the hardware and software.

Yesterday I permanently deleted 15 years of email. It wasn't because I didn't have enough hard disk space to store it. It's because I decided, after 15 years, that the benefits of keeping all this email did not outweigh the risks. Although I have never had my email subpoenaed, I have had many legal interactions due to my involvement with May First/People Link, some of which were about finding the real identities of May First/People Link members. I'd rather not risk compromising anyone or needlessly exposing my networks. Now I have an Inbox, Sent Box, Trash Box and Detected Spam Box. The Inbox I empty manually and the other boxes are automatically purged on a scheduled basis. In this age of surveillance it's sad to see data evaluated based on risk of exposure.

Some time ago I have embarked on a jurney to install NetBSD on one of my two NSLU2-s. I have ran into all sorts of hurdles and problems which I finally managed to overcome, except one:

The NSLU I am using has a standard 20 pin ARM JTAG connector attached to it (as per this page http://www.nslu2-linux.org/wiki/Info/PinoutOfJTAGPort, only TDI, TDO, TMS, TCK, Vref and GND signals), but, although the chip is identified, I am unable to halt the CPU:
My main goal is to make sure I can flash the device via JTAG, in case I break it, but it would be ideal if I could use the JTAG to single step through the code.

I have found that other people have managed to flash the device via JTAG without the other signals, and some have even changed the bootloader (and had JTAG confirmed as backup solution), so I am stuck.

So if anyone can give some insights into ixp42x / Xscale / NSLU2 specific JTAG issues or hints regarding this issue on OpenOCD or other such tool, I would be really grateful.


Note: I have made a hacked second stage Apex bootloader to laod the NetBSD image via TFTP, but the default RedBoot sequence 'boot; exec 0x01d00000' should be 'boot; go 0x01d00000' for NetBSD to work, so I am considering changing the RedBoot partition to alter that command. The gory details can be summed as my Apex is calling RedBoot functions to be network enabled (because Intel's NPE current code is not working on Apex) and I have tested this to work with go, but not with exec.

A hotfix release for the Finance-YahooQuote Perl module on CPAN is now available. Available Yahoo! Finance decided to change the base URL. My thanks to Nicola Chiapolini who not only noticed but also sent me the one-line patch fixing this:

--- YahooQuote.pm~      2010-03-27 01:44:10.000000000 +0100
+++ YahooQuote.pm       2015-04-29 11:31:20.407926674 +0200
@@ -34,7 +34,7 @@
 $VERSION = '0.24';
 
 ## these variables govern what type of quote the modules is retrieving
-$QURLbase = "http://download.finance.yahoo.com/d/quotes.csvr?e=.csv&f=";
+$QURLbase = "http://download.finance.yahoo.com/d/quotes.csv?e=.csv&f=";
 $QURLformat = "snl1d1t1c1p2va2bapomwerr1dyj1x";        # default up to 0.19
 $QURLextended = "s7t8e7e8e9r6r7r5b4p6p5j4m3m4";        # new in 0.20
 $QURLrealtime = "b2b3k2k1c6m2j3"; # also new in 0.20

If need be, edit your file YahooQuote.pm by hand. This change in Finance-YahooQuote will also affect Beancounter and smtm both of which use this module. The fix has been pushed to Debian for the corresponding package and to PAUSE for CPAN package. Having maintained this since 2002 in RCS, I also just created a GitHub repo for it where development/maintenance will now happen.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

A small project I worked on during the last few weeks has now come together in new package RcppTOML which arrived on CRAN yesterday. It provides R with a reader for TOML files. TOML stands for Tom's Obvious Markup Language. And before you roll your eyes, glance at the TOML site. It really is different, and has a number of rather wonderful features:

• free-format indentation as you please
• comments anywhere, even on the same line
• actual types such as string, integer, float, bool and datetime (!!) which are all native
• vectors, of course, of the above
• arbitrary nesting of tables

Here is a simple illustration where we parse the TOML example file derived from what is part of the main TOML README

R> p <- parseTOML(system.file("toml", "example.toml", package="RcppTOML"))
R> summary(p)
toml object with top-level slots:
   clients, database, owner, servers, title 
read from /usr/local/lib/R/site-library/RcppTOML/toml/example.toml 
R> p
List of 5
 $ clients :List of 2
  ..$ data :List of 2
  .. ..$ : chr [1:2] "gamma" "delta"
  .. ..$ : int [1:2] 1 2
  ..$ hosts: chr [1:2] "alpha" "omega"
 $ database:List of 4
  ..$ connection_max: int 5000
  ..$ enabled       : logi TRUE
  ..$ ports         : int [1:3] 8001 8001 8002
  ..$ server        : chr "192.168.1.1"
 $ owner   :List of 4
  ..$ bio         : chr "GitHub Cofounder & CEO\\nLikes tater tots and beer."
  ..$ dob         : POSIXct[1:1], format: "1979-05-27 07:32:00"
  ..$ name        : chr "Tom Preston-Werner"
  ..$ organization: chr "GitHub"
 $ servers :List of 2
  ..$ alpha:List of 2
  .. ..$ dc: chr "eqdc10"
  .. ..$ ip: chr "10.0.0.1"
  ..$ beta :List of 2
  .. ..$ dc: chr "eqdc10"
  .. ..$ ip: chr "10.0.0.2"
 $ title   : chr "TOML Example"
NULL
R> 

See much more at the TOML site. I converted one first project at work to this and it really rocks. Point to a file, get a list back and index all components by their names. We also added really simple S3 classes to the default print() method uses str() for a more compact presentation of what (in R) is of course nested list types. Internally, the RcppTOML packages use the splendid cpptoml parser by Chase Geigle. This brings in modern C++11 and makes it that CRAN simply cannot build a binary for R on Windows as the g++ version (still, as of April 2015) in Rtools is too old. There is word of an update to Rtools and that point should we able to support Windows as well. Until then, no mas. A bit more information is on the package page here as well as as the GitHub repo.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

For working with Debian packages, one method of maintaining them is to put them in git and use git-buildpackage to build them right out of the git repository. There are a few pitfalls with it, notably around if you forget to import the upstream you get this strange treeish related error which still throws me at first when I see it. Part of maintaining packages is to be able to fix security bugs in older versions of them that are found in stable and even sometimes old stable (jessie and wheezy respectively at the time of writing). At first I used to do this outside git because to me there wasn t a clear way of doing it within it. This is not too satisfactory because it means you lose the benefits of using git in the first place, and for distributions you are more likely to need collaboration with, such as working with the security team or help with backporting. So because I don t think the details are easily found and also I ll probably lose them again and need a central spot to find what I did last time. Building the environment The first step for a new distribution is to create the building environment. You really only need to do this once when there is a new distribution with then possibly some updates from time to time. The command will create the environment in /var/cache/pbuilder/base-DIST.cow/

DIST=wheezy git-pbuilder create

You will find all the files in /var/cache/pbuilder/base-wheezy.cow/ which is then ready to do be used. For more information about this useful tool, look at the git-builder entry on the Debian wiki. Creating the branch The master branch is generally where sid will located. For the other distributions, I use branches. For the initial setup you will need to create the branch and start it off from the right point. For example, the last non-security update for wordpress in jessie was version 4.1+dfsg-1. We then want the jessie branch to start from this point.

git branch jessie debian/4.1+dfsg-1
git checkout jessie

This will then create and put you on the jessie branch. You only need the first line once. You can switch between sid (master branch) and jessie (jessie branch). At this point you have a working place to make all the updates you need to do. Nothing is terribly different from the usual workflow. Building the package Make sure you have checked in all your changes and now it is time to build your package!

git-buildpackage --git-pbuilder --git-dist=jessie --git-debian-branch=jessie

You may need two additional flags:

• -sa Use this for the first security update so there is also the source included on the security servers.
• git-tag Once you are sure this is the latest changes for this version this will tag in git with the debian tag, such as debian/4.1+dfsg-1+deb8u1

Erich, As a follow-up on your blog post, where you complain about the state of Hadoop. First, I couldn t agree more with all you wrote. All of it! But why not trying to get Hadoop in Debian, rather than only complaining about the state of things? I have recently packaged and uploaded Sahara, which is OpenStack big data as a service (in other words: running Hadoop as a service on an OpenStack cloud). Its working well, though it was a bit frustrating to discover exactly what you complained about: the operating system cloud image needed to run within Sahara can only be downloaded as a pre-built image, which is impossible to check. It would have been so much work to package Hadoop that I just gave up (and frankly, packaging all of OpenStack in Debian is enough work for a single person doing the job so no, I don t have time to do it myself). OpenStack Sahara already provides the reproducible deployment system which you seem to wish. We only need Hadoop itself.

I wasn t sure whether I would make it to Linuxdays Graz (GLT15) this year so I didn t participate in its call for lectures. But when meeting folks on the evening before the main event I came up with the idea of giving a lightning talk as special kind of celebrating the Debian jessie release. So I gave a lightning talk about "Debian 8 aka jessie, what s new" on 25th of April (couldn t have been a better date :)) and the slides of my talk turned up to be more useful than expected (>3000 downloads within the first 48 hours and I received lots of great feedback), so maybe it s worth mentioning them here as well: "Debian 8 aka jessie, what s new" (PDF, 450KB) PS: please join the #newinjessie game, also see #newinjessie on twitter

Since the announcement of the chrome/chromium and firefox/iceweasel extensions that add in-browser editing of Debian sources there have been a few changes:

• Update to Ace 1.1.9, which brings quite some fixes
• Downloads with proper file names! this should work with recent browsers. E.g for a patch it will propose package-version_path_file.patch
• Changing the order of additions and removals in the generated patches (it was strange to see additions first)
• Improvements to the compatibility with debsources' URL parameters
• Allow the extension to be enabled in private browsing mode (firefox/iceweasel)
• Loading of the extension when browsing debsources via https
• Internal extension packaging cleanup, including the generation of a versioned copy of the web (remote) files, so that users of version 0.0.x do use the remote code version 0.0.x

If your browser performs automatic updates of the extensions (the default), you should soon be upgraded to version 0.0.10 or later, bringing all those changes to your browser.

Want to see more? multi-file editing? emacs and vim editing modes? in-browser storage of the modified files? that and more can be done, so feel free to join me and contribute to the Debian sources editor!

That's all I need to enjoy the best best party ever. Oh! Shall I mention that we got a beautiful present for the kids from our very dear DebConf official Laminatrix! Photos not yet available, but will provide soon.

Edit to add: These patches on their own won't enable this functionality, they just give us a better set of options. Once they're merged we can look at changing the defaults so people get the benefit of this out of the box.

Haswell and Broadwell (Intel's previous and current generations of x86) both introduced a range of new power saving states that promised significant improvements in battery life. Unfortunately, the typical experience on Linux was an increase in power consumption. The reasons why are kind of complicated and distinctly unfortunate, and I'm at something of a loss as to why none of the companies who get paid to care about this kind of thing seemed to actually be caring until I got a Broadwell and looked unhappy, but here we are so let's make things better.

Recent Intel mobile parts have the Platform Controller Hub (Intel's term for the Southbridge, the chipset component responsible for most system i/o like SATA and USB) integrated onto the same package as the CPU. This makes it easier to implement aggressive power saving - the CPU package already has a bunch of hardware for turning various clock and power domains on and off, and these can be shared between the CPU, the GPU and the PCH. But that also introduces additional constraints, since if any component within a power management domain is active then the entire domain has to be enabled. We've pretty much been ignoring that.

The tldr is that Haswell and Broadwell are only able to get into deeper package power saving states if several different components are in their own power saving states. If the CPU is active, you'll stay in a higher-power state. If the GPU is active, you'll stay in a higher-power state. And if the PCH is active, you'll stay in a higher-power state. The last one is the killer here. Having a SATA link in a full-power state is sufficient to keep the PCH active, and that constrains the deepest package power savings state you can enter.

SATA power management on Linux is in a kind of odd state. We support it, but we don't enable it by default. In fact, right now we even remove any existing SATA power management configuration that the firmware has initialised. Distributions don't enable it by default because there are horror stories about some combinations of disk and controller and power management configuration resulting in corruption and data loss and apparently nobody had time to investigate the problem.

I did some digging and it turns out that our approach isn't entirely inconsistent with the industry. The default behaviour on Windows is pretty much the same as ours. But vendors don't tend to ship with the Windows AHCI driver, they replace it with the Intel Rapid Storage Technology driver - and it turns out that that has a default-on policy. But to make things even more awkwad, the policy implemented by Intel doesn't match any of the policies that Linux provides.

In an attempt to address this, I've written some patches. The aim here is to provide two new policies. The first simply inherits whichever configuration the firmware has provided, on the assumption that the system vendor probably didn't configure their system to corrupt data out of the box[1]. The second implements the policy that Intel use in IRST. With luck we'll be able to use the firmware settings by default and switch to the IRST settings on Intel mobile devices.

This change alone drops my idle power consumption from around 8.5W to about 5W. One reason we'd pretty much ignored this in the past was that SATA power management simply wasn't that big a win. Even at its most aggressive, we'd struggle to see 0.5W of saving. But on these new parts, the SATA link state is the difference between going to PC2 and going to PC7, and the difference between those states is a large part of the CPU package being powered up.

But this isn't the full story. There's still work to be done on other components, especially the GPU. Keeping the link between the GPU and an internal display panel active is both a power suck and requires additional chipset components to be powered up. Embedded Displayport 1.3 introduced a new feature called Panel Self-Refresh that permits the GPU and the screen to negotiate dropping the link, leaving it up to the screen to maintain its contents. There's patches to enable this on Intel systems, but it's still not turned on by default. Doing so increases the amount of time spent in PC7 and brings corresponding improvements to battery life.

This trend is likely to continue. As systems become more integrated we're going to have to pay more attention to the interdependencies in order to obtain the best possible power consumption, and that means that distribution vendors are going to have to spend some time figuring out what these dependencies are and what the appropriate default policy is for their users. Intel's done the work to add kernel support for most of these features, but they're not the ones shipping it to end-users. Let's figure out how to make this right out of the box.

[1] This is not necessarily a good assumption, but hey, let's see

comments

If you are using DNSSEC you can now use it to verify DKIM keys with opendkim. This does require a bit of configuration. Opendkim uses unbound for DNSSEC support. You have to:

• Install the unbound package (not just the library, which is already pulled in as an opendkim dependency)
• Configure the DNSSEC trust anchor for unbound ( either in /etc/unbound/unbound.conf or by adding a configuration snippet to /etc/unbound/unbound.conf.d the latter makes it much less likely you ll have to resolve conflicts in the configuration file if the default file is changed on later package upgrades)
• Update /etc/opendkim.conf and add:

ResolverConfiguration /etc/unbound/unbound.conf Once that s done, restart opendkim and your DKIM key queries are DNSSEC protected (you can verify this in your mail logs since opendkim annotates unprotected keys when it logs). Note: This should also apply to Ubuntu 14.04, 14.10, and 15.04. Update: In Wheezy (and Squeeze, at least the version in backports, I didn t check the release version) and Ubuntu 10.04 (similarly with backports) this was possible too. The opendkim.conf parameter was called UnboundConfigFile. You may have to update your local configuration to use the new name when you upgrade.

(No, I'm not talking about a future Ubuntu release... After all, what kind of weird animal would a weekend be?) This weekend we took the kids outside for the first time (not counting, of course, visits to the pediatrician). We were quite anxious... Of course, they were born somewhat under weight and at 7 months of gestation. But this Saturday we feelt adventurous, and took the kids out for a day among people! It might not sound like a big deal, but... Well, we took a not such beautiful or scenic route: We took them to the supermarket, and had a small lunch out. For the first time in the already two months they have been with us. Dinner with friends at home, having a very good time, and as expected a... Very hard night for us. All that excitement had the babies very nervous. Today again, for the first time we took the children out to visit some friends of ours. Again, it was great, they behaved very nicely, and were lovely all around. Lets see what this night holds in place for us. Anyway, with them growing slowly but steadily... We are very happy, thankful parents. For the first time since Regina is with me in Mexico, this time we decided we would not have a birthday party (yes, I'm 30 minutes away from being 39 year old). I cannot imagine a fuller, better celebration than what we are having. This two babies are the real event in our lives. Oh... And by the way, this weekend also saw the release of a great new Debian release: Debian 8, codenamed Jessie. Thanks, folks, for such a great birthday present ;-) For reasons that should by now be obvious, I wasn't able to go to either of the release parties I knew of in Mexico City (even one of them was ~500m from home!)

This is a fairly minor patch release of the lbcd daemon, which is a daemon that listens for and responds to a simple UDP protocol to request information about system load. It's used in conjunction with lbnamed for dyanmic DNS, and can also be used as a lightweight way to remotely query load. The only real change in this version is to support linking with libsystemd instead of libsystemd-daemon, since systemd upstream has merged the various small support libraries into one. I also did my normal merge of changes from C TAP Harness and rra-c-util. NOTE: This package is actually orphaned. No one else has picked it up, and I still maintain the Debian package, so I went ahead and did a new release with this fix. But I'm not planning on doing any significant work on it, and am happy to hand it off to another maintainer. You can get the latest release from the lbcd distribution page.