Don't just vendor - rebuild the ecosystem and persuade the vendor to work on software management ...
Don't just vendor - rebuild the ecosystem and persuade the vendor to work on software management ...
Posted Jan 28, 2025 13:55 UTC (Tue) by taladar (subscriber, #68407)In reply to: Don't just vendor - rebuild the ecosystem and persuade the vendor to work on software management ... by bluca
Parent article: Vendoring Go packages by default in Fedora
I am glad you are in favor of forbidding the bad behavior of running outdated versions that are older than what the upstream project still supports. I agree that this is a waste of our limited resources to try to support this clearly broken use-case and to constantly waste energy all the time, forever to attempt to keep up with the changing world around you by back-porting fixes with volunteer work.
What is actually geared towards large corps is this pretense that supporting their fantasy that they can freeze the world around them is even possible or more stable.
Posted Jan 28, 2025 14:25 UTC (Tue)
by pizza (subscriber, #46)
[Link] (2 responses)
Question. What do you think all of this software actually runs on?
...."LTS" hardware, of course.
Of which the most prevalent is a 26-year-old backwards-compatible extension of a design that dates to 1985, which in turn is an backwards-compatible extension of a design released in 1978, of a which itself is a non-backwards compatible extension of a design from 1971.
_everything_ depends on _someone else_ "freezing the world".
Posted Jan 30, 2025 15:36 UTC (Thu)
by anton (subscriber, #25547)
[Link] (1 responses)
Posted Jan 30, 2025 17:47 UTC (Thu)
by pizza (subscriber, #46)
[Link]
Closer to 22 than 21 (with the spec available three years before that). But eh, that doesn't change my point. Most of us are using (recently-compiled) binaries that will natively run on two-decade-old hardware. I'd wager that a majority are still using (still recently-compiled) binaries that will natively run on three-decade-old hardware (ie 'i686'), and in some cases, four-decade-old (ie 'i386') hardware.
...As it turns out, "freezing the world" is utterly necessary in practice.
Posted Jan 28, 2025 14:33 UTC (Tue)
by bluca (subscriber, #118303)
[Link] (2 responses)
What the "upstream project" supports or doesn't doesn't matter one bit, because they largely have no concern whatsoever for compatibility. See for example the kernel, which breaks userspace API on every single damn release, and very often in allegedly "stable" releases too, because testing is for customers. And that's why people running real infrastructure with real workloads pay out of their nose to get RH or Canonical to provide targeted fixes in LTS releases for 5-10 years, instead of blindly throwing anything that kernel.org spits out and chucking it over the wall, praying nothing falls apart (hint: there's always something that does).
Posted Jan 28, 2025 22:35 UTC (Tue)
by DemiMarie (subscriber, #164188)
[Link]
Posted Jan 30, 2025 14:10 UTC (Thu)
by taladar (subscriber, #68407)
[Link]
Don't just vendor - rebuild the ecosystem and persuade the vendor to work on software management ...
The first Opteron was released on April 22, 2003, so AMD64 is currently 21.
Don't just vendor - rebuild the ecosystem and persuade the vendor to work on software management ...
Don't just vendor - rebuild the ecosystem and persuade the vendor to work on software management ...
Don't just vendor - rebuild the ecosystem and persuade the vendor to work on software management ...
Preventing upstream regressions
Don't just vendor - rebuild the ecosystem and persuade the vendor to work on software management ...