Background​

Recently I moved into a new home. Excitedly, I went to sign up for the new fibre hotness in the area (with 1 Gbps download speeds). In the mean time, I purchased a 4G router that allowed be to supply my house with internet via a cell phone SIM card (i.e. ~ 10-20 Mbps). My scheduled appointment for the super fast internet was about 2 weeks later. Finally, the guys show up to run the fibre line! After observing that they were waiting around outside (by the pole) for about 2 hours, I went to go check on what was happening. In the end they made the determination that they could not install fibre internet for me because the pole was too rotten. Argh!

Background​

When using Docker, you have the "dockerd host" (i.e. the platform managing the containers) and you have the running containers. Each container has a localhost and the "dockerd host" has its own localhost. Whether you use --network host or not, you can not use localhost to communicate between the "dockerd host" and the container.

Overview​

I've been developing an app for the past couple years. Over that time I've seen some pretty drastic changes within the Expo eco-system and how they manage workflows (usually for the better). Following a recent update to Expo SDK 46, I simply could not escape an issue with the react-native-gesture-handler not being found. For all the amazing feats that Expo has accomplished to simplify mobile development, the attention to detail in their documentation leaves much to be desired.

Background​

Docker squashing is something that has been around for awhile. For those not in the know, when you create a Docker image it layers each of the commands in the Dockerfile into their own filesystem overlay. The aggregate of these overlays are what you containers starts with.

Now, when you have vary large files getting downloaded into the build process of an image, you can find yourself with a very bloated image. Squashing is generally the solution here.

Background​

Sometimes I find myself having to do development in corporate environments where you aren't given administrative privileges to the machine at your desk. I know that many would make certain hand gestures at such a situation and walk away. But sometimes the problems that the corporate overlords are paying you to solve is just to interesting to walk away. In that case, you find ways to work with the cards you've been dealt.

For years now I've stuck a Visual Studio Code shortcut in my Startup folder (Win+r -> shell:startup). This way, when I login to my Windows machine, VSCode simply will pop up with my previous workspace state. When you work with multiple different Remote-SSH host windows all within a virtual environment that resets when you logout you need more than just a shortcut.

Background​

I've been running this blog since the beginning of 2020 in one manner or another. The largest gap and travesty that I've left unattended is the fact that there is no chat capability built in. About 6 months ago I did try to implement my own thing with a DigitalOcean droplet and a postgres database. It didn't work well and involved nasty iframes in my React app. I just didn't have the time to invest.

With the now fully released Docusaurus 2.x (the engine this blog is currently using), I decided to see if there were any new options for comment integration. With minimal forum reading I came across a GitHub app called Giscus, and it was exactly what I wanted!

Background​

Ever find yourself attempting to look up some esoteric part datasheet or source code library that only has documentation in a foreign language that you don't know? I do!

Often you can just drop the PDF into Google Translate and all will be well enough. But if you want more control, more fine grained translating, or just less tracking of your behavor in google, you can do it via Python.

Situation​

Bottom line, ifconfig has finally reached a point of scarcity that I feel I need to switch to the heir apparent iproute2. So often do I get on an isolated network that doesn't have basic tools like ifconfig, route, or vconfig and because of the environment, my workaround apt install net-tools isn't always available.

Problem​

When building from source code in Linux (or any *nix) based system, you'll often run into a web of other dependencies that you need to cherry pick from the internet. If you are required to use an older version of a package, its wise to use dependencies that were released just before the source code your are attempting to download. Even if the API for the dependency is still technically compatible, there are also many other factors that can ruin your day.

Static builds, technically linking of binaries in such a way that there is no dynamic loading of external libraries to start the process. A more broad way that I prefer to think of static applications are ones that have no external userspace dependencies. One may argue that my definition of a static application could be a docker container. Not true! A docker container depends on docker (i.e. an external userspace dependency).

Periodically I become a bit obsessed with static building and linking of various tools. These tools can be invaluable with performing troubleshooting of niche systems where you can't depend on the system's ability to accomplish what you need to analyze or debug issues. The catch is that classical unix philosophy has encouraged maximization of shared libraries and dynamic linking. This creates tight couplings between applications and their distributions. Linus has spoken about this coupling and the weaknesses that it brings into the Linux ecosystem.

There are quite a few projects that attempt to mitigate this issues. Let's explore some of these ...