Me encanta cuando las aplicaciones toman impulso y empiezan a generar noticias alrededor de ella. Es por ello que me complace compartir con vosotros que ha sido lanzada la versión de Kalendar 0.1, es decir, la primera versión «estable» de un nuevo calendario de la Comunidad KDE para su entorno de trabajo.

Lanzada la versión de Kalendar 0.1

En palabras de sus desarrolladores:

¡Así es! Kalendar está ahora en la versión 0.1, y tenemos un primer lanzamiento. Todavía nos queda mucho por trabajar antes de llegar a la 1.0, ¡pero lo estamos consiguiendo!

Si nos vamos a la página web podremos ver un registro de cambios verdaderamente titánico desde las últimas dos semanas.

Hay cambios grandes y un montón de otros más pequeños hacen que Kalendar sea mejor que nunca (lo cual es algo lógico en una nueva aplicación) y debería significar una beta que es mejora significativa sobre las anteriores versiones.

No obstante hay que recordar que Kalendar está todavía en pleno desarrollo. Eres libre de probarlo, pero aún no es un software final. Si quieres contribuir a su desarrollo, únete a los desarrolladores en la sala Matrix de Kalendar.

Entra las novedades más destacadas podemos encontrarnos:

• Revisión de la asignación de modelos en las vistas y gestión centralizada de los mismos, que traducido para los mortales significa mayor rapidez a la hora de cargar, cambiar las vistas y cambiar las fechas de lo que era antes.
• Ahora puedes importar archivos iCal (.ics) a Kalendar.
• Mejoras en las animaciones que hacen que la aplicación se mueva de forma más suave.
• Mejoras de la barra lateral.
• La vista de tareas es más rápida y bonita que nunca.
• Mejoras visuales que hacen más clara la vista semanal.
• El editor de acontecimientos es más rápido y mucho más estable.

Como podemos ver, muchas mejoras que auguran un gran futuro de este software.

Introduction

During 2021 we have been starting to focus more in security for MicroOS. By default MicroOS is a fairly secure distribution: during the development all the changes are publicly reviewed, fixes (including CVEs) are integrated first (or at the same time) in Tumbleweed, we have read-only root system and a tool to recover old snapshots, and periodically the security team audit some of the new components. Also, the move from AppArmor to SELinux should help to standardize the security management.

But we really want to rise the bar when it is possible. For example, we are starting to think on how to enable IMA/EVM properly in the distribution, or what alternatives we have for full disk encryption supported by a TPM. There are some evaluation on dm-verity inside the new Transactional Image Update installer.

Another area where we make progress in MicroOS is how to measure the health of our systems, detect remotely when an unauthorized change has been made (remote attestation), and actuate over it globally and as fast as possible.

TPM as a root of trust

Today all our devices (laptops, desktops, servers, phone or tablets) includes a cryptoprocessor known as TPM (from the initials Trusted Platform Module). Sometimes is inside the CPU, but can also be found soldered in the motherboard or implemented as a software in our firmware. Those co-processors are really cheap (and sadly slow), but very useful when we want to design software that requires a hardware based root of trust.

For example, imagine that we want to encrypt the disk but we do not want to be asked for the password at the beginning of the boot. We should need some trusted component that can provide the password very early in the boot process, and that the system can - somehow - validate that it is the real deal and not some other agent trying to impersonate it. A TPM provides mechanisms to do this validation, and if every this goes OK to unseal the password to the kernel so it can decrypt the disk.

This same role is required for many other operations, like accessing to a VPN that requires the validation of the combination machine / user. Because of how the TPMs are designed, they can generate keys that we can check that comes from this specific TPM and no other. This property is valuable to open the access to the internal network, for example.

Another activity where a root of trust is require is when we need to validate the health of our systems via measured boot.

Measured Boot and remote attestation

The general mechanism goes like this: during the boot process, a very early piece of the firmware takes care of initializing some hardware components and setting some clocks, and when is done, before delegating the execution to the next stage (maybe some early stage in the UEFI firmware), it will load in memory this next stage and will calculate a hash of it (like SHA256), and will communicate this information to some piece of hardware that we trust (the TPM in this case). This component can now delegate the boot process to this second stage, that will do the same operation when needs to move to the third stage (load, measure and communicate the measurement to the TPM), and this goes on until Grub2 enter in action and load the kernel.

