Ayer fue lanzado y es el momento de ir comentando las nuevas funcionalidades. Bienvenidos a las novedades generales de Plasma 5.18 LTS, un vistazo a todo lo que nos han preparado los desarrolladores de la Comunidad y que será afinado a lo largo de los 2 años de soporte para este nuevo escritorio.

Novedades generales de Plasma 5.18 LTS

Muchas son las novedades que nos ofrece el nuevo entorno de trabajo de la Comunidad KDE. Tantas que he decidido dividirlas en algunas entradas por eso de no hacer artículos extensos.

Empezaremos con las novedades generales, es decir, aquellas que afectan al sistema en general y no a una aplicación en particular. Pero antes, os sigo recomendando el vídeo de presentación de Plasma 5.18.

Nuevo selector de emoticonos

Entrando en detalles empezaremos con el selector de emoticonos, una funcionalidad que si bien parece a simple vista superflua es muy necesaria a la hora de comunicarnos correctamente en este mundo digital.

Lo más importante es que para activarlo lo tenemos muy fácil: pulsando la tecla «Meta» (casi siempre con el símbolo «Windows») al mismo tiempo que el punto («.»). Ahora simplemente se pincha sobre el icono y ya queda pegado en el portapapeles. Se pega donde se desee (correo electrónico, en la web en un mensaje de texto e incluso en la consola).

El selector es simple pero eficiente ya que tiene una pestaña con los iconos seleccionados recientes, una barra de búsqueda y la posibilidad de ver diferentes categorías.

Evidentemente, también se puede encontrar en Aplicaciones → Utilidades. Queda todavía integrarlo en las Preferencias del Sistema.

La barra de Edición global

Hemos de despedir en esta versión de Plasma 5.18 a la antigua caja de herramientas del escritorio, esa especie de judía (al principio) o tres rayitas (al final) que se asomaba en una esquina del escritorio.

Ahora nos encontramos con la barra de Edición global, que se activa pulsando con el botón derecho del ratón en cualquier área vacía del escritorio y escogiendo Personalizar el diseño en el menú emergente.

La barra de Edición global aparecerá en la parte superior de la pantalla y nos dará acceso a los plasmoides, las actividades y al conjunto de opciones de configuración de la pantalla (sobre todo el fondo de la misma).

Un pequeño cambio que contribuye aún más a dejar a nuestro gusto nuestro escritorio.

Mejoras en la aplicaciones GTK

Un aspecto crítico en el ecosistema KDE es la integración de todas las aplicaciones. Afortunadamente, desde hace muchas versiones esto va afinándose cada vez más y este Plasma 5.18 no es ninguna excepción.

De esta forma, este nuevo escritorio viene con un mejor soporte de las aplicaciones de GTK (es decir, aquellas que vienen del proyecto Gnome). Ahora estas aplicaciones muestran sombras correctas y sus áreas de redimensionado. Además, las aplicaciones de GTK heredan de forma automática las preferencias de Plasma sobre tipos de letra, iconos y cursores del ratón, entre otras cosas.

Nuevo plasmoide color nocturno y mejoras en el del volumen

Si en el anterior Plasma 5.17 se ganó la opción de ajuste automático del color para relajar nuestros ojos, ahora existe un nuevo plasmoide en la bandeja del sistema que nos permite controlar esta funcionalidad

Además, el plasmoide volumen del sonido del sistema muestra ahora un diseño más compacto que hace que sea más fácil elegir el dispositivo de sonido predeterminado. También existe un indicador de volumen para las aplicaciones que se muestran en el gestor de tareas que estén reproduciendo sonido.

Como vemos, esto no para de mejorar y afinarse versión a versión. ¡Esto es KDE!

Más información: KDE

Echemos un vistazo a fish la shell para sistemas GNU/Linux que con sus sugerencias y autocompletados es más amigable e interactiva con los usuarios.

Bash es la shell omnipresente en todos los sistemas GNU/Linux y seguro que la predeterminada en tu distribución de GNU/Linux.

Quizás por eso es la shell preferida por los lectores de mi blog y por muchos otros geeks por amplia mayoría. Pero frente a este “monopolio” existen otras alternativas, algunas poco conocidas como es por ejemplo fish.

