Last week, I wrote about my initial FreeBSD experiences on my new toy, an AI workstation from HP. FreeBSD runs lightning fast on it, but the desktop was somewhat problematic. Well, I made lots of improvements this week!

A bit of debugging

While there are still some rough edges, there have been tons of improvements since last week. I do not have plans to use FreeBSD on the desktop in the long term, but still, I just could not believe that the FreeBSD GUI is this problematic on this device. I did some experimentation though and it helped a lot… :-)

The initial problem I realized while browsing the output of dmesg was that desktop-installer enabled the wrong kernel modules repository for me. The line leading there was this:

KLD amdgpu.ko: depends on kernel - not available or version mismatch

The next problem occurred when I fixed this problem: there was a kernel panic on boot, when amdgpu.ko was loaded.

I did a fresh FreeBSD install and instead of using the latest packages, I decided to go with the quarterly packages. This way, the desktop installer configured the right kmod repo – however, loading amdgpu.ko still caused a kernel panic. Another experiment I made was using the ATI driver instead of AMD. The installer says that AMD is for modern cards, and ATI is for older ones. Well, as it turned out, even if the chip is barely half a year old, it counts as “old”… :-)

I am still not convinced that proper hardware-based acceleration works: both X.org logs and the GNOME “About” page showed software rendering. However, I had no problem with graphics performance: TuxRacer worked perfectly well… :-) And the GNOME desktop also worked nicely and as stable, including video playback. The only pain point when using GNOME was that screen locking still did not work.

KDE to the rescue

Even if it’s just software rendering, the graphics problem seems to be resolved. However, the screen locking problem still bothered me, as I’m an IT security guy with a healthy dose of paranoia (which means that I lock my screen even when I’m home alone… :-)).

So even if I haven’t tried KDE for the past 5+ years, I gave it a try now. After so many years on XFCE and GNOME, the interface looks a bit weird. However, everything I tried on it seems to work just fine, including screen locking.

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.

Organizada por la asociación sin ánimo de lucro GNU/Linux València os invito a participar en la charla «Debate: ¿el Estado contra las redes sociales?» que se celebrará el 27 de marzo a las 18:30 horas. Y antes, como es tradicional, su taller de instalación Linux. Una tarde completa.

Debate: ¿el Estado contra las redes sociales? – nuevo evento organizado por GNU/Linux València

Me complace presentaros un nuevo evento de la Asociación sin Ánimo de Lucro GNU/Linux València que siguen sus actividades este 2026 con una jornada que presentará un interesante y necesario debate que sería muy adecuado que llegara al gran público, sobre todo, a los adolescentes: Debate: ¿el Estado contra las redes sociales?

Pero antes, y como un servicio que no tiene precio pero que tiene un valor incalculable:

Y, si ya tienes tu Linux instalado, no te pierdas el debate-:

¡Recuerda!

• Viernes 27 de Marzo de 2026
• ¡Entrada libre!
• Edifici Las Naves (Carrer Joan Verdeguer, 16, 46024, València)
• 17:00 Taller de instalación/ayuda GNU/Linux
• 18:30 Parlem! Debate sobre regulaciones sobre redes sociales

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

¡Únete a GNU/Linux València!

Aprovecho para recordar que desde hace unos meses, los chicos de GNU/Linux Valencia ya tienen su menú propio en el blog, con lo que seguir sus eventos en esta humilde bitácora será más fácil que nunca, y así podréis comprobar su alto nivel de actividades que realizan que destacan por su variedad.

Y que además, GNU/Linux València creció y se ha convertió en asociación. Así que si buscas una forma de colaborar con el Software Libre, esta asociación puede ser tu sitio. ¡Te esperamos!

La entrada Debate: ¿el Estado contra las redes sociales? – nuevo evento organizado por GNU/Linux València se publicó primero en KDE Blog.

Two years have passed since I last shared my Friday app icon sketches, but the sketching itself hasn't stopped.

For me, it's the best way to figure out the right metaphors before we move to final pixels. These sketches are just one part of the GNOME Design Team's wider effort to keep our icons consistent and meaningful—it is an endeavor that’s been going on for years.

If you design a GNOME app following the GNOME Design Guidelines, feel free to request an icon to be made for you. If you are serious and apply for inclusion in GNOME Circle, you are way more likely to get a designer's attention.

Previously

Members of the openSUSE community are tackling the complex undertaking of transitioning from YaST by developing a streamlined system management interface.

After some adjustments and community feedback in the openSUSE bar, members took an existing tool to roll out a launcher for openSUSE users that provides a web-based system administration interface, more accessible to users switching from the traditional YaST setup utility.

The cockpit-client launcher, addresses a barrier that has frustrated some users attempting to adopt Cockpit as a replacement for YaST. According to feedback on the openSUSE forums, the process has been neither simple nor straightforward, until now.

The launcher icon, which includes legacy YaST colors for the adjusted logo, is specific to openSUSE and was created in response to user concerns. After some testing and minor refinements, the package was pushed and is available on Tumbleweed and Leap as an Official package.

“Since Cockpit-client has both Flatpak and RPM launchers available, we need to give them different icons so users can actually tell them apart,” said Lubos Kocman. “The different colored icon instantly shows users which launcher they’re opening to eliminate any confusion.”

The Installation Process

The launcher reduces a multi-step process that is now a straight-forward workflow. Previously, users faced complications accessing Cockpit through localhost:9090, which the community identified as a pain point.

sudo zypper install cockpit-client-launcher

Users are also recommended to install patterns-cockpit to ensure all Cockpit modules are available:

sudo zypper install -t pattern cockpit

Finally, users launch the application from their desktop environment’s application menu and follow initial setup dialogs. The launcher automatically activates necessary systemd services and firewall settings.

To align with security requirements, user will be asked whether to enable cockpit.socket and for preferred firewalld configuration in case cockpit wasn’t previously enabled and running.

It was tested on both Tumbleweed and Leap 16 installations and testing confirms the package successfully integrates across different openSUSE flavors, versions and installation scenarios.

A demonstration video created by Low Tech Linux showcases the installation and setup process on both Tumbleweed and Leap 16.

The Cockpit web interface provides graphical access to system administration functions that are traditionally handled through command-line tools or YaST, which include package management, user administration, service control, and more.

I often hear, even at security conferences that “no central log collection here” or “we have something due to compliance”. Central logging is more than just compliance. It makes logs easier to use, available and secure, thus making your life easier in operations, security, development, but also in marketing, sales, and so on.

What are logs and what is central log collection?

Most operating systems and applications keep track of what they are doing. They write log messages. A syslog message might look similar:

Mar 16 13:13:49 cent sshd[543817]: Accepted publickey for toor from 192.168.97.14 port 58246 ssh2: RSA SHA256:GeGHdsl1IZrnTniKUxxxX4NpP8Q

Applications might store their logs separately and have their own log format, like this Apache access log:

192.168.0.164 - - [16/Mar/2026:13:17:01 +0100] "HEAD /other/syslog-ng-insider-2026-03-4110-release-opensearch-elasticsearch/ HTTP/1.1" 200 3764 "-" "SkytabBot/1.0 (URL Resolution)"

Central log collection simply means that log messages are collected to a central location instead or in addition to saving them locally.

In this blog we take a look at what ease of use, availability, and security of central log collection mean for you.

Ease of use

If you have a single computer in your organization, finding a log message about an event on that computer takes some time. Once you have 2 computers, you have to check 2 computers to find that event. It might take twice as much time, but it is still easier than implementing central log collection. Not to mention, which one is the central computer. :-)

Once you have a network of 10 computers, logging in to each of them to find a log message about an event becomes a huge overhead. It is still doable, but implementing central log collection is a lot easier already in the short term, than looking at the logs on the machines where they were created.

On a network of 100 computers, it is practically impossible to find relevant logs by security or operations, unless logs are collected centrally.

Availability

Collecting logs centrally means that log messages are available even when the sending machine is down. If you want to know what happened, you do not have to get the machine up and running again, but you can check the logs at the central location. If you see signs of a hardware failure, you can go with a spare part immediately, reducing the time and effort needed to repair the machines.

Security

When a computer is compromised, log messages are often altered or deleted completely. However, this tactic only works with logs stored locally. Collecting logs at a central location allows you to use the unmodified logs and to figure out how the compromise happened.

What is next?

It is time to introduce central logging to your organization if you have not yet done it yet. Of course I am a bit biased, but syslog-ng is the perfect tool to do so. You can get started by reading / watching the syslog-ng tutorial on https://peter.czanik.hu/posts/syslog-ng-tutorial-toc/.

Originally published at https://www.syslog-ng.com/community/b/blog/posts/central-log-collection—more-than-just-compliance

Vamos a añadir un widget que mostrará información de nuestro sistema con escritorio Plasma de KDE

En nuestros sistemas GNU/Linux solemos tener instalado algún tipo de programa (uno de ellos puede ser fastfetch) que en la terminal muestra información muy completa de nuestro equipo y donde se muestra con más o menos gusto información como versión de nuestro kernel, versión de nuestro escritorio, compositor, nombre del sistema operativo, uptime, etc…

Pero ¿Por qué tenerlo solo en la terminal? ¿Por qué no tener un widget o plasmoide en nuestro escritorio y tenerlo a la vista? ¿Por qué no hacer que sea nativo de Plasma?

Pues hagámoslo…

Todo comenzó porque a mí me gusta saber el valor de uptime de mi máquina, y que en Plasma 5 utilizaba un bonito plasmoide que ya no está disponible para Plasma 6. Desde hace tiempo utilizaba un script en conky que me lo mostraba en el escritorio, pero decidí tratar de encontrar una solución nativa de Plasma y evitar conky.

Al final buscando encontré el modo de realizarlo, con el plasmoide configurable «Sensor del monitor de sistema». Pichamos sobre el escritorio de Plasma con clic derecho y entramos en el modo de edición y sobre la oopción en la parte superior de añadir o gestionar elementos gráficos.

En la lista que nos presenta buscamos «Sensor del monitor de sistema» y lo añadimos al escritorio.

En mi caso solo quería mostrar el uptime, pero quizás te animes tu (o quizás yo mismo en el futuro) a mostrar más información del sistema en tu escritorio. Así que vamos a ver cómo configurarlo.

En mi caso en la pestaña de Aspecto visual, eliminé la opción de «Mostrar el título» lo que elimina el título de la barra superior del plasmoide. Y en Estilo del Visor, escogí la opción solo texto, porque la información que quiero configurar es texto, por lo que no necesito gráficas, ni nada.

Ahora vamos a la pestaña Detalles de los sensores para configurar qué queremos que se muestre. En mi caso seleccionaré el dato del uptime, pero te animo a que escojas otras opciones y añadas varias informaciones a tu gusto.

Para el uptime, voy a la opción Sensores de texto (creo que en sensores también se puede configurar) y selecciono: Sistema operativo → Sistema → Tiempo de actividad y aplico la selección.

Pero en vez de que muestre el texto Tiempo de actividad con el valor del uptime, quiero que aparezce el texto Uptime, por lo que pincho sobre el icono del lápiz y modifico el texto que quiero que se muestre y aplico los cambios.

Y ya tenemos nuestro plasmoide mostrando la información del uptime del sistema. Pinchando sobre el propio plasmoide podremos seleccionar la opción de eliminar el fondo, por lo que aparecerá únicamente el texto, si lo queremos más minimalista. Hecho de menos la posibilidad de poder seleccionar el tamaño o el color de la fuente.

En el mismo sistio donde hemos configurado el Tiempo de actividad del sistema, podremos escoger otras opciones que nos muestren el nombre de nuestra máquina, la versión del Kernel que utiliza, y más información que queramos mostrar y todo de manera nativa con un Plasmoide configurable del propio Plasma.

Por Mastodon compartí una captura de pantalla de mi equipo con ese Plasmoide. Un escritorio con Plasma sencillo, y funcional con el Plasmoide en la parte inferior izquierda de la captura.

Me alegra compartir con todos vosotros la tercera actualización de Plasma 6.6, siguiendo así la serie de revisiones de software que le dotará de más estabilidad, mejores traducción y resolución de errores. Estas actualizaciones son 100% recomendables y casi obligatorias para cualquier usuario ya que lo único que hacen es mejorar la versión sin comprometer sus funcionalidades.

Tercera actualización de Plasma 6.6

No existe Software creado por la humanidad que no contenga errores. Es un hecho incontestable y cuya única solución son las actualizaciones. Es por ello que en el ciclo de desarrollo del software creado por la Comunidad KDE se incluye siempre las fechas de las mismas siguiendo una especie de serie de Fibonacci.

Así que me congratula en presentar que ayer martes 17 de marzo de 2026, una semana después de liberar el código de Plasma 6.6 la Comunidad KDE presenta la tercera actualización de errores.

