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

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çado glaucus-s6-x86-64-v3-20241026

 No dia 26/10/2024 foi lançada a terceira release (também chamada stage 3 release) da distribuição Glaucus Linux sendo agora construída através de compilação nativa (e não através de cross compilation) atingindo assim mais um objetivo.

 A versão stage 3 do Glaucus vem com novas ferramentas por padrão como o limine sendo seu carregador e gerenciador de boot, o neatvi (que já apresentei  aqui no blog no artigo Muito além d o GNU: Os vários sabores de biblioteca C) seu editor de texto, o reflex sua implementação de lex e agora o kernel e os módulos do CachyOS são utilizados neste lançamento.

 O processo de bootstrap também foi aprimorado resultando em redução de pacotes utilizados.

 Os comandos faillog, last, lastb, lastlog e w agora são executados de forma segura sob a musl libc graças ao utmps. O gerenciador de pacotes rad foi aprimorado com mais funcionalidades. 

As informações completas do lançamento do glauscus-s6-x86-64-v3-20241026 podem ser lidas clicando aqui

Mais sobre a distribuição Glaucus Linux pode ser lido clicando aqui

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

Muito além do GNU: Os vários sabores de bibliotecas C

 Alguns dias atrás me deparei com o link do site osdev.org sobre implementações de biblioteca C; trata-se de um artigo bem interessante mas muito curto. Como eu já fiz vídeos e artigos relacionados ao tema para a minha série Muito além do GNU (lembrem-se que tudo no Linux é uma questão de escolha. Escolha diz mais respeito a liberdade do que uma ideologia ou uma simples licença), eu resolvi então explorar este texto fazendo minhas observações sobre cada uma delas acrescentando mais informação e adicionando outras.

 As bibliotecas C mais populares são a glibc, uclibc, musl e dietlibc; mas há um mundo muito mais vasto e amplo do que você pode imaginar e aqui vou eu abordar muitas outras. No total, até o momento eu cataloguei por volta de 18 diferentes implementações de biblioteca C.

 Eu não pretendo seguir na mesma ordem que está descrita no artigo e sim na minha própria ordem; basicamente, a ordem que eu conheci ou de forma que eu considero mais coerente de explicar.

Toca do Tux: uutils: Um coreutils escrito na linguagem Rust

