All the AI hype aside, I wonder if there is a way to avoid becoming one of these faceless corporations where customers are just numbers. For years Amazon has been fantastically customer centered, but at some point they just lost it. I could compile a list where Amazon is actually way more customer unfriendly than in the past now, but I guess everybody already got their own anecdotes about that. So what exactly went wrong and how could that be avoided at other companies?
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.
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.
Fun fact: 0ad still doesn't support kerning. While I would've loved to see proper kerning support in r28, there is only so much a team of volunteers can do.
The best players are incredible at microing (although horse rushs are just one of multiple strategies). It's also equally important to manage resources and units in a way that you use all of them all the time. That's especially important in early game.
It crashed for you? You must be running Arch Linux. ;-)
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.
Making a high quality campaign is quite some effort and the engine still lacks some features, which would be helpful for this. A dialogue system is one of them, which already has a PR available: https://gitea.wildfiregames.com/0ad/0ad/pulls/8614
> I'd def be trying again since they've come out of alpha with this release.. a huge deal for a game that is so many years in development.
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.
> […] the game either halts completely or forks so that they can't rejoin.
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.
I believe the main reason that Flattr failed was just bad execution. After a successful start and Flattr being used more and more, they just stopped iterating on it, leaving it dormant for years. Partnering with Adblock Plus was the final nail in the coffin.
Good point. Seems like I enabled it in ~/.ssh/config ages ago and did forget about it. Nonetheless, it's good to check whether it's enabled when using rsync to transfer large, already well compressed files.