I think it's fine to say C#'s data model is a superset of Java's or Rust's a superset of C's, but XML and JSON is too far for me, personally.

The obvious way is to use elements for everything, but then you're mapping both structs and their fields (very different concepts in e.g. C) to elements. Attributes map nicely to struct fields, but they only admit string values.

React is over a decade old, and as far as I remember, desktop apps using embedded browsers (Electron) started becoming dominant after it came out.

The ease-of-distribution advantage is huge, but web technologies are big outside the Web too, where it doesn't apply.

(Besides my main point, idiomatic web UIs don't implement resize handlers for positioning each element manually, but instead use CSS to declaratively create layouts. Modern GUI libraries with visual builders can also do this, but it was decidedly not the norm in the 90s. Also, modern dynamic GUIs generally don't use a static layout with disabled parts, but hide or add parts outright. That kind of dynamicity is hard to even conceptualise with a GUI builder.)

EDIT: I forgot to check the "removable battery" checkbox; with it you get zero matching phones. Maybe you should've checked that before assuming GP just can't search.

Not to end on such a negative note, foregoing a maimum height and the removable battery, Sony's Xperia 5 and 10 fit the rest of the requirements and are very good phones. Hard to find for sale in the last few years, though.

At some point, personal information becomes history, and we stop caring about protecting the owner's privacy. The only thing we can disagree on is how long that takes.

It doesn't fully quantify the light, but it's good enough to distinguish trash or even passable lights from actually good ones.

I wish I could "just fork" most social problems. As FLOSS developers, we have the great luxury of being able to fork, and all we lose is the community, other people's considerations for our preferences. But for social problems, the people are the point, so "forking" alone wouldn't accomplish anything, not to mention physical limitations that make forking e.g. a country impossible.

The Markdown-to-templated-HTML pipeline code is the same whether it runs on each request or on content changes, so why not choose the one that's more efficient? Serving static HTML also means that the actually important part of my personal webpage (almost) never breaks when I'm not looking.

That's not true. When you configure just NAT (with e.g. nftables on Linux), the NATed devices are still reachable from the outside, you just have to add an entry to your routing table to reach that internal address space using the router.

That of course assumes time is free, so I wouldn't compare it to cloud pricing directly. I'd also personally budget in incremental backups.