In our previous post from November 2025 we already told you to expect a temporal slow down in this blog activity. And here we are, more than four months later, to finally break that hiatus by announcing a new Agama version. But, why did it take so long to go from Agama 18 to Agama 19?

The key is that Agama 19 is not just another incremental change. This new version of Agama actually represents a new starting point in several aspects, from the architectural design to the organization of the web user interface, including some rewritten components and much more.

Architectural revamp​

We always wanted Agama to follow the schema displayed below, in which the core of the installer could be controlled through a consistent and simple programming interface (an API, in developers jargon). In that schema, the web-based user interface, the command-line tools and the unattended installation are built on top of that generic API.

But previous versions of Agama were full of quirks that didn't allow us to define an API that would match our quality standards as a solid foundation to build a simple but comprehensive installer. Agama 19 represents a quite significant architectural overhaul, needed to leave all those quirks behind and to define mechanisms that can be the cornerstone for any future development (see #2951 and #2998).

Of course, such a drastic change opens the door for potential bugs. Your testing, feedback and kind bug reports will help us to consolidate the new mechanisms in upcoming Agama versions.

Note that, despite the redesign of the programming interface, the JSON-based configuration format remains fully backwards compatible. Any JSON or Jsonnet profile that worked in previous versions of Agama will keep working in Agama 19 and beyond.

In a similar way, we also expect to declare the Agama API as stable soon. So anyone could then write their own tools to directly interact with the Agama core, without depending on the web user interface or the Agama command-line tools.

Reorganization of the web user interface​

