Seguimos la serie sobre los cambios en las aplicaciones que han llegado este mes (bueno, en realidad el mes pasado). Una vez comentado las mejoras de Dolphin, Okular y KMail,  sigo con las novedades GWenview  de abril de 2020, el visor de imágenes más simple de la Comunidad KDE, que aún teniendo ese título no se queda corto en cuanto a funcionalidades añadidas.

Las novedades de Gwenview de abril de 2020

Creo que una de las aplicaciones que un escritorio debe ofrece a sus usuarios es un buen y rápido visor de imágenes. La Comunidad KDE ofrece un buen número de ellas, teniendo incluso un visor integrada en Dolphin, pero la que más utilizo, sin duda alguna, es Gwenview.

Esta pequeña pero potente aplicación abre de forma rápida y eficaz cualquier imagen de nuestro sistema, al tiempo que nos permite realizar acciones simples como el redimensionado o el recorte de imágenes de forma muy sencilla. Además, ofrece opciones de carrusel de imágenes, de visualización de varias imágenes de forma simultanea, de conexión con otras aplicaciones, reducción de ojos rojos, servicio de rotación o inversión de imágenes, integración con la barra de lugares de KDE, comapartición directa de imágenes con otros servicios como Telegram o Nextcloud, etc. Y eso que es la menor de la aplicaciones de imágenes de KDE, por debajo se ShowFoto o DigiKam. No está nada mal

De esta forma, la nueva versión de Gwenview de abril de 2020 ofrece pocas pero importantes novedades:

• Se ha solucionado el problema de bloqueo durante el inicio cuando el portapapeles del sistema contiene texto de KDE Connect, la aplicación que integra tu móvil con tu escritorio Plasma.
• Se ha corregido el acceso a lugares remotos (mediante Samba, por ejemplo) para importar o exportar fotos.

Un par de arreglos que hacen que Gwenview funcione un poco mejor.

Más información: KDE

Last week I gave a talk at the first virtual adhoc.community meetup on the history of task isolation on Linux (slides, video). It was a quick 15-minute presentation, and I think it went well, but I really wanted to include some details of how you actually configure a modern Linux machine to run a workload without interruption. That’s kinda difficult to do in 15 minutes.

So that’s what this post is about.

I’m not going to cover how to use the latest task isolation mode patches because they’re still under discussion on the linux-kernel mailing list. Instead, I’m just going to talk about how to reduce OS jitter by isolating tasks using Linux v4.17+.

First, as the below chart shows, you really do need a recent Linux kernel if you’re going to run an isolated workload because years of work have gone into making the kernel leave your tasks alone when you ask.

Linux task isolation features throughout the years

Each of these features is incremental and builds on top of the previous ones to quiesce a different part of the kernel. You need to use all of them.

Modern Linux does a pretty good job out of the box of allowing userspace tasks to run continuously once you pull the right options. Here’s my kernel command-line for isolating CPU 47:

isolcpus=nohz,domain,47 nohz_full=47 tsc=reliable mce=off

The first option, isolcpus, removes every CPU in the list from the scheduler’s domains, meaning that the kernel will not to do things like run the load balancer for them, and it also disables the scheduler tick (that’s what the nohz flag is for). nohz_full= disables the tick (yes, there’s some overlap of the in-kernel flags which means you need both of these options) as well as offloading RCU callbacks and other miscellaneous items.

On my machine, I needed the last two options to disable some additional timers and prevent them from firing while my task was running.

Once you’ve booted with these parameters (substitue your desired CPU list for 47) you’ll need to setup a cpuset cgroup to run your task in and make sure that no other tasks accidentally run on your dedicated CPUs. cset is definitely my favourite tool for doing this because it makes it so easy:

