Empezamos las semana compartiendo una nueva quedada de algunos de las primeras espadas de la comunicación gnu/linuxera. Y es que con el tema de «El futuro de GNU/Linux» se emitió y grabó el segundo evento de la nueva serie de «Charlas de 24H24L» que pretende seguir acercando a cualquiera que tenga interés por el mundo del Software Libre. No te la pierdas.

El futuro de GNU/Linux – Charlas 24H24L

El pasado 2020 finalizó con un macroevento podcastero llamado 2424L, el cual tenía como objetivo seguir difundiendo las bondades de los sistemas libre GNU/Linux.

Al parecer a su organizador, José Jiménez, le quedaron más ganas de hacer cosas y se propuso realizar las «Charlas de 24H24L» que consisten en una serie de encuentros informales sobre la Comunidad linuxera y que empezó con la dedicada a mi «oficio» y que llevaba por título «Blogs de GNU/Linux».

En otras palabras y para ser concreto, el pasado sábado 5 de Marzo a las 22:00 se emitió y grabó la segunda de «Las Charlas de 24H24L» donde se hablará del Futuro de GNU/Linux.

Los participantes fueron:

• Juan Febles, creador de Podcast Linux.
• Paco Estrada, creador de Compilando Podcast.
• David Marzal, podcaster de GNU/Linux Valencia y nuevo socio de KDE España.
• Alejandro Lopez, CEO de Slimbook.

La charla fue grabada con OBS Studio, utilizando Jitsi como servidor de comunicación y emitida en directo por Youtube con los comentarios activos para los oyentes para que todo el mundo pueda participar.

1ª Edición de la Cumbre Software Libre y Educación

Aprovecho para recordaros que los eventos linuxeros no paran y que este viernes empieza la 1ª Edición de la Cumbre Software Libre y Educación organizando la Asociación de Software Libre GNU/Linux València y Las Naves es altamente recomendable para todos y todas ya que contará con

Además, cuenta con un invitado de máximo nivel: Richard M. Stallman, fundador del movimiento del software libre, del sistema operativo GNU, de la Free Software Foundation (Fundación para el Software Libre) y defensor acérrimo de la Cultura Libre.

“We got lucky”—it’s one of those phrases I listen out for during post incident or near-miss reviews. It’s an invitation to dig deeper; to understand what led to our luck. Was it pure happenstance? …or have we been doing things that increased or decreased our luck?   

There’s a saying of apparently disputed origin: “Luck is when preparation meets opportunity”. There will always be opportunity for things to go wrong in production. What does the observation “we got lucky” tell us about our preparation? 

How have we been decreasing our luck?

What unsafe behaviour have we been normalising? It can be the absence of things that increase safety. What could we start doing to increase our chances of repeating our luck in a similar incident? What will we make time for? 

“We were lucky that Amanda was online, she’s the only person who knows this system. It would have taken hours to diagnose without her” 

How can we improve collective understanding and ownership? 

Post incident reviews are a good opportunity for more of the team to understand, but we don’t need to wait for something to go wrong. Maybe we should dedicate a few hours a week to understanding one of our systems together? What about trying pair programming? Chaos engineering?

How can we make our systems easier to diagnose without relying on those who already have a good mental model of how they work? Without even relying on collaboration? How will we make time to make our systems observable? What would be the cost of “bad luck” here? maybe we should invest some of it in tooling? 

If “we got lucky” implies that we’d be unhappy with the unlucky outcome, then what do we need to stop doing to make more time for things that can improve safety? 

How have we been increasing our luck? 

I love the extreme programming idea of looking for what’s working, and then turning up the dials. 

Let’s seek to understand what preparation led to the lucky escape, and think how we can turn up the dials.

“Sam spotted the problem on our SLIs dashboard”

Are we measuring what matters on all of our services? Or was part of “we got lucky” that it happened to be one of the few services where we happen to be measuring the things that matter to our users? 

“Liz did a developer exchange with the SRE team last month and learned how this worked”

Should we make more time for such exchanges or and personal learning opportunities? 

“Emily remembered she was pairing with David last week and made a change in this area”

Do we often pair? What if we did more of it?

How frequently do we try our luck?

If you’re having enough production incidents to be able to evaluate your preparation, you’re probably either unlucky or unprepared ;)

