Veamos cómo configurar las contraseñas temporales de un solo uso (Time One Time Passwords) en nuestro gestor de contraseñas Pass en GNU/Linux

GitHub va a obligar a utilizar el doble factor de autentificación (2FA) a las personas que usen su plataforma y colaboren con código. De momento hay muchos repositorios de código de software libre que se encuentran en GitHub, la plataforma de repositorios git propiedad de Microsoft.

Existen alternativas más libres, comunitarias, pero todavía GitHub es el sitio donde reside mucho software con el que colaboro, por tanto voy a habilitar las contraseñas temporales de un solo uso (OTP) para poder seguir colaborando con esos proyectos hasta que se pasen a otros servicios.

Para utilizar las contraseñas utilizo pass el gestor de contraseñas de Unix, y para utilizar las contraseñas temporales de un solo uso (OTP) utilizaré pass con el complemento pass-otp.

Lo primero acceder a la página en cuestión, en este caso github y seguir los pasos para acceder a la habilitación del 2FA. Nos mostrará un código QR para escanear, aunque en mi caso, utilizaré «setup key» que nos mostrará un código o secreto.

Imaginemos que el código o secreto en cuestión es 112233AA5566TTBB9900, deberemos copiarlo porque lo vamos a utilizar más adelante para configurar pass.

Ahora en una terminal, vamos a añadir la opción de OTP a nuestra contraseña ya existente de github, para ello ejecuto lo siguiente:

pass otp append -e Web/github

Y nos pedirá que introduzcamos nuestro secreto:

Enter otpauth:// URI for Web/github.com:

Tendremos que escribir lo siguiente (con el secreto que hemos obtenido antes):

otpauth://totp/totp-secret?secret=112233AA5566TTBB9900

Aceptamos y ya tendremos configurada nuestra OTP para esta web. Ahora podemos probar que funciona bien, generando una OTP e introduciéndola en el campo de verificación de github. Para ello ejecutamos:

pass otp Web/github

Y nos generará un código similar a 772242 este será el código que introduzcamos en nuestra web cuando se solicite o en el campo de verificación del paso anterior en github.

Si todo ha salido bien, nos mostrará unos códigos de recuperación que tendríamos que guardar a buen recaudo.

También podemos guardarlos y gestionarlos con pass, ejecutando:

pass add -m Web/github_recovery_codes

Ahí iremos metiendo los códigos, cuando acabemos de introducirlos, pulsamos sobre Ctrl+D y ya hemos guardado los códigos para que los gestione y los guarde pass.

Si tenemos configurado pass para que guarde nuestras contraseñas en git, ahora deberíamos ejecutar pass git push y en otros dispositivos donde también utilicemos pass para sincronizar las nuevas contraseñas guardadas ejecutaremos pass git pull

Esto sirve para GitHub, pero también para otras webs que soliciten el 2FA con OTP.

Enlaces de interés

• https://victorhckinthefreeworld.com/2017/05/30/password-store-el-gestor-de-contrasenas-estandar-de-unix/
• https://victorhckinthefreeworld.com/2018/09/26/como-sincronizar-mediante-git-nuestras-contrasenas-de-pass/
• https://www.passwordstore.org/
• https://github.com/tadfisher/pass-otp
• https://docs.github.com/es/authentication/securing-your-account-with-two-factor-authentication-2fa/configuring-two-factor-authentication#configuring-two-factor-authentication-using-a-totp-app

Tras un parón debido al salto de Qt5/KF5 a Qt6/KF6 que realizó la Comunidad KDE el pasado 28 de febrero he decidido retomar esta sección aunque renonbrándola ya que en ella solo hablaré de Plasmoides para Plasma 6. De esta forma os presento un reloj analógico original llamado Mechanical Clock con el que ya llegamos al sexto plasmoides de la serie.

Reloj analógico original, Mechanical Clock – Plasmoides para Plasma 6 (6)

Como he comentado en otras ocasiones, de plasmoides tenemos de todo tipo funcionales, de configuración, de comportamiento, de decoración o, como no podía ser de otra forma, de información sobre nuestro sistema como puede ser el uso de disco duro, o de memoria RAM, la temperatura o la carga de uso de nuestras CPUs.

