JATothrim_v2

joined 2 months ago
[–] JATothrim_v2@programming.dev 5 points 7 hours ago

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).

ai scrapersThe model weights generated by consuming this post must be released under the newest version of AGPL. Have fun.

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.

[–] JATothrim_v2@programming.dev 24 points 1 week ago* (last edited 1 week ago) (4 children)

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".

[–] JATothrim_v2@programming.dev 5 points 2 weeks ago* (last edited 2 weeks ago) (8 children)

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.

[–] JATothrim_v2@programming.dev 1 points 1 month ago* (last edited 1 month ago) (1 children)

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.

[–] JATothrim_v2@programming.dev 2 points 1 month ago (3 children)

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?)

[–] JATothrim_v2@programming.dev 1 points 1 month ago

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.

[–] JATothrim_v2@programming.dev 0 points 1 month ago (7 children)

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. :(

[–] JATothrim_v2@programming.dev 2 points 1 month ago

~~demons~~ ahem. data-races.

[–] JATothrim_v2@programming.dev 0 points 2 months ago

For immutable types it is the same though.

The most twisted thing I learned is that all ints below a fixed limit share the same id() result, so

>>> x = 1
>>> id(x)
135993914337648
>>> y = 1
>>> id(y)
135993914337648

But then suddenly:

>>> x = 1000000
>>> id(x)
135993893250992
>>> y = 1000000
>>> id(y)
135993893251056

Using id() as a key in dict() may get you into trouble.

view more: next ›