We have a couple of news to share with you on the package version tracking feature in OBS. We extended the feature in the API space, allow to skip version tracking for individual packages and display the version info in a couple more places. These updates are part of the Foster Collaboration beta program. You can find more information about the beta program here. Our efforts to foster collaboration started in August 2024, when we...

The series for openSUSE Leap 15 is coming to an end after nearly eight years of providing a consistent community distribution that’s upgradable to SUSE’s enterprise product. Leap 15.6 will reach End of Life (EOL) at the close of this month closing out an end of an era as it will no longer receive maintenance or security updates going forward.

The Leap 15 journey began it journey on May 25, 2018, when 15.0 was released as a fresh community build on top of SUSE Linux Enterprise 15. It brought a huge variety of new software along with a easy migration to SLE, transactional updates, server roles, scalable cloud images, and more.

What followed was an impressively long run of incremental releases from Leap 15.1 to 15.6 as each stable release aligned with its twin, which is source and binary compatible, and delivered maintenance and security updates to users over several years.

The series far exceeded promises and ultimately spanned nearly eight years of active support. With Leap 15.6 going EOL, users who wish to continue receiving maintenance and security updates should upgrade to Leap 16. Leap 16 is expected to go to 16.6 in Fall 2031 and will have 24 months of support for a point release.

Running an unsupported release means your system will no longer receive patches for vulnerabilities, which poses a real security risk over time. The upgrade path to Leap 16 is the recommended way to stay protected and supported.

You can download openSUSE Leap 16 and use the migration tool to upgrade.

Leap 15.6 itself received nearly 24 months of support, which extended the traditional support period of 18 months by about six months. With Leap 16, users can expect a full 24 months of community support per point release, which is a commitment that reflects the significant effort from maintainers to keep users protected.

Thank you to all the contributors, packagers, and users who made the Leap 15 series such a long-lasting and reliable platform. Here’s to the next chapter with Leap 16!

Almost 15 years ago, Balabit had a campaign, stating that syslog-ng could process 650k messages a second. Now I am happy to present 7 million EPS (events per second). Timing the announcement to April 1 is not a coincidence :-)

While the 650k EPS measurement was true, it was misleading. This value was measured right after syslog-ng 3.2 introduced multi-threading, in lab environment, under optimal circumstances, using synthetic log messages. However, there was no fine print explaining this, just the statement that syslog-ng could process 650k EPS. It was fixed after a while, but it took years to recover from the effects of this marketing campaign, and engineers ten years later still had a nervous breakdown when someone mentioned “650k”. Why? Because from that moment, everyone expected syslog-ng to collect logs at that message rate in a production environment with complex configurations. Which was of course not the case.

Fast-forward to today, I’m happy to share that:

syslog-ng can collect logs at 7 million EPS

• Is this measurement value valid? Yes.

• Does it apply to real world? No.

• Does it sound good? Definitely :-)

The tool: sngbench

I love playing with various non-x86 systems. I have various ARM, POWER, MIPS systems at home, and sometimes I access other architectures, like RISC-V remotely. And, of course, not just different architectures, but different operating systems: various Linux distributions, MacOS, FreeBSD, sometimes also other BSD variants. I’m a server guy, and for the past 15+ years: a syslog-ng guy. Sometimes I had access to an exotic system on the other side of the world only for less than an hour, but I almost always tested syslog-ng.

For many years I had a bunch of shell scripts and configs to benchmark syslog-ng performance. Not for real world production loads, but rather for comparing architectures and operating systems. I needed a script which could do measurements with minimal dependencies and do it quickly, in one go. This is how sngbench was born, based on my previous ugly scripts. It has quite a few advantages and shortcomings:

• Minimal dependencies: bash and syslog-ng

• No complex setup: everything runs on the same host

• network bandwidth is not a limiting factor

• loggen and syslog-ng processes are competing for resources

• Two bundled configurations: a performance tuned and the default syslog-ng.conf from openSUSE with minimal modifications to add a TCP source

• By default, very short (20 seconds) measurements, so disk I/O is not a limiting factor

• Many different test scenarios: from a single TCP connection to 4 * 128

