openSUSE MicroOS is one of openSUSE’s most exciting projects, and for me has replaced openSUSE Leap as my go-to server operating system of choice. I currently have 3 MicroOS installations, all running as podman with openSUSE containers. The machines are as follows:

• A nice fanless Zotac x86-64 NUC running at home as my Nextcloud and ssh-based backup server/NAS
• A VM on Hetzner Cloud running this blog, my saltstack master and a few other public facing services. (Kudos to Hetzner for adding the openSUSE MicroOS ISO to the list of Cloud ISOs so I could do a custom installation)
• A VM on Linode for running a US-based proxy for some of my friends who otherwise might have too-high latency accessing services on the Hetzner host. (Kudos to Linode for consistantly supporting openSUSE Leap releases on the day of release and providing ways of doing custom installs of any OS)

And so, with all these MicroOS boxes in my life, as reliable as they may be, I wanted to have a simple way of keeping an eye on whether or not the machines are up or not, possibly evolving to more interesting checks in the future. I wanted this to be able to monitor my machines even when my main laptop at home is off, and I wanted to not have to worry about updating the monitoring system at all. So an idea formed, why not use MicroOS to monitor MicroOS?

Hardware Used

I cobbled this little project together out of random bits of hardware I had lying around, namely:

• Raspberry Pi 3B+ with the official RPi case
• Joy IT 3.2” TFT display with 3 GPIO buttons
• 32GB micro SDCard
• 8GB random old USB stick

Software Used

I found a very nice command-line visualisation tool called sampler that perfectly fit my needs for this project. It’s nice and small, lets you draw graphs based on numbers it gets from whatever shell commands you run at whatever frequency you tell it to poll. It can also produce alerts if the results do not match expected values. So given the basic monitoring I want is basically just a ping and be alerted if they stopped responding, sampler is absolutely perfect. I packaged it for openSUSE as part of this project so it’s now available for regular Tumbleweed as well as MicroOS.

Installing MicroOS on the SDCard

First I needed to download the latest official openSUSE MicroOS aarch64 image for Rasbperry Pi from the official download page. For this project we’re using a plain old MicroOS image without any pre-installed services, not the Container Host images which come with podman.

wget https://download.opensuse.org/ports/aarch64/tumbleweed/appliances/openSUSE-MicroOS.aarch64-RaspberryPi.raw.xz

Putting in the SDCard into the reader, I simultaniously extracted the image and wrote it direct to the image with the following command. (Substitue sdX with the correct name for your SDCard device)

xzcat openSUSE-MicroOS.aarch64-RaspberryPi.raw.xz | dd bs=4M of=/dev/sdX iflag=fullblock oflag=direct status=progress; sync

And that’s it, the SDCard is ready to go…or is it?

But Wait!

By default, MicroOS images have no root password, no user accounts, and no services installed. I needed to have some way to setup the Pi when it first boots from the SDCard. MicroOS has two tools available for such first boot configuration:

• Ignition, originally from CoreOS which has a lovely structured JSON config but a limited scope of what it can setup.
• Combustion, written specifically for MicroOS and capable of doing anything you can write in a shell script.

As I already had a feeling I’d need to do some quirky things, especially to get the TFT display running, I opted to use combustion. I could have used ignition for the easy stuff and left combustion in combination for the trickier parts but it seemed silly to me to have to learn how to write a new JSON config file when I could just as easily write everything in a shell script.

Preparing a combustion USB stick

On first boot combustion looks for a device with a volume named combustion containing a directory called combustion and a script called script so that’s precisely what I did to my USB stick

mkfs.ext4 /dev/sdY
e2label /dev/sdY combustion
mount /dev/sdY /mnt
mkdir -p /mnt/combustion/
touch /mnt/combustion/script

After a few trial runs and a bit of hacking around the final script now looks like this:

#!/bin/bash
# combustion: network

## Copy config and device tree overlays for Pi TFT & GPIO buttons to /boot/efi
cp extraconfig.txt /boot/efi/
cp joy-IT-Display-Driver-32b-overlay.dtbo /boot/efi/overlays/
cp tft_keys.dtbo /boot/efi/overlays/

## Change boot params so framebuffer console goes to TFT display
sed -i "/^GRUB_CMDLINE_LINUX_DEFAULT=/ s/\"$/ fbcon=map:10\"/" /etc/default/grub
grub2-mkconfig -o /boot/grub2/grub.cfg

## Mount /var and /home so user can be created smoothly
mount /var
mount /home

## Make user
useradd -m ilmehtar

## Add user to sudoers
echo "ilmehtar ALL=(ALL) NOPASSWD: ALL" > /etc/sudoers.d/ilmehtar

## Create ssh folder and populate authorized_keys for remote sshd
mkdir -pm700 /home/ilmehtar/.ssh
chown ilmehtar:users -R /home/ilmehtar/.ssh
cat authorized_keys > /home/ilmehtar/.ssh/authorized_keys

## Setup vconsole so framebuffer console has right font/keyboard layout (Optional)
cp vconsole.conf /etc/vconsole.conf

## Setup Wifi
cp wpa_supplicant.conf /etc/wpa_supplicant/wpa_supplicant.conf
systemctl enable wpa_supplicant@wlan0.service
cp /etc/sysconfig/network/ifcfg-eth0 /etc/sysconfig/network/ifcfg-wlan0

## Disable IPv6 (Optional)
cp 90-disableipv6.conf /etc/sysctl.d/

## Install sampler
zypper --non-interactive install sampler
cp sampler.yaml /home/ilmehtar/sampler.yaml

## Make user login by default
mkdir -p /etc/systemd/system/getty@tty1.service.d
cp autologin.conf /etc/systemd/system/getty@tty1.service.d

## Make sampler run by default
echo "[ \$TERM = 'linux' ] && sleep 30 && sampler -c ~/sampler.yaml" >> /home/ilmehtar/.bashrc

## Reboot after setup
cp firstbootreboot.service /etc/systemd/system/
systemctl enable firstbootreboot.service

## Clear up mounts
umount /var
umount /home

The script references a number of additional files, all of which are placed alongside script in the combustion directory on the USB stick:

File Listing of the combustion directory

90-disableipv6.conf
authorized_keys
autologin.conf
extraconfig.txt
firstbootreboot.service
joy-IT-Display-Driver-32b-overlay.dtbo
sampler.yaml
script
tft_keys.dtbo
tft_keys.dts
vconsole.conf
wpa_supplicant.conf

Joy-IT-Display-Driver-32b-overlay.dtbo is a Device Tree overlay provided by the manufactorer of the TFT hat. tft_keys.dtbo is my own Device Tree overlay compiled from tft_keys.dts. All the other files are text files used to configure various aspects of the system to my liking and are documented at the bottom of this post for anyone wanting to use this idea as a basis for their own projects.

First Boot

And with all that prep work done, the first boot is now surprisingly easy. I inserted the SDCard, added the USB stick and connected the Pi to ethernet (The wifi won’t work until it’s configured by combustion). Powering on the Pi the whole device can be left alone for a few minutes. It boots itself, does all of the configuration, and the end result is a nice working desktop network monitor:

The GPIO switches on the top even work as the P and ESC keys for sampler, allowing me to pause the polling or dismiss any alerts. A little bit of hardware hacking (read: hot glue and acryrlic) finished of the project with a little stand so the whole thing sits on my desk at an angle easy for me to read.

The system doesn’t have any passwords, so can’t be logged in remotely with the exception of ssh using the non-root user using my existing public key. Simple and secure enough.

All this might seem like a little overkill, I realise it probably is, but one great benefit of having everything in this one combustion script is now I know I can wipe that SDCard or use a new Pi and get it back up and running to exactly how I like it directly from the first boot, without any manual intervention at all. Which I guess means I could reuse this Pi for other projects..anyone got any ideas?

Thanks and Have a Lot of Fun

Additional Config Files Used (For Reference)

90-disableipv6.conf

net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1

autologin.conf

[Service]
ExecStart=
ExecStart=-/sbin/agetty -a ilmehtar %I $TERM

extraconfig.txt

dtoverlay=joy-IT-Display-Driver-32b-overlay:rotate=0,swapxy=1
dtoverlay=tft_keys
gpio=18,23,24=pu
dtparam=audio=on
max_usb_current=1
hdmi_force_hotplug=1
config_hdmi_boost=7
hdmi_drive=1
hdmi_ignore_edid=0xa5000080

