Siguiendo el objetivo de mostrar qué ofreció el pasado mayo la Comunidad KDE en cuanto a aplicaciones. Así que ya he hablado de las nueva aplicaciones del ecosistema, de Dolphin, de Itinerary, de Neochat y de Tokodon. Así que hoy toca hablar de las novedades de Kdenlive en KDE Gear 24.05, el editor de vídeo no lineal de KDE.

Las novedades de Kdenlive en KDE Gear 24.05

Aunque es de sobra conocido en el mundillo nunca está de más presentar las aplicaciones, Kdenlive es el completo editor de vídeo de KDE que nos proporciona todo lo necesario para crear anuncios, documentales, programas de TV y películas de calidad. Inicialmente ofrecía mucha potencia pero tenía bastantes problemas de estabilidad, desde hace unos años, estos problemas han desaparecido (Casi todos) y se está convirtiendo en otra Killer APP dentro de las aplicaciones Libres. Solo diré que mis compañeros profesores la utilizan sin apenas formación para realizar los típicos vídeos de final de curso.

Esta nueva versión 24.05 incorpora efectos de grupo, que se pueden añadir a videoclips agrupados. También puede llegar a audiencias más amplias usando IA sin conexión que puede traducir los subtítulos con la función de traducción automáticas de subtítulos.

Por otra parte, ha vuelto la función que permitía capturar sonido desde el escritorio o con un micrófono directamente desde Kdenlive. También se ha mejorado notablemente el rendimiento al mover videoclips con la herramienta del espaciador.

Para finalizar destacar quela función de gestión de múltiples contenedores de recursos (los contenedores son las áreas donde se guardan los videoclips, las imágenes, los títulos y las animaciones) también se ha revisado y mejorado.

Más información: KDE Gear 24.05

La entrada Las novedades de Kdenlive en KDE Gear 24.05 se publicó primero en KDE Blog.

Tiene la funcionalidad básica de un multiplexor de terminal (similar a tmux o screen) pero incluye muchas funciones integradas

Desde hace unos días estoy probando Zellij, un software publicado bajo licencia MIT, que permite crear espacios de trabajo a la hora de trabajar con la terminal en sistemas GNU/Linux.

Es un software similar a otros multiplexadores de terminal, más veteranos y conocidos como son Tmux o screen sobre los que he escrito artículos en el blog.

Zellij ofrece una información e interfaz más visual al alcance del usuario, por lo que puede facilitar su uso e incluye muchas funciones integradas que permiten a los usuarios ampliarlo y crear su propio entorno personalizado.

Instalando

Lo primero será instalarlo en nuestra distribución de GNU/Linux, buscándolo en los repositorios. En openSUSE Tumbleweed vale ejecutar un simple zypper in zellij para tenerlo en nuestro equipo.

Una vez instalado, abrimos una terminal y ejecutamos zellij y se nos abrirá un marco con una pestaña, e información de los atajos de teclado disponibles en la parte inferior.

Comenzando

Con zellij, podremos crear diferentes espacios de trabajo, si hacemos un uso intensivo de la terminal o simplemente siempre tenemos varias cosas corriendo en la terminal al mismo tiempo.

Podremos dividir el espacio de trabajo de manera sencilla en diferentes pestañas, de manera similar a un navegador y estas a su vez en paneles con divisiones verticales u horizontales, e incluso paneles flotantes (como ves en la captura que abre el artículo).

Zellij incluye un motor de diseño que permite a los usuarios definir una disposición de cómo queremos los paneles en un archivo de configuración y cargarlo cuando inician la aplicación. De esta manera, uno puede tener los paneles dispuestos de la manera que quiera sin tener que hacer todo el trabajo de configuración.

Paneles

Pero para empezar a usarlo, echando un vistazo a la parte inferior, vemos que con Ctrl+P y después n dividiremos el espacio actual en otro panel. Podemos cambiar entre los paneles con Alt+flechas de cursores

Podemos asignarles diferentes nombres a esos paneles mediante Ctrl+P y después c y escribiremos el nombre que queramos que aparecerá en la parte superior izquierda del panel.

Pestañas

Al igual que en paneles, podemos dividir el espacio en pestañas mediante Ctrl+T y después n Y también podremos asignarle un nombre diferente a las pestañas mediante Ctrl+T y después r

