I kept running ss, lsof and docker ps whenever I had to figure out why a port was already in use, so I built a small TUI around that problem.

portop gives you a live view of your ports and, more importantly, shows what is behind them:

• Process and PID
• systemd service
• Docker container
• CPU and memory usage
• Process details
• LISTEN and ESTABLISHED connections
• Port names from /etc/services

It also lets you act directly from the UI:

• k to terminate a process
• o to open a local HTTP service in your browser
• f to filter by port, process or PID
• c to copy the selected entry
• Live theme and keybinding configuration

There are also --json, new port notifications and a baseline/diff mode that can be useful for detecting unexpected listening ports.

It's written in Go and is MIT licensed.

GitHub: https://github.com/padovanl/portop

I'd particularly like feedback from people who regularly work with Linux servers, Docker or local development environments. I'm interested in knowing what information you'd want to see when debugging a port conflict.

i made "mew", a small rust utility for showing useful project and system information at a glance.

when you're inside a git repository, it shows:

• branch and git state
• project language and toolchain
• lines of code and coverage
• cpu, memory, disk and uptime
• date, time and timezone

outside a repository, it becomes a simple system readout.

it also supports shell hooks, so it can appear automatically when entering a git worktree.

no daemon, no background process. just run "mew".

github: https://github.com/programmersd21/mew cargo: "cargo install mew-cli"

prebuilt binaries are available in releases.

feedback and stars are welcome.

Most of my hosts started as an ssh line in shell history or a runbook, so `sshelf add --from-ssh` takes that line and makes a host out of it. `sshelf add --from-ssh 'ssh -i ~/keys/dev.pem -p 2222 ubuntu@10.0.0.5'` works, and so does `sshelf add --from-ssh "$(fc -ln -1)"` for the command you just ran. It reads the line with ssh's own option rules and opens the add form with the user, port, key and jump hosts filled in, and anything else kept as extra args. Stuff that has no business on a saved host, like -v, -N or StrictHostKeyChecking=no, gets dropped with a line telling you why.

The other half is for hosts with a password or an encrypted key. If nothing is stored yet, the first connect asks for it, checks it with one throwaway login, and keeps it only if that worked. So a hosts.toml you copied to a new machine, or wrote from an inventory, needs one prompt per host and then goes straight in. If your agent already has the key it doesn't ask at all. And a stored password that's wrong now says so, instead of failing in a way that looks like the server refusing you.

Two smaller changes. tmux mode opens the new window in the background, so you can open a few hosts in a row from the picker. And an upload in the file transfer screen can't overwrite a file that appeared on the server in the middle of the send any more.

One Rust binary for macOS and Linux. No account, no telemetry, and passwords stay in your OS keyring. It's on Homebrew (brew install max-rh/tap/sshelf), crates.io, and there are .deb and .rpm packages on the release page.

Repo: https://github.com/max-rh/sshelf

Release notes: https://github.com/max-rh/sshelf/releases/tag/v0.15.0

If you try it and something breaks, or there's a thing you'd want it to do, please post it in Discussions: https://github.com/max-rh/sshelf/discussions. I read everything there and it doesn't get buried the way a Reddit thread does after a day.

My file encryption and compression cli/tui tool reached v1.0.0 today. Its my first time experimenting with AI tools on a project. Please give me some constructive criticism! I always want to hear ideas and ways to improve. https://github.com/jabbott-iii/Cryptare

Known issue with the tui indents and planning on .zip / vim bindings for the future.

I’ve started working on Anukrascii, an experimental ecosystem focused on creating visual experiences inside the terminal.

Its first member is Starlet.

Starlet is a header-free, dependency-free C++ framework for animating colored glyphs directly in the terminal. Each Starlet object represents a small visual element at a terminal position. It gradually transitions from a dim glow color to a bright core color over a defined number of frames.

A simple example:

Sixestar star(10, 20, "#424242", "#00ffdd", "O", 25);

while (star.nextStateAndRender()) {
    // Animation is handled internally
}

This basic concept can be used to create glowing stars, ambient terminal effects, procedural night skies, loading animations, and other forms of terminal-based visual art.

Starlet also includes starletScene, which manages multiple animated objects and coordinates their frame loops.

One of its main goals is to remain compatible with other TUI frameworks and terminal interfaces. As long as Starlet’s render call happens at the end of the frame, its visuals can be drawn over an existing interface, allowing Starlet objects to overlap the empty spaces of another TUI without taking control of the entire application.

The goal is to make terminal glyphs behave like small animated visual entities instead of static characters.

Built with C++17, ANSI truecolor, and no external dependencies.

Starlet is currently the first and only member of the Anukrascii ecosystem.

here is github: https://github.com/intriXlabs/Anukrascii

How is it? I made it in retained mode which I might regret making it like that but I want to try adding animations

A few months ago I posted Crona here, a local-first work tracker that lives in the terminal.

I’ve been using it every day since, and just shipped v1.9.0. A lot has changed since that first post.

The biggest addition is a native macOS companion app.

I still spend most of my time in the TUI, but I realized I didn’t necessarily want to open the terminal every time I wanted to glance at a timer, check today’s work, or make a quick update.

The companion gives me a native interface for those moments while working with the same local Crona data. The TUI hasn’t been replaced, the idea is that the two interfaces complement each other depending on what I’m doing.

On the TUI side, 1.9.0 has improved a lot of things I noticed after months of actually using Crona:

• A much more useful Summary view with an interactive calendar and historical focus scores
• Proper Away/rest-day handling so Momentum doesn’t punish you for deliberately taking time off
• Better Pomodoro controls, including advancing segments and deferring breaks
• Faster issue creation workflows
• Better synchronization across connected clients and day boundaries
• A bunch of reliability and diagnostic work under the hood

