Source addresses of the attack are known. The ISPs know which customer was using that address at that time, and dealing with the customer is their problem not the attack target's. If they don't deal with it, they get to deal with lots of angry customers who've suddenly lost connectivity to the majority of the Internet because entire blocks of the ISP's address space are being blocked by Cloudflare et. al..
Time for a law that says that if the manufacturer removes any functionality from a product that was present when it was purchased or originally offered for purchase, any owner of that product is automatically entitled to a refund of 100% of the original purchase price (if they can provide a receipt) or 100% of the initial manufacturer's recommended price (if no receipt is available) upon demand. The manufacturer may, if the owner can't present a receipt, require the owner to provide the serial number, photograph of the serial number and/or photograph of the entire item to claim the refund, and may require the owner to return the item at the manufacturer's expense.
It's time to go after the source of the problem: the compromised devices. Identify them and force the ISPs that serve them to block outgoing traffic from that customer, on pain of having entire netblocks blocked by Cloudflare etc..
At a minimum repositories should require that all packages be signed by the maintainer(s), with signatures verified upon download by keys not fetched from the repository itself. The tech is already there using GPG. The main thing that should be added is that the repository should sign maintainer GPG keys after having verified that that maintainer owns the packages signed by his key, that way clients can check for that as well and avoid packages signed by keys that don't own the package. Best practice here would be for maintainers to use a separate key for signing packages.
Requiring 2FA and such would be recommended, but with signature checking even if an attacker compromised the maintainer's account on the repository they still couldn't upload a package with the correct signature.
This won't solve the problem of maintainer systems being compromised, but that's a very non-trivial problem to solve. Nor would it solve the problem of a maintainer giving legitimate privileges to upload official packages to a party they don't realize is untrustworthy, but again that's non-trivial to solve. Neither of those problems is something there's a technical solution for, I'm afraid. And of course it creates a problem with key rollover and succession, getting clients to use the new keys at the correct point, but that merely requires some effort to get the protocol right.
This is one of those "practitioner skilled in the art" kind of things. We've had SQL and UML for ages that use and visualize parent-child relationships. Once you know them, this is an obvious application for making queries about the relationships. Given how ubiquitous trees of various kinds are, I doubt their specific implementation is particularly novel.
Most of the things people complain about involve third-party cookies of one sort or another. Very few people would object to most first-party cookies or the reasons they're used. After all, if you visit a site obviously they know everything you do there. So, my ideal rules:
I haven't seen much if any slow-down as I age, and I'm 60. What I have seen is that I spend more time thinking so I write less code to get the same result and need to do less debugging to get it working correctly. I also have a bigger library of code I can use without having to write it all from scratch so again I end up writing less code. This last is especially true for tests, and I already know the corner cases and odd cases out that many of my co-workers don't even realize need tested. But the correct measurement isn't "How much code do you write and how quickly?" but "How much time and effort does it take for you to get the functionality production-ready?". There I (and my managers) can see a clear difference between those who do it fast vs. right.
One would think, right? Yet there's a constant stream of "new" done-to-death games in the Play Store that exist solely to appear at the top of the listings (because they're newer) and attract clicks to the ads in them. The people who write those games absolutely would use AI to do it if it'd let them do it faster, and we'd see that in the number of new releases (those lists don't care about how substantial the software is). It'd also make it less boring to create Yet Another X Clone. So, as Mike asks, where is the uptick in the number of these titles?
The problem with this survey is we can't trust developer estimates of how long it took them or how much time they saved. The METR report and Mike Judge's write-up show that quite clearly. Talk to me when Fastly includes actual timings of how long developers actually took to do the job with AI vs. without showing a statistically significant difference.
What exactly does Agility's robot do that can't be done just as easily by a fixed robotic arm with an attachment to grab and hold the baskets? The fixed arm would be cheaper and wouldn't have battery-life issues, and probably would require less maintenance (fewer moving parts). This sounds like a solution in search of a problem.
Let's see him do without janitorial staff at his office for a month or three. Or without the people to mow his lawn or clean his house or prepare his meals.
Long-term, societies based on a shared ideology don't survive. Whether because of immigration or children just not agreeing with their parents' ideology, they quickly end up with a population that doesn't share a single ideology. Then either the society learns how to deal with sharing territory but not ideology, or it kicks the non-conformers out and dies as it can't replace it's population, or it turns into a police state/cult compound. That last one doesn't end well either unless it starts out the size of a small country and manages to avoid being inside the jurisdiction of another country.
When the society is being founded by grifters and con artists, implosion's going to happen even faster.
This is probably the worst approach they could take. The biggest problem with AI and mental health is the AI encouraging the user to harm THEMSELVES, not others. The vendors need to detect when that's happening and disconnect the user from the AI until they seek help, or alter the AI to not take users down those paths in the first place. But they'll never do that.
This is where we really ought to look into the state of jurisdiction regarding businesses who are not located in a state, do not have offices in a state and do not target users in that state. This has come up before when it comes to taxes and other state laws, and I'm pretty sure it's ended up with binding rulings at the Federal Appeals Court level if not the Supreme Court level.
Those cover the meanings exactly or at least exactly enough that the alternatives don't change the intended meaning. By contrast, "starboard" and "port" are used because "right" and "left" are ambiguous, are they "my X", "your X" or "ship's X"? "dorsal" and "ventral" come from Latin terms used in science, there are equivalent terms in ordinary English but using the Latin allows distinguishing between casual references and technical ones ("dorsal" means different directions depending on the organism's neural tube).
A good rule of thumb is that if you use terminology when speaking to someone not in that terminology's field and expect them to understand it, it's not jargon.
People are always available for work in the past tense.
