We got a bug with a gigantic SVG of a map extracted from OpenStreetMap, and it has about 600,000 elements. Most of them are <path>, that is, specifications for Bézier paths.

A <path> can look like this:

<path d="m 2239.05,1890.28 5.3,-1.81"/>

The d attribute contains a list of commands to create a Bézier path, very similar to PostScript's operators. Librsvg has the following to represent those commands:

pub enum PathCommand {
    MoveTo(f64, f64),
    LineTo(f64, f64),
    CurveTo(CubicBezierCurve),
    Arc(EllipticalArc),
    ClosePath,
}

Those commands get stored in an array, a Vec inside a PathBuilder:

pub struct PathBuilder {
    path_commands: Vec<PathCommand>,
}

Librsvg translates each of the commands inside a <path d="..."/> into a PathCommand and pushes it into the Vec in the PathBuilder. When it is done parsing the attribute, the PathBuilder remains as the final version of the path.

To let a Vec grow efficiently as items are pushed into it, Rust makes the Vec grow by powers of 2. When we add an item, if the capacity of the Vec is full, its buffer gets realloc()ed to twice its capacity. That way there are only O(log₂n) calls to realloc(), where n is the total number of items in the array.

However, this means that once we are done adding items to the Vec, there may still be some free space in it: the capacity exceeds the length of the array. The invariant is that vec.capacity() >= vec.len().

First I wanted to shrink the PathBuilders so that they have no extra capacity in the end.

First step: convert to Box<[T]>

A "boxed slice" is a contiguous array in the heap, that cannot grow or shrink. That is, it has no extra capacity, only a length.

Vec has a method into_boxed_slice which does eactly that: it consumes the vector and converts it into a boxed slice without extra capacity. In its innards, it does a realloc() on the Vec's buffer to match its length.

Let's see the numbers that Massif reports:

--------------------------------------------------------------------------------
  n        time(i)         total(B)   useful-heap(B) extra-heap(B)    stacks(B)
--------------------------------------------------------------------------------
 23 22,751,613,855    1,560,916,408    1,493,746,540    67,169,868            0
                                       ^^^^^^^^^^^^^
                                           before

 30 22,796,106,012    1,553,581,072    1,329,943,324   223,637,748            0
                                       ^^^^^^^^^^^^^
                                           after

That is, we went from using 1,493,746,540 bytes on the heap to using 1,329,943,324 bytes. Simply removing extra capacity from the path commands saves about 159 MB for this particular file.

Second step: make the allocator do less work

However, the extra-heap column in that table has a number I don't like: there are 223,637,748 bytes in malloc() metadata and unused space in the heap.

I suppose that so many calls to realloc() make the heap a bit fragmented.

It would be good to be able to read most of the <path d="..."/> to temporary buffers that don't need so many calls to realloc(), and that in the end get copied to exact-sized buffers, without extra capacity.

We can do just that with the smallvec crate. A SmallVec has the same API as Vec, but it can store small arrays directly in the stack, without an extra heap allocation. Once the capacity is full, the stack buffer "spills" into a heap buffer automatically.

Most of the d attributes in the huge file in the bug have fewer than 32 commands. That is, if we use the following:

pub struct PathBuilder {
    path_commands: SmallVec<[PathCommand; 32]>,
}

We are saying that there can be up to 32 items in the SmallVec without causing a heap allocation; once that is exceeded, it will work like a normal Vec.

At the end we still do into_boxed_slice to turn it into an independent heap allocation with an exact size.

This reduces the extra-heap quite a bit:

--------------------------------------------------------------------------------
  n        time(i)         total(B)   useful-heap(B) extra-heap(B)    stacks(B)
--------------------------------------------------------------------------------
 33 24,139,598,653    1,416,831,176    1,329,943,212    86,887,964            0
                                                        ^^^^^^^^^^

Also, the total bytes shrink from 1,553,581,072 to 1,416,831,176 — we have a smaller heap because there is not so much work for the allocator, and there are a lot fewer temporary blocks when parsing the d attributes.

