Next phase of Minimization Objective #64

Merged
jflory7 merged 2 commits from phase-2-proposal into master 2026-06-09 01:55:54 +00:00
Contributor

Proposing the second phase of the Minimization objective. Council ticket: https://pagure.io/Fedora-Council/tickets/issue/274

Proposing the second phase of the Minimization objective. Council ticket: https://pagure.io/Fedora-Council/tickets/issue/274
First-time contributor

There is a patch set that makes polkit able to use INI/TOML style config files for rules instead of JavaScript. It was written by Ikey Doherty for Solus and Clear Linux, and would be worth reviving, updating, and upstreaming. That would allow eliminating the mandatory JS dependency.

There is a patch set that makes `polkit` able to use INI/TOML style config files for rules instead of JavaScript. It was written by Ikey Doherty for Solus and Clear Linux, and would be worth reviving, updating, and upstreaming. That would allow eliminating the mandatory JS dependency.
First-time contributor

I think this is a great goal to have but minimization is the wrong objective for that. People are still building their own artifacts using small container base images like Alpine. If we want to change that I think this is more of a marketing/public speaking initiative that needs to happen to explain why someone should use the fedora postgresql container image instead of the official postgresql image in DockerHub for example. In my opinion making Fedora smaller will not make people want to use the Fedora image over the one available in DockerHub.

I think this is a great goal to have but minimization is the wrong objective for that. People are still building their own artifacts using small container base images like Alpine. If we want to change that I think this is more of a marketing/public speaking initiative that needs to happen to explain why someone should use the fedora postgresql container image instead of the official postgresql image in DockerHub for example. In my opinion making Fedora smaller will not make people want to use the Fedora image over the one available in DockerHub.
First-time contributor

I would love to see more cloud native use cases, like how do we do with building Go/Rust applications, how do we use quarkus.io ect ... I think this is where Fedora can make a difference in this space.
So maybe some use cases would be Go and Rust image that allow you to compile your application, a JDK application. We also have a strong Python community so having a Python base image use case would be cool.

I would love to see more cloud native use cases, like how do we do with building Go/Rust applications, how do we use quarkus.io ect ... I think this is where Fedora can make a difference in this space. So maybe some use cases would be Go and Rust image that allow you to compile your application, a JDK application. We also have a strong Python community so having a Python base image use case would be cool.
First-time contributor

Minimization could definitely be part of making more appealing for upstreams to consider Fedora over Alpine, Debian, or Ubuntu for official app/service images. But I'm unsure if minimization is what they want or need for that. We'd need to conduct some outreach and survey developers of those images to get a better picture of what would make them consider Fedora over alternatives.

Minimization could definitely be part of making more appealing for upstreams to consider Fedora over Alpine, Debian, or Ubuntu for official app/service images. But I'm unsure if minimization is what they _want_ or _need_ for that. We'd need to conduct some outreach and survey developers of those images to get a better picture of what would make them consider Fedora over alternatives.
First-time contributor

Minimization could definitely be part of making more appealing for upstreams to consider Fedora over Alpine, Debian, or Ubuntu for official app/service images. But I'm unsure if minimization is what they want or need for that. We'd need to conduct some outreach and survey developers of those images to get a better picture of what would make them consider Fedora over alternatives.

+1 for me this would be a bigger objective and minimization would only be a part of it. For example the Official Python:3.8 image on DockerHub is 955MB and it is using Debian it would be awesome to have it run on Fedora and have a smaller image. I think that should be one of the focus use cases for minimization.

> Minimization could definitely be part of making more appealing for upstreams to consider Fedora over Alpine, Debian, or Ubuntu for official app/service images. But I'm unsure if minimization is what they want or need for that. We'd need to conduct some outreach and survey developers of those images to get a better picture of what would make them consider Fedora over alternatives. +1 for me this would be a bigger objective and minimization would only be a part of it. For example the Official Python:3.8 image on DockerHub is 955MB and it is using Debian it would be awesome to have it run on Fedora and have a smaller image. I think that should be one of the focus use cases for minimization.
First-time contributor

There is a patch set that makes polkit able to use INI/TOML style config files for rules instead of JavaScript. It was written by Ikey Doherty for Solus and Clear Linux, and would be worth reviving, updating, and upstreaming. That would allow eliminating the mandatory JS dependency.

After looking at the proposed patchset for INI/TOML, it either breaks all javascript rules, or it adds to the dependency list. There is another proposal to use duktape instead of mozjs. That would be able to preserve the current javascript uses, and trim things down. duktape is under 200 KB, and doesn't have all the baggage that mozjs has.

