What explains the popularity of terminals with 80×24 and 80×25 displays? A recent blog post "80x25" motivated me to investigate this. The source of 80-column lines is clearly punch cards, as commonly claimed. But why 24 or 25 lines? There are many theories, but I found a simple answer: IBM, in particular its dominance of the terminal market. In 1971, IBM introduced a terminal with an 80×24 display (the 3270) and it soon became the best-selling terminal, forcing competing terminals to match its 80×24 size. The display for the IBM PC added one more line to its screen, making the 80×25 size standard in the PC world. The impact of these systems remains decades later: 80-character lines are still a standard, along with both 80×24 and 80×25 terminal windows.

This is a community maintained list of TUI applications. A TUI application runs in your terminal and has some level of interactivity. Commands included in this list should not wrap other interactive commands (e.g. fzf), and should be maintained.

Die Rust-Implementierung sudo-rs zeigt beim Eintippen von Passwörtern nun standardmäßig Sternchen an. Ein Bruch mit langer Unix-Tradition.

Each planet rules specific types of system tasks:

☀️ Sun (Life Force): Critical system processes (PID 1, init)
🌙 Moon (Emotions): Interactive tasks (shells, editors, terminals)
💬 Mercury (Communication): Network and I/O tasks
💖 Venus (Harmony): Desktop and UI processes
⚔️ Mars (Energy): CPU-intensive tasks (compilers, video encoding)
🎯 Jupiter (Expansion): Memory-heavy applications (databases, browsers)
⚙️ Saturn (Structure): System daemons and kernel threads

Qalculate! is a multi-purpose cross-platform desktop calculator. It is simple to use but provides power and versatility normally reserved for complicated math packages, as well as useful tools for everyday needs (such as currency conversion and percent calculation). Features include a large library of customizable functions, unit calculations and conversion, symbolic calculations (including integrals and equations), arbitrary precision, uncertainty propagation, interval arithmetic, plotting, and a user-friendly interface (GTK+, Qt, and CLI).

There are plenty of reasons why you might want to adopt a terminal-based file manager on Linux. No, they aren't as convenient as a GUI, but when they are necessary, they are great to have around.

But which ones should you consider? When you dive down that rabbit hole, you'll find there are plenty. For me, however, only a handful bubble to the top, and here they are.

ssg.sh builds static websites by converting markdown to html, applying templates, executing site scripts, honoring ignore files, zipping content, and copying other files unchanged. on subsequent runs, it only updates what has changed

Worker is a two-pane file manager for the X Window System on UN*X. The directories and files are shown in two independent panels supporting a lot of advanced file manipulation features. The main focus is to make managing files easy with full keyboard control, also assisting in finding files and directories by using history of accessed directories, live filtering, and access to commands by using the keyboard.

Pretty fancy and modern terminal file manager

A powerful and secure environment variable manager for developers, featuring an intuitive Terminal User Interface (TUI) and comprehensive command-line interface.

The quick summary is that the console TTY's mouse support is broadly like a terminal emulator. With a mouse daemon active, the TTY will do "copy and paste" selection stuff on its own. A mouse aware text mode program can put the console into a mode where mouse button presses are passed through to the program, just as happens in xterm or other terminal emulators.

*0:00* - Introduction to Terminals, PTY, and TTY
*0:08* - Running Commands and the Role of the Shell (e.g., Zsh, Bash)
*1:50* - What is TTY (Teletypewriter)?
*2:09* - Virtual Consoles and Terminal Emulators
*2:41* - Pseudo-Terminals (PTY) and Terminal Simulation
*2:50* - ANSI Escape Codes for Formatting (Color, Underline, Bold)
*3:57* - Interpretation of ANSI Codes by Terminal Emulators
*4:46* - Parsing ANSI Codes (Example with `pyte` and HTML)
*6:29* - Processes, Controlling Terminals, and Signals (Ctrl+C, SIGHUP)
*7:47* - How PTY Works and Why it's Needed
*8:32* - Line Discipline: Cooked Mode (Canonical) vs. Raw Mode
*9:40* - Line Discipline: Echoing
*9:53* - Changing Terminal Options with `stty` (Disabling Canonical Mode and Echoing)
*10:41* - Signal Management and Flow Control (Ctrl+S, Ctrl+Q)
*11:49* - Window Size and Resizing Events (SIGWINCH)
*13:47* - PTY and Remote Connections (SSH and PTY)
*14:58* - Summary

