A farsa "Linux é apenas o kernel"

A farsa por trás do termo "Linux é somente o kernel": A verdade que não te contam sobre isso

 Por quase três décadas vem sendo propagado aos quatro cantos do mundo a vaga informação:

"O nome do sistema operacional não é Linux, Linux é somente o kernel do sistema operacional e somente com o kernel você não faz nada. As ferramentas do sistema operacional são do projeto GNU. Então, o nome correto é GNU/Linux."

 Ou postam em todos os lugares o estafante texto de autoria de Ricahrd Stallman:

"...Eu gostaria intervir por um momento. O que você está se referindo como Linux, é de fato, GNU/Linux, ou como eu recentemente passei a chamar, GNU mais Linux. Linux não é um sistema operacional em si..." ... "....Linux é o kernel: O programa no sistema que aloca recursos da máquina para outros programas que você executa. O kernel é uma parte essencial de um sistema operacional, mas inútil por si só..."

 Agora a moda da vez é dizer "GNU com ou sem Linux"... Patéticos... Estranho é que eu percebi que passaram a utilizar este argumento depois que mencionei no meu vídeo Linux ou GNU/Linux? Eis a questão que "no meu canal eu trato de Linux com ou sem GNU". Simplesmente pegaram a mesma frase inverteram, mas eu duvido que eles vivam sem Linux:

 Eu até poderia escrever pelo menos mais dois ou três artigos debatendo ponto por ponto desta frase, mas o meu foco aqui será unicamente no trecho "Linux é apenas o kernel". Então, bora!

Linux: mais do que o kernel do sistema operacional

 Linux surgiu como um pequeno e singelo kernel, com apenas um conjunto de drivers que Linus portou de seu emulador de terminal que havia desenvolvido como aprendizado, o suporte a hardware era limitado, travava quando atingia o limite máximo de memória e estes são apenas alguns dos problemas que Linux enfrentava. No final da descrição da licença do kernel 0.01 (que nesta ocasião ainda era regido sob a licença da convenção de Berna do século XIX) o próprio Linus Torvalds afirmou na época que:

 "Infelizmente, um kernel por si só não te leva a lugar algum. Para se ter um sistema funcional você precisa de um shell, compiladores, uma biblioteca e etc. Essas são partes separadas e muitas estão sob uma licença rigorosa (ou mesmo mais flexível). A maioria das ferramentas utilizadas com Linux são software do GNU e estão sob a GNU copyleft."

 Não somente em sua licença como também no arquivo README Linux—a free unix-386 kernel, especificamente em Coisas faltando/incompletas no Linux (Things missing/incomplete in Linux) é descrito que:

"Nenhum dos importantes comandos de administração do sistema ainda foram escritos para Linux. Estes incluem coisas como mkfs, format, fsck, mknod e etc. Alguns destes precisam de recursos do kernel ainda não implementados (format, mknod), alguns precisam apenas serem escritos. Assim como a biblioteca, eu aceitaria quaisquer arquivos distribuíveis livremente."

  Se o desenvolvimento do Linux tivesse parado por aqui, estaria correto afirmar que Linux era apenas um kernel, mas este argumento foi válido somente até a versão 0.10, pois a partir do kernel 0.11, lançado no dia 19 de Dezembro de 1991 (apenas quatro meses após seu nascimento), surgiram os primeiros comandos do Linux fidsk, mkfs e fsck desenvolvidos pelo próprio Linus Torvalds para tornar Linux self-hosting já que acidentalmente Linus havia discado a partição do Minix ao invés de seu modem destruindo completamente a partição do Minix:

Linus relatando sobre a criação dos comandos mkfs/fsck/fdisk para o kernel 0.11

 Menos de um mês depois, foi lançado o kernel 0.12 com mais comandos como o mkswap, pois nesta versão originou-se o suporte a memória virtual no Linux, também chamado paginação de disco ou paginação de memória (Memory paging ou disc paging em inglês). A ideia surgiu quando um alemão contatou Linus perguntando como utilizar o GCC no Linux já que ele possuía apenas 2MB de RAM e era a exata quantidade exigida para executar o GCC. Foi aí que durante três dias Linus trabalhou no desenvolvimento da paginação de disco, vindo a concluí-la no dia 25 de Dezembro de 1991. Isso foi uma revolução no Linux pois não era um qualquer sistema operacional possuía suporte a memória virtual. Daí em diante as pessoas pararam de comparar Linux ao Minix e passaram a compará-lo ao Coherenlt que foi o primeiro clone do Unix na história:

Nota de lançamento do kernel 0.12 descrevendo o comando mkswap adicionado ao mkfs

 A maioria dos comandos desenvolvidos por Linus Torvalds ainda estão presentes nas distribuições e também deram origem a outros pacotes como o util-Linux, o e2fsprogs e o busybox. Hoje em dia, a maioria dos comandos nas distribuições são do próprio Linux:

Comandos de autoria do Linus Torvalds no util-linux

Comandos de autoria do Linus Torvalds no busybox

Design and Implementation of the Second Extended Filesystem

Comando badblocks de autoria de Linus Torvalds no pacote e2fsprogs

Linus Torvalds também contribuiu para o comando route

 A partir da versão 0.11 Linux passou de um simples, pequeno e inacabado kernel a um kernel self-hosting contendo os recursos e comandos necessários para a sua administração do sistema, quebrando assim o ciclo do README do kernel 0.01. Mas a comunidade Linux não parou por aí e vocês verão a seguir como a partir destes recursos, a comunidade Linux o evoluiu para um sistema operacional.

 Fato curioso é que Linus havia perdido interesse em continuar o desenvolvimento do Linux até ocorrer o acidente com o Minix. Já pensou se isso não tivesse acontecido ?

 Só com um kernel e as ferramentas do projeto GNU, você não consegue fazer porcaria nenhuma já que o GNU não possui metade das ferramentas necessárias para se ter um sistema operacional.

