One of the biggest issues I see is the overcomplication of minor things. OP's link has examples. It wants to write every piece of code as if it is a user facing API. It will try to triple check every piece of memory that enters a function, even if the function that called it had it hard coded. It's really insane when it decides that due to all the error checking, it should create a helper function just to hold all of the error checking code for something that was spun up with the class default values.

The current thing I was working on was figuring out if I can do this: https://github.com/NilsIrl/dockerc . This project, compiles a docker image, and runtime to a single container. The interesting thing I find about it, is that it brings the docker container runtime and sandbox along. If I replace a user's login shell with it, the user is now placed inside a sandboxed environment and can't do anything.

My usecase is I want to replace people's login shells with a container in a defensive cybersecurity competition. But, containers are not a sandbox, and full network access, and so on.

So my improvement, was to:

• Use the gvisor/runsc runtime instead of a normal container. Gvisor is a reimplementation of the Linux kernel in Go, and it is as secure as a virtual machine, way more secure than a normal container, BUT I can't guarantee nested virtaulization is enabled
• Rip out dependencies on user namespaces or fuse for sandboxing or the container runtime, and entirely rely on Gvisor for isolation, just in case machines are old/misconfigured and those components don't work
• Use Nix to build images and all in one executables instead: Nix has ways to package static programs that avoid pitfalls of above

I am having trouble meeting all of these requirements, so I suspect one or a few will go, or I will have multiple versions of the project with tradeoffs.

All of my projects, often involve doing something standard, but with extra constraints, or some kind of "twist". Like a very common thing I find myself doing, is to do something normal, but then rip out one of the underlying components of the system, replacing it with something else.

I've found that I've learned a lot about how these systems work, without having to spend time building them entirely from scratch. You learn way more about Linux by reconfiguring your init system to enable encryption, than copy pasting from the Arch Linux Installation Guide the whole time, doing the standard setup. And then ignoring the partition layout so that my kernels are restored by BTRFS snapshots, which is not the default configuration.

That's the way to break out of tutorial hell. You have to not follow the tutorial. You can still follow them most of the way, but you have to pick a few steps, and do something different. I pick something that I think will benefit or make my setup better in some way.

It is kind of difficult, since I feel like Linux has gotten more popular, and people know write more blog posts, and something that was previously a cool twist, is now something I can find a tutorial for. But with some care, you can ensure you still are learning, and it's made easier by picking projects with twists.