> There is a patch set that makes polkit able to use INI/TOML style config files for rules instead of JavaScript. It was written by Ikey Doherty for Solus and Clear Linux, and would be worth reviving, updating, and upstreaming. That would allow eliminating the mandatory JS dependency. After looking at the proposed patchset for INI/TOML, it either breaks all javascript rules, or it adds to the dependency list. There is another proposal to use duktape instead of mozjs. That would be able to preserve the current javascript uses, and trim things down. duktape is under 200 KB, and doesn't have all the baggage that mozjs has.
Author
Contributor

Thanks all for the feedback. I'm back from over-a-week-long vacation, will get back to every comment very shortly!

Thanks all for the feedback. I'm back from over-a-week-long vacation, will get back to every comment very shortly!
Author
Contributor

There is a patch set that makes polkit able to use INI/TOML style config files for rules instead of JavaScript. It was written by Ikey Doherty for Solus and Clear Linux, and would be worth reviving, updating, and upstreaming. That would allow eliminating the mandatory JS dependency.

@ngompa Thanks for the tip. Short-term, I'm inclined to try to do what @tdawson proposes to maintain compatibility with existing configs.

> There is a patch set that makes polkit able to use INI/TOML style config files for rules instead of JavaScript. It was written by Ikey Doherty for Solus and Clear Linux, and would be worth reviving, updating, and upstreaming. That would allow eliminating the mandatory JS dependency. @ngompa Thanks for the tip. Short-term, I'm inclined to try to do what @tdawson proposes to maintain compatibility with existing configs.
Author
Contributor

I think this is a great goal to have but minimization is the wrong objective for that. People are still building their own artifacts using small container base images like Alpine. If we want to change that I think this is more of a marketing/public speaking initiative that needs to happen to explain why someone should use the fedora postgresql container image instead of the official postgresql image in DockerHub for example. In my opinion making Fedora smaller will not make people want to use the Fedora image over the one available in DockerHub.

Minimization could definitely be part of making more appealing for upstreams to consider Fedora over Alpine, Debian, or Ubuntu for official app/service images. But I'm unsure if minimization is what they want or need for that. We'd need to conduct some outreach and survey developers of those images to get a better picture of what would make them consider Fedora over alternatives.

@cverna @ngompa I agree with both of you that the Minimization work is not everything we need to do to fulfil that outcome. But maybe we could use it as a talking point? or as a conversation starter? And then we could dig into more details how Linux distros, and especially Fedora, can benefit to containers.

I agree that this outcome will be more dependent on public speaking, online content, and also just talking to people at tech events. Would you be interested to talk about / help with that?

I wonder if we should request budget for community (or just team) members to go to events specifically for this purpose as a part of this objective. I'm sure many of us will be at DevConf, FOSDEM, Flock, ... but perhaps we should focus on container-oriented events as that's the most relevant audience I feel.

> I think this is a great goal to have but minimization is the wrong objective for that. People are still building their own artifacts using small container base images like Alpine. If we want to change that I think this is more of a marketing/public speaking initiative that needs to happen to explain why someone should use the fedora postgresql container image instead of the official postgresql image in DockerHub for example. In my opinion making Fedora smaller will not make people want to use the Fedora image over the one available in DockerHub. > Minimization could definitely be part of making more appealing for upstreams to consider Fedora over Alpine, Debian, or Ubuntu for official app/service images. But I'm unsure if minimization is what they want or need for that. We'd need to conduct some outreach and survey developers of those images to get a better picture of what would make them consider Fedora over alternatives. @cverna @ngompa I agree with both of you that the Minimization work is not everything we need to do to fulfil that outcome. But maybe we could use it as a talking point? or as a conversation starter? And then we could dig into more details how Linux distros, and especially Fedora, can benefit to containers. I agree that this outcome will be more dependent on public speaking, online content, and also just talking to people at tech events. Would you be interested to talk about / help with that? I wonder if we should request budget for community (or just team) members to go to events specifically for this purpose as a part of this objective. I'm sure many of us will be at DevConf, FOSDEM, Flock, ... but perhaps we should focus on container-oriented events as that's the most relevant audience I feel.
Author
Contributor

I would love to see more cloud native use cases, like how do we do with building Go/Rust applications, how do we use quarkus.io ect ... I think this is where Fedora can make a difference in this space.
So maybe some use cases would be Go and Rust image that allow you to compile your application, a JDK application. We also have a strong Python community so having a Python base image use case would be cool.