If you have infrequent incidents you may be well prepared but it’s hard to tell. Chaos engineering experiments are a great way to test your preparation, and practice incident response in a less stressful context. It may seem like a huge leap from your current level of preparation to running automated chaos monkeys in production, but you don’t need to go straight there. 

Why not start with practice drills? You could have a game host who comes up with a failure scenario. You can work up to chaos in production. 

Dig deeper: what are the incentives behind your luck?

Is learning incentivised in your team, or is there pressure to get stuff shipped? 

What gets celebrated in your team? Shipping things? Heroics when production falls over? Or time spent thinking, learning, working together?

Service Level Objectives (SLOs) are often used to incentivise (enough) reliability work vs feature work…if the SLO is at threat we need to prioritise reliability. 

I like SLOs, but by the time the SLO is at risk it’s rather late. Adding incentives to counter incentives risks escalation and stress. 

What if instead we removed (or reduced) the existing incentives to rush & sacrifice safety. Remove rather than try to counter them with extra incentives for safety?

The post We got lucky appeared first on Benji's Blog.

Parece que la crisis del COVID-19 ha generado, tras el impacto inicial, un auge de eventos Comunitarios relacionados con el Software Libre. No hay más que ver el número y la calidad de ellos que aparecen en el blog, que solo recoge los que me da tiempo a conocer a fondo. No obstante el de hoy se podría poner en el top 5 de los mismos ya que se trata de la 1ª Edición de la Cumbre Software Libre y Educación, que está organizando la Asociación de Software Libre GNU/Linux València con la colaboración de Las Naves y que contará con la presencia de RIchard Stallman. Interesante, ¿no?

Cumbre Software Libre y Educación, 1ª Edición

Es un tema recurrente en el blog y clave si queremos que la filosofía del Software Libre impregne nuestra sociedad: el alumnado debe conocer las alternativas libres al Software que le rodea, así como las razones humanitarias que lo sustentan.

Es por ello que es importante que los docentes seamos los promotores de uso entre el alumnado y de su difusión entre el gran número de compañeras y compañeros que no lo conocen.

Además, debemos ser defensores a ultranza de la privacidad y libertad de nuestro alumnado ya que la empresas tecnológicas no lo van a hacer.

Justo por todo esto la 1ª Edición de la Cumbre Software Libre y Educación organizando la Asociación de Software Libre GNU/Linux València y las Naves es altamente recomendable para todos y todas y, en mi opinión, merece la máxima difusión.

Además, cuenta con un invitado de máximo nivel: Richard M. Stallman, fundador del movimiento del software libre, del sistema operativo GNU, de la Free Software Foundation (Fundación para el Software Libre) y defensor acérrimo de la Cultura Libre.

La 1ª Edición de la Cumbre Software Libre y Educación se celebrará a lo largo de 3 días de ponencias en línea que se inicia el próximo 12 de marzo en línea, pronto pondré los enlaces correspondientes, que tiene el siguiente y jugoso programa:

12 de marzo, 17 horas CET

Conferencia

«La era de la digitalización en las aulas»

por Javier Sepúlveda (miembro de GNU Education y de GNU/Linux València)

13 de marzo, 17 horas CET

Mesa redonda

«Software Libre y Educación en la Comunida Valenciana»

Richard M. Stallman y varios especialistas por confirmar

Presentación de la reedicición en español del libro

«Software para una Sociedad Libre» de Richard. S. Stallman

Domingo 14, 17 horas CET

Conferencia

Software para una Sociedad Libre» por Richard. S. Stallman

Evidentemente será grabado y posteriormente podrá ser disfrutado en diferido. Así que ya sabéis: apuntad en la agenda las fechas y difundid en vuestro entorno. La sociedad os lo agradecerá.

Más información: GNU/Linux València

Meu primeiro trabalho como desenvolvedor utilizando a tecnologia Monero foi em 2018, para tentar combater a fome no mundo. Embora fracassei, vejo a moeda avançando em uma nova era de criptomoedas.

A comunidade da criptomoeda Monero comemora o sucesso da primeira demonstração pública de atomic swaps entre Bitcoin e Monero. Pesquisadores encontrou um método criptográfico distinto para efetuar atomics swaps. O trabalho de pesquisa durou em torno de 4 anos e a primeira demonstração pública ocorreu ONTEM (sexta-feira 05/03)!

