

Not really. If xz were the issue, Debian would have just switched to a different tarball format like lz4.
This is more about Debian packaging conventions being very archaic and requiring a lot of futzing with upstream tarballs and patches.
“Life forms. You precious little lifeforms. You tiny little lifeforms. Where are you?”
- Lt. Cmdr Data, Star Trek: Generations


Not really. If xz were the issue, Debian would have just switched to a different tarball format like lz4.
This is more about Debian packaging conventions being very archaic and requiring a lot of futzing with upstream tarballs and patches.


Weird. Guess it’s a crazy fluke.


Try e-mailing them. I don’t know about that specific mirror, but I use the University of Arizona mirror, and when issues came up, they got back to me pretty quick about what was going on.


That sounds more like something weird about the card itself than with the driver; “power saving feature” makes me think a faulty hardware ACPI implementation by the card vendor is to blame. I’ve had a similar thing happen with my Wi-Fi modem where it would completely crash and only a reboot would fix it; I too have to do special kernel options to get it working.


Honestly, I’ve been tempted by a Kobo lately; I have a lot of Star Trek RPG and comic book PDFs/ePUBs that I got through Humble Bundle over the past couple years.
Kobo seems like the least horrible brand I can get for a reasonable price with a reasonable screen quality; as pleasantly simple and reliable as they seem, and as nice as electronics re-use is, I’m not sure that one Sony e-reader that’s as old as my younger sibling fulfills my use case.
Though honestly, if you have other recommendations for a Linux-friendly color e-reader, I’d be glad to hear them.


Honestly, I have mixed feelings about this.
I’m very squeamish about adding more than the bare minimum external repos, though less so about extrepo stuff. I’m honestly worried this is just going to make it very easy for people to find new ways to break their systems; then again, that may be less likely to happen for the user demographic of Debian, and in the end, that’s no reason not to add a feature this convenient.


https://wiki.debian.org/Teams/DebianNet
It’s an official Debian address, and the main page redirects to .org. I think it has more broad use now, but I think it’s often been used for stuff like media codecs they can’t include in the main distro. Often used for side projects.


What GPU model is it? And what distro are you using?
Did you install separate AMD drivers? You’re generally not supposed to do that; it’s just plug-and-play in the kernel and MESA (assuming the version is new enough), and you usually don’t need to download separate drivers.
Also, what kernel flags did you have to use?
It’s just that I’m a bit skeptical any of this is actually the fault of the AMD Linux kernel driver, and I would guess there’s some underlying software or hardware issue like a faulty ACPI implementation on the motherboard. I’m not saying AMD can do no wrong, but in this case, making blanket statements about the quality of AMD GPU drivers may be premature.


As others have said, “stable” and “unstable” have a different connotation in the FOSS world.
Rolling releases probably don’t have more software crashes than their stable counterparts, which is what you meant.
However, some use cases prefer that they are able to use the same config for a long time, and when software updates frequently, system administration can become a cat-and-mouse game of “What config broke this time?” That’s not to say rolling release is bad, but sometimes it’s like using a power drill instead of a screw driver.
Also, I definitely feel like a stable distro is more likely to survive a software update after not using the computer for a few months to a year. Granted, I’ve had a Debian Testing (rolling release) install that did survive an upgrade after a year of non-use, but I’ve also seen Arch VMs that broke after just a couple months of non-use, forcing me to reinstall.


I went into this Phoronix article half-expecting someone to come up with a venomous, nasty comment over even something this mundane.


for file in *.WAV; do ffmpeg -i “$file” -i cover.png -disposition:v attached_art “$(basename “$file” .wav).flac”
(I’m doing this from memory, so I may have messed something up, but that’s the gist of it for taking a bunch of WAV files and turning them into FLACs with cover art. I also do a similar setup for combining the metadata of an MP3 and audio data of a WAV, since They Might Be Giants seems to have forgotten FLAC was invented.)


From what I can tell, you wouldn’t use it instead of Ansible or another automation system, but rather just support for a config file you can plot in to make setting up automation with any automation system easier by allowing you to put it into a file rather than a gigantic Flatpak install command.


You know, GNOME does some stupid stuff, but I can respect them for this.


