Looks like that might have changed, libc-gconv-modules-extra has an i386 package for 2.42-5 added at like midnight UTC+1. Given the sources only update every 6 hours, might be you found an unlucky update in between?

Struggled to find a time for the release, but the changelog has one, unsure how true to package-available time that is:

glibc (2.42-5) unstable; urgency=medium

  [ Martin Bagge ]
  * Update Swedish debconf translation.  Closes: #1121991.

  [ Aurelien Jarno ]
  * debian/control.in/main: change libc-gconv-modules-extra to Multi-Arch:
    same as it contains libraries.
  * debian/libc6.symbols.i386, debian/libc6-i386.symbols.{amd64,x32}: force
    the minimum libc6 version to >= 2.42, to ensure GLIBC_ABI_GNU_TLS is
    available, given symbols in .gnu.version_r section are currently not
    handled by dpkg-shlibdeps.

 -- Aurelien Jarno <aurel32@debian.org>  Sat, 06 Dec 2025 23:02:46 +0100

glibc (2.42-4) unstable; urgency=medium

  * Upload to unstable.

 -- Aurelien Jarno <aurel32@debian.org>  Wed, 03 Dec 2025 23:03:48 +0100

I thought about this for a long while, and realised I wasn’t sure why, just that most of my work has gravitated towards Arch for a while.

Eventually, I’ve decided the reason for the move is because of three specific issues, that are really all the same problem - namely I don’t want to learn the nix config language to do the things I want to do right now.

I’ve read lots of material on flakes, even first modified then wrote a flake to get not-yet-packaged nvidia 5080 modules installed (for a corporate local llm POC-turned-PROD, was very glad I could use nix for it!) I still just don’t really get how all the pieces hang together intuitively, and my barrier is interest and time.

Lanzaboote for secure boot. I’m going to encrypt disks, and I’m going to use the TPM for unlocking after measured uki, despite the concerns of cold-boot attacks, because they aren’t a problem in my threat model. Like the nvidia flake, I don’t really get how it hangs together intuitively.

Home management and home-manager. Nix config language is something I really want to get and understand, but I’ve been maintaining my home directory since before 2010, and I have tools and methods for dealing with lots of things already. The conversion would take more time than I’m prepared to devote.

Most of the benefits of nix are things I already have in some format, like configuration management and package tracking with git/stow, ansible for deployment, btrfs for snapshots, rollback and versioning. It’s not all integrated in one system, but it is all known to me, and that makes me resistant to change.

I know that if I had a week of personal time to dig in and learn, to shake off all the old fleas and crutch methods learned for admin on systems that aren’t declarative, I’d probably come away with a whole new appreciation for what my systems actually look like, and have them all reproducible from a readable config sheet. I’m just not able to make that time investment, especially for something that doesn’t solve more problems than I’ve already solved.

This is the most important thing. Over time, you develop opinions about software and methods of solving problems. I have strong opinions on how I want to manage a system, but almost no opinions on flags I want to switch when I compile software. This is why I’m on arch not gentoo. I’m sure I’ll make the leap eventually…

Before I switched back to Arch for my daily driver, I’d frankensteined my Fedora install on my laptop to replace power management, all the GUI bits, most of the networking stack and a fair chunk of the package system. Fedora, and Gnome in that case is opinionated software. That’s a good thing as far as I’m concerned, having a unified vision helps give the system direction and a unique feel. These days, I have my own opinions that differ in some ways from available distros.

I wanted certain bits to work a certain way, and I kept having to replace other parts to match the bits I was changing. When you ask the question, can I swap daemon X out for Y, the answer on fedora was, sure, but you’ll have to replace a, b and c too, and figure out the rest for yourself. Good luck when updates come along.

The answer on arch is, yeah, sure, you can do that - and here’s a high level wiki naming some gotchas you’ll want to watch out for.

I’ve also reached a stage in my computer usage that I don’t want things to happen automatically for me unless I’ve agreed them or designed them. For example, machines don’t auto-mount usb drives, even in gui user sessions, or auto connect to dhcp. I understand what needs to be done, and do it the way I want to do it, because I have opinions on networking and usb mounting.

My work laptop is a living build that I just keep adding to and changing every day. Btrfs snapshots are available for rollback…

I’ve got two backup machines - beelink mini me’s running reproducible builds created using archinstall. It’s running on internal emmc, and they have have a 6 disk zfs raidz2 on internal nvme drives, all of which are locked behind luks encryption,with the keys in the fTPM module, without the damn Microsoft key shim. On is off site. Trying to get secureboot working on Debian was an exercise in frustration.

I’ve modified a version of that same build for my main docker host on another mini PC.

My desktop runs nixos, but will be transfered to arch next rebuild.

I’ve got a steamdeck, which runs an arch based distro.

I used to run raspberry pi’s on arch because the image to flash the SD cards used to be way smaller than what was offered by the default pi is.

That’s all using arch. It’s flexible, has the tool sets I need, and almost never tells me ‘No, you can’t do that’.

I’d agree that a hardware solution would be best. Something designed specifically to do it. I’ve been eyeing up the biometric yubikey for a while.

I do this for ssh keys, VPN certs and pgp keys. My solution is pretty budget, I generate the keys on a LUKS encrypted USB and run a script that loads them in to agents, and flushes them on sleep. The script unlocks and mounts the LUKS partition, adds the keys to agents, unmounts and locks the USB. The passwords I just remember for the unlock and load into memory, but they’re ripe for stuffing in to keepass-xc - I need to look at the secret service api and incorporate that in to the script to fetch the unlock passwords directly from keepass.

