Kache

But IMO that's one reason weird UX/design is not uncommon and can persist in dev ecosystems. The intended users are more proficient than average and most are able to work around most issues.

Perhaps open federated systems should have recommendation algos too, just optional and open

Maintaining vacuum is difficult and most likely more expensive than just using a cheap energy source

For example, a solar salt distillation system can be totally passive, even if slow and space inefficient: https://en.m.wikipedia.org/wiki/Solar_still

If the goal is evaporative distillation, it makes no sense to use a process that begins with filling and conaminating the entire system with contaminated water

You'd have more success keeping the container clean (full of air) and pumping all the air out of it, which is still probably less efficient than other means like boiling

Thought it was possible to lob the ball up and over?

Bit off loss is fine, esp if it's storing extra "free" renewable energy that would otherwise just be thrown away/not collected

I think article directly emphasizes the hope that it's sustainable, scalable, and available. For example, pumped hydroelectric isn't as available because it needs just the right terrain of two nearby lakes separated by as much elevation as possible

IMO wardrobe concerns should come far behind health. Is this not a serious "all hands on deck" health situation? Are you sure considering custom tailoring is the correct life prioritization to take right now?

Bravo, a proper application of https://en.m.wikipedia.org/wiki/Paradox_of_tolerance

For me, the more relevant adage here is "a bad abstraction is worse than no abstraction".

IMO many abstractions in Java are terrible in this regard, either via commonly proliferated patterns or via language design issues. Abstractions large and small are all forcibly locked into place very early on in the name of formalism and safety, ultimately leaving us with poor versions of the former and weakened versions of the latter. Where is "encapsulation" when certain classes only work when hooked up in very particular ways to other distant classes? Where is "type safety" when certain methods simply raise "not implemented for this sub/super-type"?

These faults are often hand-waved as "all ecosystems have rough patches", but my point is that Java's bad abstractions in particular are supremely more stubborn and persistent in comparison with other ecosystems. I understand many consider this a strength aka stability, but IMO at the extreme being unable to shed the past means negatively hindering progress. I think modern Java versions show a budding shift in mentality, but I've already moved on -- it's just not for me.

I've had to resort to "do not disturb" 100% of the time, with the "allow contacts to bypass DND"

Maybe their communities are blank slates where innovations in "distributed power grid" systems can happen? Have heard that traditional power grids are "unidirectional" and have had some trouble with solar installations popping up.