A common example is the ones with the gnome- prefix and the ones that end with -themes suffix.
What system are you talking about?
Anyway, you had me worried for a minute, but:
https://packages.debian.org/source/bookworm/libs/
Click on a C library. Click on the *-dev package. There's a 1:1 mapping of .so to .a in the packages I spot checked.
Now I'll go back to enjoying Devuan.
The people making those "stupid distros" are (most likely by number) volunteers working hard to give us an integrated experience, and they deserve better than to be called "stupid".
Debian puts in a massive effort to be a long term stable "standard" system. I've found that effort to be wasteful. I'd much rather just take the occasional (although surprisingly rare) breakage than live with the limitations of old packages. That's a matter of taste though, and greatly depends on the effort of the upstream developers.
“Fuck it, just distribute software in the form of tarballs of the entire OS.”
A touch overly dramatic...
If hard links from the get go were copy on write, then I suspect content defined storage would've become the standard because it would be easy.
Instead we have this construct which makes it hard and dangerous (hard links hide data dependencies) on most Linux filesystems and no good answers (even ZFS can't easily handle a cp --reflink operation, and the problem is it's not the default anyway).
Oh wait...
We learned that most app developers hate it; to the point they don’t even bother supporting the platform unless they are FOSS diehards.
Those that do screech about not using the packaged version on almost all of their developer forums, most often because they are out of date and users blame them for bugs that were already fixed.
This actually is infuriating - imagine fixing a bug, but 2 years later, the distribution isn’t shipping your update, and users are blaming you and still opening bug reports. The distribution also will not be persuaded, because it’s the “stable” branch for the next 3 years.
Basically, Linux sucks terribly, either way, with app distribution. Linux distributions have nobody to blame but themselves for being ineffectual here.
This grossly misstates the concept of a stable distribution (e.g., Debian stable, with which I'm most familiar).
Debian stable isn't "stable" in that packages don't change, to the point that updates aren't applied at all, it's stable in that functionality and interfaces are stable. The user experience (modulo bugs and security fixes) does not change.
Stable does receive updates that address bugs and security issues. What Stable does not do is radically revise programs, applications, and libraries.
Though it's more nuanced than that even: stable provides several options for tracking rapidly-evolving software, the most notorious and significant of which are Web browsers with the major contenders updating quite frequently (quarterly or monthly, for example, for Google Chrome "stable" and "dev" respectively). That's expanded further with Flatpack, k8s, and other options, in recent years.
The catch is that updates require package maintainers to work on integrating and backporting fixes to code. More prominent and widely-used packages do this. The issue of old bugs being reported to upstream ... is a breakage of the system in several ways: distro's bug-tracking systems (BTSes) should catch (and be used by) their users, upstream BTSes arguably should reject tickets opened on older (and backported) versions. The solutions are neither purely technical nor social, which makes solutions challenging. But in reality we should admit that:
- Upstream developers don't like dealing with the noise of stale bugs.
- Users are going to rant to upstream regardless of distro-level alternatives.
- Upstreams' BTSes should anticipate this and automate redirection of bugs to the appropriate channel with as little dev intervention as possible. Preferably none.
- Distros should increase awareness and availability of their own BTS systems to address bugs specific to the context of that distro.
- Distro maintainers should be dilligent about being aware of and backporting fixes and only fixes.
- Distros should increase awareness and availability of alternatives for running newer versions of software which aren't in the distro's own stable repos.
Widespread distance technological education is a tough nut regardless, there will be failings. The key is that to the extent possible those shouldn't fall on upstream devs. Though part of that responsibilty, and awareness of the overall problem, does* fall on those upstream devs.
"2.2. Are there package upgrades in "stable"?"
Generally speaking, no new functionality is added to the stable release. Once a Debian version is released and tagged "stable" most packages will only get security updates.... there are some cases in which packages will be updated in stable ... When an urgent update is required to ensure the software continues working. The package is a data package and the data must be updated in a timely manner. The package needs to be current to useful to end user (e.g. some security software, such as anti-malware products)....
And:
Users that wish to run updated versions of the software in stable have the option to use "backports". Backports are recompiled packages from testing (mostly) and unstable (in a few cases only, e.g. security updates), so they will run without new libraries (wherever it is possible) on a stable Debian distribution.
Debian is strict in interpreting security updates:
Security updates serve one purpose: to supply a fix for a security vulnerability. They are not a method for sneaking additional changes into the stable release without going through normal point release procedure.
<https://www.debian.org/doc/manuals/debian-faq/getting-debian...>
But your quote about stable says "most packages will only get security updates".
So assuming their bug fix isn't security-relevant, it sounds like their original complaint is valid? I don't see how it's "grossly misstating" how stable works.
Backports are useful but the default is that the user is on the buggy stable version.
See for example the Debian 12.10 release notes. This is an update to the Debian Stable v.12 release:
The Debian project is pleased to announce the tenth update of its stable distribution Debian 12 (codename "bookworm"). This point release mainly adds corrections for security issues, along with a few adjustments for serious problems. Security advisories have already been published separately and are referenced where available.
<https://www.debian.org/News/2025/20250315.en.html>
Strong emphasis on "mainly adds corrections", but "along with a few adjustments for serious problems."
That is, in practice, Debian stable receives both security and bugfix updates.
You and other readers are strongly encouraged to look through Debian sources (release notes, Policy, Constitution, and individual package updates within stable repos) to verify other questions before posting further concerns here.
This might be because upstream uses Github and the distribution bug tracker requires some high-level programming skills simply to post anything there. For example, try to post a bug to Debian.
Also simply obtaining a backtrace with symbols is a pain in most distributions.
reportbug:
This is exactly what users want, though. Eg. if they want to receive updates more frequently on Ubuntu then they can use the six monthly releases, but most Ubuntu users deliberately choose the LTS over that option because they don't want everything updated.
When that happens, guess what you do? You trademark your software’s name and use the law to force distributions to not package unless concessions are granted. We’re beginning to see this with OBS, but Firefox also did this for a while.
As Fedora quickly found, when trademark law gets involved, any hope of forcing developers to allow packaging through a policy or opinion vote becomes hilariously, comically ineffectual.
The other alternative is to just not support Linux. Almost all major software has been happily taking that path, and the whole packaging mess gives no incentive to change.
Ban the user that did not read go to the distro’s maintainers first.
It isn't clear if this behaviour is legally enforceable. Distributions typically try to avoid the conflict. But they could argue that "we modified Firefox to meet our standards and here is the result" is a legally permitted use of that trademark. To my knowledge, this has never been tested.
On SaaS/mobile apps you have often daily new versions of software coming out. That's what users/developers want. They do not want 3 year+ stale versions of their software being 'supported' by a third party distro. I put supported in comments as it only really applies to security and what not; not terrible bugs in the software that are fixed in later versions.
Even on servers where it arguably makes more sense it has been entirely supplanted by Docker which ships the _entire OS_ more or less as the 'app'. And even more damingly, most/nearly all people will use a 3rd party Docker repo to manage the docker 'core' software updates itself.
And the reason noone uses the six monthly releases is because the upgrade process is too painful and regresses too much. But - even if it was 100% bulletproof, noone wants to be running 6-12 month out of date software on that either. Chrom(ium) is updated monthly and has a lot of important new features in it. You don't really want to be running 6-9 months out of date on that.
Do you have any evidence to back that statement up?
Oh wait...
You’d need some sort of system that stores files and lets you name those files and also makes it possible for software to look them up by name.
Oh wait…
pretty cool that we are undoing it as a design decision
but it will take a long time
Flatpak is not getting rid of shared libraries. They're just reimplementing them in a way that's strictly worse in multiple ways.
Re-read the section "How Flatpak Tries to Save Space: Runtimes and Deduplication" in the article.
The problem is the applications have to use the exact same version of a library to get the benefits. With traditional package managers they usually only have 1 version available. With Flatpak you can choose your own version which results in many versions and as such they do not share dependencies. If distros had multiple versions of libraries you would end up with the exact same problem.
There are probably tens of thousand (if not more) of third-party applications for Linux-like systems, and hundreds of distributions, making new releases twice a year. This multiplies to 10 000 × 100 × 2 = 2 000 000 ports per year.
Who is going to write 2 million ports per year, thoroughly test it and fix the compatibility bugs?
In the Python world, something wants numpy>=2.5.13, another wants numpy<=2.5.12, yet Python has still not come up with a way to just do "import numpy==2.5.13" and have it pluck exactly that version and import it.
In the C++ world, I've seen code that spits out syntax errors if you use a newer version of gcc, others that spit out syntax errors if you use an older version of gcc, apt-get overwrites the shared library you depended on with a newer version, lots of other issues. Install CUDA 11.2, it tries to uninstall CUDA 11.1, never mind that you had something linked to it, and that everything else in that ecosystem disobeys semantics and doesn't work with later minor revisions.
It's such a shitshow that it fully makes sense to bundle all your dependencies if you want to ship something that "just works".
For your customer, storage is cheaper than employee time wasted getting something to work.
But as a rule, `<=` dependencies mean there's either a disastrous fault with the library, or else the caller is blatantly passing all the "do not enter" signs. `!=` dependencies by contrast are meaningful just to avoid a particular bug.
If your code does:
o = foo_v1.get_obj()
foo_v2.use_obj(o)
It would be nice if a foo.py file could just deal with all of that.
A while ago I created this thing as a thought experiment. It likely doesn't work with more recent version of python though: https://news.ycombinator.com/item?id=24735303
It was partly in jest but I was not entirely un-serious; I think "dealing with dependencies" is quite possibly the biggest reason why Python isn't used to distribute end-user applications. It's a wonderful language but a really shitty import system. There are various attempts to make the experience better (pipx, poetry) but you still can't ship a .py file to someone, have them double click and run it. They still have to conda something, venv something, pipx something.
Every platform needs a way to distribute and install third-party applications. It is unlikely that the authors of the platform wrote all existing software so you need some way to install applications not included into an OS.
On Windows, there is such a mechanism - pack your application into a large installer exe. It is awful and not secure but at least it has been working for ages. For comparison, on Linux there is no such mechanism at all. Typical Linux distribution traditionally has only two supported ways to install software:
a) install more components from OS repository
b) write and compile the software yourself
While there is lot of third-party software for Linux, there is no universal distribution mechanism. Typically software developer only supports the release they are using. There may be ports - by other developers or by the distribution maintainers - but they are often broken and don't even start (for example, port of waydroid in Fedora).
Some port installation methods are outright dangerous, for example: running a curled script through sudo or adding a third-party repository to your package manager. That is a sure method to get a broken system, and it will be totally your fault because your distribution doesn't support such installation method so you got the result that was expected.
In my experience, Fedora, Ubuntu and Debian are especially bad for supporting applications other than Gimp or Libreoffice: the ports for these distributions are often broken, buggy, crash or even do not exist. For example: waydroid, carla, ardour.
The reason is that there are hundreds of releases of different distributions and nobody is going to port, test and maintain all applications for all of them. So the obvious solution is to choose a standard platform and write applications against this platform. I see no other solution. If I am writing some GUI application I am not interested in learning how Linux distributions are different from each other. I would rather ship an Alpine virtual machine image and not waste my time.
Flatpak/snap might become such platform but why they are so buggy? As I remember, Steam in flatpak is broken and cannot properly use GPU, VS Code is broken etc.
In that respect flatpak is better because it’s more universally available than the Ubuntu-specific snaps (attempts at making snap cross-distro are laughable and failed) but it still introduces a bunch of tangential issues which are too much of a bother for the average user versus just doing “apt install” and moving on with their lives. PPAs cover this acceptably if suboptimally for Deb packages.
These package formats (I’m looking at you snap as well) are disrespectful of users’ computers to the point of creating a problem where due to size, things take so long and bog the computer down so much, that the resource being used is no longer storage, but time (system and human time). And THAT is not cheap at all.
Don’t believe me, install a few dozen snaps, turn the computer off for a week, and watch in amazement as you turn it back on and see it brought to its knees as your computer and network are taxed to the max downloading and applying updates.