If we do this we effectively have a measurement of every step in the bootloader chain, from the most early stage deep in the firmware until (and included) the kernel. This process is known “measured boot”. And the TPM have a record of all those measurements!

Actually I am lying (well, sort off, as we will see a bit later).

TPMs are cheap and do not have a lot of space inside, so the TPM by itself cannot have the full record of measurement. Inside the TPM we have some registers known as platform configuration registers (PCR) that have one feature: we can read them, but we cannot directly write on them. To change the value of a register we have an operation known as extension, that can be viewed as taking the current value of the register, attaching at the end the value of the hash that we want to extend with (in this case the measurement done), and calculating the hash of the full string (again, like SHA256). This new value calculated is the one that will be stored in the PCR instead.

This extend operation makes that the current value of the PCR depends on all the previous values of it and the values (measurements) used before. So in order to replicate a value we need to know the correct measurement of each stage of the boot chain (including the initial value of the PCR after the reset, that is usually 0x00..0).

The goal here is that once all is booted, the user can ask for those PCR values to the TPM via another operation named quote. This operation returns a report signed by a key that only the TPM knows, and that I can validate to see if, indeed, comes from my TPM or not. I can later compare the PCR values with the ones that I expect for my current version of UEFI, Grub2 and kernel. If they match I know for sure that the boot chain has not been tampered, and if do not match … well … we have been hacked (or we have an unauthorized updated somewhere that we need to check).

To be honest, comparing raw PCR values is hard. If we do not know all the measurements of our boot chain, they are impossible to predict.

This is why for each measurement, from the UEFI until the kernel, besides extending a PCR register in the TPM we are also storing in memory a log of all those measurements. We register (in the normal memory) some bits extra of information used during the measurement, like the PCR number and the value used for the extension. We can also see in the log some signatures found (and expected if we are using secure boot), text data (for example the kernel command line used in Grub2), etc.

This log will be passed between stages until it reaches the kernel, that will make is available to the user space via the security file system. This log is known as the event log.

Another point here is that we can now ask, remotely from a different machine, the current values of the PCRs via a quote to the TPM, and the full content of the event log. With this information we can attest remotely that the system has not been compromised during the boot process. Of course, this is known as remote attestation.

Keylime

If we have a device with a TPM we can go to the BIOS / UEFI boot menu and activate it. After that, every boot of this system will be measured as described here, and we can do the attestation ourselves requesting a quote to TPM (via the tpm2.0-tool package in MicroOS) and comparing the values with the event log.

But this is cannot scale properly, we need a tool to help us doing this automatically.

Keylime is an open source project designed to do exactly what we need: do remote attestation of our devices, using a TPM as a root of trust of all the measurements.

In Keylime we have some services available. The agent is the service that needs to be installed in all of the nodes that we want to monitor. This service is responsible of collecting some data (TPM quotes, event log, IMA logs, etc) under demand.

This information is requested by another service known as verifier, that will validate this data based on some user provide information.

For example, it will check that the PCR values are the expected ones. It can also inspect the event log using an user provided policy (as a Python code) that will search for some signatures, will see the Grub menu used for booting and will compare some of the measurements that known of (like the kernel one, for example).

Also, if IMA is enabled in the remote node, it can validate the hashes of all the programs and services that we are running!

With Keylime we can deploy secrets to our nodes (like certificates or keys), and we can execute user-defined actions when we detect an unauthorized change in our nodes.

For example, if Keylime detect the execution of a program with a different IMA hash that the one expected, we can execute a program that will try to isolate this node from their peers, and will revoke any access to the shared resources in the network, like databases.

The good news is that Keylime has been integrated in MicroOS via two new system roles in YaST. During the installation we can see know two new roles, one should be used for the nodes that we want to monitor (agent role), and the other for the node that will take care of collecting the information of the agents, doing the verification and triggering the revocation actions when required (verifier role).