I have symlinks in the default user directories to the USB’s mount points, like ~/.ssh/id_ed25519 -> /run/media/<user>/<mount>/id_ed25519. By default, when you run ssh-agent, it tries to add keys in the default places.

The way it works for me is:

• plug the USB in to the laptop after a restart or wake-up
• run script
• enter passwords for luks key, ssh-agent, gpg agent etc.
• Unplug USB.

I keep break-glass spares in a locked cabinet in my house and office, both with different recovery keys

I do this because it’s my historical solution, and I haven’t evaluated the hardware options seriously yet.

I have never understood this fork argument. All it takes to make it work is a clear division for the project.

If you want to make something, and it requires modification of the source for a GPL project you want to include, why not contribute that back to the source? Then keep anything that isn’t a modification of that piece of your project separately, and license it appropriately. It’s practically as simple as maintaining a submodule.

I’d like to believe this is purely a communication issue, but I suspect it’s more likely conflated with being a USP and argued as a potential liability.

These wasteful practices of ‘re-writing and not-cloning’ are facilitated by a total lack of accountability for security on closed source commercialised project. I know I wouldn’t be maintaining an analogue of a project if there were available security updates from upstream.

The thing I don’t understand about any of this, is why can’t you comment on ongoing dialogues with the gatekeepers?

I understand the basic tenants of keeping the discussion closed until official statements can be prepared, to prevent the press and the public from going off half cocked. That makes sense for private matters.

This is not private. I can’t understand what is the point of negotiating law for people if they can’t even see the ongoing process?

They’ve snapified coreutils too, and rewritten them in rust (uutils). It’s proving to be a challenging transition…

Edit: While the article mentions rust’s vaunted memory safety as a driver, I can’t help but notice that uutils is licensed MIT, as opposed to GNU’s coreutils license being GPL v3.

While snapd is licensed GPL v3, it’s important to note that despite the ‘d’ suffix, it’s barely a daemon. It’s mostly a client for the snap backend - which is proprietarially licensed and only hosted with Canonical. The snapd client could be replaced at any time.

Also, according to the propaganda model, in developed democratic societies, the propaganda is assumed to be true, and if you’re not on board with that, you’re not part of the debate.

Not without Deno anymore, google just took a great big shit on it :(

I’m on hyperland, and I’ve configured ydotool to do some of this work. It can move the mouse, enter keyboard shortcuts and do a bunch of things that autohotkey can, however it is by no means a complete solution, or one that comes with sensible defaults. It’s just a daemon and client, and you’ll need to set it up to do what you want.

As far as I know there’s no record and replay function, though you could likely script one.

Also, for triggering the scripts, you’ll need to set your Desktop’s keybindings to point to them.

For me, it filled the requirements that it was launchable by systemd unit, as the user on login.

I use it for a vairiety of tasks, but the primary one is typing out my clipboard as if I had pasted something. I rebound alt + shift + p to that, so I can paste windows login passwords or whatever in to Teamviewer/other stuff that doesn’t accept a paste command.

The answer as always is, it depends.

Not all implementations rely on shim.

if you set up secureboot without doing anything more than instaling the OS… yeah probably it is true. Edit: e.g. GRUB2 generally relies on shim. sysemd-boot doesn’t

I haven’t checked the specific key that signs shim to confirm the expiration date, but there generally is a date, as we’re talking about certs and keys here.

Edit 2: Basically what this article is saying is that the machines will need a new platform key (mited in 2023) enrolled in the tpms, with often comes from the firmware (when tpms are wiped for initial enrollment of a new install/setup, they tend to enroll whatever platform keys from microsoft are baked in to the uefi firmware).

So basically, if you haven’t had a bios/uefi firmware update since 2022, there’s no way for you to have have the new key trusted by your tpm, and the whole chain of trust falls apart when the key you do have expires. So you’ll need to disable secureboot. If you use shim and/or the microsoft platform key in someway.

I have signal installed direct using obtanium, with the background connector enabled. I’ve not yet had an issue with it.

Snake eyes watching you

Have you tried tailscale with an exit node? Could be worth a test, if it works, some combination of other providers might too

Hang on though, if it’s web stats, how many of those impressions are ai bots scraping training data claiming to be Firefox users?

Don’t those likely read as Linux from how they fingerprint on TCP connections?

Muppet Treasure Island, and “Spider-Man and his Amazing Friends Ep.16 - A Fire Star is Born!”

On VHS, of course!

Well, apparently Meta’s pixel tracking script was bypassing that VM and SELinux enforcment to exfil tracking impressions for years and doing it by creating webRTC dummy ports, that were chatting with their own apps (Instagram, Facebook, ?WhatsApp?-not sure). So not sure this was a great implementation to begin with.

And this was working despite sandboxing on other browsers

Source: https://arstechnica.com/security/2025/06/meta-and-yandex-are-de-anonymizing-android-users-web-browsing-identifiers/

Thanks for the feedback - It was a systemd issue. Something caused it to continue generating slices for espanso until the machine locked up - probably spawned with each terminal. It happened on out of date fedora install 36 (when 41 was out) with gnome on it.

Since then I’ve moved to a window manager for all my machines and would likely invoke it the same way - perhaps now it’s time to revisit!

I used eapanso for a few years, but kept running in to issues with it spawning hundreds of versions of itself.

I really miss it though. Would you say it has matured?

We’re everywhere!