Why a new data analysis software ?I'm a researcher at the interface between physics, chemistry and biology, and in our team, we pride ourselves on making the most of the data we acquire, especially through quantitative analysis and modelling. In fact, we spend a lot of time doing fitting simple formulas or complex differential equations to our data. As we were not really satisfied with the data fitting capacities of the software available, we've had our custom data processing/fitting tool, SOAS, for ages. However, that tool was hard to maintain (Fortran + Fortran libraries interfacing with X11 with ABI changing every once in a while without notice), impossible to port to non-X11 platforms, not very user-friendly, and not easy to extend at all. So, when I got my permanent position, a rewrote a completely new version from scratch, called QSoas using C++, Qt, Ruby and the GNU Scientific Library. The result is incomparably more powerful, more easy to maintain, more user-friendly, and more portable (I build it for Linux, Mac and Windows).
What does it do ?The main features of QSoas are:

• all standard data processing capacities (filtering, baseline subtraction, arithmetic transformations);
• fully scriptable (can process hundreds of data files in one go);

• easy to use data fitting interface, based on the recognition that initial parameters are very important for difficult fits, and that being able to change them easily is an absolute must (screenshot);
• easy fit parameter save and reuse;
• very powerful "global fits", with parameters that can be common to several datasets and others that can be dataset-specific (at the option of the user);
• integration of differential equations and kinetic systems;
• quick data browsing;
• peak detection;
• arbitrary fit functions, and many built-in fit functions with smart initial parameters detection;
• infinite undo/redo and much more...

What has it done already ?We've relied heavily on QSoas's functionalities for the past 3-4 years, and a great part of the team's publications just wouldn't be there without QSoas. More precisely on selected examples:

• we used advanced fitting (fitting derivatives along with data) in Fourmond et al, JACS 2013;
• we used heavy batch processing and global fitting for Hajj et al, EES 2014;
• we used the integration of kinetic systems in Orain et al, JACS 2015;
• we made heavy use of the global fitting capacities in Ceccaldi et al, BBA 2015...

I hope it will also help you get more than you previously could from your data (and faster, too !).
I want it, where can I get it ?You can download QSoas version 1.0 on its website. The source code is fully available under the GNU General Public License. For those not too compilation-savvy, we sell pre-built binaries for windows and mac, in collaboration with Satt Sud-Est and eValorix. Compilation under Linux is very simple, but I'm willing to come up with a Debian package, should some of you want that. You should definitely have a look at the tutorial and the command reference.

The second update to the Rblpapi package (since the initial CRAN upload in August) is now available. Rblpapi connects R to the Bloomberg system, giving access to a truly vast array of time series data and custom calculations. This release brings a new subscribe() function for real-time data, written by Whit. Don't get too excited because R's single-threadedness places some limits of the usefulness of this--but it is still tremendously valuable for checking other data sources etc pp. Also included in this release are a ton of bug fixes, many contributed by Rademeyer -- see below for more details.

Changes in Rblpapi version 0.3.2 (2015-12-07)

