Este fin de semana, el del 11 al 12 de diciembre, tienes una cita con u macroevento: 24H24L. Y a pocos días de su emisión, es el momento de darle un poco más de promoción en el blog y divulgar la programación definitiva de 24H24L 2021: 24 horas de tecnología y Software Libre.

Programación definitiva de 24H24L 2021 del 11 y 12 de diciembre

El año pasado, la edición 2020 de 24H24L se dedicó a crear audios para aquellos nuevos usuarios de la Comunidad Linuxera. Dado que estos episodios han quedado grabados para la posteridad (aquí tenéis el rss para ponerlos en vuestro reproductor de audio favorito) , parece ser que José Jiménez ha decidido dar otro aire a esta edición del 2021 y darle un toque más técnico, dedicando casi todo el tiempo a programación y desarrollo de aplicaciones, que es algo básico en el Software Libre.

De esta forma tenemos una parte dedicada a la gestión equipos de programadores, otra a la web, otra dedicada a múltiples lenguajes de programación y una miscelánea donde aparecen tema de diseño o de Big Data.

Un menú más que apetecible que podéis ver desglosado en la imagen inferior, haz click para descargar el pdf, del programa que se emitirá el 11 y 12 de diciembre en esta segunda y definitiva versión.

Además, para esta edición han estrenado una magnífica web, cortesía de Javier Archeni, que os invito a visitar y admirar.

Y para finalizar, os recuerdo el objetivo de 24H24L en boca de sus creadores:

«Dedicamos 24 charlas de una hora de duración en una edición dedicada a la programación y al mundo del desarrollo. Una jornada para compartir con profesionales y entusiastas del software libre en español.»

Hoy me complace compartir con todos vosotros el evento que se va a celebrar el próximo lunes 13 de diciembre. Se trata de la presentación de campaña ¿Dinero público? ¡Código público! en español, es decir, con todo la información en el idioma de Cervantes, ideal para presentar a nuestros políticos.

Presentación de campaña ¿Dinero público? ¡Código público!… ¡ahora en Español!

Hay un concepto que me encanta y es el de «Piensa en global, actúa en local» que viene a decir que pensemos a lo grande pero que hagamos cosas que podamos hacer, que normalmente son pequeñas.

De esta forma, aunque una campaña internacional nos de mucha grandilocuencia, a la hora de actuar debemos pensar en hacerlo de la forma más próxima a tus posibilidades.

Es por ello que es interesante que todas las campañas de concienciación estén lo más localizadas que sea posibles, y la primera forma de localización es el idioma.

Este, creo, es el pensamiento de la Free Software Foundation (FSF) que lleva mucho tiempo con la iniciativa «Public Money? Public Code!» pero que no ha sido hasta ahora cuando lo lanza en español.

Y para que no pase desapercibido entre la maraña de noticias se ha decidido que esta lanzamiento este ligado a un pequeño evento en forma de presentación virtual donde intervendrán destacadas personalidades como Luis Falcón, fundador de GNUHealth, Ricardo Muñoz de Lliurex, Alexis Puente Montiel de Pica Pica HackLab, Ana Albalat Martínez y Francesc Busquets en representación de Linkat, y Aleix Pol Gonzalez, presidente de KDE.

Así que, como podemos leer en el anuncio oficial de FSF:

Gracias al apoyo y al duro trabajo de nuestros voluntarios, nuestro folleto ¿Dinero público? Código público! ya está disponible en Español. En este evento exploraremos las buenas prácticas ya implementadas, pero también los retos que tenemos por delante para modernizar la infraestructura digital pública con código público en España. El evento se llevará a cabo en Español.

Los datos del evento son lo siguientes:

Fecha: lunes 13 de diciembre de 2021

Horario: de 18:00 a 19:30 CET.

Requere inscripción: Si, en este enlace. Una vez registrado se compartirá un enlace a la instancia de BBB.

No te lo pienses, regístrate y asiste a la presentación… yo ya lo he hecho.

Parece que hay que adaptarse o morir, la palabra escrita está demodé (incluso esta palabra está obsoleta)

Ya hace tiempo escribí en el blog que entre mi lista de feeds que consulto todos los días, está la tira de humor de Linux Hispano. Y fue una sorpresa en aquella ocasión ver que incluían un enlace a mi blog. (gracias de nuevo).