Más información: KDE

Las novedades generales de Plasma 6.6

Aprovecho para realizar un listado de las novedades generales de Plasma 6.6:

• Nuevo Teclado Virtual: Se estrena «Plasma Keyboard», un teclado en pantalla completamente renovado y mejorado para dispositivos táctiles.
• OCR en Spectacle: La herramienta de capturas de pantalla ahora puede reconocer y extraer texto de las imágenes capturadas.
• Plasma Setup: Un nuevo asistente de configuración inicial que permite crear cuentas de usuario y configurar la red de forma independiente al proceso de instalación del sistema.
• Temas Globales Propios: Ahora puedes convertir tu configuración actual en un «Tema Global» personalizado, que además es compatible con el cambio automático entre modo día y noche.
• Intensidad de color: Posibilidad de ajustar la intensidad del color de los cuadros de las ventanas.
• Selector de emojis: Nuevo selector de tonos de piel para los emojis (Meta + .).
• Conexión por QR: Si tienes una cámara, puedes conectarte a redes Wi-Fi escaneando códigos QR.
• Control de volumen rápido: Puedes ajustar el volumen de una aplicación específica pasando el puntero sobre su icono en el gestor de tareas y usando la rueda del ratón.
• Lista de ventanas: Nueva opción para abrir la lista al pasar el ratón (Open on hover) y filtrado de ventanas por actividad o escritorio.
• Propiedades rápidas: Manteniendo Alt y haciendo doble clic en un archivo del escritorio se abren sus propiedades.
• Filtros para Daltonismo: Se añade un filtro de escala de grises, sumando un total de 4 filtros para diferentes tipos de deficiencia visual.
• Modo de seguimiento en Lupa: Nuevo modo que mantiene el puntero siempre centrado en la pantalla mientras se usa el zoom.
• Mejoras en Wayland: Soporte para «Teclas lentas» (Slow Keys) y ajuste estándar de «Movimiento reducido».
• Escritorios Virtuales: Posibilidad de tener escritorios virtuales solo en la pantalla principal.
• Gestión de Energía: Brillo de pantalla automático para dispositivos con sensores de luz ambiental.
• Gaming: Soporte opcional para usar mandos de juegos como dispositivos de entrada comunes (ratón/teclado).
• Monitor del Sistema: Ahora permite elegir la prioridad de los procesos.
• Animaciones: Mayor fluidez en pantallas con altas tasas de refresco.

Más información: KDE

La entrada Tercera actualización de Plasma 6.6 se publicó primero en KDE Blog.

A repercussão em torno da Lei 15.211/2025 mostrou, mais uma vez, como informação sem fundamento pode ser transformada em histeria coletiva quando quase ninguém se dá ao trabalho de ler o texto original da norma. No lugar da leitura, entrou o impulso por curtidas, engajamento e manchetes apocalípticas. O resultado foi previsível: uma onda de desinformação sobre uma suposta “proibição do Linux no Brasil”.

Nos últimos dias, recebi diversos e-mails e mensagens de pessoas preocupadas com a ideia de que a chamada “Lei Felca” abriria caminho para banir distribuições Linux no país. A narrativa se espalhou com velocidade impressionante, impulsionada principalmente por gente que jamais instalou, administrou ou sequer utilizou GNU/Linux de forma real no dia a dia, mas que se sentiu confortável para decretar o seu “fim” nas redes sociais.

O episódio ganhou ainda mais ruído em 17 de março, quando a distribuição Arch Linux 32 bloqueou o acesso a partir do Brasil. Para quem não conhece, trata-se de um projeto comunitário independente, um fork do Arch Linux tradicional, mantido para oferecer suporte a máquinas antigas com arquitetura de 32 bits (i686). A decisão desse projeto específico foi rapidamente tratada por muita gente como se fosse prova definitiva de que “o Linux havia sido bloqueado no Brasil”, o que evidentemente não corresponde aos fatos.

Falo disso com a tranquilidade de quem leva Linux a sério desde 1998, contribui com projetos open source e participa de palestras e iniciativas voltadas à comunidade. Para mim, usar Linux não é modismo, discurso de rede social ou bandeira ideológica de ocasião. É prática, trabalho árduo e convicção. Por isso, antes de repetir boatos, fui fazer o que quase ninguém fez: Buscar minimamente informações sobre a lei (Paulo Henrique Alkmin fez este trabalho).

