weekly check in, what's up?
New profile posts
Hopefully trying Fedora COSMIC and Budgie today on an old CompQ and a optiplex. Hopefully will report back later.
Accidentally nuking my dot-files 
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.