Hacker News new | past | comments | ask | show | jobs | submit login
macOS deprecating scripting language runtimes, including Python, Ruby, and Perl (developer.apple.com)
435 points by undefined1 on June 5, 2019 | hide | past | favorite | 433 comments

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.

And it's to be appreciated. When installing my own Python version, I'm worried it might interfere with system tools that might be written in it.

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.

> Apple hasn't been great at encouraging programming among kids

You should check out what they’ve been doing for years with Swift Playgrounds on the iPad

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.

Swift is open and available on other platforms. I can install it on a raspberry pi if I want.


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.

Huh? You can download Ubuntu builds right on their site


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.

How about using a web browser with JavaScript?

Maybe not the best language for someone new but its widely available.

How about just a web browser?

You can run almost any language from a web browser these days:


A lot of educational sites offer embedded interpreters like this.

It has never been easier to start to learn programming. The real challenge nowadays is maintaining attention...

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.

Different time. Now you got Homebrew

Which installs itself based on the system Ruby. Will be interesting to see how that plays out.

Like it works now with older versions of macOS and on Linux: it downloads a Ruby binary when it's not available on the host system.

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).

Instead of

> /usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/in...

It could become

> curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/in... | bash

With the install script containing a payload containing the current Ruby script plus a Ruby interpreter. Still a "one liner".

> 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.

Doesn't surprise me given they dislike GPLv3 and Zsh is MIT.

Personally I try to use #!/bin/sh as much as possible, and Fish as my default shell.

upvoted for fish

Take a look at the installation instructions for the Rust compiler.


But you have to download Xcode if you want a C compiler!

On the up side though, clang has made the C/C++/ObjC world a much better place.

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).

>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

And you think a one-click download and install of Ruby would have prevented that?

Not to mention Apple also has Swift, and Swift Playgrounds and so on for kids these days.

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.

Swift Playground for macOS? One can hope!

Technically Xcode has supported Playgrounds since before the iOS app existed, though if you mean the teaching content, it doesn't have that.

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.

Or anaconda!

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 dropped X11

You don't have to be anti-unix to do that though, any reasonable organization would have done the same. I agree with the rest though.

    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.

> file paths (forward slash vs. backslash)

Windows file APIs have always supported forward slashes in file paths, even before there was Windows. This goes all the way back to MS-DOS 2.0.

The Windows Subsystem for Linux fixes a lot of these problems, you can even point VS Code at Ubuntu now on Windows and avoid CMD entirely.

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.

Hell, not only VSC supports WSL. RubyMine can manage rbenv/rvm on WSL and more https://confluence.jetbrains.com/display/RUBYDEV/How+to+add+...

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 :)

You don't need a Mac. RoR works perfect on Linux as well.

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.

> macOS uses '/' as a directory separator already

Depends on what level of the UI you're dealing with.

> But macOS uses '/' as a directory separator already.

IIRC, HFS actually uses a ':'.

Mac OS versions prior to OS X used ':'.

Mac OS X, initially released on 24 March 2001, uses '/', like other Unix-derived systems.

Also, like other unices, OS X uses '\n' as the line ending. Prior Mac OSs used '\r' as the line ending. Windows uses '\r\n'.

In A/UX you could use both.

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.

Macs still come with case insensitivity on by default.

but in Finder you can use "/" in filenames, and can't use ":". They got swapped if you look on the file from Terminal.

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.

> Ruby on Windows is a nightmare.

The same stuff with Node.

Not sure why? Yeah there were times with damn node-gym not compiling for whatever reason. But nowadays things run pretty smooth.

Besides paths, Http_proxy settings on enterprise networks is a major pita.

i'm still using cntlm for that (as a proxy in front of the enterprise proxy) : http://cntlm.sourceforge.net/

(sourceforge is the main link, probably best to visit with ublock origin enabled)

paths, compilation etc. Windows isn't main server platform, so people seems like just don't care.

You can use / on Windows in node perfectly, and Windows node now installs required devtools for native modules at the end of the process.

It's pretty easy these days.

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.

> power management, high dpi settings, drivers, etc.

Have the same stuff working on Linux and deploy anything without VM/WSL/telemetry/etc. Guess similar situation with macOS.

> Ruby on Windows is a nightmare.

Nightmare? No. Suboptimal? Yes.

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

> Ruby on Windows is a nightmare.

It hurts when I do this ... [punches self in face] ...


Hint, not every OS is an UNIX clone. Thankfully.

Perl and CPAN works well enough on windows :-)

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.

1: https://www.opengroup.org/openbrand/register/

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.

This. I've asked a macbook at work specifically for this.

I can have an Unix workstation while still being able to run Outlook, Excel and Powerpoint.

I don't want to use Windows and I don't want to use that pile of crap that LibreOffice is... The mac was a good compromise for me.

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.

What makes you think Apple has any plans to move away from Unix?

The alarmist first comment in this very thread...

