Seguimos con el segundo trimestre del año y siguen las entradas recurrentes de las actualizaciones mensuales de rigor que demuestra que los desarrolladores de KDE no dejan de trabajar en sus librerías. Así que se congratulan en anunciar la actualización de mayo del 2022 de KDE Frameworks. Con esta se llega a la versión 5.94, un suma y sigue de compromiso y constancia que no parece que tenga un final cercano, y que ofrece una novedad, como mínimo, controvertida.

Actualización de mayo del 2022 de KDE Frameworks

A pesar de que para los usuarios corrientes esta noticia sea algo confusa ya que no se trata de realzar una nueva aplicación ni de una nueva gran funcionalidad del escritorio, el desarrollo de KDE Frameworks tiene repercusiones directas en él a medio y largo plazo.

La razón de esta afirmación es que KDE Frameworks es básicamente la base de trabajo de los desarrolladores para realizar sus aplicaciones, es como el papel y las herramientas de dibujo para un artista: cuanto mejor sea el papel y mejores pinceles tenga, la creación de una artista será mejor.

De esta forma, las mejoras en KDE Frameworks facilitan el desarrollo del Software de la Comunidad KDE, haciendo que su funcionamiento, su estabilidad y su integración sea la mejor posible.

El sábado 14 de mayo de 2022 ha sido lanzado KDE Frameworks 5.94, la nueva revisión del entorno de programación sobre el que se asienta Plasma 5, el escritorio GNU/Linux de la Comunidad KDE, y las aplicaciones que se crean con para él.

Más información: KDE

La constancia del equipo de desarrollo de la Comunidad KDE

Hay que recordar que los desarrolladores de KDE decidieron lanzar actualizaciones mensuales de este proyecto y lo están cumpliendo con puntualmente. La idea es ofrecer pocas pero consolidadas novedades, a la vez que se mantiene el proyecto evolucionando y siempre adaptándose al vertiginoso mundo del Software Libre.

Una gran noticia para la Comunidad KDE que demuestra la evolución continua del proyecto que continua ganando prestigio en el mundo de los entornos de trabajo Libres.

¿Qué es KDE Frameworks?

Para los que no lo sepan, KDE Frameworks añade más de 70 librerías a Qt que proporcionan una gran variedad de funcionalidades necesarias y comunes, precisadas por los desarrolladores, testeadas por aplicaciones especí­ficas y publicadas bajo licencias flexibles. Como he comentado, este entorno de programación es la base para el desarrollo tanto de las nuevas aplicaciones KDE y del escritorio Plasma 5.

Aquí podéis encontrar un listado con todos estos frameworks y la serie de artículos que dedico a KDE Frameworks en el blog,

Recuerda que puedes ver una introducción a Frameworks 5.0 en su anuncio de lanzamiento.

La entrada Actualización de mayo del 2022 de KDE Frameworks se publicó primero en KDE Blog.

Dear Tumbleweed users and hackers,

This week you ‘only’ had to update your machine 5 times – for the snapshots 0505, which was for some reason not announced, 0506, 0507, 0509, and 0510 (the last one fresh off the press). 0508 would have been ok, but QA was slightly slower than OBS and so the new snapshot moved to QA before the old one was completely tested. Oops. Anyway, nothing was lost, all good things from that snapshot are still shipped, just a day later.

So, what did those 5 snapshots bring you? The most interesting changes include:

• Mesa 22.0.3
• Mozilla Firefox 100.0
• KDE Plasma 5.24.5
• Meson 0.62
• gpg 2.3.6: Up to five times faster verification of detached signatures
• Linux kernel 5.17.5
• gnome-shell & mutter 42.1 (late arrivals to the GNOME 42.1 update)
• Poppler 22.05.0
• Virtualbox 6.1.34
• GCC 12.1 – with snapshot 0510, gcc12 has become the distro default compiler. All packages have been attempted to be rebuilt. This also means that the recently enabled FullRelRo support (-z now) is enabled across the board. There are currently about 370 build failures reported in openSUSE:Factory (non-ring packages)
• systemd 250.5

This makes for quite an impressive list in just one week. Granted, a few of those things had been in staging areas for a while (days to weeks).

