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.