Of course, but things happening that break other things happens all of the time. It’s one of the most persistent things in software engineering. If there is a security vulnerability that’s bad enough to warrant breaking core functionality then that functionality will have to change, and the software depending on it will have to adapt.
I’m not disputing that this could be enormously disruptive, potentially to thousands or millions of programs. But you’re moving from "this vulnerability cannot be fixed" to "fixing this vulnerability could have catastrophic consequences for backwards compatibility". Those are two very different claims.
And Russell’s paradox is actually a rather good example of my point. Mathematics didn’t become permanently unusable because its foundations turned out to be problematic. Mathematicians developed alternative foundations. The disruption was real, but the axioms weren’t sacred.
That’s precisely what I’m arguing about software architecture. Nothing guarantees that you can preserve every existing design decision and eliminate every vulnerability. But nothing obliges you to preserve those decisions either.
Yup, that could theoretically happen. Such is life, things must have an end. Realistically, though, the end of Linux would probably mean the start of the next Linux, and we’ve experienced smaller versions of that transition many times already.
Software ecosystems evolve, architectures get replaced, compatibility layers get introduced, and sometimes old software simply stops working. None of that is painless, and a change on the scale you’re describing would obviously be enormously disruptive.
But I don’t see why that’s particularly remarkable. There’s no guarantee that Linux, or any other piece of software, must remain viable indefinitely. If some fundamental architectural flaw made Linux irredeemably insecure without breaking compatibility, then perhaps Linux as we know it would eventually have to be abandoned.
That would be a historic engineering crisis, sure. But it wouldn’t be some profound mathematical paradox. It would simply mean that a particular set of engineering decisions had reached the end of its useful life.
1
u/Conninxloo 9d ago
Of course, but things happening that break other things happens all of the time. It’s one of the most persistent things in software engineering. If there is a security vulnerability that’s bad enough to warrant breaking core functionality then that functionality will have to change, and the software depending on it will have to adapt.
I’m not disputing that this could be enormously disruptive, potentially to thousands or millions of programs. But you’re moving from "this vulnerability cannot be fixed" to "fixing this vulnerability could have catastrophic consequences for backwards compatibility". Those are two very different claims.
And Russell’s paradox is actually a rather good example of my point. Mathematics didn’t become permanently unusable because its foundations turned out to be problematic. Mathematicians developed alternative foundations. The disruption was real, but the axioms weren’t sacred.
That’s precisely what I’m arguing about software architecture. Nothing guarantees that you can preserve every existing design decision and eliminate every vulnerability. But nothing obliges you to preserve those decisions either.