You attended the 2023 iteration of DevConf.cz, a yearly open source conference in Czechia!
You attended the 2023 iteration of DevConf.cz, a yearly open source conference in Czechia!
There’s been something in the back of my brain that’s been bothering me about talks at the big conferences lately but I just couldn’t figure out how to talk about it. Until I listed to this episode of The Hacker Mind Podcast on Self Healing Operating Systems (it’s a great podcast, like and subscribe). The episode was all about this incredibly bizarre way to store operating system state in a SQL database (yeah, you read that right). The guest made no excuses that this is a pretty wild idea and it’s not going to happen anytime soon. But we need weird research like this, it’s part of the forward march of progress.
This sort of obviously experimental research is what I’m going to call “rocket ships” in the context of this blog post. It’s work that is extremely interesting, but will take decades to turn into something that affects us directly. Almost nobody can really do it, there’s no short term money in this research, and even fewer will directly benefit for decades. It will almost certainly have benefits someday, and won’t look anything like it does today.
Now, there’s another side of this story. All that stuff we actually have to do. This is the boring every day stuff that keeps the trains moving and electricity running. Nobody is giving talks about this because it just sort of exists. I don’t think KubeCon is going to accept the talk “How I keep your family from freezing to death in the winter”. Let’s call this work “eating our vegetables” or “radishes” because I needed something that started with an R. Humans like alliteration. Rocket Ship … Radish … oh hey, Research also starts with R!
So anyway, this brings me to a lot of the big conferences. I think what I see is a lot of rocket ship research that’s dressed up as radishes. I’m not going to pick on any one company or project specifically because that’s not just bad taste, but I also can’t afford to make any more enemies. Instead, I’m going to make up an example to explain what I see. Let’s use supply chain security as the backdrop because that’s the universe I mostly live in right now. You could just as easily substitute in AI, or blockchain, or french fries.
Our hero, or maybe villain, who knows, everyone is a hero and villain to someone, they are giving a talk on how we can secure open source build systems by rewriting them all in Apple II basic. It will of course be creating reproducible binaries, and we should sign everything with a new variant of Sigstore crossed with PGP called Pigstore, the mascot is a duck. And it probably also draws pictures of clowns, or maybe cats, some sort of mammal. There’s a demo, and a GitHub website. You know it’s been donated to the OpenSSF because that’s a cool thing to do. And of course the name is an unpronounceable German word related to ship building, and the mascot is some sort of obscure animal that lives in a cave.
The room was packed, the talk went over great. The conference WiFi only let half the demos work, but that was enough to show off the internet connected Apple II building Node.js. Animated GIFs showed off the rest. On second thought none of this mattered because the demos were 75 pages of terminal text nobody could read. Whatever, everything went perfect. Oh, and did they mention we should expect all open source projects to start using this build system because if they don’t everyone will call them names! The future starts today!
In the academic days (like our operating system example from the opening), it would be well understood that this was rocket ship research. It almost certainly wouldn’t go anywhere anytime soon, but was a step as part of the larger story of progress. As the arrow of time drags us all into the future, so does the path of progress, as long as you don’t live in Florida.
But this isn’t how these talks work anymore. On Monday, there will be customers asking where on your roadmap this new build system falls so they can take advantage of all these features they didn’t even know they needed. They didn’t know they needed more clown pictures, but suddenly it’s very obvious it was the thing missing from their soul that previously a fidget spinner was filling. That senior developer who quit last week said the biggest problems were no unit tests or code reviews, but it’s probably actually this.
Your leadership will say this needs to be part of Q2 planning because all the competitors are also doing it, so they read on LinkedIn. The community meeting for the project has ballooned to 300 people, all talking about how they are busy integrating things into their production environments as we speak, just skip right over test and dev, this goes straight to prod! So you know it’s going to be a huge deal.
I want to stress, these sort of projects have immense value, but I also suspect that pretending they’re something that can be used, a radish, is actually hurting the research, or rocket ship if you’re keeping track. Now instead of researchers doing weird research things, you have community meetings filled with developer advocates trying to make sure their company gets in on the ground floor. There’s no more room for experimentation because apparently version 0.1 of the framework just got released yesterday, nobody knows who did it or how. In 3 months at the next conference something even newer will get talked about, this project will be mostly forgotten, and what could have been important research is going to fester in an abandoned GitHub repository forever.
I’m not sure how to wrap this up. Is this a problem with the companies funding this research wanting to pretend it’s something more real, or is it the large conferences looking for more “real world” focused solutions instead of research that won’t go anywhere for decades? Maybe things have always been like this and I just didn’t notice before now.
Apple has once again made waves with their latest release, the Vision Pro. The mere fact that this new device ensures legible text for its users sets it years ahead of competitors like HTC and Meta. Not to mention the array of groundbreaking sensors, user-friendly interface, and independence from a computer. It’s important to note that this is just the initial version, with much more to come.
The Apple Vision Pro undoubtedly offers more effective applications for immersive entertainment compared to its competitors. However, I believe it will also flourish in work environments.
<figure class="wp-block-embed is-type-rich is-provider-embed-handler wp-block-embed-embed-handler"><figcaption class="wp-element-caption">A giant immersive VR workspace with Apple Vision Pro</figcaption></figure>Given that this AR/VR device can finally deliver sharp and clear text, as demonstrated during the release event, one can only imagine the level of concentration achievable in a vast immersive environment, surpassing the size of a computer screen. While it may not be suitable for extended periods, a few focused hours with the Vision Pro would be incredibly productive.
Of course, I anticipate potential strain on my neck and eyes if I were to use a VR device for prolonged durations. Yet, I can’t help but envision how absurdly insignificant we would feel returning to our rectangular computer screens after spending a few hours in this new, immersive, VR-powered workspace.
I want an Apple Vision Pro, both for work and leisure purposes.
<figure class="wp-block-embed is-type-video is-provider-youtube wp-block-embed-youtube wp-embed-aspect-16-9 wp-has-aspect-ratio"></figure>
czanik)
on June 06, 2023 12:38 PM
One of the returning syslog-ng questions I receive is how many log messages can a given hardware handle. My typical answer is that it depends on the configuration. I have now an answer, or rather a tool to answer your question: sngbench.sh. It is a shell script that runs from localhost and uses loggen, the bundled benchmarking and testing tool of syslog-ng. It comes with two configurations: a performance-optimized and a realistic one. You are also free to extend sngbench with your own configurations.
<figure>
<figcaption>
admin)
on June 06, 2023 12:17 PM
Flock to Fedora returns in-person again after four years. This year is in Cork, Ireland from 2-4 August 2023. The CfP is open now. Will we see you there? This article introduces the new Flock CfP system and how to submit your proposal as a presenter this year.
Apply now for the Flock 2023 Call for Proposals (CfP) at cfp.fedoraproject.org. This year, Flock is using a new CfP system. If you have ever submitted a proposal for a DevConf event, it will feel familiar. The deadline to submit is by Tuesday, June 20th, 2023.
Flock 2023 will take place in Cork, Ireland. The venue for this year is the Clayton Hotel Silver Springs. We will use the hotel conference center for this year’s event, and Flock attendees are encouraged to book a room at the venue hotel.
Flock has a special booking code for the hotel. When booking the hotel, use REDH010823 as the block code when reserving your room. Everyone, including Red Hatters, are encouraged to book directly with the hotel using the booking code.
The hotel address is below:
Clayton Hotel Silver Springs
Tivoli, Cork, T23 E244
Ireland
Phone: +353 21 450 7533
In addition to being the first Flock in four years, we are adding in new variables to this year’s event:
All submissions for this year’s event should go to one of our three tracks. When submitting a proposal in the system, you will be asked to choose from one of these three “topics.” The deadline to submit for Flock 2023 is on Tuesday, June 20th, 2023.
This year, Flock 2023 is using the open source CfP system maintained by Josef Ridky at Red Hat. This is the same CfP system shared by the DevConf CfP system. If you already have an account on the DevConf CfP system, your account already exists in the Flock CfP system. Google and GitHub are supported for login only, although integration with a FAS account login is underway. Fedora Account System (FAS) login is now supported! Thanks Josef Řídký, Kevin Fenzi, Aurélien Bompard, and Ryan Lerch for their help in launching our new CfP system.
After logging in, view the Submit page for Flock 2023. From there, you can create a proposal with your submission. After submitting, check back soon for comments, questions, or updates on your submission by the reviewer team.
<figure class="wp-block-image size-large">
</figure>
We hope to see you this year in Cork! If you will be there, consider applying in the call for proposals. If you have questions or comments about the CfP system, you can reply as a comment to this post. Stay tuned for more information about registration and financial assistance in the coming weeks.
The post Flock 2023 CfP open now until 20 June appeared first on Fedora Community Blog.
After what was basically a flurry of typing, the snegg Python bindings for libei are now available. This is a Python package that provides bindings to the libei/libeis/liboeffis C libraries with a little bit of API improvement to make it not completely terrible. The main goal of these bindings (at least for now) is to provide some quick and easy way to experiment with what could possibly be done using libei - both server-side and client-side. [1] The examples directory has a minimal EI client (with portal support via liboeffis) and a minimal EIS implementation. The bindings are still quite rough and the API is nowhere near stable.
A proper way to support EI in Python would be to implement the protocol directly - there's no need for the C API quirkiness this way and you can make full use of things like async and whatnot. If you're interested in that, get in touch! Meanwhile, writing something roughly resemling xdotool is probably only a few hundred lines of python code. [2]
[1] writing these also exposed a few bugs in libei itself so I'm happy 1.0 wasn't out just yet
[2] at least the input emulation parts of xdotool
admin)
on June 06, 2023 08:00 AM
This is the latest in our monthly series summarizing the past month on the Community Blog. Please leave a comment below to let us know what you think.
In May, we published 24 posts. The site had 3,871 visits from 2,369 unique viewers. 902 visits came from search engines, while 95 came from Fedora Magazine, 41 from Fedora Discussion, and 37 came from Twitter.
The most read post last month was “Fedora Linux 39 development schedule” with 224 views. The most read post published last month was “Friday’s Fedora Facts: 2023-19” and “F38 elections voting now open“, each with 85 views.
No badges this month. You can earn one by sharing your work on the Community Blog!
The Community Blog is the place to publish community-facing updates on what you’re working on in Fedora. The process is easy, so submit early and submit often.
The post Community Blog monthly summary: May 2023 appeared first on Fedora Community Blog.
We're happy to announce Kiwi TCMS version 12.4!
IMPORTANT: this is a small release which contains security related updates, few improvements and new translations!
You can explore everything at https://public.tenant.kiwitcms.org!
Supported upgrade paths:
5.3 (or older) -> 5.3.1 5.3.1 (or newer) -> 6.0.1 6.0.1 -> 6.1 6.1 -> 6.1.1 6.1.1 -> 6.2 (or newer)
---
Upstream container images (x86_64):
kiwitcms/kiwi latest 5f88a1a37a39 599MB
IMPORTANT: version tagged and multi-arch container images are available only to subscribers!
Based on Kiwi TCMS v12.4
Update kiwitcms-trackers-integration from 0.4.0 to 0.5.0
Private images:
quay.io/kiwitcms/version 12.4 (aarch64) 2d1f5f1ead8a 06 Jun 2023 607MB quay.io/kiwitcms/version 12.4 (x86_64) 5f88a1a37a39 06 Jun 2023 598MB quay.io/kiwitcms/enterprise 12.4-mt (aarch64) 254794a5c858 06 Jun 2023 851MB quay.io/kiwitcms/enterprise 12.4-mt (x86_64) 5bc0ef78a3c4 06 Jun 2023 840MB
IMPORTANT: version tagged, multi-arch and Enterprise container images are available only to subscribers!
Backup first! Then execute the commands:
cd path/containing/docker-compose/ docker-compose down docker-compose pull docker-compose up -d docker exec -it kiwi_web /Kiwi/manage.py upgrade
Refer to our documentation for more details!
Happy testing!
---
If you like what we're doing and how Kiwi TCMS supports various communities please help us grow!
Version alpha1 is planned to be released this week. It's still in development and will enter soon in the stabilization phase for the developers, and the test phase for the users.
RPM of this upcoming version of PHP 8.3, are available in remi repository for Fedora 37, 38 and Enterprise Linux 7, 8, 9 (RHEL, CentOS, Alma, Rocky...) in a fresh new Software Collection (php83) allowing its installation beside the system version.
As I (still) strongly believe in SCL potential to provide a simple way to allow installation of various versions simultaneously, and as I think it is useful to offer this feature to allow developers to test their applications, to allow sysadmin to prepare a migration or simply to use this version for some specific application, I decide to create this new SCL.
I also plan to propose this new version as a Fedora 40 change (as F39 should be released a few weeks before PHP 8.3.0).
Installation :
yum install php83
To be noticed:
Also read other entries about SCL. especially description of my My PHP workstation.
$ module load php83
$ php --version
PHP 8.3.0-dev (cli) (built: Jun 5 2023 12:59:04) (NTS gcc x86_64)
Copyright (c) The PHP Group
Zend Engine v4.3.0-dev, Copyright (c) Zend Technologies
with Zend OPcache v8.3.0-dev, Copyright (c), by Zend Technologies
As always, your feedback is welcome, a SCL dedicated forum is open.
Software Collections (php83)
filiperosset)
on June 06, 2023 05:40 AM
68501a3 update parallel to 20230422
https://src.fedoraproject.org/rpms/parallel/c/68501a36e0d41a8ad157696bed281a7179c8633c?branch=rawhide
Bug 2177564 – converseen-0.9.11.1 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2177564
Bug 2178834 – ansifilter-2.19 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2178834
4895c57 – update highlight to 4.5
https://src.fedoraproject.org/rpms/highlight/c/4895c57b1087de46fb6dbc09d86a2a90ab9c7066?branch=rawhide
4af4861 – update parallel to 20230322
https://src.fedoraproject.org/rpms/parallel/c/4af486177568a3517efcc9a721303b976d322b2c?branch=rawhide
adcff0f – update homebank to 5.6.3
https://src.fedoraproject.org/rpms/homebank/c/adcff0fea7b3941d608e184a9463db5d40162c4f?branch=rawhide
Bug 2184206 – parzip-1.4.0 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2184206
Bug 2171639 – parzip: FTBFS in Fedora rawhide/f38
https://bugzilla.redhat.com/show_bug.cgi?id=2171639
Bug 2178928 – aime-8.20230311 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2178928
Bug 2175428 – worker-4.12.1 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2175428
31ee280 – Update proguard to 6.2.2 + spec cleanup
https://src.fedoraproject.org/rpms/proguard/c/31ee2806c58d481bccdef6fb9b33fa37b30a4e3b?branch=rawhide
0fdf673 – Update clinfo to 3.0.23.01.25
https://src.fedoraproject.org/rpms/clinfo/c/0fdf6736dedebc74cbc2f1c3e674fd5145cfe33c?branch=rawhide
Bug 2183783 – goaccess-1.7.2 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2183783
Bug 2098509 – f2fs-tools-1.15.0 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2098509
fa019a5 – remove upstreamed patches from apvlv
https://src.fedoraproject.org/rpms/apvlv/c/fa019a5d032cda43aed0762d56f34f5e7dae262b?branch=rawhide
Bug 2188959 – sakura-3.8.7 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2188959
Bug 1825150 – colm-0.14.7 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1825150
Bug 2189912 – xfce4-whiskermenu-plugin-2.7.3 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2189912
bogomil)
on June 05, 2023 10:41 AM
It’s early Tuesday morning, and I am again in the metro, going to a location in Prague I have never been to before. People are quiet on the train, thinking about their lives. I saw just a few people not looking at their phones. Have we become humanity addicted to some shiny devices and so-called “technologies”? That could be another topic. Now, I am going to the second day of DevOpsDays2023 Prague.
The hotel welcomes me with many tobacco smokers outside and a strange facade. I am in the right place because I saw familiar faces and heard someone talking about Jenkins.
I took the elevator to the conference area and headed to the registration. A lovely girl said hello to me after I got my welcome pack. I said hello back. I told myself something was wrong. See, sweet girls never say hello to me like that.
Then I remembered I am in a friendly company because DevOps is not only about technologies but also about the mindset of being nice to others.
I met a few great people I worked with and then went to the conference room. I expected more attendees. The room was 80% full. It may be too early.
I was just on time for the first speaker.
</figure>
Ben is representing a company called ARMO which deals with container security. I discovered their free scanner while trying to convince some of my stakeholders that we are shipping not-so-well-secured containers. I was eager to learn more.
Armo’s team researched and compared the vulnerabilities they discovered in two large groups: All open-source projects in Github as one group and a group of so-called “graduated projects” from CNCF as the second. He showed the security findings in both groups, leaning towards the intention that the graduated projects are a bit more secure (in most areas). We should investigate how they did it and apply it on our own.
The other exciting point I have struggled with is that we should investigate critical /high CVEs found during the scan because they could not be exploited in particular cases. Usually, this is part of the remediation activity, but I know of some companies that want their containers clean, no matter what. This struggle sometimes causes a lot of friction within the teams. He also showed some use cases to support that.
The CVE scanners are good conversation starters, but the human element is needed to do the analysis and prepare the remediation plan. I don’t expect the AI to do this now, but this will be the future.
Considering the title, the second talk would be boring. I was wrong.
Paul took us through a growth journey, and he challenged me and most of the audience to think about diversity, community, and true belonging.
Even though his talk was about some efforts in a different country, I learned a lot about working and building a community. This is a vital tool on your tool belt of (professional) life.
I am a visual person. When he shared a picture of grass in the parking lot, I immediately thought: everything is possible. Then he said the same with his own words.
We need to look for possibilities, specifically in unusual places. The beauty of life doesn’t lie in the known. Nobody cares about a beach full of beton, but most people will smile and be happy seeing a flower pushing through the horror and bringing something beautiful to the world. This also applies to personal and work relations. Right?
I wanted to spend more time with Paul while he was in Prague, but I didn’t make it. He is a very insightful person to learn from. So next time you end up in an event near him, say hi and soak some wisdom.
One of my favorite parts of any event is the “free” coffee. Ok, you got me, it’s the “free” beer, but it was 10:30, and I don’t like drinking in the morning.
The coffee breaks are an excellent way to support community conferences by visiting sponsors’ booths. Because of them, such events exist.
The second best use of the breaks is to meet people. I prefer to avoid meeting new people. I get nervous most of the time when I have to talk to an entirely stranger person. I know I am weird. I stayed within my comfort zone by talking to people I already knew. If you like meeting people, use the coffee break to enlarge your horizon.
I went back to the room after gulping a disgusting cup of coffee. Instant coffee is different from my thing, but I needed the caffeine. I went back to the room to meet the next fantastic speaker.
Doing proper testing is a hoax. We always do it in a way that goes against the value and the experience within the quality team. On the other hand, the level of testing desired by the same team could be more business justifiable. This, of course, is my sole opinion.
Sowmya focuses on an exciting intersection between Operations and Testing. Testing has a very low priority in the modern DevOps world.
Everyone knows that we need to ship faster quality software. Surprisingly the team responsible for this part needs to be addressed. Their proposals for improvements, tools, and processes often go to /dev/null.
I learned a lot from this talk. If I have to pinpoint one: Automation is the key, but you need to talk to your quality professionals to achieve that. So why don’t you start this conversation now?
Can you also ensure you have covered the whole 9 yards of testing?
<figure class="wp-block-image size-large is-style-default">
</figure>
The Security component that puts the Sec part into the DevSecOps is vast. Often one might feel insecure in their knowledge just because we aim to focus on many things simultaneously.
Michal covered how he solved such a problem himself. The key is to identify what area to focus on and the gaps you have in your knowledge and prepare a learning plan.
Mental health is essential. Take care of yourself and reach out for help. The Cuber Security community will help you.
</figure>
Two cups of espresso later, I get tired of writing about my great DevOpsDays experience. My energy level is getting low, and I want to go and walk the dog now. While I am doing this, please reflect on the learnings from today:
Why don’t you take a short walk as well? See you in 15 minutes.
I am back. I hope you had a refreshing break in the open. I’m not too fond of commercial conferences because you always have many more questions and topics, and there is no venue to discuss them.
<figure class="wp-block-image size-large">
</figure>
DevOpsDays Prague fixes that by running an Open Space where you can propose your topic, get the people interested in discussing it, and a room or a space where you do that.
I stayed for three sessions, but I contributed to two.
Usually, the Vegas rule applies, so I am not going to share what we have discussed, but I am free to share what I have learned:
Putting some tiny structures in the Open Spaces and focusing the energy in the right direction could produce beautiful results beneficial for everyone present. I’ve seen this working!
I took the metro back to my area of Prague, still observing people around me. I am curious. I went back home full of energy and new knowledge. I know how hard it is to organize an event like this. I am speaking from experience. I have organized more than 30 of those.
Kudos to the whole crew of DevOpsDays 2023, who did this in their free time without any benefits except for the joy of providing the others with a place to meet and discuss common topics.
You should be proud of yourselves!
ankursinha)
on June 05, 2023 09:39 AM
Photo by William White on Unsplash.
Please join us at the next regular Open NeuroFedora team meeting on Monday 05 June at 1300 UTC. The meeting is a public meeting, and open for everyone to attend. You can join us over:
You can use this link to convert the meeting time to your local time. Or, you can also use this command in the terminal:
$ date --date='TZ="UTC" 1300 2023-06-05'
The meeting will be chaired by @ankursinha. The agenda for the meeting is:
We hope to see you there!
admin)
on June 05, 2023 08:00 AM
Copr is a build-system for anyone in the Fedora community. It hosts thousands of projects for various purposes and audiences. Some of them should never be installed by anyone, some are already being transitioned to the official Fedora Linux repositories, and the rest is somewhere in between. Copr gives you the opportunity to install 3rd party software that is not available in Fedora Linux repositories, try nightly versions of your dependencies, use patched builds of your favorite tools to support some non-standard use-cases, and just experiment freely.
If you don’t know how to enable a repository or if you are concerned about whether is it safe to use Copr, please consult the project documentation.
This article takes a closer look at interesting projects that recently landed in Copr.
This year it seems that anywhere you look, ChatGPT is there. This time we have a lightweight ChatGPT and DALL-E client, written in Bash, called chatGPT-shell-cli. Look for the “Commands” section at chatGPT-shell-cli for usage. This Bash script can be especially useful for systems without standard dependencies such as Python or Node.js.
<figure class="wp-block-image size-full">
</figure>
The repo currently provides chatgpt-shell-cli for Fedora 37, 38, Fedora Rawhide, RHEL8, RHEL9, and others. To install it, use these commands:
sudo dnf copr enable kylegospo/chatGPT-shell-cli sudo dnf install chatgpt-shell-cli
Note that an OpenAI API key is required to use this script. You may create an account and get a free API Key at OpenAI.
Hyprland is a beautiful looking compositor for Wayland. It provides dynamic tiling with multiple layouts, smooth animations, and endless customization options. Similarly to Sway or i3, it has a simple configuration file that doesn’t require you to know the programming language it was written in.
<figure class="wp-block-image size-full">
</figure>
The repo currently provides Hyprland for Fedora 37, 38, and Fedora Rawhide. To install it, use these commands:
sudo dnf copr enable carlwgeorge/hyprland sudo dnf install hyprland
Wezterm is a modern terminal emulator that runs on all the major operating systems. It has built-in support for terminal multiplexing, rendering images, emojis, GPU acceleration, and many more features.
<figure class="wp-block-image size-full">
</figure>
The repo currently provides Wezterm for Fedora 37, 38, and Fedora Rawhide. To install it, use these commands:
sudo dnf copr enable zjlin/majesty-dubbed-skyline sudo dnf install wezterm
htpdate is a time synchronization client for the HTTP Time Protocol (HTP). Is it better than Network Time Protocol (NTP) which is used in Fedora by default? It is not! You should use NTP if you can. However, NTP sometimes doesn’t work because of proxy or firewall restrictions. That’s when HTP and htpdate become very useful.
<figure class="wp-block-image size-full">
</figure>
The repo currently provides htpdate for Fedora 37, 38, Fedora Rawhide, Fedora ELN, RHEL8, RHEL9, and others. To install it, use these commands:
sudo dnf copr enable whitehara/htpdate sudo dnf install htpdate
If its not clear by my posts, I have not done a single technical thing after work hours as of late. I get done working, do soccer stuff for the kids if the day requires it, and then I read a book. Not sure how long this will keep up, but I do feel better this way.
bressers)
on June 05, 2023 12:00 AM
Josh and Kurt talk about namespaces. They were a topic in the last podcast, and resulted in a much much larger discussion for us. We decided to hash out some of our thinking in an episode. This is a much harder problem than either of us expected. We don’t have any great answers, but we do have a lot of questions.
<audio class="wp-audio-shortcode" controls="controls" id="audio-3130-1" preload="none" style="width: 100%;"><source src="https://traffic.libsyn.com/opensourcesecuritypodcast/Episode_378_Naming_things_is_harder_than_security.mp3?_=1" type="audio/mpeg">https://traffic.libsyn.com/opensourcesecuritypodcast/Episode_378_Naming_things_is_harder_than_security.mp3</audio>
theevilskeleton)
on June 04, 2023 12:00 AM
Recently, the article “Developers are lazy, thus Flatpak”, by Martijn Braam, was published to criticize a few things regarding Flatpak. I want to go over the article and address some points that were raised.
While Martijn, the author, contrasted Flatpak with Alpine Linux, I’m going to be contrasting Flatpak with popular Linux distributions, as, to me, it makes sense to contrast Flatpak with some of the most used distributions.
I recommend reading his article before my response, as I won’t be replying to every point raised.
While the developers like to pretend real hard that Flatpak is not a distribution, it’s still suspiciously close to one. It lacks a kernel and a few services and it lacks the standard Linux base directory specification but it’s still a distribution you need to target. Instead of providing seperate packages with a package manager it provides a runtime that comes with a bunch of dependencies. Conveniently it also provides multiple runtimes to make sure there’s not actually a single base to work on. Because sometimes you need Gnome libraries, sometimes you need KDE libraries. Since there’s no package manager those will be in seperate runtimes.
I’m not really sure who denies that Flatpak is not a distribution, but I’m certainly not one of them. If anything, this seems to be a really good thing to me, because we’re bundling a distribution and deploying it to users’ systems, meaning that they’re getting the exact same builds that we, the developers, tested against. It makes it even easier for us to troubleshoot, because the environment is near-identical.
To quote from Flatpak’s documentation: “Flatpak is a framework for distributing desktop applications across various Linux distributions.” Even Flatpak agrees that it’s a distribution.
If you need a dependency that’s not in the runtime there’s no package manager to pull in that dependency. The solution is to also package the dependencies you need yourself and let the flatpak tooling build this into the flatpak of your application. So now instead of being the developer for your application you’re also the maintainer of all the dependencies in this semi-distribution you’re shipping under the disguise of an application.
Separating every dependency would be really inconvenient, just like managing graphical apps in a Linux distribution. If, for example, a flatpak named XYZ needs 10 dependencies, whereby one of the dependencies changes the version that the developers of the XYZ flatpak have not tested, then it could lead to bugs or even breakages that would make it really difficult for developers to trace back, as they would need to frequently contact each packager and figure out together. So, as mentioned by the author, the solution is to let the developers bundle everything, as they test their apps against an environment that is easier to understand.
Separating all dependencies is easier for smaller programs and dependencies, as they have a small volume of dependencies, and thus are not as difficult for troubleshooting. However, Flatpak targets graphical apps, which are typically large and sophisticated and need a model that can scale well. In this case, letting developers manage the dependencies is a better approach, as it’s easier to maintain and troubleshoot.1
And one thing is for sure, I don’t trust application developers to maintain dependencies.
That’s completely fair, as you’re entitled to your own opinion. Likewise, I don’t trust the worryingly large amount of non-programmer/developer that package dependencies in larger distributions, especially when they have no real world experience in developing apps. Furthermore, I trust even less the package managers that allow dependencies to self-destruct in case something goes wrong.
This gets really nuts by looking at some software that deals with multimedia. Lets look at the Audacity flatpak. It builds as dependency:
- wxwidgets
- ffmpeg
- sqlite
- chrpath
- portaudio
- portmidi
So lets look at how well dependencies are managed here. Since we’re now almost exactly half a year into 2023 I’ll look at the updates for the last 6 months and compare it to the same dependencies in Alpine Linux.
- audacity has been updated 4 times in the flatpak. It has been updated 5 times on Alpine.
- ffmpeg has been updated to 6.0 in both the flatpak and Alpine, but the ffmpeg package has had 9 updates because if codecs that have been updated.
- sqlite hasn’t been updated in the flatpak and has been updated 4 times in Alpine
- wxwidgets hasn’t been updated in the flatpak and has been updated 2 times in Alpine
- chrpath hasn’t had updates
- portaudio hasn’t had updates in flatpak and Alpine.
- portmidi hasn’t had updates
This is just a random package I picked and it already had a lot more maintainance of the dependencies than the flatpak has. It most likely doesn’t scale to have all developers keep track of all the dependencies of all their software.
The main issue here is that Audacity has many technical limitations. To name one, in Audacity’s source code, it’s documented that “Audacity on Linux uses vanilla version of wxWidgets, we require that version 3.1.3 is used. This version is not available in most of the distributions.”
This is why wxWidgets in the Audacity flatpak wasn’t updated. If they updated to major versions, then they might have ran into issues. Alpine Linux, on the other hand, packages wxWidgets version 3.2.2.1, which, as seen above, is outside of the “required” version.
Even then, in this case, the amount of updates doesn’t signify which is better maintained, as context absolutely matters. It is best to consult the maintainer of the flatpak about their decision, rather than cherry picking and misinforming yourself without doing thorough investigations.
This whole section is criticizing GNOME Software, not Flatpak itself. GNOME Software is a frontend that decides how they should display flatpaks to users. If the GNOME Software developers wanted, they could display a dialog that warns the user when they try to install the app. In this case, they went against it and put it under a separate button. In my opinion, it is really unfair to blame a backend utility when the frontend does it “wrong”.2
I’ve heard many argument for Flatpaks by users and developers but in the end I can’t really say the pros outweigh the cons.
I think it’s very important that developers do not have the permissions to push whatever code they want to everyone under the disguise of a secure system. And that’s my opinion as a software developer.
Software packaged by distributions has at least some degree of scrutiny and it often results in at least making sure build flags are set to disable user tracking and such features.
As user u/natermer explains really well on Reddit: “[T]he reviewing and security benefits of distribution packaging is heavily overstated by many people defending it. Only a small number of high profile packages ever receive serious security scrutiny. For the most part the packaging authors put in just enough to work to get the software to build correctly and the dependencies to install without breaking anything and then it is up to the end users to report on any problems that crop up. Which means that the guarantees are not really much better then with stuff like “pip”.”
In the Audacity example discussed above, I mentioned that Alpine Linux packages wxWidgets version 3.2.2.1 and Audacity, which Audacity has explicitly stated to use 3.1.3. This is a good example of “the packaging authors put in just enough to work to get the software to build correctly and the dependencies to install without breaking anything and then it is up to the end users to report on any problems that crop up”. The app launching isn’t enough to conclude that it works well. While the author’s point was regarding security, I think that scrutiny beyond security is equally as important and should be mentioned.
Furthermore, this isn’t only about scrutiny, but also maintenance, or the lack thereof. Let’s look at the amount of packages that some popular distributions contain in their repositories. As of writing this article:
So, while the author is concerned that developers will “mishandle” dependencies with Flatpak, we observe that the more worrying bit is the amount of unmaintained packages on the distributions you run on your system; packages that are installed on your host. So you either choose a mishandled package on your host, or a mishandled dependency inside a container. I will happily take the latter.
I also believe software in general is better if it’s made with the expectation that it will run outside of Flatpak. It’s not that hard to make sure you don’t depend on bleeding edge versions of libraries while that’s not needed. It’s not that hard to have optional dependencies in software. It’s not that hard to actually follow XDG specifications instead of hardcoding paths.
I’ve written “Traditional Packaging is not Suitable for Modern Applications” which goes in depth with the problems of the lack of robust dependency management. To summarize, with traditional packaging systems, developers cannot cherry pick dependencies, and distributions cannot provide consistent experiences and environments if they’re not making use of the same containers or similar.
Audacity, as an example, on a traditional packaging system, if the distribution chooses to use the latest version of wxWidgets, 3.2.2.1, and the distribution ships that version, then the packagers cannot cherry pick 3.1.3 or any other version, otherwise that version will conflict with the existing version.
This isn’t only regarding versioning, but it goes as far as applying custom patches. For example, as taken from my article I linked, OBS Studio requires a few patches for ffmpeg to neatly integrate with OBS Studio. This, again, cannot be done if the distribution ships an unpatched ffmpeg or one that doesn’t have the patches OBS Studio requires to work properly, otherwise they have to find all sorts of workarounds (refer to my article).
Another problem that traditional packaging systems cannot solve is providing a consistent and predictable environment. For example, Bottles is a “fragile” piece of software, because it needs an environment for Wine and other utilities to run in secure, contained and predictable environments. I’ve written a long comment that explains why supporting traditional packaging systems is a burden for us, while being infeasible at best.
Steam, another example, uses steam-runtime-tools, which uses bubblewrap, a utility that originated from Flatpak, to contain and isolate games. Even, though, Steam is available and “supported” on many distributions, they all originate from the same archive, which means that they’re all the same binaries and thus are somewhat consistent, just like Flatpak.
As Linus Torvalds said, “[…] I guarantee you Valve will not make 15 different binaries […]” — In reality, developers who have other things to worry about cannot spend their time to build their software 5 times for 5 different Linux distributions and continuously support them. To be fair, “5” is an understatement. Instead, they want one binary, and continuously and thoroughly test that binary and ship it to users.
That’s the best thing! Developers are not supposed to be the ones packaging software so it’s not hard at all. It’s not your task to get your software in all the distributions, if your software is useful to people it tends to get pulled in. I have software that’s packaged in Alpine Linux, ALT Linux, Archlinux AUR, Debian, Devuan, Fedora, Gentoo, Kali, LiGurOS, Nix, OpenMandriva, postmarketOS, Raspbian, Rosa, Trisquel, Ubuntu and Void. I did not have to package most of this.
The most I notice from other distributions packaging my software is patches from maintainers that improve the software, usually in dealing with some edge case I forgot with a hardcoded path somewhere.
The most time I’ve ever spent on distribution packaging is actually the few pieces of software I’ve managed to push to Flathub. Dealing with differences between distributions is easy, dealing with differences between runing inside and outside Flatpak is hard.
Masochism aside, as the author wrote in the beginning of the article, “[s]adly there’s reality”. That reality is that developers do not and literally cannot deal with all the burden that distributions cause. They want something that is easy for them to maintain, while having the control to bundle everything they want, and however they see fit, because developers know how their programs work the best. They can test their apps in environments and ship the same environments to users.
If the distribution does not put an effort to make it easy for developers to package, test and ship their apps to users, then the distribution has failed to appeal the majority of developers. The decreased difficulty that Flatpak and Flathub offer is precisely why many distributions are starting to include and use Flathub by default, like Steam OS; it’s why GNOME and KDE have been focusing on Flatpak as the primary distribution method; and it’s also why Flatpak and Flathub have grown in popularity really quickly.
A second issue I’ve had on my Pinebook Pro is that it has a 64GB rootfs. Using too many flatpaks is just very wasteful of space. In theory you have a runtime that has your major dependencies and then a few Megabytes of stuff in your application flatpak. In practice I nearly have an unique platform per flatpak installed because the flatpaks depend on different versions of that platform or just on different platforms.
While I have a 256 GB SSD, I probably have more graphical apps than the average user, because I test and contribute to several apps. I would go as much as saying that my Flatpak setup is cursed, but I digress.
Many of the apps use different runtimes and different versions of runtimes. I believe that I fall into the “I nearly have an unique platform per flatpak installed because the flatpaks depend on different versions of that platform or just on different platforms” category, although I believe his statement was hyperbolic.
First, we’ll check the amount of storage all flatpaks take. I’ll be using flatpak-dedup-checker to measure the storage usage:
$ ./flatpak-dedup-checker --user
Directories: /var/home/TheEvilSkeleton/.local/share/flatpak/{runtime,app}
Size without deduplication: 89.31 GB
Size with deduplication: 37.73 GB (42% of 89.31 GB)
Size with compression: 27.66 GB (30% of 89.31 GB; 73% of 37.73 GB)
We notice that all flatpaks, without compression, take 37.73 GB in total. Let’s look at how many apps I have installed:
$ flatpak list --app --user | wc -l
173
173 graphical apps — including major browsers, such as Firefox, LibreWolf, Tor Browser, Chromium, ungoogled-chromium, Google Chrome, Brave, Microsoft Edge, and Epiphany. If you’re curious, feel free to look at all my installed apps:
$ flatpak list --app --user
Name Application ID Version Branch Origin
Dialect app.drey.Dialect 2.1.1 stable flathub
Elastic app.drey.Elastic 0.1.3 stable flathub
Cambalache ar.xjuan.Cambalache 0.10.3 stable flathub
Valent ca.andyholmes.Valent master valent-origin
Dconf Editor ca.desrt.dconf-editor 43.0 stable flathub
Decoder com.belmoussaoui.Decoder 0.3.3 stable flathub
ASHPD Demo com.belmoussaoui.ashpd.demo 0.3.0 stable flathub
Bitwarden com.bitwarden.desktop 2023.5.0 stable flathub
Boxy SVG com.boxy_svg.BoxySVG 3.96.0 stable flathub
Brave Browser com.brave.Browser 1.52.117 stable flathub
Tally for Plausible com.cassidyjames.plausible 3.0.1 stable flathub
Discord Canary com.discordapp.DiscordCanary 0.0.156 beta flathub-beta
Mindustry com.github.Anuken.Mindustry 144.3 stable flathub
ungoogled-chromium com.github.Eloston.UngoogledChromium 113.0.5672.126 stable flathub
Gradience com.github.GradienceTeam.Gradience 0.4.1 stable flathub
Desktop Files Creator com.github.alexkdeveloper.desktop-files-creator 1.2.2 stable flathub
Eyedropper com.github.finefindus.eyedropper 0.6.0 stable flathub
Rnote com.github.flxzt.rnote 0.6.0 stable flathub
Wike com.github.hugolabe.Wike 2.0.1 stable flathub
Text Pieces com.github.liferooter.textpieces 3.4.1 stable flathub
Tor Browser Launcher com.github.micahflee.torbrowser-launcher 0.3.6 stable flathub
G4Music com.github.neithern.g4music 1.13 stable flathub
Czkawka com.github.qarmin.czkawka 5.1.0 stable flathub
Clapper com.github.rafostar.Clapper 0.5.2 stable flathub
Logisim-evolution com.github.reds.LogisimEvolution 3.8.0 stable flathub
Avvie com.github.taiko2k.avvie 2.3 stable flathub
Flatseal com.github.tchx84.Flatseal 2.0.1 stable flathub
Frog com.github.tenderowl.frog 1.3.0 stable flathub
Video Downloader com.github.unrud.VideoDownloader 0.12.4 stable flathub
Easy Effects com.github.wwmm.easyeffects 7.0.4 stable flathub
NewsFlash com.gitlab.newsflash 2.3.0 stable flathub
Google Chrome com.google.Chrome 113.0.5672.126-1 stable flathub
Inochi Creator com.inochi2d.inochi-creator 0.8.0 stable flathub
qView com.interversehq.qView 5.0 stable flathub
GtkStressTesting com.leinardi.gst 0.7.5 stable flathub
Forge Sparks com.mardojai.ForgeSparks 0.1.1 stable flathub
Extension Manager com.mattjakeman.ExtensionManager 0.4.0 stable flathub
Microsoft Edge com.microsoft.Edge 114.0.1823.37-1 stable flathub
OBS Studio com.obsproject.Studio 29.1.2 stable flathub
Share Preview com.rafaelmardojai.SharePreview 0.3.0 stable flathub
Black Box com.raggesilver.BlackBox 0.13.2 stable flathub
Geopard com.ranfdev.Geopard 1.4.0 stable flathub
Transmission com.transmissionbt.Transmission 4.0.3 stable flathub
Bottles com.usebottles.bottles 51.6 master bottles-origin
Bottles com.usebottles.bottles 51.6 stable flathub
Steam com.valvesoftware.Steam 1.0.0.75 stable flathub
Visual Studio Code com.visualstudio.code 1.78.2-1683731010 stable flathub
Fragments de.haeckerfelix.Fragments 2.1.1 stable flathub
Tubefeeder de.schmidhuberj.tubefeeder v1.9.4 master tubefeeder-origin
Tubefeeder de.schmidhuberj.tubefeeder v1.9.6 stable flathub
Tuba dev.geopjr.Tuba 0.3.2 stable flathub
Forecast dev.salaniLeo.forecast 0.1.0 stable flathub
HandBrake fr.handbrake.ghb 1.6.1 stable flathub
Metadata Cleaner fr.romainvigier.MetadataCleaner 2.5.2 stable flathub
Cartridges hu.kramo.Cartridges 1.5.4 stable flathub
Element im.riot.Riot 1.11.31 stable flathub
Cinny in.cinny.Cinny 2.2.6 stable flathub
Komikku info.febvre.Komikku 1.21.1 stable flathub
Amberol io.bassi.Amberol 0.10.3 stable flathub
Bavarder io.github.Bavarder.Bavarder 0.2.3 stable flathub
AdwSteamGtk io.github.Foldex.AdwSteamGtk 0.6.0 stable flathub
Youtube Downloader Plus io.github.aandrew_me.ytdn 3.14.0 stable flathub
Epic Asset Manager io.github.achetagames.epic_asset_manager 3.8.4 stable flathub
GPU-Viewer io.github.arunsivaramanneo.GPUViewer 2.26 stable flathub
Celluloid io.github.celluloid_player.Celluloid 0.25 stable flathub
Escambo io.github.cleomenezesjr.Escambo 0.1.1 stable flathub
PinApp io.github.fabrialberio.pinapp 1.1.7 stable flathub
Monitorets io.github.jorchube.monitorets 0.10.0 stable flathub
AppImage Pool io.github.prateekmedia.appimagepool 5.1.0 stable flathub
Kooha io.github.seadve.Kooha 2.2.3 stable flathub
Mousai io.github.seadve.Mousai 0.7.5 stable flathub
WebCord io.github.spacingbat3.webcord 4.2.0 stable flathub
Converter io.gitlab.adhami3310.Converter 1.6.1 stable flathub
Sudoku Solver io.gitlab.cyberphantom52.sudoku_solver 1.0.1 stable flathub
Letterpress io.gitlab.gregorni.ASCIIImages 1.3.0 stable flathub
Calligraphy io.gitlab.gregorni.Calligraphy 1.0.0 stable flathub
LibreWolf io.gitlab.librewolf-community 113.0.2-1 stable flathub
Upscaler io.gitlab.theevilskeleton.Upscaler master upscaler3-origin
Upscaler io.gitlab.theevilskeleton.Upscaler 1.1.2 stable flathub
Upscaler io.gitlab.theevilskeleton.Upscaler 1.1.2 test upscaler1-origin
Devel io.gitlab.theevilskeleton.Upscaler.Devel master devel-origin
Dev Toolbox me.iepure.devtoolbox 1.0.2 stable flathub
Passes me.sanchezrodriguez.passes 0.7 stable flathub
Lutris net.lutris.Lutris 0.5.13 stable flathub
Mullvad Browser net.mullvad.MullvadBrowser 102.9.0esr-12.0-2-build1 stable flathub
Poedit net.poedit.Poedit 3.3.1 stable flathub
RPCS3 net.rpcs3.RPCS3 0.0.28-1-33558d14 stable flathub
Live Captions net.sapples.LiveCaptions 0.4.0 stable flathub
Color Picker nl.hjdskes.gcolor3 2.4.0 stable flathub
Audacity org.audacityteam.Audacity 3.3.2 stable flathub
Chromium Web Browser org.chromium.Chromium 114.0.5735.90 stable flathub
Chromium application base org.chromium.Chromium.BaseApp 21.08 flathub
Electron2 application base org.electronjs.Electron2.BaseApp 21.08 flathub
Electron2 application base org.electronjs.Electron2.BaseApp 22.08 flathub
Flatpak External Data Checker org.flathub.flatpak-external-data-checker stable flathub
Builder org.flatpak.Builder stable flathub
Piper org.freedesktop.Piper 0.7 stable flathub
VulkanInfo org.freedesktop.Platform.VulkanInfo 22.08 flathub
appstream-glib org.freedesktop.appstream-glib 0.8.1 stable flathub
Feeds org.gabmus.gfeeds 2.2.0 stable flathub
Giara org.gabmus.giara 1.1.0 stable flathub
Zola org.getzola.zola 0.17.2 stable flathub
GNU Image Manipulation Program org.gimp.GIMP 2.99.14 beta flathub-beta
GNU Image Manipulation Program org.gimp.GIMP 2.10.34 master gnome-nightly
GNU Image Manipulation Program org.gimp.GIMP 2.10.34 stable flathub
Adwaita Demo org.gnome.Adwaita1.Demo 1.4.alpha master gnome-nightly
Boxes org.gnome.Boxes 44.2 stable flathub
Builder org.gnome.Builder 44.2 stable flathub
Calculator org.gnome.Calculator 44.0 stable flathub
Calendar org.gnome.Calendar 44.0 stable flathub
Contacts org.gnome.Contacts 44.0 stable flathub
Devhelp org.gnome.Devhelp 43.0 stable flathub
Web org.gnome.Epiphany 44.3 stable flathub
File Roller org.gnome.FileRoller 43.0 stable flathub
Firmware org.gnome.Firmware 43.2 stable flathub
Fractal org.gnome.Fractal.Devel 5~beta1-c3d77b7 master gnome-nightly
Geary org.gnome.Geary 43.0 stable flathub
Glade org.gnome.Glade 3.40.0 stable flathub
Lollypop org.gnome.Lollypop 1.4.37 stable flathub
Loupe org.gnome.Loupe 44.3 stable flathub
Maps org.gnome.Maps 44.2 stable flathub
Files org.gnome.NautilusDevel 44.1 master gnome-nightly
Notes org.gnome.Notes 40.1 stable flathub
Document Scanner org.gnome.SimpleScan 44.0 stable flathub
Text Editor org.gnome.TextEditor 44.0 stable flathub
Endeavour org.gnome.Todo 43.0 stable flathub
Videos org.gnome.Totem 43.0 stable flathub
Weather org.gnome.Weather 44.0 stable flathub
Pika Backup org.gnome.World.PikaBackup 0.6.1 stable flathub
Secrets org.gnome.World.Secrets 7.3 stable flathub
Clocks org.gnome.clocks 44.0 stable flathub
App Icon Preview org.gnome.design.AppIconPreview 3.3.0 stable flathub
Contrast org.gnome.design.Contrast 0.0.8 stable flathub
Emblem org.gnome.design.Emblem 1.2.0 stable flathub
Icon Library org.gnome.design.IconLibrary 0.0.16 stable flathub
Lorem org.gnome.design.Lorem 1.2 stable flathub
Color Palette org.gnome.design.Palette 2.0.2 stable flathub
Symbolic Preview org.gnome.design.SymbolicPreview 0.0.8 stable flathub
Typography org.gnome.design.Typography 0.2.0 stable flathub
Fonts org.gnome.font-viewer 44.0 stable flathub
Identity org.gnome.gitlab.YaLTeR.Identity 0.5.0 stable flathub
Iotas org.gnome.gitlab.cheywood.Iotas 0.1.16 stable flathub
Apostrophe org.gnome.gitlab.somas.Apostrophe 2.6.3 stable flathub
GTK Demo org.gtk.Demo4 master gnome-nightly
Inkscape org.inkscape.Inkscape 1.2.2 stable flathub
JDownloader org.jdownloader.JDownloader 2.0 stable flathub
Dolphin org.kde.dolphin 23.04.1 stable flathub
Kdenlive org.kde.kdenlive 23.04.1 stable flathub
Krita org.kde.krita 5.1.5 stable flathub
NeoChat org.kde.neochat 23.04.1 stable flathub
Xwayland Video Bridge org.kde.xwaylandvideobridge master xwaylandvideobridge-origin
KeePassXC org.keepassxc.KeePassXC 2.7.5 stable flathub
LibreOffice org.libreoffice.LibreOffice 7.5.3.2 stable flathub
Thunderbird org.mozilla.Thunderbird 102.11.2 stable flathub
Firefox org.mozilla.firefox 113.0.2 stable flathub
Tagger org.nickvision.tagger 2022.11.2 stable flathub
Nicotine+ org.nicotine_plus.Nicotine 3.2.9 stable flathub
ONLYOFFICE Desktop Editors org.onlyoffice.desktopeditors 7.3.3 stable flathub
Helvum org.pipewire.Helvum 0.4.0 stable flathub
qBittorrent org.qbittorrent.qBittorrent 4.5.3 stable flathub
Tenacity org.tenacityaudio.Tenacity 1.3-beta3 test tenacity-origin
Wine org.winehq.Wine 7.0 stable-21.08 flathub
Wine org.winehq.Wine 8.0 stable-22.08 flathub
Zrythm org.zrythm.Zrythm 1.0.0-beta.4.9.1 stable flathub
Imaginer page.codeberg.Imaginer.Imaginer 0.2.2 stable flathub
Atoms pm.mirko.Atoms 1.1.1 stable flathub
Commit re.sonny.Commit 4.0 stable flathub
Oh My SVG re.sonny.OhMySVG 1.2 stable flathub
Playhouse re.sonny.Playhouse 1.1 stable flathub
Workbench re.sonny.Workbench 44.1 stable flathub
Graphs se.sjoerd.Graphs 1.5.2 stable flathub
Cawbird uk.co.ibboard.cawbird 1.5 stable flathub
ArmCord xyz.armcord.ArmCord 3.2.0 stable flathub
Alright, let’s look at the amount of runtimes installed:
$ flatpak list --runtime --user | wc -l
97
And the runtimes themselves:
$ flatpak list --runtime --user
Name Application ID Version Branch Origin
Codecs com.github.Eloston.UngoogledChromium.Codecs stable flathub
Proton (community build) com.valvesoftware.Steam.CompatibilityTool.Proton 7.0-6 beta flathub-beta
Proton (community build) com.valvesoftware.Steam.CompatibilityTool.Proton 7.0-5 stable flathub
Proton experimental (community build) com.valvesoftware.Steam.CompatibilityTool.Proton-Exp 7.0-20230208 stable flathub
Proton-GE (community build) com.valvesoftware.Steam.CompatibilityTool.Proton-GE 8.3-1 beta flathub-beta
Proton-GE (community build) com.valvesoftware.Steam.CompatibilityTool.Proton-GE 8.3-1 stable flathub
gamescope com.valvesoftware.Steam.Utility.gamescope 3.11.51 stable flathub
Codecs org.audacityteam.Audacity.Codecs stable flathub
Codecs org.chromium.Chromium.Codecs stable flathub
Calf org.freedesktop.LinuxAudio.Plugins.Calf 0.90.3 22.08 flathub
LSP org.freedesktop.LinuxAudio.Plugins.LSP 1.2.6 22.08 flathub
MDA org.freedesktop.LinuxAudio.Plugins.MDA 1.2.10 22.08 flathub
TAP-plugins org.freedesktop.LinuxAudio.Plugins.TAP 1.0.1 22.08 flathub
ZamPlugins org.freedesktop.LinuxAudio.Plugins.ZamPlugins 4.1 22.08 flathub
SWH org.freedesktop.LinuxAudio.Plugins.swh 0.4.17 22.08 flathub
Freedesktop Platform org.freedesktop.Platform 21.08.18 21.08 flathub
Freedesktop Platform org.freedesktop.Platform 22.08.12.1 22.08 flathub
i386 org.freedesktop.Platform.Compat.i386 21.08 flathub
i386 org.freedesktop.Platform.Compat.i386 22.08 flathub
Mesa org.freedesktop.Platform.GL.default 21.3.9 21.08 flathub
Mesa org.freedesktop.Platform.GL.default 23.1.1 22.08 flathub
Mesa (Extra) org.freedesktop.Platform.GL.default 23.1.1 22.08-extra flathub
Mesa git snapshot org.freedesktop.Platform.GL.mesa-git 23.0-branchpoint-4408-g4ac56e3e5a4 23.08beta flathub-beta
default org.freedesktop.Platform.GL32.default 21.08 flathub
Mesa org.freedesktop.Platform.GL32.default 23.1.1 22.08 flathub
Mesa (Extra) org.freedesktop.Platform.GL32.default 23.1.1 22.08-extra flathub
Mesa git snapshot org.freedesktop.Platform.GL32.mesa-git 23.0-branchpoint-4408-g4ac56e3e5a4 23.08beta flathub-beta
MangoHud org.freedesktop.Platform.VulkanLayer.MangoHud 0.6.9-1 22.08 flathub
vkBasalt org.freedesktop.Platform.VulkanLayer.vkBasalt 0.3.2.9 22.08 flathub
ffmpeg-full org.freedesktop.Platform.ffmpeg-full 21.08 flathub
ffmpeg-full org.freedesktop.Platform.ffmpeg-full 22.08 flathub
i386 org.freedesktop.Platform.ffmpeg_full.i386 21.08 flathub
i386 org.freedesktop.Platform.ffmpeg_full.i386 22.08 flathub
openh264 org.freedesktop.Platform.openh264 2.1.0 2.0 flathub
openh264 org.freedesktop.Platform.openh264 2.1.0 2.0beta flathub-beta
openh264 org.freedesktop.Platform.openh264 2.1.0 2.2.0 flathub
openh264 org.freedesktop.Platform.openh264 2.1.0 2.2.0beta gnome-nightly
Freedesktop SDK org.freedesktop.Sdk 21.08.18 21.08 flathub
Freedesktop SDK org.freedesktop.Sdk 22.08.12.1 22.08 flathub
i386 org.freedesktop.Sdk.Compat.i386 21.08 flathub
i386 org.freedesktop.Sdk.Compat.i386 22.08 flathub
.NET Core SDK extension org.freedesktop.Sdk.Extension.dotnet6 6.0.408 21.08 flathub
Free Pascal Compiler and Lazarus org.freedesktop.Sdk.Extension.freepascal 3.2.2 21.08 flathub
Go programming language Sdk extension org.freedesktop.Sdk.Extension.golang 1.20.2 21.08 flathub
OpenJDK 11 SDK Extension org.freedesktop.Sdk.Extension.openjdk11 21.08 flathub
OpenJDK 17 SDK Extension org.freedesktop.Sdk.Extension.openjdk17 22.08 flathub
Rust stable org.freedesktop.Sdk.Extension.rust-stable 1.67.0 21.08 flathub
Rust stable org.freedesktop.Sdk.Extension.rust-stable 1.70.0 22.08 flathub
toolchain-i386 org.freedesktop.Sdk.Extension.toolchain-i386 21.08 flathub
toolchain-i386 org.freedesktop.Sdk.Extension.toolchain-i386 22.08 flathub
toolchain-i386 org.freedesktop.Sdk.Extension.toolchain-i386 22.08beta flathub-beta
GNOME Boxes Osinfo DB org.gnome.Boxes.Extension.OsinfoDb 20230518 stable flathub
HEIC org.gnome.Loupe.HEIC stable flathub
GNOME Application Platform version 41 org.gnome.Platform 41 flathub
GNOME Application Platform version 42 org.gnome.Platform 42 flathub
GNOME Application Platform version 43 org.gnome.Platform 43 flathub
GNOME Application Platform version 44 org.gnome.Platform 44 flathub
GNOME Application Platform version Nightly org.gnome.Platform master gnome-nightly
i386 org.gnome.Platform.Compat.i386 41 flathub
i386 org.gnome.Platform.Compat.i386 43 flathub
i386 org.gnome.Platform.Compat.i386 44 flathub
GNOME Software Development Kit version 41 org.gnome.Sdk 41 flathub
GNOME Software Development Kit version 42 org.gnome.Sdk 42 flathub
GNOME Software Development Kit version 43 org.gnome.Sdk 43 flathub
GNOME Software Development Kit version 44 org.gnome.Sdk 44 flathub
GNOME Software Development Kit version Nightly org.gnome.Sdk master gnome-nightly
i386 org.gnome.Sdk.Compat.i386 41 flathub
i386 org.gnome.Sdk.Compat.i386 42 flathub
i386 org.gnome.Sdk.Compat.i386 43 flathub
i386 org.gnome.Sdk.Compat.i386 44 flathub
i386 org.gnome.Sdk.Compat.i386 master gnome-nightly
Codecs org.gnome.Totem.Codecs stable flathub
yt-dl totem-pl-parser plugin org.gnome.Totem.Videosite.YouTubeDl stable flathub
Adwaita dark GTK theme org.gtk.Gtk3theme.Adwaita-dark 3.22 flathub
adw-gtk3 Gtk Theme org.gtk.Gtk3theme.adw-gtk3 3.22 flathub
adw-gtk3-dark Gtk Theme org.gtk.Gtk3theme.adw-gtk3-dark 3.22 flathub
Adwaita theme org.kde.KStyle.Adwaita 6.4 flathub
Kvantum theme engine org.kde.KStyle.Kvantum 1.0.6 5.15-21.08 flathub
KDE Application Platform org.kde.Platform 5.15-21.08 flathub
KDE Application Platform org.kde.Platform 5.15-22.08 flathub
KDE Application Platform org.kde.Platform 6.4 flathub
QGnomePlatform org.kde.PlatformTheme.QGnomePlatform 5.15-21.08 flathub
QGnomePlatform org.kde.PlatformTheme.QGnomePlatform 5.15-22.08 flathub
QGnomePlatform org.kde.PlatformTheme.QGnomePlatform 6.4 flathub
QtSNI org.kde.PlatformTheme.QtSNI 5.15-21.08 flathub
KDE Software Development Kit org.kde.Sdk 5.15-21.08 flathub
KDE Software Development Kit org.kde.Sdk 6.4 flathub
QGnomePlatform-decoration org.kde.WaylandDecoration.QGnomePlatform-decoration 5.15-21.08 flathub
QGnomePlatform-decoration org.kde.WaylandDecoration.QGnomePlatform-decoration 5.15-22.08 flathub
QGnomePlatform-decoration org.kde.WaylandDecoration.QGnomePlatform-decoration 6.4 flathub
Codecs org.kde.krita.Codecs stable flathub
DXVK org.winehq.Wine.DLLs.dxvk 1.10.3 stable-21.08 flathub
DXVK org.winehq.Wine.DLLs.dxvk 1.10.3 stable-22.08 flathub
Gecko org.winehq.Wine.gecko stable-21.08 flathub
Gecko org.winehq.Wine.gecko stable-22.08 flathub
Mono org.winehq.Wine.mono stable-21.08 flathub
Mono org.winehq.Wine.mono stable-22.08 flathub
In that output, here are some of the interesting bits:
GNOME Application Platform version 41 org.gnome.Platform 41 flathub
GNOME Application Platform version 42 org.gnome.Platform 42 flathub
GNOME Application Platform version 43 org.gnome.Platform 43 flathub
GNOME Application Platform version 44 org.gnome.Platform 44 flathub
GNOME Application Platform version Nightly org.gnome.Platform master gnome-nightly
[…]
KDE Application Platform org.kde.Platform 5.15-21.08 flathub
KDE Application Platform org.kde.Platform 5.15-22.08 flathub
KDE Application Platform org.kde.Platform 6.4 flathub
[…]
DXVK org.winehq.Wine.DLLs.dxvk 1.10.3 stable-21.08 flathub
DXVK org.winehq.Wine.DLLs.dxvk 1.10.3 stable-22.08 flathub
Gecko org.winehq.Wine.gecko stable-21.08 flathub
Gecko org.winehq.Wine.gecko stable-22.08 flathub
Mono org.winehq.Wine.mono stable-21.08 flathub
Mono org.winehq.Wine.mono stable-22.08 flathub
We can observe that, just like the author, I have many different versions of runtimes. Even with an unusual amount of runtimes and apps, Flatpak somehow manages to use 37.73 GB, even with most browsers installed as a flatpak.
I imagine that most users have a small selection of apps installed, which only come with a few runtimes and a version apart, which also means that my setup is possibly one of the worst case scenarios. Even with that amount of torture, Flatpak still manages to handle storage fairly well.
I wouldn’t say Flatpak is completely useless. For certain usecases it is great to have available. It think Flatpak makes most sense for when closed source software would need to be distributed.
This is something that is really important to address: Flatpak (Flathub) makes even more sense for free and open-source (FOSS) apps than closed source, because they make apps easily discoverable. For example, Upscaler, an app I developed as a final assignment in CS50x and published it on Flathub on November 16 2022, was featured on OMG! Ubuntu! on that same day (hover over the date for the published date). Another example, gregorni, a friend of mine, published Calligraphy on June 1 2023, which was featured on OMG! Linux! on that same day.
While it makes a lot of sense for closed source apps to publish their apps on Flathub, in my opinion, FOSS apps get even more benefits than closed source apps, because news outlets, especially the FOSS targeted ones, will quickly discover your apps, and might even write an article about them. This also means that more users will discover your apps, which helps it grow in popularity. This also means that you’re not forced to rely on GitHub to make your app discoverable. You could actually use Codeberg and have your apps easily discoverable if they are published on stores that are designed to be discovered.
Imaginer and Bavarder are some GTK4+libadwaita apps that are primarily available on Codeberg, yet both gain more than 100 downloads a day on average, which is a pretty big achievement in my opinion.
In the end, I respect the opinion of disliking Flatpak, as we all have different opinions and disagree on many things. However, there is a difference between having an opinion, and being misinformed and displaying them to viewers or readers, especially when it can potentially hurt the community who are working really hard on addressing genuine issues on the Linux desktop.
As an app developer, I cannot predict users’ setups; I prefer not to waste my time to learn what version of XYZ dependency Fedora Linux, Debian, Ubuntu, Arch Linux, etc. package. I prefer not to waste my time to refer users to Bugzilla, mailing lists, IRC or other inconvenient platforms that no one wants to use, and later figure out that they’re packaging a 6 month old version of my app. Instead, I prefer to devote my time in fixing actual bugs, adding new features, tweak some designs, work on other projects, write articles, or, you know, touch grass for once.
Footnotes
theevilskeleton)
on June 04, 2023 12:00 AM
Recently, the article “Developers are lazy, thus Flatpak”, by Martijn Braam, was published to criticize a few things regarding Flatpak. I want to go over the article and address some points that were raised.
While Martijn, the author, contrasted Flatpak with Alpine Linux, I’m going to be contrasting Flatpak with popular Linux distributions, as, to me, it makes sense to contrast Flatpak with some of the most used distributions.
I recommend reading his article before my response, as I won’t be replying to every point raised.
While the developers like to pretend real hard that Flatpak is not a distribution, it’s still suspiciously close to one. It lacks a kernel and a few services and it lacks the standard Linux base directory specification but it’s still a distribution you need to target. Instead of providing seperate [sic] packages with a package manager it provides a runtime that comes with a bunch of dependencies. Conveniently it also provides multiple runtimes to make sure there’s not actually a single base to work on. Because sometimes you need Gnome libraries, sometimes you need KDE libraries. Since there’s no package manager those will be in seperate [sic] runtimes.
I’m not really sure who denies that Flatpak is a distribution, but I’m certainly not one of them. If anything, this seems to be a really good thing to me, because we’re bundling a distribution and deploying it to users’ systems, meaning that they’re getting the exact same builds that we, the developers, tested against. It makes it even easier for us to troubleshoot, because the environment is near-identical.
To quote from Flatpak’s documentation: “Flatpak is a framework for distributing desktop applications across various Linux distributions.” Even Flatpak agrees that it’s a distribution.
If you need a dependency that’s not in the runtime there’s no package manager to pull in that dependency. The solution is to also package the dependencies you need yourself and let the flatpak tooling build this into the flatpak of your application. So now instead of being the developer for your application you’re also the maintainer of all the dependencies in this semi-distribution you’re shipping under the disguise of an application.
Separating every dependency would be really inconvenient, just like managing graphical apps in a Linux distribution. If, for example, a flatpak named XYZ needs 10 dependencies, whereby one of the dependencies changes the version that the developers of the XYZ flatpak have not tested, then it could lead to bugs or even breakages that would make it really difficult for developers to trace back, as they would need to frequently contact each packager and figure out together. So, as mentioned by the author, the solution is to let the developers bundle everything, as they test their apps against an environment that is easier to understand.
Separating all dependencies is easier for smaller programs and dependencies, as they have a small volume of dependencies, and thus are not as difficult for troubleshooting. However, Flatpak targets graphical apps, which are typically large and sophisticated and need a model that can scale well. In this case, letting developers manage the dependencies is a better approach, as it’s easier to maintain and troubleshoot.1
And one thing is for sure, I don’t trust application developers to maintain dependencies.
That’s completely fair, as you’re entitled to your own opinion. Likewise, I don’t trust the worryingly large amount of non-programmers/developers that package dependencies in larger distributions, especially when they have no real world experience in developing apps. Furthermore, I trust even less the package managers that allow dependencies to self-destruct in case something goes wrong.
This gets really nuts by looking at some software that deals with multimedia. Lets [sic] look at the Audacity flatpak. It builds as dependency:
- wxwidgets
- ffmpeg
- sqlite
- chrpath
- portaudio
- portmidi
So lets [sic] look at how well dependencies are managed here. Since we’re now almost exactly half a year into 2023 I’ll look at the updates for the last 6 months and compare it to the same dependencies in Alpine Linux.
- audacity has been updated 4 times in the flatpak. It has been updated 5 times on Alpine.
- ffmpeg has been updated to 6.0 in both the flatpak and Alpine, but the ffmpeg package has had 9 updates because if [sic] codecs that have been updated.
- sqlite hasn’t been updated in the flatpak and has been updated 4 times in Alpine
- wxwidgets hasn’t been updated in the flatpak and has been updated 2 times in Alpine
- chrpath hasn’t had updates
- portaudio hasn’t had updates in flatpak and Alpine.
- portmidi hasn’t had updates
This is just a random package I picked and it already had a lot more maintainance of the dependencies than the flatpak has. It most likely doesn’t scale to have all developers keep track of all the dependencies of all their software.
The main issue here is that Audacity has many technical limitations. To name one, in Audacity’s source code, it’s documented that “Audacity on Linux uses vanilla version of wxWidgets, we require that version 3.1.3 is used. This version is not available in most of the distributions.”
This is why wxWidgets in the Audacity flatpak wasn’t updated. If they updated to major versions, then they might have ran into issues. Alpine Linux, on the other hand, packages wxWidgets version 3.2.2.1, which, as seen above, is outside of the “required” version.
Even then, in this case, the amount of updates doesn’t signify which is better maintained, as context absolutely matters. It is best to consult the maintainer of the flatpak about their decision, rather than cherry picking and misinforming yourself without doing thorough investigations.
This whole section is criticizing GNOME Software, not Flatpak itself. GNOME Software is a frontend that decides how they should display flatpaks to users. If the GNOME Software developers wanted, they could display a dialog that warns the user when they try to install the app. In this case, they went against it and put it under a separate button. In my opinion, it is really unfair to blame a backend utility when the frontend does it “wrong”.2
I’ve heard many argument for Flatpaks by users and developers but in the end I can’t really say the pros outweigh the cons.
I think it’s very important that developers do not have the permissions to push whatever code they want to everyone under the disguise of a secure system. And that’s my opinion as a software developer.
Software packaged by distributions has at least some degree of scrutiny and it often results in at least making sure build flags are set to disable user tracking and such features.
As user u/natermer explains really well on Reddit: “the reviewing and security benefits of distribution packaging is [sic] heavily overstated by many people defending it. Only a small number of high profile packages ever receive serious security scrutiny. For the most part the packaging authors put in just enough to [sic] work to get the software to build correctly and the dependencies to install without breaking anything and then it is up to the end users to report on any problems that crop up. Which means that the guarantees are not really much better then [sic] with stuff like “pip”.”
In the Audacity example discussed above, I mentioned that Alpine Linux packages wxWidgets version 3.2.2.1 and Audacity, which Audacity has explicitly stated to use 3.1.3. This is a good example of the packaging authors putting in just enough work to get the software to build. The app launching isn’t enough to conclude that it works well. While the author’s point was regarding security, I think that scrutiny beyond security is equally as important and should be mentioned.
Furthermore, this isn’t only about scrutiny, but also maintenance, or the lack thereof. Let’s look at the amount of packages that some popular distributions contain in their repositories. As of writing this article:
So, while the author is concerned that developers will “mishandle” dependencies with Flatpak, we observe that the more worrying bit is the amount of unmaintained packages on the distributions you run on your system; packages that are installed on your host. So you either choose a mishandled package on your host, or a mishandled dependency inside a container. I will happily take the latter.
I also believe software in general is better if it’s made with the expectation that it will run outside of Flatpak. It’s not that hard to make sure you don’t depend on bleeding edge versions of libraries while that’s not needed. It’s not that hard to have optional dependencies in software. It’s not that hard to actually follow XDG specifications instead of hardcoding paths.
I’ve written “Traditional Packaging is not Suitable for Modern Applications” which goes in depth with the problems of the lack of robust dependency management. To summarize, with traditional packaging systems, developers cannot cherry pick dependencies, and distributions cannot provide consistent experiences and environments if they’re not making use of the same containers or similar.
Audacity, as an example, on a traditional packaging system, if the distribution chooses to use the latest version of wxWidgets, 3.2.2.1, and the distribution ships that version, then the packagers cannot cherry pick 3.1.3 or any other version, otherwise that version will conflict with the existing version.
This isn’t only regarding versioning, but it goes as far as applying custom patches. For example, as taken from my article I linked, OBS Studio requires a few patches for ffmpeg to neatly integrate with OBS Studio. This, again, cannot be done if the distribution ships an unpatched ffmpeg or one that doesn’t have the patches OBS Studio requires to work properly, otherwise they have to find all sorts of workarounds (refer to my article).
Another problem that traditional packaging systems cannot solve is providing a consistent and predictable environment. For example, Bottles is a “fragile” piece of software, because it needs an environment for Wine and other utilities to run in secure, contained and predictable environments. I’ve written a long comment that explains why supporting traditional packaging systems is a burden for us, while being infeasible at best.
Steam, another example, uses steam-runtime-tools, which uses bubblewrap, a utility that originated from Flatpak, to contain and isolate games. Even, though, Steam is available and “supported” on many distributions, they all originate from the same archive, which means that they’re all the same binaries and thus are somewhat consistent, just like Flatpak.
As Linus Torvalds said, “[…] I guarantee you Valve will not make 15 different binaries […]” — In reality, developers who have other things to worry about cannot spend their time to build their software 5 times for 5 different Linux distributions and continuously support them. To be fair, “5” is an understatement. Instead, they want one binary, and continuously and thoroughly test that binary and ship it to users.
That’s the best thing! Developers are not supposed to be the ones packaging software so it’s not hard at all. It’s not your task to get your software in all the distributions, if your software is useful to people it tends to get pulled in. I have software that’s packaged in Alpine Linux, ALT Linux, Archlinux AUR, Debian, Devuan, Fedora, Gentoo, Kali, LiGurOS, Nix, OpenMandriva, postmarketOS, Raspbian, Rosa, Trisquel, Ubuntu and Void. I did not have to package most of this.
The most I notice from other distributions packaging my software is patches from maintainers that improve the software, usually in dealing with some edge case I forgot with a hardcoded path somewhere.
The most time I’ve ever spent on distribution packaging is actually the few pieces of software I’ve managed to push to Flathub. Dealing with differences between distributions is easy, dealing with differences between runing [sic] inside and outside Flatpak is hard.
Masochism aside, as the author wrote in the beginning of the article, “[s]adly there’s reality”. That reality is that developers do not and literally cannot deal with all the burden that distributions cause. They want something that is easy for them to maintain, while having the control to bundle everything they want, and however they see fit, because developers know how their programs work the best. They can test their apps in environments and ship the same environments to users.
If the distribution does not put an effort to make it easy for developers to package, test and ship their apps to users, then the distribution has failed to appeal the majority of developers. The decreased difficulty that Flatpak and Flathub offer is precisely why many distributions are starting to include and use Flathub by default, like Steam OS; it’s why GNOME and KDE have been focusing on Flatpak as the primary distribution method; and it’s also why Flatpak and Flathub have grown in popularity really quickly.
A second issue I’ve had on my Pinebook Pro is that it has a 64GB rootfs. Using too many flatpaks is just very wasteful of space. In theory you have a runtime that has your major dependencies and then a few Megabytes of stuff in your application flatpak. In practice I nearly have an [sic] unique platform per flatpak installed because the flatpaks depend on different versions of that platform or just on different platforms.
While I have a 256 GB SSD, I probably have more graphical apps than the average user, because I test and contribute to several apps. I would go as much as saying that my Flatpak setup is cursed, but I digress.
Many of the apps use different runtimes and different versions of runtimes. I believe that I fall into the “I nearly have a unique platform per flatpak installed” category, although I believe his statement was hyperbolic.
First, we’ll check the amount of storage all flatpaks take. I’ll be using flatpak-dedup-checker to measure the storage usage:
$ ./flatpak-dedup-checker --user
Directories: /var/home/TheEvilSkeleton/.local/share/flatpak/{runtime,app}
Size without deduplication: 89.31 GB
Size with deduplication: 37.73 GB (42% of 89.31 GB)
Size with compression: 27.66 GB (30% of 89.31 GB; 73% of 37.73 GB)
We notice that all flatpaks, without compression, take 37.73 GB in total. Let’s look at how many apps I have installed:
$ flatpak list --app --user | wc -l
173
173 graphical apps — including major browsers, such as Firefox, LibreWolf, Tor Browser, Chromium, ungoogled-chromium, Google Chrome, Brave, Microsoft Edge, and Epiphany. If you’re curious, feel free to look at all my installed apps:
$ flatpak list --app --user
Name Application ID Version Branch Origin
Dialect app.drey.Dialect 2.1.1 stable flathub
Elastic app.drey.Elastic 0.1.3 stable flathub
Cambalache ar.xjuan.Cambalache 0.10.3 stable flathub
Valent ca.andyholmes.Valent master valent-origin
Dconf Editor ca.desrt.dconf-editor 43.0 stable flathub
Decoder com.belmoussaoui.Decoder 0.3.3 stable flathub
ASHPD Demo com.belmoussaoui.ashpd.demo 0.3.0 stable flathub
Bitwarden com.bitwarden.desktop 2023.5.0 stable flathub
Boxy SVG com.boxy_svg.BoxySVG 3.96.0 stable flathub
Brave Browser com.brave.Browser 1.52.117 stable flathub
Tally for Plausible com.cassidyjames.plausible 3.0.1 stable flathub
Discord Canary com.discordapp.DiscordCanary 0.0.156 beta flathub-beta
Mindustry com.github.Anuken.Mindustry 144.3 stable flathub
ungoogled-chromium com.github.Eloston.UngoogledChromium 113.0.5672.126 stable flathub
Gradience com.github.GradienceTeam.Gradience 0.4.1 stable flathub
Desktop Files Creator com.github.alexkdeveloper.desktop-files-creator 1.2.2 stable flathub
Eyedropper com.github.finefindus.eyedropper 0.6.0 stable flathub
Rnote com.github.flxzt.rnote 0.6.0 stable flathub
Wike com.github.hugolabe.Wike 2.0.1 stable flathub
Text Pieces com.github.liferooter.textpieces 3.4.1 stable flathub
Tor Browser Launcher com.github.micahflee.torbrowser-launcher 0.3.6 stable flathub
G4Music com.github.neithern.g4music 1.13 stable flathub
Czkawka com.github.qarmin.czkawka 5.1.0 stable flathub
Clapper com.github.rafostar.Clapper 0.5.2 stable flathub
Logisim-evolution com.github.reds.LogisimEvolution 3.8.0 stable flathub
Avvie com.github.taiko2k.avvie 2.3 stable flathub
Flatseal com.github.tchx84.Flatseal 2.0.1 stable flathub
Frog com.github.tenderowl.frog 1.3.0 stable flathub
Video Downloader com.github.unrud.VideoDownloader 0.12.4 stable flathub
Easy Effects com.github.wwmm.easyeffects 7.0.4 stable flathub
NewsFlash com.gitlab.newsflash 2.3.0 stable flathub
Google Chrome com.google.Chrome 113.0.5672.126-1 stable flathub
Inochi Creator com.inochi2d.inochi-creator 0.8.0 stable flathub
qView com.interversehq.qView 5.0 stable flathub
GtkStressTesting com.leinardi.gst 0.7.5 stable flathub
Forge Sparks com.mardojai.ForgeSparks 0.1.1 stable flathub
Extension Manager com.mattjakeman.ExtensionManager 0.4.0 stable flathub
Microsoft Edge com.microsoft.Edge 114.0.1823.37-1 stable flathub
OBS Studio com.obsproject.Studio 29.1.2 stable flathub
Share Preview com.rafaelmardojai.SharePreview 0.3.0 stable flathub
Black Box com.raggesilver.BlackBox 0.13.2 stable flathub
Geopard com.ranfdev.Geopard 1.4.0 stable flathub
Transmission com.transmissionbt.Transmission 4.0.3 stable flathub
Bottles com.usebottles.bottles 51.6 master bottles-origin
Bottles com.usebottles.bottles 51.6 stable flathub
Steam com.valvesoftware.Steam 1.0.0.75 stable flathub
Visual Studio Code com.visualstudio.code 1.78.2-1683731010 stable flathub
Fragments de.haeckerfelix.Fragments 2.1.1 stable flathub
Tubefeeder de.schmidhuberj.tubefeeder v1.9.4 master tubefeeder-origin
Tubefeeder de.schmidhuberj.tubefeeder v1.9.6 stable flathub
Tuba dev.geopjr.Tuba 0.3.2 stable flathub
Forecast dev.salaniLeo.forecast 0.1.0 stable flathub
HandBrake fr.handbrake.ghb 1.6.1 stable flathub
Metadata Cleaner fr.romainvigier.MetadataCleaner 2.5.2 stable flathub
Cartridges hu.kramo.Cartridges 1.5.4 stable flathub
Element im.riot.Riot 1.11.31 stable flathub
Cinny in.cinny.Cinny 2.2.6 stable flathub
Komikku info.febvre.Komikku 1.21.1 stable flathub
Amberol io.bassi.Amberol 0.10.3 stable flathub
Bavarder io.github.Bavarder.Bavarder 0.2.3 stable flathub
AdwSteamGtk io.github.Foldex.AdwSteamGtk 0.6.0 stable flathub
Youtube Downloader Plus io.github.aandrew_me.ytdn 3.14.0 stable flathub
Epic Asset Manager io.github.achetagames.epic_asset_manager 3.8.4 stable flathub
GPU-Viewer io.github.arunsivaramanneo.GPUViewer 2.26 stable flathub
Celluloid io.github.celluloid_player.Celluloid 0.25 stable flathub
Escambo io.github.cleomenezesjr.Escambo 0.1.1 stable flathub
PinApp io.github.fabrialberio.pinapp 1.1.7 stable flathub
Monitorets io.github.jorchube.monitorets 0.10.0 stable flathub
AppImage Pool io.github.prateekmedia.appimagepool 5.1.0 stable flathub
Kooha io.github.seadve.Kooha 2.2.3 stable flathub
Mousai io.github.seadve.Mousai 0.7.5 stable flathub
WebCord io.github.spacingbat3.webcord 4.2.0 stable flathub
Converter io.gitlab.adhami3310.Converter 1.6.1 stable flathub
Sudoku Solver io.gitlab.cyberphantom52.sudoku_solver 1.0.1 stable flathub
Letterpress io.gitlab.gregorni.ASCIIImages 1.3.0 stable flathub
Calligraphy io.gitlab.gregorni.Calligraphy 1.0.0 stable flathub
LibreWolf io.gitlab.librewolf-community 113.0.2-1 stable flathub
Upscaler io.gitlab.theevilskeleton.Upscaler master upscaler3-origin
Upscaler io.gitlab.theevilskeleton.Upscaler 1.1.2 stable flathub
Upscaler io.gitlab.theevilskeleton.Upscaler 1.1.2 test upscaler1-origin
Devel io.gitlab.theevilskeleton.Upscaler.Devel master devel-origin
Dev Toolbox me.iepure.devtoolbox 1.0.2 stable flathub
Passes me.sanchezrodriguez.passes 0.7 stable flathub
Lutris net.lutris.Lutris 0.5.13 stable flathub
Mullvad Browser net.mullvad.MullvadBrowser 102.9.0esr-12.0-2-build1 stable flathub
Poedit net.poedit.Poedit 3.3.1 stable flathub
RPCS3 net.rpcs3.RPCS3 0.0.28-1-33558d14 stable flathub
Live Captions net.sapples.LiveCaptions 0.4.0 stable flathub
Color Picker nl.hjdskes.gcolor3 2.4.0 stable flathub
Audacity org.audacityteam.Audacity 3.3.2 stable flathub
Chromium Web Browser org.chromium.Chromium 114.0.5735.90 stable flathub
Chromium application base org.chromium.Chromium.BaseApp 21.08 flathub
Electron2 application base org.electronjs.Electron2.BaseApp 21.08 flathub
Electron2 application base org.electronjs.Electron2.BaseApp 22.08 flathub
Flatpak External Data Checker org.flathub.flatpak-external-data-checker stable flathub
Builder org.flatpak.Builder stable flathub
Piper org.freedesktop.Piper 0.7 stable flathub
VulkanInfo org.freedesktop.Platform.VulkanInfo 22.08 flathub
appstream-glib org.freedesktop.appstream-glib 0.8.1 stable flathub
Feeds org.gabmus.gfeeds 2.2.0 stable flathub
Giara org.gabmus.giara 1.1.0 stable flathub
Zola org.getzola.zola 0.17.2 stable flathub
GNU Image Manipulation Program org.gimp.GIMP 2.99.14 beta flathub-beta
GNU Image Manipulation Program org.gimp.GIMP 2.10.34 master gnome-nightly
GNU Image Manipulation Program org.gimp.GIMP 2.10.34 stable flathub
Adwaita Demo org.gnome.Adwaita1.Demo 1.4.alpha master gnome-nightly
Boxes org.gnome.Boxes 44.2 stable flathub
Builder org.gnome.Builder 44.2 stable flathub
Calculator org.gnome.Calculator 44.0 stable flathub
Calendar org.gnome.Calendar 44.0 stable flathub
Contacts org.gnome.Contacts 44.0 stable flathub
Devhelp org.gnome.Devhelp 43.0 stable flathub
Web org.gnome.Epiphany 44.3 stable flathub
File Roller org.gnome.FileRoller 43.0 stable flathub
Firmware org.gnome.Firmware 43.2 stable flathub
Fractal org.gnome.Fractal.Devel 5~beta1-c3d77b7 master gnome-nightly
Geary org.gnome.Geary 43.0 stable flathub
Glade org.gnome.Glade 3.40.0 stable flathub
Lollypop org.gnome.Lollypop 1.4.37 stable flathub
Loupe org.gnome.Loupe 44.3 stable flathub
Maps org.gnome.Maps 44.2 stable flathub
Files org.gnome.NautilusDevel 44.1 master gnome-nightly
Notes org.gnome.Notes 40.1 stable flathub
Document Scanner org.gnome.SimpleScan 44.0 stable flathub
Text Editor org.gnome.TextEditor 44.0 stable flathub
Endeavour org.gnome.Todo 43.0 stable flathub
Videos org.gnome.Totem 43.0 stable flathub
Weather org.gnome.Weather 44.0 stable flathub
Pika Backup org.gnome.World.PikaBackup 0.6.1 stable flathub
Secrets org.gnome.World.Secrets 7.3 stable flathub
Clocks org.gnome.clocks 44.0 stable flathub
App Icon Preview org.gnome.design.AppIconPreview 3.3.0 stable flathub
Contrast org.gnome.design.Contrast 0.0.8 stable flathub
Emblem org.gnome.design.Emblem 1.2.0 stable flathub
Icon Library org.gnome.design.IconLibrary 0.0.16 stable flathub
Lorem org.gnome.design.Lorem 1.2 stable flathub
Color Palette org.gnome.design.Palette 2.0.2 stable flathub
Symbolic Preview org.gnome.design.SymbolicPreview 0.0.8 stable flathub
Typography org.gnome.design.Typography 0.2.0 stable flathub
Fonts org.gnome.font-viewer 44.0 stable flathub
Identity org.gnome.gitlab.YaLTeR.Identity 0.5.0 stable flathub
Iotas org.gnome.gitlab.cheywood.Iotas 0.1.16 stable flathub
Apostrophe org.gnome.gitlab.somas.Apostrophe 2.6.3 stable flathub
GTK Demo org.gtk.Demo4 master gnome-nightly
Inkscape org.inkscape.Inkscape 1.2.2 stable flathub
JDownloader org.jdownloader.JDownloader 2.0 stable flathub
Dolphin org.kde.dolphin 23.04.1 stable flathub
Kdenlive org.kde.kdenlive 23.04.1 stable flathub
Krita org.kde.krita 5.1.5 stable flathub
NeoChat org.kde.neochat 23.04.1 stable flathub
Xwayland Video Bridge org.kde.xwaylandvideobridge master xwaylandvideobridge-origin
KeePassXC org.keepassxc.KeePassXC 2.7.5 stable flathub
LibreOffice org.libreoffice.LibreOffice 7.5.3.2 stable flathub
Thunderbird org.mozilla.Thunderbird 102.11.2 stable flathub
Firefox org.mozilla.firefox 113.0.2 stable flathub
Tagger org.nickvision.tagger 2022.11.2 stable flathub
Nicotine+ org.nicotine_plus.Nicotine 3.2.9 stable flathub
ONLYOFFICE Desktop Editors org.onlyoffice.desktopeditors 7.3.3 stable flathub
Helvum org.pipewire.Helvum 0.4.0 stable flathub
qBittorrent org.qbittorrent.qBittorrent 4.5.3 stable flathub
Tenacity org.tenacityaudio.Tenacity 1.3-beta3 test tenacity-origin
Wine org.winehq.Wine 7.0 stable-21.08 flathub
Wine org.winehq.Wine 8.0 stable-22.08 flathub
Zrythm org.zrythm.Zrythm 1.0.0-beta.4.9.1 stable flathub
Imaginer page.codeberg.Imaginer.Imaginer 0.2.2 stable flathub
Atoms pm.mirko.Atoms 1.1.1 stable flathub
Commit re.sonny.Commit 4.0 stable flathub
Oh My SVG re.sonny.OhMySVG 1.2 stable flathub
Playhouse re.sonny.Playhouse 1.1 stable flathub
Workbench re.sonny.Workbench 44.1 stable flathub
Graphs se.sjoerd.Graphs 1.5.2 stable flathub
Cawbird uk.co.ibboard.cawbird 1.5 stable flathub
ArmCord xyz.armcord.ArmCord 3.2.0 stable flathub
Alright, let’s look at the amount of runtimes installed:
$ flatpak list --runtime --user | wc -l
97
And the runtimes themselves:
$ flatpak list --runtime --user
Name Application ID Version Branch Origin
Codecs com.github.Eloston.UngoogledChromium.Codecs stable flathub
Proton (community build) com.valvesoftware.Steam.CompatibilityTool.Proton 7.0-6 beta flathub-beta
Proton (community build) com.valvesoftware.Steam.CompatibilityTool.Proton 7.0-5 stable flathub
Proton experimental (community build) com.valvesoftware.Steam.CompatibilityTool.Proton-Exp 7.0-20230208 stable flathub
Proton-GE (community build) com.valvesoftware.Steam.CompatibilityTool.Proton-GE 8.3-1 beta flathub-beta
Proton-GE (community build) com.valvesoftware.Steam.CompatibilityTool.Proton-GE 8.3-1 stable flathub
gamescope com.valvesoftware.Steam.Utility.gamescope 3.11.51 stable flathub
Codecs org.audacityteam.Audacity.Codecs stable flathub
Codecs org.chromium.Chromium.Codecs stable flathub
Calf org.freedesktop.LinuxAudio.Plugins.Calf 0.90.3 22.08 flathub
LSP org.freedesktop.LinuxAudio.Plugins.LSP 1.2.6 22.08 flathub
MDA org.freedesktop.LinuxAudio.Plugins.MDA 1.2.10 22.08 flathub
TAP-plugins org.freedesktop.LinuxAudio.Plugins.TAP 1.0.1 22.08 flathub
ZamPlugins org.freedesktop.LinuxAudio.Plugins.ZamPlugins 4.1 22.08 flathub
SWH org.freedesktop.LinuxAudio.Plugins.swh 0.4.17 22.08 flathub
Freedesktop Platform org.freedesktop.Platform 21.08.18 21.08 flathub
Freedesktop Platform org.freedesktop.Platform 22.08.12.1 22.08 flathub
i386 org.freedesktop.Platform.Compat.i386 21.08 flathub
i386 org.freedesktop.Platform.Compat.i386 22.08 flathub
Mesa org.freedesktop.Platform.GL.default 21.3.9 21.08 flathub
Mesa org.freedesktop.Platform.GL.default 23.1.1 22.08 flathub
Mesa (Extra) org.freedesktop.Platform.GL.default 23.1.1 22.08-extra flathub
Mesa git snapshot org.freedesktop.Platform.GL.mesa-git 23.0-branchpoint-4408-g4ac56e3e5a4 23.08beta flathub-beta
default org.freedesktop.Platform.GL32.default 21.08 flathub
Mesa org.freedesktop.Platform.GL32.default 23.1.1 22.08 flathub
Mesa (Extra) org.freedesktop.Platform.GL32.default 23.1.1 22.08-extra flathub
Mesa git snapshot org.freedesktop.Platform.GL32.mesa-git 23.0-branchpoint-4408-g4ac56e3e5a4 23.08beta flathub-beta
MangoHud org.freedesktop.Platform.VulkanLayer.MangoHud 0.6.9-1 22.08 flathub
vkBasalt org.freedesktop.Platform.VulkanLayer.vkBasalt 0.3.2.9 22.08 flathub
ffmpeg-full org.freedesktop.Platform.ffmpeg-full 21.08 flathub
ffmpeg-full org.freedesktop.Platform.ffmpeg-full 22.08 flathub
i386 org.freedesktop.Platform.ffmpeg_full.i386 21.08 flathub
i386 org.freedesktop.Platform.ffmpeg_full.i386 22.08 flathub
openh264 org.freedesktop.Platform.openh264 2.1.0 2.0 flathub
openh264 org.freedesktop.Platform.openh264 2.1.0 2.0beta flathub-beta
openh264 org.freedesktop.Platform.openh264 2.1.0 2.2.0 flathub
openh264 org.freedesktop.Platform.openh264 2.1.0 2.2.0beta gnome-nightly
Freedesktop SDK org.freedesktop.Sdk 21.08.18 21.08 flathub
Freedesktop SDK org.freedesktop.Sdk 22.08.12.1 22.08 flathub
i386 org.freedesktop.Sdk.Compat.i386 21.08 flathub
i386 org.freedesktop.Sdk.Compat.i386 22.08 flathub
.NET Core SDK extension org.freedesktop.Sdk.Extension.dotnet6 6.0.408 21.08 flathub
Free Pascal Compiler and Lazarus org.freedesktop.Sdk.Extension.freepascal 3.2.2 21.08 flathub
Go programming language Sdk extension org.freedesktop.Sdk.Extension.golang 1.20.2 21.08 flathub
OpenJDK 11 SDK Extension org.freedesktop.Sdk.Extension.openjdk11 21.08 flathub
OpenJDK 17 SDK Extension org.freedesktop.Sdk.Extension.openjdk17 22.08 flathub
Rust stable org.freedesktop.Sdk.Extension.rust-stable 1.67.0 21.08 flathub
Rust stable org.freedesktop.Sdk.Extension.rust-stable 1.70.0 22.08 flathub
toolchain-i386 org.freedesktop.Sdk.Extension.toolchain-i386 21.08 flathub
toolchain-i386 org.freedesktop.Sdk.Extension.toolchain-i386 22.08 flathub
toolchain-i386 org.freedesktop.Sdk.Extension.toolchain-i386 22.08beta flathub-beta
GNOME Boxes Osinfo DB org.gnome.Boxes.Extension.OsinfoDb 20230518 stable flathub
HEIC org.gnome.Loupe.HEIC stable flathub
GNOME Application Platform version 41 org.gnome.Platform 41 flathub
GNOME Application Platform version 42 org.gnome.Platform 42 flathub
GNOME Application Platform version 43 org.gnome.Platform 43 flathub
GNOME Application Platform version 44 org.gnome.Platform 44 flathub
GNOME Application Platform version Nightly org.gnome.Platform master gnome-nightly
i386 org.gnome.Platform.Compat.i386 41 flathub
i386 org.gnome.Platform.Compat.i386 43 flathub
i386 org.gnome.Platform.Compat.i386 44 flathub
GNOME Software Development Kit version 41 org.gnome.Sdk 41 flathub
GNOME Software Development Kit version 42 org.gnome.Sdk 42 flathub
GNOME Software Development Kit version 43 org.gnome.Sdk 43 flathub
GNOME Software Development Kit version 44 org.gnome.Sdk 44 flathub
GNOME Software Development Kit version Nightly org.gnome.Sdk master gnome-nightly
i386 org.gnome.Sdk.Compat.i386 41 flathub
i386 org.gnome.Sdk.Compat.i386 42 flathub
i386 org.gnome.Sdk.Compat.i386 43 flathub
i386 org.gnome.Sdk.Compat.i386 44 flathub
i386 org.gnome.Sdk.Compat.i386 master gnome-nightly
Codecs org.gnome.Totem.Codecs stable flathub
yt-dl totem-pl-parser plugin org.gnome.Totem.Videosite.YouTubeDl stable flathub
Adwaita dark GTK theme org.gtk.Gtk3theme.Adwaita-dark 3.22 flathub
adw-gtk3 Gtk Theme org.gtk.Gtk3theme.adw-gtk3 3.22 flathub
adw-gtk3-dark Gtk Theme org.gtk.Gtk3theme.adw-gtk3-dark 3.22 flathub
Adwaita theme org.kde.KStyle.Adwaita 6.4 flathub
Kvantum theme engine org.kde.KStyle.Kvantum 1.0.6 5.15-21.08 flathub
KDE Application Platform org.kde.Platform 5.15-21.08 flathub
KDE Application Platform org.kde.Platform 5.15-22.08 flathub
KDE Application Platform org.kde.Platform 6.4 flathub
QGnomePlatform org.kde.PlatformTheme.QGnomePlatform 5.15-21.08 flathub
QGnomePlatform org.kde.PlatformTheme.QGnomePlatform 5.15-22.08 flathub
QGnomePlatform org.kde.PlatformTheme.QGnomePlatform 6.4 flathub
QtSNI org.kde.PlatformTheme.QtSNI 5.15-21.08 flathub
KDE Software Development Kit org.kde.Sdk 5.15-21.08 flathub
KDE Software Development Kit org.kde.Sdk 6.4 flathub
QGnomePlatform-decoration org.kde.WaylandDecoration.QGnomePlatform-decoration 5.15-21.08 flathub
QGnomePlatform-decoration org.kde.WaylandDecoration.QGnomePlatform-decoration 5.15-22.08 flathub
QGnomePlatform-decoration org.kde.WaylandDecoration.QGnomePlatform-decoration 6.4 flathub
Codecs org.kde.krita.Codecs stable flathub
DXVK org.winehq.Wine.DLLs.dxvk 1.10.3 stable-21.08 flathub
DXVK org.winehq.Wine.DLLs.dxvk 1.10.3 stable-22.08 flathub
Gecko org.winehq.Wine.gecko stable-21.08 flathub
Gecko org.winehq.Wine.gecko stable-22.08 flathub
Mono org.winehq.Wine.mono stable-21.08 flathub
Mono org.winehq.Wine.mono stable-22.08 flathub
In that output, here are some of the interesting bits:
Name Application ID Version Branch Origin
[…]
GNOME Application Platform version 41 org.gnome.Platform 41 flathub
GNOME Application Platform version 42 org.gnome.Platform 42 flathub
GNOME Application Platform version 43 org.gnome.Platform 43 flathub
GNOME Application Platform version 44 org.gnome.Platform 44 flathub
GNOME Application Platform version Nightly org.gnome.Platform master gnome-nightly
[…]
KDE Application Platform org.kde.Platform 5.15-21.08 flathub
KDE Application Platform org.kde.Platform 5.15-22.08 flathub
KDE Application Platform org.kde.Platform 6.4 flathub
[…]
DXVK org.winehq.Wine.DLLs.dxvk 1.10.3 stable-21.08 flathub
DXVK org.winehq.Wine.DLLs.dxvk 1.10.3 stable-22.08 flathub
Gecko org.winehq.Wine.gecko stable-21.08 flathub
Gecko org.winehq.Wine.gecko stable-22.08 flathub
Mono org.winehq.Wine.mono stable-21.08 flathub
Mono org.winehq.Wine.mono stable-22.08 flathub
We can observe that, just like the author, I have many different versions of runtimes. Even with an unusual amount of runtimes and apps, Flatpak somehow manages to use 37.73 GB, even with most browsers installed as a flatpak.
I imagine that most users have a small selection of apps installed, which only come with a few runtimes and a version apart, which also means that my setup is possibly one of the worst case scenarios. Even with that amount of torture, Flatpak still manages to handle storage fairly well.
I wouldn’t say Flatpak is completely useless. For certain usecases [sic] it is great to have available. It [sic] think Flatpak makes most sense for when closed source software would need to be distributed.
This is something that is really important to address: Flatpak (Flathub) makes even more sense for free and open-source (FOSS) apps than closed source, because they make apps easily discoverable. For example, Upscaler, an app I developed as a final assignment in CS50x and published it on Flathub on November 16 2022, was featured on OMG! Ubuntu! on that same day (hover over the date for the published date). Another example, gregorni, a friend of mine, published Calligraphy on June 1 2023, which was featured on OMG! Linux! on that same day.
While it makes a lot of sense for closed source apps to publish their apps on Flathub, in my opinion, FOSS apps get even more benefits than closed source apps, because news outlets, especially the FOSS targeted ones, will quickly discover your apps, and might even write an article about them. This also means that more users will discover your apps, which helps it grow in popularity. This also means that you’re not forced to rely on GitHub to make your app discoverable. You could actually use Codeberg and have your apps easily discoverable if they are published on stores that are designed to be discovered.
Imaginer and Bavarder are some GTK4+libadwaita apps that are primarily available on Codeberg, yet both gain more than 100 downloads a day on average, which is a pretty big achievement in my opinion.
In the end, I respect the opinion of disliking Flatpak, as we all have different opinions and disagree on many things. However, there is a difference between having an opinion, and being misinformed and displaying them to viewers or readers, especially when it can potentially hurt the community who are working really hard on addressing genuine issues on the Linux desktop.
As an app developer, I cannot predict users’ setups; I prefer not to waste my time to research what dependencies and their versions Fedora Linux, Debian, Ubuntu, Arch Linux, etc. package. I prefer not to waste my time to refer users to Bugzilla, mailing lists, IRC or other inconvenient platforms that no one wants to use, and later figure out that they’ve been packaging a 6 month old version of the app. Instead, I prefer to devote my time on fixing actual bugs, adding new features, tweak some designs, work on other projects, write articles, or, you know, touch grass for once.
Footnotes
Finished reading: On the Origin of Time by Thomas Hertog 📚
This was light on actual science and heavy on storytelling but still had some interesting ideas and thing to think about.
Finished reading: Chip War by Chris Miller 📚
This neat book tied together a lot of the history I knew about and things I was not aware of, providing a clear history of the chip industry and how we got to where we are today.
This is a weekly report from the CPE (Community Platform Engineering) Team. If you have any questions or feedback, please respond to this report or contact us on #redhat-cpe channel on libera.chat.
We provide you both infographics and text version of the weekly report. If you just want to quickly look at what we did, just look at the infographic. If you are interested in more in depth details look below the infographic.
Week: 29 May – 02 June 2023
<figure class="wp-block-image size-full is-resized">
<figcaption class="wp-element-caption">CPE Infographic</figcaption></figure>
Purpose of this team is to take care of day to day business regarding CentOS and Fedora Infrastructure and Fedora release engineering work.
It’s responsible for services running in Fedora and CentOS infrastructure and preparing things for the new Fedora release (mirrors, mass branching, new namespaces etc.).
The ARC (which is a subset of the team) investigates possible initiatives that CPE might take on.
Planning board
Docs
Extra Packages for Enterprise Linux (or EPEL) is a Fedora Special Interest Group that creates, maintains, and manages a high quality set of additional packages for Enterprise Linux, including, but not limited to, Red Hat Enterprise Linux (RHEL), CentOS and Scientific Linux (SL), Oracle Linux (OL).
EPEL packages are usually based on their Fedora counterparts and will never conflict with or replace packages in the base Enterprise Linux distributions. EPEL uses much of the same infrastructure as Fedora, including buildsystem, bugzilla instance, updates manager, mirror manager and more.
CPE has few members that are working as part of Community Design Team. This team is working on anything related to design in Fedora Community.
This initiative is working on enhancing current DNF mirrors-countme script, which is used to provide statistics about number of Fedora installations on machines. This script has few bottlenecks that will be addressed as part of this intiative.
ARC investigation
The post CPE Weekly update – Week 22 2023 appeared first on Fedora Community Blog.
purpleidea)
on June 01, 2023 10:20 PM
Finished reading: Ordinary Wonder by Charlotte Joko Beck 📚
We have to work with the truth or we miss an opportunity.
We will be moving the koji buildsystem database (and the virthost it runs on) to RHEL9 and postgresql 15 (from RHEL8 and postgresql 12). This outage will happen while the outage of s390x builders is occuring to consolidate outages. During the outage window koji will be unavailable and builds will …
The story of the first digital computers, since a phenomenon observed in Edison’s light bulb, through 2 bit logic operations, through triodes and vacuum tubes, up to the ENIAC, capable of doing astonishing 500 math operations per second, and running without failure for a maximum of 116 hours.
As a matter of comparison, your smartphone can do almost one trillion math operations per second with just a tiny fraction of the required energy. Your smartphone is 2 billion times faster than the first, commercial large and expensive digital computers of the 1940’s.
Veritasium nailed it again.
<figure class="wp-block-embed is-type-video is-provider-youtube wp-block-embed-youtube wp-embed-aspect-16-9 wp-has-aspect-ratio"></figure>
kzak)
on June 01, 2023 11:52 AM
This release comes with dramatic changes, and the most noticeable change is the support for a new kernel mount API in libmount.
The classic mount(2) system call has been with us since the early days of Linux. This interface is quite simple: you specify the source, target, filesystem options, mount flags, and ask the kernel to do the job. Unfortunately, the interface is too simplistic. These days, attaching a filesystem requires multiple steps, and it's important for userspace to assist in these steps and receive feedback from the kernel after each one.
We are all familiar with the infamous error message:
mount: wrong fs type, bad option, bad superblock on /mnt missing
codepage or helper program, or other error. This error message can be quite cryptic. In this case, mount(8) attempted to guess a few possibilities for the EINVAL errno, but nothing seemed relevant, so it prints this error message.
With the new interface, after the syscall fsopen("nonsense", 0), we can inform the user that "mount -t nonsense" is a bad idea.
Please note that you can still see this generic error in mount(8) from v2.39, as the goal for this release was to adopt the new interface. Optimization will come in future releases, so please be patient.
The new kernel mount interface is a set of syscalls that use file descriptors as a glue between them. This kind of interface is open to new extensions (new syscalls), and userspace and filesystem developers don't have to try to explain the entire universe in a comma-separated mount options string.
File descriptors are a game changer. We have a file descriptor to configure the superblock (the filesystem itself) and another file descriptor to set VFS (Virtual File System) node attributes and attach the node to the VFS tree. The file descriptor remains usable even when you change a namespace, etc.
The important thing is that userspace applications (like the mount(8) command) can work with a filesystem that is not yet attached. It means that mount(8) configures the filesystem, sets VFS flags (such as noexec, ...), and then attaches everything to the VFS to make it visible to other processes in the same namespace.
This is elegant, for example, when you need to set VFS flags in multiple steps. You can now set only the node in one step and recursively set all submounts in another step using "ro,noexec=recursive" in the new mount(8).
It also allows previously impossible operations to be mixed together. For example, "mount --move -oro /mnt/A /mnt/B".
Let's delve into the details, for example, the strace output for "mount -t ext4 -o ro /dev/sdc1 /mnt/test":
Classic mount(8):
mount("/dev/sdc1", "/mnt/test", "ext4", MS_RDONLY, NULL);New interface:
fsopen("ext4", FSOPEN_CLOEXEC) = 3
fsconfig(3, FSCONFIG_SET_STRING, "source", "/dev/sdc1", 0) = 0 fsconfig(3, FSCONFIG_SET_FLAG, "ro", NULL, 0) = 0 fsconfig(3, FSCONFIG_CMD_CREATE, NULL, NULL, 0) = 0 fsmount(3, FSMOUNT_CLOEXEC, 0) = 4 mount_setattr(4,"", AT_EMPTY_PATH,{attr_set=MOUNT_ATTR_RDONLY, attr_clr=0, propagation=0}) = 0 move_mount(4, "", AT_FDCWD, "/mnt/test", MOVE_MOUNT_F_EMPTY_PATH) = 0The steps in the interface are as follows:
Nothing is perfect. This change is so significant that it will take time to make it stable for all use cases. In some cases, the responsibility also lies with the kernel because filesystem drivers have to adopt the new interface as well. For example, btrfs does not work as expected if a SELinux context is specified between mount options, and libmount uses the classic mount(2) in this case.
Another consideration (for libmount) is backward compatibility. Let's imagine you boot an old kernel without the new interface. You probably assume functional mount(8), so libmount has to detect that the new syscalls are not available and switch back to the classic mount(2).
In the future, we could improve the mount(8) command-line interface to better reflect the mount process. Currently, we mix operation requests with mount options (e.g., -o remount,bind,ro). It would be nice to differentiate between VFS and filesystem operations. For example:
VFS operation (set /mnt and subdirectories to ro, exec):
mount modify /mnt --recursive --set ro --unset noexec mount reconfigure /mnt -o ro What do you think about the "mount <oper> [options]" command-line interface?
And here are some other mount/libmount-related changes:
statx(AT_STATX_DONT_SYNC|AT_NO_AUTOMOUNT) as a replacement for the classic stat() if you only need very basic information about a file or directory.Util-linux v2.39 is definitely not only about mount(8)/libmount:
lsfd --inet -Q '(COMMAND == "systemd")'.Significant changes have also been made to the util-linux test suite and our CI on GitHub. Thanks to Thomas Weißschuh for these and many other improvements.
(the blog post grammar and header has been generated by ChatGPT :-)
The Red Hat Westford location will have more power line work done. This will require the building to be powered down in places which will affect various services like network connections and s390x builders.
koji builds and composes will be affected with builds waiting until the s390x builders are able …
Cockpit is the modern Linux admin interface. We release regularly.
Here are the release notes from cockpit-machines 291 and cockpit-podman 70:
Virtual socket support enables communication between the host and guest over a socket. Cockpit Machines now has support for setting up such a device.
The user can choose to configure a custom identifier, or let have it assigned automatically upon a VM’s boot. The identifier is used by the host to uniquely identify vsock of a specific guest.
Please note that vsock still requires special vsock-aware software (e.g. socat) to communicate over the socket.
Similar to podman container prune, cockpit-podman now has a “prune” dialog for bulk deletion of stopped and exited containers. This dialog provides the option to unselect containers while displaying container names, creation dates, and owner information to help ensure the intended containers are selected for deletion.
cockpit-machines 291 and cockpit-podman 70 are available now:
We will be upgrading our wiki and it's database server along with the virthosts they are hosted on.
Update: upgrade is taking longer than expected, so we are extending the outage window to complete the upgrade.
درود دوستان، در این پست که اولین پست آموزشی من در طرفداران فدورا میباشد قرار هست با محیط کلی ترمینال یا خط فرمان در لینوکس و اجزای آن آشنا بشویم؛
وقتی شما ترمینال یا shell لینوکس را باز یا به سرور لاگین میکنید همچین تصویری را مشاهده خواهید کرد، در ادامه بخش های مشخص شده در تصویر بالا را توضیح خواهم داد:
شماره 1- نام کاربر (Username) که alireza هست.
شماره 2- نام کامپیوتر (Hostname) که localhost هست.
شماره 3- مسیری جاری که در آن قرار داریم (علامت مَد ” ~ ” یعنی داخل Home Directory کاربر کنونی هستیم )
شماره 4- در ترمینال یا shell دو علامت $ یا # را مشاهده خواهیم کرد که $ یعنی کابری معمولی با سطح دسترسی محدود (مانند کاربر alireza) و علامت # به معنی کاربر root با بالاترین سطح دسترسی.
و در ادامه پرامپت (prompt) آزاد که به معنی آماده وارد کردن دستورات کاربر میباشد.
در پست های بعد شروع خواهیم کرد به آموزش، یادگیری و نحوه کارکرد دستورات در لینوکس.
امیدوارم شروع خوبی را با هم داشته باشیم.
The post آشنایی با ترمینال لینوکس first appeared on طرفداران فدورا.
mhayden)
on May 31, 2023 12:00 AM
admin)
on May 30, 2023 11:58 PM
Join the Fedora community this weekend on Friday, June 2nd and Saturday, June 3rd to celebrate the final release of Fedora Linux 38 with a virtual Release Party. Please register on Hopin and join us on June 2nd & 3rd for a short program of informational sessions and social activities. Make sure to save the dates, share the registration, and show up to celebrate with Fedora Friends, old and new!
The schedule for the Release Party features informational sessions about the rewritten Fedora Notifications service, a Creative Freedom Summit retrospective, Fedora CoreOS, updates from the EPEL and Fedora Docs teams, and more community activities. Last, but certainly not least, we will be hanging out in the Fedora Museum WorkAdventure for our Hallway track. Thanks to our amazing community for all your contributions to the latest release of Fedora Linux. Let’s party!
admin)
on May 30, 2023 08:00 AM
We welcome you (yes, you!) to join in an Art Challenge hosted by the Creative Freedom Summit and Fedora Design Team!
To join the Creative Freedom Summit Element/Matrix channel, a Matrix network account is required. If you don’t already have an account you can create one via Element’s Create Account page. Element offers free desktop or mobile apps to join the summit. Element also offers a web app that allows you to join from your browser. There are additional ways to access Matrix, but the Summit team recommends Element as it provides the best experience for our platform setup.
The post Creative Freedom Art Challenge Info & Guidelines appeared first on Fedora Community Blog.
jstribny)
on May 30, 2023 12:00 AM
Here’s 3 reasons why I am building a brand new SaaS template for Rails.
I am building a new SaaS template for Rails called Business Class. Since there are several similar good options on the market today you might wonder why I am even doing it.
The core of a SaaS template are payments. And if you are like me, you want to collect payments for your new SaaS business from around the world. Payment providers such as Stripe will help you do just that but there’s a catch. You might need to collect and pay taxes to several different countries.
The mental barrier for me is huge. When I was a teenager I started many projects, but I haven’t put any Buy buttons on the internet. Not that I didn’t want to, no. I just imagined all the obligations I would have or giving everything I earned to tax consultants. In a way this should not stop you, but it stopped me.
It wasn’t until I learned about Gumroad I pulled the trigger to work on my first paid product Deployment from Scratch. 962 people bought the book to date yet it was almost never created. This was all possible thanks to Gumroad acting as an Merchant of Record for EU taxes. And it’s honestly just great.
So the first reason I embarked on this journey is to build my first SaaS business. And to do that I am focusing on the Paddle provider which acts as your Merchant of Record. Something like a Gumroad, but for subscription businesses.
The next reason is a philosophical one. As engineers we all have our own takes on building software. Me included. And so I want to build something close to my programmer’s heart. I believe there can be many templates on the market because if you are on a lookout for one, there’s a whole list of things to consider.
The first philosophical goal is to stay close to Ruby on Rails idioms and defaults. While it might not be possible or desired 100% of the time, I want my projects to be close to the simplicity of 37signals products. I want to build with Hotwire, Active Storage, or Minitest. I learned to love fixtures or go with the flow of CurrentAttributes.
The second goal is to build a template and not a framework. My new products should be standard Rails applications without any private or special libraries or engines. Nobody will ever know the applications started as Business Class. That’s just the template name and nothing else. Just open the files, edit, push, and done!
Right now I am wrapping up the first release of the template. I want to get it out as soon as possible to get more feedback that will make it even better in the future. If you are interested, sign up for updates.
A few weeks back Sourceware joined the Software Freedom Conservancy. This week Sourceware joins the fediverse at @sourceware@fosstodon.org.
The account will be used for Sourceware announcements, notices about downtime and temporary issues with our network.
Sourceware is run by volunteers who can be contacted on the public overseers@sourceware.org mailinglist [inbox].
Or you can file an issue in the Sourceware Infrastructure bugzilla component.
There is also an irc channel #overseers on irc.libera.chat. Overseers Open Office hours take place in the same irc channel every second Friday of the month at UTC 18:00.
jzb)
on May 29, 2023 05:52 PM
WordPress turned 20 over the weekend. Older than that, if you count the b2 codebase WordPress forked from. 20 years for a project is quite an accomplishment, but WordPress hasn’t merely survived for 20 years. The open source CMS powers a huge chunk of the Internet and has shown how commerce and community can coexist successfully for the long haul.
It’s hard to convey how impressive WordPress was when it was launched, if you haven’t dabbled with the CMSes of the time. By the time WordPress 1.0 was released, I’d fussed with static site generators (Blosxom), phpWebLog, and even Slashcode. Standing up a CMS on shared hosting was non-trivial.
Here was WordPress. Easy to install, easy to use, ran well on minimal hardware if you didn’t have heavy traffic, and entirely free. It was just a few steps and you could have a blog running in five minutes on a shared hosting account. You could have a site set up in an hour if you were happy with a stock theme.
It spread like wildfire. Early WordPress was primarily a blogging tool, but people loved it so much they kept bending it to other uses. It’s evolved to be much more than a blogging platform. (Whether WordPress should be used in every case is another discussion.)
It helped popularize the LAMP stack, and spread open source to audiences that otherwise wouldn’t have cared a lot about software or licensing. Blogging is not as popular as it once was, but WordPress is still going strong and if you need a simple web publishing platform, WordPress is there for you. If you want to DIY it, it’s easy to do. If you want to pay someone else for hosting and upkeep, you can do that too. There’s a whole community of providers who offer paid plugins and themes, or you can do it all for free if you have the know-how and are willing to apply the elbow grease.
I’ve tried many other platforms but I always come back to WordPress. It’s the right combination of ease of use, widely adopted, open, and functionality. Currently I pay WordPress.com for hosting, but I know that I can DIY it if I ever decide to do so. That freedom is important, even if I’m not currently exercising it.
Major kudos to the project and contributors. 20 years is quite an accomplishment. I can’t wait to see what the next 20 years is going to bring!
New year, new challenges.
We finally reached a major milestone with Chromium 110, which was a release where we finally got screen sharing enabled by default on Wayland, and since then you no longer have to go into the preferences and enable the flag you need. That doesn’t mean my work there is over, but I’ve shifted my focus to something related but slightly different and that is PipeWire camera support.
Work on PipeWire camera support started in 2021 and was done by Michael Olbrich (Pengutronix). He submitted a huge change to Chromium to add this support and had trouble finding a reviewer because there was actually no one who knew anything about PipeWire in the Chromium project. I actually saw his change request by accident, but we got in touch and decided to move this to WebRTC instead, because having it lower in the stack means we would get it automatically in other browsers, like Firefox. Michael attended a meeting we used to have regularly for screen sharing support in WebRTC and we discussed how to implement PipeWire camera support in WebRTC instead and how to reuse some of the code we already had for screen sharing to avoid code duplication. After a few submitted and reverted reviews (usually when things break Chromium parts that are not covered by CI, happened to me many times), we ended up with PipeWire camera support in WebRTC (talking about the beginning of this year).
Journey to PipeWire camera support in Firefox
Up to recently, my work has mostly been 95% WebRTC and 5% Chromium, but I have not been familiar with Firefox at all (not counting WebRTC backports). I actually started fixing screen sharing support in there first before moving to camera, because I noticed a few issues after Firefox (finally) did a WebRTC rebase to some of the newer versions. They’ve actually started doing monthly WebRTC rebases, which is really a good thing and I’m glad to see that happening. Anyway, even though Firefox has more recent WebRTC these days, when I started in February, there was still no PipeWire camera support at all because WebRTC was still a few months behind, so I had to backport all the patches and make them work with Firefox. Only then I could finally start working on the actual PipeWire camera support from WebRTC. Working on the backports, I was still working in the WebRTC space, so everything was somewhat familiar. Implementing the actual PipeWire support was a different story and took me some extra time to understand how everything works. This includes camera API on the WebRTC side, camera support on the Firefox side, and I also had to learn all the APIs specifically used in Firefox, but admittedly, learning about new things is fun too. After some tries and errors it started to work and I was able to share my camera using the PipeWire camera backend from WebRTC. You have to trust me that the picture below is not using the V4L2 backend.
<figure class="wp-block-image size-large is-resized is-style-default">
</figure>
I went ahead and submitted my WebRTC backports and the PipeWire camera backend implementation for review to Firefox. Unfortunately, I was told that the code where I placed my implementation could also be used by the WebRTC Javascript API, which is used by bots to check for camera presence on the client side, which I didn’t know as someone who just recently started working on camera support. This was a problem because we get PipeWire access through xdg-desktop-portal and this involves showing a dialog to the user asking for camera access. Showing a camera request dialog randomly to the user would not be a good experience. Going back to the drawing board, I talked to Andreas Pehrson (Mozilla/WebRTC). Andreas was a great helper and we came up with a solution on how to implement it properly in Firefox and avoid things like I’ve mentioned before. This time it involved some re-org changes in WebRTC, where I split the xdg-desktop-portal and PipeWire implementations for PipeWire video capture, so we can request camera access in Firefox only when appropriate and only do the PipeWire stuff in the backend assuming the access was granted. So I did implement it again, this time according to what we agreed on with Andreas and it worked.
<figure class="wp-block-image size-large is-resized">
</figure>
This is now submitted for review again and hopefully this time it will only need some minor fixes and not a complete rewrite like before, and you will be able to try/use it sooner rather than later. The main change is submitted here, but it is accompanied by other changes with WebRTC backports or changes that make the backports buildable with Firefox. With the first version of the change, I had a Fedora COPR repository, but I had to discontinue it, because it was too hard to maintain it in a buildable state on top of a stable Firefox. But you can be sure that Fedora will be the very first consumer of these changes once they are merged.
Why do we need this?
For many reasons. I would recommend you to read a blog post from Christian Schaller, where everything is explained into the details and gives you more information about the camera stack. Main reasons are:
Chromium support
While support in WebRTC has been done already a few months ago, Chromium originally didn’t use WebRTC video capture API for camera support and for that reason it had to be added. Michael implemented it and it is still currently pending on review so currently both Chromium and Firefox are both implemented, but waiting for approval.
Future plans
Most importantly, I want to get everything merged and working seamlessly, but I’m already aware of some issues and missing functionality in the PipeWire backend in WebRTC. And we also have the same problem we used to have with screen sharing, which is that it’s not enabled by default, unit tested, and feature complete and these things take time fix.
Voting in the Fedora Linux 38 elections is now open. Go to the Elections app to cast your vote. Voting closes at 23:59 UTC on Sunday 11 June. Don’t forget to claim your “I Voted” badge when you cast your ballot. Links to candidate interviews are below.
Note: The election was delayed from its original start date on 19 May. See this Devel list thread for additional context.
There is one seat open on the Fedora Council:
There are four seats open on FESCo:
There is one seat open on the Mindshare Committee:
The post F38 elections voting now open appeared first on Fedora Community Blog.
bressers)
on May 29, 2023 12:00 AM
Josh and Kurt talk about PyPI suspending new accounts and packages for a day, and a 60 minutes story about deepfakes. The problems are mostly the same, but for very different reasons. The world is changing faster than we can keep up, so what is a human to do?
<audio class="wp-audio-shortcode" controls="controls" id="audio-3126-2" preload="none" style="width: 100%;"><source src="https://traffic.libsyn.com/opensourcesecuritypodcast/Episode_377_The_world_is_changing_too_fast_for_humans_to_understand.mp3?_=2" type="audio/mpeg">https://traffic.libsyn.com/opensourcesecuritypodcast/Episode_377_The_world_is_changing_too_fast_for_humans_to_understand.mp3</audio>
admin)
on May 28, 2023 11:55 PM
This is a part of the Elections Interviews series for Fedora Linux 38. Voting is open to all Fedora contributors. The voting period starts on Monday, 29 May and closes promptly at 23:59:59 UTC on Sunday, 11 June.
I have been participating in Fedora community for a number of years. I started as one of the Fedora Ambassadors. I settled in working on Cloud a few years back and then found a job that really supported that work. Now I spend a lot of time working on the Cloud efforts.
I had the opportunity to serve on the Mindshare committee last year after one of the members found it necessary to focus their efforts elsewhere. I found it very fulfilling to work with the team. There are a lot of challenges around building a strong community and I have always enjoyed being a part of that efforts. I think that I can continue that work again.
I would like to bring some of the lessons learned from Ben Cotton to the program management and help Justin keep a strong plan of record with the milestons and tickets arranged in a way that is easily consumable. I think it would be great to have a list of events and a strong interconnection with Fedora Marketing to ensure that we have coverage and we know that we have solid plans for the editions to participate in the annual planning. Beyond that, I would like to help maintain the queue and ensure that there is reasonable support for the community architect and their vision.
(not answered)
The post F38 Mindshare election: Interview with David Duncan appeared first on Fedora Community Blog.
admin)
on May 28, 2023 11:55 PM
This is a part of the Elections Interviews series for Fedora Linux 38. Voting is open to all Fedora contributors. The voting period starts on Monday, 29 May and closes promptly at 23:59:59 UTC on Sunday, 11 June.
I have already been a Fedora contributor for 12 years, I have worked in different teams, I am in the LATAM region.
I have always tried to do my best within the Fedora community and I would like to join the Mindshare team to share my ideas for creating tasks that help the community continue to grow as we always have.
Currently we need to do more events or anything that joins the LATAM region that is a bit neglected. We require more activities, not only national, we also want some international activities and this problem dates back to before the pandemic that affected us all.
It is necessary to look for methods that are attractive to the community, we still have unofficial telegram channels. We want a united LATAM, LATAM v2 a new version in which we can all work hand in hand, reporting events and working as a team.
The LATAM region requires mindshare’s attention to help us get out of the black hole where we find ourselves. We need to motivate the region. We require support to activate the region again.
The post F38 Mindshare election: Interview with Luis Bazan appeared first on Fedora Community Blog.
admin)
on May 28, 2023 11:50 PM
This is a part of the Elections Interviews series for Fedora Linux 38. Voting is open to all Fedora contributors. The voting period starts on Monday, 29 May and closes promptly at 23:59:59 UTC on Sunday, 11 June.
#fedora-cloud#fedora-devel#fedora-pythonThe community has so many talented people with great ideas and FESCo is in a unique position to guide these ideas into production for all kinds of users. I enjoy playing a small part in the innovation and sustainability of Fedora as a member of FESCo.
FESCo membership requires plenty of consideration for various Fedora use cases ranging from small desktops up to large servers and cloud infrastructure. I believe I can represent these users well as I examine proposed changes and consider their effects.
My goal for Fedora as a member of FESCo are to grow the community by making Fedora more friendly to changes that fit our common values from the Four Foundations. Proposing changes to Fedora feels daunting for newcomers and I want to encourage new changes from a wider array of contributors and debate these changes with an experienced group of people.
I’m a member of the Cloud SIG where we expand Fedora to new clouds and improve experiences with existing clouds. This brings the Fedora experience to more users in more regions and makes that experience more consistent.
I write posts occasionally on Fedora Magazine because I love sharing what I know with other people.
My work on packaging has expanded lately and I’m a core maintainer or co-maintainer for 218 packages. Most of my packaging work is on Python SDKs and tools, but I also maintain many Golang packages. I’m a package sponsor and I’m teaching my team at Red Hat how to help with package maintenance.
I start by asking if we’re all starting with the same information and assumptions. Often times the disagreements start because multiple people are coming to the problem from different perspectives and with different pieces of information. Writing these down helps to get a consistent understanding of the problem from everyone. The why behind a problem or change is often the most important part, but it is easily overlooked.
From there, I encourage the team to discuss the problem without proposing solutions or deep diving into technologies. For example, you can ask basic questions, such as: What isn’t working? Who is affected? What could be made better? Are there examples of this elsewhere?
Level-setting the conversation leads to a better understanding and gets everyone working from the same starting point.
One of my biggest beliefs is iterating.
We can break down big changes into logical parts and build a plan that includes all of them. This allows teams to celebrate small wins along the way. It builds momentum which in turn builds confidence that the team is making progress.
The post F38 FESCo election: Interview with Major Hayden appeared first on Fedora Community Blog.
admin)
on May 28, 2023 11:50 PM
This is a part of the Elections Interviews series for Fedora Linux 38. Voting is open to all Fedora contributors. The voting period starts on Monday, 29 May and closes promptly at 23:59:59 UTC on Sunday, 11 June.
#fedora-devel#fedora-elnI’ve been a member of FESCo for many years now, and it’s been a great experience. It gives me the opportunity to see a much wider view of the project than just the pieces I would otherwise contribute to.
As for steering the direction of Fedora, I think I would mostly just continue to do as I have been doing: pushing for Fedora to continue to be both the most advanced and one of the most stable open-source distributions in the world.
Aside from my work on FESCo, I am also acting as the Lead on the Fedora ELN project, which is a prototype of what will eventually be the next major release of Red Hat Enterprise Linux. At this particular point in time (and for most of the duration of this next FESCo coterie) I will be focused on laying the groundwork for Red Hat Enterprise Linux 10 and CentOS Stream 10. Performing these activities in the public provides both an opportunity for the community to be involved with the creation of Red Hat Enterprise Linux as well as painting a clear picture of Fedora’s value to Red Hat, our primary sponsor.
First and foremost, I always strive for consensus. Most disagreements are not fundamental differences between people. Instead, they tend to be more nuanced. My goal (particularly within my FESCo service) is to make sure that everyone’s opinion is heard and considered; I then try to figure out how to meet in the middle.
Of course, not every decision can be resolved with consensus. In the event that a true impasse is reached, that’s the point where I usually advocate for calling a vote and proceeding with the majority opinion. On the whole, I believe that democratic decision-making is the best solution that humanity has come up with for resolving otherwise-insoluble disagreements.
Just so it’s very clear, I’m a Red Hat employee. My day-job at Red Hat is to organize and improve the processes we use to kick off development of the next major RHEL release. As such, my stances on FESCo will often represent my opinion of what will make that effort operate more smoothly. So, no matter how entertaining it might be, we’re not going to be replacing the entire contents of /usr/share/icons with the Beefy Miracle icon.
The post F38 FESCo election: Interview with Stephen Gallagher appeared first on Fedora Community Blog.
admin)
on May 28, 2023 11:50 PM
This is a part of the Elections Interviews series for Fedora Linux 38. Voting is open to all Fedora contributors. The voting period starts on Monday, 29 May and closes promptly at 23:59:59 UTC on Sunday, 11 June.
#fedora-devel#fedora-ci#fedora-buildsysI have a background in compilers and toolchains, and I would like to use some of the knowledge I’ve gained over the years of building and troubleshooting applications to help make Fedora better. Specifically, I’m interested in helping packagers avoid making common mistakes through standardized macros and packaging practices and also by increasing the reliance on CI.
I’m currently one of the maintainers of the LLVM packages in Fedora which is a set of 15 packages that provide a C/C++/Fortran compilers as well as a set of reusable compiler libraries that are used for developing other languages and for developer tools, like IDEs.
I’ve also worked on two system wide change requests to help standardize the use of make within Fedora packages. These changes helped to make spec files more consistent across all of Fedora and also made it possible to remove make from the default buildroot.
When I am in a leadership role, like FESCO, and there is a disagreement, the first thing I do is make sure I understand the problem and the potential solutions. This usually requires having a discussion between all interested parties either on a mailing list, chat platform, or video call. Many times disagreements are simply the result of misunderstandings, so getting everyone together to discuss the issue in the same place can lead to a consensus decision and avoid the need for someone in leadership to get involved.
However, if consensus cannot be reached, once I like to try to get some third party opinions from people who have not been directly involved with the discussions. Once I feel comfortable I have enough information and am ready to make a decision, I make sure I am able to explain in writing why the decision was made and then I communicate the decision to all the stakeholders. It’s always important to have a written record of why a decision was made in case it needs to be revisited in the future.
I work for Red Hat on the Platform Tools team. I am the technical lead for our LLVM team and the overall technical lead for the Go/Rust/LLVM compiler group. This means that I work on packaging, bug fixing and upstream feature development for LLVM and work on high-level technical issues common across all 3 compilers.
The post F38 FESCo election: Interview with Tom Stellard appeared first on Fedora Community Blog.
admin)
on May 28, 2023 11:50 PM
This is a part of the Elections Interviews series for Fedora Linux 38. Voting is open to all Fedora contributors. The voting period starts on Monday, 29 May and closes promptly at 23:59:59 UTC on Sunday, 11 June.
As a Fedora Linux, CentOS, and Red Hat Enterprise Linux user for well over a decade, and as a contributor to the Fedora community for the last several years, I find that wise and steady technical leadership has been one of the Fedora project’s great strengths. In my one term on FESCo, I think I have made a useful contribution to this tradition.
It’s my practice to listen more than I speak; respect different people’s perspectives and styles of communication; and remember that idealism and pragmatism can exist in complementary rather than adversarial opposition.
I directly maintain around 170 rather diverse packages. A few of my particular interests are scientific/technical and mathematical packages, font-related software, and the Python ecosystem. I also co-maintain or contribute to a variety of packages via the neuro-sig and python-packagers-sig packaging groups, and I regularly contribute fixes to other packages and to upstream projects.
I also mentor other packagers, not only as a packager sponsor, but also by doing package reviews and by offering detailed PRs in dist-git and suggestions in Bugzilla and on chat and the devel mailing list. Teaching and mentoring is powerful. It is good to improve a hundred packages, but even better to improve a thousand packages by learning something useful and sharing it with ten or twenty packagers.
Finally, I have been a member of FESCo for the past year. A large part of that role is the evaluation of Change proposals. I take this responsibility seriously. I read the complete text of each proposal, and I read almost everything on the devel mailing list—not only to follow discussion of proposed changes, but to be as aware as possible of the broader context: what people are working on, planning to change, or simply frustrated with, across the distribution.
Above all, I listen carefully to everyone. This is a matter of respect: all people’s feelings, experiences, and thoughts matter. Besides, there is often a lot to be learned in a disagreement, and not every situation has one clear correct answer. Often, when people can speak and be listened to carefully and honestly, the experience helps the speaker or the listener understand and clarify their own thoughts, which can lead to an unexpected compromise or consensus.
At the same time, I expect people to speak respectfully. One one hand, people sometimes need time and rhetorical space to gracefully step back from an accidentally incendiary phrasing, or to vent occasionally, without facing an escalatory response. On the other hand, a healthy community needs to push back against toxic discourse, including consistently aggressive rhetoric, excessive repetition, and personal attacks. The damage done to a conversation when not everyone feels it is safe to contribute is invisible and serious.
In the end, some disagreements can’t be resolved by consensus. A decision must be made: some people get what they wanted, and some people don’t. Keeping one’s opinions separate from one’s ego is a practiced skill, and an important one when it’s time to let go.
After a disputed decision, it’s necessary to strike a balance. A team needs to move on with confidence and start solving new problems. Constantly rehashing an old disagreement or waffling on a recent decision does little good, and risks creating paralyzing uncertainty. At the same time, as time passes, it’s important to remain willing to revisit old choices and to adapt to new information and experiences.
I’m an electrical engineer by training and experience, and a stay-at-home parent of two small children. I care deeply about music, food, ecology, and quite a few other things.
I am happy to discover that I am wrong, and to admit it. This is much better than continuing to make the same mistake!
I believe that the best way to improve a process is to make it easier for people to do the right thing than the wrong one.
The post F38 FESCo election: Interview with Benjamin Beasley appeared first on Fedora Community Blog.
admin)
on May 28, 2023 11:50 PM
This is a part of the Elections Interviews series for Fedora Linux 38. Voting is open to all Fedora contributors. The voting period starts on Monday, 29 May and closes promptly at 23:59:59 UTC on Sunday, 11 June.
Conan_Kudo, Pharaoh_Atem, King_InuYasha, Eighth_Doctor… 
#devel:fedoraproject.org, #asahi:fedoraproject.org, #kde:fedoraproject.org, #workstation:fedoraproject.org, #cloud:fedoraproject.org, #centos-hyperscale:fedoraproject.org, #okd:fedoraproject.org, #budgie:fedoraproject.org, #admin:opensuse.org, #chat:opensuse.org, #bar:opensuse.org, #obs:opensuse.org, #RedHat:matrix.org, #networkmanager:matrix.org, #rpm:matrix.org, #rpm-ecosystem:matrix.org, #yum:matrix.org, #manatools:matrix.org, #lugaru:matrix.org, #buddiesofbudgie-dev:matrix.org
)As a long-time member of the Fedora community as a user and a contributor, I have benefited from the excellent work of many FESCo members before me to ensure Fedora continues to evolve as an amazing platform for innovation. For the past few years, I have had the wonderful privilege of serving as a member of FESCo for the first time, and I enjoyed my time serving to steer Fedora into the future, and I wish to continue to contribute my expertise to help analyze and make good decisions on evolving the Fedora platform.
The bulk of my contributions to Fedora lately are on the desktop side of things. In the last year, I’ve been working steadily on improving Fedora’s multimedia capabilities, which included bringing in FFmpeg into Fedora and enabling a new range of applications, libraries, and services to be packaged and hosted on Fedora Linux. This even leads to enabling creative professional work for video and making video streaming possible with software shipped in Fedora. Most recently, I helped kickstart the Budgie SIG and assisted with bootstrapping the Fedora Budgie spin and Fedora Onyx. Finally, my newest effort is around the bringup of the Fedora Asahi Remix by the Asahi SIG to support Fedora Linux on Apple Silicon Macs. This is being done in close collaboration with the upstream Asahi Linux community and members of that community are now part of the Fedora community too.
Beyond the desktop and more into the clouds, I have been engaging with folks at AWS to bring them more into the Fedora community in a similar vein to how I helped bring Facebook into the Fedora community. This has also led to a proper revival of the Fedora Cloud Working Group and the Fedora Cloud Edition for Fedora Linux 37. We’re currently working on expanding our coverage of Fedora Cloud Edition in public cloud platforms, as well.
My hope is that the work I do helps with making the experience using and contributing to Fedora better than it was ever before and that Fedora’s technical leadership in open source draws in more users and contributors.
I attempt to explain my viewpoint and try to build consensus through persuasion and collaboration. If there isn’t a path to consensus as-is, I try to identify the points of disagreement and see if there is a way to compromise to resolve the disagreement. Generally, this ultimately results in a decision that FESCo can act on.
To me, the most important thing about Fedora is that we’re a community with a bias for innovation. Our community looks to solve problems and make solutions available as FOSS, and this is something that Fedora uniquely does when many others take the easy path to ship old software or nonfree software everywhere. We work with tens of thousands of projects to deliver an amazing platform in an easily accessible and open fashion, built on FOSS infrastructure and tools. This makes Fedora special to me, and we should continue to hold ourselves to that high standard.
I’m also a big believer in community bonds and collaboration, which is why people tend to find me all over the place. I’m involved in Asahi Linux, CentOS, openSUSE, and several other similar projects in leadership roles as well as a contributor in order to demonstrate my commitment to this philosophy.
The post F38 FESCo election: Interview with Neal Gompa appeared first on Fedora Community Blog.
admin)
on May 28, 2023 11:45 PM
This is a part of the Elections Interviews series for Fedora Linux 38. Voting is open to all Fedora contributors. The voting period starts on Monday, 29 May and closes promptly at 23:59:59 UTC on Sunday, 11 June.
I hail from APAC (India) and would like to focus on bringing in more non-US perspectives, which includes bringing in more contributors from diverse backgrounds.
Efficient utilization of our brand-new design assets which are now in multiple languages to onboard a variety of users (general and power-users) to the Fedora community as contributor either to functional sides (QA, packaging..etc) and/or outreach.
Giving suggestions and bringing new perspectives from technical and outreach are my primary motivators.
Fedora’s place in the universe is to be the leader amongst other distros in terms of innovation that’s loved and embraced by the community.
Fedora’s potential in the Workstation, container and IoT space has been rivaled by few to none.
This puts us in a very niche position to keep growing stronger with all resources at project’s disposal. Fedora has it’s presence felt in the container land with FCOS. As we move towards new beginnings, I believe Fedora should find it’s place as a go-to rpm-ostree distro for next-generation developments in AI, Blockchain and ML.
However, there is no specific way to measure, BUT.. here’s something I think can define Fedora’s success the best:
As Fedora project marches towards the 2028 vision, I would like to make room by aligning some of my previous work delegated to other community members as part of Initiatives. I would mostly be the executive sponsor and will continue to guide and oversee from time to time. These include Digital Ambassadorship and Fedora CommOps Reborn stuff.
The post F38 Council election: Interview with Sumantro Mukherjee appeared first on Fedora Community Blog.
A couple months back I recorded this line on my blog as part of investigating perf:
perf record --branch-filter any,save_type,u true What is the interface between the perf binary and the linux Kernel when I run this? There is a system call to open a file handle. The man page says this:
int syscall(SYS_perf_event_open, struct perf_event_attr *attr,
pid_t pid, int cpu, int group_fd,
unsigned long flags);
But how does that get called by the perf binary…the answer is trickier than I originally thought.
When debugging system calls, the primary tool I use is strace. I ran it like this:
sudo strace perf record --branch-filter any,save_type,u true 2>&1 | lessInside of less, I can search for the string “event_open” and I am taken to a spot in the output where the system call is made…11 times. Each one opens a file handle, and all of them are kept open after the system call. Here is the first call:
perf_event_open({
type=PERF_TYPE_SOFTWARE,
size=0 /* PERF_ATTR_SIZE_??? */,
config=PERF_COUNT_SW_CPU_CLOCK,
sample_period=0,
sample_type=0,
read_format=0,
exclude_kernel=1,
precise_ip=0 /* arbitrary skid */, ...},
-1,
2,
-1,
PERF_FLAG_FD_CLOEXEC) = 4 And here is the last one
perf_event_open({
type=PERF_TYPE_HARDWARE,
size=PERF_ATTR_SIZE_VER7,
config=PERF_COUNT_HW_CPU_CYCLES,
sample_freq=4000, sample_type=PERF_SAMPLE_IP|PERF_SAMPLE_TID|PERF_SAMPLE_TIME|PERF_SAMPLE_ID|PERF_SAMPLE_PERIOD|PERF_SAMPLE_BRANCH_STACK,
read_format=PERF_FORMAT_ID,
disabled=1,
inherit=1,
mmap=1,
comm=1,
freq=1,
enable_on_exec=1,
task=1,
precise_ip=3 /* must have 0 skid */,
sample_id_all=1,
exclude_guest=1,
mmap2=1,
comm_exec=1,
ksymbol=1,
bpf_event=1,
...},
11127,
7,
-1,
PERF_FLAG_FD_CLOEXEC) = 12 I’ve formatted this to make the relationship of the parameters a little clearer. Most significant is that the first parameter is a large structure, which strace knows how to interpret.
If we keep looking down the output of strace, we can see another block of perf_event_open. When all of these are executed we end up with file descriptors 4-12 and 13-20 open for the remainder of the program as products of the perf_event_open system call. These are never read from, so the information must come from the kernel via another means. Again, we can see a block of related system calls, this time ioctls:
ioctl(13, PERF_EVENT_IOC_ENABLE, 0) = 0
ioctl(14, PERF_EVENT_IOC_ENABLE, 0) = 0
ioctl(15, PERF_EVENT_IOC_ENABLE, 0) = 0
ioctl(16, PERF_EVENT_IOC_ENABLE, 0) = 0
ioctl(17, PERF_EVENT_IOC_ENABLE, 0) = 0
ioctl(18, PERF_EVENT_IOC_ENABLE, 0) = 0
ioctl(19, PERF_EVENT_IOC_ENABLE, 0) = 0
ioctl(20, PERF_EVENT_IOC_ENABLE, 0) = 0
But we do a see a clone system call, which implied a child process or thread.
clone3({flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, child_tid=0x7faf329ef910, parent_tid=0x7faf329ef910, exit_signal=0, stack=0x7faf321ef000, stack_size=0x7ffec0, tls=0x7faf329ef640} => {parent_tid=[11539]}, 88) = 11539
If we look for system calls based on this pid (11539) we later see:
poll([{fd=13, events=POLLIN|POLLERR|POLLHUP}, {fd=14, events=POLLIN|POLLERR|POLLHUP}, {fd=15, events=POLLIN|POLLERR|POLLHUP}, {fd=16, events=POLLIN|POLLERR|POLLHUP}, {fd=17, events=POLLIN|POLLERR|POLLHUP}, {fd=18, events=POLLIN|POLLERR|POLLHUP}, {fd=19, events=POLLIN|POLLERR|POLLHUP}, {fd=20, events=POLLIN|POLLERR|POLLHUP}], 8, 1000 <unfinished ...>However, the only time this pid is referenced again is to clean up, in this block of syscalls:
[pid 11539] <... poll resumed>) = 0 (Timeout)
[pid 11539] rt_sigprocmask(SIG_BLOCK, ~[RT_1], NULL, 8) = 0
[pid 11539] madvise(0x7faf321ef000, 8368128, MADV_DONTNEED) = 0
[pid 11539] exit(0) = ?
[pid 11539] +++ exited with 0 +++
This is a weekly report from the CPE (Community Platform Engineering) Team. If you have any questions or feedback, please respond to this report or contact us on #redhat-cpe channel on libera.chat.
We provide you both infographics and text version of the weekly report. If you just want to quickly look at what we did, just look at the infographic. If you are interested in more in depth details look below the infographic.
Week: 22 May – 26 May 2023
Read more: CPE Weekly update – Week 21 2023 <figure class="wp-block-image size-large">
</figure>
Purpose of this team is to take care of day to day business regarding CentOS and Fedora Infrastructure and Fedora release engineering work.
It’s responsible for services running in Fedora and CentOS infrastructure and preparing things for the new Fedora release (mirrors, mass branching, new namespaces etc.).
The ARC (which is a subset of the team) investigates possible initiatives that CPE might take on.
[Planning board](Link to planning board)
Docs
Extra Packages for Enterprise Linux (or EPEL) is a Fedora Special Interest Group that creates, maintains, and manages a high-quality set of additional packages for Enterprise Linux, including, but not limited to, Red Hat Enterprise Linux (RHEL), CentOS and Scientific Linux (SL), Oracle Linux (OL).
EPEL packages are usually based on their Fedora counterparts and will never conflict with or replace packages in the base Enterprise Linux distributions. EPEL uses much of the same infrastructure as Fedora, including buildsystem, bugzilla instance, updates manager, mirror manager and more.
CPE has few members that are working as part of Community Design Team. This team is working on anything related to design in Fedora Community.
This initiative is working on enhancing current DNF mirrors-countme script, which is used to provide statistics about number of Fedora installations on machines. This script has few bottlenecks that will be addressed as part of this intiative.
ARC investigation
The post CPE Weekly update – Week 21 2023 appeared first on Fedora Community Blog.