Fish en esa encuesta improvisada en mi blog y en Mastodon ocupaba puestos relegados a las opciones menos numerosas, quizás por desconocimiento, quizás por incompatibilidad con Bash, quizás por otros motivos…

Pero este es un blog amigo mío de minorías, minorías en cuanto a la elección de temas a tratar, de noticias sobre las que escribir y en número de lectores y visitas… así que disfrutemos de esas minorías y centremos el foco en esa parte de la fotografía que está oscura o borrosa…

Sí, aun sabiendo que Bash es la opción mayoritaria, lo mejor sería escribir tutoriales sobre este Shell, pero lector o lectora, al ser mayoritaria hay muuuuchos artículos en la red que cubren ese aspecto que lo hacen muy bien.

Aun sabiendo que Fish es minoritaria, hoy quería dar un primer enfoque a esta shell. Como siempre advertir, que no soy experto de nada, no domino la materia, simplemente descubro, aprendo, y lo cuento en el blog.

Eres testigo de primera mano de aquello que voy aprendiendo, y en ocasiones aprendemos juntos. Ha sido así con mis artículos sobre openSUSE, sobre la Raspberry Pi, el editor Vim o cualquier otra serie sobre la que escribo o he escrito.

Si a ti que lees esto te parece interesante me alegro que así sea, y bienvenida o bienvenido a esta minoría… ¿Empezamos con fish?

La shell Fish debe su nombre a Friendly Interactive Shell, y es la shell que desde hace unas semanas estoy utilizando de manera predeterminada en mi openSUSE.

Seguro que está disponible un paquete para tu distribución, así que la instalas con tu gestor de paquetes y una vez finalizada ya puedes empezar a probarla. Puedes probar fish sin necesidad de hacer cambios en tu sistema, simplemente como una primera toma de contacto.

Una vez instalada, abre una consola y escribe fish, y ale! ya estarás utilizándola. Cuando cierres la consola, todo seguirá como antes, tu shell segurá siendo la que estabas utilizando, no te preocupes…

Lo que más llama la atención así de primeras es su resaltado de sintaxis, y su muy útil autocompletado de comandos, a golpe de tecla Tabulador, útil sobre todo para comandos largos que quieres volver a escribir, o que casi son iguales y quieres modificar alguna parte del mismo.

Puedes probar que los comandos que ya conocías de Bash siguen siendo útiles a la hora de cambiar entre carpetas, listar archivos, también funcionan las “tuberías” o redirecciones, entre comandos, tiene comandos como en Bash para hacer bucles condicionales, crear funciones,etc…

Pero lo que de verdad le da un punto a favor frente a Bash son las sugerencias de comandos en base a tu historial, el autocompletado de rutas o de comandos. Esto la verdad es que para mí me resulta muy útil.

Otro punto a favor, es que podemos configurar fish bien mediante sus archivos de configuración en .config/fish o mediante un “configurador” con una interfaz web ejecutando el comando fish_config

Así podremos configurar varios aspectos de nuestro prompt de fish, colores, y muchas otras opciones.

Además también tenemos disponible la instalación de un “framework” mediante el que poder instalar complementos, paquetes adicionales, etc, el llamado oh-my-fish

En resumen estas son algunos de los puntos a favor que encuentro para hacer de fish tu shell predeterminada… o aquella que utilizar en tu casa y usar Bash en tu trabajo (por ejemplo…)

Si el tema tiene tirón (dentro de la minoría en la que se mueven mis artículos) quizás publique más cosas sobre fish, pequeños tutoriales, o cosas que vaya aprendiendo y me resulten interesantes.

¿Qué opinas? Prueba fish y deja tus comentarios en el blog sobre tus impresiones… será interesante saber qué piensas al respecto.

Hoy estamos de alegría. Tal y como estaba previsto ha sido lanzado Plasma 5.18 LTS, la más puntera versión del escritorio Plasma, el entorno de trabajo de la Comunidad KDE, que viene cargado de novedades y que promete ser más fácil y más atractivo. Además, al ser una versión de soporte extendido (LTS) nos garantizará una estabilidad a prueba de bombas.

Lanzado Plasma 5.18 LTS, más fácil y más atractivo

