Cobra's bits (Posts about info)

Backdoor in xz

Cobra — Mon, 01 Apr 2024 11:50:12 GMT

The upstream xz repository and the xz tarballs have been backdoored.

This backdoor is very indirect and only shows up when a few known specific criteria are met. Others may be yet discovered! However, this backdoor is at least triggerable by remote unprivileged systems connecting to public SSH ports.

This supply-chain attack targets .deb- and .rpm-based distributions, but the backdoored versions of xz or xz-utils (5.6.0 and 5.6.1) have made it only into rolling-release distributions such as Fedora Rawhide, Debian Testing/Sid, OpenSuse Tumbleweed, and Archlinux (where it is inactive).

The server of this blog is running Debian Testing and had the compromised version of xz-utils installed since March 17. The backdoor was reported last Friday, March 29. I've installed the patch provided by Debian on Saturday, March 30, and examined the system logs, which do not show any evidence that the system has been compromised in any way. In fact, according to my current understanding, the system did not meet all the requirements for the backdoor to be executed. However, I will remain vigilant and let the users of the server know if further action needs to be taken.

More links (in German): Heise 30.03.2024 09:35, Heise 30.03.2024 22:28, Heise 02.04.2024 17:10

New Neuland

Cobra — Sat, 08 May 2021 17:11:15 GMT

In 1994, snafu.de provided my first home connection to the interwebs via a 33.6K (kbits/s) modem. The upgrade to 56K came only a year later, but being a speed freak, I soon abandoned snafu for the German telecom who offered ISDN (128K by channel bonding) and again one year later the first ADSL with 768K. Just two years later again the German telecom managed to piss me off so thoroughly that I quit them right away. I selected QSC as my post-Telekom provider, which was such a lucky choice that I stayed with them almost 20 years, starting with the symmetric 2 Mbit/s SDLS line in 2002 and upgrading to the mainstream ADSL2+ option in 2008. Compared to where we had been just a decade before, the speed offered by this technology was hardly believable. In 2021, however, the speed is lamentable. The upload of 1 Mbit/s is a liability in the time of daily video conferences, and the download of 16 Mbit/s is sorely testing my wife's patience during the many hours it takes to download an eagerly awaited and freshly purchased video game.

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.

Home Office

Cobra — Mon, 13 Apr 2020 17:20:56 GMT

The spread of SARS-CoV-2 has made it advisable for many people to work from home. I and my colleagues are doing that now for four weeks, and it's working very well. For me, home office isn't new: I use this possibility since a decade whenever I have a task at hand requiring particular concentration and focus. Writing papers or proposals is such a task, or developing and implementing a quantitative model to understand experimental data (that's what lucky physicists do for a living). In fact, I've been asked in January by colleagues to help with the development of such a model, which I thought to be challenging, but didn't expect to be as difficult as it actually turned out to be. For most of the time, I was rather cluelessly poking around in a forest of equations and not getting anywhere.

During the last days, I made an effort to refocus on this issue, and not only for a few hours, but a couple of days: you go to bed with the problem and wake up with it, and there's nothing to distract you from it. This kind of total concentration is simply not possible in the daily office routine, but I can do it at home, basically returning to my time as a student where every living moment was devoted to problem solving. What greatly helps with reaching this trance-like state is having no kids, an understanding wife, and softly purring cats that love to sleep in the chairs on my left and right. The breakthrough occurred after two days, all of a sudden, like a flash. I still had to solve technical problems, but the direction was clear. These are the moments that every scientist cherishes and holds most dear: the intense joy to have solved the problem, to have broken the code. 😌

I realize that not everybody has the same favorable boundary conditions as I do, or even the luxury to compare. And I understand that the situation is very different with young kids instead of cats. 😉 But still, I'm really tired reading commentaries in the newspapers moaning about the “solitary confinement”, and how unbearable it is. Most of them stem from rather young people with a smartphone glued to their right hand, and the strong belief to have the god-given right to party. Even worse are the characters with a political agenda, bitterly complaining about violations of our constitutional rights and predicting the end of democracy. What unites these two apparently very different groups is their failure to understand even the most simple arithmetic. And yes, there's no need for calculus to understand the simple concept of the exponential spread of a virus.

More realistic models are based on systems of differential equations similar to the ones describing the zombie apocalypse. The infection rate of the human population depends on the infection probability when a human and a zombie meet. Similarly, in epidemiology, the spread of an infectious disease is characterized by R0, the basic reproduction number. This number determines how fast the infection spreads (i.e., the slope of the exponential), and if it decreases with time (which is highly desirable), the curve “flattens”. The curve remains, however, an exponential as long as R0 > 1.

The greatest shortcoming of the human race is our inability to understand the exponential function. A. A. Bartlett

InspIRCd 3

Cobra — Sun, 25 Aug 2019 09:43:40 GMT

All of a sudden, the PdeS IRC channel wasn't working anymore. As inexplicable as this sudden disruption first appeared to be, as obvious are the reasons in hindsight. What has happened?

At August 18, apt offered an InspIRCd update, dutifully asking whether I wanted to keep the configuration files. I didn't realize at this moment that the update was in fact the upgrade from version 2 to 3 I had been waiting for since May. As a matter of fact, this update is disruptive and requires one to carefully review and modify the configuration of InspIRCd. Well, I failed to do that, and I also failed to notice that the InspIRCd service didn't restart after the update.

Sometimes people jokingly remark that I should work as a system or network admin rather than as a scientist. This incident shows that I'm not qualified for such a job. I'm way too careless.

In any case, I now had to find the reason for the InspIRCd service to quit. It wasn't too difficult, but a multi-step procedure. The first obstacle was an outdated apparmor profile, which allowed InspIRCd to write in /run, but not in /run/inspircd. That was easily fixed.

The second was the TLS configuration of our channel. I took the opportunity to renew our certificate and to altogether strengthen the security of the channel, but it took me a while to realize that the identifier in the bind_ssl and sslprofile_name tags has to be one and the same (it isn't in the documentation!).

<bind
          address=""
          port="6697"
          type="clients"
          ssl="pdes">

<module name="ssl_gnutls">

<sslprofile
          name="pdes"
          provider="gnutls"
          certfile="cert/cert.pem"
          keyfile="cert/key.pem"
          dhfile="cert/dhparams.pem"
          mindhbits="4096"
          outrecsize="4096"
          hash="sha512"
          requestclientcert="no"
          priority="PFS:+SECURE256:+SECURE128:-VERS-ALL:+VERS-TLS1.3">

Well, the channel is up again, more secure than ever. Fire away. 😅

Security headers

Cobra — Sat, 08 Sep 2018 10:48:31 GMT

A few simple provisions were sufficient to make this blog GDPR compliant. Even less was required to get a high rating regarding security. As a first step, I've obtained certificates from the Let's Encrypt initiative and configured Hiawatha (our web server) accordingly:

VirtualHost {
        ...
        TLScertFile = /etc/hiawatha/tls/pdes-net.org.pem
        RequireTLS = yes, 31536000; includeSubDomains; preload
        ...
}

This configuration got an A+ rating from Qualys SSL labs.

However, there's more to the security of a website than transport encryption. For example, the Content Security Policy “provides a standard method for website owners to declare approved origins of content that browsers should be allowed to load on that website”. There are actually a number of these security headers, and after some research I came up with the following settings:

VirtualHost {
        ...
        CustomHeader = Vary: Accept-Encoding
        CustomHeaderClient = X-Frame-Options: sameorigin
        CustomHeaderClient = X-XSS-Protection: 1; mode=block
        CustomHeaderClient = X-Content-Type-Options: nosniff
        CustomHeaderClient = X-Robots-Tag: none
        CustomHeaderClient = X-Permitted-Cross-Domain-Policies: none
        CustomHeaderClient = Referrer-Policy: same-origin
        CustomHeaderClient = Expect-CT: enforce; max-age=3600
        CustomHeaderClient = Content-Security-Policy: frame-src 'self'; worker-src 'self'; connect-src *; default-src 'self'; img-src 'self' data: chrome-extension-resource:; font-src 'self' data:; object-src 'self'; media-src 'self' data:; manifest-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline'; base-uri 'none'
        ...
}

The CSP proved to be tricky since Chromium did not display images in SVG format with stricter settings. A post of April King finally provided the missing piece of the puzzle. Furthermore, MathJax only works in my implementation if I allow scripts and styles to be included 'unsafe-inline'. As a result of this latter setting, my current configuration achieves only a 'B+' instead of the 'A+' depicted below.

Update: I've cleaned up and simplified the CSP, which now reads

CustomHeaderClient = Content-Security-Policy: frame-ancestors 'none'; frame-src 'self'; default-src 'self'; object-src 'none'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline'; base-uri 'none'; form-action 'none'

That still gets a 'B+' because of the 'unsafe-inline' options.

Mike Kuketz listed a number of online scanners evaluating the implementation of security policies on arbitrary web sites. One of the most informative one of these tools is Mozilla's observatory, developed by the same April whose post had helped me with the CSP. ☺

General Data Protection Regulation

Cobra — Sun, 13 May 2018 12:47:55 GMT

The new European data protection law (the GDPR, or DSGVO in German) will be in effect in exactly 12 days from now. Time to act! I basically had the choice between implementing a privacy policy detailing on several pages why I definitely need to use all these external services, and finding alternatives. Well, since I very much prefer technical solutions over legal ones, the choice wasn't too difficult. 😉

I've used Google Analytics mainly for two reasons: first, I like to look at aggregate statistical data, and second, I don't see the evil in it. The user can block this external service in uncountable ways, for example, by simply rejecting the corresponding cookie, or by installing a script- or adblocker. Instead of creating a monstrous legal construct such as the GDPR, one should rather educate users to take care of themselves again. But the data protection industry only exists since these things are massively blown out of proportion, and of course they serve their own interests. They like to see the users as drooling rugrats, and they like to keep them like that. Well, that's the general trend of all western societies.

c't-Schlagseite von Ritsch+Renn in c't 11/2018

Anyway, since I recently integrated a black list into my local DNS resolver, it's actually not that simple anymore to access the Google analytics domain. 😄 Furthermore, I'm interested how many of my readers actually block Google Analytics. And most importantly, I thought it would be a good idea to take the opportunity to get rid of this proprietary garbage. 😊

I thus searched for local web analyzers and came across several, but took an immediate liking in goaccess. It's easily installed and even easier to use:

# echo "deb http://deb.goaccess.io/ $(lsb_release -cs) main" | tee -a etc/apt/sources.list.d/goaccess.list
# wget -O - https://deb.goaccess.io/gnugpg.key | apt-key add -
$ sudo apt update
$ sudo wajig install goaccess

Goaccess comes preconfigured with the log formats of the most popular web servers, but for Hiawatha, our web server of choice, manual configuration was required. Fortunately, I found all relevant information in the Hiawatha forum:

time-format %T %z
date-format %a %d %b %Y
log-format %h|%d %t|%s|%b||%r|%v|%u|%^|%^|%^|%R|%^|%^

Since the reports of goaccess are directly generated from the access logs of the web server, I anonymized the IP by activating the

anonymizeIP = yes

option in /etc/hiawatha/hiawatha.conf.

Finally, I configured goaccess to automatically generate html reports. Logrotate takes care of periodically deleting the logs (which don't contain personal information anyway). The reports, by the way, show that at least 75% of all visitors of this site block Google Analytics. Excellent! Also, I'm happy to see that I have four times as many readers than I thought. 😉

The next task was a local installation of the Google fonts I'm using. That was very quickly done by cloning the bash script 'best-served-local' of Ronald van Engelen and running it:

git clone https://github.com/ronalde/best-served-local
cd best-served-local
./best-served-local -i ../static/fonts "Kreon:300,400,700" > ~/temp/fonts/kreon.css
./best-served-local -i ../static/fonts "Fira Mono:400,700" > ~/temp/fonts/fira.css

The css snippets thus created have to be included in the main css file of the blog's theme, which in my case is a modified bootstrap. The fonts themselves go into ../output/assets/static/fonts (that has to be consistent with the option for the command line parameter -i above).

Next, I wanted to get rid of the dependency on an external resource for MathJax. I struggled first with a local installation of KaTeX, but couldn't get it to work. MathJax instead was very easy. I simply installed libjs-mathjax and fonts-mathjax on pdes-net.org, and copied it to a location accessible to the webserver

cp -r /usr/share/javascript/mathjax/ /var/www/hiawatha/cobra/output/assets/static/mathjax/

and back to my local blog installation

scp -r cobra@netcup:/var/www/hiawatha/cobra/output/assets/static/mathjax/ home/cobra/ownCloud/MyStuff/Documents/pdes-net.org/output/assets/static/

Finally, the Nikola configuration file had to be updated correspondingly:

<script src="../assets/static/mathjax/MathJax.js?config=TeX-AMS_SVG"></script>

Finally, the search box on this site already works on the client side by virtue of tipuesearch. So, I was done!

Ah, not entirely: I still had to update my contact page. After doing that, I also moved the link to the bottom of the page as its customary on most sites.

Well, when I look at the result, I'm actually quite pleased. I feel that I have really done something for the good of my visitors, instead of continuing to act as a data collector for Google and others, and justifying that by tons of legal mumbo-jumbo in a privacy policy nobody reads or understands. But IANAL, and it is likely that this particular species actually prefers the latter, no matter what the GDPR says about transparency and plain language. Let's see.

Let's encrypt

Cobra — Sat, 17 Feb 2018 12:47:02 GMT

Ever since I've set up the new server for this blog, I've wanted to make the switch from plain HTTP to TLS-encrypted HTTPS (if you think HTTPS is for online shops and banks only, think again).

This transition turned out to be much easier than I thought. Hiawatha, our web server of choice, comes with a script that takes care of registering the site at Let's Encrypt and requesting certificates for the associated domain(s). Chris Wadge, the maintainer of Hiawatha for Debian, provided an excellent tutorial guiding through the few steps necessary to configure Hiawatha for serving HTTPS content.

Since I had to configure vhosts for the certificates anyway, I took the opportunity to set up some proper subdomains. For example, this blog can now be reached at https://cobra.pdes-net.org.

After a bit of tweaking (setting HSTS to one year), the security rating of our site is flawless:

Meltdown patch available for Arch

Cobra — Thu, 04 Jan 2018 16:34:04 GMT

If you haven't heard of Meltdown and Spectre, it's about time you do. Since yesterday, all newspapers and even TV provide extensive coverage on a recently discovered vulnerability of modern CPUs potentially resulting in a leak of sensitive data. While Meltdown seems to primarily affect all modern Intel CPUs, Spectre also applies to AMD and ARM chips. The scale of this vulnerability is not only unprecedented, it's historic.

The KPTI (formerly KAISER) patch developed by the University of Graz defeats Meltdown. The patch is part of the coming Linux kernel 4.15 and has already been backported to 4.14.11.

Which brings me to the good news for Archers like myself: Kernel 4.14.11 is available since yesterday, 8:13 CET. Spectacular work from upstream, but also from the Arch team! No new microcode, though – the currently available one is still from 17th of November.

CentOS just provided patches as well. There's nothing from Debian yet, however. 😞

Oh, and I've just received a mail from the hoster of pdes-net.org. Good to see they react at once.

What a great start of 2018. Well, regardless, happy new year to all of you. 😉

Update: An in-depth analysis of the mechanisms resulting in meltdown and spectre can be found in an online article (in German) written by the legendary Andreas Stiller (who, most unfortunately, retired at the end of 2017).

Representative surveys

Cobra — Sun, 25 Jun 2017 14:34:20 GMT

Statistical surveys are a standard tool of sociology, and have been the subject of extensive research. In the hands of professionals, the results of these surveys can be surprisingly accurate. As a result, surveys have attained the status of the oracle of Delphi, and people fervently believe in them. Naturally, this development has made surveys an attractive tool for manipulating public opinion. The standard way to do this is to load the questions with a moral obligation. Don't you agree that the internet should be regulated to deprive extremists of their safe spaces online? No? Really, what a kind of person are you? Don't you ever think of the children?

However, unexpected results of surveys do not always have sinister reasons, but may instead simply reflect the incompetence of the inquirer. In particular, the most elementary rule for designing a survey is frequently forgotten: namely, that those taking part in the survey have to understand the questions. Sounds obvious, doesn't it? But is it?

An example: the recent news of heise online that only(!) 16% percent of all Germans encrypt their emails (Umfrage: Nur 16 Prozent der Deutschen verschlüsseln ihre E-Mails). This survey was conducted by Convios Consulting on behalf of United Internet (UI), one of the largest internet and mail providers in Germany.

UI claims that about 750,000 of their users have generated PGP key pairs. That's a very impressive number, particularly since according to UI, only 4.7 million keys “exist” worldwide. The UI users would thus account for 16% of all PGP keys. Doesn't that demonstrate very nicely that UI's encryption initiative introduced in August 2016 is highly successful?

Well, the whole reason for the survey was to create exactly this impression. I have no doubts that the numbers quoted above are correct, but what do they mean?

First of all, the number reported for the existing keys worldwide only accounts for the keys that have been deposited on key servers. Nobody can estimate how many keys have actually been generated or are in use. That's quite different in the case of the UI encryption scheme, which is based on mailvelope, and the storage of the public key of the user in a database located on a UI server. The number given above is thus the total number of UI customers with a PGP key, unless they use a separate key in a stand-alone MUA (of which I know two 😉).

There are about 40 million email users in Germany. According to UI, about half of them use GMX or WEB.DE, which seems reasonable as UI is reported to have close to 20 million customers. Now, let's suppose that all UI customers who have generated a key are also actually using it to encrypt their mail. In this unlikely case, 3.75% of all UI users would encrypt their mail, much less than the “only 16%” of their survey. Obviously, that must mean that 28.25% of the other 20 million email users in Germany, who are mostly customers of the German Telekom, Google, and Microsoft, encrypt their mail. Right?

Of course not. Try to ask arbitrary Gmail users if they encrypt their mail. 84% will look at you with with blank eyes, but 16% will recognize the word and confirm that they do, YES! Ask them afterwards if they know the difference between transport and end-to-end encryption. I guarantee that you will soon get tired of asking people because even after several hundreds you won't find a single one who can answer your second question...

How many people do encrypt their mails? I don't think there exist any bona fide surveys on that topic. I can only provide anecdotal evidence with very limited statistical significance. On the other hand, I've been a serious advocate of end-to-end-encryption since about 15 years. I've written tutorials and motivated many of my personal contacts to use end-to-end encryption in email and messenging. Well, some would say I forced them at gunpoint. But that would be exaggerated...

I have currently 49 personal contacts with public PGP keys, and 16 business contacts. That doesn't sound too bad, does it? However, 17 and 4 of these keys are expired, leaving 32 and 12, respectively. Subtracting keys whose pass phrases have been forgotten by their users or were otherwise disposed of leaves 19 and 7. Some of my contacts have passed away, are retired, or I've simply lost touch, leaving in the end 4 and 5 with which I can, in principle, exchange end-to-end encrypted mails. Actually, however, there are only three persons with whom I regularly exchange encrypted mails: my patent attorney at work and my fellow PdeS (that's why they have that label) in actual life.

Three out of 65 with an actively used key, but of how many without any clue what that even means? I don't want to spent time on the question of how I could count the number of unique addresses in my mail folders over the past few years. But obviously, this number would be in the several hundreds. In other words, the total percentage of people employing end-to end-encryption in my emails is way lower than 1%. And if I wouldn't be interested in these kind of things, and if I wouldn't be a scientist, this percentage would be exactly zero. Not 16%. Not 0.16%. Zero.

Can we find out how many people really encrypt their mails by a survey? Not really. If less than 100 ppm of all people encrypt (which is the number I find most plausible), we would need a mega-survey over 50000 people to include at least 5 people who actually do encrypt, and that's never going to happen. And don't let them tell you that the rules of statistics somehow don't apply there and representative surveys can answer all of these questions as if by magic. That's bullshit. All of it.

In the old days

Cobra — Sat, 03 Sep 2016 12:43:46 GMT

Research places like the one I'm associated with are characterized by a constant turnover of personnel. Currently, our 20 senior scientists are supported by about 50 assistant and associate researchers on temporary positions. Our annual turnover rate is thus as high as 30 to 40%, meaning that I meet about 15 to 20 new people every year.

The level of understanding in physics and material science fluctuates, but does not seem to deteriorate over the years. That's the good news. What does decline significantly is the ability to read and write and to use a computer efficiently. At the same time, the fraction of people with an undue sense of entitlement is growing dramatically.

What do I call an “undue sense of entitlement”? Well, imagine. It's your first day at a new place where you hope to perform top-notch research yielding results important enough to publish them in prestigious journals. You are shown into your office, which you share with some more experienced colleagues, and on your desk sits a brand-new 24 inch Full-HD display connected to an equally brand-new desktop computer. And exactly that's the moment when you demand, loud and clear, two monitors. The bigger the better! And an hour later, you call our IT service to demand the real Office. And Photoshop! When the IT freaks ask for which purpose you need this software, you most strongly express your righteous indignation. First of all, that's none of his business, and second, that should be obvious! After all, you have letters to write. And later, there may be images whose contrast needs to be increased.

Now, that's exactly what you would do, right?

No, of course not. No halfway sensible person would behave in this way. Alas, every year we get more and more young people with this attitude. Experience tells us that the people demanding the most are the ones returning the least. They also tend to create constant trouble: they are more concerned with their own self-importance than with their research, and are generally ignorant, obnoxious, and unproductive.

I still vividly remember my own time as a PhD student at the MPI-FKF. I had previously written my diploma thesis on an HP Vectra, an IBM AT compatible, which I had to share with the six or seven members of our research group. At the weekends, I also had access to my own computer, an Schneider PC1512 that I primarily used for running Pascal programs. God, did it feel slow compared to the Vectra at work! At the MPI, however, computing was not yet “personal”. Instead, VT220 text terminals were offered for the interaction with the VAX station in the basement. I'd say we had perhaps 20 terminals for about 300 scientists.

Basically, these terminals were used for three essential tasks. First, one could receive and send e-mails using the 'mail' program. That was my first contact with the Internet and I found it exciting! Second, we wrote our manuscripts using EVE, the extensible versatile editor, compiled them with LaTeX, converted the resulting dvi file to postscript with dvips, and used lpr to send the postscript output to one of the three or four Hewlett-Packard LaserJets located at strategic locations (mine was close to the beer machine¹) in the institute. The VT220 could not display any graphics, so we had to print to see if our LaTeX code did what we wanted! Third, EVE was also used to write FORTRAN code, and there were always a number of computations running on our VAX. I do not remember which model we had, but a VAX 6360 from 1988 had six processors clocked at 16.7 MHz and an estimated performance of 22 MIPS, all for a meager $752K. A high-end smartphone is easily 1000 times as fast.

Just that you have an idea of how it feels to work on a VT220, here's an impression recorded by jstn. The little cube on the left is the VT220 displaying a terminal of the Mac Pro it is connected to.

Between January 1990 and September 1991, I wrote 10 manuscripts on this little cube as the first author (all of which got published) followed by my dissertation which I've submitted just before Christmas 91. How I did that? Instead of complaining, I typed.

¹ Yes, you heard right: we had a beer machine. All right, it was actually a standard soda machine, but it offered two kinds of beer in addition to Coke and Co.: Stuttgarter Hofbräu Pils and Export, if I remember correctly. The machine was heavily frequented and we had the most illuminating discussions in the park just outside the canteen, where the beer machine—and the printer—were located. Many great ideas originated from these discussions. Nowadays, where people wear a helmet when going to the loo, that's unimaginable.