Eudev - "udev sem systemd" - morre e renasce das cinzas

Notícias
1

Espera, o que é Eudev e como ele nasceu?

Em 2012, o time responsável pelo systemd assumiu a liderança do udev, o serviço responsável pelo gerenciamento da pasta /dev e suas permissões, e integrou o mesmo ao repositório de código fonte do projeto.

Isso criou um receio entre a comunidade do Gentoo. Vários aplicativos dependem do udev para reconhecer e categorizar dispositivos – de jogos para reconhecer joysticks até desktop environments para montar pendrives – e o systemd tinha um histórico de criar vínculos fortes com os projetos que são mantidos em conjunto com o mesmo ao ponto de não funcionarem mais sem o PID1 do systemd (logind, por exemplo, que levou à criação do elogind que é usado no, por exemplo, no Artix). Decidiu-se por fazer um fork do projeto chamado eudev.

Conforme os anos foram passando, o udev continuou funcionando bem sem systemd (apesar de inconveniente de ser compilado separadamente), então o foco do eudev passou a ser o suporte a ambientes Linux mais “exóticos” (kernels mais antigos, bibliotecas-base do sistema alternativas, etc.).

Como morreu?

Outro projeto, o OpenEmbedded, surgiu com um foco parecido com o do eudev atual (fazer programas funcionarem em Linux “exótico”). Porém, abrangia mais programas além do udev e tinha muito mais patrocinadores, alguns deles inclusive comerciais.

Vendo o trabalho duplicado num projeto tão complexo como o eudev, em 20 de agosto de 2021, o então líder, “blueness”, anunciou o encerramento do projeto.

Reação das distribuições

Reusar o Udev do Systemd

A reação mais comum foi engolir as inconveniências de compilar o udev sem systemd e disponibilizar o pacote. Em distribuições “exóticas”, reutilizaram-se as mudanças feitas pelo OpenEmbedded.

Foi a solução usada no Artix (apesar do pacote continuar sendo chamado eudev – muitos usuários de Artix que eu conheço nem notaram a mudança) e no Gentoo (que sempre disponibilizou o udev direto do código fonte do systemd como opção, o pacote do eudev apenas foi marcado como obsoleto).

libudev-zero

É um projeto busca refazer a biblioteca que os aplicativos utilizam para se comunicar com o udev (e eudev) de modo que possam reconhecer dispositivos sem nem mesmo precisar de um equivalente do udev instalado e rodando, favorecendo uma base do sistema mais minimalista. Programas que fazem um uso relativamente simples dessa biblioteca funcionam inclusive sem recompilar.

Essa foi a solução usada em algumas distribuições Linux para roteadores e por distros que buscam adaptar a base tipicamente usada nelas para o desktop (como KISS Linux e Alpine).

O grande porém é que nem todos os aplicativos funcionam com a libudev-zero. O README inclui alguns exemplos, entre os quais figuram, infelizmente, muitos programas que fazem parte de uma boa experiência no desktop como Bluetooth, LVM2, PulseAudio e Pipewire. Para fazê-los funcionar, é necessário mudança no código fonte ou nas chaves de compilação.

Retomada do Eudev

Em 14 de setembro de 2021, foi anunciada a retomada do projeto por uma coligação de desenvolvedores do Devuan, Alpine e Gentoo.

Futuro

Resta saber que destino aguarda o eudev, ainda mais com a competição adicional da libudev-zero que certamente vai chamar a atenção de distros Linux que prezam por um minimalismo debaixo do capô e eram o público-alvo original do eudev.

Sim, se você usa uma distribuição Linux “normal”, os últimos 13 parágrafos não mudam em absolutamente nada nem sua vida, nem o uso de seu computador.

12 curtidas
2

não seria “apesar do inconveniente de ser compilado separadamente”?

por mais que tentem, não tem mais porque e como escapar do systemd, é simples e fácil de se utilizar, é o padrão.

3

Dar pra escapar até dá, mas cada dia vejo menos motivo pra isso…

4

não dá, você perde muita coisa, o GNOME por exemplo, eles fazem alguma gambiarra lá e colocam o Openbox no lugar do gnome-shell

5

Quis dizer isso mesmo, ele é inconveniente de ser compilado separadamente. Se você olhar os scripts de compilação para o udev do systemd no Artix, por exemplo:

  • tem um monte “-Dcoisa=false” que não seriam necessários se o udev fosse algo projetado para ser compilado separadamente;
  • as funções não são o make install ... de uma linha típico de projetos bem separados, mas vários install, cp e mv cuidadosamente colocados.

Vale lembrar que isso só ocorre no Slackware (e vai parar de acontecer na versão 15). Distros que empacotam o elogind (o componente logind do systemd modificado para funcionar sem o resto do mesmo) conseguem usar o GNOME completo (e isso é suportado oficialmente pelo GNOME desde a versão 3.38).

1 curtida
6

E se estiver pensando em seguir carreira na área é praticamente impossível viver sem systemd.

