I doubly agree to this. The moment you are deciding the license of your fucking software please think carefully. It is a public service and the dev(s) ow you nothing. Not even an apology. What you own to the devs is much greater and very high on value. They made the software that runs on your own paid electricity, that you granted to them.

find a new person to replace him

There is no replacement to his knowledge of the project. He can try teach it to another person, but there is the problem of trust.

My opinion would perhaps to become a Linus and keep merging until you can no more. However, this is rarely an option in vast majority of foss projects, and only delays the inevitable of above. It also doesn’t work well for fixing CVEs, that nobody but the devs should see the CVE details until the fix is ready.

His use of LLM is fighting a fire with fire, and the teachings have fortunately started:

Luckily I’ve been joined by some other very good developers with great systems development skills and security knowledge.

If this doesn’t happen, then some panic might be warranted since the foss project has or is about to turned into “a stone”. (the last dev with deep knowledge has left the project).

The disk is likely dead… The kernel is stuck doing I/O with a spinlock held. The NMI watchdog fired/timeouted because of this. The watchdog is supposed to cause a reboot, but if the HW is dead, the system will boot loop.

If you try to “help” by taking control, you’ll soon find that all the similar tasks are delegated to you and no learning takes place at all. So your only option is to just watch them fail and bear suffering.

Every technology invented is a dual edge sword. Other edge propulses deluge of misinformation, llm hallucinations, brain washing of the masses, and exploit exploit for profit. The better side advances progress in science, well being, availbility of useful knowledge. Like the nuclerbomb, LLM “ai” is currenty in its infancy and is used as a weapon, there is a literal race to who makes the “biggest best” fkn “AI” to dominate the world. Eventually, the over optimistic buble bursts and reality of the flaws and risks will kick in. (Hopefully…)

I posted this 9 months ago, and we are now at somewhere “brain washing of the masses, and exploit exploit for profit”.

I have lately jokingly guessed when I see the particular style and confusion: it’s you isn’t it? And so far I have been right. The particular author’s magic has expired, and I see the same fault replicated everywhere he has been.

I’m not a copyright-lawyer, but I think there are implications on who has authored the code, so preserving this detail can be important. The fancy copy reduced my blame by +90% on the final result.

git blame output can be affected by e.g. ignoring white-space changes.

Why are you copying a file?

I’m splitting a several thousand LOC file, which I don’t have previous history in.

Like, maybe I’m just too familiar with git to see the forest for the trees, but what the heck are you doing over there?

Normally copying a file and committing transfers the authorship to you, because the copy just appears from nothing as a brand new file, never known to git. This would prevent browsing the per-line “who changed this last” history past the copy and obfuscate who wrote what and when.

(why the downvote?)

Additionally, A update can ship a new stock version of a config that has fancy new options and some deleted ones, and your modifications to it in /etc can conflict.

Arch can either backup your version as .pacsave or install the updated file as .pacnew. It’s your task to merge your modifications to the updated configs, and these files can slowly pile-up over time until something breaks.

Replicating git history for a file takes 1 merge commit and 3 commits, and this is propably one of the most complex workflows I have encountered:

(might not be correct...)
git checkout -b work
git mv file file.tmp
git commit
git checkout -b copy HEAD^
git mv file file2
git commit
git checkout work # can be skipped if you merge "work" instead.
git merge copy # "work" and "copy" must conflict, stage file.tmp and file2 and commit the result.
git mv file.tmp file
git commit
<git blame is identical for file and file2>

I would love to squash this into a single commit, but git doesn’t have a copy operation or detection. :(

demons ahem. data-races.