There is a comparison table (http://www.etalabs.net/compare_libcs.html) of some of these.

Glibc

 De autoria de Roland McGrath e graças aos esforços de vários projetos e empresas que a mantem para que possam utilizá-la no Linux, é uma biblioteca absolutamente completa e possui suporte a quase todas as arquiteturas. Uma observação muito interessante feita no site:

"Ela não é escrita com nada além do Linux em mente, tornando-a um port difícil."

 Sim, apesar de a glibc ser uma biblioteca do projeto GNU, tecnicamente a glibc é uma biblioteca do Linux. Isso ocorreu porque no inicio dos anos 90 os desenvolvedores de Linux perceberam que glibc carecia de muitos recursos necessários para Linux e assim eles criaram um fork da versão 1.x que foi nomeada simplesmente libc e que conhecemos como libc4 que foi a ultima com suporte ao padrão a.out, a libc5 (/lib/libc.so.5 a primeira a ter suporte ao padrão ELF no lugar do a.out. Há algumas fontes que afiram que havia código da bibliotecas C do 4.4BSD, mas o link do projeto gnu não está mais disponível) e libc6 (/lib/libc.so.6) e foram o padrão nas distribuições Linux durante um bom tempo. A glibc 2.0 surgiu da libc6 e com o tempo, por uma questão de padronização, as distribuições voltaram a utilizar a glibc. Mais informações da libc5 e libc6 podem ser lidos clicando aqui. Já para saber mais sobre libc4, libc5 e libc6 consulte a manpage (man 7 libc).

 Houve também a Eglibc que foi uma variante da glibc fortemente focada em embarcados e com uma série opções e de suporte a arquiteturas que a glibc não possuía (especialmente PowerPC). A Eglibc foi a biblioteca padrão do Debian 5 e possuía suporte de um consorcio. O código da Eglibc foi fundido ao código da glibc na versão 2.20.

 No final das contas a GlibC se beneficiou muito do Linux assim como quase todas as ferramentas do projeto GNU. É difícil prever a linha do tempo das ferramentas GNU sem o Linux.

 Uma das grandes desvantagens da glibc podemos mencionar é o fato de  gerar binários muito grandes. no artigo Analisando 6 diferentes implementações do comando sed eu descrevo uma curiosidade relatada por Rob Landley que, um simples código "hello World" linkado estaticamente à glibc, gera um binário de 400k... Não é a toa que os desenvolvedores de embarcados se declaram inimigos mortais da glibc.

 E a outra desvantagem é estar sob a licença GPL que está em decadência desde 2007 por ser uma licença muito restritiva (até hoje não entendo o conceito de liberdade em algo tão restritivo. Algo totalmente incoerente).A criação da GPLv3 foi uma corda no pescoço da licença e já houveram planos no passado para migra a glibc para a terceira versão. Ainda bem que isso não ocorreu pois geraria um grande colapso nos projetos.

uClibc

 uClibc (pronuncia-se yew-see-lib-see) é uma biblioteca para Linux em embarcados no projeto µClinux. Bem menor do que a glibc porém com suporte a quase todas as suas aplicações e quase todas as arquiteturas (alpha, amd64, ARM, Blackfin, cris, h8300, hppa, i386, i960, ia64, m68k, mips/mipsel, PowerPC, SH, SPARC e v850). 

 Foi escrita do zero por Erik Andersen, ex mantenedor do Busybox (que passou a bola para Rob Landley, autor do terminal de comandos toybox), iniciando em 1999 tendo apenas algumas partes de código derivados da glibc como pthreads (threads do Linux, o mesmo recurso que querem fazer uso dentro do sistema operacional RTOS X5) e o suporte a números randomicos.

 O uClibc foi descontinuada por volta de 2012 e criaram um fork chamado uClibc-ng. Aé aonde se sabe, existem poucos mantenedores da uClibc-ng, ou talvez somente um, sob o argumento que é a única que possui suporte a algumas plataformas de hardware antigos.

 Está sob a licença LGPL e o site da uClibc-ng pode ser conferido clicando aqui.

Musl

 Musl já apareceu várias vezes tanto aqui no blog quanto no canal. É construída sobre a API do Linux e a API POSIX e tem como princípios a simplicidade, eficiência de recursos, atenção em correções, segurança sob exaustão de recurso, fácil deploy e suporte de primeira classe para textos UTF-8/multilingual. A musl permite gerar binários menores (mesmo linkados estaticamente) e rápidos. Rich Felker criou o conceito Quality Safe Code; o que leva a biblioteca a ser correta no quesito conformidade e segurança.

Mais sobre a biblioteca Musl pode ser lido clicando aquioca do Tux: musl

 Com o fim da uClibc e depois de ter péssima experiência com programas linkados a outras bibliotecas (seja de forma dinâmica ou estática) que apresentaram falhas, Rich  Felker desenvolveu a musl como uma alternativa a glibc e a Uclibc para oferecer melhor experiência no uso de aplicações linkadas estaticamente (tanto no conceito de segurança quanto eficiência) em embarcados, servidores de desktops.

 Inicialmente esteve sob a licença GPL porém, depois de conversa com Rob Landley (autor do toybox) passou a disponibilizar a musl sob a licença MIT. Hoje a musl é utilizada como padrão nas distribuições Alpine Linux que é inclusive utilizada nas imagens Docker; Adelie Linux que é baseada no Gentoo Linux e eu pretendo fazer um vídeo de Os vários Sabores de Linux; Void Linux que foi criada para implementar os gerenciador de pacotes xbps (haja coragem); Alpaquita Linux criada pela empresa Bell soft para a execução de aplicações Java; Glaucus Linux que, diferente da distribuição Alpine Linux, faz uso do toybox como userspace ao invés do busybox (tive a honra de receber seu autor no meu canal) e há planos para a sua adoção no Debian e no Android.

 Possui em torno de 1200 funções além de todo um conjunto de funções matemática e de printf, porém ainda faltam system calls para serem implementadas. Natanael Copa, autor da distribuição Alpine Linux descreve em sua palestra o que é necessário para substituir a glibc pela musl. Foi a primeira biblioteca a adotar mutexes safe que o pessoal considera incrível, condvars e a primeira a ter working thread cancellation sem race conditions (todos recursos que foram ignorados por outras implementações).

Diet libc

 De autoria do alemão Felix von Leitner, foi criada com foco em otimização de tamanho dos binários assim como a musl e cumpre muito bem esse papel. Eu mesmo já fiz analises tanto no canal quanto aqui no blog compilando o embutils, o minised e o init system runit e os resultados de sua otimização de binários são surpreendentes. Há um vídeo no meu canal onde relato a sua história e recursos interessantes.

Está sob a licença GPLv2 mantendo a compatibilidade com a licença do kernel Linux, sua. Sua ultima versão foi em 2018 e há muitos recursos faltando conforme podemos conferir no link do Ethalabas porém, mesmo que não seja uma informação de conhecimento público, é uma biblioteca muito utilizada no mercado; então as empresas concentram esforços em sua continuidade.

Mais sobre a diet libc pode ser conferido aqui no blog

skalibs

 skalibs é um pacote que centraliza bibliotecas C pequenas e seguras utilizadas para a construção de todos programas da skarnet.org. A ideia é não ter que baixar e compilar bibliotecas grandes e se preocupar com problemas de portabilidade. skalibs está sob a licença ISC e pode ser baixada através do comando

git clone git://git.skarnet.org/skalibs

 ou através de seu repositório GitHub mirror.

Saiba mais sobre a origem da skalibs clicando aqui

Newlib

 Newlib é uma biblioteca fortemente focada em embarcado. Alias, essa é uma das bibliotecas mais amada pelos desenvolvedores de embarcados. É utilizado até mesmo pelos amantes de Dreamcast (e eu não gosto, né). Ela conglomera várias partes de biblioteca sob licenças open-source. e em seu site oficial só é disponibilizada na forma de código fonte.

 Possui suporte a mais ou menos 400 funções e requer threading. Nesse embalo surge a Relibc.

Relibc

 relibc é uma biblioteca C POSIX escrita em Rust. De origem do sistema operacional redoxOS e possui port para Linux. Foi desenvolvida para ser uma alternativa a newlib (por isso coloquei nessa ordem) no RedoxOS e também possuir suporte a system calls do Linux (se system calls Linux tem muito bem) por meio do sc crate.

• GitHub - redox-os/relibc: Mirror of https://gitlab.redox-os.org/redox-os/relibc
• Google Summer of Code/2021/Ideas/Redox Relibc Support - Gentoo Wiki
• Archive Project Details | Google Summer of Code

Bionic

 Bionic é a principal biblioteca do Android; foi construída com porões de bibliotecas do NetBSD,  do OpenBSD, porções de bibliotecas de FreeBSD e partes próprias. Está sob a licença BSD para evitar os conflitos que vem ocorrendo com a GPL; existe até uma política do Android de não haver programas sob GPL no user space do Android.

 Possui suporte a arquiteturas ARM e depois foi estendida a x86 além de suporte a interfaces do kernel Linux. existem algumas limitações como não possuir suporte a locales (até aonde me lembro, a musl também não possui quando tentei compilar o htop que descobri isso), a libthread_db ou libm e possui sua propria implementação pthreads baseada nos futexes do Linux. Existe um relato do Rob Landley que para poder executar o X11 no Android, seria necessário reescrever várias parte do X11 para ser compatível com a Bionic.

olibc

 olibc (Another C Library optimized for Embedded Linux) derivada da bionic, o objetivo da olibc é fundir as melhorias feitas por várias empresas de SoC como a Qualcomm, Texas Instruments, Linaro, etc. A olibc pode se beneficiar de recursos do ARMv7 como NEON, Thumb-2, VFPv3/VFPv4 e as ultimas otimizações de recentes versões dos compiladores.

PDCLib

 PDCLib (ou The Public Domain C Library) visa fornecer uma implementação completa do padrão C99 (nada mais, nada menos do que definido no ISO/IEC 9899. Nem mesmo outras extensões como POSIX) sob a licença CC0 ("No rights reserved").

 Foi desenvolvida originalmente por Martin “Solar” Baute em 2002 e depois de 10 anos, Erin Shepherd assumiu o desenvolvimento até 2018 que implementou muitos recursos significativos (o currículo da Erin é incrível). Em 2018, Martin retornou ao desenvolvimento da PDClib.

 A versão 1.0 ainda não foi disponibilizado mas a PDClib é boa para linkar ao kernel e possui suporte a 120 funções e não possui suporte. Tudo o que já foi implementado pode ser conferido no site oficial clicando aqui:

GitHub da PDCLIB

GitHub da Erin Shepherd

PDCLIB no GitHub do XboxDev

PDPCLIB

 Não confunda PDCLIB (The Public Domain C Library visto anteriormente) com a PDPCLIB (Public Domain Project C Library. Um P a mais e pode confundir dois projetos). Essa biblioteca faz parte do projeto PDOS (Public Domain Operating System) que se trata (digamos) de um clone antigo MSDOS. (mas com suporte tanto a 32 bits do Windows e do MSDOS. Há uma de suas distribuições com suporte a API MVS API em AMODE de 24, 31, 32 e 64 bit).

 A PDPCLIB é biblioteca do PDOS que visa ser uma biblioteca C que visa junto ao GCCMVS (um port do GCC para mainframes da IBM) produzir binários sem restrições devido a sua licença (domínio público). A PDPCLIB segue os padrões da ISO/IEC 9899:1990 (aka ANSI X3.159-1989 aka C90 aka C89) e funciona não somente no MSDOS, no Win32 e no  PDOS/386 mas também no OS/2, MVS (mainframe), CMS, VSE e AmigaOS. 

mlibc

 Escrita em C++, mlibc tem como foco ser totalmente portável e na modularidade. mlibc possui uma variedade de recursos POSIX/Linux/ANSI e é capaz de executar vários programas como Weston, GCC, LLVM, Bash, GTK2/3 e muitos outros mas sem perder o foco na portabilidade (assumindo poucas systemcalls do sistema operacional hospedeiro). Está sob a licença MIT.

mlibc - an existing libc with similar goals to LLVM libc - Runtimes / C - LLVM Discussion Forums

Libc11

 Como o próprio nome já menciona, é focada em ser escrita totalmente na implementação do padrão C11 (ISO/IEC 9899:2011)  e nada mais. Está sob a licença unlicense (public domain), teve seu inicio em 2014 porém seu desenvolvimento anda bem parado. Seu antigo site (http://libc11.org/) está fora do ar, mas existem alguns repositórios git que podem ser encontrados.

GitHub - public-domain/libc11: implementation of the C11 standard library

GitHub - dryc/libc11: A public domain implementation of the C11 standard library.

klibc

 Na computação, klibc é um subconjunto minimalista da biblioteca C padrão desenvolvida por H. Peter Anvin. Ele foi desenvolvido principalmente para ser usado durante o processo de inicialização do Linux e faz parte do espaço inicial do usuário, ou seja, componentes usados durante a inicialização do kernel, mas que não são executados no modo kernel.

Documentação sobre a klibc

Link para baixar a klibc no site kernel.org (e tem gente que acha que o site do kernel só tem kernel)

Mais sobre o Initramfs pode ser lido no site LWN.net

nolibc

 Essa é uma biblioteca do kernel Linux. Foi adicionada ao kernel 5.0 no commit 66b6f755ad45 como uma biblioteca mínima que fornece emulação de baixo nível quando o Linux for inicializado somente para executar um único e minúsculo programa.

 Foi criado por Paul McKenney ao trabalhar para reduzir o tamanho do initrd (que é de 40MB) e do initramfs (que é 10MB) gerados pelo comando mkinitramfs e pelo dracut onde a maioria das coisas eram inúteis. Assim, eliminando o que não era necessário para o dash (e a maioria eram coisas relacionadas a biblioteca), Paul conseguiu reduzir para ~2MB.

Nolibc: a minimal C-library replacement shipped with the kernel [LWN.net]

Neatlibc

 Neatlibc foi desenvolvida pelo iraniano Ali Gholami Rudi para focar principalmente em bootstrapping de seu compilador neatcc. a neatlibc possui suporte as arquiteturas x86, x86_64, ARM de 32 bits; há muitas funções que não são implementadas na neatlibc mas a maioria dos programas desenvolvidos por Ali (http://litcave.rudi.ir/) podem ser compilados com o neatcc e linkados a neatlibc.

Sortix Libc

 Escrita do zero para o sistema operacional Sortix OS, foi implementada grandes partes do padrão POSIX que permite ter suporte a ~70 partes de software de terceiros.

libslack

 Libslack é uma pequena biblioteca de utilidades gerais que foi projetada com uma coleção de módulos e várias funcionalidades para torar a programação no UNIX/C um pouco mais fácil. A principio foi implementada para ser parte do programa daemon embora alguns códigos datam de antes do do daemon. A libslack possui vários recursos que podem ser conferidos clicando aqui. Está sob a licença GPLv3 e disponível para Linux, Solaris/OpenSolaris,OpenBSD, FreeBSD, NetBSD, MacOSX/macOS, kFreeBSD e GNU/Hurd.

MyOS libc

 E por ultimo temos a myOS libc que resumidamente seria você mesmo desenvolver sua própria biblioteca C. A ideia é servir como uma das soluções mais óbvias implementando os recursos personalizados que precisa a seu kernel e ao resto do sistema operacional sem camadas de portabilidade. Outra parte interessante seria a melhor integração com funcionalidades do seu hardware.

 O artigo não inclui o link para o desenvolvimento da biblioteca, então eu resolvi adicionar por conta própria.

Newtime

 Newtime é uma biblioteca C que tem como foco demonstrar falhas sutis da biblioteca e como ela poderia ser hoje em dia já que foi escrita décadas atras. É a bibliotecas mais completa e hackeável com heurísticas desatualizadas. Está sob a licença 0BSD, a mesma do toybox. O autor desta time libc explica neste artigo com detalhes os erros da time libc e como ela poderia ser.

• https://github.com/lhrios/myos
• Creating a C Library - OSDev Wiki
• Writing Shared Libraries With D On Linux - D Programming Language (dlang.org)
• C Library - OSDev Wiki

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