> You can defensively set shipped binaries as fallbacks in the event the application is running on a newer system that dropped critical functionality
Not if they're GPL licensed you can't. And that's a headache most commercial people do not want at all when trying to write software that's often for a marginal part of their audience anyway.
Wrong, misleading and possibly FUD. Yes you can ship GPL licensed software with your application, even a proprietary, closed source application.
You have to comply with the GPL terms, but that's easy to do for every library or auxiliary program that you'd link to or call in a Linux distro.
The GPL is designed to support this use case, with it's "mere aggregation" clause making it clear that it's allowed.
The one thing you can't do if you're shipping a closed source application is link to GPL-licensed code (unless there's an special exception clause, or it's LGPL, or it's dual-licensed to allow this). But for this type of GPL library, you can't use the Linux distro's shipped version either. So the GPL constraint makes no difference to the question of whether you can ship a frozen or fallback version with your application in lieu of the distro version.
If there's a corner case the above doesn't cover, I'm not aware of it and I've studied GPL compliance more thoroughly than most people. So I'd like to know about it :-)
> If the author's vision of the future is correct, then competent software engineers are safe. Domain knowledge can be learnt much quicker than how to apply good engineering principles.
I think this is true in some things and less true in others.
It's a pretty high moat getting into stuff like simulation software because the people working on numerical methods overwhelmingly have PhDs and it's a mixed skill set. Domain expertise here requires you to know maths to a high level. Even mechanical engineers often struggle here; it's often applied mathematicians and physicists turned devs that work on this stuff.
I worked on a fairly gnarly signal processing thing a while back that required bringing together knowledge of physics and software and maths and I found explaining it to people was tricky as their eyes glazed over at some point because their knowledge typically only covered one part of those.
> It's a pretty high moat getting into stuff like simulation software
I'm currently working on a simulation/game about space and orbital mechanics. I have a lot of software experience, I know how to build large projects and architect my code, and I know how to to test the end result to ensure I'm getting what I want. But I also don't have a strong math or physics background. In my experience, Claude (Opus 4.6+) has had no issues writing any simulation or game related math code. And the key thing is, I don't need to have a PhD in astrophysics to verify interactively and visually that everything is working as I expect to. I just have an interest in space, and a basic understanding of the physics involved.
> it's often applied mathematicians and physicists turned devs that work on this stuff.
It's true that this has been the case, but I also would not have been able to implement what I'm doing now without these models (at least without dedicated a huge amount of time on learning all of the physics and math). So I think this domain specific knowledge is becoming less of a moat than people realize. At least that's my perspective on the specific area I'm working on, but I don't have a hard time believing it extends to other domains, provided there is ample information about them online to have trained on.
Coding up a decent performing basic 3D finite element solver from scratch in C++. Still needed to know what I was doing but it’s a non trivial problem.
I still couldn’t get it to do more advanced stuff.
I have found this with (mechanical) engineers. They know what they want to see but don’t understand the underlying details which are more mathematical than the average engineer is able to work with. So the people working on engineering software are often physicists or applied mathematicians.
Depends on the task and the writing though doesn't it?
There's not that much depth in a lot of 'everyday' writing. For many tasks that means that you don't need to be hyperintelligent - reading a recipe or a shopping list, reading a newspaper article, etc.
My much larger company has got people already using various models through Bedrock because the Claude and OpenAI limits are too harsh and it's too expensive.
Not if they're GPL licensed you can't. And that's a headache most commercial people do not want at all when trying to write software that's often for a marginal part of their audience anyway.
reply