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

351–360 of 374 posts

Re: macOS Containers v0.0.1

#351

Post by throwaway894345 »

jrochkind1 wrote: post #269
throwaway894345 wrote: post #112

Earlier quoted context omitted.

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?

We used native MacOS processes and it worked out fine. In practice I don't recall any bugs due to different behavior between our dev environment (MacOS) and our production environment (Linux) and we saved a ton of time during development. Docker just wasn't worth it. This worked for us because our app didn't depend on any platform specific behavior.

Of course, if you are using Go or some other language with a fast, static cross-compilation step, you don't need to mount a source code volume into your container, you can just rebuild the whole container image or rebuild on the host and `docker cp` the new binary onto the target container.

Re: macOS Containers v0.0.1

#352

Post by throwaway894345 »

lloeki wrote: post #117
throwaway894345 wrote: post #112

Earlier quoted context omitted.

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…

The alternative is to use a performant file sharing system through the VM isolation. Some people use NFS, I personally use VMware Fusion + vmhgfs. Sure it does not attempt to map fsevents inotify 1:1 but honestly I can live with that limitation given that it's a 10x performance increase compared to the DfM kitchensink. I do go native darwin when I can / it makes sense.

Is that something you can configure in DfM or are you saying you sort of roll your own DfM alternative? Also, what does "VM isolation" mean here? How is NFS or VMware Fusion more "isolated" than DfM?

Re: macOS Containers v0.0.1

#353

Post by lloeki »

throwaway894345 wrote: post #352
lloeki wrote: post #117

Earlier quoted context omitted.

The alternative is to use a performant file sharing system through the VM isolation. Some people use NFS, I personally use VMware Fusion + vmhgfs. Sure it does not attempt to map fsevents inotify 1:1 but honestly I can live with that limitation given that it's a 10x performance increase compared to the DfM kitchensink. I do go native darwin when I can / it makes sense.

Is that something you can configure in DfM or are you saying you sort of roll your own DfM alternative? Also, what does "VM isolation" mean here? How is NFS or VMware Fusion more "isolated" than DfM?

> Is that something you can configure in DfM

No

> or are you saying you sort of roll your own DfM alternative?

Yes, I set up a NixOS VM and use DOCKER_HOST=ssh://docker@

If you want to have it easy you can roll with lima/colima (but I found the fs sharing slower than vmhgfs)

> Also, what does "VM isolation" mean here?

The host/guest boundary. The guest is just like any another, remote machine. DsM adds smoke and mirrors to make it look like guest and host are one.

> How is NFS or VMware Fusion more "isolated" than DfM?

It's not, both are VMs and need a way to expose the host fs to the guest, NFS or vmhgfs are a means to that.

Re: macOS Containers v0.0.1

#354

Post by TheHappyOddish »

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.

I ran desktop Linux (Manjaro) for years in an enterprise job with certified hardware, as a Linux sysadmin. I regularly had issues and spent 5-10% of my time troubleshooting the OS or a janky application.

Conversely, macOS is broadly 'production grade'. It mostly 'just works' (with a number of tweaks - including SIP -, hacks etc on initial config, most power users automate with dotfiles). It has a drastically better UI, first class terminals and unixy support, and most code built for it has a higher level of shine.

I am confident enough to deploy alternate security implementations for the convenience of full FS control, as I know many power users are. Disabling SIP is a bad idea for those who don't understand it, the same as disabling Windows Defender or forwarding NAT on your router.

Re: macOS Containers v0.0.1

#355

Post by tambourine_man »

pjmlp wrote: post #346
tambourine_man wrote: post #261

Earlier quoted context omitted.

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.

UNIX was already winning the server room and workstation market before Apple, that is why they came up with A/UX in first place. The Hollywood studios that now use Apple, would be using SGI previously. On iDevices, UNIX APIs aren't even that relevant for app development, even basic stuff like networking has been superceeded by Objective-C specific APIs. So no, I don't see anything UNIX related where Apple has helped…

> So no, I don't see anything UNIX related where Apple has helped to caught on

Perhaps if you read “Rethinking PID 1”, from Lennart Poettering in 2010, who originally wrote systemd along with Kay Sievers

http://0pointer.de/blog/projects/systemd.html

