fidzu : Fedora

14 Apr 2026 11:15am GMT

I want to say up front that the point of this post is not to disparage Trivy or its maintainers. They've had a rough few weeks and I feel for them. I only discuss Trivy as a recent example of a bad day at the office.

The saying "there's no such thing as bad publicity" always felt a little gross to me. There are a lot of reasons you might get noticed that are bad, and it should feel bad to do bad things. But maybe there's something to it. If you handle a PR disaster well, you might come out ahead (although you'd still probably prefer to not deal with it in the first place).

Bad publicity is good?

As you may know, the Trivy project fell victim to an attack last month. The compromise affected not just Trivy, but its sponsoring company and many downstream projects and companies. It was - and continues to be - a big deal.

Out of curiosity, I decided to look to see if people were switching from Trivy to other projects. I decided to use GitHub stars as a proxy for interest. Yes, GitHub stars are meaningless. But I figured a relative change might indicate interest in alternatives. Much to my surprise, Trivy's star count increased pretty dramatically post-compromise. Syft and cdxgen, which seem to be the main alternatives for SBOM generation, saw no such bump. Of course, this doesn't necessarily mean that people aren't shifting away from Trivy. But I expected to see the opposite of what the star counts show.

The past few weeks have been a PR nightmare for Trivy, and I'm sure it's been entirely unpleasant for the maintainers. I don't wish this on anyone, but if you find yourself in this kind of situation, take heart. There's at least some indication that your project can survive this kind of catastrophic event.

It's worth noting that it may just be too early to tell what the future holds for Trivy. While they've received a lot more stars and attention, there haven't been any commits to main in three weeks. People are still opening issues and pull requests, so it may just be that the maintainers are still focused on cleanup. I hope that the project comes back stronger and more secure, but time will tell.

Disaster recovery

If your project has a PR nightmare, stay calm. If you have the resources to bring in a crisis PR expert, do that and ignore everything else I say after this. Most likely, though, you don't have the resources to bring in a pro. So here's my amateur advice:

• Mitigate the damage. Take whatever technical steps are necessary to keep the problem from getting worse. This may include rotating credentials, disabling CI pipelines, locking issues, or turning off services. This step is the most important because you don't want the problem getting worse while you're handling communication.
• Create an advisory if appropriate. Do this if there's a vulnerability in your software that you're addressing. You can skip this for other flavors of disaster. If you're on GitHub, you can follow the GHSA creation process. Other hosting platforms may have their own system. As a last resort, you can request a CVE at https://cveform.mitre.org/.
• Communicate honestly and factually. Tell people what happened and, if applicable, how to know if they're affected and how to address it. Don't try to hide uncomfortable facts. Be honest, but don't speculate or guess. You can always update as new facts come to light, but you can't un-say things.
• Don't feel obligated to correct everyone. As the story spreads, people will get things wrong. Perhaps aggressively so. You don't need to put your energy into correcting every misstatement posted by some rando online. If news outlets or influential people misstate facts, you can give them the correct version. If they draw inferences that you disagree with, it's probably best to let it go.

This post's featured photo by Ante Hamersmit on Unsplash.

The post Handling a PR disaster for your project appeared first on Duck Alignment Academy.

08 Apr 2026 12:00pm GMT

So, I know you have either ~/.bashrc and ~/.bash_profile or ~/.profile in your installation. We all do. And many apps we use on a daily basis use those. Plus, you like your aliases, your own env variables and maybe even one or two bash functions you like to use.

That creates a problem. You have everything in a single file (or two) and you have a mess. It's hard to read, hard to organize and a single mistake renders that file useless. Well, maybe not useless, but you get the idea. It's a bad idea to have a 500-line config file, ¿no crees?

So, which solutions are there?

Easy, just npm install .... Yeah, right. Who wants more terrible TypeScript/EcmaScript code in their environment? I mean, really. And it comes in troves! Huge amounts of it everywhere! No mames, we can do better with plain old Bash.

The trick is actually much simpler. Here's how I do it:

Filename: ~/.bashrc

