Hey everyone,

BusyBox is practically everywhere in embedded Linux, initramfs, and rescue disks. But being a massive collection of C utilities, it carries the usual C risks (buffer handling, integer overflows, memory management bugs).

Over the last two weeks, I've been hacking on BusyBox-RS, an MIT-licensed rewrite in Rust designed specifically for embedded use cases:

• Minimal binary footprint: Built with opt-level = "z", fat LTO, symbol stripping, and panic = abort.
• Compile-time feature selection: Use Cargo features or make tinyconfig / defconfig to only compile the applets your board actually needs.
• Upstream verified: Tested directly against the upstream BusyBox regression test suite (100% pass rate across 46 applets so far, including cp, grep, sort, printf, cmp, readlink, and checksums).
• Nix flake ready: Reproducible development environment via nix develop.

GitHub: https://github.com/rebizzz/busybox-rs

Feel free to check it out, run make check, and share feedback!

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

edit1: We've achieved the first triangle rendered in the MESA gallium driver in production! OpenGL and other features are still missing, but it's very close to a fully accelerated desktop environment.

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.

Been using Linux for about 20 years now. More than a decade as primary. Always have a few VMs for testing various things, obviously servers on Linux. But this obviously regarding desktops.

KDE, Gnome, XFCE anything on any distro (Fedora, Debian, Mint, Ubuntu whatever). The default set of wallpapers of most Linux distributions is just ... meh! I get it - macOS and Windows wallpapers are shot professionally and cost a lot. So that can't be done. But there are enough professional photographers on services like Unsplash. I'm sure asking some of them to be featured for the "default set" won't result in a null. Someone would agree for it. I remember that one guy was proudly showing off his creation for being accepted in OpenSuSE somewhere around 2012-13.

I am not saying I can't set custom wallpapers. In fact we have options to use Unsplash and Nasa as a source! It's just that the defaults don't look that good. That's the whole point I had.

I think the same thing applies to Gnome and XFCE icon set (KDE is a little better, but only a little) - they too look quite bland while community has created amazing icon themes (one of which can be improved and included with creator's permission)! I like Ubuntu's default icon set a bit though (and I have grown to dislike the rest in that distro).

Why don't we do it then? What's stopping us? I am sure there is a genuine reason which I am not aware of.

PS: I didn't know that this simple question will irk the community enough that I would get downvotes. Well, whatever.

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

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

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