The openSUSE Project will begin monthly web development sprints to address feedback provided by attendees of the Jan. 23 meetup regarding the results of the End of the Year Survey.

The sprints will be every first Thursday of the month at 18:30 UTC and will take place online at https://meet.opensuse.org/websprints; the first sprint starts on Feb. 4.

The web sprints are open for people to provide feedback to the community about the various websites openSUSE has for on-boarding people who install openSUSE and people who want to learn more about the distributions, tools and technologies. The sprints will focus on several aspects of web development and enhance the structure of the websites to better direct users toward helpful links, resources and communication tools. The web sprints seek participation from new, current and former users to provide feedback to developers with the desire to better understand how people navigate the openSUSE websites.

Gaining feedback on the best communication channels to help people solve technical issues and better ways to show people how to get involved in the project are desired outcomes from the web development sprints.

The sprints will provide a useful way for people to voice their feedback and gain knowledge about web development and technologies.

Organizers of the sprint are collecting topics and ideas on https://etherpad.opensuse.org/p/websprints, so even people who are interested but unable to attend can help improve the navigation and content of the project’s websites.

Next Meetup for End of Year Survey Results

The next sessions will start at 13:00 UTC on openSUSE’s Jitsi instance on Jan. 30. Topics to be discussed are:

• Tools driving switchers to openSUSE (Where are users coming from)
• Discuss flagship project/s
• Expanding global users
• Increasing diversity
• Increase usage with people under 34

The meetup will take place at https://meet.opensuse.org/EOY2020.

Hoy me complace presentar Weekday Grid, el plasmoide de KDE número 167 de la gran serie de los mismos mostrados en el blog y que nos ofrece una forma minimalista y elegante de mostrar el día de la semana en nuestro escritorio.

Weekday Grid – Plasmoides de KDE (167)

Tenemos muchos plasmoides estilo reloj para Plasma, pero pocos para calendarios. Haciendo un rápida búsqueda por el blog me aparecen Calendar WL y Event Calendar, aunque hay que reconocer que éste último es una bestia parda difícil de igualar.

No obstante, calendarios minimalistas y con funciones muy definidas hay pocos, y es por ello que me alegra presentaros Weekday Grid, un simple plasmoide que nos muestra el día de la semana en el que nos encontramos de una forma sencilla pero atractiva.

Lo podemos colocar, como todos los plasmoides, tanto en el escritorio como en una barra de tareas, aunque yo me decanto por lo primero.

También destacan sus opciones de personalización tanto de aspecto (seleccionando el tema de colores que deseemos o creando el nuestro propio) como la posibilidad de elegir la localización específica del plasmoide, útil en mi caso ya que lo he cambiado a castellano ya que en catalán todos los días empiezan en «d».

Y como siempre digo, si os gusta el plasmoide podéis “pagarlo” de muchas formas en la nueva página de KDE Store, que estoy seguro que el desarrollador lo agradecerá: puntúale positivamente, hazle un comentario en la página o realiza una donación. Ayudar al desarrollo del Software Libre también se hace simplemente dando las gracias, ayuda mucho más de lo que os podéis imaginar, recordad la campaña I love Free Software Day 2017 de la Free Software Foundation donde se nos recordaba esta forma tan sencilla de colaborar con el gran proyecto del Software Libre y que en el blog dedicamos un artículo.

Más información: KDE Store

¿Qué son los plasmoides?

Para los no iniciados en el blog, quizás la palabra plasmoide le suene un poco rara pero no es mas que el nombre que reciben los widgets para el escritorio Plasma de KDE.

En otras palabras, los plasmoides no son más que pequeñas aplicaciones que puestas sobre el escritorio o sobre una de las barras de tareas del mismo aumentan las funcionalidades del mismo o simplemente lo decoran.

Veamos cómo consultar el historial de búsquedas realizadas y el historial de comandos ejecutados en el editor Vim

Vim tiene la gran utilidad de almacenar muchas cosas en historiales, para ahorrarnos tiempo a la hora de realizar tareas repetitivas o volver a consultar cosas que hemos realizado.

Por ejemplo los historiales de búsquedas realizadas y de comandos ejecutados en el editor Vim. Veamos cómo consultar esos historiales, navegar entre ellos, etc.

Este artículo es una nueva entrega del curso “improVIMsado” que desde hace meses vengo publicando en mi blog sobre el editor Vim y que puedes seguir en estos enlaces:

