OpenRC em Manjaro isos para inimigos do Systemd

Hoje lendo meu RSS descobri uma notícia interessante que o Blog A aparência do replicador, e é que na Comunidade de Manjaro várias ISOs foram lançadas com a peculiaridade de não usarem Systemd como o init, senão OpenRCGenericName, o sistema de inicialização usado por Gentoo.

OpenRCGenericName

Não sei quanto a vocês, mas o tema Systemd já está tocando muito em mim, e quanto mais leio, mais percebo que embora para o usuário final (ou para muitos) não represente nada de super relevante, em pelo menos para mim, não gosto do caminho que isso está tomando. Eu acredito que uma temporada negra está chegando no mundo do GNU / Linux, onde bifurcações e descontentamento estourarão mesmo em desertos áridos.

Mas vamos ao que interessa. No fórum Manjaro eles publicaram, como eu disse antes, algumas isos que o OpenRC usa. E para quem tem medo de instalar essas versões, deixo o vídeo de como fazê-lo.

Baixe ISOs com OpenRC

A primeira ISO que veremos é a versão NetInstall. Este ISO possui as seguintes características:

  • Baseado no perfil Manjaro-Net (não tem nenhum Desktop Environment pré-instalado)
  • Com base no branch Testing.
  • Apenas drivers livres
  • Use Linux kernel série 3.14
  • Não usa Plymouth
  • Foi testado no Virtualbox

O idioma pode ser selecionado no início pressionando a tecla F2. Assim que o processo de inicialização for concluído, encontraremos o prompt, onde usaremos para acessar:

  • Usuário: root
  • Senha: manjaro

Para iniciar a instalação conforme mostrado no vídeo anterior, escreveremos:

setup

Links para baixar as ISOs

manjaro-net-0.8.11-openrc-i686.iso (Bit 32)
(md5sum: 80be54ecfb0360b2a8e544344f72113c)

manjaro-net-0.8.11-openrc-x86_64.iso (Bit 64)
(md5sum: ef205f70f3b3428545fdf1420db10b74)

Instruções pós-instalação

No Fórum Manjaro Eles nos oferecem alguns dados para Pós-instalação:

Adicionamos o repositório openrc-eudev seguindo estas instruções.

1) Adicionamos o seguinte no final de /etc/pacman.conf

[openrc-eudev] SigLevel = Servidor TrustAll opcional = http://downloads.sourceforge.net/project/mefiles/Manjaro/$repo/$arch

Adicionamos e importamos as chaves:

sudo pacman-key -r 518B147D sudo pacman-key --lsign-key 518B147D

2) Nós atualizamos o sistema

sudo pacman -Syu

3) Instalamos nosso ambiente de desktop preferido, o exemplo usa lxde

sudo pacman -S lxde

Informações sobre a instalação de ambientes de desktop podem ser encontradas no wiki.

4) Instalamos um Session Manager:

sudo pacman -S lxdm-consolekit
O Gerenciador de Sessão também deve ser definido no arquivo /etc/conf.d/xdm e há mais informações clique aqui y clique aqui

5) Instalamos alguns pacotes como o miniaplicativo para networkmanager

sudo pacman -S gerenciador de rede applet

6) Reiniciamos o sistema

reiniciar

Acho que nem preciso dizer que, para isso, precisamos estar conectados à Internet por meio de um cabo. Se usarmos WiFi, você pode ver como fazer em este link.

Manajaro ISOs com OpenRC e OpenBox

No caso do Openbox ISO, algumas coisas devem ser levadas em consideração:

  • O objetivo principal é fazer o processo de instalação mais fácil e permitir configure forma gráfico rede (vestindo perverso) e o particionamento uso GParted opcionalmente.
  • A configuração inclui Openbox WM, LXTerminal, PCMan e NetSurf Web Browser (para buscar informação no wiki o google), etc.
  • Use o instalador do console.

Links para baixar as ISOs com OpenRC:

manjaro-openbox-openrc-2014-11-13-i686.iso (Bit 32)
(md5sum: 9be7e75c75ab296f955a3396386c4764)

manjaro-openbox-openrc-2014-11-13-x86_64.iso (Bit 64)
(md5sum: 07fd57df022118dfc9e2794a0ca3d26e)

Manjaro XFCE ISO com OpenRC

Apenas experimentalmente e para 64 bits, existe também uma ISO com XFCE:

manjaro-xfce-openrc-2014-11-14-x86_64.iso (Bit 64)
(md5sum: e132f294f2ffd99c6cbc371d1e7a6d72)


Deixe um comentário

Seu endereço de email não será publicado. Campos obrigatórios são marcados com *

*

*

  1. Responsável pelos dados: Miguel Ángel Gatón
  2. Finalidade dos dados: Controle de SPAM, gerenciamento de comentários.
  3. Legitimação: Seu consentimento
  4. Comunicação de dados: Os dados não serão comunicados a terceiros, exceto por obrigação legal.
  5. Armazenamento de dados: banco de dados hospedado pela Occentus Networks (UE)
  6. Direitos: A qualquer momento você pode limitar, recuperar e excluir suas informações.

  1.   um de alguns dito

    Você está certo, o problema do systemd começa a emitir um certo cheiro, já que o OpenRC é o sucessor natural do init atual. Vamos ver onde essa história termina.

  2.   William dito

    “Embora para o usuário final (ou para muitos) não represente nada de super relevante”

    Acho o mesmo, não é relevante porque como usuários não nos afetou no funcionamento do próprio SO.

    Na verdade, o único grande (debian), deu notícias de "escândalo" sobre o assunto, e embora digam que há outros motivos, todos os systemd relacionados (e não deveriam).

    As outras grandes distros, que não causaram problemas (ou pelo menos se manifestaram com espadas e tochas), Fedora, Ubuntu e OpenSUSE.

    Me dá a impressão que se trata de uma briga entre programadores, já que por exemplo o opensuse 13.2 tem uma boa aceitação / crítica e ninguém nas avaliações fala de systemd (mesmo que seja para estabelecer debate),

    Agora, por que tanto barulho para ir do systemd para o OpenRC, se no final isso não os afeta.

    1.    dero dito

      Pessoalmente, sobre o systemd, isso me deixa desconfortável e inseguro, boa postagem.

    2.    yukiteru dito

      No Fedora, houve algum debate sobre o systemd quando foi decidido colocá-lo como init, houve alguns detratores do sistema, principalmente porque eles não concordaram em usá-lo como init por padrão porque era muito novo e tinha muitas falhas, no entanto , a maioria dos principais desenvolvedores está na equipe de desenvolvimento principal e estavam relacionados ao systemd, portanto, a substituição do Upstart pelo systemd foi um sinal de alguma imposição, além do problema de que o Upstart era um desenvolvimento do Ubuntu e tinha um CLA bastante desajustado sobre, que no final ajudou todos a aceitar o systemd sem questionar. O OpenRC estava fora de questão na época, pois faltava muitos dos recursos que tem agora, incluindo paralelização e suporte a cgroup.

  3.   anônimo dito

    Boas notícias! uma distro binária que o openrc vai lançar ... é como uma dádiva de Deus.
    É o caminho que o archlinux deveria ter seguido desde o início, lembro quando tive que endossar o archlinux para ir para o systemd. Agora eu tenho a possibilidade de testar novamente uma distribuição binária com openrc + eudev que é exatamente o que eu uso aqui no gentoo.
    Muito obrigado pessoal do Manjaro !!!

    # eix -Ic openrc
    [I] sys-apps / openrc (0.13.6@24/11/14): OpenRC gerencia os serviços, inicialização e desligamento de um host
    # eix -Ic eudev
    [I] sys-fs / eudev (2.1.1@31/10/14): Suporte à nomenclatura de dispositivos Linux dinâmico e persistente (também conhecido como devfs de espaço de usuário)

  4.   xiep dito

    Obrigado pela informação, elav!

    Eu compartilho sua opinião sobre o systemd e também estou preocupado com a tendência que o Linux tomou desde o surgimento deste novo init. Se Wheezy ficar muito velho antes que a bifurcação do Debian chegue, vou pensar em dar uma chance ao Manjaro OpenRC, já que não tenho tempo livre para preparar um sistema Gentoo (valorizo ​​isso, mas definitivamente o tempo de compilação do Gentoo extenso demais para minha situação pessoal).

    Saudações!

  5.   Cristian dito

    Elav você pode descrever em menos de 10 palavras para um usuário que não entende muito a "polêmica", há um tempo atrás existem vários artigos no blog que estão sendo muito técnicos, e eles não acabam de explicar o contexto para o " não iniciados "... sempre Me falaram que independente da técnica, uma explicação deve ser entendida até pela sua avó para ser boa.

    Na verdade, no fedora, há um tempo atrás, o problema estava se tornando insuportável, tanto que vários usuários de desktop pensavam em mudar para o centos, para contornar o problema

    1.    Luis dito

      Eu me inscrevo para esse pedido.

      O Systemd funciona bem para mim. Qual é o problema que causa tanto movimento?

      Digamos que não sei.

    2.    dario dito

      systemd é o programa encarregado de iniciar o sistema, mas seus desenvolvedores decidiram estendê-lo e agora não só lida com a inicialização, mas também coisas como cron (programa para executar programas automaticamente), a rede, os logs do sistema que, a propósito, são binários, entre outras coisas

      Muitos não veem com bons olhos uma mudança tão abrupta, principalmente por se tratar de um software novo, portanto com muito mais bugs do que programas que funcionaram a vida toda, além de gerar dependências na hora de programar e por exemplo o gnome está cada vez mais vinculado a este sistema. Tornando-o menos portátil para outras plataformas Unix.

      Não sei se o meu outro comentário não passou na moderação mas dizia que gostei do systemd mas não deviam deixar monopolizar todas as distribuições e deixar alternativas como sempre foi feito no Linux para quem tem necessidades diferentes.

    3.    dario dito

      Devo dizer que antes o programa encarregado de iniciar o sistema na inicialização era o system v, que já existia há muito tempo até ser substituído na maioria das distribuições pelo systemd xD.

    4.    elav. dito

      Ao que @daryo diz, adiciono o seguinte (que também é minha opinião):

      Sempre gostei da filosofia Unix, onde um programa faz apenas uma coisa, mas faz bem. Quando o Systemd deseja controlar tudo que @daryo disse a você, tenho uma pequena dúvida e o que aconteceria se o Systemd fosse de alguma forma comprometido? Bem, possivelmente arrastaria tudo que controla com ele.

      A isso acrescento (e talvez isso seja mais por hábito), que sempre gostei que meus logs do sistema sejam arquivos de texto puro, mas com o Systemd tudo é binário e comandos como:

      cat log.txt

      o

      tailf log.txt

      Onde poderíamos usar outras opções como GREP para filtrar determinado conteúdo, mas o Systemd usa um comando nomeado jornalctl.

      Além do mencionado acima, devo dizer que sendo RedHat o principal expoente do Systemd, recebo um alerta de que não posso desligar. Talvez eu esteja errado, mas isso não parece bom .. E fico me perguntando qual a necessidade de controlar o boot, o cron, a rede e quanto serviço existe? O que eles querem dizer com isso?

      1.    Alexander dito

        Graças ao seu comentário e ao que venho investigando, posso confirmar suas suspeitas, esse alerta está correto, Broder.
        Você verá que tenho lido sobre o TCP Stealth, é uma tese alemã onde acusam a Red Hat de facilitar a espionagem industrial para os sistemas de escuta dos 5 olhos:
        Já escrevi sobre isso, se você tiver o talento necessário, eu sei que você tem, você pode tirar suas próprias conclusões:
        https://gnunet.org/sites/default/files/ma_kirsch_2014_0.pdf
        http://heise.de/ct/artikel/GCHQ-NSA-El-programa-HACIENDA-2293098.html#Invisibilidade TCP

      2.    yukiteru dito

        Apenas para complementar seu comentário @elav, o systemd é tão alto que agora afirma controlar o seguinte:

        1.- Gerenciamento de conexões de internet com IPv4 e IPv6, usando systemd-networkd e systemd-nspawn.
        2.- Gerenciamento de DNS através de um cache DNS interno, resolvido por systemd.
        3.- Gerenciamento de DNS multicast em redes internas, usando systemd-networkd.
        4.- Gestão de terminais TTY em Linux, utilizando consolado systemd. (Tchau KMScon?)
        5.- Gestão de sessão e privilégios através de logind.
        6.- Controle coredump, usando arquivos binários, e pulando as diretivas do kernel.
        7.- Controle de logs, usando arquivos em binário, e pulando as diretivas do kernel.
        8.- Controle de eventos ACPI usando logind. (Systemd-212 adicionou várias dores de cabeça aos devs da Nvidia com vários bugs que tornavam o sistema inútil)
        9.- Suporte PPPoE para networkd, trabalho que ainda está em andamento.
        10.- Suporte para DHCP em cliente e servidor. (O que eles fazem com isso? Não faço ideia)
        11.- Suporte para sistemas com reset de fábrica, que por sinal está intimamente ligado ao BTRFS (não se surpreenda se o BTRFS mais tarde se tornar uma dependência do systemd, bom Lennart adora)
        12 ..- Suporte para contêineres virtualizados (principalmente Xen e KVM)
        13.- Suporte para gerenciamento e inicialização de dispositivos (o que udev faz)
        14.- Tratamento de sistemas de criptografia de disco.
        15.- Carregando firmware e módulos do kernel.
        16.- Manipulação de hostname (cria até um identificador único de seu PC), premissas, hora, sincronização NTP, sysctl (variáveis ​​de controle do kernel), e até mesmo o gerador de números aleatórios (Muito WTF isso, e levanta muitos suspeita)
        17.- Tratamento de sistemas de arquivos temporários.

        Resumindo, estão as coisas que eu sei que o systemd faz, se é que alguém sabe mais do que dizer :).

        PS: o systemd não oferece mais suporte para scripts LSB e SysV desde o systemd-214, então não sei se o suporte "legado" deles é verdadeiro agora ou se eles são compatíveis com os padrões. Eu digo que o LSB ainda é o padrão no Linux ou estou errado?

        1.    Alan Herrera dito

          Obrigado por me avisar, eu estava pensando em ir para a BTRFS, mas sabendo que Lennart gosta dele, você deve saber que ele deve ser horrível e espionar a NSA-IBM

    5.    anônimo dito

      Há pouco espaço para resumir e explicar tanto ... é um cavalo de Tróia gigante, que eles nem tentam exibir. O que um sistema de inicialização faz ao colocar serviços de rede, dhcp dns e até mesmo eu acho que avahi ... no systemd? O poder de decisão é perdido por não ser capaz de gerenciar serviços
      que não são desejados e que não chegam até mim que podem ser desativados, não os quero no pacote systemd!
      No OpenRC, um é quem decide o que é iniciado em cada nível de execução, alguns serviços têm dependências de outros serviços, mas são muito poucos e estão listados ... enquanto no systemd qualquer coisa faz o que quer no momento … Para ganhar cerca de 5 segundos na inicialização e ser rápido no desligamento.
      O Systemd é tão complexo que é impossível saber o que ele faz, você tem que se resignar a pensar que ele é seu mestre e não faz nada de errado com você.
      O Systemd quebra o conceito de que as coisas devem ser fáceis e compreensíveis em termos de daemons ou serviços e níveis de execução, ninguém que usa o systemd sabe totalmente o que acontece em seus serviços o tempo todo.
      O Systemd não permite o uso de syslog-ng nativamente, eles fizeram o journald pisar nele e ele não o deixa funcionar, ou seja, ou você usa o journald ou o naninga!. O log do sistema é fundamental para a segurança e auditoria do que aconteceu e está acontecendo com as conexões locais e remotas, mas o journald usa um formato binário que só o jornalctl pode ver .... Muitas vezes o journald fica corrompido "misteriosamente" seu arquivo binário e como ele o vê corrompido, ele o apaga uma vez e começa com um novo, esquecendo todos os logs que já existiam.
      Posso continuar por horas, mas o pior problema é que Lennart não dá a mínima para quem relata esses erros e, pelo que eu li, ele não aceita patches de ninguém.
      Eu pensei que ao entrar no systemd, eles relatariam bugs e patches, que o systemd teria que aceitar ... mas eu honestamente acredito que Lennart e RedHat têm outro plano para o resto das distros ... como eu disse antes , CAVALO DE TROYA de RedHat.
      Honestamente, para mim, o systemd não pode ser corrigido, a ideia por trás de seu design é terrivelmente ruim, é melhor iniciar um sistema inicializável do zero do que tentar consertar aquele frankestein.

      1.    elav. dito

        AMÉM!! @anônimo..

      2.    Kunagi dito

        Tenho usado o systemd (Fedora) por alguns anos e cheguei a este:
        O problema tem um cheiro estranho, pois mais coisas adicionam mais desativar / redirecionar.
        O journald eu direcionei para rsyslog diretamente. Algum log binário seu já foi quebrado.
        Do dns eu uso o bind, se eles integrarem no systemd continuarei a usá-lo da mesma forma, embora tenha que modificar tudo.
        Eu uso o XFCE, então me economiza muito do que o gnome quer integrar.
        É como um elefante em uma loja de porcelana.

      3.    Tito dito

        Verdadeiro; nem mesmo eles sabem como chamá-lo. Saímos para atualizar diariamente, corrigindo bugs e outras porcarias. É um assunto que me deixa bastante zangado; mas não apenas por causa do fato de que SystemD é uma merda soberana; se não como eles fizeram isso.
        É claro que no mundo Linux, existem várias empresas que tentam controlar tudo; veja Canonical, RedHat e Gnome, (até o próprio Miguel de Icaza deixou o Gnome).
        Se eu uso o Linux, é por causa de quem eu o controlo e essa é a base e a filosofia dele; Para não saber o que está fazendo, monto máquinas com o W Server já rodando.
        O que sinto muito é que o Debian sucumbiu. Na verdade, a possibilidade de criar uma bifurcação paralela sem SystemD está sendo considerada.
        Vamos torcer para que as coisas não piorem; ou me vejo migrando todas as minhas máquinas para o BSD.

      4.    yukiteru dito

        @ anônimo, comentário homem, você não pode estar mais certo.

        systemd é uma coisa maluca que não tem explicação em muitas coisas, a verdade causa muita desconfiança em tudo que faz e não permite que outras ferramentas façam, a verdade é que não sei como o pessoal do Debian se permite colocar isso, mas no final eles já tomaram essa decisão e, pela primeira vez em muitos anos, parei de usar o Debian como o sistema operacional principal e continuarei até que o systemd saia do Debian para uma opção mais transparente.

    6.    Tito dito

      Em resumo. SystemD é uma merda.
      Armazena os logs em formato binário, é executado como processo pai de todos os outros, (Pid 1), com o qual se alguém quebrar, o sistema fica irrecuperável; Vai contra tudo que o Linux representa, ou seja, arquivos de texto simples, (o que diabos são esses arquivos binários ??, arquivos de texto simples! Como toda a vida de Deus).
      Vamos, isso é uma merda. Eu não gosto de nada.
      Mas graças a empresas como Canonical, Gnome e Red Hat; vamos comê-lo com batatas.
      Isso se, embora existam outras opções; Não vou utilizá-lo, nem nos servidores que administro, nem nas minhas máquinas pessoais.
      Isso já está se tornando uma filial da empresa Redmond.

      1.    sephiroth dito

        Não quero defender ninguém, mas me lembro bem que o canônico era totalmente contra o systemd em favor do arrivista. quando o debian cedeu ao systemd ele acabou arrastando para o ubuntu.

  6.   dario dito

    Além disso, esses bugs podem comprometer a segurança do sistema e a estabilidade de um servidor, por exemplo, por isso quem mais reclama dessas coisas é o administrador de sistemas.

  7.   Alexander dito

    E quanto à Mageia, é incrível que um KDE possa rodar em 512 MB de ram, impecável.
    http://mirror.cedia.org.ec/mageia/iso/cauldron/

  8.   Sergio E. Duran dito

    algumas questões; É fácil gerenciar os serviços no OpenRC? e quão fácil é instalar usando-o por padrão em uma instalação Manjaro com systemd? o que eu gosto no systemd é que com o comando simples systemctl enable (service) .service ou um systemctl disable (service) .service eu posso gerenciar meus serviços facilmente, SE eu estiver interessado em saber sobre OpenRC e especialmente se ele cheira um pouco estranho tudo isso do systemd, aliás; Eu sou um usuário novell

    1.    Sergio E. Duran dito

      Por certo; Diz que estou no Windows porque estou usando o agente de substituição do usuário

    2.    anônimo dito

      O OpenRC é muito fácil de manusear, eu dou um exemplo com o serviço de impressão cupsd.

      Para começar.
      # rc-service cupsd início
      * Iniciando o cupsd .. [ok]

      Para parar.
      # rc-service cupsd parada
      * Parando o cupsd ... [ok]

      Para reiniciá-lo.
      # rc-service cupsd reiniciar
      * Parando o cupsd ... [ok]
      * Iniciando o cupsd .. [ok]

      Para colocá-lo para iniciar no nível de execução padrão.
      # rc-update adiciona o padrão do cupsd
      * service cupsd adicionado ao runlevel default [ok]

      Para removê-lo do nível de execução padrão.
      # rc-update do padrão do cupsd
      * service cupsd removido do nível de execução padrão [ok]

      Para ver o status de todos os serviços em todos os níveis de execução.
      # rc-status -a

      Para ver o status de um nível de execução, neste exemplo é o padrão.
      # rc-status padrão

      Aqui no gentoo, o OpenRC é o sistema de inicialização padrão e permanecerá assim para sempre, temos o systemd no portage para homens-bomba, que felizmente são poucos….
      Para substituir o journald, usamos syslog-ng e logrotate, aqui no gentoo o log do sistema sai através do console virtual vt12 que é control + alt + F12, ou você pode vê-lo continuamente em qualquer terminal gráfico como usuário root com:

      # tailf / var / log / messages

      1.    Sergio E. Duran dito

        E para instalar no meu Manjaro?

      2.    Sergio E. Duran dito

        Eu digo; Não vou perder todos os arquivos e meu lindo XFCE só por mudar para o OpenRC 🙂

      3.    Sergio E. Duran dito

        Pronto; Eu instalei usando sudo pacman -S manjaro-openrc bluez-openrc (este último porque eu tenho bluetooth)

      4.    Sergio E. Duran dito

        Agora, meu problema é que o gerenciador de energia XFCE4 não funciona com upower-pm-utils 🙁 e eu não tenho as opções típicas de suspender e Hibernar

    3.    yukiteru dito

      O OpenRC é muito simples, gerenciar serviços é moleza, só para dar um exemplo:

      Habilite um serviço: rc-update add cronie default

      Inicie um serviço: /etc/init.d/cronie start ou rc-config start cronie

      Pare um serviço: /etc/init.d/cronie stop ou rc-config stop cronie

      Simples e não muito complexo.

  9.   yukiteru dito

    @elav o que vem pela frente é para o longo prazo, variando de tempestades de areia, chuva de trolls, bifurcações em massa, divisões de grupos de desenvolvimento e muitos se perguntando se migrar para o BSD é uma opção melhor do que ficar preso no systemd, porque sim.

    Pessoalmente, aplaudo essa iniciativa do Manjaro, é uma opção para quem não quer ficar com o systemd, algo que eu gosto, no momento estou no Gentoo e gosto disso, me sinto confortável com a liberdade que ele me dá , mas agora já me passou pela cabeça várias vezes para fazer a mudança para o FreeBSD, e posso dar o salto este mês, tudo depende do meu tempo e de certas coisas para fazer a migração com sucesso.

    1.    yukiteru dito

      Nada disso refuta a realidade do systemd, Lennart é muito bom em evitar coisas e responsabilidades, eu recomendo que em vez de apenas ler artigos, ler o código do systemd ou pelo menos ler a lista de desenvolvimento do systemd, você descobrirá coisas que refutam o que esses três artigos dizem que aconteceu, e apóiam mais os detratores do systemd.

      1.    pamp dito

        Seu argumento é estabelecer que há conhecimento que refuta o que mostrei, mas nunca apresenta as evidências, portanto não posso confiar em sua existência.
        https://lists.debian.org/debian-ctte/2013/12/msg00234.html

      2.    yukiteru dito

        @pamp meu argumento é um pouco mais de suporte porque eu o expliquei acima no comentário 25 desta mesma entrada, e eu o expus em muitas outras entradas relacionadas ao systemd, além de expô-lo no Debian irc e na lista desta distribuição, também o meu convite, é que você crie suas próprias opiniões e para isso basta ler um pouco a lista de desenvolvimento do systemd. Também apenas para despertar sua curiosidade, apresento este link no qual eles dizem claramente que o systemd-214 não oferece mais suporte para scripts SysV e LSB, com a desculpa de "limpeza de código".

        http://lists.freedesktop.org/archives/systemd-devel/2014-June/019925.html

        Agora me diga: Onde está o suporte para o padrão LSB que supostamente foi criado para criar uma base comum para todas as distros? Porque deixe-me dizer uma coisa, nada mais em seu primeiro link Lennart plumps, se gaba e enche a boca dizendo que o systemd suporta o uso de scripts SysV e LSB, quando a verdade é que o suporte é abandonado e substituído por um gerador de arquivos init , a propósito, tem vários bugs e no final não há outra opção a não ser fazer um arquivo init completo.

        Saudações.

    2.    Tito dito

      As opiniões são como a bunda, todos nós temos uma.
      O que este homem diz pode ir muito bem para ele, mas não é o meu caso. E a opinião de um homem que escreve em um portal da web não é que seja a palavra de Deus. É a sua opinião, ponto final.
      Então, "refutado", nada.
      A coisa boa que resta para nós é que podemos usar o que realmente queremos; sem tentar ser "Talibã" e impor nossos critérios aos outros.
      Para mim, o SystemD é uma merda real. E há pessoas que adoram. Bem, seja bem-vindo!
      Nem a minha opinião é boa nem a de quem não pensa como eu é uma merda; eles são simplesmente diferentes.
      Isso é o que nos distingue de outros sistemas operacionais; podemos escolher.
      Não vamos entrar em lutas inúteis que não levam a lugar nenhum.

      1.    anônimo dito

        @Titus
        Você não poderia ter dito melhor ... amém.
        Você tem que ser cego para não perceber a perversidade que o systemd impulsiona para cobrir tudo, pisando, cobrindo e deslocando projetos que funcionam perfeitamente, substituindo-os por versões que nunca alcançam ou se tornam estáveis, mesmo não havendo compatibilidade entre núcleos e mais de dois versões anteriores do systemd.
        Parece aos debian que o terremoto veio e eles conseguiram acordar, eu só espero que eles se inclinem para eudev e openrc, desta forma o desenvolvimento de gentoo debian manjaro e alguns outros que usam openrc seriam unificados, o que o melhoraria um muito em pouco tempo, conquistando toda a comunidade.

      2.    dah65 dito

        Eu apoio suas palavras.

        Existem pessoas que citam outras pessoas (as opiniões que lhes interessam, em geral) e as usam como evidência.

        De minha parte, não tenho uma opinião sobre o systemd. Não sei se é tecnicamente melhor do que upstart ou openrc, mas o que parece claro é que a possibilidade de sysvinit é descartada por TODAS as distros, sendo o Debian o único que ainda o tinha no Wheezy devido à sua política. Mas o próximo Debian estável, Jessie, seria um Debian sem sysvinit.

        O que está claro é que eticamente é 100% software livre; Quanto à parte técnica, não estudei o código nem o comparei com suas alternativas, portanto não tenho opinião fundamentada. Mas até mesmo o Ubuntu de hoje usa partes do systemd, embora eles ainda tenham o upstart, e eu duvido que tenham, porque a Canonical foi "comprada" pela Red Hat.

        Systemd não é "mal", por favor, não estamos lutando contra a Skynet (Terminator), ou HAL9000 ("odisséia espacial de 2001"), nem é o lado negro da Força que busca dominar os Jedi. Nem é que, ao se estabelecer em uma equipe, toma conta de tudo e faz até os alimentos da despensa desaparecerem.

        E que "move projetos que funcionam perfeitamente" (comentário 52), tive problemas com uma rede NFS doméstica nos computadores que acessam o servidor porque o processo de desligar o computador cliente desconecta a rede antes de desmontar o sistema NFS, e o desligamento travaria, sendo a única solução pressionar o botão liga / desliga para desligar à força (bug relatado por vários usuários); Tive que criar um script que desmonta os arquivos NFS para serem executados antes de desligar a máquina cliente. Por outro lado, o computador servidor NFS se conecta via wifi, e de vez em quando a conexão é perdida: não sei se o problema é o gerenciador de rede ou está no dhcpd, ou onde.

        Não estou dizendo que esses problemas desapareçam com o systemd; Eu o ignoro porque não o usei. Este é apenas um exemplo de que dizer que os projetos que o systemd substitui funcionam perfeitamente é um exagero.

      3.    yukiteru dito

        Uma coisa é uma opinião e outra é um argumento, certamente a primeira é muito variada como você diz @Tito, mas a segunda é algo mais conciso e focado, não é algo que pode ser tão facilmente manipulado, pelo menos, não no caso de software livre, onde temos o código ao nosso alcance para revisar.

        @pamp nos diz que os argumentos mostrados foram refutados por um longo tempo, e como um primeiro teste ele nos atualiza com as opiniões de Lennart (não argumentos). Mas o que esse cara diz em seus comentários é uma coisa (os números 4 e 8 são apenas para morrer de rir) e outra é o que ele faz no código do systemd. Uma atitude que tenho visto repetidamente em Lennart desde que comecei a desenvolver coisas como Avahi e Pulseaudio, e que pode simplesmente ser corroborada lendo as listas de desenvolvimento e os relatórios de bugs de ambos os softwares.

      4.    yukiteru dito

        @ Dah65 certamente muitas pessoas empunham evidências usando as opiniões de terceiros, um mau hábito para quem não consegue investigar as questões por conta própria para ter sua própria opinião e pessoal, e até mesmo criar argumentos válidos para participar de uma discussão construtiva.

        No meu caso, mantenho-me atualizado sobre as mudanças no systemd graças à lista devel, embora não goste da ferramenta, não gosto totalmente dela, mas não paro de ler sobre ela no nível técnico e do usuário, e motivo Para isso é muito simples, se tenho que atender um cliente que utiliza o dito init, sei o que devo fazer e como atender qualquer situação.

        Agora sobre o que os serviços rodam sem problemas, isso é uma falácia, existem muitos scripts SysV com problemas, e o mesmo acontece no systemd, mas pelo menos quando você relata um erro em um SysV eles são corrigidos ou você pode fazer em um maneira simples como você comentou, no systemd, depois de fazer um relatório de bug você pode encontrar um WONTFIX ou CLOSED, graças a Lennart ou Kay, conforme o caso e não estou exagerando ao dizer isso, um exemplo aqui:

        https://bugzilla.redhat.com/show_bug.cgi?id=753882

        Leia o comentário 48, você não tem nenhuma perda. O 53 de Clemente é outro que não tem prejuízo, principalmente por sua solução arcaica mas funcional para o problema que Lennart não quer resolver e que aliás foi reportado em 2011.

    3.    mario dito

      Esses "mitos" que os estabeleceram? Alguns foram removidos da galeria porque "o systemd não é portátil sem motivo." É totalmente verdade que não é portátil (e ele admite dizendo que é muito personalizado para Linux)
      Ele assume falácias, como a suposição de que o BSD não está interessado (os caras do BSD dizem o contrário: "Jordan Hubbard - FreeBSD: The Next 10 Years (MeetBSD 2014)"), mesmo se fosse portátil eles não o adotariam e coisas assim assim (mito 13,14,15).

      Se a intenção de Poettering é que reescrevamos scripts, exclusivos para o seu sistema (http://0pointer.de/blog/projects/systemd-for-admins-3.html) vamos dar errado. Em princípio, um script init clássico não se importa para onde você está indo. Modificações mínimas são feitas para funcionar em GNU, UNIX ou BSD. Bem, isso era até agora (a menos que o OpenRC seja usado). De qualquer forma, acho que coisas como essas produzirão uma divisão entre o Linux para desktop e servidores. Ubuntu e usuários derivados só verão as mudanças no final do próximo ano.

      1.    anônimo dito

        @ Dah65

        Bem, já que você diz que o systemd não é a perversidade personificada, então me diga por que eles não colocam as opções do Makefile para desabilitar todos os seus módulos em tempo de compilação, para que aqueles de nós que não gostam de ter esses "módulos opcionais "essa etapa em outros pacotes, para que possamos compilá-los e criar nossas próprias versões do systemd capped!
        Você sabe por que eles não fazem? Como sua forma de desenvolvimento é chamada de imposição forçada e como 95% dos usuários não possuem NPI, eles aproveitam o padrão, recusamos para todos vocês.
        É assim que o software livre ou de código aberto ou como eles quiserem não funciona, agora me faz rir, porque com o novo fork do Debian muitas pessoas pensam que é um desperdício de força e fico me perguntando como difícil foi colocar opções de compilação adicionais Makefile?
        A questão não dá para mais, é como querer misturar água com óleo, por isso haverá bifurcações infinitas em cada empreendimento onde há imposição de uns poucos para todo o resto.

      2.    yukiteru dito

        @mario é exatamente o que você diz. Jordan Hubbard também percebeu que o init BSD precisa ser atualizado não apenas para se adaptar às novas tecnologias, mas também para suportar novos recursos que agora são possíveis, mas ele contorna o conceito que o systemd agora tem de como eles devem ser feitos. coisas, e eles simplificam para a filosofia que sempre prevaleceu no UNIX, "Faça um programa que faz uma coisa e faz bem", e isso em um init é extremamente importante, já que não estamos falando de mais um demônio, nós estamos falando do init de um sistema operacional, além de ser uma medida de segurança, em comparação com o que muitos especialistas já estão começando a reclamar do systemd, e é demonstrável, o systemd se parece muito com svchosts.exe do Windows, fazendo a partir do inicialização de serviços para controle de rede, entre muitas outras coisas.

  10.   Luis dito

    Gente, é realmente assustador.

    É muito complicado remover do ArchLinux ????

    Vou procurar informações, mas não me atrevo a tocar nesse tipo de coisa para não estragar e perder meu sistema.

  11.   manu dito

    Dos muitos comentários que li, o SYSTEMD é um verdadeiro TROYAN HORSE….
    Isso significa salvar quem pode? Há pouca informação em espanhol sobre a configuração da área de trabalho no FreeBSD e como preparar o sistema para ser usado.

  12.   Rafael Mardechai dito

    Pobre systemd, deixe estar. xD

  13.   Waco dito

    Esse sistema odioso não será viral ???? O Arch foi ótimo para mim ... se é verdade que está cobrindo mais, não sei se é bom ou ruim! mas talvez já existam vulnerabilidades para assumir o controle ou algum vírus que destrua o sistema por causa disso ... se for estável e seguro não vejo problema ... de qualquer maneira vou ver se tenho tempo e estudar o assunto e faça alguns testes com openrc

    1.    dario dito

      não tão estável. e é muito mais inseguro do que o sistema v. Para um usuário de desktop como muitos de nós (eu), isso também não representa um problema, uma inicialização mais rápida funciona bem e eu geralmente não leio os logs, então não importa o quão claro eles são ou se estão em formato binário.

      Eu tenho uma teoria que o Linux vai crescer em desktops (e governos) e perder terreno em servidores (em vez de tomar um sistema operacional como o freebsd)

  14.   Oscar dito

    No esdebian Wiki, eles publicam como instalar o SysVinit no Debian Jessie. http://www.esdebian.org/wiki/sysvinit

  15.   anônimo dito

    Lendo sobre segurança, descobri que no lado intel, existem placas-mãe com chipsets, geralmente no northbridge, eles implementam algo chamado AMR Intel Active Management Technology .... interessante, felizmente não tenho intel, mas eu ' Vou começar a procurar por isso. Do lado da AMD, não existe tal coisa.
    Eles imaginam uma combinação de intel + AMR + systemd, Deus me livre.
    https://en.wikipedia.org/wiki/Intel_AMT_versions
    Não admira que o paranóico de Stallman clame por biografias grátis.

  16.   dah65 dito

    Em primeiro lugar, não uso o systemd porque ainda não está integrado ao Kubuntu (estou com o Netrunner 14, derivado do Kubuntu 14.04).

    Tendo esclarecido isso, várias coisas devem ser especificadas:

    1- O systemd está sendo adotado por desenvolvedores / empacotadores de várias distros diferentes (Debian, openSUSE, Arch, Fedora ...), mas agora descobrimos que os leitores deste blog sabem mais do que eles sobre as vantagens e desvantagens do systemd.

    2- systemd é um software livre, cujo código pode ser lido (e compreendido), por aqueles que têm tempo e conhecimento (aqueles desenvolvedores / empacotadores de que eu estava falando antes). Se você esconder as portas dos fundos, eles serão descobertos. Quantos leitores usam um firmware ou driver proprietário, cujo código você não leu e não pode ler? Acho mais sensato ter medo disso do que não do systemd.

    3- Todos trabalhamos com pacotes binários, porque quando eu faço download de um .deb dos repositórios para instalá-lo, não estou baixando um arquivo de texto simples. Portanto, esse argumento é bastante paradoxal.

    4- No GNU / Linux já existem programas que fazem muitas coisas: o mesmo kernel, que cada vez mais integra mais drivers, e até firmware proprietário (melhor colocar uma porta dos fundos no firmware fechado do que em um programa cujo código é publicado). Existe também o Xorg, que não só lida com o servidor gráfico, mas também com o teclado, mouse e outras coisas; Ninguém diz que o Xorg "trai" a filosofia UNIX por isso, querem aposentá-lo porque já foi ultrapassado por outros projetos.

    5- “Linux é escolha”, claro, mas é a liberdade de escolher se eu quero ler o código, alterá-lo, distribuí-lo, etc. Não que as distros sejam obrigadas a dar todas as opções (todas as arquiteturas de processador, todos os ambientes de desktop, todos os formatos de pacote, etc)

    6- Para quem está pensando em mudar para um BSD, lembro-me de ter lido notícias de que em alguns sistemas BSD a NSA americana já havia colocado suas garras. Se esta notícia foi correta, não sei porque não acompanhei o assunto. Mas é irônico que eu fuja de algo "porque o Red Hat está atrás e talvez ..." para entrar em algo que "talvez a NSA esteja por trás ..."

    Além de usar GNU / Linux, BSD, Windows ou o que você quiser que usemos, também podemos usar nossa lógica e capacidade de raciocinar

    1.    elav. dito

      Em primeiro lugar, não uso o systemd porque ainda não está integrado ao Kubuntu (estou com o Netrunner 14, derivado do Kubuntu 14.04).

      Tendo esclarecido isso, várias coisas devem ser especificadas:

      1- O systemd está sendo adotado por desenvolvedores / empacotadores de várias distros diferentes (Debian, openSUSE, Arch, Fedora ...), mas agora descobrimos que os leitores deste blog sabem mais do que eles sobre as vantagens e desvantagens do systemd.

      Ou seja, os leitores deste blog, sendo apenas leitores, não têm a capacidade de perceber se algo é bom ou não, pois devemos nos guiar pelo bom senso, conhecimento e experiência de empacotadores e desenvolvedores.

      2- systemd é um software livre, cujo código pode ser lido (e compreendido) por aqueles que têm tempo e conhecimento (aqueles desenvolvedores / empacotadores de que eu estava falando antes). Se você esconder as portas dos fundos, eles serão descobertos. Quantos leitores usam firmware ou driver proprietário, cujo código você não leu e não pode ler? Acho que faz mais sentido ter medo disso do que não do systemd.

      Es cierto, es Software Libre, y si apareciera algo raro las super personas de las que hablabas antes y de las que debemos fiarnos se podrán percatar y anunciarlo, o quizás no, porque a lo mejor como son personas se sienten tentados a callarse a cambio De algo.

      3- Todos trabalhamos com pacotes binários, porque quando eu faço download de um .deb dos repositórios para instalá-lo, não estou baixando um arquivo de texto simples. Portanto, esse argumento é bastante paradoxal.

      Quando você baixa um .deb, tudo o que você está fazendo é baixar um arquivo compactado, que você pode descompactar e, portanto, ver o que está dentro e é possível, que é onde o binário está dentro. 😉

      6- Para quem está pensando em mudar para um BSD, lembro-me de ter lido notícias de que em alguns sistemas BSD a NSA americana já havia colocado suas garras. Se esta notícia foi correta, não sei porque não acompanhei o assunto. Mas é irônico que eu fuja de algo "porque Red Hat está atrás e talvez ..." para entrar em algo que "talvez a NSA esteja por trás ..."

      Não sei quem são os usuários que vão fugir do Linux para ir para o BSD, mas por exemplo, eu não teria que sair do Linux, só teria que sair de uma distribuição que coloque o Systemd atrás de você sim ou sim.

      Além de usar GNU / Linux, BSD, Windows ou o que você quiser que usemos, também podemos usar nossa lógica e capacidade de raciocinar

      Resumindo, aqueles de nós que comentam, lêem e usam GNU / Linux neste blog não raciocinam. É isso que você quer dizer? De qualquer forma, direi a você por experiência pessoal e meu raciocínio (lógico ou não):

      Systemd é uma merda presa em uma vara. Eu li que existem outros Inits que iniciam muito mais rápido e, portanto, não precisam controlar DNS, RED, CRON e tudo o mais que o Systemd deseja controlar. Talvez para um usuário final, que só se preocupa em ligar o computador, abrir um navegador e enviar e-mails, não importa se ele usa Systemd ou Systemx, mas para nós que gerenciamos servidores é um pé no saco. E eu faço a mesma pergunta que sempre pergunto: o que acontecerá se o Systemd for comprometido e for para o inferno? Ficamos sem RED, sem CRON, sem DNS, sem Init e tudo o mais que ele faz? Lá eu deixo isso para você.

      E cuidado, eu conto tudo isso sem acrimônia. Dito isso, bem-vindo a essas partes.

      1.    dah65 dito

        Obrigado pelo acolhimento.

        Respondendo sem acrimônia, esclareço que não desenvolvo o systemd nem sou pago para promovê-lo. E que não me afeta em nada se outras pessoas o usam ou não, é decisão delas.

        Mas o que vejo com este assunto parece, às vezes, uma histeria, e leio opiniões de pessoas que, sem ter estudado o código ou sem o ter usado, rotulam-no de lixo, imposição, traição, e não sei quantos outras coisas. Isso me lembra de uma situação que vivi alguns dias atrás, quando uma pessoa que reconheceu que nunca instalou o Windows ou sabia como particionar um disco rígido começou a dizer que o Linux era muito difícil ... sem nunca ter tentado, e também tendo Android em seu smartphone.

        Você comparou systemd com sysvinit, com upstart e com openrc? Ótimo, você pode tomar uma decisão com base em sua própria experiência. É a melhor, porque você também sabe que a distro que funciona em um computador pode valer a pena em outro, e é por isso que aqueles de nós que têm alguma experiência em GNU / Linux dizem que a melhor distro é aquela com a qual o usuário se sente confortável.

        1- «Em outras palavras, os leitores deste blog, por serem apenas leitores, não têm a capacidade de perceber se algo é bom ou não, porque devemos nos guiar pelo bom senso, conhecimento e experiência de empacotadores e desenvolvedores »

        Sou leitor deste blog há bastante tempo (vocês verão meus comentários em notícias antigas), por isso estou incluído no pacote. E a resposta é não: ser leitor deste ou de qualquer blog não me permite (pelo menos para mim), julgar o bom ou o ruim de um software que não conheço. Posso ler o que os outros estão dizendo e, neste caso, há posições tanto a favor quanto contra o systemd; na verdade, toda vez que o tópico é levantado no Phoronix, há muito debate, mas mesmo lá os comentários argumentados são escassos. Estou me referindo a argumentos como "quando o systemd chama o processo X, ocorre um loop infinito, tornando o sistema inutilizável".

        E a verdade é que ao usar uma distribuição ou outra diferente, você está sendo guiado pelo julgamento, conhecimento e experiência de empacotadores e desenvolvedores. O uso de qualquer sistema operacional ou programa implica em parte confiar no julgamento e na experiência de outros; por exemplo, com o Linux você aceita a decisão de usar um kernel monolítico em vez de usar um microkernel como o Hurd. Essa decisão foi de Linus Torvalds, e você a aceita usando o núcleo dele.

        2- «É verdade, é Software Livre, e se surgir algo de estranho, as superpessoas de quem falaste antes e em quem devemos confiar poderão notá-lo e anunciá-lo, ou talvez não, porque talvez como são pessoas elas vai se sentir tentado a se calar em troca de algo. "

        Bem, suspeito, por que confiar em Linus Torvalds e Richard Stallman e no projeto GNU? Eu não li o código de seus programas, então talvez eles estejam me enganando.

        3 - «E faço-lhe a mesma pergunta que sempre faço, o que vai acontecer se o Systemd se comprometer e for para o inferno? Ficamos sem RED, sem CRON, sem DNS, sem Init e tudo o mais que ele faz? Vou deixar lá. »

        E se o OpenRC estiver comprometido de alguma forma? Ou Upstart? Ou o kernel? Aconteceu comigo, depois de uma atualização "normal" no Debian Testing, fiquei sem grub, não consegui entrar no Debian ou no Windows, e na época minha ignorância significava que eu só tinha a opção de reinstalar.

        4- «Em suma, aqueles de nós que comentam, lêem e usam GNU / Linux neste blog não raciocinam. É isso que você quer dizer? "

        Não, eu não quis dizer isso; Não pretendo generalizar de uma situação particular e concreta para a totalidade do comportamento de uma ou de mil pessoas. Mas acredito que no caso do systemd ele é falado muitas vezes sem fazer uma análise objetiva e serena; também aconteceu com o Wayland-Mir, muitas alegações infundadas sendo feitas, tanto contra Wayland quanto contra a Canonical.

        Além disso, repito que li e comento neste blog (como em outros), e que uso GNU / Linux.

        E também repito o que disse antes: vamos usar nossos cérebros, analisar o que ouvimos e lemos, assumir diferentes perspectivas para tentar refutar tanto A quanto não-A e, se possível, vamos usar nossa própria experiência para basear nossas conclusões em fatos . E então vamos usar o que achar melhor para nós.

      2.    Waco dito

        umm .. bem, estar comprometido é uma hipótese é como tudo .. minha dúvida já passou? .. talvez bugs não sejam encontrados em todos os softwares e sejam corrigidos se houver bugs no systemd eles corrigem e como qualquer programa pode ter seus bugs .. o problema não é que ele pode falhar, é se você quer fazer ou controlar o que está fazendo, mas não na suposição de que pode falhar, qualquer coisa pode falhar em um momento ... Eu não sou um fã de systemd em tudo, é apenas minha opinião.

        1.    elav. dito

          Um bug pode ocorrer no computador de um usuário e nada pode acontecer, mas em um servidor as coisas são muito, muito diferentes.

      3.    yukiteru dito

        @waco certamente se você obtiver bugs em um software, você deve corrigi-los. O problema é que o systemd tem muitos bugs antigos (alguns datando de 2010 e sérios) e eles ainda não foram corrigidos hoje, ou foram simplesmente minimizados ou simplesmente marcados por Lennart como CLOSED ou WONTFIX.

    2.    Waco dito

      o seu comentário foi muito bem sucedido! Nem todos podemos cair no systemd porque está na moda e foi criado como uma campanha de difamação para isso ... toda mudança tem uma rejeição.

    3.    yukiteru dito

      Eu respondo aos seus argumentos:

      1.- Usuários sérios e questionadores, e desenvolvedores sabem as vantagens e desvantagens de adotar o systemd em qualquer ambiente de desenvolvimento e trabalho, os pontos fracos e fortes do systemd não mudam devido a ter uma perspectiva ou outra.

      2.- Certamente o systemd é um software livre e pode ser auditado. O problema não é que ele tenha portas traseiras escondidas, o problema é que ele faz coisas que um init não deveria fazer (controle de rede, dns, consoles TTY, etc), que ele tem muitos serviços que são supostamente para outros, que ele faz as coisas de uma maneira completamente diferente de como se espera que sejam feitas, o que quebra as regras do próprio kernel do Linux (coredump), que muitos de seus desenvolvedores se preocupam muito pouco em resolver problemas estruturais que o systemd tem (coredump e depuração são entre as mais graves ainda não resolvidas).

      3.- Uma coisa é baixar um binário que passa a ser um programa cuja CONFIGURAÇÃO e LOGS ainda estão em texto simples, e outra coisa é baixar um binário cuja CONFIGURAÇÃO e outras informações estão armazenadas em binário e só são acessíveis através de ferramentas, é aqui que as coisas mudam. Um log binário não oferece segurança (se você realmente quer segurança, criptografe a partição com AES-256), é apenas uma caixa preta da qual você não sabe nada sobre o que está acontecendo e se presta a muitas coisas, por exemplo : Imagine que você tenha um Trojan que explora uma vulnerabilidade do systemd e, por meio dele, obtém acesso total ao sistema, incluindo o serviço de registro e o escalonamento de privilégios. Isso não é um problema sério? Os logs binários manipulados diretamente pelo systemd não se voltariam contra você ao serem inaudíveis sem chegar ao ponto em que já foram modificados sem saber? Este é o ponto e a diferença entre um programa e um arquivo de configuração / logs / dumps em binário.

      4.- O kernel é um software desenhado nesse sentido, está desenhado desde o início para controlar tudo no seu PC, não um init. Um init é dedicado apenas a fazer seu sistema levantar o kernel e ser utilizável, porque é a primeira coisa a iniciar e a última a terminar. É por isso que é chamado de init (inicialização) porque só inicia o sistema e não faz mais nada, e a razão para isso é muito simples, o init deve ser o software mais estável e perfeito possível, para evitar isso por algum motivo Isso acaba quebrando todo o sistema, é sobre estabilidade e segurança. O Xorg, é outra voz, faz muitas coisas é verdade, mas nada tão arriscado a ponto de te deixar com um sistema completamente inutilizável, e também sua configuração ainda é feita em simples arquivos de texto puro.

      5.- Certamente as distros não são obrigadas a oferecer liberdade em sentido amplo, e é por isso que a atual tirada é apresentada. Mas, nós somos os usuários e a comunidade, e muitos de nós simplesmente não concordamos com a implantação deste sistema, por isso fazemos chegar a nossa voz, que ouçam ou não, é uma questão de quem desenvolve o distro, e sua decisão terá um impacto sobre aqueles que decidirem usar ou não sua distro, e isso, claramente pode levar ao fracasso de várias distros dependendo de como as coisas estão indo e um exemplo agora é o Debian e sua bifurcação Devuan.

      6.- A novidade do BSD é por causa do que aconteceu no OpenSSH e na pilha de IP do OpenBSD, uma porta dos fundos que afetava não só o BSD, mas também o Linux (no caso do OpenSSH), e isso foi corrigido. A situação é atribuída ao BSD, porque é o BSD (Theo de Raadt no OpenBSD) o responsável pelo desenvolvimento desta ferramenta (OpenSSH) e a situação surgiu porque alguns desenvolvedores que não estão mais ativos no projeto plantaram a porta dos fundos . A situação foi resolvida e foram declaradas as medidas cabíveis a serem tomadas, caso essa situação esteja afetando quem fez uso do software. Agora: essa situação pode ocorrer no systemd? A resposta é simples e o resultado é catastrófico, uma vez que o systemd lida com a escalada de privilégios entre muitas outras coisas, um backdoor no systemd significa acesso total ao sistema, algo que não acontecia com os backdoors mencionados no BSD.

  17.   Oscar dito

    Eles retornam o fork do Debian sem que o systemd já tenha uma página web. Parece que o projeto está indo e muito a sério. https://devuan.org/

  18.   aaditya bagga dito

    ISOs atualizados e alguns novos uploads.
    https://forum.manjaro.org/index.php?board=50.0

  19.   Keos dito

    O instalador não é muito claro, não consigo seguir seus passos, principalmente na parte das partições, não sei porque insistem nessas coisas confusas.

  20.   Manoel R. dito

    Há algo que me chama a atenção sobre o netinstall com Openrc, em algum lugar da instalação eu continuo vendo a mensagem de que você está configurando o systemd, será que eles realmente estarão livres do systemd ou de seu uso?

    1.    Keos dito

      Olá Manuel, também observo o mesmo durante a instalação, deve ser questão do instalador porque o que não há dúvida é que o systemd não está instalado, confirme no terminal assim: pacman -Qs openrc

      lembranças

      1.    Manoel R. dito

        Olá keos, antes de mais peço desculpa por não ter respondido antes. Agradeço sua resposta, fico feliz em saber que Manjaro oferece essa opção; assim que o suporte ao Ubuntu Precise terminar (ou talvez antes), irei instalá-lo. Saudações.

  21.   Anônimo dito

    Boa postagem

    Vou esperar em Manjaro com Systemd enquanto a versão OpenRC amadurece um pouco mais, quero sair do systemd ... (eu suo)