Having a better API enabled us to adjust the web user interface to be closer to our original vision. We still have a long way to go in our road to a fully usable interface but the new navigation experience, based on a better overview page and a more useful confirmation dialog, sets the direction to follow (see #2988, #3009 and #3025).

Although most configuration sections remain similar to previous versions of Agama, we plan to revamp some of them. The process has already started for the sections to configure iSCSI, DASD, zFCP and network.

Regarding network, there are two important changes. On the one hand, now the user interface dynamicaly reacts to changes in the underlying system. For instance, when a new cable is plugged in or when a new WiFi adapter is connected (see #3285). On the other hand, now it is possible to define new ethernet connections. That is very relevant in installation scenarios with several network adapters that need to be configured in different ways. For example, where one network is used to access storage devices and another one is used to reach the installation repositories.

The web user interface also got a new option to download the current installer configuration in the JSON format used by the Agama command line tools and for unattended installation. That is the first step to turn the web interface into a useful learning and prototyping tool for more advanced scenarios, although this new functionality could benefit from several usability improvements. Stay tuned.

All the mentioned changes in the user interface will require several updates to the screenshots and guides available at the project home page. That will not happen overnight, so please bear with us during that gradual process. Of course, the page is (just like Agama itself) maintained in a public repository, so feel free to contribute to speed the process up.

Rewritten internal components​

As you may know, YaST still lives in the core of Agama. Many tasks like managing storage devices or configuring the boot loader are done under the hood by the corresponding YaST modules (ie. yast2-storage-ng or yast2-bootloader). But lately the usage of some particular YaST modules became more a limiting factor than an advantage.

That is the case for yast2-users and yast2-software. Both are very complex due to historical reasons and to their ability to both install a new system and administer an already installed one, something that is out of the scope of Agama.

Thus, we decided to use the architectural revamp as an opportunity to replace those YaST parts with simpler implementations that will allow us to evolve faster in the future. Agama 19 includes its own management of users and, even more important and ambitious, its own management of software including the registration of SUSE Linux Enterprise and associated products and extensions (see #2915, #2978 and #2982).

Installation modes​

But Agama 19 does not only bring restructuring and rewrites, it also comes with a bunch of new functionality, like the new ability to install some distributions in different so-called installation modes.

When installing the experimental pre-releases of SLES 16.1 or the corresponding version of SLES for SAP Applications, now it is possible to select between the Standard and the Immutable modes. See the following screenshot for details.

Agama support for installation modes is not limited to the use case illustrated above. Other distributions ("products" in Agama jargon) like openSUSE Leap or Tumbleweed may make use of modes in the future to redefine their software and storage configurations, offering different variants of a same operating system.

More configuration options​

Although modes are the most visible of the new features, we also added other new capabilities to Agama that are, at least for now, only accessible using the JSON configuration. That makes those new features available for users of the command-line interface and of unattended installations.

Probably, the most awaited of those new features is the ability to install into an existing LVM volume group (see #3210). When doing so, it is possible to create new logical volumes within the pre-existing volume group and it is also possible to reuse, delete or resize the existing logical volumes. Agama 19 even allows to add new physical volumes to an existing volume group as part of the process. Most of those capabilities will soon be added to the web user interface.

We also extended the configuration of the boot loader with a new setting updateNvram (see #3185) that, when disabled, prevents the boot loader updates of the persistent RAM (NVRAM). That is an expert feature that was requested by several users to handle broken firmwares or network setups.

Last but not least, now it is possible to specify several SSH public keys to authenticate the root user and also to use SSH keys as authentication mechanism for the non-root user created by Agama.

Many changes in the installation media​

As you can see, Agama 19 is quite a significant release. But there is room for many things in four months, even to work beyond Agama itself. During this time we also incorporated several changes to the live ISO that most of you use to execute Agama.

Those changes include several improvements in the boot menu (like better support for serial console or adapted timeouts), dropping the "Boot from Disk" option in most architectures, unifying the location of kernel and initramfs between the different architectures and a new boot argument live.net_config_tui=1 (see #2923) to trigger nmtui (an interactive network configuration tool) before Agama starts.

Back to regular speed​

It is clear that we consider Agama 19 to be a crucial milestone in the (still short) Agama history, but it is by no means the end of the path. Quite the opposite, we expect to recover our usual development pace and deliver new versions almost every month, as you can see in the updated roadmap.

But with great software rewrites comes great opportunity for new bugs, so we depend on your bug reports, your feedback and your contributions to keep improving. Do not hesitate to reach us at the Agama project at GitHub and the #yast channel at Libera.chat.

Have a lot of fun!

Last week, I wrote about my initial FreeBSD experiences on my new toy, an AI workstation from HP. FreeBSD runs lightning fast on it, but the desktop was somewhat problematic. Well, I made lots of improvements this week!

A bit of debugging

While there are still some rough edges, there have been tons of improvements since last week. I do not have plans to use FreeBSD on the desktop in the long term, but still, I just could not believe that the FreeBSD GUI is this problematic on this device. I did some experimentation though and it helped a lot… :-)

The initial problem I realized while browsing the output of dmesg was that desktop-installer enabled the wrong kernel modules repository for me. The line leading there was this:

KLD amdgpu.ko: depends on kernel - not available or version mismatch

The next problem occurred when I fixed this problem: there was a kernel panic on boot, when amdgpu.ko was loaded.

I did a fresh FreeBSD install and instead of using the latest packages, I decided to go with the quarterly packages. This way, the desktop installer configured the right kmod repo – however, loading amdgpu.ko still caused a kernel panic. Another experiment I made was using the ATI driver instead of AMD. The installer says that AMD is for modern cards, and ATI is for older ones. Well, as it turned out, even if the chip is barely half a year old, it counts as “old”… :-)

I am still not convinced that proper hardware-based acceleration works: both X.org logs and the GNOME “About” page showed software rendering. However, I had no problem with graphics performance: TuxRacer worked perfectly well… :-) And the GNOME desktop also worked nicely and as stable, including video playback. The only pain point when using GNOME was that screen locking still did not work.

KDE to the rescue

Even if it’s just software rendering, the graphics problem seems to be resolved. However, the screen locking problem still bothered me, as I’m an IT security guy with a healthy dose of paranoia (which means that I lock my screen even when I’m home alone… :-)).

So even if I haven’t tried KDE for the past 5+ years, I gave it a try now. After so many years on XFCE and GNOME, the interface looks a bit weird. However, everything I tried on it seems to work just fine, including screen locking.

This blog is part of a longer series about my adventures with my new machine and AI. You can reach me to discuss this blog on one of the contacts listed in the upper right corner. You can read the rest of the blogs under the toy tag.

Two years have passed since I last shared my Friday app icon sketches, but the sketching itself hasn't stopped.

For me, it's the best way to figure out the right metaphors before we move to final pixels. These sketches are just one part of the GNOME Design Team's wider effort to keep our icons consistent and meaningful—it is an endeavor that’s been going on for years.

If you design a GNOME app following the GNOME Design Guidelines, feel free to request an icon to be made for you. If you are serious and apply for inclusion in GNOME Circle, you are way more likely to get a designer's attention.

Previously

Members of the openSUSE community are tackling the complex undertaking of transitioning from YaST by developing a streamlined system management interface.

After some adjustments and community feedback in the openSUSE bar, members took an existing tool to roll out a launcher for openSUSE users that provides a web-based system administration interface, more accessible to users switching from the traditional YaST setup utility.

The cockpit-client launcher, addresses a barrier that has frustrated some users attempting to adopt Cockpit as a replacement for YaST. According to feedback on the openSUSE forums, the process has been neither simple nor straightforward, until now.

The launcher icon, which includes legacy YaST colors for the adjusted logo, is specific to openSUSE and was created in response to user concerns. After some testing and minor refinements, the package was pushed and is available on Tumbleweed and Leap as an Official package.

“Since Cockpit-client has both Flatpak and RPM launchers available, we need to give them different icons so users can actually tell them apart,” said Lubos Kocman. “The different colored icon instantly shows users which launcher they’re opening to eliminate any confusion.”

The Installation Process

The launcher reduces a multi-step process that is now a straight-forward workflow. Previously, users faced complications accessing Cockpit through localhost:9090, which the community identified as a pain point.

sudo zypper install cockpit-client-launcher

Users are also recommended to install patterns-cockpit to ensure all Cockpit modules are available:

sudo zypper install -t pattern cockpit

Finally, users launch the application from their desktop environment’s application menu and follow initial setup dialogs. The launcher automatically activates necessary systemd services and firewall settings.

To align with security requirements, user will be asked whether to enable cockpit.socket and for preferred firewalld configuration in case cockpit wasn’t previously enabled and running.

It was tested on both Tumbleweed and Leap 16 installations and testing confirms the package successfully integrates across different openSUSE flavors, versions and installation scenarios.

A demonstration video created by Low Tech Linux showcases the installation and setup process on both Tumbleweed and Leap 16.

The Cockpit web interface provides graphical access to system administration functions that are traditionally handled through command-line tools or YaST, which include package management, user administration, service control, and more.

I often hear, even at security conferences that “no central log collection here” or “we have something due to compliance”. Central logging is more than just compliance. It makes logs easier to use, available and secure, thus making your life easier in operations, security, development, but also in marketing, sales, and so on.

What are logs and what is central log collection?

Most operating systems and applications keep track of what they are doing. They write log messages. A syslog message might look similar:

Mar 16 13:13:49 cent sshd[543817]: Accepted publickey for toor from 192.168.97.14 port 58246 ssh2: RSA SHA256:GeGHdsl1IZrnTniKUxxxX4NpP8Q

Applications might store their logs separately and have their own log format, like this Apache access log:

192.168.0.164 - - [16/Mar/2026:13:17:01 +0100] "HEAD /other/syslog-ng-insider-2026-03-4110-release-opensearch-elasticsearch/ HTTP/1.1" 200 3764 "-" "SkytabBot/1.0 (URL Resolution)"

Central log collection simply means that log messages are collected to a central location instead or in addition to saving them locally.

In this blog we take a look at what ease of use, availability, and security of central log collection mean for you.

Ease of use

If you have a single computer in your organization, finding a log message about an event on that computer takes some time. Once you have 2 computers, you have to check 2 computers to find that event. It might take twice as much time, but it is still easier than implementing central log collection. Not to mention, which one is the central computer. :-)

Once you have a network of 10 computers, logging in to each of them to find a log message about an event becomes a huge overhead. It is still doable, but implementing central log collection is a lot easier already in the short term, than looking at the logs on the machines where they were created.

On a network of 100 computers, it is practically impossible to find relevant logs by security or operations, unless logs are collected centrally.

Availability

Collecting logs centrally means that log messages are available even when the sending machine is down. If you want to know what happened, you do not have to get the machine up and running again, but you can check the logs at the central location. If you see signs of a hardware failure, you can go with a spare part immediately, reducing the time and effort needed to repair the machines.

Security

When a computer is compromised, log messages are often altered or deleted completely. However, this tactic only works with logs stored locally. Collecting logs at a central location allows you to use the unmodified logs and to figure out how the compromise happened.

What is next?

It is time to introduce central logging to your organization if you have not yet done it yet. Of course I am a bit biased, but syslog-ng is the perfect tool to do so. You can get started by reading / watching the syslog-ng tutorial on https://peter.czanik.hu/posts/syslog-ng-tutorial-toc/.

Originally published at https://www.syslog-ng.com/community/b/blog/posts/central-log-collection—more-than-just-compliance

GNOME 50 just got released! To celebrate, I thought it’d be fun to look into the background (ding) of the newest additions to the collection.

While the general aesthetic remains consistent, you might be surprised to see the default shifting from the long-standing triangular theme to hexagons.

Well, maybe not that surprised if you’ve been following the gnome-backgrounds repo closely during the development cycle. We saw a rounded hexagon design surface back in 2024, but it was pulled after being deemed a bit too "flat" despite various lighting and color iterations. We’ve actually seen other hex designs pop up in 2020 and 2022, but they never quite got the ultimate spot as the default. Until now.

Beyond the geometry shift of the default, the Symbolics wallpaper has also received its latest makeover. Truth be told, it hasn’t historically been a fan favorite. I rarely see it in the wild in "show off your desktop" threads. Let's see if this new incarnation does any better.

Similarly, the glass chip wallpaper has undergone a bit of a makeover as well. I'll also mention a… let's say less original design that caters to the dark theme folks out there. While every wallpaper in GNOME features a light and dark variant, Tubes comes with a dark and darker variant. I hope to see more of those "where did you get that wallpaper?" on reddit in 2026.

In the past few weeks, I installed five different operating systems on my latest toy: an AI workstation from HP. I love playing with OSes, but my main goal with the new machine is to learn various aspects of AI. I took my first steps in this adventure on Windows.

Of course, you might ask: why on Windows? Well, it’s easy: because it’s easy… :-) There is nothing to install or configure there, as Windows has multiple built-in apps that support AI and can utilize the NPU (hardware-accelerated AI) support of the AMD Ryzen 395 chip. The Windows Task Manager application already has a graph for NPU utilization and I found good use of it already: the Task Manager was open on the NPU tab while I conducted my experiments, allowing me to verify that it was indeed in use, as I ran a couple of generative AI tasks.