## Load any supplementary scripts from ~/.bashrc.d/
if [[ -d $HOME/.bashrc.d ]]; then
   for f in "$HOME"/.bashrc.d/*.bash; do
      [[ -f "$f" ]] && source "$f"
   done

   unset -v f
fi

Now, you can do the same for your bash profile, which is the preferred place to put things like environment variables and such.

Filename: ~/.bash_profile

## Load any supplementary scripts from ~/.bash_profile.d/
if [[ -d ~/.bash_profile.d ]]; then
   for f in ~/.bash_profile.d/*.bash; do
      [[ -f "$f" ]] && source "$f"
   done

   unset -v f
fi

This is a neat trick, if I may say so. It enables me to create independent files for different things. For example, I like my $GOPATH env variable to point to ~/Projects/go. Also, I like to add Go's bin directory to my $PATH. Easy enough, right?

But, where do I put it?

Main Differences:

~/.bashrc:

Read every time you open a new interactive terminal. Perfect for aliases and prompts.

~/.bash_profile:

Read only once upon login. Best for environment variables that should be inherited by all child processes.

That said, I am putting my go.bash file in ~/.bashrc.d/go.bash:

# go settings
export GOPATH=$HOME/src/go
export PATH=$PATH:$GOPATH/bin

Now, it's as easy as opening a new terminal (I set up my terminal to use a login shell) or I can just source ~/.bash_profile. In Fedora, sourcing ~/.bash_profile will source ~/.bashrc if it exists anyway. ;D

One more customization I really like:

# ~/.bash_profile.d/ls.bash
alias ls='ls --color=auto --group-directories-first'

That one makes my directories appear before the files when using ls. The --color=auto flag is just to make the default colors stay.

08 Apr 2026 1:30am GMT

The Fedora Project's Code of Conduct and its reports are managed by the Fedora Code of Conduct Committee, the Fedora Community Architect, and the Fedora Project Leader. We publish this summary to demonstrate our commitment to community safety and our project's social fabric.

This post covers the year of reports received in the 2025 calendar year. The purpose of publishing the annual Code of Conduct Report is to provide transparency, insight, and awareness into the health signs of the community.

How'd it go in 2025

In 2025, we had a slight uptick in engagement from 2024. 14 reports were opened in 2025, compared to 11 reports in 2024. While we saw some members step down this year, the Fedora Code of Conduct Committee (CoCC) also refreshed its membership with new voices. Jef Spaleta, Chris Idoko, and Ankur Sinha were nominated this year to maintain responsiveness and steer our community standards forward.

The majority of issues reported in the year 2025 were largely handled through "shoulder taps" and formal reach-outs. This is in comparison to disciplinary actions or emergency action requiring bans or long-term suspensions. While reports did increase from 2024 to 2025, the difference is negligible. The Committee expects this number to fluctuate annually, as world events and international conflicts often impact the social dynamics of communities like ours.

You can see the full data from 2025 in the table below.

Community Health Assessment

After six years of reporting, looking back at our journey from the modernization of the Code of Conduct to where we stand today, it is encouraging to see how much we have grown together. Yearly reports indicate while our community continues to have conflicts (as any healthy community ought to), incident severity continues to decrease comparing reports spanning 2020 through 2025. We attribute this consistent reduction in "opened reports" and "CoC interventions" to the maturity of our self-moderation culture.

A significant part of this positive atmosphere is thanks to the refreshed CoC guidelines established by Marie Nordin in 2021 successfully addressing the peak in incidents that occurred in the COVID-19. These were roadmaps on how we want to treat each other. Seeing these guidelines in actions in our reports shows that they are working as hoped. We feel the community is in a healthy place at this time, but a healthy committee is one that never stops listening. We would love to hear your thoughts, feedback and suggestions on how we can continue to help our shared spaces feel safe, inclusive and welcoming.

Looking forward to 2026

If you witness or are part of a situation that violates Fedora's Code of Conduct, please open a private report on the [Code of Conduct repo] or email codeofconduct@fedoraproject.org. As always, your reports are confidential and only visible to the Code of Conduct Committee.

Remember that opening a CoC report does not automatically mean action will be taken. Sometimes things can be clarified, improved, or resolved entirely. Or, it could be something pretty small, but it definitely wasn't okay, and you don't want to make a big deal… open that report anyway, because it could show a pattern of behavior that is negatively impacting more people than yourself.

Here is a reminder to our Fedora community to be kind and considerate to each other in all our interactions. We all depend on each other to create a community that is healthy, safe, and happy. Most of all, we love seeing folks self-moderate and stand up for the right thing day to day in our community. Keep it up, and keep being awesome Fedora, we <3 you!

About the Committee

Fedora Project's Code of Conduct and reports are managed by the Fedora Code of Conduct Committee (CoCC). The Fedora CoCC is made up of the Fedora Project Leader, Jef Spaleta; the Fedora Community Architect, Justin Wheeler; the Red Hat legal team, as appropriate; and community nominated members. Jef Spaleta, Chris Onoja Idoko, Ankur Sinha, nominated this year.

We're incredibly grateful to Josh Berkus and Laura Santamaria for stepping up as term-limited members of the Fedora Code of Conduct Committee (CoCC). Their commitment ensured we had consistent coverage through September 30th, 2025, providing vital support until our newest nominees were fully onboarded and trained.

The post Fedora Code of Conduct Report 2025 appeared first on Fedora Community Blog.

07 Apr 2026 12:00pm GMT

07 Apr 2026 8:00am GMT

¿Te acuerdas de Planeta Linux México? Qué tiempos aquellos, compa. Hoy me puse nostálgico pensando en cómo ese espacio nos unía a todos los que andábamos metidos en el rollo del software libre hace ya más de dos décadas. Planeta Libre no es nomás un agregador de blogs; es la neta, es la continuación de un esfuerzo comunitario que se niega a morir.

07 Apr 2026 6:00am GMT

06 Apr 2026 11:15am GMT

06 Apr 2026 8:00am GMT

04 Apr 2026 7:10pm GMT

A somewhat quiet week in fedora land this time, which is nice, as it allows for catching up on planned work. Of course there was the usual flow of day to day items too.

04 Apr 2026 6:18pm GMT

04 Apr 2026 2:43pm GMT

04 Apr 2026 2:43pm GMT

04 Apr 2026 2:43pm GMT

04 Apr 2026 2:43pm GMT

04 Apr 2026 2:43pm GMT

04 Apr 2026 2:43pm GMT