Source: https://github.com/gregkh/kernel-development/blob/master/graphs%2Fpatches_per_release%2Fcves_fixed_per_release.png

This seems to be the impact of AI tools. In my experience AI is very good at finding bugs(not particularly great at good fixes though)

The original operating system was VirtuOS, similar to MS-DOS and includes multitasking support, was developed by Microbase. It was used in the 1996, 1998 and 2000 elections. In 2002, Unisys was unable to renew their partnership with Microbase, and were unable to reuse the VirtuOS based code. Microsoft stepped in, and provided licenses for the Windows CE operating system free of charge. In 2008, under initiative from the TSE Electronic voting team migrated to a Linux (dubbed UEnux) OS to reduce costs and take full control of development cycle.
- From Wikipedia

Thought this was a fun thing to share given yesterday's elections and how fast the votes were tallied.

None of the substantive code was written by AI.

I used AI to help with the mechanical parts of porting (e.g. translating autotools to CMake, replacing ioctl calls with tcgetwinsize, translating the C structs into Rust), as well as to write some of the smoke tests (e.g. cairo-test, mesa-test).

Where Claude really shines though is in reviewing your own commits. You give it a hash, and it tells you about the silly memory leak or deadlock that you left in, before you can make a fool of yourself.

Faith Ekstrand's write-up on Kraid, the new shader compiler for the open source Panfrost/PanVK drivers:

https://www.collabora.com/news-and-blog/news-and-events/panfrost-is-now-using-kraid.html

Starting with Mesa 27.0, all Mali GPUs with Valhall (v9) or newer will use it by default. Mesa 26.3 is the last release with the old compiler.

Highlights compared with the old compiler:

- ~18-20% fewer shader instructions across OpenGL and Vulkan shader sets

- Over 80% less register spilling

- Proper 64-bit integer support

- Much faster shader compilation with lower memory use

It went from start to default in under six months!

Saw this post on Bluesky and having had casually followed the trashing of X for about 20 years, the whole Canonical/Mir fiasco, and finally the extremely slow adoption of Wayland, this was cool to see! 😁

👀💃

For a while my PC froze about twice a day. Not a crash I could recover from: the screen stopped, audio sometimes kept going, and even Ctrl+Alt+F3 did nothing. Only the reset button helped.

Setup: CachyOS, kernel 7.3.0, niri (Wayland), RTX 4060, nvidia-open 615.78.08, Huananzhi X99-BD4 motherboard.

After a reboot, journalctl -b -1 -k showed the same pattern every time:

NVRM: dmaAllocMapping_GM107: can't alloc VA space for mapping.
NVRM: nvAssertOkFailedNoLog: Assertion failed: Out of memory [NV_ERR_NO_MEMORY]
NVRM: Xid (PCI:0000:03:00): 56, ...
NVRM: krcWatchdog_IMPL: RC watchdog: GPU is probably locked!

The process that hit it first changed. Once it was a Godot game I'm developing, twice it was Brave (its Media process died with SIGILL right before the lockup). So it wasn't one bad app.

nvidia-smi -q | grep -A3 BAR1 showed the problem: BAR1 was only 256 MiB. Without Resizable BAR, the driver maps GPU memory for the CPU through that small window, and when it fills up, the open driver can lock the whole GPU instead of just failing that one request. There's an open upstream issue with the exact same logs from people on Fedora, Bazzite, Arch and CachyOS, mostly with Chromium-based browsers or Discord as the trigger:

https://github.com/NVIDIA/open-gpu-kernel-modules/issues/1396

My BIOS had "Above 4G Decoding" but no Resizable BAR option. It turns out Huananzhi publishes an official BIOS for the X99-BD4 with ReBAR added, on the board's download page. I flashed it, enabled Above 4G Decoding and Re-Size BAR, and now:

BAR1 Memory Usage
    Total : 8192 MiB

No VA errors in the kernel log since, no freezes, and the whole system feels smoother, including games.