from the comment I am answering to

> They've been gradually deprecating Unix for 20 years, and designing the OS they want.

>> (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.

In addition to sibling comments, remember that Linus announced Linux as:

"Hello everybody out there using minix -

I'm doing a (free) operating system (just a hobby, won't be big and professional like gnu) for 386(486) AT clones. (...)"

GNU couldn't use MINIX due to the license (unlike minix 3), and as I recall, the bsd's were also in somewhat unclear license terms.

Gnu made the libc, compiler and various userland tools - but no-one did a" simple get it working"-kind of kernel, and then Linux came along.

I suppose part of this might be because in early gnu days, most gnu hackers used university Unix machines - not personal 80x86 for development.

If you bough sun hw you got Solaris. Only if you bought a pc clone would you be wanting a "real" os...


They tried it's GNU Hurd.

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).

Ruby/Python/Perl is not UNIX.

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.

> ...just as they port them to Microsoft Windows.

Just as they ported them to MacOS Classic back in the day.

So is google with chrome os first and then with fuchsia

Weird, I thought the Unix-likeness was a huge selling point of macOS ("the most user-friendly Unix on the market")

for the tech crowd that's for sure, but how much is it for their overall market ?

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.

> It will occasionally override or shadow them

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.

> 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.

Just like WSL 2.0 (https://devblogs.microsoft.com/commandline/announcing-wsl-2/)?

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.

The down side to that is that ruby is currently required to install Homebrew.

Could also just use bash to bootstrap an environment, like how RVM does.

There will be a .pkg for that, if there isn't already.

They seem to package a portable ruby already. https://twitter.com/MacHomebrew/status/1136249501252038662

You already need Xcode to get Homebrew working, and that will most likely be the vector by which optional scripting languages will be installed.

Correction: you need the Xcode Command Line Tools, not the whole Xcode bundle.


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:


Talking about factually wrong...

If you look at the full picture: https://trends.google.com/trends/explore?date=all&q=%2Fm%2F0...

"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.

I did try Homebrew. Once I realised it installs user-owned files into `/usr/local`, I tossed it. It's simply broken by design. For more details, e.g. https://applehelpwriter.com/2018/03/21/how-homebrew-invites-...

Your context link is not an accurate measure:


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.)

While I might disagree with the choices it makes, Homebrew is almost certainly significantly more popular than MacPorts.

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.

On the other hand, actually trying to use MacPorts when one is accustomed to package managers like apt is an exercise in extreme patience.

Interestingly, I feel the opposite: Homebrew acts much more like a binary distribution service than a package manager.

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.

(I use MacPorts)


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.

Can you explain further why you think Homebrew should not be used?

Maybe Google "why not use homebrew"

* 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).

Because it is unusable in multi-user environments as it installs packages as your "ordinary" user instead of root.

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 permissions is a feature

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.

> You are using users in plural.

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 ;)

Why do I care since my desktop computer is not multi-user? Also I configured Homebrew to install it's packages to ~/Applications, problem solved?

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.

(That said, I actually use Homebrew.)

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.

That, with analytics off by default. Also, Homebrew depends on Ruby, and Apple just ditched that

Homebrew installs it’s own ruby when necessary.

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.

Wrong way? I’ve used this method successfully for years.

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:



`* 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.

Or conda, which I prefer to pipenv + pyenv.

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.

AFAIK, macOS comes with Python 2.7 and without pip. For any serious, modern, Python development you need to install Python 3 yourself.

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.

Apple could solve this problem by including python3 with macOS...

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.

You can open https://repl.it/languages/python3 and start writing Python.

with open("~/Documents/important.csv", "r") as f: f.read()

No? Oh well, I guess programming is hard, IT was right. Ok, back to excel...

You can just drag and drop the file on repl.it and it'll just work :)

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.

Majority of our users are hobbyists and novices

Presumably someone said that about python 2 back in the day and that turned out to be a pretty bad decision.

Isn't this the same as saying, we should never include any software, lest it become outdated someday?

Apple could solve this problems by including homebrew with macOS...

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
    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.)

    echo "Hello there. I'm a computer. What's your name?"
    read G
    echo "Hello $G. You are welcome to computer land."

    while true
    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
      elif [ "$S" = "3" ]; then
        echo "Bye."
        echo "Try again." 
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
    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:
        elif S == "3":
            print "Bye."
            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).

    10 SCREEN 9
    20 CLS
    30 COLOR 1, INT(RND*10)
    40 SOUND 20+(RND*5000),.2
    50 GOTO 30
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.

How would you do this on macOS with just the built-in Python or Ruby?

I have no idea... I just wanted to share something fun I did around 25 years ago.

The point is that Python 2.7x is being EOL'd now. The Python that person will likely encounter in the very near future will be Python3.

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.

Why would a new programmer want to start with a deprecated language?

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.

otoh, helping people start by just typing python is great!

otoh, pointing people towards messing with system python... well, it's a trap. And they will get burned, and it will be a nightmare to straighten out.

Yeah you'd be better off having a proper clean install of Python + virtualenvwrapper as your starting point.

Not true. It's better for them to install it themselves so they know exactly what they're using, and so they type python for python 3 and not python3.

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.

What's more scary? Copying and pasting two lines into the terminal, or working out why the hell pip doesn't work.

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.

no. it's better for newbies to learn programming rather than fight with operating systems trying to set up an environment to learn programming in

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 Python and Pip should be part of the learning process for newbies.

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.

It is valuable if they start out with python 3 instead of python 2.

I'd say that depends on what kind of newbie we're talking about.

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.

You still have to download Xcode, of course.

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.

He’s right though.

When I was six years old, learning to program involved turning on the computer and typing

  10 print “hello”
That’s what I want for my kids. And there’s nothing even remotely like it in today’s world.

Open Terminal

    $ echo "hello"
seems pretty much the same to me.

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.

Teaching bash scripting as an introduction to programming? Surely there are laws against that kind of cruelty?

It's certainly not any worse than BASIC on 1980s home micro's. (IMO it's not any worse than Python either.)

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...

And then I remember that there wasn't much more to offer, because most "fun" functionality involved POKE'ing 'random' memory addresses.

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.

> Windows users have had no choice but to do that for decades.

You're saying this like it's a good thing.

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.

It seems like there’s an opportunity for a lightweight statically-linked scripting language. Something between Go and Python.

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.

> if you're doing anything serious for production then the environment should be containerized.

What do you mean?

I’m not OP but:

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?

Of course you do that type of testing.

The problem comes about when someone does the following:

- creates python project

- pip install some_package

- import some_package

Turns out some package was already in the path but a different version

- proceeds to test and build with the assumption of some_package @ newer

- all tests pass

- ships project with requirements of some_package @ newer

Someone attempts to use the package but it doesn’t work.

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.

But maybe I’m not understanding your suggestion.

OP was referring to containerizing your environment for package development.

What does connecting to a production DB have to do with any of that?

at the very least, virtualenv (for Python) to isolate the library dependencies from the system libraries.

Does OSX offer reasonable container technology? chroot?

macOS has a native hypervisor framework, Docker and xhyve uses it.

https://developer.apple.com/documentation/hypervisor https://github.com/moby/hyperkit

A hypervisor is not exactly a container. Definitely not in the Linux sense. It may be more secure, but it is also slower.

Further, there's no decent solution for shipping a macOS container image to run in a VM. Linux, yes, Mac, no.

Finally, good luck getting your virtualized macOS app to interact reasonably with your main OS (no drag and drop, no OpenGL, etc.).

I would rather chroot.

How much slower?

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.

Measurably slower than a LXC container, but still much faster than a full VM.

Qemu has a backend too if I'm not mistaken?

In other words, nothing serious.

Does anyone actually use Docker on Mac?

Xhyve is more of a proof-of-concept than a production-ready tool.

> Does anyone actually use Docker on Mac?

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.

But doesn’t Docker on Mac run a Linux VM? I don’t think it uses any of MacOS’s isolation features.

> Does anyone actually use Docker on Mac?

I use it extensively. It is a desktop product however; it you aren't expected to put a swarm of MacBook pros into production.

Unless you want to run CD to the App Store? So fun....

Ah, but if the XServe had not died and datacenters had racks of these things, there'd no doubt be a production quality implementation by now. Shame.

Xhyve is but one of the options for fronting hypervisor.framework.

Calling it “not serious” is quite wrong.

I use Docker on Mac, and know many others who do as well.

I personally know of at least 3 or 4 engineering teams of 30+ developers who use it daily.

>Does anyone actually use Docker on Mac?

Sure, for development tasks.

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.

or a dockerfile like: FROM macos:10.14

RUN installer xcode... RUN xcode-build myproject

> 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.

Just a little hunch, you know?

The devops guys need to spread the love to the OS group and ship it with the OS.

Maybe it's another "you're not the target market" kind of thing.

The point I'm getting at is that folks on other platforms have lots and lots of options and apple doesn't provide any.

> apple doesn't want macos to be virtualized.

The macOS EULA explicitly allows macOS to be virtualized if you do it on a Mac running macOS.

> It would be really nice to have say the current xcode in one container and a dev xcode in another.

This is the entire point behind xcode-select. I currently have Xcode-beta and Xcode on side-by-side on my machine, and they pretty much coexist.

Can you run them simultaneously? I've never tried.

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.

- "allows" not the same as supports.

- I think xcode-select just modifies a .plist.

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.

Containers lose a lot of appeal once you leave the server, and Apple have explicitly abandoned the server market.

They do offer a set of "primitives" for virtualization, which can be hooked into by third-party solutions like Docker if they want to do so.

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.

Singularity recently released a (non-fully featured, but still useful) mac version.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact