The Linux Thread - The Autist's OS of Choice

  • The Kiwi Farms was targeted with a historic DDoS attack last week. Confirmed reports of 2.8Tbps on an individual provider, topping 4.8Tbps when known volumes are added together, and possibly up to 8Tbps if the attacker is believed. This is the third of fourth largest recorded.
  • Want to keep track of this thread?
    Accounts can bookmark posts, watch threads for updates, and jump back to where you stopped reading.
    Create account
I'm trying it now, there is a slight delay but it's definitely not a second, let alone two. It is there though, I know I've used X11 DEs in the past where terminal emulators and other simple programs launched instantly.
is your system under load or not? if its not under load then blame wayland or other shit, but if you are nearing 98 percent or such, it might lag a bit. ive had bullshit issues where if have 40 firefox tabs open and copy and paste sometimes likes to fail.
 
Well I did guix pull and added yt-dlp to my packages and it pulled 25 for some reason
yt-dlp 25? That's really weird. Have you done "guix pull" recently or after installing your system? It updates all package definitions from all of your channels. Also, I'm not 100% sure what ships with the default Guix installation, but you might want to add the new Codeberg repo into your channels if they haven't yet made it the default. Should look like:
Code:
(channel
  (name 'guix)
  (url "https://codeberg.org/guix/guix")
  (branch "master")
  (introduction
    (make-channel-introduction
      "9edb3f66fd807b096b48283debdcddccfea34bad"
      (openpgp-fingerprint
       "BBB0 2DDF 2CEA F6A8 0D1D  E643 A2A0 6DF2 A33A 54FA"))))
If that's not it then I'm not really sure why it would pull 25. My guix search shows it as being up to date
Code:
name: yt-dlp
version: 2026.03.17
outputs:
+ out: everything
systems: x86_64-linux
dependencies: ffmpeg@8.0 nss-certs-for-test@3.101.4 pandoc@2.19.2 python-brotli@1.0.9 python-certifi@2025.06.15 python-hatchling@1.27.0 python-mutagen@1.47.0
+ python-pycryptodomex@3.23.0 python-pytest@9.0.2 python-requests@2.32.5 python-urllib3@2.5.0 python-websockets@13.1 zip@3.0
location: gnu/packages/video.scm:3300:2
homepage: https://github.com/yt-dlp/yt-dlp
license: Public Domain
synopsis: Download videos from YouTube.com and other sites 
description: yt-dlp is a small command-line program to download videos from YouTube.com and many more sites.  It is a fork of youtube-dl with a focus on adding new
+ features while keeping up-to-date with the original project.
relevance: 32
 
yt-dlp 25? That's really weird. Have you done "guix pull" recently or after installing your system? It updates all package definitions from all of your channels. Also, I'm not 100% sure what ships with the default Guix installation, but you might want to add the new Codeberg repo into your channels if they haven't yet made it the default. Should look like:
Code:
(channel
  (name 'guix)
  (url "https://codeberg.org/guix/guix")
  (branch "master")
  (introduction
    (make-channel-introduction
      "9edb3f66fd807b096b48283debdcddccfea34bad"
      (openpgp-fingerprint
       "BBB0 2DDF 2CEA F6A8 0D1D  E643 A2A0 6DF2 A33A 54FA"))))
If that's not it then I'm not really sure why it would pull 25. My guix search shows it as being up to date
Code:
name: yt-dlp
version: 2026.03.17
outputs:
+ out: everything
systems: x86_64-linux
dependencies: ffmpeg@8.0 nss-certs-for-test@3.101.4 pandoc@2.19.2 python-brotli@1.0.9 python-certifi@2025.06.15 python-hatchling@1.27.0 python-mutagen@1.47.0
+ python-pycryptodomex@3.23.0 python-pytest@9.0.2 python-requests@2.32.5 python-urllib3@2.5.0 python-websockets@13.1 zip@3.0
location: gnu/packages/video.scm:3300:2
homepage: https://github.com/yt-dlp/yt-dlp
license: Public Domain
synopsis: Download videos from YouTube.com and other sites
description: yt-dlp is a small command-line program to download videos from YouTube.com and many more sites.  It is a fork of youtube-dl with a focus on adding new
+ features while keeping up-to-date with the original project.
relevance: 32
yeah i just guix pulled today did a guix search its trying to get 25.09.23
i did notice when i did guix system describe im running a commit from 9 months ago but theres a bug in stable right now thats having people downgrade to this commit with --allow-downgrades or else you cant update at all
 
In what way? I've been using two clients no problem. I use this for window switching like Eve-O Preview.

How did you set up hotkeys? I've tried to use this one before, and while the previews work, and clicking them works, I can't get hotkeys to work consistently. Like it might work every once in a while, but then not again for a very long time. Both setting specific clients to a specific key, and trying to use a key like tab to switch to the next client over.
Screenshot_20260602_124628.png
 
How did you set up hotkeys? I've tried to use this one before, and while the previews work, and clicking them works, I can't get hotkeys to work consistently. Like it might work every once in a while, but then not again for a very long time. Both setting specific clients to a specific key, and trying to use a key like tab to switch to the next client over.
View attachment 9089483
I'm using evdev on x11. You also have to hit the Save button frequently.
 
Something you may have wondered about when using certain software on Linux is why it refuses to use your preferred file manager when you save and load. For Audacity 3 (+ prior versions) the reason is that its built in a way that defaults any file management dialog on that software to a fugly GTK based one regardless of what you have it set as the default. This is more noticeable if you use a non-GTK FM in a Qt based environment with Dolphin like I do, but it is still a problem on GNOME (or any other GTK based DE)

The reason why is because even though this functionless fallback might look like the FM that got lobotomized due to "use case?", it is not. As such it doesn't follow certain user expectations for Nautilus like plugins or w/e. But this isn't an unsolved problem, GTK3 has had a method to respect native file choosers with GtkFileChooserNative for a very long time now. In fact its existed in GTK3 since 3.20 which was released 10 fucking years ago. So I decided to just patch this feature into the source of Audacity myself:

View attachment 9087018

Originally I was waiting for Tentacruel & Co to finish their rewrite of Audacity 3 from wxWidgets/GTK3 to Qt which will most likely fix this by default, but its taking forever and also might be shite. Because of that I also suspect if I commit this it will probably be received like any new commits to X11; that is sent straight to the trash with "use new thing instead". - For anyone who want this its probably best to just use the fork of Audacity 3 which I think(?) already does this. The last time I tried it doe there were some major stability regressions compared to default Audacity 3. But YMMV.
shouldn't this be something you can set as a system setting instead of per-application? tired of the gtk browser
 
The only time I've ever had Cinnamon crash was when I was trying to play an old pinball game on steam that had a messed up emulator. I think it was running a really old version of wine that was wrapped up and shipped as a Linux game so it was running under the Linux backwards compatibility tool
I've had a bunch of odd issues with it. It isn't anything that is a showstopper, but the annoyances build up over time.
 
JFYI: ArchWiki article, and this thing was such a friggin lifesaver. The rundown is "install libbluray, libaacs, and libbdplus, download that KEYDB.cfg file and place it in the proper directory, plug in your BD drive, and be blown away at how Evangelion 1.11's Blu-ray disc plays flawlessly. Totem was my video player of choice for years, but GNOME Video deprecated disc playback (insert Emmanuele_Bassi_UHMUSECASE_Soyjak.jpg here). Celluloid worked, but I ultimately settled on VLC because it still plays discs with menus well enough. I can't speak about proper 4K UHD discs, but basic bitch 1080p blu-rays should be the least of your worries. Just don't be a fucking retard like me and key in pacman -Syu libaacs libbdplus libbluray on your Fedora console.
I got around to trying this, I had to hunt for an up to date KEYDB.cfg file but I have 1080p Blurays working swimmingly. It looks like for getting UHD playback on my LG WH14NS40, I will need to do some bootleg firmware flashing again.

EDIT:
After much LLM-whispering and fucking around with very poorly documented software, here is my advice: anyone seeking to flash a virgin Bluray drive to make it into a LibreDrive with MakeMKV on Linux should use the old 1.17.7 version which can be found here, and just compile the libraries (oss) and binary (bin) from source. Do not bother with the flatpak, and while MakeMKV 1.18.3 works with already flashed drives, performing it for the first time on Linux does not work due to a regression in versions after 1.17.7. I trust you, the reader, to look up the correct firmware and compatibility with your respective Bluray drives, but I also believe anyone comfortable with a little tinkering can do this without trying to pay $200 to some Southeast Asians trying to hock pre-flashed drives or worse, 'remote flashing' services.

EDIT 2:
I grabbed Total Recall as my test disc, and it was very easy to just turn testing the drive into watching Total Recall.
 
Last edited:
EDIT:
After much LLM-whispering and fucking around with very poorly documented software, here is my advice: anyone seeking to flash a virgin Bluray drive to make it into a LibreDrive with MakeMKV on
I have a libre drive compatible drive but after trying to figure out how the fuck to do it I gave up and need to ask someone how

@Ferryman so I'm going to eventually migrate from gnom to exwm once I've figured out how to use Emacs. Starting the lectures today got some very light config setup. I'm curious if you know much about linux-libre and wayland? There's a rust project for ewm and some other stuff happening in the pipe to get Emacs compositor on Wayland but Is Wayland against the gnu philosophy
 
Last edited:
I have a libre drive compatible drive but after trying to figure out how the fuck to do it I gave up and need to ask someone how
It's not hard if you know the right path, the issue is the current documentation is just bad. I imagine Bluray rippers want to keep this hush-hush to justify selling 4K rips or hosting streaming sites that are raped by ads.

  1. Check that your given Bluray drive is compatible, and find the matching firmware. Extract it, and also download sdf.bin from MakeMKV.
  2. For specifically Linux users, download the makemkv-oss-1.17.7.tar.gz and makemkv-bin-1.17.7.tar.gz from this old downloads archive for MakeMKV. If you want, go ahead and also grab the latest version as well.
  3. Extract both the tar files. To compile the libraries you'll need to run configure, then make, then sudo make install. For the binaries, just make and sudo make install.
    1. If you do want the latest version, you can extract and compile the oss and bin archives for the latest version, and then just extract the 1.17.7 precompiled binary from bin/amd64 to your working directory.
  4. Now that you have the libraries installed and the 1.17.7 makemkvcon binary either installed or extracted to a working directory, open a terminal shell as root through sudo -i or your preferred method.
  5. The command to actually start the firmware flash: 'makemkvcon f -v -d <driveID> -f [sdf.bin] rawflash <main or enc> -i [firmware.bin]'. Whether you use main or enc depends on your drive and the age of the firmware and more information can be found here. If you've compiled and installed the latest and you're using the standalone 1.17.7 just for the initial flash, make sure you're running the binary in your working directory.
  6. Once you run the command, you should get a prompt for 'yes' to confirm you're ready to flash the firmware. Once you do, you'll get a progress bar. Once the progress bar is complete, the drive will be successfully flashed to the new firmware. Some drives can jump straight to a LibreDrive firmware, some have to hop through two flashes to do it.
  7. An easy way to verify if the LibreDrive firmware is installed is to pop a Bluray into the drive, and then run "makemkvcon info dev:<driveID>". If you see something like "Using LibreDrive mode (v06.3 id=111111111111)" then it's working. Regular 1080p Bluray playback will still work as normal, but now you can use MakeMKV to rip 4K UHD Blurays.
  8. There were some potentially unnecessary steps I also took by advisement of ChatGPT, I will include them in case it helps someone:
    1. Disable SELinux temporarily with "sudo setenforce 0", and re-enable it after the flash with "sudo setenforce 1". SELinux does try to prevent exactly the sort of shit we're doing here, but this may not have been necessary as the regression in 1.18.3 was also preventing this from working.
    2. Instead of using a high-level drive designation like /dev/sr0, you may want to try using your Bluray drive's true device number, e.g. dev_21.
This write-up is still probably somewhat incomplete, so here be dragons and so forth. And as with anything involving device firmware, this can theoretically brick your Bluray drive if you stop flashing it midway. Don't flash your LibreDrive in a thunderstorm.
 
Last edited:
i forgot if i ever wrote about this on here but i have a particularly strange issue on artix linux where the mouse feels...off. i'll move it around but it feels like its lagging behind...

initially i believed it was the built in smoothing that most distros have ('acceleration') but turning it off did...nothing. ('off' being 'flat') - thus i've been using regular arch linux for a while now... is there a known fix for this? searching it up provided nothing.

for details:
gpu is an rx 9060xt 8gb,
cpu is an amd ryzen 5 7500f,
16gb ddr5 ram,
iso was xfce openrc stable.
 
i forgot if i ever wrote about this on here but i have a particularly strange issue on artix linux where the mouse feels...off. i'll move it around but it feels like its lagging behind...

initially i believed it was the built in smoothing that most distros have ('acceleration') but turning it off did...nothing. ('off' being 'flat') - thus i've been using regular arch linux for a while now... is there a known fix for this? searching it up provided nothing.
Stop using fentanyl.
 
For whatever reason Louis is constantly subjected to the horrors of licensed paid proprietary software and his conclusion is never "maybe we should look for ethical free software alternatives"
 
i forgot if i ever wrote about this on here but i have a particularly strange issue on artix linux where the mouse feels...off. i'll move it around but it feels like its lagging behind...

initially i believed it was the built in smoothing that most distros have ('acceleration') but turning it off did...nothing. ('off' being 'flat') - thus i've been using regular arch linux for a while now... is there a known fix for this? searching it up provided nothing.

for details:
gpu is an rx 9060xt 8gb,
cpu is an amd ryzen 5 7500f,
16gb ddr5 ram,
iso was xfce openrc stable.
Is this an older wireless mouse? You're not using wayland experimental right? maybe change your mouse curser icon to a different one?
 
I have a libre drive compatible drive but after trying to figure out how the fuck to do it I gave up and need to ask someone how

@Ferryman so I'm going to eventually migrate from gnom to exwm once I've figured out how to use Emacs. Starting the lectures today got some very light config setup. I'm curious if you know much about linux-libre and wayland? There's a rust project for ewm and some other stuff happening in the pipe to get Emacs compositor on Wayland but Is Wayland against the gnu philosophy
As far as the GNU project is concerned, Wayland is A-OK since it is 100% free software. Some of the most prolific Guix devs like Hilton Chain or Franz Gefke both use Wayland compositors (Niri & Sway respectively). I've used Hyprland, Sway and DWL, all of which run great. The whole X11 vs Wayland thing is played out. Both suck dick, just pick what flavor of dick you prefer: keylogger monolith or tranny redhatware. As far as XLibre is concerned, there's a third party Guix channel for it and it just werks as a drop in replacement for X11. I only messed around with it for like a week before jumping back cause xnamespace is still broken. If you wanna use X, XLibre is probably the way to go since it still gets commits pretty much daily (the Guix verison is updated with every major release).
 
As far as the GNU project is concerned, Wayland is A-OK since it is 100% free software. Some of the most prolific Guix devs like Hilton Chain or Franz Gefke both use Wayland compositors (Niri & Sway respectively). I've used Hyprland, Sway and DWL, all of which run great. The whole X11 vs Wayland thing is played out. Both suck dick, just pick what flavor of dick you prefer: keylogger monolith or tranny redhatware. As far as XLibre is concerned, there's a third party Guix channel for it and it just werks as a drop in replacement for X11. I only messed around with it for like a week before jumping back cause xnamespace is still broken. If you wanna use X, XLibre is probably the way to go since it still gets commits pretty much daily (the Guix verison is updated with every major release).
Yeah I've got xlibre on my slave drive on my main desktop but I mostly just use Wayland because that's where all the action that pertains to me and my projects I'm working on is
But for thinkpad I'm trying to go all in on Emacs and wasn't sure if I should bother with exwm autism if I'm going down the systemcrafters rabbit hole or if I should branch off into other compositors
 
But for thinkpad I'm trying to go all in on Emacs and wasn't sure if I should bother with exwm autism if I'm going down the systemcrafters rabbit hole or if I should branch off into other compositors

Make Emerald McS et al PhD at the University of Texas Instruments proud, @acid_ra1n. If you can't do it in Emacs, it's not worth doing. C'mon man, go the whole nine yards!

***

@wew lad I wanna give you an update on the local inference crap I brought up in the same post as the blu-ray stuff you quoted.

I specifically gave Ollama a whirl with the Podman container for Open WebUI to give me a GUI in Firefox. Protip: make damn sure your Ollama instance is pointing to 0.0.0.0 and not 127.0.0.1. I don't know why, but Podamn really fucking hates the normal fucking localhost IP address. I'm not gonna lie, Ollama is more of a novelty than it is something well and truly useful... but it was certainly quite handy to have a local chatbot sanity check my bash scripts instead of wasting ChatGPT or Claude tokens. I honestly felt compelled to give Ollama a fair shake on my desktop precisely because the 9070 XT was AMD's first graphics card where they didn't neglect the self-hosted LLM crowd. Just don't expect Llama3.1, Qwen2.5-coder:14b, or deepseek-r1:14b to diagnose why your Steam game crashed via the Proton logs. You're gonna get a ton of "oi m8 did u update ur shit?"

After screwing around with this stuff for a couple of days, this is what I can definitively attest to:

a) Fedora 44 + 9070 XT + Ollama + ROCM (pulled by Ollama from your distro's repos via the curl script) + your choice of graphical overlay = surprisingly excellent local inference platform.

As I understand it:

* Fedora naturally tracks the latest and greatest technologies. AI is very explicitly tracked by the Fedora Project, the package selection is simultaneously current and robust, and Ollama's curl script more or less pulls everything from Fedora's own repos instead of setting some obscure affair in ~/.local/bin like pip does.

* Based on my testing, I'm more than willing to say that our 9070 XTs are able to chug along perfectly while running models within the 7B-14B range (if you're looking to contain everything entirely within your GPU's VRAM). The software stack, to this point, did not give me any issues. I didn't have to fiddle with obscure rocm.conf files or anything along those lines. No hit to my CPU or RAM usage, which meant ROCM was definitively using my GPU first and foremost instead of offloading crap to the CPU like it would with RDNA1-3 cards.

* Ollama itself is more or less llama.cpp for people who can't git gud. The setup script on the home page really is all-encompassing. Bootstraps everything without any muss or fuss whatsoever. I pulled llama3.1:latest (it defaulted to the 8B parameter model) and deepseek-r1:14b. The former for general purpose LLM stuff and the latter for longer form chain-of-reasoning crap. The learning curve with Ollama isn't so much a curve so much as it is a cliff. You have a seamless onboarding with the script, and then suddenly it amps up like you're a longtime AI researcher or a turbosped hobbyist. Nothing within the false beginner to intermediate range, I'm afraid.

* I was expecting horrific nightmares with ROCM, but I came out pleasantly surprised. I'm sure that 16GB of VRAM has something to do with why the experience is so smooth, but it's also kinda nice to just own a flagship GPU, and actually feel like you're getting flagship levels of support and development. No complaints here until I decide to attempt ROCM with my RX Vega 64 again.

* Open WebUI in a Podman container is kinda where I just "naturally" ended up... because the AppImages for stuff like Chatbox AI and Open WebUI were subpar, Alpaca is only available as a Flatpak (and I can't stand Flatpak permissions fuckery anymore), and I was like "okay, fine! I'll do the stupid container crap like the ecosystem wants me to do... far be it from me to expect a local desktop application and not a containerised web service" Homeboy, this shit feels like a cross between early ChatGPT and Perplexity. There's tons of knobs to fiddle with, uploading files works as expected, you can set up full-on workspaces and notes, and other odds and ends I'm sure I'm unintentionally omitting. Podman with a systemd --user service for persistence was... surprisingly painless. I probably should learn the Firewalld zone methodology, but firewall-cmd is still more than able to open port 3000 on my LAN for other devices on my network (i.e. my phone) to access. No SELinux issues either!

b) Local inference, at this point given how recently I'm fiddling with it, is more of a novelty or a toy than something legitimately transformative. HAVING SAID THAT... it did produce a tangible benefit, and I would be disingenuous if I didn't share. Spoiler tagged as below.

My home server runs FreshRSS, Jellyfin, Navidrome, Wallabag, and WireGuard via Docker Compose. I am hideously lazy when it comes down to updating my containers, and that's not a best practice; it's a worst practice.

I started a new Llama3.1 chat thread, and I was like "hey man, I don't think I can really benefit that much from local inference but I'll give it the old college try. My desktop is pure manual, and it's better to be manual rather than pure automated because I'll actually know when to reboot for kernel updates. My home server has a bunch of Docker Compose services running and I suck at updating them manually. I haven't automated it because I'm afraid of the complexity."

Llama3.1 basically said "Yeah, I agree, your daily driver desktop don't need automation. Your home server has room for improvement." Relevant section, verbatim.

Llama3.1 said:
Updating system packages, refreshing Docker Compose services, and rebooting if necessary are good candidates for automation.
You have several options to automate this process, but I'd recommend starting simple:

Create a bash script that runs the update and refresh commands, similar to your existing script.
Use cron (or systemd-timer) to schedule the script to run weekly or daily.

Now, I actually already have a system package updater script. I adapted it from some experimentation I documented here back in January.

Code:
#!/usr/bin/env bash
set -e

apt_updater() {
        sudo apt update && sudo apt full-upgrade -y
}

main() {
        apt_updater
}

main "$@"

So, I said "hey man, I already have a script going. Lemme share it and you tell me where I can go from here." Pasted the script, and then it gave me the below output.

Code:
#!/usr/bin/env bash
set -e

apt_updater() {
  sudo apt update && sudo apt full-upgrade -y
}

refresh_docker_services() {
  for service in freshrss jellyfin navidrome wallabag wireguard; do
    cd "$service"
    docker-compose pull && docker-compose up -d --force-recreate
    cd ..
  done
}

main() {
  apt_updater
  refresh_docker_services
}

main "$@"

This had me taken aback. It looked really clean. Just invokes a loop, changes into the correct directory, pulls the latest image, forcibly recreates the container, exits, and repeats until it reaches the end of the line. There was just one hitch that I didn't immediately catch until I tried running it and it failed.

Code:
refresh_docker_services() {
  for service in freshrss jellyfin navidrome wallabag wireguard; do
    cd "$service"
    docker-compose pull && docker-compose up -d --force-recreate
    cd ..
  done
}

Llama3.1 hyphenated docker compose. Take the hyphens out like so

Code:
    docker compose pull && docker compose up -d --force-recreate

and it works as expected! In absolute fairness, I didn't immediately jump at modifying my updater script. Forcibly recreating the containers made me go "wait, what?" until I saw that all my services already have clearly defined volumes, so data loss was no big issue. The next big step would be to properly schedule a cron job or a systemd-timer service. My heart is telling me "cron job! cron job! do the cron job!" but my brain is saying "dude, you're already fiddling with systemd --user services. It doesn't hurt to learn systemd-timer and actually see whether or not it's better than a simple cron job."

Either way, that's a pursuit for when I have brain power left to spare. For now, I'm honestly pleased with the results even if it wasn't a one-shot one-kill affair.

The TLDR is "you still stand to benefit from having local inference on your daily driver hardware, and you'd be a fool to pass it up if you're using Fedora as your daily driver OS paired with a 9070XT, especially considering that AI is one of the explicit use cases that Fedora necessarily targets because Red Hat wants RHEL to handle AI stuff too. It feels like a toy, for the most part, but I still got legitimate use out of it. Results weren't flawless, but sitll good enough to justify further fiddling."
 
Last edited:
Make Dr. Emerald McS et al PhD at the University of Texas Instruments proud, @acid_ra1n. If you can't do it in Emacs, it's not worth doing. C'mon man, go the whole nine yards!
When I guix searched yt-dlp one of the packages was for Emacs and that got me curious as to how literal your statement is
 
Back
Top Bottom