NTT Labs Blog
medium.com/nttlabs · Company blog · on HN since 2019
NTT's engineering lab writes about containers, Docker alternatives, Linux, Kubernetes, and reproducible builds, often by maintainer Akihiro Suda.
What HN saysHN commenters link it for practical container guidance: Containerd with Lima on Mac, avoiding host networking, reproducible Dockerfile builds, and nerdctl.
20HN people shared it
6linked it in comments
16stories submitted
61story points
9 months agolast shared
2019people per year2026
Most-shared posts
- 1Containerd and Lima: open-source alternative to Docker for Mac3 people · 3 points · first shared 2021 · discussion on HN
- 2The current adoption status of cgroup v2 in containers3 people · 2 points · first shared 2019 · discussion on HN
- 3Linux Subsystem for FreeBSD2 people · 8 points · first shared 2022 · 1 comments on HN
- 4Don’t use Docker run –net=host – Don’t use spec.hostNetwork2 people · 5 points · first shared 2020 · discussion on HN
- 5Preparation toward running Docker on ARM Mac2 people · 4 points · first shared 2020 · discussion on HN
- 6Bit-for-bit reproducible builds with Dockerfile2 people · 4 points · first shared 2023 · 1 comments on HN
- 7Show HN: Elfconv – Linux Apps to High-Performance WASM Binary Translator1 people · 18 points · first shared 2025 · discussion on HN
- 8Show HN: Instance-per-Pod Webhook: IaaS-Level Isolation for Kubernetes Pods1 people · 6 points · first shared 2019 · discussion on HN
- 9New features in Docker 20.10 (Yes, it’s alive)1 people · 5 points · first shared 2020 · 1 comments on HN
- 10P2P Container Image Distribution on IPFS with Containerd (2021)1 people · 3 points · first shared 2022 · discussion on HN
- 11Show HN: Kubernetes Driver for Docker BuildX1 people · 1 points · first shared 2019 · discussion on HN
- 12Alcoholless: A Lightweight Security Sandbox for Claude Code1 people · 1 points · first shared 2026 · discussion on HN
- 13Experimental support for FreeBSD in Containerd 1.51 people · 1 points · first shared 2021 · discussion on HN
- 14Nerdctl v1 0 fb6bf8e1b0b1 people · first shared 2022
- 15Nerdctl 359311b32d0e1 people · first shared 2021
What HN people wrote when they linked it
Corsome · 2023-07-27
Agreed with most of the points raised here although reproducible images are currently hard to achieve due to technical reasons on how docker builder operates. See https://medium.com/nttlabs/bit-for-bit-reproducible-builds-with-docker…
sandGorgon · 2022-12-24
is this a fork of nerdctl ?
nerdctl is the coolest project ever. created by Akihiro Suda (https://medium.com/nttlabs/nerdctl-v1-0-fb6bf8e1b0b) for a containerd equivalent with the exact same UX of docker.
sbrivio · 2022-10-18
On top of that, you usually want to isolate the container workload with an observable network abstraction instead of granting it full (albeit non-root) access to host network facilities (including sockets).
See https://medium.com/nttlabs/dont-use-host-network-namespace-f548aeeef57… for just an example of what can go wrong otherwise.
seanhunter · 2022-10-16
On an M1 Mac I believe that rancher desktop (mentioned in a sibling thread) is the way to go if you are going the kubernetes route. Because I only have a really simple usecase and want something just like docker I've been using lima[1] which you can just install with homebrew and set up an alias and then pretend you're using docker. I have had some problems where in long-running processes with a lot of network usage in the container after a while I get some network timeouts. I'm not sure whether that's a problem with lima or qemu or what else might actually be causing it. But basically as a dev experience it works fine even on a pretty underpowered laptop (which is what I'm using it on in this case).
[1] https://medium.com/nttlabs/containerd-and-lima-39e0b64d2a59
Borlands · 2021-09-06
Thanks, I wasn’t thinking only about docker desktop, but also more specifically docker cli and compose (but now makes sense)
btw for mac there’s Containerd + Lima https://medium.com/nttlabs/containerd-and-lima-39e0b64d2a59
cycloptic · 2020-05-16
>having all cgroup operations flow through its opinionated dbus api was simply unacceptable for docker, kubernetes, lxc, runc, and everybody else maintaining quality container runtimes.
I think you're off-base on this. Work is being done to get support for cgroupsv2 in all the major container runtimes. Source: https://medium.com/nttlabs/cgroup-v2-596d035be4d7
In any case single-writer was not an explicit goal of systemd, it was an intentional design decision that came from the kernel. TFA even mentions this, although it is somewhat lost within the pages of ranting. You also don't even have to use systemd's D-Bus APIs to deal with this. Container managers can if they want to provide additional integrations. Source: https://systemd.io/CGROUP_DELEGATION/