The openSUSE Project moved forward with a proposed governance structure following a virtual meeting yesterday that drew community members together for a discussion on advancing a leadership framework.

The session was productive with participants reviewing a draft proposal for governing bodies for the project; a Technical Steering Committee, a Community and Marketing Committee, representation of an Infrastructure Team and a Board.

The proposal is hosted on GitLab. It is designed as a living document that welcomes revision through community input.

The discussions during the meeting proposed that the Technical Steering Committee should begin with five members with a chair elected by the committee. The group would establish clear processes for reviewing and approving technical changes, drawing inspiration from Fedora’s FESCo model. Decisions for the TSC would use a voting system of +1 to approve, 0 for neutral, or -1 to block. A proposal passes without objection. A -1 vote would require a dedicated meeting, where a majority of attendees would decide the outcome. Objections must include a clear, documented rationale.

Discussions related to the Community and Marketing Committee would focus on outreach, advocacy, and community growth. It could also serve as an initial escalation point for disputes. If consensus cannot be reached at that level, matters would advance to the Board.

The Board’s role would center on representation, including coordination with SUSE, governance oversight, conflict mediation, and strategic guidance. Over time, its operational duties may narrow to function like a supervisory body, handling trademarks, budget approval, and final appeals when necessary.

Participants emphasized that cultivating a strong culture of maintainer responsibility remains essential and could be one of the more challenging aspects of bootstrapping a new structure.

Community members are encouraged to submit pull requests to refine the governance draft.

The document is available here. Organizers note that discussions should occur through proposed changes to the text.

No timeline for final adoption was announced. Project contributors will continue discussions through the GitLab repository and future community meetings.

There is a new toy in the house. It is a miniature workstation from HP, built around AMD’s Ryzen AI Max+ PRO 395 chip. If you are interested in the specifications and other details, check the HP product page at https://www.hp.com/us-en/workstations/z2-mini-a.html. In the long run, this box will serve many purposes:

• learning AI, but running as much as possible locally instead of utilizing cloud services
• learning Kubernetes by building everything from scratch on multiple virtual machines
• home server: running complex test environments on a single box (128 GB of RAM should be enough in most cases :-) )
• photo editing using Capture One Pro
• occasional gaming :-)

For now, I have finished unboxing and taken the first steps with Windows. It worked, though I made a mistake during setup and had to reinstall. I do not mind, since I do not like using pre-installed operating systems anyway. At least I know the machine works.

Right now I am hesitant to migrate any production applications or data to the new box. I have already clicked “use the whole disk” instead of creating a partition a few times, so I want to finalize the partitioning before using the box for anything beyond hardware testing. Better safe than sorry :-)

I plan to install a couple of Linux distributions. I mainly use openSUSE on the desktop, but I found instructions for Fedora to accelerate AI on this AMD chip. So, I’ll most likely install both. And, of course, I also plan to install FreeBSD 15 on the machine and see how it works both as a server and as a desktop.

I plan to post updates about my experiences in the coming weeks.

UDP log collection is a legacy feature that does not provide any security or reliability, but is still in wide use. You can improve its reliability using eBPF on Linux in recent syslog-ng versions. Support for eBPF was added to Debian packages while preparing for the 4.11.0 syslog-ng release.

You can learn more about eBPF support in syslog-ng from the documentation or reading my blog at https://www.syslog-ng.com/community/b/blog/posts/syslog-ng-4-2-extra-udp-performance

Right now, packaging changes only affect the syslog-ng nightly Debian / Ubuntu packages and the syslog-ng nightly container image. You can learn more about how to use them in the syslog-ng README on GitHub at https://github.com/syslog-ng/syslog-ng/ Once the syslog-ng 4.11.0 release is available, using the stable syslog-ng packages will include improved UDP support as well.

Are you interested in improving TCP performance for a single or few high traffic connections? You are looking for the parallelize() option: https://www.syslog-ng.com/community/b/blog/posts/accelerating-single-tcp-connections-in-syslog-ng-parallelize The good news is that the required changes are now available in ivykis upstream, so this feature is not limited to our builds anymore.

Originally published at https://www.syslog-ng.com/community/b/blog/posts/udp-reliability-improved-in-syslog-ng-debian-packaging

This is a rudimentary attempt (that surprisingly works) to export passwords from pass to Bitwarden csv format

As a requisite you need to have the private key that protects the passwords, exported as an ASCII armored key (Or whatever the nomenclature is), the important bit is that you export it:

gpg --export-secret-keys --armor $YOURFINGERPRINT > private-key.asc