• A new subscribe() function supports live data subscription for a set of tickers and fields (#88).
• In the beqs() example the correct date format is used (PR #85 by Rademeyer).
• Both getTicks() and getBars() now check the start and end times for proper Datetime class.
• The getBars() function now also return the value traded (request of #89).
• An error in the documentation for bdh was corrected (PR #93 by Rademeyer closing #85).
• The beqs() function is now more robust with respect to empty return columns (PR #100 by Rademeyer fixing ticket #99).
• The getBars() function now uses a single (named) vector options to pass optional values to the underlying function (PR #105 updating PR #48 and fixing #47).
• When R is built with libcurl support, it used to download the build-time library and headers; otherwise curl is used. This avoids an issue on OS X where curl is insufficient.

Courtesy of CRANberries, there is also a diffstat report for the this release. As always, more detailed information is on the Rblpapi page. Questions, comments etc should go to the issue tickets system at 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.

Cookies are an important part of the Web since they are the primary mechanism that websites use to maintain user sessions. Unfortunately, they are also abused by surveillance marketing companies to follow you around the Web. Here are a few things you can do in Firefox to protect your privacy.

Cookie Expiry Cookies are sent from the website to your browser via a Set-Cookie HTTP header on the response. It looks like this:

HTTP/1.1 200 OK
Date: Mon, 07 Dec 2015 16:55:43 GMT
Server: Apache
Set-Cookie: SESSIONID=65576c6c64206e6f2c657920756f632061726b636465742065686320646f2165
Content-Length: 2036
Content-Type: text/html;charset=UTF-8

When your browser sees this, it saves that cookie for the given hostname and keeps it until you close the browser. Should a site want to persist their cookie for longer, they can add an Expires attribute:

Set-Cookie: SESSIONID=65576c...; expires=Tue, 06-Dec-2016 22:38:26 GMT

in which case the browser will retain the cookie until the server-provided expiry date (which could be in a few years). Of course, that's if you don't instruct your browser to do things differently.

Controlling Cookie Expiry In order to change your cookie settings, you must open the Firefox preferences, click on "Privacy" and then choose "Use custom settings for history" under the "History" heading. There, you will have the ability to turn off cookies entirely (network.cookie.cookieBehavior = 2), which I don't recommend you do in your browser since you won't be able to login anywhere. On the other hand, turning off cookies is what I do (and recommend) in Thunderbird since I can't think of a legitimate reason for an email to leave a cookie in my mail client. Another control you'll find there is "Keep until" which defaults to honoring the server-provided expiry ("they expire" aka network.cookie.lifetimePolicy = 0) or making them expire at the end of the browsing session ("I close Firefox" aka network.cookie.lifetimePolicy = 2). A third option is available if you type about:config into your URL bar and looking for the network.cookie.lifetimePolicy preference. Setting this to 3 will honor the server-provided expiry up to a maximum lifetime of 90 days. You can also make that 90 days be anything you want by changing the network.cookie.lifetime.days preference. Regardless of the settings you choose, you can always tell Firefox to clear cookies when you close it by selecting the "Clear history when Firefox closes" checkbox, clicking the "Settings" button and making sure that "Cookies" is selected (privacy.clearOnShutdown.cookies = true). This could be useful for example if you'd like to ensure that cookies never last longer than 5 days but are also cleared whenever you shut down Firefox.

Third-Party Cookies So far, we've only looked at first-party cookies: the ones set by the website you visit and which are typically used to synchronize your login state with the server. There is however another kind: third-party cookies. These ones are set by the third-party resources that a page loads. For example, if a page loads JavaScript from a third-party ad network, you can be pretty confident that they will set their own cookie in order to build a profile on you and serve you "better and more relevant ads".

Controlling Third-Party Cookies If you'd like to opt out of these, you have a couple of options. The first one is to turn off third-party cookies entirely by going back into the Privacy preferences and selecting "Never" next to the "Accept third-party cookies" setting (network.cookie.cookieBehavior = 1). Unfortunately, turning off third-party cookies entirely tends to break a number of sites which rely on this functionality (for example as part of their for login process). A more forgiving option is to accept third-party cookies only for sites which you have actually visited directly. For example, if you visit Facebook and login, you will get a cookie from them. Then when you visit other sites which include Facebook widgets they will not recognize you unless you allow cookies to be sent in a third-party context. To do that, choose the "From visited" option (network.cookie.cookieBehavior = 3). In addition to this setting, you can also choose to make all third-party cookies automatically expire when you close Firefox by setting the network.cookie.thirdparty.sessionOnly option to true in about:config.

Other Ways to Limit Third-Party Cookies Another way to limit undesirable third-party cookies is to tell the browser to avoid connecting to trackers in the first place. This functionality is now built into Private Browsing mode and enabled by default. To enable it outside of Private Browsing too, simply go into about:config and set privacy.trackingprotection.enabled to true. You could also install the EFF's Privacy Badger add-on which uses heuristics to detect and block trackers, unlike Firefox tracking protection which uses a blocklist of known trackers.

My Recommended Settings On my work computer I currently use the following:

network.cookie.cookieBehavior = 3
network.cookie.lifetimePolicy = 3
network.cookie.lifetime.days = 5
network.cookie.thirdparty.sessionOnly = true
privacy.trackingprotection.enabled = true

which allows me to stay logged into most sites for the whole week (no matter now often I restart Firefox Nightly) while limiting tracking and other undesirable cookies as much as possible.

Debian LTS November was the seventh month I contributed to Debian LTS under the Freexian umbrella. In total I spent ten hours working on:

• krb5: Released DLA-340-1 after applying a fix to the work done in October.
• nss: Provided patches for CVE-2015-7181 and CVE-2015-7182 for squeeze, wheezy and jessie and released DLA-354-1 for squeeze-lts for that. Since nss is subject to frequent security updates I wanted to spend less time doing "did I break the whole thing" testing so I added some autopkg tests that do basic certificate handling and make sure we can link a simple binary against the dev package (#806207). We also discussed using the same nss version in all suites on the debian-lts list. To test that path I worked on creating backports for Jessie/Wheezy/Squeeze of the current sid version. So far I tested the general feasibility and some simple upgrades. To be able to detect breackage more easily I enabled the internal test suite resulting in #806639. I also filed #806634 to ease backporting in the future. Packages are collected here with the sources in this (temporary) git repo. Work on this will continue in December.

Other Debian stuff

• There was no git-buildpackge upload in November but the git repository already collected some fixes and new features like building RPMs in clean chroots using mock. Patches for this were provided by Tzafrir Cohen. I've been hoping we get #775118 fixed in mock so it becomes actually useful in Debian before uploading a new gbp version. There's also now an example for README.source for gbp managed source packages. I'd be nice to have patches to further improve this. The main reason for not uploading new gbp yet is that I said at Debconf that I'll improve error recovery in gbp import-orig with the next or next next upload and that would be 0.7.1 latest. I did no get around to continue on this since Debconf though.
• I supplied a patch for pbuilder's #802800 to allow building with -g
• Uploaded libvirt 1.2.21 to unstable.

During the last few days, I found several references to a beautiful just-published paper, which I hope everybody reads: The Moral Character of Cryptographic Work, by Phillip Rogaway; Cryptology ePrint Report 2015/1162, published on December 1st this year. It is more an academic essay than most crypto-related papers, and a long one at that (46 pages, packed with references and anecdotal notes). But it is surprisingly easy to read. I am sitting in front of my computer while my students work on their final exam, and I have got over half way through the text; earlier today I looked at the quick presentation (as this work was presented by Rogaway at the Asiacrypt 2015 as an invited talk), and just loved it. Now, I know most of the people reading my blog have a moral stand on their work (after all, I expect most of you to be committed to Free Software just as I am, and that is a tremendous political statement). We are also more a practice community than an academic/scientific one. But many of us dwell on several projects and hold more than one hats in life through which we are defined. This paper/essay is really clicking with me, and it deeply resonates with the justification I presented when I joined the Masters on Security Engineering and Information Technologies program which I'm halfway through. Computer security does not exist in a void, and does not exist just for itself. As professionals, we have a mission to fulfill in society, and that will then shape how society evolves. So, I invite everybody to at least take a casual look at this paper. I hope you enjoy it as much as I did, and I hope it changes people's hearts and career decisions.

Categories:

• Debian-Blog
• Technology

Keywords:

• KDE
• gnome
• Yoga 2 13
• Yoga
• Lenovo
• Touch
• UI
• Design
• Freedom
• Privacy

Like:

Like everybody else on the internet today was the day I started rolling out SSL certificates, via let's encrypt. The process wasn't too difficult, but I did have to make some changes. Pretty much every website I have runs under its own UID, and I use a proxy to pass content through to the right back-end. Running 15+ webservers feels like overkill, but it means that the code running start.steve.org.uk cannot read/modify/break the code that is running this blog - because they run as different UIDs. To start with I made sure that all requests to the top-level /.well-known directory were shunted to a local directory - via this in /etc/apache2/conf-enabled/well-known.conf:

Alias /.well-known/ /srv/well-known/
<Directory "/srv/well-known/">
    ForceType text/plain
    Options Indexes FollowSymLinks MultiViews
    AllowOverride all
    AuthType None
    Require all granted
</Directory>

Then configured each proxy to avoid forwarding that path to the back-ends, by adding this to each of the individual virtual-hosts that run proxying:

<Proxy *>
  Order allow,deny
  Allow from all
</Proxy>
ProxyPass /.well-known !
ProxyPass        / http://localhost:$port/
..

Then it came to be time to actually generate the certificates. Rather than using the official client I used a simpler one that allowed me to generate requests easily:

CSR=/etc/apache2/ssl/csr/
KEYS=/etc/apache2/ssl/keys/
CERTS=/etc/apache2/ssl/certs/
# generate a key
openssl genrsa 4096 > $KEYS/lumail.key
# make a CSR
openssl req -new -sha256 -key $KEYS/lumail.key -subj "/" -reqexts SAN \
   -config <(cat /etc/ssl/openssl.cnf \
   <(printf "[SAN]\nsubjectAltName=DNS:www.lumail.org,DNS:lumail.org")) \
   > $CSR/lumail.csr
# Do the validation
acme_tiny.py --account-key ./account.key --csr $CSR/lumail.csr \
  --acme-dir /srv/well-known/acme-challenge/ > $CERTS/lumail.crt.new

And then I was done. Along the way I found some niggles:

• If you have a host that listens on IPv6 only you cannot validate your request - this seems like a clear failure.
• It is assumed that you generate all your certificates in their live-location. e.g. You cannot generate a certificate for foo.example.com on the host bar.example.com.
• If you forward HTTP -> HTTPS the validation fails. I had to setup rewrite rules to avoid this, for example lumail.org contains this:
  • RewriteEngine On
  • RewriteCond % REQUEST_URI !^/.well-known
  • RewriteRule ^/(.*) https://lumail.org/$1 [L]

The first issue is an annoyance. The second issue is a real pain. For example *.steve.org.uk listens on one machine except for webmail.steve.org.uk. Since there are no wildcards created a single certificate with Alt-names for a bunch of names such as:

• ..
• blog.steve.org.uk
• start.steve.org.uk
• ..

Then seperately create a certificate for the webmail host - which I've honestly not done yet. Still I wrote a nice little script to generate SSL for a number of domains, with different Alt-Names, wrapping around the acme_tiny.py script, and regenerating all my deployed certificates is now a two minute job. (People talk about renewing certificates. I don't see the gain. Just replace them utterly every two months and you'll be fine.)

Following on yesterday's announcement of RcppCCTZ, what is the only thing better than another date, time, or timezones library package? One that works on Solaris too :) Bradley White from CCTZ upstream spotted the failed compilation on the machine in Oxford and suggested a quick fix. Jeroen quickly tested what I had put into a branch, and there we have it: version 0.0.2 which now builds everywhere. Changes (for both releases) are summarized here:

Changes in version 0.0.2 (2015-12-02)

• Additional #ifdef statements suggested by Bradley White in CCTZ ticket #5 permitting compilation on Solaris with thanks to Jeroen for testing our branch.

Changes in version 0.0.1 (2015-12-01)

• Initial CRAN upload.
• Package is functional and provides examples.

We now also have a diff to the previous version thanks to CRANberries. More details, issue tickets etc at the GitHub repository.

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 new package! A couple of weeks ago folks at Google released CCTZ: a C++ library for translating between absolute and civil times using the rules of a time zone. It requires only a proper C++11 compiler and the standard IANA time zone data base which standard Unix, Linux, OS X, ... computers tend to have in /usr/share/zoneinfo. And as the world needs nothing more than additional date, time, or timezones libraries, I started to quickly create a basic R wrapper package. This stalled as the original version of CCTZ used an __int128 for extended precision. That is not only not portable, but also prohibits compilation on baby computers still running a 32 OS (such as my trusted X1 laptop merrily plugging along with 4 gb of ram under Linux). Hence I filed an issue ticket which, lo and behold, got resolved two days ago. And so now we have a shiny new RcppCCTZ package on CRAN in a very basic version 0.0.1. It happily runs all the original examples from CCTZ as e.g. this one:

// from examples/hello.cc
//
// [[Rcpp::export]]
int helloMoon()  
    cctz::TimeZone syd;
    if (!cctz::LoadTimeZone("Australia/Sydney", &syd)) return -1;
    // Neil Armstrong first walks on the moon
    const auto tp1 = cctz::MakeTime(1969, 7, 21, 12, 56, 0, syd);
    const std::string s = cctz::Format("%F %T %z", tp1, syd);
    Rcpp::Rcout << s << "\n";
    cctz::TimeZone nyc;
    cctz::LoadTimeZone("America/New_York", &nyc);
    const auto tp2 = cctz::MakeTime(1969, 7, 20, 22, 56, 0, nyc);
    return tp2 == tp1 ? 0 : 1;
 

which results in

R> library(RcppCCTZ)
R> helloMoon()
1969-07-21 12:56:00 +1000
[1] 0
R>

indicating that the two civil times in fact correspond to the same absolute times when Armstrong walked on the moon. If you want to learn more about CCTZ, there was a corresponding talk CppCon (Youtube, Slides). I hope this provides a starting point for some new interesting computation on time from R. Collaboration welcome via the RcppCCTZ 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.

Sometime earlier last year, I started to help Philippe Massicotte with his gtrendsR package---which was then still "hiding" in relatively obscurity on BitBucket. I was able to assist with a few things related to internal data handling as well as package setup and package builds--but the package is really largely Philippe's. But then we both got busy, and it wasn't until this summer at the excellent useR! 2015 conference that we met and concluded that we really should finish the package. And we both remained busy... Lo and behold, following a recent transfer to this GitHub repository, we finalised a number of outstanding issues. And Philippe was even kind enough to label me a co-author. And now the package is on CRAN as of yesterday. So install.packages("gtrendsR") away and enjoy! Here is a quiick demo:

## load the package, and if options() are set appropriately, connect
## alternatively, also run   gconnect("someuser", "somepassword")
library(gtrendsR)
## using the default connection, run a query for three terms
res <- gtrends(c("nhl", "nba", "nfl"))
## plot (in default mode) as time series
plot(res)
## plot via googeVis to browser
## highlighting regions (probably countries) and cities
plot(res, type = "region")
plot(res, type = "cities")

The time series (default) plot for this query came out as follows a couple of days ago:

One really nice feature of the package is the rather rich data structure. The result set for the query above is actually stored in the package and can be accessed. It contains a number of components:

R> data(sport_trend)
R> names(sport_trend)
[1] "query"     "meta"      "trend"     "regions"   "topmetros"
[6] "cities"    "searches"  "rising"    "headers"  
R>

So not only can one look at trends, but also at regions, metropolitan areas, and cities --- even plot this easily via package googleVis which is accessed via options in the default plot method. Furthermore, related searches and rising queries may give leads to dynamics within the search. Please use the standard GitHub issue system for bug reports, suggestions and alike.

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 the past few years all my important work has been stored in git repositories. Thanks to the mr tool I have a single configuration file that allows me to pull/maintain a bunch of repositories with ease. Having recently wiped & reinstalled a pair of desktop systems I'm now wondering if I can switch to using a totally transient home-directory. The basic intention is that:

• Every time I login "rm -rf $HOME/*" will be executed.

I see only three problems with this:

• Every time I login I'll have to reclone my "dotfiles", passwords, bookmarks, etc.
• Some programs will need their configuration updated, post-login.
• SSH key management will be a pain.

My dotfiles contain my my bookmarks, passwords, etc. But they don't contain setup for GNOME, etc. So there might be some configuration that will become annoying - For example I like "Ctrl-Alt-t" to open a new gnome-terminal command. That's configured on each new system I login to the first time. My images/videos/books are all stored beneath /srv and not in my home directory - so the only thing I'll be losing is program configuration, caches, and similar. Ideally I'd be using a smartcard for my SSH keys - but I don't have one - so for the moment I might just have to rsync them into place, but that's grossly bad. I'll be interesting to see how well this works out, but I see a potential gain in portability and discipline at the very least.

What happened in the reproducible builds effort this week: Toolchain fixes

• Markus Koschany uploaded antlr3/3.5.2-3 which includes a fix by Emmanuel Bourg to make the generated parser reproducible.
• Markus Koschany uploaded maven-bundle-plugin/2.4.0-2 which includes a fix by Emmanuel Bourg to use the date in the DEB_CHANGELOG_DATETIME variable in the pom.properties file embedded in the jar files.
• Niels Thykier uploaded debhelper/9.20151116 which makes the timestamp of directories created by dh_install, dh_installdocs, and dh_installexamples reproducible. Patch by Niko Tyni.

Mattia Rizzolo uploaded a version of perl to the reproducible repository including the patch written by Niko Tyni to add support for SOURCE_DATE_EPOCH in Pod::Man. Dhole sent an updated version of his patch adding support for SOURCE_DATE_EPOCH in GCC to the upstream mailing list. Several comments have been made in response which have been quickly addressed by Dhole. Dhole also forwarded his patch adding support for SOURCE_DATE_EPOCH in libxslt upstream. Packages fixed The following packages have become reproducible due to changes in their build dependencies: antlr3/3.5.2-3, clusterssh, cme, libdatetime-set-perl, libgraphviz-perl, liblingua-translit-perl, libparse-cpan-packages-perl, libsgmls-perl, license-reconcile, maven-bundle-plugin/2.4.0-2, siggen, stunnel4, systemd, x11proto-kb. The following packages became reproducible after getting fixed:

• bindex/2.2+svn101-3 by Markus Koschany.
• glyr/1.0.8-2 by Etienne Millon.
• jenkins-json/2.4-jenkins-3-4 by Emmanuel Bourg.
• pkg-config/0.29-1 uploaded by Tollef Fog Heen, original patch by Juan Picca.
• plexus-containers1.5/1.6-1 by Emmanuel Bourg.
• polyglot-maven/0.8~tobrien+git20120905-5 by Emmanuel Bourg.
• sigil/0.9.0+dfsg-3 uploaded by Mattia Rizzolo, original patch by Reiner Herrmann.
• simutrans/120.1.1+repack-2 uploaded by J rg Frings-F rst, fix by Markus Koschany.
• torrus/2.08-4 by Bernhard Schmidt.
• trigger-rally-data/0.6.1-2 uploaded by Bertrand Marc, patch by Mattia Rizzolo.

Some uploads fixed some reproducibility issues, but not all of them:

• castle-game-engine/5.2.0-1 by Paul Gevers.
• libam7xxx/0.1.6-2 by Antonio Ospite.
• libpdfbox-java/1:1.8.10-1 by Emmanuel Bourg.
• xfaces/3.3-29 uploaded by Hakan Ardo, original patch by Chris Lamb.

reproducible.debian.net Vagrant Cascadian has set up a new armhf node using a Raspberry Pi 2. It should soon be added to the Jenkins infrastructure. diffoscope development diffoscope version 42 was release on November 20th. It adds a missing dependency on python3-pkg-resources and to prevent similar regression another autopkgtest to ensure that the command line is functional when Recommends are not installed. Two more encoding related problems have been fixed (#804061, #805418). A missing Build-Depends has also been added on binutils-multiarch to make the test suite pass on architectures other than amd64. Package reviews 180 reviews have been removed, 268 added and 59 updated this week. 70 new fail to build from source bugs have been reported by Chris West, Chris Lamb and Niko Tyni. New issue this week: randomness_in_ocaml_preprocessed_files. Misc. Jim MacArthur started to work on a system to rebuild and compare packages built on reproducible.debian.net using .buildinfo and snapshot.debian.org. On December 1-3rd 2015, a meeting of about 40 participants from 18 different free software projects will be held in Athens, Greece with the intent of improving the collaboration between projects, helping new efforts to be started, and brainstorming on end-user aspects of reproducible builds.

Last Friday, I compiled a list of keyboards I'm interested in, and received a lot of incredible feedback, thank you all! This allowed me to shorten the list considerably, two basically two pieces. I'm reasonably sure by now which one I want to buy (both), but will spend this week calming down to avoid impulse-buying. My attention was also brought to a few keyboards originally not on my list, and I'll take this opportunity to present my thoughts on those too.The FinalistsErgoDoxPros

• Great design, by the looks of it.
• Mechanical keys.
• Open source hardware and firmware, thus programmable.
• Thumb keys.
• Available as an assembled product, from multiple sources.

Cons

• Primarily a kit, but assembled available.
• Assembled versions aren't as nice as home-made variants.

SummaryThe keyboard looks interesting, primarily due to the thumb keys. From the ErgoDox EZ campaign, I'm looking at $270. That's friendly, and makes ErgoDox a viable option! (Thanks @miffe!)There's also another option, FalbaTech, which ships sooner, I can customize the keyboard to some extent, and Poland is much closer to Hungary than the US. With this option, I'm looking at $205 + shipping, a very low price for what the keyboard has to offer. (Thanks @pkkolos for the suggestion!)Keyboardio M01Pros

• Mechanical keyboard.
• Hardwood body.
• Blank and dot-only keycaps option.
• Open source: firmware, hardware, and so on. Comes with a screwdriver.
• The physical key layout has much in common with my TypeMatrix.
• Numerous thumb-accessible keys.
• A palm key, that allows me to use the keyboard as a mouse.
• Fully programmable LEDs.
• Custom macros, per-application even.

Cons

• Fairly expensive.
• Custom keycap design, thus rearranging them physically is not an option, which leaves me with the blank or dot-only keycap options only.
• Available late summer, 2016.

SummaryWith shipping cost and whatnot, I'm looking at something in the $370 ballpark, which is on the more expensive side. On the other hand, I get a whole lot of bang for my buck: LEDs, two center bars (tripod mounting sounds really awesome!), hardwood body, and a key layout that is very similar to what I came to love on the TypeMatrix.I also have a thing for wooden stuff. I like the look of it, the feel of it.The VerdictRight now, I'm seriously considering the Model 01, because even if it is about twice the price of the ErgoDox, it also offers a lot more: hardwood body (I love wood), LEDs, palm key. I also prefer the layout of the thumb keys on the Model 01.The Model 01 also comes pre-assembled, looks stunning, while the ErgoDox pales a little in comparsion. I know I could make it look stunning too, but I do not want to build things. I'm not good at it, I don't want to be good at it, I don't want to learn it. I hate putting things together. I'm the kind of guy who needs three tries to put together a set of IKEA shelves, and I'm not exaggerating. I also like the shape of the keys better on the Model 01.Nevertheless, the ErgoDox is still an option, due to the price. I'd love to buy both, if I could. Which means that once I'm ready to replace my keyboard at work, I will likely buy an ErgoDox. But for home, Model 01 it is, unless something even better comes along before my next pay.The Kinesis Advantage was also a strong contender, but I ended up removing it from my preferred options, because it doesn't come with blank keys, and is not a split keyboard. And similar to the ErgoDox, I prefer the Model 01's thumb-key layout. Despite all this, I'm very curious about the key wells, and want to try it someday.Suggested optionsYogitypeSuggested by Andred Carter, a very interesting keyboard with a unique design.Pros

• Portable, foldable.
• Active support for forearm and hand.
• Hands never obstruct the view.

Cons

• Not mechanical.
• Needs a special inlay.
• Best used for word processing, programmers may run into limitations.

SummaryI like the idea of the keyboard, and if it wouldn't need a special inlay, but used a small screen or something to show the keys, I'd like it even more. Nevertheless, I'm looking for a mechanical keyboard right now, which I can also use for coding.But I will definitely keep the Yogitype in mind for later!Matias Ergo ProPros

• Mechanical keys.
• Simple design.
• Split keyboard.

Cons

• Doesn't seem to come with a blank keys option, nor in Dvorak.
• No thumb key area.
• Neither open source, nor open hardware.
• I have no need for the dedicated undo, cut, paste keys.
• Does not appear to be programmable.

SummaryThis keyboard hardly meets any of my desired properties, and doesn't have anything standing out in comparison with the others. I had a quick look at this when compiling my original list, but was quickly discarded. Nevertheless, people asked me why, so I'm including my reasoning here:While it is a split keyboard, with a fairly simple design, it doesn't come in the layout I'd prefer, nor with blank keys. It lacks the thumb key area that ErgoDox and the Model 01 have, and which I developed an affection for.Microsoft Sculpt Ergonomic KeyboardPros

• Numpad is a separate unit.
• Reverse tilt.
• Well positioned, big Alt keys.
• Cheap.

Cons

• Not a split keyboard.
• Not mechanical.
• No blank or Dvorak option as far as I see.

SummaryThis keyboard does not buy me much over my current TypeMatrix 2030. If I'd be looking for the cheapest possible among ergonomic keyboards, this would be my choice. But only because of the price.Truly Ergonomic KeyboardPros

• Mechanical.
• Detachable palm rest.
• Programmable firmware.

Cons

• Not a split keyboard.
• Layouts are virtual only, the printed keycaps stay QWERTY, as far as I see.
• Terrible navigation key setup.

SummaryTwo important factors for me are physical layout and splittability. This keyboard fails both. While it is a portable device, that's not a priority for me at this time.

Long over due post It s been a long time I haven t written here. And lots of things happened in the OpenStack planet. As a full time employee with the mission to package OpenStack in Debian, it feels like it is kind of my duty to tell everyone about what s going on. Liberty is out, uploaded to Debian Since my last post, OpenStack Liberty, the 12th release of OpenStack, was released. In late August, Debian was the first platform which included Liberty, as I proudly outran both RDO and Canonical. So I was the first to make the announcement that Liberty passed most of the Tempest tests with the beta 3 release of Liberty (the Beta 3 is always kind of the first pre-release, as this is when feature freeze happens). Though I never made the announcement that Liberty final was uploaded to Debian, it was done just a single day after the official release. Before the release, all of Liberty was living in Debian Experimental. Following the upload of the final packages in Experimental, I uploaded all of it to Sid. This represented 102 packages, so it took me about 3 days to do it all. Tokyo summit I had the pleasure to be in Tokyo for the Mitaka summit. I was very pleased with the cross-project sessions during the first day. Lots of these sessions were very interesting for me. In fact, I wish I could have attended them all, but of course, I can t split myself in 3 to follow all of the 3 tracks. Then there was the 2 sessions about Debian packaging on upstream OpenStack infra. The goal is to setup the OpenStack upstream infrastructure to allow packaging using Gerrit, and gating each git commit using the usual tools: building the package and checking there s no FTBFS, running checks like lintian, piuparts and such. I knew already the overview of what was needed to make it happen. What I didn t know was the implementation details, which I hoped we could figure out during the 1:30 slot. Unfortunately, this didn t happen as I expected, and we discussed more general things than I wished. I was told that just reading the docs from the infra team was enough, but in reality, it was not. What currently needs to happen is building a Debian based image, using disk-image-builder, which would include the usual tools to build packages: git-buildpackage, sbuild, and so on. I m still stuck at this stage, which would be trivial if I knew a bit more about how upstream infra works, since I already know how to setup all of that on a local machine. I ve been told by Monty Tailor that he would help. Though he s always a very busy man, and to date, he still didn t find enough time to give me a hand. Nobody replied to my request for help in the openstack-dev list either. Hopefully, with a bit of insistence, someone will help. Keystone migration to Testing (aka: Debian Stretch) blocked by python-repoze.who Absolutely all of OpenStack Liberty, as of today, has migrated to Stretch. All? No. Keystone is blocked by a chain of dependency. Keystone depends on python-pysaml2, itself blocked by python-repoze.who. The later, I upgraded it to version 2.2. Though python-repoze.what depends on version <= 1.9, which is blocking the migration. Since python-repoze.who-plugins, python-repoze.what and python-repoze.what-plugins aren t used by any package anymore, I asked for them to be removed from Debian (see #805407). Until this request is processed by the FTP masters, Keystone, which is the most important piece of OpenStack (it does the authentication) will be blocked for migration to Stretch. New OpenStack server packages available On my presentation at Debconf 15, I quickly introduced new services which were released upstream. I have since packaged them all:

• Barbican (Key management as a Service)
• Congress (Policy as a Service)
• Magnum (Container as a Service)
• Manila (Filesystem share as a Service)
• Mistral (Workflow as a Service)
• Zaqar (Queuing as a Service)

Congress, unfortunately, was not accepted to Sid yet, because of some licensing issues, especially with the doc of python-pulp. I will correct this (remove the non-free files) and reattempt an upload. I hope to make them all available in jessie-backports (see below). For the previous release of OpenStack (ie: Kilo), I skipped the uploads of services which I thought were not really critical (like Ironic, Designate and more). But from the feedback of users, they would really like to have them all available. So this time, I will upload them all to the official jessie-backports repository. Keystone v3 support For those who don t know about it, Keystone API v3 means that, on top of the users and tenant, there s a new entity called a domain . All of the Liberty is now coming with Keystone v3 support. This includes the automated Keystone catalog registration done using debconf for all *-api packages. As much as I could tell by running tempest on my CI, everything still works pretty well. In fact, Liberty is, to my experience, the first release of OpenStack to support Keystone API v3. Uploading Liberty to jessie-backports I have rebuilt all of Liberty for jessie-backports on my laptop using sbuild. This is more than 150 packages (166 packages currently). It took me about 3 days to rebuild them all, including unit tests run at build time. As soon as #805407 is closed by the FTP masters, all what s remaining will be available in Stretch (mostly Keystone), and the upload will be possible. As there will be a lot of NEW packages (from the point of view of backports), I do expect that the approval will take some time. Also, I have to warn the original maintainers of the packages that I don t maintain (for example, those maintained within the DPMT), that because of the big number of packages, I will not be able to process the usual communication to tell that I m uploading to backports. However, here s the list of package. If you see one that you maintain, and that you wish to upload the backport by yourself, please let me know. Here s the list of packages, hopefully, exhaustive, that I will upload to jessie-backports, and that I don t maintain myself: alabaster contextlib2 kazoo python-cachetools python-cffi python-cliff python-crank python-ddt python-docker python-eventlet python-git python-gitdb python-hypothesis python-ldap3 python-mock python-mysqldb python-pathlib python-repoze.who python-setuptools python-smmap python-unicodecsv python-urllib3 requests routes ryu sphinx sqlalchemy turbogears2 unittest2 zzzeeksphinx. More than ever, I wish I could just upload these to a PPA^W Bikeshed, to minimize the disruption for both the backports FTP masters, other maintainers, and our OpenStack users. Hopefully, Bikesheds will be available soon. I am sorry to give that much approval work to the backports FTP masters, however, using the latest stable system with the latest release, is what most OpenStack users really want to do. All other major distributions have specific repositories too (ie: RDO for CentOS / Red Hat, and cloud archive for Ubuntu), and stable-backports is currently the only place where I can upload support for the Stable release. Debian listed as supported distribution on openstack.org Good news! If you go at http://www.openstack.org/marketplace/distros/ you will see a list of supported distributions. I am proud to be able to tell that, after 6 months of lobbying from my side, Debian is also listed there. The process of having Debian there included talking with folks from the OpenStack foundation, and having Bdale to sign an agreement so that the Debian logo could be reproduced on openstack.org. Thanks to Bdale Garbee, Neil McGovern, Jonathan Brice, and Danny Carreno, without who this wouldn t have happen.

This is a burst of notes that I wrote in an e-mail in June when asked about it, and I'm not going to have any better steps since I don't remember even that amount as back then. I figured it's better to have it out than not.

So... if you want to use LUKS In-Place Conversion Tool, the notes below on converting a shipped-with-Ubuntu Dell XPS 13 Developer Edition (2015 Intel Broadwell model) may help you. There were a couple of small learnings to be had...

The page http://www.johannes-bauer.com/linux/luksipc/ itself is good and without errors, although funnily uses reiserfs as an example. It was only a bit unclear why I did save the initial_keyfile.bin since it was then removed in the next step (I guess it's for the case you want to have a recovery file hidden somewhere in case you forget the passphrase).

For using the tool I booted from a 14.04.2 LTS USB live image and operated there, including downloading and compiling luksipc in the live session. The exact reason of resizing before luksipc was a bit unclear to me at first so I simply indeed resized the main rootfs partition and left unallocated space in the partition table.

Then finally I ran ./luksipc -d /dev/sda4 etc.

I realized I want /boot to be on an unencrypted partition to be able to load the kernel + initrd from grub before entering into LUKS unlocking. I couldn't resize the luks partition anymore since it was encrypted... So I resized what I think was the empty small DIAGS partition (maybe used for some system diagnostic or something, I don't know), or possibly the next one that is the actual recovery partition one can reinstall the pre-installed Ubuntu from. And naturally I had some problems because it seems vfatresize tool didn't do what I wanted it to do and gparted simply crashed when I tried to use it first to do the same. Anyway, when done with getting some extra free space somewhere, I used the remaining 350MB for /boot where I copied the rootfs's /boot contents to.

After adding the passphrase in luks I had everything encrypted etc and decryptable, but obviously I could only access it from a live session by manual cryptsetup luksOpen + mount /dev/mapper/myroot commands. I needed to configure GRUB, and I needed to do it with the grub-efi-amd64 which was a bit unfamiliar to me. There's also grub-efi-amd64-signed I have installed now but I'm not sure if it was required for the configuration. Secure boot is not enabled by default in BIOS so maybe it isn't needed.

I did GRUB installation I think inside rootfs chroot where I also mounted /dev/sda6 as /boot (inside the rootfs chroot), ie mounted dev, sys with -o bind to under the chroot (from outside chroot) and mount -t proc proc proc too. I did a lot of trial and effort so I surely also tried from outside the chroot, in the live session, using some parameters to point to the mounted rootfs's directories...

I needed to definitely install cryptsetup etc inside the encrypted rootfs with apt, and I remember debugging for some time if they went to the initrd correctly after I executed mkinitramfs/update-initramfs inside the chroot.

At the end I had grub asking for the password correctly at bootup. Obviously I had edited the rootfs's /etc/fstab to include the new /boot partition, I changed / to be "UUID=/dev/mapper/myroot / ext4 errors=remount-ro 0 ", kept /boot/efi as coming from the /dev/sda1 and so on. I had also added "myroot /dev/sda4 none luks" to /etc/crypttab. I seem to also have GRUB_CMDLINE_LINUX="cryptdevice=/dev/sda4:myroot root=/dev/mapper/myroot" in /etc/default/grub.