It will fall through much faster than that. I’m thinking two years, tops.

You don’t have to install drivers or CUPS on client devices. Linux and Android support IPP out of the box. Just make sure your CUPS on the server is multicasting to the LAN.

You may need to install Avahi on the server if it’s not already (that’s what does the actual multicasting). The printer(s) should then auto magically appear in the print dialogs on apps on Linux clients and in the printer service on Android.

On Linux it may take a few seconds to appear after you turn it on and may not appear when it’s off. On Android it shows up anyways as long as the CUPS server is on.

From what I understand OP’s images aren’t the same image, just very similar.

short of all using the same wordpress or whatnot hoster, that is.

That’s the thing, that’s common practice. It’s basically a given nowadays for shared web hosting to use one IP for a few dozen websites, or for a service to leverage a load/geo-balancer with 20 IPs into a CDN serving static assets for thousands of domains.

with infrastructure the size of twitter you can also blackhole their whole IP range

Just one note, services the size of Twitter typically use cloud infrastructure so if you block that indiscriminately you risk blocking a lot of unrelated stuff.

It stops working occasionally but they release fixed versions pretty fast.

Bayesian filters are statistical, they have nothing to do with machine learning.

You should consider if you really want to integrate your application super tightly with the HTTP protocol.

Will it always be used exclusively over a REST-ful HTTP API that you control, and it has exactly one hop to the client, or passes through hops that can be trusted to never alter the HTTP metadata significantly? In that case you can afford to make HTTP codes semantically relevant for your app.

But maybe you need to pass data through multiple different types of layers and different mechanisms (socket protocols, pub-sub, file storage etc.) In that case you want all your semantics to be independent from any form of transport.

It’s a perfectly fine way of doing things as long as it’s consistent and the spec is clear.

HTTP is a transport layer. You don’t have to use its codes for your application layer. It’s often done that way but it’s not the only way.

In the example above the transport layer is saying “OK I’ve delivered your output” which is technically correct. It’s not concerned with logical errors inside what it was transporting, just with the delivery itself.

If any client app is blindly converting body to JSON without checking (at the very least) content type and size, they deserve what they get.

If you want to make it part of your API spec to always return JSON that’s one thing, but don’t do it to make up for poorly written clients. There’s no end of ways in which clients can fail. Sticking to a clear spec is the only way to preserve your sanity.

They buy the hardware once then sell services based on it.

Because AI reversed the ratio.

It’s much worse. Generally speaking projects in large corporations at least try to make sense and to have a decent chance to return something of value. But with AI projects is like they all went insane, they disregard basic things, common sense, fundamental logic etc.

They typically use internal personnel and being parcimonious about it so you’re right about that.

Well probably not just Nvidia but the next likely beneficiaries are in the same range (Microsoft etc.)

The most successful ML in-house projects I’ve seen took at least 3 times as long than initially projected to become usable, and the results were underwhelming.

You have to keep in mind that most of the corporate ML undertakings are fundamentally flawed because they don’t use ML specialists. They use eager beavers who are enthusiastic about ML and entirely self-taught and will move on in 1 year and want to have “AI” on their resume when they leave.

Meanwhile, any software architect worth their salt will diplomatically avoid to give you any clear estimate for anything having to do with ML – because it’s basically a black box full of hopes and dreams. They’ll happily give you estimates and build infrastructure around the box but refuse to touch the actual thing with a ten foot pole.

There’s been talk about exploring porting the engine to iOS at the beginning of 2023 but AFAIK the current state of things was that it’s a significant undertaking and probably not worth it just for the EU market.

There’s no Firefox engine for iOS and Mozilla says it doesn’t make financial sense to port it.

If you go forward 12 months the AI bubble will have burst. If not sooner.

Most companies who bought into the hype are now (or will be soon) realizing it’s nowhere near the ROI they hoped for, that the projects they’ve been financing are not working out, that forcing their people to use Copilot did not bring significant efficiency gains, and more and more are realizing they’ve been exchanging private and/or confidential data with Microsoft and boy there’s a shitstorm gathering on that front.

For now, but the EU will force Apple to allow non-WebKit engines on iOS. At which point only Google will have enough money to spare porting an entire engine to a small market.