Installing Microsoft software on your Linux system to protect it is like trying to protect your child from crashing into the dashboard by strapping him to the front bumper.

You obviously have no idea how git works. It is decentralized. You can sneakernet the repo.

This is fair, but that really just reinforces the point that the article makes. Solo dev is currently different, team output is limited by other factors than pure code output. I've worked on games with literally hundreds of concurrent programmers, and even when you're using something like Unreal Engine and your team is small ( 20 people), you've effectively got all the engine team at Epic generating code for you on a relatively regular basis.

It may indeed be possible for AI to actually make teams faster at some point (even in the nearish future), but right now, it's just more code, which isn't always the best solution.

So you are surprised that Kashed Patel fell in line and used the term? The quote was from Patel, so what would have been surprising is if he didn't use it. For the record there is an industry standard use for the word super in an AI context: ASI / Artificial Superintelligence. Both Amodei and Altman have publicly stated that they have no intention of using the term SI in place of AI. Other experts have also criticized the idea of referring to AI as anything other than AI. A few CEOs, notably Yuang, Musk, and Bezos are falling in line, but I think we already knew that was going to happen. They are CEOs, not experts, and no self-respecting expert will ever follow Trump's moronic "directive."

I don't know the reasoning or even if it makes sense. I don't have the full understanding of the system to make that decision. What is important to realize is ... neither do you.

You are completely wrong about Linus being anti source control. Linus specifically addressed this claim in the 2007 Google Talk. He was anti *centralized* source code control for the specific use case of kernel development, preferring patches and diffs to CVS because of the many flaws CVS has, including its inability to provide data integrity. Centralized tools were notoriously terrible at branching and merging, and there was no guarantee that what you checked out was the same as what was checked in. Linus’ workflow as a maintainer relied on receiving work from dozens of sub-maintainers and thousands of contributors. In other words, it was a work flow that was by definition decentralized. A tool that couldn't effortlessly handle thousands of parallel merges was useless to him. Once Bitkeeper, a decentralized SCM that suited his needs, became available, he adopted it. He didn't change position. He was still 100% unwilling to use centralized garbage, so he did the only thing he could ... write his own. Nobody ever, in the history of software development used as the basis of their presentation in a pitch that git should be used "because of the hype." In fact git took a long time to be adopted because "it was hard to use" and people didn't understand it. git stands on its own and both became, and remains, the defacto standard because it does what no other alternative does. That being said, at least we agree that Agile has resulted in indusry-wide abominations ;-)

How about if we have discussions where we don't redefine terms to mean whatever we want to sound like we know what we are talking about and see how that goes?

git isn't a database, so it stands to reason that it isn't a sharded database, nor is it a decentralized database. git is a decentralized repository architecture, and speaking about it as a database is causing you to confuse sharding with decentralization. In fact almost all databases that employ sharding are centralized.

"This centralized vs decentralized make no sense. Run multiple copies of Scion and it will behave just like multiple copies of git."

You are kidding me, right? I agree with you that they can use git to great effect and aren't using it properly for their use case, and that they are unlikely to come up with a better solution that couldn't be arrived at by just knowing how to use git properly, but that doesn't make what you said in the part of your comment that I quoted any less absurd.

I think the condescension was quite justified.

"The point stands, you have to consider the audience for the change tracking."

... and there is the proof. My whole point was that you are considering the wrong audience when you operate on the assumption that humans are the audience, then you double down on your mistake by suggesting that I do what you are trying to claim I didn't do, when you are the one who didn't do it. Then you go on to say "I don't think ..." and "it seems like..." and asserting that Scion isn't designed to do Source Code Control. You have an amazing ability to know things that nobody could possibly know just by reading a Slashdot summary. Was that enough condescension for you?

Nothing gives me more confidence in my boss than when he decides we should reinvent some popular software.

I mean, that's exactly what Linus did with git. A lot of his criticisms of existing stuff weren't justified (he went on misplaced rants about how version control software was bad in concept for years), and people have essentially cargo-culted git into areas it wasn't designed for because 'Linus is cool'.

So he re-invented bitkeeper before he even used bitkeeper, after he waited until someone else "reinvented" SVN by creating bitkeeper, then deciding to use bitkeeper because it solved the inherent problems of SVN, which really weren't problems to begin with, then it became popular because the whole software developing world is notorious for adopting a solution because the creator was "cool"? Like the way that C became popular because everyone knew Brian Kernighan and Dennis Ritchie were cool, or Open Source because Richard Stallman is so charismatic, and Window became mainstream because Bill Gates was such a notorious playa? Slashdot may not be a git repo, but it is possible to look at a threads history. You would have been better off just admitting that you have no idea what you are talking about in your initial reply to the GP. Now you are just doubling down on your blatant ignorance.

Code already isn't "all audited and tested by humans." Have you ever heard of fuzzing and lint? How about unit tests? Automated SQA? Is any of this ringing a bell?

Your false assumption is that humans have to be doing it. The whole design is to afford AI to work at AI scale. If that is a good idea or not is a completely different question. Even if it is a bad idea now, the intent is that at some point AI will in fact be better than humans at the task. For the record history has shown that AI has consistently become better at tasks than humans. I know a lot of humans won't let their egos accept that, but anyone who looks at the facts cannot argue against this simple fact.

"If a human were pushing too many changes, I'd tell them to slow down and take a bit more time per commit. "

... and if humans were doing it you would be correct. I guess nobody explained this to you yet, but computers are quite a bit faster than humans. While it is true that it is important to make sure that what is being done makes sense, it makes no sense to judge the quality of what is being done by AI basing your assessment on how fast or often humans do it. A human could technically execute machine code using pen and paper using a microprocessor assembly manual to look up the opcodes. By your logic we should be telling these damn computers to slow down to the speed a human would do it.

Exactly. Every decade or so someone has to come along and think they came up with a great new idea without doing any research before they rediscover why that idea was discarded in the first place.