Open post-doc position: carbon nanotube-based NEMS

We're still looking for some support in the Regensburg carbon nanotube nanomechanics team! The job description can be found below; please e-mail me if interested! The position is available immediately, however I'm travelling during March and may be hard to reach, so arranging a meeting and a presentation may take a bit of time...

You have already been working successfully with millikelvin RF equipment in your PhD research, and have a good understanding of low temperature physics as well as gigahertz technology? Ideally, you are coming from a research group specialized in superconductor-related mesoscopic physics, quantum information, or cavity QED? You are interested in contributing to a young and dynamic team, trying to push the limits of what is doable in nano-electromechanical systems?
Then you might be just about right here. Your will conduct measurements on coupled superconductor-carbon nanotube nano-electromechanical systems, with a low-temperature high frequency measurement setup in a state-of-the-art dilution refrigerator. Our NEMS team consists at the moment of one PhD student and two MSc students (who you'll help supervise). We expect your work to lead to exceptional publications!
Your salary will be based on the German TV-L E13 (info in German). Regensburg university has a strong focus on nanophysics, in particular on spin phenomena and carbon-based systems. The natives are friendly, and while our university buildings feature classic 1965 concrete, the medieval city of Regensburg is a jewel on its own, with a vibrant young atmosphere. Both mountains and Munich airport are not far away.
Interested? Have a look at our web pages, and contact Andreas K. Hüttel (e-mail: andreas.huettel@physik.uni-r.de) for more information!

Hardened Desktop

My work desktop is on one of these university networks where you have an internet connection in the most direct sense. No NAT, no significant firewall, fast pipe. Which naturally gives you an interesting attack surface; while I only allow ssh login via public key cryptography, it's still amusing to watch all the automated "invalid username" login attempts from all over the world. Anyway, some time ago I decided that this deserves some more attention, and switched to a hardened profile...
So, about profiles. You have probably seen this string default/linux/amd64/10.0/desktop before. A profile actually is something pretty simple- a set of predefined defaults for e.g. use flags, system set, package and use masks, ... The main purpose of the desktop profile, which many people use, is to provide sensible defaults for a typical desktop workstation, i.e. enabling useflags like "consolekit jpeg png". Profiles are inheritance-based, meaning this desktop profile inherits defaults from linux and from amd64. You can select your profile with eselect profile, but in the end whatever that does is only redirect the symlink /etc/make.profile to the appropriate target in /usr/portage/profile.
eselect profile also provides a list of profiles to choose from. Here on my laptop this is

huettel@porto ~ $ eselect profile list
Available profile symlink targets:
  [1]   default/linux/amd64/10.0
  [2]   default/linux/amd64/10.0/selinux
  [3]   default/linux/amd64/10.0/desktop *
  [4]   default/linux/amd64/10.0/desktop/gnome
  [5]   default/linux/amd64/10.0/desktop/kde
  [6]   default/linux/amd64/10.0/developer
  [7]   default/linux/amd64/10.0/no-multilib
  [8]   default/linux/amd64/10.0/server
  [9]   hardened/linux/amd64
  [10]  hardened/linux/amd64/selinux
  [11]  hardened/linux/amd64/no-multilib
  [12]  hardened/linux/amd64/no-multilib/selinux

The list comes from /usr/portage/profiles/profiles.desc. However, if you are brave (or insane), nothing keeps you from manually pointing your /etc/make.profile symlink to a different directory. As it turns out, there is a worthwile target hidden away, which provides a "hardened desktop" profile:

huettel@grenadine ~ $ ls -l /etc/make.profile
lrwxrwxrwx 1 root root 52 24. Jan 18:45 /etc/make.profile -> ../usr/portage/profiles/hardened/linux/amd64/desktop

So, if you want to void all your warranties, set your symlink like this and your profile will inherit from both hardened and desktop profile. Then follow the rest of the guide for switching to hardened.

What will you lose? Mainly, nvidia-drivers, ati-drivers, and skype. All three do at the moment not play nicely with hardened protection features. At least in the case of skype that is pure lazyness by the company; the programmers of skype could easily fix it if they wanted. In addition, the security benefits will lead to a performance hit; how much I cannot really judge yet.

What will you gain? For example, Stack Smashing Protector (SSP), Position Independent Executables (PIEs), Default full binding at load-time (BIND_NOW), ... There's a lot of documentation on hardened floating around, and I'm only just learning...

I'm running a full KDE desktop with radeon driver and accelerated graphics, so far I have not noticed any unpleasant side effects yet. I'll stay with it. :)

