This is true. I was hoping my educated guess of the outcome would minimize the possibility of anyone attempting this. And yet, here we are - the only losing strategy in the technology sector is to not try at all.
I found this interesting. On both the Chrome blog and this EFF post, there is a quote from AdGuard CTO Andrey Meshkov. One of the quotes is favorable/neutral toward Google, while the other is more negative. It sounds like Meshkov may have changed his opinion.
But yes, my opinion about MV3 did improve with time. Briefly: it is not ideal, DNR is not a full replacement for the blocking webRequest, but their work for the last several years made me hope that they can compensate for what we're losing by other platform improvements.
MV3 is basically MV2 with one tectonic change: replacing persistent background pages with ephemeral service workers. So a large part of this effort actually DID go into MV2.
There's a better question: what if instead of investing huge amount of times into DNR they put it somewhere else? For instance, into providing better tools for extensions to persist their state so that we didn't have to rewrite the extensions from scratch to make them work with the new service workers model? I think it would've been much much much better. Unfortunately, that's how hindsight works.
Yeah, at first I thought of using offscreen documents as a replacement, but it appears that:
1. They're not persistent too.
2. They have a different purpose, they're supposed to be used as a temporary crutch that gives access to DOM features for the time until it's brought to service workers.
> persistent service workers
You're right to write it in cursive, there're ways to prolong the lifetime of a service worker, but they're not persistent anyways. All in all, the only reliable way to live with service worker is to rewrite extensions in a way that allows them to very quickly initialize after the service worker is brought back to life. For some extensions it's easy, for some it's quite a complicated task.
Here’s what I heard: they are okay with such a workaround for now because they realize how hard it is to adapt to the new model, but in the future they’d prefer to see extensions adapt and be able to quickly reinit.
>Despite the fact that the Chrome devs spend considerable resources on fixing the MV3, and the dynamic is definitely positive, there are still many questions left.
Keep in mind that adguard's main product is a desktop version that effectively mitm's all traffic so they can block requests or locally inject JS & CSS directly into the page without needing browser extensions (which is admittedly pretty clever, but I don't like the local proxy approach). Purely from a business perspective, MV3 is actually good for them because it means that this desktop approach becomes the only viable option for full-control over the request lifecycle.
An excellent software project, preservation is a personal favorite ;). I had a look over the blog and GitHub project - but I have one important question that I could not find an answer for: "Which version of macOS is targeted?"
I would assume only the latest or near-latest version, though it is mentioned in this post that they were only recently able to sync source code up to macOS 11.5 (from August 2021).
My theories: either they aim to support a wide array of macOS versions (like Wine), or adopt a "moving target" approach, removing old code and stubs that handle old/removed Mac functions.
I am leaning towards my second theory, as it was mentioned in issue #1337 (heh) that Darwin does not have a stable ABI. That sounds to me like an app built for 10.7 Lion would not run at all on 10.14 Mojave... something that is probably true for real Macs as well.
> That sounds to me like an app built for 10.7 Lion would not run at all on 10.14 Mojave... something that is probably true for real Macs as well.
In practice, on real Macs, most apps built targeting 10.7 Lion will work on 10.14 Mojave. Some apps will be a bit buggy but still basically work.
If you asked about 10.7 and Ventura, then I'd give it more like a 50/50 chance the app would work (possibly via Rosetta 2 depending on your hardware).
Backwards compatibility on macOS is quite bad, and it has gotten much worse in the last few years in particular, but it's not quite as bad as some seem to imagine.
Does anyone know of the the "other" male scream that started showing up around the mid 1990s? It's a more drawn out almost growl-like yeeeeeeeaaarrrrghhhh. Usually in action movies where someone is falling or blown off a tall building or bridge.
It pops up in trailers a lot it seems around that era.
This is referred to as "Gut-wrenching scream". Apologies in advance for the fandom.com link, I know the site is cluttered. There is valuable research here though:
The original recording date here is 1978, though it was not used until 1980. The rights to this sound started with Soundelux, then passed onto Hollywood Edge, and finally Sound Ideas (who bought Hollywood Edge in 2014).
You may be already aware of this, but macOS Ventura (maybe earlier versions too) changed System Preferences to work more similarly to iOS. Lots of scrolling and nearly all the checkboxes are toggle switches.
See, you guys don't understand, they only changed the categories (that's understandable because they added plenty, similar to the permission menu), the content menu and controls remain the same, optimized for a trackpad and mouse+KB combo
One optimized for trackpad and mouse/KB combo, the other is looking like a smartphone UX, you constantly need to scroll, and "tap" on huge controls, not optimized for a mouse pointer, and not optimized for keyboard navigation
Yeah, the hack happened like a day or two before the article was written, and the hack defaced the site with stuff from Serial Experiments Lain. Which in turn has the Schumann Resonance as a plot point. So that could have started a trend in the searches or something that the recommendation algorithms picked up on.
Not currently. The website has this snippet of information:
Note that the app binary must be decrypted to be usable. Also note that you can’t directly use .ipa files right now, you’ll need to unzip it (this may be easier if you rename it to end in .zip first) and get the .app bundle out of it.
I do not think so as the chance of constructing a fleshy eldritch horror is quite high.