I assume you’ve used ESPHome for the firmware?

Did you have to mess around with deep sleep or is the battery + solar combo so overkill that it doesn’t matter?

Anyways very cool project. Thanks for sharing

Got it working thanks to your troubleshooting tips now. Also found a very neat way to handle secrets from another comment.

I tend to run a DB instance per service as that makes backup restoration much easier for me. An idle postgres sits at around 50MB which is a cost I’m willing to pay.

Thank you again for your help :)

Managed to get it working by passing in env vars from a secret now.

ArgoCD has a really handy web UI that allows you to quickly see what kind of resources get deployed.
Especially for learning k8s I found that much easier to visualize than raw kubectl outputs.

Passing in the secrets once via the global: section is very neat. Got it working now with a few of the other tips and stole your trick for my secret handling. Thank you :)

Did you also have to set all these env vars by hand?
I am wondering if it might have something to do with rendering Helm Charts under ArgoCD.

I’ll give it another try with your recommendations.

And should I get it working finally, I will obviously switch back to using Secrets.
I only removed them to reduce possible points of failure.

As for blueprints, that’s a task for future me xD

OrcaSlicer has things like Adaptive Cubic or Lightning patterns that have more infill near the walls.

The other members of that slicer family (BambuStudio, PrusaSlicer, etc) likely have them too.

Losing both uv and ruff in one fell swoop sucks.

I’ve written my bachelors thesis with it.

You won’t get any official pre made templates for your thesis (yet) and if you require some obscure notation you probably won’t find a ready made package for it.

For my purposes I only needed some pictures and code blocks which works perfectly fine.

Also typst’s show rules are awesome.

Same here. Literally just set it up and now this.

I hope the author will roll this back or someone else makes a fork. I don’t want to immediately switch technology to XMPP/Matrix/… and have to do it all over again.

I have never used them but there are some tools that advertise being able to run GitHub Actions locally, like WRKFLW.

Also the normal and rpi versions are two completely independent implementations of the same software. So now the LLMs have twice the maintenance load.

I didn’t diff the two files but even the startup and control code appears to be custom for each version.

I assume you mean AVIF? Because AV1 is not an image (file) format but a video compression format (that needs to be wrapped in container file formats to be storable).

Are the common-controls determined per user?

If yes, that would be awesome.

gitui and the plain old git cli

Thanks for the heads up. I have an ESPHome device with a display where I’ve replicated the HA look and feel. Guess I’ll have to update that now

While I fully agree with the opt-in sentiment, 95% of all core integrations are likely “inactive bloatware” on your instance, yet I don’t see anyone complaining about that.

Last time I checked we were at around 1500 core integrations on the search page.

I’m not entirely convinced that this engine will ever work but there is only one way to know for sure.

Very excited to see that this engine will get its chance to prove itself.

How well NixOS fits your purpose really depends on what you want to do with the OS. If you’re just going run a bunch of docker containers, you could manage them via Nix but its a little cumbersome.

Where NixOS really shines for small servers are the so called NixOS Options. They allow you to install tons of services on bare metal but manage all the configuration for you. E.g. open the correct firewalls ports, run a dedicated DB or cache, etc. and all those simply require you to enable them with an ... = true;.

Smaller projects might not have a NixOS Option available and some options are more and/or easier configurable than others, but if you’re running just a few common services you could feasibly manage your whole server with just one native config file and no docker shenanigans.

I’d recommend checking what’s available under the link above. If you wanna go the container route instead, you have the option of just using docker non-declaratively as on every other distro (but then you lose some of the benefits NixOS gives you), or you can declaratively have NixOS manage all the docker containers. There are a few ways to do and manage this so some further research will be required.

Then helmfile might be worth checking out

again.

On a serious note: space is hard and I wish them the best of luck for their next attempt.