I spent 4-6 hours the other day trying to figure out the equivalent of Hello World for a MediaWiki parser function extension.

In theory, they have a quick start guide, but that documentation has so many errors, and I spent ages jumping between PHP and a JSON configuration file I barely understood.

At least it’s working now. Now time to figure out how the heck to properly interact with the MediaWiki database!

(Perhaps once I’m a bit more confident in MediaWiki development, I’ll see if I can tidy up some that documentation.)

Yeh. They really did C++ unnecessarily dirty.

I’d take a well-maintained native package for my distro over a Flatpak, but sometimes, a Flatpak is just the the easiest way to get the latest version of an application working on Debian without too much tinkering - not always no tinkering, but better than nothing.

This is especially true of GIMP - Flatpak GIMP + Resynthesizer feels like the easiest way to experience GIMP these days. Same with OBS - although I have to weather the Flatpak directory structure, plugins otherwise feel easier to get working than the native package. The bundled runtimes are somewhat annoying, but I’m also not exactly hurting for storage at the moment - I could probaby do to put more of my 2 TB main SSD to use.

I usually just manage Flatpaks from the terminal, though I often have to refresh myself on application URLs. I somewhat wish one could set nicknames so they need not remember the full name.

And that is still largely true - I’m still running XFCE with xorg on Debian, and I think the only issue I’ve had was Waydroid.

Will there come a day where what you say is true? Yes.

However, right now, a more apt example to convey your point is systemd; that’s true for most distros with a lot of community support. Even then, its hold isn’t absolute - Alpine seems like the most livable non-systemd distro, though I could be wrong.

As I’ve commented elsewhere on this post and others have said, this is a change that affects pretty much no one. I didn’t even know MBR (legacy BIOS) partition tables on UEFI boot was possible, honestly.

By no longer putting in the effort to maintain this bit that no one uses, work can be put to something someone uses.

Also, with Linux, specific distros can get encrapified (kind of happened to Ubuntu), but as others have said, there’s usually always another distro to jump to at worst.

For those panicking about it, this is not something you need to worry about. Here’s what this actually does:

Enforce the use of GPT partition tables for all UEFI-based Fedora installations for x86 architecture. This removes support for installing Fedora in UEFI mode on MBR-partitioned disks on x86 systems

You probably have already been using GPT on your UEFI system since you had a UEFI system. Even if you somehow were using MBR, this probably;

1. Won’t break existing installations, as it’s merely support for installs of this type
2. Would not be a problem even if somehow the broke existing installs, as it’s not difficult to convert MBR to GPT.

As much as I resonate with the issues, in this case, this isn’t what they’re doing at all.

This drops support only for UEFI on the MBR partition scheme typically used by a BIOS setup, which I honestly didn’t even know was possible.

This ends support for no hardware - almost all distro installations on UEFI have defaulted to GPT partition tables for a long time.

That’s not what this is saying.

It’s only support for UEFI on the old MBR partition table - GPT partitioning has been the default for ages now.

Also used it before, for Rounds I believe.

You’re right that it was power-related - one of the options was an ASPM modification - but the issue seemed to be common to this chipset accross laptop brands.

The fix I used came from this post: https://bbs.archlinux.org/viewtopic.php?id=286109

My machine was a Thinkpad, but this article was also talking about problems on HP, Asus, etcetera. I think the 8852BE might just be cursed

To be fair, I was using an E series Thinkpad, but in my defense, the E series seems to have improved a lot in the past few years - this was luckily the only issue I’ve had. I’ve had much more difficult times with Linux on other laptops. Heck, even my desktop had more setup than this when I was first starting out, though it was because I was using a Broadcom Wi-Fi card, as I also dual-booted with a Hackintosh and macOS only supports Broadcom Wi-Fi chipsets.

Otherwise agree, but I did run into pain with Realtek on my Thinkpad - the module would sometimes crash and disconnect entirely (on a PCI-e level) from the system.

I did manage to find a fix, but I would not recommend Realtek to someone.

I once experimented with something similar, except it was supported to trigger my smart speaker and drop into another part of the house to tell me.

Honestly, I really need to replace my proprietary smart speaker system with something self-hosted; it’s just I only recently have had the time to start cinsidering.

Vulnerabilities certainly do exist, but I’m pretty sure the attacker has to be well-equipped

I’d call it a protection against data getting cracked in a petty theft, but if your attack vector is much more than that, there are other measures you should probably take. I think Clevis also works with Yubikeys and similar, meaning the system won’t decrypt without it plugged in.

Heck, I think I know someone who just keeps their boot partition with the keys on it on a flash drive and hide it on their person.

In my case, no; it’s all a single machine - it is in the initramfs and uses the system’s TPM to (relatively) securely store the keys.

It can be set up with an attestation server, but you certainly don’t have to do it. The Arch wiki has a really good article on getting it set up.

I use Clevis to auto-unlock my encrypted root partition with my TPM; this means when my boot partition is updated (E.G a kernel update), I have to update the PCR register values in my TPM. I do it with my little script /usr/bin/update_pcr:

#!/bin/bash
clevis luks regen -d /dev/nvme1n1p3 -s 1 tpm2

I run it with sudo and this handles it for me. The only issue is I can’t regenerate the binding immediately after the update; I have to reboot, manually enter my password to decrypt the drive, and then do it.

Now, if I were really fancy and could get it to correctly update the TPM binding immediately after the update, I would have something like an apt package shim with a hook that does it seamlessly. Honestly, I’m surprised that distributions haven’t developed robust support for this; the technology is clearly available (I’m using it), but no one seems to have made a user-friendly way for the common user to have TPM encryption in the installer.

I’m pretty sure by default, virtual networks are not enabled automatically if you’re not using virt-manager GUI.

To make it run automatically, run the following: virsh net-autostart default

If it’s not that, just to make it easier to find information, what’s your host distro? I’m guessing by mention of Kickstart files that it’s something Red Hat related, possibly Rocky 9 based on your choice of guest.

Weird. It must be that my taste is very indie/alternative. You can always also check if the artist has their own shop.

That’s how Jonathan Coulton does it. They Might Be Giants does it as well (in addition to a Bandcamp), but most of their stuff from 1990-1996 is stuck on their former label, so they can’t sell DRM-free audio, only vinyl and/or cassette.

Do you have FluidSynth installed? I had similar issues recently - I just have a script that restarts pipewire automatically on login.

PS5 controller also works.

I booted Buildroot with kernel 5.17 on a Pentium II laptop off a CD I burned once - I needed to dump a drive once and that was the only hardware I had on hand that could dump 2.5” IDE drives and had a working CD drive so I could boot something other than the operating system installed on the drive: