You should be ashamed of being involved in this monopoly handover to American big tech.

If you are a serious software developer, then you will probably be able to explain both what your code does (i.e. what spec it implements) and how it does it (what does it call, what algorithms does it use, what properties does it rely on?). With the advent of LLMs, people have started to accept not having a clue about the "how", and I fear that we are also starting to sacrifice the "what". Unless our LLMs get context windows that are large enough to hold the source of the full software stack, including LLM-generated dependencies, then I think that sacrificing the "what" is going to lead to disaster. APIs will be designed and modified with only the use cases that fit in the modifying agents context window in mind with little regard for downstream consequences and stability of behavior, because there is not even a definition of what the behavior is supposed to be.

I have started using Claude to develop an implementation plan, but instead of making Claude implement it and then have me spend time figuring out what it did, I simply tell it to walk me through implementing it by hand. This means that I actually understand every step of the development process and get to intervene and make different choices at the point of time where it matters. As opposed to the default mode which spits out hundreds of lines of code changes which overloads my brain, this mode of working actually feels like offloading the cognitive burden of keeping track of the implementation plan and letting me focus on both the details and the big picture without losing track of either one. For truly mechanical sub-tasks I can still save time by asking Claude to do them for me.

For example, if one is frequently doing "fix after rebase" commits, then they are doing it wrong and are making a history which is much less useful than a seemingly more complicated merge based history. Rebased histories are only clean if they also tell a true story after the rebase, but if you push "rebase fixes" onto the end of your history, then it means that prior rebased commits no longer make any sense because they e.g. use APIs that aren't actually there. Giving up and squashing everything to one commit is almost better in this case because it at least won't throw off someone who is trying to make sense of the history in the future.

I think that rebasing has won over merges mostly because the tools for navigating git histories suck SO HARD. I have used Perforce at a previous job, and their graphical tools for navigating a merge based history are excellent and were really useful for doing code archeology.

Locking down computing is just fundamentally wrong and leads to an unfree society.

It also depends on the criteria on which you judge it. I may be better in terms of compatibility because everything would be an expensive walled garden like Apple's. It would be worse in terms of choice because niche peripheral makers might not be able to enter the market at all. And it would certainly, almost guaranteed, be much much worse in terms of personal freedom because no-one would be allowed to modify any parts of any piece of software without some cryptographic hardware module stopping them. Imagine that situation, and then imagine how a government would use that to impose surveillance on all personal computing devices.

Also, replace "consumers" by "people" who might need to control their devices to do things that may be against the interests of the manufacturer, like removing ads and surveillance.

Google Play Integrity is not a requirement, but governments think it is. All you need to avoid trivial duplication of certificates is that keys are bound to a device which is also able to perform the primitive cryptographic operations needed to construct a ZKP proof. This could be achieved using a USB dongle. Still proprietary technology, but the scope of what needs to be locked down is much, much smaller than with a solution like Play Integrity.