So are they going to then tell Apple how much to charge for a licensing fee? Are they going to make Apple make MacOS work well on other x86 machines? What happens if/when they move to ARM?
If you explicitly manage your scripting language versions, none of what you’ve described is a problem. Instead, your post reads from a perspective of fear, uncertainty and doubt that doesn’t line up with developer experiences.
As for iOS, it is not the same as macOS and should be considered separately. I’m not sure why you’ve equated the two (different use cases), but maybe you are genuinely (and unnecessarily) worried.
Alone removing perl would massively suck because many shellscript installers depend on some form of perl being present on the system, partially to avoid the differences between GNU/Linux userland (sed!) and OS X userland.
The fear is unification of iOS and macOS, which Apple has hinted at occasionally. macOS doesn't need to disappear completely for many fears to be realized. The more application APIs are unified, for example, the more pressure there becomes for macOS to deprecate and let stagnate its POSIX interfaces. And you don't need the POSIX interfaces to disappear completely for the environment to cease being targetable by most open source projects, especially command-line projects. Windows has a significant number of POSIX APIs stemming from Windows NT 4.0 POSIX compliance, but it's just not a practical Unix target based on that subset alone.
I disagree that anything hints at unification. They have literally said outright that they want one OS for each platform, hence why iPadOS was born proper.
The aim is to reach feature parity across their three systems though, so you have a point.
Scripting languages have been removed because bundling them created problems. Apps would rely on the system version so an OS upgrade that, for example, moved to Python 3 would break apps.
The solution is to bundle your own runtime, or install with homebrew if you’re a dev.
I really don’t see Apple removing the UNIX utilities and terminal.app any time soon. Of course if they do I’ll be in the market for a new OS.
> I really don’t see Apple removing the UNIX utilities and terminal.app any time soon. Of course if they do I’ll be in the market for a new OS.
Apple needs a development environment for its own in-house OS developers to use. macOS needs to have the necessary facilities to support its own development, and also the development of iOS. So long as Apple uses macOS as its OS development platform, it is going to want to keep the UNIX components to satisfy the needs of its own OS developers.
Although they seem to be more interested in keeping the bare minimum around versus making it easier for development, since there isn't a brew-esque thing built in (Windows at least has NuGet, albeit just like everything else in PowerShell, it's super unfriendly), the coreutils are old (this may be a licensing thing), and no Darwin containerization (which would be handy for development without having to give 2GB to Docker Desktop to get a Linux userland up).
It's still fine (my only major showstopper being that valgrind just straight up isn't a thing for recent versions of OS X, with the brew version not compiling on 10.15 or 10.14), but they definitely have enough resources to make it, you know, "just work". which hurts especially when Microsoft is going full "developers developers developers"
> Although they seem to be more interested in keeping the bare minimum around versus making it easier for development, since there isn't a brew-esque thing built in
I don't know anybody in the macOS development team, so I don't know their work practices, but it totally wouldn't surprise me if they've all installed Homebrew and use it heavily.
I infer Apple's attitude as being "if you are technical enough to use Homebrew, you are technical enough to download and install it yourself". (Or MacPorts, or Fink.)
If they bundle it... then people might start turning up at the Genius bar to complain "brew install X gives me an error!"
> my only major showstopper being that valgrind just straight up isn't a thing for recent versions of OS X, with the brew version not compiling on 10.15 or 10.14
I feel the same pain... I just use Docker for Mac to run valgrind for Linux. For my personal use cases, that works fine (since I don't write much macOS-specific code)
Many of them don’t, actually: they just use the toolchain that Apple provides, and of course all scripts internally work with the old BSD tools so there’s really no need to install anything else unless you really like vim or GNU coreutils or whatever.
I thought macports was the quasi-official option; at least, it had Apple employees as founding members of the project. Granted, it's a bit sad that there's no Official package ecosystem, although I agree with you that support issues might be at play.
> no Darwin containerization (which would be handy for development without having to give 2GB to Docker Desktop to get a Linux userland up).
Do you want containers with a Darwin personality, or Linux? The latter would require either ABI emulation like FreeBSD/SmartOS/WSL1, or virtualization+glue like WSL2 on Windows. Doable, but messy and unlikely from Apple's perspective ("clean" systems, heavily Apple-centric view of the world).
That is a bit interesting; the BSDs are still permissively licensed, so maybe Apple just doesn't see enough benefit to justify the effort of pulling in new features? (Or implementing features themselves, depending on how diverged the codebases are)
I think they just don’t care. If you look at their open-source tools, they often have compile-time flags disabling code paths with better performance, probably so they can reduce the amount of code they need to worry about.
> the coreutils are old (this may be a licensing thing)
Not just coreutils, this extends to all third-party GPL tools.
> no Darwin containerization
Not for you, but I hear the simulators do some fun things with launchd namespaces ;)
> my only major showstopper being that valgrind just straight up isn't a thing for recent versions of OS X, with the brew version not compiling on 10.15 or 10.14
Valgrind doesn’t work because nobody has put in the time to make it work on new systems (keeping up with new macOS releases in a timely manner is extremely difficult unless an engineer is pushing for it, and AFAIK anyone who would has left the company or lost interest in doing this). Address sanitizer kind of does some of the same things, so you can try that.
I doubt they'd do anything to break Macs for developers because that's one of the big market segments for Macs. It'd be like removing emojis from the iPhone. :)
Apple has demonstrated for years now that they're not interested in the enthusiast/power user/developer market. They want the profits that come from disposable mass market devices. The switch to ARM laptops would be the perfect time to switch all of their laptops over to iPadOS.
Sadly, I think a more representative title would be "How long will UNIX survive?". macOS is the only widespread version of UNIX left, and as it converges with iOS and loses its command line ecosystem, it will be the effective end for UNIX.
Ignoring the parallel universe of Mainframe computing, server UNIX has been replaced almost completely by server linux. The Free/Open/Net BSDs are knocking around both desktop and server spheres, but they are not common. Desktop macOS is the only recognisable strain of UNIX you are likely to encounter.
I agree with the point made by the OP of course, and I've swapped my MacBook to Ubuntu for this reason.
IIRC PS4 relies upon (Free?)BSD, because of the permissive license, and there are probably other widely-used devices that do the same, so I'd imagine lots of people have a BSD or two in their home and don't even know it.
That's less of a surprise, IMO -- pf is a BSD utility and was originally developed for OpenBSD. It's right in the front of the name so there's no question what you're getting (as opposed to OSX, where there is a base there, but no one would know it unless they're Unixy types).
I think we all can agree here that most of us care about "UNIX user experience". The shell, the tools we can combine, APIs, man pages at my fingertips, etc. As far as I'm concerned there can be NT kernel beneath that doing all the work, I couldn't care less.
"BSD UNIX" bears little code in common with
original Bell/AT&T "UNIX" due to the USL v. BSD lawsuit[1] anyway. The closest living relative of AT&T UNIX still in use at all is probably Solaris and it's successors.
I'm not sure Solaris really counts as "living" any more. AIX seems healthier, notwithstanding the tradition distaste for it in a lot of the Unix world.
Both Solaris and AIX crawl on, particularly in the banking sector where there are decades old applications that still need a platform to run on. A bank I worked for 7-8 years ago had a project running to refresh the hardware platform for both for the next 10-15 years.
IBM of course has the resources to prop up AIX as long as it has customers that depend on it, whereas Solaris is now pretty much dependent on the community. At least it is based off of SVR4 and not SVR3 (like AIX), has source code available, and runs on x86. Not sure that will be enough for it to survive into the future though.
Well there’s nothing stopping you or me from picking a BSD and donating to the project monthly. It’s not the same as install base but probably way more important to them.
At this point the endpoint sphere is in transition. Someone could take a BSD and launch the next big thing on it if they had the right killer app. Netflix is a good example of this, or which ever consoles have ran BSD, too. I’d love to make my own startup with embedded or modded *bsd as well someday.
How many devs do you think will continue buying macs once the Unix CLI has gone?
If this happens, give me a call, and I'll help you build torches and sharpen pitchforks.
But until then, killing off your developer community is just about the stupidest thing you can do. Yes, it happens anyway (see also: Steve Ballmer), but what does worrying about it really get you, except worked up?
Oh, the irony! If the FBI released a lineup of suspects in the case of who killed Unix, those three names would be right at the top, with Perl as the ringleader* .
Besides, Unix isn't Perl, Python or Ruby. It's an OS turned API in the form of POSIX. BeOS was Posix compliant and could build and run Unix software. Even plan 9 can build Unix software using APE, the ANSI Posix Environment. Apple just doesn't feel like paying distro package maintainer.
Oh, horsefeathers. That's only true if you think C is the One True Language. The amount of system glue that was written in Perl (and later Python) through the late 90s and early 00s is one of the reasons the *nixes did so well.
It's possible that in a post-Catalina Mac world, Unix scripting languages -- at least the ones currently included with the system, e.g., Ruby, Python, Perl -- that Apple will use the same mechanism that they currently use for git and some XCode-specific command line utilities: when you type the command, you'll be told the application isn't installed and it'll offer to download it for you.
Even if that doesn't come to pass, I'm not super concerned about this. Which isn't to say that I'm serenely unconcerned, but as people have noted, there are ways to install and manage these without them being provided by the OS vendor, and probably most Mac users here have been doing just that for a long time.
I use MacOS heavily for command-line heavy programming work
> Future versions of macOS won’t include scripting language runtimes by default, and might require you to install additional packages.
This sounds sensible to me. For ruby, python, node etc you need specific versions for different projects. I literally never use the OS's python -- that's a private matter for the OS and if it doesn't need Python any longer then fine. (rbenv, pyenv, nvm etc help with managing versions)
> What bothers me the most though is that Apple has removed the man pages from their online documentation.
I recommend installing the coreutils package from Homebrew and using that over the BSD Unix utilities.
I also (perhaps controversially?) would recommend using --help over man pages where possible for the simple reason that you are probably fallible, like me! Us mere mortals tend not to have a clue whether the man pages we're looking at are for the executable we're invoking or not, and staying on top of man pages involve staying on top of a bunch of environment variables and weird directories that date back to the hairier days of UNIX. With foo --help, you are always 100% sure that it is giving help for what the executable "foo" resolved to.
If you're looking for a unix-based OS on which to develop software, and want a slick GUI on top of it for browsing the web, I encourage you to consider Chrome OS.
It is extremely secure, easy to use, and simple, and has allowed me to develop software on it like it is a linux machine.
I recently took a late 2011 Macbook Pro and installed Ubuntu 19.04 on it.
* It was easy. I don't know what to add except it was easy.
* It is fast. I now consider Mojave bloatware, although I didn't know it at the time. It appears that there are now so many things running in Mojave that my old macbook could not handle it. With Ubuntu 19.04 it is FAST. And what can you say? Except imagine what 19.10 would be like on a faster CPU. Not that I need it, but ...
* Its fun. Probably this is a function of how fast it is, but also most things just work very nicely. I'm fond of 19.10 in a way that I have not been fond of my macbook since maybe Sierra.
* I miss Apple-C and Apple-V for cut and paste and I miss iterm2, but that is all.
* The only thing I need a mac for is ios development and for that I plan to get a mac mini, but otherwise the run from an Apple II, through a Mac SE and an iMac has ended for me.
* Oh, and you can run wine and windows stuff really easily on 19.10.
Could you talk about battery life, sleep/wakeup, and trackpad feel? It's been many years since I tried this, and at that time those things were pretty bad.
...I've heard this alot but I run arch and have not once had an issue with power management. Maybe try gnome instead of unity or try kde if you like the Mac feel
I’ve used Ubuntu before completely switching to Mac 10 years ago and still use it sometimes on PCs. For me Ubuntu can’t be the primary os to use as there aren’t any decent software in for many activities e.g. image and video editing. One cannot just keep writing code on one screen and convert a bunch of raw photos on another simply putting all together to create final product. Linuxboxes aren't an option when your tasks are diverse, Linux is only ok when you just need to write code, any other tasks could be accomplished of course but not in macOS “just works” manner.
> What bothers me the most though is that Apple has removed the man pages from their online documentation. [..] So far, the best we can get is doing a search on the open source repository… until that goes away.
...Or you can just use the `man` command, which still works fine.
It seems like there's no ex-Apple weighing in. I worked there ~5+ years ago now & the OS-bundled versions were such a pain that even internally we were avoiding them. I'm not 100% sure but IIRC the issue with having python bundled is the OS is that the specific version then became required to ship meaning we were stuck on ancient versions of Python2/Python3 internally (& same for Ruby probably) to make sure that externally people relying on specific behaviours stayed functional. Additionally having them (or at least Python) installed at the system level caused all sorts of havoc in terms of interplay with other Python versions installed via homebrew if you weren't super-careful with how your paths resolved (& sometimes even then). Finally, externally most Python shops would end up installing Python via other means (e.g. homebrew) to make sure they're using the latest version & using virtualenvs which are best-practices & what we ended doing internally for our scripts too. The title & article is pure FUD - there may be reasons to worry about whether macOS remains UNIX (I'm personally not too worried) but "they're no longer pre-installing scripting languages by default" is so far from that it's laughable.
NOTE: All of this is my own personal opinion & viewpoint and in no way should be construed to represent any secret internal knowledge of Apple's internal reasonings & whatnot (I have none)
I think you’ll find that they often do weigh in, but without announcing it because they’re trying to avoid providing information that would force them to put the disclaimer you did ;)
> I'm not 100% sure but IIRC the issue with having python bundled is the OS is that the specific version then became required to ship meaning we were stuck on ancient versions of Python2/Python3 internally (& same for Ruby probably) to make sure that externally people relying on specific behaviours stayed functional. Additionally having them (or at least Python) installed at the system level caused all sorts of havoc in terms of interplay with other Python versions installed via homebrew if you weren't super-careful with how your paths resolved (& sometimes even then).
I believe this is LLDB linking against Python 2 in a way that is pretty much incorrect. I think Python 3 got a bump recently? For once this isn’t completely Homebrew’s fault :P
> I think you’ll find that they often do weigh in, but without announcing it because they’re trying to avoid providing information that would force them to put the disclaimer you did ;)
That may be true in general but this specific thread appears to be filled with wild speculation without attempting to understand the motivations behind this move, hence why I felt the need to try to provide what I hope is some more meaningful context.
I ported pacman to OS X more than 10 years ago. I’ve been handling it by myself for my own usage since then as Arch OS X, then ArchMac. I had a couple of Darwin specific patches, and I started ramping up to build stuff on Catalina first since that’s current and what free CI for FOSS are moving to. It feels like I’m close to a release compatible with Catalina but I keep on hitting strange weird bugs that did not happen when building on previous macOS versions, and keep having to work around stuff. What was a stable enough platform is now a significant pain even for trivial stuff. The last one is an obscure bug where a file existence test seems to return bogus results (there is no file in the package cache dir, yet pacman does not go through the download step when such a file is missing, and fails with a NULL pointer assertion as the later state is inconsistent. Same source code works with flying colors when built on a previous darwin). With some time I could probably add yet another patch to fix that, but I’m left wondering if it’s really worth it now, as if the trend continues as it did for the last three versions darwin20 will be even more painful to support, if at all.
ArchMac is not the only one impacted, e.g
- nix found a workaround to install on /nix but it’s a pain involving APFS volumes and synthetic.conf
- homebrew relies on ruby which will be removed in a future version
- with the impending Damocles sword of notarized binaries it will be a serious pain to do package management
And that’s just the most structural ones. Death by a thousand cuts isn’t far off.
The X of Mac OS X has been dropped for some time now for branding reasons, but reality seems to come to terms with that symbolic move.
At no point in my life has it ever been hard or regretable to install Linux on anything. I hear talk about trackpads and Bluetooth not working, but I've never experienced this at all. Maybe it's because I use i3 and vim but it just seems like if you want a development environment what more do you need besides a working terminal and a robust package manager which every distro has out of the box. Mac has always just seemed like a gimmick to me and after getting one at work I just find that at best it feels like a bloated freeBSD. If I wanted Unix there are plenty of superior alternatives and if I want to get work done I install Linux.
88 comments
[ 3.3 ms ] story [ 144 ms ] threadIf Euro governments want to do something real about antitrust, this would be a good place to start.
As for iOS, it is not the same as macOS and should be considered separately. I’m not sure why you’ve equated the two (different use cases), but maybe you are genuinely (and unnecessarily) worried.
The aim is to reach feature parity across their three systems though, so you have a point.
The solution is to bundle your own runtime, or install with homebrew if you’re a dev.
I really don’t see Apple removing the UNIX utilities and terminal.app any time soon. Of course if they do I’ll be in the market for a new OS.
Apple needs a development environment for its own in-house OS developers to use. macOS needs to have the necessary facilities to support its own development, and also the development of iOS. So long as Apple uses macOS as its OS development platform, it is going to want to keep the UNIX components to satisfy the needs of its own OS developers.
It's still fine (my only major showstopper being that valgrind just straight up isn't a thing for recent versions of OS X, with the brew version not compiling on 10.15 or 10.14), but they definitely have enough resources to make it, you know, "just work". which hurts especially when Microsoft is going full "developers developers developers"
I don't know anybody in the macOS development team, so I don't know their work practices, but it totally wouldn't surprise me if they've all installed Homebrew and use it heavily.
I infer Apple's attitude as being "if you are technical enough to use Homebrew, you are technical enough to download and install it yourself". (Or MacPorts, or Fink.)
If they bundle it... then people might start turning up at the Genius bar to complain "brew install X gives me an error!"
> my only major showstopper being that valgrind just straight up isn't a thing for recent versions of OS X, with the brew version not compiling on 10.15 or 10.14
I feel the same pain... I just use Docker for Mac to run valgrind for Linux. For my personal use cases, that works fine (since I don't write much macOS-specific code)
Old, or BSD? Darwin never used GNU coreutils.
> no Darwin containerization (which would be handy for development without having to give 2GB to Docker Desktop to get a Linux userland up).
Do you want containers with a Darwin personality, or Linux? The latter would require either ABI emulation like FreeBSD/SmartOS/WSL1, or virtualization+glue like WSL2 on Windows. Doable, but messy and unlikely from Apple's perspective ("clean" systems, heavily Apple-centric view of the world).
Old and BSD.
> The latter would require either ABI emulation like FreeBSD/SmartOS/WSL1, or virtualization+glue like WSL2 on Windows.
Both have been “done” by third-parties. (As in: they exist; they’re not perfect.)
That is a bit interesting; the BSDs are still permissively licensed, so maybe Apple just doesn't see enough benefit to justify the effort of pulling in new features? (Or implementing features themselves, depending on how diverged the codebases are)
Not just coreutils, this extends to all third-party GPL tools.
> no Darwin containerization
Not for you, but I hear the simulators do some fun things with launchd namespaces ;)
> my only major showstopper being that valgrind just straight up isn't a thing for recent versions of OS X, with the brew version not compiling on 10.15 or 10.14
Valgrind doesn’t work because nobody has put in the time to make it work on new systems (keeping up with new macOS releases in a timely manner is extremely difficult unless an engineer is pushing for it, and AFAIK anyone who would has left the company or lost interest in doing this). Address sanitizer kind of does some of the same things, so you can try that.
Ignoring the parallel universe of Mainframe computing, server UNIX has been replaced almost completely by server linux. The Free/Open/Net BSDs are knocking around both desktop and server spheres, but they are not common. Desktop macOS is the only recognisable strain of UNIX you are likely to encounter.
I agree with the point made by the OP of course, and I've swapped my MacBook to Ubuntu for this reason.
FWIW, I think "Unix" as a philosophy exists (even mainly exists) outside the spec certification, but this is how you get there.
Inspur has K-UX, however, I have never used it, so can't comment on it other then knowing it runs a Linux kernel.
https://en.wikipedia.org/wiki/PF_(firewall)
[1]https://en.wikipedia.org/wiki/UNIX_System_Laboratories,_Inc.....
IBM of course has the resources to prop up AIX as long as it has customers that depend on it, whereas Solaris is now pretty much dependent on the community. At least it is based off of SVR4 and not SVR3 (like AIX), has source code available, and runs on x86. Not sure that will be enough for it to survive into the future though.
At this point the endpoint sphere is in transition. Someone could take a BSD and launch the next big thing on it if they had the right killer app. Netflix is a good example of this, or which ever consoles have ran BSD, too. I’d love to make my own startup with embedded or modded *bsd as well someday.
If this happens, give me a call, and I'll help you build torches and sharpen pitchforks.
But until then, killing off your developer community is just about the stupidest thing you can do. Yes, it happens anyway (see also: Steve Ballmer), but what does worrying about it really get you, except worked up?
Oh, the irony! If the FBI released a lineup of suspects in the case of who killed Unix, those three names would be right at the top, with Perl as the ringleader* .
Besides, Unix isn't Perl, Python or Ruby. It's an OS turned API in the form of POSIX. BeOS was Posix compliant and could build and run Unix software. Even plan 9 can build Unix software using APE, the ANSI Posix Environment. Apple just doesn't feel like paying distro package maintainer.
* See #8: https://interviews.slashdot.org/story/04/10/18/1153211/rob-p...
Even if that doesn't come to pass, I'm not super concerned about this. Which isn't to say that I'm serenely unconcerned, but as people have noted, there are ways to install and manage these without them being provided by the OS vendor, and probably most Mac users here have been doing just that for a long time.
> Future versions of macOS won’t include scripting language runtimes by default, and might require you to install additional packages.
This sounds sensible to me. For ruby, python, node etc you need specific versions for different projects. I literally never use the OS's python -- that's a private matter for the OS and if it doesn't need Python any longer then fine. (rbenv, pyenv, nvm etc help with managing versions)
> What bothers me the most though is that Apple has removed the man pages from their online documentation.
I recommend installing the coreutils package from Homebrew and using that over the BSD Unix utilities.
I also (perhaps controversially?) would recommend using --help over man pages where possible for the simple reason that you are probably fallible, like me! Us mere mortals tend not to have a clue whether the man pages we're looking at are for the executable we're invoking or not, and staying on top of man pages involve staying on top of a bunch of environment variables and weird directories that date back to the hairier days of UNIX. With foo --help, you are always 100% sure that it is giving help for what the executable "foo" resolved to.
It is extremely secure, easy to use, and simple, and has allowed me to develop software on it like it is a linux machine.
* It was easy. I don't know what to add except it was easy.
* It is fast. I now consider Mojave bloatware, although I didn't know it at the time. It appears that there are now so many things running in Mojave that my old macbook could not handle it. With Ubuntu 19.04 it is FAST. And what can you say? Except imagine what 19.10 would be like on a faster CPU. Not that I need it, but ...
* Its fun. Probably this is a function of how fast it is, but also most things just work very nicely. I'm fond of 19.10 in a way that I have not been fond of my macbook since maybe Sierra.
* I miss Apple-C and Apple-V for cut and paste and I miss iterm2, but that is all.
* The only thing I need a mac for is ios development and for that I plan to get a mac mini, but otherwise the run from an Apple II, through a Mac SE and an iMac has ended for me.
* Oh, and you can run wine and windows stuff really easily on 19.10.
...Or you can just use the `man` command, which still works fine.
NOTE: All of this is my own personal opinion & viewpoint and in no way should be construed to represent any secret internal knowledge of Apple's internal reasonings & whatnot (I have none)
I think you’ll find that they often do weigh in, but without announcing it because they’re trying to avoid providing information that would force them to put the disclaimer you did ;)
> I'm not 100% sure but IIRC the issue with having python bundled is the OS is that the specific version then became required to ship meaning we were stuck on ancient versions of Python2/Python3 internally (& same for Ruby probably) to make sure that externally people relying on specific behaviours stayed functional. Additionally having them (or at least Python) installed at the system level caused all sorts of havoc in terms of interplay with other Python versions installed via homebrew if you weren't super-careful with how your paths resolved (& sometimes even then).
I believe this is LLDB linking against Python 2 in a way that is pretty much incorrect. I think Python 3 got a bump recently? For once this isn’t completely Homebrew’s fault :P
That may be true in general but this specific thread appears to be filled with wild speculation without attempting to understand the motivations behind this move, hence why I felt the need to try to provide what I hope is some more meaningful context.
ArchMac is not the only one impacted, e.g
- nix found a workaround to install on /nix but it’s a pain involving APFS volumes and synthetic.conf
- homebrew relies on ruby which will be removed in a future version
- with the impending Damocles sword of notarized binaries it will be a serious pain to do package management
And that’s just the most structural ones. Death by a thousand cuts isn’t far off.
The X of Mac OS X has been dropped for some time now for branding reasons, but reality seems to come to terms with that symbolic move.