La evolución del escritorio Plasma de la Comunidad KDE es un ejemplo de cómo hacer bien las cosas. De forma lenta pero constante, con ideas claras y dirección firme pero siempre atentos por una Comunidad diversa. Siendo ambiciosos para que

Atrás quedaron los tiempos de revoluciones y de saltos al vacío, como fue el paso de KDE 3 a KDE 4 (una decisión que a pesar de ser criticada los desarrolladores piensan que fue necesaria, y yo les creo), en la actualidad la continuidad prima frente al rupturismo. Y fruto de todo ello en un entorno de trabajo limpio, eficiente y productivo… sin dejar de lado su característica principal: la libertad del usuario para poder cambiarlo todo.

Así que, desde el 15 de julio de 2014 con el lanzamiento de Plasma 5.0, la Comunidad KDE está trabajando duro para llegar para a este 11 de febrero de 2020, fecha señalada en rojo porque ha sido lanzado Plasma 5.18 LTS. Un trabajo que se inició semanas antes del lanzamiento de Plasma 5.17 y que continuará durante un par de años al ser una versión de soporte extendido.

Una versión que va incorporando mejoras, integrando el trabajo de la Comunidad, mejorando funcionalidades de anteriores versiones, cambiando modos de trabajo que tradicionalmente no han sido muy bien recibidas y que estrene fondo de pantalla, como es habitual en las cada ciertas versiones pares.

De esta forma, en palabras de los desarrolladores:

«Ya está disponible una nueva versión del escritorio de Plasma. En Plasma 5.18 encontrarás nuevas características que hacen que las notificaciones sean más claras, las configuraciones más racionales y el aspecto general más atractivo. Plasma 5.18 es más fácil y más divertido de usar, mientras que al mismo tiempo te permite ser más productivo a la hora de trabajar.

Además de todas las novedades, Plasma 5.18 también viene marcado como LTS, las siglas de «Long Term Support». Esto significa que la versión 5.18 será actualizada y mantenida por los colaboradores de KDE durante los próximos dos años (las versiones regulares se mantienen durante 4 meses). Si estás pensando en actualizar o migrar tu escuela, empresa u organización a Plasma, esta versión es tu mejor apuesta, ya que obtienes la versión más estable de Plasma y todas las nuevas características también.»

Las novedades básicas de Plasma 5.18

A lo largo de esta semana espero ampliar esta somera lista de novedades, pero para hacer un poco de boca aquí tenéis unas pinceladas de las novedades de Plasma 5.18.

• Nuevo selector de Emojis.
• Nuevo modo de edición global que sustituye el botón del cuadro de herramientas de escritorio y le permite personalizar fácilmente la disposición del escritorio.
•  Mejorado el uso del lanzador de aplicaciones Kickoff y de la edición de los widgets en dispositivos táctitles.
  
• Mejoras en las aplicaciones que utilicen las librerías visuales GTK.
• Múltiples mejoras en las notificaciones como la información del nivel de energía en dispositivos bluetooth vinculados.
• Posibilidad de activar una opción de comentarios de usuario (deshabilitado por omisión), que permite dar información detallada del sistema y estadísticas de la frecuencia con la que utilice las funcionalidades individuales del Plasma.
• Añadido un control deslizante para la velocidad de animación global.
• Diversas mejoras en Discover como la adición de comentarios anidados para los  complementos.

Además, comparto con vosotros vídeo promocional:

Bash se destaca como la Shell preferida en los sistemas GNU/Linux de los lectores de este blog.

Hace unos días realicé una encuesta en Mastodon y días después en mi blog, preguntando sobre cual es la shell que prefieres en tu sistema GNU/Linux. Después de unos cuantos días abiertas las encuestas estos son los resultados.

Puedes leer las encuestas realizadas tanto en Mastodon como en mi blog en estos enlaces:

• Encuesta en Mastodon
• Encuesta en mi blog

Era una curiosidad personal, el saber cual es la Shell preferida de quienes me leen. Daba una serie de opciones como Bash, Zsh, Fish, ksh y también dejaba abierta la opción a otras no listadas en la encuesta y que se quisiera votar.

Los resultados en ambas encuestas son contundentes. La ganadora por mayoría en ambas encuestas ha sido Bash.

En Mastodon de los 172 votos que ha tenido el 59% votó por Bash, un 26% por zsh, un 12% por fish y un 3% por ksh

