Digital signatures

Our administration now requests all documents to be digitally signed, with a certificate that each employee receives from the DFN. Windows and Mac users employ Acrobat Reader for this purpose, but what software can be used under Linux?

My first choice was LibreOffice, which has offered this functionality already for several years. Signing a pristine pdf works well indeed, apart from the fact that LibeOffice does not create a placeholder for the signature. However, signing a document that has already been signed by Window users turned out to be simply not possible (here's the 12 years old bug reportand here's the inverse one that is just as old).

The next candidate was Okular, the PDF viewer of KDE, which has been sponsored by the University of Dresden to implement this functionality. But only half-way, it seems to me. I could sign most (but not all) documents, but I couldn't configure the placeholder at all. As the font size in the signature box does not scale with the size of the box, the name of the person signing is often cut off. How difficult can it be to implement such a very basic and obvious requirement?

Finally, I turned to Master PDF Editor, which I've occasionally used in the past for annotations when Evince did not yet offer this possibility. I was actually not surprised that this feature-rich PDF editor also offers digital signatures, but I was pleased that the software comes with its own certificate storage and that the signature placeholder is highly configurable. For example, one can configure the placeholder to include one's own analogue signature as a background.

Alas, using the Master PDF editor without any restrictions requires purchasing a license. The free version is unlimited, but leaves a watermark in documents that have been digitally signed or otherwise altered with the software. The licence is very fairly priced, but as the software is developed in Russia, even asking for one is frowned upon and politically inopportune. Fortunately, nobody has yet complained about the watermark in documents I have digitally signed. 😈

Backdoor in xz

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

Kernel 6.6.9

Yesterday, I've updated my systems to kernel 6.6.9 – two Intel-based desktops and one AMD-based notebook. When rebooting the latter, I immediately noticed that something was wrong. Logging in, for example, seemed to take twice as long, and the desktop needed much longer than the usual two or three seconds to come up. My Intel desktops, in contrast, behaved exactly as before.

To substantiate my feeling that my notebook's performance had degraded significantly since the update, I used sysbench, or, more precisely, the command sysbench cpu run. I would normally see a performance of about 4800 events per second on one core. But with kernel 6.6.9, all I've got were 440 events per second, more than a factor of 10 lower than the Ryzen 5800H in my notebook is supposed to deliver, and even three times lower than my 10-years old Intel desktops. No surprise the notebook felt so sluggish!

I didn't bother to investigate this issue further, and I don't know the underlying cause, like whether it's related to the AMD processor or the maker of the notebook. I just rolled back to kernel 6.6.8 (sudo pacman -U /var/cache/pacman/pkg/linux-6.6.8.arch1-1-x86_64.pkg.tar.zst) and the problem was gone.

I expected problems with kernel 6.6.6, but the devil is in the details.

Update: The performance is back to normal with kernel 6.6.10.

Virtual Arch for the VPN

Connecting to a VPN is usually like picking up your device and tossing it into another network, figuratively speaking. All of your network activities – such as browsing, fetching private mails, chatting with a friend on IRC – will take place within this virtual network, or not at all: in its most secure configuration, access to resources on the local area network will not be possible. I thus prefer to separate my real private network activities from those in the virtual private network by using a virtual guest dedicated to nothing but connecting to the latter and doing whatever I need to do within the guest system.

In the present case, I'm fortunate that my employer now uses a gateway whose VPN client (Palo Altos's GlobalProtect) runs even on an up-to-date Arch installation. So my choice for the guest system is an out-of-the-box ArchBang that comes with i3 as (tiling) Window manager. It installs in 10 min, comes with everything I need, and fits in 5 GB of space. I spent another 5 min modifying the wallpaper and the conky instance – my idea was to have a visual indication in form of my IP whether or not I'm connected to the VPN.

../images/virtualarch_95.webp

After configuring everything to my liking, it turned out that I shouldn't have bothered – our IT guys configured the VPN with split tunneling enabled. This basically means that only traffic destined to the remote location passes through the encrypted tunnel, while everything else uses the standard gateway. Supposedly less secure, but certainly much more convenient. Excellent choice! I'm sure I'll find another use for my virtual Arch – be it for testing or online banking.

