Dear Tumbleweed users and hackers,

Week 17 was filled with snapshots – 7 of them to be precise. We have published snapshots 0421…0427 (with the next ones almost ready for QA).

The main changes included were:

• TeXLive 2022
• Postfix 3.6.6
• Linux kernel 5.17.4
• jdk-11.0.15+10 (April 2022 CPU)
• systemd: systemd-boot efi binary is now signed
• Mesa 22.0.2
• KDE Gear 22.04.0

Staging projects are currently busy building and testing these things:

• ffmpeg 5: use ffmpeg 5 as default over ffmpeg 4; results are mixed so far
• GNOME 42.1
• cURL 7.83.0
• Linux kernel 5.17.5
• some fdupes changes: aid with reproducible builds (order dups by name)
• GCC 12 as default compiler

Llegamos al primer cuarto del año y sigo la serie de la iniciativa #viernesdeescritorio con un nuevo capítulo. Con este ya llevo más doce meses consecutivos compartiendo «Mi escritorio», una mirada a la intimidad de mi entorno de trabajo. De esta forma, bienvenidos a mi escritorio Plasma de abril 2022 que sigue en un tema oscuro, como el mes pasado, pero diferente ya que aproveché un tiempo de reclusión para personalizar al máximo el mismo.

Mi escritorio Plasma de abril 2022 #viernesdeescritorio

Esta va a ser la vigésimasegunda vez que muestro mi escritorio Plasma 5 en público, lo cual es número nada desdeñable de entradas. La entrada recopilatoria de las misma está cada vez más cerca… siempre lo digo pero sigue sin llegar.

En esta ocasión sigo mostrando mi escritorio del despacho, he cambiado el tema global y empezado a utilizar el Global Menú, a ver si dura o vuelvo a la posición de menú tradicional

Siendo más específicos, este mes he decidido utiliza el tema global Moe Dark, del gran creador de temas Jomada, el cual dediqué una entrada donde el mismo creador realizaba un vídeo explicativo del proceso para utilizar 100% el tema.

Siguiendo las líneas del tema, sigo con la barra Latte Dock con cuatro barras: una inferior con las aplicaciones y en la parte superior una a la derecha con la bandeja del sistema, una en el centreo con la fecha y la hora y una a la izquierda con el lanzador de aplicaciones y el menú global.

En esta ocasión, la captura está realizada sobre mi Slimbook Kymera AMD de sobremesa con doble pantalla (la principal de 24″ y la secundaria de 19″) el cual tiene instalado un KDE Neon con Plasma 5.24.4 cuando realicé esta entrada.

El resultado de mi escritorio de abril de 2022 es un entorno de trabajo oscuro pero luminoso, limpio y 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 abril 2022 #viernesdeescritorio se publicó primero en KDE Blog.

Finalizo la promoción previa de este magnífico evento que se va a celebrar mañana 29 y el sábado 30 de este mes de abril en Rovereto, Italia. En otras palabras, me complace anunciar que mañana empieza Linux App Summit de 2022, el evento híbrido que une desarrolladores de todo entornos de trabajo.

Mañana empieza Linux App Summit 2022

Para los que vayan un poco despistados el próximo 29 y 30 de abril se celebra la Linux App Summit 2022 en Rovereto, Italia, un evento que realizará una modalidad híbrida, que combinará sesiones presenciales y a distancia, incluyendo charlas, paneles y preguntas. Además, los vídeos de LAS se transmitirán en directo en su canal de YouTube. En mi opinión, este es el futuro de todos los eventos.

Hace relativamente poco anuncié el programa de charlas y hace menos comenté que se había abierto el registro del evento, y hoy quiero recordar que mañana se inicia este evento, al cual no podré asistir ni de forma presencial ni virtual.

¿Qué es Linux App Summit (LAS)?

El año pasado se celebró en Barcelona y fue un éxito, como lo demuestra la fotografía superior donde aparecen algunos de los participantes.

