Text processors such as Libre/OpenOffice Writer and MS Office Word seduce users to write texts as if they were sitting in front of a mechanical typewriter. For example, the overwhelming majority of users invariably use a hyphen to represent any kind of dash in their text. They type an x for a multiplication sign, use " as quotation mark, approximate a right-pointing arrow by => and enclose a crystallographic orientation or an ensemble average by <>, the symbols actually denoting smaller than and larger than.

Now, the human mind is surprisingly flexible and also deals with texts barely recognizable as such. Sure, it takes time to decode the text, but in the present case, this task is reduced to identifying the 'wrong' symbols and their interpretation. And if the majority of people use the 'wrong' way, doesn't it become the 'right' one by the normative power of the factual?

Many of you will enthusiastically agree at this point. After all, language is a living thing and constantly evolving, and what's true for the spoken word must apply for the written one as well. Right?

Wrong. While we can accept a certain degree of ambiguity in situations where people directly communicate with each other (after all, you can ask), the meaning of any written account that is intended to last (such as scientific texts) should be clear. We should not accept misunderstandings arising from trivially avoidable mistakes.

To avoid such mistakes, you can chose the canonical way, or the hard way. The former consists in the use of LaTeX wherever possible — my toolchain (LaTeX-matplotlib-inkscape), for example, allows me to use LaTeX for every text I write and every figure I prepare.

The latter way relies on the unicode support of the programs you are using. For all applications conforming to ISO 14755, you can enter unicode by typing Ctrl+Shift+u, the unicode number, and pressing Enter. This method applies, for example, to all GTK+ applications. In particular, it works in Libreoffice and also in inkscape if you don't want to render your text using inkscape's LaTeX extension. But why would you?

Indeed, why. Unless you are able to memorize all unicodes you need, you got to get them from somewhere. Unicode catalogues are plagued with the inherent problem that you have to guess the correct search term, which may prove unexpectedly difficult. Or do you know the difference between braces, brackets and parentheses? I didn't think so.

Unicodeit came to rescue us from this problem, but creates an absurd situation: if you know LaTeX well enough to get the corresponding unicodes, you don't need the unicode since you can use LaTeX just as well.

But don't despair: most of the characters frequently used in correctly typeset plain texts can be entered directly via the keyboard. A few examples:

“Never”, she said.                  (AltGr-b, AltGr-n)
„Niemals“, sagte sie.               (AltGr-v, AltGr-b) 
«Jamais», dit-elle.                 (AltGr-x, AltGr-y)
The length is (4 ± 0.5) µm          (AltGr-Shift-9, AltGr-m)
1 € is good, but 99 ¢ is better     (AltGr-e, AltGr-c)
4×5=20                              (AltGr-Shift-,)
Magnitude of 7.5–7.7                (AltGr--)

Try to use Siri or Cortana for that.

The maintainer of #! (Crunchbang), corenominal aka Philip Newborough, has announced the end of its development: "It’s called progress, and for the most part, progress is a good thing. That said, when progress happens, some things get left behind [...]. I’m leaving it behind because I honestly believe that it no longer holds any value [...]."

