Thursday, February 9, 2017

Gentoo LiveDVD "Crispy Belgian Waffle", FOSDEM 2017 edition

So, FOSDEM 2017 is over, and as every year it was both fun and interesting. There will for sure be more blog posts, e.g., with photographs from talks by our developers, the booth, the annual Gentoo dinner, or (obviously) the beer event. The Gentoo booth, centrally located just opposite to KDE and Gnome and directly next to CoreOS, was quite popular; it's always great to hear from all the enthusiastic Gentoo fans. Many visitors also prepared, compiled, and installed their own Gentoo buttons at our button machine.
In addition we had a new Gentoo LiveDVD as handout - the "Crispy Belgian Waffle" FOSDEM 2017 edition. For those of you who couldn't make it to Brussels, you can still get it! Download the ISO here and burn it on a DVD or copy it on a USB stick - all done. Many thanks to Fernando Reyes (likewhoa) for all his work!
Finally, for those who are wondering, the "Gentoo Ecosystem" poster from our table can be downloaded as PDF here. It is based on work by Daniel Robbins and mitzip from Funtoo; the source files are available on Github. Of course this poster is continous work in progress, so tell me if you find something missing!

Friday, September 16, 2016

PRL accepted: Secondary electron interference from trigonal warping in clean carbon nanotubes
We're very happy to announce that a few days ago one of our manuscripts, "Secondary electron interference from trigonal warping in clean carbon nanotubes", was accepted for publication in Physical Review Letters

Imagine a graphene "sheet" of carbon atoms rolled into a tube - and you get a carbon nanotube. Carbon nanotubes come in many variants, which influence strongly their electronic properties. They have different diameter, but also different "chiral angle", describing how the pattern of the carbon atoms twists around the tube axis. In our work, we show how to extract information on the nanotube structure from measurements of its conductance. At low temperature, electrons travel ballistically through a nanotube and are only scattered at its ends. For the quantum-mechanical electron wavefunction, metallic nanotubes act then analogous to an optical Fabry-Perot interferometer, i.e., a cavity with two semitransparent mirrors at either end, where a wave is partially reflected. Interference patterns are obtained by tuning the wavelength of the electrons; the current through the nanotube oscillates as a function of an applied gate voltage. The twisted graphene lattice then causes a distinct slow current modulation, which, as we show, allows a direct estimation of the chiral angle. This is an important step towards solving a highly nontrivial problem, namely identifying the precise
molecular structure of a nanotube from electronic measurements alone.

"Secondary electron interference from trigonal warping in clean carbon nanotubes"
A. Dirnaichner, M. del Valle, K. J. G. Götz, F. J. Schupp, N. Paradiso, M. Grifoni, Ch. Strunk, and A. K. Hüttel
accepted for publication in Physical Review Letters; arXiv:1602.03866 (PDF, supplemental information)

Friday, July 8, 2016

Lab::Measurement 3.512 released

Immediately at the heels of the previous post, I've just uploaded Lab::Measurement 3.512. It fixes some problems in the Yokogawa GS200 driver introduced in the previous version. Enjoy!

Tuesday, July 5, 2016

Lab::Measurement 3.511 and Lab::VISA 3.04 released

It's been some time since the last Lab::Measurement blog post; we are at Lab::Measurement version 3.511 by now. Here are the most important changes since 3.31:
  • One big addition "under the hood", which is still in flux, was a generic input/output framework for status and error messages. 
  • The device cache code has seen updates and bugfixes. 
  • Agilent multimeter drivers have been cleaned up and rewritten. 
  • Minimal support has been added for the Agilent E8362A network analyzer.
  • The Oxford Instruments IPS driver has been sprinkled with consistency checks and debug output, the ITC driver has seen bugfixes.
  • Controlling an Oxford Instruments Triton system is work in progress.
  • The Stanford Research SR830 lock-in now supports using the auxiliary inputs as "multimeters" and the auxiliary outputs as voltage sources.
  • Support for the Keithley 2400 multimeter, the Lakeshore 224 temperature monitor, and the Rohde&Schwarz SMB100A rf-source  has been added.
  • Work on generic SCPI parsing utilities has started.
  • Sweeps can now also vary pulse length and pulse repetition rate; the "time sweep" has been enhanced.
  • Test routines (both with instruments attached and software-only) are work in progress.
 Lab::VISA has also seen a new bugfix release, 3.04. Changes since version 3.01 are:
  • Support for VXI_SERVANT ressources has been removed; these are NI-specific and not available in 64bit VISA.
  • The documentation, especially on compiling and installing on recent Windows installations, has been improved. No need for Visual Studio and similar giga-downloads anymore!
  • Compiling on both 32bit and 64bit Windows 10 should now work without manual modifications in the

Thursday, May 26, 2016

Akonadi for e-mail needs to die

So, I'm officially giving up on kmail2 (i.e., the Akonadi-based version of kmail) on the last one of my PCs now. I have tried hard and put in a lot of effort to get it working. However, it costs me a significant amount of time and effort just to be able to receive and read e-mail - meaning hanging IMAP resources every few minutes, the feared "Multiple merge candidates" bug popping up again and again, and other surprise events. That is plainly not acceptable in the workplace, where I need to rely on e-mail as means of communication. By leaving kmail2 I seem to be following many many other people... Even dedicated KDE enthusiasts that I know have by now migrated to Trojita or Thunderbird.

My conclusion after all these years, based on my personal experience, is that the usage of Akonadi for e-mail is a failed experiment. It was a nice idea in theory, and may work fine for some people. I am certain that a lot of effort has been put into improving it, I applaud the developers of both kmail and Akonadi for their tenaciousness and vision and definitely thank them for their work. Sadly, however, if something doesn't become robust and error-tolerant after over 5 (five) years of continuous development effort, the question pops up whether the initial architectural idea wasn't a bad one in the first place - in particular in terms of unhandleable complexity.

I am not sure why precisely in my case things turn out so badly. One possible candidate is the university mail server that I'm stuck with, running Novell Groupwise. I've seen rather odd behaviour in the IMAP replies in the past there. That said, there's the robustness principle for software to consider, and even if Groupwise were to do silly things, other IMAP clients seem to get along with it fine.

Recently I've heard some rumors about a new framework called Sink (or Akonadi-Next), which seems to be currently under development... I hope it'll be less fragile, and less overcomplexified. The choice of name is not really that convincing though (where did my e-mails go again)?

Now for the question and answer session...

Question: Why do you post such negative stuff? You are only discouraging our volunteers.
Answer: Because the motto of the drowned god doesn't apply to software. What is dead should better remain dead, and not suffer continuous revival efforts while users run away and the brand is damaged. Also, I'm a volunteer myself and invest a lot of time and effort into Linux. I've been seeing the resulting fallout. It likely scared off other prospective help.

Question: Have you tried restarting Akonadi? Have you tried clearing the Akonadi cache? Have you tried starting with a fresh database?
Answer: Yes. Yes. Yes. Many times. And yes to many more things. Did I mention that I spent a lot of time with that? I'll miss the akonadiconsole window. Or maybe not.

Question: Do you think kmail2 (the Akonadi-based kmail) can be saved somehow?
Answer: Maybe. One could suggest an additional agent as replacement to the usual IMAP module. Let's call it IMAP-stupid, and mandate that it uses only a bare minimum of server features and always runs in disconnected mode... Then again, I don't know the code, and don't know if that is feasible. Also, for some people kmail2 seems to work perfectly fine.

Question: So what e-mail program will you use now?
Answer: I will use kmail. I love kmail. Precisely, I will use Pali Rohar's noakonadi fork, which is based on kdepim 4.4. It is neither perfect nor bug-free, but accesses all my e-mail accounts reliably. This is what I've been using on my home desktop all the time (never upgraded) and what I downgraded my laptop to some time ago after losing many mails.

Question: So can you recommend running this ages-old kmail1 variant?
Answer: Yes and no. Yes, because (at least in my case) it seems to get the basic job done much more reliably. Yes, because it feels a lot snappier and produces far less random surprises. No, because it is essentially unmaintained, has some bugs, and is written for KDE 4, which is slowly going away. No, because Qt5-based kmail2 has more features and does look sexier. No, because you lose the useful Akonadi integration of addressbook and calendar.
That said, here are the two bugs of kmail1 that I find most annoying right now: 1) PGP/MIME cleartext signature is broken (at random some signatures are not verified correctly and/or bad signatures are produced), and 2), only in a Qt5 / Plasma environment, attachments don't open on click anymore, but can only be saved. (Which is odd since e.g. Okular as viewer is launched but never appears on screen, and the temporary file is written but immediately disappears... need to investigate.)

Question: I have bugfixes / patches for kmail1. What should I do?
Answer: Send them!!! I'll be happy to test and forward.

Question: What will you do when Qt4 / kdelibs goes away?
Answer: Dunno. Luckily I'm involved in packaging myself. :)

Tuesday, May 24, 2016

kmail 16.04.1 and Novell Groupwise 2014 IMAP server - anyone?

Here's a brief call for help.

Is there anyone out there who uses a recent kmail (I'm running 16.04.1 since yesterday, before that it was the latest KDE4 release) with a Novell Groupwise IMAP server?

I'm trying hard, I really like kmail and would like to keep using it, but for me right now it's extremely unstable (to the point of being unusable) - and I suspect by now that the server IMAP implementation is at least partially to blame. In the past I've seen definitive broken server behaviour (like negative IMAP uids), the feared "Multiple merge candidates" keeps popping up again and again, and the IMAP resource becomes unresponsive every few minutes...

So any datapoints of other kmail plus Groupwise imap users would be very much appreciated.

For reference, the server here is Novell Groupwise 2014 R2, version 14.2.0 11.3.2016, build number 123013.


Thursday, February 4, 2016

Nanotechnology accepted: Co-sputtered MoRe thin films for carbon nanotube growth-compatible superconducting coplanar resonators
We're happy to be able to announce that our manuscript "Co-sputtered MoRe thin films for carbon nanotube growth-compatible superconducting coplanar resonators" has just been accepted for publication in Nanotechnology.
For quite some time we have been working on techniques to combine ultra-clean carbon nanotubes and their regular electronic spectrum with superconducting material systems. One of our objectives is to perform high-frequency measurements on carbon nanotube nano-electromechanical systems at millikelvin temperatures. With this in mind we have established the fabrication and characterization of compatible superconducting coplanar resonators in our research group. A serious challenge here was that the high-temperature process of carbon nanotube growth destroys most metal films, or if not, at least lowers the critical temperature Tc of superconductors so much that they are not useful anymore.
In the present manuscript, we demonstrate deposition of a molybdenum-rhenium alloy of variable composition by simultaneous sputtering from two sources. We characterize the resulting thin films using x-ray photoelectron spectroscopy, and analyze the saturation of the surface layers with carbon during the nanotube growth process. Low-temperature dc measurements show that specifically an alloy of composition Mo20Re80 remains very stable during this process, with large critical currents and critical temperatures even rising to up to Tc~8K. We use this alloy to fabricate coplanar resonator structures and demonstrate even after a nanotube growth high temperature process resonant behaviour at Gigahertz frequencies with quality factors up to Q~5000. Observation of the temperature dependent behaviour shows that our devices are well described by Mattis-Bardeen theory, in combination with dissipation by two-level systems in the dielectric substrate.

"Co-sputtered MoRe thin films for carbon nanotube growth-compatible superconducting coplanar resonators"
K. J. G. Götz, S. Blien, P. L. Stiller, O. Vavra, T. Mayer, T. Huber, T. N. G. Meier, M. Kronseder, Ch. Strunk, and A. K. Hüttel
accepted for publication in Nanotechnology; arXiv:1510.00278 (PDF)