I find it somewhat surprising, but Paint now also comes with integrated AI support. Of course, you must pay for image generation but generating simple graphics (or “stickers”, as they are called in Paint) is free. If the prompt field is empty, its prompt text suggests “a cat wearing sunglasses”, so that’s what I generated. It has no practical use for me, but looks fun regardless… :-) You can see an example in the first figure.

It’s only slightly crazier that the simplest Windows app, Notepad, now also has AI features. I asked Notepad to write me a three-paragraph-long blog about writing a blog with AI in a boring, formal style. It completed the task successfully: the result is pretty boring and full of bullshit. Here it is:

The integration of artificial intelligence into the realm of content creation, particularly in the sphere of blog writing, presents a multitude of advantages that merit serious consideration. Firstly, AI-driven tools offer an unprecedented level of efficiency, allowing content creators to produce substantial volumes of text without the need for exhaustive manual input. This technological boon is particularly beneficial for those with time constraints or heavy workloads, as it liberates them from the mundane task of typing and editing.

Moreover, the precision and consistency of AI in language generation cannot be understated. By leveraging advanced algorithms, AI systems can maintain a uniform tone and style throughout a piece, which is a common challenge for human writers. This consistency ensures that the content is cohesive and that the voice of the piece remains unaltered, thereby enhancing the overall reading experience.

Lastly, the ability of AI to learn from vast datasets and adapt to various writing styles is a significant asset. It empowers writers to explore new topics and styles with confidence, knowing that the AI can provide a solid foundation upon which to build. This adaptability not only streamlines the writing process but also encourages creativity and innovation in content creation.

I also wanted to try a controversial Windows feature: Recall. Well, it does not work. When I started it, I got a nice error message stating that it needs Secure Boot. Linux requires it to be turned off, so I cannot test it now. But I must admit that I do not mind that… :-)

If everything goes well, I’ll make my first steps next week to enable hardware-accelerated AI under Linux.

This blog is part of a longer series about my adventures with my new machine and AI. You can reach me to discuss this blog on one of the contacts listed in the upper right corner. You can read the rest of the blogs under the toy tag.