Los paneles que hayamos creado, los podremos redimensionar mediante Ctrl+n y diversas maneras de hacerlo, bien con el +,- o con las flechas o usando las teclas de Vim hjkl.

Sesiones

De manera predeterminada al iniciar Zellij, nos abre una sesión que llama con nombres aleatorios y exóticos como: awesome-rustaceous

Las sesiones son diferentes espacios de trabajo. La ventaja que tienen las sesiones es que podemos loguearnos mediante ssh a una máquina remota o un servidor por ejemplo y podemos cerrar nuestra sesión de Zellij, y antes debemos «detach» la sesión y esa sesión quedará activa mediante Ctrl+o y con d

Por lo que podremos retomarla más adelante como si nunca ubiéramos dejado de estar conectados a la máquina remota. Podremos acceder al gestor de sesiones mediante Ctrl+o y después w Y desde ahí renombrar la sesión actual Ctrl+r. O con Tab crear una nueva sesión, o resucitar una sesión antigua que hemos tenido.

La verdad que es un software que puede ayudar mucho, y puede que aporte algo extra a tu forma de trabajar si ya lo hacías con Tmux, con la posibilidad de crear tus propios complementos en función de lo que necesites.

Enlaces de interés

• https://zellij.dev/
• https://github.com/zellij-org/zellij
• https://zellij.dev/documentation/

Siguiendo el objetivo de mostrar qué ofreció el pasado mayo la Comunidad KDE en cuanto a aplicaciones. Hace unos días hablé de las nueva aplicaciones del ecosistema, después de Dolphin, posteriormente de Itinerary y ayer de Neochat. Hoy toca hablar de las novedades de Tokodon en KDE Gear 24.05, una plataforma para utilizar redes sociales como las de Mastodon.

Las novedades de Tokodon en KDE Gear 24.05

Tokodon es una de desa aplicaciones que ponen la plataforma de redes sociales federadas como Mastodon a tu alcance, con una integración fabulosa en el escritorio o dispositivo móvol.

Con Tokodon se puede leer, publicar y enviar mensajes fácilmente, y sus funcionalidades no paran de crecer para convertirse en un un cliente a la altura de los entornos de trabajo KDE. Las novedades más desatacadas de la versión 24.05 las siguientes:

Ahora, al escribir una nueva publicación, se puede hacer en una ventana separada, lo que le permite continuar usando Tokodon mientras se escribe la publicación.

Adicionalmente, se ha añadido una marca con un contador para seguir las solicitudes de seguimiento en la barra lateral.

Pequeñas mejoras pero constantes para que poco a poco se convierte en una aplicación imprescindible si utilizas esta red.

Más información: KDE Gear 24.05

La entrada Las novedades de Tokodon en KDE Gear 24.05 se publicó primero en KDE Blog.

Siguiendo el objetivo de mostrar qué ofreció el pasado mayo la Comunidad KDE en cuanto a aplicaciones. Hace unos días hablé de las nueva aplicaciones del ecosistema, después de Dolphin y hace un par de días de Itinerary. Hoy toca hablar de las novedades de Neochat en KDE Gear 24.05, una aplicación de charla que le permite aprovechar todas las ventajas de la red Matrix.

Las novedades de NeoChat en KDE Gear 24.05

Poco a poco se está estableciendo la red Matrix como la más libre y segura para aquellas personas que valoramos nuestra intimidad. La Comunidad KDE hace tiempo que la utiliza y no para de promocionarla.

Y, como no podía ser de otra forma, debe oferecer un cliente a la altura para poder utilizarlo en los entornos de trabajo KDE. Su nombre es NeoChat y ofrece las siguientes novedades:

Se ha movido la búsqueda a una ventana emergente para permitirle buscar conversaciones independientemente del espacio en el que se encuentre.

Además, ahora NeoChat también escaneará ahora PDF y otros archivos enviados al chat para encontrar documentos de viaje y mostrará toda la información relevante directamente en la conversación. Todo el procesamiento se realiza en nuestro dispositivo y no se envía ningún tipo de información privada a servidores de terceras partes. De manera similar, los documentos de texto se mostrarán directamente en la línea de tiempo.