And as you’re already used to, this is no reason to stop. Au contraire: the stagings are already filled again with the following presents:

• KDE Gear 22.04.1
• Attempting to build the distro using FORTIFY_SOURCE=3 instead of FORTIFY_SOURCE=2
• Linux kernel 5.17.7
• GStreamer 1.20.2
• Perl 5.34.1
• Python 3.10 as the default interpreter

Hoy Quiero invitaros a la próxima edición de Ujilliurex 2022, un evento que vuelve a ser presencial como lo fue durante unos años. Ujilliurex es un evento que se celebra en la Universidad Jaume I de Castellón y que tiene como objetivo prncipal la difusión del Software Libre,.

Ujilliurex 2022, vuelve la edición presencial

La conversión de eventos presenciales a virtuales fue una constante este últimos años. Ujilliurex no fue la excepción en su edición de 2020 y del 2021, pero gracias a la aparción de las vacunas y al control que tenemos en este momento del COVID 19 ha pasado a ser presencial en esta edición del 2022.

Este año viene con interesantes ponencias centradas los dás 18 y 19 de mayo y para participar en él es recomendable la inscripción, que podéis realizar en este enlace.

¿Qué es Ujilliurex?

Se trata de un evento que tiene bastante solera en la provincia de Castellón en el que teniendo como protagonista la distribución de la Generalitat Valenciana Lliurex se presentan novedades sobre ésta y sobre otros proyectos libres.

Concretamente sus objetivos fundamentales son:

• Difundir el uso y manejo de las TIC en la distribución LliureX entre la comunidad educativa universitaria
• Promover la coordinación, el intercambio y la discusión de conocimientos y experiencias entre profesores universitarios, especialmente de los departamentos con una mayor implicación tanto en la parte educativa de los futuros docentes (Depto. Educación), como posibles usuarios de Lliurex como herramienta en su especialidad (Depto. de Traducción e Interpretación y Depto. de Estudios Ingleses), con docentes de centros educativos de la comunidad valenciana, especialmente de los departamentos de idiomas y Coordinadores de Tecnologías de la Información (Coordinadores TIC).
• Compartir conocimiento y debatir sobre el contenido de la distribución y la utilización de diversas aplicaciones de la distribución
• Iniciar una serie de contactos entre las entidades organizadoras de la jornada y los asistentes de los diferentes centros y departamentos.

La entrada Ujilliurex 2022, vuelve la edición presencial se publicó primero en KDE Blog.

More than a month after preparing the default compiler for openSUSE Tumbleweed to be switched to GNU Compiler Collection 12, the latest snapshot passed openQA and is making GCC12 the default compiler for the rolling release.

A complete rebuild of snapshot 20220510 is syncing with the mirrors and should soon be a zypper dup away from users changing their rolling release’s default compiler. Being a complete rebuild, it might take some time to sync with the mirrors, but developers can soon have the newest GCC for their development.

“OpenQA did not notice anything weird in this snapshot, the reported errors are generally unchanged to 0509, which is a good sign,” wrote release manager Dominique Leuenberger on the factory mailing list. “Hope you will enjoy the snapshot - now built with GCC12”!

The snapshot the day prior, 20220509, updated git 2.36.1. The minor git update provided a few fixes to include a fix for the git submodule update. Text editor vim took care of a Common Vulnerability and Exposure in its 8.2.4877 version update; the fix of CVE-2022-1381 closes a vulnerability that could cause the crashing software, the modifying of memory and was capable of a possible remote execution. Virtual machine users had five CVE fixes with the virtualbox 6.1.34 update. VM host and guest fixes affected by the 5.14 Linux Kernel were also fixed with the update. However, Tumbleweed users received the update of the 5.17.5 Linux Kernel in the snapshot. The 22.05.0 update of the PDF rendering library poppler had code improvements and added the TSV mode, which is a mode to edit a table like a file. Encrypting and signing data and communications is up to five times faster with verification of detached signatures thanks to the gpg2 2.3.6 update and GnuPG doubled the detached signing speed and the AES256.OCB encryption speed. Other updates in the snapshot included gnome-shell 42.1, libstorage-ng 4.5.10, yast2 4.5.3, autoyast2 4.5.1, and z3 4.8.17.

