This is a sharp observation, and it goes even further: BeyondCompare easily allows one to hop into an editor at a specific location, while Total Commander, with its side-by-side view of the world, is n excellent trampoline into BeyondCompare.
In this kind of ecosystem (where visual tools strive to achieve some Unix-like collaboration), the super power of editors (and IDEs) is their scripting language, and in this arena it is still hard to beat Emacs (with capabilities that were present maybe 40 years ago).
It's a funny thing. I rely heavily on Ecco Pro, developed some 20 years ago. Still going strong on Windows 10, using 1.5MB RAM (Wunderlist takes up about 70MB on my Nexus 5).
The point, with nowadays web/mobile offerings, is that you don't really own them. They just come and go. No matter how useful or integrated into your work/life routines. I suspect a corresponding analogy can be made for could-based target environments. Something to think about.
Right. One should ensure that simply re-invoking the script will not break anything by itself. The end result between invocations may be different if scripts are modified between invocations, as getting configuration right is a tricky business.
Being heavily involved in setting up standard developer workstations, I consider this to be the only practical approach.
It's way beyond any specific config item (including telemetry). This is a sure way to get to a stable and consistent configuration.
A few comments:
- It is better to split such a mega-script into a set of named scripts, so admins can mix-and-match their own configuration set.
- The configuration set scripts should be re-entrant, that is, one can run it few times in a row, achieving the same stable result. This is an important principle because those scripts evolve over time until they are are stable, so the re-entrancy enabled the re-configuration game.
- Some configuration items are system-based while other are user-account-based. This means that the latter should be invoked automatically once a new user account is created.
- VM is your friend. Wash, rinse, repeat.
- It is not always wise to replace automation (PowerShell) invocations with direct registry modifications. Tradeoffs should be obvious.
- MDT setups should avoid direct system configuration wherever possible, and rely on configuration scripts instead.
- One of the features still not possible to script is setting the policy startup/shutdown/login/logout scripts. One can provide this manually in a base workstation image.
- Esp. on Windows systems prior to Windows 10: make sure PowerShell is stable - version and module-wise.
Not directly connected to VS Code launch, but rather to the New Microsoft phenomenon:
It is high time the MS offer a FUSE-like userspace filesystem for Windows (possibly, by purchasing Eldos). Along with package management (which is now addressed in Windows 10), this is one of the biggest holes in Windows armor.