Postado no site Linux Journal no dia 21 de Maio de 2026 por George Whittaker, que devido o crescimento de compatibilidade de software com o systemd, especialmente em torno de aplicações desktop, containers e programas de orquestração de container, aplicações flatpak, aplicações proprietárias, agentes de monitoramento, certas ferramentas de jogos e multimídia, AI e ferramentas enterprise começa a surgir uma pressão para que os desenvolvedores da distribuição Alpine Linux se adaptem a nova necessidade.
Apesar de a equipe do Alpine Linux intencionalmente evitar o systemd, trazendo assim vantagens e desvantagens para a distribuição, as desvantagens com as incompatibilidades começaram a ficar muito problemáticas já que as aplicações empregam fortemente a libsystemd, as APIs do systemd e os comportamentos específicos da glibc (sim, no meu artigo Linux: mais do que um Unix eu mostro uma parte considretável de recursos da API do Linux, a LSB (Linux Standard Base), que agrega recursos e funcionalidades ao Linux que nenhum outro Unix ou a API POSIX possui. Estes recursos foram basicamente concentrados dentro da glibc ao ponto que eu relato em meu artigo Muito além do GNU: Os vários sabores de bibliotecas C que a "glibc é escrita com nada além do Linux em mente"; o que eu considero uma extrema burrice terem feito isso pois deveriam ter feito o mesmo em paralelo a outras bibliotecas como alternativas e não deixando o Linux escravo da glibc. Eu tenho artigo intitulado O que falta para a que a musl substitua a GilbC no Linux que já detalha bem o assunto e espero que um dia isso venha realmente acontecer.
Como o ecossistema do Linux em torno do systemd cresce cada vez mais, alguns esforços experimentais para empacotar porções do systemd sem a necessidade de ter o Alpine Linux totalmente com systemd já estão sendo feitas assim como uma versão em paralelo do systemd com suporte a musl (já que compatibilidade da glibc na musl já existe). O que são ideias interessantes demonstrando que o Alpine não está abandonando a sua identidade de manter a distribuição mínima e sim se adaptando e se modernizando. A ideia de compatibilidade é a chave para isso assim como outros projetos no Linux fazem (Wayland com o X11, proton e o Wine com as aplicações Windows e etc).
D-Bus é um sistema de comunicação de inter-processo (em inglês = inter-process communication ou IPC) que é utilizado como uma das dependências do systemd para ativação de serviços. Não somente pelo systemd, porém o D-Bus é utilizado por vários outros serviços como durante durante o processo de instalação gerando um número de identificação para a máquina através do D-Bus machine id. Máquinas virtuais também dependem o D-Bus machine id ainda mais em casos de geração de templates que podem precisar de um novo D-Bus machine ID para garantir que recursos do sistema do hypervisor sejam instruídos para o guest correto. O comando dbus-uuidgen --get é utilizado verificar o id das máquinas enquanto que o comando bus-uuidgen --ensure é utilizado para validação sendo o dbus-uuidgen --ensure=/etc/machine-id é utilizado para gerar novo id após remover o link simbólico /etc/machine-id tendo origem em /var/lib/dbus/machine-id (fica aí essa dica para a LPIC1).
Ferramentas do D-Bus
O Varlink também é um sistema de comunicação de inter-processo porém, sendo um protocolo que visa tornar os serviços acessíveis tanto para humanos quanto para máquinas do jeito mais fácil possível fazendo uso de arquivos de texto para descrever interface com todos os tipos de dados, metodo e etc.; não faz uso de números mágicos ou valores sem nomes, é fácil de debugar com qualquer ferramenta.
"Eu não sou um grande fã do D-Bus, mas eu sou um grande fã de mensagens" ... "logs binários não é uma coisa ruim desde que você tem as ferramentas para separá-las, mas gosta de mensagens".
Mas o motivo que o Varlink está sendo adotado no systemd no lugar do D-Bus não está relacionado a coisas como logs serem ou não binários e sim por questões de limitações sendo uma delas só estar disponível após o processo de boot, demora na implementação de novos recursos, complexidade, o fato de utilizar somente serialização, não podendo ser utilizado em muitos serviços básicos, performance baixa dentre outros problemas. Todos os detalhes podem ser conferidos na apresentação do Lennart no FOSDEM deste ano:
Em maio do ano passado eu postei sobre o run0, um substituto ao sudo no systemd. Mostrei que esse não é o único substituto do sudo. Em meio a isso, a Canonical anunciou que estará adotando ao sudo-rs, uma reimplementação do sudo baseado na linguagem Rust.
A farsa por trás do termo "Linux é somente o kernel": A verdade que não te contam sobre isso
Por quase três décadas vem sendo propagado aos quatro cantos do mundo a vaga informação:
"O nome do sistema operacional não é Linux, Linux é somente o kernel do sistema operacional e somente com o kernel você não faz nada. As ferramentas do sistema operacional são do projeto GNU. Então, o nome correto é GNU/Linux."
Ou postam em todos os lugares o estafante texto de autoria de Ricahrd Stallman:
"...Eu gostaria intervir por um momento. O que você está se referindo como Linux, é de fato, GNU/Linux, ou como eu recentemente passei a chamar, GNU mais Linux. Linux não é um sistema operacional em si..." ... "....Linux é o kernel: O programa no sistema que aloca recursos da máquina para outros programas que você executa. O kernel é uma parte essencial de um sistema operacional, mas inútil por si só..."
Agora a moda da vez é dizer "GNU com ou sem Linux"... Patéticos... Estranho é que eu percebi que passaram a utilizar este argumento depois que mencionei no meu vídeo Linux ou GNU/Linux? Eis a questão que "no meu canal eu trato de Linux com ou sem GNU". Simplesmente pegaram a mesma frase inverteram, mas eu duvido que eles vivam sem Linux:
Eu até poderia escrever pelo menos mais dois ou três artigos debatendo ponto por ponto desta frase, mas o meu foco aqui será unicamente no trecho "Linux é apenas o kernel". Então, bora!
Linux: mais do que o kernel do sistema operacional
Linux surgiu como um pequeno e singelo kernel, com apenas um conjunto de drivers que Linus portou de seu emulador de terminal que havia desenvolvido como aprendizado, o suporte a hardware era limitado, travava quando atingia o limite máximo de memória e estes são apenas alguns dos problemas que Linux enfrentava. No final da descrição da licença do kernel 0.01 (que nesta ocasião ainda era regido sob a licença da convenção de Berna do século XIX) o próprio Linus Torvalds afirmou na época que:
"Infelizmente, um kernel por si só não te leva a lugar algum. Para se ter um sistema funcional você precisa de um shell, compiladores, uma biblioteca e etc. Essas são partes separadas e muitas estão sob uma licença rigorosa (ou mesmo mais flexível). A maioria das ferramentas utilizadas com Linux são software do GNU e estão sob a GNU copyleft."
Não somente em sua licença como também no arquivo README Linux—a free unix-386 kernel, especificamente em Coisas faltando/incompletas no Linux (Things missing/incomplete in Linux) é descrito que:
"Nenhum dos importantes comandos de administração do sistema ainda foram escritos para Linux. Estes incluem coisas como mkfs, format, fsck, mknod e etc. Alguns destes precisam de recursos do kernel ainda não implementados (format, mknod), alguns precisam apenas serem escritos. Assim como a biblioteca, eu aceitaria quaisquer arquivos distribuíveis livremente."
Se o desenvolvimento do Linux tivesse parado por aqui, estaria correto afirmar que Linux era apenas um kernel, mas este argumento foi válido somente até a versão 0.10, pois a partir do kernel 0.11, lançado no dia 19 de Dezembro de 1991 (apenas quatro meses após seu nascimento), surgiram os primeiros comandos do Linux fidsk, mkfs e fsck desenvolvidos pelo próprio Linus Torvalds para tornar Linux self-hosting já que acidentalmente Linus havia discado a partição do Minix ao invés de seu modem destruindo completamente a partição do Minix:
Menos de um mês depois, foi lançado o kernel 0.12 com mais comandos como o mkswap, pois nesta versão originou-se o suporte a memória virtual no Linux, também chamado paginação de disco ou paginação de memória (Memory paging ou disc paging em inglês). A ideia surgiu quando um alemão contatou Linus perguntando como utilizar o GCC no Linux já que ele possuía apenas 2MB de RAM e era a exata quantidade exigida para executar o GCC. Foi aí que durante três dias Linus trabalhou no desenvolvimento da paginação de disco, vindo a concluí-la no dia 25 de Dezembro de 1991. Isso foi uma revolução no Linux pois não era um qualquer sistema operacional possuía suporte a memória virtual. Daí em diante as pessoas pararam de comparar Linux ao Minix e passaram a compará-lo ao Coherenlt que foi o primeiro clone do Unix na história:
A maioria dos comandos desenvolvidos por Linus Torvalds ainda estão presentes nas distribuições e também deram origem a outros pacotes como o util-Linux, o e2fsprogs e o busybox. Hoje em dia, a maioria dos comandos nas distribuições são do próprio Linux:
A partir da versão 0.11 Linux passou de um simples, pequeno e inacabado kernel a um kernel self-hosting contendo os recursos e comandos necessários para a sua administração do sistema, quebrando assim o ciclo do README do kernel 0.01. Mas a comunidade Linux não parou por aí e vocês verão a seguir como a partir destes recursos, a comunidade Linux o evoluiu para um sistema operacional.
Fato curioso é que Linus havia perdido interesse em continuar o desenvolvimento do Linux até ocorrer o acidente com o Minix. Já pensou se isso não tivesse acontecido ?
Só com um kernel e as ferramentas do projeto GNU, você não consegue fazer porcaria nenhuma já que o GNU não possui metade das ferramentas necessárias para se ter um sistema operacional.
A evolução do Linux
Surgiu então a primeira comunidade Linux composta por membros da comunidade Minix. Hoje a comunidade Linux é composta por indivíduos, organizações, instituições governamentais, acadêmicas e empresariais do mundo todo.
Sua gigantesca comunidade não o limitou a simplesmente um kernel com comandos e passou a transforma-lo em um verdadeiro sistema operacional desenvolvendo todos os tipos de recursos necessários para isso além de portar ferramentas de outros Unix para Linux (sim, Linux também é um Unix. Aliás, Linux é mais do que um Unix)e receber suporte de outros projetos como é o caso do comando file (que eu não faço ideia de onde o projeto GNU tirou que pertence a eles) e o Shadow. Exemplos de pacotes e comandos do próprio Linux são o at, o Batch (que é uma parte do at), o Linux PAM, o Procps, o Psmisc, o Util-linux, e2fsprogs, iproute2, kmod. De bibliotecas facilmente temos a uclibc, a dietlibc, a musl, newlib e klibc. Existe uma lista enorme somente de bibliotecas C mas poderíamos contar até com mais em outras linguagens. Já mostrei aqui três compiladores além do GCC que compilam o kernel Linux como o tinyCC, o ICC da Intel e o LLVM. Na parte de init systems (BSD, SysVinit, upstart, systemd e etc) também temos uma lista enorme e de carregadores de boot temos outros também. Confiram mais em /pub/linux/utils/ e pub/linux/.
Já se passaram 34 anos e muita coisa mudou desde o seu primeiro lançamento. E de tudo o que foi mencionado aqui, sabe o que pertence ao GNU? Nada! Tudo no Linux é uma questão de escolha; opções não faltam.
Kernel: A alma do sistema operacional
Se lembram da frase "Algumas destas (ferramemtas) precisam de recursos do kernel" no README lá no início do artigo? Pois é, três coisas podemos mencionar aqui que ocorrem a medida que novos recursos ganham vida no kernel. A primeira é o desenvolvimento de ferramentas para a administração exatamente de recursos do kernel como exemplos os comandos do iproute2 (arpd, bridge, ctstat, devlink, ip, lnstat, nstat, rdma, routef, routel, rtacct, rtmon, rtstat, ss, tc e tipc) para administrar o framework de sub-sistema de redes do Linux; o iptables e nftables para administrar o framework de filtro de pacotes netfilter; os comandos do e2fsprogs (lsattr, chattr, fuse2fs, badblocks, dumpe2fs, e2freefrag, e2fsck, e2image, e2label, e2mmpstatus, e2undo, e4crypt, e4defrag, filefrag, fsck.ext2, fsck.ext3, fsck.ext4, logsave, mke2fs, mkfs.ext2, mkfs.ext3, mkfs.ext4, mklost+found, resize2fs, tune2fs) para a administração de recursos sistemas de arquivos da familia ext*; podemos citar atributos estendidos com o getfattr e o setfattr, ACL POSIX, capabilities e os comandos para administração dos sistemas de arquivos como btrfsprogs, xfsprogs e os próprios comandos fdisk, mkfs, mount e fsck são parte da administração dos sistemas de arquivos; os comandos getenforce, setenforce e até a opção -Z no comando ls são para administrar o SELinux (bom, essa é bem básica do SELinux já que o mundo SELinux é muito maior do que isso); os módulos Apparmor, Tomoyo, MAC e DAC também possuem seus comandos; o comando watchdog para monitorar e gerenciar comportamentos anormais de hardware e software e automaticamente reset ou rebootar o sistema se necessário utilizam o módulos como softdog e incontáveis outros. No Linux existe até o módulo B.A.T.M.A.N. (better approach to mobile ad-hoc networking) que utiliza os comandos batctl e batman-adv para administração (há também a daemon comando alfred).
A segunda é o desenvolvimento de ferramentas devido o kernel fornecer recursos para isso. Containers por exemplo são uma mistura dos recursos name space e cgroups (cgroups é fonte de recursos para vários outros programas que utilizamos e uma das principais fontes de recursos para do systemd. O systemd faz uso também do dbus que inclusive é utilizado também na parte de virtualização); o próprio kvm (kernel based virtual machine) como o próprio nome diz é um recurso do kernel para virtualização e que foi adicionado por volta de 2007 (veja na RedHat e na aws); o iproute2 já citado anteriormente, depende de vários recursos do kernel como exemplo a parte de routing policy database (ip rule list e ip route list table local) que depende dos recursos do kernel IP: advanced router e IP: policy routing e o seu IP in IP tunneling que depende dos módulos ipip.o e new_tunnel.o; o novo comando mu (veja também no git) utilizado para exibir o uso de memória por arquivo, depende da systemcall cachestat() do kernel; todos os programas dependem do kernel para serem executados através do recursoELF (Exectuable and Loadable File) que substituiu o a.out.
Sabe o shebang (#!) que utilizamos no início de nossos scripts? Pois é! Não é o shell que lê este comentário para interpretar os scripts e sim o kernel através da system call execv (fs/exec.c).
Recursos ELF e #! dentro de Executable file formats no kernel
Até o seu navegador depende de recursos do kernel a para sua execução e não estou falando de drivers drivers, estou falando de gerenciamento de processo e memória, acesso ao sistema de arquivos, recursos de segurança como Sandboxing e etc.
A terceira é o desenvolvimento de novos programas pegando partes do código do próprio kernel. Citando dois exemplos, na FAQ da dietlibc descreve que é utilizado o layout struct stat do kernel em sua interface. O segundo é no projeto Psmisc (que contém comandos como killall, pidof e pstree) que utilizaram o src/loop.h do pacote util-linux que por sua vez, pegaram do kernel Linux.
O kernel é mais do que o coração do sistema operacional, ele é a alma do sistema operacional pois seu sistema operacional depende muito mais do kernel do que você imagina. Se só com o kernel não se faz nada, sem o kernel, muito menos. Sem o kernel não há sistema operacional.
Linux: Mais do que um Unix
Aproveitando que falamos de pegar partes do código do próprio kernel para para a construção de novas ferramentas, quero sugerir meu artigo Linux: Mais do que um Unix onde debato sobre algumas das centenas de system calls da API própria do Linux que lhe proporciona recursos que nenhum outro Unix possui (e nem a API POSIX).
Por que foi propagado que Linux é apenas o kernel?
Este foi o meio que RMS, a FSF e o projeto GNU resolveram utilizar para virar os holofotes para si, tentar se tornar o centro das atenções e se promover já que ideia de ter um sistema operacional completo falhou. Como Rob Landley menciona no Ohio Talk em 2013:
"Os BSD não é uma ameaça existencial para o Linux, mas o Linux é para o GNU".
O projeto GNU foi iniciado quase oito anos antes do Linux e como tudo na vida é incerto, o curso da história mudou, Linux tomou proporção que não era esperada e passou a ganhar notoriedade em toda a comunidade de tecnologia que não, proporção essa que todos esperavam que ocorreria para o GNU.
Sabendo que as pessoas não possuem o hábito de leitura (e esse é o grande declino moral das sociedades), passaram então a explorar este ponto fraco a seu favor. No final das contas, tudo uma questão de vaidade ou outras intenções. O que mais me intriga é ver profissionais de Linux vergonhosamente defenderem este argumento.
Conclusão
Foi-se o tempo que Linux era somente um kernel. O que começou como um projeto pessoal, um pequeno kernel sem pretensões ou expectativas, apenas uma diversão e um desafio para um hacker aplicar seus conhecimentos, inesperadamente evoluiu e se tornou um verdadeiro sistema operacional contendo comandos, shells, bibliotecas, init systems e até mesmo sua própria API.
Pode não ser considerado um sistema operacional completo, o que dificilmente algum sistema operacional é (muito menos o GNU) já que em todos os sistemas operacionais (especialmente no GNU que não contém metade das ferramentas necessárias para se ter um sistema operacional funcional) são utilizadas ferramentas de outros sistemas ou de outros projetos pois o compartilhamento de conhecimento e a colaboratividade sempre foram as bases da cultura hacker.
E se Linux fosse realmente apenas o kernel do sistema operacinal, sabe qual a importância isso teria entre verdadeiros profissionais de tecnologia? NENHUMA! O importante é o sistema funcionar e atender as demandas.
Já aos que vão vir afirmar que discordam (sempre escuto ou leio isso), só tenho um recado a deixar: Eu não dou a mínima importância para concordância ou discordância. As evidencias estão aí, basta terem maturidade e hábito de leitura.
pledge(), ou simplesmente Pledge, é uma system call do OpenBSD que foi portada para Linux por Justine Tunney. Na verdade esta implementação para Linux foi inspirada no pledge() do OpenBSD porém fazendo uso dos recursos da API do próprio Linux (já descrito no artigo Linux: Mais do que um Unix sobre a própria API do Linux) SECCOMP BPF (já abordado no meu artigo: Linux: Mais do que um Unix) e Landlock LSM (introduzido no kernel Linux 5.13 para reforçar a segurança). Pledge força os processos a serem executados de forma restrita e limitada dentro de um sandbox (algo que é ótimo para a execução de scripts e ferramentas automatizadas).
Como descrito por Justine em seu site, "Pledge é como se fosse o fruto proibido que todos nós cobiçamos quando o chefe nos diz para utilizar algo como Linux"... pois ..."Linux nunca possuiu uma camada de segurança que meros mortais conseguissem entender"...; ..."Pledge torna a segurança mais compreensível". Bom, neste ponto não há como discordar de Justine visto como todos nós reclamamos como é trabalhoso configurar o SELinux (muitos até reclamam que a vida é muito curta para utilizar o SELinux) ou a diferença enorme de sintaxe entre iptables do Linux e o packet filter que apesar de muito famoso através do FreeBSD, o packet filter é na verdade do OpenBSD e foi portado para o FreeBSD. Até mesmo a sintax do antigo ipfw que o FreeBSD herdou do MacOSX possui sintax muito mais facil.
Justine mesmo passou por situação como esta ao utilizar o SECCOMP BPF para implementar pledge:
"Houveram poucos desenvolvedores no passado que tentaram isso. Não vou citar nomes pois a maioria destes projetos nunca foram concluídos. Quando se trata de SECCOMP, os tutoriais online explicam apenas como inserir lista de permissões das system calls em si, então a maioria das pessoas perdem interesse antes de compreender como filtrar argumentos. Os projetos que foram mais longe também tinham equívocos tal como permitir a alteração de setuid/setgid/sticky bits. Então nenhuma das alternativas atuais deveriam ser utilizadas. Acredito que esse esforço nos deixa muito mais próximos de ter pledge() do que nunca."
Um apelo que faço a todas as comunidades Linux: Parem de perder tempo com bobeiras de ideologias e filosofias! Nós somos técnicos e não filósofos; deixem a filosofia para os filósofos e gastem tal energia elaborando documentações que inclusive, sejam de fácil compreensão. Vejam aí mais um grande exemplo de problema do Linux demorar ter um grande e tão importante recurso pela simples falta de uma boa documentação.
Apesar disso, muitos esforços tem sido feitos para sanar tais problemas no Linux e torná-lo produtivo como o próprio e odiado (sem razão lógica) systemd que trás padronizações para as distribuições e torna a configuração dos serviços muito mais fácil; o Btrfs que facilita muito trabalhar com gerenciamento de volumes e outros recursos que, em outros sistemas de arquivos, eram serviços bem mais complexos de se trabalhar; o Netfilter que eu agradeço por nos conceder o nftables com sintaxe tão fácil que se aproxima do BSD pf (além de trazer também vários recursos que anteriormente eram difíceis de implementar no iptables).
O segundo grande motivo que levou Justine portar Pledge para Linux foi devido a baixa adesão ao OpenBSD. Em 2002 a base de usuário de OpenBSD era de apenas 7.000 usuários tendo seu crescimento sempre baixo. O que nos leva a ideia de usuários não somente migrarem mas como também portar suas ferramentas para outro sistema operacional com maior base de usuários, melhor ecossistema e melhor adesão. Isso vem ocorrendo com a base de usuários do Solaris como relata Brendan Gregg em seu artigo Solaris to Linux Migration de 2017 que está ocorrendo migração e também port de ferramentas do Solaris para Linux como o caso do Dtrace:
Bom, e o terceiro motivo que eu ponho aqui é que Justine havia desenvolvido seu Pledge para ser utilizado como uma solução sandbox para o servidor web de sua própria autoria, o redbean. Justine chegou a conclusão que Pledge é tão robusto e útil que poderia reger outros processos; então, Justine teve uma grade ideia: Ao invés de configurar o Pledge diretamente no código fonte do programa como pode ser visto man page do OpenBSD ou no código do comando cat do OpenBSD:
system call pledge sendo utilizado no código fonte: Medium
Justine desenvolveu um pequeno comando para utilizar o Pledge.
Opções do comando pledge
Para executar o comando, basta digitar pledge (ou ./pledge caso ainda não houver salvo o comando dentro de um diretório da variável $PATH) seguido do comando desejado. Pldge é intuitivo, o próprio comando pledge indicará quais systemcalls serão necessárias para executar o comando desejado. Veja no exemplo abaixo a terceira coluna indicando quais syscall necessárias para executar o comando ls com o comando pledge:
syscalls necessárias para executar o comando ls
A principio eu não consegui um bom resultado após adicionar as syscalls indicadas pelo pledge pois, após seguir o passo a passo de duas formas diferentes, o único resultado apresentado foi a mensagem invalid system call (core dump) e o Gnome reportando erros:
Erro apresentado ao executar o comando ls através do Pledge
Depois, lendo um pouco mais no site da Justine, percebi que havia faltado a syscall rpath dentro das opções selecionadas e assim consegui executar normalmente. Apesar disso, o comando ls com a opção --l ainda apresentou dois erros sendo uma de permissão (talvez seja esse o motivo pois Justice menciona em seu site que é necessário utilizar pledge como root, algo que acabei não fazendo) e outro de syscall que eu não consegui encontrar nas opções (lgetxattr). Mesmo assim, no final das linha foi apresentado o resultado do comando com sucesso:
O comando ls sendo executado com o pledge de forma mais correta
Agora resta a mim aprender melhor como utilizar o comando pldge. Eu vou continuar estudando e testando para ver como posso aplicar de forma mais clara.
Bom trabalho feito pela Justine que merece todos os créditos principalmente pelo desenvolvimento da biblioteca libcosmopolitan (que lhe rendeu um premio do Google em 2023; o premio Open Source Peer Bonus que extremamente difícil de conquistar) e muitos outros recursos; alias, Justine é financiada por mais ou menos uma centena de desenvolvedores no GitHub.
Apesar que Justine informar que só implementou por enquanto coisas descritas na man page do OpenBSD, ainda precisar trabalhar em materiais primários mas que são providos do pledge do kernel do OpenBSD, também precisam de mais feedback da comunidade.
Andreas Kling adicionou o suporte a pledge() ao SerenityOS sendo o segundo sistema operacional a adotar os mecanismos pledge() e unveil() do OpenBSD. Talvez Linux é o terceiro sistema operacional a realizar esta façanha. Quem sabe no futuro esta system call faça parte até mesmo da API do Linux? Vantagem para todos nós.
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.
.png "D-Bus será substituído no systemd")
.jpg "A imagem do kernel Linux se acoplando ao ao projeto GNU foi retirara do slide Richard Stallman's TEDx video: \"Introduction to Free Software and the Liberation of Cyberspace\" (https://www.fsf.org/blogs/rms/20140407-geneva-tedx-talk-free-software-free-society/) e está sob licença Creative Commons: https://creativecommons.org/licenses/by-nd/3.0/")
.webp)
.jpg)
