Pular para o conteúdo principal

Por que o systemd poderá, a longo prazo, prejudicar o software livre?


Cancro (português europeu) ou câncer (português brasileiro), [...] é uma doença caracterizada por uma população de células que cresce e se dividem sem respeitar os limites normais, invadem e destróem tecidos adjacentes, e podem se espalhar para lugares distantes no corpo. Dicionário Informal



Embora pesada, a descrição acima pode ser facilmente utilizada para descrever uma novidade no mundo GNU/Linux que vem crescendo descontroladamente: um novo e polêmico sistema de inicialização chamado systemd. Se a Comunidade não tomar uma atitude séria agora, corremos o risco de, em pouco tempo, entrarmos em um caminho sem volta e só percebermos isso quando já for tarde demais.



Grosso modo, no mundo GNU/Linux e Unix-Like em geral, um sistema de inicialização é um programa ou conjunto de programas responsável por carregar (e gerenciar) os serviços (daemons) do sistema. O mais conhecido e clássico sistema utilizado no Pinguim é o velho SysVInit, cujas origens remontam aos gloriosos dias do Unix original. Apesar de funcionar bem, no entanto, ele não foi capaz de acompanhar a evolução da computação pessoal - principalmente nos dias atuais, quando processadores com múltiplos núcleos deixaram de ser exclusividade de grandes servidores ou estações de trabalho - e um substituto mostrou-se necessário.


Apesar de vários candidatos terem surgido, um se destacou entre todos eles: o systemd, criado por Lennart Poetering, que também nos deu o PulseAudio e o Avahi.


Graças à suas técnicas agressivas de paralelização e utilização de algumas APIs do kernel Linux, o systemd mostrou-se ser uma maravilha, podendo iniciar um sistema mais rápido do que qualquer outro concorrente. E, aí, começaram as intrigas.


Em Outubro do ano passado, os desenvolvedores do Debian decidiram qual seria o substituto do SysVInit. No ringue, o systemd de Poetering e o UpStart, da Canonical. Após a derrota da empresa sul-africana, começaram as intrigas e, recentemente, a discussão voltou à tona com um usuário publicando uma inflamada carta aberta na LKML contrária à adoção do sistema.


Mas o que poderia estar errado? Afinal, é apenas um sistema de inicialização... ou não?


Lembra-se da definição do início do texto? Pois bem, o systemd, assim como um câncer, está crescendo descontroladamente , tomando para si o lugar de outras funções vitais do sistema operacional. Enquanto apenas um sistema de inicialização, não haveria problema algum. Mas o fato, porém, é que hoje ele é um gerenciador de inicialização, um gerenciador de login, um gerenciador de logs e... um gerenciador de hardware, graças à recente absorção do udev.


Nem toda a evolução é boa...


A comunidade GNU/Linux sempre se identificou com a evolução. No entanto, nesse caso é necessário pararmos um momento para podermos enxergar o lugar para onde essa evolução está nos levando.


O fato de o systemd estar tomando para si partes vitais do sistema é preocupante porque ele, contrariando a maior característica do GNU/Linux - a portabilidade - é, desde o seu começo, Linux-Only. O fato de o ambiente desktop GNOME estar se tornando cada vez mais dependente do systend é um exemplo disso, pois chegará um ponto em que ele não poderá ser mais portado para outros unices, como a família BSD, justamente por causa do systemd e do Linux. Como resultado - e assumindo que, em breve, outros ambientes, como o KDE, serão forçados a adotá-lo para continuar no jogo -, construiremos uma prisão em torno de nós mesmos, na qual os ambientes e os programas feitos para GNU/Linux não conseguirão mais rodar em outros sistemas. Isso prejudicará todo o mundo livre e os sistemas Unix-Like em geral.


A solução para isso, felizmente, já existe: chama-se compilação condicional. Bastaria incluir, no código desses ambientes e programas, conjuntos de instruções #IFDEF e #ENDIF para fazer algo como: "Se o systemd está presente, faça dessa forma, senão, faça desse outro jeito". No entanto, essa solução tem um preço que, talvez, poucos desenvolvedores e mantenedores estejam dispostos a pagar: trabalho dobrado. Afinal, quem aceitaria ter de escrever meia dúzia de linhas para fazer algo com o systemd e, a seguir, escrever outras 50 para fazer a mesma coisa sem ele? É algo contra-produtivo!


O fato, porém, é que os usuários que dizem que não podemos parar a evolução estão cometendo a falácia lógica falso dilema, ao assumir que ou adotamos o systemd ou ficamos no velho SysVInit, desconsiderando todos os outros sistemas de inicialização existentes e disponíveis.


Esta é uma discussão nova e ainda é muito cedo para qualquer um tomar uma posição definitiva. No entanto, o futuro sombrio que eu modelei aqui é plenamente possível. Precisamos estudar e nos utilizar do diálogo e do bom senso para encontrarmos uma solução que mantenha nossa Liberdade e que permita aos desenvolvedores de outros sistemas portarem os programas feitos para o nosso.

