Part of using software is just going off how well it works.
When one Linux flavor starts to have issues, most people don't do a dissection on why, they just switch distros. Or web browsers (I've lost count of the back-and-forth between FF and Chrome performance over the years, nevermind all their precursors). Or office suites.
Pretending that the code is what really matters, and not what the code does, is elevating the paint quality over the painting.
[–] xmprt 15 hours ago
[–] ang_cire 15 hours ago
And maintainability is a function of code, as it relates to humans, so it is a measure of the code itself.
One of the things I've actually seen companies considering (due to supply chain compromise attacks), is not just having an in-house package repo that trails public versions, but instead fully in-housing critical dependencies and essentially making them private forks that they (probably use LLMs to) maintain.
Basically cutting out the Chainguard-like companies that made private deps their business model.
[–] xmprt 9 hours ago
And larger community means there's more rewards for a successful attack and therefore fewer latent security issues (ie, obvious ones are more likely to be caught).
I think companies considering building in-house packages are just trading one risk for another. Especially with LLMs, it's going to be a lot easier to find vulnerabilities in your internal dependency than it would be in a battle hardened dependency used by 100s of others.
[–] x3haloed 15 hours ago
But there really is a floor on how deeply a person can understand their own software. There has to be a "good enough" somewhere. As a C# dev, I can understand my entire codebase pretty deeply. And I've read enough of the .NET Core framework to understand some of the nuances of how a lot of the methods we rely on every day are implemented. But I've never once looked at the CIL that Roslyn has produced, and certainly not inspected the machine code that the runtime has compiled. I can't read or write Assembly. I don't really know anything about the x86 or ARM instruction sets. My understanding of the CPU is barely better than "it's transistors," and even lower than that, I have a vague awareness that neutrinos from space can flip bits and there are error correcting mechanisms for that, but I have no idea how they work. And yet, I'm able to write fast and reliable software.
There are super knowledgeable devs out there who pretty much DO understand the whole thing, but it's impossible to memorize every line of every version of framework that you're using or the unique alterations and upgrades to every piece of silicon that your program will run on, and as you guys pointed out, proprietary operating systems are basically completely opaque to our understanding.
So the question is really "where is the practical floor that you stand on?" And for me, personally, there is room for at least some areas of code at the application level that I'm OK with never having read myself.
When dealing with LLM output, you're getting a 1 of 1. There's no way to measure the community, number of contributors, or how maintainable it is.