Mostrando postagens com marcador kernel. Mostrar todas as postagens
Mostrando postagens com marcador kernel. Mostrar todas as postagens

BigLinux cria o projeto Big-kernel

 

 Depois que a equipe BigLinux corrigiu bugs no driver de vídeo da Intel (que foi aprovado no dia 24 de Setembro), a equipe BigLinux criou o projeto Big-kernel.

 A ideia é construir uma versão otimizada do kernel Linux utilizando as bases de configurações originadas do kernel do Manjaro (que já são utilizadas pelo BigCommunity), correções desenvolvidas pela própria comunidade BigLinux e recursos de terceiros que oferecem ganhos. Os recursos em questão são o BORE CPU scheduler, o POC idle CPU selector, ADIOS I/O scheduler, os pacthes enviados pelo Tales e o compilador LLVM/Clang com suporte a ThinLTO e AutoFDO. Todas as configurações do Manjaro necessárias para desktops são mantidas sendo apenas adicionados os recursos mencionados além dos patches desenvolvidos pela própria comunidade BigLinux.

 O objetivo é oferecer um kernel com máximo desempenho possível. O que eu particularmente acho interessante em um projeto como este é que, desta forma, a comunidade BigLinux pode disponibilizar para sua base de usuário todas as melhorias feitas muito antes de serem disponibilizadas em outros projetos. Como é o caso desta correção do driver de vídeo da Intel que só estará disponível a partir da versão 7.4 e os usuários de BigLinux já usufruíam deste benefício desde o kernel 7.2.

 O processo de instalação, seja via repositório ou construção manual e como atualizar o kernel estão todas descritas na própria documentação do projeto.  O pacote Linux-Big está disponível sob licença MIT; já os patches estão disponível sob licença GPLv2



QUER APRENDER LINUX? ENTÃO CONFIRA O MEU CURSO DE MIGRAÇÃO PARA LINUX CLICANDO AQUI :)
QUER APRENDER LINUX? ENTÃO CONFIRA O MEU CURSO DE MIGRAÇÃO PARA LINUX CLICANDO AQUI :)


Equipe BigLinux corrige bug em driver de vídeo da Intel



 Em Julho de 2026, o engenheiro de software da equipe BigLinux, Tales Mendonça que também é um dos autores do livro Shell Linux – Do Aprendiz ao Administrador (que eu em particular possuo um exemplar deste autografado pelo próprio Tales e pode ser conferido clicando aqui), descobriu um bug no driver de vídeo do kernel XE da Intel. Em depoimento, o Tales me disse o seguinte:

"Em Março eu comprei um computador da Asus que foi lançado em Fevereiro deste ano e resolvi utilizar o driver XE mantido pela Intel. Este driver estava bem ruim, cheio de bugs que levavam meu computador a travar várias vezes ao dia. Eu fui aos poucos consertando as coisas; mesmo assim, passados dois ou três dias, meu computador travava novamente e era necessário reiniciá-lo. Então eu escrevi alguns patches de correções, entrei para a lista do driver XE, conversei com um dos engenheiros da Intel e enviei meus patches. Hoje, depois destas atualizações, meu computador fica ligado por vários dias sem a mínima necessidade de reinicialização e não apresenta mais nenhum dos problemas conhecidos. Ainda fiz mais algumas correções que me foram solicitadas pelos engenheiros do kernel."

 Foram enviados mais de doze patches para a Intel; alguns foram aceitos no kernel e outros não e serão disponibilizados em breve dentro da versão do 7.1. Graças a este trabalho, agora o Tales faz parte da equipe para continuar o desenvolvimento do driver XE. "vou conseguir resolver mais um bug que a Intel tem" me informou Tales. 

Você pode acompanhar todo o processo todos clicando aqui

 Esta não é a única contribuição significativa já feita pela comunidade BigLinux; a equipe já enviou patches para outros projetos e distribuições além de possuir vários recursos próprios. Vou finalizar este artigo por aqui, mas vou deixar uma live do pessoal do BigLinux que eles participaram no canal. Forte abraço e até a próxima: 



QUER APRENDER LINUX? ENTÃO CONFIRA O MEU CURSO DE MIGRAÇÃO PARA LINUX CLICANDO AQUI :)
QUER APRENDER LINUX? ENTÃO CONFIRA O MEU CURSO DE MIGRAÇÃO PARA LINUX CLICANDO AQUI :)

Vulnerabilidades de Copy Fail, Dirty Frag e Fragnesia no kernel Linux

Copy Fail, Dirty Frag, and Fragnesia kernel vulnerabilities

Vulnerabilidades de Copy Fail, Dirty Frag e Fragnesia no kernel Linux


 No dia 19 de Maio a equipe Gentoo Linux postou em seu site oficial que Linux está enfrentando uma série de vulnerabilidades no kernel Linux conhecidas como Copy Fail, Dirty Frag e Fragnesia. Estas vulnerabilidades permitem escalar privilégio de administrador na maioria das distribuições Linux como pode ser conferido no vídeo abaixo criado por Hyunwoo Kim (mais conhecido como v4bel) que é um pesquisador de vulnerabilidades independente, ganhador dos prêmios Pwn2Own Berlin de 2025 e 2026, Google kernelCTF 0-day e Pwnie Awards 2025 e foi quem reportou a vulnerabilidade Dirty Frag:


 Vale a ressalva que estas foram as distribuições testadas, mas pode afetar quase todas. Como Dirty Frag é um bug de lógica determinística, esse bug não depende de janela de tempo, não é obrigatória, não é gerado kernel panic quando o exploit falha e a taxa de sucesso é alta.

 A primeira vulnerabilidade descoberta é o Copy Fail que mostra que qualquer kernel desenvolvido desde 2017 pode ser afetado necessitado apena um usuário sem privilégio, não necessita de acesso a rede, ou recursos de debug ou outra ferramenta explorando apenas recursos do kernel como a crypto API (AF_ALG) que vem habilitada por padrão:


 E por ultimo temos o Fragnesia (CVE-2026-46300) que é uma vulnerabilidade da mesma clase do Dirty Frag que recebeu score de 7.8 e foi descoberto por William Bowling em conjunto com a equipe da V12. O Fregnesia recebeu seu próprio patch na lista da OpenWall e utiliza o mesmo sistema de mitigação do Dirty Frag:


Lançado LKRG 0.9.9

[lkrg-users] LKRG 0.9.9

Lançado LKRG 0.9.9


 Alexander da empresa OpenWall anunciou no dia 23 de Outubro a versão 0.9.9 do LKRG (Linux Kernel Runtime Guard) que é um módulo que realiza a verificação de integridade e detecção de vulnerabilidades de segurança do kernel Linux em tempo real. Trata-se de realmente um módulo e não um patch, então não é necessário aplicar patch ao kernel para depois compilá-lo.

 Neste novo lançamento o LKGR houveram muitas mudanças de código que passou a ter suporte ao kernel 6.11, ao 6.10.10, ao 5.10.220 e ao 5.14.0-470.el9 da nova versão do CentOS Stream 9 e além (RHEL 8 - 9.5 e AlmaLinux 8 - 9) que teve a sua chave SIG/Security yum/dnf atualizada para os repositórios (https://sig-security.rocky.page); suporte a CONFIG_JUMP_LABEL batch mode para ARM64; pCFI: Atualização do Frame pointer não está na pilha ao ALERT com enforcement; simplificação a validação seccomp (deve usar portabilidade para mais kernel builds).


Baixe a versão do lkrg no site ofcial


QUER APRENDER LINUX? ENTÃO CONFIRA O MEU CURSO DE MIGRAÇÃO PARA LINUX CLICANDO AQUI :)
QUER APRENDER LINUX? ENTÃO CONFIRA O MEU CURSO DE MIGRAÇÃO PARA LINUX CLICANDO AQUI :)

Lançado novo Minicurso de atributos no Linux
E não esqueçam de conferir também o meu mini curso de atributos no Linux

Acelerando o desenvolvimento do Kernel com virtme-ng

Speeding Up Kernel Development With virtme-ng

Acelerando o desenvolvimento do Kernel com virtme-ng

 Foi anunciado pela Linux Foundation que Andrea Righi que trabalhava para a Canonical e agora trabalha como engenheiro de software da NVIDIA (especializado em sistemas operacionais, virtualização e analise de desempenho) irá apresentar no dia 02 de Novembro o Webinar sobre o virtme-ng, uma ferramenta que rapidamente constrói e executa kernels dentro de um snapshot virtualizado em seu sistema live.

 Andrea demonstra que grande parte do processo de desenvolvimento do kernel é geralmente dedicado a instalá-lo, rebootar o sistema, testá-lo, debuga-lo, coletar resultados e repetir essa mesmo operação que é muito lento e desgastante.

 O virtme-ng fornece uma base para bootar o kernel recompilado ou qualquer outra imagem do kernel dentro de um ambiente copy-on-write virtualizado no sistema atual. O virtme-ng é escrito na maior parte em Python e faz uso de ferramentas como QEMU ou KVM, virtiofs, e overlayfs para esta finalidade.


 A ideia é simplificar o trabalho dos desenvolvedores do kernel criando um sendbox para teste que ofereça desempenho próximo do ambiente real sem a necessidade de um ambiente de teste. Nesse Webinar será demonstrado como utilizar o virtme-ng com exemplos práticos e cenários reais.


Clique aqui para se registrar do evento da linuxfoundation.org

GitHub do virtme-ng

Mais sobre o virtme-ng pode ser lido no LWN.net


QUER APRENDER LINUX? ENTÃO CONFIRA O MEU CURSO DE MIGRAÇÃO PARA LINUX CLICANDO AQUI :)
QUER APRENDER LINUX? ENTÃO CONFIRA O MEU CURSO DE MIGRAÇÃO PARA LINUX CLICANDO AQUI :)
Lançado novo Minicurso de atributos no Linux
E não esqueçam de conferir também o meu mini curso de atributos no Linux

nmbl: Um substituto ao GRUB

nmbl: Não precisamos de um carregador de boot

No dia 15 de Julho, Marta Lewandowska da Red Hat, apresentou no DevConf 2024 realizado na República Tcheca um novo esquema para substituir o carregador de boot GRUB por uma solução mais segura e mais rápida. Apesar do GRUB possuir suporte à uma variedade de arquiteturas, de sistemas operacionais e de recursos, estes recursos geram complexidade muito grande para mantê-los. Exemplo disso é que existe uma serie de vulnerabilidades encontradas no GRUB desde 2021 e que não há previsão de solução devido o tamanho desta complexidade.

GRUB CVEs
Vulnerabilidades do GRUB

 Já que a base de desenvolvedores do kernel é muito maior e beneficia todo um ecossistema com rápido desenvolvimento de recursos e rápida resposta a correções de vulnerabilidades, a ideia é apresentar uma solução para estes problemas utilizando o kernel Linux como seu próprio bootloader. Essa solução é chamada o nmbl (pronuncia-se nimble e é a abreviação de no more boot loader), uma imagen unificada do kernel Linux (UKI) que contem kernel command line, o initramfs que é um arquivo formatado com o filesystem ExFAT que contendo lá dentro drivers, comandos e scritps (mostrei isso no artigo E quem em sã consciência ainda utiliza Ext2? Quase todo mundo :V) e efi stub (systemd-stub) e um menu parecido com o GRUB além de drivers, filesystem, rede e duplicação de código que ocorre no GRUB é evitado. Tudo o que é necessário para o carregamento do sistema operacional.

Fedora being booted by nmbl
Fedora sendo inicializado pelo nmbl

 Há duas variantes disponíveis do nmbl sendo uma que carrega diretamente o kernel e outra que permite executar outro kernel passando pelo UEFI (já que o nmbl oferece a opção de carregar diferentes versões do kernel). A IBM demonstrou interesse no nmbl e em breve poderemos ter o nmbl disponível para outras arquiteturas.

Two variants of nmbl
Duas variantes do nmbl


 Ainda há bastante trabalho a ser feito; a Marta descreve muito mais detalhes sobre o nmbl em seu blog que futuramente estará no Fedora Planet.


O código fonte do nmbl está disponível no GitHub da Red Hat para baixar e testar (feedbacks são bem vindo para a equipe da Marta)


QUER APRENDER LINUX? ENTÃO CONFIRA O MEU CURSO DE MIGRAÇÃO PARA LINUX CLICANDO AQUI :)
QUER APRENDER LINUX? ENTÃO CONFIRA O MEU CURSO DE MIGRAÇÃO PARA LINUX CLICANDO AQUI :)

Lançado novo Minicurso de atributos no Linux
E não esqueçam de conferir também o meu mini curso de atributos no Linux


Qual a diferença entre Low Latency e Real-Time no Linux?

Qual a diferença entre Low Latency e Real-Time no Linux?

Qual a diferença entre kernel Low Latency e kernel Real-Time no kernel Linux?


 Com o lançamento do Ubuntu vindo com kernel real-time, surgiu em minha ultima live a duvida na diferença entre kernel Low Latency e kernel Real-Time no Linux. E se trata de uma pergunta muito interessante já que ambos proporcionam performance. Então, o que diferencia um do outro? Aqui vamos nós tentar explicar. 
Primeiro, o que temos que entender é que ambos são real-time. Como já dito, ambos foram desenvolvidos para proporcionar melhor performance, porém, com características e propostas diferentes. Vamos então entender primeiro o que é o real-time.

Kernel real-time

 O kernel real-time visa garantir o máximo de resposta dentro do menor tempo possível. De acordo com a documentação do RHEL8, "em muitas cargas de trabalho, o ajuste completo do sistema melhora a consistência dos resultados em cerca de 90%." ... "Ajustar o kernel padrão produzirá 90% dos possíveis ganhos de latência. O kernel Real Time fornece os últimos 10% de redução de latência exigida pelas cargas de trabalho mais exigentes."


 Mas há um problema com o real-time. O kernel real-time pode acabar sacrificando o rendimento e a eficiência energética. Na mesma documentação da Red Hat descreve que "Há alguma sobrecarga adicional do kernel associada ao kernel real-time. Isto se deve principalmente ao tratamento de interrupções de hardware em threads agendados separadamente. O aumento da sobrecarga em algumas cargas de trabalho resulta em certa degradação no rendimento geral. A quantidade exata depende muito da carga de trabalho, variando de 0% a 30%".

Kernel Low Latency

 Já o kernel low latency tem como propósito priorizar as tarefas mais sensíveis e minimizar o tempo que os processos são executados (essa é a ideia de low latency – reduzir o tempo de resposta). De certa forma, low letancy acaba tendo o desempenho um pouco menor, porém, tendo melhor garantia. O kernel low latency é ideal para quem quer trabalhar com aplicações multimédia, jogos, entre outras, mesmo consumindo mais energia que o kernel genérico. Para se ter uma ideia do ganho de performance com o kernel low latency e da garantia de eficiência de energia, é que ele é utilizado até mesmo em embarcados.

Conclusão

 O kernel low latency também é real-time assim também como o kernel real-time também é low latency (ambos focam em performance) e isso pode inicialmente confundir a cabeça das pessoas. Porém, apesar do proposito de ambos ser o mesmo, cada um foi projetado com propostas diferentes, o que acabou por definir a distinção. Se você precisa de performance sem sacrificar eficiência energética, o kernel low latency é a melhor opção enquanto o kernel real-time serve mais para ambientes críticos onde o tempo faz toda a diferença. Já eficiência energética e calor gerado por isso acabam não sendo o problema sendo que esses ambientes são refrigerados.

 Quero aproveitar e indicar o projeto tuned que permite otimizar seu computador para obter melhor desempenho através de seus recursos como latency-performancy ou network-latency, permite otimizar seu desktop, para uso de streaming e muito mais.


O comando tuned-admin
O comando tuned-admin


A lista de recursos do tuned
A lista de recursos do tuned

Novo driver DRM sendo desenvolvido na linguagem Rust

C U B E It works!!!! It doesn't display on HDMI because something is wrong with kmsro but it works!!!! It renders!!! A spinning cube!!! From my Rust driver on Linux!!!!!!!!!

Novo driver DRM sendo desenvolvido na linguagem Rust


 Em Julho o desenvolvedor da distribuição Asahi Linux Postou que estava portando Linux para Apple ARM M2 e está tendo grande exito. Até mesmo Linus está utilizando seus patches no Fedora. Agora ficamos sabendo que uma desenvolvedora de Tókio conhecida como Asahi Lina postou em seu Twitter que está desenvolvendo um novo driver DRM (Direct Rendering Manager) escrito na linguagem Rust para o apple M2. Por ora Asahi Lina informou que esse driver não exibe imagem em HDMI devido a algo de errado com o kmsro mas que está funcionando e está conseguindo renderizar cubo que vocês viram no inicio deste artigo.


QUER APRENDER LINUX? ENTÃO CONFIRA O MEU CURSO DE MIGRAÇÃO PARA LINUX CLICANDO AQUI :)
QUER APRENDER LINUX? ENTÃO CONFIRA O MEU CURSO DE MIGRAÇÃO PARA LINUX CLICANDO AQUI :)


Lançado LKRG 0.9.5

[lkrg-users] LKRG 0.9.5

Lançado LKRG 0.9.5

 Alexander da OpenWall anunciou o lançamento da versão 0.9.5 do LKRG. LKGR (Linux Kernel Runtime Guard) é um módulo que realiza a verificação de integridade e detecção de vulnerabilidades de segurança do kernel Linux em tempo de execução. Trata-se de realmente um módulo e não um patch, então não é necessário aplicar patch ao kernel para depois compilá-lo.

 A tese de mestrado Juho Junnila entitulada "Effectiveness of Linux Rootkit Detection Tools"  demonstra o LKGR como uma das ferramentas de detecção mais efetivas (isso porque ainda nem atingiu a versão 1.0. Imagina se tivesse).

 Esta versão tem como novidade o suporte a LTS do kernel 5.10 e o retrabalho no suporte ao sistema de arquivos OverlyFS que é utilizado pelo Docker e para garantir o suporte a várias versões do kernel Linux. Testes foram realizados com a versão 5.19 e funcionaram bem. O LKGR está disponível para as arquiteturas X86 e ARM (ambas de 32 e 64 bits). Todas as mudanças podem ser conferidas clicando aqui.


Kernel Linux ganhará mais desempenho em breve

Linux Kernel will gain better performance soon

Kernel Linux ganhará mais desempenho em breve


 Quando o assunto é desempenho, Linux é o melhor sistema operacional. E antes que surjam fanboys me chamando de fanboy, Linux se torna a base de referencia quando algum projeto ou empresa quer ou precisa analisar o real desempenho de outros sistemas operacionais. No History do site de DragonflyBSD é descrito que de uma perspectiva de desempenho, o único competidor real do DragonflyBSD é o Linux. Já no meu artigo 3 sistemas operacionais que não são escritos na linguagem C, o sistema operacional JX que é desenvolvido em Java, analisou o seu desempenho tendo Linux como comparativo. Brendan Gregg, um dos mestres na arte de performance e que escreveu algoritmos que melhoraram o desempenho do Solaris, descreve que, out of the box, Linux é mais rápido.

Comparando o desempenho do JX vs Linux
Comparando o desempenho do JX vs Linux

 AQUI VAI UMA CONSIDERAÇÃO MUITO IMPORTANTE

 A análise relacionada a performance é algo que oscila muito. Brendan Gregg mesmo ressalva que o desempenho de um sistema operacional depende do workload e que essas diferenças podem oscilar entre 5% á 5 vezes mais. Através de análises e configurações, Brendan conseguiu colocar o SmartOS (fork do Solaris) para ter melhor desempenho que o Linux e conseguiu também o mesmo feito ao contrário.

 Em uma análise de jogos por exemplo, por várias vezes no passado eu mencionei que, mesmo que o Windows não possuísse o desempenho e qualidade tão bom quanto a do Linux, seu desempenho em jogos era muito melhor devido o emprego do DirectX. Eu ainda mantenho essa mesma afirmação se compararmos DirectX vs OpenGL. Porém, com o surgimento do Vulkan, esse quadro tem mudado bastante; a diferença de desempenho entre Windows+DirectX vs Linux+vulkan é bem baixa em favor do Windows e depois do surgimento do DXVK (DiretcX to Vulkan) que favorece muito os usuários de Linux rodar jogos do Windows sem a necessidade de ports, muitos dos desenvolvedores já mostraram que é possível rodar os jogos do Windows no Linux com o desempenho bem melhor do que no próprio Windows.


 Se o DXVK já apresenta melhor desempenho no Linux do que no próprio Windows, a tendencia natural é ser ainda melhor uma vez que a própria Microsoft disponibilizou uma versão de DirectX para Linux e a NVidia também disponibilizou um driver open-source para Linux. A própria Apple melhorou o desempenho do MacOSX Ventura para jogos através do framework MetalFX.

 Esclarecido os detalhes sobre desempenho, agora vamos a o que importa neste artigo. No dia 21 de Junho foi publicado uma série de patches que irão melhorar ainda mais o desempenho do kernel Linux. Esses patches fazem exploram o recurso CC_OPTIMIZE_FOR_PERFORMANCE_O3, ou simplesmente -O3. O -O3 vai estar desntro do arquivo Kconfig ou podendo compilar o kernel Linux com a opção make KCFLAGS=-O3.

 Não necessariamente se trata de um novo recurso, as opções de otimização já estão presentes nos compiladores GCC e LLVM/Clang há algum tempo. Como pode ser conferido nas imagens abaixo, eu já o utilizo na compilação do bc do Gavin Howard; pode ser conferido no GCC digitanto gcc --help=optimizers e na manpage do LLVM/Clang (man 1 clang em Code Generation Options)

Configuração do bc com a opção -O3
Configuração do bc com a opção -O3

gcc --help=optimizers
gcc --help=optimizers

Clang optimization with -O options
otimização do código com o clang -O e a opção desejada

 O kernel Linux já utiliza tal recurso, porém a opção -O2 por padrão e no meu artigo Redução do kernel Linux e do filesystem para IoT é apresentado a opção -Os para a otimização de tamanho (optimize for size, uma das opções que podemos escolher). O LLVM ainda apresenta a opção -O4 que é bem parecido com o -O3 e nas duas imagens abaixo eu mostro que compilei o bc com esta opção.

Configuring Gavin Howard's bc with -O4 option
Configurando o bc de Gavin Howard com a opção -O4

-O4 during bc compiling process
-O4 durante o processo de compilação do bc

 Por volta de 2019, já haviam tentado implementar a otimização -O3 no kernel Linux, mas havia sido rejeitado por Linus Torvalds devido o código que havia sido enviado não ser confiável o suficiente. Hoje, depois de passarem por revisão e melhorias, tais patches começam a ser aceitos e apesar de ainda estarem em estágio beta, o site Phoronix realizou um benchmark que mostram serem promissores. Vamos torcer

CONCLUSÃO

 É possível melhorar ainda mais o desempenho em todo o sistema operacional Linux, e não somente em seu kernel. Particularmente, eu tenho uma ideia do desenvolvimento de uma distribuição que tem como um dos princípios melhorar ainda o desempenho de todo o sistema operacional (não com o mesmo argumento de muitas distribuições surgem "essa é uma distribuição estável, segura e com alto desempenho" mas que na prática não oferece nada demais). Essa não seria sua unica característica, mas um de seus princípios. Quem sabe no futuro? Pode ser que até lá alguém já faça isso no meu lugar, pessoas podem acabar tendo a mesma ideia mesmo não sendo expressadas. Se até lá alguém fizer me poupará muito tempo.

