Just use docker or a VM for matching your production environment. Then your devs can use whatever device they're comfortable with. Add in a CI environment and then suddenly you don't need to force the same OS on everyone. Everybody likes something different.

Its better than nothing, but you still have added extra risk by doing it this way:

Are all the VM's exactly the same

Can you 100% prove that the vm behaves identically on all the varied hardware.

And no "professional" would consider "Everybody likes something different" is ever valid for a paying job!

No problem if its a hobby project but on a project with even a small number say 5 or 6 the risk isn't worth it.

Once again, this is why CI is important, it acts as a final test to make sure things build and run correctly. If your deployments go through the entire CI process before going anywhere important, the source of the work (developers' particular workstation setup) is not as important.

> Are all the VM's exactly the same

Is the silicon die on your processor exactly the same as everyone else on your team? If not, you're not a TRUE professional.

> Can you 100% prove that the vm behaves identically on all the varied hardware.

No, but I also recognize that I (and many other devs) are not writing space shuttle / train control / self-driving car software that is responsible for human lives. If I were, I wouldn't be advocating for the style of development I mentioned above. That is a different situation which I imagine most people on this site are not dealing with.

> And no "professional" would consider "Everybody likes something different" is ever valid for a paying job!

What does this even mean? Of course it can be "valid" for a paying job. There are literally companies out there who offer different OSes and machines to use for a job and the developers get paid. You get to deem they are not "professional" because...?

> No problem if its a hobby project but on a project with even a small number say 5 or 6 the risk isn't worth it.

The risk doesn't lie with the number of people on a project but the scope of the project itself: basically, can human lives be impacted in a significant way if a dev screws up? Then yeah, there are better, more rigorous ways. Are you writing a web app, a desktop GUI, some CLI tool, or perhaps...the Linux kernel? Then develop on the machine you like! Have a good review process, set up CI to build for the platforms you support, and implement a good set of tests.

"Is the silicon die on your processor exactly the same as everyone else on your team?"

Of course I have worked on projects where all the test dev and live hardware was explicitly brought from the same production run so the hard ware was identical down to the rev no of the pcb's - our hardware guy would have liked to have all the disk also from the same production run.

Can you "100% prove" that your destop Linux distribution has the same kernel modules and packages, and that none of the versions or patches diverge from the server your project is destined for?

I don't even know what hardware I'm deploying on. Amazon/Google/Azure has abstracted that away from me.