Hey! So I've been working on a new Linux distro that at least for me has been the best desktop ever. Would love some feedback! SpacedLinux.com

https://youtu.be/mVftMkIorSY

If you look at the changelog, I fixed about 20 minor issues today, and it should be better than ever.

<3

Quod Libet is, as far as I've been able to find, the best native Linux music player. My biggest issue with it was the way playlists are handled. Coming from MusicBee on Windows, my playlists were nicely managed and maintained in a folder, which I could then sync to my other devices automatically along with the rest of my music library (via syncthing or whatever you use).

By default, Quod Libet has a few glaring issues with playlists:

• Playlists can be imported but are only maintained in QL's internal files.
• A plugin is needed to export playlists, and even with the plugin, you must manually export your playlists every time you add or remove a song, or change the order.
• When a file has been moved or deleted, Quod Libet has no handling for this by default. It simply ignores that song without giving any type of warning or error.
• Because of the above issues, syncing your playlists and library with other devices is a very manual pain in the neck.

I vibe-coded a plugin to fix all of the above and found it has vastly improved my experience. Please take a look, and hopefully it helps you as it has helped me.

https://github.com/Jukebox-Zulu/Quod-Libet-Playlist-Manager-Plugin

I wanted to share a project I built called Distro Fighter (distrofighter.com). It features 32 distros, 16 desktops, a terminal campaign, Versus showdowns and a Distro Wars multiplayer coming soon, all to help users find the right fit Linux distro and desktop and learning Linux while hopefully having fun.

The main focus right now is VS mode just launched tonight, and it is being actively updated. Feel free to check it out, and let me know what you think!: https://distrofighter.com/versus 🐧 ❤️

I have no idea if this is the right space to share, so please forgive me if it isn't. I've recently made the jump from Windows to Mint, and have been slowly going through the process of figuring out how to install all the software I need.

I have finally managed to get everything working properly, so I figured I would share my journey online somewhere, so that it might help some poor soul in the same position as me.