Those roles make very easy to start doing remote attestation in MicroOS today and the process is fully documented.

More information!

We documented all this information (and more) in the MicroOS portal. There you can find a more technical description, including how to configure the agent services in order that they can find the verifier, how to enable IMA in the nodes and prepare a white list of hashes, and how to write programs that can acts when an intrusion has been detected.

There is also some more details about the TPM and how to check if they are present in the system and recognized by MicroOS.

Also recently we had the SUSE Labs 2021 conference, and all the videos has been published recently, including a talk about Keylime and TPM in the context of MicroOS that you can check. In the proceedings of this conference there is also a paper that can be useful to complement this topic!

Macchina es una interfaz para la línea de comandos que muestra información de tu sistema GNU/Linux de manera rápida, mínima y personalizable

Software para GNU/Linux para mostrar información de manera más o menos gráfica en una terminal hay varias opciones: neofetch, screenfetch por poner un par de ejemplos.

Y en este artículo vengo a hablar sobre otra opción más ligera y más rápida llamada macchina.

Macchina está empaquetada para openSUSE, así que para esta distribución de GNU/Linux está disponible desde los repositorios.

Es un software escrito en Rust multiplataforma disponible para GNU/Linux, FreeBSD y otros sistemas privativos, incluso Android publicado bajo una licencia MIT.

macchina te permite ver la información del sistema, como la versión del kernel de tu equipo, el tiempo de actividad, el uso de la memoria, la carga del procesador y mucho más desde la línea de comandos de una manera rápida y muy facilmente.

Macchina, además de la propia interfaz que muestra la información, también se desarrolla una biblioteca para obtener información del sistema, echa un vistazo a libmacchina

Una vez instalado, al ejecutarlo, el software nos muestra la información de nuestro sistema. Pero lo bueno, es que podemos dedicarle un tiempo a configurarlo a nuestros gustos y aplicar temas y colores que nos gusten.

He creado una carpeta llamada ~/.config/macchina y dentro he creado un archivo de configuración llamado macchina.toml donde ir configurando el comportamiento de la herramienta y configurar el tema que quiero que muestre.

Para los temas he creado una carpeta llamada ~/.config/macchina/themes y ahí he copiado un tema llamado hydrogen.toml de muestra sobre el que he ido configurando cosas a mi gusto para dejarlo como la imagen que encabeza el artículo.

Para saber más sobre cómo configurar macchina o aprender más para crear tus propios temas puedes visitar la wiki del proyecto que tiene toda esa información.

Macchina es una de esas herramientas que utilizamos los GNU/Linuxeros a la hora de poner una captura de pantalla de nuestro sistema o nuestra terminal y con la que puedes darle un toque distinto y exclusivo. ¿Te animas a instalarla?

En este domingo, cercano ya a la Akademy-es 2021, me complace presentar un el episodio #142 «I Encuentro Podcast Linux» del podcast del mismo nombre, presentado por el increíble Juan Febles. Un audio muy especial por las razones que contaremos a continuación.

I Encuentro Podcast Linux, episodio #142

En esta ocasión, no voy a de decir nada en la introducción y me fío íntegramente en las palabras de Juan Febles.

¡¡¡Muy buenas amante del Software Libre!!!
Bienvenido a otra entrega, la número 142, de Podcast Linux. Un saludo muy fuerte de quien te habla, Juan Febles. Hoy estrenamos formato: Encuentros Podcast Linux. Inauguramos un espacio para la audiencia a través de un chat de audio.

Recordar a los oyentes que estamos en una sala Jam para este encuentro, un servicio libre de salas de audio, y que este podcast aloja su web en Gitlab, un servicio libre de repositorios git y su contenido en Archive.org, la biblioteca digital libre con licencias Creative Commons.

De esta forma Juan nos presenta un podcast diferente, basado en utilizar la la sala Jam para establecer una conversación con diferentes participantes en el Encuentro para comprobar las bondades de este servicio. Y los participantes en el mismo no son moco de pavo, encontrándonos a Elav de System Inside, Yoyo Fernández de Salmorejo Geek, Paco Estrada de Compilando Podcast, José Jiménez de 24h24l y el gran Víctorhck, del blog Victorhck in the free world.

Enlaces:

• Gitlab Jam: https://gitlab.com/jam-systems/jam
• Servidor Jam: https://jam.systems/
• Evento 24H24L: https://24h24l.org/
• Distro Hiperbola: https://www.hyperbola.info/

Así que os invito a escuchar esta charla distendida de un buen número de amantes del Software Libre (algunos muy conocidos) con Juan Febles de casi hora y media que seguro que no os defraudará. ¡Dentro audio!

.

Más información: Podcast Linux

Sigue a Podcast Linux

Aprovecho para animaros a seguir Podcast Linux en algunos de los canales de comunicación que tiene:

• Twitter: https://twitter.com/podcastlinux
• Mastodon: https://mastodon.social/@podcastlinux/
• Correo: podcastlinux@disroot.org
• Web: https://podcastlinux.com/
• Telegram: https://t.me/podcastlinux
• Telegram Juan Febles: https://t.me/juanfebles
• Youtube: https://www.youtube.com/PodcastLinux
• Feed Podcast Linux: https://podcastlinux.com/feed
• Feed Linux Express (Audios Telegram): https://podcastlinux.com/Linux-Express/feed

Me congratula promocionar una nueva charla y taller «Install Party» en en Los Anguijes (Albacete) organizada por Asociació Emanciació Comunitaria, con la colaboración de la Asociación GNU/Linux València. Se trata de una nueva edición de la que ya realizaron el pasado 21 de agosto y realizarán el domingo 19 de septiembre. Más información, sigue leyendo.

Nueva charla y taller «Install Party» en Algemesí (València) organizada por Asociació Emanciació Comunitaria

Parece ser que poco a poco vuelve la normalidad en cuanto a actividades presenciales de la comunidad GNU/Linux. Eso si, con todas las medidas de seguridad que sean necesarias.

Es por ello que me complace compartir con vosotros un nuevo evento del grupo de personas que en València está impulsado el Software Libre y temas relacionados con el empoderamiento de la sociedad que lleva por nombre Asociació Emanciació Comunitaria, que podéis encontrar en su Grupo y Canal de Telegram.

