# Resistance is futile

In my childhood, I lived in conditions that would be considered poverty today, but were not uncommon at the time. For example, our apartment featured neither a toilet nor a bathroom or shower. The toilet was located half a floor down in the stairway, and we shared it with our neighbors. To take a bath instead of a quick wash, we had to visit the public bath. The stove was still coal-powered, and we relied on it for cooking and getting hot water for preparing coffee and tea as well as for washing dishes. In the winter, this stove was also used for heating, but the heat didn't spread far, and we had to put on several layers of clothing in the other rooms. As we had no place for a washing machine, the clothes had to be carried to the next laundromat once per week.

But we felt very comfortable, even privileged, since we enjoyed a number of household appliances that were not entirely obvious at this time. For example, we had a telephone, a huge table-top radio, and even a black-and-white cathode ray television set (which, I remember, was smaller than the radio) with three programs that signed-off at midnight. Plenty of entertainment for my parents, but I had lots of toys in addition, of course. And since my parents tried very hard to make me happy, I got the greatest gifts a boy could wish for at that time: a Märklin model railway and a Carrera slot-car race track.

Much to their disappointment, these electric gadgets held no fascination for me. I actually spent most of my spare time outside, playing soccer and swimming, and indoors I much preferred classic board games such as Mills and Checkers, and later Chess, which became kind of an obsession and occupied most of my time and attention in solitary concentration. To get me back to a social life, my parents very cleverly introduced me to classic card games, which I then started to study with three equally nerdy friends of mine. We played Rummy, Canasta, Whist and Bridge, but also the German classics Skat, Schafkopf, and Doppelkopf.

I've recently googled for these three friends, and found to my great delight that they have all made their way. A surgeon, an attorney, an engineer – and I became a physicist instead of an electrician, as my parents had planned. And I hope that for them the ability to play a variety of board and card games has been proven to be as useful as it has been for me. For example, when I arrived in Japan some 15 years later for my postdoctoral studies, I went to an English pub I knew from a conference after realizing how fundamentaly lonely I was. The time was early, long before it actually opened, but there was a girl behind the counter, waiting for the first guests, playing Backgammon with herself. It was my knowledge of Backgammon acquired 15 years ago that enabled me to play with her, earning me an invitation for a party where I would meet Susie from Kenya. But that's another story.😙

Nowadays, I keep an average household with regard to technology. It features all of the typical electrical appliances of western civilization, sprinkled with plenty of electronic gadgets, such as desktops, notebooks, tablets, e-book readers, and even a mobile phone, but it's not “smart”. In fact, so far I even didn't bother myself with a smartphone, as I didn't see any compelling reason for using a technology without having the slightest need for it. Worse, it seems that all gadgets with the attribute "smart" are essentially designed to collect as much data as possible about their unsuspecting, dumb users and send that data to various third parties who subsequently profit from it. And last but not least, I feel thoroughly repelled by the pathetic addiction of users to their smartphone, made evident by the innumerable smombies and nomophobes whose catatonic behavior I have to endure every day.

The first of these circumstances has changed very recently. In complying to the revised payment services directive of the EU, one of my banks has decided to terminate mTANs as a method of payment authorization. As alternative, they very prominently advertise an app-based authorization, although a photoTAN generator is in principle also available – but of course not compatible with any other bank. Should I pile up photoTAN generators on my desk or go for the smartphone? I pondered this question for a short time, but it was finally decided by unexpected circumstances turning up in an entirely different context: traveling in the age of the pandemic. My wife has important family business in Japan, and for her entry and the subsequent 14 days of quarantine, she will need no fewer than three apps on a smartphone, which can be either her own one, or has to be rented at the airport.

In view of this development, an attitude of denial would be donquixotesque. I decided that we would instead try to embrace the situation, and make the best out of the gadgets we are forced to acquire by circumstances. That shouldn't be too difficult, since I already knew from my experience with our Nexie that an Android device with small form factor can be great fun. However, there was no need to spend the obscene amounts of money the smartphone industry has somehow managed to establish, with price tags for the flagship phones having tripled over the last decade. Chapeau to the industry for the masterful creation of a new consumers desire leading to excessive debts particularly for the young generation. I'm quite immune to this attempt of seduction, and we consequently decided to look into the low- rather than the high-end.

Since I would be using my phone for security-critical tasks, the main criterion was the guaranteed availability of updates, which is the domain of the Google Pixel phones, a few of the top models from other manufacturers, and of phones running Android One, of which only the Nokias are left. After looking through the specifications, I settled on a Nokia 3.4, which seemed more than sufficient for the simple tasks I would need it for. For my wife, who will certainly enjoy playing an occasional game on her phone, I looked for a higher-class SoC than on the Nokia, and finally opted for the Motorola Moto G30. Both smartphones together came for less than €300, the maximum amount I had been willing to spend.

