Not surprising at all. It's become clear that what they've been doing with iOS all along is bootstrapping a new operating system. They started with Unix, not because Unix was optimal for what they wanted to do, but it's what they had and it worked well enough. Copland and Taligent and the rest failed because of Second-System Effect, which Apple was smart enough to avoid.
(As RMS wrote in 1983, "Unix is not my ideal system, but it is not too bad. The essential features of Unix seem to be good ones, and I think I can fill in what Unix lacks without spoiling them. And a system compatible with Unix would be convenient for many other people to adopt.")
Whereas such features as "background tasks" were simply a natural consequence of the architecture of Unix, Apple didn't expose that on iOS. Now they've finally gotten around to designing the background task subsystem they really want, and it's not just an emergent property of the generic Unix way. It's built for protecting battery life and privacy. It happens to be built on Unix processes (right?), but that's just an implementation detail for them.
They've been gradually deprecating Unix for 20 years, and designing the OS they want. iOS and its App Store allowed them to kill off large sections of the old interface at once. I fully expect inside of 5 years for all of Apple's operating systems to drop "UNIX" certification and become almost unrecognizable as "Unix". They've got enough market clout now that people will port Ruby/Python/Perl to a non-Unix macOS, just as they port them to Microsoft Windows.
I think you’re overthinking this. The vast majority of Ruby/Python programmers have been installing their own copies themselves, because Apple was pretty slow in updating them (Ruby is usually a few minor releases behind, Python is still 2.7 IIRC). People will just keep doing that, and nothing will change.
They may or may not be moving off Unix, but this isn’t evidence of that.
As a counter-anecdote, the built in Ruby interpreter in Mac OS X Tiger was the way I learned to program and how I got interested in programming. I don't think a bare Ruby interpreter is the best way to get into programming, but Apple hasn't been great at encouraging programming among kids. As a kid, its development tools were totally baffling, where Ruby was much easier to understand.
But that's teaching a new generation of coders a set of tools designed only for Apple. Ruby (Python etc) are open and easily available on other platforms, Swift may be in the future but it isn't now.
Once you’ve learned one programming language, it’s not hard to learn a second. It’s not terribly important what you’re first language is, and Swift isn’t a bad starting point anyway.
Funny. I learned on qbasic and I
remember they were teaching dr racket at ubc to first year students. They were teaching java when I was in engineering and my career has basically gotten zero
Mileage from that stinking heap of uncollected garbage.
One of the things that drew me to Macs as I started to learn programming in '05 was that I could simply open any macbook and type python/ruby/perl and write some code.
They just pack a statically compiled Ruby interpreter with Homebrew. Not very complex or novel. Disadvantage: install becomes more bloated (larger size).
Sure, it’s not a hard engineering challenge. However, installation instructions right now are as simple as “run this one-liner on your terminal”. That’ll have to materially change.
> Sure, it’s not a hard engineering challenge. However, installation instructions right now are as simple as “run this one-liner on your terminal”. That’ll have to materially change.
It could just as well still remain a one-liner. Every system Homebrew is installed on has Bash installed (not the latest, but still).
> Every system Homebrew is installed on has Bash installed
Ironically, they are also moving from bash to zsh for default shell. Again not an unsurmontable challenge (just make sure the bang is correct in your scripts, bash will likely still be around somewhere in macOS for the foreseeable future) but another little hurdle to mind.
As far as I'm aware they're not changing anything about which shells are installed or which executable /bin/sh points to they're just changing the default login shell for a new user, so nothing should have to change about the scripts that are (or have been) written.
I had the opposite experience with AppleScript - the development tool (Script Editor) was simple enough for me to understand that it was the way I taught myself to program when I was 13.
(OK, I learned Logo in school when I was 7, but programming became way more interesting when I discovered AppleScript's APIs to control all the programs on my Mac).
Sure... but that was then. I too had a real hard time learning Ruby back in the day. But now if you google any Ruby or Rails how-tos they will include a one-line Brew and RBENV install.
So I get what you are saying but I think we are in a new world here.
Right, I think most developers know that it's a bad idea to mess with the old, unmaintained system versions of Python, Ruby, or Perl. Almost everyone I know uses Homebrew to install the bleeding edge versions separately, and that will save you a world of pain.
For Python folks, just install pyenv/pipenv and you can easily maintain `system` (Python), Python2.7x, Python3.7.3, &c as separate environments. For Ruby people it's rbenv.
This alone isn't evidence of that, but it's not the only data point we have. We've got 20 years of observations. They dropped X11 (and didn't use it for the main display in the first place), created new process APIs (like GCD and background tasks), deprecated standard libraries like OpenGL (and don't support Vulkan), designed their own programming language, etc. All of these point in the same direction.
What will be left? Will it still be "Unix" in any meaningful sense just for having a C compiler and running an old version of Bash? Microsoft Windows did that, too.
They've got enough market clout now that people will
port Ruby/Python/Perl to a non-Unix macOS, just as
they port them to Microsoft Windows.
Ruby on Windows is a nightmare.
To be specific, Ruby itself (the core language and core libraries) are pretty good on Windows. Great choice for a scripting language, or whatever else you want to do.
But libraries like ActiveRecord, Rails and their myriad dependencies are very very hit or miss on Windows and there's not a lot of support when things go badly.
A lot of the issues are simple - like dead simple. Lot of gem authors don't bother to make things like file paths (forward slash vs. backslash) system agnostic. Or the gems depend on compiled binary stuff like Nokogiri or ImageMagick and those are always a bit of an adventure on Windows.
If MacOS drifts farther away from Unix they will cease to be the platform of choice for many developers currently using it today.
I was someone who installed the first beta of Windows that included this, just to try it out for Rails. It had LOTS of problems. I filed bugs. I kept trying over the next couple of versions, and finally gave up. I tried it again a few months ago, and, again, ran into a show-stopping problem of some sort, and gave up again. Are you saying that you use it "in anger" for serious development, and have no issues?
People complain about doing Rails on Windows, and, while there's definitely extra friction, and I hate Windows in general, I have really good luck with RubyInstaller. I used to have a hard time with ExecJS, but now I just install Node (on either Mac or Windows), and I'm usually off and running.
I use WSL (without anger) for serious development, for about two years now and have had almost no issues.
Running 'Pengwin' (Debian) Linux via WSL, RVM using Ruby 2.4.1 + Rails 5.1.7 and Ruby 2.6.2 + Rails 6.0.0.beta3
Today, everything works just as expected, right out of the box with no effort. This includes ActiveRecord (to SQLite, MariaDB, and PostgreSQL), including Node.js / Asset Pipeline, Prawn PDF and ImageMagick integrations, uploads to AWS, email integrations, capistrano-based deployments, Heroku Gem + integration, and so on.
It's gotten to the point where we spend more time helping OSX folks figure out occasional Homebrew weirdness, than we do helping Windows folks with WSL. Especially since WSL people can almost always just re-use any Ubuntu instructions verbatim.
except when you install a native module in WSL and then try to run it from CMD. WSL is no different than having a headless VM and comes with all of the problems of one
I've done most of my Linux development on WSL for the last year. It stuggles sometimes under certain types of heavy IO load, and there are ocsssional compatibility issues, but overall it's been impressively reliable and convenient.
I am using WSL more and more often nowadays and it's really good now, it works just like you'd expect Ubuntu (or other distro you choose) to work. The only thing I've had to do is turning off anti-virus real-time protection for linux subsystem.
The funny thing is I have been a rails dev for years and didn't even know it didn't work on windows because I have never tried and don't know any dev ever using windows.
That just proves you live in a bubble :) I never got into RoR because it sucked so much on windows and every single tutorial was OSX focused. I just sticked to alternatives that worked.
So which companies are actually doing RoR development on Windows? Do they also deploy to Windows Server (?) in production? I guess I live in multiple bubbles because I’ve worked for tech companies in several different major metros and I’ve never heard of this as a mainstream thing.
It is not like that. My point is that there's a barrier to entry to RoR that you should own a Mac. I gave up because my home setup is Windows based and I won't change it for the sake of a hyped framework or tool.
But none of this is surprising considering where RoR is coming from, I'm not sad or upset about it either :)
it seems like you’re blaming RoR for a problem that is actually due to windows being “different”. almost every OS besides windows is a nix or nix clone and POSIX compliant or certified. so who’s really the problem here?
In the early days of rails say 2006, it was definitely more common place... but I guess there were fewer of us back then ... I know as a maintainer of curb I have a few windows users
I started with a ruby/rails project in 2007 and after 3 days of fighting my work issued windows machine I just went out and bought a white macbook and things were up in running in an hour or two. I've never looked back.
> But libraries like ActiveRecord, Rails and their myriad dependencies are very very hit or miss on Windows and there's not a lot of support when things go badly.
I haven't done Rails for a while, but when I did Rails (including ActiveRecord and all its other components) Just Worked o bWibdows (lots of the peripheral ecosystem of Rails and Ruby more generally was a nightmare, but Rails itself was great), and overall the Ruby (outside of Rails) experience on Windows has gotten better with Ruby installer + DevKit, which hasn't closed all the gaps but does mean that even libraries with C extensions frequently just gem install and work on Windows; I'd be surprised if Rails itself had gotten worse in this area.
But macOS uses '/' as a directory separator already. They're not going to arbitrarily change trivia like that -- at least, not short of killing the concept of a filesystem altogether. (True, if anyone was going to do that, Apple would, but APFS is brand new. That's not going anywhere.)
Apple isn't changing things just for the sake of change. They're removing 1970's-isms where they hold back the platform. Languages like Ruby/Python/Perl also clean house, from time to time, to remove old cruft. I can't imagine any legacy feature of macOS that Apple would want to deprecate which would make it more difficult to maintain a good port of Ruby/Python/Perl. These are regular general-purpose programming languages now, not just Unix scripting languages.
Yes, Unix has been one of the developer systems of choice for the past couple decades, but it wasn't always so, and it hasn't been the only one. I hear more developers than ever using and enjoying other systems like Windows (Powershell) today. Even Linux today is pretty far from traditional Unix. I just don't see perfect Unix compatibility as a necessary component like it was in 2001.
Similar, HFS+ used to provide the option for case insensitivity. Both things were built in for legacy support reasons during the transition from OS 9 to X, as with Carbon.
Pretty sure HFS doesn't actually store any directory separator. A directory, after all, is just another file, each one containing its own children. Classic Mac OS used ":" when it needed to use something as a path separator.
You can use it, yep, but devtools aren't enough. You'll meet a lot of issues sooner or later. Windows is second-class citizen for Node, Linux or macOS are much better - just share my experience.
Being a second class citizens is very different from being a nightmare. I've been able to build some fairly complex apps (TypeScript, Next.js, Relay, SQLite, Express) without running into any issues at all, and if I do hit a roadblock I know I can bail out to WSL or a VM.
The experience isn't as nice as macOS, but it's not terrible by any stretch.
Personally I moved to Windows about 2 years ago, have been developing node all day during that time and deploying on Linux. It's been great since about node 8. What have your issues been?
Same. Wsl is great. Running ides in wsl even works great, but with vscode, I don’t even do that much anymore. It’s like being on Linux for dev, but having Windows for power management, high dpi settings, drivers, etc. It’s working great, hardware selection is nice, games work. I’m really digging it lately.
We're running some legacy rails 3.2 against oracle db on windows, and it works well enough. It sure is a lot more pleasant on linux, though.
Biggest challenge on windows is to get a c compiler working/get binary dependencies working. Other than that, you need a version manager (same for other platforms really, unless you're aiming to shoot yourself in the foot).
Ruby on windows is definitely not great, but "nightmare" is a bit much.
We probably agree on an objective level. I would agree with you that nearly all of it works nearly all of the time.
But that's my idea of a nightmare - when things are suboptimal and you're often scrambling for solutions on a second-class platform. When I say "often" I don't mean "every day", but in my experience it happened enough to make me swear off Rails on Windows forever.
Of course maybe 5.x is different. My experience was in the late 3.x and early 4.x days
The main issue here is that they don't want the hassle and responsibility of breaking everyone's software each time they release a new system-level python.
They have a problem deprecating python2.7 as it is, the smartest deprecation is not to release a python3+ version at all.
You see a similar issue with python on Debian. Python 2.7 is still the system python for all of the Debian tree, and it is very challenging to migrate to a new version because of the huge impact it has.
That's not to say MacOS won't be a place where python is happy to run - just that Apple don't want to dictate a specific version of it in their releases (i.e. developers/users/applications should install one.)
Would you say that RedHat doing almost the exact same thing[1] means they are moving away from being Unix-like as well? This is just an idea who's time has come.
You might be right about OSX and it's derivatives moving away from being so unix-like, but by itself this is just sensible housekeeping they would have to do at some point anyway. It's just not reasonable to expect them to include and maintain deprecated language runtimes indefinitely.
I'm sure that others here are well familiar with other officially certified UNIX operating systems[1], but given many widely used Unix-like systems not on the list, I don't think Apple gains anything from the certification. Moreover, it probably is deleterious, forcing them to adhere to system designs that made sense in the 70s and 80s.
I'd be surprised if Apple spends all that much money/effort on official Unix certification, precisely because I doubt Apple would bother. How many customers are choosing macOS over something else because of the Unix certification? In a world where Linux exists?
(This discussion, of course, has nothing to do with whether or not macOS adheres to Unix principles or compatibility.)
I disagree. MacOS is hugely popular in academia. A significant amount of researchers use MacBooks as it allows them to have the best of both worlds by having a machine that runs MS Office for preparing proposals and dealing with Admin as well as a UNIX system that lets them ssh into whatever workstation or cluster they’re running jobs on. Sure Windows is catching up in this regard but MacOS has had the advantage of being a much nicer experience.
Getting your products into Universities is a great way to maintain market share. This is true for software like Matlab and even for banks where most students will keep banking with the same bank for decades.
>> (As RMS wrote in 1983, "Unix is not my ideal system, but it is not too bad. The essential features of Unix seem to be good ones, and I think I can fill in what Unix lacks without spoiling them. And a system compatible with Unix would be convenient for many other people to adopt.")
I have a historical question and I wonder if anyone in this thread has the answer: why did RMS (and, presumably, by then his cycle) had to wait around for Linus Torwalds to write a kernel so they could have one for GNU? RMS in particular has a reputation as a legendary hacker. Was he not able to write his own kernel?
There is GNU/HURD that was supposed to be the kernel. However, its development hit roadblock when microkernel design ended up extremely difficult to debug. Sometimes you can't predict real complexity from the architectural drawing board and prevailing hype in academia, pointing to microkernels as the future at that time. Linus just wanted to implement his own, simple UNIX kernel, based off proven principles, without doing original kernel research.
One good thing about programming on Mac is the UNIX environment which basically works just like on Linux. Makes it great for finding questions/solutions that work (vs on Windows for example).
Do you see that changing as macOS gets away from UNIX? That would probably be a bad hit on apple if Linux becomes then the de facto programming OS when Apple drops UNIX
> if Linux becomes then the de facto programming OS
It is already. Deployed any production service on macOS, of late? Windows and MacOS both, are now forced to run Linux compatibility layers (Docker, WSL...); the Mac one just happens to be thinner because of the choices made at NeXT back in the day.
I don't see this anti-Unix stance at all in what Apple is doing here. The "P"-languages that shall not be named were never part of Unix/POSIX, and arguably violate Unix principles in that they want to establish a language-centric ecosystem when the Unix userland is about small, language-agnostic programs working together.
>and arguably violate Unix principles in that they want to establish a language-centric ecosystem when the Unix userland is about small, language-agnostic programs working together.
That was never a real consideration where distros/vendors are concerned (UNIX or Linux). Just a nice-to-have goal for the command line userland (and even that, more back in the day).
I would like to believe that the people who use those features would make the much simpler switch to Linux but with the new WSL and (ridiculous) terminal I know a lot of them will be persuaded to transition into the special hell that is Windows.
The jump from os 9 to OSX was about as significant as the jump from win9x to the NT based XP. Suddenly, multitasking stability without a huge dollop of luck was a reasonable expectation.
A different solution, and possibly better, would be to run Unix/Linux in a VM rather than worrying about it being native in the system.
If I'm not mistaken, current best practice is to somewhat isolate third-party developer software anyway, using homebrew, a VM or other solutions (not sure about Docker - don't use it).
I can see where it would be an issue with developing for MacOS or iOS, but third-party web development doesn't really need anything that is installed on the system, and in my experience, it's actually better not to base it on the MacOS default packages.
Homebrew installs its own binaries in a way that they won't interfere with the macOS-supplied versions. It doesn't use a container or anything like that. Certainly not a full-on VM.
Maybe I'm old-fashioned (feels weird to say that as a 25-year-old, but here we are), but I quite like not having everything be in a container all the time.
> Homebrew installs its own binaries in a way that they won't interfere with the macOS-supplied versions
Correction: Homebrew usually installs its binaries in a way that doesn't interfere with the ones provided with the system. It will occasionally override or shadow them and things will break.
That's extremely rare, these days. When a conflict is possible, they just drop the new version in the cellar and tell you what to do if you really want to risk shooting yourself in the foot.
With brew as the de-facto package manager for macOS this is a great move. Having Python and Ruby bundled with macOS is confusing when trying to install "regular" versions of the software through brew or other methods. Because the default installation can't updated without updating the OS, the system versions are not useful for most developers.
Besides your tone and language being unwelcome here... you're just factually wrong. Comparing in Google Trends, it's very clear brew is the "de facto" package manager, and has been for years:
"DarwinPorts" was originally released in 2002. You can see it trending and then the name change which occurred in 2006. It's been on a downward trend ever since.
Even thought Homebrew was released in 2009, it trends relatively constant for the entire dataset. In fact, from 2009 onward, you see a downward trend and then a slight upward trend. So, I'd say, Google is having trouble differentiating "Homebrew" as a drink and Homebrew the package manager.
Now, my personal opinion on the matter:
I used both Fink and MacPorts extensively since around ~2002. I eventually moved to MacPorts because it had better support for Latex at the time.
MacPorts is solid and follows UNIX philosophy in its design. I've been using it for almost 15 years and in that time I've had almost zero issues with either available packages or installation bugs. It's very reliable.
Extend the time window and it also shows that homebrew was more popular than macports in 2004. Despite being released in 2009. (The word "homebrew" refers to more than one thing. Like the thing that the mac package manager was named after.)
Homebrew is the de-facto package manager on macOS because it is so widely used. It might not be the one started by Apple engineers, but it is certainly the more popular of the two.
Those don't seem to be opposing things - you expect your package distribution tool to be effectively curl and tarballs, the other person expects more complex behavior options and dislikes the absence of them.
Of course you are technicly right. Homebrew is a train wreck and should not be used. But people are using Windows also, they don't use the proper tools, like ports. Unfortunately it is the defacto packager.
But still, people should not put out Homebrew installation recipes, and prefer macports instead. At least you can seperate the newbies from the experienced immidiately. If it's a Homebrew package only, avoid.
* installs into /usr/local/bin, which is now a protected path with SIP. Why do you think Apple itself protected themselves from Homebrew? So what do Homebrew users do now? Disable SIP. Sigh
* installs with users permissions, not a seperate user. /usr/local/bin is now open for every pwner. The very first path, not just ~/bin.
Never trust a newbie package manager which takes over your whole system and installs into the very first path. Even macports can override the pre-installed coreutils without messing with /usr/local/bin.
Besides the security nightmares:
* is a unicorn, esp. for darwin only. macports uses the de-facto standard ports framework instead, just with tcl, not the shell.
apt or rpm are also not the standard. ports was much earlier and is used on much more platforms than those unicorns. You won't get any brew recipes from other and better managed packages. Those with a bit more experience.
/usr/local/bin is not under SIP, /usr/local is. Homebrew now changes the permissions and ownership of the directories inside of this to get around this (which is functionally the same thing, but I figured that I'd point this out to you before someone else did since your points are otherwise valid).
It's called a personal computer for a reason. Laptop sharing is not a really a thing for professionals (or at least not that common). So, complete non issue for the vast majority of the target audience (i.e. developers and techies). Actually, not requiring root permissions is a feature and not a bug as it reduces the scope of what these tools can do at the OS level, which is a good thing for software you blindly install after downloading.
Not requiring root to install software to system directories is a security bug, not a feature. In a practical sense Homebrew elevates you to root and in the process messes up the permissions of a /usr/local, which, being on $PATH, opens users up to vulnerabilities.
Nonsense. You are using users in plural. Macs are not typically used as multi user machines. Certainly not by developers. And when they are, so what? Technically, the permissions are only changed for the user that installs homebrew, which requires root access to change the permission, and not for the other users. If that's a problem for you, configure it to install stuff elsewhere.
Also, /usr/local is completely empty on a fresh OSX installation and the whole point of homebrew is to have the stuff you install with it on the path. That's the whole point; you put stuff there that isn't part of the OS because you need it. There's nothing to mess up other than the stuff that you put there. If you don't want stuff there, don't put it there. The only vulnerability is the single user of the laptop being an idiot. At least they can be idiots without defaulting to root privileges, which probably is an improvement.
Because I am talking about people who use Macs in general?
> Macs are not typically used as multi user machines. Certainly not by developers.
There are developers who share Macs: not everyone can afford to have a computer to themself. But that's still beside the point: regardless of the number of humans using the computer, Macs still have multiple permission levels, and there is always a "root" with more permissions than you.
> configure it to install stuff elsewhere
Yeah, this tends to break if you actually try this. Homebrew explicitly tells you that this is not well supported.
> Also, /usr/local is completely empty on a fresh OSX installation and the whole point of homebrew is to have the stuff you install with it on the path.
Yes, but there are better, and more secure ways to do this. What you should be doing is require sudo to install to a directory that is global and automatically on $PATH, or install locally to ~/bin (for example) and then put that on your $PATH. The way Homebrew does it, where it changes the permissions of /usr/local's folders, is bad because it opens the door to attacks when system software running as root picks up binaries from $PATH (which you have now changed ownership and permissions of to be writable by your user) making any code execution bug instantly become a privilege escalation attack. This isn't the first time I've had this discussion, so I have more detailed explanation which links to an actual example of this being exploited in practice: https://saagarjha.com/blog/2019/04/26/thoughts-on-macos-pack...
> The only vulnerability is the single user of the laptop being an idiot.
Aside from the fact that the security hole exists regardless of me doing something stupid, I'd like my software to work as well as possible in the face of me being an idiot ;)
Basically it means if someone has user access on a Mac with Homebrew (with default settings), they also have root. So a remote hole in, say, Safari, means your entire system is compromised.
They don't quite have root per se, but they have a functional elevation of privileges if some some other software has a bug in it with regards to pulling binaries from $PATH, which is quite common.
This has been a topic brought up internally at Apple many times over the past decade. Glad to see it finally moving forward. Although I see the benefits to having a system-version of these packages.. if you're doing anything serious for production then the environment should be containerized.
Python and pip just being there is a huge advantage for newbies. I really think that part of programming is constantly ignored because all the decision-makers are not newbies.
It's honestly terrible for newbies. If they try to use it, there's no pip included. So then they easy_install all their libraries which installs things into different places than most python devs will be used to. Or they easy_install pip first. But even still, everything is installing to system paths, so when they try to install things it fails with permission errors. They find a stack overflow post that says just "sudo" everything and they go to town. And there's no way to reset anything when it gets borked either because it's the system install.
Compare that to "brew install python". Now you have the most up to date version, with the right permissions for your user, that you can always brew uninstall and reinstall later if you need a different version or a clean install.
So you're saying Apple should adopt brew as default package manager and install all system tools using brew? I could get behind that, but just dropping everything without replacement makes it harder for first-time programmers.
you can always brew uninstall and reinstall later if you need a different version
That is the wrong way to do it. Just install pyenv/pipenv to manage different Python versions. It's dead simple to maintain system Python, Python 2.7x, and Python3.7.3 that way.
Yes but I’ve never seen someone new to programming that bothered trying to figure out pyenv or similar. Even a lot of moderately experienced devs don’t bother with it. I guess it’s hard to realize the benefits of keeping environments organized until you’ve been burned by it.
Sure you can do that, but why would you want to install and re-install different versions of Python depending on what you needed at the moment? Pyenv manages all that nicely. You can have 2x and 3x side by side without having to reinstall and uninstall anything.
> You can have 2x and 3x side by side without having to reinstall and uninstall anything.
You can do that anyway, `python` is always Python 2 (except on Arch where `python` is Python 3 and the Python 2 executable is `python2`) and the Python 3 executable is called `python3`. `pyenv` is more for keeping multiple minor versions of the same major version (e.g. Python 3.6 and Python 3.7) around at the same time.
`pyenv` is more for keeping multiple minor versions of the same major version (e.g. Python 3.6 and Python 3.7) around at the same time
Actually, it doesn't have to be multiple minor versions, it can be any version–major or minor. It can even be Iron Python or Jython. Anyway, the point is that it's smart not to touch system Python on macOS. So when I run:
`$ pyenv versions`
My output is:
`system
`2.7.16
`* 3.7.3 (set by /Users/wyclif/.pyenv/version)
Dead simple and easy to use. Much better than overwriting and reinstalling when you need a different version for a specific project.
Homebrew is not perfect though - it doesn't handle multi-versions (e.g. 3.7 and 3.8 running in parallel), which were working fine with Apple's Framework mechanism. Pyenv is superior in that respect (although it's fundamentally a hack). But I agree that brew does a better job for newbies than Apple's system python.
Again the word "serious" is there telling me people are absolutely aloof to the kinds of new developers there are and what it's like to be a non programmer.
What newbie will start with Python 2.7 at this point in time? Most books and tutorials are updated for Python 3. The default Python 2.7 interpreter from macOS is useless for newbies, it does more harm than good by confusing them.
They sure could, but is it worthy to maintain an alternative package and deployment system for which you have no use yourself? Will employees be careful and committed to something useless for their jobs?
They previously deprecated Java runtime for similar reasons. And I can’t really blame them, roadmap is crystal clear now, they prefer to assign ressources to develop Swift/Swift UI and improve tooling for native code development.
I agree overall, but I do think it's a little sad that you can no longer open a Terminal and start writing Python. I think this legitimately matters in terms of increasing overall tech and programming literacy.
Mind, there's still a command line and shell built-in, which I consider far more important.
Its not like the rest of the terminal is friendly to newbies. An online ‘jsfiddle’ like environment suitable for newbies (with a bit of inline syntax hints without turning into a full IDE) would be more useful to get people to start playing with programming
Separately from including python, I've always thought it would be nice if TextEdit had some built-in syntax highlighting, that activated automatically for the right file extensions.
I'm generally against bloating simple apps, but you'd never see this unless you opened a .py file (or .sh, .rb, etc), and if you open a .py file, you probably want syntax highlighting.
Gee, thanks. My point was about discoverability and being able to Google for "read csv with Python", not whether experienced programmers can hack things together.
The young, bored but smart kid in an elementary or middle school tinkering with her computer and finding something to do. She doesn't need a book or a tutorial to tell her the "right" way. She experiments, only guided by her curiosity.
There still Swift Playground, Safari JS console, not to mention old fashioned zsh/bash/ksh to tinker with. The part where the removal of the default macOS Python/Ruby/perl (which don't even have autocompletion) kills her curiosity seems far fetched.
What command-line programming language interpreters are left when those are removed? You have the shell itself, but that’s hardly enough to write anything cool.
This feels the same as when Microsoft removed QBasic from Windows 98. So many kids at home missed opportunities to be exposed to programming from them on, until a certain Terminal application appeared in Mac OS X and began to pique young curiosity again (mine included).
> What command-line programming language interpreters are left when those are removed?
zsh/bash/ksh93, tcsh, awk, sqlite3, elisp (assuming emacs survives for now) and javascript console. I don't know why you'd want to limit things to pre-installed command line interpreters though.
> You have the shell itself, but that’s hardly enough to write anything cool.
What kind of cool things do you envision the curious beginner to write, using only the current preinstalled Python/Ruby/perl, that they can't do with the remaining interpreters that I mentioned?
> What kind of cool things do you envision the curious beginner to write, using only the current preinstalled Python/Ruby/perl, that they can't do with the remaining interpreters that I mentioned?
What about the iconic 4th grader "greetings and cool things" script? Here's something like what it looked like for me (on the IBM PC in my classroom):
5 CLS
7 RANDOMIZE TIMER
10 PRINT "Hello there. I'm a computer. What is your name?"
20 INPUT G$
30 PRINT "Hello "+G$+". You are welcome to computer land."
40 PRINT "What would you like to do today?"
50 PRINT "1) Make noises"
60 PRINT "2) Make a maze"
70 PRINT "3) Exit"
80 PRINT "Enter your selection:"
100 INPUT S$
110 IF S$="1" GOTO 200
120 IF S$="2" GOTO 300
130 IF S$="3" GOTO 400
140 PRINT "Try again."
150 GOTO 40
200 SOUND 20+(RND*20000), RND*3
210 GOTO 200
300 SCREEN 1
310 IF RND>.5 THEN PRINT "/"; ELSE PRINT "\";
320 GOTO 310
400 PRINT "Bye."
That kind of stuff is perfect for Ruby and Python. I don't envision kids getting that far with shell scripts, awk, sqlite3, or elisp. They might with HTML and JavaScript, but that requires learning HTML as well as JS and is sandboxed in the web browser; it's also not as "Cool! Look what I can make the computer do!" as messing around in the terminal. (Note, I’m glad BASIC isn't as available anymore -- we're not getting kids into certain bad programming habits early-on, like use of GOTO. But BASIC would still be more approachable than shell scripting, awk, etc.)
clear
echo "Hello there. I'm a computer. What's your name?"
read G
echo "Hello $G. You are welcome to computer land."
while true
do
echo ""
echo "What would you like to do today?"
echo "1) Say something random"
echo "2) Make a maze"
echo "3) Exit"
echo "Enter your selection"
read S
if [ "$S" = "1" ]; then
say $( head -n $((7*RANDOM)) /usr/share/dict/words | tail -n 1 )
elif [ "$S" = "2" ]; then
for i in {1..3000}; do
if (($RANDOM>16384)); then printf '/'; else printf '\'; fi
done
elif [ "$S" = "3" ]; then
echo "Bye."
exit
else
echo "Try again."
fi
done
This doesn't seem much different than the BASIC example to me. I think only the lack of GOTO in shell scripts makes this look slightly more complicated (requiring either putting all the statements in the if ... elif parts or defining functions).
I honestly don't see how a Python or Ruby version would be much better than a shell version for this. Perhaps you can show by example?
You do have a point - that's not too bad, but to my eyes it's still more arcane than Python and Ruby (spoken as someone who has written less than 30 shell scripts in my life).
I still contend that Ruby and Python are far more accessible than shell scripting, because they are very popular, especially Python, cross-platform, and less arcane.
For my own curiosity I did the simplest Python version I could think of to see how it would compare:
import os
import random
import sys
os.system("clear")
print "Hello there. I'm a computer. What's your name?"
G = raw_input()
print "Hello " + G + ". You are welcome to computer land."
while True:
print ""
print "What would you like to do today?"
print "1) Say something random"
print "2) Make a maze"
print "3) Exit"
print "Enter your selection"
S = raw_input()
if S == "1":
F = open("/usr/share/dict/words").readlines()
W = random.choice(F)
os.system("say {}".format(W))
elif S == "2":
for i in range(1, 3000):
if random.random()>0.5:
sys.stdout.write("/")
else:
sys.stdout.write("\\")
elif S == "3":
print "Bye."
exit()
else:
print "Try again."
It looks like a tossup to me, all 3 versions have their own share of magic that will confuse the beginner. I say this as someone who reads and writes a lot more python than bash daily.
Another of my favorites -- this was fun in middle school (years 6-8) when I had a spare minute or two to sit down at a random computer (maybe in a computer lab).
The effect is rather striking, like someone must have really messed up the computer.
My main gripe with Windows NT was that it would go back to the NT screen saver -- I couldn't get it to stay displaying my program, because there wasn't any true DOS mode.
per the link, macOS won't include any scripting languages by default in the future. So the bored user will be less likely to stumble upon an intresting programming language on their macs.
I don't know if that follows. I think it's likely that Apple will include a new installer upon setup that is essentially a one step 'click to install XCode Developer Tools and the following languages:' then has a list of options including Bash, Python, Ruby, Perl, &c. But all that is conjecture because we don't know what they're going to do yet.
You'd have to be very bored and unmotivated to not install a programming language if you had even the slightest motivation to program (IOW, not a normie consumer). I understand what you're saying, but I just don't see how this would be a huge barrier to entry.
Because they don't know it's a deprecated language.
In fact they probably don't even know what "deprecated" means.
It wasn't that long ago that Python 2.7 was the default on the Raspberry Pi. (That may still be true - I haven't checked recently.)
There's a huge ecosystem of Python 2.7 tutorials, introductions, and sample code out there. Very little of it is prefaced with "Of course you should use Python 3 now."
I bet they know how versions work though, and that 3.7 is higher than 2.7. I just googled ‘Python tutorial’ and only one of the results on the first page was for python 2. The first result was ‘The Python Tutorial — Python 3.7.3 documentation’. If some non-programmer was going to start learning python, they’re most likely going to start with google. I can’t see them digging deeper into the results because they want to learn an older version of the language.
I'm gonna disagree on this one. When you're just starting, the installation process can be nontrivial and the terminal window is scary. Having less friction there makes it easier to start and build some confidence. Once you have some idea of what you're doing, you can realize that you want different versions of the language.
I think this is a better argument for Apple providing a package manager with the operating system so that installing python is as easy as typing "brew install python3". Then it'll be just as easy for newbies to learn less standard languages.
If you have a tough time installing software that has maybe a dozen words or so of instructions in a clear easy-to-read format... you really have no business learning to code until you learn how to use your computer first.
Always ask for python2 or python3. "#!/usr/bin/env python" probably won't ever be able to detect and run both, so no matter what you wanted there will always be systems on which you won't get it.
If you follow a python 3 tutorial when your computer has python 2 installed on it, that's a terribly annoying way of fighting with your tools. I've seen it happen. I'd rather they don't risk it and just start fresh.
Not only pip is not provided, but virtualenv neither.
The alternatuve to the current decision is for apple to assign people to keep updating python and provide previous versions as packages like linux distrib does. But it has never been the way they do business.
Learning how to install and configure development environments is an important skill in general, but I'm not convinced having those skills as a prerequisite for exploring programming as a newbie is at all valuable.
On macOS the best config-free entry to programming is Swift and Swift Playgrounds. Everything else can have config and shell hell for further more advanced learning purposes.
I'm sure that my kids will certainly love to hear that they have to learn Unix in order to learn a build system in order to try out Python. It's all part of the "learning process for newbies."
> learn Unix in order to learn a build system in order to try out Python
I definitely understand that the installation process for things like python can be confusing to non-programmers, but I think this is a bit disingenuous. You don't have to learn a build system to install it; python was the first programming language I ever learned, and I used it years before I ever even had any idea what a build system is.
Good grief. What's wrong with going to www.python.org/downloads/ and clicking the big button at the top that says "Download the latest version for Mac OS X"?
If you can't even download an installer and run it, then yeah, maybe not quite ready for programming either.
Please forgive my snark, but this would be exactly my thought process as a reasonably competent computer user who wanted to learn Python.
Even on Windows you can open the browser console and do
> console.log("hello")
Just for teaching basic prints, variables, loops and functions, terminal bash on macOS/Linux or Javascript console work just as well as Commodore 64 BASIC.
The problem is not that the environment is not available or setup is too difficult. The problem is that there's now way more competition from other shinies readily available (web, apps, games, videos). Even if you boot your home PC straight into a terminal, as soon as the kids find the way to a web browser it's game over. Even on 1980s home micros, if the kids got access to (pirated) games, practically none would volunterily keep on programming BASIC.
When you were 6 years old is a different time from now. You probably did not have an always-on connection. There was probably no such thing as Web 2.0. Computers were more difficult to use. Google did not exist. The Internet was perhaps still taking off...
Installing the version you need when you want to run a script is arguably easier for newbies than all the error messages arising from an out of date implementation originally included with an OS.
it's not like installing python is any more complicated than any other piece of software that needs to be installed. Windows users have had no choice but to do that for decades.
It's not a good thing or a bad thing. I'm saying it's not a thing at all.
If someone decides they want to run a custom ruby or python script the least difficult aspect of that decision is installing the interpreter. For example, I was dealing with someone yesterday who decided they wanted to learn how to write apps for Android. Without even seeing a single line of code (or even knowing which language they would have to learn!!) they had already successfully installed Android Studio and Jetbrains IDEA.
Without coming across as some gatekeeping greybeard, I think anyone who has even a glancing interest in programming would agree if you can't follow a one-line/click installation instruction you may want to find a simpler tool for the task than writing your own code from scratch.
Lots of people on just this thread, who have far more than a glancing interest, have expressed their disagreement with this exact idea.
The hardest part for lots of people in learning to program is getting over the idea that programming is for Special People, or possibly Wizards, who know lots of incantations which are beyond mere mortals. Please stop trying to convince them they're right.
Source: I've taught lots of marketing people, admins, call center techs, etc to program in PowerShell or system Python.
On the contrary, not teaching people how to install the interpreter just perpetuates the idea that it is beyond the ken of mere mortals. And that only "Wizards" should do it.
Installing the interpreter is nothing special. It should be taught as such.
The problem is not doing anything serious. Of course this would need an updated language runtime.
The problem is doing something simple, like an installer. bash => zsh: fine. You can still install with the old /bin/bash. but for many cases a shell is not enough, and then you have to compile something statically for a trivial dynamic task. Which makes the download 10x larger. Not cool.
The standard toolkit for this is perl. It's used in automake, most gnu utils and git. python and ruby bring nothing new to the table, besides being newbie friendlier.
When you build and package things for production you should create an environment. This ensures the packaging the right versioning of requirements for build.
Say you build using the system version but use packages based on another version. It may work for you but probably won’t work elsewhere.
But you wouldn’t want to develop in that environment,
right? You do integration testing in it, but development should largely happen in small modules, with unit tests and test data, no?
Right, that’s why you do integration testing (manual and automated) but are you saying therefore you should do all development inside a production environment?
That’s what doesn’t pass muster to me. Why should I work on my CSS styles in an environment with the production database? It will be much slower than just working on that package in my desktop environment with just enough scaffolding the code runs.
Not much slower than, say, Hyper-V or Virtualbox or other hypervisors that live alongside a general purpose desktop OS. Remember, they're using the same Intel chips and VT-d and such as anything else; as long as you have enough CPU power it's going to run fine.
IIRC the Docker implementation for OS X runs a tiny, carefully-configured Linux VM transparently in the background. This isn't that dissimilar from the Windows Subsystem for Linux from a user standpoint.
I've done plenty of Docker work on OS X; the only real weirdness is that you're running Linux in the containers and OS X outside. Eventually, though, before switching completely to a native Linux desktop, I moved deeper into the containers and would barely ever see the OS X command prompt any more.
Our build time on Linux container is 8 minutes, but it's a few hours on macOS using docker containers. I haven't dug into it but the hypervisor seems to be single threading the normally multicore compile.
Primarily disk access is a lot slower, even with Hyper-V. Eg. Compilation suffers from this. But tasks that don't use the disk too much shouldn't be that bad.
What? We use it at work every day for local development, and my previous employer did as well. It has issues, definitely, but they have more to do with Docker than with xhyve.
I think apple fundamentally does not understand containers.
All the interesting container stuff is on other platforms.
It might be out of fear, maybe because apple doesn't want macos to be virtualized.
It would be really nice to have say the current xcode in one container and a dev xcode in another. It would be nice to farm work out to a lot of machines.
> I think apple fundamentally does not understand containers.
Given that Apple is (or at least was) one of the biggest users of Mesos in the world and have invited me to interview specifically on the back of the operationalization of containers, I'm guessing that the staggeringly bright programmers they've got probably understand containers.
Yes, but there are some issues. For pure macOS development it's usually fine, but anything touching the simulator breaks if multiple versions of Xcode try to use it at the same time. I quickly got in the habit of always exiting Xcode before starting a different version.
It changes a symlink at /var/db/xcode_select_link, and all of the development tool stubs that Apple has placed consult this to see which binary to run. This is pretty much the officially supported way to switch between multiple copies of Xcode.
I imagine you could get pretty far with sandboxing+chroot, but it wouldn’t be docker. You’d definitely be able to prevent stuff in the container from getting out, but I’m not so sure you could reproduce docker’s “VM-like” (I.e. the inside of the container is ~identical to a normal Linux machine, with no need to make stuff compatible) quality.
I think this is great, but at the same time, auto-installing homebrew ought to be an option (perhaps enabled by default) when installing the “XCode command line tools”.
Better yet, offer a “developer setup” app that sets up the command line tools, homebrew, iTerm2, updated bash/zsh, and more.
Apple would do best to pave the cow paths developers have already worn into macOS, especially when it comes to command line utilities. A dev setup app would just make it quicker/simpler and pave the way for newbies to get into development.
I think the second you start auto-favouring one particular tool you're in trouble. Why iTerm2? Why not Alacritty? iTerm2 is more popular now, but 5 years down the line when someone else has come up with a iTerm2 replacement how is Apple meant to decide to switch? Where does Apple draw the line on which tools to add and which to leave out?
It sounds like what you're really asking for is something like Ninite for mac, which I think frankly is safer to stay as a 3rd party thing, rather than Apple getting super-involved in choices that are going to be very user taste specific.
Yeah I don't see the need for any of this to be provided by Apple. I want the platform I'm working on to be minimal and agnostic, and let me worry about what tools I'm using and how.
If there's really demand for some kind of base developer toolkit, why not leave it up for a 3rd party to put together some kind of installer to set it all up for you?
> why not leave it up for a 3rd party to put together some kind of installer to set it all up for you?
Because a potentially interested 4th grader likely won't ever know such a thing exists.
And even if she did, the teacher likely won't let her download and install it from the internet. But if she asks for permission to run a "Install Command Line Tools" app in /Applications/Utilities/ and check the "Install homebrew" option (or "Install MacPorts" - I really don't care either way... perhaps provide options for both), that's far more likely to get a "yes".
In my experience kids are very tech-savy. I don't think the 4th grader who can't discover homebrew without a system setting for it is going to be able to do much with it once they've got the terminal open.
Kids can only get savvy with exposure. Those lacking certain privileges (like having a computer at home) likely haven’t had any of that exposure.
I was only able to learn BASIC and the DOS command prompt because I was in a multi grade classroom, and an older boy (5th grader) whose mother paid for him to have programming lessons taught me on the classroom computer.
The teacher had no clue about any of that... she only knew I started spending “too much time” on the computer.
My point wasn't so much a plug for iTerm2 or anything else in particular. The purpose of a dev setup app would be to (a - primarily) provide a great default dev environment for curious kids, and (b) pave the way for some of the most popular dev configurations.
I know homebrew and iTerm are pretty popular, and that there are other popular options as well. Why not list the top n in each category, in randomized order, with short descriptions and "learn more" links?
Every time I start work on a different Mac, it usually takes me at least 30 minutes to set it up. It would be nice to have a quick button to set up command line tools, iTerm2, homebrew, zsh, and git. Making such setup available from an app would not only speed up the process, it would also gives the dev environment visibility to newcomers and "first class" status from an IT perspective.
> I think the second you start auto-favouring one particular tool you're in trouble. Why iTerm2? Why not Alacritty?
Because iTerm2 is an excellent Mac app? I don't understand your aversion to favoring one tool over another: macOS itself is a tool that I prefer to use over Linux because it's nicer, just as iTerm2 is nicer than Alacritty.
Just that the prompt automatically goes on a new line makes iTerm2 so nice though. As well as the built in timing of commands, jump to previous prompt, double click selects matching parentheses, etc. it's those little details.
If you have a command that doesn't print a new line, the prompt normally ends up on the same line as the output of the last command. iTerm can "fix" this.
See this is where I would rather have my terminal obey the program rather than imposing its own behavior. IMO a good terminal should be extremely minimal, and anything extra should be opt-in.
iTerm is amazing when using many spaces because of the hotkey overlay.
Projects and project parts are separated via spaces but I never want to have to find the right terminal for a process, instead I use a single window with animations disabled (to show immediately) and excluded from app switcher via settings so that it will only ever show up when i press alt-space no matter which space I'm on.
Together with tabs and native panes it works just great and requires very little setup
It's a script that installs all kinds of useful stuff and sets some - in my opinion - nice options. I just recently started a new job and I had a brand new Macbook Pro up and running (as in: ready to start working) in less than 30 minutes.
A good tip is to fork it and modify it to your liking. At a new computer you can then just pull down your version and install away.
So the ironic part is this script would no longer work after these deprecations because installing Homebrew requires a Ruby interpreter[0].
Obviously these things are fixable but a whole lot of people are going to have to do a lot of work to workaround having _no_ scripting languages installed by default on a fresh Mac.
> Once Homebrew no longer has to support a macOS with a system ruby, we can even run with a considerably more up-to-date version, modulo concerns for supporting older linux(brew) OSes. We have a portable ruby that we can use to bootstrap things.
MacPorts was originally started as DarwinPorts as part of the OpenDarwin initiative at Apple [1]. Apple continued to sponsor MacPorts by providing hosting of website, repository, and build servers at Mac OS forge [2] until it closed back in 2016. The project then moved to GitHub and their own servers.
I'm trying to understand how these two points reconcile. "Future versions of macOS won’t include scripting language runtimes by default" and "Use of Python 2.7 isn’t recommended as this version is included in macOS for compatibility with legacy software. Future versions of macOS won’t include Python 2.7. Instead, it’s recommended that you run python3 from within Terminal." If Catalina is the last version with any scripting languages at all, why bother with the second point? Or will python3 still be available in the future despite point 1?
As I understood it, scripting languages will still be available to the user, they just won’t have ancient versions preinstalled. Of course that also means you can’t rely on them being installed at all as a developer.
Which means you should start bundling the stuff you need to run your app, and, they’d like you not to use the same ancient batteries as they have previously made available, because, well they are ancient.
Ok, I guess it's worded vaguely enough to allow for the possibility of optional installation ("by default"), even though they don't outright promise that they'll offer a way to install it. (I interpreted it in the same way as "macOS doesn't include Photoshop by default".) Having it come from the app store doesn't seem totally appropriate since it would need to do more than dump a bundle into /Applications, like making some /usr/local/bin symlinks. Maybe they'll allow themselves that exception.
"they’d like you not to use the same ancient batteries as they have previously made available, because, well they are ancient" --> Right, I couldn't figure out if that's all they meant. Valid point or not, it doesn't seem appropriate to make it in the context of those notes. If you're going to make me bundle the language anyway, don't also give me a lecture about which version to use. :)
I suspect they plan to distribute the scripting languages the same way they currently handle the command line developer tools package, where the OS offers to download and install the package the first time you try to run one of those tools.
I just don't see the win of that over supplying the thing with the OS in the first place, unless the commands to do it are a nascent versioned ecosystem along the lines of brew, apt, etc.. It seems like the whole point of not supplying them with the OS is to make the versions less tied down. If there's some opaque command to get an arbitrary version, that's not going to help anyone.
Probably the right call - many of them don’t have abi or api stability guarantees, or in the case of python needlessly broke backwards compatibility that is still causing pain today.
Apple used to ship an incredibly old version of OpenSSL because people used its API which was not ABI stable. Even getting rid of it was a nontrivial amount of work.
The lack of care about API&ABI stability in developer facing open source projects (interpreters, libraries, frameworks, commandline arguments) is still bizarre to me: why make your work hard to use/update? People ship out of date libraries because updating requires changes beyond just pulling a new binary requires more work than the gain will give them.
It’s part of why companies like Apple and Microsoft care so much about backwards compat: they want people running the most recent OS possible, and they don’t want people to avoid updates. Every time an update breaks something for anyone, they hold off updating in future.
On the other side, developers don’t want to invest time and money into a feature that they don’t think will work/cause their app to crash in future.
It’s part of why companies like Apple and Microsoft care so much about backwards compat
Compared to (former) Microsoft, I don't think Apple spends anywhere near the amount of effort MS does on backwards compatibility.
You can create a single .exe that will work on any Windows starting from Windows 95 - nearly 25 years. In that timespan, Apple changed CPU architectures twice, and their OS architecture once. If you're willing to restrict yourself to 32-bit Windows, which can run Win16 and DOS apps too, then it goes back to the early 80s.
Not true. Apple spends an enormous amount of effort on backwards compatibility. For example, they wrote a JIT compiler to be able to run 68k code on PPC. They did the same for the PPC to Intel transition. They maintained the "Classic" ABI and binary formats for years after the move to Mac OS X.
It is true that Apple doesn't maintain backward compatibility for a long as Microsoft does, but that's not the same thing as not caring. They put the effort into making transitions as smooth as possible for users and developers and getting through them quickly.
Apple maintained 68k compatibility for years after it migrated to ppc. That's a completely different hardware architecture
It maintained classic compatibility for years after it moved to osx. That's a completely different kernel and basic system architecture.
It maintained PPC compatibility for a few years after transitioning to intel.
It supported 32 bit x86 for a number of years after the entire line was 64 bit capable.
Apple does care about compatibility, it just isn't as beholden to the past: it's much more willing to say "this is bad, so we're deprecating it, eventually it won't exist/work".
But they work to not break any software until the feature being used is actually removed.
It is considered a high priority bug if someone changes behaviour of a function or object in a way that isn't backwards compatible. All APIs are essentially statically vetted to ensure they don't change, including things like struct layouts and sizes.
That said, it kind of misses the point to respond to "Apple and MS care about backwards compatibility" in this context to say " I don't think Apple spends anywhere near the amount of effort MS does on backwards compatibility". The point is that if you care at all then libraries and services that are unwilling (or even hostile to) abi stability cannot viably be shipped in any publicly facing way as part of your platform.
Yup but OSX has a tonne of C (and unfortunately C++) APIs.
But yeah having most of the system apis being in a language that has built in dynamic resolution makes a world of difference in the difficulty of maintaining abi compat
Publicly exposed? Most of CoreFoundation and the other C APIs vend objects that are entirely opaque, and there are very few actual C++ APIs that I'm aware of–though many are written in (Objective-)C++ internally.
There are plenty of APIs that have structs in their interface, although they are always passed by reference so that the structs can increase in size, while still retaining compatibility with old software, e.g.
struct APIFoo {
int a_field;
}
void do_something(struct APIFoo* argument);
later on we add a new field, and that becomes:
struct APIFoo {
int a_field;
int new_field;
}
For API compatibility you just need the source level field names to remain, and to remain the same type. But for ABI compatibility - e.g a existing compiled program - the fields must remain in the same location, so you can only add members to the end, and you can't change the alignment or padding rules.
What remains is how the API implementation knows if the argument is the size of the old api, or the new one.
The Microsoft API idiom is to have a size field that you initialize to sizeof(APIFoo). This means when you recompile you code against a more recent version of the API you'll get a modern sized struct. My feeling has always been that this approach is more fragile, as you can unintentionally increase the struct without initializing the new members. Apple APIs that need it tend to use an explicit version number, so you have to explicitly say that you know which fields you want to update - as an example you can look up JSClassDefinition (IIRC) in JavaScriptCore.
The other thing that Apple APIs will do is use a linked-on-or-after check: basically the macOS and iOS include metadata about the system version that a library or application was compiled to target. This is generally used to control legacy behaviour to handle cases where some internal logic leaked across an encapsulation boundary but the behaviour that was leaked is simply too awful to retain in general, and in the worst of worst cases code may include explicit tests for what the current application is (you can see a bunch of these in the WebKit codebase). Microsoft accomplishes similar tasks using (I think they're called) compatibility shims.
You are right however that the actual objects you get returned in macOS and iOS APIs are basically all opaque objects - looking at the JSC example, the actual API objects are opaque: so JSClassMake() takes a pointer to a JSClassDefinition, and returns an opaque JSClassRef that provides the actual API object you use to create objects.
As for C++: I would suggest you look at the nightmare that is IOKit. That's right, the kernel driver APIs are in C++. Because NEXT wrote that code in the 90s, when C++ was considered the perfect solution to all problems (e.g. before people really understood how hard C++ makes ABI compatibility)
Well aware of how C++ structures have issues with ABI compatibility, as well as the various linked-on-or-after checks ;) Note that DriverKit on NeXTSTEP, on which IOKit is based, was written in Objective-C. The switch to embedded C++ for Mac OS X was done to attract developers comfortable in the language, AFAIK.
Completely true. Apple only cares about back-compact down to a few older major versions. So often the big projects (like modern apps, Windows 10 S, etc) Microsoft does fail or struggle to gain traction IMO because of the blessing and curse of their back-compat requirements.
I think Apple has the right formula. The do put the effort in to maintain back compat to a certain point, but they also aggressively deprecate and remove within a few years of the arrival of a replacement technology. So you get the benefit of things not suddenly breaking, with the benefit of the whole ecoystem moving forwards. If that means old unmaintained software is left behind, then so be it. The right balance I think.
Those big-projects you mentioned failed to gain traction in the first place - with a tiny use-count for (e.g.) UWP vs Win32 it’s easy for MS to not take back-compat as seriously.
32bit PPC ran on intel macOS, which is probably harder (it's basically a problem of how you map 32 registers onto 8).
The difference is that after a while Apple is willing to deprecate things. Versus a lot of open source projects that don't guarantee any stability at all, even across minor version increments. That's the problem that makes them dangerous for platforms like macOS and iOS to expose them as public API (intentionally or unintentionally - my understanding is for instance that the system openSSL was accidentally exposed publicly - and that took most of a decade to remove from the OS, e.g. most of a decade of shipping an increasingly old Frankenstein branch of openSSL)
If you're referring to the python2->python3 change, this was a pretty important one. Having a string type that isn't required to have valid encoding is an awful idea.
And rather than just accepting that was what you had and accepting that you occasionally had to deal with that (as JavaScript did), they decided to cause a decade of problems that aren’t going to go away just because they’ve now declared python 2.7 dead.
Because of that, Javascript is now a pile of accumulated technical debt and it one of the worst language you can dev in. Hell, it has no type and still 4 ways to declare a variable.
In fact it's so terrible the most popular JS projects are actually project to avoid writing JS or emulate features that don't exist in one JS implementation or another (typescript, babel, JSX, webpack, polyfills, etc)
A lot of those frameworks exist to bring modern features of JS back to older implementations, and others exist to functionally bolt on a distinct type system because many people like static typing.
And yeah, JS has some old crufty things, but it also has the ability to do things nicely now. No one is forced to use old syntax, and most new code does not, but because those features have not been unilaterally removed there has not been anything like the problems python3 has produced.
Seriously: what new syntax in python three necessitated breaking python2 compatibility? Even your string example is weird because JS allows arbitrary invalid ucs2/utf16 strings despite adding actual unicode compatible APIs.
> The lack of care about API&ABI stability in developer facing open source projects (interpreters, libraries, frameworks, commandline arguments) is still bizarre to me: why make your work hard to use/update?
If you're a FOSS developer with limited time and man power (and if you're lucky, limited budget) maintaining backwards compatibility is hard. So hard, that new features and bug fixes might have to take a back seat to it. Also, I'm almost certain that developers would rather be implementing new features, and fixing bugs, ahead of maintaining backward compatibility. It's much easier to show a new feature or a bug fix, than it is to show how backward compatibility was maintained.
Also, the big users of FOSS, projects like Debian (and Ubuntu) and Fedora, will rebuild their entire systems when new versions of software are released/integrated. This reduces the maintainer's requirements to keep ABI compatible.
> rebuild their entire systems when new versions of software are released/integrated
Yeah, the ability to rebuild the entire system from source whenever you need it has resulted in those communities just not caring about a number of things that really do matter on proprietary systems; it's also part of why Linux doesn't have fat binaries (why bundle multiple architectures together when everybody can just grab or build each one themselves?).
Thats the reason installing proprietary software on linux used to be a massive pain. The expectation is the distro maintainer packages everything for you but they only do that for things that are open source. This has changed since flatpack was created.
I don't know if I completely buy into that argument. API's on the bleeding edge are often prone to breakage because the development frontier is in constant flux.
However, software that neglects to update also tends to breakdown as libraries change to reflect new knowledge.
If you're developing software based on someone else's library you are implicitly accepting the demand to modify your software to maintain currency with those underlying requirements. It seems a bit far-fetched to expect that you only have to write the software once without having to maintain it.
What I'm saying is that that is a choice on the part of the library developer.
You can make APIs that are ABI stable (literally that's the entirety of the Microsoft and Apple platform APIs, and plenty of open source libraries as well - Qt and GTK for instance). You can also explicitly choose not to (which I believe includes OpenSSL).
Basically if a library or application is not or cannot provide a stable ABI, it cannot be used be a platform where the default update model does not include the possibility of recompiling all software. Essentially such a model would require Apple and Microsoft to have the source for all apps, and be the primary/only distribution point for all of them as well - note that this is host most linux distributions operate: any given update can result in an arbitrarily large portion of all software for the system being recompiled.
Fucking finally! Between this and deprecating Bash [1], I'm glad macOS is dropping all these obsolete packages it's been including (Emacs soon?). Their antiquity mean they're more of a hindrance to proper development than help.
Now, if they'd officially endorse one open-source packaging solution as an alternative, I'd be fully satisfied.
MacPorts has or had semi-official status. It was hosted by macOS Forge, which was an official Apple site that included other projects such as XQuartz. I'm unclear on the current status.
MacOS Forge has been deprecated for years (2016?), all its hosted projects have moved off. I don't think Apple has done anything for MacPorts since then, so I wouldn't consider it a current endorsement.
MacPorts was started by Apple engineers as part of OpenDarwin and then spun off into a community project like the rest of the projects on macOS Forge, and just like the other projects it is still worked on in part by Apple engineers.
It's not dead! [1] I use it daily, and it's working just fine. For example, check out the (centralized) list [2] of Ports files that define the packages. You can see it's pretty lively
But your perception that it's dead is certainly symptomatic of an issue for the project.
_Ruby_ devs are going to be attracted to Homebrew because it (and the "recipe" for building every Homebrew package) is written in Ruby. The test of MacPorts is how many non-Ruby devs use it.
Whether or not anyone uses it, it is still linked from https://developer.apple.com/opensource/ and was part of Apple's open source strategy several years ago. Regarding Ruby, Apple backed the MacRuby implementation for a while but that also petered out.
I don't understand why everyone is so excited about this. I don't like using brew. I use a Mac because things just work. It was annoying that the system versions were old, but most of the time they were still workable. To me, this is another (admittedly small) thing I liked about the Mac that's going away.
The problem is accruing security flaws (increasingly difficulty to back port fixes), and also the problems that come up when you install a different version (lots of Software just assumes it can use the same system python, which causes issues when it isn’t the archaic version).
I'd prefer if Apple took care of security fixes instead of some third party. And they could ship newer versions if keeping the old ones secure is harder.
The problem is that updating to a new version isn’t possible if it breaks existing software - what happens is that the end user experience is “I installed these updates and Apple broke my program” so don't update in future, and tell others not to as well.
The only way to stop the OS from including out of date software and libraries is to not ship them if they don’t have stable abi.
That’s what Apple is doing: it can’t reasonably ship them and keep them up to date, so it is going to stop.
Yes, the difference is that now Apple is shipping a new version that will have the same problem in a years time, so instead of one compatibility event there’s a new one.
The app developer also now has a problem - their binary only works on one OS revision so they have to start shipping the same code, just compiled separately. The only safe solution is to ship with their own embedded version. Which is also the correct solution to the interpreters not being part of the platform.
You don't have to use brew. And if you aren’t a developer making software, you don’t need to do anything.
If you are a developer, there are many ways to get the software you need for development. Apple is saying they’re just not going to provide it on client machines by default — which is probably fine because honestly, more often what happens is the version Apple has on the machine is old or missing newer parts anyway.
I guess you could argue Apple should make their own package manager, but they just don’t want to spend the time and energy on that when they want to focus on Mac and iOS software rather than UNIX software.
Does this include AppleScript and the Javascript runtime for AppleScripts? They reference Script Editor in the section above, so I'm assuming they're safe.
Also, what's the best way to install homebrew if you don't have a system-level ruby? The current installer is a ruby script. Is it possible to get some sort of ruby-bootstrap that can install homebrew and a homebrewed ruby?
No - the problem with the misc other interpreters is that they don’t provide sufficient binary stability for Apple to simply include the newest one in every update (which I suspect they would happily do).
They’re not removing the commandline (although moving to zsh? :-/), or banning interpreters.
They’re just not including them built into the os anymore.
As for the AppleScript and JavaScript questions:
Apple makes the runtimes for those, and makes sure they remaining binary compatible. Take a program that linked to (and used) the javascriptcore api to add js support. Something compiled 10 years ago will run without recompilation. Thats the bar for stability.
I think you read more into my question than what I meant. I was asking literally about the best way to install it was without a system level ruby. Once you have homebrew, you can install ruby; but what about before that? Download and install ruby from ruby-lang.org, install homebrew and a brewed ruby, then uninstall the one from ruby-lang.org?
At least for Python the standard .pkg's available from python.org have always been very useful for me. Especially since you can install as many versions as you want simultaneously since they install in separate folders. As a tester who used to have to keep installs of lots of versions this was very helpful.
I should know the situation for Ruby as well... but don't remember anymore.
Sure but it's very rare to update python on the desktop (not on the server). Installing a new version in parallel is common, but once you get a 3.x rolling, you seldom have the need for a 3.x.y unless you encounter a bug or are very security conscious.
On the other hand, installing xcode is really a pain.
Over time I’ve just migrated to using brew for everything. I’m not sure how it differs to macports, etc it’s just the one I always ended up using and it’s now just muscle memory :)
The system Ruby is being deprecated, but not removed in this release. By the time it’s removed, Homebrew will likely have a replacement installation process in place.
On Linux, the Homebrew installer is a shell script that invokes curl https://docs.brew.sh/Homebrew-on-Linux. I guess, they can rewrite the current installer that uses Ruby with a shell version for macOS too.
Good thing, python2.7 is deprecated and no longer receives security updates, and a lot of Linux distributions (Arch and Fedora for example) plans to remove it from the main repositories at the end of this year, so having it installed doesn't make sense.
Even the perl and ruby version installed is old, and nearly nobody uses perl or ruby at this day. Maybe perl is still used by some programs and scripts, for example TexLive relies on perl, or ruby is used for brew. But you better installing more updated version yourself so removing it is not a big deal.
There is no meaning to keep old script interpreters installed, if you want to use them you probably want to install a more modern version, if you don't need them it's better to not have them.
Homebrew (after installation) uses its own, bundled ruby runtime and will finish removing any dependency on system ruby long before Catalina is publicly available.
I know, but this wasn't the case when it started. Besides, I believe the parent's point was that nobody uses ruby or perl for anything anymore, regardless of whether it's preinstalled or not. Which is obviously silly when looking at homebrew's internals.
It's interesting to me that this is happening in the same month that Microsoft made installing modern Python as easy as typing Python and then clicking "install". One more piece of evidence that Microsoft cares about developers more than Apple does.
> It's interesting to me that this is happening in the same month that Microsoft made installing modern Python as easy as typing Python and then clicking "install".
You still need admin rights and an internet setup.
Linux is still king.
Most of my Python/Ruby stuff requires additional packages to be installed and so would need to be bundled anyway if I wanted it to be easily transferred to a vanilla machine so I don’t see what the big deal is. I got into programming through wanting to automate something really boring with AppleScript and I got into Ruby (wow that was amazing compared to AppleScript) through wanting to program sketch-up which has a bundled interpreter. When I wanted to use Ruby for other cool stuff, the Ruby website recommended I installed my own so it didn’t mess with the system install. I doubt there are very many people who get into programming by accidentally typing Ruby at the command prompt. Most will come to it via a the getting started page for the language they are interested in or because it’s bundled with the software they use for their job.
Not a big deal. Anyone doing serious development at scale would mirror production anyways (12factors principle). Plus, who uses Apple's obsolete junk anyhow? For a very long time, homebrew and macports has solved Apple macOS not rolling releasing terminal-based packages. Teapot tempest.
Of course; why would they want to maintain this crud and its dependency hell. If the slightest thing is wrong, this or that application breaks. An application should include the correct version of everything it needs to do its job, period.
Only problem is security: with multiple applications including their own dependencies, some of those dependencies will lag behind in their security updates. You can't just get a single fix for your Python run-time and fix it in all applications at once.
I did like being able to distribute an entire app with a download of just a few megabytes, relying on a highly stable system Python (literally worked for 10 years).
And these days with smallish SSDs, I find myself desperately freeing up disk space surprisingly often. I’d rather not have every single app be 100+ MB when I know deep down that the things should be tiny.
I think people are reading more into this than is there. They're just not going to ship their own (outdated) versions of these anymore because they're not needed in the core OS. You can just "brew install" them, which most people who actually use them do anyway because the stock versions are too old.
I guess it is the macOS way for every app to be self-contained and include all of its own libraries.
But I miss the idea of shared libraries; not only can they potentially save memory and disk space, but it makes bug fixes easier because you can fix the shared library without having to update every app separately.
Sounds like these runtimes will still be available via a separate download, similar to how Git and other CLI tools download when you first try to use them. Not a big deal. Makes it easier for folks who want newer versions and avoid any strange behavior with coexisting with the built-in runtimes.
Good point. Hopefully the Homebrew installer script will bootstrap this for you. They already build and distribute binary packages, they probably can easily download the existing Ruby package and execute it.
And I have a 4+ year old Perl script I use daily. Yeah, yeah, I know I can install Perl myself but when I distribute it I was expecting it, Perl, to be there—never mind that it is an out-of-date version—I wrote it accordingly.
Not that Apple even supports Widgets anymore beyond their continued vestigial existence, but it was always nice back in the day to have the power to call out from widgets to scripting languages for more power.
I thought it is reasonable. IIRC, my MacOS 10.14.5 has python 2.7.10 built-in (I've install home-brew on it, but I guess it is the Apple built-in version), it is too old (Release Date: May 23, 2015).
As a huge fan of Civ IV, I've found the macOS version pretty janky. I have a generally better experience on my Mac by just using Steam In-Home Streaming from my Windows box.
So, what's the point of using Macs as a better Linux, if they are continuing to strip out the parts of Linux that are useful? Might as well use WSL or Cygwin and save a bunch of money.
... but you have to install these in Linux as well? Python, ruby, etc are not required for Linux to run and for a long time we’re not installed by default (I don’t know if they are these days because the regular fresh install dance for Linux just has me autopilot through installation of all the things that are inexplicably not included, which historically included python).
There are many reasons that people choose to use a Mac, mostly when people say “Linux” in this context they mean: posix shell, and the ability to run most other posix software (eg most Linux commandline apps).
It’s not because it has every interpreter on earth installed by default. In fact as others have said the current status is that the system installs of python and ruby are old because updating them breaks software. The solution is to make them not part of the OS so if software does want to use an interpreter they don’t lock the shipping version again.
Linux doesn’t have this problem because it’s assumed that your update process comes from a central repository of all the apps so if you (say) update python you also pull recompiled updates of all the apps you have that depend on python. Software installation on a Mac is generally not all from one source, and even if it were Apple doesn’t have the ability to recompile other developer’s apps.
You do realise that the reason these things are being stripped out is because macOS includes hideously old versions for backwards compatibility with older software that depended on them, right?
There is no real loss here; no sane users would use the built-in versions due to their age. It has been preferable to download and install newer versions for a long time, this changes nothing.
And if it's fine to spend a tiny amount of effort to install WSL or Cygwin on Windows, then it's surely also no effort at all to install Homebrew or MacPorts (or other) — with the benefit of not working in a contrived, separate environment.
This comment betrays a fundamental lack of understanding of modern developer workflows in macOS and feels just slightly like a troll comment from someone who likely doesn't use macOS to begin with.
> And if it's fine to spend a tiny amount of effort to install WSL or Cygwin on Windows
Well, plenty of people use macOS precisely because it was like a more consistent Linux out-of-the-box. Apple will lose a ton of mindshare; indeed, they are losing a ton of mindshare. They've been slowly deprecating things for years, now, and leaving the rest to rot, and open source developers are increasingly drifting away.
About 10 years ago macOS and Apple hardware started becoming the preferred kit for open source developers, and this showed--Apple kit was seen everywhere in Silicon Valley and eventually became the default kit given out by big software companies. That was all because of macOS' Unix personality. That's all going to change over the next several years.
I was surprised when WSL 1.0 debuted. By making Linux _native_ on Windows, it solidified Linux' position as the dominate server-side platform. I'm not at all surprised they're ditching it for WSL 2.0, which is just Linux in a VM with a networked filesystem, precisely what people have been doing for about 15 years, keeping it solidly second class--like running Windows on macOS.
I personally believe that the reason why Apple is losing mindshare among some software developers, particularly in Silicon Valley and in academia, has less to do with particular choices regarding macOS and has more to do with Apple's hardware situation, particularly regarding the keyboards on Apple's recent laptops. The keyboard situation has led some developers to consider alternatives to the MacBook Pro, which often necessitates needing to consider non-Mac alternatives. PC manufacturers have been offering some really compelling alternatives to the MacBook Pro such as the Microsoft Surface line of tablets, the Lenovo ThinkPad X1 Carbon, and the Dell XPS 13 and 15, among other computers. Those frustrated with Apple's long delays in releasing updated Mac Mini and Mac Pro models have also considered switching to PCs, if they haven't already.
On top of this, the introduction of WSL in Windows 10 has made Windows a compelling option for many people who use macOS as a Unix that doesn't have the driver issues of Linux/*BSD and happens to support Microsoft Office, Adobe Creative Suite, and other commercial software packages. Provided that they are not hardcore Unix systems programmers, if they want a Unix-like userland with support for Microsoft Office and Adobe Creative Suite, why not try WSL? Despite my preference for macOS, I've used WSL on my work-issued computer as well as on my personal Dell XPS 15, and I must say, I'm very impressed with it. No more having to mess around with PuTTY or with virtual machines to do Unix work on Windows. While I am personally more productive in macOS than in Windows even with WSL, I know quite a few former Mac users who are very happy with Windows 10, thanks to WSL.
Now, software engineers who primarily work with Apple frameworks and technologies probably won't be satisfied with Windows. But software engineers who use macOS primarily as a convenient Unix with support for commercial software packages might want to give Windows 10 and WSL a try. Now, personally I'm still turned off by certain lingering "Windowsisms" (insert gripes about telemetry, ads, mandatory updates, and the UI here), but for many people Windows 10 is now a compelling alternative to the Mac.
Not that I'm providing any citations myself, but I'd like to see some evidence that macOS is losing mindshare because it doesn't bundle this, that, or the other by default anymore. macOS will remain a consistent UNIX out of the box, more consistent than Linux, as it still bundles the FreeBSD userland, their own additions, and make it simpler than ever get started developing — you can install Xcode from the App Store or just the command line tools with ``xcode-select --install``. Things like Homebrew and MacPorts can even install those for you if they're missing.
When using macOS, nobody is thinking "fantastic, I can't wait to use these hideously outdated versions of things" — it's a straight trip to Homebrew or MacPorts to sort things out, always, because the built-in version is categorically never the version people write scripts against. Nobody could depend on such old versions of Perl, Python, and Ruby because they were so ridiculously out of date.
Deprecating things that should already have been deprecated is not going to stop people preferring the experience that macOS still affords to developers. I don't see how that's going to change, there's no evidence to support this; if macOS has been losing popularity amongst developers, the butterfly mechanism and Touch Bar on the MacBook Pros has more to answer for than macOS itself which remains solid, reliable, and the best way to get stuff done on UNIX without the interminable fiddlyness of Linux.
Also, I think your timing and causations back to front; the release of WSL didn't solidify anything, it was already well known that Linux was the dominant server-side platform long before. WSL was and is Microsoft's way of bringing Unix-style tooling and development to the desktop, something macOS had done long before. I'd argue that WSL is still a VM of sorts; underneath it all, it's still a slimmed down version of Ubuntu that remains separate from other Windows processes. That WSL 2 will properly move into a VM will make that existing separation clearer, I believe — and yet, I can't help but think Docker on Windows is a more attractive offering in terms of flexibility, anyway.
I think it's fine. Linux distros don't typically come with this stuff, but they do come with package manager (unlike OSX), but it's nbd to install one.
I recently switched to linux after 10+ years of MacBook Pros because I'm disappointed in the hardware quality post 2015. I used to die-hard argue that they were worth the price tag, but now I can't do so in good faith so I got a Dell XPS about 6 months back and love it. Cheaper and superior hardware. There is a bit of learning curve for using linux as an every day work machine, and there is a couple days of setup to get things working just right and achieve parity with OSX features I love (quick view, screenshots, keyboard shortcuts, etc), but once I got everything configured I have no complaints.
It will be two lines of code and two minutes to install the interpreter you need, and you will no longer be tied to a global, possibly ancient system version.
Likewise, you won't have your own installed applications break on update because (for example) python2.7 was EoL and dropped from the OS.
Installing your own instance of python or ruby should be two lines and about two minutes assuming a decent internet connection.
How deep you are willing to go with conspiracy theories ...
If one was planning to kill off all non-approved software on an OS, what would you do first? Remove all the runtimes that can execute unapproved software of course. Then you are free to impose signing as a requirement for applications and a mandatory app store, and reap the 30% rent tax forever more.
Is Apple doing that? Of course, we can't tell. There are lots of good reasons to do this that aren't evil. The best evil plans are indistinguishable from good plans but just happen to have evil outcomes that are in your interest.
That doesn't really contradict anything above. It still remains true that if they were planning on removing ability to run unapproved applications from OSX, the first step would be to take out the ability to do that which is installed by default. Restricting what App Store applications can do would come later (and be controlled by policy rather than technical limitations).
(As RMS wrote in 1983, "Unix is not my ideal system, but it is not too bad. The essential features of Unix seem to be good ones, and I think I can fill in what Unix lacks without spoiling them. And a system compatible with Unix would be convenient for many other people to adopt.")
Whereas such features as "background tasks" were simply a natural consequence of the architecture of Unix, Apple didn't expose that on iOS. Now they've finally gotten around to designing the background task subsystem they really want, and it's not just an emergent property of the generic Unix way. It's built for protecting battery life and privacy. It happens to be built on Unix processes (right?), but that's just an implementation detail for them.
They've been gradually deprecating Unix for 20 years, and designing the OS they want. iOS and its App Store allowed them to kill off large sections of the old interface at once. I fully expect inside of 5 years for all of Apple's operating systems to drop "UNIX" certification and become almost unrecognizable as "Unix". They've got enough market clout now that people will port Ruby/Python/Perl to a non-Unix macOS, just as they port them to Microsoft Windows.