Instead of using a cronjob you can put the device into sleep and use the RTC to schedule the next wakeup (see [1]). This takes only very little power, as the device is only turned on for mere seconds and sleeps the remaining time.
Some Kindles can easily be jailbroken [1]. I have two jailbroken Kindle 4 devices and they're still great. Both for reading (though you have to sideload books) and as e-ink dashboards [2]. A Kindle 4 can run for ~ 28 days on a single charge, refreshing the screen every hour.
I've personally only tested it with a Kindle 4 NT. I haven't had any reports of people using this on other Kindle devices, but in theory it should work as long as the device is jailbroken.
Highscalability.com was great! I still follow their RSS feed but there's not a lot of new content nowadays. If someone knows a similar resource I'd love to hear about it!
Flutter for web is quite rapidly improving in all the areas you mentioned. For right now I think it's already very suitable for highly complex browser applications such as a Figma, Google sheets etc. Load times aren't the best due to a quite hefty WASM download, but for _applications_ that you typically open only a couple of times per day and where you work in for several hours, that initial loading delay really doesn't matter.
Just don't expect to use it for an E-Commerce site or something like that.
Interesting. I've never been able to make Anbox run in a cloud environment though, don't recall the exact details. But indeed I guess it should be able to work as there's also a commercial offering targeted specifically at cloud setups. https://anbox-cloud.io/
Came across this very useful project. It provides Docker images with Android running directly in Docker, without qemu or an emulator. I've never seen this before, all other solutions that I'm aware of either run the Android emulator in Docker or use qemu directly (like Anbox).
Advantage of this is that it's very lightweight and does not require VT-X or AMD-V, ideal for running in cloud environments that typically do not expose this CPU capability.
Very similar. I guess it's really k8s (the control plane) itself that is so resource intensive. Looking with top right now kube-apiserver, kubelet, kube-controller, kine and k0s use 13.5, 12.5, 5.6, and 3.0 % CPU respectively. Obviously it fluctuates quite a bit, but seems to be around 25-30% of 1 CPU core too. Also uses about 500-600mb of memory.
So yes, it definitely takes quite a bit of resources. I'm running this on 4 CPU cores and 6 GB memory, so 25% of 1 core and some 600mb of memory still leaves plenty of resources for the services. On a more philosophical note (as was mentioned below in this thread), it is a bit wasteful perhaps.
Curious what makes you think k3s is the better choice? The only reason I ended up going with k0s was that I had problems getting k3s working well behind a locked down firewall. With k0s that was pretty easy.
I'm doing something similar though I've opted specifically to _do_ use Kubernetes via k0s [0]. It works wonderfully well and allows me to use most things that are available in the k8s ecosystem like cert-manager [1] and external-dns [2]. All configuration is stored in Git and the server itself is basically disposable as it only runs k0s and some very basic stuff like iptables rules.
I see this sentiment quite a lot that k8s is too complex for small scale setups, but in my experience it scales down very well to small setups. Granted, you do have to know how to work with k8s, but once you learn that you can apply that knowledge to many different kinds of setups like k0s, bare metal, EKS/AKS etc.
Might be nice to deploy the Flutter app on the web too. Flutter web support is pretty decent now. SQLite on the web is probably going to be tricky though (sqflite doesn't support it).