Making the code prettier

I put in the following:

/// This one is mutable
pub struct PathBuilder {
    path_commands: SmallVec<[PathCommand; 32]>,
}

/// This one is immutable
pub struct Path {
    path_commands: Box<[PathCommand]>,
}

impl PathBuilder {
    /// Consumes the PathBuilder and converts it into an immutable Path
    pub fn into_path(self) -> Path {
        Path {
            path_commands: self.path_commands.into_boxed_slice(),
        }
    }
}

With that, PathBuilder is just a temporary struct that turns into an immutable Path once we are done feeding it. Path contains a boxed slice of the exact size, without any extra capacity.

Next steps

All the coordinates in librsvg are stored as f64, double-precision floating point numbers. The SVG/CSS spec says that single-precision floats are enough, and that 64-bit floats should be used only for geometric transformations.

I'm a bit scared to make that change; I'll have to look closely at the results of the test suite to see if rendered files change very much. I suppose even big maps require only as much precision as f32 — after all, that is what OpenStreetMap uses.

References

• Convert the Vec into a Box<[T]>
• Convert to SmallVec

A máscara Face Shield com material transparente (Folha de PETG) ajuda na redução do risco de contágio do COVID-19, pois barra o contato das mão com os olhos e outras ações involuntárias.

Utilizando a tecnologia de impressão 3D, podemos confeccionar um Equipamento de Proteção Individual (EPI) para a face, assim complementando as máscaras do tipo N95 (pois os olhos ficam desprotegidos).

O projeto foi denominado “Face shield for life 3D” e seu download pode ser efetuado no link a seguir ou na URL ORIGINAL:

No link, além dos arquivos 3D, encontramos as dimensões do material transparente (Folha de PETG), marcações e outros.

Minha amiga de Latinoware e eventos de Software Livre Barbara Samel Rocha Tostes especialista em impressão 3D esta disponibilizando diversas informações no seu Facebook e também me conectou ao Grupo do Telegram de modelagem3D. Então posso servir de interface para maiores esclarecimentos.

O polímero é a matéria-prima utilizada na impressora 3D. O seu custo esta em torno de R$ 100, esta quantidade é suficiente para produzir aproximadamente 30 e 32 máscaras.

Mas cuidados especiais devem ser tomados. Desde a confecção até a logística de entrega (que apenas profissionais de saúde conseguem aplicar para garantir o risco de não contaminação).

Então sugiro que os municípios se organizem reunindo profissionais com conhecimento suficiente para produzir o material de maneira segura (assim evitando o aumento do risco de contágio através da própria máscara). Os médicos e hospitais possuem aparelhos para descontaminar as mascarás (não somente do COVID-19), assim tornando eficiente o movimento.

Atenção: A ANVISA regulamentou ontem as Faceshields, tamanho mínimo de 24x24cm com 0.5mm de espessura , Logo Acetato de fichário não atende.

§ 4° O visor frontal deve ser fabricado em material transparente e possuir dimensões mínimas de espessura 0,5mm, largura 240 mm e altura 240mm.

Mais informação a seguir:

En estos tiempos de confinamiento están apareciendo muchas iniciativas para que el tiempo pase algo más rápido. De esta forma, el gran Rubén ha reunido a la flor y nata del mundo del poscasting linuxero (aunque uno de ellos no se considere así) y van a realizar una charla distenida cuyo tema principal será Linux y teletrabajo, un tema candente en estos momentos.

Linux y teletrabajo, podcast especial el 25 de marzo

El número de teletrabajadores ha experimentado un aumento considerable estos días por razones más que obvias. Oficinistas, profesores, presentadores de radio y televisión, administrativos y muchos otros, se han tenido que preparar su estudio de realización en casa e intentar sus labores desde casa.