What about my precious Xpdf ?!?!?

I keep getting e-mails asking me why app-text/xpdf is masked for removal from the portage tree. It's getting too much to reply individually, so let me sum up the situation here in a blog post.

# Andreas K. Hüttel <dilfridge@gentoo.org> (27 Jan 2012)
# Has developed into an unmaintainable mess, and everyone who
# knows about it is either retired or missing in action.
# Several minor bugs and one ugly security issues (#386271).
# Masked for removal because of lack of maintainer.
# Please try app-text/epdfview as light-weight replacement.
app-text/xpdf

Xpdf is a package with a long history, and in a way a strange remnant of bygone times. Since PDF rendering is a function that many different programs could use, some years ago the Poppler library was forked from the Xpdf codebase. By now, Poppler is a much more active project, and used by dozens of packages in the Gentoo portage tree, all the way from LibreOffice and PDFTeX to Calligra, GIMP, and e.g. Okular or Evince. Being the more active project is important in this case, because PDF files are frequently shared and distributed and PDF rendering is thus a security-relevant task.
The original Xpdf remained independent of Poppler, not using the library - with the effect that every now and then security bugs kept popping up. Some time ago, some Gentoo developers started modifying and patching Xpdf to use the Poppler library. What resulted was the complicated construct that right now noone here is willing to maintain anymore. (Otherwise some Gentoo developer would have contacted me in the meantime.) Implementing a version bump to a more recent Xpdf version is a non-trivial task because all the Gentoo-specific patches have to be reviewed and if necessary rewritten.
Thus, app-text/xpdf needs to go the way of the dinosaur. Two alternatives exist, but both do not seem realistic at the moment:
1) We could go back to the original, unpatched Xpdf from upstream. I'm not going to do it, and I doubt anyone else of the Gentoo devs will.
2) Rogério Brito has started maintaining a fork of Xpdf at Github, which uses the Poppler library. However, there is no released version yet, and as he told me myself, he's rather busy in real life right now...
In the meantime, please try one of the following packages:

• app-text/zathura (based on poppler & gtk+)
• app-text/apvlv (based on poppler & gtk+)
• app-text/epdfview (based on poppler & gtk+, ~unmaintained)
• app-text/mupdf
• app-text/gv (based on ghostscript)
• app-text/evince (based on poppler, Gnome application)
• kde-base/okular (based on poppler, KDE application)
• app-text/acroread (yes I know...)

Ironically, the first mail reply to the last-riting of xpdf was from one of our security team members, promising me a beer the next time we meet in person. Only afterwards the complaints started.

Gentoo zero-day packaging of new KDE releases explained