Of course this describes just the “factory defaults”. You can easily change the test scenarios and configurations too.

How I reached 7 million EPS, and why it is not relevant

I was testing syslog-ng code which was not yet even merged to the development branch. First, I tested these patches with various settings. Along the way I remembered that Splunk guidelines mention so-rcvbuf tuning also for TCP connections. Previously I only used that for optimizing UDP performance. Now I have done it for TCP. Wonders happened :-)

But, of course, the main question is: can you achieve this performance in production? TL;DR: No.

My tests are run from localhost. Network bandwidth is not an issue. Tests are run in short bursts. This is peak performance; when it comes to writing logs to files or forwarding to a cluster of Splunk or Elasticsearch endpoints around the clock, that would be slower. Also, in my fastest test case, logs came from four different loggen instances, over 32 TCP connections each, at a constant rate. In the real world, logs come in bursts and connections are opened and closed regularly.

Test environment and tests

I used my AI mini workstation with Fedora Linux 44 Beta. First, I took a base line with stock syslog-ng 4.11.0 included in the distribution. Then I used my syslog-ng git snapshot packages for Fedora from https://copr.fedorainfracloud.org/coprs/czanik/syslog-ng-githead/. Initially it also had jemalloc support compiled in. Later I disabled it and purely focused on the yet to be merged parallelize() optimizations from GitHub. I experimented with enabling and disabling parallelize(), adding various batch_size() values, and finally also so-recbuf().

This blog is part of a longer series about my adventures with my new machine and AI. You can reach me to discuss this blog on one of the contacts listed in the upper right corner. You can read the rest of the blogs under the toy tag.

Hoy os traigo el otro resumen del progreso en KDE Linux, un informe detallado de la última entrada de Nate Graham en su blog «Adventures in Linux and KDE», donde nos pone al día sobre los avances de KDE Linux, el sistema operativo «del futuro» de la comunidad KDE. Es decir, que bienvenidos a el progreso de este mes de marzo en KDE Linux, otro gigantesco paso que nos acerca a un sueño para los simpatizantes de este entorno de trabajo.

Este mes de marzo en KDE Linux

El bueno de Nate no solo se encarga de informarnos del progreso de Plasma en sus artículos de «This week in Plasma, sino que en ocasiones nos obsequia con una mirada a otros proyectos de la Comunidad.

Si hace un par de meses se publicó el artículo «Busy months in KDE Linux» y hace un mes otro llamado «This month in KDE Linux» en los que Nate nos muestra que el proyecto está vivo y que si no pasa nada en unos meses tendremos entre nosortros la primera versión estable de esta distribución.

Evidentemente os animo a leer el artículo completo que ha titulado «This month in KDE Linux: March 2026» pero aquí os ofrezco un resumen del mismo para los que no tenemos un dominio exhaustivo del inglés.

• Ahora es más difícil que el ordenador deje de funcionar tras una actualización, ya que se han mejorado los mecanismos para «volver atrás» automáticamente si algo falla. Este punto creo que es el básico para esta distribución.
• Se ha optimizado la gestión de memoria para evitar que el equipo se congele por completo cuando tienes demasiadas aplicaciones abiertas; en su lugar, el sistema simplemente cerrará la que más consuma.
• Para el día a día, conectar un iPhone o iPad ahora es más sencillo, permitiendo pasar fotos directamente desde el gestor de archivos.
• El sistema es más «parlanchín» y claro: si intentas abrir un programa que no es compatible, te explicará por qué en lugar de dar un error genérico.

• Al escribir contraseñas ahora verás asteriscos para confirmar que estás tecleando.
• Se ha incluido un corrector ortográfico listo para usar.n
• Ahora el sistema operativo permite «abrir» archivos que son copias exactas de un CD o DVD (como los archivos .iso) sin necesidad de grabarlos en un disco físico.
• Mejorado el soporte para archivos antiguos de Word
• Mayor compatibilidad con diferentes formatos de música y archivos comprimidos.

Para finalizar, os dejo las palabras de Nate:

¿Te parece emocionante este proyecto? ¡Espero que sí! Estamos construyendo un sistema operativo de propósito general para gente normal, con el objetivo de integrar todos los componentes de serie de una forma que rivalice con Windows y MacOS. Si quieres echar una mano con el proyecto, hay varias formas de hacerlo.
Si eres una persona técnica y aventurera, instala KDE Linux e informa de los fallos que encuentres.
Si se te da bien escribir, la documentación siempre se puede mejorar. Envía tus propuestas de cambios (merge requests) aquí.
KDE Linux se apoya mucho en Flatpak, por lo que solucionar problemas de empaquetado o de código en aplicaciones de este tipo es de gran ayuda.
¡Incluso puedes ayudarnos a construir el propio sistema operativo! El objetivo de la versión Beta está completado al 71% y queda mucho por hacer:
Y si ya estás usando KDE Linux, ¡cuéntanos qué tal ha sido tu experiencia! ¿Es buena? ¿Qué podemos mejorar?

Como vemos, KDE Linux no es solo una «distro» más; es el campo de pruebas y la vitrina oficial de lo que KDE puede ofrecer cuando controla todo el ecosistema, un sueño que no viene de ahora (ya escuché esto en la Akademy de A Coruña de 2015 y cuyo primer se dio con KDE Neon).

Vemos que el desarrollo de esta Comunidad cuyos objetivos están claros se construye dando pasos pequeños pero seguros.

La entrada Este mes de marzo en KDE Linux se publicó primero en KDE Blog.

El cliente de correo Thunderbird y la gestión para que se visualice en la bandeja de sistema de sistemas GNU/Linux es un problema que quizás pronto tenga solución

Desde hace tiempo utilizo el cliente de correo Thunderbird para la gestión de mis correos electrónicos, por hacer la tarea de manera eficiente y ser software libre y para asegurarme que siga siendo así he donado varias veces al proyecto.

Algo que todavía queda pendiente en sistemas GNU/Linux y que de manera recurrente se ha pedido, es la posibilidad de minimizar la aplicación en la bandeja del sistema y que además muestre el número de correos sin leer, o si hay alguno nuevo.

Es un problema más complejo de lo que pueda parecer, pero que quizás poco a poco se vaya solventando hasta dar con la solución.

De manera periódica, cada mes en Thunderbird publican una revisión del desarrollo que están llevando a cabo en el software. De las novedades en las que trabajan, de los problemas solucionados y tareas en las que sigue involucrado el equipo de desarrollo.

En la revisión de marzo de 2026 un apartado me llamó la atención, el referente al trabajo desarrollado para la bandeja de sistema en sistemas GNU/Linux.

Como he comentado, algo recurrente en las peticiones a Thunderbird era la posibilidad de que Thunderbird se minimizara en la bandeja de sistema y que además mostrara número de correos sin leer o alertas de correos nuevos. Desconozco si en sistemas privativos como el de Microsoft o Apple sí hace eso.

En este caso el equipo de desarrollo comparte la siguiente nota:

Bandeja del Sistema Linux

Este mes queremos dar un reconocimiento especial a Christophe Henry, que ha ido más allá con una ambiciosa contribución para mejorar la integración de la bandeja de sistemas de Thunderbird en Linux.

Este trabajo no es un parche pequeño y abarca varias partes de la base de código, incluyendo JavaScript, C++ y Rust, e incluso conecta con interfaces de XPCOM. El objetivo es unificar cómo se comportan los indicadores de correo no leído y los iconos de bandeja entre plataformas, lo cual es un problema sorprendentemente complejo si se tienen en cuenta las diferencias entre entornos Linux, Windows y macOS.

Lo que realmente destacó fue el nivel de persistencia detrás de esta contribución. A lo largo de varias iteraciones, Christophe resolvió fallos de compilación, peculiaridades de la plataforma y comentarios detallados de revisiones, todo ello mientras abordaba problemas complicados como la codificación de imágenes, las APIs de bandeja del sistema y la integración entre idiomas.

Este tipo de trabajo rara vez es sencillo y a menudo requiere profundizar en partes desconocidas de la pila. Ver que se impulse con este nivel de cuidado y determinación es precisamente lo que hace que la colaboración de código abierto sea tan poderosa.

¡Gracias por la dedicación y el esfuerzo! Realmente marca la diferencia.

