Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

macOS Containers v0.0.1

macoscontainers.org

Post reply on HN
Print view View original

261–270 of 374 posts

Re: macOS Containers v0.0.1

#261

Post by tambourine_man »

pjmlp wrote: post #254
tambourine_man wrote: post #222

Earlier quoted context omitted.

Which is why I said: “All of that stuff was not a first ever implementation, of course, but it was well executed and led the way.” Apple is rarely the first at doing something but it's often the first that's good and cheap enough that people care about.

Which makes the point that there is hardly any UNIX inovation coming from them. Please cite a USENIX research paper from Apple.

Apple didn’t invent the GUI, touchscreen or the concept of unifying init, cron, etc.

But it was after they released their implementations that those ideas caught on.

I hope you can see the point I’m making.

Re: macOS Containers v0.0.1

#262

Post by samtheprogram »

edgyquant wrote: post #247
nightfader wrote: post #188

Earlier quoted context omitted.

Homebrew is available for Linux as well since approx 3yrs now. I've been using it without issues https://docs.brew.sh/Homebrew-on-Linux

I’m curious what’s the benefit? I use homebrew as a Linux package manager for MacOS. On Linux I just use the distros package manager

If you need to build something from source (my use-case: Vim, so I can change which language bindings exist in the resulting build) it can sometimes be a lot easier than cloning and using the "raw" C/Make build system.

Also, assuming a downstream distro like Debian or Ubuntu, what's in Homebrew is likely a more up to date package. You could fiddle with adding/using Debian testing or some PPA, or... you could just use Homebrew.

(FWIW: I use Arch and the AUR on my desktop Linux installs these days, and it's essentially the same process. But still using Homebrew on the Mac, and occasionally in Linux when I'm not on a desktop)

Re: macOS Containers v0.0.1

#263

Post by jmbwell »

edgyquant wrote: post #248
jmbwell wrote: post #236

Earlier quoted context omitted.

I wish more of those 10k people would help get others off of a package manager that is so fragile and convoluted that updating so often leads to popular things breaking. Things like macports and pkgsrc do things in an arguably much simpler, more unixy way, without the contortions that so often seem to leave homebrew in a bind after routine operations like updating.

I’ve never experienced a broken homebrew and I’ve used Mac for years

The comment was in response to parent's stated complaint, namely having to wait for someone else to resolve issues with popular packages being broken after an update, which has been the experience of more than one user.

Re: macOS Containers v0.0.1

#264

Post by totallywrong »

slonopotamus wrote: post #81
maggit wrote: post #33

Earlier quoted context omitted.