“But first, let's clear a few things up: is this kind of logic new? No, it certainly is not. The most prominent system that works like this is Apple's launchd system: on MacOS the listening of the sockets is pulled out of all daemons and done by launchd. The services themselves hence can all start up in parallel and dependencies need not to be configured for them. And that is actually a really ingenious design, and the primary reason why MacOS manages to provide the fantastic boot-up times it provides. I can highly recommend this video where the launchd folks explain what they are doing. Unfortunately this idea never really took on outside of the Apple camp.”

Other than that, your answer has nothing to do with what I wrote.

Re: macOS Containers v0.0.1

#356

Post by pjmlp »

tambourine_man wrote: post #355
pjmlp wrote: post #346

Earlier quoted context omitted.

UNIX was already winning the server room and workstation market before Apple, that is why they came up with A/UX in first place. The Hollywood studios that now use Apple, would be using SGI previously. On iDevices, UNIX APIs aren't even that relevant for app development, even basic stuff like networking has been superceeded by Objective-C specific APIs. So no, I don't see anything UNIX related where Apple has helped…

> So no, I don't see anything UNIX related where Apple has helped to caught on Perhaps if you read “Rethinking PID 1”, from Lennart Poettering in 2010, who originally wrote systemd along with Kay Sievers http://0pointer.de/blog/projects/systemd.html “But first, let's clear a few things up: is this kind of logic new? No, it certainly is not. The most prominent system that works like this is Apple's launchd system: on…

Maybe they should have spent some time actually looking into Solaris Service Management Facility, or Windows Server SCM for that matter.

Re: macOS Containers v0.0.1

#357

Post by tambourine_man »

pjmlp wrote: post #356
tambourine_man wrote: post #355

Earlier quoted context omitted.

> So no, I don't see anything UNIX related where Apple has helped to caught on Perhaps if you read “Rethinking PID 1”, from Lennart Poettering in 2010, who originally wrote systemd along with Kay Sievers http://0pointer.de/blog/projects/systemd.html “But first, let's clear a few things up: is this kind of logic new? No, it certainly is not. The most prominent system that works like this is Apple's launchd system: on…

Maybe they should have spent some time actually looking into Solaris Service Management Facility, or Windows Server SCM for that matter.

I’m sure they did, it’s even stated in the first paragraph I quoted: “But first, let's clear a few things up: is this kind of logic new? No, it certainly is not.”

It’s just that influence is not all about being first.

Re: macOS Containers v0.0.1

#358

Post by crabbone »

slonopotamus wrote: post #308
crabbone wrote: post #282

Earlier quoted context omitted.

This was more of a stab at "semantic" part of the semantic versioning (which similar to in semantic Web... found its own semantics that don't follow from its definitions). You are definitely not the only one using it like this. I believe this is the problem with the format of semantic version which seem to assume that releases only happen to software ready to be... released :) My preferred course of action in such si…

> My preferred course of action in such situations is not specify a version at all. This doesn't work because, well, I do make releases and they need some numbers)

That's a contradiction. You cannot release a software that you didn't release. :)

If you release it, it has to start with version one. Zero is for non-released versions.

Re: macOS Containers v0.0.1

#359

Post by slonopotamus »

crabbone wrote: post #358
slonopotamus wrote: post #308

Earlier quoted context omitted.

> My preferred course of action in such situations is not specify a version at all. This doesn't work because, well, I do make releases and they need some numbers)

That's a contradiction. You cannot release a software that you didn't release. :) If you release it, it has to start with version one. Zero is for non-released versions.

Okay, let's call them "labeled code snapshots")

Re: macOS Containers v0.0.1

#360

Post by slonopotamus »

thtmnisamnstr wrote: post #273
therealmarv wrote: post #240

Reminds me: Still waiting for native ARM support on GitHub Actions https://github.com/actions/runner-images/issues/5631

This one is ridiculous. This should already exist. Until GitHub builds it, you can use GitHub Actions to kick your builds off but run them remotely on Earthly Cloud ( https://earthly.dev/ ). Even the free tier includes arm64 remote runners. Note: I work at Earthly, but I'm not wrong about this being a good, free, arm64-native workflow for GitHub Actions.

You mean, Earthly has macOS arm64 runners? I am failing to find any info on its website.
Post reply on HN