Yesterday I learned that #ghostty, the terminal emulator supports custom shaders. So here is a little retro/crt shader: https://gist.github.com/lukad/d979a36ed9a83020bd6fa3fa0d5d7c89

While some users prefer to use Git via CLI, they often rely on a GUI or feature-rich TUI to view commit logs. Others may find git log --graph sufficient.

Personally, I found the output from git log --graph difficult to read, even with additional options. Learning complex tools just to view logs seemed cumbersome.
Goals
Provide a rich git log --graph experience in the terminal.
Offer commit graph-centric browsing of Git repositories.

A tasty, self-hostable Git server for the command line. 🍦

The fundamental problem of shells is they are required to be two things.

A high-frequency REPL, which requires terseness, short command names, little to no syntax, implicit rather than explicit, so as to minimize the duration of REPL cycles.
A programming language, which requires readable and maintainable syntax, static types, modules, visibility, declarations, explicit configuration rather than implicit conventions.

And you can’t do both. You can’t be explicit and implicit, you can’t be terse and readable, you can’t be flexible and robust.

Shells optimize the former case, so that you can write cat beef.txt | grep "lasagna" | sort -n | uniq instead of:

with open(Path("beef.txt")) as stream:
lines = filter(
stream.readlines(),
lambda line: re.match(line, "lasagna") is not None
)
print(set(reverse(sorted(lines))))

Which does not spark joy.

So the programming language aspect suffers: shell scripts are an unreadable nightmare of stringly-typed code resembling cyphertext.

SSHHeatmap

Generates a heatmap of IPs that made failed SSH login attempts on linux systems, using /var/log/auth.log to get failed attempts. Uses the ipinfo.io library to fetch the IP address coordinates, and folium to generate the heatmap

The xpipe command reads input from stdin and splits it by the given number of bytes, lines, or if matching the given pattern. It then invokes the given utility repeatedly, feeding it the generated data chunks as input.

You can think of it as a Unix love-child of the split(1), tee(1), and xargs(1) commands.

It's usefulness might best be illustrated by an example. Suppose you have a file 'certs.pem' containing a number of x509 certificates in PEM format, and you wish to extract e.g., the subject and validity dates from each.

The openssl s_client(1) utility can only accept a single certificate at a time, so you'll have to first split the input into individual files containing exactly one cert, then repeatedly run the s_client(1) command against each file.

And, let's be honest, you probably have to google how to use sed(1) or awk(1) to extract subsequent blocks from a flip-flop pattern.

xpipe(1) can do the job for you in a single command: