fidzu : Fedora

Hoy me acordé de lo útiles que son los atajos de Readline.

Estaba tecleando un comando larguísimo y me equivoqué al final. En lugar de borrar todo, usé Ctrl + A y Ctrl + E para saltar, y Ctrl + W para borrar palabras. ¡Chido! Readline es la librería que hace que Bash sea tan poderoso. Con sus atajos, editas líneas como un pro, sin mouse. La neta, una vez que los aprendes, no vives sin ellos.

28 Nov 2025 4:00pm GMT

26 Nov 2025 7:00am GMT

Hoy me acordé cuando un compa me pidió ayuda con su laptop llena de virus y lentitud. La neta, Windows es como una novia celosa: te controla todo y te deja sin libertad. Pero GNU/Linux es abierto, gratis y bien chingón. Vamos a migrar paso a paso para que no te pierdas en el camino.

25 Nov 2025 4:00pm GMT

¿Quieres aprender Vim?

Vim es un editor de texto muy perro que ha estado por ahí desde hace décadas. La neta, al principio parece complicado, pero una vez que lo dominas, ¡tu productividad se dispara! En este artículo, te cuento lo básico de Vim y unos consejos útiles para que empieces.

24 Nov 2025 4:00pm GMT

There have been a few discussions about what Flathub should do to push developers to maintain their apps on the latest versions of the published runtimes. But most of those lack important details around how this would actually happen. I will not discuss in this post the technical means that are already in place to help developers keep their dependencies up to date. See the Flathub Safety: A Layered Approach from Source to User blog post instead.

The main thing to have in mind is that Flathub is not a commercial entity like other app stores. Right now, developers that put their apps on Flathub are (in the vast majority) not paid to do so and most apps are under an open source license.

So any discussion that starts with "developers should update to the latest runtime or have their apps removed" directly contradicts the social contract here (which is also in the terms of most open source licenses): You get something for free so don't go around making demands unless you want to look like a jerk. We are not going to persuade overworked and generally volunteer developers to update their apps by putting pressure on them to do more work. It's counter productive.

With that out of the way, how do we gently push developers to keep their apps up to date and using the latest runtime? Well, we can pay them. Flathub wants to setup a way to offer payments for applications but unfortunately it's not ready yet. So in the meantime, the best option is to donate to the projects or developers working on those applications.

And make it very easy for users to do so.

Now we are in luck, this is exactly what some folks have been working on recently. Bazaar is a Flathub first app store that makes it really easy to donate to the apps that you have installed.

But we also need to make sure that the developers actually have something set up to get donations.

And this is were the flatpak-tracker project comes in. This project looks for the donation links in a collection of Flatpaks and checks if there is one and if the website is still up. If it's not, it opens issues in the repo for tracking and fixing. It also checks if those apps are using the latest runtimes and open issues for that as well (FreeDesktop, GNOME, KDE).

If you want to help, you can take a look at this repo for apps that you use and see if things needs to be fixed. Then engage and suggest fixes upstream. Some of this work does not require complex technical skills so it's a really good way to start contributing. This is probably one of the most direct way to enable developers to receive money from their users, via donations.

Updating the runtime used by an app usually requires more work and more testing, but it's a great way to get started and to contribute to your favorite apps. And this is not just about Flathub: updating a Qt5 app to run with Qt6, or a GNOME 48 app to 49, will help everyone using the app.

We want to build an App Store that is respectful of the time developers put into developing, submitting, publishing, testing and maintaining their apps.

We don't want to replicate the predatory model of other app stores.

Will some apps be out of date sometimes? Probably, but I would rather have a sustainable community than an exploiting one.

23 Nov 2025 11:00pm GMT

Just a quick post to note my blogiversery.

22 years ago in 2003 I posted my first entry here.

Back then I was running a very new version of something called wordpress, then switched to wordpress-mu, then back to wordpress when multiuser came back into core wordpress and then finally to nikola.

It may be that blogs are out of vouge these days, but I still find them nice for longer thoughts that seem way too busy for social media.

23 Nov 2025 6:14pm GMT

¡Heytale! ¿Quieres saber sobre Podman?

Podman es un motor de contenedores sin daemon para desarrollar, gestionar y ejecutar contenedores OCI en Linux. ¡A diferencia de Docker, no necesita un daemon corriendo, lo que lo hace más seguro y eficiente! Es compatible con imágenes Docker y se integra con Kubernetes para despliegues en la nube.