Linux App Summit es un evento diseñado para acelerar el crecimiento del ecosistema de aplicaciones Linux sea cual sea su entorno de trabajo.

De esta forma se reúne a todos los involucrados para intentar optimizar la experiencia de usuario de aplicaciones GNU/Linux, compartiendo el conocimiento que se tiene del uso y problemas de sus respectivos programas.

Estamos ante un evento que va en contra del mito que los desarrolladores de los distintos entornos de escritorio se llevan como el perro y el gato, todo lo contrario ya que aunque utilizan librerías diferentes el objetivo es el mismo: crear las mejores aplicaciones posibles para los usuarios.

Más información: Linux App summit

La entrada Mañana empieza Linux App Summit 2022 se publicó primero en KDE Blog.

I’ve always, or at least ever since the development of the iconic Nokia N9 and the projects I was working on at the time, wanted “60 fps” silky smooth behavior from both phones and computers, and learned to be sensitive to that. GNOME has been fighting back a bit on that front for several years though on HiDPI displays, with also regressing at least on openSUSE a bit earlier which I was unable to pinpoint exact reason to. A combination of power management options helped, as have been kernel and GNOME fixes later on, so I have been mostly ok but still not happy.

This changed last year, when Daniel van Vugt started offering his awesome work on triple buffering in GNOME, which ensures correct amount of power budget to be used for what’s needed for a smooth UI. I backported / adapted the patch to GNOME 40 on Tumbleweed first, then later GNOME 41. There were a couple of bugs left and Wayland support worked worse at the time, but I still was so happy with the performance that I couldn’t imagine anymore using GNOME without the patch set.

Now with GNOME 42 the patch set is mature, and I’m using it also on Wayland without obvious issues. It’s great on my laptop’s internal 4K display, and on my WQHD (2560x1440) desktop screen. Notably, the patch set is enabled by default in the new Ubuntu 22.04 LTS long-term supported version, after being in development for 1.5 years. I really hope it will be merged upstream soon, but meanwhile we have the next best option - a patch set that directly applies on top of GNOME 42.

To install it from my OBS repository (note: I will not use that repository for other packages despite the generic name):

zypper ar https://download.opensuse.org/repositories/home:/tjyrinki_suse:/branches:/openSUSE:/Factory/openSUSE_Tumbleweed/home:tjyrinki_suse:branches:openSUSE:Factory.repo
zypper up

The repository automatically updates to the latest changes whenever there’s a new Mutter in Tumbleweed. I will also likely continue to update the repository either with the patch set from upstream, or if rebasing becomes more difficult I can also check the patch set changes applied on top of Ubuntu’s GNOME 42.

For smoother future!

What hardware to use for a syslog-ng server? It is a frequent question with no definite answer. It depends on many factors: the number and type of sources, the number of logs, the way logs are processed, and so on. My experience is that for the majority users even a Raspberry Pi would be enough. But of course, not for everyone.

You can read the rest of my blog at https://www.syslog-ng.com/community/b/blog/posts/hardware-for-a-syslog-ng-server

Cómo añadir el dato del uptime del servidor donde tenemos instalado Pi-hole a la cabecera del panel de administración de Pi-hole

Desde que instalé Pi-hole en mi Raspberry Pi para filtrar el tráfico no deseado de publicidad y rastreadores que asolan internet, siempre quise que en el panel de administración también se añadiera el uptime del servidor.

El uptime es el tiempo que el equipo lleva encendido desde que se arrancó, sin que se haya reiniciado, o apagado.

En sistemas GNU/Linux puedes consultar el dato ejecutando el comando

uptime

Que mostrará algo similar a:

19:50:14 up 9 days, 17 min,  3 users,  load average: 0,74, 0,80, 0,87

Que muestra la hora actual del sistema, y el tiempo que lleva arrancado el sistema, en el ejemplo anterior lleva 9 días y 17 minutos. También mostraría las horas, en este caso son 0.

Muestra el número de usuarios logueados y la carga del sistema en los últimos 1, 5 y 15 minutos.

