Even just the git has many releases during Debian Stable/Ubuntu LTS, which enhance user experience, that holding back users is not the best idea. And in most cases security fixes land first in the newest versions and are backported, so it is most likely to have a fix in HEAD than in some random older release.
The "best" user experience you're referring to is getting surprises like your OpenSSH 9 suddenly stopping to work with your key agent [1] out of the blue because they decided to change the protocol (no big deal right?) without any hint of this whatsoever during normal usage, and you just casually upgraded your packages because, well, when did Linux package upgrades ever hurt anybody?
(Just the latest incredibly frustrating surprise your fellow "Windows person" literally had to spend hours on tracking down. And that I actually remember. Most definitely not the only one.)
Debian Stable tends to hand pick the latest LTS version of packages everywhere applicable, so it's actually a good base to standardize on. Packages might be a bit older but they are reliable, predictable, and kept secure by a constant roll of security updates.
In other words, if it doesn't work on the latest Stable, you're probably moving too fast for a good part of the industry. Lots of customer and production stacks are not in the "move fast, release early, release often, and link the crap to the very latest bleeding edge dependency" bandwagon.
The whole point of stable vs testing is that versions are fixed, reviewed security updates make it, it’s all tested and vetted.
On the other hand, testing and backports haven’t been tested as well and could have issues.
If we use stable and incorporate backports from testing, is it still stable?
If I knew about Arch earlier I would have switched, because it sounds like my kind of distro - but I have to much customizations and too much kids to have time for that right now.
I never quite get why people want they development environment be similar to production - you install IDE on production? Or you just code in vim/emacs/ed without any plugins (because production doesn't need it)?
It just so happens the software you mentioned, git, is in stable backports, so it is updated frequently. Regardless, I've been on Debian stable since 2007, and running "bleeding edge" stuff is trivial, depending on your desired workflow. (For example, I just install Debian testing packages in a schroot.) I used to bounce from distribution to distribution in the old days (Red Hat, Mandrake, Slackware, Gentoo, etc.) but once I found Debian Stable I could concentrate on getting work done.
For me it’s definitely been browsers and IDE’s, but I just install those to /opt.
Most of breakages of Linux was my own doing (e.g. by mistake overwritting MBR).
I use testing+unstable (I didn't know that backports exists, thanks) + self compile some software that doesn't exist in either or is too old. I also always compile kernel, prefer it to have less modules and configured towards performance on desktop.
So I might be two years out of date on ls, but it probably hasn't changed in the last 2 years anyway.
It’s really nice to have the rest of the distribution more or less set it and forget it.
Windows users might be accustomed to having infrequent OS version releases, but they're used to their _apps_ being current.
(And, as another reply mentioned, you'll miss out on a lot of usability improvements to development tools by running stuff that's 2 years old or more)
> For things not in the Debian Stable we're using, such as if we need a bleeding-edge version of some key thing, and we have big security/reliability requirements... I manage non-Debian-packaged third-party dependencies in our own Git repo, and track and vet updates. This also means trying to minimize these dependencies, more than we would if we were pulling in 100 packages casually from a language-specific package manager, since each package is additional work.
Making it harder to have up-to-date dependencies is costing you far more than you're saving by not upgrading frequently.
Not if you're separating where you live from where you work - in a manner of speaking. Applying global changes to your system (e.g. using package manager to install a specific versions of packages required by your production app) is a terrible, terrible idea that will cost you more than isolation (standardized docker, dev VMs or similar, which ought to reflect your running environment). Debian stable provides a good workstation environment - the actual work should not be done against Debian-blessed packages. The opposite is true - your workstation packages should not be dictated by the needs of your prod software.
> Applying global changes to your system (e.g. using package manager to install a specific versions of packages required by your production app) is a terrible, terrible idea that will cost you more than isolation (standardized docker, dev VMs or similar, which ought to reflect your running environment).
Why? Your system is (or should be) a single-purpose tool. It absolutely should be managed and reproducible (using something like puppet), but keeping everything flat so that you're working on the same "bare metal" that your application works on has more advantages than disadvantages IME. (E.g. it's hugely helpful to be able to fire up a random REPL, integrated with your IDE or similar, and have the same versions of your libraries available that your application uses).
Stability. My assumption is that one would be using their workstation for tasks much broader than the production environment: development, debugging, slideshows, video conferencing, screen recording, etc. Without execution boundaries, it's almost inevitable that there will be incompatibilities.
Stability of the prod software may be impacted, when something on dev environment (and only on a specific dev environment) because the engineer added an implicit dependency on some aspect of their environment inadvertently.
For my development needs I prefer Debian Stable and install the dev tools locally in my home directory rather than using the packaged versions.
Since I don't share those boxes, it works well for me. I keep up with the frequent Android Studio / VSCode updates that way.
At that point you end up manually doing the job of a package manager.
For better or for worse, I think this is partly where my preference to use rbenv, pyenv, asdf, etc comes from.
The other part was from hosing my system installed pip packages for the Nth time because long ago I didn't fully understand pip (still don't, but I didn't then either) and I used a mix of "pip install" and "sudo pip install" when the former didn't work. I could only work on one thing at a time with this approach, and switching was a huge task because I had to figure out all the places where packages had landed and either remove them individually or blow the whole thing away.
For early startups, I've been doing "Debian Stable" as the default, partly so that we don't have to spend any time on any surprise distro changes when we're focused on MVP, etc.
And in 2 years, the startup will probably have a lot more resources, and we can look at whether that still makes sense, though we might just end up doing an in-place APT `dist-upgrade`, or coast on `oldstable` awhile if the timing is not right yet.
I also try to use the same distro on workstations and in production, to permit lightweight efficiencies, like experimenting and debugging outside of containers on workstations, without special tooling, while still having a close match to production. So, Debian Stable everywhere.
A recent Ubuntu LTS would also work for this (and sometimes be easier for things like Nvidia SDK), though Debian has been arguably a bit better for security and stability lately.
For things not in the Debian Stable we're using, such as if we need a bleeding-edge version of some key thing, and we have big security/reliability requirements... I manage non-Debian-packaged third-party dependencies in our own Git repo, and track and vet updates. This also means trying to minimize these dependencies, more than we would if we were pulling in 100 packages casually from a language-specific package manager, since each package is additional work.