Essa semana resolvi falar do sistema operacional Plan9 que foi desenvolvido pelo mesmo laboratório que deu origem ao Unix (inclusive pelos mesmos desenvolvedores). Uma das ideias por trás do Plan9 é que os erros que ocorreram no Unix não se repetiria no Plan9 (sim, erros ocorreram no Unix e um exemplo disso pode ser conferido no artigo Entendendo a divisão dos diretórios /bin, /sbin, /usr/bin, /usr/sbin que eu traduzi).
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.
Tenho certeza que, inconscientemente você esperava ler "dando mais créditos ao GNU" pois isso é o que lemos e ouvimos a vida toda. Há mais de 20 anos, a alegação dos defensores de software livre é que as ferramentas que utilizamos nas distribuições Linux são de autoria do projeto GNU (o que não é necessariamente verdade) e com isso brigam para que o nome GNU seja reconhecido no Linux para assim dar-lhe os "devidos créditos" (parece até mesmo uma briga por paternidade). Essa é uma das brigas mais inúteis que eu já vi; mas graças a essa briga inútil é que outras ferramentas muitos importantes, tão bons quanto as do GNU (e muitas vezes até melhor), não ganharam a notoriedade e adesão que deveriam e mereciam.
Como ferramentas como o terminal de comandos Zsh não ganharam notoriedade sendo o Zsh um terminal muito melhor que o Bash e apenas um ano mais novo? Como outras bibliotecas como a Dietlibc, musl e newlib também não são mais adotadas podendo tornar os mesmos binários bem menores e bem mais confiáveis? E assim esse questionamento segue para todas as ferramentas do projeto GNU que utilizamos (fora ferramentas dos BSDs, do MIT, Plan9 e até mesmo do próprio Linux que utilizamos das distribuições). E foi por isso que eu criei a série Muito além do GNU.
O estudo sugere que Linux Torvads pode ter gradualmente substituído código Minix do Linux, mas Linus afirmou que isso nunca aconteceu e argumentou que ele e outros desenvolvedores do Linux deram os créditos apropriados. O Minix foi simplesmente uma plataforma que Linus Torvalds fez seu trabalho de programação:
"Linux nunca utilizou código do Minix... Nunca demos credito a código de ninguém porque nunca utilizamos código de ninguém, mas o Unix sim forneceu as ideias. Nunca houve qualquer pergunta a respeito do fato de que o Linux foi muito aberto a pegar um monte de boas ideias do Unix."
"Eu estava utilizando o Minix quando eu escrevei o Linux, mas isso é no mesmo sentido de que você está utilizando Windows quando você escreve sua coluna. Seus artigos contem código fonte do Windows porque você utiliza Windows para escrevê-los?"
HY: Você pensa nesses outros sistemas operacionais PC-Unix como rivais, ou mais como celgas? Você olha para eles com frequência para ver o que pode ser incorporado ao Linux, ou eles nunca te incomodam de forma alguma?
Linus: Eu raramente me preocupo com outros sistemas. Eu me concentro totalmente apenas em tornar o Linux o melhor OS que eu puder, e enquanto isso as vezes envolve pegar ideias de outros sistemas, não é exatamente uma grande parte (e quando eu tenho novas e interessantes ideias eu geralmente me volto a sistemas mais radicais como o Plan-9 ou o Inferno, e então eu tento decidir quais dessas ideias são realmente validas).
Enquanto isso, em uma entrevista ao Department of Computer Science da universidade de Vrije, intitulada "Quem escreveu Linux", Andrew argumenta que "Linus não sentou em um vácuo e de repente digitou o código fonte do Linux. Ele tinha o meu livro, estava rodando o Minix e indubitavelmente sabia a história (desde que isto está no meu livro). Mas o código era dele"
Bom, fazendo uma analise nesta frase do professor Andrew Tanenbaum, temos aqui três pontos. O primeiro é a alegação do uso do seu livro como argumento para se autopromover; que então neste caso deve-se também dar créditos ao Solaris. Por que? Vamos investigar na história.
Devido a um projeto que estou trabalhando (no minix), estou interessado na definição do padrão posix. Alguém poderia me indicar um formato (de preferência) legível por máquina das regras de posix mais recentes?
Sites FTP seriam bons.
Esta é primeira mensagem enviada por Linus Torvalds e que é familiar entre nós que, devido os manuais POSIX serem caros, ele tentou conseguir uma cópia com alguém para trabalhar no desenvolvimento do Linux. Como ninguém havia respondido durante um bom tempo, então Linus passou a utilizar os manuais POSIX da Sun Microsystems que ele conseguiu na biblioteca da universidade de Helsinki. Sim, Linus utilizou o livro de Andrew para estudar e entender como um sistema operacional funciona internamente, mas Linus utilizou os manuais POSIX do Solaris para tornar Linux um verdadeiro clone do Unix (claro que depois outros manuais POSIX também foram utilizados depois que foram enviados, mas toda a implementação das características POSIX ao Linux começou com os manuais do Solaris).
Segundo ponto
Andrew Tanenbaum também não programou Minix no Vácuo (bem óbvio); ele também precisou de um sistema operacional para desenvolver e compilar do Minix, que na ocasião foi o sistema operacional Coherent, o primeiro clone do Unix na história:
"Inicialmente, eu fiz o desenvolvimento de software no meu IBM PC rodando o Coherent da Mark Williams, um clone V7 escrito pela alumni da Universidade de Waterloo. Seu código fonte não era publicamente disponível. Utilizar o Coherent foi inicialmente necessário porque a principio eu não tinha um compilador C."
Terceiro e ultimo ponto
Como afirmado pelo próprio Andrew, o código era do Linus. ENTÃO DANE-SE. Algo que eu aprendi ao longo do tempo estudando licenças open source é que você pode revogar direito sim, mas sobre o seu código, não sobre código de terceiros e nem por terceiros utilizarem suas ferramentas (você concordou com isso). Alias, nem é necessário lei para isso, é uma questão de bom senso e de lógica. Já pensou se johann pachelbel tivesse que dar créditos ao fabricante do órgão, do papel, da caneta tinteiro e todos os outros só por ter utilizado seus produtos para compor canon in d major? haja paciência...
O que eu percebo é que tudo isso não passa de uma tentativa frustrada e fracassada tanto por parte do GNU quanto do Minix de fazer propaganda do seu trabalho em cima de um sistema operacional Linux que teve o seu sucesso inesperado e subestimado por ambos; essa é a forma mais inútil que o Minix o GNU encontraram para se promover. A forma mais lógica de se dar créditos a uma projeto pode ser lida através da informação extraída do livro OpenLife e exceder a isso é desnecessário:
Um fator final importante foi que Linus não trabalhou sozinho. Ele foi aberto para ideia colocadas adiante por outros, e aberto para colaborações. Além disso, ele baseou seu trabalho em outros previamente feito por outros (minix) e aproveitou-se de ferramentas criadas por outros (bash, e gcc).
Ori Bernstein vem trabalhando no desenvolvimento de um sistema de arquivos chamado GEFS (Good Enough File System). Ainda experimental, EGFS foi desenvolvido para o sistema operacional Plan9 ( que eu já tratei no canal e no blog) tendo a interface de sistema de arquivos 9p no topo de uma floresta copy-on-write Bε trees. O 9p seria utilizado assim como o BtrfsProgs e o XFSprogs.
E assim temos mais um sistema de arquivos copy-on-write compatível com alguma estrutura tree; porém, não confunda Bε trees com B-tree. De acordo com a FAQ do Bε-tree File System:
"Bε-tree é uma B-tree, aumentada com buffers por nó. As consultas de ponto e intervalo se comportam de maneira semelhante a uma B-tree, exceto que cada buffer no caminho da raiz à folha também deve ser verificado quanto a itens que afetam a consulta."
Sistema de arquivos com snapshottingsimples e rápido
Tudo exatamente nesta ordem. Ori explica a motivação para desenvolver o GEFS e portá-lo para o OpenBSD. Uma delas é que o UFS já está ficando datado. Para quem fala inglês, o vídeo abaixo é sua apresentação bem detalhada.
O GEFS do OpenBSD será um fork da versão do Plan9 onde todas as novidades do Plan9 estarão disponíveis para o OpenBSD. O GEFS já anda apresentando ótimo desempenho, ótimos resultados e agora, cabe a nós esperar para vê-lo em produção.
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).