If you have an NVIDIA card on an older board and see "can't alloc VA space" before a freeze, check your BAR1 size. A lot of X99 and other older boards have official or community BIOS updates that add ReBAR. Flash carefully and only the file for your exact board model. If you can't enable it, people in that issue report that turning off hardware acceleration in Chromium-based browsers makes it happen much less often.

Hi everyone,

I recently encountered sping, a fairly new open-source network diagnostic tool from the LambdaBytes organisation, and I believe it merits attention from anyone overseeing Linux systems, containers, or clusters.

It has been reviewed and accepted into the official Debian repositories, indicating it has cleared strict stability checks. After reviewing its design, it is evident this is not merely another “pretty ping clone”—it addresses genuine, long-standing limits in standard network probing.

Here is a summary of why this utility is an engineering success and why you might try it:

1. It removes the need for SUDO
The conventional ping tool from iputils requires the system to open a raw socket for ICMP Echo Requests. Since raw sockets permit packet manipulation, the binary typically needs root access, which is why most distributions ship it with the SUID bit set. This presents a familiar security concern in hardened setups.

sping avoids this completely. It is built to use unprivileged DGRAM ICMP sockets (net.ipv4.pinggrouprange), a modern Linux kernel feature. It communicates safely with the kernel from user space, so you can run advanced checks inside restricted Docker containers or locked environments without invoking sudo or risking privilege escalation.

2. High-Performance Parallelism with Async Tokio
When monitoring multiple hosts with standard ping, you often create several heavy OS processes or complex Bash wrappers that consume resources quickly.

sping relies on Rust’s async framework (driven by the Tokio runtime). Rather than increasing system threads, it handles hundreds of concurrent targets within one process using lightweight virtual tasks. Even while stressing many endpoints at once, its memory use remains at a steady ~4 MB of RAM with almost no CPU load.

3. Automated Correlated Diagnostics
Standard ping only indicates whether a host is active or inactive. If a packet fails, the cause remains unclear. sping behaves like an intelligent monitor: it runs quiet auxiliary probes in the background against your local gateway and external WAN references (such as Cloudflare or Google DNS).

When a target fails, its engine matches the data immediately in the TUI or logs:
“Target unreachable · Internet still OK” (server-side issue)
“Gateway unreachable · local network issue likely” (your router or switch may be down)

Key Features worth testing:
Multi-Target Dashboard: Automatically divides your terminal into dynamic grids for real-time infrastructure monitoring.
TCP Handshake Fallback: Use --tcp <port> to avoid aggressive corporate firewalls that block ICMP traffic.
Automation-Friendly: Provides a strong --view json flag that streams stable NDJSON lines suitable for jq, Python scripts, or logging stacks.
Advanced Metrics: Computes real-time jitter, packet loss trends, and network hop counts directly.

It is cross-platform, lightweight, and production-ready.

You can review the source code, implementation details, and installation guide here:
👉 https://github.com

If you work with networks or manage servers, try it out. I would enjoy hearing your thoughts on using unprivileged ICMP sockets instead of the traditional raw socket approach!

Hi, I recently switched from Windows to Linux as my daily drive. I picked Fedora since it supports secure boot, and I can still boot into my Windows and play League of Legends (the only thing keeping me there). Other than that, it's been a smooth ride. This is not my first attempt but this time I did something different that I hadn't done those other times, I thought lets use my claude subscription to handle things for me and so I did and it's been insane how fast it fixes all the potential problems and installs my drivers and finds the settings I want quickly for me, although it might sound bad I've asked it to track every decision and command it runs in my machine in a private repo that I ask it to keep updated everytime so I have some kind of changelog of my machine but over all very smooth experience. I thought, "Well, why not let it install my game, Red Dead, and optimize it for me?" That's when I found out more about FSR and game scope; it searched for the recommended settings for my machine and gathered information from different community pages, and the result has been insane for me. I have a flashed RX 5700 -> RX 5700 XT. I could play Red Dead Redemption on it with decent quality at 1440p (sure it's upscaled) and hit 190! FPS at times, it's phenomenal. I've never seen my card hit these numbers, and to be honest, I'm happy with the quality of the game even though it's upscaled and I have fake frames. It's such a smooth experience, and my card has gotten a totally new life. I tried several other games and had the same experience everywhere. I thought I would make a video and record my gameplay and put it on YouTube so people can watch it and use the settings as well. If you have any questions, hit me up.

