TL;DR

- the kernel's eBPF verifier as a first gate

- exhaustive pre-production testing

- a multi-day staged rollout through progressively larger traffic tiers

- feature flags for decoupling feature activation from binary deployment

- atomic program replacement via bpf_link

- graceful reload mechanisms that preserve the data plane during upgrades

- pinned BPF maps that survive daemon crashes

- configuration management for location-specific logic

MicroXLinux is a small experimental Linux distribution with an ISO around 16.3 MiB in size that uses a precompiled Linux kernel from Tiny Core Linux's Core-17.1.iso. MicroXLinux is not one of my main projects, it's just something I made in like, 5-10 minutes. The GitHub repository is at https://github.com/MSK-Kernel/MicroXLinux and is under the General Public License v3.0.

I’ve been trying out a bunch of resource monitors lately (gnome-system-monitor 51.1-1, plasma-systemmonitor 6.8.1-1, xfce4-taskmanager, tmog, htop, btop 1.4.7-1) and noticed something about how most of them show RAM and CPU usage.

I get why the way, tree view is calculated right now.

It makes sense for apps or web developers who need to debug a specific stuck process, a single tab, or check how sandboxing works.

But for average users just trying to see what’s eating up RAM, having modern browsers split into dozens of processes makes the default view pretty annoying.

In gnome-system-monitor and plasma-systemmonitor process pages, seeing every individual sub-process without an easy total sum on the main application row is confusing. Most regular users don't care about isolated helper processes or PIDs, they just want to know "how much total memory is my Firefox/Chromium browser using right now?"

It gets even more confusing when you see how `Systemd` handles user processes and shared libraries.

Out of all the ones I tried, btop (1.4.7-1) is one of the few that actually groups and adds up the tree usage the way I prefer. plasma-systemmonitor also has an Applications page which helps but it lacks of system process like VM.

I’m not saying they should display the way I'm proposing. Process view is essential to power users, but having an easy opt-in setting for aggregate app grouping would make tracking system usage way better for everyday use.

I could be wrong, I think Windows or Android group things like the way I'm describing, I've not used Windows for years now, feel free to criticise my proposal.

I got inspired by the original "Powered By CachyOS" shared on r/cachyos earlier this week and started working on my version of it. I then decided to create the sticker for other distros. I've included .png and .svg for each in the following link:

https://we.tl/t-p4ji5A0e2yd8YjR3

feel free to download, copy, modify, whatever you need. Also let me know if you'd like to see another distro included.

I just started my PhD in Engineering at an R1 university, and I’m surprised by how little Linux I see around me. I always thought that research was where I’d find people running it on their desktops and laptops. So far, I’m the only person in my whole department (as far as I have explored) using Linux as my only OS on a laptop. There is HPC running Linux but thats obvisous. Granted, my field is not computer engineering, but I am in computational materials and mechanics, for which I thought I would have some of my cohorts running Linux.

Honestly, it’s starting to get to me. Being the odd one out has me tempted to just switch to Windows or Mac and blend in.

So if you’re using Linux as your main OS in academia, I’d love to hear about it! Possibly, show us your workstation (the physical setup, not just a desktop screenshot) and tell us what you use it for. I could use a little inspiration to stay the course. :D

0.1.3 is out: https://github.com/AIIX/RiftLinux/releases/tag/v0.1.3

I wrote up my findings and the fixes here: https://aiix.space/blog/riftlinux-0-1-3-stability-release/ Follow my blog for updates on RiftLinux and the CV1 work.

Quick update for anyone who tried 0.1.0. Since my last post there's been 0.1.1, a 0.1.2 pre-release and now 0.1.3, and a lot of it came from your bug reports, so thank you.

The big one: games launched from Steam now go into the headset. The most common report was VRChat opening in desktop mode, or Beat Saber saying OpenXR isn't installed. It never happened to me because I always started SteamVR by hand first. Proton VR games need SteamVR running before the game starts, and Steam on Linux doesn't start it for you. RiftLinux now starts SteamVR when you put the Rift on (or pick it up), like the Oculus app does on Windows.

Other changes since 0.1.0:

• Games you added to Steam yourself as a Windows program (e.g. Beat Saber bought somewhere else) now launch from SteamVR Home's library.
• If SteamVR's compositor dies (I hit a few NVIDIA GPU faults, mostly right after a game quit), RiftLinux closes SteamVR and Steam starts it again.
• SteamVR sometimes hung forever on shutdown, and nothing would start until you killed it. RiftLinux now ends it.
• Face shields and thick face pads: the wear sensor often can't see your face, so the picture went black while you were wearing it. Since 0.1.1 the headset also counts as worn when it moves like a head. 0.1.3 makes that much stricter, so holding it in your hands or leaving it on a bed doesn't count.
• Taking the headset off now shows black instead of switching the display off (it still switches off after 10 minutes). On GNOME 48 with NVIDIA, every display off/on leaked GPU memory until GNOME Shell ran out. Not an issue on KDE or Plasma Shell.
• Moving around on a bed no longer wakes SteamVR from standby. Waking on pick-up, like on Windows, is a setting.
• Touch controllers now go to sleep when you're not using the headset. They used to drain their batteries overnight.
• SteamVR's menu no longer opens backwards at start, and Steam's menu closes once a game is showing.
• From 0.1.1: steadier tracking with the rear headband LEDs, the headset held in place when no sensor can see it, thumbsticks that read zero at rest.
• From 0.1.2: a fix for a loop in RiftLinux that could crash GNOME Shell on GNOME 50 when the headset's display went dark (reported on AMD).
• riftlinux-setup check finds a lot more of what keeps games out of the headset (leftover SteamVR-OpenHMD or ALVR registrations, another OpenXR runtime, launch options, USB power saving), and riftlinux-setup fix puts the tested config back in one go, with backups.

Everything new has a switch, and the old behaviour is still there if you want it back. Some of them:

• riftlinux-setup autostart off if you don't want SteamVR to start by itself, or autostart trigger put-on so only putting the headset on starts it
• riftlinux-setup standby pick-up to wake SteamVR when you pick the headset up, like on Windows
• riftlinux-setup wear-sensor test shows what your wear sensor reads, and wear-sensor levels fits it to a heavy face pad; wear-sensor motion high|medium|low|off sets how quickly head movement counts as worn (face shields)
• riftlinux-setup not-worn off to switch the display off when you take the headset off, like 0.1.0 did
• riftlinux-setup controller-sleep 3|5|7|off for when the controllers go to sleep
• riftlinux-setup game-menu keep if you'd rather Steam's menu stayed open when a game starts

Which ones fit which setup (heavy face pads, a headset that lives on the bed, Windows-like standby) is in the blog post, and they're all on the settings page: https://riftlinux.com/guide/settings/. If you edit settings.json by hand and break it, RiftLinux keeps using the last settings it could read, and riftlinux-setup fix last-known puts them back.

To upgrade, install the new package and restart Steam once.

Mostly tested on NVIDIA, Gnome and KDE Plasma 6.8.2. The GNOME 50 fix was checked on an AMD card, but the rest hasn't been tested on AMD or Intel yet, so reports from those would really help.

Known issues are in the release notes.

Adobe has ignored Linux for decades. Hopefully, they won't be surprised when others eventually fill that gap.

I don't think alternatives to Premiere Pro or Photoshop are gaining attention simply because many of them are free. There's another important factor: people don't necessarily want their choice of professional software to dictate which operating system they have to use. In my own software projects, I always try to support all three major desktop platforms: Windows, macOS and Linux, whenever technically possible.

If there's a reasonable way to make my software work across all three operating systems, that's the approach I prefer. I don't want to unnecessarily restrict users to a particular platform.

Of course, that's not always easy. Different APIs, drivers, hardware acceleration implementations and OS-specific quirks can make cross-platform development significantly more complicated. That's why I try to consider cross-platform compatibility from the very beginning, including when making architectural decisions.

To me, platform independence isn't just another checkbox on a feature list. It's a deliberate engineering decision. DaVinci Resolve demonstrates that professional video editing software can work on Linux. It's not perfect, and certain features and codecs remain limited, but it works. Meanwhile, Adobe still doesn't offer native Linux versions of Premiere Pro or Photoshop.

Of course, you could argue that the Linux market is too small to justify the development and maintenance costs. From a business perspective, that might be perfectly reasonable.

But then you shouldn't be surprised when other developers see that gap as an opportunity. And if those alternatives eventually become good enough, they might even attract users who never intended to switch to Linux in the first place.

Sometimes competition doesn't emerge because someone invents something revolutionary. Sometimes it emerges because an established company has spent decades choosing not to offer something.

And this isn't just about Adobe: Blackmagic Design, for example, supports Linux with DaVinci Resolve but still doesn't provide native Linux versions of its control software for ATEM switchers and Videohub routers.

