Je n’y comprend pas grand chose a cette histoire mais je m’étonne que Gnome exige l’adoption de systemd si celui-ci ne permet pas le port pérenne du hurd. Car si on revient à la source des choses, Gnome est l’environnement de bureau du projet GNU et GNU Hurd / Mach son noyau.
[quote=“MisterFreez”][quote=“misaine”]
il était même question que gnome 4 devienne un propre OS[/quote]
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[/quote]
Si cela est mis à disposition du public et signifie une rolling-release avec les toutes dernières avancées de Gnome, ca me conviendra (a condition bien sur que ça ne passe pas son temps à pisser de l’huile avec le moteur par terre)
[quote=“MisterFreez”]
Avec tout ça je n’ai pas encore donné mon avis moi. [/quote]
je ne sais pas si tu t’en fou mais la connaissance que tu en as et que tu partages est un bien précieux pour nous tous.
merci encore
Effectivement je ne voyais pas ça sous cet angle. Toutes les machines que j’utilise sont dans un environnement assez statique, et ça ne m’a jamais choqué qu’udev ou nm prennent le relais pour le peu qui bouge.
En fait, si je comprends bien ce que tu dis, le but des nouveaux systèmes d’init est de fournir une sorte d’udev généralisé, d’homogénéiser la gestion des services et des périphériques ?
[quote=“MisterFreez”]
[]utilisation de scripts très redondants entre eux et absolument pas portable[/quote]C’est en bash, plus portable y’a pas, c’est standard sur tous les unix? C’est justement sa qualité d’être valable pour les BSD, Unix, linux, Hurd, etc[quote]
[]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[/quote]Vu que le but est de gérer le lancement en parallèle, l’ordre n’a pas d’importance ou pour être plus précis, il est impératif de mettre une hiérarchie sur les services à lancer, je doute que les autres systèmes échappent à ça. D’ailleurs sur ce point upstart et sysvinit semble avoir le même mécanisme.[quote]
[]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[/quote]Là par contre je ne peux pas dire, si un réseau se met en route plus tard, on n’est plus dans le cadre du démrarrage, sinon le script de lancement se lance après le script de démarrage du réseau et teste la présence d’une connexion (ce qui doit être fait de toute façon si on est sérieux, il est vrai que là ça devient indispensable)[quote]
[]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.[/quote]Je ne connais pas assez pour faire un commentaire[quote]
[]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é.[/quote]En quoi c’est gênant? sysvint est chargé de lancer les démons ou les services au démarrage de la machine, ensuite qu’un démon prenne la relève pour les services liés à un périphérique amovible n’est pas gênant. C’est une tache distincte[quote]
[]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 ?)
[/quote]Oui, mais visiblement c’est un pbm compliqué, upstart par exemple reste sur cette dépendance forte.
C’est sûr mais cela peut être aussi juste essentiellement une question de rivalité entre les poids lourds RedHat(=systemd) et Ubuntu(=upstart) qui de ce que j’ai vu alimente beaucoup le débat. Honnetement, du peu que je connais, je ne suis pas tellement convaincu. Les gains (réels) des deux systèmes proposés et les insuffisances (réelles) de sysvinit ne me paraissent pas justifier l’abandon des deux principes essentiels consistant à être valable sur tout système type Unix et à ne pas limiter les logiciels et environnement installables par un choix de démarrage. Tout ce que tu viens d’énoncer comme défaut ne dépend ni du noyau ni du choix de l’environnement. Donc si systemd impose linux, alors systemd est un mauvais choix. Qu’il soit une option, pourquoi pas. Qu’il soit exigé pour Gnome, admettons mais ça devient pour moi une raison d’abandonner gnome qui deviendrait spécifique à certaines plateformes et à linux, mais qu’il soit installé par défaut dans Debian me choquerait beaucoup à cause de ces remarques.
[quote=“fran.b”][quote=“MisterFreez”][ul]
[li]utilisation de scripts très redondants entre eux et absolument pas portable[/li][/ul][/quote]C’est en bash, plus portable y’a pas, c’est standard sur tous les unix? C’est justement sa qualité d’être valable pour les BSD, Unix, linux, Hurd, etc[/quote]
C’est du bourne shell, c’est ce qui se fait de plus portable (sur unix), mais ça n’est pas le langage qui rend la chose portable ou pas. Sous Debian on a le packet lsb-base qui fournis une API pour gérer les processus, on est déjà moins portable d’un coup. Ces fonctions en bourne shell ne font pas tout. Debian utilise pas mal les fichiers dans /etc/default pour paramétrer les scripts d’init, je ne sais pas si c’est un standard lsb (je crois pas c’est assez récent il me semble). Certains scripts n’utilisent pas du tout les fonctions lsb et sont donc potentiellement très dépendant de la distribution. Ces scripts sont tous créé par les distributions, évidement les dérivées de Debian ne réécrivent pas tout de même pour les dérivées de RedHat, mais si ça pouvait réellement être portable ce serait déjà fais upstream. Au passage les unix (et slackware) n’ont, à ma connaissance jamais utilisée sysvinit, ils utilisent rc.d qui est assez différent (pas de runlevel par exemple).
[quote=“fran.b”][quote=“MisterFreez”][ul]
[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][/ul][/quote]Vu que le but est de gérer le lancement en parallèle, l’ordre n’a pas d’importance ou pour être plus précis, il est impératif de mettre une hiérarchie sur les services à lancer, je doute que les autres systèmes échappent à ça. D’ailleurs sur ce point upstart et sysvinit semble avoir le même mécanisme.[/quote]
Je voulais éviter à tout prix de parler d’une alternative en particulier dans mon précédent message, mais systemd permet d’avoir un boot interactif, du log dès le tout début du démarrage et je crois qu’il a en standard un outil pour voir le graphe de dépendance de tes services.
[quote=“fran.b”][quote=“MisterFreez”][ul]
[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][/ul][/quote]Là par contre je ne peux pas dire, si un réseau se met en route plus tard, on n’est plus dans le cadre du démrarrage, sinon le script de lancement se lance après le script de démarrage du réseau et teste la présence d’une connexion (ce qui doit être fait de toute façon si on est sérieux, il est vrai que là ça devient indispensable)[/quote]
Ce n’est pas simplement faire un test de présence du réseau qu’il faut faire, mais du polling (toutes les quelques secondes revérifier si le réseau est présent ou pas) et faut le faire dans chaque service impacté. La solution que propose systemd n’est pas très belle, mais est efficace. nm est capable de dire à systemd si le réseau est présent donc systemd est capable de lancer des services au bon moment et de les arrêter assez tôt.
[quote=“fran.b”][quote=“MisterFreez”][ul]
[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][/ul][/quote]Je ne connais pas assez pour faire un commentaire[/quote]
C’est un problème que l’on rencontre assez peu si on reste dans le périmètre de la distribution, mais si on processus lancé par l’init, fork() une première fois puis une seconde et que le processus intermédiaire meurt le petit fils devient le fils direct init et ce dernier ne pourra pas corréler ce processus au service au quel il est rataché. upstart gère ça en recherchant les fork() lancé par ces processus fils, systemd encapsule chaque service dans un cgroup (ce qui permet en plus de contrôler les resources consommé par ce service).
[quote=“fran.b”][quote=“MisterFreez”][ul]
[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][/ul][/quote]En quoi c’est gênant? sysvint est chargé de lancer les démons ou les services au démarrage de la machine, ensuite qu’un démon prenne la relève pour les services liés à un périphérique amovible n’est pas gênant. C’est une tache distincte[/quote]
C’est intéressant avant c’était 2 choses qui étaient totalement fusionné, on lance les services au démarrage et on les arrêtes à l’extinction. sysvinit fais déjà plus que ça avec les runlevel. Il y en a déjà ici qui utilisent un runlevel particulier pour faire leur mise à jour, personnellement je m’en suis déjà servit pour distinguer un mode sur batterie d’un mode sur secteur pour un PC portable. Je pense que les sysvinit a était conçu pour gérer les deamon, c’est pour ça que l’on s’en sert aussi via les commandes service, invoke-rc.d ou directement en lançant des scripts de /etc/init.d.
[quote=“fran.b”][quote=“MisterFreez”][ul]
[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]
[/quote]Oui, mais visiblement c’est un pbm compliqué, upstart par exemple reste sur cette dépendance forte.[/quote]
En effet. systemd utilise massivement les possibilités du noyau linux pour faire ça, via les socket activation, autofs (je crois que c’est comme ça que ça s’appelle) et d’autre chose, il est capable de lancer un service uniquement quand on a commencé à s’en servir. Ça permet aussi de relancer un service sans perte de données (tout reste en buffer du coté du noyau).
C’est sûr mais cela peut être aussi juste essentiellement une question de rivalité entre les poids lourds RedHat(=systemd) et Ubuntu(=upstart) qui de ce que j’ai vu alimente beaucoup le débat. Honnetement, du peu que je connais, je ne suis pas tellement convaincu. Les gains (réels) des deux systèmes proposés et les insuffisances (réelles) de sysvinit ne me paraissent pas justifier l’abandon des deux principes essentiels consistant à être valable sur tout système type Unix[/quote]
Il faut bien comprendre que dans la réalité sysvinit n’est utilisé que sur linux et Debian. Une solution (que j’indique plus haut) serait d’améliorer metainit pour qu’il puisse créer des fichiers pour n’importe quel système d’init. Si on avait cet outil je pense que ce serait déjà bien plus calme, les mainteneurs sauraient quoi faire et les utilisateurs auraient le choix.
La question du couplage fort entre gnome et systemd est une autre histoire, on est d’accord que c’est mauvais, mais ça n’a pas d’incidence sur la qualité ou non d’un système d’init.
systemd n’a pas vraiment le choix, il n’existe rien de portable pour résoudre ces problèmes. Chaque noyau a (ou pas) une solution interne.
Moi non¹, parce qu’il y a déjà un paquet de trucs qui sont installés par défaut et qui sont spécifiques linux (udev, tous les *kit, tout ce qui touche à pulseaudio), ce qu’il faut c’est que ça ne soit pas un frein aux versions Hurd et kFreeBSD de Debian, pour ça une solution peut être d’utiliser metainit (oui je le martèle).
Grosso modo ils cherchent à gérer les processus, donc à être capables d’interpréter tous les types d’évènements susceptible de déclencher le démarrage d’un service et à le démarrer correctement. Tu sais upstart et systemd sont capable de remplacer cron.
[1] je ne dis pas que c’est bien ou c’est mal mais que c’est un choix.
[quote=“misaine”][quote=“MisterFreez”]
Avec tout ça je n’ai pas encore donné mon avis moi. [/quote]
je ne sais pas si tu t’en fou mais la connaissance que tu en as et que tu partages est un bien précieux pour nous tous.
merci encore [/quote]
Le sujet m’intéresse, mais le fait d’en utiliser un ou un autre me passe un peu au dessus.
Aucune idée, sysvinit a cependant été désinstallé (ça a gueulé parce qu’il est indiqué comme paquet essentiel) et il m’a fallu le mettre en hold dans le fichier preferences pour empêcher le dist-upgrade de le réinstaller.
Visiblement la raison essentielle est de faire des statistiques.
L’argument de tout faire rentrer sur un CD est quelque peu ridicule à l’heure du blu-ray.
[quote=“misaine”]c’était à craindre (c’est le gnomiste qui parle) xfce passe provisoirement comme desktop par défaut . anonscm.debian.org/gitweb/?p=tas … 237e01c9b5[/quote]
Comme le dis dannyleconte, il s’agit de voir si la popularité de gnome viens de son installation par défaut ou de sa popularité intrinsèque.
Par contre faire tout rentrer dans un CD ou un DVD ça a de l’importance, d’une part pour limiter la charge sur les serveurs, pour éviter aux utilisateurs de graver des BR qui sont encore coûteux et on voit que ce sont les petits CD qui ont la coté (les CD éventuellement les DVD). Les BR ne sont pas encore si démocratiser que ça.
Je suis tout a fait d’accord, là ou le pc de base a le graveur de CD voir de DVD il est bien mois évident de trouver le graveur de BR.
D’ailleurs si tu fait un petit sondage même ici tu verra que le BR ne représente qu’une toute petite partie.
En plus comme la mode est d’avoir des PC de plus en plus fin/petit, le lecteur CD/DVD/BR est souvent sacrifié
[quote=“MisterFreez”]
Par contre faire tout rentrer dans un CD ou un DVD ça a de l’importance, d’une part pour limiter la charge sur les serveurs, pour éviter aux utilisateurs de graver des BR qui sont encore coûteux et on voit que ce sont les petits CD qui ont la coté (les CD éventuellement les DVD). Les BR ne sont pas encore si démocratiser que ça.[/quote]
Ce que je voulais surtout dire par la c’est que le CD appartient au passé : il a été mis en circulation en 1982-84. Je n’ai pas moi-même de lecteur blu-ray, et c’est vrai qu’il n’est pas encore si démocratisé mais par contre le DVD lui est largement démocratisé.
Quand à l’emcombrement des serveurs…leur capacité augmente, les disques durs les clé USB augmentent de taille, les vitesses de transfert augmentent, la taille des OS augmentent…et il n’y aurait que Debian qui resterait accroché au CD ?
C’est un peu comme vouloir rester habiter dans un studio quand notre famille s’agrandit : des enfants, des meubles, de l’électroménager, des moyens financier qui augmentent…Ah mais non papa à dit qu’on resterait habiter la quoiqu’il arrive !
Quand tu cherche à envoyer un gros fichier à des milliers de personnes, gagner quelques % de taille c’est pouvoir supporter un débit plus important pour chacun, pouvoir faire d’autre chose avec le même serveur et/ou ne pas avoir à se payer un débit encore plus chère. Le discours marketing que tu balance c’est juste la fuite en avant que l’on présente au grand public. Quand tu es fasse aux problématiques des distributeurs, tu ne mégote pas sur les « petites » optimisations, parce que c’est petites optimisations ont une grand importance lorsque tu veux passer à l’échelle. C’est vrai pour tout, regarde les optimisations que Google met en place pour la page google.com, c’est une page simple en principe, mais ils ont optimisé tout ce qui est possible pour pouvoir fournir un maximum de gens avec moins de serveurs (et ce malgré que les capacités, les débits, les puissances de calcul explosent).
Si tu t’intéresse à HTTP2 (on est actuellement en 1.1), tu verra que l’une des grandes nouveautés sera que l’on réduit la taille des entêtes http. Ce qui est considéré comme négligeable par énormément de monde est l’un des points central de la prochaine version de l’un des protocoles les plus utilisé du monde. Tout ça parce que quand tu cherche de la performance, quand tu fait un (reverse) proxy HTTP, le décodage de ces entêtes coûte extrêmement chère en temps et donc en débit pour tes utilisateurs (ou augmenter le nombre d’utilisateurs pour un même proxy). Oui c’est un détail qui peut faire gagner 10 à 30 % de débit.
Debian passe sont temps à mettre en avant les solutions moins coûteuses en débit pour leur serveur (jigdo, bitorrent et les netinstal) ce n’est pas pour rien.
Très franchement ce que font d’autres distributions dans le domaine est tout à fait secondaire. Debian fourni et documente tout l’attirail pour créer un CD d’installation avec le bureau que tu souhaite, si le besoin est réelle il y aura des gens pour en créer un qui convient qui sera intégrer à Debian ensuite.
Pour en revenir au support de stockage : Le CD est bien en place et pas chère, le DVD est assez bien en place mais plus chère, le BR ne décollera sans doute jamais, il est arrivé au mauvais moment et sera AMHA dépassé par le dématérialisé avant qu’il ne se démocratise (il répond en sus à un besoin que les gens n’ont pas : stocker 25Gio sur un même disque). Pour installer un OS une clef usb c’est mieux (c’est réellement réinscriptible), mais on a toujours les problèmes des serveurs dont je parle au dessus.
Je dis non à toute forme d’image de ce type (que ce soit les familles dans les appart’, les voitures ou je ne sais quoi), c’est pas un parallèle (en fait ce n’est même pas un argument).
[quote=“MisterFreez”][quote=“misaine”]c’était à craindre (c’est le gnomiste qui parle) xfce passe provisoirement comme desktop par défaut . anonscm.debian.org/gitweb/?p=tas … 237e01c9b5[/quote]
Comme le dis dannyleconte, il s’agit de voir si la popularité de gnome viens de son installation par défaut ou de sa popularité intrinsèque.
Par contre faire tout rentrer dans un CD ou un DVD ça a de l’importance, d’une part pour limiter la charge sur les serveurs, pour éviter aux utilisateurs de graver des BR qui sont encore coûteux et on voit que ce sont les petits CD qui ont la coté (les CD éventuellement les DVD). Les BR ne sont pas encore si démocratiser que ça.[/quote]
Ça me choque pas l’agurment du CD. Par contre considérer que les alpha-testeurs représentent la base installée ça me paraît biaisé. En tout cas le choix de l’expérience n’a rien de scientifique et au final aucune représentativité
Tu as un trés bon argumentaire Misterfreez qui est trés percutant, trés technique et qui m’en apprend beaucoup sur cette problématique, mais franchement il n’y a pas d’autre avenir que de voir les distributions gnu/linux comme tout autres OS gagner des Mo (ce qui n’empêche pas qu’il ne faut pas les gaspiller pour autant…), et de voir le CD rejoindre la cassette audio, le vinyle, le mange-disque et le phonographe au fond du grenier.
Voir Debian appréhender ainsi “l’embonpoint” de Gnome n’est de mon point de vue que le début de la fin du support CD pour Debian plutôt que la fin de Gnome en tant que bureau par défaut.
Même si pour l’instant on n’en prendra pas le chemin, quand Debian aura fait ses stats et se sera rendu compte que Gnome est incontournable (c’est mon intime conviction) ils ne tardera plus à fournir le DVD d’install de Debian avec Gnome…et systemd (puisqu’il parait que ce dernier est l’avenir de Gnome) par défaut, sans plus se soucier du vieux CD.
À mon avis ils n’ont pas d’autres choix que ça. Ce sera un chiffre à prendre avec des pincettes, mais c’est le seul qu’ils peuvent produire.
@dannyleconte > Je n’en sais rien. Tu fais beaucoup de supputation personnellement, je m’en tamponne. Je pense que les gens qui télécharge les CD/DVD de Debian sont soit des irresponsables soit peu nombreux. Il faut arrêter de les utiliser et passer aux netinstall¹, toujours, tout le temps sauf quand vraiment on souhaite faire une installation off-line.
[1] Ce n’est pas ce que je fais personnellement, moi j’utilise une live-usb pour faire des installations encore plus réduites via debootstrap.
[quote=“Clochette”]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.[/quote]
Oui et derrière il y a aussi d’autres soucis, avec upstart notamment …
Ça ne me plairai pas trop de voir débarquer des morceaux de licence ubuntu-canonical dans ma debian pour la booter.
On l’a encore bien entendu vers la fin de la conférence sur upstart :
Je ne pense pas que Debian va pencher de ce coté la, il y a trop de divergence.
