musl é uma nova biblioteca padrão para dar poder à uma nova geração de dispositivos baseados em Linux. musl é leve, rápida, simples, livre e se esforça para ser correta no senso de padrões de conformidade e de segurança.
A musl segue o padrão POSIX 2008 base a risca e é possível ver durante o processo de compilação que é adotado fortemente o padrão ISO C99 na biblioteca e um número de interfaces não padronizadas para ter compatibilidade com funcionalidades entre Linux, BSD e a glibc:
musl está sob a licença permissiva MIT e possui suporte as arquiteturas x86 (32/64), ARM (32/64), MIPS (32/64), PowerPC (32/64), S390X, SuperH, Microblaze, OpenRISC.
Veja o vídeo da série Muito além do GNU para saber melhor sobre a Musl
Mas o que falta então para que musl se torna padrão nas distribuições Linux?
Assim como no LLVM/Clang (e é o que a comunidade LLVM mais reclama), é que faltam algumas extensões GNU extremamente importantes presentes somente no GCC e na GlibC e que não são documentadas pela comunidade GNU. Se vocês quiserem saber algo sobre essas extensões, é necessário entrar em contato com a comunidade GNU e perguntá-los sobre elas (e para eles responderem... aí já é outras história). Isso acaba dificultando que alavanquem e acaba amarrando projetos a ficarem dependendo das ferramentas que o GNU tem a oferecer (chega a ser estranho falar de liberdade...)
Faltam também um monte de localizações, dados, um monte de bloat do GNU (que acontece a mesma coisa), Name Service Switch, (NSS), serviços de rede, biblioteca (libnsl em específico) e 80+ CVEs. Quando esses recursos forem adicionados a musl, podem ter certeza, adeus glibc.
Apesar do que ainda falta para a sua melhor adoção (que estão trabalhando fortemente para ter por completo e que há longa data já é boa o suficiente para colocar em um ambiente de produção), a musl já apresenta suas viabilidades em comparação a glibc. Basta comparar o resultado final das duas:
Comparação de tamanho final de um binário entre musl e glibc.
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 é 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.
No vídeo "O que é daemon init?" eu mencionei que existem várias daemons init (ou init systems) diferentes disponíveis. porém mencionei somente as (digamos) mais populares como o rc (run command) do Unix mais ou menos na versão 10 e que foi herdado pelos BSDs e pelo slackware, o SystemV (ou sysvinit que introduziu o conceito de runlevels que é uma especificação declarativa de serviço de sistema). O holandês Miquel van Smoorenburg é o autor da versão do sysvinit para Linux. Miquel fez também o primeiro port do Debian para a arquitetura Alpha e tem como símbolo um Tux bebinho de tudo).
Olaunchd do Mac OS X, o OpenRC originado no Gentoo, o Upstart originado no Ubuntu e o systemd originado no Fedora. O vídeo pode ser conferido logo abaixo:
Então por que não debater sobre outros init systems diferentes? Vale começar pelo NetBSD que, como mencionei no vídeo, o NetBSD migrou da init BSD para uma versão da SystemV.
O Solaris possui o SMF (Service Management Facility= Facilidade de Gerenciamento de Serviço que também é uma das inspirações para a criação do systemd). Esse init system faz uso de arquivos XML ao invés de init scripts, é utilizado no IllumOS (já que é um fork do antigo OpenSolaris) e no OpenIndiana que é uma distribuição derivada do IllumOS. Agora, vamos a mais um monte de outros init systems.
Quero começar com rc específico do Plan9 (não confunda com o rc dos BSDs e do Slackware) que é um shell que soluciona o problema de white space que ocorrem em outros shell no padrão POSIX (como o bash). O que acontece é que os scripts de outros shells quebram caso os nomes dos arquivos possuam espaço como no exemplo:
for i in *.jpg; do
cp $i /tmp
done
Já o plan9 rc lida com esse problema utilizando um recurso chamado Free Carets inserindo o operador ^ automaticamente entre as palavras. O Plan9 rc possui sintax diferente mas um exemplo de como ele soluciona o problema pode ser conferido abaixo:
É um init system alternativo que incorpora as ideias da sysVinit, do simpleinit, do daemontools e do make que visa cuidar de processo paralelo (assim como o systemd e o launchd), dependências, roll-back, pipelines, melhorias no signaling e desmontar filesystems no desligamento (assim como o systemd possui recurso parecido). Falando em desmontar no desligamento, no dia 20 de agosto foi adicionado ao Systemd a ferramenta para montar filesystems. O interessante é que o Depinit possui comando parecido com o systemctl do systemd chamado depinctl. O Depinit, está sob licença GPLv2 e ainda está em fase experimental sendo disponível para Linux e FreeBSD. Sua ultima versão foi lançada em maio de 2014 (a versão 0.1.4).
É um init Unix Cross-platform com supervisão de serviço operando em três estágios obtidos em /etc/runit. Ela está disponível para Linux, FreeBSD, Mac OS X e Solaris e pode ser facilmente adaptada para outros Unixes. Os direitos autorais são reservados ao desenvolvedor da daemon. Hoje essa daemon é adotada pela distribuição Void Linux e tendo também suporte do Busybox.
É possível utilizar runit sem substituir o atual init system que estiver utilizando em sua distribuição simplesmente executando o stage 2 do runit como um serviço do seu atual init.
É uma alternativa a implementação do /sbin/init para Linux e FreeBSD, mas parece que anda em decadência. Apesar disso, é um bom init para dispositivos embarcados e é bem modular. possui runlevels nomeados modes que é descrito em um arquivo XML a parece-se um pouco com a runlevel do Gentoo.
É a daemon init da distribuição Turka chamada Pardus. É uma versão paga do Linux pelo que me lembro de ter visto anos atrás. É difícil conseguir informações nesse site desde que não possui versão inglesa (parece que os caras não querem mais nenhum outro país por lá rsrs. Essa seria uma boa distribuição para entrar para os "50 lugares onde Linux está rodando e você nem faz ideia), mas essa init trabalha com um subsistema init chamada Mudur que é escrito em python e um sistema de gerenciamento de configuração chamado Çomar.
É um init system para Linux na versão do kernel 2.6. Foi projetado tendo como foco a facilidade na configuração e a não intromissão, ser pequeno para funcionar tanto em distribuições grandes e minimas. Esse init não possui dependências externas além da biblioteca C, dos pthreads do kernel e sugerido um /bin/sh funcional. Ele possui um sistema de logs para boot, runlevels em ASCII, um único arquivo de configuração conveniente; recursos automáticos como hostname e montagem do sistema de arquivos virtual (como o /proc) e vários outros recursos. Vale a pena conhecer esse init system:
É uma daemon (ainda em versão beta) feita pelo alemão Felix von Leitner, mesmo criador da dietlibc e do embutils. Além de visar ser minuscula (característica típica do Felix e que faz isso muito bem) também visa corrigir alguns erros cometidos pelos init systems tradicionais no Linux. Se quiser saber mais sobre a diet libc e do embutils, assista o vídeo abaixo:
O processo de boot das típicas distribuições Linux é muito sofrido
Se um boot script falhar, todo o processo de boot é interrompido
Se um serviço for interrompido via o comando kill, ele não é automaticamente reiniciado (se tornando um processo zumbi)
O script de shutdown não sabe qual o PID da daemon (modos de falhas horríveis onde você acidentalmente mata o processo errado)
E a falta de flexibilidade (iniciar mais um ou um serviço a menos?).
No minit, cada serviço possui seu próprio diretório dentro de /etc/minit contendo dependências e dentre outros recursos. Dentre os problemas a serem solucionados pelo minit estava o de reduzir o período de downtime (que é também uma das ideias do systemd).
cinit é um init system com recursos de dependência e suporte a perfil que foi baseado no design no minit. Devido o minit não possuir suporte a dependências reais (o que leva a você não saber se o serviço que você depende foi realmente iniciado) e seu conceito de dependência ser lento, o suíço Nico Schottelius para suprir estas necessidade.
O cinit possui características semelhantes ao systemd: parallel execution; profile support que além de serem fáceis de criar você ainda pode especificar quais serviços iniciar (o que me lembra o conceito de units do systemd).
dinit é desenvolvido por Davin McCall, um ex contribuidor do kernel Linux e do Mesa driver. Assim como cinit e o runit, o dinit foi desenvolvido para ser integrado a outros ao invés de substituí-los (apesar que runit ainda permite substituir outros init systems). dinit é utilizado no Chimera Linux e é uma das várias escolhas do Artix Linux.
Também desenvolvida na Alemanha, trabalha utilizando seu próprio filesystem baseado em esquema de serviço e é escrita em C++. Ainda não é muito bem testada.
s6 é descrito como um pequeno conjunto de programas para UNIX, projetado para permitir supervisão de processos (a.k.a service supervision), na linha do daemontools em conjunto com runit, assim como várias operações em processos e daemons. As ferramentas do s6 são independentes que podem ser utilizadas com ou sem framework e podem ser agrupadas.
O s6 é o init system padrão da distribuição Glaucus. A skarnet disponibiliza também o s6-linux-utils que faz parte do ecossistema s6 e é utilizada para criar init system baseado no s6 no kernel Linux. É possível também ter um s6-linux-utils multicall.
Foi desenvolvido para a distribuição ObaRun, um fork da distribuição Arch desenvolvida por um anônimo como uma alternativa ao systemd. Na verdade o 66 é um fornecedor de gerenciamento de serviços para o s6 e não um init system em si.
Esse é um init e gerenciador de serviços escrito na linguagem Rust por Danilo Spinella, um desenvolvedor italiano da Suse inspirando-se no 66, no s6 (já mencionado anteriormente) e no daemontools mencionado a seguir. Ainda é um trabalho em progresso e o autor descreve que você o utiliza por conta e risco. Inicialmente se chamava tt e era escrito em C++. Possui uma sintaxe muito parecida com a do systemd. Está sob licença GPL3+, o que eu acho uma bela de uma burrice.
Também desenvolvido por Danilo Spinella o tt é um gerenciador de serviço init também inspirado no 66, s6 e no deamontools, para substituir o systemd mas oferecendo melhor base de código que o 66. A ideia é realmente reescrever o 66 já que este possui muitos bugs difíceis de serem corrigidos. A princípio parece que iria ser escrito na linguagem porém, em seu github vamos que é escrito na linguagem C++.
As próximas não são init systems. Na verdade se tratam de ferramentas que servem como auxiliares de init systems. A daemontools foi desenvolvida por Dan Bernstein como uma coleção de ferramentas para o gerenciamento de serviços de sistemas operacionais da família Unix (eles iniciam o serviço e o reiniciam caso ele morra. Parecido com o que temos no systemd). Esta ferramenta é fortemente utilizada em conjunto com o runit e o minit. Do daemontools surgiu um derivado chamado daemontools-encore que adiciona várias melhorias e mantendo compatibilidade entre ambos.
Nesse meio ainda temos o nosh que tem a mesma função que o daemontools. nosh foi desenvolvido originalmente para suprir a falta de opções que os BSDs não possui como as do launchd, systemd e do upstart. A equipe do nosh queria algo mais do que outras daemontools oferecem.
No meio disso, parece que teremos em breve algo similar no toybox que hoje traz os comandos init e oneit.
A ultima que eu gostaria de mencionar é a perp (abreviação de "the perpetrator"). Infelizmente, sua ultima versão foi em 2013.
sninit é uma pequena implementação para Linux que visa ser um substituto para o systemV sendo mais limpo e mais confiável, fornecendo melhor controle de processos removendo a necessidade de init scripts. Também é menor que o systemd para distribuilções que dependam do comando systemctl. O projeto sinit foi concluído sendo agora a continuidade no minibase.
procd é a daemon do OpenWrt sistema operacional Linux que utilizamos em nossos roteadores escrito em C. Ele mantem rastreio de processos iniciados a partir de seus init scripts (via ubus calls), e pode suprimir solicitação de inicialização/reinicialização de serviço redundante quando o ambiente de configuração não for alterado.
Conclusão
No Linux, tudo é uma questão de escolha. Não quer utilizar uma interface gráfica, você utiliza outra; não quer utilizar um terminal, utiliza outro. O mesmo vale para sistema de arquivos, gerenciadores de pacotes tanto de baixo quanto de alto nível, empacotamentos e todos os tipos de ferramentas, inclusive init systems. Isso é OS VÁRIOS SABORES DE LINUX.
Existe também por exemplo a Twsinit que é desenvolvido em Assembly, é bem pequena (exige somente coisa de 8k de memória) e ser uma substituição das atuais; a do Fedora chamada FCNewInit e Serel que também foca em acelerar o boot.Bom, acho que está bom o tamanho da lista. Vale mencionar (mais uma vez, assim como mencionado no vídeo "O caso Systemd") que do Systemd surgiu o fork UselessD, mas que não conseguiram atingir o seu objetivo proposto.
Moral da história é que acelerar o boot, reduzir o shutdown melhorando assim o uptime e solucionar os problemas gerados pelos scripts já é um desejo antigo. A maioria das aqui mencionadas focaram esforços para poder trazer essas soluções. Criticar o systemd então se torna somente uma questão de birra. E no meio de um oceano repleto de init systems, o inútil debate criticando o systemd continua até hoje. Como sempre, os argumentos são os mesmo e os piores imagináveis:
"ele não é portável", "ele é incompatível com init scripts" (o que não é verdade), "Ain, logs binários", "systemd faz muitas coisas, isso é contra a filosofia", "systemd é uma ameaça ao sistema operacional", "vou contar para a minha mãe"...
E porque ficar com essas discussões se temos a liberdade de adotar o que quisermos? ISSO É LIBERDADE DE VERDADE. Por que o systemd deveria ser portável se outros init systems já são? Alias por que criticar o systemd sendo que outros já tentaram implementar os mesmos recursos? Não quer utilizar o systemd? Neste artigo está um catalogo bom para você desfrutar; basta partir para os estudos.
Fico por aqui, espero ter agregado mais conhecimento. Forte abraço e até a próxima.
Foi lançada hoje a versão 1.1.21 da biblioteca musl. Para que não conhece, musl é uma nova biblioteca padrão para Linux fortemente focada na nova geração de dispositivos. Essa biblioteca torna Linux mais leve, mais rápida, mais simples de manter e foca no padrão correto de conformidade de padrão e de segurança.
Meu primeiro contato com essa biblioteca foi através da distribuição Alpine Linux. Depois disso já vi na Void Linux, na Adelie Linux, no Hermeric Linux, e já li a respeito de planos do Debian migrar para musl.
Esse novo lançamento trás melhorias no que diz respeito ao thread stack size, incluir um ganho no tamanho padrão de 80k para 128k, no default guard size de 4k para 8k, e permitir o padrão ser aumentado via ELF headers (desta forma, se os programas precisarem de pilhas maiores, eles podem ser construídos sem source-level changes, utilizando apenas o LDFLAGS).
Correção no MINSIGSTKSZ que gerava pilha insuficiente para o AIO threads no kernel, nos possíveis dealocks, o glb core foi reescrito para corrigir a inabilidade de verificar componentes de caminhos buscáveis mas não acessíveis a leitura (searchable-but-unreadable path components) e para evitar uso excessivo de pilha e syscalls desnecessárias.
