PascalW

Thanks for the shout out to kindle-dash! <3 Great looking dashboard you have there!

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.

[1] https://github.com/pascalw/kindle-dash/blob/main/src/dash.sh...

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.

[1] https://wiki.mobileread.com/wiki/Kindle4NTHacking#Jailbreak

[2] https://github.com/pascalw/kindle-dash

Have you considered managing DNS records with Terraform or Pulumi? That way you can easily automate (bulk) changes.

Edit: this is possible with Namecheap as well, see https://registry.terraform.io/providers/namecheap/namecheap/....

Flutter is no longer the only game in town (using the same approach), new solutions have come that are direct competitors.

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.

I'm using it myself to run Whatsapp for the Matrix Whatsapp bridge [1] on a VPS.

[1] https://docs.mau.fi/bridges/go/whatsapp/android-vm-setup.htm...

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 using iptables myself and it works fine, though you have to make sure that traffic on the kube-bridge interface is allowed.

With iptables:

  -A INPUT -i kube-bridge -j ACCEPT
  -A OUTPUT -o kube-bridge -j ACCEPT

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.

[0] https://k0sproject.io/

[1] https://cert-manager.io/

[2] https://github.com/kubernetes-sigs/external-dns

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).

I'm not familiar with this, sorry.

If your Kindle 4 NT is not broken it's actually pretty easy to root it and use as a dashboard.

Shameless plug: https://news.ycombinator.com/item?id=25939042

That's my project :-) Ht was indeed very useful as it was trivial to compile it for armv7, statically linking openssl. Thanks @ducaale!

Thanks I'm an RSS nut too but didn't know about hnrss. Super useful to keep track of replies.

That's a good point. I'm using partial refresh for this reason, which works quite well because the screen is relatively static (I do a full refresh after 4 partial refreshes, to remove the minor ghosting that does occur). But if your dashboard shows a lot of different content you'll have to do full refreshes, which on the Kindle at least also cause a flash.

Nice work!

I could replace ht with another HTTP client. I just picked it because it was the easiest way I knew to compile an HTTP client with statically linking openssl.

If anyone knows an easy way to compile curl with statically linked openssl, let me know!

It would also not be difficult to build a small custom client based on Hyper or Reqwest.

Though I'm not sure if it would actually make a large difference with only 20 screen refreshes per day.

Might be a nice fit indeed. I considered doing this on my Remarkable 2, but it's a bit tricky to combine a dashboard with actually using the product as it's intended (for note-taking, in this case).

The advantage of using a Kindle like this is that it's cheap enough that I don't have to use it for anything else. I bought the Kindle used for €25.

That's an interesting idea! It depends a bit on the data that is shown on the dashboard, but I guess in many cases the data is quite static. The data on my dashboard can change at any time in theory, but there are many times where the data remains the same for 2-3 hours.

I considered this as well but didn't really want to mess with the hardware. But if you're up for that you can buy the components yourself, or go for something like inkplate [1] which is an E-paper display + ESP microcontroller and battery in one package.

[1] https://inkplate.io/

I don't know exactly yet, but from what I'm now seeing it consumes 3-4% battery per day, with the dashboard updating every 30 minutes for 10 hours a day.

I'm only letting it update during office hours, so I reckon I should get around a month of battery life with this usage.

Yes that should be possible. You could use this as a starting point: https://www.mobileread.com/forums/showpost.php?p=3812831&pos.... With that you can wait for the 'goingToScreenSaver' event and then write your dashboard to the screen.

There are some minor downsides though. If you keep the built-in Kindle UI running it will draw a menubar on the screen when the Wi-Fi connection status changes and power consumption will be a bit higher with this setup. All in all still a good tradeoff if you want to keep using the Kindle for it's original purpose too.

Edit: someone else posted a link to this tool which does exactly this: https://www.mobileread.com/forums/showthread.php?t=236104

https://wiki.mobileread.com/wiki/Kindle4NTHacking and the mobileread forums have a wealth of information on this topic!

You do need the screen to kick off the jailbreak process I'm afraid.