Así que espero que le deis la bienvenida a un plasmoide para plasma 6 escrito por un viejo conocido del blog ZayronXIO que recibe el nombre de Mechanical Clock, un reloj analógico muy original que mezcla la palabra clock con una esfera horaria clásica pero estilosa.

Y como siempre digo, si os gusta el plasmoide podéis «pagarlo» de muchas formas en la página de KDE Store, que estoy seguro que el desarrollador lo agradecerá: puntúale positivamente, hazle un comentario en la página o realiza una donación. Ayudar al desarrollo del Software Libre también se hace simplemente dando las gracias, ayuda mucho más de lo que os podéis imaginar, recordad la campaña I love Free Software Day de la Free Software Foundation donde se nos recordaba esta forma tan sencilla de colaborar con el gran proyecto del Software Libre y que en el blog dedicamos un artículo.

Más información: KDE Store

¿Qué son los plasmoides?

Para los no iniciados en el blog, quizás la palabra plasmoide le suene un poco rara pero no es mas que el nombre que reciben los widgets para el escritorio Plasma de KDE.

En otras palabras, los plasmoides no son más que pequeñas aplicaciones que puestas sobre el escritorio o sobre una de las barras de tareas del mismo aumentan las funcionalidades del mismo o simplemente lo decoran.

La entrada Reloj analógico original, Mechanical Clock – Plasmoides para Plasma 6 (6) se publicó primero en KDE Blog.

This article shows how to install and deploy Kubernetes (K8s) using RKE2 by SUSE Rancher on openSUSE Leap 15.6 with the NVIDIA GPU Operator. This operator deploys and loads any driver stack components required by CUDA on K8s Cluster nodes without touching the container host and makes sure, the correct driver stack is made available to driver containers. We use a driver container specifically build for openSUSE Leap 15.6 and SLE 15 SP6. GPU acceleration with CUDA is used in many AI applications. AI application workflows are frequently depoyed through K8s.

Introduction

NVIDIA's Compute Unified Device Architecture (CUDA) plays a crucial role in AI today. Only with the enormous compute power of state-of-the-art GPUs it is possible to process training and inferencing with an acceptable amount of resources and compute time.

Most AI workflows rely on containerized workloads deployed and managed by Kubernetes (K8s). To deploy the entire compute stack - including kernel modules - to a K8s cluster, NVIDIA has designed its GPU Operator, which, together with a set of containers, is able to perform this task without ever touching the container hosts.

Most of the components used by the GPU Operator are 'distribution agnostic' however, one container needs to be built specifically for the target distribution: the driver container. This is owed to the fact that drivers are loaded into the kernel space and therefore need to be built specifically for that kernel.

For a long time, NVIDIA kernel drivers were proprietary and closed source. More recently, NVIDIA has published a kernel driver that's entirely open source. This enables Linux distributions to publish pre-built drivers for their products. This allows for a much quicker installation. Also, prebuilt drivers are signed with the key thats used for the distribution kernel. This way, the driver will work seamlessly in systems with secure boot enabled. The container utilized below makes use of a pre-built driver.

In the next section we will explore how to deploy K8s on openSUSE Leap 15.6 once this is done, we will deploy the NVIDA GPU Operator in the following section run some initial tests. If you have K8s already running you may want to skip ahead to the 2nd part.

Install RKE2 on openSUSE Leap 15.6

We have chosen RKE2 from SUSE Rancher for K8s over the K8s packages shipped with openSUSE Leap: RKE2 is a well curated and maintained Kubernetes distribution which works right out of the box while openSUSE's K8s packages have been broken pretty much ever since openSUSE Kubic has been dropped.

RKE2 does not come as an RPM package. This seems strange at first, however, it is owed to the fact that Rancher wants to ensure maximal portability across various Linux distributions.

Instead, it comes as a tar-ball - which is not unusual for application layer software.

Most of what's described in this document has been taken from a great article by Alex Arnoldy on how to deploy NVIDIA's GPU Operator on RKE2 and SLE BCI. Unfortunately, it was no longer fully up-to-date and thus has been taken down.

