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?
Why is automatically starting a process so difficult and different from platform to platform?
In nearly every case, there are processes or services that I want launched on boot. Many of these services do have methods for automatically starting, but they only consider themselves and not the environment that they'll exist within.
Came across Caddy (v2) recently and took the time to take a peek at what it can really do for me. After gawking at its landing page posters for awhile, I've come up with several use cases I want to put Caddy through to see if it really is the haproxy/nginx/traefik app killer that I've been looking for.
In short, I've been using Tailscale, but it drains my battery when I leave it enabled on my phone but I need access to my network for nightly backups. VMWare Workstation 17 (on Windows 11) has a pretty bad UX for networking. That said, its the lesser of problematic hypervisors, so its my poison of choice. Recently I had a requirement to make the networking behave more deterministically.
test
Due to the metric driven corporations like Microsoft, Google, and Apple, two-factor authentication has become a sort of an infection. While most of the 1st world's population will benefit by the increased security of 2FA, it remains a fact that there are a significant number of folks that will be left behind due to the fact that they don't have smart phones or access to smart phones at the point of authentication.
Recently resolved a long standing issue with my k3s implementation that was causing many DNS issues within my setup whenever the system restarted (usually due to automatically nightly patching). It was all due to the way that k3s cleverly injects "host names" into the K8s controller node's coredns service. This could be nice if it wasn't a namespace conflict where it was injecting k8s and k8s.vinnie.work.