r/linux

I made a small browser game. You answer a few questions, then 32 distros (and 16 desktops) fight through a bracket to suggest one that fits how you actually use your computer.

It's meant to be fun, but the scoring and results are real suggestions rather than random. No signup, no ads, only anonymous aggregate stats. There's also a terminal-based campaign mode if you like messing with real commands.

This new and the campaign is only about 40% complete.

Finally its done, our first stable is released. 🥳
Congratulations and thanks to the whole team, and thanks also to everybody who tested MOS and sent us feedback during the last year.

For everybody who doesnt know what MOS is... MOS is a devuan based free and open source NAS OS without any tracking or telemetry.

If you want to give it a try, please visit mos-official.net or docs.mos-official.net for more infos :)

MOS UI Dashboard

--------------------------------------
Releasenotes for 0.5.0-stable

• Recommended Kernel 6.18.38
• Update Node.js 24.18.0 LTS
• Necessary changes for organization
• Add routine to cleanup pathfix if found
• Cleanup socket on api restart
• Add sleep 1 to prevent restart API from failing
• Move stop order around in mos-stop
• Fix broken mos_start_after_services function
• Fix wrong help text
• Make sure to generate and copy over machine-id
• Add Tailscale and NetBird Docker scripts
• Fix permissions for ntpsec directory
• Make sure to write mergerfs logs into separate logfile
• Fix SnapRAID logfile size getting out of hand
• Fix false error messages on plugin installation on boot
• Make sure to sort vpools by index first before iterating over them
• Add additional logger messages
• Add mount_vpools function
• Create mos-mount_vpools
• Change wording on some return messages
• Make sure to return raw YAML even if YAML is broken for compose
• Add ability to download/install/update plugins from Gitea and Codeberg
• Make sure to chmod/chown QEMU images
• Restart udev monitor when missing disk from pool comes back
• Add docker/hub/recommended endpoint for fetching recommended repositories
• Add ability to specify URLs for Docker group icons
• Fix issue with proper model for SMART attribute acknowledgement
• Add installed key to Docker and Plugins index
• Improve loading times from LXC page
• Add endpoints for creating, configuring, mounting, unmounting, and deleting virtual pools
• Include virtual pools information in diagnostics
• Move virtual pools section, bugfix scrollbar
• Implement automount for virtual pools
• Add missing French translations
• Fix repository link
• Rename vpool to virtual pool
• Add virtual pools feature
• Add CodeMirror oneDark theme for Docker Compose forms
• Fix supporter dialog
• Show device serial in target devices of shares
• Updated u/babel/runtime to version 8.0.0
• Updated u/codemirror/state to version 6.7.0
• Updated u/codemirror/view to version 6.43.1
• Updated vue to version 3.5.39
• Updated vue-i18n to version 11.4.6
• Updated vuetify to version 4.1.2
• Updated vite to version 8.1.0
• Replaced <label> with <v-label> in docker.vue and dockerCompose.vue
• Adjusted styles for YAML and environment variable editors for vertical resizing
• Simplified chip rendering logic in notifications.vue
• Visualize recommended repositories and improved YAML field display in Docker Compose
• Add "Acknowledge" to English translations
• Set defaults for SMART disk attributes and update config after acknowledgement
• Fix acknowledge bug
• Remove unnecessary v-overlay components from Vue files
• Increase line count for environment variables in Compose Stack dialogs

I've noticed a pattern over the years that I'm curious about.

A surprising number of Linux applications, especially smaller projects on GitHub, seem to ship with an incorrect or missing StartupWMClass value in their .desktop file. The result is that when I launch the application from a pinned icon, the running window does not associate with it. Instead, a second icon, often a generic one, appears in the dock or taskbar.

In all cases I can fix it by checking the application's actual WM_CLASS value with xprop and updating the .desktop file to match. Once StartupWMClass is correct, the launcher and running window consolidate into a single icon as expected.

At this point it only takes me a minute to fix, but when I was new to Linux it was incredibly confusing because I had no idea why it was happening or how to resolve it.

My question is whether this is simply something developers frequently overlook, or if there are legitimate reasons why it is often left out or ends up being incorrect. Is it harder to get right than it seems, or is it just an easy detail to miss during development and packaging?

I'm interested in hearing from people who package or develop Linux desktop applications. Is there more to this than meets the eye?

I have been working on building, developing, and prototyping my own modular handheld x86 PC called the CG Deck. After approximately the past 7 and a half months of going from initial concept to functional engineering prototype, I am finally able to officially present the soon coming release of what I have been working tirelessly on over the course of this year! I will also be ramping up and posting more videos of the CG Deck in use, and other related content over the coming days. If you are interested in the project, like the video, leave a comment and subscribe to the channel! I appreciate all of your support so incredibly much, and thank you to everyone that has been following along so far! It means the world to me!