Más información: KDE Gear 24.05

La entrada Las novedades de NeoChat en KDE Gear 24.05 se publicó primero en KDE Blog.

Tumbleweed es una distribución de GNU/Linux «Rolling Release» o 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 esta semana.

Y recuerda que puedes estar al tanto de las nuevas publicaciones de snapshots en esta web:

• https://victorhck.gitlab.io/tumbleweed_snapshots/

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

• https://dominique.leuenberger.net/blog/2024/06/opensuse-tumbleweed-review-of-the-week-2024-25/

Esta es la semana anterior a la openSUSE Conference, y muchas de las personas que empaquetan, estarán allí, aún así han tenido tiempo para actualizar el software y se han publicado 5 snapshots esta semana (0613, 0614, 0617, 0618, y 0619)

Las actualizaciones más importantes que han llegado:

• libxml 2.12.8
• Ruby 3.3.3
• VLC 3.0.21, ver http://www.videolan.org/security/sb-vlc3021.html
• Mesa 24.0.9, 24.1.0 & 24.1.1: Mesa 24 trajo algunos fallos gráficos en las tarjetas gráficas AMD/.ATI, que no pudimos detectar en openQA. Se publicó una versión (en su mayoría) fija en el canal de actualización para acortar el tiempo)
• Mozilla Firefox 127.0
• KDE Gear 24.05.1
• Linux kernel 6.9.4 & 6.9.5

Y ya preparándose para próximas actualizaciones:

• KDE Plasma 6.1
• NodeJS 22.3.0
• Perl 5.40.0
• transactional-update
• Pytest 8.2
• dbus-broker
• GCC 14

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?
• ¿Qué es el test openQA?
• http://download.opensuse.org/tumbleweed/iso/
• https://es.opensuse.org/Portal:Tumbleweed

——————————–

Since a few weeks ago, librsvg is now in oss-fuzz — Google's constantly-running fuzz-testing for OSS projects — and the crashes have started coming in. I'll have a lot more to say soon about crashes in Cairo, which is where the majority of the bugs are so far, but for now I want to tell you about a little bug I just fixed.

The fuzzer found a memory leak that happens when librsvg tries to parse an invalid XML document that has definitions for XML entities — the things that you normally reference like &foo; in the middle of the XML.

For example, this invalid document causes librsvg to leak:

<!DOCTYPEY[<!ENTITY a ''

Valgrind reports this:

$ valgrind --leak-check=full ./target/debug/rsvg-convert leak.svg 
...
Error reading SVG leak.svg: XML parse error: Error domain 1 code 37 on line 2 column 1 of data: xmlParseEntityDecl: entity a not terminated

==3750== 
==3750== HEAP SUMMARY:
==3750==     in use at exit: 78,018 bytes in 808 blocks
==3750==   total heap usage: 1,405 allocs, 597 frees, 205,161 bytes allocated
==3750== 
==3750== 247 (144 direct, 103 indirect) bytes in 1 blocks are definitely lost in loss record 726 of 750
==3750==    at 0x4845794: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==3750==    by 0x4BD857F: xmlCreateEntity (entities.c:158)
==3750==    by 0x4BD932B: xmlNewEntity (entities.c:451)
==3750==    by 0x2EBC75: rsvg::xml::xml2_load::sax_entity_decl_cb (xml2_load.rs:152)
==3750==    by 0x4BED6D8: xmlParseEntityDecl (parser.c:5647)
==3750==    by 0x4BEF4F3: xmlParseMarkupDecl (parser.c:7024)
==3750==    by 0x4BEFB95: xmlParseInternalSubset (parser.c:8558)
==3750==    by 0x4BF50E9: xmlParseDocument (parser.c:11072)
==3750==    by 0x2ED266: rsvg::xml::xml2_load::Xml2Parser::parse (xml2_load.rs:466)
==3750==    by 0x4A8C49: rsvg::xml::XmlState::parse_from_stream::{{closure}} (mod.rs:628)
==3750==    by 0x2ACA92: core::result::Result<T,E>::and_then (result.rs:1316)
==3750==    by 0x34D4E2: rsvg::xml::XmlState::parse_from_stream (mod.rs:627)
==3750== 
==3750== LEAK SUMMARY:
==3750==    definitely lost: 144 bytes in 1 blocks
==3750==    indirectly lost: 103 bytes in 3 blocks
==3750==      possibly lost: 0 bytes in 0 blocks
==3750==    still reachable: 73,947 bytes in 746 blocks
==3750==         suppressed: 0 bytes in 0 blocks

Let's see what happened.

The code in question

Even after the port to Rust, librsvg still uses libxml2 for parsing XML. So, librsvg has to deal with raw pointers incoming from libxml2 and it must do their memory management itself, since the Rust compiler doesn't know what to do with them automatically.

Librsvg uses the SAX parser, which involves setting up callbacks to process events like "XML element started", or "an entity was defined".

If you have a valid document that has entity definitions like these:

<!ENTITY foo "#aabbcc">
<!ENTITY bar "some text here">

Then libxml2's SAX parser will emit two events to instruct your code that it should define entities, one for foo and one for bar, with their corresponding content. Librsvg stores these in a hash table, since it has to be able to retrieve them later when the SAX parser requests it. In detail, libxml2 requires that you create an xmlEntityPtr by calling xmlNewEntity() and then keep it around.

xmlEntityPtr xmlNewEntity (xmlDocPtr      doc,
                           const xmlChar *name,
                           int            type,
                           const xmlChar *ExternalID,
                           const xmlChar *SystemID,
                           const xmlChar *content);

Later, you must free each of your stored entities with xmlFreeNode() (it supports different data types, including entities), or if you are using libxml2 2.12.0 or later, with xmlFreeEntity().

void xmlFreeNode (xmlNodePtr node);
void xmlFreeEntity (xmlEntityPtr entity);

Librsvg creates a SAX parser from libxml2, calls it to do the parsing, and then frees the entities at the end. In the following code, XmlState is the struct that librsvg uses to hold the temporary state during parsing: a partially-built XML tree, some counters on the number of loaded elements, the current element being processed, things like that. The build_document() method is called at the very end of XmlState's lifetime; it consumes the XmlState and returns either a fully-parsed and valid Document, or an error.

struct XmlState {
    inner: RefCell<XmlStateInner>,  // the mutable part

    // ... other immutable fields here
}

type XmlEntityPtr = *mut libc::c_void;

struct XmlStateInner {
    // ... a few fields for the partially-built XML tree, current element, etc.
    document_builder: DocumentBuilder,

    // Note that neither XmlStateInner nor Xmlstate implement Drop.
    //
    // An XmlState is finally consumed in XmlState::build_document(), and that
    // function is responsible for freeing all the XmlEntityPtr from this field.
    //
    // (The structs cannot impl Drop because build_document()
    // destructures and consumes them at the same time.)
    entities: HashMap<String, XmlEntityPtr>,
}

impl XmlState {
    fn build_document(
        self,
        stream: &gio::InputStream,
        cancellable: Option<&gio::Cancellable>,
    ) -> Result<Document, LoadingError> {
        // does the actual parsing with a libxml2 SAX parser
        self.parse_from_stream(stream, cancellable)?;

        // consume self, then consume inner, then consume document_builder by calling .build()
        let XmlState { inner, .. } = self;
        let mut inner = inner.into_inner();

        // Free the hash of XmlEntityPtr.  We cannot do this in Drop because we will
        // consume inner by destructuring it after the for() loop.
        for (_key, entity) in inner.entities.drain() {
            unsafe {
                xmlFreeNode(entity);
            }
        }

        let XmlStateInner {
            document_builder, ..
        } = inner;
        document_builder.build()
    }
}

There are many Rust-isms in this code.

• After doing the actual parsing with parse_from_stream(), self is destructured to consume it and extract its inner field, which is the actual mutable part of the XML loading state.

• The code frees each xmlEntityPtr stored in the hash table of entities.

• The inner value, which is an XmlStateInner, is destructured to extract the document_builder field, which gets asked to .build() the final document tree.

Where's the bug?

The bug is in this line at the beginning of the build_document() function:

        self.parse_from_stream(stream, cancellable)?;

The ? after the function call is to return errors to the caller. However, if there is an error during parsing, we will exit the function here, and it will not have a chance to free the values in the key-value pairs among the entities ! Memory leak!

This code had already gone through a few refactorings. Initially I had an impl Drop for XmlState which did the obvious thing of freeing the entities by hand:

impl Drop for XmlState {
    fn drop(&mut self) {
        unsafe {
            let mut inner = self.inner.borrow_mut();

            for (_key, entity) in inner.entities.drain() {
                // entities are freed with xmlFreeNode(), believe it or not
                xmlFreeNode(entity);
            }
        }
    }
}

But at one point, I decided to clean up the way the entire inner struct was to be handled, and decided to destructure it at the end of its lifetime, since that made the code simpler. However, destructuring an object means that you cannot have an impl Drop for it, since then some fields are individually moved out and some are not during the destructuring. So, I changed the code to free the entities directly into build_document() as above.

I missed the case where the parser can exit early due to an error.

The Rusty solution

Look again at how the entities hash table is declared in the struct fields:

type XmlEntityPtr = *mut libc::c_void;

struct XmlStateInner {
    entities: HashMap<String, XmlEntityPtr>,
}

That is, we are storing a hash table with raw pointers in the value part of the key-value pairs. Rust doesn't know how to handle those external resources, so let's teach it how to do that.

The magic of having an impl Drop for a wrapper around an unmanaged resource, like xmlEntityPtr, is that Rust will automatically call that destructor at the appropriate time — in this case, when the hash table is freed.

So, let's use a wrapper around XmlEntityPtr, and add an impl Drop for the wrapper:

struct XmlEntity(xmlEntityPtr);

impl Drop for XmlEntity {
    fn drop(&mut self) {
        unsafe {
            xmlFreeNode(self.0);
        }
    }
}

And then, let's change the hash table to use that wrapper for the values:

    entities: HashMap<String, XmlEntity>,

Now, when Rust has to free the HashMap, it will know how to free the values. We can keep using the destructuring code in build_document() and it will work correctly even with early exits due to errors.

Valgrind's evidence without the leak

# valgrind --leak-check=full ./target/debug/rsvg-convert leak.svg 
==5855== Memcheck, a memory error detector
==5855== Copyright (C) 2002-2024, and GNU GPL'd, by Julian Seward et al.
==5855== Using Valgrind-3.23.0 and LibVEX; rerun with -h for copyright info
==5855== Command: ./target/debug/rsvg-convert leak.svg
==5855== 
Error reading SVG leak.svg: XML parse error: Error domain 1 code 37 on line 2 column 1 of data: xmlParseEntityDecl: entity a not terminated

==5855== 
==5855== HEAP SUMMARY:
==5855==     in use at exit: 77,771 bytes in 804 blocks
==5855==   total heap usage: 1,405 allocs, 601 frees, 205,161 bytes allocated
==5855== 
==5855== LEAK SUMMARY:
==5855==    definitely lost: 0 bytes in 0 blocks
==5855==    indirectly lost: 0 bytes in 0 blocks
==5855==      possibly lost: 0 bytes in 0 blocks
==5855==    still reachable: 73,947 bytes in 746 blocks
==5855==         suppressed: 0 bytes in 0 blocks

Moral of the story

Resources that are external to Rust really work best if they are wrapped at the lowest level, so that destructors can run automatically. Instead of freeing things by hand when you think it's right, let the compiler do it automatically when it knows it's right. In this case, wrapping xmlEntityPtr with a newtype and adding an impl Drop is all that is needed for the rest of the code to look like it's handling a normal, automatically-managed Rust object.

Dear Tumbleweed users and hackers,

It’s the week before openSUSE Conference, when all through the world, contributors get ready to travel. People might be busy with their final preparations to meet at the conference next week, and prepare their slides for the talks, but nothing can stop them from keeping Tumbleweed rolling. This week, we have received 5 snapshots (0613, 0614, 0617, 0618, and 0619)

The most relevant updates included were:

• libxml 2.12.8
• Ruby 3.3.3
• VLC 3.0.21, see http://www.videolan.org/security/sb-vlc3021.html
• Mesa 24.0.9, 24.1.0 & 24.1.1: Mesa 24 brought some graphical glitches on AMD/.ATI graphic cards, which we could not catch in openQA. A (mostly) fixed version was published in the update channel to shorten the time)
• Mozilla Firefox 127.0
• KDE Gear 24.05.1
• Linux kernel 6.9.4 & 6.9.5