Comentários

  1. Cerebro Vasconcelos15 de setembro de 2014 15:55

    Eu não entendo nada mas se prejudica a portabilidade PARA POR AÍ troço ruim

    ResponderExcluir
  2. Perfeito! Vale ressaltar alguns detalhes:
    1- O SysVinit remontam os gloriosos dias do Unix System V que era proprietario. O Unix do Bell Labs e os BSDs sempre utilizaram o RC como sistema de inicializaçao.
    2- A comunidade GNU/Linux nunca se preocupou muito com a portabilidade mesmo, a comunidade GNU sim (nao é a toa que o Richard Stallman é um dos responsaveis pela POSIX, acho que na época ele ja previa a merda que ia dar de ferir a liberdade dos usuarios de usarem o codigo onde quiserem). Mas atualmente as coisas pioraram, ate o launchd da Apple é livre e mais portavel.
    3- é engraçado o pessoal que preza pela inovaçao sacrificando a liberdade de portar o codigo, esquecem que a comunidade BSD cria mais codigo livre e portavel no mundo vide OpenSSH, LibreSSL e o atual systembsd. Isso pra nao falar do sistema de arquivos inovador que é o ZFS (que coincidentemente a mesma empresa que desenvolve o systemd e softwares Linux-only está criando um substituto Linux-only tambem...depois reclamam da Canonical e da Apple...) e o esquema das Jails do FreeBSD.
    4- Faltou argumentar o porque ele é nocivo para o software livre. Onde ele fere a liberdade.

    ResponderExcluir
  3. Marcos Paulo de Souza15 de setembro de 2014 21:58

    Interessante como as pessoas falam tanto que "o systemd não será portavel para outros UNIX-like". Parece que aqui todo mundo respira BSD e usa em casa para acessar a web. Vamos parar de ser um pouco chorões.

    ResponderExcluir
  4. Rapa eu li e choquei ao falar da suposta migração para BSD. Putz, isso n existe. Cada sistema Unix possui o seu formato de gerenciamento de inicialização de scripts e da mesma forma que eh com o systemd para trabalhar com gerenciamento em unidade eh assim no BSD a anos pelo launchd ( como ja trabalha o Darwin, alguns sistemas BSD e o OSX). Como em outros unics como o smf do solaris e outros. Systemd n eh para ser portado p outro sistema, pois ele segue um formato de "inicialização por unidades " que ja esta em outros unics a anos tanto como a mesma ideia do cgroups para linux baseado no kernfs ja usado no BSD desde 4.4.
    O formato dele ja existe a tempos, e esse padrão de "se n existe faça" existe e funciona absurdamente bem, por isso que arquivos como o fstab e outras coisas ainda funcionam muito bem. Por causa da compatibilidade. (E outras varias coisas como o formato e padrão de runlevel nele)

    Enfim, entendi a opniao de quem escreveu mas isso nao eh bem assim nao.

    ResponderExcluir
  5. Vocês são a prova de que ninguém é o dono da verdade... vivendo, aprendendo e aperfeiçoando!

    ResponderExcluir
  6. Cara, você usar MUITO mais BSD do que pensa...
    E como foi dito em vários outros comentários, a comunidade BSD cria centernas de aplicativos que são --facilmente-- portador para linux e que você usa.
    O mais notavel, que está presente em TODAS as distros e TODO usuário de linux AMA é o OpenSSH.

    ResponderExcluir
  7. Não acho que a coisa seja assim tão extrema quanto na matéria.
    Eu gosto maneira de trabalhar do Systemd e já estou até me acostumando com ele.
    Sou Adm. de Redes, e uso Linux desde 99, acompanhei toda a história do Ubuntu e do surgimento do Systemd, e há tempos esperava por uma solução mais práticas para os módulos e serviços do Linux. Pode sim haver um risco de que o Linux fique dependende do serviço, como foi falado na matéria, mas também podem vir coisas muito boas, como uma compatibilidade maior entre as distribuições, facilitando a disseminação do Linux como um sistema universal, seja Slack like, Gentoo like, Debian like, Arch like ou Redhat like, etc. Os novos adeptos se sentirão mais seguros em migrar para o sistema, a meu ver.
    Saudações a todos.

    ResponderExcluir
  8. Sobre o ítem 2...

    A comunidade GNU/Linux não é responsável pela portabilidade. Quem faz a portabilidade é quem está precisando dela. O artigo passa a impressão de quem faz o desenvolvimento, já o faz pensando na portabilidade, mas é o contrário: quem precisa da portabilidade começa a ajudar no desenvolvimento.

    Sobre o ítem 3...

    Que confusão, hein? BSD é uma licença, FreeBSD e OpenBSD são distribuições. O que é exatamente a comunidade? O ZFS nem usa a licença BSD, o OpenSSH é da OpenBSD, o LibreSSL é da FreeBSD, o systembsd, camada de compatibilidade para o systembsd, parece ser o único software citado para os *BSD.

    ResponderExcluir
  9. Fred, vc ta errado. BSD é uma familia de sistemas operacionais independentes derivados do BSD UNIX, sendo NetBSD, FreeBSD, Darwin, OpenBSD e DragonflyBSD. E nao, nao sao distribuiçoes, sao derivados, sao forks. O mundo BSD nao funciona como o mundo Linux com 33 distribuiçoes da mesma coisa, cada sistema operacional tem seu proprio codigo-fonte.
    Sim, a licença tambem se chama BSD.

    ResponderExcluir
  10. Sim, se vc usa Android, iOS, Mac OS X, Minix Playstation 3 ou 4 e PSP, vc usa BSD :)

    ResponderExcluir
  11. Se o problema é um software ficar dependente do Systemd, é só evitar que ele fique dependente do Systemd. O GNOME não *precisa* depender diretamente do Systemd. Afinal, na prática, todo software mais complexo precisa de uma camada intermediária que trabalhe com as diferenças e idiossincrasias de cada SO.

    ResponderExcluir
  12. Ué, você não usa BSD? O que você usa então?

    ResponderExcluir
  13. Então essa é a sua desculpa pra ser uma viúva do Upstart?

    ResponderExcluir
  14. Quando teu argumento abre com "Câncer" eu me lembro direto do Ballmer chamando o Linux de "Câncer"*, e já me preparo para o que vem pelo artigo. Que é basicamente mais um artigo de uma viúva do Upstart.

    Suas suposições pressupõe uma realidade que os desenvolvedores respondam à preocupações com a qualidade e segurança do Systemd dando a one finger salute. Na vida real, qualquer idiota deveria saber, não é isso que acontece.

    Não existe uma falácia lógica, devido a atual complexidade dos sistemas, o systemV não é mais adequado. Existem VÁRIAS alternativas, o Debian mesmo ficou entre ela e o Upstart, com a vitória do SystemD. Usa quem quer, e as pessoas querem, porque percebem claros avanços e práticos.

    Mas você sempre pode ficar usando uma distro que não inclua o SystemD, ou pode só ficar imitando o Ballmer.

    Claro, haveram desafios, que serão enfrentados, mas nada maior do que toda distro enfrenta desde... sempre.









    *http://news.softpedia.com/news/Steve-Ballmer-s-Legacy-Linux-Is-a-Cancer-378948.shtml

    ResponderExcluir
  15. Primeiramente, com exceção do udev e journald, praticamente todos os componentes do systemd são opcionais (ou seja, podem ser desativados na compilação com um --disable-blabla) e, ao contrário do que muitos dizem, não rodam no PID 1. O journald, apesar de não poder ser desativado, pode ser configurado para não armazenar nada e simplesmente repassar as mensagens para uma implementação syslog. openSUSE 13.1 e RHEL 7 o configuram assim. Quem estudar um pouquinho o código verá que é bastante modularizado.

    Segundo, os componentes do systemd, em particular o logind, foram criados para resolver problemas. E resolveram. Esses componentes usam APIs documentadas que podem ser implementadas pelos demais Unix-like. Lembro vagamente de um projeto para implementar as interfaces do logind no FreeBSD. Google para quem se interessar.

    O desenvolvimento do systemd é saudável. Existem dezenas de programadores com acesso de commit no repositório, de diferentes distribuições, empresas. A análise de patches é feita de forma técnica e a documentação é excelente. Aliás, aí está um diferencial na minha opinião: a documentação.

    ResponderExcluir

