They're legit trying to lock down general purpose computing devices. Even though they term this as 'child protection', this can be easily abused to lock everyone out of system modification. The heads of the corporations that sponsor this and legislators who took their money should be dragged out of their offices and paraded in a perp walk.

There are other applications that use suid (like newuidmap). And there are programs that use capabilities (like ping). I'm pretty sure that this logic will be used to justify assimilating those applications too. But I'm sure that the crowd will cheer them on as if they did something revolutionary.

Only users who don't know rebasing and the advantages of a crafted history make statements like this. There are several projects that depend on clean commit history. You need it for conventional commit tools (like commitzen), pre-commit hook tools, git blame, git bisect, etc.

You can have both. I'll get to that later. But first, let me explain why edited history is useful.

Unedited histories are very chaotic and often contains errors, commits with partial features, abandoned code, reverted code, out-of-sequence code, etc. These are useful in preserving the actual progress of your own thought. But such histories are a nightmare to review. Commits should be complete (a single commit contains a full feature) and in proper order. If you're a reviewer, you also wouldn't want to waste time reviewing someone else's mistakes, experiments, reverted code, etc. Self-complete commits also have another advantage - users can choose to omit an entire feature by omitting a commit.

Now the part about having both - the unedited and carefully crafted history. Rebasing doesn't erase the original branch. You can preserve it by creating a new branch. Or, you can recover it from reflog. I use it to preserve the original development history. Then I submit the edited/crafted history/branch upstream.

Because their name is Elon Musk.

Leap years are not as bad as timezones, if you think about it. Timezones try to imperfectly solve a local problem - how to match your clock with the position of the sun. Leap years try to reasonably solve a global problem - how to keep your calendar aligned with the seasons.

So you're just spouting some cooked up theory. Not a practical scenario.

If that's so trivial to trigger, people would be doing so everywhere. Have you seen it in the wild or heard of anyone doing so?

I have KOReader on mine. It's a great combo. The only problem is that kobo in general consumes battery charge fast.

I assume you are talking about dependency versioning. That's hard on regular Linux distros. However, it's easy on nix and guix.

I use git almost every hour and I rarely have to deal with git problems (just enough practice to avoid them). I'm also confident about resolving problems if they do arise. Heck, I even configure my entire system and manage my life using text files managed by git. So I don't claim that it's all that bad.

But if you want me to give concrete examples of how problematic git UI can be, you are so far removed from reality and are neglecting the very visible and vocal struggle git beginners have. I'm saying this as someone who trained a lot of people in using git from the very beginner level, all the way up to emailing patches - as part of a community and as a corporate trainer. I can write essays about every single problem that can trip a beginner due to git's inconsistency - but am not going to - because they are acknowledged problems (by git devs) and they actively work on it.

this appears to be a very reasonable move

There are a few problems with this:

1. The company wasn't ready for the concessions it had to make when they started the project as open source. This though, may be the most forgivable issue. They couldn't have predicted that big parasitic SaaS and LLM players would make their business unviable.
2. There may be some contributors who wouldn't have contributed if they knew this was going to happen. Generally speaking, never sign away your rights. CLA and copyright assignments should be avoided like plague. The maximum you should settle for as a contributor is a DCO.
3. Hashicorp is still trying to pass this off as open source of sorts. They say nothing has changed. But this change puts them squarely outside the definitions put forth by either FSF or OSI. This will cause their ejection from several software repositories. They should just be honest about it.