

I’ve started using this method in the past weeks and it mostly does what I want it to do: https://github.com/eriksjolund/podman-caddy-socket-activation/
I’ve started using this method in the past weeks and it mostly does what I want it to do: https://github.com/eriksjolund/podman-caddy-socket-activation/
The difference might be HTTP vs HTTPS. On a Pi the extra CPU load to properly encrypt the HTTPS stream is probably significant.
Object storage (the S3 API stuff) is the most logical answer here, it’s much simpler and thus more reliable than solutions like Gluster, and the abstraction actually matches your use case. Otherwise something like an NFS share from a central fileserver works too.
But I agree with the other comment that you’re trying to do kubernetes on hard mode and most likely with a worse result.
Thunder has experimental support, haven’t tried it yet though (says it costs extra battery)
Oh I agree with your post, but I was responding to Valmond who used different criteria.
You can have all three of those, but you won’t get great performance. The Samsung QVO SATA drives are a great example. I wouldn’t use those for an OS drive but they’re fantastic for NAS or media use.
If everything went fine during production you’re probably right. But there have definitely been batches of hard disks with production flaws which caused all drives from that batch to fail in a similar way.
A 10 Gbps network is MUCH slower than even the smallest oldest PCIe slot you have. So cramming the GPUs in any old slot that’ll fit is a much better option than distributing it over multiple PCs.