kagenouta

If we're nitpicking, it's Pascal case when it starts capitalized :-p

> x264 and x265 are not hardware accelerated, either.

Huh, TIL.

Though I would also sort of want to know where x264 and x265 were a year in, tbf.

Note that the encoders are slower largely because it's not hardware-accelerated yet.

We can reasonably assume that will change, as basically every major player in the CPU/GPU spaces[1] has signed on to back this. Even Apple is a member.

[1] the exceptions are mostly downstream ARM vendors - notably, Qualcomm

Brave and a couple of others are actually getting extension support in the near term because Kiwi recently went FOSS.

Hard agree. I'd also argue that any meaningful antitrust action we may eventually impose on big tech companies should force this.

If the one thing so far that's led the feds to threaten this is that they wanted to build a modern protocol for cross-service messaging, then there's no sane reason we couldn't have asked for that exact thing as a spec.

Huh, TIL.

> Qualcomm being closed source is the biggest issue with running good (user-respecting) software on phones, since basically every single Android has a Qualcomm processor/GPU.

Actually there are kernel drivers for several Snapdragon platforms now, to the point that a Poco F1 can boot both GNU and AOSP-based systems off mainline.

Which just sort of loops back to how if Web-based chat had a spec with meaningful user traction we wouldn't have any real use for RCS in the first place.

Also how XMPP could have been that spec, if Google hadn't decided when launching (the first version of) Hangouts to go full Ayn Rand while doing it.

Tackling this point separately: the entire reason they do this is because they routinely experiment with side projects and then build the ideas that work well into the services that gain traction. As much as it comes with the drawback of being scattershot in general, it specifically creates a track record for failure with messaging because successful messaging products, as a rule, have network effect - something you can't build when you're playing with three different approaches simultaneously.

For an example of where this works really well, look at how all of their adaptive UI efforts feed into each other:

* The enhancements to multiwindow that were built for foldables became Android's desktop mode, to the point that it was built specifically as a test environment and now underpins DeX etc

* Desktop mode's only hardware requirement is a display output, suggesting in addition that Android apps as a whole are no longer bound to specific 1:1 relationships of UI and form factor. (This is, imo, a much bigger deal than we're making it out to be, and opens up possibilities ranging from hybrid game consoles to mobile content creation to better takes at mobile-powered VR.)

* The existence of a base OS implementation and the fact that it's controlled by the system launcher, a component the user can rip and replace, pretty much ensures that custom ROM communities are already toying with this

* Android supports PWAs - installable, natively-scalable webapps - meaning that when desktop mode inevitably stops being feature-flagged there will be examples of convergent apps that work on day 1

* Desktop support for Android apps enhances those same apps when used on ChromeOS

* Flutter, the toolkit built for Fuchsia - an OS designed from the ground up with this sort of scalability in mind - is capable of targeting all of the above

Not within the spec. Which was sort of the point I was (poorly) trying to make - that it's a huge caveat, but otherwise a decent fallback if and when that changes.

Google is adding an implementation into Messages, and it's honestly not a critical problem if OS vendors are supporting it at that level, but there's still too much we don't know about it imo. Will that be supported by iOS, if and when it supports RCS at all? Will it work for third-party clients, if and when Android gets APIs?

I'm not sure how much optimism I have that this will be anything other than a fragmented mess in the short term.

I, for one, have a bigger problem with it forcing the use of phone numbers as a sign-in method. They're an arbitrary identifier from a legacy system that there's not really a point in continuing to extend, because if your device is capable of anything more advanced than SMS it's also capable of... well, this.

Also KaiOS and the like are making chat feasible even on feature phones.

Don't get me wrong, RCS will be a fine enough fallback (once it's E2E), but standardized chat is the dream.

Am I the only one thinking it's weird that this rolls out on ChromeOS first but other Linux platforms (including Android) last?

Also worth noting that one of Google's long-term goals is to make Android bootable on mainline. They've been slowly upstreaming the patches they built into Android's base kernel, and their Treble roadmap involves further isolating the hardware drivers, to enable running a generic kernel across devices.

Or that you still call your OS "intuitive" after shuffling keyboard shortcuts around so hard that not only is your OS running a completely different set of hotkeys from everything else you use, but so is every app you used that will run on it.

Or after making it a three-key shortcut to take a fucking screenshot.

11 is still early into its public testing phase -- developer previews are essentially pre-beta -- so it's hard to really make concrete guesses at what user-facing stuff will show up in the next version at this point.