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

Podman: A Daemonless Container Engine

podman.io

Post reply on HN
Print view View original

241–250 of 250 posts

Re: Podman: A Daemonless Container Engine

#241

Post by archi42 »

doliveira wrote: post #230
archi42 wrote: post #227

Earlier quoted context omitted.

C++. And it's no problem :) I don't need privileged ports, and I don't need write access to the OS. Only thing that annoyed me was when I did some work on an internal web tool (php+js) and had no php-fpm & httpd. But by now I've got a container for that.

Well, I suppose if your dependencies are very locked down it might work in C++. I would guess, though, that having to change the prefix and default locations in all tarballs you download must be quite a pain. You can't install DEBs or any other tools either?

We have all deps in gits. A build tool takes care of everything. I get all necessary source gits checked out, configured (e.g. change prefix) and built. If I change something (which is my job), rebuilding is just a 'make' away; and rebuilds only the changed parts. Pretty frictionless and painless.

We use some external stuff like sqlite, qt,... but that's all versioned in our gits as well (-> easily reproducible builds). Since we sell a commercial product we can't just add random deps anyway. Plus, I think there is very little code that would benefit from being replaced by an external libs.

Relevant tools are on a global package list. We can get stuff added there on a short notice, and with little questions asked. Eg when I needed some lib for a FPGA dev kit that was a matter of minutes.

Uaaah, Firefox on Android is messing up the input again (can only append, not edit). I guess I should just hit that "reply" button then).

Re: Podman: A Daemonless Container Engine

#242

Post by archi42 »

mekster wrote: post #233
kohlerm wrote: post #107

Earlier quoted context omitted.

In big companies there isn't always a good justification for a restriction ;-)

With no courage to voice a concern, it's your problem to be strangled by such limitations or there's actually a valid concern that you're not aware of.

Queue "you don't know me" ;) if I was strangled, I would voice concern very much. But as noted several times, everything is setup so that we never need root. The only thing that was an issue, was docker for about a year (we used chroot before that). That's why I had the sysadmin install podman (no discussion necessary) and why I build a wrapper for super easy usage (which is globally available now).

And please note that getting a CI like env is usually not necessary. I only need that exact env to prebuild things that should run in the CI, e.g. target-specific GCCs. And we can't upgrade the CI because some customers pay good money to have our product run on ancient Linux versions (safety critical industries, once something is certified, you use it a looooong time).

Re: Podman: A Daemonless Container Engine

#243

Post by pdimitar »

archi42 wrote: post #228
pdimitar wrote: post #192

Earlier quoted context omitted.

I'm intrigued that you must run Manjaro and kind of want work with you because of it. :) Manjaro is great. Best Linux experience I've had so far. It's good that people recognize it.

It's just great. But I also like Arch@home.

I tried Arch but they are a bit too trigger-happy with the rolling releases and this has caused problems for me in the past.

I recognize it's a minor pet peeve and would not try to convince anyone though. It's just that I found Manjaro's release policy more to my liking (and unwillingness to fix a broken installation which granted, was easy every time yet took time nonetheless).

Re: Podman: A Daemonless Container Engine

#245

Post by archi42 »

mekster wrote: post #232
archi42 wrote: post #106

Earlier quoted context omitted.

With root it's easy to mess up the system badly ("I'll just fix that small error") and/or let all systems slowly diverge. And if something fails on my workstation, it will fail on many others as well and needs a coordinated solution. Also, giving every dev root is a security liability, especially when there is absolutely no work reason that requires us to become root. So only a few "core IT" people have root access.…

It's only because your environment is fragile running stuff on metal instead of in a virtual environment. Why not just give everyone an isolated space on a server with stuff like systemd-nspawn and let people do whatever they want including using docker inside and if they've screwed up, that's 1 lesson for them and redeploy his environment from a daily backup of the entire space or from a base image quickly.

I gave your post some thought, but there is not too much I can really say. You throw around some conclusion/assertion ("it's fragile"), but that's just plain wrong. And then you propose a perceived solution for that non-problem ("put people on sliced servers") even though our workloads are poorly suited for that AND that's mostly orthogonal to the stated "problem" to begin with.

Re: Podman: A Daemonless Container Engine

#246

Post by hda111 »

SEJeff wrote: post #221
zapita wrote: post #165

Earlier quoted context omitted.

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.

It is actually against copyright law, and redhat legal would take any allegations very seriously. What in specific do you think is copy and pasted code?

Docker is properly attributed to, see https://github.com/containers/storage/blob/a4cc7aa79e050c976...

I think OP wanted to say that Podman hates Docker what is not I feel when I'm interacting with the community there. People who use Podman do it because of it's additional features that Docker does not have, like starting an Container from a rootfs or mounting the currect directory in a container using "." as path. Also building containers using a shellscript is supported. No need to learn the Dockerfile syntax. There are lot of small things that make Podman better integrated into Linux systems: running the container via systemd is a lot more intuitive.

Re: Podman: A Daemonless Container Engine

#247

Post by doliveira »

archi42 wrote: post #241
doliveira wrote: post #230

Earlier quoted context omitted.

Well, I suppose if your dependencies are very locked down it might work in C++. I would guess, though, that having to change the prefix and default locations in all tarballs you download must be quite a pain. You can't install DEBs or any other tools either?

We have all deps in gits. A build tool takes care of everything. I get all necessary source gits checked out, configured (e.g. change prefix) and built. If I change something (which is my job), rebuilding is just a 'make' away; and rebuilds only the changed parts. Pretty frictionless and painless. We use some external stuff like sqlite, qt,... but that's all versioned in our gits as well (-> easily reproducible build…

That actually sounds pretty cool to work with, then. If you truly have support from the company to work like that... Sadly not how it works in most places

Re: Podman: A Daemonless Container Engine

#248

Post by znpy »

tw04 wrote: post #209
windexh8er wrote: post #207

Earlier quoted context omitted.

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...…

> 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.

Netapp is love, Netapp is life.

I have fond memories of cloning a volume, from a snapshot, in seconds. On EBS it takes minutes.

Re: Podman: A Daemonless Container Engine

#249

Post by Conan_Kudo »

westurner wrote: post #154

Is the title of this page out of date? AFAIU, Podman v3 has a docker-compose compatible socket and there's a daemon; so "Daemonless Container Engine" is no longer accurate. "Using Podman and Docker Compose" https://podman.io/blogs/2021/01/11/podman-compose.html

Podman does not run in a daemon-mode by default. There's a dbus-activated service unit that activates the daemon when you try to use Docker Compose with it.

Re: Podman: A Daemonless Container Engine

#250

Post by fatherlinnux »

eriksjolund wrote: post #168
edwintorok wrote: post #4

Earlier quoted context omitted.

If you run it as non-root it is significantly slower than docker as root. Docker can us the overlay2 kernel driver, whereas podkan would use fuse-overlayfs in userspace. This has a high CPU overhead (e.g. don't try to run AFL inside podman), and a 1024 FD limit for the entire container (so a 'make -j40' usually dies). There are ways around it: raise the ulimit for your user and run new enough podman to raise limit fo…

If I understand correctly support for native rootless mounts is currently under development: https://github.com/containers/storage/pull/816 The functionality requires Linux kernel 5.11 (soon to be released)

That is correct. We're targeting that work for RHEL 8.5 in November-ish, so you'll likely see that drop in Fedora and other Linux distros sooner.
Post reply on HN