141–150 of 151 posts
Earlier quoted context omitted.
XNU itself is Mach plus a BSD "personality" taken from FreeBSD[1]. [1] https://developer.apple.com/library/archive/documentation/Da...
You are right, although doesn't look like jails was included.
Earlier quoted context omitted.
You are right, although doesn't look like jails was included.
Yeah, it feels like only the minimum needed for Unixy BSD support was adopted from FreeBSD and included in XNU and the userland.
Earlier quoted context omitted.
XNU itself is Mach plus a BSD "personality" taken from FreeBSD[1]. [1] https://developer.apple.com/library/archive/documentation/Da...
You are right, although doesn't look like jails was included.
NeXTSTEP had proprietary UNIX code in it, and required a UNIX license from AT&T to distribute. Additionally, the display manager (infamously) was based on Display Postscript, which also required a license from Adobe.
My understanding (which is by no means 100% certain! the following is my best guess) is XNU and Darwin were almost complete "rewrites" of NeXTSTEP, preserving the "idea" but with new code.
NeXT's Mach 2 based kernel and BSD userland, which seems to have been very similar to the system developed by Avie Tevanian at CMU and used on their VAXen, was replaced with XNU, which used a Mach 3 derivative from DEC's OSF/1 project, coupled with a new (non-AT&T encumbered!) BSD userland and kernel "module"/personality based on an amalgam of then forks of 4.4BSD-Lite/386BSD, namely FreeBSD and NetBSD (several big bits of libc are from NetBSD).
Point being, I doubt they've copied/pasted large chunks of Free/NetBSD into Darwin/XNU since the late 90s/early 2000s. There was been code flow between the two, but I doubt they'd backport big features like jails (and linux emulation).
(not to mention that Apple's own MACF framework seems to take the place of jails in the code -- see https://github.com/apple/darwin-xnu/blob/main/bsd/kern/kern_... vs https://github.com/freebsd/freebsd-src/blob/main/sys/kern/ke...)
Turns out the title is missing a vital piece of information that this is a port that targets macOS.
Earlier quoted context omitted.
Yeah, it feels like only the minimum needed for Unixy BSD support was adopted from FreeBSD and included in XNU and the userland.
The thing that’s a bit surprising to me is that this didn’t include FreeBSD’s Linux emulation
Earlier quoted context omitted.
> I'm going to patch podman to make it possible to run both amd64 image and aarch64 image From what I understand, if you had working QEMU-static and binfmt, wouldn't cross-architecture containers just work? I've used that a lot in chroots, and I'm confused as to why that wouldn't just transparently work in this case. Are you talking about just making that process easier? Does podman enforce extra checks that prevent…
If you just switch the binary you’re 90% finished but there are some chores to make it perfect 1. The arguments given to the qemu should be changed by the CPU arch. For example, AArch64 uses ‘-accel=hvf’ while amd64 in Apple Silicon must use ‘-accel=tcg’. AArch64 requires ‘-cpu’ option whild amd64 does not. etc. And currently, the arguments of QEMU is half-way hardcoded to the podman source code. 2. You should change…
Sounds like amd64 is falling back to BIOS, while aarch64 never really had any other standard than UEFI. You should be able to run UEFI for amd64 too if you force the machine type to pc-q35-6.1 (or whatever QEMU version you're using).
Earlier quoted context omitted.
This suggestion is a security nightmare! Anyone is one typo away from installing random junk from the internet on your machines. No one should be using docker in production while it can connect to a public registry where you have zero control of its contents.
Did you read my comment? Because I can't find any interpretation of your response that makes sense assuming you comprehend the actual content of my statements.
> I agree that it should be possible to disable the default registry, but I'm not sure I agree with allowing you to override it. (These requests appear to be conflated in various comments.) Use your own registry by specifying the domain first `myregistry.example.com/repo/image`; an unadorned `repo/image` being globally reserved as shorthand for `registry.docker.io/repo/image` seems fine. Allowing overriding the meaning of `repo/image` would be a support nightmare for both moby and internal IT, just use qualified names.
Literally anyone in your company can forget to say `myregistry.example.com/` at any moment. And then your whole infrastructure runs on some random image that you didn't vet. You're a typo away from having your machines owned, your entire infrastructure falling over, your data being exposed to the anyone.
This is no way to live and it's no way to run a company.
Earlier quoted context omitted.
The Docker CLI is also available for Mac, and is open-source.
But the Docker engine (that runs containers on the local machine) is only available on Mac and Windows via Docker Desktop which is not free-as-in-beer anymore for all.
Earlier quoted context omitted.
It doesn't. That is part of the "Docker Desktop" offer, which is non-free.
I just heard (from another commenter), that's dire. I'm stunned.
* Virtualbox * Your favorite Linux distro * Docker engine on the Linux VM * Docker CLI on the Mac host * A variety of filesystem sync solutions (I don’t remember their names but there are several)
Alternatively there’s also docker-machine.
The closed source app gets you the convenience of not having to set that all up. If you don’t like installing closed source apps you probably prefer to set things up yourself anyway. So what’s the problem?