ckyl a écrit 3877 commentaires

Comme n'importe quel service. Tu écris ton script d'init pour ton init manager qui lance les exécutables, tu dis que ton service est dépendant de dbus et de policykit, et voilà. Non testé mais y'a pas de raison que ça soit plus compliqué que ça.

Y'a peut être une dbuserie pour éviter qu'ils tournent tout le temps; mais ca dépasse mes connaissances. D'ailleurs ca me tue de devoir défendre des trucs desktop alors que c'est à l'opposé de mes compétences et préférences :p

Je ne suis pas compétent sur le sujet mais par exemple:

• Comment tu fais si tu ne veux pas que tes utilisateurs soient root mais juste leur donner le droit de faire certaines opération ? Tu peux avoir un grain très très fin si tu veux. Je veux juste que l'utilisateur local puisse régler le réseau et RIEN d'autre.
• Pourquoi les applications et GUI entières tourneraient en root alors que seul un minuscule sous ensemble d'opérations nécessitent des privilèges.

Je ne me suis pas frotté suffisamment à policy kit pour avoir un avis intéressant dessus. Mais vue du ciel, sa conception est tout à fait pertinente. C'est un bon design que tu retrouves partout: la séparation de privilèges.

Non c'est fait pour permettre à des applications de changer l'heure du système ou le nom d'hôte… Un système de Privilege separation quoi.

Premièrement tu n'as pas à recoder. Ce sont deux services classiques, qui n'ont pas de lien avec systemd. À première vue rien ne t'empêche de les compiler, de les lancer à la main, d'en faire des paquets séparés dans ta distro. Cf http://cgit.freedesktop.org/systemd/systemd/tree/src/hostname/ par exemple.

Deuxièment, même a recoder c'est ridicule comme boulot. D'ailleurs le code de gnome qui offrait exactement le même service est encore chaud dans les dépots git de gnome-settings-daemon et gnome-panel…

Bref y'a du code démon pouvant être utile à tout le monde qui est passé de gnome vers le système…

En quoi ?

Alors franchement, utiliser une abstraction et sortir systemd pour ces conneries, c'est vraiment se prendre la tête pour la beauté du geste

Ou alors de pouvoir permettre à des utilisateurs de régler la configuration de son système sans devoir le faire se déloger, ouvrir une session graphique en root, et se reloger ? Pour la date ca parait con, mais c'est exactement le même problème pour régler son réseau, installer des packages, monter une partition etc.

Les permissions Unix ca à son champ d'application, mais c'est bien moisi pour une utilisation desktop personnelle. Alors oui policykit t'aime peut être pas, mais pour le moment y'a pas mieux pour te permettre de découpler application utilisateur des opérations privilégiées à controller. Tu proposes quoi ? Balancer des setuids partout ?

Maintenant si l'admin veut pas que l'utilisateur puisse changer le système et bien il configure ses machines correctement. Comme pour tout. En plus tu peux même décider pour chaque opération si tu veux.

Comme ca, ca répond à tout les cas d'utilisation, serveur, machine perso, machine administrée.

Premièrement pourquoi je te moinsserais ? Deuxièmement ma remarque était générale envers le nombre de commentaire hallucinant qui ne reposent sur rien. Le commentaire initiale de ce thread est un tissu de conneries, sur lequel les messages suivants, dont le tien, se reposent pour élaborer la réflexion et émettre des jugements.

Je trouve ton commentaire insultant pour les devs, car tu supposes qu'ils n'ont pas été capable de faire quelque chose de trivial et que tu ne t'es pas donné la peine de chercher ou de simplement t'abstenir de juger sur des faits non avérés. J'ai trouvé l'API dbus et son utilisation en 1 minute à partir du message du forum d'Arch. Un autre commentaire m'a donné le .patch sur le bugzilla. Là on peut commencer à parler et juger le travail des gens avant de supposer qu'ils ont fait un truc totalement stupide. Ce qui n'est pas le cas ici. On est passé d'une API dbus dans gnome-setting-daemon à une autre, documentée. Au contraire c'est plus facilement portable entre les DM et les systèmes de centraliser tout ca…