• https://victorhckinthefreeworld.com/tag/vim/
• https://victorhck.gitlab.io/comandos_vim/articulos.html

Vim de manera predeterminada guarda un historial de 50 registros, algo que es muy poco. Es buena práctica aumentar el número de registros guardados en el historial.

Para ello añadiremos la siguiente línea en nuestro archivo de configuración .vimrc, para que almacene 1000 registros:

:set history=1000

También hay que destacar que:

• cuando escribimos un nuevo comando que es igual que el anterior, el más antiguo se elimina, para que no haya entradas duplicadas en el historial.
• solo se guardan los comandos que se escriben, no aquellos que provienen de mapeados de teclados, o similares.
• todas las búsquedas se guardan en el historial de búsquedas, incluso aquellas en las que hemos utilizado “*” o “#”

Pero vayamos al meollo de la cuestión ¿te parece?

Historial de comandos ejecutados

Quizás alguna vez hayas abierto este historial sin darte cuenta, ya que el comando para abrir el historial es:

q:

Similar al :q utilizado para cerrar el buffer actual de Vim. Ejecuanto el comando anterior en modo normal, se nos abrirá una ventana inferior con el historial de los comandos ejecutados.

Podemos navegar por el historial con “j” y “k” o con las teclas de movimiento del cursor arriba y abajo.

También estando en esa ventana podemos buscar entre los comandos ejecutados. Si ponemos por ejemplo:

:set

Y pulsamos con las flechas arriba y abajo, nos mostrará todos los comandos ejecutados que comenzaban con set.

También podemos buscar no solo con las letras con las que comenzaba un comando del historial, también podemos buscar con “/” y el texto a buscar:

/<texto a buscar>

Esto buscará la cadena <texto a buscar> entre todos los comandos del historial de comandos, no solo los que empiezan con set como el modo anterior.

Podremos movernos entre las cadenas encontradas con N o n.

También es posible buscar en el historial, pulsando solo los dos puntos

:

Y después movernos con las teclas de las flechas arriba y abajo e iremos recorriendo el historial.

Con cualquier modo utilizado, cuando encontremos el comando que deseamos, al pulsar Enter se volverá a ejecutar.

Historial de búsquedas

Para abrir el historial de búsquedas ejecutaremos:

q/

También nos abrirá una pantalla inferior con un listado de las últimas búsquedas realizadas. También podremos buscar en ese historial con

/<texto a buscar>

Y navegar entre las ocurrencias encontradas con N y n de las búsquedas del historial que contienen el <texto a buscar>.

Como en el caso anterior, también podemos recorrer el historial de búsquedas escribiendo el comando para buscar:

/

Y después pulsando las teclas de movimiento del cursor arriba y abajo hasta encontrar la opción que queremos.

Con cualquier método utilizado, al encontrar la búsqueda deseada y pulsar Enter, Vim volverá a realizar la misma búsqueda en nuestro buffer.

Al abrir las ventanas en las que se muestran el historial de comandos o de búsquedas, además de buscar, también podremos “reutilizar” algún elemento de esos historiales.

Podremos reutilizarlas, porque una vez encontrada la entrada que queremos podremos editarla y cambiar la parte que queremos por otra y ejecutar ese nuevo comando.

Para salir de esas ventanas podremos hacerlo con alguna de estas opciones:

• Ctrl-C
• Ctrl-C W
• :quit

Cuando los comandos o las búsquedas son sencillas igual es más fácil el volver a escribirlas de nuevo, pero cuando son comandos o búsquedas complejas que incluyen opciones, etc esta manera nos ayuda a no tener que volver a escribir todo o recordarlo.

Espero que este nuevo truco del curso de Vim en mi blog te sea de utilidad si no sabías que existía, comparte tu experiencia en los comentarios del blog. A mí me resulta útil.

Quizás en otro artículo echemos un vistazo a otros historiales que Vim almacena.

Ever since Red Hat announced that they are changing the development model of CentOS and making it an upstream project rather than downstream, it left many CentOS users frowning. No matter what argument brought forward, CentOS users, especially running production machines, relied on the stability of an enterprise-grade Linux distribution. Compiled from RHEL sources, CentOS offered such stability that it powered many web servers and enjoyed a massive 20% share of the top 500 supercomputers of the world.

