For almost two decades, the PackageKit package management abstraction layer has shipped with pkcon as its command-line client. pkcon does its job, but it was always kind of a “testing” front-end for the PackageKit daemon rather than a tool designed for everyday use. The focus has instead been on the GUI tools, automatic system updates, GUI application managers and other front-ends. Its command names mirror the D-Bus API almost one-to-one (get-details, get-updates, get-depends), output is very plain, and there is no machine-readable mode for scripting. Most importantly though, there has been no development on it at all for almost a decade, so pkcon was stuck in its rudimentary state from that era.

Since a lot of changes will be coming to PackageKit, and testing the daemon and working with it from the command-line was not very pleasant anymore in 2025/2026, I decided to modernize the tool as part of my work as fellow for the Sovereign Tech Agency last year. pkgcli is the new command-line client for PackageKit. It is built from the ground up to be pleasant to use interactively and easy to drive from scripts.

Why a new tool?

Of course, instead of introducing a new tool, I could have just expanded pkcon instead. The problem with that approach is that the pkcon utility has been around for so long and its command-line API had ossified so much, that rather than changing it and potentially breaking a lot of scripts relying on its quirks, I decided to introduce a new tool instead. pkcon can still be optionally compiled for people who need it in their scripts and workflows.

The goals for pkgcli, and the features it now has are:

• Human-friendly command names. Verbs that read the way you’d describe the task, instead of mirroring the D-Bus API 1:1: show, search, list-updates, what-provides, instead of get-details and friends.
• Readable, colored output by default (still respecting NO_COLOR and degrading gracefully).
• A real scripting mode. A global --json flag emits JSONL instead of fully human-readable output when possible, to make it easier to use the tool for scripting purposes.
• Sensible defaults. A few defaults have been changed, such as the metadata cache-age, or automatic cleanup of unused dependencies being enabled by default. This is more in line with current defaults by other tools and frontends. We also print package information in a slightly different, more readable way.
• Better handling of internationalized text. Text should now align properly in the terminal window, and we should no longer have completely chaotic text output on non-English locales (especially Chinese/Japanese).

Why not pkgctl?

Originally, this tool was called pkgctl, to match other common cross-distro tool names. However, that name was already taken by an Arch-specific distro development tool. When this issue was raised, we decided to just rename our tool to pkgcli with the next release, to avoid the name clash on Arch Linux.

Examples!

Here are some examples on how to use the new tool (some of which include the abridged output pkgcli prints).

Search for anything containing the string “editor” in name or description, then look at the details of one result:

$ pkgcli search editor
▣ ace-of-penguins 1.5~rc2-7.amd64 [debian-testing-main]
▣ acorn-fdisk 3.0.6-14.amd64 [debian-testing-main]
▣ ardour 1:9.2.0+ds-1.amd64 [debian-testing-main]
✔ audacity 3.7.7+dfsg-1.amd64 [manual:debian-testing-main]
✔ audacity-data 3.7.7+dfsg-1.all [auto:debian-testing-main]
▣ augeas-tools 1.14.1-1.1.amd64 [debian-testing-main]
▣ emacs 1:30.2+1-3.all [debian-testing-main]
▣ gedit 48.1-9+b1.amd64 [debian-testing-main]
▣ gedit-common 48.1-9.all [debian-testing-main]
▣ gedit-dev 48.1-9+b1.amd64 [debian-testing-main]
[...]

$ pkgcli show nano
Querying                  [████████████████████████████████████████] 100%
Package: nano
Version: 9.0-1
Summary: small, friendly text editor inspired by Pico
Description: GNU nano is an easy-to-use text editor originally designed as
 a replacement for Pico, the ncurses-based editor from the non-free mailer
 package Pine.
[...]
URL: https://www.nano-editor.org/
Group: publishing
Installed Size: 2.9 MB
Download Size: 646.0 KB

Search only within package names rather than descriptions:

$ pkgcli search name python3

Check for updates. refresh updates the metadata, then list-updates reports what’s available:

$ pkgcli refresh && pkgcli list-updates
Loading cache            [████████████████████████████████████████] 100%
▲ cme 1.048-1.all [debian-testing-main]
▲ gir1.2-gdm-1.0 50.1-2.amd64 [debian-testing-main]
▲ imagemagick 8:7.1.2.24+dfsg1-1.amd64 [debian-testing-main]
▲ imagemagick-7-common 8:7.1.2.24+dfsg1-1.all [debian-testing-main]
▲ imagemagick-7.q16 8:7.1.2.24+dfsg1-1.amd64 [debian-testing-main]
▲ libdlrestrictions1 0.22.0.amd64 [debian-testing-main]
▲ libfftw3-bin 3.3.11-1.amd64 [debian-testing-main]
▲ libfftw3-dev 3.3.11-1.amd64 [debian-testing-main]

Explore relationships between packages:

$ pkgcli list-depends inkscape  # list what inkscape depends on
$ pkgcli list-requiring libappstream5  # list what requires libappstream5

Find the package that provides a capability, here the AV1 GStreamer decoder:

$ pkgcli what-provides "gstreamer1(decoder-video/x-av1)"
✔ gstreamer1.0-plugins-bad 1.28.3-1.amd64 [auto:debian-testing-main]

You can also have JSON output for most commands! Attach --json to any query and pipe the result straight into jq. Each line is a self-contained JSON object:

$ pkgcli --json list-updates | jq -r '.name'
cme
gir1.2-gdm-1.0
imagemagick
imagemagick-7-common
imagemagick-7.q16
libdlrestrictions1
libfftw3-bin
libfftw3-dev
libfftw3-double3

Try it

pkgcli is built by default alongside the rest of PackageKit since PackageKit 1.3.4. If your distribution ships a recent enough PackageKit, it should already be on your PATH. You can read its man page man pkgcli for more information. Feedback, bug reports, and patches are very welcome.

Dear Tumbleweed users and hackers,

This week, Tumbleweed had to take a short break over the weekend. Technically, everything was fine, but with the summer weather approaching in the northern hemisphere, some people tend to do less screen time, especially on weekends. The outcome is still very impressive: five snapshots were published this week (0604, 0605, 0608, 0609, and 0610)

The most relevant changes shipped this week include:

• Mesa 26.1.2
• fontconfig 2.18.0 & 2.18.1: the first version caused some issues and picked the wrong fonts
• harfbuzz 14.2.1
• Linux kernel 7.0.11
• php 8.5.7
• KDE Gear 26.04.2
• tcl/tk 8.6.18
• Mozilla Firefox 151.0.3 & 151.0.4
• sqlite 3.53.2
• systemd 260.2
• file 5.48

Staging still contains the few longer-standing topics from last week and a few more, newer changes, namely:

• MariaDB 12.3.2
• Linux kernel 7.0.12
• KDE Frameworks 6.27
• llvm packaging change: moving away from update-alternatives
• Poppler 26.06.0: breaks the usual suspects like Scribus, Inkscape, LibreOffice
• Qemu 11.0.0: 32-bit host support is being dropped
• KDE Plasma 6.7.0, currently 6.6.91 staged for QA
• Rework of Python3 packaging (as a meta package instead of a provides of the default interpreter)
• gcc 16 as the system default compiler

This is a roundup of articles from the openSUSE community listed on planet.opensuse.org.

The community blog aggregates a list of the featured highlights below from June 5 - 11.

Blogs this week cover a photographer pairing rival AMD and Nvidia GPUs on one openSUSE Leap 16.1 workstation to run Adobe software in a virtual machine, a guide for open-source maintainers on avoiding burnout amid a flood of AI-generated security reports, the release of digiKam 9.1 and second bugfix updates for both KDE Gear 26.04 and Kdenlive. Blogs also highlight a dystopian short story about a web where nothing is free, a talk by KDE e.V. in Barcelona, a Digital Sovereignty event in València, the weekly Tumbleweed snapshot reviews, Plasma 6.7 bugfixing and more.

Here is a summary and links for each post:

Rival GPUs Share One Linux Desktop

The openSUSE News team profiles photographer Klaus Tröger, who recently migrated to the openSUSE Leap 16.1 beta. It talks about the use of Adobe and Photoshop in a Windows 11 virtual machine on a workstation. Performance is nearly native and the passthrough components can be cleanly isolated by IOMMU group.

Digital Sovereignty in the AI Era, New Event Organized by GNU/Linux València

The KDE Blog promotes a new event from the nonprofit association GNU/Linux València titled “Digital Sovereignty in the AI Era,” which takes place June 16 at the Universitat de València. Attendance is free, can be joined online and the session will offer concrete alternatives for regaining technological autonomy.

digiKam 9.1 Released, Making it Easier to Use

The KDE Blog covers the release of digiKam 9.1.0, which arrives after three months of active development focused on database migration, preview improvements, advanced search and general ease of use. The post also recaps the major features of digiKam 9.0 for readers who missed the previous release.

Welcome to the Icon Designer Webring!

Jakub revives a piece of 1990s internet culture. Inspired by Terry Godier’s essay “The Boring Internet,” the post argues that an older, slower, federated web built on open protocols still thrives beneath the commercial layer.

Thirty-Fourth Audio of Podcast Linux – “Maratón Linuxero Live” (Podcast Linux #34)

The KDE Blog continues its index of the now-paused Podcast Linux with episode 34. Host Juan Febles chats with four GNU/Linux veterans Gabriel Viso, Patricio García, Alejandro López and Roberto Ruisánchez about the early days of Linux. The conversation revisits the 1990s and early 2000s.

Kdenlive 26.04.2 Released

The KDE Blog announces the second maintenance release of the Kdenlive 26.04 series. The update fixes issues in rendering, timeline editing and project file management across AppImage and Flatpak packages, including a notable Windows fix that allows exporting videos to a network drive.

Everything Has a Price

Victorhck publishes a Spanish translation of Paul Brown’s dystopian short story “No Such Thing as a Free Lunch,” which is a cautionary tale about a future where every click, app launch and settings change carries a fee and free offerings are outlawed. The fiction follows Joe Bloggs through a world of mandatory hardware upgrades, surveillance AI that taxes productivity and brutal enforcement of software regulations. The story is free to read, which in the tale would be a felony.

Fixing All the Things – This Week in Plasma

The KDE Blog translates the latest “This Week in Plasma” report, which focuses on polishing Plasma 6.7 ahead of its release at the end of the month. Notable fixes include Spectacle’s clipboard behavior during OCR text extraction, low-battery notifications for connected devices appearing over fullscreen apps, and a crash fix when refreshing the list of nearby wireless networks.

Linux Saloon 205 | Open Mic Night

CubicleNate recaps episode 205 of the Linux Saloon podcast. Responding to viewer feedback, the panel shared what they like and dislike about their distributions of choice, covering Tumbleweed’s built-in Snapper rollback and overly aggressive default firewall, a panelist’s switch from GNOME to the Fedora 44 Plasma spin, and praise for MX Linux, CachyOS, Linux Mint and Bazzite, before agreeing to test the LibreWolf browser in an upcoming application appetizer segment.

BuildStream and KDE – New Barcelona Free Software Talk

The KDE Blog announces a new Barcelona Free Software talk taking place on Thursday, June 11 at Akasha Hub in Barcelona. Aleix Pol, president of KDE e.V., will present BuildStream, a powerful software integration tool used to build operating systems and all sorts of packages. Attendees will leave knowing how to build their own operating system and hopefully be ready to contribute to many more projects.

Tumbleweed – Review of the Week 2026/23

Victorhck and Dominique Leuenberger report that Tumbleweed kept rolling through a midweek European holiday with six snapshots published. Key updates included Mesa 26.1.1, Qt 6.11.1, GNOME 50.2, Pipewire 1.6.6, Samba 4.23.8 and 4.24.3, plus a Java packaging migration from update-alternatives to libalternatives. The staging dashboard predicts Linux kernel 7.0.11, KDE Plasma 6.7.0, a rework of Python3 packaging and GCC 16 as the system default compiler arriving soon.

Take it Easy. A Guide to Avoid Burnout During the Vulnpocalypse

Danigm offers open source maintainers a survival guide for the so-called Vulnpocalypse, which refers to the cybersecurity reckoning related to AI-generated security reporting. The post argues that 100 percent secure software doesn’t exist, that the deluge of dubious “high severity” reports is eroding CVE credibility, and that maintainers should learn to recognize and disarm manipulation tactics like queue flooding and gaslighting rather than burn themselves out chasing every cried wolf.

Second Update of KDE Gear 26.04

The KDE Blog highlights KDE Gear 26.04.2. The release resolves a good number of errors across applications, libraries and widgets, including a crash in Akregator on arm64, a startup crash in Skanlite via ksanecore, and a fix for Koko’s move-to-trash action overriding the editor’s delete actions.

View more blogs or learn to publish your own on planet.opensuse.org.

For years, photographer Klaus Tröger built his professional workflow on a quiet contradiction; a Linux workstation running the Adobe software that most people assume belongs on a Mac or a Windows PC.

“I’m not willing to give up Linux, and I’m not willing to give up Adobe,” Klaus said. “So I stopped choosing.”

He has now carried that arrangement onto newer ground. Klaus recently migrated his longtime Debian machine to the beta release of openSUSE Leap 16.1 and has kept editing the whole time, running Adobe Lightroom, Camera Raw and Photoshop inside a Windows 11 virtual machine that never touches the local network directly.

The setup speaks to a small but persistent group of professionals who prefer Linux as their daily environment but cannot abandon Adobe Creative Cloud, whether for client work or long-established editing habits. Open-source alternatives exist, Klaus acknowledges, but they do not always fit an established business.

The hardware behind the system is deliberately dated, and Klaus says that is the point. Rather than chase current components at current prices, he chose Intel’s older LGA-1151 platform, pairing a Core i9-9900K, which is an eight-core, 16-thread chip from Intel’s Coffee Lake generation, with an Asus Z390 WS Pro mainboard. Each was a flagship in its day, he said, delivering strong benchmark performance from the processor and stability from the board. Because the WS Pro has grown rare and expensive, he notes the same approach works with a more common Asus ROG-STRIX Z390-F board and a six-core Core i7-8700K.

The board matters less for speed than for separation. To hand physical hardware to the virtual machine, Klaus relies on the Linux “vfio-pci” driver, which requires that the devices being passed through sit in their own IOMMU group, which is the system the hardware uses to isolate components from one another.

That requirement produces the workstation’s most surprising feature; two graphics cards from rival makers. An AMD Radeon RX 6600 drives the Linux desktop, while an Nvidia RTX 3060 is dedicated entirely to Windows. Contrary to a common assumption, Klaus said, modern Linux handles mixed AMD and Nvidia setups without conflict.

A dedicated graphics card is not optional for the Windows side. Adobe’s software needs a real GPU for post-processing. Software emulation will not do, and the card must clear a modest bar; it needs 1.5 to 2 GB of video memory, DirectX 12 compatibility and a driver no more than seven years old. Passing a qualifying card through to the Windows guest, in its own IOMMU group, lets Adobe applications run with near-native hardware acceleration while Linux remains in charge.

Most consumer mainboards make that separation difficult, Klaus said, because of how they share PCIe lanes and assign IOMMU groups. He offers two ways around it: use the Intel chip’s integrated graphics for the Linux host, the simplest and cheapest option for users with light rendering needs; or run two cards, placing the primary GPU in the CPU-managed first PCIe slot and the pass-through card in a slot managed by the Z390 chipset, which lands them in separate groups.

The rest of the machine follows the same divide-and-isolate logic. A separate USB controller goes to the virtual machine so Windows can have its own keyboard and mouse. Windows lives on its own fast NVMe solid-state drive. Klaus pins 10 processor threads to the host and six to the guest, splits 64 GB of memory evenly between them using huge pages, and swaps the default power daemon for the “tuned” tool set to a virtual-host profile.

He made one deliberate exception. Rather than assign the second NVMe drive straight to Windows, he keeps the guest in a disk-image file on an XFS partition.

“It’s so easy to just copy away the Windows file to get a backup,” he said.

The choice of host operating system was its own deliberation. Klaus had run Debian 13 for its stability. He found openSUSE’s rolling Tumbleweed release too bleeding-edge and Leap 15.6 too dated, which left the Leap 16.1 prerelease as a chance worth taking. The installation, using the Agama installer with an LVM disk layout and a Btrfs root filesystem for snapshots and rollback, produced what he called “zero surprises.”

Performance, he said, is nearly native. Virtualization always carries some overhead, “but it’s fully worth it.” Security is part of the appeal. Windows never sits directly on the local network; it operates behind the Linux host, shielded by the host firewall and additional controls. The arrangement, Klaus said, balances compatibility against exposure. Windows stays available for the few applications that demand it, while Linux runs everything else.

Asked what he would change if he built the machine today, Klaus did not hesitate. “None,” he said. His advice for photographers and power users eyeing a similar build comes down to one decision made early; choose the base hardware carefully, and confirm before buying that the components you intend to pass through can be cleanly separated by IOMMU group. Consumer boards, he warns, often cannot.

Terry Godier wrote a beautiful essay "The Boring Internet". The internet isn't dying, he argues, just the commercial veneer glued on top of it is. Underneath all the engagement metrics and algorithmic feeds, there's still an older, slower, more federated web. One built on protocols nobody owns. RSS feeds still work (thank you, Aaron), people can set up websites and blogs.

Lets start a webring in 2026

Don't worry, I haven't pushed too many pixels and gone a little cuckoo. But it's a fun exercise to remind what the web once was. We'll silently skip over the fact that I actually started using gopher first, but even web surfing didn't begin on a search engine back in the day. It was web rings, later followed by index sites.

Start

Not long ago I posted about designing app icons for 3rd party GNOME app developers. The post generated quite some buzz and some old and new faces started showing up to help with the backlog. So obviously I'd like to take you on a webring tour of all the designers responsible for making the GNOME app ecosystem a little less awkward to browse on Flathub.

Let me introduce you to Brage. He's been around for a couple of years now, helping to tame the flames of the reddit community, helping with the GNOME Circle project to improve the quality of GNOME apps in the wild, creating illustrations for initial states in apps, authoring some noteworthy apps himself. So thank you, Brage, welcome to the 90s!

Next Up: Brage Fuglseth

Dear Tumbleweed users and hackers,

Another rather uneventful week over here in Europe: another holiday in the middle of the week (for some regions, not all of Europe). The openSUSE community, in its international form, is usually not significantly affected by such interruptions and keeps rolling. That’s exactly what was observed this week as well: 6 snapshots (0529, 0530, 0531, 0601, 0602, and 0603) have been published over the last week.

The main updates contained therein were:

• Mesa 26.1.1
• Mariadb 11.8.7 & 11.8.8
• Qt 6.11.1
• Pipewire 1.6.6
• Samba 4.23.8 & 4.24.3
• GNOME 50.2
• util-linux 2.42.1
• gpgme 2.1.0
• java packaging change: migrated from update-alternative to libalternatives
• libvirt 12.4.0

The future is bright, and looking into my crystal ball (or on the staging dashboard) helps me to predict these changes coming to you soon:

• Mesa 26.1.2
• Linux kernel 7.0.11
• harfbuzz 14.2.1
• php 8.5.7
• KDE Gear 26.04.2
• KDE Plasma 6.7.0, currently 6.6.91 staged for QA
• Rework of Python3 packaging (as a meta package instead of a provides of the default interpreter)
• gcc 16 as the system default compiler

Do not let the AI to remove the fun part from software development. We shouldn't allow gen AI to write software just because it "can". First, we must ask if it "should" do it, and even then, we should ask if we want to delegate the fun part, the thinking, the writing, the learning.

Remember what's important, journey before destination, we are the Code:

Do not let AI to destroy the community, do not let it destroy the technological knowledge commons.

tl;dr

Open Source maintainers are dealing with a lot of new reports and pressure to "fix" the project due to generative AI.

We need to find a way of stopping this and get back to something maintainable before all maintainers get burned out and look for a job in a farm:

• 100% secure software doesn't exists, so there will be always a possible CVE there. As Spaf said in 1989:

The only truly secure system is one that is powered off, cast in a block of concrete and sealed in a lead-lined room with armed guards - and even then I have my doubts.

• Fixing bugs, adds new bugs, and if you need to fix something quick, the probability of new bugs will be higher. Do not forget about the First Law of Programming:

If it works, don't touch it

• The amount of CVE reports is lowering the CVE credibility and quality, so if everything is a "high" security issue, we can't prioritize now and these reports are not different from random issues in github. Do not listen to The Boy Who Cried Wolf

• Stable software is sable because it doesn't change too much. It's something that we are willing to loose trying to reach the impossible of 100% secure software?

The actual problem

There's a lot of money in AI tech right now, and everyone is trying to make the best gen AI tool or just pretend that their tool is the best.

In relation with the software analysis and writing, targeting the open source is the obvious strategy.

1. It's interesting to scrap every line of code, patch, pull request, issue and discussion around software to train your model, so AI scrappers are DDoSing open source projects infrastructure.

2. To promote their tools or themselves, Security Researches are using AI to target any project, reporting High security vulnerabilities, with the only goal of getting a CVE number to say how good they are.

This second point is affecting maintainers, because now you are receiving a lot of poor quality security reports, that are generated with AI and that looks plausible and are hard to read. You need to spend a lot of time to check if there's an actual wolf there or if it's again this boy that's tricking me.

This is burning the energy of maintainers, that instead of doing something productive are wasting their limited time talking with a Stocatic Parrot.

Do not let the AI Bros to use classic manipulation techniques on you!

A lot of open source projects are maintained by volunteers that do the work with passion and love. And even if it's the job that paid your bills, the maintainer can feel the pressure. When someone put a lot of love in something and work on it during years, it's part of his identity, so attacking the software is like attacking the person behind it.

This is nothing new, and a lot of people take advantage of this emotional link to manipulate the maintainer to do something that he do not want to do.

AI bros are using these techniques, do not let them to manipulate you and define your project agenda.

Here's a (not complete) list of known manipulation techniques that you can detect (and disarm!) in your daily community work:

• Flooding the queue. Just create so many new issues that the actual maintainers can't deal with it. You feel responsible for the project and feel bad because your TO-DO list is growing.

• This software is not secure (doesn't do what I want), I will use this other one instead that's better. The classic, "GNOME doesn't allow me to change this specific preference, I'll use KDE from now on".

• This software is low quality, it doesn't follow the (my random) quality standards. Direct attack to the maintainer self-esteem.

• Gaslighting software development. LLM are expert at this and people that uses it just copy the tactic. When the maintainer detects something weird and just tries to blame the other person for reporting nonsense and wasting all people time, it starts to invent new arguments and ignore the previous interaction.

So, take it easy, and remember the best clause in almost any software project, THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU:

Disclaimer of Warranty.

THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY
APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT
HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM “AS IS” WITHOUT
WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND
PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE
DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR
CORRECTION.

Is the software more insecure in 2026?

No. Anyone old enough could remember how insecure old software was. Do you remember windows 98? Do you remember the internet when everything was http (without that little s at the end), when people use ftp to logging into their server and modify the php code directly on production?

It's true that today we have more dependency on technology, but it's also true that everything is more secure, we have more and better cryptography, we have different levels of isolation, virtual environments, containers, virtual machines...

But we have the feeling that since AI can analyse all the software and look for vulnerabilities, we are doomed, because any stupid kid can hack my over engineered GNU/Linux machine!

First, that's not true, you need to know about security to get something useful from any AI tool. But even if it was true, what can you do about it? We need to be practical and find a balance between risk and usefulness, so do not overestimate the risk just because everyone is talking about it right now.

But even then, the security paranoia is not good for anyone. Software is inherently buggy, people write software and makes mistakes, so a possible vulnerability appears. In theory, these bugs are fixed when discovered, so it's always recommended to update to the latest version, because almost all known bugs will be fixed.

But it's also known that new versions comes with new functionality and code, and that means new "unknown" bugs or different behavior. That's a headache, so that's why the stable and Long Term Support are popular distributions, because "if it works, don't touch it".

Stable packages just get the fixes, not new features, but fixes are also code changes, so there's always a possibility to break something, even with a patch update.

The stable software has a lot of value, do not let the AI security paranoia destroy that, and convert everything in a rolling release with the latest and greatest (and possibly broken) software. Sometimes it's better to keep using something old, with known vulnerabilities that you can mitigate, than use the latest with unknown new vulnerabilities that you can't do anything about.

I will fight AI with AI

Please, do not do that. What I was trying to argue during this long post is not a technical problem. The current burnout problem in open source is a social problem, you can't fix it with a new layer of probabilistic tokens.

• Community reaction against AI. The current industry push for the usage of AI everywhere is affecting a lot of people, and as a reaction a lot of people are directly fighting back. Using gen AI just sends the message that you do not care enough to do it yourself, and destroy the trust on the project.

• It doesn't worth it. Even if the AI works (that it doesn't) it doesn't worth it. Writing code is easier than reviewing, you learn and grow with every new line of code that you write, delegating the fun part and personal growth part to an AI will make you work more miserable and you will be a junior forever.

• It doesn't create community. Think about it, it's hard to get someone involved in a software project, but who will want to read or improve the code produced by a gen AI? The only future collaborator will be another AI.

Take it easy

Just remember, you can always say no, there's no hurry, and there's no need to work on something that you don't want just because other people consider that important.

Free Source is something done by people, for people. The software is important, but the community around it is sometimes more important. We use Free source not because it's technically better (that it is), but because we trust who, how and why are writing it.

Remember why are you doing this, do not remove the Fun part, continue with the Just for Fun mood.