Au vue de la discussion sur comment faire les choses au mieux pour l'intégration de systemd et nfsutils https://bugzilla.redhat.com/show_bug.cgi?id=699040 , je pense que tu as du tombé sur un bug dans les fichiers service.
Donc n'hésite pas à ouvrir un bug report.
Pour ton premier exemple, je pense que tu peux juste déclencher une action "bloquer le lid switch" via dbus quand tu as du courant ( en écoutant upower ou le demon kivabien en fonction du bureau ) et en envoyant via dbus un inhibitor kivabien sur logind : http://www.freedesktop.org/wiki/Software/systemd/inhibit
Et je pense qu'on manque d'un framework haut niveau pour dbus, surtout vu l'importance que ça prends. Quelque chose du style du shell, ou tu peux réagir à des events, et en déclencher d'autres via des pipes.
J'aime bien les théories du complot, mais j'ai pris gout à des théories plus sophistiqués et qui tiennent pas avec des bouts de ficelles et ou on voit en 3 lignes le truc, donc tu m'excuseras de faire 2/3 remarques sur tes croyances.
Que Redhat a tout intérêt a contrôler cette brique de base du système, oui!
L'init classique des distros rpms, tu crois que ça venait d'ou ?
Le paquet initscript de mandriva, c'etait un fork de celui de fedora….
Au passage, je te ferait remarquer la présence de la dite société dans
Que Redhat ne voit pas d'inconvenient a en faire une dependence de plein d'autres projets, les rendent doucement
Linux-only, oui!
Plein ? Pour le moment, c'est la gestion de l’énergie dans gnome.
Les gens réclament des interfaces freedesktop, mais c'est exactement de ça qu'il s'agit, à savoir d'une interface freedesktop , celle de logind pour remplacer l'interface via consolekit, qui n'était pas portable sur netbsd ou openbsd, ou windows, ou le hurd, donc la portabilité était déjà absente. Ou celle via upower, qui devait être sans doute aussi trés linux only. J'ai vérifié, y a grosso modo 10 000 lignes de code C dans systemd-logind. Pour comparaison, telepathy-gabble (qui traine à coté sur mon disque ) fait 99 000 lignes de code.
De ce que je voit, le but est d'avoir un démon qui gère "je suis connecté, j'ai besoin de bloquer le suspend". Rien de transcendantalement complexe à refaire.
Que Redhat trouve très bien que les projects "concurrents" perdent du temps a redevelopper des dependences/libs
pour remplacer systemd au lieu d'investir du temps et de l'argent sur autre chose, oui!
Systemd est :
- en GPL/MIT
- avec le code source dispo
- avec de la doc ( en plus du code ) sur l'interface utilisé
- développé de manière ouverte
Ça ne prone pas en faveur d'une tentative de maximiser le temps perdu pour les autres projets.
En fait, c'est la le noeud de la théorie. Si les gens utilisent systemd, alors ç'est en faveur de RH car d'aprés toi, ça donne du controle, donc RH devrait tout faire tout pour. Mais si les gens passent du temps à éviter systemd et à la refaire, alors c'est selon toi aussi en la faveur de la boite car ils perdent du temps.
Mais attends, y a mieux. RH pourrait prendre le code d'un concurrent ( genre celui d'upstart ) et le mettre dans son produit, comme ça, la charge de maintenance est pas pour eux, et donc ils y gagnent sur le long terme.
OU RH pourrait garder du vieux code, comme ça, ils peuvent vendre du support sur un truc qui ne bouge pas, donc les couts sont réduits, donc ils y gagnent.
En fait, pousser systemd partout, pousser systemd juste sur Fedora, garder init, pousser upstart, dans tout les cas, on peut trouver un moyen de dire que RH va y gagner. À partir de la, si pour tout X, Y est vrai, est ce qu'on peut pas simplement déduire qu'il y a pas de relation de cause à effet entre X et Y ?
Y a un agent dans gnome, un dans gnome-shell, un pour kde. Par agent d'authentification, faut comprendre "popup qui demande le mot de passe", y a rien de compliqué.
Moi sur une Fedora, j'ai un rpm polkit-gnome, mais il y a aussi polkit-kde, polkit-qt, lxpolkit pour que le look and feel colle.
C'est quoi ça, taper Ctrl + Alt + Fx pour aller sur une autre console et se loguer en tant que quelqu'un d'autre ?
Le bouton "changer d'utilisateur" dans gnome/kde ou autre, qui va verrouiller ta session, couper la musique et s'assurer que l'autre personne puisse accéder aux clés usb en local pendant que tu es pas en face, entre autre. une feature que windows xp propose depuis le début, au passage.
Et tu connais des administrateurs qui utilisent ces possibilités ?
template issue de la config puppet du projet mageia, pour dire "tel personnes dans tel groupe ldap ont le droit de lancer virt-manager pour couper les bécanes ou de les relancer sans avoir les droits root". S
inon, tu as aussi des gens qui laissent les utilisateurs faire les updates sans mot de passes via packagekit ( sauf erreur de ma part, c'est le cas au boulot même si j'ai pas la bécane sous la main pour vérifier ).
En general, la configuration du réseau va aussi dans le systéme d'init, tout comme le chargement des modules, l'application des sysctl, etc, etc. Le réseau est pas unifié sous systemd, mais le reste l'est déja plus, et ça, ça aide pour les ISVs a mon avis. Et les admins. Même si une distro n'est pas d'accord avec systemd, reprendre les interfaces, ça peut faire un pas en avant vers moins de différences gratuites.
D'avoir quelqu'un qui maintient, et pas juste quelqu'un qui fait de la compilation. Si tu regardes bien, Linuxmint ne fait pas de mises à jours de sécurité autre que celle de Canonical, et ils savent pas coder propre ( CVE-2012-1566 comme je le dit si souvent ).
On parle pas des fondements d'unix, on parle du système d'init qui est moisi car justement, on estime que sa seule fonction et interface, c'est de lancer le soft et advienne que pourra. On a donc rajouter par dessus un système de scripts qui fait une chose , copier celui du voisin avec divers variations, et ça donne les soucis que j'ai listé.
Et c'est bien parce que init ne fait qu'une chose, à savoir lancer un programme qui va lancer des scripts qui va lancer d'autres scripts que c'est le merdier.
Systemd a une autre approche, ou on considère que le boot, c'est un ensemble d'unité qui doit être lancé et orchestré pour avoir un système qui marche. Ou on se dit que monter un fs, c'est autant un truc de boot que de lancer sympa ( dont le script lance 4 demons à la suite par exemple ).
Ça remets en cause ta vision des idées d'unix, sans doute. Mais ça corrige les problèmes que tu as nié, et c'est pas négligeable.
Être en userland, ça rends pas les choses portables par magie. Il est ou le port BSD de iptables, ou le port linux de la commande jail ?
Systemd utilise des APis propre à linux ( comme les cgroups, udev, mais encore d'autres comme l'api pour charger des modules, selinux ( de façon optionnel ), le systeme de namespace de linux et divers API, une liste avait été posté ). Il est donc aussi dépendant de linux que shorewall ou NetworkManager puisse l'être.
Sauf que dans le cas de nm, personne ne se précipite pour faire le taf ( curieusement ) alors que le dev accepte les patchs. Donc oui, râler sur "on refuse les patchs", c'est joli. Mais en pratique, personne ne fait le taf quand même. Autant arrêter l'hypocrisie. Sans cgroups, systemd ne marche pas. Donc y a aucun sens à faire le portage tant que ça manque sur les autres noyaux.
Excuse moi, mais ça fait 40 ans maintenant que UNIX et Linux gère naturellement et sans aucun problème ses daemons !
Dit pas de la merde. La gestion des daemons, c'est pas "sans aucun problème". J'ai donné 15 fois les exemples, mais je vais les redonner, même si je sais que ça va pas rentrer.
Tu prends apache, qui va forker une paire de fois avant de lancer un cgi ( donc un autre process ) en perl qui va lancer encore des softs ( genre imagemagick ) en tache de fond. Si le cgi claque, tu va perdre la trace du process qui va devenir un zombie. C'est pas ce que j'appelle sans souci.
Tu prends bind, qui s'éteint de façon asynchrone, et qui requiert de rajouter sleep dans restart ( et donc interdit de faire "stop"/"start" en shell ). C'est pas sans souci.
Tu prends un soft mal codé ( genre sympa qui attends que pgsql soit up avant de continuer ) ou malconfiguré ( genre mcollective avec daemonize = 0 qui du coup passe pas en background et qui bloque le boot de ta bécane ). C'est pas sans souci.
Tout ça, c'est des exemples que j'ai vu il y a moins de 3 ans sur des distros modernes sur des serveurs en production. Et en pratique, quand tu regardes le code des softs, tu vois que personne ne sait exactement comment lancer un daemon proprement ( genre, aller sur /, faire un double fork, écrire le pid, se détacher du terminal, etc ), donc forcément, des softs qui font de la merde, y en a des tonnes, et à moins d'avoir vécu sur un igloo loin du monde réel ou isolé du travail au jour le jour sur une distro, tu peux pas dire "ça marche depuis 40 ans" et garder ta crédibilité.
Ça fait 40 ans que le système d'init est écrit dans un langage ( le shell, pas le bash ) sans espace de nommage, sans tests, sans gestion avancé des chaines, sans tableau, sans gestion du parallélisme, ou le fait de lire un fichier requiert de faire un fork/exec. C'est des bouts de ficelles. Apple a refait le système d'init. Solaris l'a refait. Ubuntu l'a refait. Gentoo l'a refait. Personne ne se dit vraiment "y a une raison" ?
inetd, ça reste une blague. Tu veux sans doute dire "xinetd", déjà, et sauf erreur de ma part, xinetd gère pas les sockets unix ( exemple cups, exemple mysql, exemple ldap pour ne citer que 3 qui me viennent à l'esprit ).
Euh non, ça veut pas dire qu'on a toujours besoin. Le mot clé noauto, il est pas la pour faire joli et n'avoir aucun effet. Il y a quand même une époque ou il fallait monter à la main les cdroms et les disquettes, et c'était dans /etc/fstab.
Les plus chanceux pouvait passer par un patch kernel ( genre automount, mis dans le kernel mandrake ), ou via autofs. D'ailleurs, c'est encore dans la config par défaut d'autofs.
Et donc, la solution est de garder la compatibilité avec l'ancien systéme ( en l'occurence consolekit ) car 1) ça pue pas 2) ça peut encore évoluer vers un nouveau paradigme ?
Ce qui est bien, c'est que quand systemd fait trop de choses, ça pue, et quand ça en fait pas assez et ça prends pas en compte des concepts non définis et non existants pour le moment, ça pue quand même. Donc tout le monde est d'accord pour dire qu'il y a un juste milieu, sauf que personne ne le code ou ne l'explicite ( voir même ne le défend, car la, c'est "on pourrait trouver des exemples", mais pas besoin d'en donner, ni même de faire remarquer qu'on peut toujours rajouter une API autre par la suite si besoin )
Quel pourcentage d'utilisateurs font du multiseat par rapport à quel pourcentage de temps ils vont devoir consacrer à
cette fonctionnalité ?
En fait, c'est plus "combien de personnes qui demandent ça sur linuxfr vont consacrer du temps à faire du code ou contribuer". Et qu'on me dise pas "ça prends du temps". Oui, ça prends du temps, mais si les gens veulent pas le prendre, faut pas râler si d'autres ( en l'occurrence les devs upstreams ) font le même choix.
non, c'est pas exactement ça. Policykit demande a un agent , agent qui va demander le mot de passe ou la méthode d'autorisation ( soit mot de passe de l'user, soit root, soit autre chose, c'est souple ). Ensuite, polkit peut aussi décider en se basant sur consolekit ( genre "le droit de regler l'heure est dispo pour la personne connecté physiquement sur la machine sans mot de passe" ).
Parmi l'usage, ça permet notamment de couper le son quand on change d'user ( fast user switching ), de savoir si un utilisateur est connecté en ssh, en tty ou en graphique et d'agir en conséquence ( l'usage en ssh ne donne pas accès à la carte son si quelqu'un est déjà la, pour des questions évidentes d'accès en lecture ( micro, etc )).
Le but étant de gérer de façon plus intelligente que les simples droits unix les problématiques comme "qui a l'accès au clavier à un temps T, à qui je file la clé usb qui vient d'être branché, etc". Des trucs que windows ou os x gère depuis toujours de façon cohérente pour l'utilisateur ( comment, je sais pas ).
Policykit permet de faire des trucs relativement sympas, comme dire "seul les gens de tel groupe peuvent administrer les vms en local", ou bloquer le fait de partager la connexion en wifi sauf si on file le mot de passe root. Ça permet à l'admin d'un poste client de vraiment regler au poil, même si tout n'utilise pas encore ça, et même si je trouve que parfois, c'est pas assez granulaire. Mais les bases sont la.
non je parle de kde 3, mon exemple date un peu. Ceci dit, c'était pas forcément kwin, mais l'outil responsable de la boite de dialogue "log out" de kde 3.4 ou .5, ça devait être lui, non ?
Et je me souviens pas avoir vu personne dire "mandriva va avoir plus de pouvoir avec pinit", ni l'équivalent avec arch, gentoo ou même Ubuntu avec upstart ( upstart qui a été mis sur rhel, sur fedora, et sur divers distros à l'époque ).
Non, l'équivalent serait d'avoir init qui segfault en lisant /etc/inittab. ( et en fait, la seule raison pour laquelle init ne segfault pas, c'est parce que personne n'y touche jamais )
Enfin, j'étais la lors du souci, et je pense toi non, donc tu m'excuseras de pouvoir dire si c'était dur ou pas, et toi, de pas avoir la moindre légitimité à ce sujet.
Et il va se passer quoi ? Des gens vont … se disputer sur une liste de diffusion.
Sincèrement, est ce que les séries télés sont si nulles de nos jours qu'on se retrouve à devoir inventer du drama dans le libre ? ( et linuxfr est soft quand je compare à omg ubuntu )
En pratique, c'est rien de nouveau. Par exemple, kwin n'avait toutes les fonctionnalités ( intégration avec lilo ) qu'avec kdm pendant un temps ( et c'est pas pour dire "kde le fait aussi", c'est juste que c'est un exemple qui était ressorti à l'époque ou c'était mon bureau ). Moi, ça me parait normal et même sain pour l'innovation.
Perso, j'ai déjà eu un souci sur systemd avec la version de dev de Fedora. Et c'était pas plus douloureux que n'importe quel plantage d'un truc au boot ( genre, sshd se lance pas ). Dracut m'a filé un shell, j'ai regardé ce qu'il y a eu comme souci ( à savoir systemd qui plante au démarrage ), le bug était déjà remonté sur le bugzilla, j'ai fait un rollback, et j'ai attendu l'upgrade.
Donc parfait, on peut en parler ( en tout cas, moi, je peux, toi, je sais pas ). Rappelle moi, ton expérience avec le sujet est ?
Le but de systemd c'est uniquement de noyauter les projets libres pour obliger l'utilisation de certaines
technologies, pas de booter plus vite.
En fait, le seul truc vrai, c'est la fin. le but n'est pas de booter plus vite.
Pour le reste, même en relisant lentement, je pige pas, le but serait d'imposer l'usage d'une technologie afin de ?
D'obtenir plus de richesses ?
Plus de pouvoir ?
Faire taire les opposants politiques ?
Un vendor lockin autour du système de boot, ce qui bloquerais toute alternative ?
Je doit pas avoir assez d'imagination, mais c'est sans doute le fruit d'un lavage de cerveau du à mon installation de Fedora sur mon portable, sinon je verrais la guerre en cours, avec tous les morts que ça entraine, tout ces gens qui ont donnés de leur vie pour que gnome soit sans systemd.
[^] # Re: C’est pas encore ça…
Posté par Misc (site web personnel) . En réponse au journal GNOME systemd : et la guerre ne fait que commencer. Évalué à 2.
Au vue de la discussion sur comment faire les choses au mieux pour l'intégration de systemd et nfsutils
https://bugzilla.redhat.com/show_bug.cgi?id=699040 , je pense que tu as du tombé sur un bug dans les fichiers service.
Donc n'hésite pas à ouvrir un bug report.
[^] # Re: Le problème…
Posté par Misc (site web personnel) . En réponse au journal GNOME systemd : et la guerre ne fait que commencer. Évalué à 3.
Pour ton premier exemple, je pense que tu peux juste déclencher une action "bloquer le lid switch" via dbus quand tu as du courant ( en écoutant upower ou le demon kivabien en fonction du bureau ) et en envoyant via dbus un inhibitor kivabien sur logind :
http://www.freedesktop.org/wiki/Software/systemd/inhibit
Et je pense qu'on manque d'un framework haut niveau pour dbus, surtout vu l'importance que ça prends. Quelque chose du style du shell, ou tu peux réagir à des events, et en déclencher d'autres via des pipes.
[^] # Re: C'est mort
Posté par Misc (site web personnel) . En réponse au journal GNOME systemd : et la guerre ne fait que commencer. Évalué à 1.
gdmflexiserver marche encore sur ma machine, il te faut quoi de plus pour du multiseat ?
[^] # Re: Alors
Posté par Misc (site web personnel) . En réponse au journal GNOME systemd : et la guerre ne fait que commencer. Évalué à 10.
J'aime bien les théories du complot, mais j'ai pris gout à des théories plus sophistiqués et qui tiennent pas avec des bouts de ficelles et ou on voit en 3 lignes le truc, donc tu m'excuseras de faire 2/3 remarques sur tes croyances.
L'init classique des distros rpms, tu crois que ça venait d'ou ?
Le paquet initscript de mandriva, c'etait un fork de celui de fedora….
Au passage, je te ferait remarquer la présence de la dite société dans
Plein ? Pour le moment, c'est la gestion de l’énergie dans gnome.
Et le mainteneur Solaris explique bien que le code est déjà linux only
https://mail.gnome.org/archives/desktop-devel-list/2012-October/msg00081.html
Les gens réclament des interfaces freedesktop, mais c'est exactement de ça qu'il s'agit, à savoir d'une interface freedesktop , celle de logind pour remplacer l'interface via consolekit, qui n'était pas portable sur netbsd ou openbsd, ou windows, ou le hurd, donc la portabilité était déjà absente. Ou celle via upower, qui devait être sans doute aussi trés linux only. J'ai vérifié, y a grosso modo 10 000 lignes de code C dans systemd-logind. Pour comparaison, telepathy-gabble (qui traine à coté sur mon disque ) fait 99 000 lignes de code.
Alors peut être que les gens voudraient avoir une interface différente, et ça a été discuté sur https://bugzilla.gnome.org/show_bug.cgi?id=680689
De ce que je voit, le but est d'avoir un démon qui gère "je suis connecté, j'ai besoin de bloquer le suspend". Rien de transcendantalement complexe à refaire.
Systemd est :
- en GPL/MIT
- avec le code source dispo
- avec de la doc ( en plus du code ) sur l'interface utilisé
- développé de manière ouverte
Ça ne prone pas en faveur d'une tentative de maximiser le temps perdu pour les autres projets.
En fait, c'est la le noeud de la théorie. Si les gens utilisent systemd, alors ç'est en faveur de RH car d'aprés toi, ça donne du controle, donc RH devrait tout faire tout pour. Mais si les gens passent du temps à éviter systemd et à la refaire, alors c'est selon toi aussi en la faveur de la boite car ils perdent du temps.
Mais attends, y a mieux. RH pourrait prendre le code d'un concurrent ( genre celui d'upstart ) et le mettre dans son produit, comme ça, la charge de maintenance est pas pour eux, et donc ils y gagnent sur le long terme.
OU RH pourrait garder du vieux code, comme ça, ils peuvent vendre du support sur un truc qui ne bouge pas, donc les couts sont réduits, donc ils y gagnent.
En fait, pousser systemd partout, pousser systemd juste sur Fedora, garder init, pousser upstart, dans tout les cas, on peut trouver un moyen de dire que RH va y gagner. À partir de la, si pour tout X, Y est vrai, est ce qu'on peut pas simplement déduire qu'il y a pas de relation de cause à effet entre X et Y ?
[^] # Re: Alors
Posté par Misc (site web personnel) . En réponse au journal GNOME systemd : et la guerre ne fait que commencer. Évalué à 2.
Y a un agent dans gnome, un dans gnome-shell, un pour kde. Par agent d'authentification, faut comprendre "popup qui demande le mot de passe", y a rien de compliqué.
Moi sur une Fedora, j'ai un rpm polkit-gnome, mais il y a aussi polkit-kde, polkit-qt, lxpolkit pour que le look and feel colle.
[^] # Re: Alors
Posté par Misc (site web personnel) . En réponse au journal GNOME systemd : et la guerre ne fait que commencer. Évalué à 4.
Consolekit gère aussi les permissions.
https://wiki.archlinux.org/index.php/ConsoleKit
Le bouton "changer d'utilisateur" dans gnome/kde ou autre, qui va verrouiller ta session, couper la musique et s'assurer que l'autre personne puisse accéder aux clés usb en local pendant que tu es pas en face, entre autre. une feature que windows xp propose depuis le début, au passage.
Moi, et je le prouve :
http://svnweb.mageia.org/adm/puppet/modules/libvirtd/templates/50-template-libvirt-remote-access.pkla?revision=985&view=markup
template issue de la config puppet du projet mageia, pour dire "tel personnes dans tel groupe ldap ont le droit de lancer virt-manager pour couper les bécanes ou de les relancer sans avoir les droits root". S
inon, tu as aussi des gens qui laissent les utilisateurs faire les updates sans mot de passes via packagekit ( sauf erreur de ma part, c'est le cas au boulot même si j'ai pas la bécane sous la main pour vérifier ).
[^] # Re: C'est mort
Posté par Misc (site web personnel) . En réponse au journal GNOME systemd : et la guerre ne fait que commencer. Évalué à 3.
En general, la configuration du réseau va aussi dans le systéme d'init, tout comme le chargement des modules, l'application des sysctl, etc, etc. Le réseau est pas unifié sous systemd, mais le reste l'est déja plus, et ça, ça aide pour les ISVs a mon avis. Et les admins. Même si une distro n'est pas d'accord avec systemd, reprendre les interfaces, ça peut faire un pas en avant vers moins de différences gratuites.
[^] # Re: C'est mort
Posté par Misc (site web personnel) . En réponse au journal GNOME systemd : et la guerre ne fait que commencer. Évalué à 3.
D'avoir quelqu'un qui maintient, et pas juste quelqu'un qui fait de la compilation. Si tu regardes bien, Linuxmint ne fait pas de mises à jours de sécurité autre que celle de Canonical, et ils savent pas coder propre ( CVE-2012-1566 comme je le dit si souvent ).
Et systemd supporte le multiseat : http://www.freedesktop.org/wiki/Software/systemd/multiseat
Tu noteras aussi https://bugzilla.gnome.org/show_bug.cgi?id=655380
[^] # Re: C'est mort
Posté par Misc (site web personnel) . En réponse au journal GNOME systemd : et la guerre ne fait que commencer. Évalué à 9.
On parle pas des fondements d'unix, on parle du système d'init qui est moisi car justement, on estime que sa seule fonction et interface, c'est de lancer le soft et advienne que pourra. On a donc rajouter par dessus un système de scripts qui fait une chose , copier celui du voisin avec divers variations, et ça donne les soucis que j'ai listé.
Et c'est bien parce que init ne fait qu'une chose, à savoir lancer un programme qui va lancer des scripts qui va lancer d'autres scripts que c'est le merdier.
Systemd a une autre approche, ou on considère que le boot, c'est un ensemble d'unité qui doit être lancé et orchestré pour avoir un système qui marche. Ou on se dit que monter un fs, c'est autant un truc de boot que de lancer sympa ( dont le script lance 4 demons à la suite par exemple ).
Ça remets en cause ta vision des idées d'unix, sans doute. Mais ça corrige les problèmes que tu as nié, et c'est pas négligeable.
[^] # Re: Alors
Posté par Misc (site web personnel) . En réponse au journal GNOME systemd : et la guerre ne fait que commencer. Évalué à 10.
Être en userland, ça rends pas les choses portables par magie. Il est ou le port BSD de iptables, ou le port linux de la commande jail ?
Systemd utilise des APis propre à linux ( comme les cgroups, udev, mais encore d'autres comme l'api pour charger des modules, selinux ( de façon optionnel ), le systeme de namespace de linux et divers API, une liste avait été posté ). Il est donc aussi dépendant de linux que shorewall ou NetworkManager puisse l'être.
Sauf que dans le cas de nm, personne ne se précipite pour faire le taf ( curieusement ) alors que le dev accepte les patchs. Donc oui, râler sur "on refuse les patchs", c'est joli. Mais en pratique, personne ne fait le taf quand même. Autant arrêter l'hypocrisie. Sans cgroups, systemd ne marche pas. Donc y a aucun sens à faire le portage tant que ça manque sur les autres noyaux.
[^] # Re: C'est mort
Posté par Misc (site web personnel) . En réponse au journal GNOME systemd : et la guerre ne fait que commencer. Évalué à 10.
Tu prends apache, qui va forker une paire de fois avant de lancer un cgi ( donc un autre process ) en perl qui va lancer encore des softs ( genre imagemagick ) en tache de fond. Si le cgi claque, tu va perdre la trace du process qui va devenir un zombie. C'est pas ce que j'appelle sans souci.
Tu prends bind, qui s'éteint de façon asynchrone, et qui requiert de rajouter sleep dans restart ( et donc interdit de faire "stop"/"start" en shell ). C'est pas sans souci.
Tu prends un soft mal codé ( genre sympa qui attends que pgsql soit up avant de continuer ) ou malconfiguré ( genre mcollective avec daemonize = 0 qui du coup passe pas en background et qui bloque le boot de ta bécane ). C'est pas sans souci.
Tout ça, c'est des exemples que j'ai vu il y a moins de 3 ans sur des distros modernes sur des serveurs en production. Et en pratique, quand tu regardes le code des softs, tu vois que personne ne sait exactement comment lancer un daemon proprement ( genre, aller sur /, faire un double fork, écrire le pid, se détacher du terminal, etc ), donc forcément, des softs qui font de la merde, y en a des tonnes, et à moins d'avoir vécu sur un igloo loin du monde réel ou isolé du travail au jour le jour sur une distro, tu peux pas dire "ça marche depuis 40 ans" et garder ta crédibilité.
Ça fait 40 ans que le système d'init est écrit dans un langage ( le shell, pas le bash ) sans espace de nommage, sans tests, sans gestion avancé des chaines, sans tableau, sans gestion du parallélisme, ou le fait de lire un fichier requiert de faire un fork/exec. C'est des bouts de ficelles. Apple a refait le système d'init. Solaris l'a refait. Ubuntu l'a refait. Gentoo l'a refait. Personne ne se dit vraiment "y a une raison" ?
[^] # Re: C'est mort
Posté par Misc (site web personnel) . En réponse au journal GNOME systemd : et la guerre ne fait que commencer. Évalué à 4.
inetd, ça reste une blague. Tu veux sans doute dire "xinetd", déjà, et sauf erreur de ma part, xinetd gère pas les sockets unix ( exemple cups, exemple mysql, exemple ldap pour ne citer que 3 qui me viennent à l'esprit ).
Tu peux aussi lire http://0pointer.de/blog/projects/inetd.html ou http://0pointer.de/blog/projects/socket-activation.html pour voir ou sont les différences.
[^] # Re: C'est mort
Posté par Misc (site web personnel) . En réponse au journal GNOME systemd : et la guerre ne fait que commencer. Évalué à 6.
Euh non, ça veut pas dire qu'on a toujours besoin. Le mot clé noauto, il est pas la pour faire joli et n'avoir aucun effet. Il y a quand même une époque ou il fallait monter à la main les cdroms et les disquettes, et c'était dans /etc/fstab.
Les plus chanceux pouvait passer par un patch kernel ( genre automount, mis dans le kernel mandrake ), ou via autofs. D'ailleurs, c'est encore dans la config par défaut d'autofs.
[^] # Re: API disponible
Posté par Misc (site web personnel) . En réponse au journal GNOME systemd : et la guerre ne fait que commencer. Évalué à 6.
Et donc, la solution est de garder la compatibilité avec l'ancien systéme ( en l'occurence consolekit ) car 1) ça pue pas 2) ça peut encore évoluer vers un nouveau paradigme ?
Ce qui est bien, c'est que quand systemd fait trop de choses, ça pue, et quand ça en fait pas assez et ça prends pas en compte des concepts non définis et non existants pour le moment, ça pue quand même. Donc tout le monde est d'accord pour dire qu'il y a un juste milieu, sauf que personne ne le code ou ne l'explicite ( voir même ne le défend, car la, c'est "on pourrait trouver des exemples", mais pas besoin d'en donner, ni même de faire remarquer qu'on peut toujours rajouter une API autre par la suite si besoin )
[^] # Re: C'est mort
Posté par Misc (site web personnel) . En réponse au journal GNOME systemd : et la guerre ne fait que commencer. Évalué à 2.
En fait, c'est plus "combien de personnes qui demandent ça sur linuxfr vont consacrer du temps à faire du code ou contribuer". Et qu'on me dise pas "ça prends du temps". Oui, ça prends du temps, mais si les gens veulent pas le prendre, faut pas râler si d'autres ( en l'occurrence les devs upstreams ) font le même choix.
[^] # Re: Alors
Posté par Misc (site web personnel) . En réponse au journal GNOME systemd : et la guerre ne fait que commencer. Évalué à 6.
non, c'est pas exactement ça. Policykit demande a un agent , agent qui va demander le mot de passe ou la méthode d'autorisation ( soit mot de passe de l'user, soit root, soit autre chose, c'est souple ). Ensuite, polkit peut aussi décider en se basant sur consolekit ( genre "le droit de regler l'heure est dispo pour la personne connecté physiquement sur la machine sans mot de passe" ).
Consolekit, il gère juste qui est connecté sur la machine, sur un tty, graphiquement, etc ( http://www.freedesktop.org/software/ConsoleKit/doc/ConsoleKit.html ). Voir par exemple la sortie de ck-list-sessions
Parmi l'usage, ça permet notamment de couper le son quand on change d'user ( fast user switching ), de savoir si un utilisateur est connecté en ssh, en tty ou en graphique et d'agir en conséquence ( l'usage en ssh ne donne pas accès à la carte son si quelqu'un est déjà la, pour des questions évidentes d'accès en lecture ( micro, etc )).
Le but étant de gérer de façon plus intelligente que les simples droits unix les problématiques comme "qui a l'accès au clavier à un temps T, à qui je file la clé usb qui vient d'être branché, etc". Des trucs que windows ou os x gère depuis toujours de façon cohérente pour l'utilisateur ( comment, je sais pas ).
Policykit permet de faire des trucs relativement sympas, comme dire "seul les gens de tel groupe peuvent administrer les vms en local", ou bloquer le fait de partager la connexion en wifi sauf si on file le mot de passe root. Ça permet à l'admin d'un poste client de vraiment regler au poil, même si tout n'utilise pas encore ça, et même si je trouve que parfois, c'est pas assez granulaire. Mais les bases sont la.
[^] # Re: Bah
Posté par Misc (site web personnel) . En réponse au journal GNOME systemd : et la guerre ne fait que commencer. Évalué à 1.
non je parle de kde 3, mon exemple date un peu. Ceci dit, c'était pas forcément kwin, mais l'outil responsable de la boite de dialogue "log out" de kde 3.4 ou .5, ça devait être lui, non ?
[^] # Re: Alors
Posté par Misc (site web personnel) . En réponse au journal GNOME systemd : et la guerre ne fait que commencer. Évalué à 3.
C'est pas systemd qui va changer grand chose, si avoir du code libre donne un pouvoir énorme, c'est déjà trop tard :
http://community.redhat.com/contributions/
Et je me souviens pas avoir vu personne dire "mandriva va avoir plus de pouvoir avec pinit", ni l'équivalent avec arch, gentoo ou même Ubuntu avec upstart ( upstart qui a été mis sur rhel, sur fedora, et sur divers distros à l'époque ).
[^] # Re: Alors
Posté par Misc (site web personnel) . En réponse au journal GNOME systemd : et la guerre ne fait que commencer. Évalué à 5.
Non, l'équivalent serait d'avoir init qui segfault en lisant /etc/inittab. ( et en fait, la seule raison pour laquelle init ne segfault pas, c'est parce que personne n'y touche jamais )
Enfin, j'étais la lors du souci, et je pense toi non, donc tu m'excuseras de pouvoir dire si c'était dur ou pas, et toi, de pas avoir la moindre légitimité à ce sujet.
[^] # Re: Alors
Posté par Misc (site web personnel) . En réponse au journal GNOME systemd : et la guerre ne fait que commencer. Évalué à 10.
En quoi consolekit est un produit de lennart ?
L'auteur initial est "William Jon McCann", en 2006. ( http://cgit.freedesktop.org/ConsoleKit/log/?ofs=350 )
Ne serais pas tes lunettes qu'il faut laver plutôt que tes assiettes ?
[^] # Re: Pop-corn
Posté par Misc (site web personnel) . En réponse au journal GNOME systemd : et la guerre ne fait que commencer. Évalué à 6.
Et il va se passer quoi ? Des gens vont … se disputer sur une liste de diffusion.
Sincèrement, est ce que les séries télés sont si nulles de nos jours qu'on se retrouve à devoir inventer du drama dans le libre ? ( et linuxfr est soft quand je compare à omg ubuntu )
[^] # Re: Bah
Posté par Misc (site web personnel) . En réponse au journal GNOME systemd : et la guerre ne fait que commencer. Évalué à 1.
En pratique, c'est rien de nouveau. Par exemple, kwin n'avait toutes les fonctionnalités ( intégration avec lilo ) qu'avec kdm pendant un temps ( et c'est pas pour dire "kde le fait aussi", c'est juste que c'est un exemple qui était ressorti à l'époque ou c'était mon bureau ). Moi, ça me parait normal et même sain pour l'innovation.
[^] # Re: Alors
Posté par Misc (site web personnel) . En réponse au journal GNOME systemd : et la guerre ne fait que commencer. Évalué à 8.
Perso, j'ai déjà eu un souci sur systemd avec la version de dev de Fedora. Et c'était pas plus douloureux que n'importe quel plantage d'un truc au boot ( genre, sshd se lance pas ). Dracut m'a filé un shell, j'ai regardé ce qu'il y a eu comme souci ( à savoir systemd qui plante au démarrage ), le bug était déjà remonté sur le bugzilla, j'ai fait un rollback, et j'ai attendu l'upgrade.
Donc parfait, on peut en parler ( en tout cas, moi, je peux, toi, je sais pas ). Rappelle moi, ton expérience avec le sujet est ?
[^] # Re: Alors
Posté par Misc (site web personnel) . En réponse au journal GNOME systemd : et la guerre ne fait que commencer. Évalué à 2.
En fait, le seul truc vrai, c'est la fin. le but n'est pas de booter plus vite.
Pour le reste, même en relisant lentement, je pige pas, le but serait d'imposer l'usage d'une technologie afin de ?
D'obtenir plus de richesses ?
Plus de pouvoir ?
Faire taire les opposants politiques ?
Un vendor lockin autour du système de boot, ce qui bloquerais toute alternative ?
Je doit pas avoir assez d'imagination, mais c'est sans doute le fruit d'un lavage de cerveau du à mon installation de Fedora sur mon portable, sinon je verrais la guerre en cours, avec tous les morts que ça entraine, tout ces gens qui ont donnés de leur vie pour que gnome soit sans systemd.
[^] # Re: un peu gonflé quand meme
Posté par Misc (site web personnel) . En réponse au journal Ubuntu : une donation à Ubuntu/Canonical va être proposée avant le téléchargement de la distribution. Évalué à 3.
Déjà fait :
https://launchpad.net/~scopes-packagers/+archive/adult-scopes
Une fonction curieusement peu mise en avant.