Some time back, Red Hat made another annoucement, about new Red Hat Enterprise Linux programs. Under the new program RHEL can be used in production for up to 16 systems (which Red Hat considers a small workload) at zero license costs. Also, Red Hat is making it easier for a customer's development team to join the program and reap the benefits.

What risks lie ahead for an enterprise if Red Hat changes or cancels the program in the future? 🤔

On the other hand, since 2018, SUSE has worked closely with the openSUSE community to bring the Leap distribution closer to SUSE Enterprise Linux (SLE), such that now Leap and SLE are binary compatible.

openSUSE currently offers two distinct distributions, Leap & Tumbleweed.

Tumbleweed is a rolling distribution constantly getting updated software whereas Leap has planned releases that sync with SUSE Linux Enterprise and its Service Packs.

The above image depicts how openSUSE & SUSE Linux Enterprise are developed together. Factory is the rolling development codebase for both openSUSE & SLE. In the pipeline we can see that Leap & SLE are synced and both receive software packages from the same source; that is why they are both binary compatible.

In a series of blog posts explaining how SUSE builds its Enterprise Linux distribution, author Vincent Moutoussamy details the relationship between openSUSE & SLE.

Conclusion

Red Hat allows its clients to use RHEL for free on up to 16 machines. On the other hand, openSUSE Leap boasts binary compatibility with SUSE Linux Enterprise and comes without any restriction on usage.

Cover image source:
Photo by Gratisography from Pexels

Sigo la serie de artículos que nos van a ir informando de las novedades que nos esperan en la nueva versión del escritorio Plasma de la Comunidad KDE. Así que bienvenidos a «Camino a Plasma 5.21 (II): las mejoras visuales» donde hablaremos de qué nuevos ajustes en el aspecto gráfico que se han cocinado para esta nueva versión de nuestro entorno de trabajo preferido.

Camino a Plasma 5.21 (II): las mejoras visuales

El pasado 21 de enero fue lanzado la beta de Plasma 5.21, una versión no apta todavía para el usuario domésticos, y que se libera para ir solucionando errores.

En el artículo del pasado jueves ya hablé por encima de sus novedades pero hoy quiero comentaros dos mejoras visuales que nos encontremos pronto en nuestro escritorio.

La primera es simple pero más importante de lo que parece: ñas aplicaciones que utilizan el tema por defecto de Plasma tendrán un esquema de colores renovado y lucirán un nuevo estilo de barra de cabecera unificado con un aspecto nuevo y limpio.

La segunda es la presentación de Breeze Twilight: una combinación de un tema oscuro para Plasma y un tema claro para las aplicaciones, para que podamos disfrutar de lo mejor de ambos mundos. Estará disponible en la configuración global de temas y estoy ansioso por probarlo, ya que últimamente utilizo un tema oscuro y veo que en ocasiones no cuadra todo del todo.

Más información: KDE.org

Pruébalo y reporta errores

Todas las tareas dentro del mundo del Software Libre son importantes: desarrollar, traducir, empaquetar, diseñar, promocionar, etc. Pero hay una que se suele pasar por alto y de la que solo nos acordamos cuando las cosas no nos funcionan como debería: buscar errores.

Desde el blog te animo a que tú seas una de las personas responsables del éxito del nuevo lanzamiento de Plasma 5.20 de la Comunidad KDE. Para ello debes participar en la tarea de buscar y reportar errores, algo básico para que los desarrolladores los solucionen para que el despegue del escritorio esté bien pulido. Debéis pensar que en muchas ocasiones los errores existen porque no le han aparecido al grupo de desarrolladores ya que no se han dado las circunstancias para que lo hagan.

Para ello debes instalarte esta beta y comunicar los errores que salgan en bugs.kde.org, tal y como expliqué en su día en esta entrada del blog.

Bastille is a container management system for FreeBSD, similar to Docker or Podman on Linux. The historical name of containers on FreeBSD is jail, and they appeared a lot earlier than containers on Linux. Managing jails was not always easy. When I started to use this technology in production in 2001, nothing was automated. Using Bastille, you can easily create, configure, or update jails at scale. It has a template system to install applications in containers and there is a template also for syslog-ng.

From this blog, you can learn how to get started with Bastille and how to create and run a syslog-ng jail using the freshly released 0.8 version of Bastille.

Before you begin

