xcomcmdr a écrit 3541 commentaires

Ça a beau être un projet Google, ça reste ouvert et utilisable sans payer de royalties.

Et c'est pareil pour Xvid, x264, x262, ffmpeg, et x265, donc vraiment je vois pas l'intérêt (du moins pour un particulier). :p

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

Tu compares des oranges et des pommes, là…

Le portage entre versions de GNU/Linux et tout aussi "facile" qu'entre différentes versions de Windows ou Mac OS.

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

Le problème est de pouvoir gérer ce que ni Xorg les display managers existant ne gèrent entièrement ou de la même manière :

• le login/reboot/halt/verrouillage/mise en veille (et le retour de mise en veille). Comme par exemple, verrouiller la session AVANT la mise en veille, et non au retour de veille.
• le multi-seat * (donc gérer les sessions - qu'elles soient locales/distantes ou console/graphique - et les seats)
• les session multiples (plusieurs sessions sur un même seat. Exemple : Aerith et Bob utilisent l'ordinateur à tour de rôle, et chacun a des processus dont ils attendent le résultat, donc ils ont besoin de laisser leur session ouverte mais verouillé pendant que l'autre utilise sa session)
• le nettoyage des sessions qui viennent d'être fermés
• l'ouverture de nouvelles sessions

Ou encore, gérer les interdictions temporaires, telles que :

A CD burning application wants to ensure that the system is not turned off or suspended while the burn process is in progress.
A package manager wants to ensure that the system is not turned off while a package upgrade is in progress.
An office suite wants to be notified before system suspend in order to save all data to disk, and delay the suspend logic until all data is written.
A web browser wants to be notified before system hibernation in order to free its cache to minimize the amount of memory that needs to be virtualized.
A screen lock tool wants to bring up the screen lock right before suspend, and delay the suspend until that's complete. Applications which want to make use of the inhibition logic shall take an inhibitor lock via the logind D-Bus API.

Tout est expliqué ici :

Definition of Terms

A seat consists of all hardware devices assigned to a specific workplace. It consists of at least one graphics device, and usually also includes keyboard, mouse. It can also include video cameras, sound cards and more. Seats are identified by seat names, which are short strings (<= 64chars), that start with the four characters "seat" followed by at least one more character from the range a-zA-Z0-9, "" and "-". They are suitable for inclusion in file names. Seat names may or may not be stable and may be reused if a seat becomes available again.
A session is defined by the time a user is logged in until he logs out. A session is bound to one or no seats (the latter for 'virtual' ssh logins). Multiple sessions can be attached to the same seat, but only one of them can be active, the others are in the background. A session is identified by a short string. systemd ensures that audit sessions are identical to systemd sessions, and uses the audit session id as session id in systemd (if auditing is enabled). The session identifier too shall be considered a short string (<= 64chars) consisting only of a-zA-Z0-9, "" and "-", suitable for inclusion in a file name. Session IDs are unique on the local machine and are never reused as long as the machine is online.
A user (the way we know it on Unix) corresponds to the person using a computer. A single user can have opened multiple sessions at the same time. A user is identified by a numeric user id (UID) or a user name (string).
A multi-session system allows multiple user sessions on the same seat at the same time. Linux+systemd qualifies.
A multi-seat system allows multiple independent seats that can be individually and simultaneously used by different users. Linux+systemd qualifies.

*Et une limitation intéressante de Xorg pour le multiseat :

Multi-Seat X

Note that even though XOrg gained, in version 1.12 of xserver, a new -seat switch to make use of multi-seat information it does so only for input devices, not for displays. To work around this systemd includes a tiny wrapper binary in /lib/systemd/systemd-multi-seat-x which emulates the right behaviour by creating a throw-away X configuration file which does the right thing. If you are implementing a multi-seat display manager you probably want to use this binary instead of the real X binary for now. As soon as XOrg upstream gains proper multi-seat support also for displays this binary will be removed from systemd, hence write your DM to fallback to the real X server if systemd's wrapper is not found.

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

Ben pour l'utilisateur, le changement devrait être transparent, et surtout donner des comportements plus fiables.

Aussi, dans les liens il est dit que le multiseat* était impossible / compliqué à mettre en place avant, et que logind permet d'avoir cela de manière simple.

• Plusieurs utilisateurs physiquement sur une même machine, avec chacun son clavier/souris et session(s) :

La configuration d’un ordinateur en fonctionnement multi-postes sous GNU/Linux repose sur le partage
des ressources mat ́erielles entre plusieurs utilisateurs. On branche tous les p ́eriph ́eriques n ́ecessaires, puis
par le biais de la configuration de quelques logiciels, on indique `a l’ordinateur comment utiliser le matériel et on le paramètre pour qu’il puisse connecter plusieurs utilisateurs simultanément. Il y a donc un seul 1 systèeme d’exploitation, qui une fois lance gère le partage des ressources. La réalisation d’une installation multi-postes se fait en modifiant plusieurs fichiers de configuration.

http://wwwetud.univ-pau.fr/~jlasser1/tutoriel/tuto.pdf

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

« 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 !)