xcomcmdr a écrit 3537 commentaires

« keeps track » je sais bien, et ça se voit dans l’API DBus avec des la possibilité de lister/ajouter/supprimer seats et sessions. Ça ne me dit toujours pas ce que ça permet de faire en pratique qu’on ne pouvait pas faire proprement avant, dans l’usage de tout les jours. « Lister les sessions » ne me semble pas un besoin fonctionnel.

Pour l'abandon des wrappers :

This class kdisplaymanager in plasma-workspace shows our abstraction layer growing since 2004; it currently has Logind support but as we have been adding to a constantly broken abstraction layer it's used very badly. It has tracking code for over 5 different systems (KDM, old GDM, new GDM (which is now old), consolekit, org.freedesktop.DisplayManager, and now logind) and is probably one of the ugliest pieces of code in Plasma.

Pour tous les besoins auxquels logind répond :
- gestion des "seats" et donc du multiseat
- gestion des multisessions
- pas lié à un display manager en particulier (GDM 2, GDM 3, LightDM, KDM, SDDM, XDM, …) *
- gestion des session graphiques et console (VTx)
- interface dbus indépendante, qu'on peut réimplémenter sur les systèmes n'ayant pas systemd *

(je ne fais que résumer grossièrement ces liens)

(Oui, c'est mon post précédent sous une autre forme, je vois pas comment expliquer mieux…)

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Et si tu lisais le premier lien ? Et les liens dans ce premier lien ?

Indice :

Logind is a tiny daemon that keeps track of seats and sessions on your machine.

In principle it's very simple, every login (including autologin) goes via PAM (Pluggable Authentication Modules) modules; a special PAM module signals to a central daemon that a new session is started and tell it when it stops.

This blog series has the most detail on session tracking and why logind solves problems better.

We need knowledge of all active sessions from within Plasma to be able to offer session switching inside the UI and to warn the user if they attempt to shutdown whilst other sessions are still active.

This class kdisplaymanager in plasma-workspace shows our abstraction layer growing since 2004; it currently has Logind support but as we have been adding to a constantly broken abstraction layer it's used very badly. It has tracking code for over 5 different systems (KDM, old GDM, new GDM (which is now old), consolekit, org.freedesktop.DisplayManager, and now logind) and is probably one of the ugliest pieces of code in Plasma.

Mais râler sans comprendre de quoi on parle, tout en cliquant sur "inutile" pour enfoncer le clou, c'est tellement plus "in" ! ;-)

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Je ne te prends pas pour une Mme Michu, mais je vois pas comment résoudre le problème sans poser ce genre de questions.

Mais bon, si tu te sens offensé, grand bien te fasse. ;-)

Pourriez-vous me passer le support de second niveau parce que de toutes évidences, vous ne pourrez pas résoudre cela ;-)

… Bah j'ai rien à résoudre, hein. Chez moi ça marche parfaitement. ;-)

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Et tu as regardé si le problème était répandu ? S'il y avait des bug reports dont la description était proche de ton problème ?

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Et tu as remonté tes bugs aux développeurs ?

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Bof, Debian et XFCE fonctionne très bien là, à quelques détails près (curseur de souris qui ne prenait pas le thème, icônes du menu qui ne s'affichaient pas, etc. j'ai eu le temps de tout régler).

Pourtant quand on a goûté à Xubuntu, revenir à Xfce vanilla c'est dur, très dur…

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Dans Plasma 5 et Gnome, la dépendance à systemd se limite essentiellement à systemd-logind pour gérer la session utilisateur de manière propre, plutôt que d'avoir des dizaines de wrappers tous plus ou moins cassés, chaque wrapper existant pour un système X ou Y.

Bref, la qualité a été choisie au dépend de la quantité. Ce n'est pas forcément un mauvais choix, d'autant que systemd-logind est utilisé à travers son interface d-bus, donc il "suffit" de la reproduire sur les autres systèmes qui n'ont pas systemd pour que ça fonctionne…

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Il ne faut pas croire toute la « propagande ». Alsa fonctionne(ait) relativement bien.

Hum ! Rien que pour avoir un volume sonore par application, je suis obligé d'utiliser PA (car un "codec" HDA ne fait pas de hardware mixing. Le mixing revient au software, et ALSA avec ou sans dmix ça ne marche juste pas).

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Je vois surtout une série de personne qui disent qu'elles ont eu des problèmes et ont toujours des problèmes avec pulse/systemd et autres, et un paquet de d'autres personnes qui disent :

