There's also a chance the people claiming to do clean room are cheating and took some shortcuts.

It's easy to make random claims that are impossible to prove or disprove.

They could claim that some employee one day used their model to ask a question about internal stuff and they trained on that.

It doesn't have to necessarily have to make sense to make a claim, but it doesn't necessarily bear any weight.

If using the OpenAI models to develop this taints you with Apple insider knowledge, then so is developing any macOS, iOS, Android or Windows apps around that are using any LLM.

You can't claim that some work is necessarily tainted by existing, you also have to prove which knowledge was retrieved, used and that there was no other reasonable way to know it. But unless it is actually tried in a court in all major jurisdictions, it's just speculation from all parties (including line).

One person could also claim that someone someday might leak information to them, and even though they'll ignore it, since they'll be exposed, they are tainted and can't contribute anymore. It'd be absurd.

A project is free to chose who can contribute, but they can't necessarily gatekeep others from doing their own project with different rules.

There's also been Wii games rereleased on PC with all debug symbols that cover the Wii parts that were still compiled in. You'd get mostly type names, enums, object layouts and function signatures that way.

The Juniors are also very good with AI. Having them merge bad commits into logical ones is a fine operation for them too.

People say they care about the "story" behind the PR. But no one cares about that story if it's about forgetting to fix a test and a typo in a comment.

The extra commits are just noise that make you think the original commit is a source of truth in a blame when it has been amended 3 times more in the same PR, but the link isn't apparent anymore.

Force pushing is bad to a published branch, not a feature branch (not that you really have force pushes in Gerrit anyway). There are versions of Gerrit tooling where you can have a branch as dirty as you want locally, but only the final aggregated change is visible for review of that's what you prefer too.

Thinner modular systems also require some good tooling and a good platform that ensures many security properties.

You will be trading a stable and vetted huge standard library for 200 small packages that may all be targets for supply-chain attack. Open-source projects don't all have the resources unfortunately to keep track of all their dependencies, so I'm not sure it's necessarily a more natural fit.

C++ ended up in that situation because they don't want to break backwards compatibility (ABI, API) or change contracts, except in some rare cases, even on major releases. Quite often, it is a vendor issue to break the ABI and fix issues, and some have refused to do that.

It's a self-inflicted issue that most other languages with "batteries included" don't have since they will document breakage and upgrade paths when anything changes, or they are not impacted as much since they are using an intermediate language as interface and avoid most ABI issues.

The implementation is fixable though, you can break the ABI and address your issues. A lot of standard library defects are fixed in an unstable ABI mode they have, but that requires you to link it statically or dynamically and then ensure all your shared object dependencies are using the same exact version. It's not trivial for everyone, but many do this (usually the static version).

Rust has committed to a stable API (but the ABI is explicitly unstable). Which makes sense for a systems language. It isn't (and doesn't want to be) a kitchen sink language.

But even something like Python has lots of cruft in its standard library. And they are willing to make breaking changes. Nobody should use urllib.request for example, requests is a far better HTTP client library. To the point where the stdlib docs tell you so.

I use urllib.request. It works fine, it’s always available, and I don’t need to push it through an audit.

You mostly hear about the bad ones. Mine has been doing great for almost 2 years now. I use it in a clean environment, I'm very careful and not clumsy, so that helps.

It's not that noticeable when you use the device. It will depend on your ambient lights usually and how you hold it. It's a lot easier to see when someone else is holding the phone too, so if that was your reference, you may want to use them a bit more first.