

It seems like it should be possible to build keyboard (and other) peripherals that exist in both virtual and physical worlds. Give them sensors similar to the hand controllers, so the headset can know where they are in space, project into VR so it’s easy to find and use.
VR handsets are incredibly flexible as spatial controls, but we’ve got all this evolution and a lifetime of learning just amazing finger dexterity. That control is based more on tactile and proprioceptive feedback than visual, so I think it’s been overlooked in the vision-focused VR space.










I started doing the One True Database method because I got worried that the high write count on all the little db’s was abusing a raspberry pi’s SD card. Moved them all to a bigger server with NVME and mirroring to a RAID.
Not all the compose files make obvious how to reconfigure the db host. Homeassistant uses s a sqlite db built into the container, rather than a separate unit, but you can force it to use a remote db through its config file. May or may not be worth hiding db user/pass in a .env And sometimes there’s trouble restarting after power failure, depending on what order the database, pi, and various containers come back up.
I also feel it’s worthwhile. I feel better being able to check on all the databases. Feel better not writing to the SD card so much. Feel better offloading those megabytes and cpu cycles from the little pi. It’s been fun snooping through database structures. There have been a couple times where I decided to query one of the ccontain databases directly, or cross from one project to another, and it’s easier (for me) to give a different user privileges to the database and query some deep bit of data than to figure out how to extract it from an API or frontend.
I’m not even running that many services, but why would I want the overhead of 6 separate mysql instances when I could just have one?