OS 10 BUGS MAIS BIZARROS DE SYSTEMD

Já instalei Minix direto numa CPU. Aquele que vem no CD do "livro do raccoon". É cheio de tretas. Só pode ficar no início do HD e com tamanho de partição limitado. Fiz rodar, executei compilador, vi coisas sendo instaladas. Não fiz muita coisa.

Ele usava uma partição primária. Dentro dela haviam três subpartições com serventias intrínsecas. Um sistema de arquivos próprio, o qual Linux usou nos primórdios, até adoção do ext2. Como eu não consegui fazer o LILO dar boot por não entender como achar o kernel naquela coisa tripla, tive de chavear o sistema com o Linux e algum Windows© (provavelmente 98) através de um disquetinho com DOS e FDISK. Gambiarra da p*rra!

Nunca testei em notebooks porque provavelmente nem roda com a tela de LCD. Ou eu volto para desktop e aprendo a configurar no GRUB, ou eu uso em máquina virtual. Até fiquei curioso. Faz tempo que não visito o site do Minix. Da última vez em que fui mexer com Minix no virtualizador, até tinha feito um ícone com o raccoon para ilustrar a VM. :-P Nem sei onde foi parar.

Isso é animador. Quando tiver tempo livre pretendo testá-lo, mas primeiro numa VM.
O fato de ter poucos recursos e ter a maior parte do seu uso em terminal puro parece bem empolgante, e seguro.
Se rodar um TWM e algum browser simples então...

Não me lembro se na época rodava X. Agora talvez deva rodar. É só conferir: http://www.minix3.org/

A imagem do raccoon no site não é fofa? Faltou uma destas nos virtualizadores para Minix. É uma forma de divulgação. De lembrar também que Minix ainda existe.

Minix é um sistema que há um tempo me interesso, mas que não tinha testado ainda, só lido algumas coisas a respeito bem por cima. Dependendo de como achá-lo, quem sabe não passe a utilizá-lo como "main OS".

É uma pena o Minix ser praticamente desconhecido pela maioria.

Por causa de um bug na mesa do Xubuntu Xenial que não permitia que eu abrisse alguns programas, instalei o Xubuntu Zesty. Eu vi que muitos outros bugs haviam sido corrigidos, mas uns poucos surgiram (Bluetooth de novo).

Uma coisa que me preocupou foi ver que não há mais o /etc/rc.local. Eu o utilizava para que as otimizações do powertop fossem ativadas logo ao ligar o computador com o intuito de economizar energia, especialmente com as portas SATA.

Eu não tinha escapatória, eu tive de lidar com aquele que eu achava que era o demônio do sistema. Quando eu procurei na internet, logo eu encontrei uma página da Red Hat muito completa, explicando como criar um arquivo de um serviço, com vários exemplos. Os guias da Red Hat para criar e configurar os serviços são bons.

Contudo, eu não tinha feito tudo certo inicialmente. O serviço parecia perfeito quando analisado com o systemd-analyze, mas não tinha como fazê-lo iniciar automaticamente. Por que? Eu não tinha escolhido um alvo, então nenhum serviço dependia dele, logo ele não iniciava. Solução: ler a documentação direito (especialmente a tabela 9.6): https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/System_Administrators_...

Além disso, eu criava os arquivos direto em /etc/systemd/system (recomentado pela documentação), o que não me permite fazer grandes configurações. Eu não conseguia desativar os serviços sem apagá-los. Se eu quisesse que isso funcionasse bem no Xubuntu 17.04, eu deveria por os arquivos com os serviços criados por mim em /lib/systemd/system, então dar um systemctl daemon-reload e daí posso ativá-los e desativá-los como qualquer outro serviço (o que cria um atalho em /etc/systemd/system). Não sei se é recomendado (isso eu não achei, então não deve ser), mas deixou o meu serviço tão configurável como os demais serviços do sistema, eu adorei o resultado.

No fim estou sendo o advogado do daemon. Eu não o achei o satanás infernal do capiroto do qual todos falam sobre. Os serviços são extremamente configuráveis. Ex.: para o registro dos serviços eu escolhi o syslog, daí se der errado não preciso abrir nenhum programa binário do systemd (systemctl status) para saber o que houve. Caso os desenvolvedores dos serviços não queiram utilizar o kmsg ou o syslog, a culpa não é do systemd, porque o systemd dá essa opção.

Se o systemd é considerado horroroso por causa de bugs, imagine o que deve ser considerado o ImageMagick, não existe uma palavra para defini-lo.

A diferença é que operar o ImageMagick nunca deu riscos de transformar uma máquina num tijolo.