# podman con systemd
## iniciar contenedor
podman run -di --name cs10-systemd centos:stream10

## instalar systemd y postgresql
podman exec cs10-systemd dnf -y install systemd postgresql-server sudo

## limpiar
podman exec cs10-systemd dnf clean all

## commitear a imagen
podman commit -s cs10-systemd cs10-systemd

## borrar contenedor
podman rm -f cs10-systemd

## correr con systemd
podman run -dt -p 127.0.0.1:5432:5432 --name=cs10-systemd localhost/cs10-systemd /usr/sbin/init

## configurar postgresql
podman exec cs10-systemd postgresql-setup --initdb

## habilitar e iniciar postgresql
podman exec cs10-systemd systemctl enable --now postgresql

## crear usuario y db
podman exec cs10-systemd sudo -u postgres createuser -dRS --no-replication renich
podman exec cs10-systemd sudo -u postgres createdb renich
podman exec cs10-systemd sudo -u postgres psql -c "ALTER USER renich WITH PASSWORD 'MySuperPass';"

## crear pg_hba.conf
cat << EOF > pg_hba.conf
local all all peer
host all renich 127.0.0.1/32 scram-sha-256
host all renich ::1/128 scram-sha-256
EOF

podman cp pg_hba.conf cs10-systemd:/var/lib/pgsql/data/pg_hba.conf
rm -f pg_hba.conf

## verificar
podman exec cs10-systemd systemctl restart postgresql
podman exec cs10-systemd systemctl status postgresql

PGPASSWORD='MySuperPass' psql -h 127.0.0.1 -l

# limpieza
podman rm -f cs10-systemd
podman rmi cs10-systemd

23 Nov 2025 6:00pm GMT

Another busy week in fedora infrastructure. Here's my attempt at a recap of the more interesting items.

22 Nov 2025 8:48pm GMT

21 Nov 2025 3:38pm GMT

This is a report created by CLE Team, which is a team containing community members working in various Fedora groups for example Infratructure, Release Engineering, Quality etc. This team is also moving forward some initiatives inside Fedora project.

Week: 17 November - 21 November 2025

Fedora Infrastructure

This team is taking care of day to day business regarding Fedora Infrastructure.
It's responsible for services running in Fedora infrastructure.
Ticket tracker

• The intermittent 503 timeout issues plaguing the infra appear to finally be resolved, kudos to Kevin and the Networking team for tracking it down.
• The Power10 hosts which caused the outage last week are now installed and ready for use.
• Crashlooping OCP worker caused issues with log01 disk space
• Monitoring migration to Zabbix is moving along, with discussions of when to make it "official".
• AI scrapers continue to cause significant load. A change has been made to bring some of the hits to src.fpo under the Varnish cache, which may help.
• Update/reboot cycle planned for this week.

CentOS Infra including CentOS CI

This team is taking care of day to day business regarding CentOS Infrastructure and CentOS Stream Infrastructure.
It's responsible for services running in CentOS Infratrusture and CentOS Stream.
CentOS ticket tracker
CentOS Stream ticket tracker

• HDD issue on internal storage server for CentOS Stream build infra
• Update Kmods SIG Tags (remove EPEL)
• cbs signing queue stuck
• Verify postfix spam checks
• Deploy new x86_64/aarch64 koji builders for CBS
• Prepare new signing host for cbs in RDU3
• https://cbs.centos.org is now fully live from RDU3 (DC-move) : kojihub/builders in rdu3 and/or remote AWS VPC isolated network, and also signing/releng process

Release Engineering

This team is taking care of day to day business regarding Fedora releases.
It's responsible for releases, retirement process of packages and package builds.
Ticket tracker

• EPEL 10.1 ppc64le buildroot broken
• Transfer device-mapper-multipath ownership to real person
• Transfer repo ownership to real person
• fcitx5-qt update didn't get to updates repository
• Fedora 43 branch for pgbouncer stuck
• Help with rebuilds
• Follow up on Packages owned by invalid users fesco#3475

RISC-V

• F43 RISC-V rebuild status: the delta for F43 RISC-V is still about ~2.5K packages compared to F43 primary. Current plan: once we hit ~2K package delta, we'll start focusing on the quality of the rebuild and fix whatever important stuff that needs fixing. (Here is the last interim update to the community.)
• Community highlight: David Abdurachmanov (Rivos Inc) has been doing excellent work on Fedora 43 rebuild, doing a lot of heavy-lifting. He also provides quite some personal hardware for Koji rebuilders.

Forgejo

Updates of the team responsible for Fedora Forge deployment and customization.
Ticket tracker

• Redirects for attachments retention during repository migration [A] [B] [C] [D]
• Fedora -> Forgejo talk for Fedora 43 release party has been recorded
• Valkey self managed cluster deployed for Forgejo caching on staging - prod next
• Private issues - Analysis on database schema, access protection, API layer
• Forgejo support for Konflux explored -Weighed in on Konflux roadmap meeting
• Action runners - cleanup for finished runners and workaround for service routes, demo of declarativeness recorded
• Migration request for Commops SIG, Cloud SIG and AI/ML SIG completed
• Fixes for user creation issue upstreamed, fixed Anubis problem in the production

List of new releases of apps maintained by I&R Team

Minor update of FMN from 3.3.0 to 3.4.0
Minor update of FASJSON from 1.6.0 to 1.7.0
Minor update of Noggin from 1.10.0 to 1.11.0

If you have any questions or feedback, please respond to this report or contact us on #admin:fedoraproject.org channel on matrix.

The post Community Update - Week 47 appeared first on Fedora Community Blog.

21 Nov 2025 10:00am GMT

RC5 was GOLD, so version 8.5.0 GA was just released, at the planned date.

A great thanks to Volker Dusch, Daniel Scherzer and Pierrick Charron, our Release Managers, to all developers who have contributed to this new, long-awaited version of PHP, and to all testers of the RC versions who have allowed us to deliver a good-quality version.

RPMs are available in the php:remi-8.5 module for Fedora and Enterprise Linux ≥ 8 and as Software Collection in the remi-safe repository.

Read the PHP 8.5.0 Release Announcement and its Addendum for new features and detailed description.

For memory, this is the result of 6 months of work for me to provide these packages, starting in July for Software Collections of alpha versions, in September for module streams of RC versions, and also a lot of work on extensions to provide a mostly full PHP 8.5 stack.

Installation: read the Repository configuration and choose installation mode, or follow the Configuration Wizard instructions.

Replacement of default PHP by version 8.5 installation (simplest):

Fedora (dnf 5):

dnf install https://rpms.remirepo.net/enterprise/remi-release-$(rpm -E %fedora).rpm
dnf module reset php
dnf module enable php:remi-8.5
dnf install php

Enterprise Linux (dnf 4):

dnf install https://rpms.remirepo.net/enterprise/remi-release-$(rpm-E %rhel).rpm
dnf module switch-to php:remi-8.5/common

Parallel installation of version 8.5 as Software Collection (recommended for tests):

yum install php85

To be noticed :

• EL-10 RPMs are built using RHEL-10.0
• EL-9 RPMs are built using RHEL-9.6
• EL-8 RPMs are built using RHEL-8.10
• This version will also be the default version in Fedora 44
• Many extensions are already available, see the PECL extension RPM status page.

Information, read:

• PHP 8.5 Released!
• Migrating from PHP 8.4.x to PHP 8.5.x
• UPGRADING
• UPGRADING.INTERNALS

Base packages (php)

Software Collections (php84)

21 Nov 2025 7:52am GMT

20 Nov 2025 10:00pm GMT

If you're wearing more than one hat on your head something is probably wrong. In open source, this can feel like running a haberdashery, with a focus on juggling roles and responsibilities that sometimes conflict, instead of contributing. In October, I attended the first OpenSSL Conference and got to see some amazing talks and, more importantly, meet some truly wonderful people and catch up with friends.

Disclaimer: I work at Microsoft on upstream Linux in Azure and was formerly at Red Hat. These reflections draw on roles I've held in various communities and at various companies. These are personal observations and opinions.

Let's start by defining a hat. This is a situation where you are in a formalized role, often charged with representing a specific perspective, team, or entity. The formalization is critical. There is a difference between a contributor saying something, even one who is active in many areas of the project, and the founder, a maintainer, or the project leader saying it. That said, you are always you, regardless of whether you have one hat, a million hats, or none. You can't be a jerk in a forum and then expect everyone to ignore that when you show up at a conference. Hats don't change who you are.

During a few of the panels, several panelists were trying to represent multiple points of view. They participate or have participated in multiple ways, for example on behalf of an employer and out of personal interest. One speaker has a collection of colored berets they take with them onto the stage. Over the course of their comments they change the hat on their head to talk to different, and quite often all, sides of a question. I want to be clear, I am not calling this person out. This is the situation they feel like they are in.

