Yes: because Apple actually got this added to the spec: https://www.usb.org/document-library/usb-type-cr-cable-and-c... which is the real story IMO (I am impressed no one bothered looking at the Type-C spec update after the Type-C iPhone finally came out)
This actually replaced the analog audio mode (good riddance- whoever thought adding analog audio into a port that also does digital audio was a good idea?)
The problem is that it's a rather confusing Alt Mode.
Basically, it's only supposed to be used for USB-C-to-3.5mm adapters, and it was only implemented by some smartphones. It's not a reliable way to get audio out of a USB-C port, and because it's using the internal DAC the audio quality isn't going to be good anyways.
The proper solution is to use a USB DAC. This provides the same user experience but it actually works with all USB-C devices. Considering the official Apple USB DAC is available for $9, the Audio Alt Mode really doesn't have a reason to exist.
Why is it confusing or bad? Sure, it sacrifices a data line pair, but the same can be said of DisplayPort Alt Mode - if you want 4K@60Hz on DP 1.2 you need to sacrifice USB3.0.
The ability to make this tradeoff should be up to the user.
I am not fully sure I agree with the first part of your assessment, but I share the frustration that a feature like this, which would be useful and is not particularly large, is basically ignored by the working group, while larger, more controversial, and less useful features, like keyword generics, are pursued while the more useful things languish.
As the person who proposed this feature - among lots of other ones for async Rust, like run-to-completion async functions (https://github.com/Matthias247/rfcs/blob/e7fd7042f8069e9126e...), structured concurrency, cancellation tokens, etc) - I can unfortunately share this sentiment. It seemed really hard to land anything in async Rust since the priorities don't seem overly clear. Therefore I put a pause on all contribution attempts and went back to just using Rust as a user.
block_on is a executor that polls a future until it returns ready. If the future is not ready then the executor wait until it is woken up. If you poll a future that relies on a specific runtime (I.g. A async library that uses Tokio) to wake up the executor, with a simple block_on you will get stuck.
A generic block_on in std would be a footgun for new programmers I believe.
I'm curious, so I'll bite: what do you find hard to setup about embedded Rust? Personally haven't found it too bad (this is STM32/Cortex-M though, which is sort of a happy path)
It’s worth noting that this is _allowed_ by the USB-PD spec, but you’re right that 5V @ 5A is not common because it is not required. At least it’s better than the Pi 4 was at launch? :D
"To protect your organization from excessive usage and Denial of Service attacks, we limit the number of allowed content delivery views within a twenty-four hour period. Try viewing the content again later."
C'mon guys, I was reading that 240 page government contract!
I don't, I'm sorry. I also don't think I ever tracked down that part myself (but who knows, it's been years), so it may not actually be true. But it's sure plausible!
People keep using this word when talking about what’s been happening with the internet recently- but they don’t realise how close it is to the actual answer. RSS has been around forever and it’s exactly what is needed. A feed reader can check thousands of blogs, comment sections, youtube channels, newsletters (imagine never being asked for your email randomly ever again), podcasts, whatever.
The real issue is (and should be) discovery. Make feeds more obvious (say, it was integrated into modern browsers. Some sort of first class “feed detected” icon) and then all you need is search, which has also been solved forever (hopefully it stays that way…).
This actually replaced the analog audio mode (good riddance- whoever thought adding analog audio into a port that also does digital audio was a good idea?)