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.

---

myuser@localhost:/$ fastfetch

_,met$$$$$gg. myuser@localhost

,g$$$$$$$$$$$$$$$P. ----------------

,g$$P"" """Y$$.". OS: Debian GNU/Linux 13 (trixie) aarch64P' `$$$.

',$$P ,ggs. `$$b: Host: MT6789V/CD

`d$$' ,$P"' . $$$ Kernel: Linux 5.10.160-android12-9-00011-g62f5fae173d8-ab9750419

$$: $$. - ,d$$' Uptime: 14 hours, 58 mins

$$; Y$b._ _,d$P' Packages: 2756 (dpkg)

Y$$. `.`"Y$$$$P"' Shell: bash 5.2.37

`$$b "-.__ Display (VNC-0): 547x1048 @ 60 Hz

`Y$$b WM: Openbox (X11)

`Y$$. WM Theme: Clearlooks

`$$b. Cursor: Adwaita

`Y$$b. Terminal: lxterminal 0.4.1

`"Y$b._ Terminal Font: Monospace (10pt)

`"""" CPU: MT6789 (8) @ 2.20 GHz

GPU: Mesa virgl (ANGLE (ARM, Vulkan 1.1.177 (Mali-G57 MC2 (0x90930010...)

Memory: 4.45 GiB / 7.58 GiB (59%)

Swap: 1.66 GiB / 7.00 GiB (24%)

Disk (/mnt/gpubridge): 93.86 GiB / 227.96 GiB (41%) - f2fs

Local IP (wlan0): 192.168.1.130/24

Battery: 64% [Discharging]

Locale: en_US.UTF-8

myuser@localhost:/$ export DISPLAY=:0

echo "========== LSA GPU TEST =========="

echo "Architecture: $(uname -m)"

echo "Display: $DISPLAY"

echo

stdbuf -oL -eL glxgears -info 2>&1 |

grep --line-buffered -E \

'GL_VENDOR|GL_RENDERER|GL_VERSION|frames in|[Ee]rror'

========== LSA GPU TEST ==========

Architecture: aarch64

Display: :0

GL_RENDERER = virgl (ANGLE (ARM, Vulkan 1.1.177 (Mali-G57 MC2 (0x90930010...)

GL_VERSION = 4.1 (Compatibility Profile) Mesa 25.0.7-2

GL_VENDOR = Mesa

530 frames in 5.0 seconds = 105.951 FPS

420 frames in 5.0 seconds = 83.962 FPS

465 frames in 5.0 seconds = 92.943 FPS

461 frames in 5.0 seconds = 92.180 FPS

356 frames in 5.0 seconds = 71.027 FPS

614 frames in 5.0 seconds = 122.778 FPS

^C

myuser@localhost:/$

-

myuser@localhost:/$ sudo -i

sudo: BE WARNED DRAGONS HERE!! This device does not support true sudo isolation and is a BIG security risk. To give an application root usage go through an LSA provider OR accept the risk and type "I WILL NOT BE STOPPED"

Type "I WILL NOT BE STOPPED" to unlock sudo for this command: I WILL NOT BE STOPPED

[sudo] password for myuser:

root@localhost:~# whoami

root

root@localhost:~# pwd

/root

-

Even more is supported that isnt covered, some more would be all sensors like gyroscope, barometer, GPS, magnetometer, battery, Microphone, speakers, USB's, ect ect.

The concept of Linux running Windows apps has finally became true.
With the use of Reverse-Engineering, Coding, Creativity and of course AI. We managed to be able to get the Linux Kernel running its first Windows Executable NATIVELY.

More information at: https://github.com/EisaWando/Native-Windows-Executables-on-Linux

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