It is the ultimate cop-out to avoid having any involvement in anything. "AI said so..." then shrugs or more AI answers, ultimately removing oneself from any form of commitment to an opinion or knowledge (even partial).
> In addition to the damages award, Rakoff entered a permanent worldwide injunction
Because apparently U.S. courts and judges can do that. The more this is ignored by third-parties outside of the U.S., the better.
I'm not against international cooperation regarding common rules (I'm rather for), but the current context certainly doesn't designate the U.S. as a responsible custodian/enforcer of such rules.
> nearly everyone has some niche thing they like, some 5% that isn't covered by the FOSS
I'm interested in where that estimate + number are coming from. And I'd like to point out that I don't nearly see as many people pushing back against say MacOS for "not being Windows", despite the fact that the same issue would be there. I wonder why Linux gets special treatment in that regards, when modern distros make usage very accessible.
> And that doesn't even get into gaming.
Gaming on Linux works very well. And if something doesn't, it's usually by choice (e.g. BattleEye customers not enabling it on Linux) or by sheer incompetence / malevolence (e.g. EA Games and their shitty EA App that breaks often even on Windows, and even worse on Linux in a Wine environment).
This reasoning is flawed in my opinion, because at the end of the day, the software still has to be paid for (for the people that want/need to make a living out of it), and customers wallet are finite.
Our attention is also a finite resource (24h a day max). We already see how this has been the cause for the enshittificaton of large swathes of software like social media where grabbing the attention for a few seconds more drives the main innovation...
> Then the statement "Stuff can't interoperate with c++" is true
Where is that statement? The statement I reacted to (and with some caveats) was the following: "Libraries written in C++ or Java can generally only be used by applications written in the same language. It is difficult to get an application written in Haskell or Java to invoke a library written in C++."
Which in my opinion is not true for the reason I mentioned.
> Nothing from c++ ever gets exposed
Depends what's your definition for "getting exposed". If you mean "no C++ feature from the language gets exposed" then it's mostly true (you can still wrap certain things like allocators, though painful, but there's certain C++ features that have no real equivalent in some target languages indeed). But you can definitely expose the functionality of C++ code through a C interface.
> Is it easy to write a nice C interface for C++ that makes heavy use of templates, smart pointers, and move semantics?
If the interface itself has or leaks those features, no that's not easy indeed. But if those do not leak, then they can be used internally yes.
My point was not that it's easy to wrap a currently existing C++ library that has modern features in its interface in a C interface, especially post-C++11.
But that if you design something from the ground up, then it's rather easy (with a certain set of constraints). My bad for not conveying that better.
You do lose the ability to use some features, that's true. Mostly RAII around the interface. You can still leverage it internally in the implementation, and if using context objects it would be even easier. The main pain point is if you want to let client of the library use their own allocators. It's still doable, but quite a pain.
Classes can be wrapped with a bit of effort. You do need to write the constructors and the destructors manually and invoke a pair of new/delete on the C side, but it's just as you would handle a type allocated by a C library itself. You'd use it the same way. You just have the liberty to have the implementation use (mostly) C++.
> Libraries written in C++ or Java can generally only be used by applications written in the same language. It is difficult to get an application written in Haskell or Java to invoke a library written in C++. On the other hand, libraries written in C are callable from any programming language.
Not saying they should have picked C++ but that's a bit untrue. It's quite easy given some thought into the API to invoke C++ code in basically any language which can invoke C code, since you can wrap a C++ implementation in a C interface. I've done it multiple time throughout my career (that ended up being called from Python, Swift, Objective-C/C++, Swift, Java, and Kotlin).
And as a side note, you don't have to do object-oriented programming in C++ if you don't want to.
> a high risk of being disrupted by those clients just using AI agents instead of paying $2-5000/day for a team of 20 barely-qualified new-grads in some far-off country
Is there any concrete evidence of that risk being high? That doesn't come from people whose job is to sell AI?
In a way, they really condensed perfectly a lot of what's silly currently around AI.
> Codex, Opus, Gemini try to build Counter Strike
Even though the prompt mentions Counter Strike, it actually asks to build the basics of a generic FPS, and with a few iterations ends up with some sort of minecraft-looking generic FPS with code that would never make it to prod anywhere sane.
It's technically impressive. But functionally very dubious (and not at all anything remotely close to Counter-Strike besides "being an FPS").
> Gee, how hard is to find SE experts in that particular combination of available ops tools?
You find expert in Ops, not in tools. People that know the fundamentals, not just the buttons to push in "certain situations" without knowing what's really going on under the hood.
Well a big reason this is missed is people discussing it are not part of these groups and mainly saw this as an annoyance.
I can agree that heavy & strict CoCs can be daunting and probably overkill for small open source projects. And they're far from flawless, as shown by the Rust mods resignation incidents. But to say they're useless and anti-meritocratic is to forget (and/or silence) these people that wanted to contribute in an environment where they wouldn't feel threatened (incidentally, sometimes despite being skillful contributors, so much so for the supposed meritocracy of the CoC-less projects).
I'm not sure strict CoCs are the answers to these real problems, but this feels like dismissing these problems altogether.
If you don't like the scope of the license especially with regards to the legal jurisdiction it sits under, then don't use it, don't use software under EUPL license, and call it a day?
I'd say the blame lies halfway between AT&T and Snowflake. If you let your customers have poor security practices, and you have the power to ensure a heightened security level, you're also partly to blame...