Decenas de aplicaciones online están siendo promocionadas, explicadas, utilizadas y, porqué no decirlo, sobresaturadas debido al gran incremento de uso que están sufriendo, y entre estas, existen muchas que son de código libre excelentes y capaces de realizar la mayoría de las funciones.

Este apasionante tema, Linux y teletrabajo, será justo el que será tratado a fondo este miércoles 25 a las 20:00 horas CES con cuatro de los podcasters más conocidos dentro del mundo GNU/Linux: Paco Estrada (de Compilando Podcast), Juan Febles (de Podcast Linux), Yoyo Fernández (de Salmorejo Geek) y Rubén Gómez (de KDE España). Os recomiendo esta entrevista del 2018 si no conocéis a los tres primeros.

En un principio, a lo largo de una hora hablarán de las alternativas libres (y es posible que se cuele alguna privada) que tenemos para poder realizar las tareas encomendadas o voluntarias que vamos a realizar en nuestra casa durante el tiempo en le que estemos confinados.

En esta ocasión, será emitido en directo por el canal de youtube de KDE España https://www.youtube.com/watch?v=c9AFefcDuMQ&feature=youtu.be  (que pondré mañana) y Spreaker de Yoyo Fernández (https://www.spreaker.com/show/killall-radio).

Un acontecimiento que, si pudiera, no me lo perdería. No perdáis la ocasión.

Un proyecto en el que una inteligencia artificial es capaz de leer una partitura y “tocarla” al piano todo eso usando SUSE Linux Enterprise Server y openSUSE

La empresa SUSE una vez al año, permite a sus ingenieros, que dejen de lado sus obligaciones durante una semana y se dediquen a desarrollar y llevar a cabo un proyecto que tengan en mente.

Es lo que se conoce como Hack Week y en donde en las ediciones que han celebrado, en ocasiones se han desarrollado proyectos que más adelante han tenido entidad propia.

En otros casos los proyectos son retos personales de los ingenieros de SUSE, que quieren explorar otras áreas o unir varias de sus aficiones. Como el caso que veremos a continuación.

Este proyecto del HackWeek de SUSE está desarrollado por Lin Ma un ingeniero que trabaja en Virtualización dentro de SUSE y que en su proyecto ha aunado el espíritu hacker, maker y la música.

Esta es una traducción/adaptación del artículo original escrito en inglés por Chabowski y publicado en el sitio web de SUSE.

Introducción

Lin Ma ha decidido aunar en su proyecto para HackWeek, a la música y”machine learning” basado en SUSE Linux Enterprise Server. Una especie de Internet de las cosas (IoT) basado en productos de SUSE y openSUSE.

El proceso de cómo leer notas en una partitura y cómo tocarlas en un instrumento, puede ser muy complicado y tedioso.

El objetivo de este proyecto, es que “la máquina” pueda “leer” una partitura a partir de una imagen y después automáticamente traducirla y poder tocarla en un instrumento musical físico, en este caso un órgano eléctrico.

Componentes del proyecto

Para llevar a cabo el proyecto se necesitarán los siguientes elementos:

• Un servidor ARM 2280 HUAWEI TaiShan corriendo SUSE Linux Enterprise Server for Arm 15 SP1 y TensorFlow 1.4 (esto será necesario para los pasos 1 y 2)
• Raspberry Pi 3 corriendo openSUSE Tumbleweed for AArch64 7 Python 3 (esto será necesario para el paso 3)
• Un órgano eléctrico con 61 teclas
• Unos solenoides o electroválvulas (model 0730), x 21 (que harán la función de los dedos a la hora de tocar el piano)
• Un chip ULN 2803 driver, x 3

Cada solenoide puede ser activado por un pin GPIO de la  Raspberry Pi 3. Sin embargo cada modelo de la solenoide necesita unos 500 miliamperios para poder funcionar. Esto está fuera de las posibilidades de la Raspberry Pi 3, por eso se utilizan los chips ULN 2803 para activar los solenoides.

Pasos a seguir

Estos son los pasos a seguir:

Paso 1: Utilizar la red neuronal para la extracción de características de símbolos musicales de las imágenes de partituras que sirven como entrada.

Paso 2: Utilizar Optical Music Recognition (OMR) para reconocer las notaciones musicales obtenidas de la red neuronal y guardar los resultados en un archivo XML.

Paso 3: Recibir el archivo XML, mediante una red TCP y analizarlo. Y después activar los solenoides adecuados para tocar la partitura al piano.

Limitaciones del proyecto

Es un proyecto de una semana, por lo que no pueden abarcarse y poder tocar todas las notas del piano. Debido a limitaciones de los elementos físicos, el piano solo podrá tocar 3 octavas, y no podrá tocar semitonos (las teclas negras de los pianos)

Tampoco se ha investigado en cómo reducir el ruido que producen los propios solenoides cuando son activados, a la hora de tocar las notas.

Se ha escogido un servidor TaiShan para correr la red neuronal, por ser más rápido en el proceso. Para una misma imagen de partitura, el analizarla en el servidor TaiShan duraba 30 segundos, mientras que hacerlo en una Raspberry Pi 3 duraba 8 minutos.

Resultados

Después de todo, el piano inteligente era capaz de tocar algunas melodías como estas, después de analizar sus respectivas partituras (vídeos con enlaces a YouTube)

Nuevo aspecto para planet.opensuse.org el agregador de blogs de la comunidad openSUSE

Hace unos años, eran común encontrarse diversos “planetas” relacionados con diferentes temáticas. Esos “planetas” no eran más que sitios que recopilaban artículos de blogs relacionados con la temática del sitio.

Todavía existen, pero creo que se usan menos. Sin embargo, en diversos proyectos de software libre todavía se mantienen esos “planetas” o “planets” para recopilar los artículos que escriben en sus blogs personales las personas que forman parte del proyecto.

Ese es el caso de planet.opensuse.org, el agregador de blogs de la comunidad openSUSE, donde encontrarás artículos escritos por miembros de la comunidad de openSUSE en todo el mundo.

Los artículos no siempre tienen que estar relacionados con openSUSE, aunque ya que a las personas que escriben se les supone un interés por esta distribución de GNU/Linux, cabe pensar que de vez en cuando sí se toquen temas relacionados con la distribución.

Bien sean tutoriales, noticias, u otro tema que los diferentes escritores de blogs personales quieran tratar, estos aparecerán recopilados y centralizados en ese “planet”, como medio de difusión a toda la comunidad.

Esos “planets” también suelen tener una dirección RSS a la que suscribirse, y a la que llegarán las novedades que se vayan publicando, estando así al día de (parte) de lo que ocurre en la comunidad y alguien se anime a escribirlo en su blog.

Esta entrada, es tanto para recordar, que planet.opensuse.org sigue activo, y que además ha renovado su imagen, cambiando su anterior plantilla, por una página construida sobre Jekyll.

Básicamente es lo mismo, pero adaptando el tema visual y añadiendo ciertas mejoras. Tiene un tema claro y otro oscuro (dependiendo de si utilizas un tema oscuro en tu escritorio)

El “planet” es un sitio vivo que sigue admitiendo la incorporación de nuevos blogs. Una buena forma de darte a conocer y difundir tu material si escribes mayoritariamente sobre openSUSE.

Mi blog, desde hace tiempo está entre los blogs que llenan de contenido el “planeta” de openSUSE.

Si quieres incluir tu blog, puedes seguir las instrucciones de la wiki de openSUSE. También está disponible el código fuente del planeta en un repositorio de GitHub para utilizarlo para tu propio planeta si quieres, ya que está publicado bajo una licencia GPL.2.0

También aprovecho para recordarte, que hace un tiempo puse en marcha PlanetaLibre, gracias al código de Selairi, un agregador de noticias de webs y blogs relacionados con software libre y/o GNU/Linux y escritos en Español:

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

Nos leemos en el planet.opensuse.org o en planetalibre… o por aquí mismo!!

