The "G" in 5G is not the force of gravity, it is not a speed.

5G is the fifth generation of the entire architecture. How towers work, how phones work. How they talk to each other. What infrastructure is in the tower (e.g. servers and CDNs now) and how it is secured. What frequencies are supported, and who can run equipment (such as private commercial networks).

5G towers are entirely software and are directional. They reclaimed all the old frequencies, and now switch down to LTE or Edge as needed for those individual phones (albeit using more capacity because they are less efficient).

So the cellular networks will stand up and shout about how much better 5G is for cellular customers (it's faster! you'll be able to stream a football game on your phone while at the stadium for another football game!) because the tower investment doesn't buy them as much if old phones are taking up a disproportionate amount of bandwidth.

That means you don't potentially get higher bandwidth or lower latency or better coverage, but it is worth noting that a major pitch behind 5G for the carriers is to have a lot more capacity to sell - to be able to have competitive residential internet delivered wirelessly, for example.

It is worth noting as well in the US that while Verizon was deploying millimeter wave towers in urban centers to give more capacity in the most dense areas, T-mobile bought a low frequency band because of the greater range covered by an individual tower. The different networks have different strategies on how to best take advantage of the new architecture.

> I believe the term is "malicious compliance". Apple gets to say that they're "supporting" RCS while still keeping an iron grip on their customer lock-in.

Apple isn't implementing this for iPhone users (they don't care) or for Android users (not their customers). They aren't implementing this for Google (whiny competitor) or even regulators (who haven't asked for it yet).

This is a mobile operator feature, for mobile operators who are now (through Google's prodding or for other reasons) finally caring about RCS after 15 years. End users likely won't have a way to turn this on or off; it will be part of the mobile operator profile.

As such, it will be the specifications the mobile operators have said they want (eg. the GSMA-specified universal profile). For their part, Apple has said they will try to make that profile better.

E2EE between Google Clients and Google Servers does not necessarily mean the approach is even implementable by multiple vendors - for instance, it may assume that encryption keys are always available via a single phone number to key lookup service hosted by Google. Can't really tell - AFAIK they haven't published documentation to aid interoperability either (but please correct me if I'm wrong!)

I am however curious if Apple will make RCS and SMS either-or, expecting SMS to be tunneled through RCS when an operator chooses to enable RCS support for iPhones.

USB/USB4 are protocols

USB-C is a port. it supports many different protocols over it - including things like HDMI and DisplayPort. It also supports 240W power delivery.

Thunderbolt 3.0 is one of the protocols supported over USB-C. It is basically PCIe over a wire.

USB4 is an incompatible protocol from USB 3.0, and is based on Thunderbolt 3.0. Yeah, the 4 isn't a version number but part of the name - USB4 2.0 is unfortunately a real thing.

Thunderbolt 4.0 is a brand, but it is by Intel. Think of it like AMD FreeSync - AMD doesn't actually have any tech there, it is a certification mark so people know that there are certain display technologies present.

Since people seem to be confused (and not RTFA)

"The Linux Foundation provides a neutral, trusted hub for developers and organizations to code, manage, and scale open technology projects and ecosystems."

The Linux Foundation branched way out from just supporting Linux development, and now basically provides collaborative/standards groups as a service. They manage business aspects for random cross-organizational projects. That includes Linux as well as Kubernetes, Hyperledger, and many many others.

In this case, a number of vendors want to define protocols, legal frameworks, etc for an open metaverse, e.g. a virtual user environment not owned and maintained by any one company.

> Should I go on? SMS should have died in 1995.

Yes, but in the context of this article, RCS doesn't fix these.

• RCS is still tied to the phone number/ SIM card
• Carriers can still bill per message
• It often only works in Google's chat app, running off google's servers, because carriers aren't supporting it. Google hasn't bothered making this work on anything other than Android AFAIK.
• It has the same limitations on security as SMS (no encryption in the standard, google has a proprietary addition when using their stack)
• It is still not reliable.

Google has screwed up their natural advantage in messaging apps over a dozen times in the last 20 years. Now they are pushing for a standard that only they care about.

Wake me up when there's an article about Verizon or Orange asking Apple to support RCS. Until a carrier demands it, or at least more carriers support it, this is all desperate noise on Google's part.

> SMS/RCS would be universally supported, if Apple would play ball.

Messages go to an account, represented within an app.

How do you expect Telegram, Signal, WeChat, LINE, Messenger, WhatsApp, etc to tie into the Apple Messages support and the Google Chat App (whatever they call it this month) accounts? Do you expect the carriers to manage letting third party apps tap into the RCS data stream? How will that work if Google chat has their own proprietary E2E encryption features?

It's an open standard replacement for SMS that carriers have broadly ignored, where Google runs the servers on their behalf, and where Google has proprietary extensions for their client to meet 'minimum bar' features like E2E encryption.

large scalar values, gotta collect them all!

If it isn't an App available from the App Store, then why would they think they have to pay Apple anything? For that matter, why would this ruling be about in-app purchases?

These dating services specifically wrote native apps as a way to acquire a wider array of customers. If there was literally no value, they'd just be advertising people to go to their website.

Android and Xbox (plus Playstation, Nintendo, Microsoft, Steam and Epic) also charge fees for buying games/apps and for in-app purchases such as DLC. Most of them charge 30%, though they have a wide variety of ways to get a reduced fee structure (sell more than a certain amount, sell under a certain amount, subscriptions after the first year, etc)

Didn't you ever wonder why Nintendo always has had cartridges or custom disc processes/sizes for physical games? Because they control the manufacturing processes of those, and can take their cut more cleanly that way.

Registered developers != paying developers

This. There are parts like firmware updates where the (Intel) machines are non-interactive. On my 2018 MBP, this part is downright scary - fans, screen, keyboard lights all spin down and the computer effectively acts dead. The process will just restart if you force a power cycle.

Also, a lot of users on iMacs with spinning rust - I think there was a push for HDD in base iMacs for a _long_ time since so many people store photos/video on them and the SSD cost impact was likely judged too high.

> And the operating system mostly doesn't care. It's not like you can drop support for non-T1 mass storage devices, or else your external hard drives would stop working. So there would be no obvious code savings from not supporting pre-T1 Macs, unless maybe they could eventually save a small bit of code in the crypto library.

Yes, but there _are_ features that T1-based macs have not had which were released in 10.15 and 11.0.

And there _will_ be core functionality eventually which requires a M1-based mac as a minimum, at which point macOS 16 (or whatever it is) will drop intel support completely.

It is unlikely we will see intel macs dropped from the supported line-up until then, because the leading features that result in systems being dropped are CPU/GPU feature requirements (SIMD capabilities, 64 bit support, support for a minimum metal family, H.264 encoding in hardware, etc). There isn't really a compelling OS-level featureset that they would need to bump up the supported rev until they just drop intel completely, and it would really grind with the people who are holding off on upgrades to M1 because the new machines don't support their hardware (multi-monitor) or workflow (windows, third party drivers)

There is plenty of reason for a lot of these - the ARM versions have specific hardware for things like 3D rendering and machine language operations like text detection.

If the feature doesn't run satisfactory on supported intel macs, they are not going to enable them. This isn't a new policy and can be seen with past decisions such as limiting H.265 video on facetime or limiting airplay screen sharing, or playback of 4K video.

Just need people on the ground to reboot them.

The M1 Air does not have active cooling.