spiss.dev

Mike - Your Mic, Your Rules

2026-02-28T00:00:00+00:00

While working from home is nice and all, there is one thing that has been driving me absolutely insane: macOS resetting my default microphone. Every. Single. Time.</p>

Dock the laptop, and suddenly I'm on the built-in mic. Wake from sleep, built-in mic. Toggle the KVM switch, you guessed it. And it never happens before</em> the meeting starts - it's always mid-sentence, followed by the dreaded "hey, you sound different, are you on your laptop mic?".</p>

After one too many of those moments, I figured I'd just build something to fix it. And so Mike</a> was born - a tiny macOS menu bar app that enforces a user-defined microphone priority list.</p>
The idea is dead simple: you rank your mics in the order you prefer them, and Mike makes sure the highest-priority connected mic is always the system default. Plug in your good mic? Mike switches to it. Unplug it? Mike falls back to the next best option. macOS tries to override your choice after waking from sleep? Mike overrides it right back.</p>
</span></a> How It Works</h3>
Mike sits quietly in your menu bar and listens for CoreAudio device changes. Whenever something changes - a device connects, disconnects, or macOS decides to mess with your default - Mike runs through your priority list and picks the best available mic. No polling, no timers, just event-driven reactions.</p>
The whole thing is built with Swift and SwiftUI, targeting macOS 14+. Zero third-party dependencies. The CoreAudio interactions are behind a protocol, so the core logic is fully testable with mock hardware. The priority engine itself is a pure function - give it a list of preferred UIDs and a list of connected devices, and it tells you which one to use.</p>
brew</span> install</span> --cask</span> spissable/tap/mike </span></code></pre> That's it. A cat icon (in honor of a neighborhood cat called Mike) appears in your menu bar, you can right-click to reorder your mics, and you never think about it again.</p>
The source code is on GitHub</a>. MIT licensed, enjoy.</p>

One Year of Go

2025-07-29T00:00:00+00:00

While I'm sure there are more qualified people out there to give recommendations and suggestions on how to best get started with Go, there is one resource that I keep recommending to everyone: 100 Go Mistakes and How to Avoid Them </a>. I can't overstate how positive an influence this book has been for me and how much of a head start it gave me. Take this from someone who generally isn't too keen on reading technical books.</p>

Simplicity</strong>: Coming from Node.js/TypeScript where one codebase can look completely upside-down compared to the next, Go repos just look all the same</em>, relatively speaking. There is usually one idiomatic way of doing things, and the standard library gets you mostly there. Bye bye JS framework flavor of the week.</li>
Stability</strong>: I can barely remember the last time I had a Dependabot update and something actually broke. And when it did, it was a major version with relevant release notes. Go updates are painless, given the promise of no breaking changes.</li>
Improvements</strong>: After mentioning how stable something is, one could expect it comes at the expense of improvements being shipped. But it doesn't feel like that's the case. Shipped with Go 1.24</a>, there is now a great built-in way of dealing with tools, and with the upcoming 1.25 the synctest</a> feature is coming out of the "experimental phase"—just to mention a couple of awesome improvements.</li> </ul>