En mi blog de los 76 votos emitidos un 68% fueron para Bash, un 21% para zsh, y solo un 4% para fish, quedando ksh sin votos.

Lo mejor de ambas encuestas, fueron los comentarios de aquellos que participaron y se animaron a dar sus motivos. Entre los más recurrentes se encuentra el hecho de que Bash este casi omnipresente en todas las distribuciones.

Es fácil que Bash sea la Shell predeterminada de tu distribución y si eres administrador de sistema, seguro que también en los servidores que utilices.

Por lo que lo hace muy cómodo, el saber que tus scripts, tus comandos, etc vas a poder utilizarlos en casi cualquier máquina sin problemas.

Por mi parte, siempre he utilizado Bash, pero últimamente estoy utilizando fish, que con sus sugerencias me hace más sencillo y más rápido el ejecutar comandos repetitivos u opciones que utilizo todos los días.

Muchas gracias a aquellas personas que habéis dejado vuestros votos y también para quienes habéis complementado esa información con vuestros comentarios.

Disponibilizo a versão minimalista do openSUSE na AWS. Além de multiuso, completa estável e fácil de usar. Destina-se a usuários, desenvolvedores, administradores, e qualquer profissional que deseja os recursos openSUSE no servidor. É ótimo para iniciantes, usuários experientes e ultra geeks, em resumo, é perfeito para todos! Sugestões em cabelo@opensuse.org, informações aqui: https://aws.amazon.com/marketplace/pp/B083XBP51G

A seguir as principais vantagens:

Desvantagem: Não possui YAST!

For those who don’t already know, openSUSE is a Linux Distribution Project with two Linux distributions, Tumbleweed and Leap.

• Tumbleweed is what is known as a Rolling Release, in that the distribution is constantly updating. Unlike Operating Systems with specific versions (e.g.. Windows 7, Windows 10, iOS 13, etc..) there is just ‘openSUSE Tumbleweed’ and anyone downloading it fresh or updating it today gets all the latest software.
• Leap is what is known as a a Regular Release, in that it does have specific versions (e.g.. 15.0, 15.1, 15.2) released in a regular cadence. In Leap’s case, this is annually. Leap is a variation of the Regular Release known as an LTS Release because each of those ‘minor versions’ (X.1, .2, .3) are intended to include only minor changes, with a major new version (e.g.. 16.0) expected only every few years.

It’s a long documented fact that I am a big proponent of Rolling Releases and use them as my main operating system for Work & Play on my Desktops/Laptops.
However in the 4 years since writing that last blog post I always had a number of Leap machines in my life, mostly running as servers.

As of today, my last Leap machine is no more, and I do not foresee ever going back to Leap or any Linux distribution like it.

This post seeks to answer why I have fallen out of love with the Regular Release approach to developing & using Operating Systems and provide an introduction to how you too could rely on Rolling Releases (specifically Tumbleweed & MicroOS) for everything.

Disclaimer

First, a few disclaimers apply to this post. I fully realise that I am expressing a somewhat controversial point and am utterly expecting some people to disagree and be dismissive of my point of view. That’s fine, we’re all entitled to our opinions, this post is mine.

I am also distinctly aware that, my views expressed run counter to the business decisions of the customers of my employer, who do a very good job of selling a very commercially successful Enterprise Regular Release distribution.
The views expressed here are my own and not those of my employer.

And I have no problem that my employer is doing a very good job making a lot of money from customers who are currently making decisions I feel are ‘wrong’.
If my opinion is correct then I hope I can help my employer make even more money when customers start making decisions I feel are more ‘right’.

Regular & LTS Releases Mean Well

Regular & LTS Releases (hereafter referred to as just Regular Releases) have all of the best intentions. The Open Source world is made up of thousands if not millions of discreet Free Software & Open Source Projects, and Linux distributions exist to take all of that often chaotic, ever-evolving software and condensing it into a consumable format that is then put to very real work by its users. This might be something as ‘simple’ as a single Desktop or Server Computer, or something far larger and complex such as a SystemZ Mainframe or 100+ node Kubernetes Cluster.

The traditional mindset for distribution builders is that the regular release gives a nice, predictable, plan-able schedule in which the team can carefully select appropriate software from the various upstream projects.
This software can then be carefully curated, integrated, and maintained for several, sometimes many, years.
This maintenance often comes in the form of making minimal changes, seeking only to address specific security issues or customer requests, taking great care not to break systems currently in use.

This mindset is often appreciated by users, who also want from their computing a nice, predictable, reliable experience.. but they also want new stuff to keep up with their peers, either in communities or commercially.. and here begins the first problem.

All Change Is Dangerous, but Small Changes Can Be Worse

Firstly, whether the change is a security update or a new feature, that change is going to be made by humans. Humans are flawed, and no matter how great we all get with fancy release processes and automated testing, we will never avoid the fact that humans make mistakes.

Therefore, the nature of the change has to be looked at. “Is this change too risky?” is a common question, and quite often highly desired features take years to deliver in regular releases because the answer is “yes”.

When changes are made, they are made with the intention of minimising the risks introduced by changing the existing software. That often means avoiding updating software to an entirely new version but instead opting to backport the smallest necessary amounts of code and merging them with (often much) older versions already in the Regular Release. We call these patches, or updates, or maintenance updates, but we avoid referring them to what they really are … franken-software

No matter how skilled the engineers are doing it, no matter how great the processes & testing are around their backporting, fundamentally the result is a hybrid mixed together combination of old and new software which was never originally intended to work together.
In the process of trying to avoid risk, backports instead introduce entirely new vectors for bugs to appear.

Regular Releases Neglect The Strengths Of Open Source

Linus’s Law states “given enough eyeballs, all bugs are shallow.”
I believe this to be a fundamental truth and one of the strongest benefits of the Open Source development model. The more people involved in working on something, the more eyeballs looking at the code, the better that code is, not just in a ‘lack of bugs’ sense but also often in a ‘number of working features’ sense.

And yet the process of building Regular Releases actively avoids this benefit. The large swath of contributors in various upstream projects are familiar with codebases often months, if not years, ahead of the versions used in Regular Releases.
Even inside Community Distribution Projects, it is my experience that the vast majority of volunteer distribution developers are more enthused in targetting ‘the next release’ rather than backporting complex features into an old codebase months or years old.
This leaves a small handful of committed volunteers, and those employees of companies selling commercial regular releases. These limited resources are often siloed, with only time and resources to work on their specific distribution, with their backports and patches often hard to reuse by other communities.

With Regular Releases, there are not many eyes. Does that mean all bugs are deep?

I am not suggesting the people building these Releases do not do a good job, they most certainly do. But when you consider the best possible job all Regular Release maintainers possibly could do and compare it to the much broader masses of the entire open source ecosystem, how did we ever think this problem was light enough for such narrow shoulders?

A Different Perspective

I’ve increasingly come to the realisation that not only is change unavoidable in software, it’s desired. It not only happens in Rolling Releases, but it still happens in Regular Releases.
Instead of trying to avoid it why don’t we embrace it and deal with any problems that brings?

Increasingly I hear more and more users demanding “we want everything stable forever, and secure, but we want all the new features too”.

Security and Stability cannot be achieved by standing still.
New Features cannot be easily added if good engineering practice is discouraged in the name of appearing to be stable.
In software as complicated as a Linux distribution, quite often, the right way to make a change requires a significant amount of changes across the entire codebase.
Or in other words “in order to be able to change any ONE thing, you must be able to change EVERYTHING”.

Rolling Releases can already do that, and you can read my earlier blog post if you haven’t already for some reasons why Tumbleweed is the best at that.
But it’s not enough, otherwise I would have been running Tumbleweed on my servers 4 years ago.

I Am A Lazy Sysadmin

Before my life as a distribution developer I was a sysadmin, and like all sysadmins I am lazy. I want my servers to be as ‘zero-effort’ as possible.
Once they’re working I don’t want to have to patch them, reboot them, touch them, look at them, or ideally even think about them ever again. And this is a hard proposition if I am running my server on a regular Rolling Release like Tumbleweed.

