On Fri, Oct 24, 2014 at 10:56:16AM +0200, Helio Loureiro wrote: > Bem interessante esse artigo, mas o autor esqueceu que isso foi pra Jessie, > onde não havia definição, então tudo ficou com a possibilidade de alterar > entre sysvinit e systemd. O problema é tomar informação a partir de artigos, tanto mais artigos que tem seu argumento principal na vilanização do outro. Trolls? Se você se der ao trabalho de ler alguns argumentos, vai compreender que estão em disputa dois paradigmas de computação. Mais que isto, duas visões de comunidade. Na visão da extrema-direita estadunidense (os malucos do partido do chá, dentre os quais, os notáveis desenvolvedores do "sistema" em questão), os usuários devem apenas migrar para essa novidade brilhante sem se importar com isso e confiar que os desenvolvedores estão fazendo o seu trabalho. Os desenvolvedores, por sua vez, devem usar as ferramentas deles para desenvolver, já que claramente são superiores. Agora quais são as vantagens do sistema deles? Logs em binário? Cuidar de quase tudo no sistema? Não manter nenhum compromisso com outros desenvolvedores, não manter uma API ou interface estável, não manter diálogo com os desenvolvedores do kernel? Forçar a adoção de seu sistema com dependências múltiplas que lentamente sufocam a modularidade do sistema a um ponto em que se consideram forks de uma distro como o debian só para conseguir não utilizar o sistema deles? Empurrar a adoção de seu software por via de decisão de comitê técnico, voto de minerva, numa distro testing e depois dizer que a decisão é irreversível? Mesmo por uma decisão de assembléia geral de desenvolvedores e mantenedores debian? > Com a decisão de usar systemd, essa flexibilidade pode ser abandonada. Esse > é o grande problema. Fora que manter os pacotes com systemd/sysvinit pode > não ser uma tarefa fácil, ainda mais pros pacotes essenciais. Por isto acho que o shim, ainda que seja louvável o esforço, é fadado ao fracasso no longo prazo. Os mantenedores deste pacote estarão sempre escravos das novas e brilhantes idéias dos desenvolvedores do sistema, que desde sempre não se importam em manter uma interface estável, um código estável ou mesmo corrigir os bugs que criam. > Mas acho que esse é o caminho a se adotar. Não um fork do debian. Vamos esperar a decisão no debian-vote.
Attachment:
signature.asc
Description: Digital signature