Creo que no tiene nada que ver con la causa de estos días de confinamiento mundial pero acabo de descubrir que la suite educativa GCompris Qt está disponible de forma gratuita para todas las plataformas, una buena noticia en estos tiempos de crisis.

GCompris Qt está disponible de forma gratuita para todas las plataformas

Desde el pasado mes de febrero el equipo de desarrolladores decidieron que era el momento de que la suite educativa GCompris estuviera disponible de forma gratuita para todas las plataformas. Al mismo tiempo, esta decisión coincide con el 20 aniversario de desarrollo de la aplicación y, además, con un periodo de confinamiento mundial por el COVID-19, aunque esta decisión fue previa a las drásticas medidas que se han adoptado recientemente.

Hay que decir que antes GCompris era gratuirta para plataformas GNU/Linux, pero no para dispositivos Android, Windows o macOS, lo cual dejaba (lamentablemetne) a muchos niños y niñas sin posibilidad al completo de la aplicación.

El anuncio oficial fue el siguiente:

«¡Hola!
Nos complace anunciar que la versión completa de GCompris está ahora disponible sin ningún tipo de coste para todas las plataformas soportadas.

Los instaladores para Windows y macOS que hay en nuestra web se han actualizado para que no soliciten código de activación. Además, la versión completa de Play Store y de Microsoft Store son ahora gratuitas.

Esperamos que este movimiento facilite a todos los niños del mundo el acceso al mejor software educativo.

Gracias a todos,
Timothée y Johnny»

Una más que excelente noticia para que todos las niñas y niños del mundo puedan disfrutar de un Software educativo completo, variado, divertido y en casi cualquier idioma en estos tiempo de confinamiento en casa. Mi hijo lo está disfrutando.

¿Qué es GCompris?

Más información: GCompris

Lange wurde über eLearning diskutiert, aber wenig gemacht. Jetzt, zu Zeiten der Corona Krise, brauchen wir dringend eine Lösung.

Dieser Blog soll zeigen, was diesbezüglich mit einer normalen ownCloud Installation zu erreichen ist, ohne dass langes Kennenlernen der Plattform für alle Beteiligten nötig ist.

Es wird eine wirklich einfache Variante gezeigt, die schnell an den Start gebracht werden kann, mit der aber schon erstaunlich viel möglich ist.

Das interessante ist, dass nicht nur Inhalte zur Verfügung gestellt werden können (das ist, was auf Youtube passiert), sondern dass es zusätzlich einen Weg für Schüler gibt, ihre Ergebnisse zur Ansicht und Korrektur zurückzuliefern.

Darüberhinaus gibt es noch eine einfache Dialog-Möglichkeit, um einzelne Dateien zu kommentieren.

Damit besteht eine Feedback Schleife zwischen Schüler und Lehrer, die natürlich nicht an persönlichen Unterricht heranreicht, aber besser als z.B. Mailkommunikation ist.

Dieses System kann nicht nur Schul-Lehrern helfen, sondern auch anderen Berufsgruppen wie Instrumenten-Lehrern oder Physiotherapeuten, die damit den Patienten per Video etwas zeigen und dann Hinweise auf Basis der zurückgeschickten Dateien geben können.

ownCloud als Trainings-Platform

ownCloud ist eine open source Infrastruktur zum Betreiben von sog. privaten Cloud-Speicher, mit denen Daten zwischen Rechnern synchronisiert und mit anderen sehr einfach geteilt werden können.

Mit seinen Möglichkeiten zur Zusammenarbeit bietet es alles, was für die Aufgabenstellung eines einfachen eTrainings notwendig ist.

Dateien teilen

ownCloud stellt als zentralen Baustein der ganzen Idee das sog. *File Sharing* zur Verfügung. Das bedeutet, dass ein Benutzer in der Cloud einem anderen sehr einfach Zugriff auf seine Dateien geben kann, ohne die zu kopieren oder hin- und herzuschicken.