For those who have not seen this project before, the CG Deck is an x86 based modular handheld PC which has the capability of running dual boot operating systems like Windows & Linux. Designed and built to be a device that you actually own down the the firmware. Quick swap out control modules to mix and match control schemes for your specific task. Design and make your own modules, design your own backplates, upgrade or mod the internals, and even make repairs or fixes when or if you need. The CG Deck is more attuned to a platform rather than a traditional device, giving you full capability to repair, upgrade, mod, personalize, etc.

I wanted to create my dream device, something that evolved with me as time passes. Whether I am playing Steam games, or doing retro emulation, doing CAD work in Blender or other 3D software, coding, art & design work, listening to music, home media console use, video editing, hardware tinkering or whatever it is, I wanted to be able to simply be able to do it on a single portable handheld.

Also as a little bit of an update, I am still working on the behind the scenes documentary going over the entire process from the original idea and conceptual drawing, through design iterations, CAD, creating the bill of materials, material sourcing, navigating partnerships with brands and manufacturers, prototyping, assembly, DFM rework, testing & certifications, planning mass production, figuring out the logistics of warehousing and fulfillment, and every step in between all the way though officially releasing and launching the CG Deck and bringing it to market! Because there is so much that has gone into everything (and I am still in the middle of the process doing it all :) ), I will probably post the videos as an episodic series with smaller pieces of content going up between. I will have more information about those videos over the coming weeks, and it will be posted on my personal channel.

After tons of work, we are officially gearing up for an official launch on Kickstarter to help support a full production run of the CG Deck and various modules to bring it to market! The CG Deck will be available both as a DIY Assembly Kit and a Pre-Built ready to use device! I will be sending out more information to everyone on our waitlist over the next couple of days with some new updates & announcements including early bird backer pricing, package/pledge options, and more!

CISA has added CVE-2026-43456, a Linux kernel local privilege escalation vulnerability, to its Known Exploited Vulnerabilities (KEV) catalog following confirmed in-the-wild exploitation. Here's everything covering the affected kernel versions, the vulnerability itself, which distributions have shipped fixes, and the available mitigations. If you're maintaining Linux systems, it may be worth checking whether your kernel has already been updated by your distro. Patch Now.

I was looking up laptops to buy for the first time since 2018, when I saw that nowadays they have a Copilot button next to the right Ctrl. Obviously, pressing that button launches Copilot. So I was wondering, what will that button do if I replace Windows with Linux on such a laptop?

Hey everyone,

PipeASIO 1.2.1 is out. It is a low-latency ASIO driver for Windows music software running under Wine or Proton, connecting directly to PipeWire on Linux.

If you have not checked the project recently, PipeASIO now includes experimental opt-in 32-bit WoW64 support for older 32-bit Windows ASIO hosts. The 32-bit frontend talks to the same 64-bit PipeWire backend, so no 32-bit PipeWire userspace is needed, and the normal 64-bit driver remains unaffected.

Version 1.2.1 is mainly a stability and low-latency bugfix release. Highlights from the recent 1.2.x line include:

• Real-time audio scheduling fixes to reduce xruns under CPU load
• Fixes for the 32-bit WoW64 buffer path, autoconnect, and live config reload
• Fixes for a thread leak, config-watcher lifetime issue, buffer overrun, and long-session sample-position wraparound
• Wine integration probes now run under CTest

The 32-bit path is still experimental. For Proton / Steam 32-bit hosts, Wine's new WoW64 mode is required, usually with:

PROTON_USE_WOW64=1

PipeASIO is currently verified with FL Studio under Proton-CachyOS, VB-Audio ASIO Test 64-bit/32-bit, and the project's Wine integration probes. More real-world reports are very welcome, especially from older 32-bit hosts.

I am also working on winepipewire.drv for Proton-CachyOS, so regular Windows apps and games can get low-latency PipeWire audio too, not only ASIO software. If you are interested in testing that work, please visit the CachyOS Discord server thread: <https://discord.com/channels/862292009423470592/1514956087550541924>

Links:

• Releases: <https://github.com/M0n7y5/pipeasio/releases>
• Docs: <https://m0n7y5.github.io/pipeasio/>
• Support development on Ko-fi: <https://ko-fi.com/m0n7y5>

Bug reports are welcome on GitHub. Thanks to everyone testing PipeASIO and helping improve low-latency audio under Wine and Proton.