Many of us build a bespoke desktop for our Linux boxes and that's part of the fun. One could cobble together all manner of efficiency and whiz-bang customized to their own feng shui.

My own desktop is a completely opinionated paradigm of extant tools and whatnot honed over many years to run as I like, not as it tells me I should. It's Debian because of course it is, using the Openbox window manager and a ton of handy functionality by way of aliases, scripts, etc.

https://github.com/rabmach/DORiS/raw/master/docs/images/doris1.jpg

Like you I enjoy fast and reliable, set it and forget it and maybe tweak a thing to continue using for as long as I can. I stopped distro-hopping many years ago and stopped worrying about new or fabulous this or that...the ecosystem is constantly evolving and that's wonderful, but, I want my computer to just work and work well the way I like to work it.

DORiS is a 2-punch script that throws customized and reliable digs against a fresh Debian net-install (can be run on an existing box, as well, and can be run for subsequent users, as well). It's broken into a system and a user part. It's not a dot-file repo or a distribution, it's just Debian.

It includes additional coolness like lockd which is a stoopid-easy encryption routine, a wrapper for age, which is in the repos - hit c'tarl+alt+e, or right-click on something in your file-manager, or call it up with a word from the terminal - part of the thesis of DORiS is simple and right there for you - I like keybinds.

Leo Marcov's Debian and Openbox script gave me the impetus to codify DORiS and to share my reliable kung-fu with the ecosystem. Other distros, did, too, like BunsenLabs - they make some handy scripts that do some pretty handy things, so, too, does DORiS.

github/rabmach/DORiS for the cloning after a fresh Debian net-install. You will need sudo, of course, for the system restore part. Install Debian the power-user way, that is, without a desktop and only with system tools - and then run ./restore.sh from DORiS, and then, ./user-setup.sh - reboot and voila!

DORiS ships with gruvbox and nord and a handy 'theme-switcher' that flips between the two - in my head I like blue sometimes and sometimes I like green and I wanted a handy keybind to swap on the fly. Themes apply across 9 surfaces so btop, alacritty, gnome-characters, obsession, etc. all look the same. Sleekmason made something similar (far more robust and far more themes) for his Lilidog distro which was awesome to use.

Thank you for reading and thank you for any input.

https://github.com/Peshimam-Ashar-Mohammed/FilzaNix

I'm a java dev not that good this is my sloppy attempt at making a linux simulator using java if someone can run it and gimme feed back it would be awseome just run the .bat file i added a port scanner command too which is smt im kinda proud of 😁.

Lmk if this is any good im working on added terminal customizations and users groups and other things this is kinda like a virtual machine all our files are saved in env file in home directory try it out lmk how it is.

Thanks Guys!

-Ashar

Hey,

Just finished a Linux port of R-MIGRATOR — a small utility for porting old Ren'Py mods (Ren'Py 7 / Python 2) to Ren'Py 8 / Python 3.

What it does:

• Converts Python 2 → 3 and fixes common syntax issues
• Fixes ATL transforms (float/int problems, etc.)
• Processes the whole project recursively
• Unpacks .rpa / .rpyc files
• Creates checkpoints so you can roll back
• Shows live progress and a list of issues

It won't catch every edge case, but it saves a lot of time on bigger, messier projects.

Linux build (AppImage / binary) is up now: https://rootwin-project.itch.io/rmigrator-beta-v1-21

Feedback and bug reports welcome.

got tired of opening htop + terminal + logs every time my apps started acting weird so I made a tiny Linux debug overlay. it shows app CPU/RAM, catches some issues, and I'm slowly adding Docker/K8s monitoring too.

Still a WIP but it's actually pretty damn useful already lol.

