E o Systemd me deixando fulo da vida

 Se tem uma coisa que me deixa mordido da vida por utilizar o Systemd é o seu comportamento. Recentemente tive péssima experiência com ele.

E o Systemd me deixando fulo da vida

Meu assunto sobre o Systemd, tanto no meu canal quando blog, começaram através do vídeo sobre a distribuição Debian. Veja abaixo a parte que menciono sobre o Systemd no vídeo do Debian:

Daí rolou todo aqueles boatos que o Systemd causa ameaça ao software livre e de código aberto. Sendo franco e imparcial sobre o assunto, todos esses assuntos não passam de especulação. Muitos nem mesmo sabiam que o Systemd já estava presente no Debian 7.
 Esse assunto virou especulação tão grande que vi em fóruns internacionais o pessoal afirmando que o Systemd se trata de uma armadilha da Microsoft para acabar com o Software livre.... (ri muito)

 Foi onde fiz o vídeo "O caso Systemd":

Resolvi fazer questão de utilizar o Debian para verificar o que o Systemd tem a oferecer. Na questão de boot mais rápido como proposto... sim, ele oferece um boot mais rápido. Pude notar isso do Debian 7 para o 8, mas agora vou expor a minha raiva sobre o Systemd.

Gostei dele, está funcionando bem (também, depois de anos de desenvolvimento, se não funcionasse bem, se joga da ponte), só que como qualquer outra daemon init faz... nada de inovador ao meu ver (ao menos, não ainda).

Pergunta feito a Linus sobre o Systemd, podemos ler o seguinte:

init system
Por lorinc
 Não havia um kernel unix-like decente, você escreveu um que se tornou finalmente o mais utilizado. Não havia um software de controle de versão decente, você escreveu um que se tornou finalmente o mais amado. Você acha que já temos uma init system decente, ou você tem plano de escrever uma que vai finalmente se estabelecer no mundo nesse tópico quente?

Linus: Você pode dizer que a palavra "systemd", não é uma palavra de quatro letras. Sete letras. Conte-as.
 Tenho que dizer, eu realmente não tenho ódio pelo systemd. Acho que ele melhora bastante no estado sobre init, e não, eu não me vejo aprofundando em toda essa área.
 Sim, ele pode ter uns poucos cantos estranhos aqui e ali, e tenho certeza que você encontrará coisas a desprezar. Isso acontece em todo projeto. Não sou um enorme fan de binary logging, por exemplo. Mas isso é só um exemple. Prefiro muito mais a infraestrutura do systemd para a inicialização de serviços do que a da tradicional init, e acho que é uma decisão de projeto muito maior.
 Sim, Tenho questões de personalidade com alguns dos mantenedores, mas isso é uma questão de como você trata de bug reports e aceita a culpa (ou não) para quando coisas vão erradas. Se as pessoas acham que isso siginificava que eu tenho antipatia ao systemd, terei que lhes desapontá-los, pessoal.

Agora, expondo o lado que o Systemd me deixa irritado, notei que ele apresenta uma falha ao atualizar o sistem. Após atualização utilizando aptitude safe safe-upgrade, algumas vezes o computador não desliga quando ao utilizar um dos comando:

$systemctl poweroff

#halt
#init 0

 Da semana passada pra cá, já foram três vezes que isso aconteceu. Sendo franco, isso é muito irritante; não consigo desligar o computador em algumas ocasiões. Tenho que puxar o cabo, por que na tela consta que o sistema foi desligado, mas está la, o computador ligado.

 O Pulse áudio, ficou muito a dever. Me da um trabalho conseguir uma qualidade razoável no áudio para os vídeos (o ALSA fazia isso melhor). Questão do boot rápido, ao meu ver foi simplesmente reinventar a roda, pois o OpenRC já fazia isso a bem mais tempo (e oferece boot bem mais rápido). Não sei por que não analisaram o OpenRC melhor antes de desenvolver o Systemd, talvez alguma questão na clausula 2 da licença BSD que poderia atrapalhar.

 Bom, mas enfim, esse artigo foi um feedback a quem quiser saber mais sobre o Systemd. Ele é uma realidade (aceitemos ou não). Não deixem de ler o artigo sobre o introdução ao Systemd que eu traduzi direto da Linux Foundation.

Introdução aos Runlevels e comandos de gerenciamento do Systemd

Quinta, 06 de Novembro de 2014 às 14:38. Carla Schroder. Exclusivo

cgroups, ou control groups, estão presentes no kernel Linux há alguns anos, mas não vem sido muito utilizado até o systemd.

Em tempos antigos nós tínhamos runlevels estáticos. systemd tem mecanismos para controle mais flexível e dinâmico do seu sistema.

Antes de entrarmos em mais aprendizado de mais comandos uteis do systemd, vamos dar uma pequena viagem na estrada na lembrança. Há essa esquisita dicotomia no Linux-land, onde o Linux e o FOSS estão sempre avançando e progredindo, e as pessoas estão sempre reclamando disso. É por isso que estou reduzindo todo esse tumulto anti-systemd a um grão de sal, por que eu me lembro quando:

• Pacotes eram ruins, por que usuários de Linux de verdade construíam tudo a partir do código fonte e mantinham controle estreito do que acontecia nos seus sistemas.
• Gerenciadores de resolução de dependências (Dependency-resolving) de pacotes eram ruins, por que usuários de Linux de verdade dependências manualmente.
• Exceto pelo apt-get, que sempre foi bom, então somente o Yum era ruim.
• Por que a Red Hat era a Microsoft do Linux.
• Yxi Ubuntu!
• Bú seu Ubuntu!

E por aí vai... como eu disse muitas vezes anteriormente, mudanças são perturbadoras. Elas mexem com o nosso fluxo de trabalho, que já não são coisas pequenas por que qualquer rompimento tem um verdadeiro custo de produtividade. Mas nós ainda estamos no estágio infantil da computação, então ela vai continuar mudando e avançando rapidamente por um bom tempo. Tenho certeza que você pessoas que estão presas na ideia de que uma vez que você compra algo, como uma chave inglesa ou uma peça de mobília ou um flamingo rosa ornamental de gramado, é para sempre. Essas são as pessoas que ainda estão rodando Windows Vista, ou Deus no ajude Windows 95 em algum PC antiquado, débil com um monitor CRT, e que não entende por que você continua bugado-os para que sejam substituídos. Ele ainda funciona, certo?

Que me lembra do meu grande triunfo em manter um computador antigo rodando bem depois que ele deveria ter sido aposentado. Era uma vez uma amiga que tinha esse 286 velhinho rodando alguma versão inadequada do MS-DOS. Ela o utilizava para algumas tarefas básicas como compromissos, diário, e um programinha velho de conta que eu escrevi para ela em BASIC para seu registro de verificação. Quem liga para atualizações de segurança, certo? Ele não está conectado a nenhuma rede. Então de tempos em tempos eu substituía o resistor e capacitor de falha ocasional, o suprimento de energia, e a bateria CMOS. E continuava levando. Seu velho e minúsculo monitor CRT ambar escurecia cada vez mais, e finalmente ele morreu depois de mais de 20 anos de serviço. Agora ela está utilizando um Thinkpad antigo rodando Linux para as mesmas tarefas.

Se há uma moral nessa tangente ela me escapou, então vamos nos ocupar com o systemd.

Runlevels vs. States

SysVInit utiliza runlevels estáticos para criar states diferentes para bootar, e a maioria das distros utilizam cinco:

• Single-user mode
• Multi-user mode sem serviços de rede iniciado
• Multi-user mode como serviços de rede iniciado
• System shutdown
• System reboot.

Particularmente, Eu não vejo muito valor pratico em ter múltiplos runlevels, mas lá estão eles. Ao invés de runlevels, o systemd lhe permite criar states, que lhe dá mecanismo mais flexível por criar configurações diferentes para bootar. Esses states são compostos de múltiplos arquivos unit empacotados dentro de targets (alvos). Os targets tem bons nomes descritivos aos invés de números. Arquivos unit controlam serviços, dispositivos, sockets, e montagens. Você pode ver como esses arquivos se parecem ao examinar os targets prefab que vem com o systemd, por exemplo /usr/lib/systemd/system/graphical.target, que é o padrão no CentOS 7:

[Unit]

Description=Graphical Interface

Documentation=man:systemd.special(7)
Requires=multi-user.target

Conflicts=rescue.target
After=multi-user.target

[Install]
Wants=display-manager.service
AllowIsolate=yes

Alias=default.target

Então, como os arquivos unit se parecem? Espreitemos um. Arquivos unit estão em dois diretórios:

• /etc/systemd/system/
• /usr/lib/systemd/system/

O primeiro é para nós atuarmos, e o segundo é aonde os pacotes os arquivos unit. O /etc/systemd/system/ leva precedência ao /usr/lib/systemd/system/. Urrah, humano sobre a maquina. Esse é o arquivo unit para o servidor Web Apache:

[Unit]

Description=The Apache HTTP Server

After=network.target remote-fs.target nss-lookup.target
[Service]
Type=notify

ExecStart=/usr/sbin/httpd/ $OPTIONS -DFOREGROUND
EnvironmentFile=/etc/sysconfig/httpd

ExecStop=/bin/kill -WINCH ${MAINPID}
ExecReload=/usr/sbin/httpd $OPTIONS -k graceful
KillSignal=SIGCONT
PrivateTmp=true

WantedBy=multi.user.target

[Install]

Esses arquivos são bem compreensiveis mesmo para recém-chegados ao systemd, e os aquivos são bastante simples do que um arquivo SysVInit init, como esse snippet a partir do /etc/init.d/apache2 exibe:

SCRIPTNAME="${0##*/}"

SCRIPTNAME="${SCRIPTNAME##[KS][0-9][0-9]}"
if [ -n "$APACHE_CONFDIR" ] ; then

        if [ "${APACHE_CONFDIR##/etc/apache2-}" != "${APACHE_CONFDIR}" ] ; then
DIR_SUFFIX="${APACHE_CONFDIR##/etc/apache2-}"
        else

                DIR_SUFFIX=

O arquivo inteiro tem 410 linhas.

Você pode visualizar as dependências unit, e sempre é surpreendente para mim como eles são complexos:

$ systemctl list-dependencies httpd.service

cgroups

cgroups, ou control groups (grupos de controle), tem estado presente no kernel Linux há alguns anos, mas não tem sido muito utilizado até o systemd. A documentação do kernel diz: "Control Groups fornecem um mecanismo por agregar/particionar conjuntos de tarefas, e todas as suas futuras children, nos grupos hierárquicos com comportamento especializado."Em outras palavras, ele tem o potencial para controlar, limitar, e alocar recursos em múltiplos jeitos uteis. systemd utiliza o cgroups, e você pode vê-los. Ele exibe sua arvore de cgroup inteira:

$ systemd-cgls

Você pode gerar uma visualização diferente com o bom e antigo comando ps :

$ ps xawf -eo pid,user,cgroup,args

Comandos uteis

Esse comando recarrega o arquivo de configuração de uma daemon, e não seu arquivo de de serviço systemd. Utilize isso quando você fizer uma alteração de configuração e quiser ativar-lo como a menor descrição, como esse exemplo para o Apache:

# systemctl reload httpd.service

Recarregar um arquivo de serviço para-o completamente e reinicia um serviço. Se não estiver rodando, Ele o inicia:

# systemctl restart httpd.service

Você pode reiniciar todas as daemons como um único comando. Isso reinicia todos os arquivos unit, e re-cria toda a arvore de dependência do systemd:

# systemctl daemon-reload

Você pode rebootar, suspender, e desligar como um usuário comum não privilegiado:

$ systemctl reboot

$ systemctl suspend

$ systemctl poweroff

Como sempre, há muito, muito mais a se aprender sobre o systemd. Aqui vamos nós de novo, mais um Linux Init: Introdução ao systemd e Entendendo e utilizando o Systemd são ótimas introduções ao systemd, com links para recursos mais detalhados.

Fonte:  Introdução aos Runlevels e comandos de gerenciamento do Systemd

A polêmica daemon init systemd

systemd e seus recursos

Eu acompanho o desenvolvimento do systemd mais ou menos desde 2011, e confesso que me surpreendi com a sua evolução tão rápida. Passei a me dedicar a ter noção de como utilizá-lo de acordo com que saiam as informações em sites estrangeiros (o que não fica tão distante do SystemV em uma curva de aprendizado).

Systemd é um init system desenvolvido para substituir as mais conhecidas SysteV e BSD focando trazer um padrão para o Linux e melhor adoção do sistema operacional por parte de empresas e projetos.

Achei bem uma palhaçada quando escreveram o artigo boicotem Linux (que hoje não da para encontrar. PARABÉNS POR ISSO!) e todos os ataques que fazem a Lennart e a equipe do systemd. E foram esses ataques insensatos que me levaram a estudar o systemd. Uma das besteiras que eu li e ouvi foi que o systemd é uma conspiração de empresas que ameaçam o software livre (e li ate mesmo a BALELA de que o systemd é uma conspiração da Microsoft). Então aqui vai a real noção do que é o systemd.

Esses dias um grupo de uma distribuição que utiliza o runit no lugar do systemd ate vieram me falar que os bugs demoram a ser corrigidos... Apesar de funcional, há quanto tempo o desenvolvimento do runit está parado?...

Essa semana estive na Campus Party e me encontrei com a equipe da Endless (e eu e o Dionatan no conhecemos pessoalmente depois de longos anos de amizade. Finalmente né hehehehe). Aproveitamos inclusive para entrevistar Cosimo Cecchi que trabalhou na Red Hat, é um dos desenvolvedores do EndlessOS e é amigo particular do Lennart.

É interessante saber pois a galera costuma dizer que a Red Hat desenvolveu o systemd para aprisionar as pessoas; porém Cosimo nos contou que o systemd era um PROJETO PESSOAL do Lennart que a Red Hat rejeitou por longa data. Notaram como se aprofundar no assunto é importante? Ouçam como se não existisse certo ou errado.

Open Embedded trabalhando para que systemd tenha suporte a musl

Open Embedded trabalhando para que systemd tenha suporte a musl

 Desde antes do lançamento do Debian 8 que eu venho debatendo sobre o systemd, principalmente por terem criado um monte boatos (vergonhosos e mentirosos) para poder criticar o novo init system. De lá para cá eu já fiz videos contando a sua história, debatendo bug encontrado, fiz live debatendo a palestra "A tragédia systemd" feita por um dos desenvolvedores do FreeBSD e fazendo até mesmo parte do meu curso (não deixe de conferí-lo hein ;)

 Há algum tempo atrás eu fiz um vídeo detalhando as criticas tenho a respeito do systemd.  Sim, eu tenho minhas criticas a respeito do systemd assim como tenho a respeito de qualquer outra ferramenta e que não tem nada a ver com os boatos que todos dizem a respeito do init system. Quer saber as minhas criticas? Confere o vídeo aí embaixo:

 Recentemente descobri que a Open Embedded trabalha em um patch para que o systemd passe a ter suporte a musl (clique aqui para conferir) que é algo muito interessante de se ver já que o systemd é também adotado em embarcados. Isso já é um passo e há muito trabalho a ser feito já que a glibc possui incompatibilidade com as várias outras bibliotecas além da musl (dietlibc, uClibc e newlib). Esse é o motivo da musl não ter sido adotada ainda como biblioteca padrão no Debian mesmo havendo planos para isso. Há muito trabalho ainda a ser feito por parte da Open Embedded e dos colaboradores no desenvolvimento da musl, mas o futuro desta biblioteca é muito promissor (principalmente por sua qualidade de código e resultado no tamanho final dos binários).

 Mas ainda espero que o systemd também venha a ter suporte ao LLVM/Clang e longa vida ao systemd.

Mais sobre o systemd

CLIQUE AQUI, VENHA APRENDER LINUX COMIGO E TORNE-SE UM VERDADEIRO PROFISSIONAL.