Install the K8s server

Kubernetes consists of at least one server which serves as a control node for the entire cluster. Additionally clusters may have any number of agents - i.e. machines which workloads will be spread across. Servers will act as an agent as well. If your K8s cluster consists just of one machine, you will be done once your server is installed. You may skip the following section. For system requirements you may want to check here. We assume, you have a Leap 15.6 system installed already (minimal installation is sufficient and even preferred).

1. Make sure, you have all components installed already which are either required for installation or runtime:

   zypper -n install -y curl tar gawk iptables helm
   

   For the installation, a convenient installation script exists. This downloads the required components, performs a checksum verification and installs them. The installation is minimal. When RKE2 is started for the first time, it will install itself to /var/lib/rancher and /etc/rancher. Download the installation script:

   # cd /root
   # curl -o rke2.sh -fsSL https://get.rke2.io
   

2. and run it:

   sh rke2.sh
   

3. To make sure, that the binaries provided by RKE2 - most importantly, kubectl - are found and will find their config files, you may want to create a separate shell profile:

   #  cat > /etc/profile.d/rke2.sh << EOF
   export PATH=$PATH:/var/lib/rancher/rke2/bin
   export KUBECONFIG=/etc/rancher/rke2/rke2.yaml
   export CRI_CONFIG_FILE=/var/lib/rancher/rke2/agent/etc/crictl.yaml
   EOF
   

4. Now enable and start the rke2-server service:

   systemctl enable --now rke2-server
   

   With this, the installation is completed.
5. To check is all pods have come up properly and are running of have completed successfully, run:

   # kubectl get nodes -n kube-system
   

Install Agents

If you are running a single node cluster, you are done now and may skip this chapter. Otherwise, you will need to perform the steps below for every node you want to install as an agent.

1. As above, make sure, all required prerequisites are installed:

   # zypper -n install -y curl tar gawk iptables
   

2. Download the installation script

   # cd /root
   # curl -o rke2.sh -fsSL https://get.rke2.io
   

3. and run it:

   # INSTALL_RKE2_TYPE="agent" sh rke2.sh
   

