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.

Jesus gets crucified.

I’m thinking Ctrl+C quits and Ctrl+S is scroll lock is that correct?

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.

Any PC can do that, it’s called “status after power off” or something like that.

You should be able to export both contacts and texts if the backup app is given contacts permission and to be set as the text app temporarily.

Not sure about the text multimedia. If it’s in the system text database it can be exported, if the Messages app has it in its private data then tough luck.

Well you can probably still back it up to Google.

I mean, the process is not dying in either gif, so…

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

Also, it’s established practice for workers to stagger their off days across the week.

This way both the company and things like services, banks, stores etc. can be available 7 days a week without any undue pressure.

So they’re already well positioned to take advantage of flexible working time.

Mozilla has already shipped strict privacy mode by default in recent versions of Firefox so they’re already a leg up on this.

Google is currently trying to transition people to its own proprietary method of tracking (where the browser itself tracks you) so they would love it if third party cookies were no longer usable for that.

Mozilla has also added a direct tracking feature (anonimized) to Firefox btw. Not sure what their agenda is.

Websites are irrelevant, if third party cookies stop working in major browsers there’s no point in setting them anymore, they’ll be ignored.

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

Looking through the packages available for OpenWRT I would suggest Tcl, Lua, Erlang or Scheme (the latter is available through the Chicken interpreter). Try them out, see what you like.

I’ve actually tried using PHP on OpenWRT and embedded before. It’s not exactly lightweight, it’s a memory and CPU hog. Keep in mind that the kind of machine that runs OpenWRT might only have 32 or even 16 MB of RAM to work with.

Also, PHP is not the first language that comes to mind when doing data processing and/or functional programming. You can but it doesn’t lend itself well to it.

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.

Endeavour differs very little from Arch once you’re past the installer. To the point I’ve never understood why it’s a standalone distro instead of an optional Arch installer, as an alternative to/part of archinstall.