The TTY subsystem is central to the design of Linux, and UNIX in general. Unfortunately, its importance is often overlooked, and it is difficult to find good introductory articles about it. I believe that a basic understanding of TTYs in Linux is essential for the developer and the advanced user.

Beware, though: What you are about to see is not particularly elegant. In fact, the TTY subsystem — while quite functional from a user's point of view — is a twisty little mess of special cases. To understand how this came to be, we have to go back in time.

SSH tunneling (also known as SSH port forwarding) is powerful technique that allows system administrators to create secure encrypted connections between servers, bypass firewalls, and access services securely across networks. Its also known as SSH magics! Whether you’re trying to securely access internal services, create SOCKS proxies, or establish reverse tunnels to overcome network restrictions, SSH tunnels provide flexible solutions for modern networking challenges. This comprehensive guide explores essential SSH tunneling commands that every system administrator should know, complete with practical examples and use cases to enhance your network security toolkit. So let’s get on with some SSH magics, shall we?

It's 2024! Please avoid writing SSH commands like that.

Instead, configure your ~/.ssh/config with LocalForward, RemoteForward, and ProxyJump. This can save you a significant amount of time, especially when using ssh, scp, or rsync to transfer data from a remote server that requires multiple intermediate SSH connections.

SH tunneling and port forwarding can be used to forward TCP traffic over a secure SSH connection from the SSH client to the SSH server, or vice versa. TCP ports or UNIX sockets can be used, but in this post I’ll focus on TCP ports only.

I won’t go into details, but the following post should show enough examples and options to find use in your day-to-day work.

Ever need to work on a remote computer which is behind a typical firewall. Well if there is no inbound connectivity, you can play a bit of leap frog using ssh in order to gain access to that server. Here’s a quick example.
For this example we’ll assume you are sitting at Host A and would like to have access to Internal Host C. Both firewalls are assumed to allow ssh traffic out.
Our goal here is to have the Internal Host C machine start an ssh session to External Host B (which is on the internet).
SSH -R 2200:localhost:22 User@ExternalHostB
This will start an ssh session from Internal Host C to External Host B and ask the ssh daemon to forward all traffic on External Host B’s port 2200 back to Internal Host C’s port 22 over the established ssh session.
Now If I were on External Host B, to get a shell on Internal Host C all I’d have to do is:
SSH -p 2200 User@localhost
Now the USER in the above statement would have to be a valid user on Internal Host C, not External Host B.
To connect from Host A to Internal Host C you can do several things. The easiest is to leap frog.
SSH USER@ExternalHostB
Then
SSH -p 2200 USER@localhost
The first session opens a shell on External Host B. The second opens a shell on Internal Host C by connecting to the reverse shell we started in the first command.
This has been a simple reverse shell ssh post. Stay tuned for more port forwarding fun.

he OED’s earliest listed usage of “log in” in the modern sense of “to open one’s on-line access to a computer” is from the 1963 publication Compatible Time-Sharing System from the MIT Computation Center. [2] I’m not sure if this is truly the first usage of “log in”, but it would make sense if it was, as CTSS, started in 1961, was arguably the first time-sharing operating systems, and so possibly the first system that you needed to log in to. (Before that we only had batch processing systems).

A lot of new hardware security keys (Yubikey, Nitrokey, Titan, etc.) now support FIDO2 (aka U2F aka Webauthn aka Passkey; yes it’s a mess).

So does OpenSSH.

This spells good news for us, because it is far easier to use than previous hardware security types (eg, PKCS#11 and OpenPGP) with ssh.

A key benefit of all this, if done correctly, is that it is actually impossible to access the raw SSH private key, and impossible to use it without the presence of the SK and a human touching it.

Also, ssh agent forwarding becomes safer again, and what’s more, it can be used to let you tap your local key to authenticate even when sshing from remote machine A to remote machine B.

I’m going to call these hardware security keys “SKs” within this article.

I’ve been annoyed at the material out there, which often doesn’t explain what’s happening and suggests insecure practices.

So, I’m going to introduce SKs and FIDO2, show how to use the keys with SSH, explain the role of ssh-agent with all of this, and walk you through all of the steps.

Decided to do some #Linux terminal hopping.

This is my completely unscientific test: maximised window, tmux with a NeoVim session, paging quickly through some code. I wanted to see what the most CPU usage would be for these terminals. I'm testing on a Ryzen 7 7840U.

Why worry about CPU? Laptop users and low-power machine users will care about CPU usage. I'm trying to eke as much life out of my equipment as possible.