mm publieesh

.gitignore

@@ -1,3 +1,5 @@
 themes/
 public/
 static
+
+result

config.toml

@@ -24,8 +24,15 @@ taxonomies = [
 ]
 
 [markdown]
-highlight_code = true
-highlight_theme = "base16-ocean-dark"
+# render_emoji = true
+github_alerts = true
+bottom_footnotes = true
+
+[markdown.highlighting]
+error_on_missing_language = true
+style = "inline"
+# theme = "ayu-mirage"
+theme = "andromeeda"
 
 [extra]
 # Put all your custom variables here

content/2023-08-11-thoughts-on-docker.md

@@ -0,0 +1,230 @@
++++
+title = "My Thoughts on Docker"
+date = 2023-08-11
+
+slug = "thoughts-docker"
+[taxonomies]
+categories = ["All", "Technical"]
+tags = ["Docker", "Networking", "Homelab"]
++++
+
+# My Thoughts on Docker
+
+Docker is a tool that uses kernel level namespaces
+to isolate processes from each other.
+This tool allows users to create a consistent\* runtime environment
+for their program that can run on any computer with the right kernel
+and hardware without having to consider the rest of the userspace.
+This is what most people, including me, would largely consider a _good_ thing.
+
+In addition to this, docker has evolved into the OCI-Standards,
+and you can now run docker containers with a myriad of tools,
+such as podman or kubernetes.
+In this post I'm going to argue quite heavilly against using docker for "normal" small server deployments.
+If you have a microservice oriented software stack which you designed to to run on a big cluster orchestrated via containers,
+most of these arguments won't apply.
+But that's not what most people using docker in a homelab environment do.
+I'm also not going to talk about swarm and bigger cluster orchestration services.
+They require setups too homogenic for it to be useful to me personally,
+I might do a follow up post on why I feel this way.
+
+## What does docker provide?
+
+As mentioned before, docker provides namespace isolation,
+it's important to note that this is not the same as providing security.
+It probably helps if you set it up correctly,
+but it's not explicitly designed to provide security between the host platform and the running environment.
+To accomplish this you need some sort of hypervisor.
+
+The containers get spun up via container images,
+these images can be downloaded from the internet or be built by you.
+
+Docker provides a way to build container images via a "Dockerfile"
+which provides a little recipe docker can follow to build the required environment
+and configure the command which should run on start-up.
+
+When it comes container orchestration,
+docker allows you to manage your containers,
+start new ones, delete old ones, attach filesystems - "volumes" in docker-speak,
+stop them, set up networking connections and so on.
+It has a few different ways of accomplishing this but the most used one is probably `docker compose`.
+
+docker-compose files are a declerative way to define what containers should be running,
+what volumes they should have, virtual networks they should each be in, and the whole `#!`.
+
+Declarative systems like this makes it very easy to move the configuration from one place to another.
+It means you can just move the docker-compose.yml and whatever volumes you had for your state,
+and everything will hopefully just work!
+
+## Problems with Docker
+
+I used docker for my homelab for a couple years and was heavilly invested in the ecosystem.
+
+Nowadays very little of that setup remains. And I will touch upon some of the reasons why here.
+
+### Yo dawg I heard you like init Systems
+
+Docker requires an always running daemon which manages the state of the running containers.
+It'll do things like restart containers if they crash.
+It will also make sure the right containers
+are started when your computer boots up,
+and probably lots of other internally important tasks.
+
+That should probably remind you of another daemon on your system
+which do many of those same tasks, namely systemd.
+We'll get back to that later.
+
+#### Dependency management
+
+In any kind of infrastructure there are _a lot_ of interconnected systems,
+which very often depend on each other:
+A network interface needs an ip adress,
+a filesystem needs mounting,
+a database needs to go through an initialization sequence and become available.
+
+Docker has  a good answer to dependencies on other containers
+(often limited to whether or not the container is running, not whether it's healthy),
+but have little to no knowledge of any externalities.
+This will lead to problems if you let docker decide whether or not start your container.
+
+You already have an init system that knows the status of most everything in your system,
+wouldn't it be nice if you could use that knowledge to start your services?
+
+There are even docker images out there which themseselves include an systemd or another light-weight init system.
+Some alarm bells should probably be ringing once you're three levels deep.
+
+Again podman actually plays fairly nicely with this.
+It's possible to use podman in systemd units and reap the benefits of systemd as lifecycle-management and containers as namespace isolation.
+
+###TODO INFO BOX
+### Did you know systemd has a built in container engine?
+
+`systemd-nspawn --oci-bundle` can run oci images!
+
+### Logging
+
+`journald` has blessed us with nice extensible binary logging,
+unfortunately without some workarounds docker will output all logs from its executables to stdout.
+
+Most docker images are also set up to log with time and date, loglevel, and other such metadata in each logmessage,
+something we've moved away from on "real linux" since syslog.
+
+Not being able to quickly filter on loglevels,
+and the "unit" responsible for the logger often being some weird cryptic container-id that changes run to run,
+means any docker container on your system will spam your logs.
+Requiring much fancier log-ingestion services that try to parse the output and reclassify it with metadata
+
+Just using the normal logging features available with journald is a lot better.
+
+### Network mangling
+
+Docker uses virtual network card bridges, and a whole lot of them.
+This is kind of aesthetically unpleasing, but there's nothing directly technically wrong with it.
+One gotcha however is that all that port forwarding magic needs to happen in nftables before it reaches those virtual NICs.
+Those iptables rules get added to whatever configuration you had from before and will in most distros take priority..
+
+That means any firewall settings you have mean _nothing_ to docker. If you say `-p 8000:8000` port `8000` will be open the internet; perhaps without you intending it.
+That's how it has to work so this is understandable, but it's fair to mention since it trips people up, and makes your firewall rules a bit of a mess.
+
+Inspectability/tractability is imporatant here!
+
+### Debugging
+
+Debugging containers can be annoying.
+You need to optimize for image size since this has a multiplicative effect on storage, bandwidth, and time.
+
+Unfortunately that means when you shell into a container you might just end up with a bourne-shell and not much else.
+
+With "normal" unix tools, you can just inspect all files as root, it's not perfect, especially not when you need to debug the environment itself,
+but in most cases it is easier to use your familiar tools from the "outside" of the service.
+
+### User and group ids
+
+All our programs are being ran as root, or alternatively using uids managed by hand.
+Programs generally don't need to be ran as root, and managing uids by hand is annoying at best and impossible at worst.
+As some images make a lot of assumptions around this.
+
+Managing state can also be bad, there's nothing built in to take care of chowning data to the right ids,
+and sharing files between containers can be very complicated.
+
+Some of this is inherent, but systemd has good alternatives with `DynamicUser=`, and `Group=`.
+
+### Turtles all the way up?
+
+You start with an OS, but install docker to deal with the difficulty of managing correct runtimes and state.
+Then you start orchestrating with compose, but as you realize the shortcomings of that approach you spin up a single-node kubernetes cluster.
+Kubernetes turns out not to solve everything either and now you're using rancher, or some other init-ish-system like helm,
+or alternatively maybe something simpler like a templating language you can use with kubectl.
+
+I think it's healthy to be skeptical of soulutions which claim to solve your woes simply by adding another layer of abstraction.
+Sometimes infrastructure and software just is complicated, and only adding layers to it isn't a sustainable approach.
+Do it right from the start and you might not need to add so many management-layers on top.
+
+### Using docker as your package manager
+
+This is why most people _actually_ want to use docker.
+
+Im sure if you ask a homelabber the reason they use docker, it will be be beacause it makes setting up software easy.
+You only need one look at docker hub to see this.
+A lot of the most popular images are software stacks wrapped in shell-scripts that for better or for worse make spinning up and configuring them very simple.
+
+#### Poor Quality Images
+
+Images are made by anyone.
+Sometimes that's upstream developer of a program, who might be motivated by making the software easier to test.
+Sometimes it's a user who just wanted to make their usecase work.
+Sometimes it's a organization of packagers, like linuxserver.io
+
+This leads to users having a lot of choice, which can be good!
+But it in practice also means it's on the users to make sure they're using a good image which is kept up to date,
+is secure, and exposes the right configuration options.
+
+There are no standards here, so each container you spin up comes with their own gotchas,
+and sometimes act like an entirely new ecosystem to dive into.
+
+This isn't a big deal when you start, but becomes one whenever something goes wrong.
+
+Not to mention having to validate all the image providers for trustability!
+
+#### Updates
+
+Updating software is a very important aspect of package-management.
+Gernerally the simplest way is to rely on the image tag.
+`latest`, or if you're lucky the maintainer of your image could be making tags like `<major>-<flavor>` allowing you to pin your images to certain channels.
+Then using `docker pull` to re-deploy your software. These tags are different for every image you use.
+
+That's not the whole story however.
+All software has dependencies, and these also require updating.
+This relationship isn't captured by docker infrastructure.
+The program you're running might not have gotten an update in a couple of months - so there aren't any new releases of the image either.
+That means you end up running months old versions of `openssl`, or `glibc`, or any other library or program your software depends on.
+
+Relying on each image maintainer to rebuild images routinely is a poor solution for a package-management system (something docker therefore does not replace!).
+
+#### Inspectability
+
+This is related to the issues above. Whenever there is a security issue somewhere in the stack, how can you make sure you're patched?
+
+You have to look into how the end-user software is built and included in the container:
+
+From another package-manager? Built from source then cleaned up? Downloaded from a binary release somewhere?
+
+Then your containers are built at different times, was the patch included in the repository of the base-image at that time?
+
+Then your containers are built with different base-images following different release channels, or even completely different package-managers and repositories!
+
+This information isn't recorded anywhere and you must piece together the information from `Dockerfile`s (if you have them), upstream repos, logs, and historical time information.
+
+## What to use instead
+
+I want to say, you should be using NixOS...
+The union of systemd and Nix solves all the problems docker _should_ solve while also avoiding the pitfalls of the solution.
+
+This is a hard ask though, of beginner homelabbers, or people who just need their stuff to "work".
+
+Maybe the answer is to just not deploy so much software, or prefering things available in your distribution.
+Or better yet making your own images/packages.
+
+In any case you probably need to learn more about the systems that run your applications, and take more direct ownership of it.
+
+Not because doing so is something extra docker provides, but because these are things you should be doing, which docker does not!

content/2024-08-10-minecraft-gpl.md

@@ -0,0 +1,163 @@
++++
+title = "Minecraft is GPL"
+date = 2024-08-10
+
+slug = "minecraft-gpl"
+[taxonomies]
+categories = ["All", "Legal"]
+tags = ["Minecraft", "Licensing"]
++++
+
+# Minecraft is GPL
+
+> [!WARNING]
+> I'm not a lawyer!
+> This post is meant to be a fun history lesson and thought experiment,
+> \- or maybe a parable - around a complex licensing situation.
+
+
+## Preamble
+
+Bukkit was a very popular modded minecraft server licensed under GPLv3 and LGPL. 
+
+Throughout the first half of the 2010s
+it was the defacto standard minecraft server implementation in use,
+and its forks and api are still going strong today through projects like spigot,
+paper, and glowstone.
+
+## The Licensing Situation
+
+Bukkit was two projects,
+the API (licensed under GPLv3),
+and CraftBukkit (LGPL):
+a modded mincraft server wich exposed this API to enable making plugins.
+
+If you know anything about Free Software licenses,
+you might be able to tell that this is already pretty problematic.
+
+CraftBukkit - which depends on Bukkit
+is licenced under a _more_ permissive license than Bukkit.
+Thus distributing CraftBukkit under the LGPL (as a whole)
+would be a violation of Bukkit's license.
+
+Maybe this could be overlooked - I mean, it's the same project
+and no one contributing could be thinking their contributions weren't
+intended to end up in CraftBukkit.
+Besides in the worst case all that has to be done
+is for the whole to be released under GPLv3 - Something the LGPL generally allows.
+
+> [!NOTE]
+> Since the Bukkit API (and library) is GPLv3,
+> techincally all plugins are probably also GPLv3?
+
+
+Unfortunately CraftBukkit is more than just bukkit.
+The distribution is more like Bukkit (GPLv3)
++ CraftBukkit (LGPL)
++ Minecraft (Proprietary)
+
+Not only does it link to Minecraft,
+it includes decompiled code,
+and most of it could definetly be construed as a derivative work of it.
+
+This makes the distribution itself a straight copyright violation.
+
+That would be that,
+and the argument is that CraftBukkit
+not being able to be released under the GPLv3 voids the license.
+
+All authors have copyright for their contributions
+and have never had license from any other contributor
+\- Just like they didn't have a license for Minecraft.
+
+Anyone could at will DMCA anyone.
+Which as you will see, is what happened in the end.
+
+## How did this happen?
+
+The bukkit project was so successfull that eventually
+[their core developers were hired my Mojang](https://web.archive.org/web/20120310061720/http://forums.bukkit.org/threads/bukkit-the-next-chapter.62489/)
+\- the owners of Minecraft,
+just two years after the project was started.
+
+After this,
+[three out of](https://github.com/Bukkit/Bukkit/commits?author=Dinnerbone)
+the [four core developers](https://github.com/Bukkit/Bukkit/commits?author=grum)
+stopped [working on bukkit](https://github.com/Bukkit/Bukkit/commits?author=tahg).
+The one that remained active in the bukkit project left Mojang 20 months later.
+
+> [!NOTE]
+> Unfortunately the CraftBukkit repository is not available due to a DMCA,
+> therefore I can't link to a more busy repository.
+
+It's clear that Mojang is very much aware
+of the copyright infringements taking place at this point,
+and are really enabling and directly endorsing it.
+
+[Then in 2014 minecraft changed their terms and conditions to include language that disallows distributing mojangs work, and bukkit decided to shut down.](https://web.archive.org/web/20141125024150/http://forums.bukkit.org/threads/bukkit-its-time-to-say.305106/)
+
+This made Mojang and the ex-bukkit developers spring into action.
+[Here's a summary from the mojang developers themselves](https://web.archive.org/web/20140914010750/https://storify.com/lukegb/the-tale-of-bukkit-for-minecraft-1-8),
+including tweets from the lead developer "Jeb_".
+
+They were suddenly revealing that
+when the bukkit developers were hired two years earlier,
+they also "bought bukkit",
+and would be updating it themselves,
+insisting the project was not shut down.
+And that bukkit had a "special relationship" with regards to the EULA
+
+This surprised and angered a lot of people who
+were working under the assumption that bukkit was a community lead project
+and not beholden to Mojang
+(apart from the copyright violations looming over them at all times).
+[Including one developer who decided to DMCA the project](https://github.com/github/dmca/blob/master/2014/2014-09-05-CraftBukkit.md)
+
+## And now for the epilogue, or rather, the punchline
+
+However, CraftBukkit was released,
+as a whole under the LGPL (really GPLv3),
+for 2.5 years _while_ being owned by Mojang.
+It might be fair to say that
+the copyright holder of minecraft was the one releasing it.
+This is even suggested at with the "special relationship" according to Jeb_.
+
+The only legal way for this to be done
+is for minecraft to be at least LGPL-compatible.
+Such that CraftBukkit could be released by Mojang
+(or at least their subsidiary)
+as GPLv3.
+
+Mojang certainly had the rights to publish minecraft
+under an LGPL-compatible license.
+Bukkit's LGPL code can be linked to in a work licensed as GPLv3.
+Thus Minecraft Java Edition 1.2 to 1.7 is free software.
+
+Unfortunately
+(contrary to horrifyingly common practice in the free software community)
+licenses don't really act automatically like this,
+the most restrictive license in the chain
+(plus whatever ownership the distributor actually has)
+isn't what actually counts.
+
+## Post Scriptum
+
+The most glaring hole in this logic is that more than likely
+Mojang "owning bukkit" was limited to the trademark,
+and maybe the contributions of the developers who joined Mojang.
+
+Bukkit was an informal organization,
+not a legal entity, and even if it was,
+a subsidiary does not automatically get the rights to their parent's assets.
+
+The way Mojang communicated during the situation
+is hard to decipher in regards to exactly what "owning bukkit" means.
+And the tweets of some employees
+(even high ranking ones)
+might not have that much legal sway
+
+So it's entirely possible that bukkit
+\- even during this timeframe -
+did not actually have the right
+to publish CraftBukkit under a theoretical GPLv3.
+

flake.lock

@@ -18,10 +18,12 @@
     },
     "nixpkgs": {
       "locked": {
-        "lastModified": 0,
-        "narHash": "sha256-xKel5kd1AbExymxoIfQ7pgcX6hjw9jCgbiBjiUfSVJ8=",
-        "path": "/nix/store/ylrrz211xgjzkcpyiafpq9y2yws7fyah-source",
-        "type": "path"
+        "lastModified": 1776949667,
+        "narHash": "sha256-GMSVw35Q+294GlrTUKlx087E31z7KurReQ1YHSKp5iw=",
+        "owner": "NixOS",
+        "repo": "nixpkgs",
+        "rev": "01fbdeef22b76df85ea168fbfe1bfd9e63681b30",
+        "type": "github"
       },
       "original": {
         "id": "nixpkgs",