The battery is a bit worn out and has swollen.
I need to get it replaced ASAP.

Below is a set of snippets for configuring WireGuard for three different Linux distributions and FreeBSD.
The setup assumes a Debian server with a 10.9.21.0/24 network.

Server, Debian

apt install wireguard-tools
nano /etc/network/interfaces.d/wg0

auto wg0
iface wg0 inet static
    address 10.9.21.1/32
    pre-up ip link add wg0 type wireguard
    pre-up wg setconf wg0 /etc/wireguard/wg0.conf
    up ip -4 route add 10.9.21.0/24 dev wg0
    # up /bin/systemctl restart sshd.service
    post-down ip link del wg0

umask 077
cd /etc/wireguard/
wg genkey > server-private.key
wg pubkey < server-private.key > server-public.key

nano /etc/wireguard/wg0.conf

[Interface]
ListenPort = 1234
PrivateKey = <server-private.key>

[Peer]
# Debian client
PublicKey = <public.key>
AllowedIPs = 10.9.21.3/32

[Peer]
# CentOS client
PublicKey = <public.key>
AllowedIPs = 10.9.21.4/32

[Peer]
# Ubuntu client
PublicKey = <public.key>
AllowedIPs = 10.9.21.5/32

[Peer]
# FreeBSD client
PublicKey = <public.key>
AllowedIPs = 10.9.21.6/32

The stock Keychron keycaps with the OSA profile look not bad, but I’m not a lover of typewriters aesthetic.
Since I’m used to hitting combos like CTRL/SUPER/ALT/SHIFT with a single finger for certain shortcuts, I needed to find low-profile keycaps that are all the same height.
Pressing two keys simultaneously may be unfamiliar to casual typists, but if you use a tiling WM, where everything from launching apps to window management - is shortcut-based, it makes total sense.
I immediately picked up some pretty decent low-profile Womier keycaps.
The undersides might have some mold marks, but with a little modding, they are actually quite good.
I also picked up some OUTEMU Half-height switches for testing.
They are low-profile, but that’s all.
The tactile feel is non-existent.
Looking ahead: the stock Keychron Silk POM Tactile Bananas are very good, but they honestly can’t be compared to the Gazzew Boba Black U4T.

We have a Deeper DP4H13S10 sonar, and the goal is to increase its signal range.
The original Deeper Range Extender costs about €195.
How can we solve this using what we already have? And even make it better?
It’s very simple.

A good addition to the collection.
The news needs to be given time to settle, and then the details can be savored.

• Red Hat, RED HAT, CARL!
• GitHub Actions, as usual.
• NPM, we’re already used to it.
• Arch User Repository, it’s already more interesting.

What could be wrong here?

A critical vulnerability in nginx allows remote code execution with the privileges of the nginx worker process by sending a specially crafted HTTP request.
But that’s not the point.
The problem is that Debian maintainers are in no hurry to release a new patch package.

• Security Bug Tracker CVE-2026-9256
• NGINX ngx_http_rewrite_module vulnerability CVE-2026-9256

apt --no-install-recommends \
    --no-install-suggests install \
    build-essential \
    fakeroot \
    devscripts

nano /etc/apt/sources.list

# trixie sources
deb-src https://deb.debian.org/debian/ trixie main contrib non-free non-free-firmware
deb-src http://security.debian.org/debian-security/ trixie-security main contrib non-free non-free-firmware
deb-src https://deb.debian.org/debian/ trixie-updates main contrib non-free non-free-firmware

Only six months had passed, but the news feed continued to bring new funny vulnerabilities.
As usual, I don’t focus on system vulnerabilities in snapd / Rust Coreutils / Flatpak, or kernel (Copy Fail, Dirty Frag, Fragnesia, pidfd, PinTheft, GRO Frag) or AppArmor.

No matter how dangerous they may be, they are “conditionally” passive, meaning that if they are present, a number of factors and active actions from within or outside are required for successful exploitation.

I’m much more interested in tracking compromises of package distribution systems, libraries, and other package repositories.

Because these are “active” and direct attacks, they require almost no combination of factors; after downloading, they will immediately hit the developer’s repository, then collect their personal/financial/authorization information, and then continue to act in a chain fashion on all servers to which they had access.

Continuing with the previous boring opuses about environment isolation, it’s time to remember Wayland.
Of course, this is not a call to action, but just simple examples and reflections.
I personally adhere to a philosophy where the user is the center of the system, and he has the right to configure everything as he sees fit, and not as it is imposed by general trends, or as it is implemented in a specific distribution, at the same time understanding and accepting all the risks and consequences of these actions.
As the saying goes, “If you know what you are doing.”

And before we begin, it’s worth writing again that:

• Yes, I understand that this is all very superficial.
• Yes, any connections to the local graphical shell are not allowed for anything dangerous, and you must use VNC or virt-viewer/spice.
• Unprivileged LXC should be replaced with Xen / KVM
• And yes, I know that it is possible to breakout from KVM isolation too.
• I know about Flatpak.
• And finally, yes, I have known about Qubes OS and its architecture, let’s say, since its inception, which was 2010.

And, simplifying and adapting QubesOS ideas to my everyday needs, I prefer to use either other local users or lightweight unprivileged LXC environments.

And yes, I don’t run anything potentially dangerous in them, but rather something that many of you use directly under your system account, for example:

• Firefox for everyday use and casual browsing.
• Several projects using packages from PyPI, RubyGems.
• Separately, what I compile from sources from GitHub.
• Third-party programs, such as element-desktop, Telegram, Zoom.

Introduction from afar

Not long ago I felt nostalgic inside FreeBSD again, everything is wonderful, everything is familiar, everything is convenient.
There is just one point that completely rules it out from desktop use, at least for me.
On almost all my laptops, FreeBSD does not support either sleep or standby modes (s2disk/s2ram).
And I couldn’t do anything with the hardware/drivers/ACPI, but I tried a lot.

Without standby mode, it is completely impossible to use a laptop, since after transportation, you need to load everything again, turn it on, and restore a complex work session.
And I only reboot workstations after applying updates that require it.

One of the many nice little things that Beastie has that Debian lacks is ZFS Boot Environments, this is somewhat more convenient than, say, LVM snapshots.
And the second is GEOM_ELI, which supports not only, like LUKS, the OR password OR key mode, but also supports password WITH key mode.

I thought and thought, and decided to deploy Debian from scratch, taking into account all the tools I use, my experience, and, importantly, my habits.

Debian is still my main system, so the only way to get a hardware (physical) encryption key in addition to the password is to make it from the header and place it on a bootable USB flash drive.

Preliminary laptop inspection

Let’s consider a standard situation where you have a main work computer on which you have three different projects.
One project is on nodejs, the second is a production project on python, and the third is your personal “pet project”, also on python.
You also have personal and work email in the same system, and, say, a browser and home-banking.
And all this under your login.
Well, not under the root login, of course! ¯\_(ツ)_/¯
Everything is quite normal.

Many technically competent developers may have dozens of such projects.
And dozens of keys for SSH or GIT servers.

An example with the popular PyTorch framework

It’s quite ordinary: you write your code, commit it from time to time, and then a torchtriton update arrives in your cozy pet project.
And after that, the following data sets were transferred from your system, in accordance with the binary’s main function:

• Get system information:
  • nameservers from /etc/resolv.conf
  • hostname from gethostname()
  • current username from getlogin()
  • current working directory name from getcwd()
  • environment variables
• Read the following files:
  • /etc/hosts
  • /etc/passwd
  • The first 1,000 files in $HOME/*
  • $HOME/.gitconfig
  • $HOME/.ssh/*

The update arrived and the confidential data flew away.
It’s not just everything under your account (and possibly the system) has been compromised, but also, down the chain, everything you managed, committed to, and connected to.

Very, very often you have to deal with the need to use a certain version of Python, for example, for torch, or for something specific.
Using conda or Docker with nvidia-container-toolkit and then setting up images like nvidia/cuda:13.0.1-runtime-ubuntu22.04 feels counterintuitive to me, even though I’ve done it many times.
And an additional packages have to be installed in the container.

But easier and more convenient to compile everything on the host system, and at the same time prevent contamination of the entire system with third-party libraries and executable files.

The following is an example of building multiple Python versions for the verpy group only, which is a bit more convenient than installing for just one user.

• ai - an arbitrary user from whom the compilation is performed.
• verpy - the group that will be allowed to use these versions.

apt install \
    build-essential libssl-dev zlib1g-dev libbz2-dev libreadline-dev libsqlite3-dev \
    wget curl llvm libncurses5-dev libncursesw5-dev xz-utils tk-dev libffi-dev \
    liblzma-dev libgdbm-dev libnsl-dev libgdbm-compat-dev

mkdir /opt/openssl
mkdir /opt/python
groupadd --gid 42398 verpy
usermod -aG verpy ai

Without going into detail about how exactly and why everything is organized, access is provided through the following chain:

Nginx stream ingress <> Main Nginx Frontend <> Nginx Backend inside GitLab instance.

The Main Frontend manages the gitlab subdomain, which is closed to external access via auth_basic authorization.

This example shows an installation over LXC, while for any more or less serious use this is completely unacceptable and requires using KVM with additional security measures.
And besides, installation on KVM will be much, much easier.
LXC does not provide adequate security because, for proper operation, it requires mounting the /sys and /proc partitions from the host, which are accessible to all LXC instances.
Furthermore, this example requires using a PRIVILEGED virtual machine.
However, LXC allows relatively easy setting up a testing infrastructure without the overhead associated with KVM.
So some aspects in this example will only be related to the setup in LXC.

On the HOST system

First, let’s make preparations on the host system.

nano /etc/modules

overlay
nf_nat
br_netfilter
xt_conntrack
rbd
fuse
ip_vs
ip_vs_rr
ip_vs_wrr
ip_vs_sh
iptable_nat

nano /etc/sysctl.d/35-lxc-kubernetes.conf

kernel.dmesg_restrict = 0
net.ipv4.ip_forward = 1
net.ipv6.conf.all.forwarding = 1
net.bridge.bridge-nf-call-iptables = 1
# --conntrack-max-per-core Default: 32768 * N
net.netfilter.nf_conntrack_max=131072
# net.bridge.bridge-nf-call-arptables
# kernel.pid_max=100000
# user.max_user_namespaces=15000
vm.compact_memory = 1
vm.overcommit_memory = 1

Initial inspection of the laptop

Testing the thickness of thermal pads for SSD chips.

For some reason my everyday “always with me” working tool has started to heat up.

Hi-Fi Walker H2 player repair with a problem - overheating and doesn’t turn on.
Noises are heard when shaking. Means components inside have fallen off.