Don't worry, be happy

It's Friday evening, 18:30. My fourth video meeting in a row has just concluded. Now I could finally work on the revision of a manuscript I wanted to get resubmitted during the weekend. This last revision was purely technical: the production editor requested that we move the present addresses of the authors to the back of the manuscript, instead of leaving them beneath the list of authors on the title page as destined by the LaTeX class from the publisher. Now, any such request that forces me to work around or against the journal style provided by the publisher means that the reputation of the journal (ACS Appl. Nano Mater., in case you are curious) takes a steep dive. But anyway, I had to do it, and I was looking into the footmisc package to get all footnotemarks I needed when I realized that I hadn't done my ritual update in the morning for the lack of time. Starting it, I only peripherally noticed that the update involved TeXLive and brought a new kernel. In any case, this information didn't stop me from compiling the manuscript I was working on during the update. Repeatedly. Incessantly.

At a certain point, the build command of Sublime Text didn't produce any reaction. No error message, nothing. I began to have a bad feeling. Indeed, while I could still move the mouse around, the entire Window system was unresponsive, and the update process – which was just about to build the fmt files – was hanging. I started to suspect that I had just committed the greatest blunder of this year, and indeed, when I rebooted, the system greeted me with the message that the kernel could not be found:

Loading Linux linux...
error file /boot/vmlinuz-linux not found
loading initial ramdisk
error: you need to load the kernel first

Well, I knew that this SNAFU looked worse than it actually is. But since I was suddenly very tired, I decided to call it a day and do the repair on Saturday morning.

On Saturday, I first needed a live Arch installation on a USB stick. The ISO ist just 813 MB (as of release 2023.07.01) and downloaded in 30 s. There are several options to write the ISO to the stick, but I prefer dd:

dd bs=4M if=archlinux-archlinux-2023.07.01-x86_64.iso of=/dev/sdd conv=fsync oflag=direct status=progress

Note that the stick must not be mounted, and one writes to the stick (sdd), not a partition (sdd1).

After booting from the thus created live media, I was just a few commands away from a restored system. I first wanted to have my WiFi working:

iwctl --passphrase PASSPHRASE station DEVICE connect SSID

After that, I just needed to mount my drives (have a look with lsblk before), delete the stale lock file from the previous failed update, and do an update in the mounted root directory:

mount /dev/nvme01p2 /mnt
mount /dev/nvme01p1 /mnt/boot
mount -t proc /proc /mnt/proc
mount --rbind /sys /mnt/sys
mount --rbind /dev /mnt/dev

rm /var/lib/pacman/db.lck

pacman --sysroot /mnt -Syu

Took all in all half an hour, but I would still have preferred to avoid this situation altogether. The lesson is: avoid working on the system when you're all stressed out. Particularly on Friday night.

A new VPN

The institute I'm with has offered a VPN solution for its employees for about 15 years. Well, at least for the Windows users of our staff. The Cisco we've used in the first years came with the abysmal 'vpnclient', which I've said one time to be a clear winner of the worst-software-on-this-planet contest. It would run only on CentOS and Debian OldStable (meaning Sarge at that time!), and there was no way to get it running in any reliable way on a halfway modern Linux. I've thus ended up by connecting to the VPN via a virtual Windows XP, until I discovered openconnect, which worked perfectly on modern Linux distributions. Still, I was delighted when we finally kicked out the Cisco and got a Checkpoint instead, only to learn that the promised Linux client was still in development. It actually never materialized, but I was content with the browser-based solution they offered. Now the Checkpoint license has expired, and instead of renewing the contract, we've gotten ourselves a Palo Alto firewall – much to my surprise, as Palo Alto is not known for being a bargain. But in any case, we now – after 15 years – have a VPN client that can be installed on a fully updated Arch system and actually works.

