Noticia um pounco (ou bem) atrasada, mas devido o ultimo vídeo do canal onde trato se o Alpine Linux possui bom desempenho além de sua principal característica (que é ser pequena e leve), então resolvi trazer essa noticia assim mesmo.
Além de conferir o desempenho do Alpine Linux em um benchmark comparado ao Clear Linux (o que é uma baita comparação), neste vídeo eu trago também uma novidade muito interessante que vale a pena ser conferida e até mesmo considerada adotar em projetos (quem sabe a equipe do Alpine Linux não venha a fazer isso).
No dia 23 de Março, Natanael Copa anunciou o lançamento do Alpine Linux 3.11.5. Não vou tratar quais as novidades já que se trata de um lançamento mais focado em correções de bugs. Caso queira saber mais sobre as novidades desta versão, aconselho a conferir o link clicando aqui. Aos amantes do Alpine Linux, fica a dica não somente desta nova versão mas também de conferir essa ferramentas muito interessante.
Certo, essa semana demos inicio novamente à serie Os Vários Sabores de Linux. Essa é a segunda temporada desta serie que todo mundo vive me pedindo para que volte e eu escolhi a distribuição Alpine Linux para dar a abertura:
OK. E por que vou contar como conheci essa distribuição? SIMPLES! Porque ela é importante. Essa é a base para me ter dado inicio a MUITO ALÉM DO GNU. Daí agora a indagação deve ser: "Como assim?"
Bora debater então. Antes de contar como conheci o Alpine, é preciso dar um passo atras, coisa de dois anos. Mais ou menos em 2010 ou 2011 eu li uma noticia de que já era possível compilar o Linux com o Clang. Isso me chamou a atenção porque podíamos usar outro compilador além do GCC. Fora que a primeira biblioteca que eu conheci que não fosse a tão divulgada GlibC foi a uClibc. Daí em 2012 eu estava pesquisando no Google sobre um carro da Renalt chamado Alpine. Esse da foto abaixo:
Renalt Alpine
E como o Google vinculou a pesquisa a o que pesquiso bastante (Linux), logo o Google me devolveu como resposta Alpine Linux. Daí pensei:
"Uma distribuição com o nome de Alpine? Bora ver o que ela tem a oferecer"
Viram como nem sempre é sinal de que estão te espionando?
Descobri que era uma distribuição que utilizava a Musl como biblioteca C padrão ao invés da GlibC e o busybox ao invés do Bash. Primeiramente procurei saber o que a Musl tinha oferecer (e me apaixonei) e segundo é que se ligarmos os fatos, uma distribuição com kernel Linux, com uma biblioteca C que não é do GNU, um terminal que não é do GNU (apesar que o Busybox é um agrupamento de coisas que já existem, mas o toybox não) e ainda podermos compilar tudo com um compilador que não seja o GCC me levou a fazer as seguintes perguntas:
"Quer dizer que Linux não possui vinculo obrigatório com o GNU? Quer dizer que Linux se estende a muito além do que GNU tem a oferecer? Ou seja, Linux não está limitado a GNU?"
E a resposta é: EXATO PARA TODAS AS PERGUNTAS!
Eu já era analista há quatro anos e não sabia disso. Eu a deveria saber até antes disso uma vez que já havia feito curso de LPI três anos antes desta descoberta e há anos usava KDE. Mas OK.
Você deve estar se perguntando:
"Mas então por que quando digitamos uname com as opções -a ou -o aparece escrito GNU/Linux?"
uname, uname -a e uname -o
SIMPLES! Isso acontece porque o comando uname que você utiliza foi desenvolvido pela comunidade GNU fazendo parte do pacote coreutils. Essa foi uma forma de promover a fraca ideia da obrigatoriedade do nome GNU/Linux. Falando de core-utils, ainda vai ter um vídeo no canal debatendo e destrinchando um pouco melhor o assunto.
man uname
Mas retomando o raciocínio, se baixarmos o toybox (seja código fonte ou binário), e digitarmos ./toybox aparecerá uma lista de comandos. Apesar de comandos que você provavelmente já conheça, todos estes comandos foram escritos do zero, inclusive o comando uname ;)
Comandos do toybox
Digitando ./toybox uname -a ou ./toybox uname -o, repare que aparecerá somente o nome Linux e não GNU/Linux.
Ele detém os direitos autorais sobre o nome Linux. É aí que eu acho a comunidade GNU incrível, defendem tanto que tudo deve ser livre e que tudo o que é proprietário é abominável mas brigam muito pelo direito do nome do seu sistema operacional livre aparecer em destaque em um nome proprietário... Alias, a comunidade GNU pediu autorização a Linus para chamá-lo de GNU/Linux? já que eles defendem o que é moralmente correto a ser feito, pedir autorização para tal uso é o que DEVE moralmente correto ser feito. Sabiam inclusive até que Linus poderia meter um processo nessa galera que quer forçar a todos a chamar de GNU/Linux pelo uso do nome Linux sem sua expressa autorização?
Fica então a matéria para meditação, aprofundem-se em conhecer melhor o sistema operacional que utilizam e azar de quem vier fazer dar chilique defendendo a GNU.
Agora o Alpine Linux passou a ter suporte inicial ao loongarch64 (que nada mais é do que um MIPS chinês) e o linux-firmware agora é compactado com o ZSTD.
Vi relato de que o desempenho dessa versão está tão bom que ao atualizar da versão anterior, o Alpine concluiu o Nextcloud container em menos de 10 minutos (só levou muito tempo por conta da transição do PHP 8.2 para 8.3 e precisou da instalação de algumas aplicações. O Nginx levou menos de 30 segundos e o Postfix menos de um minuto.
Quase cinco meses após o lançamento da ultima versão, é lançado o Alpine 3.10.0. Alpine Linux é uma distribuição orientada a segurança e leveza tendo como biblioteca C padrão a musl libc, o busybox como terminal de comandos e é fortemente utilizada no Docker. Quiser saber mais sobre o Alpine Linux, confira o vídeo no final deste artigo; mas vai com calma, leia o artigo também ;)
A primeira versão da série 3.10.x traz como novos recursos o suporte a Pine64LTS, iwd que é uma alternativa moderna ao wpa_supplicant (EAP ainda não está funcionando); suporte a ethernet e portaserial para placas arm; ceph (que é um sistema de arquivos e armazenamento para objeto distribuído (distributed object store and filesystem) e o lightdm como cross-desktop display manager.
Houveram atualizações significativas também como kernel Linux 4.19.52, GCC 8.3.0, Busybox 1.30, musl libc 1.1.22, LLVM 8.0.0, Go 1.12.6, Python 3.7, Perl 5.28, Rust 1.34.2, Crystal 0.29.0, PHP 7.3.6, Erlang 22.0.2, Zabbix 4.2.3, Nextcloud 16.0.1, Git 2.22.0, OpenJDK 11.0.4, Xen 4.12.0 e Qemu 4.0.0. Houveram remoções de programas também como Qt4, Truecrypt e o Mongodb. As mudanças podem ser conferidas no Git Log e no Bug Tracker do Alpine.
Natanael Copa agradece a todos que enviaram patches, bug reports, novos aportes de atualização, escreveram documentações, mantiveram a infraestrutura e que contribuíram de outras formas. E também não deixa de agradecer as empresas por prestar suporte em hardware e hospedagem:
Como sempre antes de começar (e antes que alguém me pergunte o que é Alpine Linux), vamos para o arrebento... Alpine Linux é uma distribuição segura, pequena e leve que faz uso da musl como biblioteca C no lugar da GlibC e do Busybox como terminal no lugar do Bash. Outras distribuições já passaram a adotar a musl como biblioteca C padrão assim como o Alpine e há até mesmo planos para o Debian fazer o mesmo (como já houve no passado). Há outras características do Alpine Linux que podem ser conferidos no vídeo da série Os vários sabores de Linux.
Esse lançamento trata-se mais de uma versão de correções de bugs, de segurança e de incompatibilidades; mas há uma coisa que eu não quis deixar de mencionar. Apesar de Linus Torvalds já ter explicado para não adotar o ZFS devido a incompatibilidade entre as licenças do kernel e o sistema de arquivos, Linus afirma que você pode utilizar por sua conta e risco.
E parece que é exatamente isso o que Natanael Copa fez pois neste lançamento eu descobri que Natanael Copa agora mantem uma versão LTS do ZFS na main line no kernel 5.4.12-r1.Se vai dar 3#r?@ ou não, a gente vai descobrir com o tempo. Foram mais de 70 correções e que podem ser conferidas clicando aqui.
O Alpine Linux contou com 6543 commits de indivíduos que enviaram patches, realizaram testes, reportaram bugs, escreveram documentações e muito mais. Também podemos mencionar a colaboração das empresas GIGABYTE, Linode, Fastly, IBM, Equinix Metal, vpsFree e ungleich.
Alpine Linux preparando-se para migrar para o apk-tools versão 3.0
apk é o gerenciador de pacotes da distribuição Alpine Linux; a distribuição que me fez conhecer, analisar e me apaixonar pela biblioteca C musl. É também a distribuição onde me fez surgir a ideia de muito além do gnu por se tratar de uma distribuição que substituição a maioria das ferramentas gnu de sua base. Eu já relatei sobre essa distribuição na série Os vários sabores de Linux então, antes de darmos continuidade, confira o vídeo aí:
É comum haver vários gerenciadores de pacotes no mundo Linux. Sem entrar em muitos detalhes e indo para o mais comum, o Debian e derivados possuem o APT, derivados do Fedora possuem o YUM (e adotando o dnf), Suse possui o Zipper, o Gentoo possui o Portage, o pkgtools e o slackpkg, existe também o snap, o flatpak e a lista vai longe... E por que desenvolver mais um gerenciador de pacotes em meio a uma imensidão deles?
Apesar de já existirem tantos, há motivos reais e específicos para Natanael Copa ter criado o apk. Uma das coisas que me chamou a atenção foi a sua sintax mais simples, o que para o sisadmin é muito interessante. Ao invés de seguir todo um roteiro como no APT de atualizar a base de dados para depois buscar ou instalar algum programa ou atualizar o sistema (e as vezes ainda ter que utilizar o update-rc.d), no apk basta utilizar um único passo como demostrado na imagem abaixo:
Demonstração do APK e do APT
Já outros motivos interessantes seria uma base de código limpa que fez com que a distribuição Adélie Linux, mesmo que baseado no Gentoo, abandonasse o Portage e adotasse o apk. Na imagem abaixo são apresentados mais motivos para o seu desenvolvimento. Acho que é um gerenciador de pacotes que vale a pena ser estudado (e até mesmo adotado. Por que não?)
O que torna o apk-tools rápido
No dia 23 de Janeiro, Ariadne Conill sugeriu como será realizada a migração para a versão 3.0 do apk-tools. A primeira coisa é que o APKv3 deve manter o suporte aos pacotes do APKv2 por um período de tempo (digamos que o óbvio) permitindo uma migração mais segura e com bons testes. Mesmo não tendo muitos detalhes, a linha de raciocínio seria mais ou menos a seguir:
apk-tools 3.0 será lançado nos repositórios de testing.
Usuários que optarem pelo repositório testing, poderão optar pelo apk-tools 3 se desejarem adicionando-o como dependência (apk add apk-tools@testing).
apk-tools 3 utilizar os índices do APKv3, enquanto que o apk-tools utilizará os índices legacy do APKv2.
Se o apk-tools 3 for considerado estável e o suporte a pacotes APKv3 for considerado completo, ele substituirá legacy apk-tools no Alpine 3.12.
Em algum ponto, migrarão para os pacotes APKv3 e encerrarão o suporte aos indices do APKv2 e chamarão esse lançamento de Alpine 4.0.
Ariadne sugere para as outras distribuições também adotarem a mesma estratégia. Em um eventual problema, simplesmente mantem na versão 3.13 ao invés de 4.0. Também está em aberto como o apk-tools-static será tratado. Mais detalhes estarão disponíveis quando tiverem um plano específico. Por hora é só o que informaram.
Foi lançado nesta Quarta feira (30/01/2019) a versão 3.9.0 da distribuição Alpine Linux, a primeira versão estável da série v3.9. Essa nova versão trás novos recurso e novos pacotes, suporte a armv7, migração do LibreSSL para o OpenSSL, Modloop está sendo desenvolvido, melhorias do suporte ao GRUB (usuários do GRUB dever conferir se seu config é gerado corretamente e possui media de boot de emergência preparado).
Além dessas novidade, a distribuição Alpine Linux 3.9.0 faz uso do kernel Linux 4.19, GCC 8.2.0, Busybox 1.29 (e espero que o toybox venha a ser uma opção padrão no Alpine Linux), musl libc 1.1.20, Go 1.11.5, LXC 3.1, PostgreSQL 11.1, Node.js 10.14.2, Crystal 0.27, Zabbix 4.0.3, Nextcloud 15.0.2. O Firefox está disponível somente para x86_64 (AMD64) devido a linguagem Rust.
Alpine Linux é uma distribuição segura, pequena e leve que faz uso da musl como biblioteca C no lugar da GlibC e do Busybox como terminal no lugar do Bash. Outras distribuições já passaram a adotar a musl como biblioteca C e há planos também por parte do Debian para a sua adoção (como já houve no passado).
Drew DeVault trabalha em adicionar melhor suporte a RISC-V na musl enquanto trabalha no port do Alpine Linux para a arquitetura baseado no patch abaixo:
Drew já escreveu três patches e integrou outro que foi encontrado no github ao seu port. Em contato com a equipe da musl, Ricth Felker solicitou a lista de contribuidores para conferir se não há omissões de nomes; o que foi lhe passado um dia depois. Vale acrescentar aqui que o toybox também receberá port para a arquitetura que é bem promissora.
Alpine Linux é uma distribuição segura, pequena e leve que faz uso da musl como biblioteca C no lugar da GlibC e do Busybox como terminal no lugar do Bash. Outras distribuições já passaram a adotar a musl como biblioteca C e há planos também por parte do Debian para a sua adoção (como já houve no passado). Há outras características do Alpine Linux que podem ser conferidos no vídeo da série Os vários sabores de Linux.
Seis meses depois do lançamento da ulta versão 3.10, aqui vamos nós para mais um lançamento para finalizar o ano. Esse é o primeiro lançamento da versão 3.11 que traz o kernel Linux 5.4 (linux-lts), suporte a Raspberry Pi 4 (aarch64 and armv7), suporte inicial aoGNOME e ao KDE; suporte for Vulkan, a MinGW-w64 e a DXVK. Houveram também várias atualizações e mudanças (kernel vanilla foi removido; Python 2 foi descontinuado na distribuição. Automaticamente os pacotes Python 2 foram removidos. Pacotes agoram utilizam /var/mail ao invés de /var/spool/mail de acordo com a FHS (https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch05s11.html) e o clamav-libunrar não é mais uma dependência do clamav que precisa ser instalado manualmente).
Alpine Linux é uma distribuição que, tem como foco, fazer uso da musl como biblioteca C padrão no lugar da GlibC e do busybox no lugar do Bash. Espero que no futuro substituam o busybox pelo toybox por se tratar de um terminal bem menor e mais fácil de manter, porém com quase todos os mesmos recursos (prova disso é já ser usado por padrão no Android desde a versão Marshmallow). Inclusive o toybox está nos repositórios do Alpine Linux:
No dia 26/05/2022, Natanael Copa anunciou o lançamento do versão 3.16.0 da distribuição Alpine linux. Essa nova versão tem como novidades a melhorias no suporte a NVMe, o comando sudo foi movido para o repositório community (somente últimas versões estáveis receberão atualizações de segurança. Foi sugerido também a substituição para doas ou doas-sudo-shim); novo script setup-desktop para facilitar a instalação de ambiente desktop além de várias melhorias em scripts; possibilidade de adicionar chaves SSH e criação de usuário administrador.
Essa é uma versão de correções de bugs que corrige arquivos dtbs ausentes para a imagem initramfs no netboot (e parece que é só isso...). A lista completa das alterações podem ser conferidas no git log e no bug tracker. Está bom, é só isso mesmo. Também, convenhamos, véspera de natal; vamos é dar uma descansada.
Hoje foi anunciado o lançamento do Alpine Linux 3.13.0 (a primeira versão estável da série v3.13). esta versão traz o kernel Linux 5.10.7, ZFS 2.0.1, musl 1.2, GCC 10.2.1, Busybox 1.32.1, Git 2.30.0, Knot DNS 3.0.3, MariaDB 10.5.8, Node.js 14.15.4, Nextcloud 20.0.4, PostgreSQL 13.1, QEMU 5.2.0, Xen 4.14.1 e Zabbix 5.2.3.
Além dos mencionados, agora o Alpine possui suporte a cloud images (../cloud) oficial, suporte incial ao cloud-init, introduz o novo ifupdown-ng (que é um substituto para o ifupdown do busybox), melhorias no suporte a rede wifi e muito mais
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.
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 2007por 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.
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.
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 systemrunit 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.
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
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.
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.
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.
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.
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.
Essa é uma biblioteca do kernel Linux. Foi adicionada ao kernel 5.0 no commit 66b6f755ad45como umabiblioteca 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.
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.
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.
