Matthew GarrettJun 16, 2023
Hot take: your desire to run your choice of OS on your work laptop does not trump my desire to ensure the safety of data belonging to our users
Show threadSaphira Lohikäärmekettunen Jun 16, 2023
@mjg59 what if my efficiency diminishes a lot with any OS choice given by the company (or you in this case)?
Should this at least be a reason for you to make it work reasonably safe but not just "take this OS and none other"?
Show threadMatthew GarrettJun 16, 2023
@littlefox if your employer can't support an OS that allows you to work effectively then it's time to find another employer, just as in any other case where employer policies interfere with your ability to do work
Show threadMatthew GarrettJun 16, 2023
@littlefox if the default is just to allow anything then you end up with someone insisting on Windows XP and then their prod creds getting stolen and now you're going to have a bad day
Show threadMatthew GarrettJun 16, 2023
@littlefox And if instead you want IT to support managing an additional range of special-cased OSes then you may improve some developer efficiency but at a significant cost to IT and security efficiency
Show threadSaphira Lohikäärmekettunen Jun 16, 2023

@mjg59 it's a hard trade-off between cost and developer efficiency

I get the need to restrict developer (or any user) choice, but also really get the need for "the tools I work with fast", the frustration from not being able to use them

It's hard

Had such a discussion with our CEO some weeks ago, but we didn't find a way to easily resolve this

Show threadJosh Triplett
It doesn't help that the mechanisms used to enforce "don't run some obscure Linux/BSD/etc distro and fail to install security patches" or "don't access production user data without massive restrictions" often also effectively enforce one or more of:
- "don't run newer software (that you need to get your job done)"
- "don't have remote access to systems that IT isn't allowed to have remote access to or any control over" (e.g. community/project servers)
- "don't have private keys IT shouldn't have remote access to"
- "don't expect to build quickly or have your tests reliably pass or get sensible results out of performance analysis, because you've got mandatory scanners on your system"
- "don't have experimental test systems" (yes, there *are* IT departments that think new-board bringup systems should have virus scanners on them)
- "don't expect to change system configuration because you don't have root".

In isolation, restrictions to supported/secure/up-to-date distributions are not by themselves inherently bad. And frankly, systems where you can access *production user data* should absolutely be locked down incredibly tight and should not prioritize developer comfort or privacy. But once you go that route, quite a lot of what becomes *possible* to enforce on individual developer workstations can then cause major problems.

There are *better* solutions for all of those things, but that requires IT to recognize all of those things as problems and be required to provide better solutions.
Jun 16, 2023 at 8:26pmWeb