I empathize with them because I have been in this same situation. I have participated in the Fedora community as an individually motivated contributor, the Fedora Community Action and Impact Coordinator (a paid role provided to the community by Red Hat), and as the representative of Red Hat discussing what Red Hat thinks. Thankfully, I never did them all at once, just two at a time. I felt like I was walking a tightrope. Stressful. I didn't want my personal opinion to be taken as the "voice" of the project or of Red Hat.

This experience was formative and helped me navigate this the next time it came up when I became Red Hat's representative to the CentOS Project Board. My predecessor in the role had been a long-time individual contributor and was serving as the Red Hat representative. They struggled with the hats game. The first thing I was told was that the hat switching was tough to follow and people were often unsure if they were hearing "the voice of Red Hat" or the "voice of the person." I resolved to not further this. I made the decision that I would only ever speak as "the voice of Red Hat."¹ It would be clear and unambiguous.

But, you may be thinking, what if you, bex, really have something you personally want to say. It did happen and what I did was leverage the power of patience and friendship.

Patience was in the form of waiting to see how a conversation developed. I am very rarely the smartest person in the room. I often found that someone would propose the exact thing I was thinking of, sometimes even better or more nuanced than I would have.

On the rare occasions that didn't happen I would backchannel one of my friends in the room and ask them to consider saying what I thought. The act of asking was useful for two reasons. One, it was a filter for things that may not have been useful to begin with. Two, if someone was uneasy with sharing my views, their feedback was often useful in helping me better understand the situation.

In the worst case, if I didn't agree with their feedback, I could ask someone else. Alternatively, I could step back and examine what was motivating me so strongly. Usually that reflection revealed this was a matter of personal preference or style that wouldn't affect the outcome in the long term. It was always possible that I'd hit an edge case where I genuinely needed a second hat.

I recognize this is not an easy choice to make. I had the privilege of not having to give up an existing role to make this decision. However, I believe that in most cases when you do have to give up one role for another, you're better off not trying to play both parts. You're likely blocking or impeding the person who took on the role you gave up. If you have advice a quiet sidebar with them will go further than potentially forcing them into public conversations that don't need to be public. Your successor may do things differently, you should be ok with that. And remember what I wrote above, you're not being silenced.

So when do multiple hats tend to happen? Here are some common causes of hat wearing:

1. When you're in a project because your company wants you there and you are personally interested in the technology.
2. You participate in the project and a fork, downstream, or upstream that it has a relationship with.
3. You participate in multiple projects all solving the same problem, for example multiple Linux distributions.
4. You sit on a standards body or other organization that has general purview over an area and are working on the implementation.
5. You work on both an open source project and the product it is commercially sold as.
6. You're a member of a legally liable profession, such as a lawyer (in many jurisdictions) so anything you say can be held to that standard.
7. You're in a small project and because of bootstrapping (or community apathy) you're filling multiple roles during a "forming" phase.

This raises the question of which hat you should wear if you feel like you have more than one option. Here's how I decide which hat to wear:

1. Is this really a multi-hat situation? Are you just conflicted because you have views as a member of multiple projects or as someone who contributes in multiple ways that aren't in alignment? If it isn't a formalized role you're struggling with the right problem. Speak your mind. Share the conflict and lack of alignment. This is the meat of the conversation.
2. Why are you here? You generally know. That is the hat you wear. If you're at a Technical Advisory Committee Meeting on behalf of your company and an issue about which you are personally passionate comes up - remember patience and friendship because this is a company hat moment.
3. If you are in a situation where you can truly firewall off the conversations, you can change to an alternative hat. What this means is when you find yourself in a space where the provider of your other hat is very uninvolved. For example, if you normally work on crypto for your employer, but right now you are making documentation website CSS updates. Hello personal hat.
4. If you're in a 1:1 conversation and you know the person well, you can lay out all of your thoughts - just avoid the hat language. Be direct and open. If you don't know the person well, you should probably err on the side of being conservative and think carefully about states 1 and 2 above.

Some will argue that in smaller projects or early-stage efforts the flexibility of multiple roles is a feature, not a bug, allowing for rapid adaptation before formal structures are needed. That's fair during a "forming" phase - but it shouldn't become permanent. As the project matures, work to clarify roles and expectations so contributors can focus on one hat at a time.

As a maintainer or project leader, when you find people wearing multiple hats, it's a warning flag. Something isn't going right. Figure it out before the complexity becomes unmanageable.

