GNOME 46 Wallpapers
GNOME 46 is on its final stretch to be released. It's been a custom to blog a little about the wallpaper selection, which is a big part of GNOME's visual identity.
The first notable change in 46 is that we're finally delivering on the promise of bringing you a next generation image file format. Lots of performance issues had to be addressed first, apologies for the delay. While efficiency and filesize requirements might not be too high on the list outside of the geek crowd, there is one aspect of JPEG-XL that I am very excited about.
JPEG-XL allows the use of client-side synthesized grain. A method pioneered by Netflix/AV1 I believe. Compression algorithms struggle with high frequency detail, which often introduce visible artifacts. JPEG-XL allows to decouple the grain component from the actual image data. This allows for significantly more efficient compression of images that inherently require noise, such as those in gnome-backgrounds — smooth gradients that would otherwise be susceptible to color banding. To achieve similar fidelity of the grain if it were baked in, a classic format like JPEG would need an order of magnitude larger filesize. Having the grain in the format itself also allows to skip various techniques in the rendering or compositing in the 3D software.
Instead of compressing a noisy image, JPEG-XL allows to generate film-like grain as part of the decoding process. This synthesized grain combats issues like color banding while allowing a much more efficient compression on the original image data.
In essence, client-side grain in JPEG-XL isn't simply added noise, but a sophisticated strategy for achieving both efficient compression and visually pleasing image quality, especially for images that would otherwise require inherent noise.
The fresh batch of wallpapers includes evolutions of the existing assets as well as new additions. A few material/shape studies have been added as well as simple 2D shape textures. Thanks to the lovely JPEG-XL grain described earlier, it's not just Inkscape and Blender that were used.
I hope you're going to pick at least one of the wallpapers when GNOME 46 releases later next week as your favorite. Let me know on fediverse!
GNOME 46 Wallpapers
GNOME 46 is on its final stretch to be released. It’s been a custom to blog a little about the wallpaper selection, which is a big part of GNOME’s visual identity.

The first notable change in 46 is that we’re finally delivering on the promise of bringing you a next generation image file format. Lots of performance issues had to be addressed first, apologies for the delay. While efficiency and filesize requirements might not be too high on the list outside of the geek crowd, there is one aspect of JPEG-XL that I am very excited about.

JPEG-XL allows the use of client-side synthesized grain. A method pioneered by Netflix/AV1 I believe. Compression algorithms struggle with high frequency detail, which often introduce visible artifacts. JPEG-XL allows to decouple the grain component from the actual image data. This allows for significantly more efficient compression of images that inherently require noise, such as those in gnome-backgrounds — smooth gradients that would otherwise be susceptible to color banding. To achieve similar fidelity of the grain if it were baked in, a classic format like JPEG would need an order of magnitude larger filesize. Having the grain in the format itself also allows to skip various techniques in the rendering or compositing in the 3D software.

Instead of compressing a noisy image, JPEG-XL allows to generate film-like grain as part of the decoding process. This synthesized grain combats issues like color banding while allowing a much more efficient compression on the original image data.

In essence, client-side grain in JPEG-XL isn’t simply added noise, but a sophisticated strategy for achieving both efficient compression and visually pleasing image quality, especially for images that would otherwise require inherent noise.

The fresh batch of wallpapers includes evolutions of the existing assets as well as new additions. A few material/shape studies have been added as well as simple 2D shape textures. Thanks to the lovely JPEG-XL grain described earlier, it’s not just Inkscape and Blender that were used.
I hope you’re going to pick at least one of the wallpapers when GNOME 46 releases later next week as your favorite. Let me know on fediverse!
Primera actualización de Plasma 6
Me alegra compartir con todos vosotros la primera actualización de Plasma 6, iniciando así una serie de revisión de software que le dotará de más estabilidad, mejores traducción y resolución de errores. Estas actualizaciones son 100% recomendables y casi obligatorias para cualquier usuario ya que lo único que hacen es mejorar la versión sin comprometer sus funcionalidades.
Primera actualización de Plasma 6
No existe Software creado por la humanidad que no contenga errores. Es un hecho incontestable y cuya única solución son las actualizaciones. Es por ello que en el ciclo de desarrollo del software creado por la Comunidad KDE se incluye siempre las fechas de las mismas siguiendo una especie de serie de Fibonacci.
La Comunidad KDE ha publicado se se ha lanzado la primera actualización de Plasma 6, una versión que ha supuesto una salto muy importante en cuanto a tecnología y que, francamente, ha salido bastante bien ya, por ejemplo, KDE Neon se actualizó pasadas unas horas del lanzamiento, con problemas menores y completamente funcional (de hecho, estoy trabajando desde el jueves 29 con él en todos mis equipos).

