I've noticed the same when I tried to replace my ultrawide 34" with a Dell U3225QE for my home office the other day. I really wanted to like the Dell since I love the specs, but my head would hurt from the perceived bulge in the middle of the screen, where the curve used to sit farthest before. Stupid brains, really.
Reminds me of the AGNES [0] (Age Gain Now Empathy System), developed at MIT AgeLab. Saw it in action there back when I worked at the lab in the early 10s - I found the broad range of applications in research quite intriguing.
Reminds me of the experimental version of Stanford's CS 140/212, CS 140e, which used Rust to develop a simple operating system kernel for the Raspberry Pi 3B:
I love how it was already clear that it would be Raymond Chen's blog just from the title and domain name. I really enjoy The Old New Thing and his coverage of obscure details that might otherwise be long forgotten.
At least in Germany (where I live), it is entirely normal for the pedestrian lights to be synchronized with the road parallel to it, meaning that turning cars will cross the path of walking pedestrians. However, by law pedestrians have the right of way in these situations (since cars are crossing their path), and generally that is being respected. I'd say that's what sets it apart from the US in that regard.
We even have right on red in some metro areas, though admittedly that's where things can get quite dangerous at times.
I was actually wondering if the driving factor is legal documents. ID cards show names in all-caps letters, which creates the dilemma that your ID might not show your actual name (notwithstanding international standards for travel documents that prescribe transliteration of non-latin characters; see ICAO Doc 9303 Part 3, section 6 [0] for examples)
You can also use iodine (https://github.com/yarrick/iodine/) to tunnel IPv4 data through DNS (useful e.g. when on a captive portal network that doesn't block DNS requests). Performance isn't great obviously, but the concept is fascinating nonetheless.
While I haven't personally tried it (and have since given up on BT audio in my setup), there seems to be a way to extract the pairing key from Windows and have the Linux Bluetooth stack use it (see e.g. [0]), effectively making the Windows and Linux host appear identical to the paired device.
I recently wanted to give my current RPi4 home server a GitOps makeover, migrating services (Home Assistant, Nextcloud and others) to k3s in the process.
What has been an obstacle is the availability of officially maintained Docker images for some of the components I've been wanting to use - afaict neither Argo CD nor Rook have official armv7/aarch64 images (though it seems Argo will release one soon).
Until then, I'll hold off on that pet project until I get my hands on a reasonably priced x86 SFF PC (the ThinkCentre M700 Tiny from TFA looks interesting!).
Thanks for providing some context! Reading your response makes me realize that my initial assumption was probably way too pessimistic - and that the project serves a nice educational purpose.
On top, sparking interest in tech and ham in kids is always a good thing, a reminder about the possible side effects can always come at a later time :)
Not a ham operator, but I'd assume that a transmitter like this will emit a significant amount of noise across the RF spectrum (also, make sure to check your local laws before transmitting in potentially reserved frequency bands, e.g. with the FCC [0], or the Bundesnetzagentur in Germany [1]).
"Working great" in the sense that the modification and integration was pretty painless. In terms of output quality, I've only done a few smoke tests (pun intended) - cooking, blowing smoke over the sensor - with decent results.
I have a Vindriktning with the ESP8266 makeover sitting on the desk behind me, feeding its data into my Home Assistant instance. So far it's working great, except for one annoying detail: I'd much prefer the forced airflow fan to be on at all times, since the constant on-off cycling (around every ~10s) is quite audible and distracting in a quiet environment.
There's also RFC 8058 [0] that proposes to refine the `List-Unsubscribe` header for one-click unsubscriptions. It uses the `List-Unsubscribe-Post` header to indicate that an HTTP POST request can be used to unsubscribe with a single click.
It specifically mentions in section 3.2 that mail receivers are not to crawl this URL without user consent:
> The mail receiver MUST NOT perform a POST on the HTTPS URI without user consent. When and how the user consent is obtained is not part of this specification.
I haven't seen any statistics on how widespread adoption of this RFC is among the major mail providers, though.
I've recently discovered pacdiff [0] to solve that problem, which helped me clean up about 30 leftover .pac[diff|new] files from my everyday desktop machine.