Tooling

Setting up snapper on Arch

had thinkpad to spare; old opensuse tumbleweed; snapper on btrfs was convenient post mess ups.

don’t like distrohopping, like rolling releases, like docs, like snapper - installed arch (arch wiki’s great), will hijack with bedrock linux 1 some day.

installed with minimal defaults first(systemd-boot instead of grub), later decided to setup snapper : an involved process: crude state transitions as follows:

  • systemd-boot + UKI -> grub + initramfs
    • grub-btrfs convenience
    • readily shows snapper snapshots
  • setup pacman (pre and post mutation, temporal) snapper snapshot creation and cleanup hooks

been my DD for a while now : sway + waybar, wayland, gcc emacs, tmux, some handrolled CSS, a bunch of TUIs: been fun

Staples

  • Have converged onto a DE agnostic workflow.
  • need only a few keybinds to help me move across windows and monitors.
  • window estate management is done via emacs and tmux : don’t really need a tiling wm.
  • opencode when I’m not learning anything and mostly know what needs to be done.
    • open a bunch of these in multiple tmux panes and you’re good.
  • a vim-keybinds enabled browser

The Un-Unified Heterogenous Irk

I’ve lately been thinking deeply about how I interact with my computing environments; when working, I’ve a
- an unrooted snapdragon ARM Android with Termux and Tmux for ephemeral vimmin & sshing around when on the move
- an Intel x86 FreeBSD home lab for some asynchronous compute that I don’t need right away and some redundancy for my important files
- a personal ubuntu VPS with a couple of intel x86 vCPUs for my self hosting endeavours and overall context orchestration
- several compute clusters (avx enabled x86s, ARM, “the propietary GPU driver guy on the street” GPUs, “the other open source GPU driver guy on the steet” GPUs, k8s orchestrated production & development playgrounds) for work
- an AMD x86 Tumbleweed with emacs as the daily driver where I actually “work” : this is desk where I dissect, analyse, reconstruct and dispatch for usage across the above

Assume Competence

Following a recent realization that jargons are fun, experimenting with prompts that inform LLMs to talk in outlines and jargons, assuming the reader is competent. Producitvity is up.

.dotfiles commit for linked context : https://github.com/rajp152k/.dotfiles/commit/28dd1385cc4370dd0b15774bb96a661b3cab628f

You respond exclusively in highly concise, jargon-rich org-mode only outlines, without any bold or italics formatting: the reader is a competent expert with polymathic knowledge and exceptional contextual comprehension. Do not provide explanations unless asked for further simplifications; instead, communicate with precision and expect the reader to grasp complex concepts and implicit connections immediately. Do not use any filler sentences and collabaratively contribute in constructing whatever topic is being expanded upon

Blub in the Unix Philosophy

I’ve always maintained a philosophical appetite for the tooling that I use.

One of the core tenets of the Unix Philosophy1 is that everything is a file…

Plan92 has caught my eye due to its more homogenous design than the usual unix you’re used to.

The footnoted-paper (~pre-mature book) is somewhat unhinged and doesn’t shy away from taking a jab at the Unix ecosystem and design.

Apart from the several points the author makes, what stands out the most for me is the idea of everything truly being a file: in hindsight, Unix only realizes a fraction of the principle.

Bells & Whistles

I’ve started spending some time per day without the usual modern software engineering tooling (LLMs, the Internet, etc) to explicitly maintain my cyber-deduction skills (in the context of Unix-based systems (BSDs, Linux, yet to explore Plan9), mostly because they power the majority of the global compute infrastructure).

It’s fun: init your journey with a man man (I’m an info info guy myself) and be extremely skeptical of your usual modus operandi, ditching all assumptions and tumbling down the rabbit hole.

I wrote an Emacs Package

Fabric1 is a collection of crowd-sourced prompts, exposed via a CLI tool. I used it for a while some time ago but never fully exploited it because I prefer Emacs.

Eshell buffers are an option, but I am principled in my tool usage and prefer to delegate longer-running CLI tasks to a combination of Alacritty and Tmux.

Maintaining my Emacs shell usage to ephemeral popups feels natural.

Gptel2 is a versatile LLM client that integrates smoothly into my workflow (buffer/text manipulation and management) without disrupting my thought flow.

I'm using Monitors again

I’m using monitors again and it’s like consuming caffeine after a long time (last recorded usage circa mid November 2024).

I guess I need to cycle my dosage so that I don’t end up being too dependent.

I’m enjoying it though.

EDIT: as of <2025-01-27 17:50:30 IST>, I’ve given up again

Contextual .gitignores

A while ago, I had the strong desire to partition some of my professional work logs into mutually exclusive git repositories: with Blacklists and Whitelists flipped.

I was aware that the .gitignore could ignore stuff; today I found out that I can also whitelist stuff via that.

checkout 1 this stackoverflow question

So if the first .gitignore looks like

asdf-pattern 
more-asdf
some-absolute-asdf
dir-asdf/

the second one would look like:

# blacklist everything first
*

# unignore the directories to capture nested existences
!*/

# then your usual unignores
!asdf-pattern
!more-asdf
!some-absoluete-asdf
!dir-asdf/

What I wonder now is if git would allow for a branch-contextual .gitignore (named with certain protocols) so that I don’t have to maintain two different repositories altogether.