Staging projects are currently testing the integration of these changes:

• KDE Plasma 6.1
• NodeJS 22.3.0
• Perl 5.40.0
• transactional-update: enable soft reboot; see https://microos.opensuse.org/blog/2024-06-13-soft-reboot/
• Pytest 8.2
• dbus-broker: some networking issue after upgrades left to work out
• GCC 14: phase 2: use gcc14 as the default compiler – lots of help needed: https://build.opensuse.org/project/show/openSUSE:Factory:Staging:Gcc7

With all this, I am looking forward to seeing many of you at the openSUSE conference in Nuremberg next week!

Hoy mismo (21/6/2024) se ha publicado la nueva versión de MyGNUHealth 2.2.

Pero ¿Ya sabes qué es MyGNUHealth?

MyGNUHealth es un programa de software libre con el que es muy sencillo llevar un registro de salud personal. Esta aplicación se puede utilizar en computadoras de escritorio y dispositivos móviles.

Te ayuda a tomar el control de tu salud, y con la aplicación podrás registrar, valorar y actuar proactivamente sobre los determinantes de los principales ámbitos de tu salud (biopsicosocial).

MyGNUHealth no pretende reemplazar el consejo de un profesional de la salud. consulta siempre con profesionales que son las mejores fuentes para su salud y bienestar, aunque este programa te podrá servir como herramienta de algo tan importante como la salud.

