L’un ou l’autre :
Upstart en meilleure position ?
Peut-être que si tu voulais faire de l’information et non du sensationnalisme tu irais lire directement aux sources et tu verrais les différentes questions abordées :
bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708
et autres sources Debian
Salut,
[quote=“hitch”]Peut-être que si tu voulais faire de l’information et non du sensationnalisme tu irais lire directement aux sources et tu verrais les différentes questions abordées :
bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708
et autres sources Debian[/quote]
[Distro-politique] Gnome, Systemd et Debian
[1] igurublog.wordpress.com/2012/11/ … in-threes/
[2] debian-facile.org/viewtopic.php?id=7612
[3] lists.debian.org/debian-devel/2 … 00444.html
[4] lists.debian.org/debian-devel/20 … 00496.html
[5] blogs.gnome.org/ovitters/2013/09 … -thoughts/
Et si plutôt que balancer des liens en tout genre que n’importe quel barbu à déjà du lire ou est plus ou moins au courant … vous expliquez un poil plus.
J’explique :
- Les news de ce genre sont totalement indigeste pour les ‘newbies’ donc autant prendre le temps de refaire un point.
- Ce genre de news balancer tel quel ne motive pas des gens qui n’ont pas trop l’habitude d’aller fouiner de cliquer et de lire des news parfois en anglais.
- Comme la précisé avec raison Hitch à quoi bon remonter l’information sur un autre site alors que l’information existe sur les listes de diffusion ou les reportbugs.
Gnome va exigé systemd (pour l’instant) pour gérer le démarrage, hors systemd ne permet pas de continuer de façon pérennisé le port du kernel FreeBSD, Hurd.
Mais ce n’est pas les seuls problèmes, Upstart de son côté pourrait proposer des patch mais ne serait pas non plus natif pour les ports actuellement en cours de Debian.
Il y a pleins d’autre problèmes qui sont posés mais je n’ai pas tous les tenants pour aborder tout ça (ni le temps et ni la volonté de développer) mais par pitié arrêtez de balancer des liens sans rien dire de plus.
il faut quand même reconnaître que le sujet sur debian-facile est clair et très bien fait. merci a captnfab
Clairement orienté avec de jolies simplifications.
Je ne sais pas ce qu’il en est pour gdm, mais gnome dépend de services dbus avec logind. Actuellement seul systemd propose les backends dbus qui vont avec, mais c’est séparé du système d’init.
Quand on énumère les options on oublie souvent celle qui a ma faveur (et qui déchire tout) : metainit
Je n’ai pas regardé plus que ça pour le moment, maisje pense que le seul backend disponible actuellement c’est les scripts sysvinit, mais vu la facilité d’écrire une unit systemd ou un script openrc, ça ne doit pas être la mort à ajouter. Ce qu’il faut c’est que la description des services dans la syntaxe metainit soit suffiament complète pour tous les init.
Salut,
Je plussoie ! 
Et, c’est bien pour cela que j’ai inséré ce lien que je suis depuis sa création (entre autre), CaptaineFab ( 
) à joliment et clairement résumé/développer/rechercher ce sujet des plus épineux.
C’est bien le but de ce fil debian-fr Pause café (pas tout à fait HS il me semble), avoir des pistes et avis pour en savoir plus et démêler les choses 
Je ne suis pas l’auteur de l’article de Phoronix, alors le sensationnalisme ne me rapporte rien (ou alors j’aurais fait un journal linuxfr ou un billet sur mon blogue 
)
M’en vais lire vos liens
Le problème n’est pas tant Gnome3+systemd vs le reste (problème réel et à résoudre c’est sûr) plutôt que la logique même d’un environnement complet (comme KDE, Gnome et peut être bientôt XFCE)par rapport à une machine modulaire.
Il y a deux logiques qu’on pourrait appeler logique Gnome et logique fluxbox:
Logique Gnome: On fournit un environnement de bureau qui traite tous les problèmes que peut rencontrer un utilisateur sur sa machine: on y trouve donc les classqiues bureaux, barre de tache, etc mais aussi le gestionnaire de réseaux, d’imprimantes, d’agendas, et même de paquets. C’est à voir comme une gigantesque couche incontournable. Une éventuelle modularité s’estompe vite devant les interdépendances des modules entre eux. Par ailleurs, il est évident que cette énorme surcouche va figer ce qu’il y a en dessous: démarrage, gestion du réseau, des imprimante, etc en accaparant de plus en plus des taches systèmes de plus bas niveau. C’est ce qu’il se passe avec Gnome qui par exemple demandait la neutralisation de la gestion par script des interfaces et qui désormais veut figer le démarrage d’une session.
Disons le cela conduit à un environnement tout en un type Windows avec à la longue ses inconvénients, notamment une énorme complexité et la quasi impossibilité de comprendre un éventuel dysfonctionnement.
Logique fluxbox: (ou Windowmaker, XFCE, etc) On fournit un gestionnaire de fenêtres, un gestionnaire de sessions, un bureau, un logiciel de gestion de barres de taches, etc bref autant de modules dédiés à des taches précises que l’on peut mélanger ou utiliser seul. Cela complique les choses (l’autonomie d’un module finit par limiter ses possibilités et entrainer un empiétement des rôles), rend la configuration d’une machine plus compliquée et il peut y avoir une foultitude de paquets. mais l’aspect modulaire est conservé et cela a l’avantage qu’un module ne supposera pas des fonctionnalités particulières en dehors de son cadre, comme Gnome3 qui exigerait donc systemd.
C’est un débat récurrent, la volonté d’avoir une machine homogène et cohérente a favorisé les environnement de bureau (KDE, Gnome) mais ce qui se produit désormais était inévitable. J’espère que la logique conduira à ne plus privilégier cette idée d’environnement homogène et à pousser les systèmes modulaires, en espérant que ceux ci (tel XFCE) ne vont pas devenir eux même des Gnome-bis.
Pas sûr d’avoir été clair mais bon…
Y’a t’il une raison valable (autre que le fait que ça arrangerait Canonical 
) à choisir upstart plutôt que systemd?
Puisque Canonical désire de plus en plus faire cavalier seul, qu’ils se démerdent avec leur système d’init 
Parce que systemd ne tourne pas avec d’autres noyaux que linux ce qui est pour moi une raison suffisante pour ne pas le prendre. upstart tourne avec tout je crois. Je pense qu’upstart sera privilégié, ce serait la logique. (Que reproche-t-on à sysvint?).
il était même question que gnome 4 devienne un propre OS
Une distribution à lui tout seul oui, un OS non.
BelZéButh, les liens que tu as donnés sont tronqués
tu peux les retrouver sur debian-facile (le premier lien)
C’est une raison valable, c’est vrai que j’avais oublié que Debian ne tourne pas qu’avec le noyau Linux…
Ceci étant, les versions de Debian ne tournant pas sur noyau Linux, ne sont pour moi, qu’anecdotiques
C’est aussi la question que je me pose. Avec le passage à insserv, le bon vieux sysvinit fonctionne très bien maintenant y compris pour lancer les services en parallèle. Je ne connais pas les problématiques spécifiques que Gnome rencontre pour demander absolument la présence de systemd mais je soupçonne fortement que c’est un cas de “sinon on est pas à la mode”.
Je crois que c’est dans la gestion des sessions et l’interface avec la procédure de login. systemd définit un démon logind gérant les sessions de ce que j’ai compris, et gnome ne saurait dialoguer qu’avec ce démon.
C’est une raison valable, c’est vrai que j’avais oublié que Debian ne tourne pas qu’avec le noyau Linux…
Ceci étant, les versions de Debian ne tournant pas sur noyau Linux, ne sont pour moi, qu’anecdotiques [/quote]
Parles pour toi voyou, j’attend avec impatience que la KfreeBSd s’améliore pour quitter complètement et pouvoir migrer mes dernières machines critiques vers autres choses que du kernel made in ‘Linux’
Et ce même si j’ai un sérieux doute sur le portage des outils qui me manquent sous BSD
En plus les portage concernés ne sont pas quel e portage du kenrel BSD et Hurd.
Je crois que c’est dans la gestion des sessions et l’interface avec la procédure de login. systemd définit un démon logind gérant les sessions de ce que j’ai compris, et gnome ne saurait dialoguer qu’avec ce démon.[/quote]
Il me semblais aussi que la raison principale de se glissement vers systemd était en partie due à ça.
Je me le demande aussi sysvinit marche très bien, upstart proposerai des patch (pas terrible apparemment) mais la dernière version serait encourageante.
Ce que je craint c’est que dans la course à proposer une solution viable pour remplacer les OS proprio avec un userland correct et un système unifié ou finisse par tomber dans le mêm travers que ces mêmes OS proprio.
[quote=“fran.b”]Le problème n’est pas tant Gnome3+systemd vs le reste (problème réel et à résoudre c’est sûr) plutôt que la logique même d’un environnement complet (comme KDE, Gnome et peut être bientôt XFCE)par rapport à une machine modulaire.
Il y a deux logiques qu’on pourrait appeler logique Gnome et logique fluxbox:
Logique Gnome: On fournit un environnement de bureau qui traite tous les problèmes que peut rencontrer un utilisateur sur sa machine: on y trouve donc les classqiues bureaux, barre de tache, etc mais aussi le gestionnaire de réseaux, d’imprimantes, d’agendas, et même de paquets. C’est à voir comme une gigantesque couche incontournable. Une éventuelle modularité s’estompe vite devant les interdépendances des modules entre eux. Par ailleurs, il est évident que cette énorme surcouche va figer ce qu’il y a en dessous: démarrage, gestion du réseau, des imprimante, etc en accaparant de plus en plus des taches systèmes de plus bas niveau. C’est ce qu’il se passe avec Gnome qui par exemple demandait la neutralisation de la gestion par script des interfaces et qui désormais veut figer le démarrage d’une session.
Disons le cela conduit à un environnement tout en un type Windows avec à la longue ses inconvénients, notamment une énorme complexité et la quasi impossibilité de comprendre un éventuel dysfonctionnement.
Logique fluxbox: (ou Windowmaker, XFCE, etc) On fournit un gestionnaire de fenêtres, un gestionnaire de sessions, un bureau, un logiciel de gestion de barres de taches, etc bref autant de modules dédiés à des taches précises que l’on peut mélanger ou utiliser seul. Cela complique les choses (l’autonomie d’un module finit par limiter ses possibilités et entrainer un empiétement des rôles), rend la configuration d’une machine plus compliquée et il peut y avoir une foultitude de paquets. mais l’aspect modulaire est conservé et cela a l’avantage qu’un module ne supposera pas des fonctionnalités particulières en dehors de son cadre, comme Gnome3 qui exigerait donc systemd.
C’est un débat récurrent, la volonté d’avoir une machine homogène et cohérente a favorisé les environnement de bureau (KDE, Gnome) mais ce qui se produit désormais était inévitable. J’espère que la logique conduira à ne plus privilégier cette idée d’environnement homogène et à pousser les systèmes modulaires, en espérant que ceux ci (tel XFCE) ne vont pas devenir eux même des Gnome-bis.
Pas sûr d’avoir été clair mais bon…[/quote]
Et voilà un résumé de ce que je redoute en fait 
Non. Il ne pose pas autant de problème que systemd, mais upstart n’est pas portable.
sysvinit pose un tas de problème :
[ul]
[li]utilisation de scripts très redondants entre eux et absolument pas portable[/li]
[li]difficile à debugger, si l’ordre de lancement des services n’est pas correct, tu dois te palucher un script pour essayer de générer un graphe de dépendance des services[/li]
[li]les évènements/intéractions sont simples mais limité : par exemple si tu veux lancer des services uniquement quand la machine a du réseau, soit tu gère ton réseau via une /etc/network/interfaces, là pas de problème, soit tu utilise un truc à network-manager et là la terminaison du processus lancé par l’init n’indique absolument pas qu’il y a du réseau, donc tu va lancer des services comme des montages réseau dans le vent[/li]
[li]manque de fiabilité : si un démon fait un double fork(), il passe sans problème outre le système d’init, ce dernier n’est plus en mesure de savoir à quel service il appartiens et ça va être au script d’init de retrouver tous les processus qui ont cette tête pour les tuer.[/li]
[li]sysvinit n’est plus en mesure de gérer les services d’une machine depuis longtemps, il est couplé à udev principalement. Si on branche un périphérique bluetooth c’est udev qui lance directement /lib/udev/bluez-udev. C’est un deamon qui n’est plus pris en charge par l’init sauf si l’on souhaite qu’il soit toujours lancé.[/li]
[li]insserv est limité, il permet que la création de dépendance forte. On peut imaginer un service (A) qui ne dépend pas toujours d’un autre (B) que cette dépendance ne se fait que dans certains cas ou que le service A n’a pas besoin d’attendre que B ai totalement fini sa tâche pour être lancé (cas d’une dépendance vers le système de fichier et où l’un des points de montage est bloqué par un fsck ou est simplement lent (peut être parce qu’il dépend du réseau mais que ce dernier n’est pas encore initialisé totalement ?)[/li][/ul]
La liste n’est probablement pas exhaustive il y a par exemple le fais que l’on est incapable de loguer ce qui se passe au tout début du démarrage, mais je pense que c’est déjà quelques points intéressants/importants. Imaginez tout de même qu’on ne verrait pas apparaître OpenRC, systemd, upstart, initng, runint, SMF (Solaris) et launchd (OSX) s’il n’y avait pas réellement quelque chose à redire à sysvinit.
Au passage vu les gens intelligents qui sont entrain de se fritter depuis 4 mois sur le sujet, je pense que le problème est un peu plus compliqué qu’une histoire de mode.
Non, tu parle probablement de GnomeOS ce n’est pas du tout ce dont il s’agissait. Gnome OS est juste une plateforme de développement. Rien de plus.
C’est à peu prêt ce que disait Lennart Poettering, ce sont des OS jouets qui sont entrain de freiner des évolutions (on se base sur le plus petit commun dénominateur au lieux d’utiliser les particularité de chacun).
Je crois que c’est dans la gestion des sessions et l’interface avec la procédure de login. systemd définit un démon logind gérant les sessions de ce que j’ai compris, et gnome ne saurait dialoguer qu’avec ce démon.[/quote]
C’est ça. logind est un remplaçant de policykit (entre autre chose).
Moi ce que je crains c’est que par peur du changement, on hésite à innover. Je trouve que repenser la problématique de démarrage d’une machine pour prendre en compte les usages actuels (machine dans un environnement qui évolue (avec ou sans réseau, sur batterie ou sur secteur,…) et machine qui évolue (ajout ou retrait de périphériques à chaud)) est une opportunité.
La question de savoir s’il faut utiliser au maximum les possibilités de l’OS que l’on utilise ou plutôt se contenter d’un sous-ensemble commun avec d’autres OS n’est pas aussi simple que l’on ne crois (« À quoi sert d’avoir un noyau très sophistiqué avec des cgroup ou des jails si c’est pour ne pas s’appuyer dessus ? » au contraire c’est une segmentation du marché que de se rendre incompatible avec les autres OS).
Avec tout ça je n’ai pas encore donné mon avis moi. Personnellement je m’en fou, comme dans énormément de cas, je sais que les développeurs Debian vont faire des choix tout à fais mesuré et la polémique actuelle est là pour ça. Passer à systemd, upstart ou autre ça ne me changera pas grand chose, je les ai déjà utilisé (sauf SMF et launchd) et pour mon usage basique ils sont aussi simples les uns que les autres.