Todo tiene un precio

Joe Bloggs se sentó frente a su portátil nuevo, pulsó el botón de encendido y esperó. Le había costado una buena suma, pero bien lo merecía: había tenido su dispositivo anterior durante casi seis meses. Mantenerlo más tiempo seguro que le costaría aparecer en un registro en algún sitio. Eso nunca era bueno. Aún peor era estar en posesión de una máquina más allá de su periodo legal de uso, una violación de la RA1011. Eso era aterrador.
Tras 30 minutos de vídeos promocionales, el ordenador llegó a la pantalla de inicio. Pasó la tarjeta y le cobraron 25 dólares por abrir el escritorio. Aunque sí era verdad que tenía que pasarla una sola vez. En cada una de las siguientes sesiones, el importe se le cargaría automáticamente en cuenta.
Lo mismo ocurría con las aplicaciones. Algunas eran más baratas que otras. Abrir Wowser costaba solo 50 céntimos, porque era la puerta de entrada al World Wide Market. En la red, cada sitio ya tenía su propia tarifa de acceso: las tiendas solían ser más baratas. Pero visitar cualquier portal donde pudieras interactuar con otras personas, en chats, foros o redes sociales, te podía costar hasta 100 dólares el minuto.
Tras los 50 anuncios de visionado obligatorio, Wowser mostró la página de GooBing, cargándole otros 10 dólares a su cuenta. Aunque aún no había realizado ninguna búsqueda, ¡uno no podía esperar que le regalasen la información!
De hecho, eso estaba prohibido por la ya famosa RA1996: «Ninguna persona, empresa, organización o entidad pública puede ofrecer productos o servicios de ningún tipo de forma gratuita». En el momento de su aprobación, argumentaron que esto nivelaría el terreno de juego, impidiendo que ciertas asociaciones, organizaciones benéficas y hackers subversivos de software libre socavaran a las empresas. Los mandamases tecnológicos, al fin y al cabo, eran los grandes titanes hechos a sí mismos al mando de los verdaderos motores de la industria, dirigiendo las empresas que generaban empleo y creaban verdadera riqueza a partir de la nada digital.
Joe no podía estar en desacuerdo. Después de todo, él era uno de los beneficiarios de la industria tecnológica. Cuando encendía su procesador de textos con certificación RA0365, podía trabajar y ganar lo suficiente para mantener la tecnología que le permitía trabajar y ganar dinero. Además, todo le resultaba tan cómodo: el subsistema iSpyAI detectaba automáticamente que estaba usando la suite ofimática para su trabajo, calculaba el valor monetario de su producción y descontaba un 10% para el proveedor de software.
Esto tenía sentido para Joe: si ganas dinero con su software, era justo que se llevaran su parte, incluso después de cobrarte en su momento por la adquisición del software y por el privilegio de usar su almacenamiento en la nube. Después de todo, los discos estaban ridículamente caros y eran muy lentos, decían, tanto es así que, no tenía sentido ofrecer en los menús del software en ningún sitio una opción para guardar tu trabajo localmente.
Si usaba la suite de oficina para cosas no relacionadas con el trabajo, como cuando escribía sus poemas, la tarifa se calculaba por palabra. Pero ya no hacía eso muy a menudo, no tanto por el coste, sino porque iSpyAI también registraba y analizaba esos textos y era cada vez más fácil violar alguna de las RA menos conocidas, incluso con un simple haiku.
El chaval del apartamento de al lado había escrito un apasionado mensaje a su novia. Antes de que pudiera pulsar el botón de Enviar, unos hombres armados vestidos de negro derribaron su puerta y lo golpearon con sus porras eléctricas hasta dejarlo sin sentido. Joe nunca llegó a enterarse qué empresa de software los había enviado, pero ahora su vecino cojeaba y estaba ciego de su ojo izquierdo.
En todo caso, que el navegador Wowser le llevara a GooBing cada vez que se ejecutaba era demasiado caro para Joe. Así que abrió la configuración y rebuscó en su contenido. Cambiar un valor predeterminado le costaría solo unos pocos céntimos. Modificar la página principal probablemente supondría algún cargo extra, pero, si elegía con cuidado, a la larga le saldría a cuenta.
Localizó la opción de la página principal y rellenó la casilla con foodsolutions4u.com, un sitio barato que Joe frecuentaba. Era una tienda que ofrecía «comidas*» para microondas. El texto bajo el asterisco garantizaba que cada comida contenía «sustancias alimentarias aprobadas». Foodsolutions4u le obligaba a hacer una compra en cada visita según la RA0888, pero sus productos eran casi todo lo que comía Joe.
Pulsó Guardar.
Una alerta a pantalla completa se iluminó en su escritorio. Letras grandes, blancas y agresivas sobre un fondo rojo:
VIOLACIÓN DE RA0101 DETECTADA. NO ABANDONE LAS INSTALACIONES. NUESTROS AGENTES LE ATENDERÁN EN BREVE.
La sangre se le heló en las venas.
Sonó un fuerte golpe en la puerta…
Este texto es una traducción del artículo original escrito en inglés por Paul Brown y publicado originalmente en su blog bajo una licencia CC-by-sa que puedes leer en este enlace:
Muchas gracias a Paul por permitirme traducir y publicar su ficción o peligrosa profecía de la «truñificación» que va asolando cada rincón de lo que una vez fue una red abierta.
El software libre creado por las distintas comunidades debe seguir ofreciendo alternativas éticas y creadas por personas para personas frente a sistemas cerrados que cada vez encierran más a sus usuarios «usados» en sus propios ecosistemas abusivos: no posees tus equipos o software, solo una licencia que te permite su uso.
Arreglando todas las cosas – Esta semana en Plasma
El incansable trabajo de promoción que está realizando Nate (ahora con ayuda de otros desarrolladores) en su blog sigue su ritmo. Cada semana hace un resumen de las novedades más destacadas, pero no en forma de telegrama, sino de artículo completo. Su cita semanal no falla y desde hace un tiempo que le voy a siguiendo semana tras semana, traduciendo sus artículos al castellano utilizando los magníficos traductores lo cual hará que la gente que no domine el inglés esté al día y que yo me entere bien de todo. Bienvenidos pues a «Arreglando todas las cosas – Esta semana en Plasma». Espero que os guste.
Arreglando todas las cosas – Esta semana en Plasma
Nota: Artículo original en Blogs KDE. Traducción realizada utilizando Perplexity. Esta entrada está llena de novedades de la Comunidad KDE. Mis escasos comentarios sobre las mejoras entre corchetes.
¡Bienvenido a un nuevo número de This Week in Plasma!
Esta semana, el equipo siguió puliendo Plasma 6.7 de cara a su lanzamiento a finales de mes. Por tanto, la mayor parte del trabajo se centró en corregir errores.
Mejoras en la interfaz de usuario
Plasma 6.7
Al pasar el cursor sobre un elemento parcialmente visible del widget del lanzador de aplicaciones Kickoff, la vista ya no se desplaza automáticamente y sin querer para mostrar el elemento completo. (Christoph Wolk, KDE Bugzilla #426015)
La función de Spectacle que copia automáticamente la captura al portapapeles ahora se desactiva temporalmente mientras se extrae texto mediante OCR, para que el texto extraído sea el que termine en el portapapeles. (Tobias Fella, KDE Bugzilla #520758) [Afinando una gran funcionalidad de Spectacle].
Al iniciar una app desde una ventana de terminal, el efecto animado de lanzamiento ahora termina después de que la app se abre, como era de esperar. (Nicolas Fella, Vlad Zahorodnii y Akseli Lahtinen, KDE Bugzilla #459986) [Igual que antes, en este caso, afinando la visualización del sistema].
Plasma 6.8
Las notificaciones sobre dispositivos conectados con batería baja ahora también se muestran en apps a pantalla completa, para que no te las pierdas, igual que las notificaciones de batería baja de la batería interna. (Jan Bidler, plasma-workspace MR #6623) [Esto es importante, el control de las baterías se han convertido en algo cotidiano en nuestro día a día].
Los efectos Peek at Desktop y Window Aperture ahora respetan el ajuste global de velocidad de animación del sistema. (Sudip Datta, KDE Bugzilla #490531)
Framework 6.27
KRunner ahora asume que te refieres a pintas estadounidenses en lugar de pintas imperiales cuando conviertes desde o hacia ellas, ya que la pinta sigue siendo una unidad oficial en Estados Unidos. (Nate Graham, kunitconversion MR #86) [No se me ha dado el caso].

Los tamaños de disco mostrados en varios lugares ahora respetan por completo tu preferencia sobre las unidades de almacenamiento. (Tobias Fella, KDE Bugzilla #518493)
Corrección de errores importantes
[No comento las correcciones de errores ya que son bastante evidentes].
Plasma 6.6.6
Se corrigió un caso en el que Plasma podía bloquearse al actualizar la lista de redes inalámbricas cercanas. (David Edmundson, KDE Bugzilla #519739)
Se corrigió un problema que restablecía los diseños personalizados de mosaico en monitores girados en vertical después de reiniciar el sistema. (Hynek Schlindenbuch, KDE Bugzilla #514355)
Al buscar una app en el widget del menú de aplicaciones Kicker y abrir una que no sea el primer resultado de la lista, ahora ya no se abre dos veces. (Christoph Wolk, KDE Bugzilla #521001)
Plasma 6.7
Se corrigió una regresión en el escritorio compartido basado en VNC que impedía enviar las teclas modificadoras Ctrl y Alt al equipo controlado. (David Edmundson, KDE Bugzilla #519690)
Se corrigió un problema que podía hacer que Plasma se congelara si cambiabas rápidamente de mes en el widget Reloj digital arrastrando la vista del calendario varias veces seguidas. (Sander Wolswijk, KDE Bugzilla #511028)
La función “Mover al escritorio” del widget Gestor de tareas ahora funciona con tareas agrupadas. (Hynek Schlindenbuch, KDE Bugzilla #520777)
Se corrigieron dos problemas con el widget de agrupación: que no reapareciera al instante al deshacer su eliminación, y que quedara visible una cabecera fantasma después de quitarle la última app. (Tobias Fella, KDE Bugzilla #517044 y KDE Bugzilla #517043)
Se corrigió una variedad de problemas con iconos o elementos de lista que no se invertían correctamente al usar un idioma de escritura de derecha a izquierda como árabe o hebreo. (Tobias Fella y Akseli Lahtinen, KDE Bugzilla #518932, KDE Bugzilla #518909, KDE Bugzilla #518935, KDE Bugzilla #518835 y KDE Bugzilla #518837)
Se hizo que Configuración del sistema elevara y enfocara su ventana como era de esperar al iniciarse usando un nivel de prevención de robo de foco superior al predeterminado. (Kai Uwe Broulik, systemsettings MR #408)
Frameworks 6.27
Al cambiar entre Temas globales claros y oscuros, ahora ya no ocurre a veces que varios elementos de la interfaz de Plasma solo cambien de color a medias. (Marco Martin, KDE Bugzilla #503671)
Se corrigió un problema al guardar y recuperar datos de configuración en los casos en que un ajuste tiene un valor predeterminado establecido por el proveedor del sistema que difiere del valor predeterminado de KDE. (Nicolas Fella, KDE Bugzilla #509416)
Se corrigieron varios problemas relacionados con recursos compartidos de red montados automáticamente mediante systemd, incluido que la papelera no funcionara correctamente y que aparecieran de forma extraña en aplicaciones gráficas. (Oliver Schramm, KDE Bugzilla #518012)
Se corrigió un problema que hacía imposible renombrar archivos del escritorio mediante la función “Sugerir nuevo nombre” del diálogo de sobrescritura. (Akseli Lahtinen, KDE Bugzilla #509461)
Cómo puedes ayudar
KDE se ha vuelto importante en el mundo, y tu tiempo y contribuciones han ayudado a llegar hasta aquí. A medida que crecemos, necesitamos tu apoyo para mantener KDE sostenible.
¿Te gustaría ayudar a preparar este informe semanal? Preséntate en la sala de Matrix y únete al equipo.
Más allá de eso, puedes ayudar a KDE involucrándote directamente en cualquier otro proyecto. Donar tiempo es realmente más impactante que donar dinero. Cada colaborador marca una gran diferencia en KDE — ¡no eres un número ni un engranaje en una máquina! No tienes que ser programador, existen muchas otras oportunidades.
También puedes ayudar haciendo una donación. Esto ayuda a cubrir costes operativos, salarios, gastos de viaje para colaboradores y, en general, a mantener KDE llevando Software Libre al mundo.
La entrada Arreglando todas las cosas – Esta semana en Plasma se publicó primero en KDE Blog.
Linux Saloon 205 | Open Mic Night
BuildStream y KDE- nueva charla de Barcelona Free Software
Vuelven los chicos y chicas de Barcelona Free Software. Concretamente será el próximo jueves 11 de junio con una charla titulada «BuildStream y KDE» en la que Aleix Pol, presidente de KDE e.V. nos hablará de BuildStream, una potente herramienta de integración de software que se utiliza principalmente en el entorno de sistemas basados en Linux
BuildStream y KDE- nueva charla de Barcelona Free Software
Segunda charla de este año que promociono de esta rama de KDE España con una ponencia de una de las personas más importantes de la Comunidad KDE, Aleix Pol, presidente de KDE e.V. y ex-presidente de KDE España.
En palabras de los organizadores.

Aleix Pol, president of KDE e.V. will talk about BuildStream, a mechanism to build operating systems and all sorts of packages like that.
We will discuss why it’s interesting, what can it do and why have I been spending time seeing to KDE Linux using it as it’s build tool.
After this presentation you’ll also know how to build your operating system and hopefully be able to contribute to a bunch more!
Aleix Pol, presidente de KDE e.V., hablará sobre BuildStream, una herramienta diseñada para compilar sistemas operativos y todo tipo de paquetes de software.
Vamos a ver por qué es interesante, qué es capaz de hacer y por qué ha pasado tanto tiempo en KDE Linuxusándolo como nuestra herramienta de compilación.
Después de esta presentación, tú también sabrás cómo compilar tu propio sistema operativo y, con suerte, podrás empezar a contribuir en muchos otros proyectos.
La información básica de la charla es:
- Día: Jueves 11 de junio de 2026
- Hora: 19:30
- Lugar: Akasha Hub Carrer de la Verneda, 19, Nau 1 · Barcelona
No te lo pienses. ¡Te esperamos el jueves 11 de junio!
Más información: Barcelona Free Software
¿Qué es Meetup?
Las charlas de Barcelona Free Software se organizan mediante Meetup, una red social que tiene una diferencia básica respecto a otras redes sociales, ya que promueve la formación de grupos en torno a intereses con el fin de que sus miembros se conozcan cara a cara.
Es decir, los usuarios establecen contacto a través de grupos digitales nuevos o ya creados, partiendo de intereses comunes como política, libros, juegos, películas, salud, mascotas,
La entrada BuildStream y KDE- nueva charla de Barcelona Free Software se publicó primero en KDE Blog.
#openSUSE Tumbleweed revisión de la semana 23 de 2026
Tumbleweed es una distribución de GNU/Linux «Rolling Release» o 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 esta semana.
Y recuerda que puedes estar al tanto de las nuevas publicaciones de snapshots en esta web:
El anuncio original lo puedes leer en el blog de Dominique Leuenberger, publicado bajo licencia CC-by-sa, en este este enlace:
Esta semana se han publicado 6 Snapshots (0529, 0530, 0531, 0601, 0602 y 0603).
Estos son los cambios más relevantes:
- Mesa 26.1.1
- Mariadb 11.8.7 & 11.8.8
- Qt 6.11.1
- Pipewire 1.6.6
- Samba 4.23.8 & 4.24.3
- GNOME 50.2
- util-linux 2.42.1
- gpgme 2.1.0
- libvirt 12.4.0
Y para próximas snapshots, ya se están preparando las siguientes actualizaciones:
- Mesa 26.1.2
- Linux kernel 7.0.11
- harfbuzz 14.2.1
- php 8.5.7
- KDE Gear 26.04.2
- KDE Plasma 6.7.0
- GCC 16
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?
- ¿Qué es el test openQA?
- http://download.opensuse.org/tumbleweed/iso/
- https://es.opensuse.org/Portal:Tumbleweed
——————————–
Tumbleweed – Review of the week 2026/23
Dear Tumbleweed users and hackers,
Another rather uneventful week over here in Europe: another holiday in the middle of the week (for some regions, not all of Europe). The openSUSE community, in its international form, is usually not significantly affected by such interruptions and keeps rolling. That’s exactly what was observed this week as well: 6 snapshots (0529, 0530, 0531, 0601, 0602, and 0603) have been published over the last week.
The main updates contained therein were:
- Mesa 26.1.1
- Mariadb 11.8.7 & 11.8.8
- Qt 6.11.1
- Pipewire 1.6.6
- Samba 4.23.8 & 4.24.3
- GNOME 50.2
- util-linux 2.42.1
- gpgme 2.1.0
- java packaging change: migrated from update-alternative to libalternatives
- libvirt 12.4.0
The future is bright, and looking into my crystal ball (or on the staging dashboard) helps me to predict these changes coming to you soon:
- Mesa 26.1.2
- Linux kernel 7.0.11
- harfbuzz 14.2.1
- php 8.5.7
- KDE Gear 26.04.2
- KDE Plasma 6.7.0, currently 6.6.91 staged for QA
- Rework of Python3 packaging (as a meta package instead of a provides of the default interpreter)
- gcc 16 as the system default compiler
Take it easy. A guide to avoid burnown during the Vulnpocalypse
Do not let the AI to remove the fun part from software development. We shouldn't allow gen AI to write software just because it "can". First, we must ask if it "should" do it, and even then, we should ask if we want to delegate the fun part, the thinking, the writing, the learning.
Remember what's important, journey before destination, we are the Code:
Do not let AI to destroy the community, do not let it destroy the technological knowledge commons.
tl;dr
Open Source maintainers are dealing with a lot of new reports and pressure to "fix" the project due to generative AI.
We need to find a way of stopping this and get back to something maintainable before all maintainers get burned out and look for a job in a farm:
- 100% secure software doesn't exists, so there will be always a possible CVE there. As Spaf said in 1989:
The only truly secure system is one that is powered off, cast in a block of concrete and sealed in a lead-lined room with armed guards - and even then I have my doubts.
- Fixing bugs, adds new bugs, and if you need to fix something quick, the probability of new bugs will be higher. Do not forget about the First Law of Programming:
If it works, don't touch it
-
The amount of CVE reports is lowering the CVE credibility and quality, so if everything is a "high" security issue, we can't prioritize now and these reports are not different from random issues in github. Do not listen to The Boy Who Cried Wolf
-
Stable software is sable because it doesn't change too much. It's something that we are willing to loose trying to reach the impossible of 100% secure software?
The actual problem
There's a lot of money in AI tech right now, and everyone is trying to make the best gen AI tool or just pretend that their tool is the best.
In relation with the software analysis and writing, targeting the open source is the obvious strategy.
-
It's interesting to scrap every line of code, patch, pull request, issue and discussion around software to train your model, so AI scrappers are DDoSing open source projects infrastructure.
-
To promote their tools or themselves, Security Researches are using AI to target any project, reporting High security vulnerabilities, with the only goal of getting a CVE number to say how good they are.
This second point is affecting maintainers, because now you are receiving a lot of poor quality security reports, that are generated with AI and that looks plausible and are hard to read. You need to spend a lot of time to check if there's an actual wolf there or if it's again this boy that's tricking me.
This is burning the energy of maintainers, that instead of doing something productive are wasting their limited time talking with a Stocatic Parrot.
Do not let the AI Bros to use classic manipulation techniques on you!
A lot of open source projects are maintained by volunteers that do the work with passion and love. And even if it's the job that paid your bills, the maintainer can feel the pressure. When someone put a lot of love in something and work on it during years, it's part of his identity, so attacking the software is like attacking the person behind it.
This is nothing new, and a lot of people take advantage of this emotional link to manipulate the maintainer to do something that he do not want to do.
AI bros are using these techniques, do not let them to manipulate you and define your project agenda.
Here's a (not complete) list of known manipulation techniques that you can detect (and disarm!) in your daily community work:
-
Flooding the queue. Just create so many new issues that the actual maintainers can't deal with it. You feel responsible for the project and feel bad because your TO-DO list is growing.
-
This software is not secure (doesn't do what I want), I will use this other one instead that's better. The classic, "GNOME doesn't allow me to change this specific preference, I'll use KDE from now on".
-
This software is low quality, it doesn't follow the (my random) quality standards. Direct attack to the maintainer self-esteem.
-
Gaslighting software development. LLM are expert at this and people that uses it just copy the tactic. When the maintainer detects something weird and just tries to blame the other person for reporting nonsense and wasting all people time, it starts to invent new arguments and ignore the previous interaction.
So, take it easy, and remember the best clause in almost any software project, THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU:
Disclaimer of Warranty.
THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY
APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT
HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM “AS IS” WITHOUT
WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND
PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE
DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR
CORRECTION.
Is the software more insecure in 2026?
No. Anyone old enough could remember how insecure old software was. Do you remember windows 98? Do you remember the internet when everything was http (without that little s at the end), when people use ftp to logging into their server and modify the php code directly on production?
It's true that today we have more dependency on technology, but it's also true that everything is more secure, we have more and better cryptography, we have different levels of isolation, virtual environments, containers, virtual machines...
But we have the feeling that since AI can analyse all the software and look for vulnerabilities, we are doomed, because any stupid kid can hack my over engineered GNU/Linux machine!
First, that's not true, you need to know about security to get something useful from any AI tool. But even if it was true, what can you do about it? We need to be practical and find a balance between risk and usefulness, so do not overestimate the risk just because everyone is talking about it right now.
But even then, the security paranoia is not good for anyone. Software is inherently buggy, people write software and makes mistakes, so a possible vulnerability appears. In theory, these bugs are fixed when discovered, so it's always recommended to update to the latest version, because almost all known bugs will be fixed.
But it's also known that new versions comes with new functionality and code, and that means new "unknown" bugs or different behavior. That's a headache, so that's why the stable and Long Term Support are popular distributions, because "if it works, don't touch it".
Stable packages just get the fixes, not new features, but fixes are also code changes, so there's always a possibility to break something, even with a patch update.
The stable software has a lot of value, do not let the AI security paranoia destroy that, and convert everything in a rolling release with the latest and greatest (and possibly broken) software. Sometimes it's better to keep using something old, with known vulnerabilities that you can mitigate, than use the latest with unknown new vulnerabilities that you can't do anything about.
I will fight AI with AI
Please, do not do that. What I was trying to argue during this long post is not a technical problem. The current burnout problem in open source is a social problem, you can't fix it with a new layer of probabilistic tokens.
-
Community reaction against AI. The current industry push for the usage of AI everywhere is affecting a lot of people, and as a reaction a lot of people are directly fighting back. Using gen AI just sends the message that you do not care enough to do it yourself, and destroy the trust on the project.
-
It doesn't worth it. Even if the AI works (that it doesn't) it doesn't worth it. Writing code is easier than reviewing, you learn and grow with every new line of code that you write, delegating the fun part and personal growth part to an AI will make you work more miserable and you will be a junior forever.
-
It doesn't create community. Think about it, it's hard to get someone involved in a software project, but who will want to read or improve the code produced by a gen AI? The only future collaborator will be another AI.
Take it easy
Just remember, you can always say no, there's no hurry, and there's no need to work on something that you don't want just because other people consider that important.
Free Source is something done by people, for people. The software is important, but the community around it is sometimes more important. We use Free source not because it's technically better (that it is), but because we trust who, how and why are writing it.
Remember why are you doing this, do not remove the Fun part, continue with the Just for Fun mood.
Segunda actualización de KDE Gear 26.04
La Comunidad KDE es una comunidad responsable y no solo se preocupa en lanzar novedades sino que también en mejorarlas. Me complace presentar, un poco tarde, la segunda actualización de KDE Gear 26.04 que apareció hace casi dos meses. Más estabilidad, mejores traducciones y pequeñas mejoras para las aplicaciones de nuestro entornos de trabajo.
Segunda actualización de KDE Gear 26.04
A pesar de lo que puedan pensar muchas personas, las aplicaciones no son perfectas. Entre las líneas de código se pueden colar errores de tipografía o que el usuario realice alguna opción que en un principio no estaba prevista por los desarrollador, por poner solo un par de ejemplos de imperfecciones.
Este no es un problema del Software Libre ya que el Software actual funciona de esta manera ya que no se piensa en él como un producto final que se encierra en una caja y se olvida. En la actualidad se sabe que el Software está vivo y sería estúpido ir guardando las mejoras sin dejarlas a disposición del gran público.
Con esto se gana en rapidez y evolución pero puede aumentar el número de errores (por norma general) leves, los cuales son subsanables con pequeñas actualizaciones.
La Comunidad KDE lo tiene claro: grandes lanzamientos cada cuatro meses y actualizaciones mensuales para subsanar errores.

Por ello me congratula compartir con vosotros la segunda actualización de KDE Gear 26.04 que nos ofrece un buen número de errores resueltos entre aplicaciones, librerías y widgets, algo que mejora el rendimiento del sistema.
Aquí podéis encontrar la lista completa de cambios de KDE Gear 26.04.2, pero por poner unos cuantos ejemplos de los errores que sea han resuelto tenemos:
- akregator: Se ha corregido un fallo al ejecutarse en arm64. (Código modificado).
- ksanecore: Se ha corregido un fallo durante el arranque de skanlite. (Código modificado, corrige el fallo #517465).
- koko: Se ha corregido el fallo de la acción de mover a la papelera que anulaba las acciones de borrado del editor. (Código modificado, corrige el fallo #519784).
Más información: KDE Gear 26.04.2
La entrada Segunda actualización de KDE Gear 26.04 se publicó primero en KDE Blog.
SELinux Insanity: Doing the same thing over-and-over and expecting security convergence
Every time a piece of software encounters a new access pattern, the answer is to tweak the policy. Then tweak it again. Then tweak it again. Then tweak it again. Then tweak it again. At what point does this stop being a security model and start becoming an endless process of granting exceptions?
There is one thing in open source software that consistently consumes more time than it has any right to.
SELinux.
Every few weeks it seems like another SELinux issue appears.
Implementing a new feature? Fix SELinux. Fixing a bug? Fix SELinux. Scratching your butt? Gotta fix your SELinux policy. Repeat forever.
At some point we should start asking the question: What exactly is this accomplishing?
The Concept
The idea is straightforward. If an attacker compromises a process, SELinux limits what that process can access. The attacker is confined to a security domain and prevented from reaching resources outside that domain.
That’s a reasonable goal.
I’m not arguing against the idea of mandatory access control. I’m questioning whether this was the right tradeoff.
The Cost of Convergence
If a piece of software has been around for twenty years, and enough users have run into enough denials, and enough maintainers have added enough exceptions, then sure, maybe the policy eventually becomes stable.
But what a ridiculous way to get there.
The model seems to be: run the software, wait for SELinux to break something, examine the denial, add a rule, repeat until users stop complaining.
That’s not design. That’s playing whac-a-mole.
We’re not thoughtfully defining a security model. We’re painfully discovering the application’s behavior by tripping over every possible thing it might need to do.
An Engineering Failure
SELinux asks us to accept that defining a security model requires years of stumbling over ourselves. I have a hard time believing that’s the best we can come up with.
Surely there must be a middle ground somewhere between “the application can do anything it wants” and “the application can’t do anything until we’ve spent the next several years teaching SELinux how it works.”
At some point we should be willing to ask whether there is a better way to solve this problem.
I don’t have the answer.
But I’m no longer satisfied with pretending that SELinux is the answer.
The status of OpenSSL 4.0 support in syslog-ng
OpenSSL 4.0 was released just over a month ago. So, how is its support progressing in syslog-ng? Well, Git master already supports it, and the patch is easy to backport to earlier releases. At the same time, version 4.12 will support OpenSSL 4.0 out of the box.
A month ago, someone from Gentoo Linux reached out to the syslog-ng team about OpenSSL 4.0 support. I asked the community about their expectations, knowing that version 4.0 is not an LTS version. However, I quickly learned that all major distros were preparing to use it in their rolling development versions. A few days later, we also received hints on how to add support for it in syslog-ng. And thus, a PR was born, which is now merged into syslog-ng git master.
What does this mean for you?
- If you need OpenSSL 4.0 support RIGHT NOW using a RELEASED syslog-ng version, then use syslog-ng 4.11 and the related pull request from https://github.com/syslog-ng/syslog-ng/pull/5688
- Use the latest syslog-ng git snapshot, as the above PR is already merged.
- Wait a few more weeks, as syslog-ng 4.12 will be released soon with OpenSSL 4.0 support.

syslog-ng logo
Originally published at https://www.syslog-ng.com/community/b/blog/posts/the-status-of-openssl-4-0-support-in-syslog-ng



