2,744 karma · joined November 8, 2016
Using a very few selected companies as auditors feels like an odd decision. I'd have rather preferred some kind of web-of-trust like CAcert.org does.
And then there is the final nail in the coffin:
> When Automatic Key Verification is turned on, the Signal client periodically fetches Merkle tree heads from the Signal key transparency server. The client requires that each tree head belong to a lineage endorsed by all registered auditors within the last seven days. If the server does not present valid auditor signatures, the client will raise a warning and Automatic Key Verification will fail. A fully malicious server may therefore maintain a split view of the system for at most one week before client applications start to display warning messages.
(from https://blog.trailofbits.com/2026/08/11/how-trail-of-bits-he...)
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].
[1]: https://www.deutschlandfunk.de/fast-3000-verstrahlte-wildsch...
[2]: https://www.wildtierschutz-deutschland.de/_files/ugd/173a38_...
https://energy-charts.info/charts/price_spot_market/chart.ht...
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.
> 4. Stacked PRs are just better. […]
Seems like Github is working on this: https://github.github.com/gh-stack/
> 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.
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.
> 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.
That the CPU cores are low frequency cores probably helps with yield as well.
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.
If you're interested in progress in this area, I suggest you keep an eye on https://gitea.wildfiregames.com/0ad/0ad/issues/7945
Arch Linux used system-provided SpiderMonkey which lacked a crucial bug fix. This issue should be solved by now, by Arch Linux switching back to vendored Spidermonkey.
Check out https://gitlab.archlinux.org/archlinux/packaging/packages/0a... and https://gitea.wildfiregames.com/0ad/0ad/issues/8757 for details.
There is also a thread in the forum, where people are brainstorming about an official campaign: https://wildfiregames.com/forum/topic/123956-narrative-campa...
We're not calling it Alpha anymore, but we still don't consider it a polished major release. The announcement of the last Alpha, Alpha 27 had a section explaining the motivation for the change: https://play0ad.com/new-release-0-a-d-alpha-27-agni/
> Only for really huge end of game final battles with the screen packed with troops did it lag out for us, but being free and all, we'd often gather around one monitor and talk crap at each other while we waited for it to clear up.
I'm not sure when you last tried the game, but a27 notably improved performance and feedback so far suggests that r28 did as well.
When a player looses the connection the game just continues. Usually one of the remaining player then pauses the game until the player who lost the connection returned.
The game state becoming out-of-sync is often a problem of players using buggy mods. That this happens without mods is pretty rare and of course clearly a bug.
> It's also impossible to save and restore in multiplayer.
It seems you haven't played 0ad in a while, as that's possible since a27 (see https://play0ad.com/new-release-0-a-d-alpha-27-agni/).
rsync -e "ssh -o Compression=no" ...> hooks shouldn’t be run during a rebase
The pre-commit framework doesn't run hooks during a rebase.
> hooks should be fast and reliable
The pre-commit framework does its best to make hooks faster (by running them in parallel if possible) and more reliable (by allowing the hook author to define an independent environment the hook runs in), however it's of course still important that the hooks themselves are properly implemented. Ultimately that's something the hook author has to solve, not the framework which runs them.
> hooks should never change the index
As I read it the author says hooks shouldn't change the working tree, but the index insteead and that's what the pre-commit framework does if hooks modify files.
Personally I prefer configuring hooks so they just print a diff of what they would've changed and abort the commit, instead of letting them modify files during a commit.
Crucial for the approval was that we had cost alerts already enabled before it happened and were able to show that this didn't help at all, because they triggered way too late. We also had to explain in detail what measures we implemented to ensure that such a situation doesn't happen again.
There is also a "new way" (I believe QtQuick-based) for applications to create popups, which results in them not being separate windows anymore. System Settings makes prominent use of them for example and those popups just behave entirely different than one is used to. As far as I know it's not even possible to navigate these popups with the keyboard.