choobacker

This looks great. Is there by out-of-the-box usable e-reader that supports SSH? Air still has some manual steps/maintenance.

For comparison, I've used PostmarketOS on Pinephone, and it required a lot of fiddly to get a poor experience.

But maybe the simpler usecase of "just reading" has good solutions?

> I will not bank with HSBC because their app will not work if you install things from outside the Google App store

I have this requirement too, since I like to use F-Droid.

My point isn't that there are no such users. My point is that product managers in banks don't care about F-Droid users, since there's so few of us that it's not worth them worrying about.

Many websites are giving up Firefox support, and Firefox adoption is much higher than F-Droid.

If a bank app happens to be okay with F-Droid, it's not because they look out for the needs of F-Droid, it's simply by happenstance.

I agree with his issues with dependencies.

But I'm not sure about his other stuff.

"Avoid features that add disproportionate cost"

I expect part of the problem here is that it's often not clear what the value of features until it's available to customers.

Even the costs of bloat are unclear. Take his bank website example. Do we really think many bank customers are choosing banks based on their website's latency? Banks compete on things users actually care about, like interest rates or fees.

Lots of software inevitably won't meet our ideal standards, because given the cost of developers it's not worth doing things The Right Way.

+1. I think that about summarises it.

Window managers can plausibly already do a lot of what other software can do, yet in practice, popular workflows tend to assume very little from the window manager.

I try to avoid terminal multiplexers in favour of Sway/Emacs/dtach/SSH multiplexing, but I still often reach for tmux.

> Source: this is a description of my own workflow and preferences, so I’m the ultimate authority on the subject, haha.

It's fine to choose your workflow by whatever criteria you decide, but on a post about workflows on a discussion forum, it's reasonable for mvdtnz to continue that discussion and not be laughed at for doing so.

+1.

It's nice to have to a set of programs I moderately care about, so when I'm learning another language I can port them to it.

They're unimportant enough that I can comfortably experiment, but important enough that I want to complete the rewrite.

My "blog engine" is a nushell script that uses pandoc and built-in XML support to convert markdown into a site+feed.

Size is a limiting factor for so.e hardware and architecture too.

NixOS works well for x86-64 and aarch64, but not so much armv7l, as so many consumer routers are.

The PC Engines happens to be x86-64 with decent storage expansion, but for sure if you want to target armv7l, NixOS is not a good choice.

Good job on raising that issue. TIL SSTP.

> Nobody actually cares about security for packages that are not in the default install.

Probably an exaggeration, but it's clear there are some packages that are insecure out-the-box.

systemd-networkd sets up a LAN interface, which Kea then serves DHCP for.

CoreRAD is about the same thing, but for NDP instead of DHCP.

I could have used systemd-networkd for serving DHCP and NDP, but prefer to use separate modular privilege-separated deamons, especially if I get memory safety too.

Tracking config via VCS is great, but the automatic changes is what then makes it tricky to understand what you've actually configured.

There's hardware that has the form factor of a router, but is powerful enough to run an ordinary Linux machine. PC Engines, various ARM64 SBCs.

Me too. My TP Link EAP605 is an AP running OpenWRT. Works well.