779 karma · joined September 15, 2018
The main issues are just difficulty connecting to networks. When connected it usually works fine, sometimes DNS will randomly fail though.
When I yank to the "kakoune clipboard buffer" in kakoune (a terminal text editor), the X clipboard is updated (again through OSC 52). When I copy something to the X clipboard (either on chrome or some other program), the "kakoune clipboard buffer" is updated [0].
[0]: technically, the kakoune clipboard buffer updates itself from the X clipboard when it is read from.
I also thing (again very minor) that the hinge is too loose. If I have it on my lap and type on it the hinge slowly opens up. I wish there was a stiffer hinge.
I currently have 1 & 2 sync'd ok, but 3 is only one-way. I use the OSC 52 escape sequence (supported by my terminal) to sync a copy on 3 to 1. But I have not figured out how to sync from 1 to 3.
Taqtile's Manifest [0] product does something like this. There are some videos of it here [1] [2]. It's not exactly what you describe w.r.t diagnostics, but instead it's used to speed up training of mechanics/mechanic-like tasks. It uses Microsoft's hololens, so a bit bulkier than these glasses, but it's a cool look into what kinds of tools some of these jobs might have 10-20 years from now.
[0]: https://taqtile.com/manifest/ [1]: https://www.youtube.com/watch?v=G1xNd_n1QyE [2]: https://www.youtube.com/watch?v=CxoczR8-mwU
I think this is a typo, the prize is $1 million. Is this some suffix I am unaware of?
[0]: https://i3wm.org/
[1]: https://swaywm.org/
class A(random.choice([B, C]):
...Also, if you're making a set, use `map[string]struct{}` instead of `map[string]interface{}` as `struct{}` takes 0 bytes whereas `interface{}` takes 8.
Reading local docs, perusing man pages, or just trying to deduce stuff alone gives a lot of deep understanding of some of the tools available to you.
Hot take: taking code form online tutorials is faster to get something working but can lead to low understanding & bad code. Trying to learn things alone is a very rewarding way to _supplement_ learning and I recommend people try it sometime.
In my opinion, what helped me the most is: when an issue arises, like something during an on-call, have the person resolving the issue share their screen and talk through the workflow/debugging process, to whomever is being mentored. The tools/logic/reasoning they use during a live debugging session is invaluable knowledge for incoming engineers.