The person that found this is a hero.

Whenever I see slightly weird behaviour, there is a temptation to just move on because there isn't enough time, running software is complicated, and there is something else I want to do. I will try to change my attitude in future in case it uncovers a backdoor like this -- it would be educational too.

I got interested in constraint programming, and I had NO idea how it worked. It seemed like magic.

I have started on following the slides and code of MiniCP, and have started implementing the first steps in Rust. I find it very challenging but it is a great learning experience. I got such a thrill from solving the N-Queens problem in milliseconds from a program that I had written myself.

I am continuing to develop the implementation for a few hours this weekend. Because writing a constraint system is hard, I am also learning some new parts of Rust that I have not touched before.

I find daily is better than weekly because I can actually remember what I was doing. However, it is mostly just a few hours each weekend for me a the moment.

Filling out forms to get CI runners means no serious users will be attracted.

I think this will have opposite effect. Only serious users will be willing to fill out forms and casual users will be put off by the bureaucracy. I agree that it is a downside though. In a perfect world, there would be no forms to fill in.

The problem with CI is that the internet is full of not-nice people who will use free compute to mine crypto. Gitlab had problems with this abuse and requires credit card details.

I found the most interesting bit was this at the end:

• You can now specify a new RestartPolicy: Always configuration for an init container.
• If you add that new config, you now have a sidecar container.
• A sidecar container starts before all ordinary containers (because it's an init container), and—this is the big part—it now terminates after all the ordinary containers all terminate.
• If for some reason your sidecar container dies while ordinary containers are running, it will be restarted automatically. (This is the "Always" bit.)
• Finally, unlike with normal init containers that each wait in turn to complete before the next starts, the other init containers do not wait for sidecar containers to complete before starting. Which is good, because they're not going to complete until much later.

Github page for the library: https://github.com/gmcgoldr/stackerror

Learning Rust is a journey. I actually gave up twice before I learnt it properly. I built a simple interpreter as my first project and I found it challenging.

I think that tutorials, and the support you get, is much better now though. Its also a language well worth learning.

At $work we write closed source Rust but we do not use Kellnr.

Instead we use a mono-repo, using a workspace, that contains most of our applications and libraries.

Our setup is mostly OK but needs some workarounds for problems we have hit:

• Slow cargo clean && cargo build, to speed this up we use sccache.
• Very slow Docker builds. To speed these up we use cargo chef.
• Slow CI/CD. To speed this up we use AWS instances as Github runners that we shutdown, but do not destroy, after use. This allows us to cache build dependencies for faster builds.

I am generally happy with our setup, but I am a fan of mono-repos. If it ever becomes to difficult to keep compiles times reasonable, I think that we would definitely look at Kellnr.

I am not sure if it is best practice, but this is what I do and it might provide some inspiration:

• Bootstrap from a private gitlab.com repository with a base ansible setup. Executed from a laptop.
• The bootstrap setups up k8s and installs a bare bones git repository docker container based on https://codeberg.org/al13nsc13nc3/gitsrv.
• Flux CD is installed into the bare bones git repository and k8s.
• Flux CD is used to install Forgejo and Woodpecker CI using the bare bones git repository as the gitops source of truth.

This has the advantage that Gitops and normal git repositories are separate. I think that a similar principle would work with docker compose instead of k8s.

Just to add to this point. I have been running a separate namespace for CI and it is possible to limit total CPU and memory use for each namespace. This saved me from having to run a VM. Everything (even junk) goes onto k8s isolated by separate namespaces.

If limits and namespaces like this are interesting to you, the k8s resources to read up on are ResourceQuota and LimitRange.

For a fun comparison, a reasonable 1TB USB Stick costs slightly less than 1TB of AWS egress.

I bought my Fairphone for similar reasons to you.

I had a second hand mid-range Samsung for about 6 months and then the USB port got destroyed. I was unable to replace the USB port so the phone is useless.

I bought a Fairphone 5 thinking that, if anything similar happened, I would NOT need to replace the phone and would save money in the long term.

Kids not dying in cobalt mines is also a bonus: https://www.npr.org/...

That's a cool docker compose setup and is definitely competitive with a single node k8s deployment I run for hobby projects (k3s). The simplicity of this docker compose setup is an advantage, but it is missing some useful features compared to k8s:

• No Let's Encrypt support for Nginx using Cert Manager.
• No git ops support, the deployment shell script is manually run.
• No management ui's like Lens or k9s.
• Will not scale to multiple machines without changing the technology to k8s or Nomad.

That said, I would be happy to run their setup if I hadn't gone through the pain of learning k8s.

The only thing you should keep an eye on is probably the license? But I’m not the right person to discuss about licensing :/

It is normal practice to keep the same copyright notice and add your name to it, e.g for this project I forked in 2021: https://code.alienscience.org/...

Its not the solution that you are looking for but Woodpecker runs well on k8s and directly supports Forgejo. I use them together on k8s and I am happy enough not have tried runners.

Despite using Tokio underneath, I think that Actix does NOT do work stealing and uses mostly separate threads:

• https://actix.rs/docs/server/#multi-threading
• https://docs.rs/actix-rt/latest/actix_rt/

Given this architecture, I think the article might inaccurate when it says that Actix handlers must be Send + Sync. See also: https://www.reddit.com/...

Actix is a bit weird, but it has been around, and used in production, for a relatively long time.

I do this for sites where I don't care at all about security. One minor tip, that will protect against automated attacks if the password is cracked, is to add part of the website name into the password (e.g "mystrongp4ss!lemworld") .

A human could easily crack it, but automated systems that replay the password on different sites would probably not bother to calculate the pattern.

The manifest of my Kubernetes cluster is managed in a Git repository and is automatically deployed via a GitOps tool named Flux CD. When I push changes to the repository, such as adding a new application or upgrading Docker images, the deployment occurs within a few minutes.

This is the way.

Although I use Flux ImageUpdateAutomation instead of Renovate Bot. Did you consider using Flux to do auto updates? Are there any downsides that made you choose Renovate Bot instead?

I also use KeepassXC and Synthing together and I am very happy with this combination.

One tip that I have, if you are worried about the security of the database file being shared, is to get 2 Yubikeys and use these, along with a strong passphrase, to protect the database file.

If you deploy with Docker you need to attach to the external interface -- I bound to localhost in a Docker container once and its painful enough to debug that it is something I never forget.

I expect that upload_handle() would need to change to 0.0.0.0 rather than axum to bind to localhost.