firstbootreboot.service

[Unit]
Description=First Boot Reboot

[Service]
Type=oneshot
ExecStart=rm /etc/systemd/system/firstbootreboot.service
ExecStart=rm /etc/systemd/system/default.target.wants/firstbootreboot.service
ExecStart=systemctl reboot

[Install]
WantedBy=default.target

sampler.yaml

runcharts:
  - title: Status
    position: [[0, 2], [80, 40]]
    rate-ms: 1000
    triggers:
      - title: Node Down
        condition: '[ $cur = "DOWN" ] && echo 1 || echo 0'
        actions:
            visual: true
    legend:
        enabled: true
        details: false
    scale: 0
    items:
      - label: node1
        sample: ping -qc5 192.168.1.1 2>&1 | awk -F'/' 'END{ print (/^rtt/? $5:"DOWN")
            }'
      - label: node2
        sample: ping -qc5 192.168.1.2 2>&1 | awk -F'/' 'END{ print (/^rtt/? $5:"DOWN")
            }'
      - label: node3
        sample: ping -qc5 192.168.1.3 2>&1 | awk -F'/' 'END{ print (/^rtt/? $5:"DOWN")
            }'
      - label: node4
        sample: ping -qc5 192.168.1.4 2>&1 | awk -F'/' 'END{ print (/^rtt/? $5:"DOWN")
            }'
      - label: node5
        sample: ping -qc5 192.168.1.5 2>&1 | awk -F'/' 'END{ print (/^rtt/? $5:"DOWN")
            }'

tft_keys.dts

/dts-v1/;
/plugin/;
/ {
	compatible = "brcm,bcm2835";
	
	fragment@0 {
		target-path = "/soc";
		__overlay__ {
			tft_keys{
				compatible = "gpio-keys";
				autorepeat;
				key1 {
					label = "Key 1";
					linux,code = <1>;
					gpios = <&gpio 18 1>;
				};
                                key2 {
                                        label = "Key 2";
                                        linux,code = <25>;
                                        gpios = <&gpio 23 1>;
                                };
                                key3 {
                                        label = "Key 3";
                                        linux,code = <1>;
                                        gpios = <&gpio 24 1>;
                                };
			};
		};
	};
};

vconsole.conf (Because uk layout is best keyboard layout)

KEYMAP=uk
FONT=eurlatgr.psfu
FONT_MAP=
FONT_UNIMAP=

wpa_supplicant.conf

network={
   ssid="My-SSID"
   psk="MyPassword"
}

Veamos cómo marcar posiciones en un texto utilizando las marcas que podemos utilizar al trabajar con el editor Vim

Mientras estamos utilizando el editor Vim, podemos marcar una posición (línea, columna) para poder regresar a ella cuando lo necesitemos. De hecho podemos establecer varias marcas para acceder a diferentes partes del documento.

Veamos los comandos básicos para establecer diferentes marcas y cómo podemos trabajar con esta herramienta de Vim.

Este artículo es una nueva entrega del curso “improVIMsado” que desde hace meses vengo publicando en mi blog sobre el editor Vim y que puedes seguir en estos enlaces:

• https://victorhckinthefreeworld.com/tag/vim/
• https://victorhck.gitlab.io/comandos_vim/articulos.html

Al establecer una marca en Vim, esta te permite guardar la posición actual donde se encuentra el cursor para poder regresar a ella cuando quieras.

Al establecer una marca, no hay una señal visible en el documento que indique donde se han establecido las marcas.

En Vim las marcas se establecen con letras minúsculas de la “a” a la “z”. (También hay marcas con las letras mayúsculas, que veremos en otra ocasión).

Cada marca es específica para el archivo que se establece. Es decir, puedes estar editando varios archivos y establecer la marca “a” en cada uno, y todas serán distintas y accesibles hasta que cierres el archivo.

¿Cómo establecer marcas en Vim?

Para guardar la posición actual del cursor (fila y columna) en una marca en Vim, esta se establece en el modo normal, con la letra “m” mas la letra minúscula de la “a” a la “z” según la letra que queramos utilizar. Por ejemplo, para establecer la marca “a” ejecutaremos:

m a