Daemons, daemons e mais daemons init

Imagem ilustrando com os logos os vários initi systemd utilizados no Linux.

    No vídeo "O que é daemon init?" eu mencionei que existem várias daemons init (ou init systems) diferentes. porém mencionei no vídeo somente (digamos) as mais populares como a BSD, SystemV, o launchd do Mac OS X, o OpenRC do Gentoo, o Upstart do Ubuntu e o systemd. O vídeo pode ser conferido logo abaixo:

    Então por que não debater sobre outros init systems? Vale começar peo NetBSD que, como mencionei no vídeo, o NetBSD migrou da init BSD para uma versão da System V (ou simplesmente sysvinit que introduziu o conceito de runlevels (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 Debian para a arquitetura Alpha e tem como simbolo um Tux bebinho de tudo).

    O Solaris possui o SMF (Service Management Facility = Facilidade de Gerenciamento de Serviço que também é baseada na SysVinit). Eu não sei hoje, talvez esse não seja mais o init do Solaris, mas ele é fortemente utilizado no IllumOS e no OpenIndiana. Agora, vamos a mais um monte de outros init systems.

Depinit 

    É 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).

InitNG 

    Tem como objetivo iniciar os processos em paralelo para reduzir o tempo de boot (assim como o systemd e o launchd... Mas já foi dito isso). Algo que foi inspirado no Mac OS X Tiger. Nele tudo é chamado em uma única ferramenta para gerenciar ciclo de vida ao invés de chamar múltiplos scripts que duplicam comportamentos similares. Li a algum tempo atras que a daemon InitNG tornou o Linux mais rápido (notaram como até mesmo a daemon init ou as outras daemons influenciam no desempenho do sistema operacional e não somente um filesystem? O InitNG está sob licença GPLv3 e recebeu uma pequena atualização há dois anos.

Runit 

    É um init Unix de esquema 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.

eINIT 

    É 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.

Pardus 

    É 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.

Epcoh 

    É 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:

• Epoch no Freshmeat
• Github do Epoch
• FAQ do Epoch

minit

    É 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:

    Como descrito  no documento de sua palestra na Linux Kongress de 2004 que:

• O processo de boot das tipicas 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 horriveis 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).

jinit

    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.

    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 a Serel que também foca em acelerar o boot.

    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.

    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.

busybox remove suporte ao Systemd:

Fico por aqui, espero ter agregado  mais conhecimento,forte abraço e falow.

 E PARA CELEBRAR OS 30 ANOS DO LINUX, VENHA APRENDER LINUX DE VERDADE COMIGO ;)

E não esqueçam de conferir também o meu mini curso de atributos no Linux

Informações gerais sobre o Systemd

Já que esse é assunto para um bom tempo, então resolvi dar uma pequena continuidade sobre o assunto que acredito ser de grande utilidade.

Informações gerais sobre o Systemd

 Setembro do ano passado, o site Linoxide publicou a imagem com informações comparativas entre o Systemd e o SystemV. Resolvi então postar aqui esta mesma imagem para poderem fazer essa analise e saberem mais sobre o Systemd.

Ainda disponibilizaram também o artigo sobre o Systemd no CentOS 7. Espero que seja de grande ajuda.

E o SystemD me deixa fulo

Introdução aos runlevels e comandos gerenciamento do SystemD

Homed, o novo diretório home do Linux sendo reinventado.

Homed, o novo diretório home do Linux sendo reinventado.

 Lennart Poettering apresentou no FOSDEM 2020 o systemd-homed que faz parte da versão 245 do systemd. Esse novo recurso visa realizar alterações fundamentais no diretório home (e que vale a ressalva antes que a galera anti-systemd de plantão venha a dar chiliques e espernear se jogando no chão; esse é um recurso opcional).

 Chiliques e esperneio a parte, o systemd-homed foca em oferecer suporte a migração de diretórios home de forma mais prática de um sistema para outro, melhor suporte a senha e a criptografia para o home, melhor self containment,  melhores formatos a novos usuário além de oferecer suporte volumes criptografados com  LUKS, pontos de montagem a servidores CIFS, criptografia FSCRYPT, suporte a sub-volumes Btrfs e fazer uso de JSON-formatted user records.

 A nova ferramenta para o gerenciamento do Homed-systemd é o comando homectl com as opções create/remove/change.

Mais sobre o systemd

NÃO SE ESQUEÇA DE SE INSCREVER NO MEU CURSO DE MIGRAÇÃO PARA LINUX.

CURSO DE SHELL SCRIPT DO MATEUS MÜLLE

Cursos na Udemy

A tragédia do systemd

systemd comentado por Beno Rice do FreeBSD

 O systemd já causa discórdia entre desenvolvedores, projetos, profissionais e usuários de Linux ( e sem necessidade, diga-se de passagem). Agora, vamos tratar desse init system de acordo com a visão de um desenvolvedor do FreeBSD. E que comecem os rumores.

CURSO DE SHELL SCRIPT DO MATEUS MÜLLER

Foi uma live muito boa onde debatemos a sua origem, de onde foi inspirado, fatos históricos, vantagens e desvantagens e o erro cometido tanto pela comunidade Linux quanto a comunidade FreeBSD.


 Mas essa não é a primeira vez que debato sobre o systemd e init systems tanto no canal e no blog. Confiram também os artigos abaixo:

• O que é daemon init?
• Daemons, daemons e mais daemons init
• O que são runlevels?
• A polemica daemon init systemd
• Thunderbolt, a nova interface de conexão de periféricos do Linux

Phoronix mente a respeito do systemd possuir um milhão de linhas de código?

No dia 02/01/2017 o site Phoronix publicou que o systemd VIOLOU o total um milhão de linhas de código. SIM! escreveu VIOLOU (BREACHED) e não OBTEVE ou ALCANÇOU (REACHED). Ok,pode ter sido somente um erro de digitação.

systemd é um init system que foi desenvolvido inicialmente por Lennart para substituir a mais conhecida SystemV e hoje conta com uma boa equipe envolvendo comunidades como Debian, Arch Linux entre outras.

Para saber mais sobre o que é init system, confiram o vídeo abaixo:

Neste artigo descreve a quantidade de commits no git, que foi o ponto mais baixo desde 2012 e no final disponibilizam um link (só que do próprio Phoronix) com mais detalhes de estatísticas de código (apesar de eu gostar do Phoronix, odeio quando os sites fazem isso).

Lennart respondeu comentando em seu perfil pessoal no G+ (OK, eu não vou disponibilizar o perfil do cara porque muitos o atacam) respondendo aos detalhes:

Uh, então Phoronix está sendo Phoronix, e reporta noticia bastante enganosa. Deixe-me colocar rapidamente algumas coisas diretas: antes de tudo, "um milhão de linhas de código" é realmente enganoso, assim como aparentam ser brutas de aquivos gerenciados pelo git. Desde que nós carregamos grande montante de documentações as linhas de código vigentes são muito menores. utilizar uma ferramenta como "sloccount" para contagem de linhas de código revela que o systemd atualmente carrega ~342K linhas de código, das quais 318K são apropriados códigos C. Que na verdade não é tanto assim. Para colocar as coisas em perspectiva, como um exemplo o wpa_supplicant sozinho possui ~451K de linhas de código, das quais ~351K são apropriados código C. Acho que desde que a supostamente enorme arvore do systemd com todos os seus componentes, tais quais resolved, networkd, timesyncd, nspawn, journald, e assim por diante sozinho atinge 75% do tamanho da base de código de você $#$#%$ o subsystem wifi, eu acho que nós estamos bem, você não?
Quero dizer, com certeza, maçãs, laranjas e coisas, mas ainda…
(e sim, mesmo coisas tais quais projetos supostamente "inclinarem-se" como a uclibc pesarem 329K de linhas de código já…)

Viram como transmitir informações reais é uma responsabilidade muito grande? Sempre se questionem e corram atras para certificarem das informações. O link para o artigo está logo abaixo:

• Phoronix: systemd atinge um milhão de linhas de código
• Daemons, Daemons e mais Daemons (init)

Comemorando dez mil views no vídeo do Debian

Parece besteira para muitos estar escrevendo este artigo somente por que o meu vídeo compeltou dez mil visualizações. Mas a verdade é que para mim se trata de dez mil vezes que consegui difundi conhecimento sobre a distribuição.

Comemorando dez mil views n vídeo do Debian

 Parece besteira em primeira instancia, mesmo que não é um numero grande comparado a muitos youtubers, mas me é algo muito satisfatório. Esse é o vídeo que tive mais acessos e um dos maiores que tenho. A distribuição tem muito a oferecer.

 Foi contudo, o vídeo que me rendeu assunto sobre o Systemd em quatro artigos e os vídeo "O caso Systemd" (que alias, me rendeu algumas tretas também. Pessoal é fogo):

 E o vídeo "Busybox remove suporte ao Systemd":

 Demais a tudo isso, tive que aturar as encheção de paciência de ideologistas de distribuições, especulando que o Debian não é estável. Então, como mencionei no meu artigo anterior "Resumo da semana 07/11/2015", estou trabalhando em um vídeo para desmistificar este assunto. Por essa razão, estou escrevendo este artigo. Aguardem.

 Confiram os outros artigos que mencionei que o vídeo acabou rendendo (isso que é distro que deu o que falar):

• Revisando o Debian Jessie
• Introdução aos runlevels de gerenciamento do Systemd
• E o Systemd me deixando fulo da vida
• Informações gerais sobre o Systemd
• Tratando um pouco sobre init OpenRC

Retrospectiva Linux 2014

O ano de 2014 está chegando ao final e é hora de resumir algumas das maiores histórias do Linux no ano de 2014. Todos os anos por aí nós seguimos algumas histórias boas, algumas ruins e algumas feias relacionadas a Linux e Open Source. Vamos dar uma recapitulada rápida em como foi o ano de 2014 para Linux.

As Boas

primeira e principal, vamos ver quais forma as histórias positivas para os amantes de Linux em 2014.

Netflix no Linux

Os usuários Linux andam tentando por várias alternativas para fazer o Netflix funcionar no Linux do uso do Wine ao usar de recursos beta no Chrome. A boa coisa é que o Netflix finalmente trouxe o suporte nativo no Linux no ano 2014 trazendo sorrisos nos rostos dos usuários de Linux aonde o Netflix estiver disponível. As pessoas ainda teriam que contar com a alternativa utilize o Netflix fora dos EUA (e outros países aonde o Netflix está disponível oficialmente).

A adoção de Open Source/Linux em países europeus