And you know what: I wouldn't have half of the fun with this little gadget if it hadn't been so affordable. I was a bit disappointed that the Android 11 upgrade didn't come earlier, but eventually it came, and the phone is currently running Android 11 with the latest patches (August 5). That's good enough for me to use it for the purpose I bought it for, i.e., as an authentication factor for my banks. But I also set it up as a general two-factor authentication device by installing and configuring andOTP for some of my most important accounts, such as the control panel of the server running this blog. Being thus an integral part of my security measures, it will securely stay at home, where it has already plenty of alternative uses. Here's one of them: I always wanted to have an HP 48, but never got it. Now I have one!

# Debian 11

Bullseye is stable, Bookworm is the new testing.

sed -i 's/bullseye/bookworm/g' /etc/apt/sources.list

# I can haz IP?

I have the strange habit to look up my external IP and to display it in the conky instance on my desktop (see here for an example). So far, I've got this IP directly from my Fritz!Box 7170, but the command I've used doesn't work with the new box (a 7590). I thus had to find a new way to get my IP.

There are plenty of websites returning the IP upon a simple connection by curl:

curl icanhazip.com
curl ifconfig.me
curl ipecho.net/plain
curl ifconfig.co
curl ipinfo.io/ip
curl -s checkip.dyndns.org | sed -r 's#(.*: )([0-9.]*)(<.*)#\2#'

There's also at least one DNS server offering this service:

dig +short myip.opendns.com @resolver1.opendns.com

But I would very much prefer a local solution as before. And it turns out that this solution exists: The package miniupnpc “enables applications to access the services provided by an UPnP ‘Internet Gateway Device’ present on the network. In UPnP terminology, MiniUPnPc is a UPnP Control Point.”

This package contains a command that retrieves the external IP from current Fritz!Boxes:

cobra at blackvelvet in ~
↪ external-ip
85.212.90.227

Bingo!

# New Neuland

It's high time to upgrade, I told myself, and consequently looked at the options available to someone living more or less in the center of the western part of Berlin. I had entertained the hope that when upgrading my connection, FTTH would be available, but as the matter stands the only affordable option is still VDSL. After my experiences with the Telekom, I was reluctant to again enter a relation with them, but I'm not too fond of the other big players (Vodafone, 1&1, O2) either. Fortunately, I've talked to my colleague Jonas about my plans, and he recommended easybell, a small regional provider with a clear focus on customer service. I very much liked what I saw and ordered their super-vectoring VDSL offering 250 Mbit/s down and 40 Mbit/s up. The whole procedure was transparent and very well documented, and the handover went as smoothly as possible: we got disconnected at 15:00, and when I finished setting up the new router at 15:30, it connected right away.

Woohoo! Now we're talking. 😎

The new router is a Fritz!Box 7590, and since its producer AVM is also located in Berlin, my internet connection is now a purely regional one. 😉 The 7590 does not support IEEE 802.11ax or Wi-Fi 6, which doesn't really matter for me since I don't have a single device that would support this standard. However, compared to the Fritz!Box 7170 I had before, the increase in wireless speed is impressive, much larger than I had expected. On my ten years old Fujitsu Lifebook, I never saw anything better than 10 Mbit/s with the 7170, but I'm getting a very stable 40 Mbit/s with the 7590. Makes a huge difference when using Mathematica via ssh -Y -C to my desktop: while the interface reacted sluggishly before, it's now downright snappy.

Alas, not all of my devices can actually benefit from the new and shiny wifi: my Nexie won't connect to it, and constitutes the collateral damage of this modernization. Debugging the attempts to connect returned the error message NETWORK_SELECTION_DISABLED_ASSOCIATION_REJECTION, which is caused by the activated “Protected Management Frames” for the login process (on the Fritz!Box: "Unterstützung für geschützte Anmeldungen von WLAN-Geräten (PMF) aktivieren"). Since this feature is required for WPA3 and thus the protection of my entire wireless network, I'm not willing to sacrifice it for one nine years old tablet, even when this tablet happens to be my beloved Nexie. Still, I will miss it, particularly since tablets with this diminutive size have been replaced entirely by phablets, and are not produced any more. And before you're going to argue like 'so-why-not-buying-such-a-phablet': I did exactly that, although for an entirely different reason, which I will disclose in a subsequent post.

# Hidden settings