O que me intriga e ainda não encontrei a resposta, é pq a maioria das distros o adotaram.

A que parece ser mais palusível, seria pq Gnome tem o systemd como dependência e mesmo Gentoo conseguindo contornar essa dependência, acredito que as demais distros não se interessaram em ir contra. Podemos tbm levar para o lado das teorias da conspiração sobre monitoramento.

Mas ainda existe essa dúvida e acredito que na maioria de nós.

Outro ponto é que ele foi adotado pelas principais distros mais amigáveis (existem exceções) e de certa forma tende a controlar tudo para não dar "trabalho" ao usuário. Se ele foi criado para ajudar e ser algo bom, pq distros como Slack e Gentoo não o adotaram? Pq existe a necessidade em criar distros sem ele, se foi dito aqui que ele é o futuro?

Acredito que essa galera contra o Systemd não seguem apenas a filosofia, mas possuem um bom conhecimento técnico para julgarem que ele não serve por enquanto ou talvez nunca. Aqui não seria a questão de seguir a manada, mas hj acredito mais nos motivos do pessoal do Devuan, do que do Debian, ou Void do que Arch, Slack do que Ubuntu (ai foi sacanagm kkkkk).

Dizem que ele está melhorando com o passar do tempo, mas se ele é peça importante na distro, já não deveria estar estável desde quando foi implementado?


"Failure is an option here. If things are note failing, you are not innovating enough" - Elon Musk

E já já não vai ter /etc/fstab, pois o systemD já esta tem seu próprio arquivo de configuração de partições, só não é obrigatorio, ainda, mas por default, é a primeira opção a ser verificada para depois ir em /etc/fstab




--------------------------------------------------------------------------
Somente o Software Livre lhe garante as 4 liberdades.
Open Source =/= Free Software.
https://goo.gl/mRzpg3
http://www.anahuac.eu/contrarrevolucao-osi/

Uma das ideias, também, é que unificando tudo em uma única ferramenta, melhoraria o processo para os desenvolvedores... sqn.

Engraçado que vejo muitos adm's de sistema glorificando esta porcaria. Dizendo que agora está menos trabalhoso, com poucas preocupações... nunca vi isto. Um adm de sistema não querer ter o próprio controle da bagaça e ficar se lamuriando por ter que configurar na mão algumas coisinhas. É de matar!

Um simples script aliado à versatilidade do zsh é de longe mais estável que esta tranqueira... ¬¬

Alguém aqui neste tópico, o @listeiro se não me engano, escreveu que isto pode ser jogada da Red Hat, o que eu concordo (e aqui já indo pra teoria da conspiração)... mas é de se pensar. Veja o Runit. É mais velho que o systemd, melhor (100000x), mais estruturado, mais bem configurado, etc. e não é esta sensação toda, nem teve toda esta comoção por parte das distros quando foi lançado. E não tem a metade dos bugs que o systemd tem... =]

-----------------------------------''----------------------------------

Larry, The Cow, uses Gentoo GNU/Linux

^__^
(oo)
(__)

"If it moves, compile it."

Up:

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-9445
http://www.phoronix.com/scan.php?page=news_item&px=Systemd-OOB-Write-9445

-----------------------------------''----------------------------------

Larry, The Cow, uses Gentoo GNU/Linux

^__^
(oo)
(__)

"If it moves, compile it."

As duas vezes quando eu tinha bugs aparentemente ligados ao systemd, tratava-se de bugs de outros módulos que precisavam ser solucionados. O systemd só apontou para estes problemas. Me acomodei com o systemd há bastante tempo.

Eu, como programador durante mais de 20 anos, sei como é fácil de cometer um bug "bizarro". Felizmente não me lembro mais de nenhum. Mais ainda na programação de software do sistema que depende de vários tipos de hardware, que simplesmente não estão disponíveis para testes.

O que realmente são bugs "bizarros" é quando o programador nem fez os testes mais fáceis e com pouco custo. O programa passou pelo compilador e pronto ... Isto também já vi várias vezes.

Um sistema de zilhões de scripts e logs está longe de ser simples, especialmente quando aparece um problema que você tem que debugar. Um verdadeiro pesadelo! A grande maioria de administradores profissionais aqui na Alemanha aceitou o systemd e tenta aproveitar as vantagens. O systemd também traz melhorias de segurança, por exemplo não é mais possível renomear um processo.

Ademais, o Lennart Poettering passou alguns anos na infância no Rio de Janeiro. Ele fala Português, mas não é suficiente para palestrar na língua.

Abraços
Bequimão

Estou acompanhando o tópico apenas.




--
If it ain't broke, fix it until it is.