También podemos mostrar el uptime de otras formas más amigables como por ejemplo:

$ uptime -p
up 1 week, 2 days, 22 minutes

o que nos muestre desde qué fecha lleva el sistema encendido mediante:

$ uptime -s
2022-04-17 19:32:39

También el dato en segundos está disponible en /proc/uptime

Vamos a utilizar esta última opción y convertirla en segundos, minutos y horas para mostrar la información en el panel principal de Pi-hole como se muestra en la captura que abre el artículo.

Aviso que no soy desarrollador, así que quizás mi opción no es muy ortodoxa. Y también tiene el fallo de que no se actualiza ese dato en el panel. Solo se actualiza si refrescas la pantalla con F5.

He estado mirando cómo hacer que se refresque el dato cada quizás 10 segundos o así, pero todavía está en proceso…

Para mostrar el uptime de nuestro servidor en donde tenemos instalado Pi-hole, en mi caso en mi Raspberry Pi, hay que modificar el archivo:

/var/www/html/admin/scripts/pi-hole/php/header.php

He creado un parche que añade directamente las modificaciones en el archivo usando patch, y que puedes consultar/descargar en este enlace:

• https://gitlab.com/-/snippets/2305191

Descargado el parche podemos aplicarlo mediante:

sudo patch /var/www/html/admin/scripts/pi-hole/php/header.php uptime.patch

Refrescamos nuestra página del panel de administración de Pi-hole y ya aparecerá el nuevo dato del uptime de nuestro servidor.

He querido sugerirlo como una nueva «feature» en el proyecto Pi-hole, pero hay que registrarse en Discord, y además seguro que el código es muy chapucero y mejorable, así que aquí queda como proyecto personal.

Y si a tí te apetece probarlo, ya te he dado las pautas para incluirlo. Si quieres antes de probarlo, haz una copia del archivo header, por si no te convence y quieres volver al archivo original.

¿Te parece útil ese dato en Pi-hole? Si lo pruebas, utiliza los comentarios para compartir tu opinión.

Este mes de abril está siendo un mes con muchos lanzamientos: el viernes hablaba de KDE Gear 22.04 (colección de aplicaciones para sistemas de escritorio) y el lunes de Kubuntu 22,04, la nueva versión de esta veterana distribución. Hoy toca hablar de que también está disponible Plasma Mobile Gear 22.04, la colección de aplicaciones especialmente diseñadas para dispositivos móviles. Hagamos una breve reseña del lanzamiento.

Para los que no lo conozcan Plasma Mobile es la alternativa libre a interfaz gráfica para smartphones de la Comunidad KDE, hablé de él hace un tiempo y, poco a poco, se está convirtiendo en un clásico del blog.

Su idea es muy simple, tras conquistar tu escritorio KDE la Comunidad también quiere conquistar tu teléfono móvil… aunque todavía lo tenga complicado por todas las limitaciones de hardware que todavía tiene este campo de la tecnología.

No obstante, confiemos que de igual forma se han ido conquistando los ordenadores de sobremesa, portátiles y servidores, lleguemos un día que podamos tener libertad total en nuestros smartphones.

Y para cuando eso ocurra la Comunidad KDE estará preparada para ello y por eso está confeccionando un catálogo más que decente de aplicaciones con tecnología adaptativa.

Disponible Plasma Mobile Gear 22.04

En este mes de diciembre, y siguiendo la estela de los KDE Gear, Plasma Mobile Gear ha lanzado su versión 22.04, la cual llega con muchas novedades. Veamos algunas de ellas a la espera de poder realizar un articulo más completo.

• Actualizada la página web: página de inicio, las páginas del sitio, el estilo del contenido y la página de capturas de pantalla.
• Creadas algunas páginas de documentación para desarrolladores, útiles para ayudar a los nuevos contribuyentes a la pila y las herramientas de Plasma.
• Se continua trabajando en la corrección de problemas y mejoras incrementales en el shell para la próxima versión 5.25.
• Se ha corregido la doble animación que se produce al activar y minimizar las aplicaciones,.
• Se ha añadido una función para el conmutador de tareas que permite ordenarlas por el momento en que se abrieron, en lugar de hacerlo por orden alfabético.

