In 2011 I switched to macOS due to my job and I have never had to deal with any of that. Ever. Perhaps the Linux laptop experience has improved significantly since then though.
Furthermore, there was no hardware nearly as nice as Apple laptops on which to install linux. (Yeah, other than Apple laptops, but I felt like I didn't have the money to justify that).
However I of course agree with your points regarding Vagrant/Docker and shell scripting. It is a shame that MacOS could not be based on Linux.
If you want to run Linux on a laptop and get the best experience, a Mac is not the best option. Thinkpad (business class X and T series) is what you are looking for.
But first of all development without docker is much faster. Setting up a docker container takes some time (especially with a custom built apache server).
Secondly running a docker machine (needs a Linux VM) on mac in parallel to Vagrant (I have to use it too) is CPU taxing as both (docker machine and vagrant) VMs take a lot of power from main CPU.
Add to this constant port conflicts and network paths resolutions issues between different docker containers and hosts. Also it forces me to use Oracle Virtual Box (who likes Oracle ?) These little things all add up.
My point is that what should be a trivial task, is not so trivial when deployment is done on one platform and development is done on another. I agree with original comment that it probably makes sense for industry as a whole to switch to Linux development workstation instead of Mac.
The only reason I use Mac besides it is a company policy is because OSX somehow able to render better fonts. My eyes are getting tired after looking on poorly rendered fonts from Linux machines. If you use Mac and want to see how Linux fonts look like - install SeaMonkey browser. It turns off all proprietary patented algorithms available on OSX and renders fonts exactly as on pure Linux where due to some licensing issues many nice font rendering technics are disabled.
I don't, because docker is a buggy, embarrassingly-poorly-designed system and VMs are a pain. I develop on the same system I deploy on: Debian stable.
> And even when you have only one project, who wants to run debian stable or centos as his main OS?
I loathe CentOS, but I love Debian stable. It's a wonderful, solid (one might even say … stable) system. Why wouldn't I want to run it as my main OS?
One of the things I really hate about our development culture is the cult of the new. It's a good thing to use stable, well-tested systems. Let others find the bugs; I'm happy to get work done.
I haven't used these two in particular, but if they support flatpak, why not? You'd have the same packages as on the server plus the latest versions of GUI apps.
If you are Python developer, install specific version your project needs and use that. Same for any other language.
Not sure what you mean by outdated compiler? For what? C, C++ etc are distributed with Xcode and clang is usually standard compliant and recent.
BASH is the only problem. Newer BASH versions switched to GPL v3 and Apple will never upgrade to that.
My personal solution for that is to disable system integrity protection, build latest bash and install in /bin.
This way most scripts that have #!/bin/sh or #!/bin/bash and rely on new BASH features just work.
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.
> 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.
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.
* a convoluted process involving Vagrant, Docker, or both, because you depend on one or more pieces of software that don't run at all on OSX, including Docker itself.
* slogging through bugs specific to services running on OSX because they really only support Linux well, such as Cassandra or Kafka, or even MySQL.
* Getting shells scripts that work reliably on both OSX and Linux, especially as the tools used to do so break backwards compatibility, either by Apple itself or by 3rd party tools like HomeBrew.
* Getting a consistent development environment at all on OSX. Doing so seems to be much easier on a Linux distribution than on OSX.
And that's not even talking about general issues like:
* incredibly flaky bluetooth drivers, often requiring a full restart to fix, if not having to reset some weird hardware bit.
* My laptop randomly not waking up properly from sleep and requiring a restart.
* My laptop randomly beach-balling more often than I ever saw BSoDs on windows.
* OSX seeming to just run really slowly compared to Linux whenever it is stressed in any meaningful way.
* My laptop's wifi not working with random wifi endpoints, such as at the airport or hotel. Whether it's router software bugs or OSX bugs, I am always able to connect just fine on my windows laptop.
* Having to deal with OSX's incredibly outdated userland and its BSD-specific userland. Yes, there are workarounds, but they are generally a pain to figure out and have not been standardized in our environment in any way.
* For a few months my OSX terminal was SEG-faulting about twice a week. I learned to be very grateful for screen/tmux during that time. At some point Apple seemed to fix it, at least.
At $lastjob we were actually developing a Linux service that relied heavily on Linux APIs because it was essentially creating full-on Linux containers like Docker. Before I joined, the previous developers, all big apple fans, were actually going through the tremendous effort of trying to make the service at least build and run on OSX, even if it no-oped most of the things it did.
When I joined, one of my first acts was to completely remove OSX support for this service, and I promise you that life got way easier ever since. Our development processes got simpler. Our build system got simpler. And most of all, our source code got simpler and easier to read.
Granted, most of us aren't developing software that directly calls into Linux APIs, but even then I think you'll find huge productivity wins if you just use a Linux laptop or desktop, assuming everything else is equal.