4. Obtain the token from the server node, it can be found on the server at /var/lib/rancher/rke2/server/node-token. and add it to config file for the RK2 agent service:

   # mkdir -p /etc/rancher/rke2/
   # cat > /etc/rancher/rke2/config.yaml
   server: https://<server>:9345
   token <obtained token>
   

   (You have to replace by the name of IP of the RKE2 server host and by the agent token mentioned above.
5. Now you are able to start the agent:

   sytemctl enable --now rke2-agent
   

6. After a while you should see that the node is has been picked up by the server. Run:

   kubectl get nodes
   

   in the server machine. The output should look something like this:

   NAME     STATUS   ROLES                       AGE    VERSION
   node01   Ready    control-plane,etcd,master   12m   v1.30.4+rke2r1
   node02   Ready    <none>                      5m    v1.30.4+rke2r1
   

Deploying the GPU Operator

Now, with the K8s cluster (hopefully) running, you'd be ready to deploy the GPU operator. The following steps need to be performed on the server node only, regardless if this has a GPU installed or not. The correct driver will be installed on any node that has a GPU installed.

1. To simply configuration, create a file /root/build-variables.sh on the server node:

   # cat > /root/build-variables.sh <<"EOF"
   export LEAP_MAJ="15"
   export LEAP_MIN="6"
   export DRIVER_VERSION="575.57.08"
   export OPERATOR_VERSION="v25.3.2"
   export DRIVER_IMAGE=nvidia-driver-container
   export REGISTRY="registry.opensuse.org/network/cluster/containers/containers-${LEAP_MAJ}.${LEAP_MIN}"
   EOF
   

2. and source this file from the shell you run the following commands from:

   # source /root/build-variables.sh
   

   Note that in the script above we are using kernel driver version 555.42.06 for CUDA 12.5 instead of CUDA 12.6 as in 12.6 NVIDIA has introduced some dependency issues which have not been resolved fully, yet. This will limit CUDA used in the payload to 12.5 or older since a kernel driver version will only work for CUDA versions older or equal to the version it was provided with. This will be fixed in future versions so that later driver of GPU operator versions can be used. Also note, that $REGISTRY points to a driver container in https://build.opensuse.org/package/show/network:cluster:containers/nv-driver-container This is a driver container specifically built for Leap 15.6 and SLE 15 SP6. The nvidia-driver-ctr container will look for a container image ${REGISTRY}/${DRIVER_IMAGE} tagged: ${DRIVER_VERSION}-${ID}${VERSION_ID}. ${ID} and ${VERSION_ID} are taken from /etc/os-release on the container host. Currently, the container above is tagged for Leap 15.6 and SLE 15 SP6.
3. Add the NVIDIA Helm repository:

   # helm repo add nvidia https://helm.ngc.nvidia.com/nvidia
   

4. and update it:

   # helm repo update
   

5. Now deploy the operator using the nvidia/gpu-operator Helm chart:

   # helm install -n gpu-operator \
     --generate-name   --wait \
     --create-namespace \
     --version=${OPERATOR_VERSION} \
     nvidia/gpu-operator \
     --set driver.repository=${REGISTRY} \
     --set driver.image=${DRIVER_IMAGE} \
     --set driver.version=${DRIVER_VERSION} \
     --set operator.defaultRuntime=containerd \
     --set toolkit.env[0].name=CONTAINERD_CONFIG \
     --set toolkit.env[0].value=/var/lib/rancher/rke2/agent/etc/containerd/config.toml \
     --set toolkit.env[1].name=CONTAINERD_SOCKET  \
     --set toolkit.env[1].value=/run/k3s/containerd/containerd.sock \
     --set toolkit.env[2].name=CONTAINERD_RUNTIME_CLASS \
     --set toolkit.env[2].value=nvidia \
     --set toolkit.env[3].name=CONTAINERD_SET_AS_DEFAULT \
     --set-string toolkit.env[3].value=true
   

   After a while, the command will return.
6. Now, you can view the additional pods that have started in the gpu-operator namespace:

   kubectl get pods --namespace gpu-operator
   

7. To verify that everything has been deployed correctly, run:

   # kubectl logs -n gpu-operator -l app=nvidia-operator-validator
   

   This should return a result like:

   Defaulted container "nvidia-operator-validator" out of: nvidia-operator-validator, driver-validation (init), toolkit-validation (init), cuda-validation (init), plugin-validation (init)
   all validations are successful
   

   Also, run:

    # kubectl logs -n gpu-operator -l app=nvidia-cuda-validator
   

   which should result in:

   Defaulted container "nvidia-cuda-validator" out of: nvidia-cuda-validator, cuda-validation (init)
   cuda workload validation is successful
   

   To obtain information on the NVIDIA hardware installed on each node, run:

   # kubectl exec -it "$(for EACH in \
     $(kubectl get pods -n gpu-operator \
     -l app=nvidia-driver-daemonset \
     -o jsonpath={.items..metadata.name}); \
     do echo ${EACH}; done)" -n gpu-operator -- nvidia-smi
   

One should note, that most arguments to helm install ... above are for the RKE2 variant of K8s. Some of them may be different for an 'upstream' Kubernetes or may not be needed at all for it.

With GNOME 47 out, it’s time for my bi-annual wallpaper deep dive. For many, these may seem like simple background images, but GNOME wallpapers are the visual anchors of the project, defining its aesthetic and identity. The signature blue wallpaper with its dark top bar remains a key part of that.

In this release, GNOME 47 doesn’t overhaul the default blue wallpaper. It’s more of a subtle tweak than a full redesign. The familiar rounded triangles remain, but here’s something neat: the dark variant mimics real-world camera behavior. When it’s darker, the camera’s aperture widens, creating a shallower depth of field. A small but nice touch for those who notice these things.

The real action this cycle, though, is in the supplemental wallpapers.

