alienscience

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 enjoyed reading the Phoenix Project and learnt a lot from it. It is a classic for very good reasons.

There was another follow up book -- The DevOps Handbook that went into more detail about solutions to the problems raised in the Phoenix Project. I got a lot from the DevOps handbook but I found it quite a heavy read.

Years later I found a smaller, but super practical book, that covered much of the same subject matter -- Operations Anti-Patterns, Dev Ops Solutions. I recommend this Manning book after the Phoenix Project.

But then I haven't read the Unicorn Project yet, so that is a book for the list.

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/alienscience/dnsclientx/src/branch/master/LICENSE

LOL, yes. Just in case it is of interest:

• ESP32-S3 is the chip, this family usually comes with CPU + Bluetooth + Wifi.
• Reverse TFT, this is a small display put on the other side of the circuit board from the chip.
• w.FL Antenna, this is the connector on the Wifi Antenna.

I like these small boards, they are tiny and I need a magnifying glass for soldering. Its mind blowing how these tiny boards are more powerful than mainframe computers filling a room, and supporting 20 users, used to be.

I think that Kreya is worth a mention:

• It has more complete OAuth2 support than Insomnia.
• Saves to human readable files.
• Usable free tier.
• Cheap Pro tier pricing.

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.

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/sections/goatsandsoda/2023/02/01/1152893248/red-cobalt-congo-drc-mining-siddharth-kara

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/r/rust/comments/14cbe1u/why_does_actixwebs_handler_not_require_send/

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

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.

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.

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 learnt something from this article, thanks.

I only found out yesterday that Rust has a Binary Heap in the standard library so the timing of this is perfect.