Tumbleweed is made up of over 15,000 packages, all moving at the rate of contribution. Worse, Tumbleweed is designed as a multi-purpose operating system.
You can quite happily set it up to be a mail server, web server, proxy server, virtualisation host, and heck, why not even a desktop all at the same time.
This is one of Tumbleweed’s greatest strengths, but in this case it is also a weakness.
openSUSE has to make sure all these things could possibly work together. That often means installing more ‘recommended packages’ on a system than absolutely necessary, ‘just-in-case’ the user wants to use all the possible features their combination of packages could possibly allow.
And with this complexity comes an increase of risk, and an increase of updates, which themselves bring yet more risk. Perfectly fine for my desktop (for now), but that’s far too much work for a Server, especially when I typically need a Server to just do one job.

Minimal Risk, Maximum Benefits with openSUSE MicroOS

openSUSE MicroOS is the newest member of the openSUSE Family. From a code perspective, it is a derivative of openSUSE Tumbleweed, using exactly the same packages and integrated into its release process, but from a philosophical perspective, MicroOS is a totally different beast.

Whereas Tumbleweed & other traditional distributions are multi-purpose, MicroOS is designed from the ground up to be single-purpose. It’s a Linux distribution you deploy on a bit of hardware, a VM, a Cloud instance, and once it is there it is intended to do just one job.

• The package selection is lean, with all you need to run on bare metal if you install from the ISO, or even smaller if you choose a VM Image for a platform where hardware support isn’t necessary. Fewer packages mean fewer reasons to update, helping lower the risks of change traditionally introduced by a rolling release. Recommended packages are disabled by default.
• Being a transactional system, it has a read-only root filesystem, further cutting down the risk of changes to the system, ensuring that any unwanted change that does happen can be rolled back. Not only that, but such roll-backs can be automated with health-checker.
• With rebootmgr, I can even schedule maintenance windows to ensure my updates only take effect during times I’m happy with.

Auto updating, auto rebooting, auto rolling back? I can be a lazy sysadmin even with a rolling release!

Just One Job Per Machine?

MicroOS is designed to do just one job, and this is fine for machines or VMs where all you would want to do is something like a self-maintaining webserver. That is as a simple as runningtransactional-update pkg in nginx.
But that can be rather limiting. Wouldn’t it be nice if there was some way of running services that minimised the introduction of risk to the base operating system, and could be updated independently of that base operating system?

Oh, right, that already exists, and they’re called containers.

MicroOS makes a perfect container host, so much so we deliver VM Images and a System Role on the ISO which already comes configured with podman.

Especially now openSUSE has a growing collection of official containers, a good number of services are a simple podman run podman pull registry.opensuse.org/opensuse/foo away.

In my case, I have moved all of my old Leap servers to now use MicroOS with Containers, this includes

• NextCloud, using upstream containers [1][2][3][4]
• Jekyll, using an upstream container [5]
• Nginx, using the official openSUSE container [6]
• A custom salt-master container [7]
• A custom SSH container acting as both a jump-host and backup target for all my other machines [8]
• and some other containers which I hope to make official openSUSE Containers once I’m happy they’ll work for everyone

All of the custom containers are built on openSUSE’s tiny busybox container which is just small and tiny and magical and I have no idea why anyone would use alpine.

All of my servers are now running MicroOS. The software is newer with all the latest features, but through a combination of containerisation and transactional-updates I find myself spending significantly less time maintaining my servers compared to Leap.

I can update the containers when I want, using container tags to pin the services to use specific versions until I decide when I want to update them.
I can easily add new containers to the to the MicroOS hosts just by adding another systemd service file running podman to /etc/systemd/system.
And I never need to worry about my base operating system which just takes care of itself, rebooting in the maintenance window I defined in rebootmgr.

I’m going to be writing further blog posts about my life with MicroOS and podman , but meanwhile I couldn’t be happier, and sincerely hope more people take this approach to running infrastructure.
Why? Well, we’re still only human, but when things do go wrong it’ll be even easier with more people looking at any problems :)

Now all I need to do is see if any of these benefits make sense for a desktop….

We are happy to pre-announce a new service entering the openSUSE world:

https://debuginfod.opensuse.org

debuginfod is an HTTP file server that serves debugging resources to debugger-like tools.

Instead of using the old way to install the needed debugging packages one by one as root like:

zypper install $package-debuginfo

the new debuginfod service lets you debug anywhere, anytime.

Right now the service serves only openSUSE Tumbleweed packages for the x86_64 architecture and runs in an experimental mode.