Dê o crédito ao derretimento econômico, se quisewr, mas a adoção de Linux e Open Source andam agarrando as cidades europeias. Não estou falando da adoção do Linux por indivíduos, mas de governos e autoridades. Todos os anos nós ouvimos histórias de como Franceses e Cidades italianas economizaram milhões de Euro ao migrar para Linux e Open Office. E a tendencia não foi limitada somente ao Itália e França, o mesmo pode ser visto na Espanha, Suiça e Alemanha.

Windows 10 se inspira no Linux

O lançamento vindouro do sistema operacional carro-chefe da Microsoft, Windows será chamado de Windows 10 (não Windows 9). E o Windows 10 cria um alarde de número de novos. Mas esses ‘novos recursos’ são novos somente para o mundo da Microsoft e a maioria deles já existem no mundo Linux há anos. Dê uma olhada em tais 10 recursos do Windows copiados do Linux.

/* Linus Torvalds completa 45

Essa eu não podia deixar de mencionar e foi de próprio pulso, não tradução de algum website.

Linus Benedict Torvalds, Criador do Linux, inventor do Git e do Subsurface (http://subsurface-divelog.org/pt/) e da lei de Linus, ganhador de prêmios como o Internet Hall of Fame completou 45 anos no dia 28 de Dezembro. E pensar que sua filha mais velha, Patricia Miranda tem 18 anos, Daniela Yolanda 16 e Celeste Amanda 14. Pela crítica que Linus fez ao OpenSuse há algum tempo atras e novamente mencionou na DebianConf14 de Portland, percebe-se que suas próprias filhas usam Linux naturalmente. Quando perguntado na DebianConf14 se uma de suas filhas daqui à alguns anos chegasse a ele e disse-se: “Pai, eu quero ser uma kernel hacker”, o que ele vai dizer a elas, sua resposta foi “Eu vou dizer: ALELIA! Por que isso não vai acontecer... Eu amaria que elas fossem kernel hacker, mas eu vou ter que adotar” (gargalhadas foram inevitáveis). Sua esposa, Tove Torvalds é faixa preta em Karatê e seis vezes campeã nacional na Finlândia.

Também vale lembrar que o Linux completou 23 anos no dia 23 de Agosto, quando Linus Torvalds postou a seguinte mensagem:

Feliz aniversário mestre Linus!

https://www.youtube.com/watch?v=u818v7r1zn8

*/

A Explosão da Nuvem

Docker e OpenStack. É difícil arremessar um bastão sem acertar a história de um desses dois (excelentes) projetos – que estão definindo a tendencia de como “A Nuvem” é construída e executada nos próximos anos.

OpenStack, não é algo novo. Retrocedendo em 2010, com a primeira distribuição comercial com o OpenStack (SUSE Cloud) seguindo meados de 2012. Red Hat um anos depois, em meados 2013, e a Canonical começou a promover o utilizando o Ubuntu em conjunção com o OpenStack no início desse ano. Mas 2014 definitivamente é quando a tech journalists do mundo realmente se ergeu e tomou notoriedade.

O tanto o quanto temos ouvido sobre essas tecnologias em 2014... Eu (pessoalmente) espero ouvir ainda mais em 2015.

Os maus

Tudo não foi um mar de rosas para o Linux no ano de 2014. Alguns eventos aconteceram que abalaram a imagem do Linux/Open Source.

Heartbleed

Em abril desse ano, uma vulnerabilidade foi detectada no OpenSSL. Esse bug, nomeado Heartbleed, impactou mais de meio milhão de websites ‘seguros’ incluindo Facebook e Google. O bug na verdade permitia qualquer um ler a memória do sistema e logo dar acesso a chave que é utilizada para criptografar o tráfego. Uma tira cómica na xkcd explica o Heartbleed de modo mais fácil. Desnecessário dizer que essa vulnerabilidade foi corrigina em uma atualização para o OpenSSL.

Shellshock

Como se o Heartbleed não fosse o bastante, o mundo Linux mais a frente abalado em setembro com uma vulnerabilidade no Bash. O bug, nomeado Shellshock, mais a adiante colocou o sistema Linux em risco de ataques remotos. A vulnerabilidade foi explorada por hackers para carregar ataques DDoS. Uma atualização para a versão do Bash supostamente corrigiu o problema.

Ubuntu Phone e Steam Console

Promessas após promessas, esperanças após esperanças. Mas mesmo em 2014 ninguém viu o Ubuntu Phone ou os consoles Steam gaming no entanto. Muitas conversar foram a respeito do Ubuntu Phone. Do lançamento fevereiro de 2014 à setembro à dezembro, finalmente é o lançamento (esperançosamente) para fevereiro de 2015. Nenhuma informação dos consoles Steam todavia. Leia mais Ubuntu Phone specification, price and release date.

O Feio

Coisas se tornaram feias com guerra sobre a adoção do systemd.

Controvérsia systemd

Disputa do init vs systemd está acontecendo há algum tempo. Mas ficou feia a coisa em 2014 como o systemd equilibrou a substituição do init em muitas das maiores distribuições Linux incluindo Debian, Ubuntu, OpenSUSE, Arch Linux e Fedora. Se ficou tão que não ficou limitada somente ao boycottsystemd.org como websites. Lennart Poettering (desenvolvedor líder e autor do systemd) afirmou em um post no Google Plus que pessoas that anti systemd estavam “coletando bitcoins para contratar um hitman para matá-lo”. Lennart seguiu a diante chamando a comunidade Open Source “um lugar doente para se estar”. Pessoas tem assumido essa batalha tão longe quanto criar um fork do Debian em um novo OS nameado Devuan.