With all due respect, but that is utter nonsense. Crunchbang is undoubtedly the most polished Openbox distro out there, has served me well over the past two years, and will continue to do so in the near future (I've just updated it to Jessie).

And comparing it to Lubuntu is ... well, it is beside the point. Lubuntu addresses an entirely different bunch of people as #!, and as such it isn't 'progress' (personally, I would rather call it regress).

Progress. Pffff.

My enthusiasm for Gnome was short lived. The ideas are certainly interesting, but they are not for me.

Here's my current desktop running openbox as window manager, tint2 as tray and taskbar (top), plank as launcher (bottom), and conky as information center (left and right).

I've been using cloud-based storage services to synchronize files between my different machines since years. Recently, I've synchronized active projects via the ownCloud server we've set up at the office. For private purposes, such as sharing cat photos with the family, I've used Wuala since it offered ample space for this purpose for free, featured client-side encryption, and used servers located in the EU.

In June 2014, Wuala announced a new pricing plan which included a termination of the free storage offer they had previously. However, the original press release also included the statement "Remaining customers will keep their free storage." All right.

This morning, I was thus mildly surprised to receive an e-mail from Wuala stating that I've exceeded my "available Wuala storage space". Starting the client told me that my "available Wuala storage space" is 0 bytes, which I've indeed exceeded. What happened?

It turned out that Wuala didn't keep their promise and didn't communicate their business moves properly. As documented by Caschy, Wuala changed the original press release in October 2014. I haven't received any mail regarding this change.

Instead, they now inform me "that we reserve the right to delete your account if you don't upgrade or delete files within the next 30 days."

And then: "We're sure that you will continue to enjoy the benefits of Wuala, the secure Cloud Storage."

Sure. :D

Here's one way to install a python-based blog such as Nikola. In principle, it's the same procedure as documented in a previous post, but I understand it better this time.

First, install the essential ingredients to create a virtual environment for python and friends and handle it in a convenient fashion:

sudo pacman -S python-virtualenv python-virtualenvwrapper

Second, create the virtual environment, install Nikola and all other things you need.

mkvirtualenv nikola
pip install Nikola
pip install requests
pip install livereload
pip install jinja2
pip install markdown
pip install webassets

If you don't know what you need:

pip install Nikola[extras]

Third, initialize your blog and install some plugins:

nikola init pdes-net.org
cd pdes-net.org/
nikola install_theme bootstrap /or any other/
nikola plugin -i localsearch
nikola plugin -i tags

Fourth, create a new post:

nikola new_post

Edit the new post with your favorite editor!

Fifth, after saving the new post, build and serve it:

nikola build && nikola serve

You can examine the result under http://localhost:8000. ALternatively, you can use

nikola auto

to be able to edit the post in quasi real-time. When you are satisfied, you can sync the result to your webspace using

nikola deploy

After all this work, you may have got tired of the whole business. Get out of it:

deactivate nikola

To start working again, issue

workon nikola

After a while,the whole machinery in your virtualenv is in dire need to be updated. How to do that? The easiest way is:

workon nikola
pip install pip-tools
pip-review --interactive

pip thus becomes a veritable package manager in its respective virtualenv. Not too bad.

The AUR offers a surprising number of perl modules, but from time to time I need one which I don't find there. Instead of bypassing the package manager and installing the module directly from CPAN, I use this way:

sudo pacman -S perl-cpanplus-dist-arch
setupdistarch 
cpanp -i Your::Module::Name

Clean and simple, just as I like it.

I will really miss them, but I can integrate them into my shell. I just feel sorry for you, since you won't get any fortunes in the future!

In case you didn't notice: I've switched from nanoblogger to Nikola, which doesn't have a fortune plugin (yet).

Why did I do that? Well, I've answered that question already quite some time ago.

And why Nikola, and not Acrylamid with which I flirted at that time?

Two reasons:

1. The ipynb support of Nikola. Since ipython notebooks seem to become my standard way of scientific computing and presentation, this feature — to which a whole blog is devoted— interests me greatly. Unfortunately, I couldn't get the search form working for Damian's theme, and I thus use a standard one for the time being.
2. Martin scared me away by ominous statements about the upcoming 0.8 release. For once, I wanted a (more or less) stable solution. I also wasn't sure about ipynb and MathJax support. I'm just a beginner and I'm feeling still quite unsure in the python blogging business.

Besides, I argued that once I made the transition, a change from Nikola to any other python based static blog compiler would be trivial (I may very well be wrong there).

Once I had decided that I'll use Nikola, I converted all my old posts from html to markdown with an adapted version of Bastian Rieck's nb2ikiwiki.

After that, I just installed Nikola and friends in a virtual environment. I'll list the commands required in a separate post. Of course there are still a few rough edges, but most things seem to work.

To soften the transition, here's the fortune of the day:

Let's say your wedding ring falls into your toaster, and when you stick your hand in to retrieve it, you suffer Pain and Suffering as well as Mental Anguish. You would sue:

• The toaster manufacturer, for failure to include, in the instructions section that says you should never never never ever stick you hand into the toaster, the statement "Not even if your wedding ring falls in there".

• The store where you bought the toaster, for selling it to an obvious cretin like yourself.

• Union Carbide Corporation, which is not directly responsible in this case, but which is feeling so guilty that it would probably send you a large cash settlement anyway.

Dave Berry

It turned out that my previous assessment of the situation I faced was too optimistic. After a further reboot, everything seemed fine at first, but then the system started to behave in ways which made me realize that it was destined to careen toward disaster. I thus examined the available snapshots (which, ironically, were the root of all these problems) and found some that still had retained their integrity. I rebooted and selected the most recent one by adding the following flag to the kernel line:

rootflags=subvol=.snapshots/10336/snapshot

After booting, my plan was to issue a

snapper rollback

and to roll safely back in time. This rollback, however, was only partly successful, since the corrupted snapshots couldn't be removed by any means, and the partition was thus subsequently and invariably mounted as read-only. Since everything was working fine except for my temporal inability to update the system, I let the issue rest until the bug would be reported as having been fixed.

After the fix was announced, I followed my fellow sufferers and tried to repair the filesystem from a live CD with an appropriately recent kernel and btrfs-progs version. In my case, I downloaded VoidBang and did a simple

btrfs check --repair /dev/sda1

Success! Well, at least the filesystem was mounted read/write again. But systemd, now suddenly able again to write to the disk, started to spit our error messages faster that I could read them. The situation got worse minute after minute.

All right all right, let's clean up this mess. *sigh*

A

dd bs=4M if=/home/cobra/Downloads/archlinux-2014.12.01-dual.iso of=/dev/sdb && sync

later, I was grudgingly reinstalling the system. Once you have done it more than twice, the installation of Archlinux is really straightforward and is finished in 15 min. The base system, mind you: for the rest I need a day a two if I don't install from a list of packages. In any case, since my /home was left untouched from the carnage of the amok-running btrfs, I expected that I would find everything as I've left it.

And then I started kmail, and didn't see a single e-mail in my folders.

It's not my first problem with kde in general and kmail in particular. This whole kde-pim/akonadi entanglement is so fragile that it breaks all the time and so complex that it's difficult to fix. Well, at least for me. But this time, I was really fed up and started to get a little mad.

After acquiring a certain amount of experience, old problems do not register as a challenge anymore, but as a nuisance. Solving them does not satisfy, but fatigue. We cease to perceive these problems as the life-threatening, adrenaline-pumping roller-coaster experiences which were so exciting when we met them the first time. Instead, we rightly feel that they are just plainly boring.

I suddenly desperately wanted something fresh, something entirely different, something I haven't touched in the last decade. No, neither Windows nor Mac OS — although the latter has indeed crossed my mind 😉 . Of all desktop environments and window managers, I realized that there was one I've never found the time to examine in detail, and which came up in 2011 with a rather radical (and highly controversial) redesign of the desktop paradigm. Let's have a look!

Here's my daily production history in FAH. Until November 4th, this was the output of two 24 core AMD Opteron workstations. From November 5th, a 32 core Intel Xeon E5 has been added for which I've promised benchmarks. Well, what would be better than FAH for benchmarking the performance of a system for scientific computing?

What we see here is that my 48 AMD cores have about one third (1/3) the performance of my 32 Intel cores. 'My', mind you, since this is not an entirely fair comparison: the Opterons are older models, while the Xeons are comparatively recent.

Alas, AMD has made only little progress, and the comparison wouldn't look that much different for more recent models from AMD. Right now, the only choice we have when performance is an issue is Intel.

What a pity.

If you're using btrfs and its snapshot function: stay away from kernel 3.17! It may corrupt your filesystem. I've just spent the better part of the morning trying to coax my desktop into getting back to its normal self.

After updating to 3.17 and editing syslinux.cfg to take care of the now manual microcode updates, I've noticed the following anomalies:

• KDE needed several minutes to start, just as every KDE application afterwards
• System load was high (up to 5) despite the fact that the system was essentially idling (no CPU or I/O activities)
• the btrfs formatted system partition switched to RO mode after a few minutes of use. WTF?
• after a further reboot with the microcode updates disabled, avahi didn't come up and journald dumped one core after the other (105, to be precise).
• oh, and there was no network at this point 😒

After rolling back to kernel 3.16.4, reinstalling systemd, and purging all (corrupted) journal files in /var/log/journal, the worst seems to be over.

Note that this bug is not restricted to users of Archlinux, but was reported by users of Fedora 20, Debian Sid, Gentoo, and OpenSUSE Tumbleweed.