Live data from Hacker News

Podman: A Daemonless Container Engine

podman.io

201–210 of 250 posts

Re: Podman: A Daemonless Container Engine

#201
post #200

Earlier quoted context omitted.

I could very well be wrong but Podman seems to have missed the time-frame of opportunity. It was always a knife fight between Red Hat and Docker with regard to tooling. Red Hat wanting to own the toolchain for containers so they didn't have to deal with, and so they could box out, competitors like (now basically defunct) Docker Enterprise. I've taken a look at podman from time to time over the years but it seems like…

> Red Hat wanting to own the toolchain for containers so they didn't have to deal with This is a misrepresentation. The situation was that Docker didn't take patches, as some were very specific changes for systemd and lack of unionfs, etc but over time it applied to most patches from RH associated people.

I'm not sure that's entirely true. If you look at the history of container tooling, all of the FUD Dan Walsh used to spread and Red Hat pulling support for Docker packages on RHEL I believe what was stated to be fairly accurate.

Edit: You also may have different perspective given you work for Red Hat / IBM.

Re: Podman: A Daemonless Container Engine

#202
post #73
post #13

It is almost 100% compatible with docker. I only had to do minimal changes in my Dockerfiles to use it.

But not Buildkit and docker-compose.

Podman v3 is compatible with docker-compose (but not yet swarm mode, FWIU), has a socket and a daemon that services it.

Buildah (`podman buildx`, `buildah bud --arch arm64`) just gained multiarch build support; so also building arm64 containers from the same Dockerfile is easy now. https://github.com/containers/buildah/issues/1590

IDK what BuildKit features should be added to Buildah, too?

Re: Podman: A Daemonless Container Engine

#203
I was a big fan of Podman and switched to it wholeheartedly[0][1] but after a while I ran into a few issues that made me have to switch off of it and back to docker:

- image unpacking issues (invalid tar header)

- linking containers isn't supported

[EDIT] - I wrote up the post real quick[2]

[0]: https://vadosware.io/post/rootless-containers-in-2020-on-arc...

[1]: https://vadosware.io/post/bits-and-bobs-with-podman/

[2]: https://vadosware.io/post/back-to-docker-after-issues-with-p...

Re: Podman: A Daemonless Container Engine

#204
post #198
post #172

Earlier quoted context omitted.

It feels weird that a containerisation technology imposes requirements on the underlying storage technology to work well, tho. Now I understand that btrfs is not really a requirement. But I've been thinking about using podman to replace docker-in-docker on our fleet of gitlab runners where we build our images, and running btrfs is a deal breaker. We really don't want to add complexity to the mix. Fuse-overlay burning…

>It feels weird that a containerisation technology imposes requirements on the underlying storage technology to work well, tho. Why? Storage is literally the backbone of technology. From databases to webservers there are unique and real requirements. There's a reason why the enterprise storage market is still worth several billion dollars, and it's not because storage is easy. In 2021, with billions of dollars of R&D…

Are you sure Amazon, Google and Microsoft don't have this competitive stack because they don't want to enter that market or are in that market solely for themselves? Storage may be a multi-billion dollar market - but it's also razor thin margin compared to where those brands focus their R&D spend. I'd argue those you've named don't have interest selling storage to the enterprise in the form of legacy boxes. They make far more revenue leasing storage to the enterprise. Cloud storage is also recurring revenue where enterprise storage is considered perpetual. The latter is generally frowned upon from the Street's perspective these days (good, bad or otherwise).

Re: Podman: A Daemonless Container Engine

#205
post #198

Earlier quoted context omitted.

>It feels weird that a containerisation technology imposes requirements on the underlying storage technology to work well, tho. Why? Storage is literally the backbone of technology. From databases to webservers there are unique and real requirements. There's a reason why the enterprise storage market is still worth several billion dollars, and it's not because storage is easy. In 2021, with billions of dollars of R&D…

Are you sure Amazon, Google and Microsoft don't have this competitive stack because they don't want to enter that market or are in that market solely for themselves? Storage may be a multi-billion dollar market - but it's also razor thin margin compared to where those brands focus their R&D spend. I'd argue those you've named don't have interest selling storage to the enterprise in the form of legacy boxes. They make…

>Are you sure Amazon, Google and Microsoft don't have this competitive stack because they don't want to enter that market or are in that market solely for themselves

They have "competition" in the market, it's just horrible. Because storage is hard.

>Storage may be a multi-billion dollar market - but it's also razor thin margin compared to where those brands focus their R&D spend.

I'm going to let you go back and review the earnings reports from the aforementioned companies. Razor thin margins? You wouldn't survive in the market with razor thin margins.

> I'd argue those you've named don't have interest selling storage to the enterprise in the form of legacy boxes.

I'd argue Azure Stack, AWS Outpost, and Google Anthos readily prove you wrong.

> Cloud storage is also recurring revenue where enterprise storage is considered perpetual.

Just... no. Enterprise storage has a shelf life of 3-5 years before maintenance or technology make it obsolete.

>The latter is generally frowned upon from the Street's perspective these days (good, bad or otherwise).

https://www.google.com/finance/quote/NTAP:NASDAQ

5 years ago they were at $20/share, today they're at $69/share. Reality doesn't appear to match your claim as to the street's opinion of enterprise storage.

