A cada dia, nossos computadores se tornam uma parte cada vez mais importante de nossas vidas; se eles apresentam algum tipo de problema, isso afeta nosso humor, nosso senso de humor, haha. Claro, usuários do Windows são mais propensos a ataques de pânico: vírus ( viva o Linux! ), desfragmentação do HD, encontrar e instalar o Clean Master para PC ( embora aqui no Linux também precisemos limpar o sistema; o BleachBit é uma das alternativas preferidas ). Recentemente, alguns usuários de Linux têm experimentado uma certa dor de cabeça chamada systemd.
Enfim, indo direto ao ponto, li um artigo interessante sobre o systemd , que parece estar na moda ultimamente.
O Systemd , que alguns consideram ( e vou usar as palavras de um amigo ) como "o único anel para governar todos "... para outros, que são simplesmente indiferentes; contanto que o computador funcione corretamente, não se importam se o init faz X ou Y, ou se o systemd é usado. Quanto a mim, bem... digamos que prefiro o init; acho-o mais simples.
Deixo o artigo aqui:
Antes de começar, devo dizer que discordo veementemente da decisão de mudar as coisas no Debian, mas não tenho intenção de abandonar meu amado sistema. Estou simplesmente tentando garantir que, se formos discutir um tópico, o façamos da forma mais preparada possível, mesmo que eu não me considere um defensor do systemd. Para desmistificar o systemd, vou me basear em um site onde desenvolvedores compartilham suas perspectivas , que me foi apresentado por um colega que parece ser a favor do systemd, embora não seja usuário do Debian. Dito isso, acho que posso prosseguir e tentar desmistificar o que está sendo dito sobre o systemd.
systemd é baseado em binário
Talvez este seja um dos aspectos que mais nos chocam, se tudo é baseado em binário, como monitoramos o que costumamos fazer através de logs? Não tenho ideia de como esse mito nasceu, mas não é absolutamente verdade.
O systemd é configurado quase exclusivamente por meio de arquivos de texto simples. Algumas configurações que também podem ser alteradas com a linha de comando do kernel e por meio de variáveis de ambiente. Não há nada binário em sua configuração (nem mesmo XML). Apenas um arquivo de texto simples, direto e fácil de ler.
Aquilo é monolítico e controla tudo
Antes de chegar ao site citado, confesso que também pensei assim, mas depois de ler o que dizem seus desenvolvedores, minha opinião mudou algo ...
Se você compilar o systemd com todas as opções de configuração habilitadas, você criará 69 binários individuais . Esses binários executam tarefas diferentes e são cuidadosamente separados por diversos motivos. Por exemplo, o systemd foi projetado com foco em segurança; portanto, a maioria dos daemons é executada com privilégios mínimos (usando recursos do kernel, por exemplo) e são responsáveis apenas por tarefas muito específicas, minimizando sua superfície de ataque e impacto. Além disso, o systemd paraleliza a inicialização mais do que qualquer solução anterior. Essa "paralelização" é criada pela execução de múltiplos processos em paralelo. Assim, fica claro que o systemd é muito bem dividido em muitos binários e, consequentemente, processos. De fato, muitos desses binários são tão bem separados que são muito úteis fora do contexto do systemd.
Um pacote contendo 69 binários individuais dificilmente poderia ser chamado de monolítico. O que difere das soluções anteriores, no entanto, é que enviamos mais componentes em um único arquivo tar e os mantemos agrupados em um único repositório com um ciclo de lançamento unificado.
Isso não parece Unix
Certamente há alguma verdade nisso. Os arquivos de origem do systemd não contêm uma única linha de código das linhas originais do UNIX. No entanto, a inspiração é derivada do UNIX e, portanto, há muito UNIX no systemd. Um exemplo seria a ideia UNIX "tudo é um arquivo", que se reflete no fato de que no systemd todos os serviços são expostos em tempo de execução em um sistema de arquivos kernel cgroupfs. Portanto, um dos recursos originais do UNIX era o suporte a vários locais, com base no suporte de terminal integrado. Com o systemd, trouxemos suporte a vários lugares nativamente novamente, mas desta vez com suporte total para o hardware de hoje, abrangendo gráficos, mouses, áudio, webcams e muito mais. Na verdade, o design do systemd como um conjunto de ferramentas integradas, cada uma com suas finalidades individuais, mas quando usadas em conjunto, são mais do que a soma das partes, o que é mais ou menos o cerne da filosofia UNIX. Portanto, a forma como nosso projeto é tratado (ou seja, mantendo a maior parte do kernel do sistema operacional em um único repositório git) é muito mais próxima do modelo BSD (que é um verdadeiro UNIX, em oposição ao Linux) para fazer as coisas (onde a maior parte do sistema operacional central é mantida em um único repositório CVS / SVN), o que nunca foi o caso no Linux.
Em última análise, a questão de saber se algo é UNIX ou não importa muito pouco. Sendo tecnicamente excelente, dificilmente é exclusivo do UNIX. Para nós, o UNIX é uma influência importante (na verdade, a maior), mas também temos outras influências. Portanto, em algumas áreas o systemd será muito UNIX e em outras um pouco menos.
Isso é muito complexo ...
Certamente há alguma verdade nisso. Os computadores modernos são bestas complexas e o sistema operacional que roda neles obviamente também o será, então eles têm que ser complexos. No entanto, o systemd certamente não é mais complexo do que as implementações anteriores dos mesmos componentes. É mais simples e tem menos redundância. Por outro lado, construir um sistema operacional simples baseado em systemd envolverá muito menos pacotes do que os usos tradicionais do Linux. Menos pacotes torna mais fácil construir seu sistema, elimina as interdependências e muitos dos comportamentos diferentes de todos os componentes envolvidos.
Isso não me deixa usar scripts de shell
Isso é completamente falso. Simplesmente não os utilizamos no processo de inicialização porque acreditamos que não são a melhor ferramenta para esse propósito específico, mas isso não significa que o systemd seja incompatível com eles. Você pode facilmente executar scripts de shell como serviços ou daemons do systemd; você pode executar scripts escritos em qualquer linguagem como serviços do systemd, já que o systemd não se importa minimamente com o conteúdo do seu executável. Além disso, utilizamos scripts de shell extensivamente para nossos próprios fins: para instalar, compilar e testar o systemd. E você pode inserir os scripts no processo de inicialização, usá-los para serviços normais, executá-los no desligamento final — praticamente não há limites.
Neste ponto, suponho que algumas das principais crenças possam ter sido esclarecidas. Embora eu não me considere um defensor da mudança e tenha minhas reservas quanto à ideia de " um demônio para governar todos ", acho que, no fim das contas, ninguém ousará dizer que ele não funciona. Conheço até alguns usuários que notam que, com o systemd, "o PC funciona mais rápido", mas isso é assunto para outra discussão. Por ora, só posso convidá-los a debater seus pontos de vista aqui sobre o sistema init que muitas distribuições adotaram, embora as reações mais fortes estejam sendo vistas atualmente dentro da comunidade Debian, que inclusive criou um novo fork por causa disso tudo. Gostar ou não é uma questão pessoal; da minha parte, só quero contribuir para desmistificar o systemd, que estará presente no Jessie, a próxima versão estável do Debian.
Vi o artigo no GUTL (que por sua vez foi retirado do DesdeAbreus ).
Atual do Systemd?
Sou daqueles que não lê muitas notícias quando algo gera tanta polêmica, prefiro ficar com detalhes mais técnicos. A questão é…. Às vezes sinto que certos assuntos deixam de ser uma discussão ou debate puramente técnico, e passam a ser uma daquelas fofocas do showbiz
Primeiro, um desabafo aberto de um usuário sobre o systemd chamado "systemd VS inteligência" , depois Linus Torvalds dizendo que o systemd não é tão ruim quanto dizem ( e ele tem razão ), um fork chamado uselessd ... sem comentários... e, resumindo, finalmente o Devuan.
Não vou dizer se é tão ruim quanto dizem, menos ruim ou pior. O sistema funciona bem para mim, porém, pessoalmente, eu preferiria o init, pois gosto da maneira como ele organiza várias coisas (como os logs, por exemplo). Mas, ei, se o systemd vai ser chamado de cavalo de corrida e tiver que substituir o init ( será que ele seria nosso cavalo de trabalho, fazendo tudo, menos lentamente? ), bem... contanto que a mudança não seja drástica demais, os usuários possam se adaptar sem muita dificuldade e o sistema funcione melhor (sim, melhor, talvez isso não seja suficiente para mim!), então seja bem-vindo! 😉