O Allen Institute for Artificial Intelligence (Ai2) está lançando uma nova família de modelos de linguagem multimodais de código aberto, chamada Molmo, que rivaliza com modelos da OpenAI, Google e Anthropic. O maior modelo Molmo possui 72 bilhões de parâmetros e supera o GPT-4 da OpenAI em testes de compreensão de imagens e documentos, enquanto um modelo menor de 7 bilhões de parâmetros se aproxima do desempenho do modelo mais avançado da OpenAI, graças a métodos eficientes de treinamento de dados.

Segundo Ali Farhadi, CEO do Ai2, o desenvolvimento de IA de código aberto está agora em par com modelos proprietários, oferecendo a vantagem de ser acessível para outros desenvolvedores construírem aplicações. Uma demonstração do Molmo estará disponível em breve no site Hugging Face, embora alguns elementos do modelo maior ainda sejam restritos ao público.

Contrastando com outros modelos treinados em conjuntos de dados massivos e indiscriminados, o Molmo utiliza um conjunto menor e mais selecionado de 600.000 imagens, resultando em melhor desempenho com menos recursos. Anotadores humanos detalharam imagens em texto, convertidas depois em dados através de técnicas de IA, otimizando o treinamento e reduzindo a necessidade de potência computacional. Essa abordagem focada em qualidade, segundo Percy Liang, do Stanford Center for Research on Foundation Models, pode diminuir os custos computacionais e, segundo Yacine Jernite da Hugging Face, pode ajudar a controlar melhor os dados utilizados em IA.

Além disso, o modelo Molmo demonstrou capacidade de “apontar” elementos específicos em imagens, uma função útil para interações mais sofisticadas com interfaces de usuário, o que Ali Farhadi enfatiza como uma vantagem sobre modelos que apenas descrevem imagens. Com a promessa de maior eficiência e potencial para aplicações futuras, o Ai2 espera que o Molmo influencie o campo da IA de código aberto e seja uma base para inovações futuras.

https://arxiv.org/pdf/2409.17146

In High Performance Computing (HPC) we frequently encounter node counts in compute clusters that are impractical to be managed manually. Here, the saving grace is that the number of variations in installation and configuration among nodes of a cluster is small. Also, the number of parameters that are individual to each node is low. Thus, in the 'cattle/pet' model, compute nodes would be treated like cattle.
Warewulf, a deployment system for HPC compute nodes, is specifically designed for this case. It utilizes PXE to boot nodes and provide their root filesystem. Nodes are ephemeral, i.e. their root filesystem resides in a RAM disk. In a recent Blog post, Christian Goll described how to set up and manage a cluster using Warewulf.
Kubernetes (K8s) deployments potentially face similar challanges: K8s clusters often consist of a large number of mostly identical agent nodes with a minimal installation and very little individual configuration.
In this article we explore how to set up a K8s cluster with Rancher's next-generation Kubernetes distribution RKE2 using Warewulf.

Considerations

K8s Server

In K8s we distinguish between a 'server' and 'agents'. While a 'server' may act as an agent as well, it is mainly to organize and control the cluster. In a sense it is comparable to a 'head node' in HPC. It is possible to deploy the server role using Warewulf - and we have done so for our experiments. However, at present Warewulf is capable of deploying ephemeral systems only while the server role may require to maintain some state. Therefore, it may be preferrable to set it up as a permanent installation and utilize Warewulf for agent depoyment only. We will still describe how to deploy a server using Warewulf.

Container Image Storage

Since our workloads are containerized, the container host requires only a very minimal installation. This installation - together with RKE2 - will not use up much of a node's memory when running out of a RAM disk. This is different for container images which are pulled from registries and stored locally. If these were stored on RAM disk, memory would quickly be exhausted. Fortunately, warewulf is able to set up mass storage devices - optionally every time a node is started. We will show how to set up storage for container images using Warewulf.

Basic Setup

This post will not cover how to perform the basic network setup required for the nodes to PXE-boot from the Warewulf deployment server or make nodes known to Warewulf. These topocs are all covered in Christian's Blog already.

Setup

Create Deployment Image

Warewulf utilizes container registries to obtain installation images. We start by importing a base container image from the openSUSE registry.

wwctl container import \
  docker://registry.opensuse.org/science/warewulf/leap-15.6/containers/kernel:latest \
  leap15.6-RKE2

General Image Preparation

Since this base image is generic, we need to install any missing packages required to install and start the RKE2 service. First, open up a shell inside the node image:

wwctl container shell leap15.6-RKE2