A Lei nº 15.211, sancionada em setembro de 2025 e vigente a partir de 17 de março de 2026, institui o chamado Estatuto Digital da Criança e do Adolescente. O apelido “Lei Felca” surgiu em referência ao youtuber cujo vídeo sobre exploração infantil em redes sociais acelerou a tramitação do tema no Congresso. Até aí, tudo bem. O problema começou quando parte do debate público resolveu transformar uma leitura superficial em profecia técnica.

De fato, o Art. 1º estabelece que a lei se aplica a produtos e serviços de tecnologia da informação direcionados a crianças e adolescentes no país, ou com provável acesso por eles. Já o Art. 2º, inciso I, menciona exemplos como aplicações de internet, programas de computador, softwares, sistemas operacionais de terminais, lojas de aplicativos e jogos eletrônicos. Foi justamente a presença da expressão “sistemas operacionais” que bastou para disparar o pânico.

Mas o mais curioso é que a própria lei contém dispositivos que enfraquecem frontalmente a tese de que haveria espaço para uma proibição ampla de Linux ou qualquer outro sistema operacional (Obrigado novamente Paulo Henrique Alkmin ).

O primeiro ponto ignorado por quase todo mundo está no Art. 2º, § 2º, que exclui do escopo da lei as funcionalidades essenciais ao funcionamento da internet, incluindo protocolos e padrões técnicos abertos e comuns. Basta lembrar que o kernel Linux está presente em mais de 96% dos servidores web do mundo para perceber o tamanho do absurdo da narrativa criada. Estamos falando de uma base tecnológica central da infraestrutura global da internet, não de um aplicativo qualquer.

O segundo ponto relevante aparece no Art. 14, parágrafo único. Ali, a lei deixa claro que, independentemente das medidas adotadas por sistemas operacionais e lojas de aplicativos, os fornecedores das próprias aplicações devem implementar mecanismos para impedir o acesso indevido. Em outras palavras: a responsabilidade principal recai sobre a aplicação, não sobre o sistema operacional. Se uma rede social precisa adotar verificação etária, o dever primário é da plataforma. O sistema operacional pode até ter um papel complementar, mas não é o centro da obrigação.

O terceiro ponto, talvez o mais ignorado de todos, está no Art. 37, parágrafo único, que veda regulamentações que resultem em mecanismos de vigilância massiva, genérica ou indiscriminada, além de resguardar explicitamente direitos como liberdade de expressão e privacidade. Bloquear o uso de um sistema operacional inteiro como resposta regulatória seria, justamente, uma medida genérica, indiscriminada e incompatível com esse espírito.

Ou seja: bastariam três trechos da própria lei para desmontar a história do “Linux proibido”. Três dispositivos. No mesmo texto legal. Ainda assim, muita gente preferiu ignorá-los para manter viva a narrativa do caos.

A desinformação se espalhou em dois eixos ao mesmo tempo. De um lado, houve exploração política. De outro, houve um ruído técnico lamentável, inclusive entre pessoas da própria comunidade de tecnologia, que transformaram um “pode impactar discussões futuras” em “vai proibir o Linux”. É sempre mais fácil viralizar com uma frase catastrófica do que ler e interpretar os 37 artigos de uma lei.

Outro argumento que apareceu com frequência foi o de que o GNU/Linux “não teria mecanismos de controle parental” ou que seria incapaz de se adaptar a exigências legais voltadas à proteção de menores. Isso também revela desconhecimento técnico. O ecossistema Linux já dispõe de soluções concretas para esse tipo de necessidade. Há ferramentas como Malcontent, além de repositórios que exigem classificação etária de aplicativos com base no padrão OARS (Open Age Ratings Service). Também existem soluções como o Timekpr-nExT, que permite estabelecer limites diários, semanais e mensais de uso, e o CTparental, que oferece gestão de tempo e controle de conteúdo acessado ou baixado na internet.

Ou seja, além de a tese do “banimento” não se sustentar juridicamente, ela também fracassa tecnicamente. O GNU/Linux não é um ambiente sem recursos, sem governança ou sem capacidade de adaptação. Pelo contrário: justamente por ser aberto, auditável e colaborativo, ele frequentemente consegue responder com mais agilidade e transparência a desafios técnicos do que plataformas fechadas.

