It depends on the Discord server. At minimum, they'd have an email address that the user controlled at least at some point (to confirm it). Due to spam bots, a lot of servers require a phone number verification via SMS as well.

There are multiple companies that provide bulk SMS sending for corporate use (plus some large companies do it themselves). All my notifications are from such senders - I don't get any email-to-SMS gateway messages. Bulk senders would otherwise get blocked; the email-to-SMS gateways have low rate limits. Even things like restaurants that use SMS to notify waiting customers a table is ready use real SMS senders, not email gateways.

Email-to-SMS (at least on the carriers I've seen) is really obvious and stands out as weird (which no sender wants), and the only time I remember seeing it was when I was testing it for personal use.

Email-to-SMS has always been a lightly-documented, "best effort" (don't call support if it doesn't go through or is delayed), and probably lightly-used service. Due to email abuse, it's never going to be a service that doesn't cost some money to support, so I can see it getting the axe from all the providers. I also wonder if the shift to RCS meant they were going to have to spend development money to keep it working and decided it wasn't used enough.

I've been on T-Mobile for ages, and I've seen their email-to-SMS gateway be unreliable at times, with no real effort apparent to update it.

For my personal stuff, I shifted to Pushover (one-time $5 fee, per receiving-platform but I only use one platform to receive), which a lot of things already support and can easily be called with a simple wrapper around curl. For a couple of email-only things, I have a special address in my own domain and a procmail rule to forward to Pushover.

See the list at Rabbit Ears - stations highlighted in red and with a lock icon next to them have encrypted their ATSC 3.0 signal:

https://www.rabbitears.info/ma...

It's not just approved for experimental use, it's fully approved for use. It's voluntary, not mandatory, and stations must still maintain an ATSC 1.0 signal, but they can satisfy that by getting together and compressing multiple primary channels (e.g. the major broadcast networks, leaving out public and independent broadcasters) into a single ATSC 1.0 channel. Broadcasters get together, put the ABC, CBS, FOX, and NBC primaries on one or two over-compressed ATSC 1.0 signals. Then they can each move all their additional channels to ATSC 3.0 only, and flip the DRM flag.

This isn't conjecture or "how it could happen", this is fact in multiple markets. And it's been successful enough that now they are pushing to make it a mandatory transition and drop the ATSC 1.0 requirement (and then drop ATSC 1.0 completely).

That'll work right up until the broadcasters in your market flip the ATSC 3.0 DRM flag, at which point you'll lose all DVR functionality. SiliconDust has said they're "working on" DRM support... for several years.

The ATSC 3.0 DRM parts were already approved and are already active in many markets. It's not a proposal, it's in use... the only proposal here is to force the end of ATSC 1.0 (probably hoping for another handout for set-top boxes for all the TVs that don't support ATSC 3.0).

LG (IIRC) included ATSC 3.0 tuners in one generation of TVs, then dropped it over the licensing fees. TV makers don't mind the Internet requirement - they'd like for you to hook that up so you can get THEIR ads, not the broadcasters'.

ATSC 3.0 DRM is already active in many US markets - it is quite different from the NTSC->ATSC 1.0 transition. Stations transition to ATSC 3.0, get everybody comfortable, and then flip the DRM flag. It's the end of antenna DVRs - it's basically reimplementing cable over the public airwaves, with no Cable Card-like mandate (since the Cable Card mandate is also dead).

I tried to skim through the article and it seemed to jump around a bit. The thing I didn't see is how a more-accurate small-scale atomic clock replaces the need for GNSS. While yes, GNSS is based on accurate time, it's the reception and comparison of the time signals that give you distance to each transmitter (satellite) and so your current position. Having the time on board doesn't help with positioning.

Accelerometers are mentioned, which would be for inertial guidance... but if you have good inertial guidance, you don't care what time it is. And if you don't have good inertial guidance, the time still isn't going to help.

That's only true if you link Chrome to a Google account, and also assumes you only use Chrome linked to that account for browsing (no other browser, no other account). That's a very "give Google your life" approach.

But part of the problem is also the assumption that a known password is "compromised" and "out in the open". I reset a managed switch to factory defaults (in preparation for selling), and Chrome kept trying to get me to change the password. It's on my local network (so not "out in the open"), it's not compromised (just a default), and no I'm not going to change it so the next person has to do a password reset just to get into the config.

No, automated password change is NOT fine. A browser has no idea what that password is, why it is what it is, where else it may be used, who else may need the password, and more.

Hector Martin didn't like the technical process for patch submission so threw in "shaming on social media" as an approach... that did not win any friends.

Peak enshittification is people throwing the word enshittification on everything they don't like.

Maybe we don't live as long just because we don't want to.

The original owner DID sell the site a long time ago... Amazon bought it in 1998. It's been operated as a subsidiary since, with the founder staying on as CEO of the subsidiary until now.