Jonas, a fellow Archer and colleague of mine, figured out the best way how to install the client. I'm' adding his instructions here so I find them when the next version is released. 😄

  1. Install the AUR package 'globalprotect-bin' (which will fail, but gets the necessary 'PKGBUILD' file and 'globalprotect.install' script).

  2. From /software/VPN/VPN_Client_GlobalProtect get the latest version of the archive with the client binaries for Linux: 'PanGPLinux-u.v.w-...tgz'. From this archive, you only need the files 'GlobalProtect_tar-u.v.w.x-yz.tgz' and 'GlobalProtect_UI_tar-u.v.w.x-yz.tgz'.

  3. Place the two files in the AUR build-folder, e.g. '.cache/yay/globalprotect-bin/'

  4. Check that in PKGBUILD the correct 'pkgver' (u.v.w.x) and 'pkgrel' (yz) are set. If you need to change these, you also need to adapt the 'sha256sums'.

  5. Run makepkg -si.

  6. Start gpd.service using systemctl enable --now gpd.service (check status with systemctl status gpd) and restart the system.

  7. Import the certificate (I had to use an absolute path): globalprotect import-certificate --location /home/user/...

To update the client to a new version, you need to repeat steps 2–5 and restart the system.

Now you are ready and you can

  • Start the connection using globalprotect connect --portal vpn.foo.bar.de

  • Disconnect using globalprotect disconnect

  • Alternatively, run the gui (which then appears in the system tray) using: globalprotect launch-ui and use the connect/disconnect button

I have little to add to these instructions. I don't recommend the GUI: it is outdated and does not work in a high-dpi environment such as my notebook. But that's fine with me; I like the CLI better anyway. Following my habits, I've just defined aliases for the two commands most frequently used:

alias vpnon='globalprotect connect --portal vpn.foo.bar.de'
alias vpnoff='globalprotect disconnect'

Perhaps I will install a minimal virtual Linux guest to run the client and to connect, while still being able to use my other connections in the host system. I'll post an update if I do that. 🤠

Error...error...error

I love TOS, the original Star Trek series with Kirk and Spock from the 1960s. I'm not totally sure, but I think there were at least two examples in this series for an amok-running artificial intelligence brought down by very simple arguments revealing an error in the logic of the machine. Normally the computer in question would then start to steam and hiss and speak in a squawking voice.

What follows is a chat protocol of me talking with ChatGPT. I started with an English grammar question.

Elaborate on the correct use of "allow" and "allow for" in the english language.

"Allow" is a verb that means to permit or grant permission for something to happen or be done. It can be used in a variety of tenses, such as "I allowed him to borrow my car" or "She will not allow the dog on the couch."

"Allow for" is a phrase that means to make provision or take into consideration. It is often used when planning or making arrangements. For example, "We need to allow for traffic when planning our route" or "The budget should allow for unexpected expenses."

In summary, "allow" is used to grant permission or make something possible, while "allow for" is used to make provision or take into consideration when planning or making arrangements.

That's by far the best explanation I've ever heard – certainly better than the arguments of native speakers trying to convey the difference to me.

In our chat yesterday, you've said "It's important to note that the direct bandgap nature of GaAs also allows for a higher electron mobility." Given your explanation above, isn't the use of "allow for" incorrect in this statement, and should be replaced by "allows"?

I apologize for the confusion. You are correct that in the statement "It's important to note that the direct bandgap nature of GaAs also allows for a higher electron mobility," the phrase "allows for" should be replaced with "allows."

"Allows" is the appropriate verb to use in this context as it is used to indicate that the direct bandgap nature of GaAs makes it possible for the higher electron mobility. The phrase "allows for" would be more appropriate in a context where provision or consideration is being made, such as "The design of the device allows for easy maintenance."

Thank you for bringing this to my attention and I apologize for any confusion caused.

Apart from the language, what is the factual accuracy of the statement "the direct bandgap of GaAs also allows a higher electron mobility"?

The statement "the direct bandgap of GaAs also allows a higher electron mobility" is generally considered to be factually accurate. [...] In summary, GaAs has a direct bandgap and higher electron mobility, which makes it an attractive semiconductor material for optoelectronics and high-frequency electronic devices.

While it is correct that GaAs exhibits both a direct bandgap and a high electron mobility, the statement "the direct bandgap of GaAs also allows a higher electron mobility" implies causality. Is there truly such a direct relation between the nature of the bandgap and the electron mobility?

