@dezza, the first sentence of the ref is in error. I have plenty of 15 y/o linux apps that still run fine.
Let me refine that to: “I have plenty of 15 y/o linux apps that still run fine on a polluted and troublesome system”.
Please see, that the issues you’re bringing up over and over again, never really get solved if you keep dismising the solutions that we provide you with. Myself, I’m at the point where I wonder whether you even want these issues solved.
3 Likes
were they compiled 15y ago?
I have a few programs that were compiled in 2006, and still work.
Yes, they are 32-bit, so I do need the 32-bit support for them.
depends static, non-static and whether you use only stable APIs which is quite restricting in itself.
point is that we rarely can control it, without being fully FOSS, self-compiled and LTS. On topic of LTS being on 15y support cycle also have major downsides.
The Windows example is great, because even if they can’t control 3rd party deps - its focus on backwards compatability is also the reason its becoming stuck.
I’d also like to make the comparison to hype JavaScript frameworks that are replaced every 3 months. In this case its most likely more because junior devs prioritize “new and fancy” over stable API and incremental improvement. On that note in comparison to JS frameworks: I also used to create a ton of wrapper functions and increase complexity, also a common pattern in Java development, even encouraged.
Takes time to learn. Sometimes inlining code, repeating yourself (opposite of DRY) and keeping API small is better for maintainability and less abstraction load.
Its a completely different mental model in the Linux kernel for instance, especially in the lts branch.
gtk, qt also suffer from this - its one of the hardest problems to manage. Games are not much different. iirc a Bink video dependency kept lots of windows games on wine stuck without support for a very long time.
To bring this discussion back to the original topic:
You are mixing the concepts of packages and files. You probably know that you can prevent packages from being installed by locking them (zypper al <pkg-name>) or setting them to status taboo in Myrlyn or the old YaST package manager.
If you really refer only to individual files, though, that doesn’t work: Whenever the package that owns that file (see rpm -qf /path/to/that/file) is updated, the file will come back - because a package update is really just a glorified unpacking of a cpio archive with potentially some scriptlets before and after.
I personally try to keep any translated man pages out of my system because the translations often don’t keep up with changes in the original English version, and they only consume disk space. That’s a neverending fight against windmills, yet I still do it from time to time: I delete them, and they keep coming back after package updates.
So, which one is really your problem - too many packages, or too many files in some of the packages?
2 Likes
Actually, Qt keeps their APIs and their ABI very stable during the lifetime of a major release; and that’s easily 10 years or more. I’ve been using it for the YaST Qt UI, QDirStat and some more since about 1998.
And you could still keep a Qt 5 application alive for 5 or 10 more years if it wasn’t for some distros being over-eager to get rid of it and putting pressure on FOSS authors to migrate to a newer version.
2 Likes
Oh, thats news to me, but thanks. Anyways I agree, lets keep it on topic. I think containers fit this scenario perfectly.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.