La entrada Disponible Plasma Mobile Gear 22.04 se publicó primero en KDE Blog.

A long time passed since the last time I wrote something on this blog! 😅 I haven’t been idle during this time, quite the opposite… I kept myself busy experimenting with WebAssembly and Kubernetes.

You probably have already heard about WebAssembly, but there are high chances that happened in the context of Web application development. There’s however a new emerging trend that consists of using WebAssembly outside of the browser.

WebAssembly has many interesting properties that make it great for writing plugin systems or even distributing small computational units (think of FaaS).

WebAssembly is what is being used to power Kubewarden, a project I created almost two years ago at SUSE Rancher, with the help of Rafa and other awesome folks. This is where the majority of my “blogging energies” have been focused.

Now, let’s go back to the main focus of today’s blog entry: write kubectl plugins using WebAssembly.

The current state of things

As you all know, kubectl can be easily extended by writing external plugins.

These plugins are executables named kubectl-<name of the plugin> that, once put in your $PATH can be invoked via kubectl <name of the plugin>. This is the same mechanism used to write git plugins.

These plugins can be managed via a tool called Krew.

The kubectl tool is available for multiple operating systems and architectures, which means these plugins must be available for many platforms.

Can WebAssembly help here?

I think writing kubectl plugins using WebAssembly has the following advantages:

• Portability: you don’t have to build your WebAssembly-powered plugin for all the possible operating systems and architectures the end users might want.
• Security: each WebAssembly module is executed inside of a dedicated sandbox. They cannot see other modules or processes running on the host. They also don’t have access to the host resources (filesystem, devices, network). Think of them as containers.
• Size: the majority of kubectl plugins are written using Go, which produces big binaries. The average size of a kubectl plugin is around 9 Mb. WebAssembly on the other hand, can produce plugins that are half the size.

Last but not least, this sounds like a fun experiment!

Introducing krew-wasm

The idea about writing kubectl plugins with WebAssembly originated during a brainstorming session I was doing with Rafa about our upcoming talk for WasmDay EU 2022. The idea kinda “infected” me, I had to hack on it ASAP!!! This is how the krew-wasm project was created.

krew-wasm takes inspiration from Krew, but it does not aim to replace it. That’s quite the opposite, it’s a complementary tool that can be used alongside with Krew.

The sole purpose of krew-wasm is to manage and execute kubectl plugins written using WebAssembly and WASI.

krew-wasm plugins are WebAssembly modules that are distributed using container registries, the same infra used to host container images.

krew-wasm can download kubectl WebAssembly plugins from a container registry and make them discoverable to kubectl. This is achieved by creating a symbolic link for each managed plugin. This symbolic link is named kubectl-<name of the plugin> but, instead of pointing to the WebAssembly module, it points to the krew-wasm executable.

Once invoked, krew-wasm determines its usage mode which could either be a “direct invocation” (when the user invokes the krew-wasm binary to manage plugins) or it could be a “wrapper invocation” done via kubectl.

When invoked in “wrapper mode”, krew-wasm takes care of loading the WebAssembly plugin and invoking it. krew-wasm works as a WebAssembly host, and takes care of setting up the WASI environment used by the plugin.

I’ll leave the technical details out of this post, but if you want you can find more on the GitHub project page.

Some examples

The POC would not be complete without some plugins to run. Guess what, you can find a one right here!

The kubectl decoder plugin dumps Kubernetes Secret objects to the standard output, decoding all the data that is base64-encoded. On top of that, when a x509 certificate is found inside of the Secret, a detailed output is shown rather then the not so helpful PEM encoded representation of the certificate.

If you want to experiment with this idea, you can write your plugins using Rust and this SDK.

