My Terminal-First Stack: Fast Tools for People Who Actually Work

title: My Terminal-First Stack: Fast Tools for People Who Actually Work
published: false
description: 17 terminal tools I use daily on Fedora Linux — and why VSCode is a browser, not an editor.
tags: linux, terminal, productivity, unix
cover_image:
My Terminal-First Stack: Fast Tools for People Who Actually Work
I've been a Linux user for a long time. Long enough to have watched the ecosystem slowly drift toward a strange place — where "developer tools" means Electron apps, where editors are basically Chrome tabs with syntax highlighting, and where a simple text editor somehow needs 600MB of RAM to open a Python file.
This is my answer to that. A stack built around one principle: fast, focused tools that do one thing well and get out of the way.
No bloat. No browser disguised as a development environment. No monthly subscriptions to write a damn task list.
The Foundation

1. Fedora Linux Fedora is my desktop OS and has been for a while. Red Hat-based, ~6 month release cycle, first-class Wayland support, SELinux enabled by default. It sits in a sweet spot: cutting-edge enough to have modern tooling, stable enough to not blow up your workflow every other week. The RPM package format gets unfairly overlooked in desktop Linux conversations. Compared to .deb, RPM has stricter dependency resolution, atomic transactions with rollback support, and native integration with the Red Hat/CentOS/Rocky ecosystem. When your servers run Rocky Linux and your desktop runs Fedora, you get consistency from top to bottom. That matters.
2. LXQt / KDE LXQt for daily use, KDE when I need something heavier. The desktop environment exists to launch the terminal — that's it. Lightweight, no background indexing daemon eating my CPU, no unnecessary animations. The graphical environment is just a launcher. The work happens somewhere else. Shell & Editing
3. WezTerm I've tried Alacritty, Kitty, the KDE default terminal. WezTerm won because it gets the balance right: GPU-accelerated rendering, configuration in Lua, built-in multiplexer, ligature support, native splits — without forcing tmux for everything. Starts in ~80ms. Configured in plain text. Works identically on any machine. The best terminal I've used, and also the easiest to tune to your taste.
4. Oh My Zsh Zsh with Oh My Zsh handles 90% of what you'd otherwise configure by hand: smart autocompletion, shared history across sessions, useful plugins for Git and Docker, sane aliases out of the box. Pair it with zoxide for directory jumping, atuin for searchable shell history, and fzf for fuzzy-finding everything — and the shell becomes something you never want to leave.
5. Textadept This is the one that gets the most raised eyebrows, and I'm fine with that. Textadept is a lightweight, scriptable editor built in Lua. It opens instantly. It doesn't run a language server that consumes 400MB just to tell me I forgot a semicolon. It doesn't phone home. It doesn't have a marketplace of 40,000 extensions maintained by strangers. LSP support is available via plugin, works well, and stays out of the way. Keybindings that make sense without memorizing Vim liturgy. People will say Neovim. I respect Neovim. But Textadept just works — no initiation ritual, no hours of configuration before you can edit your first file. That's worth a lot. The VSCode Problem Let's talk about the elephant in the room. VSCode is not a text editor. It is a web browser — specifically, it's Electron, which is Chromium wrapped in a JavaScript runtime — dressed up as an IDE. When you open VSCode, you are launching a browser. This is not an exaggeration. Open your system monitor and look at the process tree. The symptoms are familiar to anyone who's used it seriously: Startup time measured in seconds, not milliseconds Memory usage that starts at 300MB before you open a single file and climbs to 1GB+ with a few extensions A fan that spins up on a modern machine just for editing text Extensions that are themselves mini Electron apps, each with their own memory footprint "Extensions host" crashing at random, taking half your tooling with it The VSCode model is: ship a platform, let the community build everything on top of it, hope the result is stable. And to be fair — it works, mostly. The extension ecosystem is enormous. GitHub Copilot integration is seamless. For many people it's genuinely fine. But "genuinely fine" at a cost of 1.5GB of RAM and a 4-second cold start is a trade I'm not willing to make when the alternative is a tool that starts in 80ms and uses 20MB. The deeper issue is philosophical. VSCode treats the editor as a product to be grown indefinitely — more features, more integrations, more UI surface. The Unix approach is the opposite: small, sharp tools that compose. I want an editor that edits text well and delegates everything else to the right tool for the job. Textadept does that. So does any serious terminal editor. VSCode is a browser. Choose accordingly. Security
6. pass pass is the Unix password manager. Each password is a GPG-encrypted file, stored in a plain directory, versioned with Git. No proprietary database, no third-party app, no someone else's cloud server. I use it primarily to manage API keys — Anthropic, GitHub, cloud services, internal tools. Instead of dumping keys into .env files in plain text, or exporting them in .zshrc where they'll show up in history, I do: export ANTHROPIC_API_KEY=$(pass show api/anthropic) The key never appears in any file. It never shows up in a commit. It never leaks through a misconfigured dotfile sync. pass decrypts it at runtime, injects it into the environment, and that's it. This is especially relevant when you work with AI tools like Claude Code or Aider — both of which need API keys in the environment. Storing those keys in plain text anywhere is an accident waiting to happen. pass solves this cleanly, with zero overhead, using tools that have existed in Unix for decades. Task & Time Management
7. Taskwarrior + vit The most powerful task manager in the terminal. task add, task next, filtering by project/tag/urgency, configurable reports. vit is the TUI layer on top — navigate, edit, and complete tasks without typing full commands every time. Sync via WingTask, which speaks the taskd protocol natively and has a mobile app for when you're away from the terminal.
8. Timewarrior Time tracking that integrates directly with Taskwarrior. When you complete a task, the time is already logged. Reports per project, charts in the terminal. Simple, local, no monthly subscription.
9. bugwarrior Pulls issues from GitHub and cards from Trello as Taskwarrior tasks. Your external work items live inside the same task system as everything else. One interface, one workflow.
10. TaskWarrior Agenda Syncs Taskwarrior with Google Calendar. Deadlines and scheduled tasks appear in your calendar. Useful for the overlap between terminal-first work and the rest of the world that insists on using Google Calendar.
11. Joplin CLI Notes in Markdown, synced via Dropbox or OneDrive, accessible from the terminal or the GUI app. Fast, open source, no vendor lock-in. The terminal interface is clean enough that I rarely need to open the GUI.
12. gcalcli Google Calendar in the terminal. Check your schedule, add events, get agenda view — without opening a browser. Pairs well with TaskWarrior Agenda for a complete picture of the day without leaving the shell. AI Tooling
13. Claude Code + Aider Two AI agents running in the terminal. 🔥 Claude Code is Anthropic's official CLI agent — it reads your codebase, understands context, writes and edits files, runs commands. Deep integration with Claude's reasoning capabilities. Aider is a complementary agent that works at the git level — it makes commits as it goes, which means AI changes are tracked just like any other change. Useful for a different style of interaction. Having both is not redundant. They're good at different things and together cover most of what you'd want from AI-assisted development — without opening a browser or switching to an Electron app to do it. Both need API keys in the environment. Both get those keys from pass. Version Control
14. gh + git + lazygit git for everything. gh for GitHub-specific operations — creating PRs, checking CI status, managing releases — directly from the terminal. lazygit for when you want a visual overview of branches, diffs, and staging without leaving the terminal. Fast, keyboard-driven, genuinely good TUI.
15. yadm Dotfile manager built on top of git. No symlinks, no templating system to learn — your home directory is the repository. yadm handles the git operations on top of it. Automated commits via watchexec and a systemd user service mean changes are versioned as they happen, with GitHub as offsite backup. Communication
16. WeeChat IRC and Matrix client in the terminal. Everything else in this category is either an Electron app or a web interface. WeeChat is neither. It's fast, extensible via scripts, and has been around long enough that most edge cases are already handled. Browser
17. Chrome / Firefox The one concession to the GUI world. The web exists, and some of it genuinely needs a browser. I'm not going to pretend otherwise. But the browser is a tool for browsing, not for editing text, managing tasks, tracking time, or writing code. That distinction — browser as one tool among many, not as the platform everything runs on top of — is what separates this stack from a default modern developer setup. Resource Awareness Is an Engineering Virtue — Not a Hardware Problem Here's an argument I hear constantly: "Hardware is cheap. RAM is cheap. Who cares if VSCode uses 1.5GB?" It's a reasonable-sounding argument. It's also completely wrong — and the reason it's wrong reveals something important about the difference between someone who writes code and someone who actually understands systems. Fast machines don't make wasteful abstractions acceptable. They make them invisible. That's worse. When you stop feeling the cost of your tools, you stop reasoning about cost altogether. You ship a web service that runs fine on your 32GB dev machine and falls apart under load in production. You build a mobile app that feels smooth on your flagship phone and destroys the battery of anything released before 2022. You design a database query that works great with 10,000 rows and brings the system to its knees with 10 million. The machine was fast. The problem was invisible. Until it wasn't. Engineers who have always worked with constrained environments develop a different instinct. They ask: what is this actually doing? They notice when something takes longer than it should. They know the cost of an abstraction — not because they memorized it, but because they've felt it. This is not about nostalgia for slow computers. It's about maintaining calibration. A tool that starts in 80ms tells you something. A tool that takes 4 seconds tells you something too — it tells you that somewhere in that startup sequence, layers of abstraction are being initialized that you didn't ask for and probably don't need. A senior engineer notices that. A junior engineer says "it's fine, hardware is cheap." The same logic applies at every level of the stack. An API that does one thing cleanly. A function that allocates only what it needs. A query that hits the index. A container image that doesn't bundle the entire Ubuntu base when Alpine would do. These are not micro-optimizations. They are the habits of someone who understands what they're building. Resource consciousness is not a constraint. It's a diagnostic tool. The engineer who chooses a 20MB terminal editor over a 600MB Electron app isn't making a sacrifice. They're demonstrating that they can reason about the tradeoff — that they know why one costs more than the other, and they've decided that cost isn't justified. That reasoning process is exactly what separates architects from assemblers. You can absolutely write correct code with VSCode on a 64GB machine and never think about any of this. Many people do. But the moment your work crosses into systems where resources are finite — embedded hardware, production servers at scale, shared infrastructure, battery-powered devices, cloud bills — the habits you built in your comfortable environment will betray you. Choosing lean tools keeps the feedback loop honest. It keeps you calibrated. And calibration is what engineering actually is. Why This Matters The cumulative effect of these choices is significant. This entire stack, running simultaneously, uses less memory than VSCode does on a cold start. Every tool starts in under a second. Everything is configurable in plain text. Everything works over SSH on a remote server. Everything composes. That's the Unix philosophy. Not nostalgia, not minimalism for its own sake — pragmatism. Tools that respect your hardware, your time, and your attention. The terminal isn't a limitation. It's a feature. Running on Fedora 43. All tools open source. No Electron processes were harmed in the making of this workflow.