That's a good point, let me add Go, Rust, and Quarkus to the list. At least to look at.

With Python, my thinking was that there is Python in every Fedora image because of DNF, but maybe "having Python" vs. "being useful to deploy Python apps" is not always the same. So let me add Python there as well.

> I would love to see more cloud native use cases, like how do we do with building Go/Rust applications, how do we use quarkus.io ect ... I think this is where Fedora can make a difference in this space. > So maybe some use cases would be Go and Rust image that allow you to compile your application, a JDK application. We also have a strong Python community so having a Python base image use case would be cool. That's a good point, let me add Go, Rust, and Quarkus to the list. At least to look at. With Python, my thinking was that there is Python in every Fedora image because of DNF, but maybe "having Python" vs. "being useful to deploy Python apps" is not always the same. So let me add Python there as well.
Author
Contributor

Minimization could definitely be part of making more appealing for upstreams to consider Fedora over Alpine, Debian, or Ubuntu for official app/service images. But I'm unsure if minimization is what they want or need for that. We'd need to conduct some outreach and survey developers of those images to get a better picture of what would make them consider Fedora over alternatives.

+1 for me this would be a bigger objective and minimization would only be a part of it. For example the Official Python:3.8 image on DockerHub is 955MB and it is using Debian it would be awesome to have it run on Fedora and have a smaller image. I think that should be one of the focus use cases for minimization.

Huh, 955MB for a Python runtime seems quite big? So yes, let's focus on that one specifically, too.

> > Minimization could definitely be part of making more appealing for upstreams to consider Fedora over Alpine, Debian, or Ubuntu for official app/service images. But I'm unsure if minimization is what they want or need for that. We'd need to conduct some outreach and survey developers of those images to get a better picture of what would make them consider Fedora over alternatives. > > +1 for me this would be a bigger objective and minimization would only be a part of it. For example the Official Python:3.8 image on DockerHub is 955MB and it is using Debian it would be awesome to have it run on Fedora and have a smaller image. I think that should be one of the focus use cases for minimization. Huh, 955MB for a Python runtime seems quite big? So yes, let's focus on that one specifically, too.
Author
Contributor

1 new commit added

  • add container-native use cases
**1 new commit added** * ``add container-native use cases``
Author
Contributor

@cverna @ngompa About outreach, @bex has suggested to me that this would be a great marketing/talking point for Fedora. Maybe we should reach out to the marketing team to figure something out.

@cverna @ngompa About outreach, @bex has suggested to me that this would be a great marketing/talking point for Fedora. Maybe we should reach out to the marketing team to figure something out.
First-time contributor

So from the few conversations I have when going to different developers meetup in my area. It is really hard for people to understand why they should consume a layered image (ie postgresql) from the fedora registry rather than taking the official image from Docker Hub. By experience you can talk to people about security, the fact that we update our images etc still most of the time developers are using containers in their development environment and they don't really care about that.

For them creating a container by FROM python:3.7 rather than FROM registry.fedoraproject.org/f31/python:latest is going through some extra typing for not much benefit.

For containers that run in production, the general trend I see, in these meetup and or devopsdays conferences is that people generally build their own containers and build a custom pipeline to keep them updated. So in general they just use an alpine base image, or more and more just do a FROM scratch and drop the binary from their golang or rust project.

I think selling Fedora as a platform to build containers from is not an easy task, at least to me :-)

So from the few conversations I have when going to different developers meetup in my area. It is really hard for people to understand why they should consume a layered image (ie postgresql) from the fedora registry rather than taking the official image from Docker Hub. By experience you can talk to people about security, the fact that we update our images etc still most of the time developers are using containers in their development environment and they don't really care about that. For them creating a container by FROM python:3.7 rather than FROM registry.fedoraproject.org/f31/python:latest is going through some extra typing for not much benefit. For containers that run in production, the general trend I see, in these meetup and or devopsdays conferences is that people generally build their own containers and build a custom pipeline to keep them updated. So in general they just use an alpine base image, or more and more just do a FROM scratch and drop the binary from their golang or rust project. I think selling Fedora as a platform to build containers from is not an easy task, at least to me :-)
Contributor

Approved by Council. Merging.

Approved by Council. Merging.
Contributor

Pull-Request has been merged by bcotton

Pull-Request has been merged by bcotton
Author
Contributor

\o/

\o/
Sign in to join this conversation.
No reviewers
No milestone
No project
No assignees
5 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
council/docs!64
No description provided.