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

131–140 of 374 posts

Re: macOS Containers v0.0.1

#131

Post by rafaelmn »

hamandcheese wrote: post #47
rafaelmn wrote: post #30

Earlier quoted context omitted.

>Wouldn't a Linux device, or Linux running on a Mac suit you better? Maybe they want a unixy desktop with working sound ? Half joking, but that's my use case - homebrew is pretty great, most developers use a Mac in my domains of interest so it's always supported. Linux is just too much work (and I'm using Fedora on my desktop). SIP is just false positives and annoyance. I'm on the fence about M/ARM switch since I sti…

> homebrew is pretty great I hear this said a lot in passing, and I'm really curious what people mean when they say this.

I can use it to get stuff I need to do work and I don't remember the last time I couldn't. Upgrades sometimes leave me broken but it's usually ironed out fast because everyone is using it. If my dependencies are that locked down I'm using docker and special environments anyway. Linux can get tedious with upgrades breaking or dependency mismatches. Homebrew is probably the largest homogenous community - if you're doing something relatively popular there will be a lot of noise when stuff breaks. Linux is spread out across various distros/repos/package managers, overlap of users with your problem is a lot smaller.

Beats all the package management experiences I've had on Windows, admittedly I have not tried to use Windows for work for >1 year.

Re: macOS Containers v0.0.1

#132

Post by dtech »

stonewhite wrote: post #88
urxvtcd wrote: post #71

Earlier quoted context omitted.

Anecdotal evidence, but here it goes. I moved from Linux to M1 MacBook recently. I know my greps and vims, but I was tired of audio glitches during high CPU usage, system not waking up from sleep, total OS freezes, super loud fans, and so on. Now I get none of that. I don't think I've ever heard the fans. Audio just works, everything is super snappy. It always wakes up. I'm no longer afraid of bluetooth. And on top o…

Exactly my experience. After 15 years, I became an apple fanboy in 15 days. I still do hate losing my muscle memory on some bash shortcuts, but I'd say it was very much worth it.

You can just install a recent bash with homebrew and use that as your terminal.

Re: macOS Containers v0.0.1

#133

Post by kdrag0n »

highwaylights wrote: post #16
AceJohnny2 wrote: post #6

How does this work? Fundamentally, containers are about namespace/isolation of a bunch of OS interfaces, so file system functions, network functions, memory management, process functions, etc, can all pretend like they're the only game in town, but crucially without having to virtualize out the kernel. Does XNU have such namespacing functionality across all its interfaces? Furthermore, the existing container ecosyste…

This introduces a long-standing problem that is really the main issue I have with Docker/Podman/containers on anything other than Linux - you have a dedicated VM that needs memory to be set aside for it exclusively. This is fine if you have a 32/64GB machine, but less so on an 8GB non-upgradeable laptop. I get it - memory is relatively cheap these days - and manufacturers that are building memory-limited devices are…

This is supposed to be possible on macOS, but it's basically completely broken (just doesn't work) due to a bug. Apple is aware of it but unfortunately hasn't said much more.

Obviously that limits the options, but I'll still be taking one last shot at using creative workarounds to tackle the memory problem in OrbStack (another containers-on-macOS product).

Re: macOS Containers v0.0.1

#134

Post by donatj »

lloeki wrote: post #130
donatj wrote: post #127

What's the licensing situation on this? Would I be distributing parts of macOS in my containers? I don't think Apple is OK with that. Or is this just the fully open source Darwin core? That wouldn't likely be super compatible with a ton of production software? I need more explanation of what is actually going on here because it sounds like a good way to get sued.

> Would I be distributing parts of macOS in my containers? Unless you're producing fully static binaries (or static enough that they don't bind to non-redistributable things) it'd be a yes (it would not be much of a container if it needed non-packaged things) The screenshot points out a ghcr.io URL that lands on these packages: https://github.com/orgs/macOScontainers/packages?repo_name=m... Edit: There's a note here†…

Counting the hours until this gets DMCA'd out of existence

Re: macOS Containers v0.0.1

#135

Post by pdpi »

hamandcheese wrote: post #68
kowlo wrote: post #56

Earlier quoted context omitted.

Perhaps they are talking about Homebrew the package manager [1]. [1] https://brew.sh

