[phosphophyllite]

Will someday debian authors and die hard fans understand that old libc and old Firefox or Gimp are different and one really can mean stable and another can be just outdated?

Is it possible that desktop should be developed in other manner than server?

[beefhash]

> Will someday debian authors and die hard fans understand that old libc and old Firefox or Gimp are different and one really can mean stable and another can be just outdated?

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.

[phosphophyllite]

1. Mac OS somehow achieved exactly this. 2. Actually no-changes and no-brainers are bad for mental health of elderly. In that age brain needs training.

[ris]

> 1. Mac OS somehow achieved exactly this.

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!

[phosphophyllite]

> bundle all of their dependency 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.

[ris]

> god only knows how entire install base of mac and windows machines works today

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.

[lolc]

Yeah retirement home staff is going to switch my shell every week so I stay alert!

If the only thing keeping me cognitively engaged in old age will be UI changes, I might as well die.

[dash2]

Tell that to my Dad when he can't access his email because they tweaked the UI yet again.

[kasabali]

Not upgrading versions of desktop applications means I won't have to deal with nasty surprises like configuration files changing, defaults changing and requiring changing configuration, disappearing features, incompatibilities with existing plugins/extensions or integration with other tools.

[phosphophyllite]

Can you just not upgrade on your own machine. Why other should suffer? Changes in life are inevitable.

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.

[kasabali]

> Can you just not upgrade on your own machine.

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.

[alxlaz]

> 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.

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.

[zodmaner]

> Why other should suffer?

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.

[phosphophyllite]

It's impossible when you just need pick up one distro and get new desktop software as it releases, and it also being supported by commercial vendors.

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)

[eikenberry]

This is the point of flatpak and appimage (and snap, though it is meant more for servers). To address the need for the mix of stable parts of the system and up-to-date parts. Between the applications and the OS.

[unwrap]

They could implement something like Fedora modules: you have a stable base system, and then you have separate module streams for some software packages, which are updated separately, with multiple versions supported concurrently. For example, you can install the latest Fedora, and then pull the postgresql-9.6 module (or 10, or 11, or all three in parallel), despite 11 being the "official" version.

https://docs.fedoraproject.org/en-US/modularity/using-module...

[kasabali]

Tangential but this is misunderstood widely, so I cannot resist the urge to explain.

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...

[fanf2]

Debian has backports https://backports.debian.org/Instructions/

For PostgreSQL in particular, the Debian / pgdg packages support concurrent installation of multiple versions https://wiki.postgresql.org/wiki/Apt

[mruts]

This is why I switched to Arch. Debian is just too conservative.

[unwrap]

Ah yes, Arch certainly is much better. I've had enough to do with Arch when they totally borked my workflow three times in a row in a couple of months. One of the issues was rebuilding all of the Qt5 libraries without testing any of their dependents. All Qt5 applications simply stopped working.

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.)

[darkpuma]

I think most Debian desktop users pull things like their browser from Sid.

[raegis]

Actually, Debian stable uses Firefox ESR, which is updated roughly once a year. I've used Debian exclusively on the Desktop since around Etch/Lenny, and never see the need to update my browser often.

[qplex]

It's worth noting that Debian backports security fixes for firefox-esr and these come in more often than once a year[0].

[0] https://www.debian.org/security/2019/

[jillesvangurp]

The notion of a linux distribution repackaging software released by others has always seemed a bit strange to me and a bit of an outdated practice. I get that it has its origin in the inherent need of distributions to explode packages in a distribution specific way all over the file system using distribution specific practices, scripts, file locations, etc. This indeed causes lots of headaches and creates a need for a lot of managing and testing. So don't do that. These days with things like docker and snap, there's no need for any of that and you can get your software straight from those most committed to developing, maintaining and fixing it: the original developers.

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.

[darkpuma]

Do you think that's typical? I wasn't trying to be contentious, I've always installed the latest firefox as soon as it's packaged and the other Debian users I've known were doing similar. I know ESR exists and works, but I've never gotten the impression that many people actually use it as their 'daily driver'.

[yakubin]

I use Firefox ESR on desktop with Debian stable as well. I've never felt the need to update it, while several times, when reading about things that break in non-ESR releases, I was glad I didn't use non-ESR versions.

[octotoad]

This leaves you with a messy, strange non-stable/sort-of-unstable installation that is likely to come back to bite you sooner or later.

[ageofwant]

After spending 25 years in tech as a dev I can unequivocally state that 'stability' is a mostly meaningless meme and most all arguments built around stability=good ships with some deep and profound caveats.

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'.

[ris]

I take it you've never built a system that you want to still be working in a year whether or not development resource is taken away from it.

[asymptotically2]

Stability is important, that's why people pay Red Hat and Canonical for support.