Deploying software for HPC clusters is often a complex task, as HCP cluster tend to have a fixed software stack. Also precompiled software is not always fully optimized to hardware of the HPC cluster. With this post I want to describe two tools which try to solve these problems. The first one is spack which is build system for mainly HPC applications and their dependencies. With singularity[1] these HPC applications can be packed into containers which can be executed in user space.

Preparations

As well spack as singularity are available as packages in openSUSE Tumbleweed, Leap and via PackageHub for SLE. The packages can be installed with

# sudo zypper install singularity spack

After the installation you should add all the users which want to use singularity to the singularity group, e.g. with

# sudo usermod -a -G singularity <user_login>

Create singularity definition

Now you have to decide which application to build inside the container. For this example we will gromacs with MPI support. So create the file spack.yaml with following content

spack:
  specs:
  - gromacs+mpi
  - openmpi

  container:
    format: singularity
    images:
      os: "leap:15"
      spack: "latest"

    os_packages:
      final:
      - libgomp1

additionally the multi threading support is enable in the final container with the installation of the OpenMP runtime library libgomp1. The definition file for singualrity can then be created with the command

spack containerize > gromacs-mpi.def

Build the container

With this definition the final application container image can now build with the command

singularity build --fakeroot gromacs-mpi.sif gromacs-mpi.def

where the --fakeroot switch to allow building for non root users. The build will have two phases, where the first one will pull in the container spack/leap15:latest which has spack and necessary build tools installed, build gromacs together with openmpi and move the resulting binaries to the container opensuse/leap:latest. The binairis built with spack are located in the container under /opt/view/bin.

Inspect the container

A single command within the container can be run with

singularity exec gromacs-mpi.sif ls /opt/view/bin

which will list all the binaries installed under /opt/view/bin within the container. You can also open a shell in the container with

singularity shell gromacs-mpi.sif

Please note that the home directory of the user is mounted under $HOME in the container.

Run the container

Now you can run the application, which is gromacs in this case, in parallel with

mpirun singularity exec gromacs-mpi.sif gmx_mpi mdrun\
	-s topol_pme.tpr -maxh 0.50 -resethway\
	-noconfout -nsteps 10000 -g gmx_sing.log

Have a lot of fun

Apptainer

[1] In order to avoid confusion with singularity Community Edition from sylabs, singularity will be renamed to apptainer, but the them of this article ‘apptainer’ is not fully stable, yet. [https://linuxfoundation.org/press-release/new-linux-foundation-project-accelerates-collaboration-on-container-systems-between-enterprise-and-high-performance-computing-environments/]

Abaixo uma imagem que explica claramente a diferença entre segmentação Panótica, Instância e Semântica. A segmentação de semântica agrupa as instâncias de objetos, na segmentação de instância separa todas as instancias de objetos ( assim permitindo distinguir os pixels de cada objeto), já a segmentação panótica sera todos os pixels (camadas, instancias e objetos).

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!