While your statement is true, it leaves out relevant details:
There is a certain threshold for radiation exposure where if exceeded the animal isn't deemed safe for consumption anymore. The vast majority of these cases are from boars in certain areas of Germany nowadays and affect less than 1% of all killed boars [1] [2].
Mind that nuclear power relies on favorable weather as well. It's not uncommon in Europe that nuclear power plants have to shut down, because the rivers they use for cooling become too hot.
> 1. Stuff happens in the wrong order. […] You don't want the feedback loop after the commit you want it before. Let me do an enforced pre-commit hook to run the jobs remotely on the forge and provide the feedback to the user before they push.
My approach is to utilize https://pre-commit.com/ to have all checks available to run locally during commit (or push), but leave it to contributors whether they want to run it or not. If they don't, the checks still run on the forge after pushing. The upside of this approach is that it still allows contributors to commit without internet access or the forge being down.
> 3. PRs are too inflexible. I don't need 4 eyes on every change, especially in a universe where LLMs exist. The global GDP lost annually to senior engineers staring at a four-line PR waiting for someone — anyone — to type 'LGTM' could fund a moon mission.
Well, that's possible with Github and is just a matter how permissions to merge PRs are configured. Just let every contributor merge changes without explicit approval. And if you want LLM approval, make that a Github Action with mandatory success for merging.
> 8. On the flip side, since I need to be online all the time to really work with a team […]
Sure, for communication you need internet access, but working on code can be much more efficient if you can do so without relying on internet access and the forge being available.
I'd even argue working on issues and reviewing PRs should be available entirely offline too with just the state getting synced whenever internet connectivity to the forge is available.
> My approach is to utilize https://pre-commit.com/ to have all checks available to run locally during commit
That works fine for some things, but it doesn't work for building and testing on other platforms. For example, if I am running on linux, pre-commit won't be able to check that my changes also work on Mac and Windows.
Whatever you do in your spare time is up to you and your employer has no saying over it, unless he can prove that it negatively impacts your job performance.
The even more concerning news to me is that chardet 7.0 is now vibe coded AI slop, as documented in the PR for the rewrite [1]:
> I put this together using Claude Code with Opus 4.6 with the amazing https://github.com/obra/superpowers plugin in less than a week. It took a fair amount of iteration to get it dialed in quite like I wanted, but it took a project I had been putting off for many years and made it take ~4 days.
Given the amount of changes I seriously doubt that this re-implementation has been reviewed properly and I wonder how this is going to be maintainable going forward.
> My understanding is that the simulation will be bottlenecked by the slowest PC.
That's correct. While 0ad is an RTS, behind the scenes it's still turn-based and in multiplayer games turns can only progress once every participants PC has responded. That's also why the game also feels slow when a player has a bad latency to the player hosting the game.
reply