Yes, macOS is a BSD - UNIX Certification and POSIX compliance is nice, but macOS does not behave the same way as Linux, which famously is not a Unix (it's even in the name), and POSIX compliance doesn't mean much today: even Windows 2000 and Windows Server 2003 were POSIX compliant with SFU.
From what I gather from people with far more experience than me: if you need a "Linux-compliant" environment you're better-off with WSL2 than macOS.
I'd argue you're better off with macOS + something like Parallels or, if you just need ubuntu, multipass. Introducing Windows to get a Linux-compliant environment is reaching around your back to scratch your elbow.
My use case for WSL is slightly different: I work with developers who run Windows and I'd like to be able to figure out workflows that will work on their systems. A coworker today was having issues with running a Docker container that apparently had something to do with how Docker was interacting with WSL, but I couldn't reproduce on my Linux or Mac systems.
MacPorts makes your Apple a Unix box in userspace and has most of the apps and frameworks and languages.
WSL2 is just running a Linux in a VM. You can do that with VirtualBox and other hypervisors. You can also spin up a Kubernetes runtime that supports Apple's Hypervisor Framework.
Ah true, some SW is built for specific Linux distros (on one side, it's hard to build an "universal binary" but on the other side, I've seen very ugly software installs)
My mac using coworkers constantly complain that the *NIX parts of Mac are ancient and out of date and already use a linux VMs on top of Mac for better bash or whatever.
But then you have to deal with a VM on top of the host macOS. IMO it's way easier to install brew, install an up to date copy of bash (which is more recent than Ubuntu has), and coreutils, and just use macOS. Having to do gls occasionally (for GNU ls) is minorly annoying, but way less work than a whole freaking VM.
They might be bumping into old versions of utilities up to just before GPLv3.
From GPLv3 onwards, Apple has had to leave installation of newer versions of tools to users, legally, our publish their own proprietary IP, Stallman’s objective some would say.
That’s simply FUD. Apple seemed to be able to use GPLv2 without any consequences, and GPLv3 has all the same properties in that regard. The real reason is likely this:
Anyway, the message is pretty obvious: Apple won’t ship anything that’s licensed under GPL v3 on OS X. Now, why is that?
There are two big changes in GPL v3. The first is that it explicitly prohibits patent lawsuits against people for actually using the GPL-licensed software you ship. The second is that it carefully prevents TiVoization, locking down hardware so that people can’t actually run the software they want.
So, which of those things are they planning for OS X, eh?
I’m also intrigued to see how far they are prepared to go with this. They already annoyed and inconvenienced a lot of people with the Samba and GCC removal. Having wooed so many developers to the Mac in the last decade, are they really prepared to throw away all that goodwill by shipping obsolete tools and making it a pain in the ass to upgrade them?
From what I hear, Clang development has slowed to a crawl and GCC leads in new standards compliance and features, since major past Clang supporters have stopped contributing to concentrate on their own languages.
But I see that user ‘pjmlp’, who probably has a much more informed opinion than mine, is posting in this thread.
Then your were lied to (or legal was incompetent). GPL has no way to force anyone to publish internal proprietary source code. Any copyright infringer always has the option to stop distributing. If they want to keep distributing something, they have the option to re-implement the missing functionality themselves.
Well I was there for years, and it seems Apple legal should know more about this as a concern than most, and they clearly didn't lie to us about it being a concern for _them_. (Still consistent with your point: it could be their own fear/uncertainty/doubt.)
Perhaps legal decided the fiasco wasn't worth a protracted court battle, and PR digressions, and foisted the option of re-implementing missing modernized functionality on homebrew/macports, on purpose?
Well, I would tend to trust the FSF’s legal opinions about the GPL over that of Apple’s lawyers. Addidionally, Apple didn’t seem to have a problem with GPLv2, and GPLv3 is no more copyleft than v2 was. Finally, the “might be forced to release proprietary code” story is, while FUD, extremely well-known FUD, repeated for decades industry-wide by GPL naysayers, and would be an appropriate choice for a believable story to tell the programmer employees.
If Apple merely wanted to save on work and dump it all on third-party ports, why not remove packages outright or, for a period of time, make them available as official add-ons? Why, in that case, keep ancient versions as part of the OS? Why remove something as widely used as Samba, which as I recall garnered some criticism at the time? It seems likely to me that Apple has some other reason than that to remove all GPL-licensed packages.
Which parts in particular? I’ve seen literally hundreds of developers use macOS (including myself) for over a decade either at work/ conferences/meetups and never seen them use a Linux VM apart from something like docker, etc.
Docker has much better IO perf with lot of small files on WSL vs Mac. Currently doing Rails development and had to revert to running local straight up on Mac vs Docker because on Docker it was extremely slow. This of course means more testing on prod like cloud envs so it is really a load of crap.
I've experienced this with IO performance for huge files too. A while back I setup a caching service on a spare older Mac Mini first with Docker for macOS and when it couldn't keep up I installed Windows and it was slightly better but still crap. I threw Ubuntu on it and I was saturating the gigabit connection without breaking a sweat.
I'm also a Rails dev and I do all my dev work on an M1 mac and don't even have Docker installed, though I've heard it has improved a lot recently.
I used WSL2 on Windows 10 to compile the WSL2 kernel with additional flags supporting wireguard. So I'm pretty sure compiling works, maybe it was an issue with WSL1?
I concede technically yes it can compile some things but there is such a large catalog of software which fails to compile in WSL2 it’s frustrating. A great example is the many Python modules with c extensions.
