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

231–240 of 374 posts

Re: macOS Containers v0.0.1

#231

Post by slonopotamus »

kevincox wrote: post #229
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…

I am also interested in the API boundary. It seems that there are too options: 1. Rely on system call stability. This is like Linux containers but unlike Linux macOS doesn't provide a stable system call API. So this would break when the system updates with a change that modifies the system call API. 2. Install the host libraries into the container at runtime. This should provide as much stability as macOS apps usuall…

> macOS doesn't provide a stable system call API

I'm really wondering, do you have any links about macOS syscall stability over versions?

Re: macOS Containers v0.0.1

#232

Post by zare_st »

highwaylights wrote: post #147
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.

This is not necessarily the case. On Linux, more or less the entire permissions system makes no assumption about SIP existing (as it doesn't there), so other protections are relied upon to secure the system (such as SELinux, granular directory permissions, etc.). On both Linux and Windows, TPM and secure boot provide similar protections to SIP on macOS, but are optional (it's encouraged more forcefully on Windows 11)…

I'd like to digress to your "Encouraged more forcefully" phrasing which is quite interesting if you think about it. In my view, it would mean something like pervasive dialog box ala EULA, some UI hoops you need to resolve, alike going with local account on installation.

In reality they done basically everything to force users to use secure boot. If they disabled normal boot altogether, OS adoption would suffer heavily. They could've obscured that option, but it would be found out, and enterprise users would be pissed at them because they didn't gave them a provisionable way while the way exists. So it came down to normal variables in installer registry.

However modifying, e.g making users "hack" the ISO is really as forceful as it gets without market loss.

Note: There may be more normal way today than modifying the registry of ISO, I installed 11 once when it came out.

Re: macOS Containers v0.0.1

#233

Post by jmbwell »

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.

They mean they haven’t tried another package manager for Mac, like pkgsrc or macports.

Re: macOS Containers v0.0.1

#235

Post by kevincox »

slonopotamus wrote: post #231
kevincox wrote: post #229

Earlier quoted context omitted.

I am also interested in the API boundary. It seems that there are too options: 1. Rely on system call stability. This is like Linux containers but unlike Linux macOS doesn't provide a stable system call API. So this would break when the system updates with a change that modifies the system call API. 2. Install the host libraries into the container at runtime. This should provide as much stability as macOS apps usuall…

> macOS doesn't provide a stable system call API I'm really wondering, do you have any links about macOS syscall stability over versions?

I do not. I'm not really a macOS user but have heard this mentioned many times. I remember one recent example is Golang switched from doing raw syscalls to using the macOS libc due to this issue. That was probably ~5 years ago now so you may be able to dig up examples there.

Re: macOS Containers v0.0.1

#236

Post by jmbwell »

rafaelmn wrote: post #200
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

OK but what I like about homebrew on mac is that when I'm having an issue with "popular stack X broke after updating" it's probably me and >10k other people out there, so by the time I hit the problem it's already under investigation on GH. I'm not sure the same would apply to homebrew on Linux - even if you ignore the differences between distros - how popular is homebrew on linux and linux desktop in comparison ?

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.

Re: macOS Containers v0.0.1

#237

Post by reddit_clone »

ayewo wrote: post #99
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.

If you really want good adoption, you’ll have to figure out a way for devs to try it out without first having to disable SIP. Is this related to the code you tried to have merged here: https://github.com/containerd/containerd/pull/8789 ?

In corporate managed laptops it may not be an option to disable SIP.

Re: macOS Containers v0.0.1

#238

Post by da39a3ee »

nicexe wrote: post #193
da39a3ee wrote: post #95

I use MacOS and am very positive about it. I have lots of reasons to run Linux containers. What are some reasons I might want to run a MacOS container?

I would imagine it would enable you to run MacOS specific pipelines like building a project and have it work semi-portably across different machines/users.

Yes, I can see it could be useful for a company making MacOS software. But for a company whose developers use MacOS but whose product has nothing specifically to do with MacOS, my instinct is that if local environment reproducibility concerns get to that point then linux containers are the answer since they'll be more closely related to CI/prod envs. Or are you thinking maybe that's wrong for large companies with lots of developers using MacOS?

Re: macOS Containers v0.0.1

#239

Post by smoldesu »

noveltyaccount wrote: post #226
lloeki wrote: post #70

Earlier quoted context omitted.

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

> WSL1 was implementing the Linux syscall API on the Windows kernel, which proved to be much more complex than it appears to be. I've long wondered, and again now that Chat GPT is proving so adept at coding, if this translation layer could be automated. Do humans actually have to hand-code each syscall? Or are there just enough edge conditions that can't be automated?

The hard part isn't so much writing the code as it is testing the code. The WINE server is decades old, porting API calls to another kernel isn't an entirely new or novel process. Getting all the software to work right is an ongoing process though, and it requires careful deliberation over what works and what doesn't. WINE code is still being refined to this day in response to new titles and old bugfixes.

So, I won't preclude the idea of AI helping, but I think human effort is still the bottleneck for projects like this. Even if AI could write perfect code 100% of the time, testing and troubleshooting would probably still be the larger timesink.

Post reply on HN