The 100th version of Mozilla Firefox arrived in snapshot 20220506. The new version brings in Picture-in-Picture that supports video captions on websites that use WebVTT (Web Video Text Track) format. Firefox spell checking now checks spelling in multiple languages. An update of clamav 0.103.6 fixed a CVE for a possible infinite loop vulnerability in the TIFF file parser and another CVE of a possible memory leak in the HTML file parser. KDE users had an update of plasma 5.24.5 in the snapshot. The updated Plasma improved the stability of different source integration with the Discover Flatpak backend. The update also fixed the unlocking of Wayland sessions with KWin. An update of the 3D graphics driver Mesa fixed most of the major drivers in the 22.0.3 release and added the AArch64 architecture. An update of openconnect 8.20 added support for the Array Networks SSL VPN. The openexr package, which is a professional-grade image storage format for the motion picture industry, updated to version 3.1.5; it updated the Continuous Integration workflow matrix and fixed a build failure for one of the Linux distros. Other packages to update in the snapshot were font rendering library freetype2 2.12.1, LibreOffice 7.3.3.2, re2c 3.0 and caching DNS resolver unbound 1.15.0.

La Comunidad KDE es una comunidad responsable y no solo se preocupa en lazar novedades sino que también en mejorarlas. Me complace presentar la primera actualización de KDE Gear 22.04 que apareció hace casi un mes. Más estabilidad para nuestros entornos de trabajo.

Primera actualización de KDE Gear 22.04

A pesar de lo que puedan pensar muchas personas, las aplicaciones no son perfectas. Entre las líneas de código se pueden colar errores de tipografía o que el usuario realice alguna opción que en un principio no estaba prevista por los desarrollador, por poner solo un par de ejemplos de imperfecciones.

Este no es un problema del Software Libre ya que el Software actual funciona de esta manera ya que no se piensa en él como un producto final que se encierra en una caja y se olvida. En la actualidad se sabe que el Software está vivo y sería estúpido ir guardando las mejoras sin dejarlas a disposición del gran público.

Con esto se gana en rapidez y evolución pero puede aumentar el número de errores (por norma general) leves, los cuales son subsanables con pequeñas actualizaciones.

La Comunidad KDE lo tiene claro: grandes lanzamientos cada cuatro meses y actualizaciones mensuales para subsanar errores.

Por ello me congratula compartir con vosotros la primera actualización de KDE Gear 22.04 que nos ofrece más de 120 errores resueltos entre aplicaciones, librerías y widgets, algo que mejora el rendimiento del sistema.

Por poner un par de ejemplos que podemos ver en la lista de cambios de KDE Gear 22.04:

• Dolphin: el panel de la terminal se mantendrá sincronizado con los cambios rápidos de carpeta ahora.
• Kate: arreglado el bloqueo al restaurar la sesión.
• Kalendar: arreglado el botón de «próxima semana» en la vista de la semana.

Más información:KDE Gear 22.04

La entrada Primera actualización de KDE Gear 22.04 se publicó primero en KDE Blog.

PHP 8.1 is available off the shelf in openSUSE Tumbleweed. I will shortly prepare a PHP 8.1 / tumbleweed version of the maintaina Horde containers. These will initially be broken due to some outdated language constructs. As PHP 7.4 will EOL by the end of this year, I decided not to bother with PHP 8.0 and ensure compatibility with PHP 8.1 right away, while staying compatible with PHP 7.4 until end of year. This is not fun. PHP 8.x provides several features which allow for more concise code. I will not be able to use them.
This also means that for the time being I will produce code which you may find more verbose than necessary. While Constructor promotion is mostly about being less verbose, Readonly Properties and Enums kill some of the pro-method arguments in the eternal discussion if getter methods or public properties are more appropriate interfaces. Union Types and Intersection Types allow a flexibility of method interfaces which PHP 7.4 can only emulate. You can get far by type hints for static analysis combined with boilerplate guard code inside a method and dropping type hints all along or using insufficient surrogate interfaces. But it is really not shiny. Maintaining software which shows its age has its tradeoffs.

