Is it possible that desktop should be developed in other manner than server?
1. Things depend on one another. Keeping the base system stable while iterating everything else more quickly can end up being infeasible because it's turtles all the way down. Application X wants a newer CMake to build, which wants a newer something else, which wants yet another newer version of something, and then your base system changes underneath you.
2. I really, really love to “fire and forget” a Debian installation for a few years. I've got elderly family members on Linux that are really sensitive to changes in the UI. Things being not changing for years rather than months or weeks is a blessing.
If the only thing keeping me cognitively engaged in old age will be UI changes, I might as well die.
You're right - that's why macos definitely hasn't spawned suspiciously debian-like package managers in an attempt to handle all these problems.
And if we're talking about "app bundles", if you dig a bit deeper you'll find most of these applications which "just work" just bundle all of their dependency libs. God knows if they bother to update them or do a security release if vulnerabilities are found in their bundled libs!
Mother of God! Very popular argument. No one cares (in terms of architecture).
> vulnerabilities are found in their bundled libs!
Yes, god only knows how entire install base of mac and windows machines works today (this problem is not as big as you try to present here).
Your arguments like debate about linux monolithic and minix micro kernel architecture. Minix is more advanced in theory, linux (not linux desktop) working in reality.
The issue being that, for a lot of people, they often work a little too well.
If you're going to follow the philosophy that caring about the correctness, lack of duplication and security of an installed application is too esoteric to be relevant, I'll remind you that you're entirely free to do that to any extent you like with linux. Equally people like me are free to tell people who do that that they will receive no support from me for such a setup.
Let me remind you that binary distros emerged for convenience and speed – you dont need to compile bunch of stuff when internet and computing power was limited, e.g. new version of gimp (or mpv) with feature you really waited and wanted.
I have never (never!) encountered security problems, and sudden config changes in most updates (lates major versions of KDE are exceptions) and this is not a problem at all on my desktop machine.
Problem is when can't intsall new version wihout learning new often sophisticate upgrade procedures or even compiling/building (let me remind you it's 2019 today).
Debian is not universal, it's a server distro with desktop packages appeared in repos by as a result of some mistake.
How can I know which packages and which versions will be incompatible upgrades beforehand? How can I rely on distribution maintainers to know and warn me against incompatibilities with any kind of customization or 3rd party integration I've had outside of the distribution. Why should I spend time before and after every upgrade to assess something won't/isn't broken.
> Why other should suffer?
They shouldn't. Dozens of other distributions with different release policies are available and well supported.
> I have never (never!) encountered security problems, and sudden config changes in most updates (lates major versions of KDE are exceptions) and this is not a problem at all on my desktop machine.
You can't say that as the very first example you've given in your above post, Firefox, has been notorious with the breakages for the better part of the last decade; with every single new release either breaking extensions, removing features that users have relied on, introducing anti-features that required disabling or any combination of these.
> Debian is not universal, it's a server distro with desktop packages appeared in repos by as a result of some mistake.
You must hurry tell that to Debian developers so they can stop wasting their time packaging thousands of desktop programs, then.
I guess you also never encountered a red-bellied black snake. That doesn't mean it's not a problem for the 25,000,000 people who share an island with it.
Good for you, but don't presume your use cases and requirements are the only valid ones.
I'm sorry, but what is stopping you or other people from using distros with faster release cycle or rolling release?
If anything, there are so many rolling release distros nowadays, that Debian Stable is a breath of fresh air in the sea of release first, fix later mentality (especially when it comes to desktop environment).
But I digress, in the end just choose the distro that suits your needs and requirements and be happy.
Amazing example of why linux desktop goes wrong direction is so many distros. When you have many answers – you don't have answer.
Ubuntu studio for artists, Kubuntu for those who like KDE, Debian for thos who don't like updates (._.), gentoo, etc etc.
Why on windows and mac user can compile, and update anything? Just install photoshop (or newer version of gimp that available for majority of users on windows earlier than on linux before snap/appimage) and you get "distro" for artists.
And even snaps/appimages go wrong direction and overthink problem with security and sandboxing — when majority of users just need one runtime to deal with, like in SteamClient.
No one wants download or plug special repo/package for debian or fedora — this is amazing resource waisting! (insane even)
https://docs.fedoraproject.org/en-US/modularity/using-module...
First of all, modules can not be installed in parallel [1].
Secondly, it is not a new technological development at all. Modules in essence are just a fancy version of maintaining multiple overlay repositories on top of your base distribution. Only difference is it adds a more streamlined usage to dnf. You could do the same thing 15 years ago with yum or apt by manually enabling/disabling repositories.
This is the easy part.
Real hard work that goes to modules is actually creating and maintaining those separate modules having separate versions of the same software stack. And that is the thing none of the distributions were willing to do until recently. Heck, maintaining multiple versions of the same library or the same program in a distribution release was a taboo. Distribution developers dreaded the idea of doing that and avoided it as possible as they can.
Jury is still out on how well it'll work in practice and how much useful it'll be (in that will maintainers be actually eager to do the hard work of maintaining multiple stacks in parallel, how long will they support each version or how many versions will they maintain in parallel etc.)
I have the best wishes Fedora developers with the modules idea and I hope it'll prove to be successful thus maybe other distributions would be more open to the idea in the future.
[1] > Modularity brings parallel availability, not parallel installability. Only one stream of a given module can be enabled on a system https://docs.fedoraproject.org/en-US/modularity/architecture...
For PostgreSQL in particular, the Debian / pgdg packages support concurrent installation of multiple versions https://wiki.postgresql.org/wiki/Apt
I don't blame them though, one of the maintainers was supporting like, 3000 packages? I don't recall the exact number, but it was an impossible amount of work for a single individual. This strongly implies there was zero QA for these packages (an he really was doing it himself, it was not a front for an organization.)
My experience with Debian, Red Hat, etc. is to ignore packages for basically anything I care about for both Development and Production. It's likely to be the wrong version of what I need and quite possible for it to have distribution specific issues and quirks. E.g. for OpenJDK I would never put Debian provided packages in production and instead use a package from one of the several licensees of the testsuite (Amazon Coretto, Azul, etc.). I have actually run into issues with e.g. certificates, premature releases of non released versions of the jdk, etc. Much better to use Docker and CI test the entire container before it goes near production with exactly those dependencies that I tested and hand picked. Even Docker itself I prefer to get straight from the source when I build AMIs in Amazon (using packer). Most things I use are well supported with packages by their developers.
Do not drink the stability cool-aid, its 98% poisonous nonsense.
Perhaps this is different on non-linux platforms, but if you find yourself there you have far greater problems than 'stability'.