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

macOS Container Machines

github.com

Post reply on HN
Print view View original

141–150 of 457 posts

Re: macOS Container Machines

#141

Post by TylerE »

rpeden wrote: post #129
TylerE wrote: post #121

Earlier quoted context omitted.

The biggest issue I remember is directory seperators... windows of course using \ which bash would then interpret as an escape. Cygwin mostly papered over that from what I can recall, but it could lead to some weirdness, like sometimes you'd get C:\\path\\es\\like\\this

You could also use forward slashes, like C:/path/subpath, which has worked since Windows 1.0/DOS 2.0. That's handy when you're entering paths in a Cygwin/MSYS Bash shell, but might not help much if you're trying to parse or otherwise work with existing patgh variables composed with backslashes.

Yes, you could if you were entering them manually, but some apps that generated file names would screw it up. I think they were using some sort of stdlib function to get the path seperator. Forward slash paths working in native windows apps also wasn't quite a given, either. Keep in mind this was a loooong time ago... like windows xp era maybe, even.

Re: macOS Container Machines

#145

Post by d3v1an7 »

kdrag0n wrote: post #26
blahgeek wrote: post #10

OrbStack works really well for me. I wonder how it’s compared to this performance wise

(OrbStack dev here.) Instead of Virtualization.framework, we have a custom Rust virtualization stack with custom devices and protocols for things like filesystem sharing. It's a highly optimized vertically integrated stack specifically for running our Linux machines and containers. Our biggest perf/resource gain is dynamic memory, which reduces memory usage a lot by releasing unused memory back to macOS. Nothing else…

just adding a 'hell yeah: orbstack is so good' to the thread. i mainly avoid containers where i can, but when containers need to happen, orbstack is 'just enough' for me. lovely and well considered ui, stable, performant. don't need much else. thank you for your work and care!

Re: macOS Container Machines

#146

Post by bel8 »

vehemenz wrote: post #117
TheDong wrote: post #107

Earlier quoted context omitted.

Apple set itself up for defeat in the server and developer marketplace as soon as they decided macOS was proprietary code. Why would any serious developer use closed-source code they can't debug and modify? Especially for a production server? It's the same reason no serious developers or hackers use macOS, like part of the point of being a developer is being able to dig into the code at any layer and debug and fix th…

No offense, but serious developers don’t think this way at all.

For server side, which I believe is the context here, Linux and open source are king.

Even Microsoft gave up on Windows and just runs Linux most things except niche cases. Heck, even SQL Server which is expensive piece of machinery got ported to Linux and that's the default target now in their docs.

With that said, one can't deny Apple's success on the b2c side of things so it feels wrong to call their strategy a failure.

Re: macOS Container Machines

#147

Post by Gigachad »

xd1936 wrote: post #143
vachanmn123 wrote: post #142

Could this allow us to use proton on mac maybe?

This is hilarious. Next year, the PC gamers will be saying "The best Windows gaming experience is win32 on Linux on macOS Containers".

I mean at this point literally anything works better than Windows.

Re: macOS Container Machines

#149

Post by skissane »

MBCook wrote: post #135
cogman10 wrote: post #105

Earlier quoted context omitted.

Potentially faster application execution along much lower memory requirements. In the case of docker, even a possibility of shared library loading further reducing runtime costs (For example, containers based on the same base image could load glibc into memory only once). There's also simply the possibility of using linux software directly in macos without doing OS dependent changes to the software.

Yeah. But in exchange it’s a lot of work to keep up with. For GUI stuff you’re now having to have some sort of Wayland layer/driver. Running VMs is really really easy and low maintenance demand on Apple. And it’s guaranteed compatibility. Wasn’t compatibility what really sunk WSL1?

> Wasn’t compatibility what really sunk WSL1?

Yes, but a big part of the problem with WSL1 was the size of the conceptual gap between POSIX and Windows NT that WSL1 had to bridge. An “MSL1” would likely have fewer problems because the gap between macOS and Linux is smaller, given they are both POSIX

The other thing Apple could potentially do, is add Linux-compatible APIs to macOS. IBM wanted to support Kubernetes on their z/OS mainframe operating system, so they implemented on it a clone of Linux namespace APIs, e.g. unshare. Then we could have macOS nodes in a K8S cluster-which might actually be useful for some people, e.g. if you have a Jenkins CI farm, the Linux nodes can run on K8S, but currently macOS nodes (which you need if you are targeting iOS or macOS) can’t, they have to be bare metal or VMs.

More Linux-macOS source compatibility would also benefit macOS by making it less work to port software to it from Linux

Re: macOS Container Machines

#150

Post by aurareturn »

xd1936 wrote: post #143
vachanmn123 wrote: post #142

Could this allow us to use proton on mac maybe?

This is hilarious. Next year, the PC gamers will be saying "The best Windows gaming experience is win32 on Linux on macOS Containers".

The fastest (Geekbench 6) Windows laptop in the world is actually an M5 Max Macbook running Parallels running Windows.
Post reply on HN