Not only do they forbid devs to use Linux on their dev machines, they then proceed with cb.exe etc. Nothing shows how they value your time quiet as much as these artificial slowdowns they love to introduce. (Along with gigantic privacy issues, as it allows the employer to essentially look at a live feed of your desktop whenever they want)
I could understand it if your device needed special access (VPN to prod etc), but you usually can't do that either from the dev machines - and need to first connect to a virtual machine (via browser or rdp) to be able to do that...
Well, we use Linux dev machines but IT has loaded them up with enough panopticon software that several times a week for an hour or so I can not get enough CPU or resident RAM to do productive work. But at least there are no forced system reboots at inconvenient times during the work day.
At a previous job they offered Linux laptops (yay!), but...
- umask was not 022, so installing pretty much anything with `sudo make install` would fail, as would some software.
- Running nmap caused an alert to phone home to IT, who would nag me on slack.
- Opening well-known ports to my LAN (like 22) caused an alert to IT.
- An "agent" program ran constantly, often using 100% of a CPU. The system overall had about 45 minutes of battery life.
- Various system settings were overridden by a sysctl.d/ file that was regenerated by the agent at boot. Fortunately I know how ASCII sorting works and could produce a file that overrode the overrides.
- Various capabilities (CAP_...) were disabled for my sudoer user.
It wasn't that bad, and IT was helpful, but it was a persistent annoyance. Maybe what happened is somebody googled "how to harden Linux" and then just made everything on the first page of results company policy.
I could understand it if your device needed special access (VPN to prod etc), but you usually can't do that either from the dev machines - and need to first connect to a virtual machine (via browser or rdp) to be able to do that...