Zero Initialization</strong>: I'm sure some smart people have really good arguments about this. But so far I can't wrap my head around why this is the way to go (pun intended).</li>
Mocking</strong>: Writing interfaces for the sole purpose of having a way of mocking them—using a 3rd party package. I don't think I need to elaborate.</li>
Rawness</strong>: Some things could just use a fresh coat of paint to make them a bit more user-friendly right out of the box. One thing that comes to mind specifically is the go test</code> output. The raw out-of-the-box experience is just not good. Luckily there is the gotestsum</a> package.</li> </ul> </span></a> GopherCon EU 2025</h3> Finally, I also had the chance to visit GopherCon EU this year, and it's an experience I can wholeheartedly recommend. Lots of interesting talks, passionate people, and all in all just great vibes.</p>
My Tech Stack - 2025 Edition 2025-02-09T00:00:00+00:00 </p> </span></a> First, the hardware</h3> Work Laptop: 16" Macbook Pro M1 Pro</li> Home PC: Custom mini-itx desktop running Fedora Silverblue</li> Keyboard: Nuphy Air75 V2</li> Mouse: Razer Pro Click Mini</li> Mic: Blue Yeti Nano</li> Webcam: Razer Kiyo Pro</li> </ul> </span></a> Second, the software</h3> </span></a> Amethyst</a></h4> This is probably my most essential piece of software. As you would assume from reading my i3wm</a> blogpost, having a decent tiling window manager is essential for me. This amazing piece of open-source software works perfectly well for me, emulating most things that I was already used to before using macOS.</p> </span></a> VSCode</a></h4> This one is a bit of an odd one for me. I've been going back and forth between the Jetbrains IDEs and VSCode for many years at this point. While generally finding the Jetbrains experience more polished (e.g. running Go table test cases individually), at some point last year the debugger just stopped working altogether</a> with an update for me and my team, which made me switch over.</p> </span></a> TablePlus</a></h4> As someone who browses databases almost every day and is a sucker for a simple, clean UI, TablePlus is the perfect database client for me. Aside from that, the absolute killer feature is the "Safe-Mode", which, when enabled, asks for your password (the fingerprint sensor works on Mac as well) for every write operation.</p> </span></a> Podman</a></h4> As this has become the default already on Fedora, I figured I could also give it a try on the Macbook. And well, it just works and it's free. Nothing much else to add here to be honest.</p> </span></a> Firefox</a></h4> I have to admit, this is probably one of the pieces of software where I've become a bit old-school and resistant to change. I really don't need much from my browser. Pinned tabs, bookmarks and a healthy dose of privacy. That being said, I do really like the UX of the Arc Browser</a>, but the project seems to already have been abandoned by its creators. Perhaps the Zen Browser</a> will become the perfect mix of the two.</p> </span></a> Duck Goes AI</a></h4> While not being the hugest advocate of the AI/LLM trend, I found the frontend of Duckduckgo to be great. No log-in requirement, a selection of different language models and the promise of some privacy are everything I really need at this point. I'm sure I'll also use GitHub's Copilot more and more as well, but since last year has been the year of learning Go for me, I figured it's smarter to type your own code for a while until reaching a certain proficiency.</p> </span></a> Mos</a></h4> Last but not least, this little utility is a live saver for me. For whatever reason, you cannot have a different scroll direction for your trackpad and mouse in the macOS settings. Thanks to this tool, however, I have a peace of mind and don't need to flip settings whenever switching to the mouse inputs.</p> Domain-Driven Design - A personal tale 2024-09-20T00:00:00+00:00 </span></a> A little bit of backstory</h3> I’m a very pragmatic and hands-on person, for the better and for the worse. It probably originates from many different things, genetics, experiences and definitely my upbringing in a rural place with a difficult access to the internet.</p> Instead of Googling why our first family computer was acting up yet again, it was a long and painful troubleshooting process. Studying technical books always felt less appealing than simply hacking away on a hobby project, doing internships or quitting university and starting to work full-time.</p> </span></a> Learning on the job</h3> Learning on the job has been an amazing journey. Not only from a technical perspective, but I’ve also become an absolute sucker for domain knowledge.</p> Every time I started a new job, I found myself in a completely new domain. From smart home appliances, to waste logistics and finally the football industry. And if there is one thing that’s certain, it’s that I love sponging up all of this knowledge and putting it to good use.</p> </span></a> Hello DDD</h3> My first introduction to DDD was an interesting one. At the time, I was definitely one of the domain experts within the company relatively speaking, when a new colleague arrived.</p> Right from the beginning they had big plans. CQRS here, bounded context there… my head was spinning, but I was intrigued and asked question after question. Just to become more and more skeptical. Even the simplest things seemed to become so unnecessarily complicated.</p> So I blamed myself. Clearly, this person has more experience than me and is much more educated. I just don’t understand these concepts... yet.</p> </span></a> Learning DDD</h3> To combat my shortcomings, I decided to finally grab a book about DDD. Specifically I chose Learning Domain-Driven Design</a> whose reviews seemed to resonate much better with me, compared to “the blue book” and others. And boy oh boy did it resonate with me.</p> Instead of preaching a specific solution, the book, or rather its author Vlad, does an amazing job explaining how to make good decisions for yourself. How to choose a good solution out of different potential ones, depending on various heuristics and other factors. He doesn’t just say “it depends”, which is just an empty statement. But rather he explains on what it depends.</p> </span></a> Closing thoughts</h2> Having all the technical knowledge in the world, isn’t enough to make great decisions.</li> Having all the domain knowledge isn’t enough to make great decisions.</li> </ul> A sophisticated solution for a simple problem can be just as bad as a naive solution for a complex problem. At the end of the day, what matters is having great collaboration and being open minded.</p> And if you’re an expert in everything, you should probably look for a new challenge ;)</p> Go Snake - Having a little fun 2024-05-04T00:00:00+00:00 </span></a> The Game</h2> The game is a super simplistic version of the good ol' snake, written with the Go game engine Ebitengine</a> and compiled to WebAssembly, so you can enjoy it in its full glory right from this blog post.</p> </span></a> Some hot-keys:</h3> <Arrow keys></code> - Navigate the snake</li> <Esc></code> - Pause the game</li> <r></code> - Restart the game</li> <w></code> - Toggle walls on/off (only if you have 0 points)</li> </ul> P.S. You have to first click on the visible game area for the input keys to work.</p> </iframe> </div> </span></a> Conclusion</h3> It's really nothing fancy, but as someone who primarily learns by doing, it's a cool little project to hack on and get familiar with some Go concepts. Feels almost like high school again when I was first introduced to Java and programming in general and I started emulating some tiny games.</p> Fish Shell - 90s shell for a 90s kid 2023-11-18T00:00:00+00:00 </span></a> Backstory</h3> Many years ago, in the early days of my professional career, I remember looking over my on-boarding buddy's shoulders. What caught my eye was his terminal, which looked far different from the standard terminal running pure bash. This is how I got introduced to zsh</em> and ohmyzsh</em>.</p> Many config changes and installed plugins later, I was delighted with my shiny-looking terminal. However, as a chronic distro-hopper, I already started looking for other tools that I haven't heard about.</p> </span></a> Fish</h3> Soon I came across fish. I have to admit, I wasn't impressed by the website, but I was more than happy to look past that. And for the better. The main thing that struck me was the out-of-the-box experience. I had everything I ever wanted and more, without a single config change, or a single plugin. Some of these are:</p> Case insensitive auto-complete</li> Git integration</li> Responsiveness</li> </ul> The only real config changes that I eventually made were un-setting the greeting message:</p> set fish_greeting </span></code></pre> and adding a bunch of folders to the path:</p> set -gx PATH "$HOME/.cargo/bin" $PATH </span></code></pre> </span></a> A long boring time later</h3> And here I am now, in 2023, still completely happy with my fish shell experience. I guess it's just the right amount of features and old-school familiarity that has kept me happy for so long. Or perhaps I'm just getting old 😅.</p> That being said, I'm sure there are new shiny things on the horizon (like Warp</a>) that I'll give a try, especially now in the times of generative AI.</p> Jest Memory Leaks - some lessons learnt 2022-05-03T00:00:00+00:00 </span></a> Project Infos</h3> Nest.JS v8</li> Node.JS v14</li> ~800 unit tests using Jest</li> </ul> </span></a> The Build Up</h3> Every once in a while, the GitHub Actions pipeline would run out of memory during a test run. This is what it looked like:</p> <--- JS stacktrace ---> </span> </span>FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory </span></code></pre> While it didn't happen consistently, it was still becoming annoying enough. To make matters worse, a Node.JS update to v16 seemed to make the problem unbearable. Time to investigate 🕵🏽‍♂️.</p> </span></a> Node v16</h3> There seems to be a bug</a>, introduced with Node v16.11, causing memory leaks with Jest. While this bug is certainly putting my Node 16 update to a halt until it's resolved, the mentioned Github issue also gives quite some insight on how to debug these kinds of issues. Back to Node 14 🔙.</p> </span></a> Early Suspicions</h3> Some early ideas about what could be causing the issues were:</p> A bad jest/ts-jest/... package update</li> Jest-ts-auto-mock</a> as this is messing with the transformer</li> The setupFilesBeforeEnv</code> which I had added recently</li> </ul> In order to verify any assumptions and changes made, the following command was used to see if any memory was leaking:</p> node --expose-gc ./node_modules/.bin/jest --runInBand --logHeapUsage</code></p> </span></a> Going Back in Time</h3> In order to see if the problem has been happening for a while, just at a smaller scale, I went back to a commit some months ago and ran the above command. Turns out, back then everything was looking fine!</p> With that knowledge, I proceeded to test whether package updates are responsible for what's happening, but no luck there.</p> I figured I should try and pinpoint the exact commit where the problem started, but with the normal memory fluctuation, it was impossible to spot. To make matters even worse, there seems to be a different memory issue</a> when using the --runInBand</code> flag.</p> </span></a> detectLeaks Flag to the Rescue</h3> Thankfully there is yet another flag called --detectLeaks</code> which will force the garbage collection and fail the test suite if it detects any memory leak.</p> The updated command: node --expose-gc ./node_modules/.bin/jest --detectLeaks</code></p> Going back to the same "suspected-memory-leak-free-commit", this command proved exactly that. Jumping around commits "bisection" style, while running the leak detection every time, very quickly gave me the exact commit which turned every test suite red.</p> </span></a> setupFilesAfterEnv + nock</h3> Turns out, the issue was the following jest setup file which I introduced to globally disable any external HTTP requests in tests:</p> // jest.setup.ts </span>import </span>* </span>as </span>nock </span>from </span>'</span>nock</span>'; </span> </span>nock</span>.</span>disableNetConnect</span>(); </span>nock</span>.</span>enableNetConnect</span>('</span>127.0.0.1</span>') </span></code></pre> There is a section in the nock README</a> that describes that exact issue. There is also some more context linked there.</p> </span></a> Key lessons learnt</h3> RTFM</li> Run tests with --detectLeaks</code> flag, perhaps even in the CI to detect issues right away, instead of facing 5 different issues at the same time once it all bubbles up.</li> Try out newer transformers such as swc/jest or esbuild/jest for new projects.</li> </ul> Code-Server - taking the home office to the outside 2021-08-20T00:00:00+00:00 </span></a> The Challenge</h3> While iPads got the shiny new M1 processor and therefore loads of processing power, the coding experience is still pretty much nonexistent, due to the software limitations of iPadOS. And that's where code-server</a> comes into play:</p> Run VS Code on any machine anywhere and access it in the browser.</p> </blockquote> Sounds perfect for my use case!</p> Below are some of the key steps I had to take to make it all work. However, this is not a detailed step-by-step guide.</p> </span></a> Setting up Code-Server</h3> The code-server is available via the AUR for Arch Linux users at AUR link</a>.</p> Once installed, the actual setup is pretty easy.</p> $ cat ~/.config/code-server/config.yaml </span> </span>bind-addr: 0.0.0.0:1897 </span>auth: password </span>password: XXXXXXXXXX </span>cert: false </span></code></pre> $ sudo systemctl edit --full code-server@USER </span> </span>... </span>ExecStart=/usr/bin/code-server --proxy-domain *.XXXXXXXXXX.spiss.dev </span>... </span></code></pre> </span></a> Setting up Caddy</h3> As the code-server docs suggest, I decided to go for Caddy as my reverse proxy. This made the next part of the set-up pretty easy as well. The only sort of annoying part was that I couldn't use the caddy package from the Arch repo, but I had to compile it from source together with the Route 53 plugin, which I use to manage my domain. See the GitHub Repo for more details: GitHub link</a></p> Once installed, I added this config file:</p> $ cat /etc/caddy/Caddyfile </span> </span>XXXXXXXXXX.spiss.dev *.XXXXXXXXXX.spiss.dev { </span> tls { </span> dns route53 { </span> max_retries 10 </span> } </span> } </span> </span> reverse_proxy 127.0.0.1:1897 </span>} </span></code></pre> In order for Caddy to obtain a wildcard</strong> SSL certificate, I had to add a user who is allowed to manage my Route 53. See the GitHub repo for more details: GitHub link</a></p> $ sudo systemctl edit --full caddy.service </span> </span>... </span>[Service] </span>Environment=AWS_ACCESS_KEY_ID=XXXXXXXXXX </span>Environment=AWS_SECRET_ACCESS_KEY=XXXXXXXXXX </span>... </span></code></pre> </span></a> Setting up the Router</h3> Almost done, phew. After starting all the necessary systemd services, this should be the first time a beautiful VS Code window is accessible on the iPad, but only on the same network. Because I wanted to go outside my WI-FI range, I still had to open the 443 port on my router. Kinda scary, but code-server got us covered by blocking too many wrong password attempts. Since this is very router-dependent, I'll let you figure that one out. It's probably a good time to configure a firewall on your PC as well.</p> </span></a> DynDNS</h3> Everything is working now, and if you have a static IP, you're done. Since my ISP doesn't give me one, I still had to configure some kind of DynDNS service to keep my IP address up-to-date in Route 53. To achieve this, I configured yet another systemd service: GitHub link</a></p> </span></a> Et Voilà</h3> Using the power of my desktop PC right from the browser, including forwarding of locally hosted web services. In fact, I wrote this whole blog post on my iPad via code-server on my PC. The locally running 0.0.0.0:1111</code> Zola site was automatically served via 1111.XXXXXXXXXX.spiss.dev</code> behind the same password protection. And nowadays, I even find myself connecting to the code-server from my Dell XPS 13, as the Desktop PC is just way more powerful, especially when compiling large Rust projects ;)</p> </div> Arch Linux - it's really not that complicated 2020-07-23T00:00:00+00:00 </span></a> Overview</h3> 2 partitions: boot (fat32), root (f2fs - encrypted)</li> Bootloader: Systemd-boot (formerly gummiboot)</li> Desktop Environment: Gnome</li> </ul> Please also consult the official Arch Linux Documentation</a>. The step-by-step instructions can also be found on my Github</a>.</p> </span></a> Enter BIOS with F2 and configure:</h3> "System Configuration" > "SATA Operation": "AHCI"</li> "Secure Boot" > "Secure Boot Enable": "Disabled"</li> </ul> </span></a> Boot from USB</h3> Make sure to boot from USB using UEFI - this is required by systemd-boot!</strong></p> </span></a> Set the desired keymap</h3> loadkeys en_US-utf8</code></p> </span></a> (Optional) Connect to wifi</h3> wifi-menu</code></p> Once done it can take some seconds - confirm it worked using ping</em></p> ping 1.1.1.1</code></p> </span></a> Sync clock</h3> timedatectl set-ntp true</code></p> </span></a> Create two partitions:</h3> 1000MB EFI partition with hex code ef00</strong></li> 100% Linux partition (to be encrypted) with hex code 8300</strong></li> </ul> CAUTION</strong> Find the correct disk/partition names for yourself using lsblk</code>. From here on I am using mine as an example. Do not blindly copy and paste these, it might not work or you might destroy partitions you don't want to destroy.</p> cgdisk /dev/nvme0n1</code></p> </span></a> (Optional) Install f2fs-tools</h3> pacman -S f2fs-tools</code></p> </span></a> Formatting and encryption</h3> Boot</strong> partition</p> mkfs.fat -F32 /dev/nvme0n1p1</code></p> Root</strong> partition</p> cryptsetup luksFormat --type=luks2 /dev/nvme0n1p2</code></p> cryptsetup open /dev/nvme0n1p2 luks</code></p> (choose filesystem - assuming f2fs)</p> mkfs.f2fs -l luks /dev/mapper/luks</code></p> </span></a> Mount root and boot partition</h3> mount /dev/mapper/luks /mnt</code></p> mkdir -p /mnt/boot</code></p> mount /dev/nvme0n1p1 /mnt/boot</code></p> </span></a> Change Pacman mirror priority, move the closer mirrors to the top</h3> vim /etc/pacman.d/mirrorlist</code></p> </span></a> Install the base system plus a few extra packages</h3> f2fs-tools is needed if you chose f2fs as your partition</strong></p> With some recent XPS Laptops linux-zen seems to be working better, e.g. resolves screen flickering issues</strong></p> pacstrap /mnt base linux linux-firmware zsh vim git sudo efibootmgr wpa_supplicant </span>dialog iw f2fs-tools </span></code></pre> </span></a> Generate fstab</h3> genfstab -L /mnt >> /mnt/etc/fstab</code></p> </span></a> Enter the new system</h3> arch-chroot /mnt</code></p> </span></a> Setup time</h3> rm /etc/localtime</code></p> ln -s /usr/share/zoneinfo/Europe/Berlin /etc/localtime</code></p> hwclock --systohc</code></p> </span></a> Generate required locales</h3> vim /etc/locale.gen</code></p> locale-gen</code></p> </span></a> Set the desired locale</h3> echo 'LANG=en_US.UTF-8' > /etc/locale.conf</code></p> </span></a> Set desired keymap and font</h3> echo 'KEYMAP=us' > /etc/vconsole.conf</code></p> </span></a> Set the hostname</h3> echo '<hostname>' > /etc/hostname</code></p> </span></a> Add hostname to /etc/hosts:</h3> vim /etc/hosts</code></p> 127.0.0.1 localhost </span>::1 localhost </span>127.0.1.1 <hostname>.localdomain <hostname> </span></code></pre> </span></a> Set password for root</h3> passwd</code></p> </span></a> Add real user</h3> useradd -m -g users -G wheel -s /bin/zsh <username></code></p> passwd <username></code></p> echo '<username> ALL=(ALL) ALL' > /etc/sudoers.d/<username></code></p> </span></a> Configure mkinitcpio with modules needed for the initrd image</h3> vim /etc/mkinitcpio.conf</code></p> # Optional - for f2fs module crypto-crc32 is required however </span>MODULES=(crypto-crc32) </span> </span># Important - Use the correct order </span>HOOKS=(base systemd autodetect modconf block keyboard sd-vconsole sd-encrypt filesystems) </span></code></pre> </span></a> Regenerate the initrd image</h3> mkinitcpio -P</code></p> </span></a> Setup systemd-boot</h3> bootctl --path=/boot install</code></p> </span></a> Enable Intel microcode updates</h3> (For AMD replace intel-ucode</strong> with amd-ucode</strong> in every step that follows)</p> pacman -S intel-ucode</code></p> </span></a> Create bootloader entry</h3> Get luks-uuid with:</p> cryptsetup luksUUID /dev/nvme0n1p2</code></p> Create the entry:</p> vim /boot/loader/entries/arch.conf</code></p> title Arch Linux </span>linux /vmlinuz-linux </span>initrd /intel-ucode.img </span>initrd /initramfs-linux.img </span>options rw luks.uuid=<uuid> luks.name=<uuid>=luks root=/dev/mapper/luks </span></code></pre> </span></a> Set default bootloader entry</h3> vim /boot/loader/loader.conf</code></p> default arch </span></code></pre> </span></a> (Optional) - Setup Gnome</h3> pacman -S gnome</code></p> systemctl enable gdm</code></p> </span></a> Exit, unmount and reboot</h3> exit</code></p> umount -R /mnt</code></p> reboot</code></p> Giving Clear Linux a try 2020-03-01T00:00:00+00:00 </span></a> Installation</h3> The installation experience was very straightforward, similar to the one of Ubuntu I'd say. The graphical interface leaves next to no room for mistakes and presents you with a ready-to-go system with just a few clicks.</p> The only thing I was missing was F2FS (Flash-Friendly File System) support, which is my preferred filesystem. However, at the time of my writing this post, a pull request adding support for it has been merged</a>.</p> </span></a> The Good</h3> The very first thing I noticed when booting Clear Linux, was the boot process itself. It is blazing fast</em>! Despite full root encryption. I also found confirmation of that impression here</a>.</p> Since the default desktop environment of the distro is Gnome, I was then greeted by the Gnome Desktop Manager. A choice I very much support, as Gnome gives a very complete desktop experience in my opinion, including support for X11 and Wayland.</p> Last but not least, all the software I installed was up-to-date, which is one of the big promises on the distro's website.</p> </span></a> The Bad</h3> While the software I installed was up-to-date, it still cost me quite some frustration. Clear Linux offers a lot of its packages in bundles, e.g. the desktop-dev bundle, which includes lots of different packages that you might need or might not. As for me, I prefer being in control of what is being installed, rather than having to get a whole bundle of things of which half of it is useless to me.</p> Another packaging format that is supported is Flatpak</a>. A containerized, distribution-independent packaging format that claims to be "The Future Of Apps On Linux." As they offer Visual Studio Code, which is my main code editor, I gave it a try. The first problem, the integrated terminal was not working as I was used to. The Z shell didn't respect my config files, certain executables weren't usable... and I am not the only one</a>.</p> Last but not least, only 1 week into the experiment, my Gnome Wayland setup didn't load anymore, instead, I was greeted with a black screen on log-in. The X11 variant still worked though, so I tried to repair it from there. However, attempt after attempt the frustration grew bigger and bigger and I needed my system to be reliable at work, so I just decided to pull the plug and re-install the trusted Arch Linux.</p> </span></a> Conclusion</h3> I am still glad I gave Clear Linux a try and despite the problems that I faced, I am still very impressed with how far this very young distro has come. The performance is astonishing, and I hope other distros can integrate some of Clear Linux's patches. I can't wait to try out the next up-and-coming distro, whichever it might be.</p> i3wm - the world of tiling window managers 2019-05-25T00:00:00+00:00 </span></a> Floating vs. Tiling</h3> The window manager landscape for the Linux ecosystem is quite crowded. Major names like Gnome, KDE or XFCE satisfy most users' needs and give a lot of room for customization. One feature that unites them is, that they are all floating window managers. It's the concept of dragging windows around freely (mostly with your mouse), which probably everyone is familiar with from using Windows or MacOS.</p> On the other side, there are tiling window managers like i3, awesome or herbstluft, just to name a few. They are way less popular amongst the average user, but the concept of automatically tiling windows by default, not just helps you to stay organized, but enforces it. And once you get accustomed to it, you'll find your workflow to be vastly improved in speed.</p> </span></a> i3wm</h3> i3wm has been my window manager of choice for some years now whenever I'm working on a Linux machine. Initially, I encountered it during a presentation at the university. I had been using Linux for years at that point, but I wasn't familiar with the concept of tiling window managers. Clearly impressed, I installed it right away and well... it was a game changer. A few of the main features (for me):</p> Tiling (duh.)</li> Binding applications to workspaces</li> Horizontal / Vertical / Tabbed / Stacked / Floating</li> Configuration in a single config file</li> </ul> </span></a> Binding applications to workspaces</h3> In order to stay truly organized in a tiling window manager environment, it's quite fundamental that your windows open in pre-defined workspaces. Otherwise, your screen would become really crowded, really fast. This is how I organize my workspaces:</p> 1: Browsers</p> 2: Editors</p> 3: Terminals</p> 4: Communication</p> 5: Music</p> Scratchpad: Notes</p> With this setup, I got my everyday needs covered. It became second nature to me and going back to any other window manager without this feature (which I occasionally do, because I love to experiment) is just a pain in the ass.</p> </span></a> Configuration</h3> All keybinds, workspaces etc. are configured in one config file (~/.config/i3/config). While this might be a little bit intimidating at first, it becomes more and more advantageous with time. i3 has great documentation for beginners, making it quite easy to tailor the window manager the way you like it. And once configured, you can just backup your configuration file and have it ready whenever you decide to install a new OS.</p> </span></a> Additional tools</h3> Polybar:</strong> Alternative, feature-rich and beautiful status bar</p> Rofi:</strong> Application launcher, window switcher and much more</p> Udev rule + systemd service + bash script:</strong> to properly manage monitor hotplug</p> </span></a> Helpful resources</h3> i3 documentation</a></p> Sway (Wayland implementation of i3)</a></p> Subreddit for inspiration</a></p> My dotfiles</a></p>

