nous

If that were the main goal why not just ban them from the extension store? Or why allow manifest v3 extensions to block requests at all? Ad blockers still work and this did not kill off any of them. Just forced them to change some of their functions. I don't doubt the executive overlords are happy about the turmoil that this has done to ad blockers but they would be pissed if that was the only or main goal of this as there are still loads of effective adblockers about.

That is a more complex story then that. The manifest v3 changes primary give a lot of security and privacy changes that stop extensions from doing a lot of questionable things in the background on all your page you visit. But that does stop ad blockers from doing a lot of what they currently do - blocking in page elements and modifying the pages you visit. But it does not block them from blocking page requests so ad blockers like ublockorigin lite can still function in a more limited capacity to block ads.

I do think the teams outside of the chrome team are happy for this change - but I don't think the chrome team set out to do this purely or even mainly to block ads.

Besides even if they did it does not change my argument - whom ever buys chrome will likely want to squeeze it for more money then google currently are doing and will likely do far worst things like including ads directly in the browser. Or trying to monetize it in some other way.

I would love it if chrome where maintained by some non-profit foundation. But how likely is that going to be from a court order sell off?

I would rather they split up google in other ways first.

TBH I am not sure this will end well at all. Google needs to e broken up but splitting off chrome? What will that achieve? Chrome does not directly make any money for Google really, they don't sell it, they don't sell ads in it, they don't even collect much personal data though it. No where near as much as they really could if they really wanted to. Google have not been terrible at managing chrome or pushing as much profit out of it as they could.

Instead they are using it to create a good platform for all the rest of their services where they actually make money. So what will selling off this loss leader do for chrome? Most likely it will get bought up by someone else that will want to see a return on investment that wont be using it as a loss leader. Which I can very well see it getting en-shitified like everything else that is purely driven by profit.

Best case it is gets bought by a non profit foundation that can develop and take care of it - but lets be real, they wont have the money to out compete anyone wanting to buy it to make more money.

I personally don't really trust google with my browser either - hence why I avoid chrome. But I would trust anyone seeking to buy it for profit far less and can very well see this as a overall negative if the wrong people buy it (which I see as more likely).

That being said, I don't keep one in my car.

Now is the time to change that.

Um no. Containers are not just chroot. Chroot is a way to isolate or namespace the filesystem giving the process run inside access only to those files. Containers do this. But they also isolate the process id, network, and various other system resources.

Additionally with runtimes like docker they bring in vastly better tooling around this. Making them much easier to work with. They are like chroot on steroids, not simply marketing fluff.

Documentation is generally considered one of the stronger points of rust libraries. Crates.io is not a documentation site you want https://docs.rs/ for that though it is generally linked to on crates.io. A lot of bigger crates also have their own online books for more in depth stuff. It is not that common to find a larger crate with bad documentation.

Not sure why you need an arc mutex to delegate it to the responsible component. Seems like the type of thing that should not cross thread boundaries nor be cloned multiple times.

They refuse to make changes to their C code, so it can cooperate with Rust code via bindings.

I don't even think the rust devs where asking for that. They are refusing changes by rust devs that help with rust while making the c code clearer and even refuse to answer questions about the semantics behind the c code. At least as far as I can see from the outside.

Transactions should be short lived, they block data on the database side from acessing those tables or rows. Best to not jole onto a transaction that long and instead gather your data first or rethink your access patterns to your data base.

But arc does give you a try_unwrap which returns the inner type if there is only one strong copy left. And mutex gives you an into_inner to move out of it. But really transactions should not be held for a long period of time.

Doesn't a lot of the money for the research come from tax payers? And a lot of effort put into tweaking formulas with no real impact just so they can extend the patents? And then they jack up the prices to insane levels so that those tax payers cannot even afford the results anyway... The system is broken and massively abused. It needs to be changed. We might need something to help foster innovation but the current system just stifles it far more then it helps.

TLDR; Install the relevant packages for the language you care about like every other guide tells you do to.

By the end of this guide, you’ll have a robust development setup ready to tackle any project.

And by a robust dev setup they mean the bare minimum packages installed for projects in one of C/C++, Python, Java, or Javascript.

If you really want a robust developer setup look for guides and tutorials about the language you care about. This goes into so little detail on anything that it is basically useless.

Why do we need tests to be understandable by any human. IMO tests that go to that degree do so by obscuring what logic is actually running and make it harder as a developer to fully understand what is going on. I would rather just keep tests plain and simple with as few abstractions around them as possible.

Cypress cy.get('h1').contains('Result')
Playwright await expect(page.getByTitle('Result')).toHaveCount(1)
Testing library expect(screen.getByTitle(/Result/i)).toBeTruthy()

We can nit pick about syntax here and I prefer the cypress one as it immediately tells me what it is doing and I am not even familiar with those frameworks but:

UUV Then I should see a title named "Result"

That tells me nothing about what it is actually doing. How is the framework meant to interpret that or similar things? It is imprecise and I have no way to validate it will do what I expect it should. I do not trust AI or LLMs enough to translate that into a workable test. Even if it works for simple situations like this how does it grow to far more real and complex test cases?

It would be one thing to use a LLM to generate a test for you that you can inspect - but to generate it probably on every run quite likely without being able to see what it did? Um No thanks. Not with the current state of LLMs.

At least I assume it is LLM based as there is no other way to do this as far as I am aware, though they dont seem to mention it at all.