Ma réponse ne me semble pas plus impolie que de systématiquement basher un projet sans même chercher à comprendre ce qu'il se passe. Juger sur des faits ca coute pas beaucoup plus cher et c'est beaucoup plus poli et constructif.

C'est sur le système d'init la dépendence ou sur une API dbus implémentable par n'importe quel soft/système d'init ?

Mais pourquoi ne pas passer par une abstraction (quitte à ce que l'API d'abstraction soit du 1-1 vers l'API systemd pour ce genre d'appel)…

http://system-tools-backends.freedesktop.org/dbus-spec.html c'est du poulet ?

Ce qui devait arriver arriva: systemd n'est plus "un système d'init comme un autre". Avec cette dépendance, Gnome devient spécifique à systemd, et donc à Linux. L'étau se resserre: on s'éloigne encore d'un pas des principes d'Unix.

Pas que j'aime ce changement; mais apparemment avant gnome utilisait /etc/rc.conf. En quoi est-il maintenant plus ou moins lié à un système d'init ? Par ce que /etc/rc.conf dans le genre dépendant d'un système d'init et avec des clés pas documentés ca se pose la aussi…

Si quelqu'un à un pointeur sur le commit ca m'interesse. Avec un grep rapide je l'ai pas trouvé.

C'est vraiment une comparaison à deux francs mais soit. Tu peux effectivement commencer par te plaindre et faire remarquer, puis aller voir en face, puis quand tu juges que personne ne fait quelque chose de bon tu te dis que y'a peu être moyen de faire quelque chose de bon.

Le problème c'est qu'on reste bloqué au point 1. Chaque jour tu vas au même resto et chaque jour tu dis que c'est de la merde sans rien faire d'autre, et ce depuis 40 ans…

Si ca servait a quelque chose, depuis le temps on en serait pas à en parler. J'ai effectivement pas mal d'exemples autour de moi de gens qui ont choisi cette voie. L'issue au bout de 10 à 20 ans, c'est qu'absolument rien n'a changé. C'est une guerre de tranchée aussi absurde que ridicule qui n'apporte rien; ni à la personne qui la mène, ni au groupe qu'on souhaite défendre. Ça na pas d'issue possible. Ces personnes utilisaient justement l'argument "c'est pas toujours et c'est même rarement possible de le faire". En reposant la question plus 15 ans plus tard, même si ils continuent dans la même démarche et arguant que maintenant c'est trop tard, certains avis ont changés. L'issue était courue d'avance pourtant y'avait des moyens de faire plus de bien autour de soi.

c'est encore une comparaison à deux francs, mais croire que la v2 ultra disruptive résoudra les problèmes, je ne peux qu'être sceptique. Si en plus de ca, pendant les 30 dernières années, on a préféré parler du grand soir de la v2 que d'améliorer ce qui est possible, je passe…

Être patron, ce n'est pas forcément un travail qu'on aime. Personne n'a dit que c'était la meilleure chose du monde pour tout le monde. Seulement certains disent qu'il faut y mettre des contraintes.

Et alors ? En étant pragmatique; plutôt que de te battre dans le vent pendant 20 ans pourquoi ne pas avoir investi ces 20 ans à faire ? L'excuse du travail qu'on aime c'est du flanc. Tu vas pas me faire croire que tu préfères passer ces 20 ans à combattre ta hiérarchie tout les jours: épanouissement 0, intérêt du travail 0.

Maintenant je n'ai jamais dit que ca devait être fait par tout le monde. Mais si tu rassembles la force de travail et les fonds disponibles, il y a moyen de faire des choses et de montrer que c'est possible. Personnellement je n'ai rien vu; du coup je m'étonne beaucoup de ce biais statistique. Autant de gens qui s'insurgent de quelque chose, mais aussi peu qui se donnent effectivement les moyens de changer concrètement les choses; préférant se borner à la critique. J'ai toujours trouvé ca étrange. Si ton patron est un connard, c'est pas en tractant que ca changera…

L'exploitation est forcément basée sur une inégalité sociale. Si c'est moi qui possède l'usine, ce n'est pas moi qui vais travailler pour les ouvriers.

Pourquoi depuis le temps vous avez pas fait l'usine et montré l'exemple de bonne gestion et non exploitation ?