So I enabled support for up to 16384 columns in Calc by default some time ago, but just getting it to work was not necessarily the end of the work. Making Calc have 16 times more columns means that any operation that works on entire columns is suddenly 16 times slower, or even worse. Similarly this could easily lead to 16x more memory used. So the support not only needs to work, but it also needs to be usable.

It theory adding a number of empty columns to the end of a spreadsheet should not make a difference, but in practice it does. With 1024 columns it is not as necessary to ignore those empty columns as it is with 16k, and a lot of the code dates back to the times when Calc supported even fewer colums (256?), where a being little inefficient here or there didn't show. But now it suddently did.

For example, if you protect or hide all unused columns until the end of the spreadsheet, then hitting the right arrow key on the last accessible cell makes Calc check all cells to the right for whether it's possible to go into them. And checking whether a column is hidden requires searching the list of column information, which is not trivial (it's compacted in order not to waste memory). The barely noticeable cost of this with 1024 columns got large enough to cause noticeable delays. Fortunately the ColHidden() function is smart enough to return the first and last column in the compacted range where the flag is equal, the code doing the cursor navigation just up until now didn't bother using that information, but now it needed to do so.

Another example, and that's quite a large topic, is allocating columns. If most of those new columns are not actually used, then it makes sense to allocate them only when needed, right? That will save memory, and it will make things faster too, because there is no need to check those empty columns. That idea got implemented back when this 16k work was started by others, adding e.g. function GetColumnsRange() that clamped the range to the allocated columns, but the problem is that in practice this is not as simple as that.

One of the issues here is let's say the case of selecting an entire row (clicking the row number to the left of the table does that easily) and then hitting Ctrl+B to make the entire row bold. That should not clamp the column range to the allocated columns, because if I later enter something into cells in those columns, I expect that to be bold. But if Calc allocates all columns for this, maybe I do not intend to enter values anywhere else except the first rows, so allocating all columns will be a waste. The solution to this is having default column data. The ScTable class now, besides having a list of allocated ScColumn's also has a ScColumnData member that stores some data for all not-yet allocated columns. Set the bold flag for all allocated columns and also in the default, and problem solved.

Except then, GetColumnsRange() clamping to allocated columns becomes incorrect, because now it's possible to have set data even beyond allocated columns, such as this bold flag. So I changed GetColumnsRange() to simply return the given range, without any adjustments, and then added the better-named GetAllocatedColumnsRange() for cases where the code knows it wants only the allocated range.

Somewhat similarly to the bold case, merely showing or going to an unallocated column should not allocate it. Otherwise hit e.g. Ctrl+Right one time too many and the cursor going to column XFD would make all columns get allocated. But that causes yet another complication - I am now at an unallocated column and all operations should either detect the column is not allocated and return, or allocate the column if needed. The initial 16k work added CreateColumnIfNotExists() exactly to protect such accesses and allocate the column if needed. It's just that this needed adding to quite many places, and some were still missing it, and others were calling it unnecessarily causing unnecessary column allocations. So I needed to work on these over time. I eventually went as far as change Calc to initially allocate just one column. Since before that Calc used to allocate 64 columns by default, a number of places missing such checks kept working because normally people didn't work with more than 64 columns (and so this 64 default was a reasonable choice at the time, as there was really a lot to check and fix). Now that I have changed this to just one column and fixed all tests, it looks like I've rooted them all out (at least I'm still getting only very few bugreports about something breaking :) ).

Drawing, somewhat unexpectedly, turned out to be a possible performance problem too. There are few ways in which cells to the left can affect drawing of cells to the right. If you enter a too-long text into a cell, it will overflow to the right, into the space of the next cell, or possibly even several cells. So when Calc is drawing let's say a couple of cells around the 10000th column, it actually needs to check also all the 10000 columns before. Somebody back in the day thought about optimizing it, and so before Calc draws cells, function FillInfo() first collects information about all the cells to draw and also all the cells to the left. What possibly(?) was an optimization with 256 or 1024 column is a problem with 16384 columns. Even allocating and clearing all the memory actually had a noticeable performance impact. Sadly, as sometimes happens to be the case with optimizations from the OpenOffice.org times, whoever wrote this made it slow. Function FillInfo() collects all data necessary for drawing a cell into struct CellInfo, and all that info is collected also for all the cells to the left, even though most of it is not used for them. So I had to find out what was necessary and split that out (and provide proper abstraction, because real programmers back in the day used direct data access, right).

 Some of the problems can be even a bit funny. Have you created e.g. a named range called DAY1, NUM1, LOG10 or even DOG10? Well, now you can't, since now those are valid cell addresses, going up to XFD1. So Calc now needed special backwards compatibility code for this.