Summary

This has been a nice experiment. It proves the combination of WebAssembly and WASI can be used to produce working kubectl plugins.

What’s more interesting is the fact these technologies could be used to extend other Cloud Native projects. Did someone say helm? 😜

There are however some limitations, mostly caused by the freshness of WASI. These are documented here. However, I’m pretty sure things will definitely improve over the next months. After all the WebAssembly ecosystem is moving at a fast pace!

The first time I heard about 21unity was when I read the announcement: 21unity Joins OpenPOWER Foundation. I immediately became interested in the company, as it combines two things I am interested in: POWER and open source. Among others 21unity has its own cloud based on the POWER platform and provides Nextcloud as a service. I tried to refresh my German knowledge and read their website, but the more I read the more interesting it got and the more questions I had. I have seen from the reactions on Twitter, that many people were happy to learn about a new company working with POWER. So, instead of a few quick questions in private, I asked for an interview. Chris Branston of 21unity answered my questions.

Introduction:

Hi, my name is Chris Branston and I’m 35, living in Nürnberg Germany and am the Head of Marketing and Communications for 21unityGmbH. I’m a tech and opensource enthusiast and have spent many years working in the IT/opensource Industry and have always enjoyed meeting and collaborating with people from around the globe in the many different communities creating awesome and open solutions.

How 21unity was born?

I only joined 21unity in March 22 but one of the favorite quotes our CTO likes to mention is a quote from Steve Jobs: “Here´s to the crazy ones (…) the ones who see things differently (…) You can quote them, disagree with them, glorify or vilify them, but the only thing you can´t do is ignore them. Because they change things.” “Because the people who are crazy enough to think they can change the world, are the ones who do.“

I love the way 21unity tries to find new solutions, to everyday problems without all the nonsense and blabla, which we are used to from big corporations. But with a sole focus on making IT accessible and easy to use and maybe even fun for our users.

As lateral thinkers in technology, we leave the path of conventional thinking behind, to find new and efficient solutions. Solutions that form the foundation for a trusting and long-term cooperation. Our claim is to stand by our customers as honest partner.

We‘ve learned our trade from scratch and our team consists of technicians, developers and programmers who were there in the beginnings: Those who grew up with Apple II and Lisa and worked with systems from sgi, Cray, Sun and IBM. But generally, we are just as knowledgeable in the Linux or Unix environment, as we are in handling Apple devices (Mac) or Windows PCs.

Our mission is to take really complex technology and deliver it to our customers (and with that the end users) in an easy to use, stress free way. While it is vital, to use state of the art technology, it’s even more important, to create products that do one simple thing – WORK.

Those are the reasons why 21unity was founded and from where we take our everyday motivation to do what we do.

How did you get started with POWER? What was the main reason?

We decided, the only way to deliver consistent services with full control of what happens where and how data is handled and how secure these systems are, is to build our own data center, which is not connected to any of the big 3s networks. This idea might sound a bit crazy at first, but it has one big benefit when you build stuff from scratch: There are no messy integrations, upgrades or other legacy issues that come up, but you get to build exactly what you need and want.

So when we started thinking about architecture and designing the system, we started thinking from the other side- the enduser perspective. We wanted to build a cloud system, that is fast, easy to use and foremost reliable and secure. With the hopes of becoming very successful and gaining many new users in short periods of time, we knew it would be important, that we use hardware that is scalable, modular and which gives the maximum user per core, or to say it a little more colloquial, which gives us more bang for our buck.

The thing about x86 and traditional VMs, is that they also are scalable and manageable, but there is just so much speed you can get out of them. In 2022 we have so many new ways of deploying and running workloads on hardware, that it wouldn’t have made any sense, to deploy in a traditional, or say pretty monolithic way.