Since I've quit KDE, and desktop environments in general, I'm primarily using applications developed for LXDE, XFCE, and Gnome. I have no problems with the former two, but I keep having conceptual difficulties with the ideologically driven minimalism of the latter. Take file managers and their associated terminal, for example. In PCManFM (LXDE), for example, one can change the associated terminal as expected in the program's preferences. Same in Thunar (XFCE). But of course not in Nautilus (Gnome) or any of its forks such as, for example, Nemo (Cinnamon). All of these “nonessential” settings have been dispelled to dconf, the ‘registry’ of Gnome, which can be accessed either with the dconf-editor or the command-line tool gsettings. For example, the following command changes the terminal associated with nemo to sakura:

gsettings set org.cinnamon.desktop.default-applications.terminal exec 'sakura'

I hope to remember that the next time instead of spending an eternity in the preferences again.

# Better annotations

A significant part of my daily work consists of critically reading drafts of publications or project proposals. I usually place hand-written comments on a printout of the respective document and discuss them with the author in my office, but that isn't such a good idea in the time of SARS-CoV-2. We hold these discussions now in video meetings, with the document in question being looked at together by sharing someones screen showing an annotated pdf. Now, I'm using evince to annotate pdfs, and didn't like the fact that all annotations seem to come from ‘Unknown’. In principle, that can be changed by editing the author in the annotation's properties, but I certainly would not have enjoyed doing that for each of the 80+ comments I had made for the present manuscript.

Alas, the official help told me that setting a different default author would not be possible. And that seemed final, since it came from the most authoritative source – the developers themselves. But I finally found a surprisingly simple solution in the place where, at this time, I had expected it least: the ArchWiki.. Shouldn't the developers know that evince looks into /etc/passwd? In any case, a simple

usermod -c “Deus ex machina” cobra

ensured that my comments would be now easily distinguishable from those of the other coauthors.

# Fast, faster, M1?

I should have created a category called “Modern advertisement techniques” or “How-the-media-manipulate-us-to-help-Apple-selling-its-products”. The crude attempts of the tabloid press are so glaringly obvious to anybody that they are more amusing than anything else. What I find far more disconcerting is the subtle approach one encounters in media of higher standard. At first the occasional inaccuracy or omission seems innocuous enough, but after a while it becomes clear that all of these apparent oversights and mishaps are invariably in favor of Apple, establishing an act of framing, deliberate or not. Here is one and here is another example of what I'm talking about.

Now, in June Apple announced that they are going to switch from Intel to ARM, and in November they announced the Apple M1 system-on-chip with their usual vastly exaggerated grandiose claims (3×, 6×, 15× faster!!!). One doesn't have to be the oracle of Delphi to predict the resulting media circus and the ever higher flying expectations based on nothing but hype.

Finally, some meaningful benchmarks (Cinebench R23) in c't 26/2020. Before examining and evaluating the numbers, here are two quotes from this issue:

p. 36 (Bit-Rauschen) Beim 15-W-Typ Ryzen 5000U wird es jedenfalls spannend, ob er zumindest bei Multithreading Apples-ARM-Renner M1 einholt und somit die x86-Ehre rettet.

p. 44 (Alles M1!) In der Single-Core-Performance enteilt der aktiv gekühlte M1 [...] allen bisherigen Mobilprozessoren der 15- bis 45-Watt-Klasse [...]. In der Multi-Core-Wertung sortiert er sich zwischen den 45-Watt-Mobil-CPUs Core i7-10750H (6300 Punkte) und Ryzen5 4600H (8370 Punkte) ein [...].

Now, these statements very clearly imply that the performance of the M1 surpasses that of any currently available 15-W mobile processor, wouldn't you say so?

Let's compare the single/multithreaded Cinebench R23 scores [1] of Intel's TigerLake top model and three Ryzen 7 4000U with those of the M1:

i7-1185G7               1538/6264
4700U                   1184(1218)/6874(7269)
M1                      1514(1517)/7760(7786)
4750U                   1184/8088
4800U                   1235/10156

As you can see, Apple has come up with a highly competitive chip offering a single-core performance on par with the 1185G7, and a multi-core performance just between the 4700U and the 4750U. But neither do we need a 45-W-CPU, nor the upcoming Ryzen 5000U to leave the M1 far behind in terms of multi-core performance: the 4800U does that well enough. And that's what I would have liked to read in an objective summary of the M1 instead of the distorted statements above.

The M1 is the first ARM-based processor that offers competitive performance for desktop applications. Is that the end of Intel and AMD? The loss of Apple as a major client may seem like an enormous loss for Intel, but actually it's a rather insignificant one, and some even believe it to be beneficial for them. Moreover, the M1 currently only runs on Apple hard- and software, resulting in a correspondingly small market share. More alarming, particularly for AMD with their hopes to break the dominance of Intel processors in data center and high-performance computing applications, is the current development of ARM-based server processors offering high performance for an affordable price. Remember when Linux-based x86 boxes replaced SPARC, MIPS, PA-RISC, and Power PC workstations running Solaris, IRIX, HP-UX, and AIX? That's just 11 years ago. Perhaps we are witnessing an analogous transition right now.