---

Espero que ese esfuerzo, poco a poco vaya dando los resultados esperados y el cliente de correo Thunderbird llegue a ese grado de integración con sistemas GNU/Linux, en el que la diversidad es la norma y que supongo complica la tarea.

I gave a proprietary tool a fair chance - and was not disappointed

The views expressed in this post are my own and do not represent the position of my employer. This post is not a commercial endorsement of QASE or any of its products.

I very seldom write about proprietary solutions and software. Not because I have any problem with them, but simply because I usually prefer open source solutions, and during my daily work and hobby projects I use almost exclusively open source software.

No dia 31 de março de 2026, um evento chamou a atenção da comunidade de engenharia de software e segurança: o suposto vazamento completo do código-fonte do Claude Code, CLI oficial da Anthropic.

Mas o mais curioso?
Não foi um ataque sofisticado.

Foi algo muito mais comum e perigoso: um source map publicado no npm.

O que aconteceu

Um pesquisador de segurança identificou que o pacote @anthropic-ai/claude-code incluía um arquivo .map de aproximadamente 57 MB, contendo o código original completo da aplicação. Esse tipo de arquivo é usado normalmente para debug, mapeando código minificado de volta ao original mas, neste caso, ele continha todo o código em texto puro dentro da propriedade sourcesContent.

O resultado:

• ~1.900 arquivos
• 512.000+ linhas de código TypeScript
• Arquitetura completa de produção exposta

Ou seja: não foi um
leak parcial.
Foi o sistema inteiro.

O que existe dentro do Claude Code

O vazamento revelou algo muito mais interessante do que apenas código revelou como uma IA moderna de desenvolvimento realmente funciona por dentro.

Arquitetura real (não marketing)

O Claude Code não é apenas um wrapper de chat. Ele é um sistema complexo com:

• Sistema de ferramentas (tool-based)
  Cada ação (ler arquivo, executar bash, buscar web) é um módulo isolado e com permissões.
• Query Engine (~46k linhas)
  Responsável por orquestrar chamadas ao modelo, cache, streaming e controle de execução.
• Multi-agentes (“swarms”)
  Capacidade de criar agentes paralelos para resolver tarefas complexas.
• Integração com IDEs
  Comunicação com VS Code e JetBrains via canais autenticados.

Tudo isso rodando sobre Bun + React (Ink) no terminal.

O que mais chamou atenção (e preocupa)

Esse tipo de vazamento não expõe só código ele expõe modelo mental e decisões de segurança.

Entre os pontos críticos identificados:

• System prompts e lógica interna de comportamento
• Modelo de permissões de ferramentas
• Proteções contra path traversal e acesso indevido
• Features beta não lançadas
• Estratégias de orquestração de agentes

Além disso, foram encontrados codenames internos como:

• KAIROS → modo persistente “always-on”
• Capybara → outro subsistema interno
• Flags de recursos como:
  • contexto de 1 milhão de tokens
  • “interleaved thinking”
  • controle de esforço e modo rápido

A falha real: supply chain e build pipeline

O mais importante aqui não é o Claude. É o padrão. Esse incidente reforça um problema recorrente:

Falhas em pipelines de build e publicação são hoje uma das maiores superfícies de ataque.

O erro foi simples:

• O bundler gerou .map
• O .npmignore não excluiu
• Nenhum pre-check validou o pacote antes do publish

Resultado: qualquer pessoa com npm pack tinha acesso ao código inteiro.

Insight estratégico (o que isso nos ensina)

Esse caso revela três coisas fundamentais sobre o futuro da IA:

1. IA moderna = sistemas complexos, não modelos isolados

O diferencial não está só no LLM está na orquestração.

2. Segurança de IA não é só prompt injection

É:

• supply chain
• permissões de ferramentas
• controle de execução

3. Transparência involuntária acelera aprendizado global

Mesmo sendo um incidente, ele oferece um “raio-x” de como sistemas state-of-the-art são construídos.

Conexão com o futuro (e com o que estamos construindo)

Se você trabalha com:

• sistemas multi-agente
• execução local/offline de IA
• orquestração de ferramentas

