Sigo con la octava entrada de este año de la iniciativa #viernesdeescritorio. Bienvenidos a mi escritorio Plasma de agosto 2025, realizado sobre ordenador portátil, un Slimbook Pro, con el que llegamos a las 63 entregas compartiendo «Mi escritorio» de forma mensual.

Mi escritorio Plasma de agosto 2025 #viernesdeescritorio

Esta va a ser la sexagésimatercera (63 para los que nos cuesta leer esto) vez que muestro mi escritorio Plasma 6 en público, lo cual es número nada desdeñable de entradas que sigue creciendo de forma constante.

De nuevo lo realizo de nuevo sobre mi Slimbook Pro, el cual tiene instalado un KDE Neon con Plasma 6.4.4, sobre una versión de KDE Frameworks 6.17.0 y una versión de Qt 6.9.1. El servidor gráfico es Wayland y el Kernel es 6.14.0-27-generic (64 bits).

En este equipo sigo utilizando un aspecto bastante muy oscuro, con el tema global básico Brisa Oscuro e iconos estándar (Brisa Oscuro). La barra de tareas a la izquierda se ha quedado para siempre. En ella he puesto un plasmoide llamado Weather Widget Plus, bajo del reloj de la barra de tareas, que me indica la temperatura del exterior de mi casa y me hace la previsión para unos días. Por último, antes del lanzador de aplicaciones, he puesto un pequeño bloc de notas para acceder de forma rápida a esas cosas que pasan por mi mente y necesito apuntar para recordar después.

Para el fondo tengo mantengo la novedad del mes pasado: he puesto un widget llamado Random AI Wallpaper que me pone un fondo aleatorio, generados por alguien gracias a la IA y de calidad (la IA puede genera fondos pero que sean de calidad es decisión de una persona, y aquí radica el buen uso de esta herramienta), y que se guardan en un Gitlab. Ya publiqué la entrada de este magnífico complemento.

Y para finalizar, he cambiado mi reloj de escritorio por otro creado por una desarrollador de Plasma que me indica la hora aproximada, que queda estupendo en temas oscuros. Una maravilla y, además, es exclusivo.

El resultado de mi escritorio Plasma de agosto de 2025 es un entorno de trabajo oscuro y, como siempre, funcional que podéis ver en la imagen inferior (pinchad sobre ella para verlo un poco más grande).

La entrada Mi escritorio Plasma de agosto 2025 #viernesdeescritorio se publicó primero en KDE Blog.

After I took a longer break from KDE development, I’ve been back in action for a few months now. It’s really nice to be back among friends, hacking on what I like most: Plasma. My focus has been on Plasma Mobile with some work naturally bleeding over into other areas.

Plasma on more Devices

I’d like to share some bits and pieces that I’ve worked on in the past months. Most of my efforts have revolved around making Plasma Mobile suitable for a wider range of devices and use-cases. The purpose of this work is that I want to make Plasma Mobile a more viable base for all kinds of products, not just mobile phones. We have a really mature software stack and great tools and applications which make it relatively easy for companies to create amazing products without having to hire large teams and many years to get the product ready for their market. This is I think a very interesting and worthwhile niche for Plasma to get into and I’m sure that Valve is not the only company that understands this.

Convergence Improvements

Convergence, or rather being able to support and switch between formfactors and usage patterns has always been a pet-peeve of mine and still is.
One area was improving using the available screen real estate use landscape displays (Plasma Mobile has quite naturally been rather “portrait-focused”, though a few smaller patches go a long way.)

I also improve usability with different pixel densities in the mobile shell by making the size of the top panel configurable. Also, when plugging in a second monitor, Plasma Mobile now switches from “all apps are maximized” to normal window management. (I’m currently working on KWin supporting more fine-grained window management. Currently, we just maximize all windows which has problems especially with modal dialogs.)

