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.
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.
Dropbear é um pequeno SSH disponível para uma variedade de plataformas POSIX-based como distribuições Linux com a uClibc >=0.9.17, dietlibc, e a musl libc; Mac OS X (compilado com suporte ao PAM); FreeBSD, NetBSD e OpenBSD; Solaris; IRIX 6.5 (com /dev/urandom, ou prngd deve funcionar); Tru64 5.1 (com prngd por entropy); AIX 4.3.3 (com gcc e o Linux Affinity Toolkit), AIX 5.2 (com /dev/urandom); HPUX 11.00 (+prngd. TCP forwarding não funciona) e Cygwin (testado 1.5.19 no Windows XP). Dropbear é uma alternativa ao SSH e por mais que talvez você possa não conhecer, o Dropbear roda em milhões de computadores. Mencionei o Dropbear na segunda parte da minha live sobre vulnerabilidade no SSH causada pelo compactador XZ.
No dia 25 de Abril foi lançado o Dropbear 2024.85 que corrige erros da versão 2024.84 como o SHA ou o DROPBEAR_CLI_PUBKEY_AUTH falham ao serem desabilitados. Houve também mudando de diretórios no Debian.
O dia que Laurent Bercot calou Richard Stallman: Eu não uso GNU, eu uso Linux!
Em Fevereiro de 2022, Laurent Bercot, autor do projeto ferramentas skarnet, como a skalib, execline e s6 (s6 é fortemente utilizado em containers e há uma proposta para o Alpine Linux adotá-lo) postou em seu perfil no site X o dia que deixou Stallman calado ao dizer que utilizava que utiliza exatamente Linux e não utiliza projeto do projeto GNU.
Bom, eu já sou conhecido por ser escorraçado por essa galera devido a minha série Muito além do GNU e, gostem eles ou não, eu vou sempre postar sobre o assunto porque, tudo no Linux é uma questão de escolha. É simples lógica e de se encarar a realidade (o que não é o forte deles). A diferença entre eles e eu (e isso eu digo categoricamente) é que eu afirmo tudo isso baseado em argumento técnico enquanto eles só se baseiam em paixões. Essa é a prova exata de que eles se quer já leram uma manpage.
Bom, vamos a o que realmente nos interessa neste post que é o artigo que, além de abordar a quebra desse paradigma irreal (GNU/Linux) também nos apresenta a origem do projeto Skarnet e de suas ferramentas.
A Convenção anual de software livre na França
Havia uma convenção anual de software livre na França mas o debate entre Stallman e Bercot ocorreram inicialmente na convenção do ano 2.000 e estendendo para a convenção de 2.001. Stallman estaria presente ambos os anos para fazer sua apresentação. Laurent e seus amigos foram à convenção do ano 2000; foi sua primeira vez em um evento desses e ainda era muito novo nas comunidades open source.
"A apresentação do RMS foi... interessante. RMS é (era?) um excelente pregador. Ele é, de mais maneiras, uma figura religiosa, e eu entendi porque ele tinha tantos fanáticos. A causa que ele estava pregando era correta e nós tinhas vontade de abraça-la."
Depois da palestra de RMS, todos estavam conversando em um corredor, Larent não sabia mas RMS estava atrás dele. Quando Laurent soltou a palavra Linux no meio de sua conversa, pronto... RMS parou na mesma hora a conversa que estava com outras pessoas e, nas palavras de Laurent, "como um tubarão cheirando farejando sangue" começou o seu discurso de moral e ética explicando porque Laurent deveria dizer GNU/Linux em vez de Linux, por pelo menos três minutos; o que nas palavras de Laurent era muito muito tempo. Era mesmo se levarmos em conta que é de pura balela. Aquela mesma lenga de sempre que vivem copiando do site do GNU postando nos grupos e comentando no meu canal de "Eu só gostaria de interromper por um momento. O que você está se referindo como Linux, é na verdade, GNU/Linux, ou como eu comecei recentemente a chamá-lo, GNU e Linux. ..." e bla bla bla bla bla.
Bom, moral da história, Laurent só ficou ouvindo de forma insegura sem confrontá-lo no meio dos seus admiradores enquanto que Stallman simplesmente sorriu de autossatisfação, deu as costas e saiu andando sem parar para ouvir o que Laurent teria a dizer, porque escutar não é o forte do stallman.
Laurent diz que se sentiu humilhado e a partir dali, Laurent começaria a sua revanche (ia ter revanche; ah sim, ia).
O início da skarnet
Laurent agradece a Stallman por sua atitude pois a partir daí, Laurent se interessou por detalhes de como Linux bootava, quais componentes são necessários para faze-lo bootar, quais pacotes alternativos existiam que lhe permitiriam bootar o Linux sem executar qualquer coisa de origem do GNU; como init system é feito e o que é POSIX.
A glibc foi substituída pela dietlibc e o coreutils foi substituído pelo embutils, ambas ferramentas desenvolvidas por Felix Von Leitner e já apresentadas tanto aqui no blog quanto no canal.
As outras partes que faltavam foram desenvolvidas pelo próprio Laurent. Laurent afirma que foram noites de sangue suor e lágrimas mas depois de quase um ano inteiro Laurent conseguiu bootar seu servidor Linux sem uma única peça de software do projeto GNU. E assim nascia o projeto http://skarnet.org que inicialmente se chamava antah server e Laurent estava pronto para a revanche.
A revanche
A convenção de 2001 não foi diferente da do ano anterior (mesmos rostos e mesmas conversas) e a palestra do Stallman foi basicamente a mesma coisa do ano anterior com a mesma dinâmica (o que não é nenhuma novidade).
Quando foi aberto espaço para perguntas, Laurent teve a sua chance. Na verdade Laurent nem se lembra qual foi a sua pergunta e o bom da verdade é que ele disse que isso não importa pois sabia que iria conseguir completar a sua pergunta depois de sua abordagem inicial:
"Eu uso Linux."
Quando Stallman quis interromper o raciocinio da pergunta (como de costume ele faz ao ouvir a frase "Eu uso Linux", Laurent já o interrompeu:
"Não. Eu use Linux, the kernel. Eu não uso GNU. Não há software GNU na minha máqina, o userspace é feito de outros tijolos de software. Quando eu digo "Linux", eu quero dizer exatamente o que eu digo."
Laurent disse que Stallman ficou olhando para ele boquiaberto e não disse uma palavra e, nas palavras de Laurent, foi GLORIOSO. Seus amigos estavam rindo perto dele.
Abaixo estão prints de evidencias do site Skarnet nos dias atuais; até hoje não há presença de ferramentas do projeto GNU. trata-se de ferramentas bem interessantes levando em conta o downtime total e a quantidade de vulnerabilidades exploradas (apenas uma e sem sucesso) durante ~23 anos.
Claro, como sempre Stallman não daria o braço a torcer (o que já era de se esperar) e soltou a seguinte frase:
"Okay, bom, você provou um ponto. No entanto, esta é uma ocorrência bastante rara; em praticamente todas as máquinas, o sistema GNU..."
E blablabla... Laurent diz que, mesmo não tendo mais como argumentar por serem incapaz de se questionar, ficou satisfeito porque encontrou seu propósito na jornada, alcançar o destino foi apenas um bonus. Depois disso, Laurent voltou para casa e continuou trabalhando em software de baixo nível para Linux. Depois disso, Laurent até palestrou no FOSDEM de 2017 sobre o s6, mas não voltou mais a eventos de software livre (fez bem).
Depois disso tiveram comentários interessantes como:
"I submeti um patch para o core utils para remover "/GNU" por exatamente o motivo que você especificou. O patch foi rejeitado :)"
é obvio que seria rejeitado né
"RMS ficou muito chateado quando tornamos a Web libwww public domain ao invés de disponibilizar sob GPL. "E se a Microsoft pegar o seu código?" Esse era exatamente o nosso objetivo."
Toma
"Em 2006, eu estava bebado e debati com ele o fato de que as pessoas precisam de dinheiro para viver, o que deixou ele muito ofendido."
Pow, até um bêbado destrói os argumentos dele. Alias, Stallman acha ruim as pessoas ganhar dinheiro mas ele mesmo cobra para tirar foto com ele (e cobra caro ainda por cima) e até mesmo por autografo. Hipocrisia bem típica.
Ninguém é *forçado* a utilizar ferramentas do GNU com o Linux. Por exemplo, eu tenho um box com ferramentas do Plan9 (rodando Gentoo). Então chamar de "GNU/Linux" seria simplesmente errado.
Isso é verdade, eu mesmo já mostrei várias vezes o projeto 9Base que são comandos do sistema operacional plan9 portados para Linux (agradeço ao plan9 por várias ferramentas que existem no Linux hoje).
A frase final de Lauent é simplesmente a melhor forma de descrever do que se trata a minha série Muito além do GNU:
Eu acredito que eu sou a primeira pessoa que na verdade fez isso na vida real, e eu vou continuar usando este distintivo com orgulho. E me deixa perplexo, dado o montante existente de userspace de baixo nível que não são do GNU hoje em dia, a FSF ainda acredita que Linux == GNU. Fósseis!
Além de não existir somente ferramentas do GNU, ainda temos o segundo ponto que Laurent descreve bem no inicio que eu já mencionei por várias vezes: A maioria das ferramentas que utilizamos no Linux, não são do GNU. Elas vem de outros sistemas operacionais como IRIX, Solaris, BSDs e até do próprio Linux (vocês que dizem que Linux é somente o kernel, vocês estão simplesmente muito enganados).
"Eu não culpo RMS ou a FSF por quererem comercializar com precisão o projeto GNU. No entanto eu os culpo por se recusarem a reconhecer que o GNU não possui o monopólio no userspace para Linux mais. Eles não tinham 21 anos atrás eles com certeza não tem hoje."
Como eu sempre digo, não existe GNU/Linux nem tecnicamente, nem historicamente e nem juridicamente falando. Liberdade diz respeito a escolha e não a uma licença (que diga-se de passagem está em pleno declínio).
Linux não não é e nunca foi limitado ao uso de ferramentas do projeto GNU; se isso fosse verdade, então não haveria liberdade. A adoção de ferramentas do projeto GNU no passado (e até no presente) foi dado devido a conceitos técnicos e não ideológicos como gostam de lhe contar. Desenvolvedores de outros Unix melhoraram as ferramentas do projeto GNU para seu próprio uso (como é o caso dos desenvolvedores de Solaris. Sejam gratos a eles, se não o GCC nem teria ido para frente) como uma alternativa mais barata e assim o projeto GNU se beneficiado (algo que eles costumam ocultar).
.png "Lançado Dropbear 2024.85")