! An error occurred. If this issue persists please contact us through our help center at help.openai.com.

Ha! I did it. I'm the Kirk, the creator!

My question about the relationship between the nature of the band gap and the electron mobility goes back to a conversation I had with ChatGPT the day before. I wanted to see how ChatGPT would answer a question I might ask a master's or Ph.D. student at his thesis defense. ChatGPT turned out to be overly talkative, but I'll give it to you unabridged. You'll see that ChatGPT likes to make things up, and when the hoax is discovered, it apologizes profusely, but is not smart enough to learn on the fly. It took about a week for ChatGPT to come up with another, at least slightly more correct answer to my question.

What's the major difference between the semiconductors Si and GaAs?

The major difference between semiconductors silicon (Si) and gallium arsenide (GaAs) is the bandgap. The bandgap is the energy difference between the valence band and the conduction band, and it determines the energy needed to excite an electron from the valence band to the conduction band, allowing it to participate in electrical conduction.

Silicon has a relatively small bandgap of around 1.1 eV, which makes it suitable for use in low-power electronic devices, such as transistors and diodes, but it is not as efficient for optoelectronics applications such as light-emitting diodes (LEDs) and laser diodes.

On the other hand, GaAs has a relatively large bandgap of around 1.4 eV, which makes it more efficient for optoelectronics applications. GaAs is commonly used in high-power and high-frequency electronic devices, such as microwave and millimeter-wave devices, as well as in LEDs and laser diodes.

Another important difference is that GaAs is direct bandgap semiconductor which allows for more efficient light emission and absorption, while Si is an indirect bandgap semiconductor, which is less efficient for these purposes.

Additionally, GaAs is more sensitive to radiation than Si and it's more expensive to produce than Si.

Well, don't you think that the direct/indirect nature of the bandgap is more important than the minor difference in the actual energy?

Yes, you are correct that the direct/indirect nature of the bandgap is more important than the minor difference in the actual energy value. The direct bandgap allows for more efficient light emission and absorption, which is crucial in optoelectronics applications such as LEDs and laser diodes. Direct bandgap semiconductors like GaAs are more efficient at generating light and are more sensitive to light, which makes them more suitable for these applications. On the other hand, indirect bandgap semiconductors like Si are less efficient at generating light and are less sensitive to light, which makes them less suitable for optoelectronics applications.

It's important to note that the direct bandgap nature of GaAs also allows for a higher electron mobility, which makes it more suitable for high-speed and high-frequency electronic devices such as microwave and millimeter-wave devices.

In summary, while the small difference in bandgap energy between Si and GaAs is important, the direct/indirect nature of the bandgap is more critical in determining the suitability of a semiconductor material for a specific application, especially in the field of optoelectronics.

You said that the "direct bandgap nature of GaAs also allows for a higher electron mobility". Can you substantiate this claim?

Yes, the direct bandgap nature of GaAs allows for higher electron mobility compared to indirect bandgap semiconductors like silicon.

In a direct bandgap semiconductor like GaAs, the conduction band and the valence band intersect at the same point in the Brillouin zone, which means that the electrons can transition from the valence band to the conduction band without having to change momentum. This results in a higher electron mobility, which means that the electrons can move more freely and at a faster rate through the material.

On the other hand, in an indirect bandgap semiconductor like silicon, the conduction band and the valence band do not intersect at the same point in the Brillouin zone, which means that the electrons need to change momentum in order to transition from the valence band to the conduction band. This results in a lower electron mobility and a slower rate of movement of the electrons through the material.

This is why GaAs is more suitable for high-speed and high-frequency electronic devices such as microwave and millimeter-wave devices, where high electron mobility is crucial.

It's also worth noting that the electron mobility of a semiconductor is affected by other factors such as temperature, impurities and defects in the material and the fabrication process, so it's not only the bandgap nature of the material which determines the electron mobility.

How are transitions from the valence band to the conduction band related to the mobility?

Transition from the valence band to the conduction band and mobility are related in the sense that the ease of this transition affects the mobility of electrons in a semiconductor.

