@Kerplunk @mcc I have a couple of reasons:
* RGB lighting is cool. (Very silly, but cool.)
* Adjustable white balance is actually really nice for reinforcing appropriate sleep habits.
* The bulb dimming itself is *waaaaay* better than "dumb" dimming (which turns "whatever nonsense dimmers do" into a *protocol* that non-incandescent bulbs must interpret).

Of course, my bulbs are Zigbee-only and physically incapable of talking to the Internet.

@jelte @rmondello There are not people with device stability. Phones get stolen, dropped, lost, break; laptops much the same; SSDs fail unreadable; even the server in your basement is subject to flooding, fires, power surges.

The problem with a lot of passkey discourse is that it doesn't have a good answer to what happens when (not if) someone loses device continuity. It doesn't matter how convenient and secure it is if a bad day hardware-wise can lock you out of your entire online existence.

@aeva @glyph
$ upower -e
/org/freedesktop/UPower/devices/line_power_qcom_battmgr_ac
/org/freedesktop/UPower/devices/battery_qcom_battmgr_bat
/org/freedesktop/UPower/devices/line_power_qcom_battmgr_usb
/org/freedesktop/UPower/devices/line_power_qcom_battmgr_wls
/org/freedesktop/UPower/devices/DisplayDevice

Those… uh, dbus paths?… all correspond to filesystem paths under `/sys/class/power_supply`.

@mcc I think about Java checked exceptions a lot. By any objective criterion I can think of, they're preferable to the alternative, but they're *so unpleasant* to use that Kotlin, as well as nearly every major JVM library, ditched them outright.

It seems error conditions are *just* uncommon enough that if you completely botch handling them, you can still clear the (very, very low) bar for "minimum software quality that can still get you a paycheck".