"System Integrity Protection (SIP)" seems to be the correct name here, for anyone as confused as me :) (More details here: https://support.apple.com/en-us/102149 )

Original author here. Thanks for spotting the typo, fixed. WRT security implications of disabling SIP - I don't think OS becomes any less vulnerable than usual Linux/Windows installation.

> I don't think OS becomes any less vulnerable than usual Linux/Windows installation.

A modern Linux with SELinux enabled (the default in e.g. Fedora) running apps inside rootless containers (Podman doesn’t even need a daemon) is likely much more secure than your default MacOS or Windows.

Re: macOS Containers v0.0.1

#265

Post by WesolyKubeczek »

duped wrote: post #256

I can't help but feel like this is an X/Y problem. Apps on MacOS shouldn't need containerization to function. I get the point of isolation for build/test situations. But Apple provides a neat virtualization framework, and you get security + isolation + reproducibility + decent performance. It seems like if you feel the need to containerize the userspace on MacOS you're using MacOS wrong. It's not the same thing as th…

> But Apple provides a neat virtualization framework, and you get security + isolation + reproducibility + decent performance.

You also get limits on how many VMs your machine can run, each VM needs gobs of storage and locked-out RAM blocks, and sharing directories between the host and guest, compared to bind mounts, is something that makes me remember for my root canal dental jobs wistfully.

Re: macOS Containers v0.0.1

#266

Post by brabel »

totallywrong wrote: post #264
slonopotamus wrote: post #81

Earlier quoted context omitted.

Original author here. Thanks for spotting the typo, fixed. WRT security implications of disabling SIP - I don't think OS becomes any less vulnerable than usual Linux/Windows installation.

> I don't think OS becomes any less vulnerable than usual Linux/Windows installation. A modern Linux with SELinux enabled (the default in e.g. Fedora) running apps inside rootless containers (Podman doesn’t even need a daemon) is likely much more secure than your default MacOS or Windows.

I think you're probably @totallywrong

Re: macOS Containers v0.0.1

#267

Post by duped »

WesolyKubeczek wrote: post #265
duped wrote: post #256

I can't help but feel like this is an X/Y problem. Apps on MacOS shouldn't need containerization to function. I get the point of isolation for build/test situations. But Apple provides a neat virtualization framework, and you get security + isolation + reproducibility + decent performance. It seems like if you feel the need to containerize the userspace on MacOS you're using MacOS wrong. It's not the same thing as th…

> But Apple provides a neat virtualization framework, and you get security + isolation + reproducibility + decent performance. You also get limits on how many VMs your machine can run, each VM needs gobs of storage and locked-out RAM blocks, and sharing directories between the host and guest, compared to bind mounts, is something that makes me remember for my root canal dental jobs wistfully .

I've only used it with Linux kernels, but that has not been my experience with the new Virtualization.framework. The perf of virtio shares is reasonably fast.

I can see how you'd need a crap ton of disk for MacOS virtualization, but again, why do you need it?

If it's isolation for builds, fix your build. If it's isolation for tests, live with it. If it's for running your app, write your app to properly run in the app sandbox.

Re: macOS Containers v0.0.1

#268

Post by dartos »

insanitybit wrote: post #224
kafrofrite wrote: post #138

Earlier quoted context omitted.

> I don't think OS becomes any less vulnerable than usual Linux/Windows installation. is not a good enough argument. For the story, SIP is Apple's "rootless". Effectively the OS runs with less privileges than root. Disabling SIP significantly increases the attack surface. That being said, I'm grateful that someone decided to do something more native for containers in macOS.

I think it's an OK argument given that most people run (and have been running with no alternative until very recently) docker in such a way that there's a trivial privesc to root. In general it seems like docker users are, overall, willing to take that tradeoff.

How so? I use docker pretty frequently, but I’m sure that my user is part of the docker group before I do, so I don’t sudo anything.

Is there anything else I should be doing security wise?

I’ve been hearing podman is more secure, but I think it’s still containerd under the hood, so idk how true that is.

Re: macOS Containers v0.0.1

#269

Post by jrochkind1 »

throwaway894345 wrote: post #112
hhh wrote: post #96

Earlier quoted context omitted.

Docker Desktop doesn’t require me to disable SIP. Why would I use this if it requires that?

Docker For Max marshals filesystem events over a VM host/guest boundary which can grind the most powerful computers to a halt if you’re sharing directories between the host and guest. For example, at my last company we developed Python apps and ran them in Docker for Mac containers by mounting the source code directory into the containers (so we wouldn’t need a build step) but as our project grew the filesystem event…

> until we eschewed Docker from our dev iteration loop entirely

Can you say anything more about what you did instead, and how it ended up working out?

Re: macOS Containers v0.0.1

#270

Post by WesolyKubeczek »

What my dream is that the User Mode Linux is made into a cross-platform userspace binary that translates syscalls transparently between itself and the host. So you might get "drivers" that talk to Windows, Linux, *BSDs, Darwin, it manages memory in an efficient (for the host) way, and enables you to run any kinds of wild experiments with, say, virtualized and passed-through serial devices, USB devices, networking, bind-mounting from the host and image mounts. And yes, containers. All of that without needing host root in most cases.

Of course the drawback would be that the host would see just a fat Linux process and its child processes, much like you can see qemu, but it could be an interesting thing nonetheless, if even for shits and giggles of it.

Post reply on HN