I've had a lot of bad experiences with snap. For a time, it drove me to pure Debian. Debian of course has its own issues, especially in regards to hardware support. Therefore I've switched back to Ubuntu, critically WITHOUT snap.

The synopsis is:

# See the impact before removal. (Know what needs to be replaced.)
snap list

# Tell snap to remove all the things it manages.
snap remove --purge <snap-name>

# Stop snap services (and prevent anything from restarting them).
systemctl stop snapd
systemctl disable snapd
systemctl mask snapd
systemctl stop snapd.socket
systemctl disable snapd.socket
systemctl mask snapd.socket

# Remove snap from the system (and prevent anything from re-installing).
apt purge snapd
apt autoremove
apt-mark hold snapd

Recently, I've been reading up on MicroVMs. I've been a long time user of QEMU for its flexibility and open nature. You can run KVM machines with near-native performance as well as emulate completely foreign architectures on an x86 (64-bit) based architecture. Its open source nature also allows developers to tailor feature sets and add new machine configurations within it framework. All good things, right?

Apparently this hasn't been good enough for Amazon because they've been developing and maintaining their own hypervisor called Firecracker. It boast fast loading times and security, but I call bullshit on all the review articles because they don't seem to know what is really happening within. What is Firecracker really?

Disclaimer: I'm writing this article based on my "general knowledge" of hypervisor technology. Not a thorough set of experiments and results.

Coming from a strong C/C++ background, I have been a big user of make as a project action manager. Since most of my projects are no longer C/C++, I've migrated away from using make. Instead, I generally will lean in on the ecosystem of the project I am using (e.g. packages.js commands for Javascript/Typescript projects or setup.py for Python projects).

For projects that don't have a straight forward project action manager I've established a do file pattern. The do file is always committed along side the project code itself for maximum portability (i.e. binaries are discouraged). You can think of do as a black box action interface that behaves like make:

• do build
• do run
• do deploy

In practice, the do script is a BASH script, but I think we can do better...

Perusing Reddit​

As I'm sure many other do, I peruse reddit for current events, curiousities, and new things to discover. One habbit I have is to see a new tool that looks like it could remotely apply to some use case I've encountered in my past and then I'll share it to myself in a chat application. The hope here is that I'll actually go back and look more into it when I have time. As you can probably guess, that chat stream gets ever longer without me ever going back and checking on the entries.

Because I've found some extra time Thanksgiving morning to go back through the list a bit, I've taken a bit of a dive into Dark-Alex-17's dtools repository as advertised in this reddit post. Its yet another toolbox repo that's been tailored to a specific engineer's experience and use cases. I very much appreciate this kind of thing because it's like rummaging through a physical workshop and finding all of the tools and things that you may not have know about, or in my case I usually find things I've seen in passing, but now get extra points for being used in the wild.

Wayland Rant​

What do you mean I have no control over what my applications identify as?! The Wayland developers don't get it. They are the reason Linux Desktop still struggles. I don't care what security strides or modern GPU support they've developed. When you get in the way of an entire community from meeting minimal standard usability, you've created a negative product that might feel good, but degrades the community in the same way controlled substance tear apart families. Its bad for society, organizations, and the future. Their choice to block window managers from doing actual window management is pitful, short sighted, and an utter failure of synapses. Without going into details, we have to go great lengths to attempt to save and restore windows states for even the most simple situations. Rant Over

Overview​

One simple work around for managing Window Rules in KDE-Plasma6-Wayland (for multi-instance applications) is to treat the Window Rules as a dynamic thing. The idea here is to add some metadata to the Window Rules themselves. Then when we want to launch a specific application with specific rules, we reconfigure the Window Rules temporarily, launch the application, and then revert the Window Rules back to their original state. This feels and is ridiculous, but Wayland ridiculous decision breed ridiculous solutions.

In Interactive Consoles/REPLs of Python, I wrote about some pains with dropping into a useable REPL from anywhere in my code. Hoping code.interact() would just work failed me, so I started down the path of writing a simple REPL that would allow me to copy/paste arbitrary python code (including code with multi-line pastes).

I even went as far as developing an await-able version, but it was really only a synchronous function masquerading as an async function. And to make matters worse, we still could not await in the REPL itself.

All things to fix now!

Recently I've been developing some debugging utilities in python. Due to a number of desires to have multiple ways of interfacing with these tools, I've gone down a number of rabbit holes in how the internals of Python work. One such rabbit how is in regards to the interactive console or REPL. Note: REPL is a "read-eval_exec-print loop". I use console and REPL interchangeably.

As most know, when you start python without any parameters it drops into a interactive console:

Python 3.13.5 (main, Jun 25 2025, 18:55:22) [GCC 14.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>>

When you type a (single-line) command in the terminal, it completes.

>>> print("text here")
text here
>>>

Now, the print("text here") code above is considered a complete block (or a complete expression). Python was able to confidently assume that your command was complete and it could be run. But what if we're doing a multi-line function?

>>> def func():
...     print("first")
...     print("second")
...

The console will change the prompt to indicate that there is a continuance of the current python code block. The console will not run until it can assume that you are done with your code block. This assumption is based on the empty line at the end. Ok, great, but what about functions that have newlines in the middle of them? For example, what happens if you copy the following into an interactive python console? For example:

def func():
    print("first")

    print("second")

Magic!

Overview​

For awhile now, but not always, I've been getting chan_shutdown_read: channel 1: shutdown() failed for fd 7 [i0 o0]: Not a socket on my terminal whenever I do something with SSH. This include ssh, scp, and git commands. It'll often obscure the password prompt at the bottom of the terminal screen.

Overview​

Been using neovim more in recent months. I think its a great replacement for vim, but it suffers greatly because all its modern bells and whistles also require an internet connection. I'm not a fan of this. To make matters worse, it has a great many external dependencies.

Overview​

Code snippet of 3 python files:

• EnhancedConsole - a simple extension of InteractiveConsole for hosting REPL in server and client code.
• Server - A simple example of using multiprocessing.managers over Unix sockets and running with a REPL.
• Client - A simple exmaple of using multiprocessing.managers (as a client) over Unix sockers and running with a REPL.