and run:

zypper -n in -y tar iptables awk
cd /root
curl -o rke2.sh -fsSL https://get.rke2.io

tar and awk are required by the RKE2 install script while iptables is required by K8s to set up the container network.

Image Preparation for Container Image Storage

This step is optional, but it is advisable to set up a storage device to hold container images. Container image storage is required on every node that will act as an agent - including the server node.
First we need to prepare the deployment image. To do so, we log into the image again to we create the image directory:

mkdir /var/lib/rancher

Then we install the packages required to perform the setup:

zypper -n in -y --no-recommends ignition gptfdisk

Prepare the Image for the K8s Server

Now, we are done with the common setup. We can exit the shell session in the container. When doing so, we need to make sure, the container image is rebuilt. We should see a message: Rebuilding container.... If this is not the case, we need to rebuild the image by hand:

wwctl container build leap15.6-RKE2

It's recommend to install the K8s Server permanently, therefore, if we would like to follow this recommendation, we can skip the reminder of this section.

Otherwise, we clone our image for the server:

wwctl container copy leap15.6-RKE2 leap15.6-RKE2-server

open a shell in the newly created server image:

wwctl container shell leap15.6-RKE2-server

install and enable rke2-server and adjust the environment for RKE2:

# Install the RKE2 tarball and prepare for server start
cd /root
INSTALL_RKE2_SKIP_RELOAD=true INSTALL_RKE2_VERSION="v1.31.1+rke2r1" sh rke2.sh
# Enable the service so it comes up later
systemctl enable rke2-server
# For container deployment we want `helm`
zypper -n in -y helm
# Set up environment so kubectl and crictl are found and will run
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

We are pinning the version to the one this has been tested with. If we omit INSTALL_RKE2_VERSION=... we will get the latest version. Now, we exit the shell in the server container and again make sure the image is rebuilt.

Prepare the Image for the K8s Agents

We need to finalize the agent image by downloading and installing RKE2 and enabling the rke2-agent service. For this, we log into the container

wwctl container shell leap15.6-RKE2

and run:

cd /root
INSTALL_RKE2_SKIP_RELOAD=true INSTALL_RKE2_TYPE="agent" \
 INSTALL_RKE2_VERSION="v1.31.1+rke2r1" sh rke2.sh
systemctl enable rke2-agent

Here, we are pinning the RKE2 version to the version this has been tested with. This has to match the version of the server node. If the server node has not been deployed using Warewulf, we need to make sure its version matches the version used here. If we omit INSTALL_RKE2_VERSION=... we will get the latest version. When logging out, we make sure, the container image is rebuilt.

Set up a Configuration Template for RKE2

Since the K8s agents and servers need a shared secret - the connection token - and secondary nodes need information about the primary server to connect, we set up a warewulf configuration overlay template for these.
We create a new overlay rke2-config on the Warewulf deployment server by running:

wwctl overlay create rke2-config

create a configuration template

cat > /tmp/config.yaml.ww <<EOF
{{ if ne (index .Tags "server") "" -}}
server: https://{{ index .Tags "server" }}:9345
{{ end -}}
{{ if ne (index .Tags "clienttoken") "" -}}
token: {{ index .Tags "connectiontoken" }}
{{ end -}}
EOF

and import it into the overlay setting its owner and permission:

wwctl overlay import --parents rke2-config /tmp/config.yaml.ww /etc/rancher/rke2/config.yaml.ww
wwctl overlay chown rke2-config /etc/rancher/rke2/config.yaml.ww 0
wwctl overlay chmod rke2-config /etc/rancher/rke2/config.yaml.ww 0600

This template will create a server: entry pointing to the communication endpoint (address & port) of the primary K8s server and a token: which will hold the client token in case these entries exist in the configuration of the node or one of its profiles. (These templates use the Golang text/template engine. Also, check the upstream documentation for the template file syntax.)

Set up Profiles

At this point, we create some profiles which we will use for setting up all node, i.e. the Agents and - if applicable - the Server. To simplify things, we assume the hardware for all the nodes is identical.

The 'Switch to tmpfs' Profile

Container runtimes require pivot_root() to work, which is not possible as long as we are still running out of a rootfs. This is not only the case for K8s but also for podman. Since the default init process in a Warewulf deployment doesn't perform a switch_root, we need to change this. To do so, we need to perform two things:

1. Make sure that rootfs is not a tmpfs. This can be done by adding rootfstype=ramfs to the kernel command line.
2. Let init know that we intend to switch to tmpfs. We do this by setting up a profile for container hosts:

wwctl profile add container-host
wwctl profile set --root=tmpfs -A "crashkernel=no net.ifnames=1 rootfstype=ramfs" container-host

(Here, crashkernel=no net.ifnames=1 are the default kernel arguments.)

Set up the Container Storage Profile

As stated above, this step is optional but recommended.
To set up storage on the nodes, the deployment images need to be prepared as describe above in section 'Image Preparation for Container Image Storage'.
For simplicity, we assume that all nodes will receive the identical storage configuration. Therefore, we create a profile which we will add to the nodes later. It, however, would be easy to set up multiple profiles or override settings per node.
We create the profile container-storage and set up the disk, partition, file system and mount point:

wwctl profile add container-storage
wwctl profile set --diskname <disk> --diskwipe[=false] \
   --partname container_storage --partnumber 1  --partcreate=true \
   --fsname container_storage --fsformat ext4 --fspath /var/lib/rancher
   container-storage

Here, we need to replace <disk> by the physical storage device we want to use. If the disks are not empty initially, we should set the option --diskwipe=true. This will cause the disks to be wiped on every consecutive boot, therefore, we may want to unset this later. --partcreate makes sure, the partition is created if it doesn't exist. Most other arguments should be self-explanatory. If we need to set up the machines multiple times and want to make sure the disks are wiped each time, we should not rely on the --diskwipe option which in fact only wipes the partition table: if an identical partion table is recreated, ignition will not notice and reuse the partition from a previous setup.

Set up the Connection Token Profile

RKE2 allows to configure a connection token to both Servers and Agents. If none is provided to the primary server it will be generated internally. If we set up the server persistently, we need to create a file /etc/rancher/rke2/config.yaml with the content:

token: <connection_token>

before we start this server for the first time, or if the server has been started before already, we need to obtain the token from the file /var/lib/rancher/rke2/server/node-token on this machine and use it for the token variable below. We now run:

wwctl profile add rke2-config-key

generate the token, add the rke2-config overlay to the profile and set a tag containing the token that will later be used by the profile:

token="$(printf 'K'; \
         for n in {1..20}; do printf %x $RANDOM; done; \
         printf "::server:"; \
         for n in {1..20}; do printf %x $RANDOM; done)"
wwctl profile set --tagadd="connectiontoken=${token}" \
              -O rke2-config rke2-config-key

Set up the 'First Server' Profile

This profile is used to point the agents (and secondary servers) to the initial server:

wwctl profile add rke2-config-first-server
wwctl profile set --tagadd="server=${server}" -O rke2-config rke2-config-first-server

Start the Nodes

With these profiles in place, we are now able to set up and boot all machine roles.

Start and Test the first K8s Server

If we use Warewulf to also deploy the K8s server, we need to start it now and make sure it is running correctly before we proceed to start the nodes. Otherwise, we assume a server is running already which we can connect via ssh and proceed to the next section.

It's assumed that we have already performed a basic setup of the server node (like make its MAC and designated IP address known to Warewulf). First we add the configuration profiles to the server. This includes the container-host and container-storage as well as the rke2-config-key profiles. We also set the container image:

wwctl node set -P default,container-host,container-storage,rke2-config-key -C leap15.6-RKE2-server <server_node>

Finally, we build the overlays:

wwctl overlay build <server_node>

Now, we are ready to power on the server and wait until is has booted. Once this is the case, We log into it via ssh. There we can observe the RKE2 server service starting:

systemctl status rke2-server

The output will show containerd, kubelet and several instances of runc (containerd-shim-runc-v2) running. When the initial containers have completed starting, the output should contain the lines:

Oct 07 16:36:36 dell04 rke2[1299]: time="2024-10-07T16:36:36Z" level=info
msg="Labels and annotations have been set successfully on node: k8s-server"
Oct 07 16:36:42 dell04 rke2[1299]: time="2024-10-07T16:36:42Z" level=info msg="Adding node k8s-sesrver-d034de85 etcd status condition"
Oct 07 16:37:00 dell04 rke2[1299]: time="2024-10-07T16:37:00Z" level=info msg="Tunnel authorizer set Kubelet Port 0.0.0.0:10250"

We can watch the remaining services starting by running:

kubectl get pods -A

Once all services are up and running, the output should look like this:

NAMESPACE     NAME                                                    READY   STATUS      RESTARTS   AGE
kube-system   cloud-controller-manager-k8s-server                     1/1     Running     0          20m
kube-system   etcd-k8s-server                                         1/1     Running     0          19m
kube-system   helm-install-rke2-canal-lnvv2                           0/1     Completed   0          20m
kube-system   helm-install-rke2-coredns-rjd54                         0/1     Completed   0          20m
kube-system   helm-install-rke2-ingress-nginx-97rh7                   0/1     Completed   0          20m
kube-system   helm-install-rke2-metrics-server-8z878                  0/1     Completed   0          20m
kube-system   helm-install-rke2-snapshot-controller-crd-mt2ds         0/1     Completed   0          20m
kube-system   helm-install-rke2-snapshot-controller-l5bbp             0/1     Completed   0          20m
kube-system   helm-install-rke2-snapshot-validation-webhook-glkgm     0/1     Completed   0          20m
kube-system   kube-apiserver-k8s-server                               1/1     Running     0          20m
kube-system   kube-controller-manager-k8s-server                      1/1     Running     0          20m
kube-system   kube-proxy-k8s-server                                   1/1     Running     0          20m
kube-system   kube-scheduler-k8s-server                               1/1     Running     0          20m
kube-system   rke2-canal-xfq6l                                        2/2     Running     0          20m
kube-system   rke2-coredns-rke2-coredns-6bb85f9dd8-fj4r4              1/1     Running     0          20m
kube-system   rke2-coredns-rke2-coredns-autoscaler-7b9c797d64-rxkmm   1/1     Running     0          20m
kube-system   rke2-ingress-nginx-controller-nmlhg                     1/1     Running     0          19m
kube-system   rke2-metrics-server-868fc8795f-gz6pz                    1/1     Running     0          19m
kube-system   rke2-snapshot-controller-7dcf5d5b46-8lp8w               1/1     Running     0          19m
kube-system   rke2-snapshot-validation-webhook-bf7bbd6fc-p6mf9        1/1     Running     0          19m

This server is now ready to accept agents (and secondary servers). If we require additional servers for redundancy, their setup is identical, however, we will need to add the rke2-config-first-server profile when setting up the node above.

Start and verify the Agent

Now, we are ready to bring up the agents. First, we set up the nodes by adding the profiles container-host, container-storage, rke2-config-key and rke2-config-first-server to all the client nodes:

agents=<agent_nodes>
wwctl node set -P default,container-host,rke2-agent,container-storage $agents

as well as the container image for the agent:

wwctl node set -C leap15.6-RKE2 <agent_nodes>

and rebuild the overlays for all agent nodes:

wwctl overlay build $agents

We replace <agent_nodes> by the appropriate node names. This can be a comma-seperated list, but also a range of nodes specified in squuare brackets - for example k8s-agent[00-15] would refer to k8s-agent00 to k8s-agent15 - or lists and ranges combined.

At this point, we are able to boot the first agent node. Once the first node is up, we may log in using ssh and check the status of the rke2-agent service:

systemctl status rke2-agent

The output should contain lines like:

Oct 07 19:23:59 k8s-agent01 rke2[1301]: time="2024-10-07T19:23:59Z" level=info msg="rke2 agent is up and running"
Oct 07 19:23:59 k8s-agent01 systemd[1]: Started Rancher Kubernetes Engine v2 (agent).
Oct 07 19:24:25 k8s-agent01 rke2[1301]: time="2024-10-07T19:24:25Z" level=info
msg="Tunnel authorizer set Kubelet Port 0.0.0.0:10250"

This should be all we check on the agent. Any further verifications will be done from the server. We log into the server and run:

kubectl get nodes

This should produce an output like:

kubectl get nodes -A
NAME          STATUS   ROLES                       AGE    VERSION
k8s-server    Ready    control-plane,etcd,master   168m   v1.30.4+rke2r1
k8s-agent01   Ready    <none>                      69s    v1.30.4+rke2r1

We see that the first agent node is available in the cluster. Now, we can spin up more nodes and repeat the last step to verify they appear.

Conclusions

We've shown that it is possible to deploy a functional K8s cluster with RKE2 using Warewulf. We could for example proceed deploying the NVIDIA GPU operator with a driver container on this cluster as described in a previous Blog and set up a K8s cluster for AI workloads. Most of the steps were straight forward and could be derived from the Warewulf User Guide. The only non-obvious step to take were the ones required to set up the rootfs in a way that it is ensured the container runtime is able to call pivot_root.

GRUB2 with BLS is now in MicroOS and Tumbleweed

Recently the openSUSE project released for MicroOS and Tumbleweed a new version of the GRUB2 package, with a new subpackage grub2-$ARCH-efi-bls. This subpackage deliver a new EFI file, grubbls.efi, that can be used as replacement of the traditional grub.efi.

