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

211–220 of 250 posts

Re: Podman: A Daemonless Container Engine

#211

Post by maweki »

johnchristopher wrote: post #160
maweki wrote: post #138

One very interesting piece of tech coming from it, is toolbox ( https://github.com/containers/toolbox ). Basically throwaway (or keeparound) rootless containers with their own root directory but shared HOME. Install hundreds of dev-dependencies to build this one piece of software? Yeah, not gonna install those packages permanently. Spin up a toolbox, build it, install it in my home/.local. You have root in the contai…

I usually share a volume between containers (eg:: a volume for wp-cli cache, another for -g npm_modules). What benefits would toolbox add ?

You could, for example, host the whole dev environment for a project in a container and still develop on the code in home.

Re: Podman: A Daemonless Container Engine

#212

Post by johnchristopher »

maweki wrote: post #211
johnchristopher wrote: post #160

Earlier quoted context omitted.

I usually share a volume between containers (eg:: a volume for wp-cli cache, another for -g npm_modules). What benefits would toolbox add ?

You could, for example, host the whole dev environment for a project in a container and still develop on the code in home.

Ah, I see ; put the whole dev toolchain in the container.

I use bindfs to mount the volume. I have a $HOME/Dev folders with WPProjectA, WPProjectB folders. Each has a volume subfolder mounted like that (the script has more variables but that's the gist of it):

    /usr/bin/bindfs \
        --force-user=johnchristopher \
        --force-group=johnchristopher \
        --create-for-user=www-data \
        --create-for-group=www-data \
        /var/lib/docker/volumes/WPProjectA-web/_data \
        $HOME/Dev/WPProjectA/volume
This setup allows using VSCode+xdebug and editing the code in the mounted volume while running the container and remote debugging.

Re: Podman: A Daemonless Container Engine

#213

Post by dastx »

stock_toaster wrote: post #194
windexh8er wrote: post #173

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…

Not to mention podman's historic[1] lack of compose support (or similar), which is frequently used in CI and local dev environments. I think has really held it back for a lot of folks. [1]: Apparently initial support planned in version 3.0?

I don't know if I'm misunderstanding, but if by 'compose support' you mean docker-compose, then podman-compose has existed for a lot longer than v3.0 (which got released yesterday). First commit was nearly two years ago.

Sadly it doesn't feel as polished as docker-compose, I can only assume it's due to the lack of API. Specifically, podman-compose just translates all the docker-compose.yml file directives into podman cli commands, which doesn't seem to be handled gracefully.

Re: Podman: A Daemonless Container Engine

#214

Post by horstmeyer »

carlosf wrote: post #193
znpy wrote: 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…

Have you tried Kaniko? That's how I got hid of DinD in my Gitlab Runners.

Could you maybe provide a small example of the relevant part of the gitlab CI definition? I assume you run kaniko inside a Docker container on the runner?

Re: Podman: A Daemonless Container Engine

#215

Post by MaxBarraclough »

adev_ wrote: post #143
SEJeff wrote: post #98

Earlier quoted context omitted.

This is C, not C++. Modern C++ is kind of a mess with how much stuff they’ve added to the language. This is not relevant.

> Modern C++ is kind of a mess with how much stuff they’ve added to the language. This is not relevant. Yeah and C++ would be a way better language to write critical system daemon in 2020 than C. Both safer and more productive while keeping the exact same portability and performance as C when necessary. Most safety issues of C (buffer overflows, use-after-free, stack smash) are not a problem anymore in modern C++. Ye…

> There is zero excuses to C in userland in 2020.

I wouldn't go quite that far. I'm generally in the C++ camp (rather than C, that is) but there are significant advantages to a compact and stable language, and real disadvantages to a sprawling disaster like C++ that grows still more monstrously complex every few years.

This topic turned up a year ago: https://news.ycombinator.com/item?id=21946060

Your point stands though: well written modern C++ should be much less prone to memory-safety issues than well written modern C.

Re: Podman: A Daemonless Container Engine

#216

Post by windexh8er »

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

Your chart takes all of Amazon into account, not just AWS. You'll have to actually dig into earnings to understand that.

Second thing is gross margin is not the same thing as net margin. Net margin is a far better indicator in the case of pure profitability / revenue. Just because a company shares $1.42B in revenue doesn't mean they have $1.42B in profits. If you look at NetApp net profit margin it's off 45% year over year. Latest net profit margin is 9.68%. So on that 1.42B we have $137M in profit. Not too hot.

The reality is hardware sales have thin margin (comparatively) and NetApp's software model is much weaker than comparative storage offerings in the cloud. It's very expensive to design, build, ship and house inventory of hardware for purchase. There's no way around this, which chews through that profit margin.

Re: Podman: A Daemonless Container Engine

#217

Post by curt15 »

maweki wrote: post #138

One very interesting piece of tech coming from it, is toolbox ( https://github.com/containers/toolbox ). Basically throwaway (or keeparound) rootless containers with their own root directory but shared HOME. Install hundreds of dev-dependencies to build this one piece of software? Yeah, not gonna install those packages permanently. Spin up a toolbox, build it, install it in my home/.local. You have root in the contai…

>Basically throwaway (or keeparound) rootless containers

Toolbox emphasises "keeparound" containers since it's intended to be the primary command-line environment for image-based systems like Silverblue or CoreOS. Such systems try to keep a small, atomically updated rootfs and push users to install everything in containers.

Re: Podman: A Daemonless Container Engine

#218

Post by tw04 »

windexh8er wrote: post #216
tw04 wrote: post #209

Earlier quoted context omitted.

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

Your chart takes all of Amazon into account, not just AWS. You'll have to actually dig into earnings to understand that. Second thing is gross margin is not the same thing as net margin. Net margin is a far better indicator in the case of pure profitability / revenue. Just because a company shares $1.42B in revenue doesn't mean they have $1.42B in profits. If you look at NetApp net profit margin it's off 45% year ove…

>Your chart takes all of Amazon into account, not just AWS. You'll have to actually dig into earnings to understand that.

Yes, I'm aware Amazon continually buries their AWS profitability. It's 57% of the overall margin, it's not significantly better than NetApp.

>Second thing is gross margin is not the same thing as net margin. Net margin is a far better indicator in the case of pure profitability / revenue.

Net margin is a dial they can and do turn by shifting money in and out of R&D and sales staff. Furthermore you can't simultaneously say that for Amazon we only take into account AWS and not the rest of the business... which is a part of the engine that drives the AWS business. That's no different than saying we shouldn't account for hardware in NetApp's number because they also sell software.

>It's very expensive to design, build, ship and house inventory of hardware for purchase. There's no way around this, which chews through that profit margin.

What exactly do you think Amazon's datacenters are full of? Hardware they design, build, and ship inventory around the country for. They are working with the exact same ODM's that NetApp or any other storage vendor works with to design their custom hardware variations.

Re: Podman: A Daemonless Container Engine

#219

Post by windexh8er »

tw04 wrote: post #218
windexh8er wrote: post #216

Earlier quoted context omitted.

Your chart takes all of Amazon into account, not just AWS. You'll have to actually dig into earnings to understand that. Second thing is gross margin is not the same thing as net margin. Net margin is a far better indicator in the case of pure profitability / revenue. Just because a company shares $1.42B in revenue doesn't mean they have $1.42B in profits. If you look at NetApp net profit margin it's off 45% year ove…

>Your chart takes all of Amazon into account, not just AWS. You'll have to actually dig into earnings to understand that. Yes, I'm aware Amazon continually buries their AWS profitability. It's 57% of the overall margin, it's not significantly better than NetApp. >Second thing is gross margin is not the same thing as net margin. Net margin is a far better indicator in the case of pure profitability / revenue. Net marg…

I'd wager heavily on AWS (i.e. Amazon) outperforming NetApp over the next decade. Why? Their operation model is far better positioned for profits. Honestly, if you consider storage vendors a significant growth market you and I have a very different opinion of what's driving profits in technology today.

All balance sheets can and are manipulated to differing extent. The reality though is net margin takes better into account than what you were proposing, which is a cherry picked angle to make a point. Growth companies move profits to R&D. NetApp isn't highlighting R&D on earnings calls. Amazon highlights R&D very publicly multiple times per year. Low R&D costs and investment are indicators of a stagnant market.

Amazon's hardware model is not the same as NetApp's. You realize Amazon consumes almost 100% of their own hardware offerings for AWS, right? They have a much more palatable JIT model. They can build as they need. NetApp has to house dead weight inventory for potential sales so they can recognize revenue, especially for end of quarter / end of year sales pushes. Amazon doesn't have this problem.

Also NetApp has to package their product for customer distribution. You may ignorantly shrug this off but it's an additional cost that adds up quickly. NetApp also has to maintain documentation and support staff for customer facing hardware related issues. Amazon has a much lighter requirement because they have specialists within their DCs.

It's not even remotely comparable. Amazon isn't working with "the exact same ODMs". Many ODMs NetApp is forced to work with Amazon doesn't need. Take a look at what Amazon is doing internally and it's clear their stack continues to evolve more towards in house designs and build. NetApp is far more reliant on external support than Amazon is given their positions in the market and have far greater control over the hardware stack from top to bottom. Maybe peruse the career openings at AWS vs NetApp for some insights.

Re: Podman: A Daemonless Container Engine

#220

Post by SEJeff »

zapita wrote: post #190
SEJeff wrote: post #180

Earlier quoted context omitted.

Docker and Redhat were both founding members of OCI. CoreOS probably was responsible for a lot of the initial conversations. They wanted a standardized container runtime after finding some limitations in docker which caused them to create rkt. Docker inc wasn’t super into changing anything and as history as shown, wasn’t terribly into working well with others. The industry was going to move forward without them but t…

I understand what you’re saying but it is incorrect. Docker was in fact the originator of OCI in every way that matters. They made the decision to create it; drafted the founding documents and went back and forth with Linux Foundation on the content; chose the names (initially OCF, then later OCI); negotiated with LF the governance structure and initial board composition; negotiated the list of external maintainers w…

Well thanks for your input, and I stand corrected. I liked Solomon and he always seemed like a super nice guy when I met him, but it did seem that there was a bit of a crisis when Docker Inc realized, "Oh shit, we have to make money for these VCs!" and then it got really awkward. I was sad to see it happen as Dan Walsh and Solomon are both really good peeps to me.
Post reply on HN