Creo es un buen momento para reflexionar: yo tardé casi un año en dar el salto a KDE 4 a Plasma 5, ya que es cuando pensé acertadamente que ya se ofrecía algo bastante estable para el trabajo diario. Para dar el salto de KDE 3 a KDE 4 fueron varios años, así que estamos ante un hito que marca un pico de calidad en el mundo del Software Libre.
Para dar el salto de Plasma 5 a Plasma 6 han bastado 5 horas. ¡Y lo mejor está por llegar! Y es que en realidad, los desarrolladores de KDE simplemente se han centrado en portar Plasma 5 a Plasma 6 y todas las novedades de la nueva tecnología está todavía en desarrollo y se irá implementando poco a poco.
Así que me congratula en presentar que ayer martes 5 de marzo de 2024, una semana después de liberar el código la Comunidad KDE presenta la primera actualización de errores entre los que destacan:
- KWin: Arreglado que el puntero confinado pueda escapar de la pantalla.
- Arreglado la desaparición del puntero al alejarse (esto explica porqué no lo veía!!!!)
- La opción «Añadir widgets» del menú contextual hacía que el panel en modo «Ocultar automáticamente» se ocultara, lo que hacía imposible añadir widgets al panel sin entrar en el modo Edición de otra forma.
Más información: KDE
Las novedades básicas del Plasma 6
Han sido dias tan frenéticos que no he podido hacer todavía la entrada detallando las novedades de Plasma 6 o de KDE Gears, pero he aquí una pincelada de las mismas .
- Nuevo efecto de vista general: se han combinado los efectos de Vista general y Cuadrícula de escritorios en uno, con grandes mejoras en los gestos del panel táctil.
- Color mejorado: Plasma en Wayland ya tiene compatibilidad parcial con alto rango dinámico (HDR).
- Nuevo fondo de escritorio: Árbol escarlata, creado por axo1otl.
- Panel flotante: en Plasma 6, el panel flota de forma predeterminada. Se puede cambiar, por supuesto.
- ¡Nuevos valores predeterminados!
- Brisa refrescada: se ha rediseñado el tema Brisa para que presente un aspecto más moderno, con menos marcos y con un espaciado más consistente.
- Preferencias reorganizadas: se ha mejorado la aplicación de Preferencias para que resulte más amigable y tenga menos páginas anidadas.
- ¡El cubo ha vuelto!
- Mejoras en la búsqueda de Plasma: ahora personalizar el orden de los resultados de la búsqueda y es mucho más rápida.
- Mejoras en Plasma Mobile.
- Cambios en todas las aplicaciones de KDE Gear: Kontact, Kleopatras. Itineray, KDE Edu, KDEnlive, Dolphin, Spectacle, etc.