Atomic Swaps é sensacional, pois são contratos inteligentes que proporciona troca entre criptomoedas diferentes SEM UM INTERMEDIÁRIO com exchange ou banco. A primeira Atomic Swap aconteceu com Litecoin e Decred em aproximadamente em 2017, eu particularmente nesta época achava impossível isto ocorrer entre Monero e Bitcoin. Devido a robustez e privacidade da XMR (Monero) e a falta de recurso referente a contratos inteligentes nesta criptomoeda.

Qual o motivo da importância? Ao contrário de muitas criptomoedas, todas transações Monero são extremamente privada e anônima. Ótimos para o usuário, mas tenebroso para que DESEJAVA COBRAR IMPOSTOS. Algumas regiões no mundo estão tomando medida para banir o Monero. Em breve tutorial no Viva O Linux (CLARO!) de como efetuar os testes.

Meu primeiro desenvolvimento com a tecnologia Monero, foi em 2018. Onde desenvolvi o projeto OSMINER (OpenSUSE Miner) é uma imagem linux baseado no openSUSE criada inicialmente para ajudar combater a fome no Hait utilizando a tecnologia Blockchain com a cripto moeda Monero. Para você ajudar, basta doar algumas horas de computação do seu equipamento com o sistema OSMINER, a inspiração do projeto foi baseado no vídeo e/ou projeto liderada pelo WESLEY ROS no HAITI. O vídeo no qual assisti, me deparei com a triste realidade onde crianças aparecem no video se alimentando com BOLINHO DE BARRO COM SAL! Maiores informações sobre a origem do vídeo, esta disponível neste link do YouTube. Não sei a aceitação, e o resultado na íntegra do projeto no contexto de resolução do problema, mas pelo menos não fiquei inerte a situação tão impactante negativamente e sofrível ao próximo. Mais informações sobre o projeto OSMINER AQUI!

Ya hablé hace unos días del Día de los datos abiertos 2021 que se celebrará en línea el próximo sábado 6 de marzo y también del evento de A Coruña en particular. Ahora, esta mañana de domingo os invito en tiempo real a seguir en directo el evento.

Día de los Datos Abiertos 2021

Para los que no lo sepan, entre los que me incluía yo en el 2020, el «Día de los Datos Abiertos» es una celebración anual de los datos abiertos alrededor del mundo.

Y es que los datos abiertos son mucho más importantes de lo que nos pueda parecer, según la Wikipedia, uno de lo estandartes de esta una filosofía y práctica que persigue que determinados tipos de datos estén disponibles de forma libre para todo el mundo, sin restricciones de derechos de autor, de patentes o de otros mecanismos de control.

Con esta se llega a la décima edición del evento, en la que grupos de todo el mundo crearán eventos locales que utilizarán datos abiertos en sus comunidades para crear aplicaciones, visualizaciones, liberar datos o publicar análisis.

En directo – Día de los Datos Abiertos de A Coruña

Uno de lo eventos locales que se han organizado en España tiene su sede en A Coruña, que de la mano de Jorge Lama y Asociación Melisa han preparado una interesante jornada que con las siguientes charlas:

• Datos abiertos, SL y medio ambiente por David Marzal y Voro MV
• Datos abiertos y otros dramas legislativos por Bárbara Román
• GeoAprendizaje Libre por Baltasar Ortega (un servidor)
• Archive.org: Tu repositorio multimedia Creative Commons por Juan Febles
• Tráfico y calidad de aire en Santiago de Compostela por Rafael R. Gaioso
• Análisis de datos abiertos con Radiant por Miguel Muíños
• Exportando datos de OSM con overpass-turbo para la creación de un mapa en umap por Jorge Lama
• Tus libros ya no son tuyos por Javier Teruelo
• Los datos abiertos en la lucha contra incendios por Marta Rodríguez Barreiro (ITMATI) y Mª José Ginzo Villamayor (USC)

Ahora tenéis la oportunidad de seguirlo en directo este sábado 6 de marzo simplemente debes pinchar en el siguiente imagen a partir de las 10:00 horas peninsular para la jornada matinal y de las 15:30 horas jornada vespertina.