Este nuevo MyGNUHealth 2.2 viene con muchas mejoras y correcciones de errores. Algunos aspectos destacados de esta nueva versión:

• Soporte para Kivy 2.3.0
• MyGNUHealth ahora tiene soporte para diferentes idiomas: Inglés, español y chino están disponibles para su uso, y francés, alemán e italiano están listos para ser traducidos. Habrá un componente de traducción para MyGNUHealth en la instancia Weblate de Codeberg.
• Funcionalidad Bluetooth: a partir de la serie MyGH 2.2, se proporciona integración Bluetooth para dispositivos abiertos compatibles y rastreadores de salud. Se incluye la vinculación con el Pinetime Smartwatch (experimental) y la posibilidad de vinculación a cualquier dispositivo de hardware libre (glucómetro, báscula, tensiómetro, etc).
• Los gráficos ahora permiten seleccionar rangos de fechas con widgets de calendario
• El Libro de la Vida tiene un formato revisado para las páginas.
• Se ha mejorado el formato de los gráficos e incluyen etiquetas del eje x.

En cuanto a la compatibilidad con hardware sanitario, el proyecto necesita obtener una lista de dispositivos médicos disponibles que respeten la privacidad y libertad de las personas que los utilizan, así que informa al proyecto si tienes información al respecto.

Gracias a Kivy, el código base de MyGNUhealth se puede migrar a otras arquitecturas y sistemas operativos como Android AOSP o teléfonos con sistemas GNU/Linux.

Además de Savannah, han incorporado Codeberg al entorno de desarrollo de GNU Health. Las listas de correo, noticias y descargas de archivos están en GNU, mientras que los repositorios de desarrollo están en Codeberg.

Se puede descargar el código fuente más reciente de MyGNUhealth desde el sitio ftp de GNU, pypi (usando pip) o desde el paquete de su sistema operativo (como openSUSE).

La actualización debería ser sencilla y todo el historial de salud que ya tuvieras almacenado permanecerá en la base de datos MyGH. En cualquier caso, es seguro siempre de hacer una copia de seguridad antes de actualizar o de manera diaria.

Mantén un seguimiento de tu salud y diversos datos relacionados con la salud gracias a MyGNUHealth y/o colabora con este gran proyecto comprometido a nivel tecnológico y social con el bienestar y la libertad de las personas.

Enalces de interés

• https://savannah.gnu.org/news/?id=10644
• https://codeberg.org/gnuhealth
• https://translate.codeberg.org/projects/gnuhealth/
• https://docs.gnuhealth.org//mygnuhealth/
• https://victorhckinthefreeworld.com/2022/06/15/que-es-gnu-health-su-creador-nos-responde/