1 curtida
7

sai fora dilsso, para com ilsso, que ilsso? nem perca tempo com essas excentricidades, ainda mais que - como fogo de palha - acabam logo a frente. fique no tradicional mesmo, q n arranca pedaço nem mata ninguém.

1 curtida
8

Ainda bem que ninguém nesse fórum é excêntrico o suficiente para usar seriamente no desktop um conjunto de sistemas operacionais com menos de 10% do mercado, e considerar pouco prático ou não atraente outro com mais de 25 anos de liderança.

5 curtidas
9

Exatamente o que eu iria dizer! Vc sempre com seus comentários pertinentes.

10

Claro, só não vamos esquecer que desktop é só um mercado, muitas pessoas buscam exatamente isso, Workstation mais parecidas com o ambiente de produção.

E concordo, padrões não são inevitáveis, são apenas mais onipresentes, e são coisas boas de se ter… Antes do systemd é bash e assim vai, e nunca foi absurdamente simples se livrar deles, porque padrões fazem isso, eles viram fundações enormes por baixo de tudo…

Alguém acha que vai extirpar bash e sh da sua distro do dia a dia sem nenhum trabalho? Vamos ser gratos por ter padrões, e por eles serem flexiveis, para usarmos nosssos eudev, elogind, zsh, fish, xonsh, etc. Amém. :)

2 curtidas
11

Apesar de ser o “cara da vez”, dá pra viver sem Systemd. Cada um escolhe o que é melhor pra si e todos vivem contentes e satisfeitos. Eu escolhi viver sem systemd e estou muito feliz. :wink:

12

Se soou assim, não quis criticar a existência de padrões, nem quis dizer que o usa por ser familiar, por preferência pessoal, ou por necessidade está errado – quem usa Windows também não está --, até porque também uso muitos padrões criados ou mantidos pelo systemd (apesar de serem implementações alternativas).

A crítica foi direcionada à atitude de chamar projetos de perda de tempo ou rogar-lhes pragas apenas porque não são o padrão ou o tradicional. Com uma atitude derrotista contra o padrão, a maior parte dos projetos que viabiliza um Linux de desktop nem existiria. Afinal, suponho que você está organizando documentos, pastas, fotos, etc. (assim como testando projetos de servidor) de modo prático no Linux por que alguém acreditou que isso seria melhor do que deixar coisas de desktop com o “tradicional”.

2 curtidas
13

Não acho que soou como uma critica a padrões, é mais pelo fato de eu não ver desktops Linux como algo não tradicional, depende do ramo, diversas vezes em vídeos da Pixar eu vi o “chão de fábrica” deles quase exclusivamente equipado com desktops RHEL, tirando obviamente os farm renders da empresa, inclusive é uma industria onde acho que o Windows nunca foi tradicional.

E concordo, também faço uso de projetos exóticos como é o caso do xonsh e também não vejo sentido em desfazer projetos que não acabaram virando padrão em um setor.

14

Depende!

15

Meu maior “porém” com o systemd é achar que ele faz mais do que deve.

Outros init sistems disponíveis só fazem isso, iniciam e terminam serviços e o sistema em si.

Coloco como exemplo de coisa a mais a atualização offline do fedora, é tocada pelo systemd.

Volto a dizer, não acho que seja o init do demônio, mas me preocupa algo que teria de ser simples, ser tão complexo e importante para todo o sistema

16

essa história me lembra muito a luta inglória do Patrick Volkerding, do slackare, com o PAM. Tadinho! Falava, falava, falava, pelejava, pelejava, pelejava e hoje ninguém mais preocupa-se nem com o peter, muito mais com o PAM (affff… essa doeu). seguro ou não, o peter e o slack passaram e o PAM continua vivo e forte (doeu de novo).

a mesma coisa com o systemd. as pessoas vão aprimorando o código continuamente e tudo entra nos eixos. e o mundo segue sempre em frente. não adianta espernear.

em vez de forkear o udev, porque não se juntar à equipe do systemd e aprimorar o recurso? muito mais prático.

outro pessoal perdido no tempo e no espaço é o dessas distros “exóticas”, sem futuro, num nicho dos nichos com a morte decretada desde o nascimento. basta dar uma olhada no distrowatch.

1 curtida
17

Várias e várias vezes a equipe do systemd sinalizou que não quer os aprimoramentos que motivam projetos como o eudev ou o OpenEmbedded, como componentes melhor separados ou mais facilidade de usar em sistemas ou CPUs de nicho. Logo, não há como essas duas visões coexistirem sem um fork.

Apesar de não terem sido adotados em nenhuma distribuição caseira ou comercial de grande porte, ambos eudev e elogind estão passando a marca de 10 anos, o que é um sinal bem claro que eles atendem uma demanda pequena, mas constante.

2 curtidas
18

o problema do fork é que quem forkeia não tem bala na agulha pra manter o fork. n é a primeira nem a última vez que isso acontece.

1 curtida