Y'en a aussi beaucoup chez qui ça fonctionne très bien, et qu'on entend jamais (moi - sauf qu'on m'entend dire que ça juste marche :p -, mes connaissances ayant PA / systemd, des millions d'utilisateurs d'Ubuntu et autres distribs utilisant systemd et/ou PA…)

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Sous Windows ? Ils peuvent dans la plupart des cas faire un driver qui tournera sur toutes les versions depuis Vista. Ca couvre 90% du marché desktop.

Ha ! 99 % du temps pour du matos pas-si-vieux j'ai un matériel dont le pilote n'est pas disponible sous Windows (genre, le driver n'existe qu'en version pour Windows 32 bits uniquement, ce qui te bloque à Windows 7 32 bits pour pouvoir l'utiliser), mais qui fonctionne très bien sous Linux sans rien faire.

À bon entendeur, salut !

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Pour tout dire, je me suis pas tellement documenté.

D'abord, avec sysv-compat (sous Arch), le switch à systemd n'a rien changé. Un jour, je bootais avec SysV, le suivant avec systemd. A part ça, tout était pareil.

Et puis, systemctl start/enable/disable, c'est plutôt intuitif. 9 fois sur 10, j'utilise pas autre chose.

Ensuite, j'ai découvert systemctl et la documentation de systemd sur mon temps libre. Elle est très bien faite, et les quelques scripts que j'avais sont devenues des unit systemd en peu de temps. J'aurais pu garder des scripts, mais je trouvais les unit systemd plus faciles et bien plus courtes.

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Android s'est imposé via la vente liée sur des milliers de devices.

Windows, pareil.

La danse du ventre pour qu'on vienne développer chez toi, c'est quand tu as pas de vente liée, et pas de part de marché.

C'est long, et à la fin, Android domine toujours. ;-)

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Alors, premier truc qui me gêne profondément c'est l'utilisation massive d-bus: je ne veux pas de ce type de bus sur un système serveur typiquement. Sur un desktop, c'est déjà plus acceptable.

Bah sinon pour faire de l'IPC de manière efficace, simple, et pratique il faut bien une sorte d'API comme dbus.
Mac OS et Windows les ont depuis longtemps, mais sous Linux on a rien à part dbus (qui est très bien, et fait déjà partie / va faire partie du kernel avec kdbus :D )

Second truc, c'est que je préfère tout simplement les scripts shell que je modifie selon mes besoins.

Tu peux modifier tout autant les unités sytemd au niveau système ou utilisateur. Ça survie aux mises à jours, et ce sont essentiellement de simples fichiers ini..

Bien sûr, on peut aussi en ajouter. Exemple pour rc.local :

[Unit]
Description=/etc/rc.local compatibility

[Service]
Type=oneshot
ExecStart=/etc/rc.local
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

(/etc/rc.local est évidemment un script)

À mettre dans /etc/systemd/user/ (exemple de nom de fichier : rc-local.service), et ensuite :

systemctl enable rc-local

Donc voilà, systemd n'a pas de notion de rc.local, mais ça se refait en 30 secondes.

systemd-delta permet de voir les différences.

Certes, il y a tout un tas de .conf pour systemd qui permettent de configurer un peu le bouzin, mais si tu sors des sentiers battus (aka ce à quoi à penser l'auteur de systemd en le codant) tu risques de te retrouver emmerder…

Bah vu que tu peux lancer des scripts avec tes propres unit systemd, qui peuvent elles-mêmes êtres puissantes et avoir des overrides, je vois pas où est la limite dans ce qu'on peut faire.

Et je dois t'avouer qu'un examen rapide du bouzin (/etc/systemd/, /etc/init/*) ne m'a pas permis d'avoir une idée de comment il fonctionne. C'est une lacune à mes yeux (opinion, toujours).
Qu'un framework web, une lib système soit pas intuitive d'accès, OK. Mais l'outil responsable du lancement du système… bof bof.

J'ai surtout lu la doc, et ça s'utilise surtout via systemctl (rien n'empêche de modifier les fichiers de conf, mais systemctl peut le faire pour toi bien plus facilement/rapidement). systemd est vraiment bien documenté, systemctl est assez conviviale. C'est pas parfait (rien ne l'est), mais franchement j'ai essayé, j'ai été conquis. :)

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Ah bah, tant pis alors…

J'imagine que :
1) c'est pas tellement merdique, vu que tu n'as rien à dire dessus en fait
2) tu as vu un comportement différent, et plutôt que de te documenter et apprendre, t'as décidé que c'était de la merde.

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

tu crois sérieusement que Windows resterait aussi implanté si MS cassait les API toutes les versions?

Non, mais je sais que Windows s'est imposé via la vente liée d'abord, et une ABI stable ENSUITE, pas l'inverse !

Non

Bah si.

Ca fait que les développeurs apprécient, ça fait boule de neige.

T'auras peut-être plus de développeurs, mais pas beaucoup plus de parts de marché.

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Utilises pas une distro de bidouilleur comme Arch

Tiens, c'est bizarre, perso j'ai vachement plus de temps libre depuis que je suis sous Arch (avant j'étais sous Ubuntu) :
- plus de grosse mise à niveau tous les 6 moins / 3 ans / 5 ans
- plus de PPA à mettre pour avoir ffmpeg à la place de libav, ou pour avoir un logiciel plus récent que sur les dépôts
- beaucoup moins de stress lors des mises à niveau, vu que ça se fait peu à peu, et pas pour tout le système à la fois en serrant les fesses.

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Et oui, pour moi systemd, c'est de la merde. Tu ne penses pas ça ? C'est ton choix. Respecte le mien.

Pourquoi ?

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

"arrête de te mentir sur Linux aussi pratique que Windows"

Le truc, c'est que tu es hors sujet.

Je répondais à un post qui prétendait que Linux n'avait aucun moyen de tout mettre à jour en une seule fois. Or, ça fait 20 ans que ça existe, ça s'appelle un couple gestionnaire de paquets + dépôts.

Quant au reste de ton poste, Windows gagne d'abord parce qu'il est préinstallé depuis 20 ans. Le reste, c'est des détails d'implémentation dont l'impportance est ridiculement petite face à un avantage aussi massif et utilisé constamment depuis 20 ans (et tout ce qui en découle : support matériel meilleur, plus d'applications, etc. …).

Le nerf de la guerre, ce n'est pas la stabilité de l'ABI, la diversité des distros, ou je ne sais quoi. Une ABI stable, c'est très bien,, mais ça changera pas grand chose aux parts de marché.

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

C'est pas plutôt dans la config de PulseAudio ?

https://wiki.archlinux.org/index.php/PulseAudio/Configuration#daemon.conf

flat-volumes = [yes|no]
If yes (default), all input sources have their volume relative to the maximum volume of the entire sound card. This allows each application to individually adjust their volume so for example, raising your VoIP call volume will raise the hardware volume and adjust your music player volume so it stays where it was, avoiding confusion by having to lower manually the music player then raise the global volume.
Warning: Sometimes this can be more confusing than what it solves and some applications unaware of this feature can set their volume at 100% at startup, potentially blowing your speakers or your ears. If unsure, prefer to set this to no so pulse will use the classic ALSA behavior instead.

Par défaut, j'ai :

; flat-volumes = yes

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Que ce soit Windows 10 avec son gestionnaire de paquets, ou n'importe quel distribution Linux, si c'est pas sur les dépôts/stores, la mise à jour devient plus problématique.

Pendant longtemps sous Windows, il fallait mettre à jour chaque application une à une, et je doute que ça change de sitôt avec Windows 10 (le pois de l'existant).

Bref, dire que Windows est plus pratique à ce niveau là (regarde le post auquel je réponds, ça t'évitera de répondre à côté la prochaine fois), c'est juste un mensonge.

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Ça fait au moins 15 ans que je fais ça en cliquant sur un icône et en tapant mon mot de passe une seule fois…

Et en fait c'est pas que moi, mais tous les utilisateurs de distributions grand public.

Franchement je me demande dans quel univers parallèle tu vis.

Et depuis quand c'est centralisé sous windows ?!

C'est bien pour y remédier que windows 10 introduit un gestionnaire de paquets !

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

QT

QuickTime ?!

Tu voulais dire Qt ?

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Tout aussi pratique que sous Windows…

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Il faut dire que je quittais à l'époque l'environnement particulièrement lourd de Windows, vérolé de partout, même sans rien faire, qui ramait sans véritable raison, et qu'il fallait sans arrêt nettoyer, dépanner et/ou réinstaller. Je faisais cependant tourner un Windows XP parfaitement dans 64 Mo de mémoire avec réactivité, alors qu'il était profondément modifié en apparence pour ressembler à un Linux, et avec effets de transparence.

Euh non. Windows XP swap à mort avec 64 Mo de mémoire, même tout nu, et même en faisant rien. Il arrête de swaper comme un goret à partir de 512 Mo de RAM, et encore là il faut mieux éviter les bidules en arrière-plan.

La config minimum niveau mémoire est de 64 Mo, mais même à l'époque 128 Mo était bien plus réaliste (pour une utilisation et des applications qui datent de la sortie de l'OS, soit 2001 !!)

Par ailleurs, dans la vidéo on voit bien que tu avais en fait 512 Mo de RAM.

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Toutes ces commandes sont documentés, hein.

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)