[GoLUG] [GTALUG] Status of Debian and derivatives, or flatpak/appimage/snap discussion redux

[Wayne]

There's also AppImage which carries the required dependencies with it and doesn't require other built-in modules like Flatpak or Snap do. For example, the image manipulation application GIMP is available as a single AppImage file at gimp.org. and the latest version runs without any other dependencies on even 'older' hardware or OSs. I've been using that and dozens of other AppImages for years with great success. They're a good way to run the latest version of something on older hardware.


On 11/28/25 11:17 AM, Steve Litt wrote:
> Nick Accad via Talk said on Fri, 28 Nov 2025 12:53:06 -0500
> 
>> Hi
>>
>> Recently I have been noticing that more and more of my daily-use
>> packages in Debian are old.
>>
>> I am not talking about stuff in "Stable" where versions are not
>> upgraded but fixes are backported, I am using Sid as my main
>> workstation, and some stuff is really old
>>
>> Example is rssguard, in Debian (any release), it is stuck on version
>> 4.0.4, github is on 4.8.6.
>>
>> I started digging, and I found out that there are over 4000 packages in
>> Debian that are either orphared, or the maintainer is asking for help.
>>
>> This is not sustainable,
> 
> I don't think this is about Debian (and I'm not a Debian fan by any
> means). This is about two things:
> 
> 1) There are thousands of pieces of software. No distro can or should
> be expected to maintain all of that.
> 
> 2) The modern hobby of overcomplexificating software, with tens of
> dependencies which themselves have tens of dependencies, so building a
> working, bug free executable is a monumental task. What could POSSIBLY
> go wrong?
> 
> 3) Developers (I mean real developers, not the distro guys who corral a
> bunch of versionated code bases into a working application) should
> learn to say "no" to all these whacked out "new feature" requests and
> requests for "pretty" at the expense of simplicity.
> 
>> The immediate solution for me is to use flatpaks.
> 
> Flatpaks are no more a solution than putting a penny in the fusebox to
> prevent fuse blowing, putting coins on the tonearm of an audio
> turntable to prevent the needle from skipping, or "fixing" a roof leak
> by placing a bucket under the leak. When the symptom rather than the
> root cause is addressed, there are always unpleasant side effects (the
> house burning down, the vinyl records wearing out faster, or the wood
> under the leak rotting into pulp).
> 
> The solution is to use software with a simple supply chain, and if
> you're a software author, ignore these bozos screaming "don't invent
> the wheel!" If you can avoid a dependency by writing an extra 100 or 200
> lines of code yourself, go for it. If Freddie Fashionfollower wants
> your software to "look native", ignore him if it requires more
> dependencies. Strive to issue software compileable with just a gcc
> command, or Python software using only the well curated Python Standard
> Library. THAT'S the true solution.
> 
>> The other option is of course to switch to something else, either
>> Fedora and derivatives, or Arch and derivatives, but honestly after
>> 20+ years of Debian, I am the old man who has no patience for new toys.
> 
> I guarantee you other distros are going to have the same problem. I use
> Void Linux, which has many less package choices than Debian, yet I've
> been using it happily for 15 years. Nobody can keep up with the
> proliferation of applications with 20 deep, 200 wide dependency trees.
> 
> My suggestions to everyone:
> 
> * Learn shellscripting and the shellcheck program.
> 
> * Learn enough Python to act as a glue language. Ruby and Lua are
>    acceptable for this need, and even Perl in a pinch.
> 
> * Scale back your aesthetic expectations. Pretty ain't free.
> 
> * When evaluating programs, evaluate not only capabilities, speed and
>    security, but also level of dependency entanglement.
> 
> * If an app requires flatpak, consider that a temporary solution. Then
>    find or create an application that gives you what you need.
> 
> SteveT
> 
> Steve Litt
> 
> http://444domains.com
> 
>