To run simply run, you need to clone the sources from the git repo and inside the directory run:

go run . --private-key private-key.asc --identity alice@example.com

Alternatively you can build it and then run it (Sky is the limit)

You can check usage too by passing --help, It runs fairly fast, and in the end up with a pass_exported_passwords.csv (again see program help for defaults).

A feature that I’d like to add is a support for user plugins, to i.e check if an otp token is duplicated, or if a password is being reused, but that’s for the future

As usual PRs are welcome, specially for adding tests.

PS: “Maybe” I fix the program to be able to be installed via go install $foo (or somebody submits a PR :D)

https://github.com/foursixnine/pass-exporter

En ocasiones dos noticias deben ir unidas. Si esta mañana he hablado de la LliureJam 2026 de València ahora tocas hablar de su primer evento presencial con el Taller de Godot + Charla Licencias Libres organizadas por GNU/Linux València y Hackerspace VLC que se celebrará el sábado, 21 de febrero en los locales de éste último (Carrer Francisco Martínez, 19 Bajo, València 46020)

Taller de Godot + Charla Licencias Libres dentro de la LliureJam 2026 de València

Me complace presentaros un nuevo evento de la Asociación sin Ánimo de Lucro GNU/Linux València, esta vez con la cooperación de Hackerspace VLC, que siguen sus actividades este 2026 con un macro evento:

En palabras de los organizadores:

El sábado 21, nos podremos reunir toda la gente que quiera participar en la LliureJam (o simplemente que quiera aprender sobre Godot y licencias libres) en las maravillosas instalaciones de Hackerspace València.
Empezaremos con un almuerzo a las 10:00 en un bar cercano, para las personas que quieran venir a socializar y conocer a gente.
A las 11:00, haremos una presentación sobre licencias y recursos libres, donde explicaremos de forma muy sencilla lo que implican en garantizar la libertad del usuario. Veremos también dónde poder encontrar recursos para crear nuestro arte que nos garantizan la libertad de usarlos sin problemas, y en particular para la publicación de nuestro arte como contenido libre.
Finalmente, a las 11:30, dará arranque un taller de Godot, uno de los mejores motores de videojuegos que aprender hoy en día (¡y libre!) liderado por Guillem, el coordinador de LliureJam, ¡trata de instalar Godot en tu ordenador por adelantado! Así ganarás un poco de tiempo de aprendizaje.

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

¿Qué es LliureJam 2026?

LliureJam 2026 es una «game jam» (un concurso de desarrollo rápido de videojuegos) con un enfoque muy especial: el Software Libre.

Se celebra justamente entre el 20 febrero al 6 marzo de 2026, y a diferencia de otras jams convencionales, aquí no solo importa el juego final, sino también las herramientas que usas para crearlo y cómo lo compartes.

Aunque puedes participar de forma remota a través de su página en Itch.io, el evento tendrá mucha presencia física en Valencia. Por ejemplo, el 21 de febrero hay un Taller de Godot + Charla Licencias Libres en el Hackerspace de València. En breve más noticias.

Y ahora la parte más ética y técnica:

Más información: LliureJam

La entrada Taller de Godot + Charla Licencias Libres dentro de la LliureJam 2026 de València se publicó primero en KDE Blog.

Modern Linux systems are increasingly used to run autonomous, policy-driven services that operate continuously without user interaction. One example is a self-hosted trading agent running on openSUSE Tumbleweed, and can be run on other openSUSE flavors if desired.

There is no flashy interface, no proprietary cloud service, no opaque black box and no paid service that charges a monthly fee. Instead, the system runs reliably 24/7 continuously executing predefined policies in response to market signals.

The setup highlights the use of Linux distributions in the age of decentralized finance. Running autonomous and securely with minimal human intervention is a natural fit for Linux-based operating environments.

Unlike trading apps and services, this approach favors transparency. Configurations are easy. Logs are readable. Services are managed through systemd. When something goes wrong, administrators can inspect, roll back or fine-tune their system without surrendering control to closed platforms.

Open-source tooling allows users to deploy and audit their own automation logic without relying on proprietary platforms. A trading agent built on a development platform’s APIs allows anyone with a laptop or Raspberry Pi running openSUSE or other another Linux distribution to operate in 24-hour financial markets.

While this example focuses on trading logic, the architecture applies equally to other continuous workloads such as telemetry processing, monitoring systems, API polling services or data aggregation pipelines.

