Could you elaborate what does "compiling orchestration prompt" mean?

commons, is something that is eventually being migrated into the main, at least those that are decided to be required for most projects. I don't use apache commons or guava at all in java (now at 25 or 26, depending on project) - there are still some libs that depend on those, but I would argue that most use it out of inertia, than actual need.

As for slf4j, I still don't see any justification for an abstraction layer on top of logging. I never, ever migrated from one logger to another, and even if I did need to do it - it is very easy as most loggers are very similar. E.g. that's why I decided to use log4j2 in my latest project.

The logging implementation should be an application level decision. By using a facade like slf4j a library allows an application using any logging implementation to use it. That’s why libraries should use it.

Rather people unable to setup a static websites where needed.

I hate that I can't do a curl, or automate my curls to retrieve data from the web because I either see some cloudfrare protection or some captcha.

Information is blocked in walled gardens.

Model capabilities are rising slower compared to model pricings. Recent price increases made hiring juniors cheaper and in the short run, not to mention in the long run.

It would be best if distros kept tap on kernel changes and update as soon as possible when they see a security issue fixed.

Sending emails to some big distros would still result with e.g. Gentoo not getting that info because they are not a big distro.

The problem is that the kernel devs (correctly imo) consider all bugfixes security fixes. So the distros need to decide for themselves which ones are important enough to warrant an update. Apparently this one had a quite unclear commit message, so it importance was missed.

Not ideal, but also: shit happens? It's always a balancing act choosing the lesser of multiple evils and most of the time it seems to work ok-ish, which is probably the best we can hope for ;-P

The kernel maintainers don't flag "security fixes" as special, and they have a well-thought-out reason for that, see many other comments in this thread.

That, and they flag pretty much any random patch with a CVE these days, making it harder for distro maintainers to keep up.

For this specific "bug" they took care to not mention any security angle in the commit message, making it extremely hard for an outsider to even realize this was a critical patch. I assume this was because they wanted to push the fix without breaking embargo.

There are so many distributions that it is not possible to notify each one, unless there is some single distribution list for all.

And if you disclose to just a handful, why ignore the rest?

You can look at the code in editor or IDE even when CLI agent is doing work.

I do that when I want to, but for me using agents in IDE is like looking with one eye covered.

Yeah, people learned.

I created a 4 subagents that polled for new tasks, and restart after ~5h.

It was a great run.

They do for any new plan. Those multipliers are only for people that paid annually. After their subscription ends they'll go into token based pricing like the rest of people.

Those multiplier are only for grandfathered Pro an Pro+ plans that had annual billing, basically a way to scare people of out of those plans. Ant new ones (and bussiness+enterprise plans) will be on token based billing since June 1.