First of all, to use Bastille, you need FreeBSD installed. I used FreeBSD 12.2 on AMD64, but it also works on CURRENT and on any platform supported by FreeBSD, including the Raspberry Pi. Bastille 0.8, the release I’m describing in my blog, was released after the latest quarterly package release. It means, that by the time of writing this blog article, you can install it only using an up-to-date ports snapshot or following the latest PKG builds, instead of the quarterly PKG release.

Installing Bastille

The easiest way to install Bastille is to use the pkg command:

pkg install bastille

And depending on your Internet connection, it will be installed within a few seconds. You can also install it from ports:

cd /usr/ports/sysutils/bastille/
make install clean

There are no extra dependencies when you install Bastille. There is one exception, even if it is not hardcoded into the Makefile in ports: you need to install Git to be able to use the template system.

pkg install git

Configuring Bastille

Bastille supports many different FreeBSD features, like ZFS or VNET. However, these need extra planning, stronger hardware, and more control over the network. So, in this blog, I go with the easiest configuration possible, which works anywhere: on your local network or somewhere in a public cloud as well. For more choices and advanced functionality, check the Bastille documentation at https://bastille.readthedocs.io/en/latest/

The commands below enable Bastille, create and start an internal network interface for jails and also enable the PF firewall. Run each of these commands from a terminal.

sysrc bastille_enable="YES"
sysrc cloned_interfaces+=lo1
sysrc ifconfig_lo1_name="bastille0"
service netif cloneup
sysrc pf_enable="YES"

The next step is to set up the PF firewall. The configuration below should go into /etc/pf.conf and you should replace “em0” on the first line with your actual network interface name. This configuration makes sure that jails can reach the Internet through NAT and Bastille can create rules to access services in jails without editing the firewall configuration manually.

ext_if="em0"

set block-policy return
scrub in on $ext_if all fragment reassemble
set skip on lo

table <jails> persist
nat on $ext_if from <jails> to any -> ($ext_if)

rdr-anchor "rdr/*"

block in all
pass out quick modulate state
antispoof for $ext_if inet
pass in inet proto tcp from any to any port ssh flags S/SA modulate state

You can now restart the pf service for these rules to take effect. Note, that if you work over an SSH connection, you might be kicked off from the system when you hit Enter. In this case, reconnect and continue your work:

service pf restart

Finally, bootstrap the release of your choice (not more recent than what the host is running):

bastille bootstrap 12.2-RELEASE

It downloads and extracts the given release. You are now ready to create your first jail!

Creating your first jail

The first step is to create a jail. “bastille create” expects a few parameters from you. One is a name for the jail. In the example below, we use “alcatraz”, but in real life, you will most likely use names that remind you of the function of the jail, for example: centralsyslog. You also need a FreeBSD release name and finally an IP address. Use a different IP address if your host is on a 10.0.0.0/8 network.

bastille create alcatraz 12.2-RELEASE 10.17.89.50

Unlike previous releases, version 0.8 of Bastille starts the freshly created jail automatically. I prefer this way, but not everyone is happy with this change, so it might change in future releases.

Now, bootstrap the syslog-ng template. It uses Git to download the template from a repository on GitLab.

bastille bootstrap https://gitlab.com/BastilleBSD-Templates/syslog-ng

Apply the template to the jail. As you can see, we refer to the jail by its name, so choose jail names wisely!

bastille template alcatraz BastilleBSD-Templates/syslog-ng

Finally configure the PF firewall with a bastille command, and redirect the external 514 port to the 514 port of the freshly created jail on the internal network:

bastille rdr alcatraz tcp 514 514

And your second jail

The commands below create a second jail with a slightly different name and IP address. You do not have to bootstrap the syslog-ng template again, just apply it to the jail. And as port 514 on the host is already redirected to the first jail, here we redirect the external 515 port to the 514 port of the jail.

bastille create alcatray 12.2-RELEASE 10.17.89.51
bastille template alcatray BastilleBSD-Templates/syslog-ng
bastille rdr alcatray tcp 515 514

Testing

You can check the logs from both jails with the following command:

tail -f /usr/local/bastille/jails/alcatraz/root/var/log/messages /usr/local/bastille/jails/alcatray/root/var/log/messages

You should see two sets of log messages from the two jails. The -f option means that you do not get back the command prompt, but tail follows the files.

Now open another terminal and from another system use telnet to connect to port 514 and 515 of your FreeBSD host. In both cases, enter some test messages.

