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:

1. No consent required for cookies when being set by or sent to the site you're visiting. Site in this case being the 2nd-level or 3rd-level domain of the host you're visiting (depending on the TLD).
2. As an exception to the previous rule, consent required for any cookie being sent to a server for the site you're visiting that is controlled or operated by any entity other than the entity that controls and operates the site. This is to close the loophole of third parties requiring a hostname in the site's domain pointing at their servers to conceal the fact that they're third-party hosts.
3. Consent required for cookies being set by or sent to any site other than the one you're visiting.
4. The operator of the server or domain setting or sending cookies is responsible for obtaining consent, not the site being visited. If consent has not been affirmatively obtained, it must be assumed to have been denied.
5. Any server or domain that requires consent be obtained MUST NOT present any content that obscures content on the site being visited, that materially negatively impacts viewing of the site being visited, or that materially negatively impacts use or operation of the site being visited. No pop-ups, no overlays, no blocking or obscuring content on the site until the user consents.
6. 1. That should let users simply reject all third-party cookies in their browser and be done with it.

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.

• "action item" = "need to do"
• "offline" = "later"

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.

"Let's touch base offline to align our bandwidth on this workflow." isn't jargon, it's buzzwords. It just translates to "Let's meet after this and make sure you understand how I want that to work.". Just use the ordinary English instead of the buzzwords. A lot of the "confusion" is probably the employees thinking "Just speak English, dumbass.".

Jargon has specific meanings that can't be quickly expressed in plain English. "hack" vs. "kludge" for example. Both have implications beyond the basic "solution to a problem" that take several sentences in English to state clearly but represent things you need to identify often enough that you can't readily spell it out in full every single time. Others, like "mis-bug" (as in "This is a mis-bug, clarify the code and docs so someone doesn't accidentally fix it.") are jargon but the plain English terms are simple enough you ought to use them most of the time.

One big difference, though: when you had to wait in line it was because there were so many people wanting tickets. In this case there's 5 people at the head of the line and each one bought thousands of tickets so there's none left for anyone else. Then they turned around and started selling to everyone else at 100x the price. If not for them, everyone else WOULD HAVE been able to get tickets at the regular price. Completely different situations.

The abysmal results are because every workplace trains people to fall for phishing scams. That change in vacation policy? The real, legitimate notification of it will be in an email from an external bulk-mailing service telling employees to click on the link included. There's nothing in it to distinguish it from a phishing attempt, and employees are supposed to trust it.

Progress is going to require workplaces, schools etc. to:

1. Send official mail from an internal address, not through any external service.
2. Have all email cryptographically signed and email clients are set up to automatically verify signatures.
3. Have information users need to know delivered through the organization's intranet site, with users directed to log in to that and check notifications for more information.