En esta ocasión, quiero escribir un pequeño artículo (reflexión personal), porque en la tira de Danigm para Linux Hispano que encabeza el artículo y que podéis visitar en este enlace, me he visto reflejado.

No soy un millenial, pertenezco a la (jodida) generación X y con mis recién estrenados 46 años, veo que me he convertido en un boomer al seguir manteniendo un blog en el que escribo y encima sobre algo tan minoritario (¿de verdad?) como es GNU/Linux y/o el software libre.

Sigo juntando palabras para escribir sobre noticias, tutoriales, artículos, etc sobre esta pasión que se plasmó de manera incierta en un mes de abril de 2011.

He ido aprendiendo, tanto nuevas cosas técnicas, como a escribir, y la evolución de ambas se puede seguir en este blog. Creo que ha sido una evolución hacia mejor, pero supongo que hay opiniones distintas al otro lado del cable de internet (puedes compartirlas en los comentarios).

Veo cómo todo ha evolucionado a velocidad de vértigo en esto de la tecnología. GNU/Linux (la principal fuente que llena este blog) ha mejorado en gran medida. Ahora es más sencillo instalarse una distribución de GNU/Linux y echarla a funcionar.

Ahora es más sencillo lidiar con diferentes problemas derivados de la incompatibilidad con hardware (problemas cada vez más escasos, pero que se siguen dando con según qué fabricantes).

Pero como ilustra la imagen de Linux Hispano, esto de escribir un blog, es algo antiguo, algo pasado de moda. Ahora hay que hacer un video tutorial, monetizar tus vídeos, crear una cuenta en Twitter (¿o eso también es del pasado?), subir tus vídeos en TikTok y un storie en Instagram, si quieres estar en la cresta de la hola. Espera que pronto habrá algo nuevo que hacer para estar al día!

En un par de libros que he estado leyendo estos días, se hacía referencia a un proto-internet donde primaba la descentralización. Donde primaba el poder compartir.

Hoy esa descentralización se ha esfumado (en gran parte). Son 4 empresas (casi literalmete) las que monopolizan internet, sus contenidos y su distribución.

Pero lo que quiero decir, es que hemos dejado de lado la palabra escrita en texto plano, que podremos volver a leer una y otra vez en detrimento por opciones más visuales, que rápidamente se perderán en un maremágnum de contenido de consumo rápido.

No consumo podcats, pero a día de hoy creo que es el soporte más utilizado, junto con el vídeo. Pero no puede valer para todo (o eso creo). Estará bien como consumo de noticias, contenido cultural de diversa índole, etc, pero no como consulta. Para eso, quiero algo escrito donde poder consultar aquello que quiero o que me valga y pueda adaptar.

Me resisto a formar parte de esas redes centralizadas, de esos nuevos contenidos efímeros. No por cabezonería, si no como simple planteamiento personal. Quizás esté equivocado, pero en todo caso habré hecho lo que quería.

El blog (como pasa en otros muchos casos) lo empecé como libreta de anotaciones personales, con el tiempo fue ampliando la temática sin perder esa naturaleza de recopilación de apuntes de futuras viejas preguntas.

Quizás el blog se quede en un pequeño reducto para nostálgicos boomers como yo y como tu, lector o lectora que lees este artículo hasta las últimas líneas… en búsqueda de algo que aprender.

Nueva edición la revista digital SoloLinux, la cual llega con un contenido muy especial, ya que para poder completar este pasado y odioso mes (por el fallecimiento de a Sergio G. B., uno de sus creadores, editores y mantenedores) Adrián ha llamado a la colaboración de la blogosfera, y como no podía ser de otra forma, ha acudido (y evidentemente KDEBlog no podía ser una excepción) . Además este SoloLinux de diciembre de 2021 también ofrece la novedad de que se publica a mes vencido no a mes en curso, de ahí el cambio de mes.

SoloLinux de diciembre de 2021, edición comunitaria

La introducción es repetitiva, así que os dirijo a la de hace unos meses. Os dejo con las palabras de la editorial:

«Estos últimos meses han sido diferentes para todos nosotros, gracias por
todos comentarios de apoyo recibidos por el grupo de Telegram, Instagram, y diferentes redes sociales.
Hace hoy 33 números atrás que nació la revista, gracias a Sergio por entender mi idea, llegamos hoy a este numero. El numero 33 de la Revista SoloLinux. Podría ser distinto pero ahora tenemos un mar de dudas de como va a continuar todo esto.
Este numero ha sido posible a la gran ayuda de diferentes
comunidades de Linux (denovatoanovato, kdeblog, latinlinux, drivemeca, espaciotecnologico, Quirinux GNU/LINUX), que nos han cedido varios artículos para
poder homenajear el gran trabajo que realizo Sergio para la comunidad Linux en general. Si quieres participar en los siguientes numeros de SOLOLINUX,
ponte en contacto con adriansololinux@gmail.com
Gracias a TOD@S«

De tal forma, que en esta ocasión el contenido está dividido por editores:

SOLOLINUX:

• Como instalar Debian 11 de forma sencilla
• Instalar Astra Linux – La distribución rusa perfecta

KDEBLOG:

• ¿Qué es KDE? Respuesta corta, larga y la verdad
• 25 aniversario de KDE ¡Felicidades a toda la Comunidad!

ESPACIO TECNOLOGICO

• Multiplexor de Terminal en Linux
• Bloquear Escaneo de Puertos en Linux

LATIN LINUX

• MX-21 Wildflower ¿Una distribución Linux genial?
• LliureX 21

QUIRINUX

• Quirinux GNU/Linux, la distro del cine animado

DE NOVATO A NOVATO

• Diferencias entre terminal, consola y shell
• Gestor de paquetes aptitud

CARRERA LINUX

• Puntos Ciegos – Coaching IT
• Asterisk. Funcionalidad de una central telefonica
• ipfwadm->ipchains->iptables

DRIVEMECA

• Linux logs o como saber que esta haciendo tu distro GNU Linux

OPINIÓN PERSONAL LECTORES

• La Opinión de Juan Manuel Sánchez
• La Opinión de Christian Rodriguez Baeza

La revista puede ser descargada o simplemente visualizarla en línea, ya que se cuelga en diferente servicios como Calameo. A continuación os dejo los enlaces de descarga y visualización directa de todos los números publicados hasta la fecha.

Además, recordar que desde hace muchos meses se ha abierto el canal oficial sololinux.es de Telegram: https://t.me/sololinux_es

Evidentemente, este proyecto no se centra en exclusivo a los contenidos de su web y está abierto a colaboraciones de todo tipo. De esta forma si estas interesado en insertar publicidad en nuestra revista, o quieres que publiquemos algún articulo que hayas escrito tu mismo, puedes contactar con «Adrián» por correo electrónico: adrian @ sololinux. com

Muchos ánimos en este proyecto que ya parecer estar consolidad y que que facilita la difusión del Software Libre de una forma que ya no es tan habitual en estos tiempos pero que es igual de válida y necesaria en algunas ocasiones.

O openSUSE Tumbleweed agora está disponível com um kernel atualizado do Linux (5.15.5) como uma imagem Amazon (AMI). O kernel 5.15 introduz diversos recursos e melhorias de performance, incluindo otimizações para processadores Intel Ice Lake, melhororia no NTFSe nas placas de vídeo Intel Arc para potencializar as instâncias do Amazon EC2 de última geração. A aplicação de patch do kernel 5.15 que introduzi em nome da iniciativa openSUSE Innovators é compatível para arquiteturas de x86-64 .

Para mais detalhes adicionais ou informações sobre atualização, entre em contato com Innovators for openSUSE https://aws.amazon.com/marketplace/pp/B086VDH9KM.

Os recursos mencionados são alguns mas não são os únicos! Outros recursos são listados no anúncio oficial publicado por Linus Torvalds.

Abaixo também alguns pacotes alterados neste release:

• ritchie cli (2.11.3)
• groff
• groff-full
• harfbuzz (2.9.1 -> 3.1.1)
• libstorage-ng (4.4.61 -> 4.4.63)
• makedumpfile
• osinfo-db
• rubygem-cheetah (0.5.2 -> 1.0.0)
• rubygem- yast-rake (0.2.42 -> 0.2.43)
• scout (0.2.5 + 20210424.3bff388 -> 0.2.6 + 20211130.022a45c)
• xen (4.16.0_01 -> 4.16.0_02)
• yast2 (4.4.22 -> 4.4. 27)
• yast2-add-on (4.4.3 -> 4.4.5)
• yast2-installation (4.4.23 -> 4.4.26)
• yast2-packager (4.4.14 -> 4.4.17)
• yast2-ruby-bindings (4.4 .4 -> 4.4.6)
• yast2-storage-ng (4.4.15 -> 4.4.20)
• yast2-update (4.4.5 -> 4.4.6)
• yast2-users (4.4.8 -> 4.4.9)

This video demonstrates an image with a holographic effect generated on the openSUSE platform with the realsense camera using the Realsense Video Creator for Looking Glass Portrait project. Source codes are available at: https://github.com/cabelo/rscreatelg

In this video we will see how to work with immersion using the oculus quest 2 of the metaverse. The calculation of the transformation of the relative coordinates of the keyboard in the virtual reality environment is demonstrated. We can also see the hand traceability with skeleton detection algorithms among other fantastic features.

On the road to AppStream 1.0, a lot of items from the long todo list have been done so far – only one major feature is remaining, external release descriptions, which is a tricky one to implement and specify. For AppStream 1.0 it needs to be present or be rejected though, as it would be a major change in how release data is handled in AppStream.

Besides 1.0 preparation work, the recent 0.15 release and the releases before it come with their very own large set of changes, that are worth a look and may be interesting for your application to support. But first, for a change that affects the implementation and not the XML format:

1. Completely rewritten caching code

Keeping all AppStream data in memory is expensive, especially if the data is huge (as on Debian and Ubuntu with their large repositories generated from desktop-entry files as well) and if processes using AppStream are long-running. The latter is more and more the case, not only does GNOME Software run in the background, KDE uses AppStream in KRunner and Phosh will use it too for reading form factor information. Therefore, AppStream via libappstream provides an on-disk cache that is memory-mapped, so data is only consuming RAM if we are actually doing anything with it.

Previously, AppStream used an LMDB-based cache in the background, with indices for fulltext search and other common search operations. This was a very fast solution, but also came with limitations, LMDB’s maximum key size of 511 bytes became a problem quite often, adjusting the maximum database size (since it has to be set at opening time) was annoyingly tricky, and building dedicated indices for each search operation was very inflexible. In addition to that, the caching code was changed multiple times in the past to allow system-wide metadata to be cached per-user, as some distributions didn’t (want to) build a system-wide cache and therefore ran into performance issues when XML was parsed repeatedly for generation of a temporary cache. In addition to all that, the cache was designed around the concept of “one cache for data from all sources”, which meant that we had to rebuild it entirely if just a small aspect changed, like a MetaInfo file being added to /usr/share/metainfo, which was very inefficient.

To shorten a long story, the old caching code was rewritten with the new concepts of caches not necessarily being system-wide and caches existing for more fine-grained groups of files in mind. The new caching code uses Richard Hughes’ excellent libxmlb internally for memory-mapped data storage. Unlike LMDB, libxmlb knows about the XML document model, so queries can be much more powerful and we do not need to build indices manually. The library is also already used by GNOME Software and fwupd for parsing of (refined) AppStream metadata, so it works quite well for that usecase. As a result, search queries via libappstream are now a bit slower (very much depends on the query, roughly 20% on average), but can be mmuch more powerful. The caching code is a lot more robust, which should speed up startup time of applications. And in addition to all of that, the AsPool class has gained a flag to allow it to monitor AppStream source data for changes and refresh the cache fully automatically and transparently in the background.

All software written against the previous version of the libappstream library should continue to work with the new caching code, but to make use of some of the new features, software using it may need adjustments. A lot of methods have been deprecated too now.

2. Experimental compose support