Interesting project, but not pulling me off XFCE terminal.
The name sounds like a Romulan senator, though.


At least they provide an official Flatpak now.
Also, this isn’t an official repository, but https://github.com/palfrey/discord-apt works pretty good for me. If you look at the source code for the fetching script and the Github Workflows, you can see that they just pull directly from the Discord website, and comparing file hashes further confirms it. I no longer use it since the official Flatpak is an option now, but it’s still useful.


I would ditch Discord, but the TMBW server is just so darn good and I can’t leave that behind. Maybe I could convince them to set up a Matrix bridge (they already self-host MediaWiki), but then they’d probably end up basically doing this just for me.
My university’s Linux User’s Group is on Discord, but they have it bridged with a Matrix server; due to the current state of things in the US, they only allow political discussion in certain encrypted channels that are exclusive to the Matrix server.


I also recommend dd on a live USB, but with some advice.
First off - and I’m really surprised nobody’s warned you - be EXTREMELY CAREFUL with dd; it is a very powerful tool, but with great potential for data loss. Check your command over and over again to make sure it’s doing what you want before running it, and make sure you have a backup beforehand; it will happily mow over any disk you tell it. Also, do it when you’re fully awake, not at 1 AM or something.
I would call myself an experienced dd user, and even I messed up once recently; I was trying to create a bootable USB when I was really tired. Instead, I overwrote a drive. Luckily, it wasn’t my root drive, and I had a full backup of its contents, so I was able to reformat the drive and restore from backup.
Also, don’t run a bare minumum dd command like dd if=/dev/whateverdevice1 of=/dev/whateverdevice2; it’s going to be an absolute pain in the rear.
dd bs=1M oflag=sync status=progress if=/dev/whateverdevice1 of=/dev/whateverdevice2
bs=1M: The size of block it tries to copy at a time. Play with this a bit, as different drives have different optimal block sizes.oflag=sync: Basically, most operating systems don’t actually write data to the drive right away, but store it in a buffer in RAM to be written later. This is usually fine, but sometimes, you want to be certain that data has actually been written to a drive; this flag turns off that buffering so that when dd is done, the data will for sure actually be on the drive. In lieu of this, you could also just run the sync command afterwards, which forces it to write the current buffer to disk, but I prefer the dd way. It should also do it automatically during shutdown, but I have had cases where a system hangs during shutdown and I’m not certain if syncing is done or not.status=progress: Gives the command a progress bar. It’s just really darn convenient and allows you to see how much time is left, how fast the drive is going, etcetera. I don’t know how anyone uses dd without this. Otherwise, it just shows nothing, and you’re left anxiously wondering when it will be done.if is input drive, of is output drive. I prefer lsblk for looking at the list of drivers.You’ll usually need to run dd with sudo.
Once you do a successful copy, you’ll need to extend your BTRFS partition using GParted or similar. If you have a partition after your main one, like swap, you’ll need to delete the swap partition before extending, then recreate the swap partition and update fstab accordingly.


Cool. Probably still not using it. If I want to run an out-of-tree COW filesystem, I might as well be using ZFS - stable and with less drama.
Also, depending on the time of year, some E series models can drop to pretty low prices on clearance. E series used to suck, but they’ve upped the build quality and they’re pretty good budget Thinkpads now. Most things should be swappable (check Hardware Maintenance Manual to be sure), so back in 2024, I was able to snap an E16 gen 1 with 8 GB RAM 256 GB and upgrade it to 24 GB RAM, 2 TB storage for not too expensive.
The really nifty thing about the E16s is they have dual NVME drive slots; I just kept the OEM 256 GB drive in it and eventually threw a Windows 11 LTSC install on it, as I unfortunately have to use Windows to do a few assignments, which luckily only come up every couple weeks, usually.
I mean, that’s true, but that doesn’t mean that’s why Debian’s doing it.
If they were solving just that, then they would have just pushed for something like a reproducible tarball where you can point to a commit, branch, tag, etcetera from which that tarball can be reproduced and not bother migrating their package format.
Debian has a serious ease-of-packaging issue that I’ve witnessed first-hand, and I think they’ve made it clear that it’s moreso the ease factor they’re focused on that the security factor.