E o esquisito

Ao longo com o bom, o mal e o feio vem o esquisito que esse esquisito não é outro menos que a Microsoft.

Microsoft ama o Linux

Sim! Você leu corretamente. Microsoft ama o Linux. A mesma Microsoft que o CEO Steve Ballmer tinha uma vez dito que o Linux é um cancer. A mudança de lider na Microsoft viu algumas mudanças nessa aproximação ao Linux e ao Open Source quando o novo CEO Satya Nadella anunciou que a Microsoft ama o Linux. Esse novo amor encontrado pelo Linux é na verdade a tentativa da Microsoft de tornar o Azure como uma plataforma de nuvem melhor . Para esse propósito, o Azure precisa de virtualização Hyper-V (núcleo do Azure) para funcionar com o Linux. Esse desespero tornou a Microsoft, quinto maior contribuidor para o kernelLinux.

Fonte: http://itsfoss.com/biggest-linux-stories-2014/

Fonte: http://www.linux.com/news/software/applications/799502-the-5-best-linux-stories-of-2014

Bug no systemd de novo?

Algo errado não está certo. Deu uma falha no engano.

 Bom, encontrados três bugs no systemd-journald que permitem até mesmo escalar privilégio de usuário administrador, alvoroço é o que não faltou entre a galera.

 Como as distribuições Fedora 28-29, SUSE Linux Enterprise e OpenSUSE não foram afetadas pelos dois primeiros bugs por terem compilado o systemd utilizando a opção -fstack-clash-protection do GCC e o terceiro bug já havia sido corrigido em 2018, no o vídeo (que eu gravei no 15 de Janeiro de madrugada) eu já previa que todas as outras distribuições iriam aplicar a mesma técnica para sanar os problemas.

 Dito e feito. No dia 15 de Janeiro de 2019, já começaram a ser lançadas novas atualizações do systemd e há previsões para mais.

 Agora é só para o abraço.

CURSO DE SHELL SCRIPT DO MATEUS MÜLLER
Curso COMPLETO para a certificação CompTIA Linux+ e LPIC-1 do Mateus Müller do canal 4Fasters
Cursos na Udemy

Tratando um pouco sobre a init OpenRC

Bom, cheguei a mencionar sobre o OpenRC no meu artigo "E o Systemd me deixando fulo da vida" em que para mim, muita coisa no Systemd, foi simplesmente reinventar a roda. Por que não comentar sobre o OpenRC?

Tratando um pouco sobre a init OpenRC

 É inevitável que utilizemos o systemd? Bom, em partes pode ser que seja. As principais distribuições estão adotando-a. Fica a critério em alguns casos das nossas decisões sobre o que vamos utilizar. Mas existem outras inits no mundo Linux (o que considero como a beleza do linux, sempre há alternativas da mesma solução a oferecer. Isso é "os vários sabores de Linux").

 A daemon init OpenRC foi desenvolvida em 2001 por Daniel Robins (criador do Gentoo Linux) e mantida por outros membros como Azarh (Martin Schlemmer), com a migração da nova init system com a assistência de Woodchip (Donnie Davies) que convertei todos os scripts ebuild init scripts para funcionar com o novo sistema. Roy Marples se tornou 

  Roy Marples, que se tornou desenvolvedor do Gentoo em 2004 e mantinha os scripts modulares de rede para o pacote baselayout do Gentoo. Em 2007, Roy anunciou a baselayout-2 contendo scripts init reescritos condificados em C e permitindo init scripts POSIX sh ao inves de utilizar o bash (que as implementou em meados do mesmo ano em versões alpha e pre release ao Portage do Gentoo como componente opcional).

 Uma das alternativas para o Debian de substituir o atual SystVinit era exatamente o OpenRC (antes mesmo de pensar em Upstart ou Systemd). O que levou a comunidade Debian a não utilizar o OpenRC (e com uma certa razão) foi como afirmaram no e-mail:

O OpenRC é mais conservador e com menos mudanças revolucionarias do que o Systemd e o Upstart...

Se vamos concentrar esforços de substituir init systems e mudar nossos scriptis startup, um requerimento minimo para mim é que ao menos enderecemos os pontos fracos do mecanismo sysvinit, nomeadamente:
* Ausência de integração com os eventos de kernel-level para para  comandar startup corretamente.
* Sem mecanismo para monitoramento de processo e reiniciar além da inittab.
* Confiança pesada em shell scripting ao inves de syntax declarative.
* Um fork e exit com arquivo modelo PID para daemon startup.

 Isso aconteceu com o OpenRC devido a saída de Roy do projeto Gentoo no final de 2007, quando a baselayout-2 ainda estava em pre stage (o que foi mascardo). Roy continuou mantendo a baselayout-2 como um projeto independente (que foi permitido pelo concelho do Gentoo sob a clausula 2 da licença BSD) . Em meados de 2010, Roy resolveu não mais mantes o OpenRC, como dito por ele mesmo eu seu site, se aposentou devido a rasões politicas. Nesse ponto, ele transferiu o desenvolvimento para a comunidade Gentoo.

 Daniel Robins continua a desenvolvê-lo como um projeto independente, mantendo a versão fork do OpenRC para o Funtoo Linux, que inclui um sistema de configuração de rede Funtoo-specific.

 Para saber mais sobre o OpenRC, visite o link http://www.funtoo.org/Package:OpenRC