Re: Podman: A Daemonless Container Engine

#206
post #124

Earlier quoted context omitted.

Oh, I agree it is a tradeoff. But the parent said "you can learn to miss every time". Can anyone point me to a C language project where the developers consistently miss every time?

Are you saying that every project written in C has suffered from a memory leak issue at some point? Most C/C++ code I've personally written doesn't even use the heap. I work on avionics and we use C/C++ now and then. We have a ton of rules regarding memory management (pretty much everything stays on the stack) and I can't recall anything I've ever been involved with suffering from a memory leak.

If basically everything stays on the stack, you’ll have a much lower chance of seeing a memory leak, by definition.

Re: Podman: A Daemonless Container Engine

#207
post #205

Earlier quoted context omitted.

Are you sure Amazon, Google and Microsoft don't have this competitive stack because they don't want to enter that market or are in that market solely for themselves? Storage may be a multi-billion dollar market - but it's also razor thin margin compared to where those brands focus their R&D spend. I'd argue those you've named don't have interest selling storage to the enterprise in the form of legacy boxes. They make…

>Are you sure Amazon, Google and Microsoft don't have this competitive stack because they don't want to enter that market or are in that market solely for themselves They have "competition" in the market, it's just horrible. Because storage is hard. >Storage may be a multi-billion dollar market - but it's also razor thin margin compared to where those brands focus their R&D spend. I'm going to let you go back and rev…

First, if you review the financials of the storage companies compared to earnings of all cloud companies they're abysmal.

Yes, razor thin margins - comparatively. The cost of buying physical storage is commoditized. I've worked in technology from the pre-sale engineering side for a number of years. Margins on hardware are fractional compared to software and subscription offerings.

Stack, Outpost and Anthos are not revenue drivers today. They're vendor lock in tools.

3-5 years is a horrible argument in the position you're attempting to make considering it's an eternity in technology. Consider that you sell the storage once in that 3-5 years. Your cloud provider bills you monthly and you don't own it. It's recurring revenue vs a singular sales event.

NTAP over 5 years is a decent return. 215% over that timeframe. Amazon returns 543% in the same timeframe. And let's use a hot space that's 100% subscription based, like Crowdstrike: 265% in less than a year. Software and subscription margins crush the legacy perpetual hardware model.

Storage is an old, stable, and commoditized market. There's no huge growth (any storage earnings report show that very clearly). And while the demand for storage continues to increase, the NetApps of the world aren't capturing where that growth is.

Re: Podman: A Daemonless Container Engine

#208
post #165
post #158

Earlier quoted context omitted.

> Excellent question, especially since the code is copy-pasted without crediting the original authors. That seems like a serious allegation. Can you back that up?

It’s right there in the repo history. Start from the first commits. I don’t know how serious of an allegation it is: copy-pasting open-source code without crediting it properly is rude, but not illegal.

No, that’s totally illegal. The Docker Engine is licensed under the Apache-2.0 terms, which require attribution.

Re: Podman: A Daemonless Container Engine

#209
post #205

Earlier quoted context omitted.

>Are you sure Amazon, Google and Microsoft don't have this competitive stack because they don't want to enter that market or are in that market solely for themselves They have "competition" in the market, it's just horrible. Because storage is hard. >Storage may be a multi-billion dollar market - but it's also razor thin margin compared to where those brands focus their R&D spend. I'm going to let you go back and rev…

First, if you review the financials of the storage companies compared to earnings of all cloud companies they're abysmal. Yes, razor thin margins - comparatively. The cost of buying physical storage is commoditized. I've worked in technology from the pre-sale engineering side for a number of years. Margins on hardware are fractional compared to software and subscription offerings. Stack, Outpost and Anthos are not re…

>First, if you review the financials of the storage companies compared to earnings of all cloud companies they're abysmal.

I'm sorry but you're just flat out wrong and didn't bother to look up margins like I suggested you do.

NTAP 2020 margins: 66% https://www.macrotrends.net/stocks/charts/NTAP/netapp/gross-...

AMZ 2020 margins: ~41% https://www.macrotrends.net/stocks/charts/AMZN/amazon/profit...

An all time high... and not even close.

>Storage is an old, stable, and commoditized market.

Which is why... per my original post... the cloud providers struggle to provide basic features in 2021 that have been available to enterprise storage customers for 20+ years.

Re: Podman: A Daemonless Container Engine

#210
post #88

Earlier quoted context omitted.

One huge advantage over docker is that if you mount a directory into the container, and the container writes files there, on the host system they always have the owner of the user that started the container. That makes it much more convenient for build environments, without having to hard-code user IDs both in the container and on the host.

If you're on a Linux system you can actually make this work better with sssd. So sssd's architecture is actually client-server over a unix socket. So all you need to do is create a very simple base container layer that just installs sssd-client, and wires up /etc/nsswitch.conf to use it (your package manager will almost surely do this automatically). Then just bind mount the sssd socket into your container and boom,…

This is glorious and just the thing I was looking for. I am trying to move towards an even more container based dev environment, basically shell into long running containers. Maybe even window manager in docker .

Totally eliminates dependency hell, e.g. ROS heavy workflows where it wants to control every part of your environment.

Post reply on HN