I wonder what people mean when they say "Homebrew is pretty great", I do not wonder what they mean when they say "Homebrew".

It's plenty solid, and there's a good library of packages on there. It's a package manager, doesn't take more than that.

Re: macOS Containers v0.0.1

#136

Post by tannhaeuser »

highwaylights wrote: post #21
perryizgr8 wrote: post #15

Earlier quoted context omitted.

> "Disable System Identity Protection." This is the first thing I do on any Mac OS system before I start using it.

This kind of makes me wonder why you'd have a Mac at all (I'm sure there are use cases). Wouldn't a Linux device, or Linux running on a Mac suit you better? For me, the security picture is one of the main features of the eco-system even if it's very restrictive - disabling SIP undermines it more or less completely.

> Wouldn't a Linux device, or Linux running on a Mac suit you better?

No? Maybe you're preferring Mac OS for getting stuff done, exchange work with the outside world and/or use non-historic software (like any commercial desktop app such as idk Photoshop, Sketch, Audio, 3D, CAD s/w, etc., etc.) and still are a developer?

Or even doing something esoteric such as using office software without wanting to throw your notebook out of the window?

Re: macOS Containers v0.0.1

#137

Post by chupasaurus »

highwaylights wrote: post #16
AceJohnny2 wrote: post #6

How does this work? Fundamentally, containers are about namespace/isolation of a bunch of OS interfaces, so file system functions, network functions, memory management, process functions, etc, can all pretend like they're the only game in town, but crucially without having to virtualize out the kernel. Does XNU have such namespacing functionality across all its interfaces? Furthermore, the existing container ecosyste…

This introduces a long-standing problem that is really the main issue I have with Docker/Podman/containers on anything other than Linux - you have a dedicated VM that needs memory to be set aside for it exclusively. This is fine if you have a 32/64GB machine, but less so on an 8GB non-upgradeable laptop. I get it - memory is relatively cheap these days - and manufacturers that are building memory-limited devices are…

WSL1 didn't run Linux kernel anywhere.

Re: macOS Containers v0.0.1

#138

Post by kafrofrite »

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.

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.

Re: macOS Containers v0.0.1

#139

Post by slonopotamus »

dvdplm wrote: post #123
dingi wrote: post #94

Can anybody explain, what's the point of Mac containers? Almost nobody uses Mac for container based deployments.

CI/CD workflows most likely. And devshops that have standadised on docker containers for their stacks (mac-based devs in such places suffer a fair amount of papercuts today). Then I guess there are people that are very security minded that might want to run all userland executables in containers (although this project here is not for them I'd say).

> CI/CD workflows most likely

Yep, this is primary goal of this project.

Re: macOS Containers v0.0.1

#140

Post by highwaylights »

vetinari wrote: post #57
highwaylights wrote: post #23

Earlier quoted context omitted.

I have these thoughts about Homebrew also. macOS apps have to be signed and notarised to run without a warning, which is a pretty big part of the defence picture for this software - the certificates can be revoked at any time to block the software if malicious behaviour is identified. However, if I install Homebrew, then install python, then install a pip package, there's really no kind of scanning/notarization/check…

> However, if I install Homebrew, then install python, then install a pip package, there's really no kind of scanning/notarization/checking happening at all. There is: you are running that pip package in a chain of processes: Terminal (or iTerm, or whatever) - your shell - python - pip package. In this chain, Terminal has "Developer Tools" privilege, which allows you to run software, that does not meet the system's s…

EDIT: Having looked at this again, I'm not sure the Developer Tools privilege is even required to run essentially arbitrary software in Terminal. Homebrew still works without Developer Tools installed, as do interpreted runtimes. If I can even run an arbitrary shell script then the privilege is pointless, which makes the case for a dedicated sandbox for Terminal even more important.

This is my point, Terminal with Developer Tools privilege is essentially granting carte blanche privilege to every sub-process running there, which is not really necessary.

If I could pop a Terminal with a restrictive scope, allowing read and write access only within that directory tree it would be a much better situation than we have now. macOS' permission system isn't really that far away anyway - I can already disable Terminal's permissions to access anything else same as other apps.

Essentially a basic and very limited not-even-a-chroot would be a vast improvement and would still offer an adequate sandbox.

Post reply on HN