The valence band is the band of energy levels in a semiconductor where the electrons are tightly bound to the atoms, and the conduction band is the band of energy levels where the electrons are free to move and participate in electrical conduction.

In a direct bandgap semiconductor like GaAs, the conduction band and the valence band intersect at the same point in the Brillouin zone, which means that the electrons can transition from the valence band to the conduction band without having to change momentum. This results in a higher electron mobility, which means that the electrons can move more freely and at a faster rate through the material.

On the other hand, in an indirect bandgap semiconductor like silicon, the conduction band and the valence band do not intersect at the same point in the Brillouin zone, which means that the electrons need to change momentum in order to transition from the valence band to the conduction band. This results in a lower electron mobility and a slower rate of movement of the electrons through the material.

In general, the easier the transition from the valence band to the conduction band, the higher the electron mobility, and the faster the electrons can move through the material. This is why direct bandgap semiconductors like GaAs have a higher electron mobility compared to indirect bandgap semiconductors like silicon.

You said that "the easier the transition from the valence band to the conduction band, the higher the electron mobility". That's complete nonsense. The mobility is largely determined by the effective mass of a given band, and has nothing to do with interband transitions, as you have claimed. Where did you get this misinformation?

I apologize for the confusion caused by my previous statement. You are correct that the mobility of electrons in a semiconductor is determined primarily by the effective mass of the electrons in the material, and not by the ease of transition from the valence band to the conduction band. The effective mass of an electron is the mass that an electron is assumed to have when it is affected by a force, and it is used to describe the behavior of electrons in a semiconductor.

The lower the effective mass of an electron in a semiconductor, the higher its mobility, as the electrons can move more freely and at a faster rate through the material. In general, the effective mass of electrons in a direct bandgap semiconductor like GaAs is lower than that of an indirect bandgap semiconductor like silicon, which results in higher electron mobility in GaAs.

Again, I apologize for any confusion caused by my previous statement and for not providing a clear explanation of the concept of electron mobility. Thank you for bringing this to my attention.

Gerade noch die Kurve gekriegt, oder?

Es tut mir leid, dass ich zuvor falsche Informationen geliefert habe. Ich schätze es sehr, dass Sie mich darauf aufmerksam gemacht haben, und ich werde mich bemühen, in Zukunft sorgfältiger und genauer zu sein. Ich bin ein Programm und bin darauf trainiert, auf Fragen zu antworten, aber ich bin auch nur so gut wie die Daten, die ich erhalten habe und manchmal kann es sein, dass ich mich irren. Ich bin immer bereit, mein Wissen zu aktualisieren und zu verbessern, und ich stehe zur Verfügung, um weitere Fragen zu beantworten.

Prima. Welcher Halbleiter hat eine höhere Beweglichkeit: InSb oder AlAs, und warum?

InSb (Indium Antimonid) hat eine höhere Elektronenbeweglichkeit als AlAs (Aluminium Arsenid). Dies liegt daran, dass InSb einen niedrigeren effektiven Massenkoeffizienten für Elektronen hat als AlAs. Der effektive Massenkoeffizient ist ein Maß dafür, wie schwer ein Elektron in einem Halbleiter wirkt, wenn es von einer Kraft beeinflusst wird. Ein niedrigerer effektive Massenkoeffizient bedeutet, dass die Elektronen leichter sind und sich schneller und freier bewegen können, was zu einer höheren Beweglichkeit führt.

Es ist auch zu beachten, dass InSb ein III-V-Halbleitermaterial ist, das einen direkten bandgap hat, während AlAs ein II-VI Halbleitermaterial ist und einen indirekten bandgap hat. Direkte bandgap Materialien haben in der Regel höhere elektronische Beweglichkeiten als indirekte bandgap Materialien, da die Elektronen in direkten bandgap Materialien schneller und effizienter von den Valenzband zu den Leitungsband übergehen können.

Zusammenfassend kann man sagen, dass InSb eine höhere Beweglichkeit hat als AlAs, da es sowohl einen niedrigeren effektiven Massenkoeffizienten als auch einen direkten bandgap hat.

AlAs ist ein II-VI-Halbleiter?

