Do I understand correctly that this has all the building blocks which make up various lossless compression schemes (dictionaries, run length encoding, delta encoding, etc) and kit bashes them together for your specific dataset?

I was under the impression that modern file formats and compression schemes already kind of do that as part of the normal compression process, so I was a little surprised by how much they beat some of the competition in their benchmarks.

If you don’t mind me asking, what made you go with VoidAuth vs Authelia or something else entirely?

I’m in a similar boat as OP and while VoidAuth looks very promising I’m put off a little by the young age and size of the project.

Harper is great, but it only does English. Really wish their “extensible core” was extended to other languages sometime.

I just wish that they wrote more articles. Their writing style is superb. Can’t argue with this though:

More coming soon. Or not. I don’t owe you shit.

Not to mention that this simplifies the problem so massively that its almost a pointless metric.

This is like analysing traffic jams by counting the number of registered cars.

Sure there is a correlation but not a very meaningful one.

Don’t get me wrong this problem is an important one, no arguments there, but this says nothing about collision risks (in certain orbits of which most don’t impact each other) or orbital parking capacity (as in how many objects can we safely add).

QR codes come with (differing levels of) error correction. You could decode it and take the amount of corrected errors as a score.

I don’t know what unit/chunk of data the error correction works on but you could alternatively dive a bit into information theory and calculate how close any of the chunks are to an uncorrectable error and use that as a score.

Since the first uncorrectable error will cause the scan to fail this would match your problem definition fairly well.

One benefit of this approach would be that it’s a single scan and done vs searching n permutations of the same code.
Or maybe you’d want to scan it a couple of times to rule out any additional errors introduced by the camera or environment.

Randall’s timing is impeccable sometimes

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

Losing both uv and ruff in one fell swoop sucks.

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 ran into the same issue not so long ago and at least for no_std I had to resort to using the async_trait crate. (The project is no_std but has alloc)

I can’t recall the exact error so it might have been due to mixing async and non-async methods in the same trait. I would have to look at it again…

Source (German)

Would it have cost you so much to leave a link at the bottom of the post?

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

Indeed

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.

Since projects of the same language often use the same tooling this makes it easier to clean up the whole directory by running something like this:

for d in ./*/ ; do (cd "$d" && somecommand); done

somecommand could be cargo clean if you’re in the Rust directory for example.

Just out of curiosity I don’t see how 4 sticks die together at the exact same time unless the PSU is/has fucked up hard.

I’d argue that the likelihood of 4 sticks failing together is much lower than the MOBO or CPU or PSU failing in a way that makes RAM inaccessible.

Typically you’d see one stick failing at which point you could take it out and run with the other 3 (or 2 depending on configuration).

Anyway if you ever intend to return its probably best to keep the rest of the components because who knows which of those will be up next for a shortage/crisis.