[HN Gopher] Podman, the open source Docker alternative ported to...
       ___________________________________________________________________
        
       Podman, the open source Docker alternative ported to M1 (Apple
       Silicon) machines
        
       Author : pcr910303
       Score  : 453 points
       Date   : 2021-09-06 02:25 UTC (20 hours ago)
        
 (HTM) web link (github.com)
 (TXT) w3m dump (github.com)
        
       | nsonha wrote:
       | Idk why people keep pushing for this, on a personal dev machine,
       | root is not a problem, and then there is QEMU
        
         | simnalamburt wrote:
         | The main motive for me to make podman-apple-silicon was due do
         | Docker Desktop's pricing model change.
        
         | denkmoon wrote:
         | I think you'd be surprised how often the route from dev to prod
         | is "copy it from my machine into the cloud".
         | 
         | Good practices start at home.
        
           | eru wrote:
           | Well, it's also a good practice the other way round:
           | 
           | If you can make your dev setup model the production setup,
           | that's one less thing to worry about.
        
             | goodpoint wrote:
             | That's what VMs are for.
        
           | nsonha wrote:
           | it's docker that requires root, you don't use root yourself
        
         | [deleted]
        
         | stavros wrote:
         | It certainly is a problem. We want to run local development
         | stacks with Docker, but, since it runs as root, it leaves files
         | into your home directory (database and other files mounted from
         | the guest) that are owned by root, so you can never delete
         | them.
         | 
         | It's really bad UX.
        
           | nickjj wrote:
           | If you create a user inside of your Dockerfile and switch to
           | that your files will be owned by whoever is assigned to
           | uid:gid 1000:1000 on your dev box if you use a volume mount.
           | This solves the problem in nearly every case because your
           | primary dev box user is almost always going to be 1000:1000.
           | It'll work on native Linux, Windows (WSL) and macOS using
           | Docker Desktop or not.
           | 
           | Here's a bunch of complete web app examples of it working: ht
           | tps://github.com/nickjj?tab=repositories&q=docker-*-exampl...
        
             | stavros wrote:
             | Oh, good call, I wasn't doing this because 1000 is not
             | always the user uid, but it's almost always, and at worst
             | you'll need root to delete the files, thanks!
        
           | hda111 wrote:
           | Rootless Podman does this as well but with the subuid owned
           | files. For instance you run postfix in a container and it has
           | files owned by postfix. You can't change the files outside of
           | the container. You can make yourself root in the namespace
           | and delete with podman unshare however. But it isn't optimal
           | from UX perspective either.
        
           | wiredfool wrote:
           | Home directory, /etc, or /root/.ssh/authorized_keys,
           | depending on what arguments you pass to -v.
        
       | OneTimePetes wrote:
       | Is the name a Blindsight reference?
        
       | sdze wrote:
       | What hypervisor is used for that?
        
         | simnalamburt wrote:
         | QEMU with Hypervisor.framework patch has been used!
        
       | mdoms wrote:
       | Podman, the open source alternative to the open source parts of
       | Docker. To be clear.
        
         | slimsag wrote:
         | This looks more like the Podman version of Docker Desktop
         | (which is closed source, and no longer free), effectively, as
         | it's handling the virtualization aspects for you according
         | to[0].
         | 
         | [0] https://twitter.com/simnalamburt/status/1434244533001224192
        
           | zapita wrote:
           | The Docker CLI is also available for Mac, and is open-source.
        
             | dolmen wrote:
             | 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.
        
             | slimsag wrote:
             | Does that handle virtualization for you like this does? Is
             | it distributed pre-built anywhere?
             | 
             | I honestly looked just now and couldn't find anything.
        
               | stavros wrote:
               | I would be surprised if it didn't, as Docker wouldn't
               | work at all then.
        
               | j16sdiz wrote:
               | It doesn't.
               | 
               | That is part of the "Docker Desktop" offer, which is non-
               | free.
        
               | stavros wrote:
               | I just heard (from another commenter), that's dire. I'm
               | stunned.
        
       | simnalamburt wrote:
       | 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, you will have to bear the performance
       | overhead due to CPU emulation.
       | 
       | Q: Is this toy or are you actually going to maintain this?
       | 
       | A: I'm DevOps engineer and I made podman-apple-silicon to
       | actually use this in my day job.
       | 
       | Q: Are you going to merge this to the upstream?
       | 
       | A: I'll keep trying, but it won't be easy unless QEMU merges Alex
       | Graf's Hypervisor.framework patch.
       | 
       | I may forgot to check HackerNews, so please feel free to ask me
       | anything about podman-apple-silicon at
       | https://twitter.com/simnalamburt
        
         | nickysielicki wrote:
         | Q: What sort of contributions/help are you looking for?
        
         | traverseda wrote:
         | > 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 you from using binfmt?
        
           | simnalamburt wrote:
           | 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)
        
       | awild wrote:
       | 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 documentatiom let's on.
       | 
       | Overall I don't have an opinion on the software, it's just
       | confusing to me how much praise it receives?
        
         | alibarber wrote:
         | 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.
        
         | michaelcampbell wrote:
         | > bugs can only be solved by completely resetting your user.
         | 
         | What does "resetting your user" mean?
        
           | dotancohen wrote:
           | Presumably there is a config file somewhere that is causing
           | issues. Resetting the user might be a way of saying rm -rf
           | /home/someuser. That said, I've never used podman and this is
           | the first that I've heard of it.
        
           | awild wrote:
           | I meant user config sorry.
        
       | zapita wrote:
       | Calling podman "the open-source docker alternative" is
       | disingenuous. The Docker engine which it competes with is also
       | open-source. The only closed Docker product is their desktop
       | wrapper, for which podman is not an alternative.
       | 
       | Podman people, you're better than this.
        
         | brodock wrote:
         | Docker is open-core.
        
           | j16sdiz wrote:
           | Docker Desktop is not
        
         | hda111 wrote:
         | Docker isn't true open source in my opinion. With true open
         | source you can compile your own version of the software with
         | your own changes and it works just like the official release.
         | You can't do this with Docker Engine afaik.
        
         | kodah wrote:
         | 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
        
       | fiddlerwoaroof wrote:
       | Is there anyway to make docker-style Darwin containers?
        
         | kf6nux wrote:
         | The closest you're probably going to get is sandbox-exec
         | https://jmmv.dev/2019/11/macos-sandbox-exec.html
        
         | jamesfinlayson wrote:
         | I don't think Mac/Darwin has cgroups but it's based on BSD to
         | it might have jails?
        
           | yjftsjthsd-h wrote:
           | So my somewhat shaky understanding is that Apple _does_ have
           | some form of jails in Darwin, because they use it on iOS
           | (hence,  "jailbreaking"), but for some reason doesn't ship it
           | in desktop Darwin (aka macOS).
        
             | johncolanduoni wrote:
             | It exists on macOS but doesn't support the mount
             | namespacing you'd need to create something like a docker
             | container on macOS.
        
             | lostlogin wrote:
             | > Apple does have some form of jails in Darwin
             | 
             | Thinking about the names Apple might call this tech is
             | amusing, with their use of 'me' 'I' 'Apple' etc. I assume
             | 'Jail' wouldn't be in the name.
        
               | dotancohen wrote:
               | iSolation
        
             | heavyset_go wrote:
             | As far as I'm aware, macOS' sandbox isn't like the kernel
             | namespaces and cgroups available on Linux.
        
             | Hackbraten wrote:
             | Apple's sandbox focuses on isolating the OS from non-
             | platform binaries. It doesn't have namespaces or cgroups.
             | 
             | Jailbreaking on iOS is mostly about that sandbox. It
             | doesn't relate to BSD jails.
             | 
             | On macOS, Apple made the sandbox more lenient and
             | implemented it a bit differently than on iOS. But both have
             | roughly the same goals. They're also alike in that both use
             | the same kernel-level framework (MACF) to do their job.
             | 
             | But the MACF is completely off-limits to everyone outside
             | Apple. Not even accredited kext developers can use it. So I
             | think that no one except Apple could possibly add
             | container-style isolation to macOS.
        
           | shilch wrote:
           | MacOS doesn't have jails as FreeBSD does. But they are using
           | some kind of isolation for Mac applications, so they can not
           | see data of other applications.
        
           | takeda wrote:
           | A lot of people assume that, but it's only partially true.
           | 
           | Darwin's userland is taken from FreeBSD, the kernel is from
           | NeXTSTEP, although it also borrowed some things from FreeBSD,
           | but I don't think they incorporated jails[1].
           | 
           | [1] https://github.com/apple/darwin-xnu/search?q=jail
        
             | heavyset_go wrote:
             | XNU itself is Mach plus a BSD "personality" taken from
             | FreeBSD[1].
             | 
             | [1] https://developer.apple.com/library/archive/documentati
             | on/Da...
        
         | takeda wrote:
         | I don't see reason why it wouldn't be possible. Windows did
         | just that.
         | 
         | Although at that point having x86_64-linux, x86_64-windows and
         | armv8-darwin would further remove benefits of docker reducing
         | it to a fancy tarball.
        
         | theThreeTuples wrote:
         | Probably should look at https://veertu.com/
        
           | Hackbraten wrote:
           | Are those containers or VMs?
        
             | pcr910303 wrote:
             | They're VMs. It's based on the Hypervisor.framework, so
             | it's actually faster than I thought, but it's VMs.
        
               | easton wrote:
               | Do you know if the VMs have accelerated graphics? The new
               | version of Hypervisor.framework in 12.x supports
               | accelerated macOS guests but I didn't know if they
               | figured out a way to do it without Apple's tricks.
               | 
               | (https://developer.apple.com/documentation/virtualization
               | /vzm... is the best citation I have, unfortuately)
        
       | ur-whale wrote:
       | > the open source Docker alternative
       | 
       | I was under the impression that docker was open source.
       | 
       | I am mistaken?
        
         | slimsag wrote:
         | Docker Desktop (the software people must use to run Docker
         | under any Mac or Windows machines) is closed source.
        
           | scandinavian wrote:
           | You can run docker on Windows without Docker Desktop. I think
           | the only thing that requires Docker Desktop on windows is if
           | you want windows containers, but I don't really think that's
           | a common usecase.
        
             | pjmlp wrote:
             | It is a common use case for .NET deployments with
             | Kubernetes.
        
             | chupasaurus wrote:
             | You can do the same thing for native containers by setting
             | up Server Core VM with Docker Engine and the client on
             | host.
        
             | easton wrote:
             | Or if you want to share folders from Windows into Linux
             | containers (you can do it via /mnt/c/ but it's a little
             | more complicated).
        
           | The_Colonel wrote:
           | ... and podman is not an alternative for Docker Desktop.
        
             | slimsag wrote:
             | ... sure seems like it is: this handles QEMU setup/teardown
             | with hardware virtualization support through
             | Hypervisor.framework according to[0].
             | 
             | [0]
             | https://twitter.com/simnalamburt/status/1434244533001224192
        
               | stavros wrote:
               | Doesn't Docker proper do that on Mac?
        
               | dolmen wrote:
               | AFAIK the Docker engine (that allows to run containers)
               | isn't available for Mac independently of Docker Desktop.
               | 
               | At least binaries are not provided.
               | https://docs.docker.com/engine/install/binaries/
        
               | stavros wrote:
               | 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.
        
               | dotancohen wrote:
               | 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.
        
               | stavros wrote:
               | Well, work has to get done...
        
       | jedahan wrote:
       | I made a dumb shell script alternative to Docker Desktop. works
       | on M1, fork unneeded. Uses multipass and podman.
       | 
       | https://github.com/jedahan/podman-desktop
        
       | nsonha wrote:
       | I'm not on M1 so QEMU kind of puts me off . Is there a way to use
       | this with any of hyperkit, virtualbox, or vmware?
        
         | imwillofficial wrote:
         | Trust me, learn QEMU, worth the time.
        
           | nsonha wrote:
           | how do you mean learn it? So far I've only used these as
           | drivers to run other things so my only concern is that QEMU
           | is supposed to be slow. I don't really do anything directly
           | with it.
        
             | imwillofficial wrote:
             | My mistake, I took your usage of QEMU as a shorthand for
             | managing and manipulating VMs, and wanting to use VMware et
             | al due to not wanting to use the "QEMU ecosystem"
        
       | symlinkk wrote:
       | Why is HN shilling this so hard? This feels so forced.
        
       | lox wrote:
       | This looks like the podman client, effectively? Has anyone gotten
       | `podman machine` working on M1?
        
         | simnalamburt wrote:
         | One of the main reason that I made podman-apple-silicon was to
         | make `podman machine` work properly. It works!
        
         | kenada wrote:
         | `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
        
           | simnalamburt wrote:
           | The current version of podman-apple-silicon uses "testing-
           | devel" version of official Fedora CoreOS aarch64.
        
       | athorax wrote:
       | Linking to the homebrew installer for this is an...odd... Choice.
       | Never the less, congrats podman devs!
        
         | pcr910303 wrote:
         | 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
         | 
         | [1]: https://github.com/simnalamburt/podman
        
       | whckt wrote:
       | Very nice! I'm keen to do away with the VirtualBox on my current
       | Intel when I make the transition to M1.
        
       | phinnaeus wrote:
       | 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.
       | 
       | Edit: It works. Had a bit of trouble since I wanted to uninstall
       | the "real" QEMU first, but `lima` still depended on it, and then
       | installing the patched QEMU needed to update the version of
       | `lima` I had installed, which then tried to reinstall QEMU, which
       | failed because of some symlinks which were now owned by the
       | patched QEMU...
        
         | gizdan wrote:
         | TIL of nerdctl. Anyone know what the differences between
         | nerdctl and podman are?
        
         | kitd wrote:
         | OT, but I'm impressed you managed to make all those changes
         | within the HN-comment-edit-timeout!
        
         | piaste wrote:
         | > 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 Raspberry Pi 4B homeserver and I would have used podman
         | for improved security, were it not for the poor/incomplete
         | Compose support, while nerdctl seems to explicitly support it.
        
       | whimsica1 wrote:
       | Anyone tried this? How's the performance compared to Docker
       | Machine in Mac (notoriously slow on storage).
        
         | initplus wrote:
         | I assume it's pretty slow, not on storage but on compute. x86
         | docker/podman on M1 must use QEMU software emulation, rosetta
         | doesn't support x86 virtualization.
        
           | vbezhenar wrote:
           | Why do you think that it uses x86? I assume that it just runs
           | ordinary ARM linux in VM which just works (I also don't
           | really understand this title post, surely podman worked on
           | ARM linux since the beginning).
        
           | slpnix wrote:
           | Behind the scenes, it's using QEMU with Alex Graf's patches
           | for hvf (Hypervisor.framework) support, so it's
           | Virtualization, not emulation. In other words, the
           | performance is really good ;-)
           | 
           | BTW, in case you don't want to depend on a fork, upstream
           | podman is going to gain M1 support (in the sense of 'podman-
           | machine' knowing how to start aarch64 VMs with hvf) _very_
           | soon.
        
       | infogulch wrote:
       | 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.
        
         | alibarber wrote:
         | Podman's been a great tool (on Linux) for a while, it's my
         | daily driver. Rootless, no daemon and networking nonsense, and
         | docker-compose can be replaced with real K8s pod definitions
         | for the most part. I'm actually really happy to see the zeal
         | that has come to it from docker's changes - thank you docker ;)
        
           | alias_neo wrote:
           | > docker-compose can be replaced with real K8s pod
           | definitions for the most part
           | 
           | Could you elaborate on this part? Are you running in
           | Kubernetes or somehow using the pod definition format with
           | Podman? I'd like a way to declaratively specify my Podman
           | pods without docker-compose and friends.
        
             | gizdan wrote:
             | Podman has built in support for K8s' Pod definitions. I've
             | never used it so not sure how good (or bad) it is, but it
             | is possible.
             | 
             | It is also able to generate pod definitions from created
             | containers, as well as generate systemd units that you can
             | then enable allowing systemd to manage your
             | pods/containers.
        
               | alias_neo wrote:
               | Incredible, I didn't know any of this and I've been using
               | Podman for ~1 year.
               | 
               | Thanks, some reading for me to do, will be testing both
               | those features out imminently!
        
             | TobTobXX wrote:
             | There's also podman-compose, which does exactly what
             | docker-compose does, but with podman.
        
               | gizdan wrote:
               | podman-compose is sadly not as good docker-compose. It
               | simply converts compose yaml files into podman commands.
               | 
               | As an alternative, as of podman v3 (rootfull) and v3.2
               | (rootless) podman has an optional podman socket you can
               | enable. The API is docker compatible, thus allows for
               | full docker-compose support, and will take any other
               | application that interacts with the docker api directly.
        
         | SilverRed wrote:
         | I suspect the push for podman was more about how docker ignored
         | CGroupsV2 for so long that Fedora eventually turned it on
         | anyway which broke docker and then told users to switch to
         | podman.
        
           | cozzyd wrote:
           | And EL8 for that matter
        
           | kbenson wrote:
           | 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 only be our own when used in production, and I was
           | surprised to find out you can't (at least not without a hack
           | to make it think it's using a mirror and just hitting your
           | registry first).
        
             | infogulch wrote:
             | 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.
        
               | kbenson wrote:
               | I believe that was acknowledged in some of the pull
               | requests, and also a problem with correctly using
               | credentials for repositories and various solutions were
               | proposed (see one of my other comments for links).
               | Ultimately, the reason given in the pull requests I saw
               | was along the lines of "it will fracture the namespace
               | and hurt the community".
               | 
               | Disabling all registries except for those whitelisted and
               | requiring full names for those would probably have been
               | sufficient for this problem, and not fractured the
               | community IMO. There's a difference between what you
               | allow in dev and what you allow in production, where you
               | should have a chance to vet all new requirements and
               | ensure they are appropriate. It's just unacceptable for
               | some organizations to allow stuff to be as ad hoc as
               | that, as much as Docker might want to inject itself into
               | their processes at that level.
        
               | light_hue_1 wrote:
               | 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.
        
               | infogulch wrote:
               | 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.
        
             | intsunny wrote:
             | Fascinating history, is there a PR link for this exchange
             | between Redhat and Docker?
        
               | kbenson wrote:
               | 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 in the second link that's references in
               | the first one that explains the rationale for the pull
               | request refusal:
               | 
               |  _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 full comment at https://github.com/moby/
               | moby/issues/11816#issuecomment-86732..., and it also
               | references that this will be possible with signed images,
               | so I don't know what happened after that (but that was
               | over 6 years ago).
        
               | SSLy wrote:
               | https://github.com/moby/moby/issues/1988#issuecomment-271
               | 402...
        
             | junon wrote:
             | 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
             | formats, many of them having redundant information, and
             | editing one of them would cause the other to be corrupted.
             | 
             | One was a binary database format that was specific to Go
             | and didn't have any utility CLI to work with, so you had to
             | write a programmatic interface with it just to edit it.
             | 
             | Or how about the fact that even if you issue commands
             | directly to docker over the HTTP Unix socket, it will
             | deadlock if you issue too many commands to it? This became
             | our nightmare when trying to implement one of the first
             | iterations of custom deployment backends at ZEIT. In fact,
             | the entire project failed because of docker (there was no
             | great alternative at the time).
        
               | wernerb wrote:
               | 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)
        
               | junon wrote:
               | As we were a deployment company (ZEIT) our usecase was
               | quite different.
               | 
               | And yes, as the other person mentioned, it was _on the
               | wire_ GZIP, not storage concerns.
        
               | infogulch wrote:
               | Pretty sure it's CPU vs network not CPU vs storage. A
               | fast internal network can be cheap compared to the cpu
               | required to pack/unpack images on every download. I
               | wonder if choosing a fast-to-decompress algorithm like
               | zstd would change that.
        
           | infogulch wrote:
           | 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...
        
             | foxpurple wrote:
             | 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
        
               | vetinari wrote:
               | 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).
        
         | Thaxll wrote:
         | 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.
        
           | cmeacham98 wrote:
           | 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.
        
           | WhyNotHugo wrote:
           | 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.
        
             | detaro wrote:
             | Docker Desktop can run Windows Containers (or a Linux VM to
             | run Linux containers).
        
         | DocTomoe wrote:
         | Moby has the power of using a well-established name ("I want to
         | have Docker on my desktop, let's google that, oh, hi Docker
         | Desktop!") that also appears in a lot of tutorials and training
         | material, both aspects that developers tend not to spend time
         | on.
         | 
         | Given how often I still stumble over massively obsolete
         | documentation and "helpful" articles from 15 to 20 years ago,
         | I'd say they are safe.
        
           | hda111 wrote:
           | They are as safe as MySQL is
        
             | dotancohen wrote:
             | Safe as Open Office is probably a better analogy. MySQL is
             | still very widely deployed. But, yes, your point is very
             | apt!
        
       | pojzon wrote:
       | Demn after Docker Desktop announcment this podman gets posted
       | almost daily on HackerNews.
       | 
       | I understand its a good moment do advertise, but good tools
       | happen to advertise themselves.
        
         | stavros wrote:
         | > good tools happen to advertise themselves.
         | 
         |  _Nothing_ advertises itself. People advertise things, by
         | posting about them.
        
       | qwerty456127 wrote:
       | Planning to buy a new MacBook for a family member I have some
       | question to whoever is into the Apple wold: is that true that the
       | next generation of MacBooks is going to have classic Esc&F#
       | buttons, MagSafe, SD card reader and HDMI? When is it expected to
       | be released? How is a MacBookPro better than a MacBookAir of the
       | same specs (RAM&SSD)? We were going to buy a new MacBook now but
       | the classic parts returning sound really motivating to wait.
        
         | konradkpl wrote:
         | We don't know anything for sure, only rumors:
         | https://www.macrumors.com/guide/14-inch-macbook-pro/
        
           | qwerty456127 wrote:
           | Thank you. This answer all the questions except the Pro-vs-
           | Air difference.
        
             | konradkpl wrote:
             | The current macbook pro 13 with M1 does not differ
             | significantly from the macbook air m1:
             | https://9to5mac.com/2021/09/01/m1-macbook-air-
             | vs-m1-macbook-... . You have one core more and active
             | cooling with fan, but in daily use it is difficult to
             | generate the load that will trigger this cooling. The
             | situation will definitely change with the new Macbook Pro
             | 14/16 to be shown in October or November.
        
         | lucian1900 wrote:
         | The only difference between the current Pro and Air is that the
         | latter can thermal throttle.
         | 
         | I got the Air and I have managed to make it throttle while
         | running x86 games. However, it wasn't by much. The games
         | remained playable.
         | 
         | Overall, it's great. Very fast and entirely silent.
        
           | qwerty456127 wrote:
           | You mean Pro can not throttle even when you want it to? It
           | sounds nice to have a full power at my disposal when I
           | actually want it but most of the time I want a laptop to run
           | near its minimum power to prevent heating, avoid noise and
           | save battery. Even when I run a computation-heavy task I
           | still want to be able to force it to run slowed-down and take
           | its time. Is this not possible with Pro? Even with 3-rd party
           | tools?
        
             | lucian1900 wrote:
             | Based on what people that have both say, when the Air would
             | throttle the Pro's fans become slightly audible.
             | 
             | I also prefer the design of the Air, so it was an easy
             | choice for me.
        
               | qwerty456127 wrote:
               | I see. I personally am a PC user and I have a habit of
               | controlling the throttle manually (it's not necessary but
               | easy and handy). I have been doing this for almost 20
               | years, using handy 3-rd party panel applets and system's
               | (both Linux and Windows) built-in tools. So I'm surprised
               | to learn MacBooks still don't allow manual throttle
               | control. I usually prefer to keep my thermal regime below
               | of what the vendors pre-define.
        
               | lucian1900 wrote:
               | All intel MacBooks I've used allowed controlling the fans
               | manually, at least.
               | 
               | It's not relevant for the M1 Air since it has no fans, of
               | course.
        
               | qwerty456127 wrote:
               | I don't mean controlling the fans. I mean voluntarily
               | throttling down the frequency of the CPU (and telling it
               | it should not up-throttle even when the load goes high)
               | so the computer actually stays cold even without the
               | fans.
        
               | lucian1900 wrote:
               | Sure, you could do that too at least on Intel ones.
               | Generally it makes sense to do it indirectly with the
               | fans.
               | 
               | It's really not needed on the M1. The only time my Air
               | got warm was in a game.
        
       ___________________________________________________________________
       (page generated 2021-09-06 23:02 UTC)