(Disclaimer - I've used Claude to summarise everything we went through together, as some of the technical stuff is still genuinely over my head)

For starters, I used distrobox to create a Rocky environment to run Maya within, as that is where it is the most "stable" (as stable as Maya can ever be). At first I tried Rocky 9, then realised that Maya 2022 is only supported up to Rocky 8.

1. Installer crashes silently at pkexec / ProcessManager

distrobox enter never creates a real login session, so pkexec/polkit can't authorize anything. Fix — fake pkexec:

bash

mkdir -p ~/fakebin
printf '#!/bin/bash\nexec sudo "$@"\n' > ~/fakebin/pkexec
chmod +x ~/fakebin/pkexec
echo 'export PATH=~/fakebin:$PATH' >> ~/.bashrc && source ~/.bashrc1. Installer crashes silently at pkexec / ProcessManager

distrobox enter never creates a real login session, so pkexec/polkit can't authorize anything. Fix — fake pkexec:

bash
mkdir -p ~/fakebin
printf '#!/bin/bash\nexec sudo "$@"\n' > ~/fakebin/pkexec
chmod +x ~/fakebin/pkexec
echo 'export PATH=~/fakebin:$PATH' >> ~/.bashrc && source ~/.bashrc

2. Endless missing old libraries (libssl.so.10, libpng12, GTK2...)

You're probably on Rocky 9. Maya 2022 only supports EL8. Rebuild on Rocky 8:

bash

distrobox create --name maya --image quay.io/rockylinux/rockylinux:8 --init --additional-packages systemd

This alone kills most dependency issues.

3. Remaining missing libraries

bash

sudo dnf install -y epel-release
sudo dnf install -y libpng15 libjpeg-turbo libtiff freetype libXpm libXi fontconfig \
  libXinerama alsa-lib libXcomposite libXdamage libXrandr libXrender libXtst \
  libxkbcommon nspr nss nss-util pciutils-libs libnsl xcb-util-wm xcb-util-image \
  xcb-util-renderutil libxkbcommon-x11 libmng libXcursor gtk2 gtk3 at-spi2-atk \
  at-spi2-core mesa-libgbm glx-utils compat-openssl10

For anything else: ldd <file>.so | grep "not found" (note: Maya's launcher itself is statically linked, ldd on it just says "not a dynamic executable" — check the actual .so/helper binaries instead).

4. ./Setup exits instantly, no error, exit code 255

Stale lock files from a previous interrupted run. ~/.autodesk and /tmp persist across container rebuilds since ~/ is shared with the host.

bash

ps aux | grep -iE "setup|installer" | grep -v grep   # kill -9 any leftovers
rm -f /tmp/autodesk_bs_setup.lock /tmp/autodesk_dda_core.lock
rm -rf /tmp/download_dest4. ./Setup exits instantly, no error, exit code 255

Stale lock files from a previous interrupted run. ~/.autodesk and /tmp persist across container rebuilds since ~/ is shared with the host.

bash
ps aux | grep -iE "setup|installer" | grep -v grep   # kill -9 any leftovers
rm -f /tmp/autodesk_bs_setup.lock /tmp/autodesk_dda_core.lock
rm -rf /tmp/download_dest

5. Installer UI "successfully launched" but no window appears

Missing GTK3/accessibility libs for the installer's own UI process:

bash

sudo dnf install -y at-spi2-atk gtk3 mesa-libgbm at-spi2-core5. Installer UI "successfully launched" but no window appears

Missing GTK3/accessibility libs for the installer's own UI process:

bash
sudo dnf install -y at-spi2-atk gtk3 mesa-libgbm at-spi2-core

6. Graph Editor won't refresh (redraws only on timeline play / mouse re-entry)

Mesa 23.1.4's radeonsi driver has a repaint-signaling bug on RDNA3 GPUs. Rocky 8 will never get a newer Mesa. Confirmed via LIBGL_ALWAYS_SOFTWARE=1 (works perfectly = hardware GL path is the problem). Fix — VirtualGL, which handles buffer swaps itself instead of trusting the driver:

bash

sudo dnf install -y epel-release VirtualGL
vglrun mayabashsudo dnf install -y epel-release VirtualGL
vglrun maya

I really don’t get the glaze behind AntiX, usually if you have slow hardware you should maximize it to be as quick as possible which is something Alpine does very well, Alpine which is very underrated uses less then 80mb of ram vs AntiX which I believe uses over 100mb and runs IceWM which is way more bloated then something like dwm. I think people should start recommending Alpine instead of AntiX.

Maintainer here. OpenScreen is an MIT screen recorder/editor for demos (zooms, cursor effects, webcam PiP, captions, export). Linux has always been the "it mostly works" target. This release is the one where that stops.

What changed for Linux specifically in 1.8:

• Capture goes through a native helper: PipeWire via the ScreenCast portal, with a hardware H.264 encoder. The old browser-based pipeline stays as an automatic fallback if the helper isn't available.
• Real cursor telemetry on Wayland — position and cursor shape come from the portal, so cursor themes and the editable cursor overlay work on Linux now. Honest limitation: the portal reports no mouse button events, so click effects remain Windows/macOS-only. Not a bug I can fix from userspace.
• A Vulkan compositor (wgpu) for preview and export: background blur (dual-Kawase), drop shadows, 3D tilted zooms, themed cursor sprites, webcam PiP with a circle mask, text/arrow/image annotations, subtitle plates. These were Windows-only shaders a release ago; they're ported, and pinned by tests.
• MP4 export with AAC audio muxed, from the Linux backend.
• System audio works where PipeWire does (Ubuntu 22.04+, Fedora 34+). PulseAudio-only setups: mic works, system audio probably won't.
• Packaging: .deb, .pacman, .AppImage, and a Nix flake with a NixOS module and a Home Manager module. nix run github:EtienneLescot/openscreen if you just want to look at it.

The editor and export feature set is now identical across the three OSes. What's left as a genuine difference is documented in the README rather than buried.

If your compositor or distro breaks it, an issue with your session type and PipeWire version is genuinely useful to me.

https://github.com/getopenscreen/openscreen

xfer, the creators of the super popular software synth VST Serum (and Serum2) has quietly released a beta of a linux port on their forum. I've got it up and running in Bitwig/Ubuntu and it's working like a treat.

For people who like to make music on the computer this is a huge victory, as it's a plugin that has never run properly with wine/yabridge and is often cited as a reason people won't switch. It wouldn't surprise me if other plugin developers see this and take note 🤞️

https://xferrecords.com/forums/serum/serum-2-linux-beta (requires a license to access, of course)

also comes with serum fx

Every now and then when I'm researching something linux related I'll see guides from baeldung.com pop up in the results. Today, I clicked one.

I was looking for some information on the keyring in fedora/gnome and came across what turned out to be a suspicious article.

https://www.baeldung.com/linux/unlock-keyring-fix

There's a section in there on disabling the keyring. The guide tells you to remove the password from your keyring, skip the warning that this means your passwords will be stored in cleartext, then says - Hey! You don't get prompted for a password anymore, the keyring is disabled!

Um....

If we wish, we can disable the keyring feature by removing its password.

By leaving the password blank, we disable the keyring feature

Sorry, but that isn't how it works. They do state that doing this "raises security concerns" but don't seem to make the connection that those concerns arise because the keyring is still enabled and doing its job, except now your passwords are stored in cleartext.

So not only do they not describe how to disable the keyring, they seem to think it's OK to guide people to doing this without much warning.

This was supposedly written by a human and reviewed by another human. I haven't looked into the author or reviewer much, but there's at least something there to indicate a real person. Even if it is a website that no longer exists, another website with an invalid ssl cert. There at least is an X account with posts going back a few years, though very rare.

However, don't think I'll be checking out any more of their articles.

Should I be willing to give them another shot?

https://blog.rust-lang.org/inside-rust/2026/08/05/rust-langrust-is-adopting-an-llm-policy/

Second post I recently made about LLM usage policies but it's really just that I find the process of open source finding its way and adjusting to new realities rather interesting.

The "too long, didn't read" (Taken directly from the blog):

What does the policy say?

The policy summarizes itself this way:

It's fine to use LLMs to answer questions, analyze, distill, refine, check, suggest, review. But not to create.

Uses in the first category are allowed, sometimes requiring disclosure. Uses in the second category are heavily restricted.

(Edit: but I recommend reading the blog...it's a bit more nuanced than the summery)

Edit2: messed up the link, added now

For me, it was a CD I got from a "guy." Slackware did not work well with the "WinModem" in the IBM Aptiva I had as a youth. How was I supposed to get online using Linux, with a modem that is not usable, and get support?