They existed before LLMs were spitting code like today, and this will undoubtedly lower the bar for bad developers to enter.

If LLMs allow bad programmers to deliver work with good enough quality to pass themselves off as good programmers, this means LLMs are fantastic value for money.

Also worth noting: programmers do learn by analysing the output of LLMs, just as the programmers of old learned by reading someone else's code.

Claude is laughable hypersensitive and self-censoring to certain words independently of contexts (...)

That's not a problem, nor Claude's main problem.

Claude's main problem is that it is frequently down, unreliable, and extremely buggy. Overall I think it might be better than ChatGPT and Copilot, but it's simply so unstable it becomes unusable.

Aside from the obvious UX disaster, Git has some big issues:

I find this blend of claims amusing. I've been using Git for years on end, with Git LFS and rebase-heavy user flows, and for some odd reason I never managed to stumble upon these so-called "disasters". Odd.

What I do stumble upon are mild annoyances, such as having to deal with conflicts when reordering commits, or the occasional submodule hiccup because it was misused as a replacement for a package manager when it really shouldn't, but I would not call any of these "disasters". The only gripe I have with Git is the lack of a command to split a past commit into two consecutive commits (a reverse of a squash commit), specially when I accidentally bundled changes to multiple files that shouldn't have been bundled. It's nothing an interactive rebase doesn't solve, but it's multiple steps that could be one.

Can you point out what is the most disastrous disaster you can possibly conceive about Git? Just to have a clear idea where that hyperbole lies.

Remembering ActiveX Controls, the Web’s Biggest Mistake:

Running JavaScript everywhere is looming as one of the biggest screwups in InfoSec. What do userscript extensions like Grease monkey teach us?

So you started with the need to authenticate, which should be documented in the requirements. You know, the things that are required to happen.

I think you're confusing documentation with specification.

Requirements are specified. They are the goals and the conditions in which they are met. Documentation just means paper trails on how things were designed and are expected to work.

Requirements drive the project. Documentation always lag behind the project.

"GitUI is amazing, although unusable."

what is the usecase for going beyond maxint?

There are many examples of applications that leverage integer overflow, either wrapping around or saturating values.

appears to be a weak patch.

It's not a patch. It's eliminating an attack vector, and the one which is more pervasive and easier to exploit.

Security-minded people pay far more attention to what software you run than what hardware you have.

For Signal, no.

There is an argument to make about using custom versions of Signal that route their traffic through your own infrastructure.

This would count as France running their own service.

Given that Signal relies on centralized servers to route traffic, and if I'm not mistaken they use AWS in US instances, this means that your Signal traffic is being fed straight into the US security services' infrastructure. France might be a staunch ally of the US, but they do go through great lengths to preserve their independence.

You used the wrong search bar, you just used the one for the file list.

The fact that one of the excuses for GitHub search results being subpar is that there is a right and a wrong search bar is already telling.

What do you mean by "build step"? For example, does running a barreler count as building?

I agree. The GIL and packaging woes are a good indication that it's range of applications isn't as extensive as other tech stacks.