I apologize for the mistake, AlAs is not a II-VI semiconductor but rather a III-V semiconductor. III-V semiconductors like AlAs are composed of elements from groups III and V of the periodic table, and they are characterized by their direct bandgap nature. The electronic properties of III-V semiconductors are determined by their crystal structure, which is wurtzite in case of AlAs. This direct bandgap allows for a higher electron mobility, which makes it suitable for high-speed and high-frequency electronic devices such as microwave and millimeter-wave devices as well as in optoelectronics application like laser diode and LEDs.

Du sagst "This direct bandgap allows for a higher electron mobility". Ich hatte das schon weiter oben korrigiert. Du solltest versuchen, Gelerntes zu behalten.

I apologize for repeating the same mistake. You are correct that the direct bandgap nature of a semiconductor does not directly affect the electron mobility. The electron mobility is determined primarily by the effective mass of the electrons in the material and the scattering mechanisms present in the semiconductor. The direct bandgap may allow for more efficient light emission and absorption, but it does not have a direct effect on the mobility of the electrons. I apologize for any confusion I may have caused, and I will make sure to be more accurate and clear in my future responses.

Wenn Du jetzt das Gelernte auf Si und GaAs anwendest?

Silicon (Si) is an indirect bandgap semiconductor, while Gallium Arsenide (GaAs) is a direct bandgap semiconductor. The bandgap of a semiconductor is the energy difference between the valence band and the conduction band, and it determines the energy needed to excite an electron from the valence band to the conduction band, allowing it to participate in electrical conduction.

The indirect bandgap nature of Si means that the conduction band and the valence band do not intersect at the same point in the Brillouin zone, which means that the electrons need to change momentum in order to transition from the valence band to the conduction band. This results in a lower electron mobility for Si, which means that the electrons move more slowly through the material.

On the other hand, the direct bandgap nature of GaAs means that the conduction band and the valence band intersect at the same point in the Brillouin zone, which means that the electrons can transition from the valence band to the conduction band without having to change momentum. This results in a higher electron mobility for GaAs, which means that the electrons move more quickly through the material.

In terms of the electron mobility, GaAs has typically a higher mobility than Si, because of its direct bandgap nature, also the effective mass of the electrons in GaAs is lower than that of Si which also results in higher electron mobility in GaAs.

This is tiresome: you are still confusing the nature of the band gap and the real reason for the higher mobility, which is the effective mass. Why can't you remember what we discussed a few seconds ago? What does that say about your intelligence?

I apologize for the confusion and inaccuracies in my previous response. You are correct that the electron mobility in a semiconductor is primarily determined by the effective mass of the electrons and not directly by the nature of the bandgap (direct or indirect). The effective mass of an electron is the mass that an electron is assumed to have when it is affected by a force, and it is used to describe the behavior of electrons in a semiconductor. The lower the effective mass of an electron, the higher its mobility, as the electrons can move more freely and at a faster rate through the material. InSb has a lower effective mass for electrons compared to AlAs, which is why it has a higher electron mobility.

As a machine learning model, my intelligence is based on the patterns and information present in the data that it was trained on. Sometimes, I may not have been trained on the most up-to-date or complete information, and I may make errors or not have the ability to recall previous inputs. I apologize for any inaccuracies in my previous responses and I will make sure to be more accurate and clear in my future responses.

Ich glotz TV

Well, actually I've essentially stopped watching linear TV about 20 years ago. My Loewe CRT TV set I'd bought in 1994 didn't take kindly to that and twice suffered from dried-up electrolyte capacitors. “You have to switch on the TV at least sometimes”, said the electronics guy who repaired the set. When it happened the third time, I didn't bother anymore, but lived without dedicated TV set for the next 5 years. My first flat-screen TV purchased in 2010 suffered the same fate when it all of a sudden developed dead pixel rows, resulting in a rapidly increasing number of black lines across the display.

It was not until 2018 when I finally gave in and bought a new TV set with the explicit purpose to enjoy the FIFA World Cup held this year. You all know that from a German perspective, this word cup was as much of a disaster as the following one in 2022. Regardless, the 65" QLED panel with three-sided ambilight is perfect for enjoying the occasional movie from my NAS or Amazon Prime Video.

