Our great sponsors
-
Moby
The Moby Project - a collaborative project for the container ecosystem to assemble container-based systems
The main ones I know of are https://github.com/moby/moby/pull/10411 and https://github.com/moby/moby/issues/11816
There's a comment explaining the rational for the pull request refusal in the first link, but I don't have any info as to if it's accurate or not.
Like pointed out earlier (#11815), this would fragment the namespace, and hurt the community pretty badly, making dockerfiles no longer portable.
You can see that comment at https://github.com/moby/moby/pull/10411#issuecomment-5736648...
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
qemu
Official QEMU mirror. Please see http://wiki.qemu.org/Contribute/SubmitAPatch for how to submit changes to QEMU. Pull Requests are ignored. Please only use release tarballs from the QEMU website. (by simnalamburt)
It looks like the real nice thing here is having a formula for QEMU with the ARM patch applied: https://github.com/simnalamburt/qemu/tree/hvf
With this I believe you could also used [nerd](https://github.com/containerd/nerdctl) instead of podman but I haven't tested it yet.
-
nerdctl
contaiNERD CTL - Docker-compatible CLI for containerd, with support for Compose, Rootless, eStargz, OCIcrypt, IPFS, ... (by AkihiroSuda)
It looks like the real nice thing here is having a formula for QEMU with the ARM patch applied: https://github.com/simnalamburt/qemu/tree/hvf
With this I believe you could also used [nerd](https://github.com/containerd/nerdctl) instead of podman but I haven't tested it yet.
-
`podman machine` uses Fedora CoreOS, which doesn’t currently support aarch64. However, it [sounds like][1] that could change soon.
[1]: https://github.com/coreos/fedora-coreos-tracker/issues/13
-
Mostly because the dev linked to the Homebrew installer when announcing(?) it on her Twitter account[0], but also because the forked repo[1] that contains the patches just shows the original README.
This isn’t an official port to the M1 — it’s a custom version patched by a different dev.
[0]: https://twitter.com/simnalamburt/status/1434244533001224192
-
This has little or nothing to do with "podman people". The stuff people are talking about in the top comments have everything to do with people (and corporations) trying to figure out how to run podman efficiently on MacOS. It certainly can be done by bundling QEMU or through a VM.
Second, Docker Desktop for MacOS and Windows are not open source, hence this repository is empty: https://github.com/docker/for-win
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
nerdctl
contaiNERD CTL - Docker-compatible CLI for containerd, with support for Compose, Rootless, eStargz, OCIcrypt, IPFS, ...
> With this I believe you could also used [nerd](https://github.com/containerd/nerdctl) instead of podman but I haven't tested it yet.
This is the first time I hear of nerdctl and it's _very_ interesting.
M1 aside, does it work fine on regular arm64 linux? I run a small
-
darwin-xnu
Discontinued Legacy mirror of Darwin Kernel. Replaced by https://github.com/apple-oss-distributions/xnu
Darwin and MacOS aren't really all that related to NeXTSTEP, on purpose.
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...)
-
freebsd-src
The FreeBSD src tree publish-only repository. Experimenting with 'simple' pull requests....
Darwin and MacOS aren't really all that related to NeXTSTEP, on purpose.
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...)
