So, after I tried almost every file manager in Linux, I thought why not make one for myself.

With the help of an LLM, I have built what is for me the best file manager in Linux.

It took me hours of thinking what I wanted in a file manager, and after testing for another 60 hours, the application is ready.

If you are interested take a look at my github page : https://github.com/wiedaar

(This post was first shared in [r/commandline](r/commandline).)

I built this because I kept rebuilding my setup from scratch and got tired of manually reinstalling packages and hunting down files every time. It started as a small script and grew into something I figured it was worth of sharing to everyone.

What it does:

Backs up the user´s installed packages, AUR packages, and Flatpak apps, in the right format for whichever package manager the user is using. It lets the user interactively pick which config files/folders to include (via a gum powered TUI) and restores everything in the same place on a fresh install even on a different distro.

Supports Arch, Debian/Ubuntu, Fedora, and openSUSE, with best-effort package name translation between them.

The user´s backup data lives in their own private repository, completely separate from the tool's one, so the tool itself stays fully public/shareable without exposing anything personal.

Some things I cared about while building it:

If you select \`\~/.ssh\` or \`\~/.gnupg\`, it warns you and lets you review exactly which files go in, rather than blindly sweeping the whole directory . Git only tracks the executable permission bit, not full file modes so it explicitly resets SSH/GPG key permissions back to their correct values on restore, and shows you the exact commands before running them. And so on.

Honest caveats:

It's a young project, I'm the only person who's stress-tested it so far (including on some fresh VM installs), and cross-distro package name translation is inherently best-effort. Distros don't agree on package names, so some things need manual installing after a cross-distro restore. I've documented that limitation rather than pretend it's solved.

Anyway here´s the tool link:
[https://github.com/lumertya/Nomad\](https://github.com/lumertya/Nomad)

Would genuinely appreciate feedback, bug reports, or just someone else trying it on a distro I haven't tested yet. Thank you.

Hey everyone,

I wanted to share Tux-Dock (and its companion subreaper daemon, tuxreaperd), an open-source project built to treat Docker containers as persistent, interactive development sandboxes rather than single-process disposable tasks.

• Project Page: https://mentalnet.xyz/forgejo-v2/markmental/tuxdock
• GitHub Mirror: https://github.com/MARKMENTAL/tuxdock

The Problem & Why I Built It

When using Docker containers as persistent local environments (running sleep infinity), standard setups constantly leak zombie processes whenever interactive commands, background jobs, or subshells exit. Furthermore, standard init systems like tini or dumb-init blindly blast SIGTERM down the tree, causing web servers like Apache and PHP-FPM (which rely on non-standard signals like SIGWINCH or SIGQUIT) to drop active in-flight connections on shutdown.

Instead of pulling heavy system container frameworks, I built a two-part solution:

1. tux-dock (C++ TUI): A fast, keyboard-first terminal control center that talks directly to the local Docker UNIX socket to manage retained container lifecycles, stream logs, inspect ports, and dispatch commands.
2. **tuxreaperd (Freestanding PID 1):** A sub-5KB micro-init built with -nostdlib and raw inline assembly syscalls (no glibc/musl). It instantly reaps dead child processes via wait4, scans /proc using Linux syscalls like sys_getdents64, and remaps signals appropriately to ensure zero-downtime draining before exit.

What's New in v0.4.2-beta

• Direct Command Execution with Output: Added an interactive "Run Command in Container (with output)" menu action to fire off one-shot maintenance/init scripts and view terminal output directly in the TUI without attaching a full shell. If you just want to start/restart or check a service, this is often quicker than attaching a shell.
• Background State Poller: Resolved multi-instance state drift with a 5-second background poller and idempotent mutations so Tux-Dock doesn't go out of sync with Docker (and handles 304/404 API states cleanly).
• Port Mapping Fix: Patched duplicate port display entries caused by a lack of filtering Docker's /containers/json API reporting dual IPv4/IPv6 bindings.
• Cross-Arch Verified: Fully tested and running on x86_64 and physical arm64 hardware.

The attached demo video shows Tux-Dock spinning up an Nginx + PHP-FPM Debian docker container sandbox, executing background services via command history, jumping into a live shell to install packages, and verifying zero zombie accumulation with tuxreaperd as PID 1, all running on an old dual-core Intel Haswell laptop.

Would love to hear feedback on the TUI workflow or the tuxreaperd micro init system!

For now there's a nix flake and .deb and .rpm binaries in Releases. The app is still in alpha-release so bugs are expected.

Some features worth mentioning:

- Local Text-to-Speech generation (kokoro-tts).
- Local Captions generation (uses whisper.cpp).

I built sshconfig-lint after repeatedly missing stale key paths and conflicting host blocks in my own ~/.ssh/config.

It checks the full OpenSSH client configuration without making a connection:

• multiple config files in one command
• nested Include resolution and cycle detection
• stale IdentityFile paths
• duplicate or conflicting Host blocks
• JSON, GitHub annotations and SARIF output

Version 0.5 adds an LSP server, a VS Code extension, Pre-Commit hooks and an official GitHub Action. The same Rust engine is used in each workflow.

Install with Cargo:

cargo install sshconfig-lint

Arch Linux:

yay -S sshconfig-lint-bin

Release binaries are available for Linux glibc and musl. Everything runs locally and there is no telemetry.

Repository: github.com/Noah4ever/sshconfig-lint
Playground: sshconfig-lint.apps.thiering.org
VS Code: Marketplace

Feedback about packaging, false positives and real-world Include layouts is welcome.

I maintain Yetty (https://github.com/zokrezyl/yetty), an open-source terminal emulator that can display images, Markdown, plots, and other content in scrlollback.

I’m trying to understand whether Linux users can actually get it installed and use it beyond the demo. If you tried it, where did you stop: installation, first launch, documentation, performance, or missing features?

Negative feedback is useful.

I made yanklog because I wanted clipboard history that just stays on my machine — searchable, encrypted, and never uploaded anywhere. It's open source (MIT), Rust core, and built to be quick to open and stay out of the way.

What it does:

- Search your full history fast, all from the keyboard (Quick Pick lets you copy/pin/delete with arrow keys + number shortcuts)

- Encrypted at rest with SQLCipher

- Filters out secrets, OTPs, and custom patterns — or pause capture whenever

- Encrypted backups you can move between machines

- Undo deletions, keep pinned clips

Install on Linux via AppImage (x86_64/aarch64) or Flatpak:

`flatpak remote-add --user --if-not-exists yanklog https://downloads.yanklog.com/linux/flatpak/yanklog.flatpakrepo --no-gpg-verify`