This panel creates a high level of immersion due to its sheer size and the light surrounding it, providing a near cinematic experience for movies in FullHD and 4K resolution. For anything else the immersion may be a bit overwhelming, particularly if one is not willing to fully focus on the action displayed. For me, that's often the case when watching a football match, or a documentary on publicly broadcasted TV, and I would prefer to be able to watch the TV channel on my notebook with one eye while doing other stuff in the background.

Instead of a flull-fledged IPTV application such as hypnotix, I thought that a simple script may be more suitable to my needs. The script I've found on archlinux.de was basically just what I needed. I've merely integrated the download of the current URLs (done by a python script by Axel-Erfurt I've reproduced below), cleaned up a bit, and formatted it for zenity. I've also excluded some redundant channels to keep the list from cluttering.

#!/bin/bash

# Original livetv script by tuxnix and Mis,
# see `https://wiki.archlinux.de/title/Live-Tv <https://wiki.archlinux.de/title/Live-Tv>`_
# liveiptvstations.py by Axel-Erfurt,
# see `https://gist.github.com/Axel-Erfurt/5106f9bbef1fca1d63bb74a849607128 <https://gist.github.com/Axel-Erfurt/5106f9bbef1fca1d63bb74a849607128>`_
# Also see `https://wiki.ubuntuusers.de/Internet-TV/Stationen/ <https://wiki.ubuntuusers.de/Internet-TV/Stationen/>`_

script_path="$(dirname "$0")"
script_name="$(basename "$0")"

# Pull down a current list of IPTV channels
liveiptvstations.py > channellist.txt

# Basic formatting
sed -i -e 'N;s/:\n/ /' -e 's/^/FALSE /' channellist.txt
sed -i -e "s/ARD Alpha/ARD.alpha/" -e "s/ARD ONE/ARD.one/" -e "s/MDR Sachsen/MDR/" -e "s/BR Süd/BR/" -e "s/NDR Hamburg/NDR/" -e "s/RBB Berlin/RBB/" -e "s/SWR BW/SWR/" -e "s/WDR (Deutschland)/WDR/" channellist.txt

# Remove some redundant channels (optional, but beware they need formatting if included)
sed -i -e "/Tagesschau/d" -e "/ARTE.FR/d" -e "/ORF/d" -e "/Brandenburg/d" -e "/Anhalt/d" -e "/Thüringen/d" -e "/Mecklenburg-Vorpommern/d" -e "/Niedersachsen/d" -e "/Schleswig-Holstein/d" -e "/Lokalzeit/d" -e "/weltweit/d" -e "/BR Nord/d" -e "/SWR RP/d" channellist.txt

#create oneliner for zenity
channel_list=$(paste -s -d ' ' channellist.txt)

stream_url=$(zenity --list --title "Live IPTV channels" --text "Choose a channel:" --radiolist  --column "" --column "Channel" --column "URL" --print-column=3 $channel_list)

if(($? == 0)); then
        mpv "${stream_url}"
        exec "${script_path}/${script_name}"
else
        echo "Leaving LiveTV"
fi
#!/usr/bin/python
# -*- coding: utf-8 -*-
import requests
import json

# see https://gist.github.com/Axel-Erfurt/5106f9bbef1fca1d63bb74a849607128

url = "https://raw.githubusercontent.com/mediathekview/MServer/master/dist/live-streams.json"

data = requests.get(url).text

js = json.loads(data)

def parse_object_pairs(pairs):
        return pairs

decoder = json.JSONDecoder(object_pairs_hook=parse_object_pairs)
obj = decoder.decode(data)

for value in obj[2:]:
        print(f'{value[1][2].replace(" Livestream", "")}:\n{value[1][8]}')

MSTwo

We are in the middle of a scientific discussion, and out of nowhere, a reference to an old and well-known operating system popped up. Our benjamin chimes in, grinning: “MSTwo!”

“MSwhat?” It took a second or two, and then it clicked. She's spanish, you know: “uno, DOS, tres, cuatro,...” And young enough to have never seen MSDOS herself.

Which makes me a relic because I've not only seen it but prepared my master thesis with it. 😑