> GH shouldn't have promoted LLM usage the way they have
No qualifiers necessary. But try arguing with a lawnmower...
398 karma · joined January 1, 2026
No qualifiers necessary. But try arguing with a lawnmower...
What would that philosophy be about? Sounds apocryphal. Unicode has never done "unification" like that for other languages/scripts?
i/ı/i, ö/ø/ø̈/oͤ: Same same, different codepoints.
Search and sorting is a mess everywhere. Depending on your locale, ö sorts either after o or after z. Sometimes it's semantically and phonetically equivalent to o wrt search but moreoften not. https://en.wikipedia.org/wiki/%C3%96
"State and government" section in https://en.wikipedia.org/wiki/State_(polity)
There is no reason to believe it should be lower than that - or even that low. Or do you have access to research claiming such achievements?
Sibling comment estimates lower bounds of current research at minimun 10^6 overhead which sounds more realistic.
Project intro talk from 2023: https://www.youtube.com/watch?v=kqDFdKUTNA4
Nobody's calling for outright banning of cameras. It's about the way these and their feeds are being deployed, integrated and utilized.
The repo and the account were locked again, so I opened another ticket with GitHub. Their automatic fraud detection is “very frustrating.” No idea how long it will take. Last time, it was bots that reported the repository en masse. Let's see what the reason is this time...
This time, GitHub didn’t notify me about the lock; a user reported it to me.
The mirror on GitLab is online, and the CDN links from jsDelivr are still working.
> Which makes the exact situation that occurred here possible.
Not so. The situation here was operator errror and someone mistakenly committing signing key in cleartext to repo. So this exact situation would not be possible. They could also have a process of signing on a dedicated instance (possibly with its own shard) which would remove key exposure completely from operator machines. This is all achivable with existing tooling and without changing implementations on verifier side.
The first link shows how an actual threshold signature scheme for PGP could be constructed.
This will not do. Try harder. I believe in you.
Stop putting sensitive stuff there.
Self-hosting classic forge is great but does require domain name and infra with uptime. These p2p solutions are more like bittorrent where you can clone as long as someone is seeding and git already has commit signature as building block for trust.
Codeberg has 0 paying customers. It is a non-profit providing services for free and not a business.
Membership in the non-profit requires fee paid by EU bank transfer and gives voting rights on questions like this but is separate accounting from use of the free sevices.
All this is explained front-and center or codeberg.org.
.env files for creds are a convenience for dev and testing. They were never supposed to be used for security or carried around with sensitive stuff inside. None of this is new.
The requested feature wouldn't be a robust solution here either for the same reasons.
Besides, have you noticed the amount of other amateur-hour bugs anf jank in Codex going for weeks or months without proper resolution? Given that, why would you want and trust their solution here over alternatives, specifically?