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

61–70 of 374 posts

Re: macOS Containers v0.0.1

#61

Post by sacnoradhq »

przems wrote: post #18
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.

Could you elaborate why? I’m new to macOS, I’d love to learn more about it.

Don't disable security features because of random comments from randos.

Also, don't install shit anywhere but your home directory as you unless you want to break your system in an irreparably, unmaintainable, or unsupported manner.

If you're using sudo, you're already doing it wrong.

https://support.apple.com/en-us/102149

Re: macOS Containers v0.0.1

#62

Post by ShamelessC »

devsda wrote: post #45
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…

> Maybe they want a unixy desktop with working sound ? In my experience, this has not been an issue for the past 10-15 years atleast. Before that there were some problems with few (external) soundcards or random cpu spikes with the mixers. However, the UX can still improve. Switching audio outputs with multiple outputs like external displays etc is not very smooth or intuitive. Some bluetooth headsets have issues but…

> In my experience, this has not been an issue for the past 10-15 years atleast. Before that there were some problems with few (external) soundcards or random cpu spikes with the mixers.

May be some confusion. To run linux on a newer Mac with "Apple Silicon" (ARM based), you need to go through a lot of hoops and much work needs to be done still for a stable environment. Check out https://asahilinux.org/about/

Or maybe you thought they meant running linux in general on a PC (Intel x86 32/64 bit)? In that case I agree - driver issues like that have been mostly ironed out by now.

Re: macOS Containers v0.0.1

#63

Post by zuppy »

rafaelmn wrote: post #30
highwaylights wrote: post #21

Earlier quoted context omitted.

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? 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…

depending of what you mean by friction with containers, there may be different solutins. for example, as a temporary solution on Docker when you don't want/have time to support both arm and x86, you can do something like this: FROM --platform=linux/x86_64 ubuntu:23.04

i haven't found any issues with it that i could not get over in the past 2+ years of m1. most of the containers are available on both architectures anyway. the performance improvement was totally worth it, i won't even talk about the heating issue with intel.

Re: macOS Containers v0.0.1

#65

Post by RockRobotRock »

ThePowerOfFuet wrote: post #38
Squarex wrote: post #5

Earlier quoted context omitted.

Looks like it's open source https://github.com/macOScontainers

Unfortunately, that doesn't answer their question.

It answers both of their questions. Git lets you see the author and they can audit the code if they like.

Re: macOS Containers v0.0.1

#66

Post by AHTERIX5000 »

devsda wrote: post #45
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…

> Maybe they want a unixy desktop with working sound ? In my experience, this has not been an issue for the past 10-15 years atleast. Before that there were some problems with few (external) soundcards or random cpu spikes with the mixers. However, the UX can still improve. Switching audio outputs with multiple outputs like external displays etc is not very smooth or intuitive. Some bluetooth headsets have issues but…

I'm getting early PulseAudio vibes with PipeWire though. BT audio devices stuttering and sometimes losing audio completely regardless of output devices unless I restart the daemon. I guess it stabilizes again during next few years.

Re: macOS Containers v0.0.1

#68

Post by hamandcheese »

kowlo wrote: post #56
hamandcheese wrote: post #47

Earlier quoted context omitted.

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

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

Re: macOS Containers v0.0.1

#69

Post by steeleduncan »

jamil7 wrote: post #51
highwaylights wrote: post #7

https://github.com/macOScontainers/homebrew-formula "macOS native containers" Cool, this sounds interesting. "Disable System Identity Protection." Eesh.

In the context of an internal CI or something, it's probably fine.

Given that the vast majority of CI runs on linux without any equivalent of SIP, I'd have thought it were a complete non-issue

Re: macOS Containers v0.0.1

#70

Post by lloeki »

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…

> If anyone knows of any projects trying to work around that problem I'd love to hear about it.

Containers are namespaced processes. These processes exec against the corresponding kernel they require. There is no workaround: if you have an ELF binary calling Linux syscalls it can only run on a Linux kernel†, so to run that you need a VM††. It's not as bad as it appears thanks to memory ballooning†††.

Conversely if you want to exec a Windows binary in a container, the Windows kernel needs to provide process namespacing features (which it does). And if you want to exec a Darwin binary in a container, then the Darwin kernel needs to provide process namespacing features (which it doesn't).

† WSL1 was implementing the Linux syscall API on the Windows kernel, which proved to be much more complex than it appears to be.

†† Or colinux (https://en.wikipedia.org/wiki/Cooperative_Linux), or user-mode Linux (https://en.wikipedia.org/wiki/User-mode_Linux).

††† https://en.wikipedia.org/wiki/Memory_ballooning

Post reply on HN