Je suis toujours étonné de voir le nombre de personnes qui donnent des leçons aux autres en expliquant qu'ils ont la solution, mais qui n'ont jamais rien fait hormis s'écouter parler. Tu peux commencer petit. Monte ta boite, embauche 10 personnes t'auras fait déjà beaucoup plus qu'une vie de militantisme à écrire des tracts…

Les images qui ne servent à rien, c'est lourd même si elles ne pèsent pas lourd…

Si un développeur obfusque son code js, ça veut dire que la condition "mon code doit être lisible" est moins importante pour lui que la condition "mon site doit être rapide". On ne peut pas dire que ça part d'une bonne intention.

Ce que j'envoie à un client c'est fait pour être exécuté par une machine, tout comme un binaire. Mon code lui est lisible et maintenable. Bref on peut voir ca comme une compilation js vers js. Si l'utilisateur veut le code il va le chercher.

Ton argument est du même acabit que dire qu'un compilo ne devrait pas trop optimiser le code, par ce qu'autrement ca devient plus difficile à comprendre quand tu pars du binaire…

Et franchement, laisser une personne décider ce que doit être un système de log, laisse moi rire.

C'est quoi ce FUD ? Il n'y a pas une personne qui décide, c'est un processus ouvert et tu es libre de contribuer. Pour le protocole syslog, ca a pris 6 ans pour arriver à la RFC finale. Rainer en a simplement été l'auteur. Je peux te dire qu'il est compétent, pro et ouvert, c'est un bon auteur de RFC. Comme dans tout groupe de travail de l'IETF tout ce dont tu as besoin pour contribuer c'est d'une adresse mail; et corrige moi si je me trompe, mais la tienne n'est pas apparue sur la liste du WG.

Maintenant pour lumberjack, on en est pas encore à ce stade, mais tu peux être sur que si tu veux contribuer et que tu as des choses constructives à dire, elles seront lues et entendues. Tu peux aussi jouer avec les protos, ou écrire une implémentation des idées & draft, ca permet d'avoir un très bon feedback.

Si le sujet t'intéresse et que tu peux aller plus loin que le ranting, il faut aller défendre tes idées !

Un programmeur n'attend pas la même chose d'un système de log qu'un admin ou un utilisateur. Dire qu'on va résoudre "le problème" (et oui il n'y en à forcement qu'un) de tout le monde avec la magie des logs structurés, c'est comme dire qu'on va résoudre tout les problèmes de Linux avec une distribution unique.

Tu déformerais pas un peu l'histoire à ta sauce ?

Y'a une spec quelque part ? Y'a beaucoup de blahblah mais pas beaucoup de matière pour se faire une idée du système, de son fonctionnement, de sa robustesse et de son interaction avec le reste d'internet ?

La dualité n'est pas bureau ou serveur. La dualité est: Est ce que c'est à l'utilisateur local de décider de la configuration réseau ou est ce que c'est un paramètre système ?

Donc si tu n'aimes pas NM, tu ne l'utilises pas et ça ne te pose aucun problème puisque la solution d'avant était parfaite pour tout les usages.

Et si tu as une meilleure approche que celle utilisée pour répondre au besoin au besoin qu’adresse NM une spec ou une implémentation est la bienvenue

Sérieusement… Quand j'ai eu besoin de fonctionnalités offertes par ConsoleKit:
1. J'ai découvert que ça existait
2. Que ça répondait à mon besoin, et que je sais pas comment faire aussi bien sans
3. Que la doc est poucrave, mais que le fonctionnement général est facile à saisir et semble rationnel même si c'est un peu hackesque de reposer sur une variable d’environnement.
4. Que l'API DBUS c'est ce qui t’intéresse, qu'elle est triviale et documenté et que tu peux faire ton job.

Je suis pas fan de ConsoleKit. Je suis dev, j'ai pu utiliser leur truc, la doc est pourrie mais j'en fait de la pire qu'eux, ça répond à un besoin, ca fonctionne, j'ai pas de meilleure solution. Donc je me la ferme, plutôt que de passer mon temps à cracher sur tout. J'espère que vous êtes dev et que vos utilisateurs sont aussi méprisant envers vous.