Marcadores

A pior história sobre Linux que já ouvi (6) A.I (2) ambiente gráfico (19) AMD (14) analise (10) Andriod (17) android (9) Apple (1) arm (5) artigo (5) aws (1) bc (24) benchmark (6) BetrFS (1) biglinux (1) blackhat (1) BSDs (36) btrfs (32) bugs (2) Caixa de Ferramentas do UNIX (18) canonical (1) canto do Diego Lins (2) certificações Linux (7) Código Fonte (53) comandos (34) comp (1) compressores (9) consoles (1) container (8) CPU (20) cracker (1) criptografia (5) crowdfunding (9) cursos (24) daemons (14) Debian (31) desempenho (2) desenvolvimento (105) desktop (19) DevOps (3) DevSecOps (4) dic (1) Dica de leitura (91) dica DLins (2) dicas do Flávio (27) Dicas TechWarn (1) diet libc (4) diocast (1) dioliunx (3) distribuições Linux (15) Docker (13) DragonflyBSD (24) driver (2) dropbear (3) ead Diolinux (2) edição de vídeo (5) embarcados (1) EMMI Linux (4) emuladores (9) endless (5) English interview (3) Enless OS (2) entrevista (17) espaço aberto (82) evento (6) facebook (1) Fedora (11) filesystem (82) financiamento coletivo (2) fork (4) fox n forests (4) FreeBSD (23) Funtoo Linux (13) games (96) garbage collector (1) gerenciadores de pacotes (4) glaucus (8) GOG (3) google (9) gpu (4) hacker (2) hardware (104) hash (1) helenos (3) I.A (1) init system (13) Intel (16) inteligencia artificial (2) IoT (1) ispconfig (1) jogos (40) kde (1) kernel (144) lançamento (64) leis (1) LFCS (1) libs (2) licenças (10) Linus (16) linus torvalds (2) Linux (196) linux foundation (3) linux para leigos (1) live (4) lkgr (1) LPI (8) LTS (1) Mac (1) machine learning (1) matemática (9) mesa redonda (27) microcontroladores (1) microsoft (6) microst (1) muito além do GNU (183) musl (3) não viva de boatos (9) navegadores (5) NetBSD (7) newlib (1) nim (13) nimlang (5) nintendo (2) novatec (17) novidades (1) nuvem (1) o meu ambiente de trabalho (3) off-topic (12) ONLYOFFICE (5) open source (85) OpenBSD (8) OpenShift (1) oracle (1) os vários sabores de Linux (46) padrim (2) palestras e eventos (5) partições (6) pentest (8) performance (1) pipewire (1) plan9 (3) playstation (1) processadores (30) professor Augusto Manzano (11) Programação (72) promoção (1) propagandas com Linux (8) ps4 (1) real-time. (1) Red Hat (23) redes (4) resenha nerd (5) Resumo da Semana do Dlins (2) resumo do Tux (19) retrospectiva Linux (1) risc-V (14) RISCV (13) rtos (2) runlevel (2) rust (16) Sega (1) Sega Saturn (1) segurança digital (28) servidor web (2) servidores (3) shell (13) shell script (10) sistema operacional (26) skarnet (2) smartphones (3) Software livre e de código aberto (150) sorteio (3) Steam (11) Steam no Linux (9) supercomputadores (4) suse (7) systemd (9) terminal (91) terminal de comandos (22) toca do tux (1) toybox (32) tutorial (6) Tux (3) ubuntu (1) unboxing (7) UNIX (17) UNIX Toolbox (13) vartroy (1) vga (1) virtualização (3) vulnerabilidade (7) wayland (5) web (1) whatsapp (1) whitehat (1) Windows Subsystem for Linux (2) wine (14) WoT (1) yash (1) ZFS (16) zsh (3)