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.

I feel like this could go really well together with Piet.
Just imagine; an album consisting of a bunch of Velato programs with Piet code as the artwork.

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.

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.

Websockets really don’t integrate well with the entire rest of the HTTP stack, instead just repurposing the socket as a free-standing two-way communication pipe.

You can definitely use websockets for requests like regular HTTP, but you have to reimplement things like cookies/session handling, request resumption/retry, duplicated request detection, request timeouts, authentication, etc yourself if you want to use it that way.

I personally much prefer regular HTTP requests for queries/RPC, and HTTP SSE for notification streams, since those are well developed technologies in the web space - and work much better if there’s a middleware in between.

Replies?! Nobody told me there’d be replies!

Well, I did quite literally just get this instance set up, so I guess just posting random comments is necessary.