[1] A very similar comparison can be found, by the way, in the current issue of c't (Apfel-Alternativen, c't 1/2021, p.109). The values here are taken from cpu-monkey.com, and the ones in parentheses are from c't. If you have an older processor and would like to compare, chances are good that you find it in the comprehensive, community-compiled list at computerbase.de.

There are many examples of companies that didn't last very long after having been acquired by IBM. In a process called blue washing, IBM replaces the processes, corporate culture and philosophy of the new acquisition with those of its own. This routine inevitably leads to the complete assimilation and absorption of the company's original identity until nothing is left of it.

It is thus no surprise that IBM's spectacular takeover of Redhat in 2018 was met with considerable scepticism and sometimes outright concern. And rightly so: a few days ago Redhat announced the end of CentOS as we know it. Ironically, those who recently upgraded from CentOS 7 to CentOS 8 to get support until 2029 instead of 2024 now have only one year left.

CentOS Stream is not a viable replacement for the most common use case of CentOS, namely, running software suites certified for Redhat as I've described previously on this blog (part I, part II). New distributions filling the gap that CentOS will leave have been announced (Rocky Linux, Project Lenix), and we will see if and when they materialize, and how long they last. In the meantime, I'm glad that I generally avoided Linux distributions with a commercial background.

# Keep Alive

I'm so much used to mosh that I'm always surprised by how fast a plain ssh connection runs into a timeout. Or worse into a kind of half-terminated hanging connection with an apparently unresponsive terminal.

Which is weird, since there's already one measure in place that is intended to avoid this situation: TCPKeepAlive, which is enabled by default. To quote the man page of sshd_config:

On the other hand, if TCP keepalives are not sent, sessions may hang indefinitely on the server, leaving "ghost" users and consuming server resources. The default is yes (to send TCP keepalive messages), and the server will notice if the network goes down or the client host crashes. This avoids infinitely hanging sessions.

What irritates users most in this situation is the unresponsive terminal, which seems to no longer accept any commands, and won't close unless the ssh connection is terminated by killing the process. But there's no need to kill, as ssh offers several escape sequences that also take care of this case:

 ~.  - terminate connection (and any multiplexed sessions)
~B  - send a BREAK to the remote system
~C  - open a command line
~R  - Request rekey (SSH protocol 2 only)
~^Z - suspend ssh
~#  - list forwarded connections
~&  - background ssh (when waiting for connections to terminate)
~?  - this message
~~  - send the escape character by typing it twice
(Note that escapes are only recognized immediately after newline.)

To prevent this thing to ever happen again, two options can be set either on the server or the client.

On the server side, one can set the following options in /etc/ssh/sshd_config:

TCPKeepAlive no (default yes)
ClientAliveInterval 30
ClientAliveCountMax 240

To quote again the man page of sshd_config:

ClientAliveInterval Sets a timeout interval in seconds after which if no data has been received from the client, sshd(8) will send a message through the encrypted channel to request a response from the client. The default is 0, indicating that these messages will not be sent to the client.

ClientAliveCountMax Sets the number of client alive messages which may be sent without sshd(8) receiving any messages back from the client. If this threshold is reached while client alive messages are being sent, sshd will disconnect the client, terminating the session. The default value is 3. If ClientAliveInterval is set to 15, and ClientAliveCountMax is left at the default, unresponsive SSH clients will be disconnected after approximately 45 seconds. Setting a zero ClientAliveCountMax disables connection termination.

On the client side, corresponding options exist in etc/ssh/ssh_config, but changing them occurs better on a per-user basis in ~/.ssh/config (instead of adding them manually to each connecting ssh call via the -o command-line parameter):

TCPKeepAlive no (default yes)
ServerAliveInterval 30
ServerAliveCountMax 240

The meaning is the same as above, but the roles are reversed: now, the client sends an alive message to the server every 30 s, and the client drops the connection if it didn't receive an answer from the server within 2 hours.

It took quite some time until I realized that I don't get notifications anymore on any of my Arch-based installations, but when aarchup didn't chime up even after days, I've finally noticed that there must be something wrong.

The culprit is the new autostart file coming with xfce4-notifyd 0.6.2:

[Desktop Entry]
Type=Application
OnlyShowIn=XFCE;
cp /etc/xdg/autostart/xfce4-notifyd.desktop /home/cobra/.config/autostart/
G dd ZZ