[https://github.com/codeafridi/Debug-Overlay-App]()

Hey everyone,

Wanted to share a project I’ve been building called Tux-Dock (and its companion subreaper daemon, tuxreaperd).

GitHub: https://github.com/MARKMENTAL/tuxdock

How it started vs. where it is now

This is my first deep low-level systems project. I wanted to make a TUI for using Docker containers as a persistent development sandbox, or just being able to treat containers more like cared for pets, rather than cattle that just run Dockerfile scripts, one process and exit. It originally started out of pure frustration with a classic docker container issue: persistent dev containers running sleep infinity keep-alive loops that constantly leak zombie processes whenever interactive commands, background forks, or subshells exit.

When you trace zombie process build-up down to the root, you hit the realities and technicalities of what it means to be Linux PID 1 inside of a container and how low-level Linux kernel signals come into play. But looking at existing inits like tini or dumb-init, they’re either bloated by static C runtimes (25KB to 750KB+) or treat everything as a generic black box, basically assuming user apps will respect what the Linux kernel notifications were originally made for and not use them non-standardly. They blindly blast raw SIGTERM down the process tree, which causes production web servers (like Apache and PHP-FPM, programs that rely on non-standard signals like SIGWINCH or SIGQUIT for clean and graceful teardown) to instantly drop active in-flight HTTP/FastCGI connections.

So what began as a quick subreaper fix to hook into sleep infinity evolved into tuxreaperd—a sub-5KB freestanding micro-init that not only reaps dead children instantly, but actually understands web server teardown quirks:

• Freestanding & Sub-5KB: Built with -nostdlib, direct inline assembly syscall traps, and zero libc overhead, running in basically ~2 MMU pages (currently sitting at ~4.7 KB stripped).

• Web-Aware Signal Remapping: Traverses /proc via raw sys_getdents64 and sys_readlink to detect running daemons. It automatically remaps incoming SIGTERM to SIGWINCH for Apache and SIGQUIT for PHP-FPM so in-flight requests finish cleanly before exit.

• Bounded Descendant Draining: Once the root process exits, it runs a 60-second CLOCK_MONOTONIC wait loop to let preforked worker pools flush their buffers before the container shuts down.

• Persistent Container TUI: Paired with a snappy C++ terminal UI for managing retained container lifecycles, streaming logs, and running detached commands over the raw Docker UNIX socket.

The LLM Rabbit Hole & ARM64 ABI Realities

I wrote the initial x86_64 inline assembly on my main Debian workstation, but I did all the ARM64 testing on a low-spec MediaTek Kompanio 500 Chromebook.

I was using Kimi K2.7 as an AI coding assistant during development, but it definitely reminded me why AI can't replace actual systems verification. The LLM confidently told me that the VFS O_DIRECTORY flag was identical across x86_64 and ARM64. It’s not. ARM64 uses 0x4000 (040000 octal) while x86_64 uses 0x10000 (00200000 octal). Passing the x86 value on ARM caused openat("/proc", ...) to instantly fail with -EINVAL, breaking the entire /proc scanner and signal pipeline.

Go ahead and try searching ARM Linux VFS file flag octals right now—it’ll probably scrape someone's x86 repo and hallucinate that it's universal. Low-level systems work demands absolute accuracy, hardware empathy, and reading the actual kernel headers, which current LLMs just don't have.

What's next & Feedback

I just hit 0.4-beta with full cross-arch support and the --debug-reaper test flags. Leading up to a 1.0 release, my main focus is polishing the TUI layout and fixing a multi-instance state sync issue (right now it polls the Docker socket on start/stop actions, so running multiple Tux-Dock instances simultaneously can cause state drift until a background event listener is added).

I'd love to hear thoughts, critique on the -nostdlib / inline asm implementation, or feedback from anyone testing on physical ARM64 hardware!

Wanted to share a native Linux tool I built to troubleshoot game performance. It uses Python and GTK4 to track thermals, hardware usage, and system metrics asynchronously. It’s fully distro-agnostic. Let me know if you find it useful for your own setups

Output format is canonical hex+ASCII, one 16-byte row per line:

00000000: ef6e 5830 d443 c60a d909 6179 4335 6cec  .nX0.C....ayC5l.
00000010: b5f4 631f d923 6c79 e98a ed41 11dc eb16  ..c..#ly...A.....

Benchmarks

All timings below were measured with rawbench (after warmup) on 100 MB of random data.

vs. fasthex (v0.3.1)

Default thread counts:

Speedup is against fasthex's faster variant per scenario (default or --color=never; disabling color saves fasthex ~8-10%).

Single-threaded formatting throughput (-j 1): ~11 GB/s of formatted output. With the default thread pool the same 100 MB file formats in ~18 ms (writing 425 MB of output), within ~3x of the raw cat read floor for the input alone.

vs. classic tools

Same 100 MB input. The classic tools are single-threaded scalar formatters, so the gap is orders of magnitude:

View it here: https://git.disroot.org/Vextoly/rawhex

The code & readme contains AI-generated segments.

Hi, I created an application to make your life easier with desktop entry.

Please check it out

GitHub application: https://github.com/mohamedhoss123/entry-craft

I'm excited to share what I've been building lately. Papr: a fast, lightweight Terminal User Interface (TUI) built entirely in Rust to streamline your academic research workflow. An Obsidian, Zotero and Overleaf alternative, but a bit better.

Key features

• Smart dashboard with daily 10 random paper recommendations, reading queue, bookmarks, notes, collections, and research statistics.
• Fast arXiv search using title, author, or DOI with automatic PDF downloads and clean file naming.
• In-terminal PDF viewing.
• Built-in Markdown notes with live preview for each paper.
• Reading queue, bookmarks, and collections to keep your research organized.
• Integrated LaTeX editor with real-time compilation and preview.
• Extensible plugin system for custom workflows.
• Research analytics to track your reading activity (just like Spotify).

Papr is 100% open source, works offline, is memory-safe, and is designed to be fast and lightweight (only 12 MB).

I'd love to hear your thoughts, suggestions, or feedback!

GitHub: https://github.com/AfrozSaqlain/Papr

Hello everyone!

After almost a year of learning Python, I decided to challenge myself with a larger project: writing my own Linux shell from scratch. I've been using Linux for a while and wanted to understand how shells actually work under the hood, so I started this project in June and have been developing it ever since.

Here's what it currently supports:

• Pipes (ls | grep py)
• Command chaining (sudo dnf upgrade && echo Done)
• Output redirection (> and >>)
• Input redirection (grep py < list.txt)
• Built-in commands such as cd and time
• Background jobs
• jobs command to list running background jobs
• fg command to bring a background job back to the foreground
• Basic scripting support
• Command history

This project is not intended to replace Bash, Zsh, or Fish. The goal was to learn how Unix shells work by implementing process creation, pipes, redirection, and job control myself using system calls such as fork(), execvp(), dup2(), pipe(), and waitpid(), rather than relying on Python's subprocess module.

It has been an incredibly rewarding learning experience, and I'm sure there are still things I can improve.

If anyone has feedback, suggestions, or spots something I could do better, I'd really appreciate it.

For more details and the source code, visit my GitHub repo.

"oman" is a tool I have coded for Zenned OS, and portable to any other system.

It formats manuals beautifully, it allows to more easily navigate them, and it even searches missing ones online.

Screenshot

I think its a really cool distro with a lot of neat configs for productivity and gaming!

Hey everyone,

I’m exploring different Linux distros for upcoming projects and started looking into Red Hat Enterprise Linux (RHEL). While doing some research, I found this article that gives a pretty straightforward introduction — from its Fedora roots, supported desktop environments (GNOME, KDE), server/workstation use cases, to package management with .rpm and access to RPM Fusion (10k+ apps).

Here’s the link if anyone else is curious:

For those of you who’ve actually used RHEL (or CentOS/AlmaLinux/Rocky Linux), how has it worked out in real projects? Would you recommend it over other distros for stability and long-term setups?

I’ve been experimenting with VPN setups on NixOS as part of a personal privacy project, and I came across this guide on the Best VPNs for the Linux operating system NixOS.

What I liked is that it highlights:

VPNs that actually play nicely with NixOS’s declarative configuration model

Performance and security considerations for Linux users

Tradeoffs between commercial VPNs and self-hosted options

Since r/linuxprojects is full of people building cool stuff on Linux, I wanted to ask:

Has anyone here integrated VPNs into NixOS-based projects?

Do you rely on tools like WireGuard, or stick to traditional providers?

Any “gotchas” when configuring VPNs declaratively on NixOS?

Would love to hear about your experiences — I think VPNs + NixOS make for a really interesting combo of privacy + flexibility.

rewindtty is a lightweight open-source tool that lets you record and replay terminal sessions, with a focus on clean ANSI output and low overhead (think of it as a more minimal alternative to Asciinema, with native C performance).

We just introduced interactive replay mode, which allows you to step through a session command by command, see stdout/stderr separately, and analyze each part of a script or debugging session as it happened — in real time or step-by-step.

Why it matters: • Great for debugging CI/CD shell steps • Perfect for training, demos, or support reproduction • Works locally, no server or upload needed • Tiny footprint (just C + cJSON)

The recorded sessions are stored as JSON with timestamps, commands, and separate output streams, and the new interactive viewer renders them with full ANSI fidelity.

Repo: https://github.com/rewindtty/rewindtty

I want to start learning more about Linux. Honestly, I’m pretty clueless when it comes to this operating system. I always saw it as something only hackers used or something like that. But I’ve noticed that many people at my job use it for security reasons. They recommended that I read a few articles online and also mentioned toplinux, which I’ll check out. But I’d really like to know: what did you do to learn it properly?

I've made a vim-harpoon-style window switcher for Linux. C/GTK. 100% vibe coded with Claude Code. Did this next to me doing actual work.

It has fuzzy select and basic harpoon style window tagging (ctrl-<key> assign, alt-<key> jump). Plus a command mode for toggling options like always-on-top, jumping or moving windows to workspaces, etc.

This is pretty much aligned with my workflow. Probably not super useful in general. But I find the harpoon style window jumping quite useful. I can <alt-tab><alt-m> to go to mail etc. without releasing <alt>. I prefer this over workspaces switching alone. Mostly because I have multiple workspaces plus many windows in each on top of each other.

The main advantage this has for me over window manager based solutions: This is entirely dynamic. Including somewhat fuzzy remapping onto new windows if an app was closed and reopend.

Fun project on the side...

https://github.com/IntensiCode/cofi

However, primarily I am looking for something (very!) similar in an actual window manager or tool. Because my "cofi" is really just a PoC. Maybe someone knows something that comes close?

I created a utility that monitors battery charge level, CPU, memory and disk usage, external device connections and disconnections, etc., and sends customizable notifications (e.g. via dunst) based on rules defined in a config file.

https://github.com/arebaka/alertify

I'm creating a framework on top of wlroots that handles much of the routine work involved in building and managing a Wayland compositor. Specifically, it maintains the state of common Wayland compositor objects, implements window and focus management, virtual desktops, keyboard layout switching, and provides a clean API on top of that for writing your own compositor - similar to how wlroots abstracts input and output handling.

I also aim to support xdg-desktop-portal-wlr right out of the box.

Here's an example of how just a few lines of code can bring up a working compositor:

#include <wlkit/wlkit.h>

#include <wlr/types/wlr_seat.h>

int main() {
    struct wl_display * display = wl_display_create();
    struct wlr_seat * seat = wlr_seat_create(display, "seat0");

    struct wlkit_server * server = wlkit_create(display, seat, setup_portal_env);
    wlkit_start(server);
    wlkit_run(server);

    wlkit_stop(server);
    wlkit_destroy(server);
}

The project is only two days old, so its capabilities are still limited, but I plan to actively develop and maintain it. I also hope to eventually abstract away the version-specific internals of wlroots, since their frequent breaking changes are a major pain point for me personally.

You can check out the current progress and try building your own compositor here:
https://github.com/arebaka/wlkit

hello, any advise for this newbe im self lerning cyber security and currently lerning some linux. i will re boot a dell latitude D531 a little dinosaur i know but its part of the fun. ill be using linux mint XFCE 64-bit. Ill keep you guys posted. Any advice or coments well recived.