20 Nov 2025 3:00pm GMT

RPMs of PHP version 8.4.15 are available in the remi-modular repository for Fedora ≥ 41 and Enterprise Linux ≥ 8 (RHEL, Alma, CentOS, Rocky...).

RPMs of PHP version 8.3.28 are available in the remi-modular repository for Fedora ≥ 41 and Enterprise Linux ≥ 8 (RHEL, Alma, CentOS, Rocky...).

ℹ️ The packages are available for x86_64 and aarch64.

ℹ️ There is no security fix this month, so no update for versions 8.1.33 and 8.2.29.

These versions are also available as Software Collections in the remi-safe repository.

⚠️ These versions introduce a regression in MySQL connection when using an IPv6 address enclosed in square brackets. See the report #20528. A fix is under review and will be released soon.

Version announcements:

• PHP 8.4.15 Release Annoucement
• PHP 8.3.28 Release Annoucement

ℹ️ Installation: use the Configuration Wizard and choose your version and installation mode.

Replacement of default PHP by version 8.4 installation (simplest):

dnf module switch-to php:remi-8.4/common

Parallel installation of version 8.4 as Software Collection

yum install php84

Replacement of default PHP by version 8.3 installation (simplest):

dnf module switch-to php:remi-8.3/common

Parallel installation of version 8.3 as Software Collection

yum install php83

And soon in the official updates:

• Fedora Rawhide now has PHP version 8.5.0
• Fedora 43 - PHP 8.4.15
• Fedora 42 - PHP 8.4.15

⚠️ To be noticed :

• EL-10 RPMs are built using RHEL-10.0 (next build will use 10.1)
• EL-9 RPMs are built using RHEL-9.6 (next build will use 9.7)
• EL-8 RPMs are built using RHEL-8.10
• intl extension now uses libicu74 (version 74.2)
• mbstring extension (EL builds) now uses oniguruma5php (version 6.9.10, instead of the outdated system library)
• oci8 extension now uses the RPM of Oracle Instant Client version 23.8 on x86_64 and aarch64
• a lot of extensions are also available; see the PHP extensions RPM status (from PECL and other sources) page

ℹ️ Information:

• Migrating from PHP 8.2.x to PHP 8.3.x
• Migrating from PHP 8.3.x to PHP 8.4.x

Base packages (php)

Software Collections (php83 / php84)

20 Nov 2025 2:21pm GMT

Hi,
I'm Jef, the Fedora Project Leader.

As FPL I believe Fedora needs to be part of a healthy flatpak ecosystem. I'd like to share my journey in working towards that over the last few months with you all, and include some of the insights that I've gained. I hope by sharing this with you it will encourage those who share my belief to join with me in the journey to take us to a better future for Fedora and the entire ecosystem.

The immediate goal

First, my immediate goal is to get the Fedora ChangeProposal that was submitted to make Flathub the default remote for some of the Atomic desktops accepted on reproposal. I believe implementing the idea expressed in that ChangeProposal is the best available option for the Atomic desktops that help us down the path I want to see us walking together.

There seems to be wide appeal from both the maintainers of specific Fedora outputs, and the subset of Fedora users of those desktop outputs, that using Flathub is the best tradeoff available for the defaults. I am explicitly not in favor of shuttering the Fedora flatpaks, but I do see value in changing the default remote, where it is reasonable and desirable to do so. I continue to be sensitive to the idea that Fedora Flatpaks can exist because it is delivering value to a subset of users, even when it's not the default remote but still targeting an overlapping set of applications serving different use cases. I don't view this as a zero-sum situation; the important discussion right now is about what the defaults should be for specific Fedora outputs.

What I did this summer

There is a history of change proposals being tabled and then coming back in the next cycle after some of the technical concerns were addressed. There is nothing precedent-setting in how the Fedora Engineering Steering Committee handled this situation. Part of getting to the immediate goal, from my point of view, was doing the due diligence on some of the concerns raised in the FESCo discussion leading to the decision to table the proposal in the last release. So in an effort to get things in shape for a successful outcome for the reproposal, I took it on myself to do some of the work to understand the technical concerns around the corresponding source requirements of the GPL and LGPL licenses.

I felt like we were making some good progress in the Fedora discussion forums back in July. In particular, Timothee was a great help and wrote up an entirely new document on how to get corresponding sources for applications built in flathub's infrastructure. That discussion and the resulting documentation output showed great progress in bringing the signal to noise ratio up and addressing the concerns raised in the FESCo discussion. In fact, this was a critical part of the talk I gave at GUADEC. People came up to me after that talk and said they weren't aware of that extension that Timothee documented. We were making some really great progress out in the open and setting a stage for a successful reproposal in the next Fedora cycle.

