2 ms·

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

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

lmm 4y ago
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).
- sangnoir 4y ago
  > 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.
  - lmm 4y ago
    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.

lmm 4y ago

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

sangnoir 4y ago
> 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.
- lmm 4y ago
  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.