I second that, I have an EzSBC ESP32 board [1] that wakes up twice a day to fetch data through WiFi and three standard mini 1.5V, non rechargeable batteries are still going strong after almost one year. The power supply stage is truly the most important bit when it comes to deep sleep power consumption.
Some time ago I have in fact written a small utility based on fzf that solves this problem by letting you comment aliases in your shell config file and fuzzy-search through them:
"Better" is quite subjective, in my experience I've had workloads that were a breeze to setup in Nomad and painful enough to replicate in K8S that I haven't followed through with the latter. That is especially true in a home server/lab environment where things change and break all the time. I still run Nomad and K3S back-to-back to re-evaluate them periodically for my production needs, but so far my take on the matter hasn't changed.
"Free" puzzles me as well. Free as in open and hackable? The source and buildfiles are all publicly available, hack away to your heart's content. Free as in free beer? The same concept still applies, and if paid support is being referred to here, how's that different from paying any cloud provider to use their managed K8S services?
Yeah I find "better" quite subjective too as I tend to find Nomad better in almost every way and I run both k3s and Nomad as well, both at home and professionally.
Also the "Enterprise" features of Nomad aren't really something a home server user is going to need in the first place (Multiregion Deployments? Doubtful. Non voting servers? Also no)
I'm not sure whether that's a bad thing, though, since the alternative would be having no free plans/editions for those pieces of software at all, or maybe just using them for a few years and the company going bankrupt.
Thanks for chiming in. Any chance that you tried an older, pre-v1.0 version? I used to share some of your considerations, but lately I've seen Nomad evolve at a quicker pace and catch up with some of the features I wanted/liked (ex.: readiness checks were introduced in May 2021 with v1.1, going by the changelog).
As others have already said and basing on the official docs (https://www.nomadproject.io/docs/enterprise), the few Enterprise-only features left don't really feel necessary to me for small-medium deployments; especially when there's an Ops team that can oversee things anyway.
Not trying to play the devil's advocate here, I'm genuinely interested in what I might be missing with my current approach.
Have you ever experienced spikes in the S8's readings? Mine seems to underflow and wraparound every once in a while for no apparent reason or when exposed to fresh air for prolonged periods of time. I tried recalibrating it on the 400ppm baseline a few times but the issue hasn't gone away.
Lower the temperature or turn off when not moved for some time, better temperature control via PIDs, set a voltage cutoff when running off battery packs...
From last time I hacked something up with a Sphero [1] I remember having to lock the motors to read the raw gyro/acc data, this would make the ball itself quite unbalanced but it's an interesting idea nonetheless.
gPodder is already pretty great at this and doesn't require per-podcast config files. Some time ago I even made a simple WebUI for it: https://github.com/nmaggioni/dashpodder
[1]: https://www.ezsbc.com/product/esp32-breakout-and-development...