Podremos seguir utilizando Vim editando el archivo, pero si queremos volver a regresar a esa marca, en el modo normal pulsaremos la comilla inclinada (`) y la letra de la marca:

` a

Con esto, el cursor regresará a la misma posición que grabamos la marca “a”.

También podemos utilizar la comilla simple (‘) y la letra de la marca a la que queremos regresar. Con esta combinación de teclas, el cursor se posicionará en el primer caracter que no sea un espacio en blanco de la línea donde esté establecida la marca.

Puedes abrir el editor Vim y establecer una marca y regresar a ella utilizando ambos métodos para ver la diferencia. Es pequeña, pero puede ser sustancial uno u otro método.

Pero ahora imaginemos que queremos seguir en donde estábamos antes de saltar a la marca para continuar con la edición del texto. Vim nos lo pone muy fácil.

Además de las marcas que establezcamos, hay otras marcas del propio editor Vim que se van estableciendo en diversos lugares y que podremos utilizar a nuestra conveniencia.

Es el caso de la marca del último sitio en el que estaba el cursor antes de saltar a la marca. Vim guarda esa ubicación y estará disponible ejecutando este comando:

` '

Con esto después de haber saltado a la marca deseada, al ejecutarlo llevará de nuevo el cursor a la posición original desde la que saltó. ¿No es genial?

Podemos ver todas las marcas que tenemos establecidas con el comando:

:marks

En donde veremos las marcas de las letras que hayamos establecido, y además las marcas especiales que Vim va guardando en diferentes ocasiones (última posición del cursor, posición del último archivo editado cuando se salió de Vim, etc)

Resumen

Vamos a hacer un repaso de lo que hemos aprendido en este artículo sobre las marcas temporales que podemos crear con Vim y cómo utilizarlas:

• ma → Crea la marca “a” en la posición actual del cursor
• 'a → Salta a la línea en la que hemos establecido la marca “a”. En el primer caracter de la línea que no sea un espacio en blanco
• `a → Salta a la posición exacta en la que se creó la marca “a”
• d'a → Borra desde la línea actual hasta la línea donde se encuentra la marca “a”
• d` a → Borra desde la posición actual del cursor hasta la posición exacta donde se encuentra la marca “a”
• c'a → Cambia el texto desde la posición actual hasta la línea marcada con la letra “a”

Y esto es lo básico que podemos aprender sobre este tipo de marcas de letras minúsculas que podemos establecer y utilizar en el editor Vim.

Espero haberme expresado bien y se haya comprendido la utilidad y funcionalidad que podemos sacar de esta herramienta de Vim.

 Avances en las imágenes de openSUSE para The PinePhone

 Traducción del articulo original publicado por Douglas DeMaio

La conciencia creció después de que apareció una publicación en un foro en línea en junio sobre imágenes de openSUSE para PinePhone, que es un teléfono inteligente desarrollado por Pine64 que permite al usuario tener un control total sobre su dispositivo y ejecutar la línea principal de Linux.

"Estoy trabajando en la portabilidad de openSUSE para PinePhone", comenzaba la publicación. “Estoy trabajando en algunas mejoras para migrar todos los paquetes a openSUSE. Estoy trabajando con Open Build Service, así que pronto tendremos noticias al respecto ".

Las respuestas a la publicación comenzaron a llenar la página y se corrió la voz. En el momento en que la animación del logo se hizo visible en la pantalla de PinePhone, se tomaron fotos, se publicaron en las redes sociales y los comentarios comenzaron a difundirse en Twitter.

“Lo más interesante de mi trabajo con PinePhone fue crear la animación de arranque del logo de Geeko”, dijo Adrián Campos Garrido, quien llevó el proyecto de afición a una capacidad oficial.

Garrido, quien es un arquitecto de plataforma, hizo esto al llevar su pasión y trabajo al proyecto devel, envió los paquetes que estaba usando para el proyecto a openSUSE Factory y comenzó a construir las imágenes oficiales en OBS.

“Estoy muy contento con toda la migración a OBS ya que me permite hacer el trabajo que hacía antes pero todo es mucho más eficiente y más cómodo”, dijo. “Mi interés por el PinePhone vino desde el primer momento porque era un dispositivo con grandes posibilidades de convertirse en el primer dispositivo a un precio razonable que funciona prácticamente igual que una computadora; ya que se presentó como integrado en el núcleo principal de GNU / Linux ".

Los primeros pasos se enfocaron en cómo crear una imagen de sistema operativo, dijo Garrido, quien está interesado en todo lo relacionado con la tecnología y el código abierto.

“Para esto utilicé una serie de scripts y un esclavo Jenkins en mis servidores para crear una imagen”, dijo. “Luego, comencé a portar todos los paquetes a openSUSE; comenzando por aprender cómo funcionaban los archivos de especificaciones para crear paquetes RPM ".

Su viaje de creación de imágenes de openSUSE para PinePhone no fue fácil.

"Lo más difícil fue adaptar el kernel con el paquete para hacer que las llamadas y el audio funcionen".

Todavía hay algunos problemas conocidos que deben solucionarse, como el Bluetooth, el acelerómetro y el GPS. Garrido se ha centrado en mantener los lanzamientos lo más estables posible y planea avanzar con un mapeo (roadmap) que le permita tener un objetivo más claro de por dónde continuar.

"Cualquier ayuda es bienvenida, desde ayudar con el mantenimiento del paquete hasta informar errores", dijo. "Los informes son muy interesantes y me permiten priorizar algunas tareas sobre otras".

Las personas pueden ponerse en contacto con Garrido en GitHub y averiguar cómo ayudar en la página wiki de imágenes de openSUSE.

Hoy vamos de demostraciones, y es que de la mano de baby WOGUE podremos ver un vídeo donde nos ofrece una demostración de Plasma 5. Una prueba más de la versatilidad y el buen hacer de la Comunidad KDE.

Una demostración de Plasma 5

Aunque alguna funcionalidad que veamos pueden pertenecer a Plasma 5.21, os presento una demostración de Plasma 5 en el que vemos la potencia de una escritorio sin igual en el mundo de la computación.

Así, a lo largo de los 5 minutos y poco que dura el vídeo, baby WOGUE nos muestra cosas como:

• Como trabajar intercambiando las ventanas entre los escritorios virtuales.
• Como interactúa Elisa, un reproductor de audio que cada versión es más potente, con los ficheros y las carpetas que lo contienen.
• La división de pantalla de Konsole y la forma de visualizar las barras de herramientas del mismo.
• El modo que tiene Dolphin de mostrar diversas pestañas y de dividir su pantalla en dos secciones independientes, pudiendo pasar archivos desde cualquiera de estas vistas a otra.
• La posibilidad de activar la vista previa de archivos en el modo terminal.
• El funcionamiento avanzado de las notificaciones o el control independiente del sonido controlable desde la bandeja del sistema.
• Algunas opciones de comportamiento del espacio de trabajo.

Todo ello de una forma sencilla, relajada y con efectos de sonido muy acertados.

Y como siempre digo, si os gusta el vídeo podéis “pagarlo” de muchas formas, ya que el creador os lo agradecerá: puntúale positivamente, hazle un comentario en la página, dale un like o subscríbete a su canal. 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 2017 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.

Depuis quelques semaines, le paquet openMVS est disponible dans le dépôt graphics. Il est le complément quasi-indispensable à openMVG pour finaliser un modèle 3D quand on entreprend un traitement d'images par corrélation dense. Ce traitement d'images fait partie d'un sujet plus vaste qu'on nomme "Photogrammétrie".

Par abus de langage on peut parfois confondre les deux, alors laissons de côté pour l'instant le terme "Photogrammétrie" et étudions simplement le traitement d'images par corrélation dense.

Présentation d'openMVS et de ses outils

L'installation du paquet openMVS est désormais possible en ajoutant le dépôt graphics au préalable, comme ceci (en root) :
zypper addrepo https://download.opensuse.org/repositories/graphics/openSUSE_Leap_15.2/graphics.repo
ou :
zypper addrepo https://download.opensuse.org/repositories/graphics/openSUSE_Tumbleweed/graphics.repo

puis :
zypper refresh
zypper install openMVS

(note : si openMVG n'est pas installé, alors faites : zypper install openMVG)

Le paquet openMVS propose 7 outils : 4 pour traiter les données, 2 pour convertir les objets, et 1 pour visualiser les résultats (intermédiaires ou finaux). On retiendra donc DensifyPointCloud, ReconstructMesh, RefineMesh et TextureMesh pour traiter les données produites en amont par openMVG. Chaque outil dispose de ses propres options, pour en prendre connaissance on lance alors le programme sans argument, dans un terminal.

Le principe de pipeline : exemple et résultat

Le but d'openMVS est de (re)créer une scène en 3 dimensions à partir du jeu de données produit par openMVG. Ce dernier est donc l'étape préliminaire indispensable à toute opération : openMVG analyse les photographies qu'on lui indique et calcule les positions des objectifs et des points "clés" afin de proposer un rendu 3D de l'objet photographié. Car c'est bien ça le point de départ : les photos !

En résumé : si on associe openMVG + openMVS, alors on a la combinaison idéale pour générer un modèle 3D texturé en HD, à partir de simples photos (en JPG, sans zoom de préférence), pour autant qu'on respecte certaines règles dans le processus de traitement.

D'une manière générale, on distingue 4 étapes successives dans l'élaboration d'un modèle 3D, quels que soient les softs utilisés :

1. Alignement des photos
2. Densification du nuage de points
3. Génération du maillage
4. Texturage du maillage d'après les photos

Voyons sur un schéma comment tout cela s'articule, quand on compare à d'autres processus tels que ceux proposés par MVE et VisualSFM :

Et voici un exemple en images avec d'un côté les photos de départ d'un sujet de type architectural, et de l'autre un rendu (intermédiaire) ouvert dans MeshLab :

openMVG et openMVS s'utilisent en ligne de commande, pas d'interface graphique autre que le Viewer d'openMVS (exemple de rendu dans la première image de l'article). Alors pour traiter un sujet, l'idéal est de scripter l'ensemble du processus, avec parfois des options spécifiques à indiquer.

Voici un exemple ici avec RUN_openMVG_openMVS.sh, en lien sur cette page : SfM_Tools
Ce script met l'accent sur la gestion des logs, c'est un moyen efficace pour suivre le processus de traitement des images.
(dans cet exemple, le fichier sensor_width_camera_database.txt se situe dans le home utilisateur)

Pour mieux...

Pada tanggal 28-29 Agustus 2020 lalu dilakukan brainstorming eksternal. Selama 2 hari yaitu Jum’at dan Sabtu Team Excellent bekerja di luar markas. Hari Sabtu, 28 Agustus 2020 bekerja di rumah Qchen Marsan Susanto. Selain sebagai selingan bekerja, acara brainstorming Excellent juga dilakukan sebagai bagian dari acara ultah Excellent yang ke-9.

Kemudian dilanjutkan dengan kegiatan sore bermain ke kebun singkong milik Qchen Marsan Susanto sambil menikmati suasana sore hari.

Few weeks ago during server setup phase for one of my project, I notice there is no ICMP or ping replies from server and some port are not able to access.

I told the network engineer to check and seem they blocking the ports and disabling ICMP replies from their firewall configuration.

From that accident I do some google-fu if I can do same thing for personal computer / server. We can setting the kernel variable or use iptable to disable ICMP / ping replies if requested.

Temporarily disable ICMP / ping replies

$ su -
echo "1" >  /proc/sys/net/ipv4/icmp_echo_ignore_all
# This instructs the kernel to simply ignore all ping requests
# 1 = ignore ping requests and 0 = allow ping request

or

$ iptables -A INPUT -p icmp -j DROP

Permanently disable ICMP / ping replies

To disable ping requests permanently, add this line into your /etc/sysctl.conf file:

net.ipv4.icmp_echo_ignore_all = 1

And reload sysctl’s policy by # sysctl -p.

Or save iptables rule by

# for distros with systemd
/usr/libexec/iptables.init save

# for all other distros
service iptables save

# univeral way: edit main config by yourself
vim /etc/sysconfig/iptables

Awareness grew after a post in an online forum appeared in June about openSUSE images for the PinePhone, which is a smartphone developed by Pine64 that allows user to have full control over their device and run mainline Linux.

“I am working on porting openSUSE for PinePhone,” the post began. “I am working on some improvements porting all packages to openSUSE. I am working with Open Build Service, so soon we will have news about it.”

Replies to the post began to fill the page and word spread. At the moment the animation of the logo became visible on the PinePhone screen, pictures were taken, posted to social media and comments began to spread on Twitter.

“The most interesting thing about my work with the PinePhone was creating the Geeko logo boot animation,” said Adrian Campos Garrido, who took the hobby project to an official capacity.

Garrido, who is a Platform Architect, did this by bringing his passion and work to the devel project, submitted the packages he was using for the project to openSUSE Factory and began building the official images in OBS.

“I am very happy with all the migration to OBS since it allows me to do the work I did before but everything is much more efficient and more comfortable,” he said. “My interest in the PinePhone came from the first moment because it was a device with great possibilities of becoming the first device at a reasonable price that works practically the same as a computer; since it was presented as integrated into the mainline kernel of GNU/Linux.”

The first steps focused on how to create an operating system image, Garrido said, who is interested in everything related to technology and open source.

“For this I used a series of scripts and a Jenkins slave on my servers to create an image,” he said. “Then, I started to port all the packages to openSUSE; starting by learning how the Spec Files worked for building RPM packages.”

His journey of building the openSUSE images for the PinePhone wasn’t easy.

“The most difficult thing was to adapt the kernel with the package to make the calls and the audio work.”

There are still some known issues that need fixing like the Bluetooth, accelerometer and GPS. Garrido has been focused on keeping the releases as stable as possible and plans on progressing with a roadmap to allow him to have a clearer objective of where to continue.

“Any help is welcome from helping with the maintenance of the package to reporting bugs,” he said. “Reporting is very interesting and allows me to prioritize some tasks over others.”

People can contact Garrido on GitHub and find out how to help on the openSUSE images wiki page.

En este artículo veremos cómo establecer a Konsole un fondo transparente o un fondo propio para este emulador de consola

Konsole es el emulador de consola desarrollado por la comunidad KDE. Una herramienta que va ganando en opciones, funcionalidades y mejoras, por lo que lo hace mi herramienta preferida a la hora de trabajar con la consola.

Una herramienta a la que ya he dedicado varios artículos y tutoriales en mi blog. En esta ocasión veremos cómo darle un nuevo aspecto, con transparencias o con un fondo de escritorio propio para esta aplicación.

Abrimos Konsole y hacemos clic con el botón derecho del ratón sobre un espacio libre de la consola y seguimos los siguiente menús:

Editar el perfil actual → Aspecto → Editar…

Se nos mostrará un “deslizador” para seleccionar la cantidad de transparencia que deseamos en nuestro emulador de consola. También podemos seleccionar la opción de difuminar el fondo.

Personalmente un emulador de consola con el fondo transparente no lo veo nada útil y para mi gusto es una molestia, porque impide ver claramente la información que se muestra.

Pero algo que he descubierto hace poco es que podemos establecer una imagen de fondo propia para Konsole. Algo así como un fondo de escritorio propio para esta aplicación.

En el mismo menú que hemos abierto anteriormente. Seleccionamos la opción de imagen de fondo y se nos abrirá un menú para seleccionar la imagen que se muestre de fondo en Konsole.

Por mi parte, he seleccionado una con un color negro predominante y con pocas “florituras” o dibujos para que no me distraigan y así darle un toque menos uniforme al color liso de fondo del emulador de consola.

Quizás con este par de trucos extras le des un nuevo aspecto a tu Konsole y deslumbres cuando compartas una captura de tu escritorio. Si es así, me gustaría ver una muestra…

仮想環境プラットフォームとしてとても便利なProxmox VEですが、バージョン6.3が出ています。

変更点は https://pve.proxmox.com/wiki/Roadmap#Proxmox_VE_6.3 にありますが、順当に少しずつ機能が強化されてるという所でしょうか。あと今回は、Proxmox Backup Server との統合機能がメインかな。

地味にモダンなインタフェースになっているところもあります。例えば、今までプルダウンメニューで選択していたブート順の指定が、GUIのドラッグ&度ラップで出来るようになっていたりします。

日本語訳については最新版が反映されていないようです(画面ではテスト環境なので最新版になってますが、まだバグがありますね)。

そのほか、クラスタ回りとかストレージ回りで少しずつ改良がされているようです。ただ、openSUSE をゲストOSにしてテストするような場合にはあまり影響はないようです。