So when it came down to choosing an architecture, naturally we decided on using openPOWER, because the POWER architecture has proven itself time and time again in big, mission critical deployments. OpenPOWER, in our scenario, helps us tackle typical challenges like scalability, high availability and stability of our infrastructure. Since we believe in the benefits of open solutions and the communities building them,we joined the OpenPOWER foundation, because we want to use the benefits of a proven technology, combined with a global community of enthusiast and experts. And at 21unity internally, we were always more on the RISC than the CISC side of thing ;)

Do you use IBM servers, or from Raptor Computing? Or do you build your own?

We use POWER 9 processors combined with hardware, that we build ourselves. We will also deliver this hardware to our customers in the future, if they don’t want to or can’t use our cloud services and applications. While IBM servers are usually the go-to for these cases, as mentioned in the first question, we like to re define the common standards and find our own ways of using state of the art technologies, to build the best possible services.

Do you have POWER also on the desktop?

No, for the moment, we are only working on the server side of things, but for the future I was told by our CTO, that a POWER workstation is definitely on the horizon.

You provide Nextcloud, a well known open source application as a service. Are there any other open source software in your portfolio?

Since Nextcloud is a complete collaboration platform, that includes many features and functionalities, we are using a multitude of open source projects and technologies. We are also in contact with different projects like the OpenPOWER foundation to connect and collaborate and modify some of the out of the box experiences, to create our own custom-built platform and features, that are oriented around our customers feedback and needs.

One of the main open source projects I can mention and that we heavily use is Kubernetes.

Your website and blogs are only available in German. Does it mean that you are active only in Germany or German speaking countries? Do you plan international expansion?

As our marketing expert I really love that question and have already been asked about that a couple of times. We had internal discussions about this and decided to start locally and then grow to international levels at pace. I’ve seen many companies trying to reach the whole world instead of taking things step by step and delivering quality over quantity and reach. But I definitely will start to seed international (English) content to our pages and products, as this is an industry standard and I don’t want to leave anyone out with cool information and technology.

Hoy os traigo una otra obra de Ramón Miranda en que nos explica cómo grabar con Krita utilizando la nueva funcionalidad de Krita 5: Recorder Docker. Y para hacerlo nada mejor que hacerlo mediante un vídeo donde nos explica las opciones básicas.

Cómo grabar con Krita, vídeo de Ramón Miranda

Empiezan a ser un clásico del blog los vídeos de Ramón Miranda y el fabuloso Krita. Ya han aparecido en esta bitácora 10 trucos para Krita, pintando con Krita el «Tajo de Ronda» y perspectiva con Krita así que no es de extrañar que esta serie siga creciendo, como es el caso de hoy en el que os presento hoy.

En sus propias palabras:

¡HOLA! La Recorder Docker es una función increíble para crear timelapses. Descubre cómo usarla. Disfrútalo! y si te gusta apóyanos!

El vídeo tiene subtítulos en inglés para la gente con discapacidad auditiva y está separado en partes ya que los tiempos están en la descripción de Youtube. No obstante, para el que solo quiera ver el vídeo lo pongo abajo.

Recuerdo bien a Ramón Miranda, al cual tuve el gusto de conocer en la Akademy y Akademy-es de 2013 de Bilbao, y que sigue promocionando Krita con su maravilloso trabajo.

¿Qué es Krita?

Para los que no lo sepan, Krita es el software de pintura digital e ilustración basado en las librerías de la plataforma KDE que antes estaba incluido en Calligra Suite.

A diferencia de otras aplicaciones gráficas, se diseño hace énfasis en la creación de imágenes desde cero, es decir, está especialmente orientado para los artistas gráficos como ilustradores, dibujantes de cómics, etc.
Krita es software libre distribuido bajo la licencia GNU GPL y fue lanzado por primera vez como parte de la versión 1.4.0 de KOffice, el 21 de junio de 2005. (Vía: Wikipedia)

Para ver el funcionamiento de esta aplicación nada mejor que ver un vídeo de Odysseas Stamoglou en la que nos muestra como dibujar una chica futurística con Krita.

La entrada Cómo grabar con Krita, vídeo de Ramón Miranda se publicó primero en KDE Blog.