Esse vazamento praticamente confirma uma direção:

O futuro da IA está na integração entre modelo + sistema operacional + runtime de execução.

Algo muito próximo do que já vemos emergindo em iniciativas como:

• AI-native OS
• agentes autônomos
• computação heterogênea (CPU + GPU + NPU)

---

Conclusão

Não foi apenas um vazamento. Foi um lembrete.Onde:

• segurança básica ainda falha
• sistemas de IA são mais complexos do que parecem
• e estamos apenas começando a entender como esses sistemas realmente funcionam

E talvez o ponto mais importante:

Quem dominar a arquitetura, não só o modelo vai dominar a próxima geração da IA.

My AI mini workstation from HP has seen some non-AI workloads this weekend. I installed Capture One for photo editing and a couple of software synthesizers. And realized along the way that while built-in speakers are nice, high-end audio is a lot better! :-)

For months, I have been listening to music on devices that are designed for speech: a pair of Jabra headphones and the speakers of my various laptops. There were many reasons for this, including peer pressure, and some hearing loss at a way too loud concert. I was also lazy to use my high-end devices and tried to persuade myself that audio equipment designed for meetings is good enough for music too. Well…

This weekend, I installed various software synthesizers on my new computer. Not that I learned music or could play any instruments, but I still enjoy experimenting with music (well, with noise, actually :-) ). As I connected the machine to the big screen in the living room, I also connected it to my HiFi system. Suddenly, I realized how much better it sounds than my laptop or anything I’ve listened to in the past few months.

While making noise with a couple of software synths and listening to music from my TIDAL subscription, I also recharged my Focal headphones. My Focal Bathys is not as good as my HiFi, but also has a wonderful sound regardless.

So I guess that after a few months long detour, I am back to using high-end audio gear whenever it is technically possible. I love the extra detail I can hear on my Heed Enigma speakers or on my Focal headphones. Of course, nothing can replace listening to live music at concerts, but high-end gear is much better at approximating the vibe of various live events than anything below it.

This blog is part of a longer series about my adventures with my new machine and AI. You can reach me to discuss this blog on one of the contacts listed in the upper right corner. You can read the rest of the blogs under the toy tag.

Con este creo que ya me pongo al día con los últimos episodios del podcast más regular e informativo de la Comunidad KDE. Me congratula presentaros el episodio 71 de KDE Express, titulado «esLibre2026 Guía de Autodefensa Digital con Enxeñería Sen Fronteiras» donde David Marzal sigue promocionando el evento de la Comunidad del Software Libre de abril.

Episodio 71 de KDE Express: esLibre2026 Guía de Autodefensa Digital con Enxeñería Sen Fronteiras

Comenté hace ya bastante tiempo que había nacido KDE Express, un audio con noticias y la actualidad de la Comunidad KDE y del Software Libre con un formato breve (menos de 30 minutos) que complementan los que ya generaba la Comunidad de KDE España, aunque ahora estamos tomándonos un tiempo de respiro por diversos motivos, con sus ya veteranos Vídeo-Podcast que todavía podéis encontrar en Archive.org, Youtube, Ivoox, Spotify y Apple Podcast.

De esta forma, a lo largo de estos 71 episodios, promovidos principalmente por David Marzal, nos han contado un poco de todo: noticias, proyectos, eventos, etc., convirtiéndose (al menos para mi) uno de los podcast favoritos que me suelo encontrar en mi reproductor audio.

En palabras de David:

Bueno, con esto de los PrestoCast me ha costado volver a los podcast normales (que llevan bastante más trabajo), pero la ocasión lo merece porque os traigo información de primera mano de otra charla de esLibre. Hoy tenemos a Laura Salgueiro Sánchez voluntaria de Enxeñería Sen Fronteiras.