Trading logic implemented in these systems may adopt a conservative posture; however, this does not eliminate risk. Users reading this assume full responsibility for both market exposure and technical failure modes. This content does not constitute financial advice, but is only showing a use case for the technology available to Linux users.

The agent checks price data and calculates a desired indicator as well as other services. One indicator that can be used is the Relative Strength Index (RSI) of recent candles. When the RSI drops below a threshold, the agent considers buying a digital asset. When the RSI rises above an upper threshold, it considers selling that digital asset.

The example shown operates only in spot markets and avoids leverage.

The example given is not a high-frequency system. It is designed to run quietly, sometimes doing nothing at all.

Running the Agent on openSUSE

The trading agent runs as a standard Node.js service. On openSUSE, it is typically managed using a user-level systemd unit.

Starting the Agent manually:

sudo zypper in nodejs

node --max-old-space-size=8192 dist/bot.js

Running it as a background service:

systemctl --user enable --now jup-bot.service

Monitoring logs:

journalctl --user -u jup-bot.service -f

The approach works identical on Leap, Tumbleweed and MicroOS. MicroOS users can benefit from automatic rollback if a system update ever breaks the runtime.

One of the system’s defining characteristics is that all trading behavior is controlled through environment variables, not hard-coded values.

This makes experimentation safer and easier. Changes can be tested, reverted or tuned without recompiling the application.

Timing and Conditions

Defines how many candles are used for RSI calculation.

RSI_PERIOD=14

Fourteen is a common default for 15-minute charts and balances responsiveness with noise reduction. Shorter periods react faster but generate more signals, while longer periods smooth fluctuations and trade less frequently.

Buy and Sell

Define the thresholds that trigger trades.

RSI_BUY=30
RSI_SELL=70

Lowering the buy threshold makes buy signals more selective, reducing trade frequency. Raising the sell threshold delays exits, also reducing churn. Moving either threshold closer to the midpoint increases trading activity and sensitivity to price movement.

Fine-tuning on openSUSE

openSUSE users often fine-tune in stages rather than all at once.

A conservative configuration might look like:

TRADE_FRACTION=0.40
MIN_SOL_RESERVE=0.20
RSI_BUY=28
RSI_SELL=72
CHECK_INTERVAL_SECONDS=900
COOLDOWN_SECONDS=3600

A more aggressive configuration might look like:

TRADE_FRACTION=0.80
MIN_SOL_RESERVE=0.05
RSI_BUY=30
RSI_SELL=70
CHECK_INTERVAL_SECONDS=900
COOLDOWN_SECONDS=1800

Changes are applied simply by restarting the service.

This use case is not about digital assets or cryptocurrency; it is about demonstrating its use case in the space.

The distribution provides a foundation for autonomous, policy-driven systems that must run as programmed continuously, transparently and easily recover from failure. Whether the task is trading, data aggregation, monitoring or infrastructure automation, the same principles apply.

Running autonomous services on open systems reinforces transparency, recoverability and operational control. Whether the workload is trading, monitoring or automation, openSUSE provides the foundation.

Here are differentiators for each openSUSE flavor. Leap offers enterprise-grade stability for users who prefer slower change and long support cycles; plus there is the option to upgrade to SUSE Linux Enterprise Server for those who want it. Tumbleweed provides up-to-date kernels and libraries, ideal for developers working with fast-moving blockchain SDKs. MicroOS, with its transactional updates and immutable filesystem, is especially well-suited for unattended edge services where reliability and rollback matter more than manual tweaking.

The trading agent may be watching price charts, but the real story here is about control; who has it, how it is exercised, and whether users can see and understand the system they are using. On openSUSE, they can.

Have alot of fun!

Vuelvo de nuevo justo a esta noticia, y es que últimamente hay muchas actualidad en el mundo libre. Llega la LliureJam 2026 a València de la mano de GNU/Linux València y Hackerspace VLC. ¿No sabes lo que es? No pasa nada, yo te lo explico y de paso me entero yo mismo.

Llega la LliureJam 2026 a València de la mano de GNU/Linux València y Hackerspace VLC

Me complace presentaros un nuevo evento de la Asociación sin Ánimo de Lucro GNU/Linux València, esta vez con la cooperación de Hackerspace VLC, que siguen sus actividades este 2026 con un macro evento:

En palabras de los organizadores:

El día 20 dará comienzo LliureJam, una «gamejam», que viene a ser una especie de concurso de desarrollo de videojuegos, que incluye también a diseñadores, artistas, músicos, guionistas… ¡haz amistades y crea videojuegos libres en común!