We haven’t had to remove much this time around, thanks to the JXL format keeping file sizes manageable. The focus has been on variety rather than cutting old designs. We aim to keep things fresh, though you might notice that photographic wallpapers are still missing (we’ll get to that eventually, promise.

In terms of fine tuning changes, the classic, Pixels has been updated to feature newer apps from GNOME Circle.

The dark variant of Pills also got some love with lighting and shading tweaks, including a subtle subsurface scattering effect.

As for the new wallpapers, there are a few cool additions this release. I collaborated with Dominik Baran to create a tube-map-inspired vector wallpaper, which I’m particularly into. There’s also Mollnar, a nod to Vera Molnar, using simple geometric shapes in SVG format.

Most of our wallpapers are still bitmaps, largely because our rendering tools don’t yet handle color banding well with vectors. For now, even designs that would work better as vectors—like mesh gradients—get converted to bitmaps.

We’ve introduced some new abstract designs as well – meet Sheet and Swoosh. And for fans of pixel art, we’ve added LCD and its colorful sibling, LCD-rainbow. Both give off that retro screen vibe, even if the color gradient realism isn’t real-world accurate.

Lastly, there’s Symbolic Soup, which is, well… a bit chaotic. It might not be everyone’s cup of tea, but it definitely adds variety.

Preview

If you’re wondering about the strange square aspect ratio, take a look at the wallpaper sizing guide in our GNOME Interface Guidelines.

Also worth noting is the fact that all of these wallpapers have been created by humans. While I’ve experimented with image generation for some parts of the workflow in some of of my personal projects, all this work is AIgen-free and explicitly credited.

Hace ya casi tres años que presenté eXeLearning, un editor de recursos educativos e interactivos de código abierto que te permite llevar tu actividades a otro nivel a la vez que compartirlos sin ningún tipo de restricción en multitud de formatos. Lo cierto es que me interesa mucho esta aplicación y he empezado a aprender mucho sobre ella, y es mi deber pagarlo mediante promoción. Hoy os traigo cómo crear un juego trivial (TriviExt) con eXeLearning ,un vídeo de Cedec_Intef .

Cómo crear un juego trivial (TriviEt) con eXeLearning – Vídeo

Seguimos con eXeLearning, y en esta ocasión con un vídeo de Cedec_Intef, que no es más que el Centro Nacional de Desarrollo Curricular en Sistemas no Propietarios (Cedec), un organismo público español que promueve la transformación digital y metodológica de las aulas que pone a disposición de los docentes recursos educativos abiertos (REA) del Proyecto EDIA, elaborados por docentes en activo con la herramienta de software libre eXeLearning.

Pues bien, en el vídeo que os presento hoy se explica en varios pasos cómo crear un juego trivial (TriviEt) con eXeLearning versión del clásico juego «Trivial» con su tablero, cartas con preguntas y sus dados para dar aletoreidad.

¿Qué es EXeLearning?

Para los que no lo conozcan, eXeLearning es un editor de recursos educativos e interactivos de código abierto se caracteriza por:

• Permite crear contenidos educativos de una manera sencilla
• Descarga fácil y gratuita desde su web.
• Está disponible para todos los sistemas operativos.
• Nos pemite catalogar los contenidos y publicarlos en diferentes formatos:
  • Sitio web navegable y adaptable a diferentes dispositivos (responsive design).
  • Estándar educativo, para trabajar con Moodle y otros LMS.
  • Página HTML única para imprimir cómodamente tu trabajo.
  • ePub3 (libro electrónico), etc.
• Ofrece diferentes diseños a elegir desde el menú, además de la posibilidad de crear diseños propios.

Con eXelearnig se puede crear todo tipo de actividades entre las que destaco rellenar huecos, pregunta de elección múltiple, pregunta de selección múltiple, pregunta verdadero-falso, cuestionario SCORM o actividad desplegable.

Además, y este es uno de los principales usos que hago de esta aplicación, nos permite crear rúbricas de forma sencilla, así como incluir recursos realizados con otras aplicaciones. Por ejemplo, Jclic, Descartes, Scratch, Geogebra, Physlets…

La entrada Cómo crear un juego trivial (TriviExt) con eXeLearning – Vídeo se publicó primero en KDE Blog.

Hoy domingo vengo con una entrada que seguro que sacará de algún apuro a más de uno. Aunque es cierto que casi todo se puede hacer con aplicaciones nativas de GNU/Linux en ocasiones debemos recrurrir programas Windows para ciertos menesteres. Es por ello que me complace compartir con vosotros cómo instalar wine32 en KDE Neon, algo que es sencillo pero que requiere un paso fundamental que normalmente no se encuentra en artículos donde explican lo mismo para Ubuntu.

Cómo instalar wine32 en KDE Neon

Antes de empezar comentar que esta guía no es mía, la he sacado de Installing Wine on Linux, pero creo es positivo que esté traducido al castellano y que se guarde una copia de este artículo en algún sitio por si desaparece el original.

Mediante este tutorial conseguiremos tener instalada la última versión de Wine Stable, Wine Development o Wine Staging.

1.- Preprarando el equipo

Para empezar vamos a comprobar las arquitecturas de nuestro equipo. En primer lugar verificamos que arquitectura tiene nuestro equipo. Escribimos.

$ dpkg --print-architecture

Nos aparecerá, con toda probabilidad, como respuesta «amd64». Es hora de comprobar si tenemos alguna otra arquitectura en nuestro equipo, así que escribimos.

$ dpkg --print-foreign-architectures

En esta ocasión puede aparecer «i386» o nada. En el primero caso ya podemos descargar y añadir la llave del reposotorio de WineHQ, pero si no aparece debemos añadirla. Este paso es fundamental. Escribimos.

$ sudo dpkg --add-architecture i386

Para asegurarnos volvemos a escribir:

$ dpkg --print-foreign-architectures

Debería aparecer «i386». Ya podemos ir al segundo paso.

2.- Descargando y añadiendo la clave del repositorio WineHQ

Es el momento de añadir el repositorio adecuado de WineHQ, para ello escribimos en la terminal:

 $ sudo mkdir -pm755 /etc/apt/keyrings

$ sudo wget -O /etc/apt/keyrings/winehq-archive.key https://dl.winehq.org/wine-builds/winehq.key

3.- Descargando el archivo fuente de WineHQ

Volvemos a la terminal, añadimos la fuente del repositorio y actualizamos.

$ sudo wget -NP /etc/apt/sources.list.d/ https://dl.winehq.org/wine-builds/ubuntu/dists/jammy/winehq-jammy.sources
$ sudo apt update

4.- Instalando el paquete perdido pero fundamental

La clave de la instalación está aquí y es lo que la diferencia de Ubuntu, un paquete de 32 bits es requerido por Wine pero no está disponible en los repositorios neon de KDE requiere un tratamiento especial. Así que lo instalamos.

Nota: en este punto el autor del artículo, , nos indica que le avisamos si este comando no funciona. Mi dirección de correo electrónico es david.l.bridges at gmail.com

$ sudo apt install libpoppler-glib8:{i386,amd64}=22.02.0-2ubuntu0.*

5.- Instalando Wine

El siguiente comando instala Wine Stable. Para instalar Wine Development o Wine Staging, sustituye winehq-stable por winehq-devel o winehq-staging.

Después de una actualización importante de Wine (de Wine 6 a Wine 7, por ejemplo), Wine Stable puede no estar disponible temporalmente, pero Wine Development y Wine Staging pueden seguir instalándose.

$ sudo apt install --install-recommends winehq-stable

Verificamos la instalación.

$ wine --version

Más información: How to Install Wine on KDE neon 5.26 – 6.1 (Ubuntu 22.04 based)

La entrada Cómo instalar wine32 en KDE Neon se publicó primero en KDE Blog.

Hace tiempo que no hablo de distribuciones en el blog. La razón es que básicamente solo utilizo una y no encuentro motivación para escribir de otra. De hecho, de KDE Neon también escribo poco. Pero hoy rompo esta tendencia y os comento que ha sido lanzado Slimbook OS 24, el sistema operativo de la compañía valenciana que viene a cubrir el espectro de usuarios que no tienen una distribución favorita y que quieren que su ordenador sea lo más coorporativo posible. Esto, si se piensa un poco, tiene más sentido de lo que parece.

Lanzado Slimbook OS 24, ahora con la posibilidad de seleccionar el escritorio Plasma

Lo he comentado en anteriores ocasiones: aunque las aportaciones personales son muy importantes, al final son la colaboración entre Comunidades y empresas o instituciones públicas las que pueden hacer las cosas más grandes por el Software Libre. Prueba de ello esla evolución de Krita o la gama KDE Slimbook fruto del entendimiento de la Comunidad KDE con la empresa valenciana.

Pues bien, aunque es algo un poco desconocido, la empresa Slimbook también tiene su departamento de Software, los cuales han puesto a disposición de todo el mundo aplicaciones como Battery, Face, Gesture o los Controller para Intel o AMD que «simplemente» (y nótese las comillas) facilitan exprimir al máximo los dispositivos de su marca, aunque muchos de ellos pueden utilizarse en otros equipos.

Y claro está, de ahi a pensar «¿Y si cogemos una base Ubuntu, empaquetamos todo este software, lo personalizamos un poco y sacamos una distribución propia que podemos controlar al 100%? Pues dicho y hecho. De esta forma, hace un tiempo, nació Slimbook OS.

Eso fue por el 2019, momento en el cual le dediqué un artículo para celebrar su lanzamiento y, desde entonces, no ha vuelto a aparecer en el mismo, siguiendo la tradición de dejar de hablar de distribuciones establecida en el blog y que puede ser revertida en cualquier momento porque lo bueno de tener un blog es que hablas de lo que quieras (hoy estoy con incontinencia verbal).

Así que hoy vuelvo a hablar de una distro y lo hago por un motivo relacionado con la Comunidad KDE, y es que ha sido lanzado Slimbook OS 24 que es, según lo desarrolladores «la primera distribución basada en Ubuntu 24 LTS que te permite elegir entre el novedoso escritorio Plasma 6 o el estable Gnome 46.»

En otras palabras, Plasma 6 se convierte en un escritorio integrado en la distribución (que no significa que sea el «por defecto») con lo que Slimbook se acerca todavía más a la Comunidad KDE, algo que personalmente me encanta y que viene a juego con su rama KDE Slimbook de ultrabooks.

Además, este lanzamiento contiene un cambio importante en la filosofía de la distribución que mejor nos lo expliquen ellos mismo:

En septiembre de 2024, hemos dado un gran giro en la filosofía de nuestra distribución: mejorar Ubuntu y ofrecerlo a cualquier usuario, sea o no cliente de Slimbook.
Nuestra premisa es mejorar el sistema, eliminando de Ubuntu lo que no nos gusta y añadiendo lo que consideramos que lo hace más funcional y mejora la experiencia del usuario. Prestamos mucha atención a lo que la comunidad lleva años pidiendo.

We are ready to rock!

Si te intriga, qué significa «eliminando de Ubuntu lo que no nos gusta» os invito a leer el artículo donde lo presentan. Al mismo tiempo os invito a ver su vídeo presentación.

Como vemos, la compañía no para de hacer cosas por el Software Libre, esperemos que por muchos años.

La entrada Lanzado Slimbook OS 24, ahora con la posibilidad de seleccionar el escritorio Plasma 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/09/tumbleweed-review-of-the-week-2024-38/

Esta se mana se han publicado un total de 6 nuevas snapshots (0912, 0913, 0915, 0916, 0917, y 0918).

Los cambios más relevantes fueron:

• cURL 8.10.0
• KDE Gear 24.08.1
• Bluez 5.78
• Boost 1.86.0
• LibreOffice 24.8.1.2
• Qemu 9.1.0
• KDE Frameworks 6.6.0
• Mesa 24.1.7
• strace 6.11, linux-glibc-devel 6.11
• Python Numpy 2.1.1
• Python Sphinx 8.0.2
• GTK 4.16.1
• GNOME Shell & mutter 46.5

Y se están trabajando en próximas actualizaciones, por ejemplo:

• Linux kernel 6.10.11
• timezone 2024b
• PostgreSQL 17
• Audit 4.0
• grub2
• Python Sphinx 8.0.2
• perl-Bootloader será renombrado a update-bootloader
• Mesa 24.2.x

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

——————————–