moved to kobo (the nice one with colour screen) with calibre web running behind a cloudflare tunnel, getting books direct through smallest publishers/authors. Adds the tiniest bit of friction in book acquisition but reading experience, battery life, everything else shits on my kindle experience (and I’ve owned every one).
What software do you use on the device itself? I recently got a Kobo Clara HD, but software support seems to be a big issue.
On one hand, there's folks using the vendor's OS, which looks like an abandoned custom-made Linux distro, where compiling anything is a nightmare. It's not really made to be hackable, but just to read books purchased via their partners.
OTOH, there's a near-mainline kernel, which works nicely, and hacking on the device becomes much nicer, but e-reader-oriented software seems to commonly rely on kernel APIs only present in the vendor's abandoned fork, and won't work on a more mainline Linux. But this is a great target for actually developing stuff.
I'm tempted to write my own minimal e-reader-focused DE, but honestly, I don't want another project on my hands and would like to use something that's already there.
I want to use it mostly to offload reading web articles (or RFCs) onto it, so I want a simple pipeline on my desktop that renders a web page into something e-reader friendly, and then sends it to the reader. I'm using something like Mozilla's readability to extract the article itself.
I don't intend to use the e-reader to displace paper books, I have no quarrel with those. I mostly want to displace "sitting on my desk, reading a multi-page article on a computer monitor".
It's custom software but still pretty dumb, doing most of its work in the background.
Please mention that color e-ink has significantly lower contrast than black and white. I thought I did enough research, but was bitten by this caveat- I would trade basically any feature for more contrast.
On the plus side, with your setup, you can have the lowest friction ebook experience possible on planet Earth by installing koreader, and then the z-library plugin.
Color (Kaleido) eInk screens can't show pure white, because the color filter is in the way. That makes the display significantly darker, and negates the entire purpose of eInk.
I sold my color eInk device after trying it for two days, and went back to B&W.
There are some tablets with RLCD screens that have decent colors and contrast (not quite as good as 300dpi eink, but close, with color and fast updates), but most w/color screens lack proper frontlights for some reason, and they all run android so it's a bit of a mixed bag compared to a proper Kobo/Pocketbook/Linux eink tablet, but having a decent browser on a reflective display without having to cross-compile for 32-bit ARM linux is great.
The antigravity teamwork-preview doesn't work for me -- upgraded to ultra, installed antigravity 2, ran teamwork-preview, keeps failing: "You have exhausted your capacity on this model. Your quota will reset after 0s."
I’m a huge elixir fan, but imho it doesn’t solve durable execution out of the box which is a major problem that often gets swept under the rug by BEAM fanboys. Because ETS and supervision trees don’t play well with deployment via restart, you’ve got to write some level of execution state to relational database or files. You can choose persistent ETS, mnesia, etc, (which have their own tradeoffs and come with some kind of gnarley data-loss scenarios in deep documentation). But, whatever you choose, in my experience you will need to spend a fair amount of time considering how your processes are going to survive restarts. Alternatively, Oban is nice, but it’s a heavy layer that makes control flow more complex to follow. And, yes you can roll your own hot code deploy and run in persistent VMs/bare metal and be a true BEAM native, but it’s not easy out of the box and comes with its own set of foot guns. If I’m missing something, I would love for someone to explain to me how to do things better, as I find this to be a big pain point whenever I pick up elixir. I want to use the beautiful primitives, but I feel I’m always fighting durable execution in the event of a server restart. I wish a temporal.io client or something with similar guarantees was baked into the lang/frameworks.
The good thing about those, IMO, is that they’re leveraging everything that’s already in BEAM/OTP, so there’s no need to reinvent the harder parts. They “only” add some extra features (like persistence of processes/GenServers between restarts) and higher-level abstraction APIs.
Spot on. BEAM is great at surviving process crashes, but if the whole cluster goes down or you redeploy, that in-memory state evaporates. It's not magic. For agents that might hang around for days, pure Elixir isn't enough, you still need a persistence layer. The ecosystem is catching up (Oban Pro, FLAME), but in reality, we're still building hybrids: fast actors for active chats and a good old DB for history and long-running processes
- A phoenix/ecto inspired batteries included framework for Golang. Uses data-star for real time bindings (can do live view like things but my personal favorite is just real time form validation out of the box). Hot reload with templ, daisy, and tailwind (no npm required). Routes file provides metadata on routes so type safe route helpers are generated for views and handlers.
An often overlooked extra advantage to Google is their massive existing ad inventory. If LLMs do end up being ad supported and both products are roughly the same, Google wins. The large supply of ads direct from a diverse set of advertisers means they can fill more ad slots with higher quality ads, for a higher price, and at a lower cost. They’re also already staffed with an enormous amount of talent for ad optimization. Just this advantage would translate into higher sustained margins (even assuming similar costs), but given TPU it might be even greater. This plus the gobs of cash they already spin off, and their massive war chest means they can spend an ungodly amount on user acquisition. It’s their search playbook all over again.
An often overlooked extra advantage to Google is their massive existing ad inventory. If LLMs do end up being ad supported and both products are roughly the same, Google wins. The large supply of ads direct from a diverse set of advertisers means they can fill more ad slots with higher quality ads, for a higher price, and at a lower cost. They’re also already staffed with an enormous amount of talent for ad optimization. Just thus advantage would translate into higher sustained margins (even assuming similar costs), but given TPU it might be even greater. This plus the gobs of cash they already spin off, and their massive war chest means they can spend an ungodly amount on user acquisition. It’s their search playbook all over again.
Agree on mise. It's a great tool, really well implemented and easy to use. I've been trying to set up hk[0] this week and it's unfortunately not been as smooth a ride though.
that's fair. The DX of hk is a much harder problem since it will always require a decent amount of customization to fit into a project. I will be improving this though.
I'd probably say hk is the most challenging pre-commit manager to setup compared to its peers. That said, it's also the only one that can run hooks in parallel safely and deal with partially staged files where the others don't bother with these problems.
At least right now hk is good for folks that want the fastest and don't mind a bit of effort. Hopefully I can improve that and make it the best all-around.
Im very open to a bit of a learning curve! I wasn’t able to get a pre commit of ‘tofu fmt -check’ with the list of tf files changed working, which was frustrating! I found working with pkl tough as there’s little/no editor support (compared to writing tasks in toml with mise). I tried adding a post install hook to mise to run hk install which had surprising side effects!
Yeah, I found the import of existing pre-commit config wasn't very useful. I just switched to using prek as a much faster drop-in replacement for pre-commit https://github.com/j178/prek. Really like mise though, and just started using fnox yesterday.
Mind if I ask what trouble you've had setting up hk? I've been using it a while now and I love it almost as much as I love mise. Took me a little while to get my head around pkl (and if I'm honest, I'm very much still winging it) but otherwise it's been a joy to use.
No support for opentofu, so I had to write a custom hook for tofu instead of terraform. Then the hook itself didn’t work because tofu fmt didn’t like the full list of files being passed on instead of just the tf files. Then I had an issue with tflint. It wasn’t clear that hk would install in the current directory and not the git repo. Writing pkl was awkward - vscode has no support.
Our use case is a dotnet project with infra defined in terraform. Dotnet fmt is too slow to run as a pre commit hook so I wanted to try tflint and tofu fmt as I know they are very quick and they are relatively easy to work with.
They both accept a list of files to work on, but the filter on hk gives you a full list of files that changed, so if a cs file and a tf file changes, both steps will fire with both the cs and the tf file
I think a small improvement might be adding a matched_files template sub that would only show the files that matched the glob rule. I also think an LSP integration for VSCode would go a long way. I could manage the first but the second might be pushing my limits
reply