Postar um comentário

Postagens mais visitadas deste blog

Como acessar configurações avançadas no Sagemcom F@st 2704N

NOVO TUTORIAL: GUIA DEFINITIVO DAS CONFIGURAÇÕES AVANÇADAS DO SAGEMCOM F@ST 2704N!
Atualização 23/01/2015: Alguns problemas apontados e descobertos nesse modem:
1. Alguns usuários relatam dificuldade em salvar alterações na configuração ADSL;
2. Não sei como acessar os logs do modem; mesmo habilitando, eles não aparecem;
3. Se você trocar o DNS do modem, ele voltará ao da Oi ao ser reiniciado;
4. Estou enfrentando alguns problemas sérios de lentidão. Não sei se isso é relacionado ao modem ou a algum dispositivo na minha rede interna.
-----
Os modens da marca Sagemcom estão se tornando muito populares no Brasil, não, quiçá, por sua qualidade, mas porque eles são os atuais queridinhos das operadoras: quando você assina um plano ADSL, geralmente a operadora envia um modem wireless para sua casa a fim de que você possa navegar sem precisar ter gastos extras com esse equipamento. É claro que os equipamentos fornecidos pelas operadoras são básicos, mas saciam as necessidades dos usuários comuns - …

O Guia Definitivo das configurações avançadas no Sagemcom F@st 2704N

Há alguns meses, eu contei minha experiência com o Sagemcom F@st 2704N e tenho recebido diversos comentários sobre suas configurações avançadas. Agora que minhas aulas na faculdade estão acabando, resolvi reservar um tempinho para explorar melhor esse modem que, diga-se de passagem, é muito bom.