The simple solution to use the debuginfod for openSUSE Tumbleweed is:

export DEBUGINFOD_URLS="https://debuginfod.opensuse.org/"
gdb ...

For every lookup, the client will send a query to the debuginfod server and get's back the requested information, allowing to just download the debugging binaries you really need.

More information is available at the start page https://debuginfod.opensuse.org - feel free to contact the initiator marxin directly for more information or error reports.

Llegamos a la actualización mensual de rigor que demuestra que los desarrolladores de KDE no dejan de trabajar. Así que se congratulan en anunciar la actualización de febrero del 2020 de KDE Frameworks.  Con esta se llega a la versión 5.67, una plusmarca de compromiso y constancia que no parece que tenga un final cercano.

Actualización de febrero del 2020 de KDE Frameworks

A pesar de que para los usuarios corrientes esta noticia sea algo confusa ya que no se trata de realzar una nueva aplicación ni de una nueva gran funcionalidad del escritorio, el desarrollo de KDE Frameworks tiene repercusiones directas en él a medio y largo plazo.

La razón de esta afirmación es que KDE Frameworks es básicamente la base de trabajo de los desarrolladores para realizar sus aplicaciones, es como el papel y las herramientas de dibujo para un artista: cuanto mejor sea el papel y mejores pinceles tenga, la creación de una artista será mejor.

De esta forma, las mejoras en KDE Frameworks facilitan el desarrollo del Software de la Comunidad KDE, haciendo que su funcionamiento, su estabilidad y su integración sea la mejor posible,

El domingo 02 de febrero de 2020 fue lanzado KDE Frameworks 5.67, la nueva revisión del entorno de programación sobre el que se asienta Plasma 5, el escritorio GNU/Linux de la Comunidad KDE, y las aplicaciones que se crean con para él.

Hay que recordar que los desarrolladores de KDE decidieron lanzar actualizaciones mensuales de este proyecto y lo están cumpliendo con puntualmente. La idea es ofrecer pocas pero consolidadas novedades, a la vez que se mantiene el proyecto evolucionando y siempre adaptándose al vertiginoso mundo del Software Libre.

Una gran noticia para la Comunidad KDE que demuestra la evolución continua del proyecto que continua ganando prestigio en el mundo de los entornos de trabajo Libres.

Más información: KDE

¿Qué es KDE Frameworks?

Para los que no lo sepan, KDE Frameworks añade más de 70 librerías a Qt que proporcionan una gran variedad de funcionalidades necesarias y comunes, precisadas por los desarrolladores, testeadas por aplicaciones especí­ficas y publicadas bajo licencias flexibles. Como he comentado, este entorno de programación es la base para el desarrollo tanto de las nuevas aplicaciones KDE y del escritorio Plasma 5.

Aquí podéis encontrar un listado con todos estos frameworks y la serie de artículos que dedico a KDE Frameworks en el blog,

Recuerda que puedes ver una introducción a Frameworks 5.0 en su anuncio de lanzamiento.

While we monitor basic functionality of our MariaDB (running as Galera-Cluster) and PostgreSQL databases since years, we missed a way to get an easy overview of what's really happening within our databases in production. Especially peaks, that slow down the response times, are not so easy to detect.

That's why we set up our own Grafana instance. The dashboard is public and allows everyone to have a look at:

• The PostgreSQL cluster behind download.opensuse.org. Around 230 average and up to 500 queries per second are not that bad...
• The Galera cluster behind the opensuse.org wikis and other MariaDB driven applications like Matomo or Etherpad. One interesting detail here is - for example - the archiving job of Matomo, triggering some peaks every hour.
• The Elasticsearch cluster behind the wiki search. Here we have a relatively high JVM memory foodprint. Something to look at...

Both: the Grafana dashboard and the databases are driving big parts of the openSUSE infrastructure. And while everything is still up and running, we would love to hear from experts how we could improve. If you are an expert or know someone, feel free to contact us via Email or in our [IRC channel](irc://irc.opensuse.org/#opensuse-admin).

Nesta prova de conceito, podemos entender a viabilidade computacional da utilização de Inferência em Deep Learning, processando em tempo real vídeos ao vivo, para detecção e classificação de atributos e propriedades humanas COM BAIXA LATÊNCIA HPC.