 |
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 e há exemplo real disso que é o caso do Android que se beneficiou de Rust tendo redução de 76% para 24% de seus bugs; por outro lado 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á por outro lado, outros projetos poderão ser afetados ao adotar Rust tanto que há programas que 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 possuir menos dependências (1; 2. Valeu Nilton por compartilhar estas informações); o projeto Prisma que migrou de Rust para JavaScript e que tornou seu código 90% menor, mais de 3,4 vezes mais rápido, utilizar menos uso de CPU, ter menos complexidade no deploy e mais fácil de a comunidade fazer contribuições (23 de Julho de 2025: Prisma ORM Rust to TypeScript Migration: Rationale, Benchmarks, & GA launch, Prisma ORM without Rust: Latest Performance Benchmarks). Outro grande exemplo de projeto que foi prejudicado ao adotar Rust é o Ubuntu que ao adotar o Rust coreutils, teve seu desempenho afetado em até 17 vezes se comparado com as ferramentas tradicionais.
É questão de adotar o que se adéqua ou não a necessidade corretamente (aprendam isso). Honestamente, esta terceira opção é a mais provável que venha acontecer com o kernel Linux. Sim, eu vejo isso acontecer e sou bem pessimista quanto a Rust.
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 |
.jpg)
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:
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 uso deste recurso.
O tinycc possui a opção -b (bound checker) há no mínimo 15 anos... E o GCC há uns 10... E se perguntar para boa parte dos que estão estão com fascínios por Rust, eles nem sabem disso...
 | ||
Bound checker no tinycc
|
 |
| Opção -b em invoke no manual do tinyCC |
Fora o recurso 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.
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 |
 |
Hare: Uma nova linguagem C? |
Assim como C, Hare pode ser utilizada para escrever sistemas operacionais, ferramentas de sistemas, software de rede de computadores e várias outras ferramentas de baixo nível e de tarefas de alto desempenho. Já existem relatos de sistemas operacionais escritos em Hare como o sistema operacional microkernel Helios inspirado no seL4 e um clone do Unix chamado Bunix que por ter sido inspirado no design do Linux, levou menos de 30 dias para um único desenvolvedor escrevê-lo e aprender bastante coisas sobre sistemas operacionais de kernel monolítico.
 |
| Processo de boot do Bunnix |
Outros projetos também já foram implementados em Hare como OpenGL, Raytracer, gerenciador de senha, ferramenta de criptografia, bindings para GUIs simples, um substituto para o cron, um shell rc inspirado na implantação do plan9 e muito mais.
Outra característica é que Hare compartilha alguns recursos da linguagem Go como defer e design de biblioteca. Um fator que acredito que poderia atrair mais usuários e desenvolvedores para a linguagem Hare seria a adicionar as macros que não foram possíveis adicionar na linguagem C e assim dando origem a linguagem Odin.
Hare está disponível sob os termos da the Mozilla Public License (MPL) e é tão pequena que cabe em um floppy disc de 3½". Ainda está na versão 0.24.2 e só entrará para uma versão comercial quando chegarem na versão 1.0.
|
| 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.
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.
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 (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 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).
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 é 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 é 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.
Existe a biblioteca ELL (Embedded Linux Library) desenvolvida pela Intel. https://github.com/bdragoncore/ell
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 (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 (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:
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.
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
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.
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.
Mais sobre o Initramfs pode ser lido no site LWN.net
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.
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 é 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.
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 é 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.