E digo mais: Se em algum momento surgisse uma exigência real para integração de verificação etária ou mecanismos complementares dentro do sistema operacional, a própria comunidade open source teria plena capacidade de responder.

Eu mesmo sozinho iria procurar a Serpro ou Gov.BR e implementaria integração com APIs com base de fé pública “e/ou privada” em módulos PAM, se necessário fosse. (exemplo vídeo abaixo). Agora imagine o que aconteceria se toda a comunidade resolvesse atacar o problema de forma coordenada. A chance de o resultado ser tecnicamente melhor do que o de plataformas proprietárias seria enorme.

No fim, esse episódio não fala apenas sobre Linux ou sobre a Lei 15.211/2025. Ele revela algo mais amplo e preocupante: a velocidade com que boatos se tornam “verdades” quando são emocionalmente convenientes. Em vez de leitura, contexto e análise, escolhe-se o pânico performático. Em vez de debate sério, produz-se barulho.

A lição é simples. Antes de decretar o fim do Linux, do software livre ou da internet como conhecemos, vale a pena fazer o básico: ler a lei. Porque, neste caso, o suposto escândalo nasceu muito menos do texto legal e muito mais da preguiça intelectual de quem preferiu acreditar na desinformação.

Use a FORÇA, Leia os fontes
e USE LINUX!

A repercussão em torno da Lei 15.211/2025 mostrou, mais uma vez, como informação sem fundamento pode ser transformada em histeria coletiva quando quase ninguém se dá ao trabalho de ler o texto original da norma. No lugar da leitura, entrou o impulso por curtidas, engajamento e manchetes apocalípticas. O resultado foi previsível: uma onda de desinformação sobre uma suposta “proibição do Linux no Brasil”.

Nos últimos dias, recebi diversos e-mails e mensagens de pessoas preocupadas com a ideia de que a chamada “Lei Felca” abriria caminho para banir distribuições Linux no país. A narrativa se espalhou com velocidade impressionante, impulsionada principalmente por gente que jamais instalou, administrou ou sequer utilizou GNU/Linux de forma real no dia a dia, mas que se sentiu confortável para decretar o seu “fim” nas redes sociais.

O episódio ganhou ainda mais ruído em 17 de março, quando a distribuição Arch Linux 32 bloqueou o acesso a partir do Brasil. Para quem não conhece, trata-se de um projeto comunitário independente, um fork do Arch Linux tradicional, mantido para oferecer suporte a máquinas antigas com arquitetura de 32 bits (i686). A decisão desse projeto específico foi rapidamente tratada por muita gente como se fosse prova definitiva de que “o Linux havia sido bloqueado no Brasil”, o que evidentemente não corresponde aos fatos.

Falo disso com a tranquilidade de quem leva Linux a sério desde 1998, contribui com projetos open source e participa de palestras e iniciativas voltadas à comunidade. Para mim, usar Linux não é modismo, discurso de rede social ou bandeira ideológica de ocasião. É prática, trabalho árduo e convicção. Por isso, antes de repetir boatos, fui fazer o que quase ninguém fez: Buscar minimamente informações sobre a lei (Paulo Henrique Alkmin fez este trabalho o que facilitou este post).

A Lei nº 15.211, sancionada em setembro de 2025 e vigente a partir de 17 de março de 2026, institui o chamado Estatuto Digital da Criança e do Adolescente. O apelido “Lei Felca” surgiu em referência ao youtuber cujo vídeo sobre exploração infantil em redes sociais acelerou a tramitação do tema no Congresso. Até aí, tudo bem. O problema começou quando parte do debate público resolveu transformar uma leitura superficial em profecia técnica.

De fato, o Art. 1º estabelece que a lei se aplica a produtos e serviços de tecnologia da informação direcionados a crianças e adolescentes no país, ou com provável acesso por eles. Já o Art. 2º, inciso I, menciona exemplos como aplicações de internet, programas de computador, softwares, sistemas operacionais de terminais, lojas de aplicativos e jogos eletrônicos. Foi justamente a presença da expressão “sistemas operacionais” que bastou para disparar o pânico.

Mas o mais curioso é que a própria lei contém dispositivos que enfraquecem frontalmente a tese de que haveria espaço para uma proibição ampla de Linux ou qualquer outro sistema operacional (Obrigado novamente Paulo Henrique Alkmin ).

