The EU AI act classifies AI based on risk (in case of mistakes etc), and things like criminality assessment is classed as an unacceptable risk, and is therefore prohibited without exception.

There’s a great high level summary available for the act, if you don’t want to read the hundreds of pages of text.

They couldn’t possibly do that, the EU has banned it after all.

Especially if you - like Microsoft - consider “Unicode” to mean UTF-16 (or UCS-2) with a BOM.

Do you have WebP support disabled in your browser?

(Wasn’t aware my pict-rs was set to transcode to it, going to have to fix that)

The first official implementation of directly connecting WhatsApp to another chat system - using APIs built specifically for purpose instead of third-party bridges - was indeed done against the Matrix protocol, as part of a collaboration in testing ways to satisfy the interoperability requirements of the EU Digital Services Act.
So not a case of a third-party bridge trying to act as a WhatsApp client enough to funnel communication, but instead using an official WhatsApp endpoint developed - by them - explicitly for interoperation with another chat system.

I think the latest update on the topic is the FOSDEM talk that Matthew held this February.

Edit: It’s worth noting that the goal here is to even support direct E2EE communication between users of WhatsApp and Matrix, something that’s not likely to happen with the first consumer-available release.

Well, the first tests for interconnected communication with WhatsApp were done with Matrix, so that’s a safe bet.

Version requirements? No rules!

He won’t be allowed to perform at Eurovision with the Windows 95 name/trademark/logo, so it would be hilarious if he switches to a name like Linuxman during it.

This looks really odd in relation to other fediverse software; Why /magic and required to be on the root of the domain? Why hard-require routing the domain part of the user ID when .well-known/webfinger exists? Why is there a X-Open-Web-Auth header which the spec only describes as “its purpose is unclear from the code”?
So many questions.

I definitely like the idea of distributed sign-in, Solid did a decent work of that many years ago after all. This particular proposal just looks rather odd.

Here’s a .jxl JPEG-XL upload I did on Lemmy three days ago;
https://lemmy.ananace.dev/pictrs/image/ad4e745e-0135-4cc3-889c-052600828d82.jxl

The built-in Firefox support is only activated for unstable builds, so you can’t enable it on stable unless you manually enable it during compile-time.

Why is it .jpg and not .jxl? That’s the registered extension for JPEG-XL.

We’ve recently kicked out our entire Cisco networking core due to it actively refusing to interoperate with other pieces of necessary hardware for us, which was causing us to have to run an almost entire second redundant core network. Switching it out with ALE has been really nice in that regard, SPB scales like a dream even between locations and cities, we even get working L2 routes all the way over to some of our locations almost half a country away.

For us, Dell has been the far better of the two (HPE/Dell) big server-providing beasts in terms of just being able to use the hardware they provide, but they’re very close to getting a complete block from future procurement due to how they’ve been treating us.

Honestly, Fujitsu is probably our best current provider; their hardware is reasonably solid, their rack-kits aren’t insane, their BMC doesn’t do a bunch of stupid things, they don’t do arbitrary vendor locking on expansion cards, etc. Unfortunately their EFI/BIOS is a complete mess, especially in regards to boot ordering and network boot, and they’ve so far not been able to provide us Linux-based firmware upgrade packages - despite using a RHEL image in their BMC-orchestrated offline firmware upgrade process.

Got a pair of old HPE gen8 1U servers that are chewing through fan packages like nobody’s business, replaced at least five burnt-out fans on them in a similar amount of years.

We’re running a mix of HPE, Dell, and Fujitsu servers and they all absolutely suck in their individual ways - HP(E) adds a bunch of arbitrary hardware limitations which we have to work around, Dell intentionally degrades our multi-system setups with firmware updates, and Fujitsu’s boot firmware goes absolutely pants-on-head retarded if you’re doing netboot first.

We’ve gotten some Supermicro systems now as well, and they’ve been a real treat in comparison, though their software UX feels like it’s about two decades behind.

I don’t get the “Game Porting Toolkit” they made, content-wise it basically looks like a regular Wine packaging - much like what Proton is, but then it has one of the strangest licenses I’ve ever seen for something designed to help development and shipping.
To paraphrase, you can’t include any part of the toolkit with your product. Not the development components, the runtime components, the translation layers, nothing. So good luck using it to actually ship game ports, since that would be a license violation.