Jack K

To Manage: verb

2025-10-02T00:00:00+00:00

I used to have a manager
I've been thinking since he went.
Of how he made an impact,
and what "to manage" meant.

Most all start with aversion,
in the field of tech and cloud.
Hear of colleagues micro-managed;
at work they are not proud.

I'm thankful to have faced
cultures true and good.
Encouraged, helped, and guided,
they've managed as they should.

From this I've grown perspective,
on what "to manage" means.
And though we are still techie,
we are not just mere machines.

As my career develops,
and my duty further grows.
From those whom I've been managed,
my approach I have now chose.

I will now look back fondly,
of time together spent.
I believe I have a better grasp
of what "to manage" meant.

- Jack K

Thank you Carl, David, Izzy, Jon, Steve, Rhyddian, and Alan.

Nix in the Shell

2025-08-20T00:00:00+00:00

So, maybe you read the previous installment</a> on what Nix is; or you just want to get stuck in with Nix. As long as you've installed Nix or can run it in a container we can get started.
Table of Contents

A Basic Shell</a>

shell.nix</code> Annotated</a></li> </ul> </li>
Pinning our copy of nixpkgs</code></a></li>
Adding Proprietary Tooling</a></li>
Graphical Tools</a></li>
Conclusion</a></li> </ul> A Basic Shell For this example I'll be using flakes and the new cli. (If you'd like to learn more about flakes vs before flakes, there will be a future blog post.) For now you can try follow the steps below, and if you get a warning you need "Experimental features" and aren't interested in enabling them in your configuration, just add --extra-experimental-features "nix-command flakes"</code> after nix</code>. Our basic minimal shell.nix</code> file can appear like so: { pkgs ? import <nixpkgs> {} }: pkgs.mkShell { packages = [ pkgs.protobuf pkgs.hadolint pkgs.nodejs ]; } </code></pre> At this point if you had this file and ran nix-shell</code> if you didn't have any of these tools, they'll now be available to you. And in the case of openssl</code> you'd have the libraries and headers. And if you did have them available you should find your current PATH</code> will pull the ones from the nix store. You can see this by running readlink -f $(which BINARY)</code>: $ readlink -f $(which protoc) /nix/store/82dkd41796gz81i8nqx70xjcajy32p3q-protobuf-31.1/bin/protoc-31.1.0 $ sha256sum $(which protoc) 92d2bf5ca23e8cdf3a39feb5433970e11b871874e3c44a0c636face2a3801843 /nix/store/82dkd41796gz81i8nqx70xjcajy32p3q-protobuf-31.1/bin/protoc </code></pre> shell.nix</code> Annotated For this guide we'll just make some simple tweaks, but if you're interested in what's going on here's an annotated version of the same file: # Overall this is a function. # # The output produced by "evaluating" and building the # output (AKA derivation) will match what `nix-shell` expects. # # It takes a `pkgs` argument with a default provided of # `import <nixpkgs> {}`. { pkgs ? # `import` is a way of calling other nix files. import # `<nixpkgs>` is a special syntax for refering to "channels" # you can define, think of them like aliases. # # And because the `default.nix` within the `nixpkgs` repository # is itself a function we provide an empty `{}` object. # In nix objects are called an "attribute set". <nixpkgs> {} }: # From `pkgs` we run the function `mkShell`. pkgs.mkShell # `mkShell` expects an attribute set where most # attributes/parameters are optional. { # Here we use the `packages` attribute to define what # to provide in the shell. packages = [ # and from `pkgs` we have access to # `protobuf`, `hadolint`, and `nodejs` pkgs.protobuf pkgs.hadolint pkgs.nodejs ]; } </code></pre> Pinning our copy of nixpkgs</code> With the simple shell.nix</code> if you run nix-shell</code> on an x86_64 Linux machine, and your friend runs the same nix-shell</code> command with the same shell.nix</code> you can still end up with different versions or copies of binaries. This can be demonstrated by the fact you probably have a different copy to me in my example above. To ensure you get not only the same version of protoc</code> e.g. 31.1.0</code> , but also the exact same file e.g. it lives in /nix/store/82dkd41796gz81i8nqx70xjcajy32p3q-protobuf-31.1/</code> and the same sha256sum</code> we'll want to do some "pinning" or "locking. This is basically standard practice now across ecosystems for package management. You may recognise files like package-lock.json</code>, go.sum</code>, Cargo.lock</code> etc. Lock files (to varying degrees of success) are intended to identify the exact same dependency every single time. We can do the same with our small shell.nix</code>: { pkgs ? import (builtins.fetchTarball { # Descriptive name to make the store path easier to identify name = "nixos-unstable-2025-08-19"; # Commit hash for nixos-unstable as of 2025-08-19 url = "https://github.com/nixos/nixpkgs/archive/20075955deac2583bb12f07151c2df830ef346b4.tar.gz"; # Hash obtained using `nix-prefetch-url --unpack <url>` sha256 = "1s3lxb33cwazlx72pygcbcc76bbgbhdil6q9bhqbzbjxj001zk0w"; }) {} }: pkgs.mkShell { packages = [ pkgs.protobuf pkgs.hadolint pkgs.nodejs ]; } </code></pre> Now we will always fetch the 20075955deac2583bb12f07151c2df830ef346b4</code> commit of NixOS/nixpkgs</code> (which was the current latest commit as of writing this post.) By forcing this exact commit we're ensuring that everything is the same for everyone who runs this. This inline and more manual method of handling our dependency on nixpkgs</code> can be difficult, especially if we want other remote nix code for overlays etc. This is one aspect where flakes can help, or you can look at projects like npins</code></a> which work with pre-flakes tooling like nix-shell</code>. You may also be wondering, should I use nixpkgs-unstable</code>, nixos-unstable</code>, nixos-25.05</code>, nixos-25.05-small</code>, etc. I plan to cover this in more detail in the future but for getting started any release should work. Just make sure when you're doing a search on https://search.nixos.org</a> you pick a matching release! Adding Proprietary tooling Some times you might need some proprietary tooling, which will also be called "unfree". For this example we'll use unrar</code>. The UnRAR license explicitly says it's "freeware" so better matches "source-avalable" licenses. It wouldn't be considered Free or Open Source because of it's section 2 relating to the proprietary RAR compression algorithm, and it's section 6 relating to deleting all "UnRAR files from your storage devices and cease to use the utility." (If you're interested in licenses and SPDX, it's actually yet to be reviewed</a>.) By default nixpkgs won't give access to "unfree" software as a saftey mechanism and to make "unfree" software opt-in. There are several ways to do this but if we'd like our choices to be preserved in shell.nix</code> we can do this: { pkgs ? import (builtins.fetchTarball { # Descriptive name to make the store path easier to identify name = "nixos-unstable-2025-08-19"; # Commit hash for nixos-unstable as of 2025-08-19 url = "https://github.com/nixos/nixpkgs/archive/20075955deac2583bb12f07151c2df830ef346b4.tar.gz"; # Hash obtained using `nix-prefetch-url --unpack <url>` sha256 = "1s3lxb33cwazlx72pygcbcc76bbgbhdil6q9bhqbzbjxj001zk0w"; }) { config.allowUnfree = true; # this addition } }: pkgs.mkShell { packages = [ pkgs.protobuf pkgs.hadolint pkgs.nodejs pkgs.unrar ]; } </code></pre> Providing config.allowUnfree = true;</code> when we import</code> nixpkgs</code> allows access to all packages marked "unfree". The same thing could have also been written like below: { config = { allowUnfree = true; } } </code></pre> If you'd like to be more granular you can instead provide a function to allowUnfreePredicate</code>. In this case our function can receive a pkg</code> and we can either allow it or deny it. In this case we're using the helper lib.getName</code> to pull the package's name, and we're using builtins.elem</code> to do that check against every string in our list. Currently with only "unrar"</code> but we could add other tooling as necessary. config.allowUnfreePredicate = pkg: builtins.elem (pkgs.lib.getName pkg) [ "unrar" ]; </code></pre> Graphical tools Graphical tooling can be a bit more difficult due to how graphics libraries and drivers work. On a NixOS machine there shouldn't be any problems, but on other systems you may get errors from OpenGL or Vulkan. That's where the nix-community/nixGL</a> project can help. But for graphical tooling outside of NixOS you may find it easier to stick with Flatpak on Linux, or Brew on Darwin/MacOS. Conclusion With these snippets we have enough to get a bunch of useful tooling, including the "unfree" stuff where necessary. Feel free to dot these files around and spread the shell.nix</code> file! (if your team is happy with it) And if cluttering up the root dir is a worry you can put it in a sub directory and run nix-shell ./some/subdir</code>! In a future post I'll cover doing some of this in a flake.nix</code>, and having the new stuff also be compatible with nix-shell</code>. I'll also touch on packaging tools from scratch!
So You've Heard of Nix 2025-08-01T00:00:00+00:00 Nix is a tool that's rapidly gaining popularity; it's something you may have heard of in passing conversation, or seen in threads and blogs online. But what actually is Nix? Like what does it actually do? How might it benefit your workflow; your day-to-day needs? I'd like to address some of the immediate benefits it can offer you as a new user, and also some aspirational cool things it can do which you may go on to use. Table of Contents: Quick Wins</a> Package Availability</a></li> Platform Coverage</a></li> Teams Use the Same Tools</a></li> </ul> </li> Trying Nix</a></li> Installing Nix</a></li> </ul> Quick Wins Package Availability Fundamentally nix is a package manager so the first aspect I'll focus on is the package availability. Using nix (and its package repository nixpkgs) you gain access to an enormous selection of packages. As tracked by https://repology.org</a> as of writing there are over 107k "packaged projects" available. That number alone isn't much use, so to put it in perspective: Arch with the AUR has 90k, Debian 39k, Fedora 24k, and Arch without the AUR has 11k. Now these raw numbers are interesting but it's also useful to look at the number of "non-unique packaged projects" too. By filtering out packages that are only seen in one repository we can track projects which multiple distributions have considered useful. This can be particularly important to avoid cases where additional packages are just a side-effect of correctly packaging a program. Nix is still in the lead with 85k (-20%), Arch with the AUR on 51k (-43%), Debian 29K (-27%) Fedora 22k (-10%), and Arch without the AUR still on 11K (-4%) Below is a graph of total packages on the X-Axis and "fresh" packages on the Y-Axis showing not only the amount of packages but also how up-to-date they are. Ideally you want a package repository that's not only far on the X-Axis for coverage, but as close to the Y-Axis (close to the darker grey area) as possible denoting how up-to-date it is. The nixpkgs repository quite literally sits in its own section of the graph. I'd also like to emphasise pure package availability and freshness isn't everything. Distributions like Debian with a lower package count benefit from being a curated list, wide user testing, and stability. But I'd also like to add as a nixpkgs maintainer I think it also has good measures in place to test packages such as running their unit-tests when building and even featuring End-to-End style tests with NixOS VMs</a> for important packages. Platform Coverage Nix can be used on almost any Linux environment and even on MacOS (Darwin), some usage on BSD and even minor usage on Windows. This wide coverage also extends to architectures. "x86_64-linux" is the best supported architecture but unlike many repositories "i686-linux" (aka 32bit machines) also receives support and cached builds. Then for SBC or Raspberry Pi fans there's also support for various ARM linux platforms like "aarch64-linux". For MacOS the new Apple silicon "aarch64-darwin" is supported for many packages but so is the older intel based "x86_64-darwin" allowing you to extend the life of your devices. There's also community work on more exotic platforms like "riscv64-linux". Teams Use the same tools Building upon the large package availability and the strong platform coverage when working with others you can all leverage the same tooling. For teams across Linux and MacOS there's the benefit of most tools being available to both platforms. Let's say we have a team of 4 using: Arch, Debian, MacOS, and NixOS and they're interested in using buf</code> for managing protobuf files. buf</code> is available for Arch in the official repos, MacOS in homebrew, and NixOS in nixpkgs. However it's not available in the Debian repos. Now in the case of buf</code> it's not too big a problem since go install</code> is quite easy to use so that can be the method for Debian. Your next concern might be that you're all on separate versions, updating at different rates. The plan might be to move everyone to using go install</code> to fetch the exact same version of buf</code>. This works quite well and you can even fix a version within your Makefile</code> or scripts to ensure it's all matching. This is easy enough but there are still some drawbacks. You have a minor wait for some quick go builds, there are sometimes additional steps beyond go install</code> for version information when you run --version</code>, additional libraries, etc. And this is purely looking at go</code> based projects. The moment you also need a python</code> project like pre-commit</code>, a node</code>/npm</code> based project like prettier</code>, or a haskell</code> based project like hadolint</code> you have to make all these decisions again. Another thought may be to use containers but you'll still be making the same decisions for which base distro, where to fetch the package from, whether to fetch the binary yourself (and of course check the sha256sum!). By just leveraging nix</code> the package maintainers will see to updates and following the correct build instructions. And for Libre and Open Source projects you get to leverage the cache for pre-built packages. Trying Nix If you're thinking nix</code> could help you simplify your work the next question is probably how to get access to nix</code>. I'd firstly recommend just playing with nix</code> inside of a container. It's published to the Docker Hub @ nixos/nix</code></a> and by mounting a directory or just trying things inside the container you can get an initial feel before installing it to your system. For what to try I'd recommend using the Search on NixOS.org</a> to find packages you're interested in. From there you can: Immediately run it Original nix-shell</code> syntax: nix-shell --run <PACKAGE></code></li> Newer syntax with flakes: nix run nixpkgs#<PACKAGE></code></li> </ul> </li> Make it available in a temporary shell Original nix-shell</code> syntax: nix-shell -p <PACKAGE></code></li> Newer syntax with flakes: nix shell nixpkgs#<PACKAGE></code></li> </ul> </li> Make its dependencies available if you have its source you want to build Original nix-shell</code> syntax: nix-shell -A <PACKAGE></code></li> Newer syntax with flakes: nix develop nixpkgs#<PACKAGE></code></li> </ul> </li> Add it to a list of packages you'd like as a "dev shell" for your project Original nix-shell</code>: create a shell.nix</code></a> and run nix-shell</code></li> Newer syntax with flakes: create a flake.nix</code></a> and run nix develop</code></li> </ul> </li> </ul> (If you're wondering whether you should use the original or newer syntax it's totally up to you! There are some out-of-the-box benefits to the flakes method but these can be replicated with additional tooling.) Installing Nix Once you're happy there are 3 main install methods: The scripts on the NixOS.org website</a></li> The installer created by Determinate Systems</a></li> Your distribution package manager</li> </ul> The first two options are both good and have their pros and cons. The third option I personally don't use but it's up to you. Anyway, welcome to the fold and thanks for reading! I plan to do a series on creating your own packages either for personal use, for your team, or to submit upstream to nixpkgs! KubeCon 2025 EU Review 2025-05-24T00:00:00+00:00 This year KubeCon was back in London, England, United Kingdom. The last KubeCon in London was in 2016 and in that 9 year gap the "Cloud-Native" ecosystem has grown signficantly. In 2016 London saw around 300 KubeCon attendees whereas 2025 had 12,500 which is over 4000% growth. The talks My goal for the conference was to avoid any talk with AI in the title. Upon talking with my colleagues I belive that was the right decision. Instead my focus was to deep dive on Controllers, refresh my knowledge, and ensure I'm tracking up-to-date methods and practices. My secondary goal was to attend monitoring and observability talks where wasn't talks on controllers, or where there were presentations covering both. I hope to write more detailed thoughts and summaries of the talks I attended in the future. The CTF I'm biased working for ControlPlane</a> (the consultancy which designed and developed the scenarios) but I really enjoyed the CTF this year. Usually I play-test them before the events so I don't participate but this year I kept my eyes off spoilers. I was quite happy with my progress, getting through the first two and attempting the third while attending the talks I wanted to see. On the leaderboard I landed 11th overall or joint 9th just by points which isn't too shabby. Especially with many regular players showing on the leaderboard. If you're interested in a full writeup on the KubeCon EU 2025 CTF I'd strongly recommend reading the writeup by the winner Skybound/Mohit here</a>. The Venue Overall the Excel London convention centre is well equipped to support large conferences like KubeCon and frequently hosts similar events such as the AWS Summit. Being essentially a mega-warehouse overall it wasn't too complex to navigate with essentially all the rooms branching off the main coridoor. Having the The Food As usual with these larger KubeCon events catering is hard so the food was cold as per usual. This isn't a problem but I recommend thinking about what food you'd like cold when deciding. I generally went with sandwiches where available and they were nice. The bags have icons for what type of diet it'd suit e.g. Pork, Lamb, Vegetarian/Vegan, but be sure to view the signage which outlines what's actually inside the bags. This will ensure you get something you like but also save you from peeking inside each type of bag before you eventually pick one. As covered prior, the Excel centre has many food options along the main coridoor; if nothing is to your liking there are many other options close by. If you have eaten elsewhere and you see at the end of lunch there's still bags I'd still advise taking one. The cost of lunch is included in the ticket and these lunches may go to waste pick something that you or someone you know would be happy to eat later. Transport The Excel centre is quite well serviced by the DLR and the (relatively) new Elizabeth Line (also known as CrossRail). There are many hotels within a short walking distance. If you have only one or two DLR stops I'd advise walking as even same zone travel is very expensive. Additionally it's very easy as a visitor to forget to pay on the DLR as the touch points are out of the way. If you are going to take the DLR the east entrance is usually the closest to Tech events and was in the case of KubeCon. Driving in is also a good option from the east side of London. The traffic can be rough but this is mitigated by arriving early, or aiming to arrive after the keynotes end and before the general talks begin. On-site parking was a bit steep at £25 a day but there are other options in walking distance. Although, on rainy days or where you need to make a swift exit, having your car parked in the same building could be a plus. Conclusion Overall it was a great event and it was lovely to have it in London again, especially with the shockingly good weather we had! If your employer is covering your costs attending a KubeCon can be a great experience both for learning and making contacts in the industry. The price cuts for self funding and students do also help. Overall I strongly recommend getting in on Early Bird pricing as you'll save a large amount of money and it'll make your trip feel even more worth it. The Kubestronaut Jacket - A Review 2025-02-18T00:00:00+00:00 On the 22nd of March last year the CNCF announced</a> the Kubestronaut Program</a>, but it's more likely you heard about it after KubeCon EU 2024 where early Kubestronauts were showcasing their jackets! In this post I'd like to showcase and review the sought after jacket and help you evaluate if the juice is worth the squeeze! What is a Kubestronaut The FAQ summarises things well: To become a Kubestronaut, you need to pass all Kubernetes-related certifications: CKA, CKAD, CKS, KCNA, and KCSA. All certifications must be current/active (i.e., in good standing, not expired). </blockquote> CNCF - Kubestronaut FAQ</a> What does the jacket look like? 🎉 Tada 🎉 Here it is. It's a "royal blue" jacket with a CloudNative Computing Foundation logo on the front and a Kubestronaut logo on the back. It features a full-body zipper, long sleaves, and two decently large pockets. The grey accent along the zipper and the back are reflective. The inside is a grey colour and made of a breathable material, more on that in the statistics</a> section! The rear of the zipper is covered which should reduce discomfort when moving around or wearing less layers underneath. And this hole isn't a bug, this is a feature! It's a hole for your earphones to reach through to the top of your left-hand pocket. In a world of phones loosing their 3.5mm headphone jack this may not benefit too many of you, but the wired diehards are sure to appreciate it. There is also a loop on the neck to help hold the cable in place which is useful when running or hiking a long distance. Overall the jacket feels well made, useful, and has a variety of nice features! I'm very happy with mine and I think it's quite stylish. It's also a refreshing alternative to a certain shiny jacket you may also be aware of. Personally I find this much more comfortable to wear out in public and I'll be brining it with me to any CNCF conferences and probably most cloud related events. Statistics It's actually pretty waterproof with a 8,000 mm waterproof rating. It can be machine washed, on a cold gentle cycle. It's an 8oz/yd2 / 200 gsm, 3-Layer 100% polyester interlock bonded to polyester birdsey if that means anything to you. In laymans terms, it has a soft but sporty texture to it and the inside has a breathable mesh. This jacket should be suitable for most climates. In colder regions layering up underneath should be sufficient. However in high heat or extreme cold you might only wear it indoors or leave it forever on a hanger! Should you get one? Well if you're thinking of buying all the certs at $1645 USD, spending the time swotting up on the material, and spending several hours on proctored exams just for the jacket, I'd suggest visiting a sporting or camping shop or searching online. If you're already going to be doing the study to broaden your understanding of k8s, or already have several of the pre-requisite certs, maybe consider going for Kubestronaut! Going for Kubestronaut If you do decide you just have to have this jacket (or the other benefits), here are some tips: Consider the Kubestronaut Bundle</a> You can often save some money over buying the certs individually.</li> It can be more convenient than buying certs one-by-one since the LF Training website doesn't really have a "cart".</li> If you already have one or more of the certs run the numbers as to whether the bundle is best for you.</li> </ul> Keep an eye out for deals There are frequently discounts and deals for various events or occasions. With these discounts you can save a good chunk of cash which you could put towards training materials or anything else.</li> </ul> Use your training budget or check in with your employeer If you have a training budget don't forget to expense the certs.</li> Even if you're not going to sit the exams immediately you may want to buy access before your budget rolls-over/expires.</li> If you don't have a standard training budget maybe check in with your employeer as they may want a Kubestronaut on their team and might fund things anyway!</li> </ul> I plan to provide some more comprenehsive guidance in future posts on the road to Kubestronaut and sitting the exams so be sure to check back in, or subscribe to the RSS feed! Home media and what on earth is a "Jellyfin" 2025-02-12T00:00:00+00:00 When in our down time sometimes it's nice to kick up your legs and watch something on the TV, or wrap up in bed and watch something on the Laptop. For many, this means a streaming service. In the past it was pretty much just Netflix; now we're inundated with numerous different subscription services. These "services" fragmenting the libraries of content we're interested in and getting evermore restrictive at the same or higher costs. Home media servers Why Jellyfin is the Better Option for Your Home Media Server Even less-technical people are growing an interest in self-hosted home media servers. An easy answer for most people is Plex</a> due to it's polished interface and relative ease of setup. In this blog post I'll attempt to lay out a few reasons why I'd suggest you try Jellyfin</a> first. 1. Free as in Freedom Jellyfin is Free/Libre and Open Source Software (FLOSS). Its source code is publicly available, and contributions come from a passionate community of developers and users who value transparency. This means no hidden surprises in the codebase, no corporate meddling, and no forced updates that could compromise your setup. Plex, while offering a free tier, is still proprietary software. You’re subject to the whims of their development roadmap, and features can be locked behind paywalls or removed altogether without notice. 2. Privacy and Control With Jellyfin, you control your data. It doesn’t "phone home" to third-party servers or require online accounts to operate. Everything stays on your server, giving you complete control over your media and metadata. Plex, on the other hand, often requires interaction with their cloud services—even if you’re only streaming locally. If you care about keeping your data out of corporate hands, Jellyfin is the obvious choice. 3. No Paywalls, Ever One of the biggest frustrations with Plex is its monetization model. While its free tier is functional, key features like hardware transcoding, offline downloads, and mobile sync are locked behind the Plex Pass subscription. Jellyfin doesn’t do this. All features are free for everyone, whether you’re setting up remote access, using hardware acceleration, or creating user profiles for your family. 4. Customization for Power Users As someone who thrives in Linux environments and embraces tools like Nix for declarative systems management, Jellyfin aligns perfectly with the ethos of customization and flexibility. It’s highly configurable, with support for different metadata providers, fine-tuned transcoding settings, and integration with other FLOSS projects like Kodi. If you enjoy tweaking your setup to suit your specific needs, Jellyfin feels like a breath of fresh air compared to the walled-garden approach of Plex. 5. Community-Driven Development Jellyfin’s community-driven model fosters innovation and inclusivity. Because it’s open source, features are added and bugs are fixed by users like you and me. This results in a product that evolves based on real-world needs, not corporate priorities. For example, recent updates have focused on better transcoding support, UI improvements, and expanded plugin options—all driven by user feedback. 6. The Joy of Owning Your Media Experience At its core, choosing Jellyfin is about embracing the philosophy of ownership. Whether you're a developer who enjoys the satisfaction of running a self-hosted system or simply someone who values the freedom to use software on your terms, Jellyfin represents the ideal media server solution. It’s about aligning your tools with your values: transparency, privacy, and community. Summary For anyone considering setting up a home media server, Jellyfin is a no-compromise option. It respects your privacy, doesn’t penny pinch you at every opportunity, and gives you the freedom to own your experience. Sure, Plex has a smoother onboarding process and a shinier app—but for those of us who believe in FLOSS and the principles it stands for, Jellyfin isn’t just better; it’s the only choice. So take the leap, install Jellyfin, and rediscover the joy of owning your media on your terms. The Beginning and the Tech Stack 2025-01-16T00:00:00+00:00 An overview of how this blog is built and what will be posted here.

Jack K

To Manage: verb

Nix in the Shell

So You've Heard of Nix

KubeCon 2025 EU Review

The Kubestronaut Jacket - A Review

What is a Kubestronaut </path> </svg> </a> </h1> The FAQ summarises things well:</p> To become a Kubestronaut, you need to pass all Kubernetes-related certifications: CKA, CKAD, CKS, KCNA, and KCSA. All certifications must be current/active (i.e., in good standing, not expired).</p> </blockquote>

Home media and what on earth is a "Jellyfin"

The Beginning and the Tech Stack