Perhaps we'll eventually see a change in thinking there as well.

What do you think? Is the Linux desktop market genuinely too small to justify professional software support, or are companies underestimating the opportunity they're leaving behind?

it is actually easy to use and you can use it anywhere because I wrote it with python so what it does: it just generates .desktop files yeah thats it. its easy actually it just asks and you type what you want

git repo: https://github.com/sbusiedcake7945/desktop-file-generator

it is licensed under MIT license btw

Honestly, is mobile Linux (pmOS / Droidian) dead on arrival now that Samsung killed bootloader unlocking on One UI 8 and Google is locking down Android harder, or could an EU Citizen Initiative (like Stop Killing Games) actually force OEMs to support standard UEFI/mainline boot?

Hi

As a average Linux User who worked for a long Time on a Samsung N510 Netbook with Intel Atom CPU and 2 GByte RAM i have to ask:

What is the Point of Distros that are made specifically for Low CPU/Ram Usage?

I get the Point to a certain Degree but my Question is this:

Most of us People use the Internet/Browsers every Day. What makes a PC/Notebook/Netbook with a slow CPU and RAM from 2 to 4 GBYte slow is not the System itself, its the Browser/ the Way the Internet is programmed today.

If Websites still would be built like in the early Days of the Internet then we could still use Devices with RAM under 4GByte. But the Internet today is built for Devices with over 4GByte RAM and fast CPUs.

As a Guy who is always fascinated by Retro Style Desktop Environments i run XFCE myself.

I wish there would be 2 Types of Internet today. The Normal Internet, for fast, modern Devices with RAM from 8 to 16GBytes and the "Slow Internet" for Devices that have maybe 2 to 4GByte RAM and extremly slow CPUs.

I know that some Sites can be accessed today in a Kind of low Quality Mode but imo there should be a mandatory Standard for all Websites for a low Quality Mode for older Devices.

Maybe my Thread comes off as unorganized but i hope you People can understand what i am trying to say.

Low Power Distros are only really useable if the Internet is forced to have 2 Quality Modes. One for Normal, modern Devices and one for old Devices. What good is it to run a Low Power Linux when the whole System hangs once you have the Browser open and try to display a modern Website. Everything will become painfully slow then.

Hey everyone,

I wanted to share a project I've been working on that's been a personal itch I've wanted to scratch for decades.

I’ve been using Linux since the original Red Hat Linux days—initially as a secondary OS, and for several years now, as my daily driver (primarily running Zorin OS 18.1 and the latest Fedora). Professionally, I’ve spent 29 years in software engineering, including 18 years at Microsoft.

Throughout my career, I always admired the convenience of utilities like Microsoft PowerToys on Windows, but I wanted something native, fast, and modular for the Linux desktop. So, I finally decided to build it: Voltkit.

What is Voltkit?

Voltkit is a PowerToys-style utility suite designed to bring a collection of handy productivity tools, system helpers, and quick-access features into one cohesive package on Linux.

• Language: Built in Rust, chosen for its performance, safety guarantees, and zero-cost abstractions.
• Interfaces: Features both CLI and App/UX layers.
• Distribution: Available as a free, open-source project (APT package format / GitHub).

Voltkit 0.2.2 includes eight tools:

Each tool also works from the terminal, for example voltkit ocr, voltkit qr make, voltkit ruler or voltkit awake 1h. man voltkit has the full list of commands.

The Development Process & AI

After decades of manually writing code, I tackled this project by pulling together various scripts and ideas I've collected over the years, using modern AI tooling (specifically Claude Code) to help re-write and merge them into a unified application.

That said, I want to be very clear about how I approached it: we cannot blindly trust AI. It introduces plenty of regressions, out-of-context changes, and logic gaps. I treated AI as a helpful assistant, but I manually tested every single feature—both through the command line and the App/UX—and personally ensured that all documentation and man pages are accurate and up to date. You have to understand the code to guide it properly.

Check it Out

The project is completely open-source and free, and I wanted to share it with this community to see what you think, get feedback, or hear suggestions from fellow Linux power users.

You can find the repository and installation details here: 👉 https://github.com/arios4k/voltkit

(Note: I’ve made sure to adhere strictly to open-source licensing and community guidelines—no commercial strings attached, just a developer scratching an itch and giving back to the ecosystem.)

I'd love to hear your thoughts, bug reports, or feature ideas if you give it a spin. Thank you!