this is exactly what I was looking for!

this sounds cool!

OP here - So the way we rendering this we are using the braille characters that are available in the character set on the terminal.

That's interesting but not clear at all in the readme. Do you choose specific characters for their shade/coverage of each dithering cell?

ah yes, I went with the braille characters ascii values between 32 and 95.

I don't think I agree with this claim. Also, they didn't cut-off anyone. You can still use their API as you wish. It's out there for anyone who wants it.

They simply stopped people from abusing a accessibility feature that they created for their own product.

I'm not seeing how "subsidized pricing for their own product" is accessibility related.

if you make something - you want people to use it right?

>they didn't cut-off anyone

They did banned a lot people. Later, they "unbanned" them, but your comment isn't truthful.

Adding to this: socially awkward people shouldn't feel pressured to mute themselves.

> Everything being a repeat game and people on the sideline taking notes

This isn't an excuse to play small. The universe rewards courage.

also, on the markdown front, I saw this cool library https://github.com/Canop/termimad gaining popularity

Termimad author here: I’m always a bit afraid, when I see the popularity of this crate, that it might be undue and that people may lose time trying to use it when it’s probably not the tool they need.

Termimad isn’t a full-fledged TUI framework. It can be used to build TUIs (I made broot, bacon, safecloset, etc. with it), but if you want to quickly build a TUI and compose UI components and widgets, you’ll probably find it much easier to choose a real TUI framework (e.g. ratatui).

Termimad isn’t a generic Markdown viewer either. Markdown is mainly used as a language for the developer to describe parts of the interface—especially rich text—inside a TUI. People interested in rendering arbitrary Markdown files will find that it lacks features such as image rendering.

I don't know much about the GUI space. I would love your take on why did you went with egui instead of guirs

Good question! A few reasons for egui over gtk-rs/iced/others:

- Immediate mode — egui redraws every frame, which makes state management simpler (no callback hell). Great for prototyping.

- Pure Rust, minimal deps — egui is self-contained. gtk-rs requires GTK installed on the system.

- Cross-platform out of the box — Same code runs on Windows/Linux/macOS/Web

- Rapid iteration — Hot reload-friendly, easy to experiment with layouts

Trade-offs: egui's TextEdit isn't designed for code editors (no multi-cursor, can't hide folded text), which is why v0.3.0 will replace it with a custom widget.

I agree, I personal prefer simple docker runtimes over orchestration systems

I am curious, I haven't faced any major issues using claude code in my daily workflow. Never noticed any flickering either.

Why do you think opencode > CC? what are some productivity/practical implications?

Opencode has a web UI, so I can open it on my laptop and then resume the same session on the web from my phone through Tailscale. It’s pretty handy from time to time and takes almost zero effort from me.

The flickering is still happening to me. It's less frequent than before, but still does for long/big sessions.

I agree. the type safety that it brings to the HAL. it's a like cushion for people entering this space.

never understood what a watchdog is tho...

A watchdog is a piece of hardware that will automatically restart the chip if it detects the code as being stuck. The way it detects this is that you have to poke a register of the watchdog every so often, and if the register hasn't been poked for a certain timeout (usually configurable), the chip is restarted.

Watchdogs exist on MCUs but also on some "proper" computers. The Raspberry Pi has one for example.

>Watchdogs exist on MCUs but also on some "proper" computers

All modern computers have watchdog. You can check your logs

`journalctl -b | grep watchdog`

https://access.redhat.com/articles/7129255

That's a software watchdog. The comment you're replying to is talking about hardware watchdogs.

Yes, but those are done in software

There's generally at least one watchdog device available in most PCs delivered in last decade, but it's not always utilized. Essentially at one point an intel southbridge integrated a basic watchdog on all models, and it started to just... be included.

So these days you can find a variation on the TCO timer watchdog in most PCs, even if the exact implementation varies so we now have a bunch of drivers for the different variants.

Linux doesn't see one on my Ryzen 5600X desktop at least. My Intel Skylake Thinkpad does seem to have two though (iTCO as well as INT3F0D, not sure what that is, but if I interpret the files under /sys correctly it belongs to the LPC/eSPI controller PCIe device, while the TCO watchdog is found under the SMBus PCIe device).

In both cases they do have software watchdogs (NMI based) which relies on a hardware timer triggering an NMI in the kernel. But that relies on the NMI handler still working, which is not as good as a real HW watchdog.

Apparently it depends to a little bit on how the motherboard is designed, theoretically SP5100 watchdog which is part of the CPU logic in recent ryzens, apparently, is supposed to be enabled if the motherboard is designed with IPMI in mind.

For whatever reason, it's enabled on my laptop despite it obviously not having IPMI support :)

mac’s too?

“All CPUs” would probably be 99.9999% accurate. It’s just one of those fundamental functions you want in a processor. Whether it’s exposed in the OS is a different matter.

AMD doesn't have it. I just confirmed by grepping through dmesg and journalctl -b, the only time it appears is due to UPS driver notifications (unrelated).

Cortex-A includes a watchdog so yeah.

You don't need to poke the watchdog! Petting or feeding is fine too.