https://www.youtube.com/watch?v=ivDFitbCoSY

This is the reasoning on how this was possible (AI response):

RDR2 does not support FSR 3.1. Out of the box it only has FSR 2 (added in a 2022 patch) and DLSS 2, and no frame generation at all. The secret sauce is a mod that fakes it.

1. OptiScaler: the main trick

- It's a small DLL dropped into the game folder (winmm.dll, with the Wine override winmm=n,b).

- When the game calls its built-in FSR 2, OptiScaler intercepts that and runs FSR 3.1.4 instead, which is a better upscaler.

- It then adds FSR 3.1 frame generation on top: it hooks the game's frame output and inserts a generated frame between every two real ones. That roughly doubles the number on the counter.

- Frame generation only works in DirectX 12 mode, not Vulkan, so the game runs in DX12.

1. Upscaling from a low internal resolution

- FSR 2 is set to Performance in the game, so it renders at only 1280x720, and FSR 3.1 rebuilds that to 2560x1440. That's the biggest real-fps gain.

1. Smart settings

- Ultra textures, which cost almost nothing on an 8 GB card.

- Shadows and lighting on Medium, the most expensive settings.

- Volumetrics and GI on High, motion blur off, VSync off.

1. The Linux side

- GE-Proton 11-11 with vkd3d-proton turns DX12 into Vulkan.

- RADV_QUEUE_DISABLE=compute avoids the RX 5700's GPU-hang bug.

- vulkan-1=b fixes OptiScaler crashing on Rockstar's old bundled Vulkan file.

- gamescope runs at native 1440p with no extra scaling.

- GameMode keeps the CPU at full speed.

Hey everyone,

I'm developing Linux Subsystem on Android (LSA), an experimental project that runs a native Linux userspace on rooted Android devices while keeping Android as the host operating system.

The goal isn't just to run a Linux desktop. I'm trying to make Android's hardware and services usable through normal Linux interfaces, without requiring applications to be rewritten for Android.

LSA uses the Android kernel directly. It's not PRoot, emulation, or a VM.

What's currently working in development testing on a Blackview N6000:

Debian ARM64 with a graphical desktop and native Linux applications

Hardware-accelerated OpenGL through Mesa/VirGL and Android's GPU stack

Audio playback and microphone capture

USB storage integration, including automatic NTFS mounting

Applications including Firefox, OpenArena, and SuperTuxKart

This is still pre-alpha. Some applications require workarounds, graphics compatibility is incomplete, and hardware support varies. Some of the results above are from a private development preview and may not be present in the current public release.

I'm looking for people who have spare rooted Android phones and are willing to help test LSA on different hardware.

Useful experience includes Android rooting, ADB, Linux debugging, shell scripting, Mesa/VirGL, graphics drivers, audio, and embedded Linux. You don't need to be an expert.

There are two ways to help:

Independent testing: Try LSA on a spare device, collect logs, report bugs, and share hardware compatibility results. No remote access required.

Direct development collaboration: For volunteers who want more involved help, I'm open to supervised SSH debugging on a dedicated test device. Any access would be optional, explicitly authorized, and governed by a written agreement restricting my activity to the agreed testing and development work.

Please don't run this on your primary phone or anything you can't recover. This is experimental rooted system software, and things can break.

GitHub: https://github.com/Phsphorus/LinuxSubsystemOnAndroid

If you're interested, let me know your phone model, chipset, Android version, and rooting method.

I'm also looking for feedback from people familiar with Linux systems programming or Android internals.

Thanks!

Disclaimer:

This project has been developed with the assistance of AI. I'm not an expert in every field this project covers, and I don't claim to be. LSA is an experimental learning project, and I welcome technical feedback, corrections, and contributions.

A dream can only be achieved if you try.

---

Example of the experimental UI.

Title.