Y, además, os invito a asistir al chat en directo con los ponentes en la siguiente sala: https://chat.comacero.com/channel/general

Más información: Día de los Datos Abiertos A Coruña 2021

Ich nutzte schon seit 2011 einen USB-Stick um bei meinem mit openSUSE laufenden Heimserver beim Start das Passwort für die Festplattenverschlüsselung „eingeben“ zu können ohne eine Tastatur oder einen Monitor am System angeschlossen zu haben. Den dafür genutzten Mechanismus habe ich auch schon damals hier im Blog dokumentiert. Leider funktionierte der dort beschriebene Mechanismus aber seit openSUSE Leap 42.2 nicht mehr. Auf den nachfolgenden Versionen gibt es aber einen neuen Mechanismus, der sogar noch besser funktioniert. Dieser wird hier beschreiben und wurd auf allen Versionen von openSUSE Leap 42.2 bis 15.5 erfolgreich getestet.

Festplattenverschlüsselung

Für die Festplattenverschlüsselung wird ganz klassisch LUKS genutzt, so wie auch openSUSE ein System mit Festplattenverschlüsselung aufsetzen würde. Da der Schlüssel vom USB-Stick während des initialen Boots aus der Initrd gelesen wird muss /boot allerdings unverschlüsselt sein. Moderne Versionen von openSUSE erlauben auch einen Boot mit verschlüsselter Boot-Partition. In diesem Fall wird der Schlüssel aber bereits von Grub abgefragt. Diese Variante wird vom hier beschriebenen Mechanismus nicht unterstützt.

Da LUKS die Nutzung mehrerer alternativer Schüssel unterstützt empfiehlt es sich das System zunächst mit einer klassischen Passphrase einzurichten. Dies erleichtert Offline-Upgrades des Systems und das Einbinden der Festplatten zu Wiederherstellungs- und Wartungszwecken.

USB-Stick als Schlüssel

Da der USB-Stick später aus der Initramfs gelesen werden soll, empfiehlt es sich ein dort sowieso eingebundenes Dateisystem zu nutzen. Ich nutze hierfür immer noch Ext2. Ist der Stick als /dev/sdb im System zu sehen, kann er wie folgt passend formatiert werden.

mkfs.ext2 -L keystick /dev/sdb

Das Label keystick ist wichtig um den Schüssel später leicht referenzieren zu können. Außerdem ist es beim Mount mit Label möglich eine zweite Kopie des Sticks zu erstellen falls das Original mal zerstört wird.

Anschließend sollte ein Schlüssel generiert und auf dem USB-Stick hinterlegen werden. Dies kann mit pwgen gemacht werden:

pwgen -s 1024 1 > /media/keystick/keyfile

Und schließlich muss der Schlüssel der verschlüsselten Partition hinzugefügt werden.

cryptsetup luksAddKey /dev/sda2 /media/keystick/keyfile

In diesem Beispiel befindet sich die verschlüsselte Partition auf /dev/sda2.

USB-Stick beim Booten nutzen

Um den Schlüssel beim Booten vom USB-Stick zu lesen muss der Kernelparameter rd.luks.key auf die Schlüsseldatei zeigen.

rd.luks.key=/keyfile:LABEL=keystick

Hier wird wieder das, bei der Formatierung des Sticks vergebene, Label für das Dateisystem genutzt. Der Pfad ist relativ zum per Label referenzierten Dateisystem. Konfigurieren lässt sich der Kernelparameter am einfachsten über die Bootloaderkonfiguration in Yast.

Damit der Parameter rd.luks.key funktioniert benötigt es allerdings noch eine Änderung. In der Standardkonfiguration nutzt die Initrd bei openSUSE Systemd. Dann hat der Parameter allerdings keinen Effekt. Deshalb muss Dracut, welches in openSUSE die Initrd baut, so konfiguriert werden, dass es eine Initrd ohne Systemd baut. Dazu ist eine neue Datei /etc/dracut.conf.d/50-keystick.conf mit folgendem Inhalt anzulegen:

omit_dracutmodules+=" systemd "

Die Leerzeichen im Wert sind hier Absicht. Ohne diese wirft Dracut eine Warnung:

dracut: WARNING: <key>+=" <values> ": <values> should have surrounding white spaces!
dracut: WARNING: This will lead to unwanted side effects! Please fix the configuration file.

Ein anschließendes mkinitrd erzeugt eine Initrd ohne Systemd und das System kann zukünftig bei eingestecktem USB-Stick ohne Passworteingabe gestartet werden.

Vorteile gegenüber der alten Methode

Bei der alten Methode blieb das System in einer Schleife hängen wenn der USB-Stick beim Boot nicht gesteckt war. Ohne Stick konnte das System gar nicht mehr gebootet werden. Bei der hier beschriebenen Methode versucht das System zunächst die Schüsseldatei vom USB-Stick zu lesen. Kann es diese aber nicht finden, so fällt es auf die klassische Passworteingabe zurück. Wurde der USB-Stick also nicht als einziges Passwort eingerichtet lässt sich das System im Notfall auch noch so starten.

Diese Woche erschien die Beta von openSUSE Leap 15.3, der nächsten Version von openSUSE Leap. Ich habe meinen primären privaten Rechner bereits darauf aktualisiert und es war völlig unspektakulär. Was auf den ersten Blick enttäuschend klingt ist aber etwas wirklich gutes, denn es heißt, dass ich keinerlei Probleme hatte und weiterhin alles funktioniert.

Das die Aktualisierung auf die nächste Version so unspektakulär ist war gar nicht so selbstverständlich, denn technisch gab es unter der Haube größere Umwälzungen. OpenSUSE verwendet für alles, dass es auch in SUSE Linux Enterprise gibt, direkt das Paket von dort. Eine gute Nachricht, für alle, die auf ein grundsolides System bauen wollen. Durch die direkte Nutzung der Pakete von SLE gibt es auch nicht nur maximale Kompatibilität, sondern Patches werden auch direkt verfügbar sein, ohne die Zeitverzögerung durch die Portierung von SLE auf openSUSE.

Auch meine Methode zum Booten mit Keystick funktioniert mit der Beta von Leap 15.3 wunderbar.

Einen kleinen Stolperer gibt es momentan noch beim Onlineupgrade auf die Beta, zumindest wenn man bereits den Weg mit der Variablen releasever in den Quellen für die Paketpfade nimmt. Nach dem Update zeigt /etc/products.d/baseproduct ins Leere. Das hat zur Folge, dass Zypper die Paketquellen nicht mehr findet:

Warnung: Der Symlink /etc/products.d/baseproduct ist defekt oder fehlt!
Der Link muss auf die .prod-Datei Ihrer Kernprodukte in /etc/products.d verweisen.

Zum Glück lässt sich dies sehr leicht reparieren und bis zum finalen Release von 15.3 wird diese Problem auch gelöst sein.

sudo rm /etc/products.d/baseproduct && sudo ln /etc/products.d/Leap.prod /etc/products.d/baseproduct

Auch wenn es momentan in 15.3 aus Nutzersicht keine Features gibt für die es dringend ein Update bräuchte, sollte, wer ein in irgendeiner Form ein ungewöhnliches Set-Up hat, der Beta also auf jeden Mal einen Versuch gönnen. Denn so können Probleme idealerweise noch vor dem Release gefunden und behoben werden. Dazu bietet sich natürlich eine Zweitinstallation an, auch wenn die Beta sogar schon stabil genug für die tägliche Nutzung erscheint.

Tumbleweed es una distribución “Rolling Release” de actualización contínua. Aquí puedes estar al tanto de las últimas novedades.

openSUSE Tumbleweed es la versión “rolling release” o de actualización continua de la distribución de GNU/Linux openSUSE.

Hagamos un repaso a las novedades que han llegado hasta los repositorios estas semanas.

El anuncio original lo puedes leer en el blog de Dominique Leuenberger, publicado bajo licencia CC-by-sa, en este enlace:

• • http://dominique.leuenberger.net/blog/2021/03/opensuse-tumbleweed-review-of-the-weeks-2021-09/

Esta semana ha sido todo un reto para Tumbleweed. Se han compilado 6 nuevas snapshots y solo dos de ellas pasaron los test y tenían la suficiente calidad como para publicarse y llegar a todos los usuarios y usuarias.