Okay, that's all context intended to help you, dear reader, understand where my head is at. Hopefully we can all agree my efforts were aligned with the goal leading up to late July. The next part gets a bit harder to talk about, and involves a discussion of communication fumbles, which is not a fun topic.

The last 3 months

Unfortunately, at GUADEC I found a different problem, one I wasn't expecting to find. Luckily, I was able to communicate face to face with people involved and they confirmed my findings, committed on the spot to get it fixed, and we had a discussion on how to proceed. This started an embargo period where I couldn't participate in the public narrative work in the community I lead. That embargo ended up being nearly 3 months. I don't think any of us who spoke in person that day at GUADEC had any expectation that the embargo would last so long.

Through all of this, I was in communication with Rob McQueen, VP of the Gnome Foundation, and one of the Flathub founders, checking in periodically on when it was reasonable for me to start talking publicly again. It seems that the people involved in resolving the issues took it so seriously that they not only addressed the deficiencies I found -missing files- but committed to creating significant tooling changes to help prevent it from happening again. Some characterized that work as "busting their asses." That's great, especially considering much of that work is probably volunteer effort. Taking the initiative to solve not just the immediate problem, but building tooling to help prevent it is a fantastic commitment, and in line with what I would expect from the volunteers in the Fedora community itself. We're more aligned than we realize I think.

What I've learned from this is there's a balance with regard to embargos that must be struck. Thinking about it, we might have been better served if we had agreed to scope the embargo at the outset and then adjusted later with a discussion on extending the time further, that also gave me visibility into why it was taking additional time. It's one of the ideas I'd like to talk to people about to help ensure this is handled better in the future. There are opportunities to do the sensitive communications a bit better in the future, and I hope in the weeks ahead to talk with people about some ideas on that.

Now with the embargo lifted, I've resumed working towards a successful change reproposal. I've restarted my investigation of corresponding source availability for the runtimes. We lost 3 months to the embargo, but I think there is still work to be done. Already, in the past couple of weeks, I've had one face to face discussion with a FESCo member, specifically about putting a reproposal together, and got useful feedback on the approach to that.

So that's where we are at now. What's next?

The future

I am still working on understanding how source availability works for the Flathub runtimes. I think there is a documentation gap here, like there was for the flatpak-builder sources extension. My ask to the Fedora community, particularly those motivated to find paths forward for Flathub as the default choice for bootc based Fedora desktops, is to join me in clarifying how source availability for the critical FLOSS runtimes works so we can help Flathub by contributing documentation that all Flathub users can find and make use of.

Like I said in my GUADEC talk, having a coherent (but not perfect) understanding of how Fedora users can get the flatpak corresponding sources and make local patched builds is important to me to figure out as we walk towards a future where Flathub is the default remote for Fedora. We have to get to a future where application developers can look at the entire linux ecosystem as one target. I think this is part of what takes the Linux desktop to the next level. But we need to do it in a way that ensures that end users have access to all the necessary source code to stay in control of their FLOSS software consumption. Ensuring users have the ability to patch and build software for themselves is vital, even if it's never something the vast majority of users will need to do. Hopefully, we're just a couple more documents away from telling that story adequately for Flathub flatpaks.

I've found that some of the most contentious discussions can be with people with whom you actually have a significant amount of agreement. Back in graduate school, when my officemate and I would talk about anything we both felt well-informed about and were in high agreement on: politics, comic books, science, whatever it was.. we'd get into some of the craziest, heated arguments about our small differences of opinion, which were minor in comparison to how much we agreed on. And it was never about needing to be right at the expense of the other person. It was never about him proving me wrong or me proving him wrong. It was because we really deeply wanted to be even more closely aligned. After all, we valued each other's opinions. It's weird to think about how much energy we spent doing that. And I get some of the same feeling that this is what's going on now around flatpaks. Sometimes we just need to take a second and value the alignment we do have. I think there's a lot to value right now in the Fedora and Flathub relationship, and I'm committed to find ways both communities can add value to each other as we walk into the future.

The post A statement concerning the Fedora and Flathub relationship from the FPL appeared first on Fedora Community Blog.

20 Nov 2025 12:00pm GMT

20 Nov 2025 5:51am GMT