Apple frequently introduces changes to its OS that caters to the average user without any hindsight for developers. A good example I had to deal with; I wanted to change the port the SSH daemon listens on. With El Capitan and future versions you have to temporarily disable SIP (System Integrity Protection) - which requires two reboots - in order to make the change to the ssh.plist file. As you can see it's a common problem: https://apple.stackexchange.com/a/208481 It's lots of little things like this that require extra effort on OSX but which are straightforward on a decent Linux distro.
I can still go into /etc/ssh sudo vim sshd_config, can my values, and they stick.
Just to test it, I did it right now, and I'm running 10.13.4, for what its worth.
What exactly was the issue with changing the sshd config? This isn't a SIP protected directory, which is the only thing that would prevent such a move.
Perhaps the requirement of sudo? I feel like most linux distros force that in the /etc directory too.
Changing /etc/ssh/sshd_config was my first attempt as well. But since this is OSX things are a little different, see here: https://serverfault.com/a/67616/
this security feature that is great for the vast majority of Apple's user's isn't convenient for me.
Luckily, Apple shipped SIP with the option to disable it, and it's not hard. So you can disable it once and then you never need to deal with issues like that again. It's weird because it sounds like you want the protection of SIP without the inconvenience of SIP, but that's never been possible with pretty much any security measure ever -- more safety means less convenience. That being said, to me Apple has actually been the best when it comest to safety/convenience ratio. Linux distros don't even have the option of SIP or something similar, so I can't say I find your argument compelling.
It's not the fact that the SIP is there which bothers me. It's that Apple introduces these kinds of things with little notice and without caring if they break compatibility. This has always been Apple's approach and it's just not friendly for developers.
Not all all, Linux is the culture of command line, where people improving UI/UX on GNOME/KDE always get bashed as taking the power away doing irrelevant work.
There is not a single cohesive stack of desktop technologies, what macOS calls Kits, Android frameworks, Windows UWP and such.
Something like Glade still fails short of what XCode or VS Blend are capable of.
Sure there is something like Qt QML designer, but that isn't Linux specific anyway.
You are missing context. Grandparent was claiming that Linux was the best OS he’d used for development (fair enough), but that he’d rather have Windows over macOS otherwise. That part I was hoping for clarification on.
Something I don’t quite understand, coming from a scripting-language bqckground: why are you using your OS’s provided compiler toolchain (for anything other than building OS packages for distribution?) Is there no version manager for clang the way there is for e.g. Rust?
Speaking about the classical C/C++ mainstream, and more from the Linux perspective:
Tooling for C and C++ mostly relies on some external package manager, often the OS-provided one (on most Linuxes, for example). There isn't a standard cpan/npm/pip/cargo for C/C++, although there are plenty of tools that can do kind of the same thing.
There's also not much support for virtual environments (there are tools out there, but not ubiquitous tools). It's pretty easy to point the compiler to a different set of header files and libraries, even on a per-file basis, to get a similar effect.
And from the Apple side (which I have a vague understanding of, having dipped my toes in a few times): Most of the documentation assumes that you're using XCode, and I'm pretty sure that the version of the compiler is just tied to whichever version of XCode you're using (which has a somewhat looser tie to the version of MacOS you're running). So in that case, you'd be using the XCode-provided toolchain rather than the OS-provided one.
Homebrew exists on Linux. I like running LTS distros because they just work. For newer per-project exceptions, I put everything into a container (again layered on LTS), it is esp nice for things like specific versions of LLVM which I wouldn't want to pollute my base machine with. My peronal userland gets shipped via, cargo, go, pip, npm, etc.
I try to put everything our team does into a container for the same reason. I'd point out though that the version of docker listed by apt on 16.04LTS is also really ancient. Pre docker-ce.
It's not just understanding the packages. When I upgraded from 16.04LTS to 17.10 I had to relearn how to compile the kernel because my laptop would no longer boot.
Wasn't that hard to do in the end but it's not something I've done for many, many years and doesn't fill me with confidence.
BASH is outdated, but I compile the latest version and install it in /bin (I have system integrity protection turned off).
Other UNIX utilities are actually standard POSIX ones. If you are used to GNU extensions to these on Linux, then Mac ones may seem outdated, but ironically (macOS kernel is called XNU which stands for X is not UNIX) Mac is certified UNIX, while Linux is only UNIX like.