Compiling MetaInfo and other metadata into AppStream collection metadata, extracting icons, language information, refining data and caching media is an involved process. The appstream-generator tool does this very well for data from Linux distribution sources, but the tool is also pretty “heavyweight” with lots of knobs to adjust, an underlying database and a complex algorithm for icon extraction. Embedding it into other tools via anything else but its command-line API is also not easy (due to D’s GC initialization, and because it was never written with that feature in mind). Sometimes a simpler tool is all you need, so the libappstream-compose library as well as appstreamcli compose are being developed at the moment. The library contains building blocks for developing a tool like appstream-generator while the cli tool allows to simply extract metadata from any directory tree, which can be used by e.g. Flatpak. For this to work well, a lot of appstream-generator‘s D code is translated into plain C, so the implementation stays identical but the language changes.

Ultimately, the generator tool will use libappstream-compose for any general data refinement, and only implement things necessary to extract data from the archive of distributions. New applications (e.g. for new bundling systems and other purposes) can then use the same building blocks to implement new data generators similar to appstream-generator with ease, sharing much of the code that would be identical between implementations anyway.

2. Supporting user input controls

Want to advertise that your application supports touch input? Keyboard input? Has support for graphics tablets? Gamepads? Sure, nothing is easier than that with the new control relation item and supports relation kind (since 0.12.11 / 0.15.0, details):

<supports>
  <control>pointing</control>
  <control>keyboard</control>
  <control>touch</control>
  <control>tablet</control>
</supports>

3. Defining minimum display size requirements

Some applications are unusable below a certain window size, so you do not want to display them in a software center that is running on a device with a small screen, like a phone. In order to encode this information in a flexible way, AppStream now contains a display_length relation item to require or recommend a minimum (or maximum) display size that the described GUI application can work with. For example:

<requires>
  <display_length compare="ge">360</display_length>
</requires>

This will make the application require a display length greater or equal to 300 logical pixels. A logical pixel (also device independent pixel) is the amount of pixels that the application can draw in one direction. Since screens, especially phone screens but also screens on a desktop, can be rotated, the display_length value will be checked against the longest edge of a display by default (by explicitly specifying the shorter edge, this can be changed).

This feature is available since 0.13.0, details. See also Tobias Bernard’s blog entry on this topic.

4. Tags

This is a feature that was originally requested for the LVFS/fwupd, but one of the great things about AppStream is that we can take very project-specific ideas and generalize them so something comes out of them that is useful for many. The new tags tag allows people to tag components with an arbitrary namespaced string. This can be useful for project-internal organization of applications, as well as to convey certain additional properties to a software center, e.g. an application could mark itself as “featured” in a specific software center only. Metadata generators may also add their own tags to components to improve organization. AppStream gives no recommendations as to how these tags are to be interpreted except for them being a strictly optional feature. So any meaning is something clients and metadata authors need to negotiate. It therefore is a more specialized usecase of the already existing custom tag, and I expect it to be primarily useful within larger organizations that produce a lot of software components that need sorting. For example:

<tags>
  <tag namespace="lvfs">vendor-2021q1</tag>
  <tag namespace="plasma">featured</tag>
</tags>

This feature is available since 0.15.0, details.

5. MetaInfo Creator changes

The MetaInfo Creator (source) tool is a very simple web application that provides you with a form to fill out and will then generate MetaInfo XML to add to your project after you have answered all of its questions. It is an easy way for developers to add the required metadata without having to read the specification or any guides at all.

Recently, I added support for the new control and display_length tags, resolved a few minor issues and also added a button to instantly copy the generated output to clipboard so people can paste it into their project. If you want to create a new MetaInfo file, this tool is the best way to do it!

The creator tool will also not transfer any data out of your webbrowser, it is strictly a client-side application.

And that is about it for the most notable changes in AppStream land! Of course there is a lot more, additional tags for the LVFS and content rating have been added, lots of bugs have been squashed, the documentation has been refined a lot and the library has gained a lot of new API to make building software centers easier. Still, there is a lot to do and quite a few open feature requests too. Onwards to 1.0!

Si una cosa destaca en los sistemas GNU/Linux es que tenemos alternativas para casi todo. Este es el caso de la barra de tareas que os presento hoy. Se trata de Plank dock, una alternativa a la barra de tareas clásica de Plasma que rivaliza incluso con otras más atrevidas como Latte Dock.

Plank dock, una alternativa a la barra de tareas para Plasma

Lo bueno de la diversidad es que siempre encuentras cosas nuevas que complementan las que conoces y que te abren nuevas posibilidades.

