Accidentally nuking my dot-files 
New profile posts
Small update on my Audiobook Shelf Manager project.
I made some big changes to the app and it is finally starting to work the way I wanted.
What changed:
I’m running it as a Flatpak on Ubuntu 26.04 with KDE X11, and it’s feeling a lot closer to how I wanted the app to behave from the start.
Still more I want to improve, but this was a huge step forward.
I made some big changes to the app and it is finally starting to work the way I wanted.
What changed:
- Moved the old “Set Library Root” action out of the main toolbar
- Added a real Settings menu
- Built a proper Settings window with left-side navigation, kind of like a game settings screen
- Added support for multiple library folders instead of only one
- The app now remembers those folders when I open it again
- Multiple folders are scanned into one combined gallery
- Added better support for duplicate artist names across different roots
- Artist grouping now works better for albums with multiple authors/artists
- Albums can show under more than one artist when the metadata has multiple names
- Grouping now prefers Album Artist, then falls back to Artist, then folder names if tags are missing
I’m running it as a Flatpak on Ubuntu 26.04 with KDE X11, and it’s feeling a lot closer to how I wanted the app to behave from the start.
Still more I want to improve, but this was a huge step forward.
T
-
tunac5 dos2unix tunac5 wrote on dos2unix's profile.
I am new to lubuntu (dragonOS) during my update I got an error message ERROR (dkms apport): binary package for limepcie: 0.1.9 not found . several efforts to correct did not help. Any suggestions ?
ITS ALL GOING TO HELL! LINUX THE TV. LINUX THE PC. LINUX THE PHONE. LINUX THE F*ING HOUSE! THEN LINUX THE LINUX BECAUSE F* AGE VERIFICATION!!!
Slowly getting used to to navigating the terminal! Playing around with mkdir and mv.
tired
Chicken peacefully sleeping on pallet in forest. A man walks by and puts a speaker by the chicken, playing the iPhone default alarm sound. The chicken wakes up, startled by the sound.
I'm actually pretty decent at trig, at least what they've taught us during Geometry
physics is hurting my brain....
Checking out other distros. MX looks cool..
Hi everyone,
I wanted to share a small update on my app, Audiobook Shelf Manager.
This is still a work-in-progress audiobook metadata app, but I made some nice improvements to the UI.
The biggest update is the artist view. I changed the artist cards so they now show series completed out of total series directly on the card in a cleaner way. Before, the artist tiles felt more cluttered and repeated information. Now the layout is tighter, easier to read, and fits the style of the rest of the app much better.
I also updated the app name to Audiobook Shelf Manager, which reflects what the app does a lot better.
Right now the app is focused on:
Here is what I worked on in this update:
Feedback is welcome.
Github
I wanted to share a small update on my app, Audiobook Shelf Manager.
This is still a work-in-progress audiobook metadata app, but I made some nice improvements to the UI.
The biggest update is the artist view. I changed the artist cards so they now show series completed out of total series directly on the card in a cleaner way. Before, the artist tiles felt more cluttered and repeated information. Now the layout is tighter, easier to read, and fits the style of the rest of the app much better.
I also updated the app name to Audiobook Shelf Manager, which reflects what the app does a lot better.
Right now the app is focused on:
- editing audiobook metadata
- cover/gallery handling
- tracking progress
- organizing audiobook libraries better
Here is what I worked on in this update:
- renamed the app to Audiobook Shelf Manager
- improved the artist card layout
- added a cleaner series completed X/Y display on artist cards
- tightened spacing so the artist view looks less loose and more polished
- kept the album/series cards working the way I wanted while only tightening the artist UI
Feedback is welcome.
Github
What I am sick of is not change by itself. It is things being forced before they are ready for the people still using what already worked.
Wine is the best example I have right now. Wine 10 introduced the new WoW64 architecture as experimental, and Wine 11 moved further in that direction by saying pure WINEARCH=win32 prefixes are deprecated and not supported in the new WoW64 mode. On top of that, the separate wine64 loader is gone in favor of one wine loader. That may look clean on paper, but for older 32-bit software and older install chains it is not a harmless change. It breaks assumptions people have been relying on for years.
I ran straight into that with TextAloud and an old NextUp/Acapela voice. My old working setup only worked because I had already built a real 32-bit prefix the old way. That was not some random lucky install. It took time to get right, and once it worked, it worked because it was a proper 32-bit environment. With the newer WoW64 path, I could still get TextAloud itself to launch, but the setup no longer behaved the same. I had to force-install speechsdk, and even then it only half-worked. The built-in voices showed up, but my own installed voice did not register properly, so the program could not use it the way it did before. That is not a real replacement. That is a partial workaround that breaks exactly where it matters.
And what makes it worse is the mixed messaging. Winetricks will throw warnings like “You are using a 64-bit WINEPREFIX. Note that many verbs only install 32-bit versions of packages,” and there is a current issue specifically about speechsdk still insisting on a WIN32 prefix. That is exactly the sort of thing that tells users the transition is not finished, no matter how much people want to pretend it is. If the new path was actually ready, it would not be tripping over old 32-bit speech components and old verbs like this.
I tried more than just one thing. I tested the newer WoW64 route. I forced speechsdk. I compared the registry from the old working prefix with the new one. I copied over the parts that were obviously missing. I manually added Acapela-related registry entries. I got far enough that TextAloud opened and the default Microsoft voices appeared, but the custom voice still would not come through properly. In the end, the only thing that actually worked for me was launching the app through Lutris with Wine-GE 8-26 x86_64. That is the only path I found that got me back to something usable. Everything else on the new forced path either failed outright or only half-worked.
That is why I hate this kind of forced transition. I do not care how nice it sounds in release notes if the real effect is that older working setups get turned into debugging projects. If something worked before, and the replacement still cannot cover the same ground, then it is being pushed too early. That is not “fear of change.” That is people being told to accept regressions because the project wants to move on.
And it is not just Wine. KDE has already said Plasma 6.8 will be Wayland-only, with the Plasma X11 session supported only into early 2027 through the Plasma 6.7 line. So the same pattern is showing up there too: the old path is being shut down, and users are expected to move whether their use case is fully covered or not.
So my view is simple. If developers are going to force people off an old path, the new path needs to be ready first. Not “good enough for most users.” Not “fine unless you use older 32-bit software, old voices, old speech components, or old workflows.” Ready. If it is not ready, then they should not force it yet. And if enough real use cases break, then people should keep filing bugs, keep making noise, and keep pushing back until the replacement actually does the job.
Wine Bug Report
Wine is the best example I have right now. Wine 10 introduced the new WoW64 architecture as experimental, and Wine 11 moved further in that direction by saying pure WINEARCH=win32 prefixes are deprecated and not supported in the new WoW64 mode. On top of that, the separate wine64 loader is gone in favor of one wine loader. That may look clean on paper, but for older 32-bit software and older install chains it is not a harmless change. It breaks assumptions people have been relying on for years.
I ran straight into that with TextAloud and an old NextUp/Acapela voice. My old working setup only worked because I had already built a real 32-bit prefix the old way. That was not some random lucky install. It took time to get right, and once it worked, it worked because it was a proper 32-bit environment. With the newer WoW64 path, I could still get TextAloud itself to launch, but the setup no longer behaved the same. I had to force-install speechsdk, and even then it only half-worked. The built-in voices showed up, but my own installed voice did not register properly, so the program could not use it the way it did before. That is not a real replacement. That is a partial workaround that breaks exactly where it matters.
And what makes it worse is the mixed messaging. Winetricks will throw warnings like “You are using a 64-bit WINEPREFIX. Note that many verbs only install 32-bit versions of packages,” and there is a current issue specifically about speechsdk still insisting on a WIN32 prefix. That is exactly the sort of thing that tells users the transition is not finished, no matter how much people want to pretend it is. If the new path was actually ready, it would not be tripping over old 32-bit speech components and old verbs like this.
I tried more than just one thing. I tested the newer WoW64 route. I forced speechsdk. I compared the registry from the old working prefix with the new one. I copied over the parts that were obviously missing. I manually added Acapela-related registry entries. I got far enough that TextAloud opened and the default Microsoft voices appeared, but the custom voice still would not come through properly. In the end, the only thing that actually worked for me was launching the app through Lutris with Wine-GE 8-26 x86_64. That is the only path I found that got me back to something usable. Everything else on the new forced path either failed outright or only half-worked.
That is why I hate this kind of forced transition. I do not care how nice it sounds in release notes if the real effect is that older working setups get turned into debugging projects. If something worked before, and the replacement still cannot cover the same ground, then it is being pushed too early. That is not “fear of change.” That is people being told to accept regressions because the project wants to move on.
And it is not just Wine. KDE has already said Plasma 6.8 will be Wayland-only, with the Plasma X11 session supported only into early 2027 through the Plasma 6.7 line. So the same pattern is showing up there too: the old path is being shut down, and users are expected to move whether their use case is fully covered or not.
So my view is simple. If developers are going to force people off an old path, the new path needs to be ready first. Not “good enough for most users.” Not “fine unless you use older 32-bit software, old voices, old speech components, or old workflows.” Ready. If it is not ready, then they should not force it yet. And if enough real use cases break, then people should keep filing bugs, keep making noise, and keep pushing back until the replacement actually does the job.
Wine Bug Report
I need help I just downloaded Linux cinnamon and I don’t have Wi-Fi I have a WLAN Wi-Fi adapter and I need to know how to download the drivers without internet .
i just found this silly little forum it seems cool Yeah
Just finished setting up Jellyfin on my own Linux network fully self-hosted, local-first, and locked down
I recently deployed Jellyfin inside Docker on my home server and got it running exactly how I want: LAN-only access, no WAN exposure, and controlled outbound traffic. The goal wasn’t just “it works” it was understanding and controlling every layer.
What I did:
I’m very strict about what I allow in and out. Even if I’m not a “target,” that doesn’t mean I should run an open network. When you actually have control over your infrastructure, it makes sense to use it.
Running your own router/firewall + DNS layer:
I wish more people realized this isn’t out of reach. It just sounds harder than it is.
I recently deployed Jellyfin inside Docker on my home server and got it running exactly how I want: LAN-only access, no WAN exposure, and controlled outbound traffic. The goal wasn’t just “it works” it was understanding and controlling every layer.
What I did:
- Installed Jellyfin in Docker
- Mounted multiple large local drives into the container
- Configured nftables firewall manually
- Allowed LAN → Jellyfin (port 8096)
- Blocked WAN → Jellyfin completely
- Carefully allowed Docker → WAN only for required outbound traffic (metadata, plugins)
- Verified everything through logs and container shell access
- Full visibility into DNS queries
- Network-wide ad and tracker blocking
- Control over device resolution and behavior
- A central point for filtering and logging
I’m very strict about what I allow in and out. Even if I’m not a “target,” that doesn’t mean I should run an open network. When you actually have control over your infrastructure, it makes sense to use it.
- Inbound traffic = real exposure → keep it blocked unless needed
- Outbound traffic = controlled, not unrestricted
- Local services = stay local unless there is a clear reason otherwise
- no visibility
- no control
- no understanding of what’s happening on your network
- Docker simplifies deployment
- nftables is consistent once you understand flow (input/forward/output)
- Tools like ChatGPT help you learn while doing, not just copy commands blindly
Running your own router/firewall + DNS layer:
- improves privacy (you decide what leaves your network)
- improves security (reduced attack surface)
- improves reliability (no dependency on external services for local media)
- builds actual understanding of your system
- a Linux box
- some time
- willingness to learn
I wish more people realized this isn’t out of reach. It just sounds harder than it is.
I went from Ubuntu Server 25.10 to 26.04 prerelease. 26.04 comes out next month while I’m on vacation, so I just jumped on it early and took the hit now instead of later. I already knew I was going to run into problems, and I did almost right away.
The first thing that broke was internet after boot. I had no connection until I manually ran sudo systemctl restart NetworkManager. After checking logs, it looked like some boot-order mess involving NetworkManager, netplan-configure, nss-user-lookup.target, and winbind. I was not really using winbind for anything useful, so it was just pointless baggage on my system, and after disabling/removing it, the network side started acting normal again.
Then came the Steam and gaming side. I also had old Flatpak Steam leftovers still hanging around, like com.valvesoftware.Steam.Utility.gamescope and com.valvesoftware.Steam.CompatibilityTool.Proton, both throwing end-of-life warnings even though I do not even use Flatpak Steam anymore. Not a fatal issue, but still more leftover junk causing noise.
Wine on 26.04 prerelease has also been a mess so far. It behaved badly, especially when I tried to run Steam through it. It spent way too much time on locale-related nonsense, and some .exe installers that used to work fine just started hanging or acting wrong. I also had to deal with old Wine cleanup, reinstall confusion, and the usual “is this Flatpak Wine, native Wine, or just old broken leftovers?” mess. Lutris and glxinfo were part of that confusion too, because what the system saw and what I expected it to use were not always the same thing.
Then I hit the MangoHud and GOverlay problem, and that one was the most obvious because it straight up wrecked the image in-game. Bright Memory: Infinite started looking completely broken, with blown-out reflections, giant light bloom, and pixelated garbage all over reflective surfaces. Wayland made it even worse. X11 fixed part of it, especially the “light source looks like the sun exploding in my face” issue, but not all of it. In the end, it turned out my old manually installed MangoHud and GOverlay were part of the problem. I removed the old installs, wiped the old configs so nothing stale got reused, then recompiled both on the new system. After that, the game started looking normal again.
I also had to install missing 32-bit libraries along the way, because Linux gaming still loves to remind you that one missing library can be the difference between “works fine” and “why is this broken now?” The ones I ended up installing were: libgtk2.0-0:i386, libpipewire-0.3-0:i386, libxcb-res0:i386, libc6:i386, libstdc++6:i386, libgcc-s1:i386, libgl1:i386, libvulkan1:i386, libx11-6:i386, libxext6:i386, libxrandr2:i386, libxrender1:i386, libxfixes3:i386, libxi6:i386, libxcb1:i386, libxss1:i386, libasound2:i386.
That is one of the reasons Linux gaming still annoys me sometimes. Two people can have what looks like the same distro, same hardware, same desktop, and still get a very different result just because one system has the right libs, the right rebuilds, the right leftovers cleaned out, or the right bits installed by accident. Once it works, it can work great. But getting there can still be stupid.
To be fair, not everything I hit was a real 26.04 fault. The phased cloud-init update message was just Ubuntu doing phased rollout stuff. The broken audiobook-manager.service was just an old user systemd service pointing to a deleted Python virtualenv, so that was cleanup, not really an Ubuntu bug. But the actual 26.04 problems I hit first were definitely network boot issues, Wine acting badly, Steam/runtime leftovers, MangoHud/GOverlay breaking visuals, and missing libraries.
There will probably be more problems I have not hit yet. These were just the first ones.
The first thing that broke was internet after boot. I had no connection until I manually ran sudo systemctl restart NetworkManager. After checking logs, it looked like some boot-order mess involving NetworkManager, netplan-configure, nss-user-lookup.target, and winbind. I was not really using winbind for anything useful, so it was just pointless baggage on my system, and after disabling/removing it, the network side started acting normal again.
Then came the Steam and gaming side. I also had old Flatpak Steam leftovers still hanging around, like com.valvesoftware.Steam.Utility.gamescope and com.valvesoftware.Steam.CompatibilityTool.Proton, both throwing end-of-life warnings even though I do not even use Flatpak Steam anymore. Not a fatal issue, but still more leftover junk causing noise.
Wine on 26.04 prerelease has also been a mess so far. It behaved badly, especially when I tried to run Steam through it. It spent way too much time on locale-related nonsense, and some .exe installers that used to work fine just started hanging or acting wrong. I also had to deal with old Wine cleanup, reinstall confusion, and the usual “is this Flatpak Wine, native Wine, or just old broken leftovers?” mess. Lutris and glxinfo were part of that confusion too, because what the system saw and what I expected it to use were not always the same thing.
Then I hit the MangoHud and GOverlay problem, and that one was the most obvious because it straight up wrecked the image in-game. Bright Memory: Infinite started looking completely broken, with blown-out reflections, giant light bloom, and pixelated garbage all over reflective surfaces. Wayland made it even worse. X11 fixed part of it, especially the “light source looks like the sun exploding in my face” issue, but not all of it. In the end, it turned out my old manually installed MangoHud and GOverlay were part of the problem. I removed the old installs, wiped the old configs so nothing stale got reused, then recompiled both on the new system. After that, the game started looking normal again.
I also had to install missing 32-bit libraries along the way, because Linux gaming still loves to remind you that one missing library can be the difference between “works fine” and “why is this broken now?” The ones I ended up installing were: libgtk2.0-0:i386, libpipewire-0.3-0:i386, libxcb-res0:i386, libc6:i386, libstdc++6:i386, libgcc-s1:i386, libgl1:i386, libvulkan1:i386, libx11-6:i386, libxext6:i386, libxrandr2:i386, libxrender1:i386, libxfixes3:i386, libxi6:i386, libxcb1:i386, libxss1:i386, libasound2:i386.
That is one of the reasons Linux gaming still annoys me sometimes. Two people can have what looks like the same distro, same hardware, same desktop, and still get a very different result just because one system has the right libs, the right rebuilds, the right leftovers cleaned out, or the right bits installed by accident. Once it works, it can work great. But getting there can still be stupid.
To be fair, not everything I hit was a real 26.04 fault. The phased cloud-init update message was just Ubuntu doing phased rollout stuff. The broken audiobook-manager.service was just an old user systemd service pointing to a deleted Python virtualenv, so that was cleanup, not really an Ubuntu bug. But the actual 26.04 problems I hit first were definitely network boot issues, Wine acting badly, Steam/runtime leftovers, MangoHud/GOverlay breaking visuals, and missing libraries.
There will probably be more problems I have not hit yet. These were just the first ones.
I just got done troubleshooting a really stupid graphics issue in Bright Memory: Infinite on my Linux setup, and it turned out to be a good reminder that sometimes the problem is not the game itself, not Proton itself, and not even Vulkan itself sometimes it is the stuff around it.
In my case, MangoHud was the main problem.
The first video shows how broken it looked before. Reflections were completely messed up, bright light sources looked like the sun exploding in my face, and a lot of surfaces turned into a pixelated mess. On top of that, the whole image looked far worse than it should. X11 helped with part of it compared to Wayland, especially with the insane blown-out reflection/light effect, but it did not fix the full problem. The really ugly pixel mess and broken look turned out to be tied to MangoHud on my system.
What fixed it for me was doing a proper cleanup and rebuild instead of just poking at random settings. I removed my old manually installed MangoHud and GOverlay, wiped the old configs so nothing stale got reused, then recompiled both on my current setup. I also ended up installing some missing 32-bit libraries while cleaning up the system:
libgtk2.0-0:i386
libpipewire-0.3-0:i386
libxcb-res0:i386
libc6:i386
libstdc++6:i386
libgcc-s1:i386
libgl1:i386
libvulkan1:i386
libx11-6:i386
libxext6:i386
libxrandr2:i386
libxrender1:i386
libxfixes3:i386
libxi6:i386
libxcb1:i386
libxss1:i386
libasound2:i386
After that, the game started looking the way it should. That is what the second video shows. The broken lighting, the weird pixelated reflections, and the “what the hell am I even looking at” image quality were gone. After that I was mostly left with the usual kind of stutter I have seen from this game before under VKD3D/DX12, and I also ran out of VRAM because I was playing on max settings while livestreaming from the same machine at the same time, so that part is on me.
This is also one of the reasons Linux gaming can be frustrating. Two people can run what looks like the same distro, same desktop, same GPU, and still get very different results because one system has the right libs, the right rebuilds, the right runtime, or just less old junk left behind from upgrades. Once it works, it can work great. But getting there can still be way more annoying than it should be.
For reference, this was on my own setup, not some clean prebuilt gaming distro. I run Ubuntu Server with KDE on top, and because I tinker, compile things, and upgrade over time, I know full well that old builds and old configs can come back and bite me later. That is pretty much exactly what happened here.
First video: broken mess
Second video: fixed after cleanup, rebuild, and library cleanup
If anyone else on Linux gets bizarre overblown reflections, pixelated lighting, or graphics that suddenly look far worse only when MangoHud is active, do not just assume the game is dead. Check your MangoHud build, your config, and whether you are dragging old installs across distro upgrades.
In my case, MangoHud was the main problem.
The first video shows how broken it looked before. Reflections were completely messed up, bright light sources looked like the sun exploding in my face, and a lot of surfaces turned into a pixelated mess. On top of that, the whole image looked far worse than it should. X11 helped with part of it compared to Wayland, especially with the insane blown-out reflection/light effect, but it did not fix the full problem. The really ugly pixel mess and broken look turned out to be tied to MangoHud on my system.
What fixed it for me was doing a proper cleanup and rebuild instead of just poking at random settings. I removed my old manually installed MangoHud and GOverlay, wiped the old configs so nothing stale got reused, then recompiled both on my current setup. I also ended up installing some missing 32-bit libraries while cleaning up the system:
libgtk2.0-0:i386
libpipewire-0.3-0:i386
libxcb-res0:i386
libc6:i386
libstdc++6:i386
libgcc-s1:i386
libgl1:i386
libvulkan1:i386
libx11-6:i386
libxext6:i386
libxrandr2:i386
libxrender1:i386
libxfixes3:i386
libxi6:i386
libxcb1:i386
libxss1:i386
libasound2:i386
After that, the game started looking the way it should. That is what the second video shows. The broken lighting, the weird pixelated reflections, and the “what the hell am I even looking at” image quality were gone. After that I was mostly left with the usual kind of stutter I have seen from this game before under VKD3D/DX12, and I also ran out of VRAM because I was playing on max settings while livestreaming from the same machine at the same time, so that part is on me.
This is also one of the reasons Linux gaming can be frustrating. Two people can run what looks like the same distro, same desktop, same GPU, and still get very different results because one system has the right libs, the right rebuilds, the right runtime, or just less old junk left behind from upgrades. Once it works, it can work great. But getting there can still be way more annoying than it should be.
For reference, this was on my own setup, not some clean prebuilt gaming distro. I run Ubuntu Server with KDE on top, and because I tinker, compile things, and upgrade over time, I know full well that old builds and old configs can come back and bite me later. That is pretty much exactly what happened here.
First video: broken mess
Second video: fixed after cleanup, rebuild, and library cleanup
If anyone else on Linux gets bizarre overblown reflections, pixelated lighting, or graphics that suddenly look far worse only when MangoHud is active, do not just assume the game is dead. Check your MangoHud build, your config, and whether you are dragging old installs across distro upgrades.