I had a need to parse only the beginning preview of a set of large JSON files (e.g. safetensors). I wanted the ability to parse this JSON, to:
Alas, most json libraries do want the whole JSON. After a bit of work, I was able to get it going with ijson.
As of late, I've been attempting to catch up with the flurry of new developer tools that now exists. Many of the TUI tools are golang or rust and therefore have nice portable static versions. This means one single binary that has all the things I need to use the tool. It goes in my ~/.local/bin and that is that (presuming you aren't ricing in catppuccin).
Now tmux and nvim are central to all of this portability and yet they remain relatively non-portable and are themselves written in C and C++ respectively. I'd like to fix this.
Lots of network applications stopped working in my developer virtual machine but would work within containers on the same VM. The network stack was working, the firewall didn't look weird ... what the heck?
Recently I decided to revisit some of my staple habits and tools for development. This included the question, "What is the new generation using for console text editing?". I was under the naive perception that most are using nano because most are likely using a GUI IDE like VSCode or XCode as their work horse and there is little reason to bother with the likes of emacs and vim anymore. Apparently, this was grossly wrong ...
My home network is now no less than 22 network nodes. Because of this, I've long since passed the feasibility of using only DHCP. When things go wrong, I want to troubleshoot from an IP, not a hostname. Therefore I've set static IP addresses for all of the long running network nodes. (Things like the xbox and cell phones are still DHCP).
Trouble is, this isn't as straight forward as I'd like it to be in Debian (specifically Bookworm).
Ever have a list of files in the side bar of VSCode that was unearthly long? It can get really annoying having to scroll up and down through that list to trace through some control flow of a program or multi-micro-service application. One possible solution for that is the IPC mechanism built into VSCode from the CLI. At any point in your VSCode terminals, you can run code <path> to open a file in the running VSCode.
But it doesn't work in Tmux! ... well I found a fix.
Recently I've been working on revamping my home lab setup with some more dedicated hardware and I've been replacing a lot of custom scripts and processes with more or less industry standard workflows (e.g. Runners, K8s, Flux).
In doing this, I've really learned that it is not trivial to setup a complete tech stack for GitOps/DevOps at home. Many tools, like Flux, with provide documentation or demos on setting up their system for only the simplest cases, and those cases will usually involve some cloud service like Github or Dockerhub to handle a bunch of the configuration.
It has long been normal to embed some blob of data into the end of a shell script that is implemented as a self-extracting tar file. I've used varying methods of this over the years, but I recently started seeing Segmentation Faults when creating files over 2G.
Finding a way to SCP Baulder's Gate 3 saves took me roughly 15 minutes to figure out, but wow, that's to long to learn how to copy a file. :) Leaving a bread crumb here for this weird SCP use case.
In every situation where I've wanted to monitor a device's packets for troubleshooting or analysis purposes in the past 25 years, I've always listened to a single interface that I knew the packets were traversing. This works great for completely controlled environments in short bursts, but what if you wanted to provide some guarentees that all packets leaving the monitor were being captured?
In otherwords, what is the cost of analysis when packets are permitted to traverse the network without you knowing about them? How do we prevent this?