Dois vídeos numa tacada só

Pois é, aconteceu algo que eu nunca esperava. Postei dois vídeos numa tacada só essa semana. Isso por que nem eu mesmo esperava. Acompanhem aqui o por que.

Dois vídeo numa tacada só

Pois é, tudo começa quando um amigo me chama no chat e pergunta se eu tinha o vídeo How Linux is Built legendado no meu canal (isso é algo que vocês sabem que eu faço normalmente):

Porém eu tinha visto a notícia sobre o suporte ao Systemd ter sido removido do Busybox. Então eu não resisti e resolvi postar um vídeo explicando o que é o Busybox e qual a sua importância no sistema operacional.

 Daí, como eu já havia prometido para esse amigo, resolvi postar dois em uma tacada só. Um na Segunda Feira, e outro na Terça.

 Então, estou escrevendo este artigo para promover (digamos assim) uma campanha. Conhece algum vídeo em Inglês envolvendo Linux e gostaria de assisti-lo legendado? Envie um e-mail para tocadotux@gmail.com que eu terei a satisfação de traduzi-lo. :-)

 Aguardem, pois é previsto mais um vídeo para Sexta Feira.

 Veja mais sobre o Systemd:

• http://tocadotux.blogspot.com/2014/11/introducao-aos-runlevels-e-comandos-de.html
• http://tocadotux.blogspot.com.br/2014/12/retrospectiva-linux-2014.html
• http://tocadotux.blogspot.com.br/2015/03/o-que-sao-forks.html
• http://tocadotux.blogspot.com.br/2015/04/-debian-jessie.html
• http://tocadotux.blogspot.com.br/2015/10/e-o-systemd-me-deixando-fulo-da-vida.html
• http://tocadotux.blogspot.com.br/2015/10/informacoes-gerais-sobre-o-systemd.html
• http://tocadotux.blogspot.com.br/2015/10/tratando-um-pouco-sobre-init-openrc.html

Revisando o Debian Jessie

 Muitos fizeram review sobre o novo Debian lançado no dia 25 de Abril. Resolvi eu e um amigo fazer a mesma coisa notando suas novidades no desktop.

 Eu ainda não havia lançado esse artigo, pois estava finalizando o meu vídeo sobre o Red Hat Linux.

 E por que Red Hat Linux se estava para ser lançado o Debian? Bom, vídeo sobre o Debian eu já fiz trazendo até mesmo noticias sobre o Jessie que pode ser conferido abaixo:

 Então, resolvi lançar hoje, bem no dia em que foi lançado o kernel 4.1 e o kernel 3.19.6 que inclusive ja baixei para dar uma verificada; mas queria dar a minha palinha e lancei hehehehe.

No passado, há pouco mais de quatro anos atras (no dia 07 de Fevereiro de 2.011 para ser mais específico), eu fiz uma review quando atualizei do Lenny para o Squeeze. Desta vez parece que isso não aconteceu, pois na review anterior não foi necessário realizar realizar o #aptitude dist-upgrade, bastou um #aptitude safe-upgrade após o #aptitude update e já havia atualizado o sistema para a nova versão (apesar que depois eu tive que executar o dist-upgrade por que algumas coisas não estavam funcionando corretamente). Pode ser que atualizou o de alguém somente com o safe-upgrade, mas não aconteceu com o meu desta vez.

Vendo agora algumas novidades que há no ultimo lançamento do Debian, podemos citar:

• Suporte para as arquiteturas “ia64” e “sparc” foram removidos do spark? :(.
• Adicionado o suporte as arquiteturas “arm64” e “ppc64el”.
• O uso do kernel 3.16 (a mesma versão que o Ubuntu 14.04 e 14.10 estavam utilizando).
• Suporte a novos idiomas, que totalizam 75.
• Suporte a instalação via UEFI
• O systemD substitundo o SysVinit. O SystemD rendeu muitas criticas por muitos. Por aqui o que mais gerou foi boatos do que criticas. Mal os especuladores sabem que o SystemD já está presente no Wheezy e ficam com essa besteira toda.

 Olha, minha opinião quanto ao Devuan é que ele tem grande chance de não dar la grande resultado. Acho que seria mais interessante se ele tivesse sido derivado do Debian ao invés de um fork. E teve gente ainda me dizendo que se fosse um derivado não haveria como remover o SystemD do Devuan. Especulação é fogo.

• É possível agora escolher qual interface gráfica que queira utilizar no momento da instalação do sistema, não tendo somente o Gnome como padrão.

• Imagem ISO nas versões LiveCD. É possível customizá-la (assim como é feito no Porteus e no OpenSuse) possuindo as opções: as versões Jessie e SID, interfaces diversas (coisa nova no Debian, pois antigamente era só o Gnome, apesar que um apt resolveria a instalação de uma nova interface; mas aqui me refiro no momento da instalação do sistema. Enfim, agora temos Gnome, KDE, LXDE, Mate, padrão eXfce), podendo também escolher entre o apt e o aptitude.

 Agora, quer saber mais sobre o Jessie? Então acesse esse link do Diolinux e a nota de lançamentos do Debian que vão te dar uma base mais completa.

 Agradeço ao Strog que me forneceu as informações sobre o Jessie no desktop e a imagem do XFCE, pois ainda não executei o dist-upgrade na minha maquina.