One changeset I worked on earlier this year makes it possible to ship multiple user interfaces for settings modules (“kcms”). An example is the “remote desktop” kcm which now shows a mobile-focused UI in Plasma Mobile. What happens here is that we load a main_phone.qml file in Plasma Mobile (where “phone” is picked from a list of form factors set in the environment of the session, so basically the “main” QML file gets picked based on the device. This mechanism allows us to share components quite easily, reducing the delta between different device UIs.

This actually builds on top of work that I’ve done ten years ago which added support for form factors to our plugin metadata system.
I’ve also made the “Display & Monitor” kcm usable on mobile, this is a pretty important thing to have working when you want to be able to plug in an external monitor into your device. I have a mobile version of the keyboard KCM in the pipeline, too, but this will need a bit more work before it’s ready for prime-time.

More Features

There’s a new page in the mobile Wi-fi settings module, showing connection details and tranfer speeds. The code for this was amazingly simple since I could lift most of the functionality from the desktop panel widget. A shared code-base across devices really speeds up development.

Adding useful features here and there, such as having the list of available bluetooth devices now filtered by default and only showing devices which actually make sense to pair (with an option to “Show all devices” in good Plasma manner). This feature isn’t mobile-specific, so desktop and laptop users will benefit.

Welcome to Okular Mobile

Not all my work goes into infrastructural and “shell” bits. The mobile okular version has now kind of caught up with the desktop version since it got a nice welcome screen when opened. This allows the user to easily open a document either from the “Documents” directory on disk (this is actually configurable) or one of the recent files viewed.

Going to Akademy ’25

After having missed our yearly world conference for a number of years, this year I will be at Akademy again. I’m really looking forward to seeing everybody in person again!

See you in Berlin!

A ver si entre este mes de agosto y septiembre me pongo al día con este podcast (ya podéis intuir que son muchos los episodios de retraso que llevo). De momento ya llevo dos seguidos con éste, así que os presento el episodio 8 de Accesibilidad con Tecnologías libres: Magazine veraniego de noticias sobre accesibilidad. Una oportunidad más para conocer las opciones que existen para acercar la tecnología a todo el mundo.

Episodio 8 de Accesibilidad con Tecnologías libres: Magazine veraniego de noticias sobre accesibilidad

Hace más de dos años que presenté este podcast y he dejado pasar demasiado tiempo para seguir promocionándolo. Areglé este error hace un tiempo pero perdía la inercia. Así que vuelvo con nuevos bríos para seguir promocionándolo como se merece.

Me complace presentar el séptimo episodio de Accesibilidad con Tecnologías libres que tiene el siguiente resumen:

• Rompiendo barreras, con Eva Marco. Nos describe los «Principios de diseño inclusivo».
• 00:08:55 Odisea en el ciberespacio, con David Marzal.
  • Mozilla está experimentando con la generación local del ALT text, por ahora (FF130) en imagenes de PDF, pero con intención de generalizarlo en el navegador.
  • Y siguiendo con Mozilla, ya implementado, tenemos la funcionalidad de captura de pantalla ahora se puede usar en más sitios y en materia de accesibilidad tiene atajos de teclado y un soporte para temas o modo de Alto Contraste.
  • Se esta desarrollando una nueva arquitectura de accesibilidad llamada Newton para mejorar la actual AT-SPI, ya que será nativamente compatible con Wayland
  • Fedora tiene un grupo de accesibilidad, aquí os dejo un vídeo presentación y su sala de Matrix
  • Podcasts en ingles dirigidos a invidentes: reviews de hardware y juegos y otro sobre tecnología, viajes y auto-cuidados
  • Articulo con 4 vídeos sobre como testear la accesibilidad en tus proyectos
  • Aplicación para revisar la accesibilidad
• 00:17:29 Accesibilidad web, con Pablo Arias. Nos habla sobre de los formularios web.
• 00:33:42 Diseño para todos, con Jonathan Chacón. Nos comenta sobre las smartcities y las ayudas a la orientación en la ciudades.

Transcripción disponibles en steno.fm por si vuestra Podcatcher no los implementa, como estas.

Créditos de la música:

• «Evening» de Kevin MacLeod (incompetech.com) – Licensed under CC: By Attribution 4.0

Este podcast tiene licencia Reconocimiento-CompartirIgual 4.0 Internacional (CC BY-SA 4.0).

Más información: Sexto episodio de Accesibilidad con Tecnologías Libres

Podcast Accesibilidad con Tecnologías libres

Jorge Lama, Víctor , David Marzal, Thais Pusada, Pablo Arias, Jonathan Chacon y Markolino son el equipo reunido para crear el podcast Accesibilidad con Tecnologías libres, un podcast para hablar sobre temas de accesibilidad y tecnologías libres.

En palabras de sus creadores:

En informática, la accesibilidad incluye diferentes ayudas como pueden ser las tipografías de alto contraste o gran tamaño, magnificadores de pantalla, lectores y revisores de pantalla, programas de reconocimiento de voz, teclados adaptados y otros dispositivos apuntadores o de entrada de información.

Además, las inteligencias artificiales están empezando a ser un gran aliado para mejorar la accesibilidad en muchos aspectos. Existen podcasts y canales de vídeo que hablan de la accesibilidad centrándose en entornos Windows o de Apple porque son los más conocidos por el público generalista. Pero en este podcast queremos dar a conocer otros aspectos de la accesibilidad y su relación con otras tecnologías menos conocidas.

Tecnologías que consideramos libres y que nos parecen mejores para la sociedad, en muchos casos…

Por supuesto, os invito a visitar la página de Archive.org donde están recogidos el resto de programas y donde nos indican también aquellos que estań subtitulados, aunque creo que al final lo estarán todos:

Créditos de la música:

La música usada ha sido «Evening» de Kevin MacLeod (incompetech.com)
Licensed under Creative Commons: By Attribution 4.0 License
http://creativecommons.org/licenses/by/4.0/

Personalmente, me parece un podcast muy interesante que aborda un tema recurrente en el mundo del Software Libre pero que todavía está lejos de solucionarse. Los diferentes proyectos de escritorio de GNU/Linux implementan cosas pero en muchas ocasiones no están coordinadas realmente con las personas que las necesitan. Esperemos que en los próximos años este aspecto se vaya mejorando y, si ocurre, creo que este podcast tendrá parte de culpa, en el buen sentido de la palabra.

Más información: Accesibilidad con Tecnologías Libres

La entrada Episodio 8 de Accesibilidad con Tecnologías libres: Magazine veraniego de noticias sobre accesibilidad se publicó primero en KDE Blog.

Usuários que compraram placas da nova geração NVIDIA, como a GeForce RTX 5070 Ti, podem se deparar com o seguinte erro ao tentar rodar projetos com PyTorch e CUDA, como o Fooocus ou outras interfaces com IA generativa:

RuntimeError: CUDA error: no kernel image is available for execution on the device

Além disso, pode surgir o aviso:

UserWarning: NVIDIA GeForce RTX 5070 Ti with CUDA capability sm_120 is not compatible with the current PyTorch installation.

O erro indica que o PyTorch instalado não possui suporte à arquitetura SM da sua GPU. No caso da RTX 5070 Ti, trata-se de uma arquitetura nova (possivelmente Blackwell ou Lovelace Refresh), e o PyTorch está compilado apenas para arquiteturas anteriores (como SM_50 a SM_90).

Solução passo a passo

A solução é instalar uma versão nightly do PyTorch que já foi compilada com suporte às arquiteturas mais recentes e ao CUDA 12.8, exigido por GPUs mais novas.

1. Remova o PyTorch atual

pip uninstall torch torchvision torchaudio -y

2. Limpe o cache do pip (opcional, mas recomendado)

pip cache purge

3. Instale o PyTorch nightly com suporte ao CUDA 12.8

pip install --pre torch torchvision torchaudio --index-url https://download.pytorch.org/whl/nightly/cu128

4. Verifique a instalação

python -c "import torch; print(torch.__version__); print(torch.version.cuda); print(torch.cuda.is_available()); print(torch.cuda.get_device_name(0))"

Saída esperada:

2.7.0.dev2025xxxx+cu128
12.8
True
NVIDIA GeForce RTX 5070 Ti

Se tudo estiver certo, o erro desaparecerá e você poderá usar a GPU corretamente no Fooocus, Stable Diffusion, LLMs, etc.

Dica extra

Se você estiver usando Pinokio, Fooocus, WebUI, InvokeAI ou outro frontend com interface gráfica para IA, garanta que ele esteja utilizando o ambiente Python com esse novo PyTorch instalado.

Referência oficial

A própria equipe do PyTorch mantém instruções atualizadas aqui

Agama está llamado a ser el sustituto del legendario YaST a la hora de instalar openSUSE y SUSE en nuestros equipos. Echemos un vistazo a Agama 17

Agama es un nuevo instalador de Linux nacido en el núcleo del equipo de YaST. Está diseñado para ofrecer reutilización, integración con herramientas de terceros y la posibilidad de construir interfaces de usuario avanzadas sobre él.

Desde hace tiempo además de contribuir en la traducción del software al español, también me hago eco en el blog de las novedades que van trayendo las nuevas versiones publicadas por el equipo de desarrollo de Agama.

En este caso echaremos un vistazo a Agama 17. Puedes ver el anuncio oficial en este enlace:

• https://agama-project.github.io/blog/2025/08/27/agama-17

Esta versión de Agama 17 representa un hito importante para el proyecto Agama, ya que estando tan cerca la publicación de SUSE Linux Enterprise 16.0 y openSUSE Leap 16, esta versión de Agama (o una muy similar) se convertirá en el instalador que se utilizará para esa versión de la distribución insignia de SUSE y openSUSE.

Echemos un vistazo a algunas de las mejoras que trae Agama 17.

Mejor representación de las conexiones de red cableadas

Comenzando con la interfaz de usuario, la página para mostrar y configurar una interfaz cableada concreta se ha reorganizado en gran medida para mejorar la claridad y representar correctamente la situación en la que varios dispositivos comparten la conexión.

Mejoras en la interfaz en el apartado de almacenamiento

La página para establecer la configuración del almacenamiento también se ha reorganizado ligeramente. La información que se muestra en la sección «Dispositivos de instalación» se reorganizó con el objetivo de hacer que su uso sea más comprensible a primera vista.

Aunque todavía se esperan más cambios, este es solo el primer paso. Además de reorganizar la información, la nueva interfaz de usuario ofrece la posibilidad de utilizar directamente un disco (o un dispositivo RAID preexistente) sin crear particiones.

También hay una nueva opción para volver a escanear el sistema en caso de que se hayan conectado nuevos dispositivos de hardware, se hayan creado nuevos dispositivos lógicos (RAID de línea o grupos de volúmenes LVM) o el usuario necesite una segunda oportunidad para ingresar una contraseña de cifrado.

Nuevas opciones al incio que permite seleccionar la distribución a instalar

Agama permite instalar diferentes distribuciones que se denominan «productos» en la jerga de Agama. Recientemente, Lubos Kocman contribuyó con una nueva definición de producto para openSUSE Leap Micro 6.2. Eso significa que ahora se podrá encontrar una nueva opción en la página inicial que le permite seleccionar la distribución a instalar.

Probar y contribuir a Agama

Todavía queda un largo camino por recorrer y se siguen implementando correcciones y nuevas funciones que puedes probar en la ISO de pruebas. También puedes aportar con código en el repositorio de GitHub, reportando errores, traduciendo, etc.

Whenever I present syslog-ng at a conference or I stand next to a booth, people often ask me why should they use syslog-ng instead of one of its competitors. So let me summarize what the users and developers of syslog-ng typically consider as its most important values.

Documentation

Yes, I know, this is not syslog-ng itself. However, talking to some of our most active and loyal users, one common feedback was that they had chosen syslog-ng because of the quality of its documentation. Syslog-ng have always had very detailed and (usually) up-to-date documentation. Unfortunately though, there has been a period when our documentation has fallen victim of resource shortages for a while. However, as soon as these resource shortages have been taken care of, bringing our documentation up to pace has been at the top of our list.

Read about the rest at https://www.syslog-ng.com/community/b/blog/posts/the-core-values-of-syslog-ng

Después de la «Charlas de 24H24L», que fueron una magnífica colección de podcast sobre el ecosistema GNU/Linux, Jośe Jiménez cambió la forma de crear contenido y se centró en realizar podcast cortos, como si fueran píldoras de información que puedas tomar a modo de introducción de diversos temas o simplemente reflexiones que siempre son interesantes. Voy a intentar promocionarlos, igual que hago con otros podcast, para que este arduo trabajo no quede en saco roto. Bienvenidos pues a «Usando una sola distro de Linux», una reflexión muy acertada sobre este importante aspecto de mundo del Software Libre. No te la pierdas.

Usando una sola distro de Linux – Podcast 24H24L

El pasado 2020 finalizó un macroevento podcastero llamado 2424L, el cual tenía como objetivo seguir difundiendo las bondades de los sistemas libre GNU/Linux. Su promotor fue José Jiménez, al cual tuve el gusto de conocer en la Akademy-es 2013 de Málaga OpenSouthCode Edition ya que, además de asisitr, fue ponente.

En el 2021 repitió experiencia con bastante éxito, con una edición dedicada a la programación. Y en 2024 tenía la intención de volver a realizar la hazaña pero por diversos motivos redirigió el proyecto al formato podcast. La verdad es que tiene muchos muy interesantes, destacando la variedad de ponentes y presentadores.

Últimamente se dedica el podcasting de corta duración centrada en un tema muy específico, lo cual es ideal tanto para introducir un tema como para escuchar interesantes reflexiones, y este es el motivo de esta entrada (y las que vengan, espero)

Para empezar esta difusión empiezo con uno que publicó ayer y que me ha gustado especialmente porque creo que es una muy interesante reflexión.

En palabras de Jose:

Cuento mi experiencia usando solo un distro durante muchos años y como esto puede servir a la gente que está empezando en Linux, a centrarse en una sola distro.

Mi reflexión es la siguiente: céntrate en una distribución, soluciona el problema investigando y preguntando y, si puedes, comparte la solución.

Por cierto, dos cosas antes de cerrar. En primer lugar comentar que el podcast ha cambiado el feed. Ahora es https://24h24l.es/feed.xml. Actualiza tu aplicación de podcast si lo tenías, y si no, ya sabes qué añadir.

Y en segundo lugar, puedes realizar una pequeña donación al proyecto 24H24L. Los medios de para realizarla son los siguientes.

• PayPal ⁠https://paypal.me/JosAJimenez⁠
• Ko-fi ⁠https://ko-fi.com/josjimenez⁠
• Buy me Coffe ⁠https://buymeacoffee.com/jajt⁠
• Usando enlace referido de Amazon ⁠https://amzn.to/3DV9fy3⁠

La entrada Usando una sola distro de Linux – Podcast 24H24L se publicó primero en KDE Blog.

This week is the last week of Google Summer of Code for this year edition, and I'll do a summary of what we have been doing and future plans for the Log Detective integration in openSUSE.

I wrote a blog post about this project when it starts, so if you didn't read, you can take a look.

All the work and code was done in the logdetective-obs github repository.

Aazam, aka the intern, also wrote some blog post about his work.

Initial Research

The idea of the project was to explore ways of integration of LogDetective with the openSUSE dev workflow. So we started collecting some build failures in the openSUSE build service and testing with log detective to check if the output is smart or even relevant.

The intern creates a script to collect log from build failures and we store the LLM answer.

Doing this we detected that the log-detective.com explain is very slow and the local tool is less accurate.

The results that we got weren't too good, but at this point of the project is something expected. The model is being trained and will improve with every new log that users send.

Local vs Remote, model comparison

The logdetective command line tool is nice, but LLM requires a lot of resources to run locally. This tool also uses the models published by fedora in huggingface.co, so it's not as accurate as the remote instance that has a better trained model and is up to date.

In any case, the local logdetective tool is interesting and, at this moment, it's faster than the deployed log-detective.com.

Using this tool, Aazam did some research, comparing the output with different models.

logdetective apache-arrow_standard_x86_64.log\
  --model unsloth/Qwen2.5-Coder-7B-Instruct-128K-GGUF\
  -F Qwen2.5-Coder-7B-Instruct-Q4_K_M.gguf\
  --prompt ~/prompt.yaml

So using other specific models, the logdetective tool can return better results.

The plugin

openSUSE packagers uses the osc tool, to build packages in build.opensuse.org. This tool can be extended with plugins and we created a new plugin to use log-detective.

So a packager can get some AI explanation about a build failure with a simple command:

$ osc ld -r -p devel:languages:python --package python-pygame --repo openSUSE_Tumbleweed
🔍 Running logdetective for python-pygame (openSUSE_Tumbleweed/x86_64)...
Log url: https://api.opensuse.org/public/build/devel:languages:python/openSUSE_Tumbleweed/x86_64/python-pygame/_log
🌐 Sending log to LogDetective API...
 The RPM build process for the `python-pygame` package failed during the
`%check` phase, as indicated by the "Bad exit status from /var/tmp/rpm-
tmp.hiddzT (%check)" log snippet. This failure occurred due to seven test
failures, one error, and six skipped steps in the test suite of the package.



The primary issue causing the build failure seems to be the traceback error in
the `surface_test.py` file, which can be seen in the following log snippets:



[[  278s] Traceback (most recent call last):
[  278s]   File "/home/abuild/rpmbuild/BUILD/python-
pygame-2.6.1-build/BUILDROOT/usr/lib64/python3.11/site-
packages/pygame/tests/surface_test.py", line 284, in test_copy_rle
]
[[  278s] Traceback (most recent call last):
[  278s]   File "/home/abuild/rpmbuild/BUILD/python-
pygame-2.6.1-build/BUILDROOT/usr/lib64/python3.11/site-
packages/pygame/tests/surface_test.py", line 274, in
test_mustlock_surf_alpha_rle
]
[[  278s] Traceback (most recent call last):
[  278s]   File "/home/abuild/rpmbuild/BUILD/python-
pygame-2.6.1-build/BUILDROOT/usr/lib64/python3.11/site-
packages/pygame/tests/surface_test.py", line 342, in test_solarwolf_rle_usage
]



These traceback errors suggest that there are issues with the test functions
`test_copy_rle`, `test_mustlock_surf_alpha_rle`, and `test_solarwolf_rle_usage`
in the `surface_test.py` file. To resolve this issue, you should:



1. Identify the root cause of the traceback errors in each of the functions.
2. Fix the issues found, either by modifying the test functions or correcting
the underlying problem they are testing for.
3. Re-build the RPM package with the updated `surface_test.py` file.



It's also recommended to review the other test failures and skipped steps, as
they might indicate other issues with the package or its dependencies that
should be addressed.

Or if we are building locally, it's possible to run using the installed logdetective command line. But this method is less accurate, because the model used is not smart enough, yet:

$ osc build
[...]
$ osc ld --local-log --repo openSUSE_Tumbleweed
Found local build log: /var/tmp/build-root/openSUSE_Tumbleweed-x86_64/.build.log
🚀 Analyzing local build log: /tmp/tmpuu1sg1q0
INFO:logdetective:Loading model from fedora-copr/Mistral-7B-Instruct-v0.3-GGUF
...

Future plans

1. Adding submit-log functionality to osc-ld-plugin. In-progress. This will make it easier to collaborate with log-detective.com, allowing openSUSE packagers to send new data for model training.
2. Gitea bot. openSUSE development workflow is moving to git, so we can create a bot that comment on Pull Request with packages that fails to build. Something similar to what fedora people have for centos gitlab
3. Add a new tab to log-detective.com website to submit logs directly from OBS

This was an interesting Summer of Code project. I learned a bit about LLM. I think that this project has a lot of potential, this can be integrated in different workflows and an expert LLM can be a great tool to help packagers, summarizing big logs, tagging similar failures, etc.

We have a lot of packages and a lot of data in OBS, so we should start to feed the LLM with this data, and in combination with the fedora project, the log-detective could be a real expert in open source RPM packaging.

Summer is vacation season, at least in Europe, and that usually means nothing seems to move too much. But since there is an exception to every rule, here comes a new Agama version to prove that not even heat can stop Free Software!

Agama 17 represents an important milestone for the Agama project. Taking into account how close the release of SUSE Linux Enterprise 16.0 is, we foresee this version of Agama (or a very similar one) becoming the endorsed installer for that release of SUSE's flagship distribution.

So let's see what's new.

Better representation of wired network connections​

Starting with the web user interface, the page to display and configure a concrete wired interface was heavily reorganized to improve clarity and to correctly represent the situation in which several devices share the connection.

Improvements in the storage user interface​

The page to configure the storage setup was also slightly restructured. The information displayed at the "Installation Devices" section was reorganized with the goal of making its usage more understandable at first sight.

This is just an intermediate step to our envisioned user interface. But that is how goals are reached - one step at a time.

Apart from reorganizing the information, the new user interface offers the possibility to directly use a disk (or a pre-existing RAID device) without creating partitions.

There is also a new option to re-scan the system in case new hardware devices has been plugged in, new logical devices (line RAIDs or LVM volume groups) have been created or the user needs a second chance to enter an encryption password.

Last but not least, the user interface can now detect when an Agama configuration has been loaded affecting the storage setup.

More options at the registration page​

To finish the recap of the main changes at the user interface, we must mention the registration page. Apart from registering the system on the SUSE Customer Center (SCC), now the user interface can be used to register the system on a custom instance of RMT (Repository Mirroring Tool).

Users of such RMTs do not longer need to use a configuration profile or Agama's command-line tools, like in previous versions of the installer.

Skipping SELinux configuration​

The default installations of SUSE Linux Enterprise Server 16.0 and openSUSE Leap 16.0 will use SELinux as the default Linux kernel security module (LSM). But it is possible to adjust the software selection to not install SELinux or to install an alternative LSM (like AppArmor).

Previous versions of Agama did not manage that situation correctly. Agama always enforced the configuration of the default LSM for the product (SELinux in the mentioned cases).

Now the configuration of the LSM is based on the software selection. At the end of the installation process, Agama configures the installed security module. If several ones are installed, Agama configures one of them, with the default one having precedence over the other candidates.

New options in the JSON configuration​

As most of our readers know, the best way to access the full potential of Agama is to use a JSON (or Jsonnet) configuration. That goes far beyond the options offered by the web interface and is the default mechanism to configure unattended installations.

Agama 17 adds the possibility to configure VLAN interfaces. See the following example.

{
  "id":          "vlan10",
  "method4":     "manual",
  "method6":     "disabled",
  "addresses":   ["192.168.1.28/24"],
  "gateway4":    "192.168.1.1",
  "nameservers": ["192.168.1.1"],
  "vlan": {
    "id":     10,
    "parent": "eth0"
  }
}

Now it is also possible to activate zFCP devices by specifying the corresponding section at the JSON configuration, like in this example.

{
  "zfcp": {
    "devices": [
      {
        "channel": "0.0.fa00",
        "wwpn":    "0x500507630300c562",
        "lun":     "0x4010403300000000"
      }
    ]
  }
}

This version also adds more flexibility to define the list of software patterns to be installed. In previous versions, it was only possible to specify a whole list that would replace the default list of optional patterns defined by the product. Now it is possible to ask Agama to modify that list, just adding or removing certain patterns.

{
  "software": {
    "patterns": {
      "remove": ["selinux"],
      "add":    ["apparmor", "gnome"]
    }
  }
}

But sometimes it is Agama that wants to ask something to the user. For example, when it finds an encrypted device and needs the password to inspect its content. If that happens, Agama's user interface can show a dialog for the user to provide the answer. But there are more options to communicate those answers to Agama, like using the command agama questions to load a file containing answers. Agama 17 introduces a third way - the new questions section at the JSON configuration. Again, let's illustrate it with an example.

{
  "questions": {
    "policy": "auto",
    "answers": [
      {
        "class": "storage.luks_activation",
        "password": "nots3cr3t"
      }
    ]
  }
}

Improvements for unattended installation​

Users of the unattended installation will of course benefit from the mentioned new options added to the JSON configuration. But the improvements for automated installations go beyond that.

On the one hand, Agama does not longer proceed silently if it fails to fetch or process a configuration provided via the inst.auto boot argument. Instead, this new version displays an error message asking the user whether or not to retry. If the user decides to not retry, Agama does not start the auto-installation process. This is just a first step in the right direction, in the future Agama will offer better diagnostics and the possibility to specify a new URL.

On the other hand, the new boot arguments inst.auto_insecure and inst.script_insecure allow to disable the SSL checks when fetching the configuration or the installation script for an unattended installation. That simplifies setting up the corresponding infrastructure in controlled environments.

More possibilities to patch the installer​

Traditionally, the (open)SUSE installation process could be modified using RPM packages or a so-called DUD (driver update disk). Despite the name, the possibilities go way further than updating the drivers. A DUD might contain files to be copied to the installation media, scripts to be executed during the process, new or updated packages to be installed, etc. You can learn more at this classic document.

Previous versions of Agama already had some limited compatibility that allowed to patch the installation process. But that compatibility improves a lot with Agama 17.

At Agama, the URL of an update is specified through the boot option inst.dud. As mentioned, an update can be a simple rpm package or a more complex DUD, created with the mkdud tool. You can specify as many updates as you wish. Do not forget the rd.neednet option if you need the network to retrieve the DUD.

inst.dud=http://192.168.122.1/agama.dud rd.neednet

Additionally, the inst.dud_insecure boot argument allows to ignore SSL certificate problems (eg. a self-signed certificate) when fetching updates.

The family grows​

As you know, Agama allows to install different distributions that are called "products" in Agama's jargon. Recently Lubos Kocman contributed a new product definition for openSUSE Leap Micro 6.2. That means you will now find a new option on the initial page that allows to select the distribution to install.

Welcome aboard, Leap Micro!

Web page reorganization​

And last but not least, a news that is not about Agama itself but about the site that hosts this blog. As a first step to extend Agama's documentation, we reorganized agama-project.github.io quite a lot. Check the new additions like the "Get started" and "Guides & HowTos" sections. The second one is at an early stage, but we are already working on growing it with more and more content. Of course, contributions are more than welcome.

As a drawback, many of the links you may have from previous sources may now be broken. We rearranged the content a lot and it was not feasible to define a redirection for every moved piece of information. Sorry about that.

We keep moving​

As mentioned, the upcoming SUSE Linux Enterprise 16.0 will be distributed with the current version of Agama or with a very similar one. But that does not imply Agama development will slow down, quite the opposite. There is still a long road ahead and we will keep implementing fixes and new features that you could always test with our constantly updated testing ISO.

Of course, we will keep you updated on this blog. But if you got questions or want to get involved further, do not hesitate to contact us at the Agama project at GitHub and our #yast channel at Libera.chat.

Have a lot of fun!

¿Cuánto dinero te cuesta instalar el navegador Chrome de Google en tu equipo? ¿Cuánto pagaría una empresa a Google por hacerse con su navegador?

El navegador Chrome de Google es sin duda el más utilizado a la hora de utilizarlo para navegar por la red. Su cuota de mercado está por encima del 65%, muy lejos de su segundo competidor.

El 17 de agosto de 2025, Enrique Dans publicaba un artículo en su blog donde escribía sobre la oferta que la empresa Perplexity le había hecho a Alphabet (a la sazón Google) por comprarle su navegador Chrome.

Y juntando estas dos cosas, me dio por pensar…

Cualquier persona que quiera utilizar el navegador Chrome de Google puede hacerlo de maner gratuita. Puede ir a su página oficial, descargarlo, instalarlo en su equipo y utilizarlo, todo sin pagar nada, ya que el navegador Chrome es gratuito.

No hay que pagar nada por utilizarlo, ni por añadir funcionalidades. No piden donaciones ni dinero al proyecto por ningún sitio y además se integra con otras herramientas del ecosistema de Google. Millones de personas utilizan este navegador a coste 0 para la persona que lo utiliza. Chrome es gratuito (aunque no es libre, ya que no está publicado bajo una licencia de software libre).

Entonces, según el artículo de Enrique Dans ¿Por qué una empresa como Perplexity ha hecho una oferta a Google por 34.5 billones de dólares (y probablemente pueda valer más) por un software que es gratuito?

Es decir, a la persona que lo usa le ha costado 0, y a la empresa que lo desarrolla, con toda la inversión en materia de desarrollo de software que implica, le han ofrecido 34.5 billones de dólares.

Además Chrome está basado en Chromium, que sí es software libre. Perplexity podría poner en marcha un navegador web (de hecho creo que lo está haciendo) empleando mucho menos del dinero de la oferta y crear su propio navegador. Pero no tendría la cuota de mercado de Chrome, y conseguirla sería muy complicado.

¿Dónde están las ganancias? ¿Qué es lo que tiene tanto valor en un software que no puedes vender? ¿Qué es lo que vale tanto dinero o más como el ofertado para querer comprarlo? ¿Si el precio es 0, dónde está el valor?

Supongo que en los datos que generan los millones de usuarios en todo el mundo que lo utilizan.

El navegador es la parte clave con la que nos comunicamos en la red. Aunque ahora hay aplicaciones en nuestros dispositivos móviles fuera del navegador para acceder a nuestras compras, bancos, y otras acciones del día a día. El navegador sigue siendo la puerta con la que nos conectamos a internet.

Y supongo que todos los datos que generamos y todas las estadísticas y bases de datos que pueden alimentar con nuestro modo de utiliarlo es lo que vale tanto dinero, porque habrá un montón de empresas deseando comprar y tener disponibles todos esos datos cruzados para su beneficio y sacarle todo el partido.

La verdad es que todo eso me queda muy grande y no entiendo cómo podría explotarse el uso de Chrome para ganar dinero, o por lo menos tanto como para que puedan ofertarse esas cifras por su software.

Pero me dio por pensar en ese abismo tan enorme entre precio y valor. Me gustará leer tus opiniones al respecto.