Esto no hace si no probar que los test automáticos de openQA hacen que Tumbleweed llegue con la calidad y seguridad que requieren los usuarios y usuarias de openSUSE. Así disfrutamos de una distribución de GNU/Linux a la última sin tener quebraderos de cabeza.

Solo dos snapshots 0227 y 0302, pero con interesantes cambios, por ejemplo:

• NetworkManager 1.30 – con soporte para WPA3
• Más cambios y mejoras en YaST por parte del equipo de desarrolladores.
• Mozilla Firefox 86.0
• Mozilla Thunderbird 78.8.0
• KDE Plasma 5.21.1
• Dracut 053
• krb5 1.19.1
• pipewire 0.3.22: pipewire-pulseaudio debería ser capaz de reemplazar PulseAudio
• podman 3.0.1

Y más cosas que llegarán en próximas actualizaciones:

• Linux kernel 5.11.2
• openssl 1.1.1i
• KDE Plasma 5.21.2
• glibc: una solución para quienes usas arquitecturas i586
• GCC 11 como compilador predeterminado

Si quieres estar a la última con software actualizado y probado utiliza openSUSE Tumbleweed la opción rolling release de la distribución de GNU/Linux openSUSE.

Mantente actualizado y ya sabes: Have a lot of fun!!

Enlaces de interés

• • • ¿Por qué deberías utilizar openSUSE Tumbleweed?
    • zypper dup en Tumbleweed hace todo el trabajo al actualizar
    • ¿Cual es el mejor comando para actualizar Tumbleweed?
    • Comprueba la valoración de las “snapshots” de Tumbleweed
    • ¿Qué es el test openQA?
    • http://download.opensuse.org/tumbleweed/iso/
    • https://es.opensuse.org/Portal:Tumbleweed

——————————–

I have received quite the number of comments about emulating the Game Boy on modern hardware and all the work that is going into it. I learned so much about the extensive community around emulating Game Boy games and the technology, research and absolute passion that goes into it. Though I was given many suggestions, … Continue reading mGBA | Game Boy Emulation on Linux →

Creo que ya tengo implenatado el gusto de compartir mi pantalla siguiendo la iniciativa #viernesdeescritorio y gracias a la energía de Lina Castro (@lirrums) a la que ya le he dedicado una entrada a su podcast . Así que, de forma cada vez más habitual, añado por quinto mes consecutivo una entrada a la serie «Mi escritorio», en la que comparto en el blog el aspecto de mi ordenador. Espero que mi escritorio Plasma de marzo 2021 os guste tanto como a mi y que os de ideas para mejorar el vuestro.

Mi escritorio Plasma de febrero 2021 #viernesdeescritorio

Esta va a ser la novena vez que muestro mi escritorio Plasma 5 en público. Respecto al mes pasado quiero comentar que sigo utilizando Latte Dock, que a petición de un lector he estado buscando un entorno claro para mi escritorio y que he realizado la captura de las características de mi equipo con neofetch.
Como es habitual, la captura está realizada sobre mi portátil Slimbook Pro de 13 pulgadas, el cual tiene instalado un KDE Neon con Plasma 5.21.

He vuelto al motor de ventana Brisa, ya que el motor Kvantum no lo he conseguido poner en un modo claro.

El resultado de mi escritorio de marzo de 2021 es un escritorio más clásico y colorido. y cuyo resultado lo podéis ver en la imagen inferior. Puedes pinchar sobre ella para verlo un poco más grande.

OS: KDE neon User Edition 5.21 x86_64  
Kernel: 5.4.0-65-generic  
Resolution: 1920×1080  
DE: Plasma  
WM: KWin  
WM Theme: Keepin
Theme:Keepin [Plasma], Breeze [GTK2/3]  
Icons: Keepin [Plasma], Lyra [GTK2/3]  
Terminal: konsole  
CPU: Intel i5-7200U (4) @ 3.100GHz  
GPU: Intel HD Graphics 620  

Plasmoides:

• Barra de tareas: Latte dock centrada y que se ocultamiento automático y que contiene, de izquierda a derecha, lanzador de aplicaciones Kickoff, gestor de tareas solo iconos (que ahora es el por defecto en Plasma) y bandeja de sistema.
• Reloj digital: Digital Clock BeClock Style