The new PE binary is a version of GRUB2 that includes a set of patches from Fedora, which makes the bootloader follow the Boot Loader Specification (BLS). This will make GRUB2 understand the boot entries from /boot/efi/loader/entries, and dynamically generate the boot menu showed during boot time.

This is really important for full disk encryption (FDE) because this means that now we can re-use all the architecture and tools designed for systemd-boot. For example, installing or updating the bootloader can now be done with sdbootutil install, the suse-module-tools scriptlets will create new BLS entries when a new kernel is installed, and the tukit and snapper plugins will take care of doing the right thing when snapshots are created or removed.

Reusing all those tools without modification was a significant win, but even better, many of the quirks that classical GRUB2 had when extending the event log are no longer present. Before this package, sdbootutil needed to take ownership of the grub.conf file, as this will be measured by GRUB2 by executed lines. That is right! For each line that is read and executed by the GRUB2 parser, a new PCR#8 will take place, and because GRUB2 support conditional as other complex constructors, it is very hard to predict the final value of PCR#8 without imposing a very minimal and strict grub.conf.

However, with the new BLS subpackage, this file, along with the fonts and graphical assets for the theme, and the necessary modules (such as bli.mod), are now included in the internal squashfs within the EFI binary. GRUB2 will no longer measure those internal files without compromising security guarantees because now it is the firmware that measures the entire EFI when the bootloader is executed during the boot process.

As today, we cannot use YaST2 to install GRUB2 with BLS, but we can do that manually very easily. We need to make a systemd-boot installation, replace LOADER_TYPE from systemd-boot to grub2-bls in /etc/sysconfig/bootloader, install the new GRUB2 BLS package, and do sdbootutil install. Another option is to play with one of the available images for MicroOS or Tumbleweed.

Have a lot of fun!

Han pasado ya los ocho meses de rigor desde la mega actualización del ecosistema de aplicaciones KDE. Fue justo un 28 de febrero cuando se dio el salto a KF6/Qt6 para todos los entorno de trabajo y aplicaciones de la Comunidad KDE. En estos meses, se ha trabajado duro para pulir el sistema al máximo y dar piceladas de lo que está por venir. De esta forma me complace anunciar hoy 8 de octubre, que ha sido lanzado Plasma 6.2, que quiere ser más amigable, más accesible y más inteligente, ¿lo conseguirá?

Lanzado Plasma 6.2: más amigable, más accesible y más inteligente

La Comunidad KDE ha publicado hoy Plasma 6.2, una versión que supone otro paso firme en la evolución positiva que está siendo la rama 6.x. Prueba de ello es que en sus dos primeras versiones (6.0 y 6.1) han sido escritorios 100% funcionales.

Esta nueva iteración tiene como objetivos convertir a Plasma en un entorno más amigable, más accesible y más inteligente. En palabras de sus desarrolladores:

Plasma 6 ha cobrado importancia en los dos últimos lanzamientos. Se han solucionado los problemas que siempre surgen con una migración importante y es hora de comenzar a cumplir las promesas de las nuevas plataformas tecnológicas Qt 6 y Wayland sobre las que se basa Plasma.

Uno de los temas pendientes ha sido hacer de Plasma un entorno más amigable para los artistas, proporcionando soporte completo para el hardware que las personas creativas necesitan para realizar su trabajo.

Así que empecemos por ahí…

Más información: KDE

Las novedades de Plasma 6.2

Hoy es un día de descarga y actualizaciones, y mientras espero que esté disponible para mi KDE Neon, os comento algunas de sus novedades:

No obstante, aquí tenéis unas pinceladas de las novedades que nos facilitaron los desarrolladores en su fase beta fueron las siguientes:

• Opción para reasignar los botones del lápiz de la tableta de dibujo a distintos tipos de clics del ratón.
• Capacidad de anular aplicaciones que bloquean la suspensión o el bloqueo de la pantalla.
• Discover es compatible ahora con PostmarketOS.
• Se ha renovado la interfaz gráfica del módulo Accesibilidad de las Preferencias del sistema para mayor… ¡accesibilidad!
• Nueva experiencia de usuario para el modo de edición de Plasma, para hacer que su modalidad sea más obvia y visualmente más elegante.
• Previsión meteorológica: Pronóstico nocturno del proveedor meteorológico NOAA.
• Opción para desactivar el desplazamiento suave en las aplicaciones de KDE.
• Se ha mejorado la organización de la vista de cuadrícula expandida de la bandeja del sistema.
• Ahora se reproduce un sonido al conectar o desconectar una pantalla.
• Herramienta de recorte integrada cuando se selecciona el avatar del usuario.
• Más información: KDE