The game is a super simplistic version of the good ol' snake, written with the Go game engine Ebitengine</a> and compiled to WebAssembly, so you can enjoy it in its full glory right from this blog post.</p>

That being said, I'm sure there are new shiny things on the horizon (like Warp</a>) that I'll give a try, especially now in the times of generative AI.</p>

There seems to be a bug</a>, introduced with Node v16.11, causing memory leaks with Jest. While this bug is certainly putting my Node 16 update to a halt until it's resolved, the mentioned Github issue also gives quite some insight on how to debug these kinds of issues. Back to Node 14 🔙.</p>

Everything is working now, and if you have a static IP, you're done. Since my ISP doesn't give me one, I still had to configure some kind of DynDNS service to keep my IP address up-to-date in Route 53. To achieve this, I configured yet another systemd service: GitHub link</a></p>

`default arch </span></code></pre></span></a> (Optional) - Setup Gnome</h3> pacman -S gnome</code></p> systemctl enable gdm</code></p> </span></a> Exit, unmount and reboot</h3> exit</code></p> umount -R /mnt</code></p> reboot</code></p>`

`</span></a> Exit, unmount and reboot</h3> exit</code></p> umount -R /mnt</code></p> reboot</code></p>`

`</span></a> Exit, unmount and reboot</h3> exit</code></p> umount -R /mnt</code></p> reboot</code></p>`

The only thing I was missing was F2FS (Flash-Friendly File System) support, which is my preferred filesystem. However, at the time of my writing this post, a pull request adding support for it has been merged</a>.</p>

i3 documentation</a></p>
Sway (Wayland implementation of i3)</a></p>
Subreddit for inspiration</a></p>
My dotfiles</a></p>

i3 documentation</a></p>
Sway (Wayland implementation of i3)</a></p>
Subreddit for inspiration</a></p>
My dotfiles</a></p>

spiss.dev

Mike - Your Mic, Your Rules

The source code is on GitHub</a>. MIT licensed, enjoy.</p>

One Year of Go

My Tech Stack - 2025 Edition

Domain-Driven Design - A personal tale

Go Snake - Having a little fun

Fish Shell - 90s shell for a 90s kid

Jest Memory Leaks - some lessons learnt

Code-Server - taking the home office to the outside

Arch Linux - it's really not that complicated

Giving Clear Linux a try

i3wm - the world of tiling window managers