I expect the real test of this comes when it becomes part of the LibreOffice 7.4 release or Collabora Online. But so far it seems to work rather well.

This work is funded/sponsored by DEVxDAO as part of its mission to support open source and transparent research and development of emerging technologies and frameworks.

A NVIDIA acaba de publicar o módulo do kernel da GPU para o Linux com código aberto sobre a licença GPL/MIT. Após a versão R515, o código fonte está disponível no github https://github.com/NVIDIA/open-gpu-kernel-modules.

Para mim o ano já acabou de notícias boas, pois esta versão é um passo significativo para o mundo de visão computacional no sistema operacional GNU/Linux, assim trazendo uma maior integração com o sistema operacional e com os desenvolvedores da comunidade para contribuírem de volta.

Para provedores de distribuição Linux, os módulos de código aberto aumentam a facilidade de uso, como também melhorar a experiência de distribuição do driver da GPU NVIDIA. A Canonical e a SUSE são capazes de empacotar imediatamente os módulos de kernel abertos com o Ubuntu e SUSE Linux Enterprise Distributions.

Os desenvolvedores terão total transparência do código, isto ajudará a melhorar ainda mais a qualidade e a segurança do driver da GPU NVIDIA. A cada lançamento do driver, a NVIDIA compartilhara o código-fonte no GitHub . Os patches enviados pela comunidade são revisados e, se aprovados, integrados em uma versão futura do driver.

Funcionalidade compatível
A primeira versão dos módulos de kernel da GPU opensource é R515. Será disponibilizado o código-fonte com suas versões completas e empacotadas dos drivers.
Nesta versão de opensource, o suporte para GPUs GeForce e Workstation encontra-se na versão alfa. O modulo do kernel opensource funciona com o mesmo firmware mas devendo obedecer o número da versão.

Opção de instalação
A versão R515 contém versões pré-compiladas do driver de código fechado e dos módulos de kernel de código aberto. O usuário pode fazer a escolha no momento da instalação de qual módulo instalar.A NVIDIA tem trabalhado com Canonical, Red Hat e SUSE na melhor prática de empacotamento, implantação e suporte.

SUSE
“Nós da SUSE estamos animados que a NVIDIA está lançando seu driver de modo kernel de GPU como código aberto. Este é um verdadeiro marco para a comunidade de código aberto e computação acelerada. A SUSE se orgulha de ser a primeira grande distribuição Linux a oferecer esse avanço com o SUSE Linux Enterprise 15 SP4 em junho. Juntos, a NVIDIA e a SUSE potencializam suas necessidades de computação acelerada por GPU em nuvem, data center e borda com uma cadeia de fornecimento de software segura e excelência em suporte.”

Markus Noga, Gerente Geral, Business Critical Linux na SUSE

Mais informações no site original: https://developer.nvidia.com/blog/nvidia-releases-open-source-gpu-kernel-modules/

Es un hecho incuestionable que compartir ideas y datos fue uno de los motores que hizo que la ciencia despegara de la forma que lo hizo hace un par de siglos. Y si queremos seguir mejorando en este aspecto en campos como la medicina este espíritu debe ir más allá para encontrar curas a enfermedades tan duras como el cáncer. Es por ello que la charla «La necesidad de compartir recursos computacionales en Bioinformática» que ha organizado GNU/Linux València es de vital difusión.

La necesidad de compartir recursos computacionales en Bioinformática, próxima charla de GNU/Linux València

Me complace presentaros un nuevo evento de la Asociación sin Ánimo de Lucro GNU/Linux València. que según podemos leer en el anuncio oficial de la Asociación nos hablará de:

La Bioinformática nos ayuda a resolver problemas clínicos o biológicos con abordajes computacionales.
En estos trabajos se emplean grandes volúmenes de información que requieren el uso de repositorios públicos y herramientas de acceso libre, para el análisis de los datos ómicos y la interpretación de sus resultados.  Durante esta sesión, hablaremos de  los principales recursos utilizados en esta área de trabajo e investigación.

Y para ello se contará con Francisco García-García, jefe de la Unidad de Bioinformática y Bioestadística del Centro de Investigación Príncipe Felipe (CIPF) y que nos dará una pincelada sobre este importantísimo aspecto de la medicina.

Es este caso será el 25 de mayo a las 17:30 GTM+1 (huso horario de la España peninsular) y podrá seguirse en en línea utilizando los servicios de Big Blue Button (BBB para los amigos) en este enlace.

Por cierto, para los que no lo sepan con exactitud (como era mi caso) según el National Human Genome Research Institute (NHGRI), la Bioinformática es una subdisciplina de la biología y las ciencias computacionales que se encarga de adquirir, almacenar, analizar y diseminar la información biológica, en gran parte correspondiente a las secuencias de ADN y aminoácidos. La Bioinformática usa programas informáticos que tienen muchas aplicaciones, como por ejemplo: determinar las funciones de genes y proteínas, establecer relaciones evolutivas y predecir la conformación tridimensional de las proteínas.

Más información: GNU/Linux València

La entrada La necesidad de compartir recursos computacionales en Bioinformática, próxima charla de GNU/Linux València se publicó primero en KDE Blog.

openSUSE.Asia Summit は、コントリビューターやファンがアジア全域から参加者が集まる、アジア地域の年次openSUSEカンファレンスです。このイベントでは、openSUSEディストリビューションとそのコミュニティ、個人や企業で使用するアプリケーション、そしてオープンソースの文化について、主に焦点を当てています。

2014年から、openSUSE.Asia Summitはオフラインで開催され、コミュニティの人たちが実際に会う非常に良い機会でした。しかしながら、COVID-19の影響により、2020年のサミットはキャンセルせざるを得ませんでした。そして2021年、サミットはインドチームによりオンラインで開催されました。

openSUSE.Asia Summit 2022はどうなる？

openSUSE.Asia Summit 2022はハイブリッドイベントとなります。

中心となるオンラインサミットと共に、各国/地域でのオフラインイベントをそれぞれ開催します。

アジア全体パート（オンライン + サテライトのオフライン）

• 各アジア地域から参加しやすいよう、4:00 – 6:00 UTC（13:00 – 15:00 JST）を目安に開催します。

• 基調講演、招待講演などを予定しています。

ローカルパート（オンライン/オフライン – 開催場所に依る）

• 各国、各地は、COVID-19の影響や制限を熟慮した上で、オフラインイベントを開催することができます。
• 開催内容はそれぞれの開催場所によって異なります。それぞれの開催場所で、トークセッション、ワークショップ、ミートアップなどが企画されます。

ボランティアにお願いしたいこと

このイベントを実現する為、ボランティアを募集しています。今年はボランティアはどの地域からでも参加できます。

ボランティアにお願いしたいことは以下の通りです。

• アジア地域パートの準備の為のレギュラーオンラインミーティングに参加してください（今は金曜日の 13:00 UTC <22:00 JST>にSlackで行っています。）
• ローカルパートのイベントを企画し、アジア地域パートとスケジュール調整を行ってください
• オンラインカンファレンスを手伝い、ボランティア同士のミーティングのスケジュールを調整してください
• オフラインイベントを開催してください（openSUSE.Asia Summitの実行委員に相談し、必要なサポートを受けることができます）

ボランティアに興味がありましたら、5月30日までに簡単な自己紹介と共にメールを opensuseasia-summit@googlegroups.com までお送りください。

原文はこちら

※訳者コメント※

今年のopenSUSE.Asia Summitは、メインのオンラインイベントと、各地域のローカルイベントのハイブリッド開催となりました。ボランティアスタッフには、オンラインイベント、ローカルイベントの両方（もしくは片方）のお手伝いをして頂ければと思っています。興味を持たれましたら、上記の実行委員連絡先や、ユーザ会の方へご連絡ください。疑問・質問なども遠慮なくお問い合わせください。