En los próximas entradas más detalles.

La entrada Lanzado Plasma 6.2: más amigable, más accesible y más inteligente se publicó primero en KDE Blog.

This weekend I visited the first Audio Expo in Budapest. It was the first music event I truly enjoyed in years. Even if corridors and rooms were packed, there was enough fresh air. What sets this event apart from other events is the focus on listening to music on the vendors’ products rather than just the speeds and feeds on why you should buy their products. While, of course, the expected outcome is the same, with the emphasis on listening to live systems, I found the event much more comfortable to walk around.

Key takeaway

Do not judge quickly! Go back to a place multiple times! If you are lucky, there will be less people in the room, and you can sit at a better spot. You can also listen to a different music, or listen to the same speakers with a different amplifier. Actually, both of these happened to me this weekend, and brought drastic changes to the experience.

Best of Audio Expo

Everyone is asking me what I liked the most. I am not an engineer when it comes to listening to music. I just listen to my ears and do not care much about the technical details. At home I listen to a pair of Heed Enigma 5 speakers, which are omnidirectional. At the expo the best listening experience was another omnidirectional speaker: the MBL speakers at Core Audio. This was also probably the most expensive setup at the expo.

According to my ears the best value award should go to NCS Audio Reference One PREMIUM. I visited all rooms on all floors and listened to many different speakers along the way. Some were close to or matching the sound quality of the NCS Audio speakers, however for a lot higher price. I only felt with the MBL speakers that they sounded better, however from the price difference you can buy a luxury car :-)

Exhibitors

I had various programs in the neighborhood, so instead of a long block at the Audio Expo, I spent three times a few hours there. Some places I visited multiple times, just to ensure that my first judgment was not too quick. Let me share here my experiences with some of the exhibitors, in alphabetical order.

Allegro Audio

As usual, the system exhibited at Audio Expo sounded really nice. Allegro Audio not only distributes some quality components, but also has its own amplifier: Flow. I really love listening to their Franco Serblin Accordo monitor speakers, but Ktema was not bad either :-)

Core Audio

Probably the most expensive setup of the expo was exhibited by Core Audio. However, the first time I visited them, they played some terrible (at least to me) music. With that music, the whole setup sounded like a pair of $100 computer speakers. So, I started to wonder what is all the hype about MBL speakers… Fortunately, I returned to the show the next day and with a different selection of music, the system really shined, and became the best sounding system of the whole Expo. However, price is prohibitively expensive for most people…

Heed

I listen to various Heed components at home: DAC, amp and speakers. So, I was very happy to see the founder talking about the latest Heed products, and also having the opportunity to listen to them. I love Heed speakers, especially the omnidirectional variants, however for the demo they used GoldenEar speakers with the Heed amplifiers at the Expo. Not bad at all, but different.

NCS Audio

I already listened to Reference One a few times, and I was amazed. Rock, classical, jazz and others, all sounded perfectly on these speakers, no matter the room size. This time Reference One Premium was on stage, using cables from Bonsai Audio. This pair sounded even better than speakers costing many times more.

Popori Acoustics

I have been reading about Popori Acoustics for years. Finally I had a chance to listen to these electrostatic speakers made in Hungary for the first time. And I must admit that my first listening experience was not that good. Hearing a woman singing was fantastic. However, even if the sound of bass guitar was very detailed, it still sounded a kind of meh. Luckily I went back on the second day of the expo again. The amplifier was replaced, and suddenly not just human voice, but everything sounded perfectly.

Closing words

Of course there were many more exhibitors. In some cases I loved the sound I heard, but did not have enough time to go back, ask questions, take photos. Some examples are 72audio and Sabo Audio. And there were many more, where the sound was not bad, but did not impress me too much either.

I really hope that next year we will have a similarly good Audio Expo in Budapest!

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 renombrándola ya que en ella solo hablaré de Plasmoides para Plasma 6. En la entrada de hoy me complace compartir con vosotros el lanzador de aplicaciones DeepinMenu Classic, un lanzador que destaca por su elegancia y con el que llegamos a siete artículos dedicados a este tipo de widgets.

Lanzador de aplicaciones DeepinMenu Classic – Plasmoides para Plasma 6 (7)

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 llamado DeepinMenu Classic, otra creación de ZAYRONXIO que nos ofreceun lanzador de aplicaciones elegante y funcional, imitación del menú clásico de deepin, creado con el código del menú start.next, utilizando principalmente ditto by adhe como base.