Y esto es una brevísima pincelada… Creo que ahora tengo temas de para el blog de sobra hasta 2025.
La entrada Primera actualización de Plasma 6 se publicó primero en KDE Blog.
Linux Gaming with Anti-Cheat | Work in Progress
Enhancements in OBS Content Moderation: Canned Responses, User Insights, UI Upgrades, and Documentation Updates
Séptimo audio de Podcast Linux «Linux Connexion con Huezo» – Podcast Linux #7
Aunque el proyecto Podcast Linux está parado esto no significa que no tenga cabida en el blog y, mientras pueda, seguiré promocionándolo con la esperanza de que reviva, como cierto pájaro mitológico. Y he pensado hacerlo de una forma sencilla para mi y creo que benificiosa para todos, creando poco a poco un índice de todas sus emisiones, de forma que podamos encontrar en este blog una alternativa a su magnífica obra. Así que bienvenidos al séptimo audio de Podcast Linux «Linux Connexion con Huezo» que nos trae al creador y administrador del grupo GNU/Linux en Telegram, la primera comunidad que reseñó Juan en la sección Comunidad Linux.
Séptimo audio de Podcast Linux «Linux Connexion con Huezo» – Podcast Linux #7

Como los lectores del blog sabrán hace un tiempo Podcast Linux cerró sus emisiones por motivos que solo incumben a su creador. Desde el blog no quiero dejar que su recuerdo se desvanezca así que seguiré publicitando sus audios ya que su calidad no debe caer en el olvido.
Hace poco decidí empezar por el principio, mostrando su primer audio, el cual no promocioné en su día. Lo mismo ocurría con los siguientes, y, si las búsquedas no me engañan no fue hasta los episodios 19, 20, 21 y 22 cuando empecé a hacerlo.
De esta forma continuo con su séptimo audio que, en palabras de Juan, se nos presentaba así:
Tenemos hoy con nosotros a Huezo, creador y administrador del grupo GNU/Linux en Telegram, la primera comunidad que reseñé en la sección Comunidad Linux.
Agradecerle su total disposición y todas las facilidades que me ha dado para grabar esta entrevista.
Más información: Podcast Linux
Sigue a Podcast Linux
Aprovecho para animaros a seguir Podcast Linux en algunos de los canales de comunicación que tiene:
- Twitter: https://twitter.com/podcastlinux
- Mastodon: https://mastodon.social/@podcastlinux/
- Correo: podcastlinux@disroot.org
- Web: https://podcastlinux.com/
- Telegram: https://t.me/podcastlinux
- Telegram Juan Febles: https://t.me/juanfebles
- Youtube: https://www.youtube.com/PodcastLinux
- Feed Podcast Linux: https://podcastlinux.com/feed
- Feed Linux Express (Audios Telegram): https://podcastlinux.com/Linux-Express/feed
La entrada Séptimo audio de Podcast Linux «Linux Connexion con Huezo» – Podcast Linux #7 se publicó primero en KDE Blog.
Installation guide for warewulf4
Warewulf
Preface
In High Performance Computing (HPC) computing tasks are usually distributed among many compute threads which are spread across multiples cores, sockets and machines. These threads are thightly coupled together. For this compute clusters consist of a number of largely identical machines that need to be managed to maintain a well defined and identical setup across all nodes. Once clusters scale up there are many scalability factors to overcome. Warewulf is there to address this ‘administrative scaling’.
Warewulf is an operating system agnostic installation and management system
for HPC clusters.
It is quick and easy to learn aud use as many settings are pre-configured
to sensible defaults. It still provides the flexibility allowing to finely
tune the configuration to local needs.
It is released under the BSD license. Its source code is available at
https://github.com/warewulf/warewulf. This is where the development happens
as well.
Installing warewulf4
Compute clusters consist of at least one management or head node which is usually multi-homed connecting both to an external network and to a cluster private network as well as multiple compute nodes which reside solely on the private network. Other private networks dedicated to high speed task like RDMA and storage access may exist as well. Warewulf gets installed to one of the management nodes to manage and oversee the installation and management of the compute nodes. To install Warewulf on a cluster is running SUSE Linux Enterprise HPC 15 SP5, openSUSE Leap 15.5 or openSUSE Tumbleweed, simpy run:
zypper install warewul4
on this management node to install the SUSE-provided Warewulf package. This package seamlessly integrates into a SUSE system and should therefore be preferred over packages provided on Github.
During the installation the actual network configuration is written to the
/etc/warewulf/warewulf.conf. These settings should be verified, as for
multi homed hosts a sensible pre-configuration is not always possible.
Check /etc/warewulf/warewulf.conf for the following values:
ipaddr: 172.16.16.250
netmask: 255.255.255.0
network: 172.16.16.0
where ipaddr should be the ip address of this host management host.
Also check the values of netmask and network - these should match
this network.
Additionally, you should configure the ip addresse range for dynamic/unknown hosts:
dhcp:
range start: 172.16.26.21
range end: 172.16.26.50
If the ISC dhcpd server is used (default on SUSE) make sure the value of
DHCPD_INTERFACE in the file /etc/sysconfig/dhcpd has been set to the
right value.
You are now ready to start the warewulfd service itself which delivers the
images to the nodes:
systemctl enable --now warewulfd.service
Now wwctl can be used to configure the the remaining services needed by
warewulf. Run
wwctl configure --all
which will configure all warewulf related services.
Adding nodes and profiles to warewulf
Warewulf uses the concept of profiles which hold the generalized settings
of the individual nodes. It comes with a predefined profile default, to
which all new node will be assigned, if not set otherwise. You may obtain
the values of the default profile with:
wwctl profile list default
Now, a node can be added with the command assigning it an IP address:
wwctl node add node01 -I 172.16.16.101
the mac address is known for this node, you can specify this as well:
wwctl node add node01 -I 172.16.16.101 -H cc:aa:ff:ff:ee
For adding several nodes at once you may also use a node range which results e.g.
wwctl node add node[01-10] -I 172.16.16.101
this will add the nodes with ip addresses starting at the specified address and incremented by warewulf.
Importing a container
Warewulf uses a special 1 container as the base system to build OS images for the compute nodes. This is self contained and independent of the operating system installed on the warewulf host.
To import an openSUSE Leap 15.5 container use the command
wwctl container import docker://registry.opensuse.org/science/warewulf/leap-15.5/containers/kernel:latest leap15.5 --setdefault
This will import the specified container for the default profile.
Alternative container sources
Alternative containers are available from the openSUSE registry under the science project at
https://registry.opensuse.org/cgi-bin/cooverview?srch_term=project%3D%5Escience%3A
or from the upstream warewulf community repository
https://github.com/orgs/warewulf/packages?repo_name=warewulf-node-images
It is also possible to import an image from a chroot by using the path to
chroot as argument for wwctl import.
Booting nodes
As a final preparation you should rebuild the container image by running
wwctl container build leap15.5
as well as all the configuration overlays with the command
wwctl overlay build
just in case the build of the image may have failed earlier due to an error. If you didn’t assign a hardware address to a node before you should set the node into the discoverable state before powering it on. This is done with
wwctl node set node01 --discoverable
Now the node(s) can be powered on and will boot into assigned container.
For a convenient experience you should now log out of and back into the warewulf host, as this way an ssh key for password-less login to the compute nodes will be created on the warewulf host. Note, that this key is not pass-phrase protected. If you require a pass phrase, it is probably a good idea to set one now:
ssh-keygen -p -f $HOME/.ssh/cluster
Also you should run
wwctl configure hostlist
to add the new nodes to the file /etc/hosts.
Additional configuration
The configuration files for the nodes are managed as Golang text templates. The resulting files are overlayed over the node images. There are two ways of transport for the overlays to the compute node, the
- system overlay
- runtime overlay
where the system overlay is baked into the boot image of the compute node
while the runtime overlay is updated on the nodes on a regular base
(1 minute per default) via the
wwclientservice.
In the default configuration the overlay called wwinit is used as system
overlay. You can list the files in this overlays with the command:
wwctl overlay list wwinit -a
which will show a list of all the files in the overlays. Files ending with the
suffix .ww are interpreted as template by warewulf and the suffix is removed
in the rendered overlay.
The content of the overlay can be shown using the command
wwctl overlay show wwinit /etc/issue.ww
To render the template using the values for node01 use:
wwctl overlay show wwinit /etc/issue.ww -r node01
The overlay template itself may be edited using the command
wwctl overlay edit wwinit /etc/issue.ww
Please note that after editing templates the overlays aren’t updated automatically and should be rebuild with the command
wwctl overlay build
The variables available in a template can be listed with
wwctl overlay show debug /warewulf/template-variables.md.ww
Modifying the container
The node container is a self contained operating system image. You can open a shell in the image with the command
wwctl container shell leap15.5
After you have opend a shell in the image additional software can be installed
with zypper.
The shell command provides the option --bind which allows to mount arbitrary
host directories into the container during the shell session.
Please note that if a command exits with a status other than zero the image won’t be rebuilt automatically. So its also advised to rebuild the container with
wwctl conainer build leap15.5
after any change.
Network configuration
Warewulf allows to configure multiple network interfaces for the compute nodes. You can add another network interface for example for infiniband using the command
wwctl node set node01 --netname infininet -I 172.16.17.101 --netdev ib0 --mtu 9000 --type infiniband
This will add the infiniband interface ib0 to the node node01. You can now
list the network interfaces of the node:
wwctl node list -n
As changes in the settings are not propagated to all configuration files, the node overlays should be rebuilt after this change running the command:
wwctl overlay build
After a reboot these changes will be present on the nodes, in the avove case the Infiniband interface will be active on the node.
A more elegant way to get same result is to create a profile to hold the values
which are the same for all interfaces. In this case these are mtu and the
netdev.
A new profile for an Infiniband network is created using the command
wwctl profile add infiniband-nodes --netname infininet --netdev ib0 --mtu 9000 --type infiniband
Once this has been created, you may add this profile to a node and remove the node specific settings which are now part of the common profile by executing:
wwctl node set node01 --netname infininet --netdev UNDEF --mtu UNDEF --type UNDEF --profiles default,infiniband-nodes
You may list the data in a profile using this command:
wwctl profile list -A infiniband-nodes
Secure Boot
Switch to grub boot
Per default warewulf boots nodes via iPXE, which isn’t signed by SUSE and
can’t be used when secure boot is enabled. In order to switch to grub as boot
method you will have add/change following value in /etc/warewulf/warewulf.conf
warewulf:
grubboot: true
After this change you will have to reconfigure dhcpd and tftp executing
wwctl configure dhcp
wwctl configure tftp
and rebuild the overlays with the command
wwctl overlay build
Also make sure that the packages shim and grub2-x86_64-efi for x86-64
or grub2-arm64-efi for arm are installed in the container. shim is
required by secure boot.
Cross product secure boot
If secure boot is enabled on the compute nodes and you want to boot different
products make sure that the compute nodes boot with the so called ‘http’ boot
method: For secure boot the signed shim needs to match the signature of the
other pieces of the boot chain - including the kernel. The ‘http’ method is
handled by warewulfd which will look up the image to boot and pick the shim
from the image to deploy to this node. Otherwise, the initial shim for PXE
boot, which is the default boot method, is extracted from the host running the
warewulfd server. Make sure, the node container contains the shim package.
The host system shim will also be used for nodes which are in discoverable
state and subsequently have no hardware address assigned yet.
Disk management
It is possible to manage the disks of the compute nodes with warewulf. Here,
warewulf itself doesn’t manage the disks, but creates a configuration and
service files for ignition to do this job.
Prepare container
As ignition and its dependencies aren’t installed in most of the containers
you should install the packages ignition and gptfdisk in the container
wwctl container exec <container_name> zypper -n in -y ignition gptdisk
Add disk to configuration
For storage devices all the necessary structures must be configured which are
- physical storage device(s) to be used
- partition(s) on the disks
- filesystem(s) to be used
Disks
The path to the device e.g. /dev/sda must be used As diskname.
The only valid configuration for disks is diskwipe which should be
self explanatory.
Partitions
The partname is the name to the partition whick iginition uses as the path
for the device files, e.g. /dev/disk/by-partlabel/$PARTNAME.
Additionally the size and number of the partition need be specified for all but the last partition (the one with the highest number) in which case this partition will be extended to the maximal size possible.
You should also set the boolean variable --partcreate so that a parition
is created if it doesn’t exist.
Filesystems
Filesystems are defined by the partition which contains them, so the
name should have the format /dev/disk/by-partlabel/$PARTNAME. A filesystem
needs to have a path if it is to be mounted, but its not mandatory.
Ignition will fail, if there no filesystem type is defined.
Examples
You can add a scratch partition with
wwctl node set node01 \
--diskname /dev/vda --diskwipe \
--partname scratch --partcreate \
--fsname scratch --fsformat btrfs --fspath /scratch --fswipe
This will be the only (and last) partition, therefore it does not require a size. To add another partition as swap partition, you many run:
wwctl node set n01 \
--diskname /dev/vda \
--partname swap --partsize=1024 --partnumber 1 \
--fsname swap --fsformat swap --fspath swap
This adds the partition number 1 which will be placed before
the scratch partition.
-
This container is special only in that it is bootable, ie it contains a kernel and an init-implementation (systemd). ↩
Dedicated Windows XML eventlog parser in syslog-ng
Version 4.6 of syslog-ng introduced windows-eventlog-xml-parser(), a dedicated parser for XML-formatted event logs from Windows. It makes the EventData portion of log messages more useful, as it combines two arrays into a list of name-value pairs.
https://www.syslog-ng.com/community/b/blog/posts/dedicated-windows-xml-eventlog-parser-in-syslog-ng

