Essa nova versão traz na versão somente correções de bugs (um total de 10 correções) e melhorias na parte de segurança. Dentre as correções as mais importantes são a do 7zip, nas entradas do ar, duas no lha sendo uma na truncação inteira em sistemas de 32 bits e uma que não permite tamanhos negativos (até porque não faz sentido); uma no shar que confere o retorno do valor, uma no rar que não nomes ridiculamente longos; uma de loop infinito no xar e muitos outras na versão do Windows.
Implementação do comando cpio do projeto libarchive
Muitas outras correções foram feitas mas podem ser conferidas nas notas de lançamento do projeto.
ClonOS - Uma alternativa ao Proxmox baseado no FreeBSD
Depois que Xen server passou a ser pago, muitos profissionais passaram a migrar os seus clientes para outra solução como o Proxmox, o xcp-ng, o oVirt e até mesmo o Openshift da Red Hat que possui suporte a virtualização; a Nutanix também entra nesta briga como uma briga como concorrente da VMWare e muitas vem migrando para containers o máximo de aplicações possíveis e que pode gerar economia ainda maior:
No ano passado, a VMWare foi adquirida pela Boradcom pelo valor de US$ 61 bilhões (uma das mais caras aquisições da indústria de tecnologia). Após esta aquisição, os produtos e serviços da VMWare passaram a ficar mais caros e consequentemente, as empresas que as possuíam, passaram a buscar outras soluções em virtualização. Há empresas que já mantinham outras alternativas de virtualização atuando paralelamente dentro de suas infraestruturas exatamente para se prevenirem de casos inesperados (lógico que tudo isso tem um custo que a curto prazo pode parecer caro, mas não quando necessário remediar a situação). Bom, e no meio de tantas soluções de virtualização no Linux (Linux é o sistema operacional com o melhor suporte a virtualização que existe), uma equipe desenvolvedores de FreeBSD decidiu projetar uma alternativa que a chamaram ClonOS.
ClonOS: Uma alternativa ao Proxmox Baseada no FreeBSD
ClonOS é uma plataforma baseada no FreeBSD e no framework CBSD que eu já abordei aqui no blog no artigo CBSD sendo portado para DragonflyBSD. O ClonOS vem com interface web para facilitar o controle, deploy e gerenciamento dos containers jails do FreeBSD e dos ambientes de virtualização tanto do Bhyve quanto do Xen. Além disso, o ClonOS disponibiliza suporte ao 9p (sistema de arquivos do plan9 utilizado o WSL) para ser utilizado no compartilhamento de diretórios do bhyve via virtio-p9; Bhyve management para criar e excluir VMs; conexão com console "físico" de convidado via VNC do navegador ou diretamente pelo sistema; monitoramento em tempo real; acesso a estatísticas de carga através do SQLite3 e beanstalkd; suporte a ZFS; import/export de ambientes virtuais; repositório público com virtual machine templates e ajuda baseada em puppet para a configuração de serviços populares. Há ferramentas que estão em andamento.
Eu venho promovendo linguagem Nim desde que eu a conheci no projeto Glaucus. Eu simplesmente amei a linguagem por suas características; possui a tão cobiçada segurança de memória que todos tanto almejam na linguagem Rust (ambas oferecem com técnicas diferentes apesar que estão prevendo Rust trazer garbage collector em futuras versões ¬¬), o desempenho da linguagem C e sintax que lembra muito Python tornando o desenvolvimento mais simples e mais fácil de manter. Então sim, eu quero promover a linguagem Nim. Então vamos a o que interessa.
No dia 26 de Outubro acontecerá o quarto NimConf, o NimConf 2024. O primeiro ocorreu em 2020, o segundo em 2021 e o terceiro em 2022. Tiveram um intervalo de um ano e agora estão de volta. As apresentações serão gravadas e os autores participarão com a audiencia via chat; esse é um formato que eu não goste muito. Prefiro a apresentação em tempo real para uma questão de interação (algo que eu gosto muito de fazer) e durarão de 10 à 45 minutos. Os tópicos só poderão ser relacionados a linguagem Nim.
Se você tiver um projeto escrito na linguagem Nim e quiser ser participante, você pode preencher o formulário clicando aqui até o dia 15 de Setembro. Uma vez que a equipe entrar em contato, você deverá enviar o seu vídeo até o dia 13 de Outubro. A equipe o encoraja a considerar utilizar o NimbleSlides com o NimTheme em sua apresentação, o Nimib para converter seu código Nim para documento HTML (uma boa forma de promover a linguagem). O vídeo abaixo é um exemplo de uma apresentação do NimbleSlides com o NimTheme:
No dia 31/7/24 Jeff Wittich, Chief Product Officer da Ampere anunciou o AmpereOne® Aurora, o processador ARM voltado a convergência da IA com a nuvem. O AmpereOne Aurora é focado em eficiência energética, ser implantável em qualquer data center já existente e aceleração de IA diretamente no SOC.
O AmpereOne® Aurora possui mais de 512 núcleos entregando acima de 3 vezes mais performance do que os atuais processadores da própria Ampere (realmente, se comparado com o artigo Toca do Tux: Resultados da pesquisa ampere, que o máximo eram 192 núcleos, o que já é surpreendente, o AmpereOne Aurora superou muito as próprias expectativas), escalabilidade com base de dados RAG e de Vetores permitindo conexão transparente de todos os tipos de computação e pela primeira vez o IP IA da Ampere integrado diretamente no silício. Com isso, o AmpereOne Aurora entregará melhor desempenho por rack para todos os tipos de serviços empregados.
Como a necessidade por IA vem crescendo muito nos últimos anos, a Ampere desenvolveu o Aurora para suprir essa demanda. O Ampere One Aurora é eficiente tanto em consumo de energia quanto custo para ser implantado solucionando o grande desafio de empregar inteligencia artificial nos dias de hoje.
No dia 15 de Julho, Marta Lewandowska da Red Hat, apresentou no DevConf 2024 realizado na República Tcheca um novo esquema para substituir o carregador de boot GRUB por uma solução mais segura e mais rápida. Apesar do GRUB possuir suporte à uma variedade de arquiteturas, de sistemas operacionais e de recursos, estes recursos geram complexidade muito grande para mantê-los. Exemplo disso é que existe uma serie de vulnerabilidades encontradas no GRUB desde 2021 e que não há previsão de solução devido o tamanho desta complexidade.
Vulnerabilidades do GRUB
Já que a base de desenvolvedores do kernel é muito maior e beneficia todo um ecossistema com rápido desenvolvimento de recursos e rápida resposta a correções de vulnerabilidades, a ideia é apresentar uma solução para estes problemas utilizando o kernel Linux como seu próprio bootloader. Essa solução é chamada o nmbl (pronuncia-se nimble e é a abreviação de no more boot loader), uma imagen unificada do kernel Linux (UKI) que contem kernel command line, o initramfs que é um arquivo formatado com o filesystem ExFAT que contendo lá dentro drivers, comandos e scritps (mostrei isso no artigo E quem em sã consciência ainda utiliza Ext2? Quase todo mundo :V) e efi stub (systemd-stub) e um menu parecido com o GRUB além de drivers, filesystem, rede e duplicação de código que ocorre no GRUB é evitado. Tudo o que é necessário para o carregamento do sistema operacional.
Fedora sendo inicializado pelo nmbl
Há duas variantes disponíveis do nmbl sendo uma que carrega diretamente o kernel e outra que permite executar outro kernel passando pelo UEFI (já que o nmbl oferece a opção de carregar diferentes versões do kernel). A IBM demonstrou interesse no nmbl e em breve poderemos ter o nmbl disponível para outras arquiteturas.
Há mais ou menos 10 dias foi lançada a versão 2.0.6 da liguagem Nim. No dia 03 de Julho de 2024 a equipe da linguagem lançou a versão 2.0.8 (seu quarto patch release) contendo 20 commits e trazendo melhorias importantes.
Agora o alocador Nim é muito mais estável com a opção --threads:on; possui melhor suporte ao gcc14, otimização de setLen(0) para strings e seqs ilimitados; otimização de move for utilizado com --mm:refc. Também houveram oito correções de bugs.
Hoje (dia 17 de Junho de 2024) foi lançada a versão 2.0.6 da linguagem de programação Nim. Desde que eu escrevi o artigo Rust no Linux: Um caso de amor e ódio, eu venho divulgando a linguagem Nim para promover mais linguagens que possuem recurso Memory Safety. Nim é uma linguagem de propósito geral inspirada em Python, C++, Ada, Modula-3 e Lisp. Seu recursos mais importantes são type e resource safety, meta programação e combinar confiabilidade com syntactic convenience.
Foi desenvolvida por Andreas Rumpf que é possui diploma de ciências da computação pela universidade de Kaiserslautern na Alemanha e que possui interesse em pesquisas que incluem hard realtime systems, sistemas embarcados, construção de compiladores e inteligencia artificial. Nim está disponível para Linux, FreeBSD, macOS, OpenBSD e Windows nas plataformas X86 (de 32 e 64 bits) e ARM.
Esse é o maior lançamento para o Nim 2.0.x (contando com 200 commints) de correções de bugs e melhorias desde o lançamento da versão 2.0.4 há dois meses atrás. A rasão para esse lançamento é devido ao planos de lançamento da versão 2.2. Ao todo, a versão 2.0.6 conta co 84 correções de bugs que podem ser conferidas na nota de lançamento.
A equipe aceita doações para continuar melhorando a linguagem, corrigindo bugs e adicionando novos recursos. Doações podem ser feitas através do
Laurent Bercot, autor do primeiro projeto skarnet.org, anunciou no dia 07/06 novas versões de alguns dos pacotes do projeto que são focadas em qualidade de vida, melhoria de suporte a plataformas antigas e preparação para futuras grandes atualizações. Para quem não sabe, Laurent foi um dos primeiros a desafiar Richard Stallman mostrando que não existe GNU/Linux. Todo o processo de como ocorreu pode ser lido no artigo O dia que Laurent Bercot calou Richard Stallman: Eu não uso GNU, eu uso Linux! aqui no blog.
MUDANÇAS MENORES
A skalibs-2.14.2.0 (principal grupo de bibliotecas do projeto) traz suporte ao ambiente midipix e versões antigas do MacOS; agora possui também mais funções a cspawn para a melhoria do uso do posix_spawn().
O execline-2.9.6.0 (linguagem de script do projeto) agora adiciona a opção elglob -d para codificar o resultado de um glob em uma unica palavra. também adiciona importas -S para importar uma variável com o mesmo nome como valor substituto assim como o antigo comando import.
execlineb, principal comando para executar os scripts do execline
O arquivo tipidee.conf da tipidee-0.0.5.0 agora aceita "" como um indicador de extensão para diretiva de tipo de conteúdo, que permite o usuário especificar tipo de conteúdo padrão para arquivos sem uma extensão.
MUDANÇAS MAIORES
Esses foram lançamentos menores, já o s6-2.13.0.0 traz mudanças maiores e significativas como o s6-supervise agora rastreia o endereçamento de um grupo de processo de serviço que é útil para situações como se caso precisar encerrar todo um grupo processo (digamos) zumbi quando o serviço morre e você não estiver utilizando cgroups e por fim acabar deixando processos filhos. Esse recurso ainda não está pronto já que daemons normalmente não mexem com grupos de processos e um serviço com mal comportamento pode criar um processo filho em grupos de processos diferentes. Enquanto o serviço estiver em execução, o s6-svstat -o pgid exibe o id do grupo do processo e o s6-svc -K pode enviar o sinal SIGKILL ao grupo (asim como o -P para o SIGSTOP e o -C para o SIGCONT). Um pequeno bug também foi corrigido e um limite arbitrário foi aumentado no s6-ftrigrd: Um serviço agora pode esperar quantos fifodirs quiser.
Josiah Frentsos enviou um patch para o s6-supervise: para não adicionar '(child)' ao final do PROG por ser desnecessário, o que foi aplicado por Laurent:
" Ha. Aplicado, obrigado! Obrigado também por confirmar que o melhor jeito de obter contribuições é cortar um lançamento. ;)"
Já Carlos Eduardo enviou antes do lançamento seu patch para executar a daemon como um child de sdnotify-wrapper. O que tem gerado debate no projeto e até então, não foi aceito.
LANÇAMENTO
Ainda dentro do conjunto do supervisor s6, o s6-rc-0.5.4.3 também recebeu aumento de um limite arbitrário podendo um fd-holder interno agora recarregado automaticamente com quantos pipes ele puder manter.
Houve refatoração de algumas APIs para permitir implementação de dns-0x20 no s6-dns-2.3.7.2 que é util para interoperar com versões recentes de Unbound. O shibari-0.0.1.1 também implementa o dns-0x20. Também ocorreram mudanças menores em outros pacotes como s6-networking-2.7.0.3, mdevd-0.1.6.4 e smtpd-starttls-proxy-0.0.1.4 que não foram mencionadas aqui mas que podem ser conferidos direto no projeto.
DOCUMENTAÇÕES
As documentações também receberam atualizações por parte do australiano Alexis (flexibeast) que faz contribuições para o Gentoo 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.
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.
![[announce] skarnet.org June 2024 update](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi5PxUdtIcld2K7XHvoYc4HxN_PPd287KhQH2IWAe50mFmslQ7zjI_sZutcce85ZtAa1N9o_muk7UU-n2iFyJ5MdY0RI-nf9PNubLcDF_i2tCRFlwXr91b86Q8jMaoSijUUP9J2r0Xp8O6VSoYRmBzL6CjWmLPEdc1KvFgCUSCGEDjAQoOQdBpoucAwAPI/s1600/skarnet.org:%20Atualiza%C3%A7%C3%B5es%20de%20Junho%20de%202024.jpg "skarnet.org: Atualizações de Junho de 2024")