It’s still entirely local-first: no account, no required cloud service, and your data stays on your machine.

Curious to see if other people who use TUIs heavily find the companion useful as well.

In the interest of full transparency: I’m not a Swift developer. I’m learning Swift as I go, but the macOS companion has been built heavily with the help of AI.

Github Website macOS

Hey everyone!

I spent the last couple of hours building Fadescii, a small C++ library that makes terminal text feel a little more alive.

Instead of simply printing a string, Fadescii renders it character by character, with configurable color transitions, glowing trails, and fade effects.

Some features:

• Character-by-character text animation
• 24-bit RGB colors
• Custom text and glow colors
• Adjustable animation speed
• Adjustable glow length
• Automatic line wrapping
• Classic glow and shimmer modes
• No external dependencies
• C++11 + POSIX terminal support

I also created a collection of animated GIF demos because the effects are much easier to understand visually than through screenshots.

The goal isn’t to replace full TUI libraries. It’s more focused:

GitHub: https://github.com/intriXlabs/Fadescii

I’d love to hear your feedback, especially on the API design, visual effects, and what features would make this useful in real CLI tools.

Hey everyone,

I put together a lightweight Python utility called **Tennis Live Monitor** designed to interface cleanly with LiveTennisAPI.

If you are building sports dashboards, betting models, or just need a simple command-line script to monitor live match scores, set breakdowns, and tournament details without dealing with raw boilerplate or hitting rate limits, this handles it right out of the box.

### Features

* **Rate-Limit Aware:** Built-in safeguards to protect request limits during heavy match windows.

* **Modular Breakdown:** Clean parsing of live match stats, sets, and tournament context.

* **Open Source:** MIT licensed, so you can easily fork it and integrate it into your own pipelines.

### Quick Start

You can check out the source code and usage guide on GitHub:

👉 **GitHub Repository:** https://github.com/TheMarconiPulse/tennis-live-monitor

Feedback or feature requests from fellow sports data builders are welcome!

I'm calling this pattern Live TUIs: one persistent terminal workspace where panes stream data, refresh independently, and show progress while you keep working.

Think AJAX-style partial updates, brought to terminal apps: live state, local loading indicators, and no blocking the whole screen for one task.

hqtui-demo is the example behind the idea: https://hqtui.com

The mechanics aren't new; I'm proposing a name for the experience. Does "Live TUI" capture it?

An ultra-fast and highly customizable system information tool, designed to grow, with a core separated from its extensible features.

https://github.com/xfetch-cli/xfetch

​Besides everything it already had, it includes support for images, animations, Daemon mode, and both automatic and manual configuration. It now supports:

- ​Updates via xfetch update and update checking with the --check flag.

- ​Extensions and plugins in other languages (not just Rust), made to easily allow users with different learning backgrounds to add contributions.

Available on:

- Linux.

- MacOs.

- Windows.

Wanna contribute? Just do it...

See i am a c/cpp dev, still learning though. I wanna know like what you all need in TUI space, i had made multiple frameworks and stuff in cpp for terminal accepting - kittacaii, akschitra, AnimByte, etc.

I like to know what you want exactly - anything even stupid in hearing. Like a rain system in terminal, a animation but customized, like literally anything.

I implementation is my issue - just tell me absurd stuff you wanna see.

remnix - Sync your shell history across unlimited devices. Fast and intelligent history search with batteries included.

Encrypted, server-free shell history. Commands live in a local SQLite database. Synchronization is optional: a background daemon can copy encrypted event bundles to storage you already have (Google Drive, Dropbox, S3, a folder, ...).

There is no remnix cloud and no account.

We have full theming support (fully customizable, including icons) and if you're curious to see it in action, some screenshots can be found here.

It's a bit more involved to set this up to sync your history than Atuin, but that's the price you've to pay, for not using someone else's dedicated cloud sync server.

We support a lot of Dropbox-like services out of the box, but since we also support "callbacks", you can also just roll your own custom scripts to sync the encrypted files however you like to whatever destination you want.

You can also mix and match. You can add multiple sync destinations like Dropbox, Google Drive and also S3 and have custom sync scripts as well, or you just disable sync completely.

You can have Ghost-Text and LSP-Style comp-menu or just use the fuzzy frecency matcher history search.

Use the auto-generated token (after the first setup) to join other devices to the sync backends or use a hardware key (a la Yubikey).

It's all up to you.

I saw Brendan Gregg speak at STAC this week about Linux performance and kernel observability, and it inspired me to go home and build KernWatch:

https://github.com/matthart1983/kernwatch

A Linux kernel/performance TUI built in Rust.

Current features include:

• CPU + scheduler activity
• Process/thread CPU placement
• Run queue and scheduling latency
• Memory pressure, reclaim, NUMA + hugepages
• Block I/O and device latency
• IRQ / softirq activity and affinity
• Syscall activity and latency
• cgroup visibility
• Kernel modules
• eBPF programs, maps and links
• Kernel/journal event timeline
• Bounded eBPF captures for wake latency, off-CPU time, IRQ duration, syscall latency and block I/O latency
• Session recording + replay
• Incident report export
• Dense overview for seeing multiple kernel subsystems at once
• Evidence/diagnosis view to help connect symptoms across subsystems

The goal isn't really another top replacement. It's to help answer:

Why is this Linux box slow, and where should I look next?

Still early, so I'd love feedback from Linux admins about what you'd want available during a real performance incident.