It actually reminds me of the the [OSS Sabotage book](https://www.cia.gov/static/5c875f3ec660e092cf893f60b4a288df/...)'s section on General Interference with Organizations and Production (page 28):

    (11) General Interference with Organizations and Production
        (a) Organizations and Conferences 
            (1) Insist on doing everything through “channels.” Never permit 
                short-cuts to be taken in order to expedite decisions.
            (2) Make “speeches.” Talk as frequently as possible and at great 
                length. Illustrate your “points” by long anecdotes and accounts 
                of personal experiences. Never hesitate to make a few appropriate 
                “patriotic” comments.
            (3) When possible, refer all matters to committees, for “further 
                study and consideration.” Attempt to make the committees as 
                large as possible—never less than five.
            (4) Bring up irrelevant issues as frequently as possible.
            (5) Haggle over precise wordings of communications, minutes, resolutions.
            (6) Refer back to matters decided upon at the last meeting and attempt 
                to re-open the question of the advisability of that decision.
            (7) Advocate “caution.” Be “reasonable” and urge your fellow-conferees
                to be “reasonable” and avoid haste which might result in 
                embarrassments or difficulties later on.
            (8) Be worried about the propriety of any decision—raise the 
                question of whether such action as is contemplated lies within 
                the jurisdiction of the group or whether it might conflict with 
                the policy of some higher echelon.

"I'm a volunteer, my job is to choose where I volunteer my time, and I won't be volunteering it for free for this".

The output in their Mesa project bug report is outright misinformation, it sounds completely plausible but is absolute nonsense. This is the true danger of AI, it is so convincingly confident that people forget to question it, or in this case, don't even have the tools to begin questioning it. It's actively unhelpful at best.

Personally, the developers of both the LLVM and Mesa projects were far kinder and patient than I would have been, most OSS developers aren't just not paid to work on these projects, but are usually paid to work on other things. Taking up their time with this nonsense is very insulting to them, and the attitude that they owe the author anything at all is, as stated in the LLVM ticket, exactly what pushes many developers out of OSS development.

I also found it very interesting that their pics of this feature were with Davinci Resolve on the screen and not Final cut Pro - I guess when it comes to colour, there's no better tool.

No one is going to claim this. The fact the Pro gets 10Gbit USB 3 _is_ interesting (particularly for anyone using the phone for video), but certainly not revolutionary or genius.

You might have literally deleted people's whole businesses, companies, who employ real people, who have families, now need to figure out how to continue. Not least of which, your own. If the company survives until Christmas I will be shocked; no one can trust your company ever again - your core business is storing other people's data, and you deleted it, for many, completely without warning.

I guess people still use Mongo even after finding it doesn't achieve any property of the CAP theorem, maybe some people will keep using a database provider with a track record of intentionally deleting their paying customers' data.

There just aren't enough adjectives for astonishment to adequately describe this situation.

I hope you offer Jay Clifford some support, he's clearly been put in the awful situation of having to explain the decisions of others and deliver the awful news. If I were him, I would be in need of serious mental health support, this is an absolutely awful thing to have responsibility for without any ability to rectify.

Going the other way, there is an extremely well understood interface between all the processes which run in isolation: shared memory. Nearly by definition this must be well coordinated between the processes.

So the first step in moving to a multi-threaded implementation would be to change nearly nothing about each process, and then just run each process in its own pthread, keeping all the shared memory ‘n all.

You would expect performance to be about the same, maybe a little better with the reduces TLB churn, but the architecture is basically unchanged. At that point, you can start to look at what are more appropriate communication/synchronisation mechanisms now you’re working in the same address space.

I just don’t understand why so many people seem to think this requires an enormous rewrite - having developed as a multi-process system means you’ve had to make so much of the problematic things explicit and control for them, and none of these threads would know anything at all about each other’s internals.