I was helping someone with a non-trivial installation of Debian on a Lenovo ThinkPad E495 recently. The installation was anything but straightforward so I'll quickly document what it took to get WiFi and graphics working eventually. I have an idea by now why the E495 did not receive a hardware certification from Ubuntu like other ThinkPads did.
I believe that E495 and E595 are very close with regard to hardware outside of screen size, so there is some chance that most to all of this article applies to E595 as well.
Relevant E495 hardware components
If you're wondering if your E495 is close enough to keep reading this article, our model has:
- AMD Ryzen 7 3700U CPU with Radeon Vega Mobile Gfx "Picasso"
Advanced Micro Devices, Inc. [AMD/ATI] Picasso (rev c1)
Kernel modules: amdgpu
- Realtek RTL8111/8168/8411 Ethernet Controller
Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 10)
Kernel modules: r8169
- Realtek RTL8822BE WiFi adapter
Realtek Semiconductor Co., Ltd. RTL8822BE 802.11a/b/g/n/ac WiFi adapter
Kernel modules: rtwpci
- Realtek RTL8822B Bluetooth Radio
The details were extracted from output of
lspci -k in the running system.
The Bluetooth hardware not attached through PCI but internal USB.
What made the installation difficult?
- Out of the box Debian buster is too old for recent hardware like this one (so we went for bullseye)
- Even bullseye firmware packages are to outdated to contain all needed files
- The bullseye installer is buggy (so it takes installing buster first and doing a dist-upgrade)
- We saw nasty rendering artifacts in XFCE (before we adjusted xfwm4 configuration)
- Some menu entries would not open (but have XFCE complain about lack of qdbus)
- With secure boot enabled, WiFi will list available networks and pretend to be connected but it won't serve any actual traffic. Ouch.
The approach to installation that worked
Before we start, please make sure you have secure boot disabled in the BIOS or at least WiFi will not be fully functional.
So we start by installing Debian buster; it takes a working Ethernet connection
and using a USB stick flashed with the Debian buster netinst ISO, e.g.
During installation we do not select any desktop environment so we do not end up in a broken Xorg session but the terminal, after reboot.
After the installation, we mass-replace
sed -i 's,buster,bullseye,g /etc/apt/sources.list'
and do a dist upgrade, e.g. by
apt update ; apt dist-upgrade -V.
One of the downloads of
apt update will fail because bullseye
is not released yet but that's okay. On a side note, we went for
testing here because
bullseye will stop moving at some point
in the near future while
testing will remain rolling all the time.
What more do we need now?
- some firmware files
- the right Xorg driver package
- a desktop environment
- (a config change of xfwm4 in case of XFCE)
Let's start with firmware.
If the related packages in Debian were complete and recent, you would need:
How do I know which firmware files are needed? The kernel knows which hardware needs which firmware file and the kernel log tells us which firmware files it loads or failed loading. In working E495 system it looks like this:
# sudo dmesg | fgrep direct-loading [ 1.768139] amdgpu 0000:05:00.0: firmware: direct-loading firmware amdgpu/picasso_gpu_info.bin [ 1.768281] amdgpu 0000:05:00.0: firmware: direct-loading firmware amdgpu/picasso_sdma.bin [ 1.770323] amdgpu 0000:05:00.0: firmware: direct-loading firmware amdgpu/picasso_asd.bin [ 1.770364] amdgpu 0000:05:00.0: firmware: direct-loading firmware amdgpu/picasso_ta.bin [ 1.770391] amdgpu 0000:05:00.0: firmware: direct-loading firmware amdgpu/picasso_pfp.bin [ 1.770412] amdgpu 0000:05:00.0: firmware: direct-loading firmware amdgpu/picasso_me.bin [ 1.770427] amdgpu 0000:05:00.0: firmware: direct-loading firmware amdgpu/picasso_ce.bin [ 1.770456] amdgpu 0000:05:00.0: firmware: direct-loading firmware amdgpu/picasso_rlc.bin [ 1.770582] amdgpu 0000:05:00.0: firmware: direct-loading firmware amdgpu/picasso_mec.bin [ 1.770687] amdgpu 0000:05:00.0: firmware: direct-loading firmware amdgpu/picasso_mec2.bin [ 1.772470] amdgpu 0000:05:00.0: firmware: direct-loading firmware amdgpu/raven_dmcu.bin [ 1.772592] amdgpu 0000:05:00.0: firmware: direct-loading firmware amdgpu/picasso_vcn.bin [ 116.581265] platform regulatory.0: firmware: direct-loading firmware regulatory.db [ 116.581427] platform regulatory.0: firmware: direct-loading firmware regulatory.db.p7s [ 116.828475] rtw_pci 0000:04:00.0: firmware: direct-loading firmware rtw88/rtw8822b_fw.bin [ 116.991964] bluetooth hci0: firmware: direct-loading firmware rtl_bt/rtl8822b_fw.bin [ 116.992154] bluetooth hci0: firmware: direct-loading firmware rtl_bt/rtl8822b_config.bin [ 117.098348] r8169 0000:02:00.0: firmware: direct-loading firmware rtl_nic/rtl8168g-3.fw
The source of all of these files is the linux-firmware upstream Git repository.
Let's see how recent these very firmware files are in the upstream Git today (as of 2020-05-04):
# git clone -c fetch.fsckObjects=False \ https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git # cd linux-firmware # for i in $(ls -1 amdgpu/picasso_* \ rtw88/rtw8822b_fw.bin \ rtl_bt/rtl8822b_*.bin \ rtl_nic/rtl8168g-3.fw); do \ echo "$(git log --format=%as -n1 -- "$i") $i" ; done | sort 2013-04-23 rtl_nic/rtl8168g-3.fw 2017-04-14 rtl_bt/rtl8822b_config.bin 2017-04-14 rtl_bt/rtl8822b_fw.bin 2018-10-04 rtw88/rtw8822b_fw.bin 2018-12-13 amdgpu/picasso_gpu_info.bin 2018-12-13 amdgpu/picasso_sdma.bin 2019-04-26 amdgpu/picasso_rlc_am4.bin 2020-01-06 amdgpu/picasso_ce.bin 2020-01-06 amdgpu/picasso_mec2.bin 2020-01-06 amdgpu/picasso_mec.bin 2020-01-06 amdgpu/picasso_pfp.bin 2020-01-06 amdgpu/picasso_rlc.bin 2020-01-06 amdgpu/picasso_vcn.bin 2020-04-16 amdgpu/picasso_asd.bin 2020-04-16 amdgpu/picasso_me.bin 2020-04-16 amdgpu/picasso_ta.bin
For the AMD firmware files, all but
amdgpu/picasso_ta.bin are contained
firmware-amd-graphics but Debian most recent 20190717-2
does not have up-to-date versions.
For the Realtek firmware files, all but
rtw88/rtw8822b_fw.bin are included
with latest version 20190717-2 of
firmware-realtek in Debian.
So we'll copy files from Git into
Make sure to keep the directory structure, e.g. copy
To get the firmware loaded, you either need to reload selected kernel modules
— at least
rtw88 — or just do a quick reboot.
I recommend going for the latter, for simplicity.
Xorg and desktop environment
Now that we have the firmware files around, let's install packages
libgl1-mesa-dri so that Xorg has the right drivers.
In case you don't get a picture but a hanging Xorg later,
inspecting log file
/var/log/Xorg.0.log may help.
Adding a desktop environment can easily by done by
you'll get the same experience as inside the Debian installer.
In case you choose XFCE like us and experience weird graphic artifacts like these, our fix was running…
# xfconf-query -c xfwm4 -p /general/vblank_mode -t string \ -s xpresent --create # pkill xfwm4
as learned from
this forum post by
pkill xfwm4 kills the current instance of xfwm4
so that XFCE starts a new one that respects our change in configuration.
To teach XFCE how to open desktop menu items just install
qdbus-qt5 and it should work.
If you cannot get it to work, feel free to get in touch.
Some closing notes:
Stable distributions and recent hardware are not a good match.
Command line tool
efibootmgrcan be of great help with debugging or changing EFI boot entries and boot order from within a running system.
Command like tool
mokutilcan be of help checking if secure boot is enabled, without a reboot.
I installed Debian on a Lenovo ThinkPad L13 a few days ago. The system is working by now but the road to "it works!" was a lot more exhausting than expected. I learned a few things along the way so it was not in vain. Maybe I can save you some time and/or headache with your own installation or help getting the WiFi to work. Let's go!
Why even get a Lenovo ThinkPad L13?
Simplified, I was looking for the cheapest ThinkPad with:
a less-than-14-inch matt full-HD IPS display
at least 16GB RAM, i5 CPU, 512 GB SSD, Intel GPU
support for a docking station
decent support for Linux
Canonical has certified Lenovo ThinkPad L13 to work well with Ubuntu 18.04 so I was in good faith that feeding Debian to it would work well. Not right away but eventually.
What's nice about the L13?
I like the keyboard
It has a shutter, a small hardware switch to close the eye of the camera
It looks rather elegant
What's weird about the L13?
It does not have an RJ45 LAN port. That's a bug in my world.
The battery cannot be removed. Bug!
It comes with two USB-A slots, only. I'm used to three or more and need them, so that's an inconvenience to me.
The BIOS is graphical be default (but it can be changed back to curses-like by setting
Config > Setup UI: Simple Text) and supports mouse navigation. Except when the cursor gets stuck, happened multiple times; definitely a bug.
By default the function keys
F12act as if the
Fnkey was hold. That's not very friendly to users of Linux (think
Ctrl+Alt+F1); the fix is setting
Config > Keyboard/Mouse > F1-F12 as Primary Function: Enabledin the BIOS before you first need one of those keys.
What made the installation difficult?
The laptop itself lacks a RJ45 LAN port but the Debian installer wants wired Ethernet.
The WiFi chip does not work with the firmware and Linux kernel packaged in Debian buster; it needs more recent versions of these packages or a more recent release of Debian.
Unlike the installer of Debian buster, the installer of Debian bullseye is in alpha stage and fails with an error half-way in.
Upgrading a Debian buster with XFCE to bullseye produces file/package conflicts that need manual fixing and
apt install -fto continue.
There is EFI involved, so e.g. all your live media need to be built for booting with EFI.
The approach to installation that worked for me
The lack of a RJ45 port can be approached in at least three different ways:
(a) Buy a docking station with RJ45 and wait until you have it at hand
(b) Buy a USB-to-RJ45 external network card adapter and wait until you have it at hand
(c) Boot a live system shipping working WiFi drivers (e.g. Xubuntu 19.10) and use QEMU to make the Debian installer believe that the WLAN below its feet is plain LAN to them.
I didn't have a USB-to-RJ45 network adapter and no docking station handy. So it was waiting or… adventure. I decided for (c): no waiting, QEMU, adventure.
Installing Debian to the host SSD from inside QEMU
Before I continue: If you're using this as a manual I'll assume/expect that you already:
have set the boot order in the BIOS to boot off an external medium so we don't end up in some half-installed Windows; if you're looking for
-keys on an L13 with a German layout try
Security > Secure Boot: Disabledin the BIOS
Config > Keyboard/Mouse > F1-F12 as Primary Function: Enabledin the BIOS or know a way around it from within a running Linux
have an external live medium ready that
- supports EFI (if you made something custom yourself) and
- comes with recent
Excellent — let's continue.
So you first boot that live medium with working WiFi. To install to the host SSD from within QEMU it takes:
Passing the SSD to QEMU
KVM virtualization to be fast
Allocating enough RAM to QEMU (for both swap size math and speed of installation)
An OVMF EFI image so that the installer detects an EFI environment and runs
pc, e.g. from package
A small Debian buster network installer ISO download, e.g.
You then boot QEMU with KVM with the EFI image for a BIOS and two drives: the installer medium and the host SSD to install to. Note that the installer ISO cannot be passed as a CD-ROM drive or EFI won't boot off it. My command looked something like this:
sudo qemu-system-x86_64 \ -enable-kvm -m 12G \ -bios /usr/share/OVMF/OVMF_CODE.fd \ -drive file=debian-10.3.0-amd64-netinst.iso,format=raw \ -drive file=/dev/vnme0n1,format=raw
While in the Debian installer, when asked for the software to install,
do not enable "desktop environment" and do not enable any specific desktop
environment like XFCE, either. This allows upgrading to bullseye after the
installation without running into conflicts during upgrade.
The trick is to add the desktop environment after upgrading, not before.
You can run
tasksel from the installed system later and it will not only
install say XFCE for you but also present the very ASCII dialog
that you were presented during installation.
When the installation is done, the installer asks to reboot and remove media. Do not worry about media removal: EFI will boot of the disk because the boot order in the NVRAM of the VM (not the host) has that order set by the installer. If you run into a situation where you want to restart the installation from the beginning but cannot stop QEMU from preferring the SSD over the Debian installer live media, for a workaround consider wiping the EFI-partition of the SSD — it will be re-written during installation anyway.
Back on track: The Debian installer finished, it's the second boot in QEMU
and we need to do some finial adjustments to make the installation ready to
boot off actual hardware.
So log in as root, upgrade to bullseye using
enable package distribution
non-free next to
to be able to install
firmware-iwlwifi and then install it,
install the meta package of the desktop environment that you want,
xfce or by running
tasksel as root.
Also install some WiFi management tool,
network-manager-gnome (for command
if you don't want to transfer
.deb files with a USB stick later.
Do a last boot in QEMU to ensure that everything but already WiFi works,
do a clean shutdown of the VM, run
sync on the host to flush unwritten
data to disk and boot on real hardware after.
If you cannot get it to work, feel free to get in touch.
Some closing notes:
Stable distributions and recent hardware are not a good match. It make sense now but I didn't expect that big of a disconnect.
The Debian installer makes full disk encryption with sane defaults, separate
/varvery convenient by now. Very nice. It's ahead of Ubuntu in that regard.
Command line tool
efibootmgrcan be of great help with debugging or changing EFI boot entries and boot order from within a running system.
It took me some Googling and experiments before I saw it work the first time: an EFI boot inside QEMU. I was blown away.
What is an EFI boot in QEMU good for? Two things:
To predict about future bootability on actual EFI hardware.
To make a Linux installer work with WLAN as if it's LAN.
My case was a bit of both combined, but that's a story for another post.
To have QEMU do an EFI boot, besides QEMU it takes:
OVMF installed (e.g. package
An EFI-only test image for proof (e.g. MemTest86 5.x or later)
wget https://www.memtest86.com/downloads/memtest86-usb.zip unzip memtest86-usb.zip sudo qemu-system-x86_64 \ -enable-kvm -m 2G \ -bios /usr/share/edk2-ovmf/OVMF_CODE.fd \ -drive file=memtest86-usb.img,format=raw
-enable-kvm -m 2G are optional and just make things run faster.
The location of BIOS file
OVMF_CODE.fd depends on your Linux distrubution:
Enough EFI for today.
First, this post is not sponsored by anyone and has no links or ads that make me any money. Let's go!
I grew quite a bit of a sympathy for Helvetica fonts recently and
ended up buying
Helvetica Neue a few days ago eventually.
While buying and then integrating the font into my Linux setup I learned a few things… that I would like to share with you.
Buying process + choices I had to make
Precisely I bought bundle "Neue Helvetica Pro Basic Family", 8 weights, each italic and not italic, desktop license 1-5 computers, Pro OpenType TTF, 20% discount from a promo code from signing up for their newsletter prior to buying, totaling at 141.85 Euro including VAT.
Helvetica Neue over
because it seemed like one of the more modern options fit for 2020.
Also I had seen it work very well before
(with content of The Futur in particular), and
it was not an experiment (like
Helvetica Now would have been),
and it was more affordable than some of the other options.
I picked OpenType TTF over OpenType CFF for the desktop download because in my local prior experiments, TTF fonts rendering looked different and better. I should not pay twice to get both formats though, that's not cool.
Out of all the font-selling websites run by Monotype with close to identical offerings — fontshop.com, fonts.com, linotype.com, myfonts.com — I went for FontShop for buying because I liked the arty feeling about the site and because they allow experimenting with a font prior to buying in a more fun way than the others.
What that go me was 16
Installing them was easy:
create a folder like
put the 16
.tfffiles in, and
fc-cacheto update the Fontconfig cache.
Integrating with Linux more
But I wanted a bit more. I often saw website refer to plain Helvetica —
e.g. through CSS like
font-family: [..],Helvetica,Arial,sans-serif,[..]; —
and I wanted browser to use my Helvetica Neue for that. Also, I wanted
change the default choice for
sans-serif to Helvetica Neue, at least to see
how it would feel for a few days. To summarize I wanted:
Helvetica Neuefor all applications and
Helvetica Neueas the default
sans-seriffont for all applications.
Took me a few takes to get that right but looking back it's actually not that hard.
fc-match helped me understand where I was at.
When I started out,
sans-serif mapped to
Liberation Sans and
Helvetica mapped to
TeX Gyre Heros as can be seen here:
# fc-match Helvetica texgyreheros-regular.otf: "TeX Gyre Heros" "Regular" # fc-match sans-serif LiberationSans-Regular.ttf: "Liberation Sans" "Regular"
Those mappings are configured
.conf files below
/etc/fonts/ and also
So I learned from the existing
.conf files I found, put two more files
~/.config/fontconfig/, one per task, and ran
This is how I named my files:
Let's a have a closer look at their content.
Helvetica Neue win over
TeX Gyre Heros I came up with this:
# cat ~/.config/fontconfig/conf.d/01-helvetica-neue-aliases.conf <?xml version="1.0"?> <!DOCTYPE fontconfig SYSTEM "fonts.dtd"> <fontconfig> <description> Serve Helvetica Neue when asked for Helvetica </description> <!-- needs binding="same" to win over TeX Gyre Heros --> <alias binding="same"> <family>Helvetica</family> <prefer> <family>Helvetica Neue LT Pro</family> </prefer> </alias> </fontconfig>
Helvetica Neue was similar, slightly easier:
# cat ~/.config/fontconfig/conf.d/02-neue-helvetica-default-sans-serif.conf <?xml version="1.0"?> <!DOCTYPE fontconfig SYSTEM "fonts.dtd"> <fontconfig> <description> Make Helvetica Neue the default sans-serif </description> <alias> <family>sans-serif</family> <prefer> <family>Helvetica Neue LT Pro</family> </prefer> </alias> </fontconfig>
fc-match, it was easy to verify those files worked:
# fc-match Helvetica HelveticaNeueLTPro-Roman.ttf: "Helvetica Neue LT Pro" "Regular" # fc-match sans-serif HelveticaNeueLTPro-Roman.ttf: "Helvetica Neue LT Pro" "Regular"
During my experiments, I played with a downloaded copy of
Web Font Specimen
to make sure that both Firefox and Chromium were doing what I expected.
(I had one of the
<prefer> tags be an
<accept> earlier and that made
Firefox and Chromium behave differently — I still need to figure out why,
but use of
<prefer> fixed things for me.)
I also got curious in which order
fc-cache process the
in particular how user config and system config would blend together.
Why not just spy on
fc-cache while it does the work… using
I'll trim this down a bit to the interesting part:
# strace -F -efile fc-cache |& fgrep openat \ | grep -Eo '"[^"]+\.conf"' | sed 's,",,g' | nl 1 /etc/fonts/fonts.conf 2 /etc/fonts/conf.avail/10-hinting-slight.conf 3 /etc/fonts/conf.avail/10-scale-bitmap-fonts.conf 4 /etc/fonts/conf.avail/20-unhint-small-vera.conf [..] 10 /etc/fonts/conf.avail/50-user.conf 11 /home/user/.config/fontconfig/conf.d/01-helvetica-neue-aliases.conf 12 /home/user/.config/fontconfig/conf.d/02-neue-helvetica-default-sans-serif.conf 13 /home/user/.config/fontconfig/fonts.conf 14 /etc/fonts/conf.avail/51-local.conf [..] 51 /etc/fonts/conf.avail/70-yes-bitmaps.conf
So that's where
fonts.conf and user config come in.
It's controlled by
50-user.conf, cut down to the interesting bits:
# cat /etc/fonts/conf.avail/50-user.conf <?xml version="1.0"?> <!DOCTYPE fontconfig SYSTEM "fonts.dtd"> <fontconfig> <description>Load per-user customization files</description> <!-- Load per-user customization files where stored on XDG Base Directory specification compliant places. it should be usually: $HOME/.config/fontconfig/conf.d $HOME/.config/fontconfig/fonts.conf --> <include ignore_missing="yes" prefix="xdg">fontconfig/conf.d</include> <include ignore_missing="yes" prefix="xdg">fontconfig/fonts.conf</include> </fontconfig>
My personal summary
I'm very happy to have desktop access to
Helvetica Neuenow, e.g. for use with future presentation slides.
I will probably revert back to
DejaVu Sansfor a
sans-serifdefault though, will see.
Mapping or re-mapping fonts on Linux is not that hard.
Fontconfig configuration can be adjusted without root permissions by putting a small XML file into directory
fc-matchare the Fontconfig commands needed to get user fonts and configuration to work.
Font Manager is great for browsing and previewing installed fonts on a Linux System.
Googling for differences between OpenType TFF and OpenType CFF for quite a while did not help me making the choice easier. Converting one font TTF-to-CFF and another CFF-to-TFF using FontForge and comparing results did.
Enough fonts for me today.
Facebook post 26 Essential Typefaces Recommended by Chris Do or
the Futur's Typography Tutorial on YouTube.
To me, their use of font in general and Helvetica in particular seems excellent so I got interested in Helvetica myself more. With multiple different Helveticas in the top 50 best-selling fonts on MyFonts it didn't take long to get me confused: Helvetica, Helvetica Neue, Helvetica Now, Neue Haas Grotesk — phew! Are they even different? Which one would I want to use?
Let me put my findings on available Helveticas on a date-of-publishing timeline:
1957 Neue Haas Grotesk – the original font
1960 Helvetica — renamed version by Linotype
1982 Arial — custom Helvetica by Monotype for Microsoft
2010 Neue Haas Grotesk (Display/Text) — restoration remake by Linotype
2019 Helvetica Now — remake by Monotype
That's a quite a few. From comparing their looks side by side and researching more I came to these…
When someone says "Helvetica" in 2020 they probably don't mean the original Helvetica from the late 50s; they probably refer to a more recent version.
When someone says "Neue Haas Grotesk" in 2020 they probably don't mean the original font from the late 50s but "Neue Haas Grotesk Display" or "Neue Haas Grotesk Text" released in 2010.
Letters to recognize Helvetica style fonts easily are lower
Gand the rectangle dots seen with
jand full stops.
Different versions of Helvetica can be distinguished by a closer look at lower letters
tand capital letters
The Futur has been using Helvetica Neue precisely back in 2016.
I find recent version of Helvetica to be beautiful; it is obvious to me now why Helvetica has been used so much.
Each of these fonts is rather expensive and their licensing rules do not seem "sane" to me; potentially a topic for another post. I hear that IBM has been spending over a million dollars every year to use Helvetica prior to their move to font IBM Plex — wow! I'll explore other legal free options more before putting this much money into a font for personal use as an individual.
From comparing different Helveticas side by side, Helvetica Now feels the most natural, balanced and beautiful to me by quite a bit.
Monotype's Helvetica Now 2019 marketing seems to ignore Linotype's prior effort with Neue Haas Grotesk Text/Display from 2010 altogether.
There are some resources I found on the way that I consider worth sharing, in particular:
The official user guide for Helvetica Now (PDF)
Some key visual differences between Helvetica and Arial (PNG, Wikipedia)
Typography Manual ed. 2018 by the Futur (PDF)
Article History of Neue Haas Grotesk by Indra Kupferschmid
Fontsc's list of free alternatives to Helvetica Font
That's it; enough Helvetica for me today.
I recently noticed that I would clearly suggest Debian over Ubuntu to someone about to make that choice. A few reasons why:
The Chromium browser lagged so much behind Debian in Ubuntu recently, that payment on AirBnB would fail on Ubuntu (16.10) while working well on Debian; the update/fix took way too long.
The corefonts installer is broken (and not hard to fix) in Ubuntu (16.10). I would not recommend any of the workarounds I have seen, the bug is not fixed for two years. Affected a non-IT friend of mine.
The shutdown process of a freshly installed Ubuntu 16.04 took ages due to the cups-browsed daemon. Experienced that at a Linux install party.
Pycharm freezes soon after start-up on Ubuntu 16.10.
Right now Debian has Postgresql 9.6, latest alpha Ubuntu only has Postgresql 9.5 (while we want 9.6 features on the server at work).
The Debian community will like you way better if you are not actually on Ubuntu if you end up asking questions in the Debian channel at some point (say you have questions on Debian packaging).
- Canonical gives up on supporting Chromium as a proper Debian package and announces its move of Chromium to Snap for Ubuntu 19.10. So users of Chromium on Ubuntu now get Snap forced onto their system.
After more than an hour of trying to convince the Ubuntu installer to do full disk encryption with LVM on a friend's notebook we switched to Debian… and the Debian installer did not only support it, it even made it easy.
The liburiparser1 0.8.4-1 package of Ubuntu bionic 18.04.x LTS(!) whose Standard Support with security updates ends 2023-04 — i.e. is still ongoing as of today — lacks patches for four CVEs that are clearly labelled as security fixes in the uriparser changelog. When contacting Ubuntu Security about it, their response was that "[.. s]ince the package referred to in this bug is in
universe, it is community maintained. [..]" (emphasis mine). That is in line with what Standard Support is offering, and it was a good eye-opener fow me on how little that actually is.
So much for now.
Some people care if software is free of cost or if it has the best features. I don't. I care that I can legally dissect its parts, adjust it to my needs, and share my modifications with the community: run, study, redistribute, improve. That's why I happily avoid macOS, Windows, Skype, Photoshop. I love … free software!