Es por ello que os invito a la nueva charla y taller «Install Party» en Algemesí (València) que se va a realizar el próximo sábado 6 de noviembre organizado conjuntamente con Mercat 10 (https://t.me/mercat10), que vuelve a tener como lema «Para una sociedad libre necesitamos una tecnología que no esté controlada por el poder».

De esta forma se han organizado varias actividades:

• 17:00 h: Charla sobre el Software Libre, donde se explicará la importancia del software libre en una comunidad con democracia real
• A continuación: Taller Install Party, al que podréis LLEVAR VUESTRO EQUIPO y os ayudaremos a instalar un Sistema Operativo COMPLETAMENTE LIBRE!! · ◡ · además de otras herramientas. que nos permiten independencia de aquellas controladas por instituciones, empresas y estados.

Resumiendo, la información básica es:

• Fecha: sábado, 6 de noviembre de 2021
• Horario: A partir de las 17:00
• Lugar: Plaça del Mercat, 10 Algemesí (València)
• ¿Registro necesario? Si, plazas limitadas. Reserva en los siguientes teléfonos 667 059 956 Inma, 644 131 338 Juan

Si podéis asistir no os lo perdáis, seguro que no quedáis decepcionados.

Tumbleweed es una distribución «Rolling Release» 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.

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/2021/11/opensuse-tumbleweed-review-of-the-week-2021-44/

En esta parte del mundo el tiempo empieza ha enfriarse, las horas de luz van disminuyendo lo que hace que no haya ganas de salir de casa, por lo que los desarrolladores, y encargados de paquetes de software tienen más tiempo para dedicarle.

Esto ha provocado que esta semana se hayan publicado 6 snapshots (la número 7 se hubo de descartar debido a problemas de instalación de vi). Las snapshots publicadas fueron 1028, 1029, 1030, 1031, 1101 y 1102.

Los cambios más relevantes que trajeron han sido:

• pcre2 10.38
• KDE Plasma 5.23.2
• pipewire 0.3.39
• Mesa 21.2.5
• Bison 3.8.2
• GDB 11.1
• Meson 0.59.3

Y los cambios que llegarán en próximas actualizaciones serán entre otros:

• Mozilla Thunderbird 91.3.0
• Mozilla Firefox 94.0
• KDE Gear 21.08.3
• Más mejoras en rpmlint 2
• Bash
• Meson 0.59.4
• Linux kernel 5.15
• tbb 2021.4
• gc 8.2.0
• X.org server 21.1
• Coreutils 9.0
• openSSL 3.0

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?
    • Comprueba la valoración de las «snapshots» de Tumbleweed
    • ¿Qué es el test openQA?
    • http://download.opensuse.org/tumbleweed/iso/
    • https://es.opensuse.org/Portal:Tumbleweed

——————————–

Dear Tumbleweed users and hackers,

The weather is getting colder, days shorter, motivation to go outside is shrinking. Which leaves more time in front of the computer, helping Tumbleweed roll. And roll it did during the last week! We have published 6 snapshots (number 7 needed to be discarded due to vi installation issues). The snapshots released were numbered 1028, 1029, 1030, 1031, 1101, and 1102.

The most relevant updates shipped as part of those snapshots were:

• pcre2 10.38 (I wish we could get rid of the old pcre 8.x version at least in the bootstrap cycle)
• KDE Plasma 5.23.2
• pipewire 0.3.39
• Mesa 21.2.5
• Bison 3.8.2
• GDB 11.1
• Meson 0.59.3

Staging projects are almost all filled up, you can expect changes like these in the near (for most parts) future:

• Mozilla Thunderbird 91.3.0
• Mozilla Firefox 94.0
• KDE Gear 21.08.3
• More improvements to rpmlint 2: next up: Fix “no-library-dependency-for” errors
• Bash: moving away from update-alternatives to handle /bin/sh; To allow busybox to step in as ‘sh’ provider, we are switching to a package replacement model (e.g. bash-sh, bysybox-sh). Those packages will install the relevant /bin/sh symlinks
• Meson 0.59.4 (followed by the stricter 0.60 branch)
• Linux kernel 5.15
• tbb 2021.4: breaks opencv3
• gc 8.2.0: breaks texlive and guile
• X.org server 21.1: causes some havon on openQA as font rendering changed due to DPI reporting changes
• Coreutils 9.0
• openSSL 3.0

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

Tercera actualización de KDE Gear 21.08

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

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

Con esta filosofía de trabajo gana en rapidez y evolución pero a cambio puede aumentar el número de errores (por norma general) leves, los cuales son subsanables con pequeñas actualizaciones que se realizan periódicamente.

La Comunidad KDE lo tiene claro: grandes lanzamientos cada cuatro meses con grandes mejoras y nuevas funcionalidades, y actualizaciones mensuales para subsanar errores y mejorar las traducciones, que como es comprensible, siempre van un poco por detrás de las aplicaciones.

Por ello me congratula compartir con vosotros la tercera actualización de KDE Gear 21.08 que nos ofrece un buen número de errores resueltos entre aplicaciones, librerías y widgets, algo que mejora el rendimiento del sistema.

Si queréis ver la lista completa de cambios os recomiendo visitar la changelog donde los podéis encontrar todos, destacando en su número los de Kdenlve, KItineary, tinearary y Okular.

Más información: KDE Gear 21.08

Most people know me as a Linux and/or FreeBSD guy, and they are right. I use openSUSE and FreeBSD most of my time. However, I am not a fanatic who tries to solve everything using a single OS and I am curious as well. Most other operating systems I use are running in virtual machines, but I also have two computers: a Windows desktop and an old MacBook Pro. Both received a major software upgrade during the weekend. Or did they?

Windows 11

While Microsoft promised that the Windows 11 roll-out will take a year with most users receiving it only next year, my desktop received the possibility to upgrade just three weeks after release. I have many applications that proved to be problematic during earlier Windows updates. My main application is Capture One, a photo editing software. There are also many audio applications, traditionally even more sensitive to any kind of change in the operating system: Ableton Live and software synthesizers from Native Instruments, Expressive-E, Cherry Audio, and others.

I took a big breath and started the upgrade process. It went perfectly well. There were a couple of reboots and that’s all. Well, maybe a bit more. Once Windows 11 was installed, there were many updates available for it, and as I have an AMD Ryzen-based system and many of the updates were AMD-related, I quickly installed all updates as well. Once the installation and updates were ready, I started to test and clean-up the system. I deleted many of the freshly installed applications and cleaned up the start menu. After testing if the most critical applications still work, I did a disk clean-up to remove temporary files, the previous version of Windows and so on.

Out of all my Windows updates, this was the least drastic and problematic. Of course, there are some visible changes in Windows, but luckily not too much. I moved back the start menu to the left. Most of the changes made the whole system more logical, and much of the chaos around configuring Windows is resolved. Best of all: an already extremely fast machine now feels even faster.

MacOS Monterey

A couple of years ago I bought a MacBook Pro. I hate Apple products for many reasons: they are very expensive, and as a technical user I find that they are not too flexible. Still, there are quite a few people who like Macs and even would love to run syslog-ng on them, so I mostly bought my MacBook Pro to test and compile syslog-ng on it. However, just like any of my other devices, I use it for music too. I have a Moog software synthesizer running together with Garage Band, and I also use it for TIDAL, as out of all my TIDAL-capable devices, this one has the best headphone amplifier. :-)

The upgrade to Monterey was not so smooth. When I first started it, it was a 2.5GB download, but the installation failed. My second attempt had a 12.5GB download and while it was a bit slower, it was successful. I must admit that I did not notice any changes after the OS upgrade, but that’s no wonder: the look and feel stayed the same and I do not use the apps that changed.

I tried the Moog synth and a few more apps and they worked just fine. However, homebrew breaks with all kinds of strange errors. As it is needed to compile syslog-ng, I will investigate it, but that’s something for next week. Now I enjoy the long weekend and use my MacBook Pro only for music.

What’s next?

Windows 11 has WSL 2. It means that Linux is practically running in a virtual machine and behind a NAT. WSL 2 provides close to native performance, so I will try to figure out if I can run an externally available syslog-ng server inside.

On the latest MacOS I’ll most likely reinstall homebrew from scratch, and then check if syslog-ng still compiles and works.

Hoy me complace presentaros el nuevo cliente de Telegram para KDE que ha recibido el nombre de Tok, y que promete más integración con Plasma. La Comunidad KDE nunca deja de buscar la excelencia.

Nuevo cliente de Telegram para KDE, con todos ustedes: Tok

Como he comentado anteriormente, Telegram se ha convertido en la forma de comunicación favorita entre los linuxeros, al menos de los que nuevos y de los que buscamos llegar a mucha gente. De esta forma se han creado Canales y grupos (algunos de los cuales sirven para seguir a KDE); se han diseñado y programado stickers y bots, Y otras decenas de servicios más florecen en la red de comunicación desarrollada, según la Wikipedia,  desde el 2013 por los hermanos Nikolái y Pável Dúrov.

Ya sabemos que no es la forma más libre de todas, ya que Matrix (con el permiso de Signal) de momento se lleva ese título. La Comunidad KDE ya la ha adoptado y está realizando la migración a este sistema de mensajería libre, creando su propio cliente para Plasma llamado NeoChat.

No obstante, los desarrolladores KDE piensan que vale la pena invertir tiempo en tener un nuevo cliente de Telegram para el escritorio Plasma y han creado Tok, una versión que es compatible tanto para dispositivos móviles como para escritorios.

Evidentemente con Tok podrás hacer todo lo que sueles hacer con tu cliente de Telegram, con la diferencia que estará integrado en el escritorio Plasma y que utilizará menos recursos y librerías de terceros.

Si queréis probarlo debéis informaros de su desarrollo en la siguiente página del Invent de KDE, y si queréis verlo en funcionamiento nada mejor que este vídeo de Niccolò Ve que le ha dedicado a la aplicación y que ha colgado, entre otros sitios, en el canal de vídeo Peertube de la Comunidad KDE llamado Kockatoo Tube.