syslog-ng logo
Aggregating messages in syslog-ng using grouping-by()
Sometimes you have many log messages from an app, but none of them have the exact content you need. This is where the grouping-by() parser of syslog-ng can help. It allows you to aggregate information from multiple log messages into a single message.
In this blog, I will show you how to parse sshd logs using the patterndb parser of syslog-ng, and then create an aggregate message from the opening and closing log message using grouping-by.
https://www.syslog-ng.com/community/b/blog/posts/aggregating-messages-in-syslog-ng-using-grouping-by

syslog-ng logo
Cómo Google ayudó a destruir la expansión de los feeds RSS
Google con su monopolio casi exclusivo de lo que la gente conoce como internet ha contribuido con sus prácticas a que decaiga el uso de los feeds RSS aunque aún hay quienes los utilizamos

¿Quieres estar al tanto de las publicaciones de una web, blog que te gusta mucho? Una opción es visitarla todos los días para ver si ha publicado algo nuevo… pero hay otras opciones, por ejemplo usar los feeds RSS.
En resumen, cada web o blog (este blog mismo que estás leyendo) tiene disponible ese servicio que hace que gracias a un programa único puedas recopilar todas las novedades de esas webs o blogs recopiladas en un solo lugar en tu equipo.
Así podrás recopilarlas cuando tengas tiempo para leerlas, puedes guardarlas para consultarlas más adelante, ordenarlas, etiquetarlas, etc. Pero no solo sirve para webs o blogs. muchos otros servicios también se difunden usando esta tecnología.
Ahora que resuena en una parte de la comunidad de internet esa tendencia a retornar a los orígenes de la red, alejándonos de la comercialización, del seguimiento, del abuso de la persona que visita, de cobra por cookies, etc.
Los feeds RSS son una herramienta que ha estado ahí desde hace muchos años y fue muy utilizado. En este artículo repasaremos cómo Google con sus prácticas monopolistas ha querido también eliminar del imaginario de internet esta tecnología en favor de algo más centralizado (en su empresa) que permita cuntificar, monetizar y controlar al usuario.
Este artículo es una traducción del inglés de un artículo publicado por OpenRSS en agosto de 2023 en su web que puedes leer en este enlace:

Aunque los feeds RSS están vivos y todavía se utilizan mucho hoy en día, su nivel de adopción se ha visto afectado debido a lo difícil que ha sido para un puñado de empresas de tecnología populares utilizarlos.
Google, especialmente, ha confiado en el protocolo RSS de la web abierta para ganar tanta participación de mercado e influencia, pero continúa adoptando un comportamiento que explota la web abierta a expensas de sus usuarios.
Como resultado, Google ha contribuido por sí solo a la razón por la que muchos usuarios que alguna vez confiaron en los canales RSS hayan dejado de usarlos.
A continuación, profundizamos en el historial de Google de lo que parece ser un modelo de Abrazar, Extender y Extinguir.
La compañía ha construido y ampliado continuamente sus productos en torno al protocolo RSS abierto y gratuito para ganarse la confianza del usuario, solo para luego eliminar el soporte RSS una vez que han bloqueado a los usuarios e ignorar cualquier queja o solicitud para restaurarlo.
No sólo es un flagrante desprecio por el RSS y una gran decepción para quienes lo utilizan, sino que plantea una de las mayores amenazas a la libertad y apertura de Internet.
Google elimina el botón RSS del navegador Chrome
Las primeras versiones del navegador Chromium (en el que se basa el navegador Google Chrome) alguna vez vinieron con integración RSS incorporada.
El navegador tenía un botón RSS incorporado que se mostraba en la barra de direcciones del navegador cuando cualquier sitio web en el que se encontraba tuviera una fuente RSS disponible.
Al hacer clic en el botón, accederá a la fuente RSS de esa página web, lo que permitirá al usuario suscribirse fácilmente.
Luego, el botón RSS desapareció sin previo aviso y no se dio ninguna razón para su eliminación.
Google adquiere FeedBurner y limita el RSS
En 2007, Google adquirió FeedBurner, un servicio de feeds RSS que permite a los propietarios de sitios web monetizar sus feeds RSS.
FeedBurner funciona reemplazando los canales RSS ordinarios por canales privados que sólo pertenecen a Google.
Los feeds se modifican para incluir anuncios, enlaces de afiliados y otros mecanismos de seguimiento, como recuentos de lecturas, tasas de clics y recuentos de suscriptores. Luego, los usuarios de FeedBurner utilizan los feeds para realizar un seguimiento de sus lectores y monetizar su comportamiento.
Después de adquirir FeedBurner, Google cerró las API de FeedBurner en octubre de 2012, lo que impidió a los desarrolladores crear integraciones RSS de terceros para el servicio.
Luego, en julio de 2022, Google cambió drásticamente la infraestructura y el modelo operativo de FeedBurner al eliminar la mayoría de los servicios de FeedBurner de los que dependían sus usuarios de RSS, que incluían suscripciones por correo electrónico.
Esto dejó a muchas personas con URL de fuentes RSS que no funcionaban en sus correos electrónicos de suscripción y sin forma de solucionarlas.
Google cierra Google Reader
En 2005, Google creó Google Reader, una aplicación de lectura de RSS basada en web. Le permitía agregar fuentes RSS en cualquier lugar de Internet y organizarlas en carpetas en una interfaz limpia y minimalista.
Luego, en 2013, después de años de que los usuarios confiaran en él para sus feeds RSS, Google lo eliminó.
La razón que dio Google para eliminar Google Reader fue en un anuncio en el que afirmaban que «si bien el producto tiene seguidores leales, a lo largo de los años su uso ha disminuido».
Pero un ingeniero, que trabajaba para Google en ese momento, declaró: «Me sentí como si durante todo el tiempo que estuve en el proyecto, varias personas intentaran acabar con él».
Sin embargo, la acusación de Google sobre el bajo uso no infundió mucha confianza en la viabilidad de los canales RSS. Los usuarios se quedaron sin una aplicación de lectura de RSS, sin una alternativa comparable y sin educación por parte de Google sobre cómo continuar usando sus canales RSS sin Google Reader.
Esto llevó a los usuarios no sólo a dejar de usar Google Reader, sino también a abandonar por completo los feeds RSS.
Google elimina el RSS de las Alertas de Google
Google Alerts es un servicio ofrecido por Google que le notificará con una alerta cuando haya contenido nuevo en la web que coincida con un término de búsqueda que usted especifique.
En octubre de 2008, Google añadió la posibilidad de recibir alertas de Google en un canal RSS. Pero, en julio de 2013, Google decidió eliminarlo, convirtiendo el correo electrónico en la única opción para recibir alertas de Google. El motivo de la eliminación no estaba claro.
Finalmente, después de recibir una reacción violenta, Google restableció los canales RSS para las Alertas de Google. Pero en ese momento, muchos usuarios ya abandonaron los feeds RSS debido al cierre de Google Reader por parte de Google (mencionado anteriormente), por lo que el daño ya estaba hecho.
Google elimina su extensión de navegador RSS
Google proporcionó una extensión de Google Chrome que coloca un pequeño ícono RSS al lado de la URL de un sitio web en la barra del navegador si estás en una página web que tiene una fuente RSS.
A pesar de que se utilizó esta extensión, Google la eliminó. Pero luego, después de una reacción violenta, lo restableció una semana después, alegando que se eliminó por error. Y si bien restablecerlo era mejor que no hacerlo, eliminarlo seguía siendo un duro golpe para la confianza del usuario en el uso general del feed RSS.
Y si es cierto que se hizo sin querer, todavía muestra cuán poco prioritario se ha convertido el RSS para Google, a pesar de lo mucho que el RSS ha contribuido al crecimiento de la empresa.
Google elimina la integración RSS de Google News
En 2002, Google anunció Google News, el primer sitio de agregación de medios de la compañía, con la capacidad de agregar URL de fuentes RSS de toda la web.
Luego, después de que muchos usuarios de RSS quedaran bloqueados y dependieran de la aplicación Google News para sus feeds RSS, Google dejó de admitir el soporte RSS, lo que provocó que los feeds RSS de los usuarios dejaran de funcionar.
Luego, Google cerró por completo su soporte para feeds RSS en diciembre de 2017. La compañía no dio ninguna razón para eliminar el soporte para feeds RSS en su aplicación Google News.
Como resultado, los usuarios no tuvieron más remedio que buscar enlaces RSS alternativos para cada feed que agregaron a la aplicación Google News, mientras que los enlaces privativos y no abiertos de Google News continuaron funcionando bien.
Google sigue en ello…
El incidente más reciente ocurrió en mayo de 2021, cuando Google anunció que están trabajando en una actualización de Google Chrome que recupera la compatibilidad con RSS.
Pero no ha habido noticias sobre un lanzamiento oficial desde que se anunció hace años. No está claro cuáles serán las implicaciones de esta característica. Pero está claro que Google tiene un historial de crear productos con RSS y eliminar el soporte RSS una vez que ha establecido una base de usuarios.
Por lo tanto, no hay garantía de que, incluso si se lanza la función, seguirá estando disponible y siendo confiable para los usuarios de RSS con el tiempo.
Debido a que Google sin duda tiene una enorme influencia, esperamos que comprenda que incorporar funciones RSS en sus productos y luego eliminarlas afecta negativamente la percepción y la confianza del usuario en torno a RSS en general.
Los canales RSS son una parte vital de la web abierta. Por lo tanto, si Google decide continuar integrando funciones RSS en sus productos, es fundamental que las respalde, las mantenga a lo largo del tiempo y se asegure de que siempre sigan siendo una prioridad.
Si has leido hasta aquí, espero que te haya resultado interesanta esta interesante recopilación de lo que la gran empresa Google ha realizado con los RSS y los estándares abiertos.
Por mi parte sigo utilizando los RSS en mis equipos usando Akregator, aunque en el blog he escrito artículos y tutoriales sobre otros programas para recopilar los feeds RSS.
Además los feeds son la base sobre la que se mantiene PlanetaLibre, el agregador de blogs y webs en español sobre GNU/Linux y software libre. ¡Al que de hecho te puedes suscribir también mediante RSS! 
¿Usas RSS? ¿Conoces este método de consultar aquello que te interesa? ¿Tienes algo que compartir al respecto? Usa los comentarios para compartirlo.
