Fedora 43 has been released!
🎉 So let’s see what is included in this new release for the Fedora Atomic Desktops variants
(Silverblue, Kinoite, Sway Atomic, Budgie Atomic and COSMIC Atomic).
Alongside the rest of Fedora, we are now compressing our initrds with the Zstandard (zstd) algorithm.
This should make the initrd a bit smaller and the boot a bit faster.
Alongside the rest of Fedora, systems will install with a 2GB /boot partition.
This should make things easier with the growing initrd sizes (mostly due to firmwares).
Existing systems will require a backup and re-install to benefit from this change.
We are adding the wireguard-tools to all variants.
Users can still use the graphical interface in their desktop environment to configure WireGuard connections.
However, it should now be easier to debug issues using the wg tool.
This change was decided too late to be included in the installation ISO but it will come via an update.
We temporarily removed the Third Party page shown during the first boot as it
was causing issues. Users will be asked if they want to enable Third Party
repositories when then open GNOME Software.
It will be re-enabled once we figure out where the bug is.
Updates are now automatically applied on a weekly basis, for Flatpaks and the
system. You can configure the frequency or disable auto-updates in the system
settings.
As always, I heavily recommend checking them out, especially if you feel like some things
are missing from the Fedora Atomic Desktops and you depend on them (NVIDIA drivers, extra
media codec, out of tree kernel drivers, etc.).
We have established a roadmap
(atomic-desktops-sig#26)
and we need your help to make this a smooth transition for all of our existing
users.
New home for the Fedora sysexts
We have moved the systemd system extensions (sysexts) to a new GitHub organization.
The sysexts are now split between those built exclusively from Fedora packages and those built from various community sources.
Make sure to update your systemd-sysupdate configs to point to the new URLs.
Your toolbox defines your craft. The freedom to choose, evolve, and master your tools is not just a productivity choice—it’s a long-term strategic decision that will put you in control of your craft, for life. Yet another reason to choose open source tools.
Level up your tabletop RPG experience with Dice Roller 3D! Whether you’re deep into D&D, Pathfinder, or your favorite homebrew system, DicelyVerse gives you all the power of physical dice and more—right in your pocket.
3D Dice Rolling Engine Feel the thrill of real dice physics with stunning 3D visuals. Roll multiple dice with satisfying animations.
Roll Dice with Commands Type d20+5 or any custom command to get your results instantly. Supports advanced syntax for complex rolls! The command engine is DiceParser. See the documentation here.
Reroll with Ease Need a second chance? Reroll instantly without retyping your command or resetting your dice.
Macros – One Tap Commands Save your favorite or frequently used dice rolls as macros for quick access. Perfect for initiative rolls, attack rolls, and spell damage!
✍️ Aliases – Shortcuts for Long Commands Tired of long roll strings? Set up aliases to keep your gameplay fast and your input clean.
Character Sheet Integration Store your character’s stats, modifiers, and abilities directly in the app. Pull values into rolls on the fly.
Multiple Profiles Play multiple campaigns or characters? No problem. Create separate profiles to keep everything organized.
Dark Mode Change the UI to dark mode or light mode on the fly (no need to restart).
Translation DicelyVerse has translations available now: English, German, French, Italian, Spanish and Portuguese.
Watch it in Action!
Check out our YouTube demo video showcasing the app’s features and real-time gameplay experience:
Download Now on Android!
Simplify your tabletop experience. Make every roll count—with flair.
Early this year I got asked by Martin Wolf from Golem.de if I want to appear on their German podcast in respect to my work on Kate and the experience on maintaining it for 2 decades.
The podcast is in German like the text on the page.
There is a full transcript of the podcast on the site, I guess your preferred browser can translate it, if you are interested :)
KDE e.V. held its annual general meeting online. During the AGM, elections for two vacancies on the board of directors were held. Members Carl Schwan and David Redondo were elected and take a seat on the board.
We would like to thank Nate Graham and Adriaan de Groot for serving on the board during their terms.
New features in Krita, Calligra Plan ported to Qt6 and a simplified Itinerary UI
Welcome to a new issue of "This Week in KDE Apps"! Every week (or so) we cover as much as possible of what's happening in the world of KDE apps.
Getting back to all that's new in the KDE App scene, let's dig in!
Travel Applications
Last weekend, some of the developers behind Itinerary and KTrip were in Vienna for the first edition of the Open Transport Community Conference, where there were many discussions relevant to Itinerary and Transitous.
Jonah Brüchert simplified the journey selection by moving the mode of transport selection to a separate page (25.12.0 - link) and by asking for a trip group after selecting a journey (25.12.0 - link).
Jonah also brought back the top-level import action in the trip group list page (25.12.0 - link)
Volker Krause added the altitude information to the live status map when the information is available (25.12.0 - link).
David Pilarčík added 10 new extractors and improved some existing ones (25.12.0 - link)
Joshua Goins made the United extractor more resilient when parsing multi-passenger tickets (25.12.0 - link)
PIM Applications
Volker Krause and Albert Astals Cid fixed some safety issues found by the newly added OSS-Fuzz tests in KMime (25.12.0 - link 1 and link 2).
Carsten Hartenfels added a Marker blend mode to Krita, which works like Alpha Darken but properly adheres to channel flags (so it e.g. obeys alpha lock and inherit alpha) and interpolates colors without artifacts. When you use it on a brush in build-up mode, it will only increase opacity up to your stroke's intended opacity but not compound what's on the layer, while the colors get interpolated. It works like Paint Tool SAI's marker tool, hence the name. (link)
Wolthera van Hövell improved the support for loading and saving PSD files and now text, shapes, and guides are supported (link).
Pavel Shlop added the possibility to edit icons for toolbar actions in the toolbar editor (link).
Laurent Montel released a new version of KAIChat. This version adds tools support, make it possible to download Ollama on Windows and macOS and add some configuration options to some plugins.
For a complete overview of what's going on, visit KDE's Planet, where you can find all KDE news unfiltered directly from our contributors.
Get Involved
The KDE organization has become important in the world, and your time and
contributions have helped us get there. As we grow, we're going to need
your support for KDE to become sustainable.
You can help KDE by becoming an active community member and getting involved.
Each contributor makes a huge difference in KDE — you are not a number or a cog
in a machine! You don’t have to be a programmer either. There are many things
you can do: you can help hunt and confirm bugs, even maybe solve them;
contribute designs for wallpapers, web pages, icons and app interfaces;
translate messages and menu items into your own language; promote KDE in your
local community; and a ton more things.
You can also help us by donating. Any monetary
contribution, however small, will help us cover operational costs, salaries,
travel expenses for contributors and in general just keep KDE bringing Free
Software to the world.
To get your application mentioned here, please ping us in invent or in Matrix.
Today I’d like to talk about package management a bit. The lack of a user-facing package manager is a big difference between KDE Linux and most other Linux distros (even immutable/atomic ones), so it bears some discussion!
Let me start by saying:
I absolutely love package management.
No, really!
Before Linux, I came from the Mac world which lacks real package management. To install apps back then, you would fail to successfully drag them to the /Applications folder. Software requiring more integration was installed using Windows-style wizards with no dependency management and no provision for uninstalling them later. (!!!!!)
Moving to Linux was a revelation.
You mean I can just do sudo apt install thingy to get my thingy instantly? And it gets upgraded with the rest of the system automatically? And I can easily remove it if I don’t want it anymore?
It’s just 1000% better. We all know this. It’s a crowning jewel of our ecosystem.
However! There’s package management to get add-on software… and then there’s package management for assembling the base OS on your own computer.
The former is incredibly convenient and amazing. The latter is a Tool Of Power best suited for use only by OS builders and true experts.
I feel it’s a problem that historically we’ve used this amazing tool for both of those use cases, because building the base system from packages on users’ computers suffers from a number of nearly unsolvable challenges:
It deteriorates and explodes
As you install, remove, and update packages on your system, you inevitably encounter problems over time:
Conflicts and incompatibilities with add-on repos
Heisenbugs from orphaned packages still present on the system
The ability to uninstall important functionality without realizing it, breaking the system
Updates that break bootability due to some untested condition present only on your system
True experts and OS engineers can usually resolve these issues as they crop up.
What about everyone else? There’s usually no recovery method exposed in a normal-person-friendly manner, or at all. You’re just screwed unless you have a second computer or a phone set up to be able to talk to the distro developers on Matrix or IRC, and one can walk you through fixing it live.
It’s not a targetable platform
No installation of a package-based operating system can be guaranteed to have the same set of system software and libraries as any other one.
This means if you’re a developer, your software can’t make safe assumptions, and it’s running in an untested environment pretty much all of the time. You can contend with this complexity via a forest of conditional “if this thing is present, enable that behavior” logic, but versions of dependent libraries you didn’t test with can still break your app, and users will report bugs that you can’t reproduce.
It’s a barrier to raising quality levels
Package-based OSs allow for and encourage self-service to fix problems. Install this package. Edit that config file. Replace the version of some package with the one from another repo.
This is great for current you in the short term. But it’s less great for future you, after you’ve forgotten about your local fixes and encounter the same bugs the next time you re-install on a new computer, or after the local fixes have become unnecessary and are now causing issues that nobody will be able to debug.
It’s also less great for the whole project, its ecosystem, and others who might encounter the same issues but lack your level of technical skill or available time for troubleshooting.
But what about the really good distros?
I do think these challenges are manageable, even if they can’t be fully eliminated. My best experiences with a package-based KDE-focused distro have been with Fedora KDE, where they do a great job of it:
They prevent removing critical packages that would break the system.
They have a huge main repo with almost everything you could want, and RPMFusion (the only add-on repo you really need), has a close relationship with the primary packagers so conflicts are rare.
They work hard on shipping a good product out of the box, rather than making you fix bugs yourself, and they regularly make bug-fixy tweaks to improve the out-of-the-box experience.
In 4 years of usage, I’ve never had a system update break bootability.
And the result is fantastic. I 100% recommend Fedora KDE to anyone who wants a good experience with a GUI-focused package-based operating system. It’s hard to go wrong with it.
And obviously those of us building KDE Linux also think Arch Linux is great, since we use their packages for building our base system! It’s is an amazing tool for OS builders and experts wanting to create the personal OS of their dreams.
Others that I have less experience with are excellent, too. But still, none of them can fundamentally solve the problems I outlined earlier. It’s not for lack of labor or expertise; these simply aren’t easily solvable problems with a mutable system-level package-based design.
So what’s the solution?
Well the world is messy and everything has drawbacks. So there’s no solution that’s better in every way, and worse in none. But the approach we’ve chosen in KDE Linux does solve the above problems:
Stability
In KDE Linux, we build the base system out of Arch packages, but freeze the contents and take responsibility for the result being functional; we don’t offload responsibility onto the user.
Updating the system swaps out the old OS image for the new one; it’s both fast and safe. And you can keep around the old OS image (three of them, in fact) and easily roll back if you have a problem. It doesn’t become “quirky” and degrade over time.
It isn’t 100% perfect, of course. Users can still mis-configure their software and manually install user-level libraries that conflict with system-provided libraries. But it’ll be more obvious that you’re about to shoot yourself in the foot.
Being a platform
Specifically, Flatpak is a platform.
With Flatpak, developers target a specific version of a discrete SDK and its corresponding runtime. This runtime will be the same on every user’s computer. Now developers can make safe assumptions and reproduce bugs — at least, bugs not caused by hardware problems or users’ configurations differing from their own.
And developers who target this platform make their apps available not only on KDE Linux, but also most other Linux-based operating systems, too.
There are problems with Flatpak, of course; I’m not gonna claim it’s perfect. It’s opinionated, restrictive, can’t be used for deeper parts of the OS the way Snap can, and multiple installed versions of each runtime can end up consuming a lot of space. But it solves the platform problem, and traditional system-level package management just can’t.
Quality
Every KDE Linux user is going to to have image and video thumbnails, all the KDE wallpapers, the Desktop Cube effect, KDE Connect, a working installation of Plasma Vault, well-tuned power management, and support for as much exotic hardware as we could stuff in. None of this comes in optional add-on packages you can find yourself missing. You’ll just automatically have it.
If you find that something significant is missing or broken, you’ll need to tell the developers, and then they can fix it for everyone. If you’re an expert who likes fixing problems, you can still make those fixes; you’ll just be doing it for everyone in the world and not just yourself! The project and its entire userbase will benefit.
But what about the glaring, obvious drawbacks?!
The most obvious drawback of not having a package manager, is, well, not having a package manager. I’m pretty sure I don’t need to explain the lost benefits to anyone reading this. We all know how amazingly flexible and powerful real package management is.
Thing is, its absence isn’t a problem for regular people because they weren’t using package managers to install gimp and rust and waydroid and whatever anyway. The Discover graphical app store is a waaaaaaay more user-friendly way to get GUI apps from Flathub or anywhere else. It isn’t actually a problem.
Pictured: a usable way for normal people to find and install apps
But the lack of a package manager does become a problem for power users and software developers. Let me group the usages into a few broad categories and explain how KDE Linux handles them:
GUI apps not on Flathub
This category shrinks all the time as Flathub cements its position as the de facto repository of GUI apps on Linux.
Still, for the remaining omissions, there are other options such as Snap, finding an AppImage of the app, or installing it using the package manager of another distro using a container. But these don’t offer the level of integration we’re aiming for in KDE Linux, so for that reason, we focus on boosting Flathub as its primary supported repository of GUI apps.
Command-line productivity and software development tools
In KDE Linux, we already pre-install most of the common and modern ones. This includes:
Performance monitoring/debugging:drm-info, htop, iotop, lsof, lspci, lsusb, nvtop, powertop, and loads more
Productivity/automation:kdialog, rg, tree, vim, wget, wl-clipboard, ydotool, and many more
Network management:hostnamectl, ip, iw, resolvectl, tracepath, and more
Version control:git and svn
Compilers etc:ccache, gammaray, gcc, gdb, llvm, and lots of ancillary tools
For anything you need that isn’t pre-installed, there are multiple options including containers and the add-on Homebrew or Nix package managers. We even include a custom “command not found” handler that can direct you to available options:
Drivers and support packages for hardware
This is a tricky one, as a lot of these include kernel drivers or need to be installed systemwide. So we pre-install as many as we possibly can: support for printers, game controllers, filesystems, fingerprint readers, drawing tablets, smart card readers, braille displays, Yubikeys, specialized audio/video processor boxes; lots of stuff. However there are cases where this isn’t possible, which is a legitimate problem with KDE Linux right now.
Input methods
KDE Linux aspires to pre-install state-of-the-art input methods so you don’t have to install and configure everything yourself. However we haven’t reached this goal yet. We’re building a virtual keyboard with built-in support for CJKV languages, but it’s still a work in progress.
Languages
KDE Linux pre-installs support for all available languages; any that are missing are the result of bugs we should fix!
Support packages for VM guest OS integration
KDE Linux pre-installs all the ones that are available on Arch Linux. Similarly, anything missing is something for us to fix.
Software development languages and toolkits
Qt is obviously included, and so is GTK. There’s also Python, JavaScript, and Rust.
But we can’t pre-install everything here, as software dev stuff tends to be huge. If a large high-level toolkit/language/build dependency/etc. that you need isn’t pre-installed, the best way to use it anyway is by installing it or its development environment a container. Distrobox and Toolbox are fully supported.
And that should about cover it, I think!
Basically, we’ve tried to eliminate the need for traditional package management as much as we can, while preserving your ability to use a package management tool if you’re an expert or a developer who benefits from one. It should just be a userspace package manager (via a container, Homebrew, or Nix — your choice) so it can’t impact the stability of the system so strongly, and so any problems can be easily undone.
And to be clear, if you prefer a traditional OS that’s 100% mutable using a system-level package manager, that’s completely fine. There’s no shortage of Linux-based operating systems using this model out there, and KDE Linux is an admittedly opinionated divergence from it.
On the other hand, if all of this seems really exciting, please feel free to install KDE Linux somewhere and help us build it! At the time of writing, we’re a little over 40% of the way through the Beta milestone, at which point we’ll declare it suitable for general use by current Linux users. Progress is steady but slow; with more help, it can become a polished product much faster!
We’re excited to share a major milestone in the development of the Ocean Design System for the Plasma Desktop! The project is moving away from Figma and fully migrating to the open-source platform Penpot.
This shift was made possible by significant improvements in Penpot, which now supports critical features needed for a robust design system.
The Move to Penpot: Open Source and Component Cleanup
The team begun a clean-up and migration of all design assets into Penpot. We’ve created the Ocean Design Systems Foundations Library, which is the central Penpot file housing all our graphical assets. It contains all the foundational elements of the design system, but now features shared assets.
Progress Highlights in Penpot
Foundations and Shared Component
These are the second level, or more advanced design elements used in ui. Buttons, sliders, progress bars, etc. Using these elements, users are able to actually compose and deliver small UI elements for developers to use.
New Feature: Variants
A massive win for our design process is Penpot’s new support for variants. Variants allow us to group components with different states (e.g., a badge with an icon or an avatar). This makes it incredibly easy to design on the fly—you can drop a component and quickly switch its size, state, and type without having to manually redesign.
Exciting News from Penpot Fest 2025
The recent Penpot Fest brought some fantastic announcements that will further accelerate our work:
New Rendering Engine: Penpot is developing a new rendering engine based on Skia and Web Assembly (like what Chrome uses) to dramatically improve performance and speed, especially for math-oriented design work. We’ve already signed up for the beta!
Layer Blur and Tokens: They are bringing layer blur into the system and allowing for the creation of more tokens for things like typography and complex multi-layered shadows.
Better Shape Control: The new engine also promises better shape control, which is great news as we explore creating our Ocean icons directly in Penpot.
Sharing the Library
We’ve now published the first iterations of our Ocean Design Foundations library. To enable worldwide collaboration, we are periodically exporting the Penpot file and uploading it to our GitLab repository (currently hosted in a personal repo, but moving to a Plasma-backed one soon). This means anyone can clone the repository and work with the same assets we do.
@siosm:matrix.org
toscalix
obiwan_kennedy
Core Features
3D Dice Rolling Engine
Roll Dice with Commands
Reroll with Ease
Macros – One Tap Commands
Character Sheet Integration
Multiple Profiles
Dark Mode
Translation
Watch it in Action!
Check out our YouTube demo video showcasing the app’s features and real-time gameplay experience:
Download Now on Android!
best suited for use only by OS builders and true experts.
We all know how amazingly flexible and powerful real package management is.
