Exactly my thoughts. But it all changed when i just put the tailscale proxy on kindle and allowed claude to ssh into it. Now i can just configure it remotely and never really need to do anything else except reading on kindle itself.
Ohhhh that's not a bad idea at all. I'd read the article and was still largely in the "but why do I care?" space, but hands off management makes a lot of sense.
For me Tailscale is what i setup for all my homelab services. This way my Kindle feels like just another homelab service exposed by Tailscale. I'm sure you can do it differently.
Charm/bubbletea toolstack, is very much focused on an ELM style architecture, I.e. message passing and deriving UI from state. You can still do immediate type UI if that is what you prefer, but it won't fit with any of the standard components. Bubbletea is a framework more or less, so even if you know Go, it will require you to learn how to build to its strengths.
Ratatui is by default not very opinionated about how to handle state and updates, which requires some development from you, or using a third party library to get an opinionated architecture around it. Ratatui is more of a collection of libraries, out of the box, it expects a certain interface for components, but it is up to you how you want to compose them together. Whether that is immediate-, stateful-, react-, or ELM style. Stateful is the default for all their examples.
Charms way of doing terminal UI is very much based around strings, which can sometimes give issues with spacing, as components can be fiddly to be constrained within a certain space.
Ratatui creates UI on top of a matrix of bytes, which makes it more difficult to do easy things, but allows you to more easily build complex uis.
Generally I prefer Ratatui, as you can really build robust and fast uis on top of it. It does take a bit more work to get started though. I am also biased by Rust tho.
Ratatui maintainer here. I'd agree with all of the above points.
The lack of opinionated approach stems from Ratatui being not a framework, but a library (you call us, we don't call you), and not having any of the event/input handling things included.
There's likely room for a framework or two on top of it.
You're right; but it should be noted that that is a design choice not an inherent property of the technology.
Currently, the design goal isn't to make LLMs feel "lifelike." It is likely that lifelike LLMs will be released in the future, which could result in sarcastic or dismissive replies to poor questions or missing information.
You can probably run it locally with llama.cpp using CPU only, but it will be slow. I have a couple year old laptop with a RTX 3060 and it runs pretty well split across the CPU and GPU.
I mean, hosting your own outside of OpenAI is mainly to avoid OpenAI accessing the data and using it for X, Y, and Z. I wouldn't roll my own if there weren't concerns about safety due to the cost and quality of the results.