Como se ve, además de las aplicaciones favoritas que se ponen a la izquierda, justo bajo del cuadro de búsqueda, tenemos la opción de ver todas las aplicaciones o, en la columna de la derecha, bajo del avatar, buscarlas por categorías. En la parte inferior, arriba de las opciones de apagado, nos encontramos con un reloj con fecha.

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 Lanzador de aplicaciones DeepinMenu Classic – Plasmoides para Plasma 6 (7) se publicó primero en KDE Blog.

The author shares their experience with the Atari VCS, purchased after years of anticipation. Initially intrigued by its retro aesthetic and modern features, the author details upgrades made to enhance performance. Ultimately, they find satisfaction in its dual functionality as a home theater PC and casual gaming console, celebrating its design and upgrade potential.

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 una actividad relaciona con eXeLearning, un vídeo de Cedec_Intef .

Cómo crear una actividad relaciona 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 una actividad relaciona con eXeLearning en la que el alumnado debe unir con flechas conceptos que pueden ser textos enriquecidos, imágenes y/o sonidos.

¿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 una actividad relaciona con eXeLearning – Vídeo se publicó primero en KDE Blog.

Ya está disponible una primera versión pre-alfa de la que será openSUSE Leap 16

El pasado 12 de junio de 2024 se publicaba openSUSE Leap 15.6, el último «service pack» o actualización menor de la serie de Leap 15 de la distribución de GNU/Linux openSUSE.

Y hoy mismo, ya se puede obtener una versión de la que será la próxima openSUSE Leap 16, eso sí, en estado pre-alfa, por lo que espera muchos cambios y posibles inestabilidades.

Las versiones Alfa y Beta son versiones en desarrollo de lo que será la futura versión final y estable de un sistema operativo.

La comunidad de openSUSE ofrece estas versiones de desarrollo para que la comunidad las pueda descargar y probar en sus equipos y sirvan para corregir errores, añadir nuevas funcionalidades y probar nuevas cosas antes de la versión final a fin de corregirlas y hacer que sea estable y fiable.

Esta nueva versión de Leap 16, ofrecerá la opción de instalar el sistema base y entornos de escritorio Gnome y Plasma de KDE, más adelante se irán añadiendo quizás más opciones.

Podrás descargar las imágenes de esta versión de desarrollo que incluirán el nuevo instalador Agama.

Leap 16.0, que verá la luz en otoño de 2025 será un cambio de versión importante respecto de Leap 15.6 actual y al ofrecer una versión en desarrollo tan pronto tiene como objetivo el ir puliendo cosas y que ese tránsito a una versión nueva sea un cambio sin complicaciones ni dolores de cabeza para quienes utilizan Leap.

openSUSE Leap 16, seguirá basándo su base en la distribución empresarial SUSE Linux Enterprise Server 16, por lo que se disfrutará de una distro estable con una paquetería comunitaria.

No hay ningún plan para hacer un Leap 15.7, sin embargo, todavía se necesita publicar los paquetes comunitarios publicados anteriormente desde Leap 15 a través de Package HUB para el próximo SLES 15 SP7. Es por eso que existen el proyecto openSUSE:Backports:SLE-15-SP7 y los repositorios 15.7 en OBS, la herramienta desde la que se construye la distribución openSUSE.

Como es habitual, este es un producto pre-alfa que no está diseñado para instalarse en tu equipo de uso diario. Se recomienda comenzar con la instalación en una máquina virtual y familiarizarse con el nuevo instalador en línea Agama.

Si quieres probar lo más nuevo, si quieres contribuir con pruebas, entonces instala Leap 16 y pruébalo de vez en cuando para comprobar la compatibilidad con tu hardware.

Si no, lo mejor es esperar a la primavera de 2025 donde se publicará la versión Beta, que aunque siga siendo de desarrollo ya es más similar a lo que nos encontraremos en la versión final.

Si pruebas estas versiones, no dudes en aportar tu granito si encuentras un bug, o testear la wiki con los bugs conocidos y aportar tu experiencia. O con el instalador Agama en su proyecto propio.

openSUSE Leap 16 está ya en camino y tu puedes tomar parte en su desarrollo, hay muchos aspectos en los que aportar: traducciones, márketing, diseño, desarrollo, documentación, etc. ¿Te animas?

Enlaces de interés

• https://news.opensuse.org/2024/10/07/leap-16-0-prealpha/
• https://get.opensuse.org/leap/16.0