Usually, whenever a new KDE release is published, Gentoo users can update already the same day, as suddenly a complete and polished set of ebuilds appears in the portage tree. (Stay tuned on upcoming wednesday for KDE 4.8.0, it's shaping up very nicely!) How is this possible? Well... let me explain.

If you're a stable version user, you may have never heard of so-called live ebuilds. This is a special variant, usually denoted by a version number ending in 9999, that does not rely on a source tarball. Instead, it contains a URL of a revsion control system (say on anongit.kde.org). When you emerge such a version of a package, the sources of the specified branch are checked out or updated to the newest upstream state, and that is used for building the installation package. Obviously this is not for everyone; depending how well upstream structures commits, things may not build for a while, contain fresh bugs, ... Also, reporting bugs from live versions on Gentoo bugzilla is discouraged as most of the times we can't do anything about it (do it only if you are sure it's a problem with the ebuilds, not with the source). If you're running live, you should be willing to hack yourself and work with upstream.

However, many of the Gentoo KDE team members run these live ebuilds, partly the current bugfix branch (i.e. KDE/4.8), partly even git master. They continuously keep the live ebuilds in the Gentoo KDE overlay updated to the newest state of the source. When a release is made, the corresponding live ebuilds of this branch are copied to the version ebuilds. For example, the KDE/4.8 branch live ebuilds have the version number 4.8.49.9999 (i.e.
kde-base/kdelibs-4.8.49.9999), so when the pre-release tarballs for KDE 4.8.0 were released to the packagers a few days ago, we only had to copy all 4.8.49.9999 ebuilds to 4.8.0 and immediately had a working set for testing. Most problems at that point are only caused by changes in tarball packaging. As distribution packagers get the pre-release tarballs (that still may change due to last-minute bugfixes) a week before the official release date, these can easily be fixed in time.

This also means that KDE maintenance in Gentoo is really a team effort. Whoever moves a released version to the main portage tree and/or commits bugfixes there builds on all the work that the team has done in the overlay in the meantime. Cheers!

Calling for brave testers: net-print/cups-1.5.0-r2

Maybe some of you have noticed that CUPS 1.5.0 is still hard-masked. Well, the reason for that is simple- at home, I'm nearly not printing at all, and at work, I have to rely on printing too much to tinker with it on the side a bit. So... if you would like to help, please unmask net-print/cups-1.5.0-r2 and give it a try. You will for sure find some problems, as the only thing I tested looong time ago was building it, never actually running it. Report them on bugs.gentoo.org, and we'll have a look... with a bit of luck, the package mask can then go away at some point. Any feedback (also positive) is appreciated. Cheers!

My personal KDEPIM upgrade status

Some time ago when we were filing the first stable request for KDE 4.7 I decided I'd have to give KDEPIM-4.7 also a try. I used to be a pine (and later alpine) user for ages, some time ago I switched to kmail1 (maybe at version 4.2 or so) and have been using it ever since... About the setup, incoming mail is stored and filtered server-side (Novell Groupwise), and accessed as disconnected IMAP.

1) Office desktop.
This one's usually running the latest and greatest KDE RC or beta, with a static IP and something like a 100MBps-FD link to the mail server. No local folders, so this was the natural candidate to test first. I did not even try the data migration, but wiped my entire local configuration of the KDEPIM programs as thoroughly as possible before updating. On the whole this went rather well. From 4.7.3 to 4.7.95 I've seen my share of kmail2 / kontact / akonadi crashes, but none of them really led to bigger problems. Impressively, I could also see each of these crash bugs I hit get fixed on KDE bugzilla in the meantime! Since upgrading to 4.7.97 I haven't had a crash anymore.
The only thing that is really bugging me a the moment is that I absolutely can't drag an e-mail message into another folder (I always have to right-click on the entry in the message list, select "Move to folder", ...). However, that is likely a problem in one of the underlying libraries. :| I would really like to help debugging this problem; if you can give me any clue where to look, please message...

2) Laptop.
Going home for christmas meant spending some time on a train. The days before I had upgraded this box to QT-4.8.0 and KDE+KDEPIM 4.7.95. Again, clean start with a new configuration. On the train I spent some time ironing out bugs there. The GPRS connection was happily going down and up again with every tunnel or less-populated countryside. That's when the akonadi backend started really acting up. When I arrived at my family's place, my e-mail had become fully non-functional (no fetching e-mails, no sending e-mails, the backend making kmail hang, regular crashes, and all fumbling with akonadiconsole did not help). After a while of trying, I gave up, wiped my entire KDEPIM configuration and data and downgraded to 4.4 again. I was impressed how responsive my e-mail program suddenly became.
Talking to other people, it seems that some have problems with bad internet connections, some don't. Maybe I should have used networkmanager, at least Alexxy reports that it's working fine with it.

3) Home desktop.
Well... Here I store my e-mail archive since 1996- that's maildir folders with roughly 50000 messages. Maybe I'll consider upgrading KDEPIM sometime around KDE 4.9.

I'm sorry if this blog entry is demotivating for the program developers. Some time ago I followed part of an animated discussion on irc between a kdepim user and a kdepim developer. Quoting a small part,

<user> first: fix bugs. second:dont change data formats. third: change gui only if absolutly nessary.
<developer> no
<developer> first: have fun; second: make it work for others

While this is of course oversimplifying, both points have clear validity, the first because people have come to rely on the software, the second because it's volunteer work by people enthusiastic about their creation. In the end we'll have to find a good compromise.

kdepimlibs-4.7.3 imap4 regression fix

Attention Gentoo users: If you're running kmail-4.4.11.1 and kde-4.7.3, and if you have been hit by bug 382411 (problems with local filters, cannot upload unread message on imap; see also here and here), please keyword kde-base/kdepimlibs-4.7.3-r1 and give it a try. (You may want to log out and log back in.) This upgrade seems to fix the problem... If I get some positive feedback, I'll fast-track it for stabilization. Cheers!