Siendo más precisos, para los que van tan perdidos como yo, la LliureJam 2026 es una «game jam» (un concurso de desarrollo rápido de videojuegos) con un enfoque muy especial: el Software Libre.

Se celebra justamente entre el 20 febrero al 6 marzo de 2026, y a diferencia de otras jams convencionales, aquí no solo importa el juego final, sino también las herramientas que usas para crearlo y cómo lo compartes.

Aunque puedes participar de forma remota a través de su página en Itch.io, el evento tiene mucha presencia física en Valencia. Por ejemplo, el 21 de febrero hay talleres de Godot y charlas sobre licencias en el Hackerspace de València. En breve más noticias.

Y ahora la parte más ética y técnica:

Más información: LliureJam

La entrada Llega la LliureJam 2026 a València de la mano de GNU/Linux València y Hackerspace VLC se publicó primero en KDE Blog.

openSUSE Leap 16.0 is now available as a public image on Google Cloud Platform. Both x86_64 and Arm64 images were built on 16 February 2026 and are ready for use with Compute Engine instances.

Launching an instance with openSUSE Leap 16.0

Getting started with Leap 16.0 on GCP is straightforward. From the Google Cloud Console, navigate to Compute Engine > VM instances and click Create Instance.

In the instance configuration page, scroll down to the OS and storage section and click Change to open the boot disk configuration panel.

Under the Public images tab, select openSUSE from the Operating system dropdown. You will then see openSUSE Leap listed under the Version dropdown — select the openSUSE Leap 16.0 entry. Choose your preferred boot disk type and size, then click Select to confirm.

From there, configure the rest of your instance settings — machine type, networking, firewall rules — as you normally would, and click Create to launch your new Leap 16.0 VM.

A note on Google Cloud Observability

During instance creation, you will notice the Observability - Ops Agent section near the bottom of the configuration page. For supported operating systems, this provides a convenient Install Ops Agent for Monitoring and Logging checkbox that automatically installs the agent when the VM boots. However, with openSUSE Leap 16.0 selected as the boot disk image, this checkbox is greyed out and displays the message: "Not available for the selected image." This is because the automated installation method does not yet support Leap 16.0.

You might think the next step would be to install the Ops Agent manually via the command line. Google's installation documentation provides a script for exactly this:

curl -sSO https://dl.google.com/cloudagents/add-google-cloud-ops-agent-repo.sh
sudo bash add-google-cloud-ops-agent-repo.sh --also-install

Unfortunately, this does not work on Leap 16.0 either — and the reason is buried in how the script identifies your operating system.

Why does the script fail?

The script reads /etc/os-release to determine the OS family and version. For any SUSE-based distribution, including openSUSE Leap, it routes to a handle_suse function via a case statement in main():

sles|opensuse-leap) handle_suse ;;

Inside handle_suse, the add_repo() function extracts the major version number and constructs a SLES-based repository codename:

local SUSE_VERSION=${VERSION_ID%%.*}
local CODENAME="${REPO_CODENAME:-"sles${SUSE_VERSION}"}"

On openSUSE Leap 16.0, VERSION_ID is 16.0, so SUSE_VERSION resolves to 16 and the codename becomes sles16. The script then attempts to add a repository at:

https://packages.cloud.google.com/yum/repos/google-cloud-ops-agent-sles16-$basearch-all

The problem is that this repository simply does not exist. Google currently publishes Ops Agent packages for sles12 and sles15, but there is no sles16 repository — SLES 16 itself has not been released yet. The script makes no distinction between SLES and openSUSE Leap; it treats both as the same platform and derives the repo path purely from the major version number. The result is a refresh_failed error telling you to check your network connectivity and verify that you are running a supported distribution.

This leaves openSUSE Leap users on GCP in a bit of a gap. While the Ops Agent officially supports Leap 15.6, that image is no longer available on GCP — only Leap 16.0 is offered as a public image. So the supported version cannot be deployed, and the deployable version is not supported. Until Google publishes a compatible repository for Leap 16.0, there is no straightforward path to running the Ops Agent on an openSUSE instance on GCP. Keep an eye on the Ops Agent supported platforms list for updates.

Installing the Leap 15.6 version of the agent isn't a viable workaround due to missing libraries.

Problem: 1: nothing provides 'libcrypto.so.1.1()(64bit)' needed by the to be installed google-cloud-ops-agent-2.63.0-1.sles15.x86_64

As always, the openSUSE community welcomes feedback and bug reports — if you run into issues with the GCP images that are specific to the openSUSE project, report them through the openSUSE Bugzilla.