czanik@czplaptop:~> telnet 172.16.167.138 515
Trying 172.16.167.138...
Connected to 172.16.167.138.
Escape character is '^]'.
this is a test
^]
telnet> quit
Connection closed.
czanik@czplaptop:~> telnet 172.16.167.138 514
Trying 172.16.167.138...
Connected to 172.16.167.138.
Escape character is '^]'.
this is another test
^]  
telnet> quit
Connection closed.

On the other terminal, you should see log messages about the connection and the test messages as well:

Jan 22 10:03:13 alcatraz syslog-ng[1120]: syslog-ng starting up; version='3.30.1'
Jan 22 11:52:52 alcatraz syslog-ng[1120]: Syslog connection accepted; fd='23', client='AF_INET(172.16.167.1:50212)', local='AF_INET(0.0.0.0:514)'
Jan 22 11:52:56 172.16.167.1 this is another test
Jan 22 11:53:01 alcatraz syslog-ng[1120]: Syslog connection closed; fd='23', client='AF_INET(172.16.167.1:50212)', local='AF_INET(0.0.0.0:514)'

If you have questions or comments related to syslog-ng, do not hesitate to contact us. You can reach us by email or even chat with us. For a list of possibilities, check our GitHub page under the “Community” section at https://github.com/syslog-ng/syslog-ng. On Twitter, I am available as @Pczanik.

Just in case, if you’ve ever wondered how to stop cron from sending empty emails, a quick look at man mail will give you the answer you’re looking for (if you know what you’re searching for):

    -E

    If an outgoing message does not contain any text in its first or only message part, do not send it but discard it silently,
    effectively setting the skipemptybody variable at program startup. This is useful for sending messages from scripts started 
    by cron(8).

I got this after visiting couple of forums, and some threads at stack exchange, however this one nailed it

So all you need to do is, fire up that crontab -e and make your script run every five minutes, without fear of the noise

*/5 * * * * /usr/local/bin/only-talk-if-there-are-errors-script |& mail -E -r $(hostname)@opensuse.org -s "[CRON][monitoring] foo bar $(date  --iso-8601='minutes')"  do-not-spam-me@example.com

Et voilà, ma chérie!

A few tweets ago, openSUSE Mauritius mentioned using YaST to configure the timezone on a machine with just a few clicks.

YaST is a system setup & configuration tool. It was developed by SuSE in the mid-90s. YaST is an acronym for Yet another Setup Tool. It is a handy tool for administrators to install software, configure hardware, connect to a network, etc.

It is written in Ruby. It has both a GUI and is available as a command-line utility through a text-based user interface using ncurses.

To run the ncurses-based YaST version, run sudo yast2 using the terminal. Then, use the tab & arrow keys to navigate and press the enter button to select an item. Menu items and buttons can be triggered by using the Alt + Hightlighted Letter. For example, to quit the screen as in the above screenshot, one would press Alt  + Q.

Software Management

YaST can be used to install software packages. Both the GUI & yast2 command can be used to search for packages and install them. YaST uses the Zypp package management engine which is also used by the zypper command-line tool, to manage software.

YaST Modules

Additional modules can be installed to extend YaST's capabilities. For example, installaling the yast2-docker package provides a module that allows YaST to manage Docker containers. The YaST website provides a list of available modules.

Documentation

SUSE has excellent documentation on YaST. The administration section of the Leap documentation refers to using YaST for various configuration tasks.

Contributing

YaST is developed in the open. Its source code is available on GitHub. The YaST Team has made it easy for volunteers to to find their way to contribute code.

VICE (Versatile Commodore Emulator) es un emulador del popular Commodore 64 que podemos instalar en nuestro sistema GNU/Linux

Mis primeros pinitos fueron con Basic y Cobol hace ya muchos años. Pero la primera vez que recuerdo ver un ordenador fue un Commodore 64 que tenía un primo mío y con el que jugué en alguna ocasión.

La verdad es que no recuerdo gran cosa de aquel ordenador, simplemente su color marrón, un lío de cables para conectarlo a una televisión y la espera para jugar a juegos “con gráficos increíbles”.

No sé qué más se podría hacer con aquel equipo que para la época y para el jugo que se le podía sacar supongo que era bastante caro. Tiempo después compré mi 8086 con MS-Dos.

Ahora podemos recrear ese Commodore 64 y otros modelos gracias al emulador VICE (Versatile Commodore Emulator) publicado bajo una licencia libre, instalándolo en nuestro sistema GNU/Linux, concretamente en openSUSE Tumbleweed.

