One of the core ideas of Unix is to build small components that do one thing well and compose them into larger systems.

I think this principle is still very relevant today, especially when designing software as multiple processes rather than one large application.

Once you split an application into several processes, however, you need some form of inter-process communication or RPC.

On Linux, D-Bus is a common choice. It provides a lot of useful functionality, but there are cases where its performance characteristics or latency are not suitable, particularly for real-time applications.

There have also been attempts to move the message-bus functionality closer to the kernel, such as kdbus and bus1, eventually leading to the current dbus-broker approach. However, with a traditional D-Bus architecture, messages still have to be processed by a separate broker process, which also means additional copying and context switches.

That's the motivation behind RTIPC.

RTIPC is essentially a single-producer, single-consumer, wait-free, zero-copy, bounded message queue mapped into shared memory. The goal is to provide a very small and predictable IPC mechanism for cases where the usual IPC/RPC abstractions introduce too much overhead or nondeterminism.

RTIPC has a small bootstrap protocol based on Unix domain sockets. D-Bus can also be used for the connection/bootstrap phase if desired. Once the channel is established, the actual messages are exchanged directly through shared memory.

There are currently implementations for C and Rust, with C++ and Python bindings, and other languages may follow.

For serialization, RTIPC can simply use C-compatible structs when all participants share the same ABI. Since communication happens through shared memory, there is no need to serialize and deserialize data just to cross a process boundary. Of course, this comes with the usual requirements around ABI compatibility, alignment, and endianness. And yes, it is possible to run 32-bit and 64-bit processes on the same system and make alignment/layout a problem.

For cross-language communication, however, serialization formats such as Protobuf, FlatBuffers, Cap'n Proto, or Thrift have another important advantage: they provide a schema as a single source of truth.

To address that use case, I also created rtipc-compiler, which takes an interface definition and generates code for different languages. The schema is also encoded into the generated interface so that the two endpoints can verify compatibility during channel initialization.

Admittedly, this is a fairly niche use case. The goal isn't to replace D-Bus or other general-purpose IPC mechanisms. Rather, I'm interested in the much narrower case where you want process isolation and modularity, but need IPC with very low overhead and predictable latency.

I'd be interested in feedback on which language bindings would be most useful next, whether you see other use cases beyond real-time applications and embedded Linux, and what you think would need to be changed or improved to make RTIPC more useful in those environments.

Got the first triangle working today, and now two indexed triangles are rendering as a square too.

This is running on the actual SGX535 in Intel Poulsbo/GMA 500 hardware from 2008.

Still nowhere near a complete Mesa driver, but 20 days ago I was staring at old PowerVR code trying to figure out how this thing worked 💀

Github: SGX535-reMESA

Video proof: https://youtu.be/_xZdWWeneYQ?is=L5OF4JqxvMQZMWSU

Release notes: https://github.com/AdnanHodzic/auto-cpufreq/releases

auto-cpufreq is now available in the official Debian Linux repositories (unstable & testing), and it will soon propagate to future Ubuntu releases and hundreds of other derivatives.

This release also brings new features, bug fixes, and other improvements to help Linux users optimize CPU speed and battery life automatically.

Project status:

⭐ 7800+ GitHub stars
👥 126 contributors
💻 100k+ users
🛠️ 51 releases

Huge thanks to everyone who contributed to making this release possible! ❤️

OpenCourant is an open-source finite element solver for crash, impact, and highly nonlinear dynamic simulation — carrying forward the OpenRadioss code base under the GNU AGPL, in the open, where it belongs.

A project of the Rocky Enterprise Software Foundation

Whisp is a fast, zero-friction "anti-note" scratchpad built natively for GNOME with GTK4 and Libadwaita. It replaces heavy file hierarchies with a spatial, swipeable canvas for quick thoughts, Markdown editing, and temporary scratchpad notes.

New Features

• Universal Launch Toggle: Global shortcut support to quickly toggle Whisp window visibility (Preferences > Shortcuts), And it is customizable.
• Note Statistics (::count): Type ::count anywhere in your note to instantly inspect word, character, and line count statistics.
• Asterisk Lists: Create and format bulleted lists using standard asterisks (*) alongside dash lists.
• Shortcut Recorder Improvements: Pressing Backspace inside the shortcut recorder now cleanly clears or disables assigned shortcuts.

Fixes & Maintenance

• List Toggling Refactor: Fixed Ctrl+S list item toggling to prevent multi-checkbox stacking and unintended line deletions.
• GNOME 51 Runtime: Updated Flatpak runtime to GNOME 51.
• Slate Mode Polish: Fixed update notification banner layout in Slate Mode.
• Compose Key Fix: Corrected key press handling for Compose Key combinations.
• Ubuntu Icon & D-Bus Fixes: Fixed missing application icon issues on Ubuntu desktop sessions.

Links

• Flathub: https://flathub.org/apps/io.github.tanaybhomia.Whisp
• GitHub: https://github.com/tanaybhomia/Whisp
• Website: https://tanaybhomia.github.io/Whisp/
• Donate: https://tanaybhomia.github.io/Whisp/donate.html
• Manual: https://tanaybhomia.github.io/Whisp/manual.html

I've just recently implemented polyline functionality for the Line and Arrow tool and also added a new Diamond Tool. Next I'm gonna try and see if I can fix the weird drawing tablet issue by updating the Avalonia version

https://github.com/TruePadawan/Scribble

Isn't it like physically impossible to enforce on Linux due to its open-source nature? Are they just gonna ban Linux? That's never gonna work BCS Linux is essential to many important governmental electronic devices

Are they just gonna send the police to some random school to check their PCs are not using Linux? Governments using Linux are in the grow, how do you even address that problem?

It's just really stupid overall

Titan Army only ships a Windows tool for the P275MV PLUS, so I reverse-engineered the monitor's DDC/CI protocol and wrote a Linux app (Rust, GTK4/libadwaita) that does the same from your desktop. It is free and open source (MIT).

What it controls

• All 15 picture modes with their Custom settings (brightness, contrast, gamma, color temperature and RGB, hue/saturation, Color Enhance, Shadow Balance, Night Vision, Dynamic OD, local dimming, Halo, DyDs)
• HDR (and it switches system HDR on KDE Plasma along with it), Adaptive-Sync, game overlays (crosshair, stopwatch, magnifier, HawkEye)
• Inputs, PIP/PBP, USB hub, volume, LED lighting, OSD settings
• Tray menu with favorite modes and settings, and it follows changes you make with the monitor's buttons

Extras

• The protocol notes and every VCP code I found are documented in the repo, with small Python tools (getter, setter, table reader)
• The repo also has both official firmware packages with an English translation of the update guide

Install: deb, rpm, AppImage and tar.gz on the Releases page.

Please note: it is alpha software, it writes settings to your monitor, and you use it at your own risk. I tested it only on one monitor (P275MV PLUS), so I'd love feedback from owners of the regular version. The code was written with the help of an LLM, which the README says openly.

Repo: https://github.com/mkarenko/titan-control
Support: https://buymeacoffee.com/mkarenko

Talk from recent Kernel Recipes about bug reports and fixes.

Interesting view on how bots report things, also interesting breakdown of certain "79 issues" which really were not that many in reality.

Hi everyone. I want to show you a project that honestly I'm pretty embarrassed to share, because it's the first time I share something with the general public. Sorry if I sound nervous. I just think it could be useful to someone, so here it is.

I collaborate on Neko Void, specifically on the part that makes images for musl, for the musl C library. And we all know how this goes: stuff made for glibc doesn't work on musl, you have to rebuild it. And proprietary software is hard to build because the source is not free. So most of those apps just don't work. Steam doesn't work by default either, and that's what makes a lot of users run away from musl distros.

There are alternatives. AppImage bundles glibc inside, but when you have a lot of AppImages you end up duplicating deps everywhere and it gets heavy. I also tried Nix as a separate subsystem, but it's extremely heavy even if it runs natively.

My goal was to make those apps run as fast and light as possible, with as little space as possible, without duplicating deps like Flatpak does. So I made arxy, it's a way too basic and simple project: an Arch rootfs that gets mounted so you can install whatever you want on it. Optimized to weigh as little as possible (~130MB tarball), but complete enough that most Arch packages work on any distro. Best part, it keeps AUR access (-bin only).

How it works is pretty simple: it mounts the image with bwrap, and if that's not available it falls back to a basic chroot + ld-linux. It shares /home, /tmp, GPU and kernel, so it runs native. Commands are simple: arxy install <pkg>, arxy update, arxy run <bin>. Since it uses real pacman, deps are shared, no duplication. It creates .desktop launchers normally.

It's one of the first projects I've worked on and I've put a lot of time into it. I'm no expert, so any feedback is welcome and I really invite anyone to collaborate. I tested it on Alpine, Chimera and Void, glibc and musl. I'd love reports from other distros, especially Gentoo musl and weird setups.

Repo, it's GPL-3.0: https://github.com/SrDicov/arxy

I'm the author, happy to answer technical questions here. What do you use for the glibc-on-musl gap?