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
@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"?
@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
@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
@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
@mjg59 @littlefox also, I don't know all the tooling out there, but when I was doing infra at my last job I saw what the tools IT was using on Mac and Windows offered on Linux and I can say with full certainty that allowing me to use Linux was allowing me to get away with a vastly inferior level of mandated security. There simply isn't the security ecosystem out there that there is for more common OSes.

@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

@littlefox I'm enthusiastic about the goal being to find a way that lets developers work effectively without compromising on security (there's no point in security if nobody can do their job!), but the solution can't be for developers to assert they have the right to choose an arbitrary os
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.
@mjg59 @littlefox Which is usually the right answer, though. Surely the workflow should be "work out what OS your developers need in order to be effective, then hire IT people capable of supporting that OS", and not "work out what OS your existing IT people are capable of supporting, then tell your developers to use it"?
@TalesFromTheArmchair @littlefox If I have 15 different developers wanting to run 15 different BSD varients, the answer isn't to hire enough IT staff to manage 15 different BSD varients
@TalesFromTheArmchair @mjg59 but seems like especially when having a wide variety of jobs (datacenter people, network engineering, ops for different infra parts and toolchains, developers, again for many different toolchains and ecosystems), you'll end up with a wide variety of OS', toolsets and co favored by your people
@mjg59 @littlefox @TalesFromTheArmchair it’s got to be a bit of both. Any engineer who insists it’s my way (tools) or the highway is probably ignoring other rules as well.
@mjg59 @littlefox I know you're referring to software development settings. Other workplaces present different challenges. For me (working in healthcare and primary education settings, with a distant background in corporate infosec), it's common to feel that I'm better able to protect sensitive data than my employer, whose IT systems are often overseen by an overworked operations manager who's struggling to keep the lights and HVAC running, as well as manage a coterie of aging servers and desktops. But except when invited, I rarely deviate from the work systems I'm given, since I don't want the liability I'd assume in going my own way, even if I'd be more efficient (and even if my employer wouldn't care). The employer "owns" their policies and their consequences.

@littlefox @mjg59 Efficiency is, usually, the employer's concern. If my employer is happy to pay me for 10 hours of business-value-delivering work and 30 hours of fighting with OS config, why should I be unhappy to accept?

(If it gets in the way of personal growth and future career prospects, then sure. But very many things can get in the way of that too.)

@geofft @mjg59 because it's extremely frustrating to want to work on actual stuff and not being able too as efficient as I'm used to