Es el caso de Plank dock, una barra que he conocido en una conversación de Telegram en el Grupo de Linux y Tapas, y que ha hecho que personalice de una forma sencilla pero rompedora mi escritorio (ya lo veréis el próximo viernes).

Para explicarlo de forma sencilla, Plank Dock es un docker al estilo de los sistemas MacOS que tiene un consumo de recursos muy limitado, aunque hay que destacar que también sus funcionalidades también lo son.

Y es que cuando lo vemos en funcionamiento nos viene a la cabeza el completo Latte Dock, el cual es extraordinario y lleno de funcionalidades, pero que evidentemente consume muchos más recursos.

No obstante, Plank Dock nos ofrece todas estas funciones (traducido de Linux Uprising):

• Muestra los iconos de las aplicaciones en ejecución y permite anclar las aplicaciones al dock
• Permite arrastrar y soltar para reorganizar los iconos en el dock
• Múltiples modos de ocultación: intellihide, autohide (siempre se oculta hasta que se mueve el ratón cerca de la parte inferior de la pantalla), esquivar ventana maximizada, esquivar ventana, esquivar ventana activa, con retardo configurable para ocultar y desocultar y presión opcional (para no revelarla accidentalmente) para revelar el dock
• Posición configurable en la pantalla: abajo, arriba, izquierda o derecha
• Múltiples posibilidades de alineación: centro, relleno (que rellena el fondo del dock para el 100% del ancho de la pantalla, haciendo que aparezca como un panel; en esta configuración se puede cambiar la disposición de los iconos al centro, inicio o final del dock), inicio (izquierda o arriba, dependiendo de la orientación del dock) y final (derecha o abajo, dependiendo de si el dock es horizontal o vertical).
• Tamaño de los iconos configurable, y efecto de zoom de los iconos opcional (con nivel de zoom configurable); la función de zoom de los iconos está desactivada en elementary OS y Fedora debido a una posible infracción de la patente

• Puede configurarse para que sólo muestre los elementos anclados para que funcione sólo como un lanzador (sin mostrar las aplicaciones en ejecución), útil en las configuraciones de múltiples docks en las que un dock sirve sólo como lanzador (mostrando sólo las aplicaciones ancladas)
• Puede mostrar sólo las aplicaciones que se ejecutan en el espacio de trabajo actual
• Permite elegir el monitor en el que se muestra el dock
• Soporta docklets y viene con algunos incorporados (estos son applets / herramientas independientes que se ejecutan dentro de Plank, por ejemplo, Clippy, un gestor de portapapeles, un indicador de batería, un escritorio de muestra o un icono de basura)
• Soporte de temas
• Ejecutar varios docks al mismo tiempo, cada uno con su propia configuración (esta funcionalidad no está expuesta en las preferencias de Plank)

No obstante, tiene alguna limitación como, por ejemplo, que no soporta Wayland, algo que si hace Latte Dock y que no se soluciona pronto dejará obsoleto este dock.

この記事は openSUSE Advent Calendar の7日目です。

今回は filelight を紹介します。

filelight はグラフィカルにファイルの使用量を表示するツールです。KDE 環境が必要です。起動すると、以下のように、おそらくマウントポイント単位でディスクの使用状況をドーナツ状のグラフで表示します。

色が付いているところをクリックすると、その部分をドリルダウンして詳細を表示していきます。

また、特定のディレクトリについては調査対象外とすることもできます。既定では、/dev,/proc,/sys,/root が除外対象になっています。

そのほかにも、注目しているところをズームインしたり、画像を SVG 形式で保存できる機能もあります。
ただ、ドリルダウンは、最初の状態、すなわちマウントポイント毎の表示画面には戻れません。あるマウントポイントのトップまでしか戻れません。別のマウントポイントの状況を見るときには、一旦 filelight を再起動する必要があります。/homeや/var などをそれぞれ別パーティションにしてマウントしている場合には少々不便です。
ただ、その点を考慮に入れても、状況をグラフィカルに見ることができるのはとても便利です。気軽に使えるツールとして常用しても良いと思います。

なお、filelight は、Windows 版もあります。Microsoft Store で入手が可能です。