Frau Teacher teilt ein Verzeichnis mit Schülerin Felizitas

Dazu legt der Lehrer in seiner ownCloud für jeden seiner Schüler ein Verzeichnis an, in das Dokumente oder Videos für einen Schüler gespeichert werden. Mittels des *File Sharings* kann der Lehrer dieses Verzeichnis nun per Klick mit dem entsprechenden Schüler teilen. Das bedeutet, dass das Verzeichnis des Lehrers im ownCloud-Zugang des Schülers „auftaucht“.

Der Schüler hat damit Zugriff auf den Inhalt, den der Lehrer für ihn zur Verfügung gestellt hat. Er kann Dokumente herunterladen und zB. Videos ansehen.

Mit ownClouds Fähigkeit, Benutzer in Gruppen zu organisieren, können Inhalte genauso einfach zB. gleich für eine ganze Klasse zur Verfügung gestellt werden. Dazu muss das entsprechende Verzeichnis nicht mit einem individuellen Benutzer wie Felizitas geteilt werden, sondern mit einer Gruppe, in der zum Beispiel alle Geigenschüler zusammengefasst sind.

Feedback

Kommentarfunktion

Nun ist es aber auch möglich, dass der Schüler eine Datei in den vom Lehrer geteilten Folder zurücklegt. Das geschieht durch Hochladen einer Datei in das Verzeichnis. Das kann z.B. ein bearbeitetes und gescanntes Papier sein oder auch ein kurzes Video.

Der Lehrer kann nun nachvollziehen, was der Schüler mit den Lerninhalten erreicht hat und seinerseits Feedback geben.

Kommentare

Ein in diesem Zusammenhang nützliches Feature ist die Kommentar-Funktion, die ownCloud auf Datei-Ebene zur Verfügung stellt. Damit können von jedem Benutzer Kommentare zu einer Datei geschrieben werden.

Im Falle der geteilten Inhalte ist dann ein einfacher Dialog um die verschiedenen Dateien leicht möglich.

Ausblick

Dies ist erst der Anfang – ownCloud hat als erfolgreiches open source Projekt noch eine Vielzahl von mehr Möglichkeiten, aber mit diesen wenigen Schritten sollte schon ein rudimentärer eTraining Ablauf möglich sein, der Schüler und Lehrer schnell und relativ unkompliziert wieder zusammenbringt, wenn persönlicher Kontakt nicht möglich ist.

Weitere Features wie File-Tags, Gruppenmanagement, Ablaufdaten etc. können im weiteren Verlauf hinzugenommen werden.

Jadi kapan hari menjenguk duo R, dan keinget kalau ada “harta” lama yang gak dipakai. Jadinya saya minta dan dicoba dihidupkan. Macbook2,1. Laptop jaman Pak Beye kata teman saya.

Ini komputer cukup nyusahin. Kalau pakai MacOS X mentok di Lion. Walhasil gak bisa ngapa-ngapain, wong banyak aplikasi ndak support. Boot usb linux juga ndak mau, gak kayak Macbook keluaran baru yang mau boot linux. Dulu masang ubuntu lewat media CD. Berhubung sudah gak punya CD, alhasil menggunakan segala cara agar bisa boot. Cara termudah adalah memasang ubuntu dari komputer lain, lalu pindah disknya ke macbook jadul tersebut.

Bagaimana dengan OS Linux lainnya? susah … gak bisa kepasang. Kesimpulan akhir, karena grub yang terpasang di ubuntu itu grub-pc i386 (walaupun pakai arch 64 bit). Jadi yang mulus terpasang pertama kali adalah ubuntu.

Selanjutnya usaha agar memasang openSUSE Tumbleweed. Berbagai cara sudah digunakan, ketemu kesimpulan cara yang mujarab sebagai berikut:

1. Pasang opensuse (boot legacy, jangan uefi) pada disk (usb flashdisk) lain dengan komputer lain.
2. Sediakan partisi kosong ext4 di macbook jadul tersebut.
3. Salin isi usb flashdisk pada nomor 1 ke dalam partisi ext4 tadi. Salin dengan opsi -rapv biar kebawa semua atribut dan permission berkasnya.
4. Uji dengan chroot, kalau mulus berarti sudah benar.
5. Ubah fstab, sesuaikan dengan uuid yang baru, pindah motherboard/komputer akan membuat beda uuid.
6. Edit grub di ubuntu, sesuaikan.

Ribet kan? tapi seru, buat nambah kesibukan selama masa diam di rumah.

Ini nulisnya telat banget, juga males nulis banyak karena udah telat. Intinya sih pingin pamer kalau berhasil pergi ke FOSDEM 2020 di Belgia. Dan seru-seruan bersama teman-teman TDF/LibreOffice.

Foto lainnya masih banyak sih, tapi ndak minat ditaruh di sini.
Perjalanan ini ditanggung sepenuhnya oleh The Document Foundation (kecuali pembelian oleh-oleh).

Por segundo año consecutivo, el equipo de desarrolladores de Plasma Mobile realizó un encuentro para dinamizar su trabajo y así disminuir el tiempo que pase hasta que se tenga un Software de la Comunidad KDE preparado para teléfono móviles y tabletas.  Así que bienvenidos al resumen del Plasma Mobile Sprint 2020 de Berlin que se celebró a principios del mes de marzo y que parece que fue muy productivo.

Resumen del Plasma Mobile Sprint 2020 de Berlin

El mundo del Software Libre ya ha conquistado los superordenadores, el mundo de los de los servidores de internet, ha cimentado su dominio en el del Internet de las cosas y, muy poco a poco, va entrando en el día a día en los escritorios de los usuarios domésticos o, como mínimo, cualquier usuario que lo desee dispone de Software de Calidad para instalar en sus dispositivos.

Eso si, todavía hay un campo que todavía no ha alcanzado: los dispositivos móviles como smartphones o tabletas. Y es una pena ya que debido a este hecho no podemos decir que tenemos estamos libres de algunas compañías que se dedican a recopilar nuestros datos.

Afortunadamente, la Comunidad KDE va dando pasos con el objetivo de solucionar este problema con su proyecto Plasma Mobile, que sigue su desarrollo lento pero seguro.

De esta forma, como ya ocurrió en 2019, se han reunido en Berlín para realizar un Sprint (encuentro en el mundo real) para hablar, concretar líneas de trabajo y compartir unos días de convivencia llena de horas de hacking.

Algunas de las acciones que se realizaron en este Sprint o que se empezaron para seguir trabajando durante el próximo año fueron las siguientes:

• Marco Martin ha reescrito y mejorado en entorno básico del usuario. Os recomiendo su blog para ver más detalles.
• Mathis Brüchert ha ampliado los iconos de las aplicaciones de  Plasma Mobile.
• Jonah ha estado trabajando en hacer más amigable la interfaz para abrir o guardar ficheros, añadiendo una barra de favoritos al estilo de Dolphin.
• Aleix Pol implementó mejoras en los protocolos KWin/Wayland,
• Nuevas aplicaciones se han incorporado al proyecto:  Voicememo (una grabadora de audio) , un lector de RSS, mejoras en la cámara y en el dialer (marcador de números).

Además, uno de los días se dedicó a reunirse con dos desarrolladores de UBports (concretamente con  Marius Gripsgard y Dalton Durst) con el objetivo de mejorar la colaboración entre equipos y comunidades KDE yUBports.

Una de las conclusiones de este encuentro fue la necesidad de compartir ciertos protocolos comunes para compartir código y así mejorar la compatibilidad entre estas dos soluciones para móviles. Además, se pusieron las bases para que las aplicaciones desarrolladas por los programadores sean compatibles en ambas plataformas.

En resumen, un buen Sprint que se espere que de más impulso a este más que interesante y prometedor proyecto.

Más información: KDE