ConsoleKit fait uniquement ce pour quoi il est conçu, tracer les sessions. On peut l’interroger, et il émet les événements relatif à ca sur le bus session et le bus system. Le reste c'est le choix des clients de ConsoleKit. Si un IM veut passer le status en idle et desactiver les notifications sonores quand la session n'est plus active, c'est son choix il va pas demander au système. Si le système décide de supprimer temporairement certains droits aux applications d'une session inactive c'est son choix.

Pour le nice -n 20 j'aime quand tu insultes mon intelligence. Tu ne peux pas imaginer 30s que ça ne répond pas forcément à tout les besoins et qu'on peut avoir besoin de faire autrement ?

Mais où tu as vu quelqu'un dire que NM, pulseaudio ou autre c'était bien pour les serveurs ? Personne ne recommande d'utiliser ces trucs pour des serveurs, même pas la doc de redhat. Faut arrêter de fantasmer.

Par contre l'utilisation d'une machine ne s'arrête pas aux serveurs et aux sysadmin du dimanche. Alors il y a d'autres technos, pour d'autres utilisation; et tu utilises ce qui est adapté.

Si tu pars dans cette voie, NM c'est aussi inadapté pour un serveur, que la gestion via /etc & root pour un laptop. Pour faire des choses utilisables dans un environnement dynamiques pour des utilisateurs, on met la tête dans le sable en ce disant que tout est parfait ou on essai de faire mieux ?

ConsoleKit est un très bon exemple. Tellement indispensable qu'à peine arrivé il est déjà remplacé par autre chose

Premièrement ConsoleKit aura été livré dans Fedora pendant 6 ans…

Deuxièment peut être que ConsoleKit était nécessaire avec un init SysV mais passer à systemd permet de faire la chose plus proprement ? Moi en général avant de dire que les autres font des choix de merdes et sont incompétents, je lis le code et j'explique pourquoi ils sont cons, ou alors je suis plus modéré… J'attends donc ton argumentation. Pourquoi c'était mal fait, quelle était la meilleur solution ?

Tu t'es formé il y a dix ans, et tu étais obligé de te taper des kilo de documentation. Maintenant ca marche presque toujours tout seul, donc tes connaissances sont obsolètes et tu n'as rien appris des nouvelles technos. Maintenant si tu fournissais le même effort qu'à l'époque peut être que tu serais compétent aujourd'hui. Modulo le fait qu'un desktop moderne fait beaucoup plus de chose qu'il y a dix ans et qu'il y a donc forcément plus de choses à savoir.

Bref tu reproches aux autres ta fainéantise d'aujourd'hui tout en crachant sur leur boulot. Si tu veux revenir à l'état d'il y a dix ans, ce n'est pas très difficile mais tu vas couiner que rien ne marche…

Maintenant sur quoi tu te bases pour dire que ConsoleKit est un BloatKit ? En quoi est il plus mal conçu que les outils d'avant ? En quoi ne peut il pas être combiné avec d'autres outils ?

Si c'est autre chose, ça sert à quoi au juste ?

D'avoir un service qui est capable de connaitre les sièges et de suivre les sessions afin de permettre de faire des environnements pas trop cons, ce qui inclus de manière non exhaustives:
1. Pour les applis de bureau, de connaitre l'état de sa session. Si on est plus la session active, on peut passer idle, désactivé le son etc.
2. Pour la gestion des périphériques, adapté les permissions, changer les paramètres etc.
3. Pour les démons systèmes, savoir l'état global du système. Par exemple j'ai eu a écrire un service, qui devait détecter quand il n'y pas d'utilisateur actif pour lancer des calculs en tâche de fond. Sans un comportement commun type console kit t'es un peu dans la merde.

Ca ne sert à rien pour un serveur. Ca ne sert à rien si tu ne veux pas un comportement simili-intelligent. Ça ne sert pas à grand chose si tu as un seul utilisateur local par machine. Mais, ca sert à faire un système qui se comporte comme un tout. Histoire de sortir un peu de l'état pouilleux des bureaux Linux pour les particuliers.

Alors console-kit en tant que tel n'était peut être pas la solution la plus heureuse, mais ca répond à un besoin et personne n'a proposé mieux avec les briques qui existaient.