$ cset shield --kthread=on --cpu 47
cset: --> activating shielding:
cset: moving 34 tasks from root into system cpuset...
[==================================================]%
cset: kthread shield activated, moving 79 tasks into system cpuset...
[==================================================]%
cset: **> 56 tasks are not movable, impossible to move
cset: "system" cpuset of CPUSPEC(0-46) with 57 tasks running
cset: "user" cpuset of CPUSPEC(47) with 0 tasks running

Now all you need to do is add the PID of your task to the new user cpuset and you’re good to go.

Verifying your workload is isolated

Of course, it’s all well and good me saying that these options isolate your tasks, but how can you know for sure? Fortunately, Linux’s tracing facilities make this super simple to verify and you can use ftrace to calculate when your workload is running in userspace by watching for when it’s not inside the kernel – in other words, by watching for when your workload returns from a system call, page fault, exception, or interrupt.

Say we want to run the following super-sophisticated workload without it entering the kernel:

while :; do :; done

Here’s a sequence of steps – assuming you’ve already setup the user cpuset using cset – that enables ftrace, runs the workload for 30 seconds, and then dumps the kernel trace to a trace.txt

# Stop irqbalanced and remove CPU from IRQ affinity masks
systemctl stop irqbalance.service
for i in /proc/irq/*/smp_affinity; do
        bits=$(cat $i | sed -e 's/,//')
        not_bits=$(echo $((((16#$bits) & ~(1<<47)))) | \
		xargs printf %0.2x'\n' | \
		sed ':a;s/\B[0-9a-f]\{8\}\>/,&/;ta')
        echo $not_bits > $i
done

export tracing_dir="/sys/kernel/debug/tracing"

# Remove -rt task runtime limit
echo -1 > /proc/sys/kernel/sched_rt_runtime_us

# increase buffer size to 100MB to avoid dropped events
echo 100000 > ${tracing_dir}/per_cpu/cpu${cpu}/buffer_size_kb

# Set tracing cpumask to trace just CPU 47
echo 8000,00000000 > ${tracing_dir}/tracing_cpumask

echo function > ${tracing_dir}/current_tracer

echo 1 > ${tracing_dir}/tracing_on
timeout 30 cset shield --exec -- chrt -f 99 bash -c 'while :; do :; done'
echo 0 > ${tracing_dir}/tracing_on

cat ${tracing_dir}/per_cpu/cpu${cpu}/trace > trace.txt
# clear trace buffer
echo > ${tracing_dir}/trace

The contents of your trace.txt file should look something like this:

# tracer: function
#
# entries-in-buffer/entries-written: 102440/102440   #P:48
#
#                              _-----=> irqs-off
#                             / _----=> need-resched
#                            | / _---=> hardirq/softirq
#                            || / _--=> preempt-depth
#                            ||| /     delay
#           TASK-PID   CPU#  ||||    TIMESTAMP  FUNCTION
#              | |       |   ||||       |         |
          <idle>-0     [047] dN..   177.931485: sched_idle_set_state <-cpuidle_enter_state
          <idle>-0     [047] .N..   177.931487: cpuidle_reflect <-do_idle
          <idle>-0     [047] .N..   177.931487: menu_reflect <-do_idle
          <idle>-0     [047] .N..   177.931488: tick_nohz_idle_got_tick <-menu_reflect
          <idle>-0     [047] .N..   177.931488: rcu_idle_exit <-do_idle
          <idle>-0     [047] dN..   177.931488: rcu_eqs_exit.constprop.71 <-rcu_idle_exit
          <idle>-0     [047] dN..   177.931489: rcu_dynticks_eqs_exit <-rcu_eqs_exit.constprop.71

You want to make sure that the you didn’t lose any events by checking that the entries-in-buffer/entries-written fields have the same values. If they’re not the same you can further increase the buffer size by writing to tracing/per_cpu/<cpu>/buffer_size_kb.

The key part of the trace file is the finish_task_switch tracepoint which tells you when a context switch completed. You can use this tracepoint to find when your bash process starts running and when it finishes – hopefully after 30 seconds has elapsed – with a bit of awk magic:

$ awk '/: finish_task_switch / {
        # Do not start counting until we see the bash task for the first time
        comm = substr($1, 0, index($1, "-")-1)
        if (comm == "bash") {
                counting = 1;
        }
}

{
        if (counting) {
                usecs = $4
                gsub(/\./,"",usecs)
                gsub(/\:/,"",usecs)
                msecs = usecs / 1000

                delta = msecs - last
                if (last && (delta > runtime)) {
                        runtime = delta
                }
                last = msecs
        }
}


BEGIN { runtime = -1 }

END { printf "Max uninterrupted exec: %.2fms\n", runtime }' < trace.txt
Max uninterrupted exec: 29877.67ms

I’ve successfully used this technique to verify that I can run a bash busy-loop for an hour without entering the kernel.

The openSUSE Summit 2020 kicked off yesterday. Like many others this summit was a virtual one too. It ran on a platform managed by openSUSE fan and user P. Fitzgerald.

I was busy with work stuff and couldn't watch the presentations live. I hopped on and off on the platform. I didn't want to miss Richard's presentation about MicroOS yet I missed it. Luckily he was quick to record his session and upload it on YouTube. I got a chance to watch it afterwards. Surely, all other presentations will be available on openSUSE TV soon and I'll be able to catch-up.

If you didn't rush to watch Richard's presentation on YouTube right-away, here are a few hints that may encourage you to do so.

openSUSE container registry

I'm not going to tell you what MicroOS is, you got to watch the video to learn about that, but did you know that the openSUSE project had a containers registry available publicly at https://registry.opensuse.org ? You can add it to the /etc/containers/registries.conf file and Podman can now search & pull containers from it.

Tiny openSUSE containers

When deploying your application in a container you always look for the fattest container, right? Of course, no!

ish@coffee-bar:~$ podman pull registry.opensuse.org/opensuse/busybox
Trying to pull registry.opensuse.org/opensuse/busybox...
Getting image source signatures
Checking if image destination supports signatures
Copying blob b6fc9a391c78 [====>---------------------------------] 515.9KiB / 3.8MiB

ish@coffee-bar:~$ podman images
REPOSITORY                               TAG      IMAGE ID       CREATED        SIZE
registry.opensuse.org/opensuse/busybox   latest   c19f82628d9f   44 hours ago   9.4 MB

openSUSE offers a small (Tumbleweed) busybox container that is just under 10 MB. Mini but mighty! 💪

How to keep a system patched & running?

If it's running you don't want to touch it, but, systems need security updates. Someone has to do the dirty-job. Who? Can a system update itself without breaking the applications that are running?

Health checks during boot-up

Have you ever had a system that fails to boot after an update? I had. MicroOS checks for errors during the boot phase and if a snapshot is faulty the system then boots up with the last known working snapshot. MicroOS does so without any manual intervention, so, automatic reboots are safe.  😀 🎉 🎊

Debugging your MicroOS container host

MicroOS is a lightweight system that doesn't come bundle with debugging tools (for obvious reasons). Once in a while though you need to troubleshoot things like network issues. There you go, you can spin a toolbox container and inspect the network interface on the host. 🛠️

I hope these are enough to convince you to watch the presentation and that openSUSE MicroOS becomes part of your servers infrastructure. 🐧

Tumbleweed es una distribución “Rolling Release” de actualización contínua. Aquí puedes estar al tanto de las últimas novedades.

openSUSE Tumbleweed es la versión “rolling release” o de actualización continua de la distribución de GNU/Linux openSUSE.

Hagamos un repaso a las novedades que han llegado hasta los repositorios estas semanas.

El anuncio original lo puedes leer en el blog de Dominique Leuenberger, publicado bajo licencia CC-by-sa, en este enlace:

• http://dominique.leuenberger.net/blog/2020/05/opensuse-tumbleweed-review-of-the-week-2020-18/

Esta semana se han publicado menos snapshots, pero las que se han publicado han venido con cambios importantes y muy esperados.

Por ejemplo, se ha publicado GNOME 3.36.1 que también incluye un cambio menor en la fuente Cantarell. Y como el test automático openQA compara capturas de pantalla con unas de referencia, un cambio en una fuente tipográfica se traduce en un montón de desjustes que son necesarios confirmarlos.

Lo que lleva algo de tiempo, lo que ha resultado en que se han publicado solo 3 nuevas snapshots (0425, 0427 y 0428).

Que entre otros cambios, podemos destacar estos como los más importantes

• GNOME 3.36.1
• KDE Applications 20.04
• Linux kernel 5.6.6
• Mesa 20.0.5
• openSSL 1.1.1g

La lista parece corta pero GNOME y KDE Applications implican un buen número de aplicaciones actualizadas.

Y como es normal, hay muchas más cosas esperando para próximas actualizaciones, por ejemplo:

• Cambio de Ruby 2.6 a 2.7
• Linux kernel 5.6.8
• Qt 5.15.0
• TeXLive 2020
• Guile 3.0.2
• GCC 10 como compilador predeterminado

Si quieres estar a la última con software actualizado y probado utiliza openSUSE Tumbleweed la opción rolling release de la distribución de GNU/Linux openSUSE.

Mantente actualizado y ya sabes: Have a lot of fun!!

Enlaces de interés

• • • ¿Por qué deberías utilizar openSUSE Tumbleweed?
    • zypper dup en Tumbleweed hace todo el trabajo al actualizar
    • ¿Cual es el mejor comando para actualizar Tumbleweed?
    • Comprueba la valoración de las “snapshots” de Tumbleweed
    • ¿Qué es el test openQA?
    • http://download.opensuse.org/tumbleweed/iso/
    • https://es.opensuse.org/Portal:Tumbleweed

——————————–

Sigue la serie sobre los cambios en las aplicaciones que han llegado este mes (bueno en verdad técnicamente fue el mes pasado, pero ya me entendéis). Una vez comentado las mejoras de Dolphin y Okular,  sigo con las novedades KMail de abril de 2020, el gestor de correos electrónicos de la Comunidad KDE. Hay que decir que no ofrece muchas mejoras, pero así aprovecho para hablar un poco de esta otra Killer App de KDE.

Las novedades KMail de abril de 2020

Debo confesar que tengo una relación de amor/odio con KMail, el gestor de correo electrónico. Amor porque, al igual que con Okular, fue una de las que me conquistó al iniciarme en el mundo del Software Libre. Odio porque su funcionamiento ha sido irregular a lo largo del tiempo, en muchas ocasiones por culpa de indexeación de correos).

En la actualidad la estoy utilizando sin problemas en mi portátil y la utilizo para tener sincronizados mis correos de mi servidor y  me encanta por muchos motivos: integración con Plasma (concretamente con Krunner), su vista de mensajes por hilos, su rapidez cuando se trabajan de forma local, sus integración con las demás aplicaciones de la suite Kontact (KOrganizer, KAdressBook, etc.)

Tras un periodo algo árido, la aplicación ha vuelto a encontrar el amor que loe faltaba y vuelve a evolucionar de forma positiva, como hemos podido comprobar el mes pasado.

De esta forma, la nueva versión de Okular de abril de 2020 son varios, y lo mejor es realizar una breve lista:

• Se ha añadido la posibilidad de exportar en formato pdf los mensajes de correo electrónico de forma sencilla.
• Mejorado la visualización de los mensajes formateados con Markdown,
• Mejoras varias en seguridad, como que ahora KMail muestra una advertencia cuando el compositor de mensajes se abre al pulsar un enlace que le solicita adjuntar un archivo.

Más información: KDE

El desarrollo del escritorio Xfce se realizará en una instancia propia de GitLab

Git es sin duda la herramienta principal para muchos proyectos de software libre (y privativo también) y muchos proyectos prefieren tener esos repositorio de Git bajo control de su propio proyecto y no utilizando opciones de terceros.

Es por eso que cada vez más proyectos ponen en marcha instancias propias de Git en sus propios servidores para alojar sus proyectos y no utilizar opciones como por ejemplo GitHub.

Es el caso de la comunidad Xfce, que acaba de anunciar que el desarrollo de sus aplicaciones se realizará a partir de ahora en una instancia propia de GitLab.

Para los usuarios finales o las propias distribuciones, nada cambia. Seguirán disfrutando como hasta ahora de su escritorio preferido.

El cambio lo notarán aquellas personas que participan en el desarrollo y mantenimiento de paquetes de software.También tienen planeado migrar otras herramientas como Bugzilla… pero por partes.

Así que ya sabes, si participabas en el desarrollo de alguna de las grandes herramientas de este escritorio ahora encontrarás ese software en su propia instancia de GitLab.

Enlaces de interés

• Anuncio oficial
• Anuncio en las listas de correo
• Instancia de GitLab de Xfce

Salut,

Les responsables de SUSE Linux Enterprise reconnaissent les besoins de la communauté openSUSE pour une collaboration meilleure et transparente avec SUSE. La dynamique qui nous anime maintenant nous incite à réfléchir et à être différents.

La symbiose entre SUSE Linux Enterprise et openSUSE est réelle, nous partageons bien plus que du code, nous utilisons les mêmes outils comme Open Build Service, openQA, des processus de maintenance similaires, des personnes (Release Managers, contributeurs, etc.) et bien plus encore.

Nous avons peut-être été un peu discrets dans le passé, mais cela ne signifie pas que nous n'avons pas avancé ; au fil des ans, nous avons créé davantage de liens comme Package Hub, favorisé notre contribution avec la politique SLE Factory First pour les employés de SUSE et nos partenaires technologiques, être plus accessibles pendant notre phase de développement avec le programme de bêta publique de SLE, pour ne citer que quelques exemples.

Mais nous avons maintenant une dynamique à accélérer, notamment en ce qui concerne la transparence sur nos défauts et nos demandes de fonctionnalités au profit de la distribution et de la communauté openSUSE. Nous vous avons donc entendus, et aujourd'hui nous voulons clarifier et améliorer les processus, pour nous tous, et donner quelques éléments sur les discussions internes de SUSE concernant la suppression des "portes fermées".

Sans plus attendre, voici nos actions :

• Rafraîchir et créer des pages wiki openSUSE pour la clarification des processus
  • Luboš Kocman a déjà commencé à documenter le processus mis en place pour récupérer les demandes de fonctionnalités de SLE et son projet est de présenter un processus réellement amélioré pour les contributeurs externes d'ici octobre ou plus tôt.
  • Nous allons également revoir et améliorer “comment contribuer, phase de développement openSUSE Leap” afin de clarifier et formaliser les informations qui existaient depuis des années, mais qui n'étaient pas documentées.
  • Créer une nouvelle page sur notre "Politique SLE Factory First", et les sujets potentiels de maintenance et d'assurance qualité.
• Parler plus ouvertement de la relation entre openSUSE et SLE,
  • "Stratégie actuelle et future pour openSUSE Leap" et "Jump ! État actuel et changements à venir" pendant le sommet virtuel d'openSUSE.
  • Sujet à venir dans le billet de blog "How SUSE Builds its Enterprise Linux Distribution".(«Comment SUSE construit sa distribution Linux pour l'entreprise»)
  • Un exposé sur "la relation entre SLE et openSUSE" lors du sommet virtuel SUSECon
• Trouvez la bonne façon pour consulter notre site bugzilla.suse.com
  • SUSE s'engage pleinement à protéger les données privées de ses clients et partenaires hébergées dans notre outil comme Bugzilla. Ils nous font confiance pour leurs données hautement sensibles, c'est pourquoi nous abordons ce sujet avec beaucoup de sérieux. Toutefois, grâce au transfert complet des instances de Bugzilla de MicroFocus à SUSE, nous avons désormais le contrôle total de Bugzilla et pouvons donc discuter de la manière de modifier nos processus en interne pour combiner confidentialité et ouverture des données.
  • Un groupe a été formé (Vincent Untz, Anna...

Dear Tumbleweed users and hackers,

This week, we released a few snapshots less. But we released GNOME 3.36.1 which also contained a minor font change for cantarell. And as openQA compares reference screen shots, a font change results in a lot of mismatches, that need to be confirmed. This takes easily a bit of time. This resulted in three snapshots being published (0425, 0427 and 0428), bringing those changes:

• GNOME 3.36.1
• KDE Applications 20.04
• Linux kernel 5.6.6
• Mesa 20.0.5
• openSSL 1.1.1g

The list looks short, but GNOME and KDE Applications both consist of numerous applications. So all in all the snapshots were actually rather large.

And as usual, that’s not the end: things currently being worked on in Staging projects:

• Switch from Ruby 2.6 to 2.7 (some preparations/fixes are coming by regularly)
• Linux kernel 5.6.8
• RPM change: %{_libexecdir} is being changed to /usr/libexec. This exposes quite a lot of packages that abuse %{_libexecdir} and fail to build
• Qt 5.15.0 (currently beta4 is staged)
• TeXLive 2020
• Guile 3.0.2: breaks gnutls’ test suite on i586
• GCC 10 as the default compiler

Este 1 y 2 de mayo de 2020 se celebrará una reunión virtual con charlas de la comunidad global de openSUSE.

Por motivo de esta pandemia, hemos tenido que estar confinados, entregados a diversas aficiones, pero todas dentro de casa. Parece que eso va a pasar, pero de momento nuestra realidad ha cambiado.

Se han cancelado las clases, algunos trabajos, se han suspendido conciertos, no podemos asistir al cine ni teatro. Los eventos sociales que pueden juntarnos y expandir la pandemia se han visto recortados.

Pero somos seres sociales (algunos más que otros) por tanto en esta época digital hemos sustituido esos actos presenciales por opciones virtuales mediante video conferencias.

Ese es el caso de la conferencia anual que celebra la comunidad openSUSE llamada openSUSE Summit, que este año se celebrará de manera virtual mediante video conferencias este próximo 1 y 2 de mayo de 2020.

Por un lado, es una contrariedad, porque coarta las relaciones personales, pero por otro nos permite a algunas personas que no podíamos asistir, el poder hacerlo cómodamente desde el sofá de nuestras casas junto con nuestras gatas.

Si tu también estás interesado o interesada en asistir a estas charlas de la comunidad de openSUSE que se celebrarán en inglés, deberás registrarte en el siguiente enlace:

• https://opensuse.reqmagic.com

Se recomienda el uso del navegador Chrome o Chromium. Si quieres consultar los horarios y las charlas que se darán puedes hacerlo en este enlace:

• https://events.opensuse.org/conferences/oSvirtsmt/schedule

Ponentes desde Asia a Europa miembros de la comunidad de openSUSE darán charlas técnicas enfocadas en diversos aspectos de tecnologías de GNU/Linux y en especial openSUSE.

Hay un canal público de Telegram relacionado con esta conferencia:

• t.me/oSVS2020

Y si no tienes Telegram, también puedes aportar tus opiniones o interactuar con un servicio pad en el siguiente enlace:

• https://etherpad.opensuse.org/p/openSUSEVirtualSummitfeedback

Saca tu mejor camiseta Geek, pon a enfriar cerveza o la bebida que quieras, y prepárate para hackear con esta sesión geek de charlas a cargo de la comunidad de openSUSE.

Happy hacking y have a lot of fun!