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

Podman, the open source Docker alternative ported to M1 (Apple Silicon) machines

github.com

Post reply on HN
Print view View original

111–120 of 151 posts

Re: Podman, the open source Docker alternative ported to M1 (Apple Silicon) machines

#111

Post by stavros »

dotancohen wrote: post #108
stavros wrote: post #57

Earlier quoted context omitted.

Oh wow, really? I thought Docker Desktop was only a UI that helped you start/stop Docker, I didn't realize there's no OSS version at all . That's much worse than I thought, wow. I guess I'll have to switch to Podman too, even though I don't use Mac, just because we need a unified approach across OSes in our company and can't afford to have Mac-using developers be second-class citizens.

I love this comment. 15 years ago we were refusing Windows-only tools to protect the Linux users, today we are refusing Linux-only tools to protect the Mac users.

Well, work has to get done...

Re: Podman, the open source Docker alternative ported to M1 (Apple Silicon) machines

#112

Post by simnalamburt »

traverseda wrote: post #101
simnalamburt wrote: post #66

Hi, podman-apple-silicon developer here! I want to share some FAQs about this project. :) Q: Does this run amd64 docker images or aarch64 docker images? A: aarch64 images currently, but I'm going to patch podman to make it possible to run both amd64 image and aarch64 image. All I have to do for this is to make QEMU call and Linux image configurable, so it won't be very hard. However, if you are running amd64 images,…

> 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 the linux image when you change the CPU arch. Currently, podman always downloads the Linux image whose CPU arch is same with host’s CPU arch. This is where configuration should be added.

3. aarch64 uses UEFI while amd64 don’t need to (I don’t know why)

Re: Podman, the open source Docker alternative ported to M1 (Apple Silicon) machines

#113

Post by cmeacham98 »

Thaxll wrote: post #92
infogulch wrote: post #6

Tangentially, I wonder if Moby underestimated the amount of human hours that were instantly allocated to alternatives as soon as they announced Docker Desktop was going paid. (I don't know if this project is a consequence of that announcement or not.) Hopefully Podman will be able to capitalize on this event and get the polish needed for widespread use.

Most people don't care about Podman and will keep using Docker. There is no alternative on Windows so how exactly podman is a replacement? Also I don't trust Red Hat / IBM with the CentOS fiasco.

Not everyone has to use the same tool. Even if you continue to use only docker, podman helps you by competing with docker and driving them to improve their software (ex: cgroupsv2).

Also, I believe podman works in WSL with some tweaks.

Re: Podman, the open source Docker alternative ported to M1 (Apple Silicon) machines

#115

Post by alibarber »

awild wrote: post #89

I'm curious every post on podman had a very positive thread. We were kinda forced to use podman and while we enjoy rootless containers conceptually they have caused us a lot of issues. After every restart of a node when a user had pods running, said user will not be able to use podman. Often times, bugs can only be solved by completely resetting your user. It's also not as straightforward to configure as the document…

Podman does rely on a lot of files in the /tmp/run-... directory and this has caused us some similar issues. There was some info somewhere on how to change this to somewhere more suitable.

Sorry it's not too helpful, but might be some clues for you.

Re: Podman, the open source Docker alternative ported to M1 (Apple Silicon) machines

#116

Post by WhyNotHugo »

Thaxll wrote: post #92
infogulch wrote: post #6

Tangentially, I wonder if Moby underestimated the amount of human hours that were instantly allocated to alternatives as soon as they announced Docker Desktop was going paid. (I don't know if this project is a consequence of that announcement or not.) Hopefully Podman will be able to capitalize on this event and get the polish needed for widespread use.

Most people don't care about Podman and will keep using Docker. There is no alternative on Windows so how exactly podman is a replacement? Also I don't trust Red Hat / IBM with the CentOS fiasco.

FWIW, docker itself doesn't run on Windows either -- you have to run docker on Linux on Windows.

You can do the same thing for podman: run podman on Linux on Windows.

Probably the link on this very article is a good starting point for doing that.

Re: Podman, the open source Docker alternative ported to M1 (Apple Silicon) machines

#117

Post by detaro »

WhyNotHugo wrote: post #116
Thaxll wrote: post #92

Earlier quoted context omitted.

Most people don't care about Podman and will keep using Docker. There is no alternative on Windows so how exactly podman is a replacement? Also I don't trust Red Hat / IBM with the CentOS fiasco.

FWIW, docker itself doesn't run on Windows either -- you have to run docker on Linux on Windows. You can do the same thing for podman: run podman on Linux on Windows. Probably the link on this very article is a good starting point for doing that.

Docker Desktop can run Windows Containers (or a Linux VM to run Linux containers).

Re: Podman, the open source Docker alternative ported to M1 (Apple Silicon) machines

#118

Post by awild »

michaelcampbell wrote: post #93
awild wrote: post #89

I'm curious every post on podman had a very positive thread. We were kinda forced to use podman and while we enjoy rootless containers conceptually they have caused us a lot of issues. After every restart of a node when a user had pods running, said user will not be able to use podman. Often times, bugs can only be solved by completely resetting your user. It's also not as straightforward to configure as the document…

> bugs can only be solved by completely resetting your user. What does "resetting your user" mean?

I meant user config sorry.

Re: Podman, the open source Docker alternative ported to M1 (Apple Silicon) machines

#119

Post by vetinari »

foxpurple wrote: post #94
infogulch wrote: post #33

Earlier quoted context omitted.

I hadn't heard about CGroupsV2. Apparently it's been in the kernel since 2015. Seems like a better design. https://thenewstack.io/linux-cgroups-v2-brings-rootless-cont... https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2...

Every distro had it turned off for ages because turning it on would break docker. So eventually fedora decided docker was never going to added it and turned it on anyway. Then shortly after, docker adds support

Between fedora and docker, it didn't help, that docker made a first release for current fedora version always about a month before fedora was going to make a new release (i.e. with fedora's 6 month release cycle, the corresponding docker release for that fedora version was 5 months late).

Re: Podman, the open source Docker alternative ported to M1 (Apple Silicon) machines

#120

Post by wernerb »

junon wrote: post #54
kbenson wrote: post #25

Earlier quoted context omitted.

I think a really big part of it was where Red Hat asked Docker to accept their patch that allowed people to run docker with local registries only (no docker.io), and were told Docker would not be accepting that patch, and to go pound sand if they didn't like it (eh, so maybe not so forcefully). The first thing I tried to figure out when looking into Docker for work was how to limit the registries it would look at to…

Docker does this a lot. For example, we were trying to turn off gzipping images on the wire when pulling because it actually cost more when done from the intranet. You can't. And modifying the source was so convoluted that we gave up. Then we needed to clean up docker (before there were commands to do that) when it started to eat up all of the disk space. To our (un)surprise, Docker uses 3 (!!) different storage form…

I am honestly wondering more about your specific use case. Does the CPU cost outweigh the storage cost? Is it a timing problem (speedup) or are you at such large scale (on premise)?

Maybe where I'm getting at is, I can think of 99 problems but docker gzip ain't one :) how was this a priority (at some point)

Post reply on HN