993 karma · joined October 11, 2013
Of course the challenge there is good bot detection to not accidentally serve fake data to a legitimate user.
I have a bunch of these switches https://www.zigbee2mqtt.io/devices/TS0044.html#tuya-ts0044, and the solution of turning off the periodic battery reporting seems to have helped, I haven't had to change any of their batteries in many months. See https://github.com/Koenkk/zigbee2mqtt/issues/14157#issuecomm.... Not sure if something similar can be done with original Hue switches or bridge (or whether it would help there).
One different kind of switch I have, which doesn't have this problem, has had the same battery in it since I bought it 2 years ago.
It may require a bit more tinkering though, you either need to use it via its web dashboard, or write a simple program in anything that has a mqtt client library (which is basically everything), if you want to link it with things like zigbee remotes or some external triggers, etc.
And I wonder whether someone observed that in practice.
E.g. code that accesses an optional property as if it was always present, because it happens to be present when you're writng the code, etc.
That seems like a possible pitfall when relying on a REPL heavily, but I haven't used such a language myself, so can't speak from experience.
Even the next version of IntelliJ will have partial support for them (https://blog.jetbrains.com/idea/2023/06/intellij-idea-2023-2...)
That's one advantage of ChatGPT, my OpenAI account is isolated from other things.
If you have roughly 4K per eye in the headset that renders everything you see, then you can't expect the virtual equivalent of a 4K monitor that only takes up a part of your vision.
Lower PPI virtual screens should be usable, but the text may still look bad on those when you can't do things like subpixel antialiasing (macOS on 27" 1440p also suffers from this). Especially if you need to render small text at an angle. If you only work with fairly large text or with pictures/video, that would probably be fine.
Full color passthrough from cameras and a depth sensor (better than Quest Pro), 120Hz, slightly higher resolution than Quest 2, 40% smaller (whatever that means), Snapdragon XR2 Gen2 (they claim more than twice as fast as Quest 2), pancake lenses, controllers without the tracking rings, $500.
Compared to Apple's, the main downsides are lower resolution display (also not OLED), slower, no eye tracking.
Main advantages are price, support for games/controllers (you can still use hand tracking if you just want to watch movies), and no external battery pack.
Might as well just buy a keyboard with lights built into the keys.
Of course there needs to be somewhere for them to go, but if you can have an open window close to your bench, that solves that problem quite nicely.
Remove that expectation and almost all of the demand disappears.
Automating all the other stuff that's left on the table.
I don't see a problem with relying on a few super popular basic libraries for almost every project.
Errors are still values in Rust - usually as part of the `Result` type - but unlike Go, it actually has tools to let you deal with them in a convenient way, like the `?` propagation operator (https://doc.rust-lang.org/book/ch09-02-recoverable-errors-wi...), or the functions on the `Result` type like `map`, `and_then`, `map_err`, or crates like `thiserror` for defining error types, and `anyhow` for easily converting them when you don't care about the details.
Having access to people who can sit down with you and explain things to you when you get stuck, or who can point out mistakes in your existing understanding or your work, can make a huge difference in the outcomes of students.
If AI gets good enough to fill that role, everyone can have that access (or at least something close enough).