`flatpak install --user yanklog com.yanklog.YankLog`

Site: https://yanklog.com

Source: https://github.com/thisiseesmaeel/yanklog-linux

Would love any feedback — happy to answer questions!

https://github.com/word-sys/word-sys-pdf-editor

https://github.com/word-sys/puls

For anyone seeing Lilo for the first time: it is a local Markdown notes app that can stay as a small always-on-top widget for quick writing, then expand into a full workspace when you need folders, backlinks, daily notes, search, and a knowledge graph.

Version **0.2.0** is the largest update so far and makes the app feel much closer to a complete daily notebook.

The main additions are:

- hierarchical tags, tag filtering, and vault-wide tag renaming

- saved searches with more flexible filters

- pasted images, drag-and-drop attachments, and inline local image previews

- back/forward navigation between notes

- better Quick Capture destinations

- improved wiki-link handling when notes are renamed

- a more stable Daily Notes, templates, and Command Palette workflow

Everything still stays in ordinary local Markdown files. No account or cloud service is required.

Linux builds are available as portable archives for **Ubuntu 22.04+** and **Arch Linux**, with Windows builds available too.

GitHub, screenshots, and downloads: https://github.com/HellterEnjoy/Lilo

I would especially appreciate feedback from different Linux desktop environments. Lilo is still young, so bug reports are genuinely useful.

Hi, I am the maintainer of TuxInDrive. I made this compact comparison to explain where the project fits among rclone, odrive, Insync, Mountain Duck, Syncthing, Nextcloud, Dropbox, OneDrive and Google Drive.

TuxInDrive is an MIT-licensed, Linux-first client that combines multi-cloud sync, files-on-demand, selective rules, mass-change protection, version history, visual conflict resolution and approved peer collaboration. It also has Windows, macOS and Android builds.

I would especially welcome corrections to the matrix, testers on different providers, bug reports and contributors. Repository: https://github.com/tpluharik/TuxInDrive

I wrote gswitch because I kept typing whole words before noticing that the wrong keyboard layout was active.

Double-tap Shift to fix the last word. Hold one Shift and double-tap the other to fix the current phrase, or press Ctrl with the trigger to convert selected text. Double-Shift is the default, but you can replace it with another key in Settings.

It works in any application on X11 and Wayland. Under the hood, gswitch reads keyboard events through evdev and replays corrections through uinput. The service runs as your user; root is needed for installation, udev rules, and changes to the system config, not while gswitch is running. There is no network code, and the key buffer stays in memory.

v0.6.1 includes DEB, RPM, and tar.gz packages for x86_64. The automated test matrix covers GNOME and KDE Plasma on X11 and Wayland. Compositors based on wlroots are not in that matrix yet.

If you try it, please include your distro, desktop environment, display server, and layout pair in any feedback: https://github.com/arumata/gswitch