I'm kinda on the edge to start using Firefox as a flatpak, cause I can get codecs and hardware acceleration for my GPU. I know about the weakened sandbox of the flatpak Firefox, but on the other hand Mozilla is actively developing it and it is a standard for example on RHEL nowdays.

Am I thinking this too far? Is the weakened sandbox really a big deal?

Main Features:

• Video Wallpapers per Workspace
• Mouse Gestures
• Float / Auto Tiing / Scrollable Tiling per Workspace
• Radial Menu

Here is the repo -> https://github.com/PreCosmos/Vaela

I wanted to share a project that's been making some interesting progress in PC-based home theatre.

CroqueMr (u/Croque_Mr) is developing native Dolby Vision support for Kodi through a custom LibreELEC build, including Profile 7 FEL reconstruction. Development has moved quickly, with regular releases bringing performance improvements, new rendering modes and broader hardware support.

What's currently available?

• Native Dolby Vision playback, including Profile 7 FEL reconstruction.
• Intel and AMD support, with NVIDIA support also being developed.
• Dolby Vision rendering modes, including Master Reference and Adaptive HDR Mapping.
• Dolby Vision-to-HDR10 conversion and experimental AI-assisted HDR10-to-Dolby Vision conversion.
• Blu-ray 3D support on compatible AMD hardware.
• Performance optimisations targeting lower-power mini PCs, including Intel N100/N150 systems.

The latest Beta 5 release includes further improvements to playback stability, FEL handling, scaling and display detection. Results and compatibility can vary depending on the hardware, TV, source material and rendering mode.

What's coming next?

The developer has outlined plans for a GPLv2-or-later licensing rebuild, further AMD improvements, HDR10+ support and Dolby Vision-to-HDR10+ metadata reinterpretation, alongside expanded compatibility with older Intel graphics and additional NVIDIA hardware.

The longer-term goal is to make PC-based Dolby Vision playback more capable and accessible, including on affordable mini PCs.

Project links

• Main development thread: https://forum.libreelec.tv/thread/30362-dolby-vision-w-fel-3d-for-pc-amd-intel-nvidia/
• GitHub — source code and releases: https://github.com/CroqueMr/libreelec-x86-DV/
• Original Reddit thread: https://www.reddit.com/r/libreeLEC/comments/1wq20eu/wip_native_dolby_vision_support_on_x86_intel_cpu/

Full credit to u/Croque_Mr for the development, along with the community members contributing testing, feedback and improvements.

It's been impressive to see how much the project has evolved in such a short time. If you're interested in the technical details, supported hardware or latest builds, the links above have all the information.

Flatpak needs bubblewrap, bubblewrap needs user namespaces, and Android kernels ship without them. So flatpak run can't work on a phone, root or not.

In Tessera (GPL-3.0, an Android app that runs Linux desktop apps as native Android windows), flatpak still downloads, but Tessera builds each app's root itself:

- the runtime at /usr and the app at /app, read-only;

- the runtime's GL extension where the runtime expects it, on a tmpfs over its parent since the folder doesn't exist in the read-only runtime;

- /etc from the runtime, with passwd, group, hosts and resolv.conf written for the session;

- the session's X11 directory shared, carrying its D-Bus and PulseAudio sockets, so the app gets the same bus, sound and theme portal as the Debian side.

Without root that's PRoot's path translation. With root, each launch gets a private mount namespace, an unprivileged uid and no_new_privs, so per-app permissions are kernel-enforced.

The rest is about making Linux apps feel native on a phone: each app (and each of its windows) gets its own Android task and Recents card; GTK, libadwaita and Qt take Material You colors and follow dark mode live through a settings portal Tessera serves; apps rescale live from a slider; and the Android keyboard opens on text fields by listening to AT-SPI focus events. GPU acceleration is a bundled Mesa with Turnip and Zink for Adreno, which also loads inside Flathub runtimes.

Source: https://github.com/daryan044/tessera-linux

Note: AI WAS USED IN THE PROCCESS OF CREATING THIS APP

Happy to go deeper on any part.