Vivimos en un mundo que, con su parte buena y su parte mala, avanza hacia lo digital a pasos agigantados y, en demasiadas ocasiones, dejando a mucha gente atrás. Este mundo digital, al igual que el presencial, también tiene una serie de riesgos de los que hay que protegerse. Muchas de vosotras quizás tenéis a esa persona de confianza (hija, sobrina, amiga…) a quien consultarle dudas o pedirle consejo en cosas relacionadas con las tecnologías de la información (TIC), pero no todo el mundo tiene esa opción. Además, tendemos a caer en el uso de herramientas de Google, Microsoft y otras grandes multinacionales, cediendo completamente nuestra soberanía digital. Por eso hacemos esta guía, explicando de forma clara y detallada cómo puedes mejorar tu seguridad digital, recuperando tu soberanía digital, tengas o no conocimientos previos de ciberseguridad. Es importante tener claro que la seguridad absoluta no existe, y siempre hay riesgo. Lo que podemos hacer como personas usuarias es poner barreras que nos protejan.

Laura es estudiante del último curso de Ingeniería Informática y Matemáticas. Le interesa especialmente utilizar sus conocimientos para mejorar la igualada de genero, el medio ambiente y la educación. Imparte como voluntaria de Ingeniería Sin Fronteras charlas en institutos sobre el impacto medioambiental de la nube, la privacidad digital o ciberseguridad.
Web personal: https://galicia.isf.es/ Mastodon (u otras redes sociales libres): https://mastodon.gal/@ESFGalicia GitLab (u otra forja o portfolio general): https://gitlab.com/esfgalicia/guia_autodefensa_dixital
Que nos trae la charla:

Guía de Autodefensa Digital: recupera tu soberanía digital. Tipo de propuesta: Charla larga (alrededor de 30 minutos)

Público objetivo: Todo tipo de público. No se requieren conocimientos previos de ningún tipo.

https://propuestas.eslib.re/2026/charlas/guia-de-autodefensa-digital-recupera-tu-soberania-digital

---

Por cierto, también podéis encontrarlos en Telegram: https://t.me/KDEexpress

La entrada Episodio 71 de KDE Express: esLibre2026 Guía de Autodefensa Digital con Enxeñería Sen Fronteiras se publicó primero en KDE Blog.

No es la primera vez que Guillem Cortés (GCtech) se asoma por el blog, lo tuvimos cuando hablaba de su experiencia instalando en un MacOS un sistema libre como Asahi Linux . En esta ocasión, GCtech vuelve para compartir una de sus mayores aventuras digitales: su primer año completo utilizando Linux como sistema operativo principal intentando contestar a la pregunta del millón: ¿Qué es Mejor Windows o Linux? Evidentemente la respuesta no es categórica ya que depende de la persona pero gracias a este vídeo podemos tener las cosas más claras.

¿Qué es Mejor Windows o Linux? Mi Experiencia 1 año Después

Hoy toca un excelente vídeo de GCtech donde explica de forma muy didáctica las bases de Linux, sus ventajas e inconvenientes, comparándolo con Windows.

En palabras de Guillem:

¿Puede Linux realmente reemplazar a Windows en el día a día? En este video comparto mi experiencia completa tras un año usando Linux a diario: desde mis inicios hasta usarlo como sistema operativo principal. Te explico sus diferencias técnicas con Windows, las ventajas, los retos reales, y por qué creo que probar Linux debería ser obligatorio en un mundo cada vez más digital.

De esta forma, a lo largo de casi 30 minutos nos cuenta las bondades, y los inconvenientes de Linux (o GNU/Linux siendo precisos). Unos problemas que se centran en las aplicaciones que no existen en el sistema del pingüino, el tema de los videojuegos (aunque estos problemas tienen solución como la búsqueda de las alternativas o en el desarrollo de Protón) o en eterno problema del hardware no compatible.

Aunque hayáis visto el vídeo, creo que es bueno tener una lista de cosas buenas y malas:

Más allá de las comparativas técnicas, el mensaje de Guille es una invitación a la curiosidad. Defiende que Linux debería enseñarse en las escuelas para entender la tecnología que sostiene el mundo (desde servidores hasta Android).

Si tienes un PC antiguo acumulando polvo o simplemente quieres recuperar la soberanía sobre tu ordenador, este vídeo es la guía perfecta para perder el miedo a la terminal y descubrir que, como bien dice Guillem, en Linux «el límite lo pones tú».

La entrada ¿Qué es Mejor Windows o Linux? Mi Experiencia 1 año Después se publicó primero en KDE Blog.