Debian is not a good distro for development. They have an intrusive package management philosophy that expects to be able to manage everything on the system, installing up to date things from a language package manager is harder on Debian than elsewhere.
(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.
> 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.
If you do that then you undermine the idea of being able to do lightweight debugging etc., and there's no particular merit to matching your servers. You need a reasonably stable workstation environment, but it doesn't really matter if different developers use whatever they're most comfortable with as long as it makes them productive, and people will probably want more up-to-date tools than what's available in Debian Stable. (In practice a lot of people who follow this model end up using Macbooks, and it's... fine, not an awful way of working, but not the clear best either).
> 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).
> Why? Your system is (or should be) a single-purpose tool.
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.
It's a tradeoff to be sure, but IMO if you're a developer then development and especially debugging should be the priority. I've worked at one place where developers had a second "office machine" that we used via RDP for doing emails/presentation/etc., kind of an inversion of the usual suggestion of setting up your main system with a stable environment and using a VM to match your deployment environment. I found that way more productive, because using a remote or VM imposes much less overhead on everyday office stuff than it does on debugging where you want to be able to connect your IDE to the running process, add packet filters to your kernel or whatever. But I guess YMMV.
I want a system that's better at playing nice between system-managed and developer-managed packages. Distributions that stick closer to upstream (e.g. Slackware, Gentoo, or especially FreeBSD with the built-in ports system) are better than Debian for developer machines IME.
> installing up to date things from a language package manager is harder on Debian than elsewhere
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.
(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.