O primeiro ponto ignorado por quase todo mundo está no Art. 2º, § 2º, que exclui do escopo da lei as funcionalidades essenciais ao funcionamento da internet, incluindo protocolos e padrões técnicos abertos e comuns. Basta lembrar que o kernel Linux está presente em mais de 96% dos servidores web do mundo para perceber o tamanho do absurdo da narrativa criada. Estamos falando de uma base tecnológica central da infraestrutura global da internet, não de um aplicativo qualquer.

O segundo ponto relevante aparece no Art. 14, parágrafo único. Ali, a lei deixa claro que, independentemente das medidas adotadas por sistemas operacionais e lojas de aplicativos, os fornecedores das próprias aplicações devem implementar mecanismos para impedir o acesso indevido. Em outras palavras: a responsabilidade principal recai sobre a aplicação, não sobre o sistema operacional. Se uma rede social precisa adotar verificação etária, o dever primário é da plataforma. O sistema operacional pode até ter um papel complementar, mas não é o centro da obrigação.

O terceiro ponto, talvez o mais ignorado de todos, está no Art. 37, parágrafo único, que veda regulamentações que resultem em mecanismos de vigilância massiva, genérica ou indiscriminada, além de resguardar explicitamente direitos como liberdade de expressão e privacidade. Bloquear o uso de um sistema operacional inteiro como resposta regulatória seria, justamente, uma medida genérica, indiscriminada e incompatível com esse espírito.

Ou seja: bastariam três trechos da própria lei para desmontar a história do “Linux proibido”. Três dispositivos. No mesmo texto legal. Ainda assim, muita gente preferiu ignorá-los para manter viva a narrativa do caos.

A desinformação se espalhou em dois eixos ao mesmo tempo. De um lado, houve exploração política. De outro, houve um ruído técnico lamentável, inclusive entre pessoas da própria comunidade de tecnologia, que transformaram um “pode impactar discussões futuras” em “vai proibir o Linux”. É sempre mais fácil viralizar com uma frase catastrófica do que ler e interpretar os 37 artigos de uma lei.

Outro argumento que apareceu com frequência foi o de que o GNU/Linux “não teria mecanismos de controle parental” ou que seria incapaz de se adaptar a exigências legais voltadas à proteção de menores. Isso também revela desconhecimento técnico. O ecossistema Linux já dispõe de soluções concretas para esse tipo de necessidade. Há ferramentas como Malcontent, além de repositórios que exigem classificação etária de aplicativos com base no padrão OARS (Open Age Ratings Service). Também existem soluções como o Timekpr-nExT, que permite estabelecer limites diários, semanais e mensais de uso, e o CTparental, que oferece gestão de tempo e controle de conteúdo acessado ou baixado na internet.

Ou seja, além de a tese do “banimento” não se sustentar juridicamente, ela também fracassa tecnicamente. O GNU/Linux não é um ambiente sem recursos, sem governança ou sem capacidade de adaptação. Pelo contrário: justamente por ser aberto, auditável e colaborativo, ele frequentemente consegue responder com mais agilidade e transparência a desafios técnicos do que plataformas fechadas.

E digo mais: Se em algum momento surgisse uma exigência real para integração de verificação etária ou mecanismos complementares dentro do sistema operacional, a própria comunidade open source teria plena capacidade de responder.

Eu mesmo sozinho iria procurar a Serpro ou Gov.BR e implementaria integração com APIs com base de fé pública “e/ou privada” em módulos PAM, se necessário fosse. (exemplo vídeo abaixo). Agora imagine o que aconteceria se toda a comunidade resolvesse atacar o problema de forma coordenada. A chance do resultado ser tecnicamente melhor comparado as plataformas proprietárias seria enorme.

No fim, esse episódio não fala apenas sobre Linux ou sobre a Lei 15.211/2025. Ele revela algo mais amplo e preocupante: a velocidade com que boatos se tornam “verdades” quando são emocionalmente convenientes. Em vez de leitura, contexto e análise, escolhe-se o pânico performático. Em vez de debate sério, produz-se barulho.

A lição é simples. Antes de decretar o fim do Linux, do software livre ou da internet como conhecemos, vale a pena fazer o básico: ler a lei. Porque, neste caso, o suposto escândalo nasceu muito menos do texto legal e muito mais da preguiça intelectual de quem preferiu acreditar na desinformação.

Use a FORÇA, Leia os fontes
e USE LINUX!