Hello everyone!

I’d like to announce the start of development and the public availability of what we currently refer to as Leap 16.0 pre-Alpha. Since this is a pre-Alpha version, significant changes may occur, and the final product may look very different in the Alpha, Beta, Release Candidate, or General Availability stages. The installer will currently offer you Base, GNOME, and KDE.

Users can get our new Agama install images from get.opensuse.org/leap/16.0. The installer will currently offer you Base, GNOME, and KDE installation.

Leap 16.0 is a traditional distribution and a successor to Leap 15.6 with expected General Availability arriving in the Fall of 2025.

We intend to provide users with sufficient overlap so that 15.6 users can have a smooth migration, just like they’re used to from previous releases.

Further details are available on our roadmap. The roadmap is subject to change since we have to respond to any SUSE Linux Enterprise Server 16 schedule changes.

Users can expect a traditional distribution in a brand new form based on binaries from the latest SLES 16 and community packages from our Factory development codebase.

There is no plan to make a Leap 15.7, however, we still need to deliver previously released community packages from Leap 15 via Package HUB for the upcoming SLES 15 SP7. This is why there are openSUSE:Backports:SLE-15-SP7 project and 15.7 repos in OBS.

Who should get it?

This is a pre-alpha product that is not intended to be installed as your daily driver. I highly recommend starting with the installation in a virtual machine and becoming familiar with the online installer Agama.

The target audience for pre-Alpha are early adopters and contributors who would like to actively be part of this large effort. Adopters should consider booting Agama Media from time to time just to check compatibility with their hardware.

For non-contributor users, I highly recommend waiting until we have a Beta, which is expected in the late Spring of 2025.

How to report bugs?

I’d like to kindly ask you to check our Known bugs wikipage before reporting a new issue. If you find a new issue that is likely to affect users, please feel free to add it to the page.

Specifically for Agama I highly recommend using github.com/agama-project and collaborating with the YaST team on suggestions and incorporating any changes.

For the rest of the components, the workflow isn’t changing; just select version 16.0 for bug submissions.

Feature requests

All changes to packages inherited from SLES 16 need to be requested via a feature request.

Feature requests will be reviewed every Monday at a feature review meeting where we’ll convert code-o-o requests into JIRA requests used by SUSE Engineering where applicable.

The factory-auto bot will reject all code submit requests against SLES packages with a pointer to code-o-o. You can get a list of all SLFO/SLES packages simply by running osc ls SUSE:SLFO:1.1:Build.

Just for clarification SLFO, SUSE Linux Framework One, is the source pool for SLES 16 and SL Micro 6.X. SLFO was previously known as Adaptable Linux Platform (ALP).

I highly recommend using code-o-o to co-ordinate larger community efforts such as Xfce enablement, where will likely need to update some of SLES dependencies. This allows us to share the larger story and better reasoning for related SLES update requests. The list of features is also extremely valuable for the Release article.

Where to submit packages, how is it built, and where is it tested?

Leap 16.0 is built in openSUSE:Leap:16.0 project where we will happily welcome any community submissions until the Beta code submission deadline in the late Spring of 2025. We intend to keep the previous development model and avoid forking SLES packages unless necessary. We no longer can mirror SLES code submissions from OBS into IBS. So all SLES 16 update requests have to be requested via feature requests.

For quality control, we have basic test suites based on Agama installations in Leap 16.0 job group. Later, we plan to rework the existing Leap 16.0 Images job group for testing the remaining appliance images.

The project where we maintain community packages is subject to change as we have not fully finalized yet how to make Package HUB; we may use a similar structure with Backports as in 15.3+).

Further test suite enablement is one of the areas where we currently need the most help. Related progress.opensuse.org trackers poo#164141 Leap 16.0 enablement and poo#166562 upgrade from 15.6.

Another area where you can help is new package submissions and related maintainer review of package submissions to Leap 16.0. These reviews make sense as we’d like to check with maintainers whether that software in a given version makes sense for inclusion into Leap 16.0, rather than blindly copying all packages over.

Involvement in branding and marketing efforts

I’m very proud to announce fresh branding efforts and want to thank all the people who helped give Leap and Tumbleweed a new look. We plan to publish an article or a video about the changes, and further plans as we still have a surprise or two in our pocket.

Do you want to help us on this front? Spread the news and feel free to join the openSUSE Marketing Team in our Telegram channel.

Many thanks to all who helped us to reach this point.

Lubos Kocman
on behalf of the openSUSE Release team