Por que um gerenciador de usuários do systemd é usado em sessões de área de trabalho? GNOMO?

Question

Desktops como o GNOME mudaram os processos do escopo por sessão para o gerenciador systemd por usuário ( systemd --user ). Isso inclui aplicativos GUI, como o Terminal GNOME.

O que o GNOME usa o gerenciador de usuários do systemd para obter? Existe uma lógica em algum lugar que eu possa ler?

O GNOME parece copiar as variáveis de ambiente da sessão no gerenciador de usuários. Observe que o GNOME não suporta o login do usuário mais de uma vez ao mesmo tempo. Essas variáveis de ambiente incluem, intencionalmente ou não, XDG_SESSION_ID.

loginctl , como em loginctl lock-session , acabou sendo modificado para dar suporte a esse segundo conceito menos definido de uma sessão .

Estou curioso sobre o que levou as pessoas a criar essa estranheza.

    

Answer 1

There are a number of benefits to this, but the primary one is to place each application in its own kernel cgroup. This allows gnome-shell to do application matching more reliably, and one can use resource controls to (for example) say Epiphany only gets 20% of system RAM.

Furthermore, this lays some fundamental groundwork for application sandboxing.

link

Eu posso entender que o GNOME está interessado em CGroups. O Systemd fornece uma estrutura existente para isso.

Eu não encontrei nenhuma razão para o KDE Plasma fazer isso na minha busca. O mais perto que cheguei foi

My idea so far is that a Plasma on Wayland shell needs to be brought up by systemd. Especially I consider using socket activation to start the KWin session compositor.

link

mas não havia explicação para o fato de o KWin ativador de socket fazer sentido quando é essencial para uma sessão de Plasma.

Eu não olhei porque o systemd matou systemd --session e consagrou systemd --user em pam_systemd . Talvez uma instância por sessão tenha sido um sistema mais limpo em princípio, mas não tenho certeza. Espero que haja algum motivo prático que não seja tão atraente.