A evolução do Linux

 Surgiu então a primeira comunidade Linux composta por membros da comunidade Minix. Hoje a comunidade Linux é composta por indivíduos, organizações, instituições governamentais, acadêmicas  e empresariais do mundo todo.

 Sua gigantesca comunidade não o limitou a simplesmente um kernel com comandos e passou a transforma-lo em um verdadeiro sistema operacional desenvolvendo todos os tipos de recursos necessários para isso além de portar ferramentas de outros Unix para Linux (sim, Linux também é um Unix. Aliás, Linux é mais do que um Unix) e receber suporte de outros projetos como é o caso do comando file (que eu não faço ideia de onde o projeto GNU tirou que pertence a eles) e o Shadow. Exemplos de pacotes e comandos do próprio Linux são o at, o Batch (que é uma parte do at), o Linux PAM, o Procps, o Psmisc, o Util-linux, e2fsprogs, iproute2, kmod. De bibliotecas facilmente temos a uclibc, a dietlibc, a musl, newlib e klibc. Existe uma lista enorme somente de bibliotecas C mas poderíamos contar até com mais em outras linguagens. Já mostrei aqui três compiladores além do GCC que compilam o kernel Linux como o tinyCC, o ICC da Intel e o LLVM. Na parte de init systems (BSD, SysVinit, upstart, systemd e etc) também temos uma lista enorme e de carregadores de boot temos outros também. Confiram mais em /pub/linux/utils/ e pub/linux/.

 Uma boa recomendação de leitura é o artigo O dia que Laurent Bercot calou RMS: Eu não uso GNU e seu projeto  

toybox, desenvolvido para Linux e mais tarde portado para FreeBSD

moreutils Uma coleção de ferramentas para Unix que ninguém pensou em escrever

uutils ou rust core utils

Comandos do embutils desenvolvidos para Linux

Comandos do ubase inspirados no util-linux porém mais simples

sbase

minibase

9base port de várias ferramentas originárias do Plan 9 para os Unixes

vcoreutils que é desenvolvido na linguagem V

 Já se passaram 34 anos e muita coisa mudou desde o seu primeiro lançamento. E de tudo o que foi mencionado aqui, sabe o que pertence ao GNU? Nada! Tudo no Linux é uma questão de escolha; opções não faltam.

Kernel: A alma do sistema operacional 

 Se lembram da frase "Algumas destas (ferramemtas) precisam de recursos do kernel" no README lá no início do artigo? Pois é, três coisas podemos mencionar aqui que ocorrem a medida que novos recursos ganham vida no kernel. A primeira é o desenvolvimento de ferramentas para a administração exatamente de recursos do kernel como exemplos os comandos do iproute2 (arpd, bridge, ctstat, devlink, ip, lnstat, nstat, rdma, routef, routel, rtacct, rtmon, rtstat, ss, tc e tipc) para administrar o framework de sub-sistema de redes do Linux; o iptables e nftables para administrar o framework de filtro de pacotes netfilter; os comandos do e2fsprogs (lsattr, chattr, fuse2fs, badblocks, dumpe2fs, e2freefrag, e2fsck, e2image, e2label, e2mmpstatus, e2undo, e4crypt, e4defrag, filefrag, fsck.ext2, fsck.ext3, fsck.ext4, logsave, mke2fs, mkfs.ext2, mkfs.ext3, mkfs.ext4, mklost+found, resize2fs, tune2fs) para a administração de recursos sistemas de arquivos da familia ext*; podemos citar atributos estendidos com o getfattr e o setfattr, ACL POSIX, capabilities e os comandos para administração dos sistemas de arquivos como btrfsprogs, xfsprogs e os próprios comandos fdisk, mkfs, mount e fsck são parte da administração dos sistemas de arquivos; os comandos getenforce, setenforce e até a opção -Z no comando ls são para administrar o SELinux (bom, essa é bem básica do SELinux já que o mundo SELinux é muito maior do que isso); os módulos Apparmor, Tomoyo, MAC e DAC também possuem seus comandos; o comando watchdog para monitorar e gerenciar comportamentos anormais de hardware e software e  automaticamente reset ou rebootar o sistema se necessário utilizam o módulos como softdog e incontáveis outros. No Linux existe até o módulo B.A.T.M.A.N. (better approach to mobile ad-hoc networking) que utiliza os comandos batctl e batman-adv para administração (há também a daemon comando alfred).

 A segunda é o desenvolvimento de ferramentas devido o kernel fornecer recursos para isso. Containers por exemplo são uma mistura dos recursos name space e cgroups (cgroups é fonte de recursos para vários outros programas que utilizamos e uma das principais fontes de recursos para do systemd. O systemd faz uso também do dbus que inclusive é utilizado também na parte de virtualização); o próprio kvm (kernel based virtual machine) como o próprio nome diz é um recurso do kernel para virtualização e que foi adicionado por volta de 2007 (veja na RedHat e na aws); o iproute2 já citado anteriormente, depende de vários recursos do kernel como exemplo a parte de routing policy database (ip rule list e ip route list table local) que depende dos recursos do kernel IP: advanced router e IP: policy routing e o seu IP in IP tunneling que depende dos módulos ipip.o e new_tunnel.o; o novo comando mu (veja também no git) utilizado para exibir o uso de memória por arquivo, depende da systemcall cachestat() do kernel; todos os programas dependem do kernel para serem executados através do recurso ELF (Exectuable and Loadable File) que substituiu o a.out.

 Sabe o shebang (#!) que utilizamos no início de nossos scripts? Pois é! Não é o shell que lê este comentário para interpretar os scripts e sim o kernel através da system call execv (fs/exec.c).

Recursos ELF e #! dentro de Executable file formats no kernel

 Até o seu navegador depende de recursos do kernel a para sua execução e não estou falando de drivers drivers, estou falando de gerenciamento de processo e memória, acesso ao sistema de arquivos, recursos de segurança como Sandboxing e etc. 

 A terceira é o desenvolvimento de novos programas pegando partes do código do próprio kernel. Citando dois exemplos, na FAQ da dietlibc descreve que é utilizado o layout struct stat do kernel em sua interface. O segundo é no projeto Psmisc (que contém comandos como killall, pidof e pstree) que utilizaram o src/loop.h do pacote util-linux que por sua vez, pegaram do kernel Linux.

 O kernel é mais do que o coração do sistema operacional, ele é a alma do sistema operacional pois seu sistema operacional depende muito mais do kernel do que você imagina. Se só com o kernel não se faz nada, sem o kernel, muito menos. Sem o kernel não há sistema operacional.

Linux: Mais do que um Unix

 Aproveitando que falamos de pegar partes do código do próprio kernel para para a construção de novas ferramentas, quero sugerir meu artigo Linux: Mais do que um Unix onde debato sobre algumas das centenas de system calls da API própria do Linux que lhe proporciona recursos que nenhum outro Unix possui (e nem a API POSIX).

Por que foi propagado que Linux é apenas o kernel?

 Este foi o meio que RMS, a FSF e o projeto GNU resolveram utilizar para virar os holofotes para si, tentar se tornar o centro das atenções e se promover já que ideia de ter um sistema operacional completo falhou. Como Rob Landley menciona no Ohio Talk em 2013:

"Os BSD não é uma ameaça existencial para o Linux, mas o Linux é para o GNU".

 O projeto GNU foi iniciado quase oito anos antes do Linux e como tudo na vida é incerto, o curso da história mudou, Linux tomou proporção que não era esperada e passou a ganhar notoriedade em toda a comunidade de tecnologia que não, proporção essa que todos esperavam que ocorreria para o GNU.

 Sabendo que as pessoas não possuem o hábito de leitura (e esse é o grande declino moral das sociedades), passaram então a explorar este ponto fraco a seu favor. No final das contas, tudo uma questão de vaidade ou outras intenções. O que mais me intriga é ver profissionais de Linux vergonhosamente defenderem este argumento.

Conclusão

 Foi-se o tempo que Linux era somente um kernel. O que começou como um projeto pessoal, um pequeno kernel sem pretensões ou expectativas, apenas uma diversão e um desafio para um hacker aplicar seus conhecimentos, inesperadamente evoluiu e se tornou um verdadeiro sistema operacional contendo comandos, shells, bibliotecas, init systems e até mesmo sua própria API.

 Pode não ser considerado um sistema operacional completo, o que dificilmente algum sistema operacional é (muito menos o GNU) já que em todos os sistemas operacionais (especialmente no GNU que não contém metade das ferramentas necessárias para se ter um sistema operacional funcional) são utilizadas ferramentas de outros sistemas ou de outros projetos pois o compartilhamento de conhecimento e a colaboratividade sempre foram as bases da cultura hacker.

 E se Linux fosse realmente apenas o kernel do sistema operacinal, sabe qual a importância isso teria entre verdadeiros profissionais de tecnologia? NENHUMA! O importante é o sistema funcionar e atender as demandas.

 Já aos que vão vir afirmar que discordam (sempre escuto ou leio isso), só tenho um recado a deixar : Eu não dou a mínima importância para concordância ou discordância. As evidencias estão aí, basta terem maturidade e hábito de leitura. 

• O dia que Laurent Bercot calou Richard Stallman: Eu não uso GNU, eu uso Linux!
• Projeto Skarnet
• A verdadeira face de Richard Stallman
• Muito além do GNU
• Daemons, daemons e mais daemons (init)
• Muito além do GNU: Os vários sabores de bibliotecas C

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

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

dietlibc 0.36?

 Depois do lançamento da versão 0.35 no dia 7 de Novembro do ano passado (3 dias após o lançamento da versão 0.35), a dietlibc recebeu mais três patches e um git request enviados por Friedrich Beckmann que trabalha no provedor de e-mail alemão posteo.de.

 Os dois primeiros patches estão relacionados a arquitetura aarch64. O primeiro trabalhando com o símbolo __clone que é necessário para pthread_internal.c e solucionar o problema que Friedrich notou ao tentar construir gatling no Raspberry Pi linkando-o ao t.c da libowfat; o que acabou reportando missing symbol __clone required pela dietlibc libpthread. O segundo já relacionado ao símbolo __getauxval da libgcc também necessário para aarch64.

 E o ultimo é uma regressão de test de regex do port e adaptação da glibc para a dietlibc: https://github.com/fredowski/dietlibc/tree/fredo

 Já o pull requeste corrige alguns bugs de expressões regulares. Alguns testes foram portados da glibc

https://github.com/fredowski/dietlibc/compare/master...regex

 Torço para que em breve tenhamos um novo lançamento da dietlibc.

Mais sobre a diet libc pode ser conferido aqui no blog

A dietlibc também pode ser conferido na série muito além do GNU

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

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

Rust no kernel Linux: A guerra sem trégua

 Em 2023 eu escrevi o artigo Rust no Linux: Um caso de amor e ódio e depois dessa nova temporada de Rust no kernel, eu estava pensando em fazer um vídeo porém, como ando muito ocupado, preferi escrever aqui no blog mesmo.

 Bom, a treta de Rust no kernel Linux continua. Tentaram de todas as formas e contra todos os gostos promover Rust no kernel Linux, houve resistência por parte de muitos desenvolvedores e até mesmo de Linus Torvalds mas por fim, foi feita a adoção. Depois disso houveram novos problemas, o principal responsável por Rust no kernel saiu do projeto e em Fevereiro desse ano, começou o processo tudo de novo; ninguém dá trégua nessa bagaça. Muitos desenvolvedores não apoiam sua adoção mas a cartada final dada por Greeg Kroah-Hartman:

"Adicionar outra linguagem não deveria ser um problema, já lidamos com coisas muito piores no passado."

"Sim, bases de códigos de linguagens mistas são grosseiras e difíceis de manter, mas somos desenvolvedores de kernel, droga. A gente vem mantendo e fortalecendo o Linux por mais tempo que qualquer um já pensou que fosse possível"

 Não tem como discordar do Gregg nesse ponto já que nós sysadmins passamos bastante por situações parecidas, mas alguns até mesmo abandonaram o desenvolvimento como Karol Herbst que deixou o desenvolvimento do driver nouveau depois que adotaram o driver Nova como substituto do Nouveau; Christoph Hellwig bateu de frente com todos (inclusive com Linus) e esse debate parece não tem fim.

 Estamos em um período de transição na tecnologia onde novos processadores, novos chips e novas linguagens estão surgindo. Muito se fala hoje em dia sobre segurança de memória (apesar que este assunto já dura mais de 30 anos) e seus benefícios; Em 2017 foram reportados cerca 40 CVEs somente do kernel Linux relacionados a falhas de segurança de memória. Então, se for para o bem, sim eu acredito que uma linguagem que possua recursos relacionados a segurança de memória deva ser adotada no desenvolvimento do Linux, mas Rust não é esta linguagem; outras linguagens são muito mais interessantes para se integrar ao kernel Linux do que Rust, como é o caso de Lua e Nim. Bom, o argumento que podem apresentar é que Lua é uma linguagem interpretada por scripts. Sim, porém o NetBSD possui drivers escritos em Lua, o carregador de boot do FreeBSD é escrito em Lua e o interpretador do rpm é escrito em Lua:

 Lua é uma linguagem que facilmente se comunica com a linguagem C e C se comunica com tudo; geralmente é comum incorporar códigos C a alguma aplicação Lua para se comunicar com outras coisas. Lua na verdade já nasceu tendo como uma de suas características ser amigável com a linguagem C; inclusive um dos melhores recursos da linguagem Lua é exatamente o design de sua API que lhe permite integrar seu código a bibliotecas C ou fazer com que scripts Lua sejam executados de forma muito rápida junto ao código C dos jogos. Alias, se precisar portar seu código Lua para C, se torna uma tarefa muito mais fácil do que qualquer outra linguagem. E SIM, LUA POSSUI SUPORTE A SEGURANÇA DE MEMÓRIA!

 Eu conheci Lua por volta de 2007 ou 2008 em um PDF como uma linguagem para integrar a linguagem C e fazer coisas que a linguagem C não faz; depois eu descobri que Lua já era amplamente utilizada em muitas aplicações como desenvolvimento da maioria dos jogos (inclusive liderando a parte de scripts de jogos e já até ganhou prêmios na parte de jogos), aplicações industriais, estações espaciais e petrolíferas, sistemas embarcados, os sites Wikipedia e Github são implementados em Lua, Netflix faz forte uso de Lua, Adobe Photoshop Lightroom, Ultradefrag, VLC, nmap, wireshark (1, 2), snort (1, 2), Metaplace, teclados da Logitech. Lua é um grande caso de sucesso e mais presente do que imaginamos sem essa necessidade de propaganda e comoção que foi feito em cima de Rust.

 Nim é outra linguagem muito mais apropriada e interessante para o kernel Linux (existem ao menos dois sistemas operacionais escritos em Nim) e seus recursos únicos, que eu vou descrever mais a frente, são muito mais interessantes do que Rust.

 Muitos projetos se beneficiarão de Rust enquanto que muitos outros não; alias, é uma lei natural. Exemplos reais são o Android que se beneficiou de Rust tendo redução de 76% para 24% de seus bugs enquanto que o port do fish shell de C++ para Rust não resultou em nenhum benefício, não entregou nenhum novo recurso e quando estes surgiram, não estavam vinculados a linguagem Rust... já outros projetos por outro lado, pode ser tornar até prejuízo a adoção de Rust tanto que há programas ques estão sendo migrados de Rust para outras linguagens como é o caso do gerenciador de pacotes da distribuição Glaucus Linux que foi portado de Rust para Nim (sintax mais simples e mais fácil de manter, melhor desempenho e menos uso de memória, de CPU) e a linguagem Roc que está sendo reescrita de Rust para Zig pela sua eficiência no processo de compilação ser maior e ter menos dependências (1; 2. Valeu Nilton por compartilhar estas informações). É questão do que se adéqua ou não a necessidade (aprendam isso). Honestamente, esta terceira opção é a mais provável que venha acontecer com o kernel Linux. Sim, eu vejo isso acontecer.

 Não é de hoje que tentam substituir a linguagem C como menciona o próprio autor da linguagem C Plus Prolog (ou simplesmente C+P) que descreve sobre a  linguagem C como sendo a única linguagem útil* (*portável, com desempenho que mais se aproxima de Assembly e consegue se comunicar com tudo) e que cientistas vem tentando há quase 50 anos encontrar uma solução para (digamos) substituir a linguagem C. E alguns até criaram C mais parecida com a linguagem Prolog e outros criaram o inverso, Prolog parecido com C."

 O grande problema não é a linguagem Rust, o problema é mais uma questão psicológica. Os usuários estão querendo adotar Rust de forma eufórica e irracional, sem pesar na balança as vantagens e desvantagens assim como todas as linguagens possuem, sem pensar nas consequências; só estão querendo adotar acreditando que Rust é a oitava maravilha do mundo que solucionará todos os problemas da humanidade. A maioria não são desenvolvedores e os que são, além de nunca nem mesmo terem explorado o real potencial da linguagem C, estão cheios de amores por Rust... Rob Landley, autor do toybox que eu sempre menciono, disse em seu artigo de 21/09/2024 da melhor forma:

"Eu desisti de Rust porque todo puritano de Rust que eu encontro há anos trata NÃO escrever código em Rust como um pecado... ...A multidão "all must rust away" não conseguem explicar as vantagens de Rust a não ser "não é C"...

 A única coisa que vemos é essa frescura de "rewrite in Rust", o que é uma bela de uma burrice já que o kernel Linux possui quase 1 Gigabyte somente de código na linguagem C. Levariam vários anos só para porta-lo para Rust e mais muitos outros anos somente para torna-lo estável (reescrever drivers será uma mão de obra intensa e que introduzirá mais problemas do que soluções — reescritas sempre introduzem bugs). Por vezes eu já vi desenvolvedores sugerir aos desenvolvedores de Rust desenvolverem as mesmas soluções do zero ao invés de ficarem querendo reescrever tudo em Rust. O autor da linguagem Hare sugeriu:

"Um grupo motivado de talentosos desenvolvedores de sistema operacional em Rust poderiam construir muito rápido um kernel compatível como Linux do zero e sem necessidade de se envolverem na política LKML"... 

"Eu acho que se o montante de esforços sendo colocados no Rust-for-Linux fossem aplicados em um novo sistema operacional compatível com Linux, poderíamos ter algo pronto para produção para alguns casos de uso dentro de alguns anos."

..."desenvolver um sistema operacional baseado em um design comprovado como o do Linux é muito mais fácil e pode ser feito muito rápido. Eu trabalho em meu próprio sistema operacional de novo design (um microkernel) há alguns anos e ainda está travado no design e precisa urgentemente ser repensado; por outro lado eu escrevi um clone aceitável do Unix em menos de 30 dias."

 O MIT também já desenvolveu um kernel assim chamando Biscuit o e apresentou no Usenix de 2018. Biscuit é kernel monolítico POSIX escrito na linguagem Go e é tão compatível com Linux que roda as aplicações do próprio Linux sem nenhuma necessidade de modificação do código fonte das aplicações. Por que a galera de Rust não acata essa proposta? Outro grande exemplo de escrever algum programa do zero e não de porta-lo é o bzip2; no meu artigo Qual o futuro do Bzip2? descrevi que os novos mantenedores foram questionados se portariam bzip2 para Rust, o que foi respondido que eles preferem trabalhar no suporte a multithreading em C, que para Micah é algo que seria muito interessante principalmente nas futuras versões 1.2 ou 2.0, do que qualquer coisa em Rust (lembram-se que eu mencionei que muitos que estão cheios de amores por Rust nunca nem mesmo exploraram o real potencial da linguagem C? Aqui está uma prova disso) e por fim foi indicada a implementação do Bzip2 em Rust desenvolvida do zero.

 Lanldey também argumenta sobre o desenvolvimento de um sistema operacional escrito em Rust do zero e ainda apresenta a percepção das intenções da comunidade Rust:

"Se quizerem escrever um novo sistema operacional inteiramente em Rust, com kernel e userspace e toolchain, tudo em Rust, eu respeitaria isso e desejaria tudo de bom para eles. Mas não é o que eles querem. eles acreditam que lhes é devido Linux e eles querem sequestrar Linux (ainda que majoritariamente escrito em C)"... ..."E eles acreditam que ADICIONAR COMPLEXIDADE ADICIONAL resultará em sistemas melhores"

 Sim, essa é percepção que se passa; não é que querem ter uma linguagem secundária no kernel Linux com a intenção de melhorar sua segurança e sim de aos poucos dominar o kernel substituindo todo o código por Rust para se autopromover. Rescrever algo em Rust pode se tornar uma cilada; imaginem a complexidade será reescrever o código rust para outra linguagem; você pode acabar ficando atrelado a ela (coincidência ou não, já vi desenvolvedores reclamando de coisas parecidas do projeto GNU).

 O que esquecem de nós contar é exatamente os contras da linguagem: Curva de aprendizado terrível; difícil de debugar; complexa (não é a toa que o autor do minibase diz que o Rust coreutils o forneceu uma grande inspiração por lhe mostrar como não escrever o coreutils); tempo de compilação enorme; ecossistema pequeno; otimizada para a maioria dos processadores i686 e x86_64 porém, em outras plataformas como armel, armhf, armv7, mips{64}, powerpc{64} e riscv{64} carece de suporte de primeira classe, fora "recursos" de Rust que podem causar erros e bugs no LLVM; utilizar  HLL pode causar perdas de desempenho, uso excessivo de CPU, memória e I/O; foram o tamanho dos biários ser enorme.

Diferença de tamanho dos binários UUtils e toybox

 Se gabam unicamente de segurança de memória sem mencionar à que custo... E tudo tem um custo. O artigo The benefits and costs of writing a POSIX kernel in a high-level language faz uma ótima análise descrevendo os benefícios de escrever seus programas e sistemas operacionais em linguagens com segurança de memória ao custo de sacrificar o desempenho que foi de 5% a 15%. Segurança de memória pode também afetar os seus programas; o autor da linguagem C3 descreve em seu artigo Por que eu parei tudo e comcei a escrever  em C de novo:

"...Quem consegue escrever um jogo de estratégia com milhares de units cada tendo sua própria versão de mundo sem ter um garbage collector rodando o inferno? De fato meu amigo tentou escrever o jogo e falhou. Garbage collectors são péssimos e todos os meu projetos em Lisp possuem aplicações muito limitadas apenas por causa do garbage collector. ..."

 Ok, o segundo argumento que podem querer apresentar é que Rust não utiliza garbage-collection por acreditarem não ser um recurso eficiente. Ao invés disso, Rust aplica a técnica de analisar o código fonte durante o processo de compilação para garantir que não haja brechas de segurança; PORÉM este tipo de recurso já é empregado na linguagem C há muito, mas muito tempo. A biblioteca dietlibc emprega ao menos seis linker warnings (avisos) durante o processo de compilação para ajudar os desenvolvedores escrever melhores códigos:

1. Avisa se assert for utilizado (pode indicar debug code)
2. Avisa se stdio for utilizado (bloat)
3. Avisa se sprintf for utilizado  e indica utilizar snprintf por ser melhor e mais seguro¹
4.  Avisa se *printf/*scanf for utilizado (bloat e recomenda utilizar -lowfat)
5. Avisa se system for utilizado (risco de segurança)
6. Avisa se mktemp/tempnam/tmpnam for utilizado (race condition)

 E esse é um dos grandes problemas; Rich Felker, autor da biblioteca musl, descreveu em seu artigo intitulado Overcommit que "há um monte de mal entendidos relacionados a gerenciamento de memória no Linux que levam à um monte de programas ruins que falham de forma robusta com condições de baixa memória e geram mitos". OK, gerenciamento de memória e segurança em memória são coisas diferentes, mas a mesma situação se aplica-se a ambos os casos, ou seja, não vai adiantar nada adotar outra linguagem se os desenvolvedores não souberem tratar corretamente seus códigos.

 Falando em musl, além de também fazer a mesma coisa por trabalhar com o conceito de quality safe code (visando ser correta no senso conformidades padrões e segurança) é utilizada para encontrar bugs através do recurso fail-safe da biblioteca.

 A Red hat adicionou a flag -FORTIFY_SOURCE aos compiladores GCC e Clang para detectar falhas como buffer over flow (1). O GCC também possui desde 1998 a extensão StackGuard que é uma Stack Smashing Protection (SSP) (1) que ajuda o compilador detectar e prevenir ataques buffer-overflow que alias, o OpenBSD faz forte usso deste recurso.

 O compilador tinycc possui a opção -b (bounds checker) há no mínimo 15 anos... E o GCC há uns 10... foram o recursos ASan (AddressSanitizer) que é um plugin detector de erros de memória para C/C++ utilizado inclusive no Google Chrome do Android, no Chrome OS, simulador do iOS, Linux, Mac, e Windows de 64 bits e disponível no LLVM há mais ou menos uns 15 anos (1, 2, 3), -fstack-protector, -fsanitize=safe-stack, UBSan (-fsanitize=bounds) e o SafeCode. Alias, a própria Wiki do  ASan sugere o uso da ferramenta como cgroups para limitar o consumo de memória. Por que não incluir Pledge a esta lista? Ou seja, existem vários mecanismos para se utilizar somente com a linguagem C, mas a solução que encontraram foi adotar outra linguagem que pode gerar uma série de outros problemas... ... ... Enquanto isso Rust possui um recurso chamado unsafe que a galera de rust se refere como o "segredinho sujo" que eles utilizam em todos os lugares mas está tudo bem... São eles que estão usando... não é?

 Está certo que utilizar recursos como verificação do código fonte acaba gerando binários um pouco maiores por acabar adicionando mecanismos de segurança, mas em Rust isso tinha que ser tão exagerado? O Rust coreutils por exemplo, contendo apenas apenas 87 comandos e sendo linkado dinamicamente, possui o tamanho de mais de 12MB enquanto o toybox, sendo linkado estaticamente e contendo 233 comandos (quase três vezes mais que o Rust Coreutils), ocupa apenas 724KB (mais de 17 vezes menor levando em conta sua ligação estática e a quantidade de comandos). Já houve quem dissese que isso acontecem em Rust apenas em X86 por conta das dependências e não ocorre em embarcados. O que não é verdade pois geralmente Rust gera binários praticamente do mesmo tamanho.   

 O interessante mesmo é poder decidir quando utilizar segurança de memória. No livro Nim in action descreve que algumas linguagens de programação, como C, não possuem segurança de memória porque ela permite que programas sem atribuição possa acessar a memória. Por outro lado, linguagens possuem segurança de memória oferecem essa segurança ao custo de não permitir que programas acessem detalhes de baixo nível da memória quando se faz necessário; e é aí que Nim se torna uma linguagem muito interessante. Por padrão Nim já oferece proteção contra erros de memória porém, porém Nim oferece as duas opções (escrever códigos com ou sem segurança de memória) permitindo que você decida quando utilizar cada uma delas. Ainda no livro Nim in Action descreve que "...há situações quando muitos querem evitar garbage collectors; eles são considerados por muitos ser inadequados para certas aplicações como embarcados e jogos. Por essa razão, Nim possui suporte a um número diferente de garbage collectors com diferentes aplicações em mente. Garbage collector pode também ser removido completamente, lhe dando a habilidade de você mesmo gerenciar memória." ... "Aplicações escritas em Nim são muito rápidas, em muitos casos, tão rápidas quanto aplicações escritas em C, e mais de trinta vezes mais rápido do que aplicações escritas em Python. Eficiência é  maior prioridade, e alguns recursos toram otimização de código fácil. Isso vai de mãos dadas com um soft real-time garbage collector, que lhe permite especificar o montante de tempo que deve ser gasto coletando memória. Esse recurso se torna importante durante desenvolvimento de jogos, onde um garbage collector comum pode desacelerar a renderização de frames na tela se utilizar muito tempo coletando memória. Também é útil em sistemas real-time que precisam rodar em frames de tempo muito estrito." Nim, além de por padrão já proteger seu programa contra todos os tipos de erro de memória, possui também recursos muito mais interessantes como meta programação, style intensitivity; seu type system (que apesar de ser estática, incorpora o recurso type inference que lhe permite acelerar o desenvolvimento do seu código sem sacrificar a segurança), type safety e type-checking dinâmico; Generics (que lhe permite reutilizar o código sem sacrificar type safety) e muito mais.

 (13/08/2025) Linguagens como C e C++ possui suporte a segurança em memória, mas algo que é feito manualmente. Os desenvolvedores que devem verificar seus próprios códigos e identificar o problema (algo que já vimos aqui Rich Felker denunciando). Os desenvolvedores do Busybox por exemplo fazem isso muit bem, no dia 03/08/2025, Denys Vlasenko corrigiu o vazamento de memória  causado pela otimização do compilador.

 (13/08/2025) Além destes recursos, a equipe do Btrfs implementou no dia 12/08/2025 o ref_tracker que detecta vazamentos e printa os traços da pilha que ainda não liberadas e assim poderem corrigir os problemas.

 Vale ressaltar que essas técnicas de memory safety também são possíveis na linguagem C e C++ não somente manualmente como muitos acreditam mas também através de garbage collector para C e C++ que foi desenvolvido pelos três pesquisadores Hans-J. Boehm, Demers e Weiser (por isso o nome bdwgc) em meados da década de 90... Este recurso lhe permite utilizar garbage collector nas duas linguagens quando quiser bastabdo definir #include "gc.h" em seu código. O bdwgc também oferece o recurso Leak Detector.

 (28/03/2025) No dia 26 de Fevereiro de 2025 a equipe de desenvolvedores do XFS implementou o recurso garbage collection no zoned do XFS todo desenvolvido em C (e que vai para o kernel 6.15-rc). E no dia 19 de Março foi adicionado a opção gc_pressure no mount do XFS para evitar um risco no garbage collection em circunstancias distintas. O que nos leva a questionar se realmente se faz necessário a adoção de uma linguagem secundária no kernel Linux somente pelo recurso de segurança em memória ao custo de perda de desempenho, binários enormes, alto consumo de memória, CPU e etc sendo que tal recurso já está presente de tantas formas (linguagens mais adequadas, algoritmos, bibliotecas, flags, extensões), há tanto tempo (uns há quase trinta anos) e que já poderiam estar sendo empregados...

Garbage Collection no zoned do XFS

Garbage Collection no f2fs

 E o mais interessante de tudo: Se lembram do artigo da Casa promovendo que todos deveriam migrar de linguagens como C e C++ para linguagens com segurança de memória? Pois é, estranhamente parece que a Casa Branca voltou atrás e não vai mais promover segurança de memória já que o mesmo link está indisponível.

 Bom, eu acho que agora sim neste segundo artigo eu tenha abordado elementos o suficiente para pensar no assunto; o assunto de segurança em memória vai muito além do que simplesmente adotar uma linguagem com tal recurso achanado que solucionará os problemas de forma definitiva.

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

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

Lançada dietlibc 0.35

 Finalmente, depois de seis anos, foi lança a versão 0.35 da biblioteca dietlibc que é muito abordada tanto aqui no blog quanto no canal. Por mais que não seja popularmente conhecida, essa é uma biblioteca fortemente utilizada em vários ambientes, especialmente em embarcados assim também como a Newlib.

 Eu já realizei testes de binários linkados à dietlibc (como o embutils que é um pacote parecido com o coreutils, minised, runit e muitos outros) e os resultados são surpreendentes. Por esse motivo eu torço para que a dietlibc continue recebendo cada vez mais atenção de várias grupos. A versão 0.34 da dietlibc havia sido lançada em 2018 porém, no últimos dois anos, alguns grupos vem enviando tanto patches quanto testes para a biblioteca.

 No dia 5 de Janeiro de 2023 por exemplo, Gabriel Ravier enviou um patch com algumas correções no retorno de valores do recurso wcs{,n}cmp (para near-limits assinado com valores wchar_t) correções em seu comportamento e correções que evitam overfalow. Mas esta não foi a sua única contribuição; Gabriel fez o total de dez contribuições corrigindo várias falhas (especialmente do printf), adicionando melhor segurança, definindo valores e adicionando novos recursos (um deles no scanf).

 Já no dia 13 de Janeiro do mesmo ano, Jai Arora, Abhishek Rose, Shubhani Gupta e Sorav Bansal da empresa indiana CompilerAI Research GroupIIT reportaram uma série de bugs em funções da dietlibc. A empresa foi tão organizada que disponibilizou códigos fonte em seu próprio repositório no Github e quais flags foram utilizadas durante o processo de compilação para que os bugs possam ser reproduzidos, analisados e assim futuramente corrigidos. Acredito que boa parte possa ter sido corrigido nessa nova versão.

Bessel e ARM na dietlibc

 Ficamos um bom tempo sem noticias até que Larry Doolittle, que participa também do desenvolvimento do TinyCC, enviou no final do ano passado dois patches; um com apenas nove linhas e outro com mais sete, para que sejam utilizados nos sub-testes runtests.sh e funcionarem melhor. Sem eles, há certos bugs que fazem com que o shell reclame que cada arquivo dentro de test/*/runtests.sh não seja executado. Outro trabalho que Larry está atuando é na função de Bessel que aponta das versões 12 e 13 do GCC.  

"Eu sei algo sobre funções de Bessel, então isso despertou meu interesse e comecei a me aprofundar. Eu aprendi duas coisas principais: bessel.c inclui uma seção escrita somente para x86 e não possui nenhum banco de testes."

 Larry criou um tarball de 8 kbyte e postou em seu site pessoal contendo implementações de código de pesquisa bessel.c reescritos de forma simples e portável. O arquivos pode ser baixado em: 

http://doolittle.icarus.com/~larry/diet-bessel-test.tar.gz

 A integridade do arquivo pode ser verificada utilizando sha256sum conferindo o resultado a seguir:

18da50d99030c680d1dfa33e2f78e3abf056a2b91a3d530a6b42d1116e8f67a9  diet-bessel-test.tar.gz

 Esse código inclui também um banco de teste que podem ser realizados com a opção make -C test e obter os resultados parecidos com os abaixo:

$ make -C test  # riscv64

make: Entering directory '/redacted/test'

gcc -std=c99 -O2 -pedantic -Wall -Wextra -I../include bessel.c ../libm/bessel.c -lm -o bessel

./bessel

Bessel function test with sizeof(double) == 8 and sizeof(long double) == 16

in 176: J max errors 0.0000000000000021 0.00000000005 0.00000000005 0.0000000009

in 175: Y max errors 0.00000000005 0.00000000023 0.000000005 0.000000084

max |J| at known zeros 0.00000000002 0.0000016 0.0000011

max |Y| at known zeros 0.00000000087 0.0000011 0.0000007

Y_0 at first zero 0.00000000327

Hankel modulus-squared max error 0.00000000039

PASS

$ make -C test  # x86_64

make: Entering directory '/redacted/test'

gcc -std=c99 -O2 -pedantic -Wall -Wextra -I../include bessel.c ../libm/bessel.c -lm -o bessel

./bessel

Bessel function test with sizeof(double) == 8 and sizeof(long double) == 16

in 176: J max errors 0.0000000000000513 0.00000000005 0.00000000005 0.0000000009

in 175: Y max errors 0.00000000005 0.00000000023 0.000000005 0.000000084

max |J| at known zeros 0.00000000002 0.0000016 0.0000011

max |Y| at known zeros 0.00000000087 0.0000011 0.0000007

Y_0 at first zero 0.00000000327

Hankel modulus-squared max error 0.00000000039

PASS

 

$ make -C test  # armv7l (armhf)

make: Entering directory '/redacted/test'

gcc -std=c99 -O2 -pedantic -Wall -Wextra -I../include bessel.c ../libm/bessel.c -lm -o bessel

./bessel

Bessel function test with sizeof(double) == 8 and sizeof(long double) == 8

in 176: J max errors 0.0000000000456691 0.00000000007 0.00000000008 0.0000000009

in 175: Y max errors 0.00000000014 0.00000000023 0.000000005 0.000000084

max |J| at known zeros 0.00000000002 0.0000016 0.0000011

max |Y| at known zeros 0.00000000087 0.0000011 0.0000007

Y_0 at first zero 0.00000000327

Hankel modulus-squared max error 0.00000000139

FAIL

 

 O novo banco de testes é quatro vezes maior e Larry trabalha para concluir a documentação antes de submeter o patch. E por ultimo, Larry reportou um problema que ocorre na dietlibc com a arquitetura ARM quando utilizadas algumas flags. Não se trata de um problema exclusivo na arquitetura ARM, esses erros ocorrem em muitas arquiteturas, menos em x86_64 e x32.

"DEFAULTCFLAGS e seu -nostdinc também é problemático para construir json em qualquer arquitetura exceto em x86_64 and x32... ...gamma.h sofre da mesma codificação específica 387 assim como bessel.c. ... ... Tentar consrtuir código de usuário utilizando quaisquer funções matemática falha, faltando coisas como sin cos exp log, que são definidas em assembly em x86_64 e i386. ..."

 Estes são alguns trechos que eu traduzi e que notei que o grande problema é que estes recursos não foram portados para outras arquiteturas. Agora é esperar que as comunidades trabalhem nos problemas. Reports já temos.

More working around optimiser bugs (04/07/2024)

 Thorsten Glaser da Evolvis informou que a dietlibc entra em um loop interminável na arquitetura arm64 devido o GCC otimizar a implementação da chamada strlen. Uma solução sugerida por Thorsten foi adicionar a opção -ffreestanding na variável DEFAULTCFLAGS (e IMHO bootloaders, kernels e libcs também precisam ser construídas com essa opção) que corrige esse problema.

Há muitos recursos ainda pendentes na dietlibc conforme podemos conferir nesta tabela de comparações de implementações de bibliotecas C para Linux porém, acredito que este lançamento tenha sido muito importante tendo um total de 23 novos recursos, 3 de segurança, 1 definição e 12 correções que podem ser conferidos clicando aqui.

 Eu baixei e testei a nova versão da dietlibc compilando tanto em embutils, quanto o minised e o runit e todos foram bem sucedidos; não houve incompatibilidade com a nova versão.

Mais sobre a dietlibc pode ser conferido clicando aqui

LEIA TAMBÉM: Muito além do GNU: Os vários sabores de bibliotecas C

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

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