Hacker News new | ask | show | jobs
by mdaniel 1388 days ago
> That and some sort of container story.

While off-topic for this thread, I don't think that's going to do what you expect. If you snapped your fingers and XNU suddenly had cgroups and other namespace trickery required to make containers operate, you'd still have the grave problem of "containers are not virtual machines" and thus an XNU container would only run Darwin binaries, so you're back to the old days of "run one exe locally, run another in prod"

2 comments

You're assuming that everyone's "prod" is a Linux server. I would say that MacOS needs containers for developing Darwin software.
Yes, I think that's a perfectly reasonable assumption given that (AFAIK) the only current "containerization" (as GP used that word) strategy is on Linux. BSD has jails and Solaris has something similar, but as far as "fire this thing up with its own pid, network, and fs namespacing, and allow me to constrain it easily" that's just Linux. I guess put another way: you run Darwin in production?

As for the latter, macOS actually does have what they call Containers (https://developer.apple.com/library/archive/documentation/Se...) but as best I can tell such a thing requires opt-in from the app, which kind of defeats the purpose of running untrusted software IMHO. I actually only learned about that Containers stuff from trying to find where in the hell 1Password 8 stores its actual sqlite file: `$HOME/Library/Group Containers/2BUA8C4S2C.com.1password/Library/Application Support/1Password/Data/1password.sqlite`

>BSD has jails and Solaris has something similar, but as far as "fire this thing up with its own pid, network, and fs namespacing, and allow me to constrain it easily" that's just Linux.

Nope, you get the same thing with jails, just easier. Jails weren't developed by a company living off selling support for it, you know :-)

I guess put another way: you run Darwin in production?

Anyone who builds software for MacOS, iOS, or iPadOS targets Darwin as their production environment. This includes end user applications and tools used by other devs.

Thanks for this. I have a library that uses 1Password files and have not updated for v8.
Be forewarned that (to the best of my knowledge) they haven't, and likely don't intend, to document the sqlite structure. The contents in the sqlite file seems to mirror the api responses from their new rest apis, so their Burp analyzer (https://github.com/1Password/burp-1password-session-analyzer...) may help matters, as will the absolutely essential reading (https://darthnull.org/inside-1password/) along with its code (https://github.com/dschuetz/1password#readme) and I just found this while digging up those other links: https://github.com/mickaelperrin/onepassword-local-search/bl...
> "containerization" (as GP used that word)

No one used that word

Yeah, but easily switching between specific version of PHP, MySQL, Node.js, etc, without messing with /usr/local/bin and brew while having full speed disk access goes a long way.

I could probably get by with the chroot support that macOS has, but I never manage to find the motivation.

You can install multiple versions of PHP and Node alongside each other just fine using Homebrew:

    brew install php@7.2 php@7.3 php@7.4 php@8.0 php@8.1 # and soon php@8.2

    brew install node@18 node@16 node@14 node@12 node@10
Most people don't want to install and uninstall software at the system-level like that. They'd rather have nicely isolated disposable containers for individual projects.
Installing multiple versions is solved, changing the environment easily, not so much, I think
I'm not sure of the specifics with Homebrew, but with MacPorts, I have both PHP 7.4 and 8.1 running via FPM and serving sites rather trivially. The basics: Install both php74-fpm and php81-fpm, configure the former to put its socket at /var/run/php74-fpm.sock and the latter at /var/run/php81-fpm.sock, configure nginx's domain-specific config files to look for the FastCGI socket that the respective path, use MacPorts to load both daemons, and away you go. I imagine a similar approach would be possible with Homebrew.
I edit Apache’s config files and reload it every time, but I’m not pleased with that solution.
Is there not a way in Apache to specify a different path for the FastCGI socket based on the domain name? It's been a long time since I've used Apache but I'd be surprised if the functionality wasn't somewhere in its inscrutable config file syntax.
or just use asdf
I wasn't aware of it, thanks. I'm not it's exactly what I want though. Can it easily start and stop daemons? Can it assign different ports to different versions?