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.

Thanks!!!

Thursday, February 4, 2016

Nanotechnology accepted: Co-sputtered MoRe thin films for carbon nanotube growth-compatible superconducting coplanar resonators

http://www.akhuettel.de/publications/remo.pdf
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)

Saturday, January 30, 2016

Gentoo at FOSDEM: Posters (systemd, arches)

Especially after Lennart Poettering made some publicity for Gentoo Linux in his keynote talk (unfortunately I missed it due to other commitments :), we've had a lot of visitors at our FOSDEM booth. So, because of popular demand, here are again the files for our posters. They are based on the great "Gentoo Abducted" design by Matteo Pescarin.  Released under CC BY-SA 2.5 as the original. Enjoy!



PDF SVG


PDF SVG

Tuesday, January 26, 2016

DFG magazine "german research" publishes article about our research group

http://www.akhuettel.de/publications/german-research.pdf
The 3/2015 edition of the "german research" magazine of the DFG includes an article about the work of our research group! This is a translation of a previous publication in the German language journal "Forschung" of the DFG. Enjoy!

"Carbon Nanotubes: Strong, Conductive and Defect-Free"
Carbon nanotubes are a fascinating material. In experiments at ultra-low temperatures, physicists make their different properties interact with one another - and in so doing find answers to fundamental questions.
Andreas K. Hüttel
german research 3/2015, 24-27 (2015) (PDF)

Friday, January 22, 2016

Please test www-apache/mod_perl-2.0.10_pre201601

We're trying to get both Perl 5.22 and Apache 2.4 stable on Gentoo these days. One thing that would be really useful is to have a www-apache/mod_perl that works with all current Perl and Apache versions... and there's a candidate for that: a snapshot of what is hopefully going to be mod_perl-2.0.10 pretty soon. So...

Please keyword (if necessary) and test www-apache/mod_perl-2.0.10_pre201601!!! Feedback for all Perl and Apache versions is very much appreciated. Gentoo developers can directly edit our compatibility table with the results, everyone else please comment on this blog post or file bugs in case of problems!

Please always include exact www-servers/apache, dev-lang/perl, and www-apache/mod_perl versions!

Friday, November 27, 2015

Grafting history onto your Gentoo git clone

Somehow after a while I got a bit tired that my git checkout of the main Gentoo repository didn't have any real history available. So, here's how I got it back:

(Note, you may want a fast network connection for this.)
  • cd into the main directory of the Gentoo git checkout:
$ cd ~/Gentoo/gentoo
  • fetch 2GByte of converted cvs history into a new local branch "history-20150809-draft"
$ git fetch https://github.com/gentoo/gentoo-gitmig-20150809-draft.git master:history-20150809-draft
  • attach the last commit of the cvs history to the first commit of the new git era
$ echo 56bd759df1d0c750a065b8c845e93d5dfa6b549d 2ebda5cd08db6bdf193adaa6de33239a83a73af0 > .git/info/grafts
And done. :)

Should at some point in the future a new, improved (or "official") conversion of the cvs history become available, here's (untested) what to do:
  • fetch it in the same way into a new local cvs history branch, and 
  • modify the grafts file to now connect the last commit of the new local cvs history branch with the first commit of the git era. 
Once you are happy with the result, you can delete the old local cvs history branch and run "git prune", freeing up the space used by the now obsolete old conversion.

Thanks to rich0 for providing the draft conversion (though inofficial so far) and to everyone else involved.