Para instalar Vice en nuestro openSUSE, deberemos añadir el repositorio Emulators. Para eso abrimos YaST y en el apartado Software → Repositorios de Software

Damos sobre el botón añadir, y especificamos la siguiente url, en el caso de que sea openSUSE Tumbleweed:

• https://download.opensuse.org/repositories/Emulators/openSUSE_Tumbleweed/

Si es otra versión, pincha en este enlace y obtén la url correspondiente de la versión de openSUSE que estés ejecutando:

• https://download.opensuse.org/repositories/Emulators/

Guardamos los cambios, aceptamos la clave con la que van firmados los paquetes y ya podremos instalar vice desde los repositorios.

Una vez finalizada la instalación, ya podremos abrir nuestro lanzador de aplicaciones y ejecutar cualquiera de los emuladores que se nos han instalado. Porque no solo es el Commodore 64, si no que tenemos otras opciones disponibles.

A la hora de escribir este artículo, en Tumbleweed está la versión 3.5 que es la versión más reciente publicada el pasado 24 de diciembre de 2020.

Utilizan librerías GTK, a la hora de mostrar los menús y diferentes opciones que tiene Vice. Lo he instalado hoy mismo y todavía estoy familiarizándome con la cantidad de opciones y posibilidades de configuración que ofrece este emulador de Commodore 64.

Puede ser una buena opción para volver a disfrutar de los juegos de entonces en tu equipo, o para otros proyectos que tengas en mente.

¿Tuviste un Commodore 64 y quieres volver a recordarlo? Este es el emulador perfecto con el que puedes hacerlo. Comparte en los comentarios del blog tus recuerdos de retroinformático.

Enlaces de interés

• https://vice-emu.sourceforge.io/
• https://vice-emu.sourceforge.io/vice_toc.html
• https://www.c64-wiki.com/wiki/C64-Commands

Hoy inicio una serie de artículos que nos van a ir informando de las novedades que nos esperan en la nueva versión del escritorio Plasma de la Comunidad KDE. Así que bienvenidos a «Camino a Plasma 5.21 (I): nuevo lanzador de aplicaciones» donde hablaremos de este importante cambio que se avecina: el nuevo kickoff.

Camino a Plasma 5.21 (I): nuevo lanzador de aplicaciones

El pasado 21 de enero fue lanzado la beta de Plasma 5.21, una versión no apta todavía para el usuario domésticos, y que se libera para ir solucionando errores.

En el artículo del pasado jueves ya hablé por encima de sus novedades pero hoy quiero describir más a fondo una de ellas: el nuevo lanzador de aplicaciones.

Plasma 5.21 nos ofrecerá un nuevo lanzador de aplicaciones que contará con una interfaz de usuario de doble panel, mejoras en la navegación con el teclado y el ratón, mejor accesibilidad y compatibilidad con los idiomas con escritura RTL (es decir, de izquierda a derecha como la árabe, la china, la japonesa o la coreana)

El nuevo lanzador incluye una vista alfabética de «Todas las aplicaciones», una vista de favoritos al estilo de una cuadrícula y acciones de poder visibles por defecto con sus etiquetas.

Por último, pero no por ello menos importante, hemos corregido la mayoría de los errores reportados por los usuarios, garantizando un acceso más fluido a todas tus cosas.

Por otra parte, es destacable que el antiguo lanzador de aplicaciones Kickoff sigue estando disponible en store.kde.org.

Más información: KDE.org

Pruébalo y reporta errores

Todas las tareas dentro del mundo del Software Libre son importantes: desarrollar, traducir, empaquetar, diseñar, promocionar, etc. Pero hay una que se suele pasar por alto y de la que solo nos acordamos cuando las cosas no nos funcionan como debería: buscar errores.

Desde el blog te animo a que tú seas una de las personas responsables del éxito del nuevo lanzamiento de Plasma 5.20 de la Comunidad KDE. Para ello debes participar en la tarea de buscar y reportar errores, algo básico para que los desarrolladores los solucionen para que el despegue del escritorio esté bien pulido. Debéis pensar que en muchas ocasiones los errores existen porque no le han aparecido al grupo de desarrolladores ya que no se han dado las circunstancias para que lo hagan.

Para ello debes instalarte esta beta y comunicar los errores que salgan en bugs.kde.org, tal y como expliqué en su día en esta entrada del blog.