Comme vous le savez peut-être, le projet Debian s'interroge actuellement sur ce que doit être son système d'init par défaut (sysvrc, openrc, upstart, systemd).
Après de longs mois d'étude, le comité technique semble sur le point de rendre son avis. Une proposition de vote convenant à la plupart des membres a été rédigée, et les votes à son sujet devraient avoir lieu d'ici la fin de la semaine prochaine.
Pour les non-anglophones, voici une traduction de la résolution:
Nous avons pu rédiger collaborativement une résolution via IRC. En voici le résultat.
DT systemd sera l'init par défaut dans jessie, il est permis de dépendre d'un init particulier
DL systemd sera l'init par défaut dans jessie, il est interdit de dépendre d'un init particulierUT upstart sera l'init par défaut dans jessie, il est permis de dépendre d'un init particulier
UL upstart sera l'init par défaut dans jessie, il est interdit de dépendre d'un init particulierOT openrc sera l'init par défaut dans jessie, il est permis de dépendre d'un init particulier
OL openrc sera l'init par défaut dans jessie, il est interdit de dépendre d'un init particulierVT sysvrc sera l'init par défaut dans jessie, il est permis de dépendre d'un init particulier
VL sysvrc sera l'init par défaut dans jessie, il est interdit de dépendre d'un init particulierGR le projet décidera par une résolution générale
FD la discussion doit se poursuivre
Chacune de ces propositions correspond à une ou plusieurs sections de la résolution ci-dessous (dont on peut trouver le texte dans le git du comité, sous 727708_initsystem/draft-resolution.txt)
Nous nous sommes mis d'accord pour appeler à voter lundi soir, à moins q'un membre du comité ne s'y oppose. Nous commencerons à voter plus tôt si tout le monde approuve cette formulation.
Ian, Bdale, Andy, Don et Russ ont tous approuvé cette formulation via IRC. Steve, Colin et Keith, faites nous savoir votre avis, nous pourrons ainsi peut-être commencer le vote plus tôt.
Merci,
Ian== version D (systemd) ==
Le système d'init par défaut dans jessie sous linux sera systemd
== version U (upstart) ==
Le système d'init par défaut dans jessie sous linux sera upstart
== version O (openrc) ==
Le système d'init par défaut dans jessie sous linux sera openrc
== version V (sysvinit) ==
Le système d'init par défaut dans jessie sous linux sera sysvinit
== version GR (résolution générale) ==
Le comité technique décide que la question du système d'init par défaut sera résolue via une résolution générale
== annexe sur les dépendances version T (couplage fort) ==
Cette décision se limite à la sélection du système d'init par défaut, nous continuons à accueilir les contributions visant à supporter d'autres systèmes d'init.
Il est permis que des logiciels dépendent d'un init spécifique en pid 1.
Cependant, lorsque possible, les logiciels devraient supporter tous les systèmes d'init, les mainteneurs sont encouragés à accepter des patchs raisonnables pour permettre l'interopérabilité, même si celà résulte en une réduction de fonctionnalités sous le sytème d'init pour lequel le patch a été proposé.== annexe sur les dépendances version L (couplage faible) ==
Cette décision se limite à la sélection du système d'init par défaut, nous continuons à accueilir les contributions visant à supporter d'autres systèmes d'init.
Il n'est pas permis que des logiciels dépendent d'un init spécifique en pid 1.
Les mainteneurs sont encouragés à accepter des patchs raisonnables pour permettre l'interopérabilité entre les sytèmes d'init.== annexe pour toutes les versions sauf GR ==
Cette décision est automatiquement annulée par une résolution générale contraire rassemblant une majorité simple. Le cas échéant, la résolution générale remplace cette résolution.
# Pari
Posté par MTux . Évalué à 6.
Qui prend les paris ?
[^] # Re: Pari
Posté par TuxMips . Évalué à 1.
Pas moi
:-D
[^] # Re: Pari
Posté par Laurent Cligny (site web personnel) . Évalué à 9.
Moi je vote et je dis qu'il bluffe !
[^] # Re: Pari
Posté par martoni (site web personnel, Mastodon) . Évalué à 5.
attention sinon pan pastèque.
J'ai plus qu'une balle
[^] # Re: Pari
Posté par jnoel . Évalué à 3.
il dit qu'il voit pas le rapport…
[^] # Re: Pari
Posté par Misc (site web personnel) . Évalué à 4.
Il dit qu'il a plus de genoux
[^] # Re: Pari
Posté par barmic . Évalué à 5.
OL :)
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Pari
Posté par cosmocat . Évalué à 4.
Vu comment c'est parti, ça va plutôt finir en FD tout çà!
[^] # Re: Pari
Posté par barmic . Évalué à 2.
Tant que ce n'est pas une
?Lça me va :)Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Pari
Posté par claudex . Évalué à 4.
Pourquoi, j'aurais plutôt dit l'inverse.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Pari
Posté par barmic . Évalué à 3.
Tu as raison j'ai inversé les lignes…
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Pari
Posté par Sylvain Berfini (site web personnel) . Évalué à 3.
OL également ! (et je parle pas de foot)
[^] # Re: Pari
Posté par barmic . Évalué à 1.
C'était ironique… C'est à mon avis improbable qu'ils choisissent cette option, elle est fonctionnellement faible et n'apporte pas grand chose face à l'existant. Ce serait beaucoup de bruit pour presque rien. Vu le débat il n'y a pas grand monde pour défendre OpenRC (c'est un peu le truc qui est re sortie pour avoir quelque chose à répondre aux fan de systemd/upstart).
AMHA il est important de choisir une option qui ne soit pas
?L, mais de la part de Debian ça m'étonnerait. Pour le reste c'est pas très gênant. Ils vont choisir DT, UT ou GR et ce sera bien. Ça permettra au packagers de commencer le boulot pour Jessie.Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Pari
Posté par barmic . Évalué à 3.
En l'occurrence si, j'ai pas relu la constitution Debian, mais je parle des membres du ctte, ceux qui vont voter.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Pari
Posté par Shuba . Évalué à 4.
Je parie sur DT, ça m'a l'air de correspondre aux positions de Russ Albery, Bdale Garbee, Keith Packard et (dans une moindre mesure) Don Armstrong.
Vu que Bdale a un vote supplémentaire en cas d'égalité, ça peut faire pencher la balance.
[^] # Re: Pari
Posté par Spyhawk . Évalué à 2. Dernière modification le 31 janvier 2014 à 13:13.
Bah non, puisque l'égalité a déjà été atteinte lors du précédent-précédent vote (4.5 vs 4 avec le vote de Bdale, le vote suivant a été écourté), et il semble qu'il ne veuille pas forcer une décision controversée.
Ca finira en FD ou GR pour sûr.
[^] # Re: Pari
Posté par deleted_user . Évalué à -4.
UT, vu que c'est le cttt qui vote et qu'ils sont employés canonical, et que j'espère pour eux qu'ils aiment les softs canonical, il me semble naturels qu'ils poussent ce sur quoi ils travaillent, donc ce sera upstart.
J'ai déjà commencé à migrer ailleurs, gentoo/arch on verra bien ;)
[^] # Re: Pari
Posté par Maclag . Évalué à 6.
Je parie sur DL.
Et je dis ce que je veux, on est vendredi!
# dépendance à un système d'init
Posté par bobo38 . Évalué à 1.
Il y a eu pas mal de trolls autour du fait que GNOME serait à terme dépendant de systemd.
Quelle est la conséquence de ce passage de l'annexe sur les dépendances ?
« Il n'est pas permis que des logiciels dépendent d'un init spécifique en pid 1. »
[^] # Re: dépendance à un système d'init
Posté par barmic . Évalué à 4.
Ce sera considéré comme un bug et :
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: dépendance à un système d'init
Posté par zebra3 . Évalué à 10.
GNOME n'est pas dépendant à systemd. Il est dépendant d'une API dbus qui pour l'instant n'est fournie que par systemd, aux systèmes concurrents de l'implémenter.
Au passage, si je me souviens bien il s'agit de features non essentielles comme le réglage de l'hostname. Ça n'empêche pas le bureau d'être utilisable.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: dépendance à un système d'init
Posté par barmic . Évalué à 0.
C'est un peu comme si tu disais que KDE n'est pas dépendant de Qt mais d'une API fournie uniquement par Qt…
On sait tous que c'est Gnome et GDM qui sont directement en ligne de mire là dessus notamment à cause d'un potentiel (je sais pas si ça a était fait finalement) couplage fort entre systemd, logind et gdm. La crainte que Gnome se dirige vers une dépendance forte avec logind/systemd n'est pas sans raison.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: dépendance à un système d'init
Posté par xcomcmdr . Évalué à 10. Dernière modification le 31 janvier 2014 à 14:10.
Tu confonds API et "API DBUS".
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: dépendance à un système d'init
Posté par gnumdk (site web personnel) . Évalué à 10. Dernière modification le 31 janvier 2014 à 14:55.
Je te propose de regarder comment fait ubuntu pour fournir les API DBUS en question alors qu'ils utilisent upstart…
Donc, c'est juste du gros troll cette partie… Les services fournis par systemd ne dépendent pas de systemd (le PID 1)
[^] # Re: dépendance à un système d'init
Posté par Atem18 (site web personnel) . Évalué à 2.
On est Vendredi, la raison, je te l'a donne, elle est cadeau : "De toute façon, Gnome/Gtk+/SystemD/PulseAudio, c'est la tambouille de Red Hat".
Comment ? Ubuntu fait la même chose avec son Upstart/LightDM/Unity/Mir ? Ouais mais pas toujours les mêmes aussi.
[^] # Re: dépendance à un système d'init
Posté par Guillaume T . Évalué à 5.
Au passage, si je me souviens bien il s'agit de features non essentielles comme le réglage de l'hostname. Ça n'empêche pas le bureau d'être utilisable.
Pas uniquement : la gestion d'énergie dans gnome est aussi dépendante d'une API dbus dépendante elle même de systemd, ce qui peut être considéré comme une feature essentielle
Après, il y a toujours moyen de contourner le problème en bricolant un peu le JS de gnome-shell
[^] # Re: dépendance à un système d'init
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 1.
Non, même les infos d'énergie ? Bordel, mais ça marchait très bien sans systemd avant, ça…
[^] # Re: dépendance à un système d'init
Posté par Renault (site web personnel) . Évalué à 10. Dernière modification le 31 janvier 2014 à 16:57.
Répétons, GNOME n'a pas besoin de systemd mais d'une implémentation de l'API de DBus que notamment systemd propose mais que tout autre programme pourrait fournir.
C'est tout l'intérêt d'une API que d'être utilisé par d'autre programme, rappelons qu'en soit POSIX est une API et personne ne semble être offusqué que GNU ou *BSD fournissent ces implémentations sans concurrent sur un système donné.
Oui il peut y avoir des intérêt pour la gestion d'énergie qui nécessite pas mal d'informations pour être optimums (réglage sur le matériels ou certains logiciels) en réponse à des évènements que seul certains programmes ont l'information directement.
EDIT : je pense qu'il faut arrêter de critiquer tout uniquement parce qu'il y a le mot systemd dans la phrase. Oui avant on savait faire des trucs avant qu'aujourd'hui on ne fait plus forcément, mais c'est pareil pour tout. Il y a une époque sous Linux il fallait monter sa clé USB à la main, c'était cool cette époque. Aujourd’hui on a besoin de HAL ou de udev dans son système… C'est à peu près pareil pour tout, pour plus de conforts et d'efficacité certains composants sont apparus avec son lot de dépendance par la suite.
[^] # Re: dépendance à un système d'init
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à -2. Dernière modification le 31 janvier 2014 à 17:12.
Et dépendait autrefois d'une autre API, celle d'UPower, qui ne dépendait pas du tout de systemd et marchait très bien. Donc on a bien ici une modification volontaire d'un truc qui marchait déjà, qui introduit une dépendance à un truc nouveau qui n'est fourni que par systemd.
[^] # Re: dépendance à un système d'init
Posté par Renault (site web personnel) . Évalué à 10.
Et tu ne te demandes pas pourquoi ils ont changé d'API ?
Peut être qu'il lui manquait des possibilités, pas assez performant ou non maintenu. Bref, ils ont changé d'API et alors ? On a bien remplacé HAL qui était aussi une couche d'abstraction mais abandonnée pour diverses raisons aujourd'hui au profit d'autres solutions. Ce n'est pas un phénomène nouveau et c'est même sain.
Si un autre logiciel fournit cet API, GNOME ne dépendra plus de systemd mais il faut le faire (et personne ne semble particulièrement motivé pour faire cette tâche). C'est comme ça pour tout API.
Avant on avait une distribution GNU/Linux presque nue, aujourd'hui il y a XFree86 qui est devenu X.org et qui deviendra Wayland, udev, dbus, HAL, les ConsoleKit/PolicyKit, on est passé de OSS à ALSA puis PulseAudio, la couche graphique s'est bien complexité avec des ajouts comme KMS, drm, GLX, OpenGL avec un mic-mac d'implémentations comme Mesa ou Gallium 3D.
Bref des couches comme ça qui ont bougé ou sont en mouvement il y a des tas. Je trouve très malhonnête de ne se focaliser dans ce cadre la critique qu'envers les changements de système d'init avec systemd en tête.
Les dépendances d'une distribution se complexifient avec le temps et c'est normal, systemd est loin d'être le seul cas existant et honnêtement ce n'est pas la partie à mon goût la plus problématique.
[^] # Re: dépendance à un système d'init
Posté par Thomas Debesse (site web personnel) . Évalué à 0.
Clair ! J'ai eu plus de problème à faire tourner Gnome sur des carte graphiques dont le pilote n’implémentait pas bien certaines dépendances fonctionnelles qu’à faire tourner Gnome sur du pulseaudio.
Typiquelent avec de vieilles Intel. Dernièrement j’ai eu un bug très bizarre, si je configurai XDM au boot, l'affichage fonctionnait bien et je pouvais lancer un environnament à l'ancienne genre metacity + nautilus + gnome-panel.
Si je configurai GDM au boot, l'affichage était noir. Si je lançais GDM à la main (
service gdm startou équivalent), j'avais l'affichage mais je ne pouvais pas ouvrir ma session Gnome, je pouvais ouvrir une session à l'ancienne genre LXDE, mais pas Gnome : si je me connectais avec la session Gnome sélectionnée, GDM faisait disparaitre l’écran de connexion pour switcher vers la session, mais n’aboutissait jamais, au passage l'affichage était foiré, je ne voyais plus que le fond d’écran, mais si je cliquais dans des endroits stratégiques, je voyais se dérouler des menus (comme le son en haut à droite) et c’était pas le menu de Gnome, mais de GDM !Et si je lançais Gnome à la main avec un X11 sans GDM, j'avais un bug similaire que décrit après connexion dans le GDM : Gnome Shell se lançait bien, mais l'affichage était foireux, certains éléments n’apparaissant qu’au clic.
En mode "fallback", la session marchait très bien SAUF que je ne pouvais pas me connecter depuis GDM vers Gnome, fallaback ou pas.
C’était une Ubuntu 13.10, je l’ai remplacé par une Debian Wheezy avec un pilote un peu plus ancien et un Gnome un peu plus ancien, et tout marchait très bien…
Dans aucun des cas je n’avais systemd, mais y a donc parfois de gros problème où un bug dans un pilote graphique va entrainer quelque part un lock dans un service quelconque qui va bloquer… l'identification ! Incroyable complexité.
Dbus c’est cool, mais on devient très dépendant d’une foultitude de services et parfois ça foire. Aujourd’hui Dbus est aussi critique que le noyau, si on a un bug dbus plus rien ne fonctionne, ni le son, ni le réseau, ni l’identification, et si une api dbus se vautre à cause d’un problème sous-jacent ça peut être tout aussi gênant.
Un pulseaudio qui ne marche pas pour une raison X ou Y est très difficile à contourner. Si PulseAudio ne marche, pas vaut mieux être admin pour trouver une solution de secours.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: dépendance à un système d'init
Posté par freem . Évalué à 4.
DBus est peut-être critique pour toi, mais pas pour tout le monde.
Il offre certainement un grand confort, notament de permettre de configurer son réseau via une zolie IHM sans devoir devenir root, mais, ça ne signifie pas que ce ne soit pas faisable.
Et, même si je conçois très bien que mon cas personnel n'est pas représentatif d'une quelconque majorité, je peux te dire que jusqu'a présent, mes machines sur lesquelles dbus est installé, mais pas démarré ( dépendance dure de quelques logiciels et flemme de faire un paquet bidon… ) il ne me manque aucune fonctionnalité.
Pour le réseau, par exemple, j'édite tout bêtement /etc/network/interfaces à la main ( et pour les desktop, ça veut dire le faire 1 fois par installation, puisqu'au final la plupart des gens à un dhcp sur le LAN… ) . Pour le gestionnaire de session… j'avoue, je n'en utilise pas, je me log avec login, et un script lance startx si je suis en tty1.
Largement suffisant pour mes besoins, en somme.
Pulseaudio? Je crois que j'ai 1 ou 2 paquets avec pulse dans le nom d'installés ( mpd, de mémoire ), mais ce qui est certain, c'est que je n'ai aucun daemon PA qui tourne.
Donc, non, dbus est loin d'être aussi critique que le kernel. Pas même aussi incontournable que Xorg. D'ailleurs, à l'heure actuelle, il n'y a bien que linux et Xorg, que je considère comme des outils vitaux. Tous les autres ont des alternatives plus que viables. Et Xorg sera remplacé par wayland, un de ces 4. A voir pour linux également, il faudrait que je teste debian kfreebsd.
[^] # Re: dépendance à un système d'init
Posté par Thomas Debesse (site web personnel) . Évalué à 6.
Je suis bien d’accord, comme le fait qu’au boulot, aucune machine n’utilise Network-Manager ni PulseAudio, et ça fonctionne très bien.
Le problème c’est que pour l’expérience citée, ce n’était pas critique pour moi mais pour un autre. La machine n’était pas la mienne, et je ne pouvais pas la laisser avec la solution
startxpour le lancement du bureau, ce même bureau à base de.xinitrc, demetacityet degnome-panellancé à la main, tout comme je n’aurai pas pu laisser une telle machine avec une configuration façon le très efficace/etc/network/interfaceàla Debian.On peut faire sans dbus, sans gdm, sans gnome, sans network-manager, sans pulseaudio… Mais quand tu installes un bureau grand public à un tiers, tu auras du mal à lui laisser autre chose dans les mains, en lui mettant dans les mains non seulement la machine, mais aussi le système d’exploitation et son autonomie à l’administrer à la cliquouille.
Bref, pour avoir un gdm+gnome+pulseaudio+network-manager parce que c’était le besoin, un bug du pilote intel d’Ubuntu foirait tout : si le néophyte ne peut pas passer l’étape d’ouverture de session de gdm, il ne peut rien faire. Les « pour toi pas pour tout le monde » n’ont aucun sens ici, et les « je t’apprend comment vivre avec » non plus : ce n’est pas pour moi que c’est critique, et ce n’est pas moi qui doit vivre avec.
Donc oui, on peut faire énormément de choses sans dbus, tout comme je m’en passe très souvent et que je me passe également des network-manager et de pulseaudio. Mais c’est un fait : dbus est aussi critique que le noyau dans une distribution bureautique grand public à la Ubuntu. Sans dbus, t’es même pas sûr que le gestionnaire de connexion se lance.
Il y a là des dépendances qui ne sont pas techniques. Par exemple si le serveur de connexion ne se lance pas parce que dbus ne se lance pas, X11 ne sera pas lancé même si X11 n’a pas besoin de dbus et qu’il peut être lancé manuellement. Dans mon exemple du post précédent, le fait que gdm ne lançait pas gnome après identification n’était peut-être même pas du à une dépendance technique, qui sait ?
NB : tout comme il est sain d’accorder le bénéfice du doute à celui que l’on ne comprend pas afin de ne pas partir du principe que celui que l’on ne comprend pas est bête mais qu’on ne l’a tout simplement pas compris, il est sain de ne pas partir du principe que celui qui relate un problème est celui qui doit vivre avec ce problème, ou bien les réponses apportées seront inadaptées.
Ici je relatais un problème qui affecterai quelqu’un d’autre que moi à la livraison, je ne pouvais donc pas installer un contournement. C’est pas la peine de m’enseigner ce que je fais tous les jour quand il m’est possible de le faire. Ça n’apporte aucune solution.
Celui qui réalise n’est pas forcément celui qui va utiliser. En oubliant ce point crucial, on apporte des solutions qui n’en sont pas.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: dépendance à un système d'init
Posté par fmaz fmaz . Évalué à 8.
Je suis sûr que sur tes machines, ta pile réseau utilise le protocole ARP. Pourtant, c'est complètement inutile, en plus, ça fait des requêtes en plus sur le réseau, du code qui tourne sur ta machine alors qu'un bête fichier /etc/networl/arp dans lequel tu mettrais toutes les correspondances IP - adresse MAC ferait parfaitement l'affaire.
Et puis, tu n'utilises pas vi mais ed parce que vi est complètement bloated.
Pour moi, un des intérêts de l'informatique est d'automatiser certaines tâches. L'informatique avance parce que les gens sont paresseux.
En ce qui me concerne, j'ai fondamentalement gardé les même besoins qu'en 1996. Je fais du mail, du LaTeX. J'écoute de la musique. Et je surf sur le web. Alors, c'est vrai que le web à changé. C'est donc normal que le navigateur aussi. Mais je pourrais en grande partie continuer à utiliser ma configuration de l'époque. Sauf que je ne veux pas. Certes ma configuration est beaucoup plus lourde. Mais ma machine est beaucoup plus puissante.
[^] # Re: dépendance à un système d'init
Posté par Zenitram (site web personnel) . Évalué à 8. Dernière modification le 31 janvier 2014 à 17:36.
Rien ne t'empèche de maintenir le bousin. Les mainteneur actuels n'étnt pas tes esclaves, ils ont la liberté de choisir le logiciel qui répond au mieux à leurs besoins.
A chaque changement de logiciel pour faire une fonction X, il y a des râleurs pour se plaindre que ça marchait avant, qui ne se posent jamais la question de pourquoi les developpeurs et mainteneurs veulent changer…
[^] # Re: dépendance à un système d'init
Posté par barmic . Évalué à 8. Dernière modification le 01 février 2014 à 00:49.
C'est un peu fumeux ce que tu dis. Il ne s'agit pas de l'« API DBus », mais d'une API faite sur dbus et qui est proposée par systemd. Si tu veux parler en terme de couche il est bon d'être un peu plus précis et oui c'est une API c'est un ensemble de fonctions, donc ça peut se réimplémenter (comme Qt même si ça choque certains de le dire).
Personnellement tu te fourvoie, je n'ai rien contre systemd (je l'utilise sur ma Debian stable), j'ai l'impression qu'il écrase n'importe quel autre init linux, je vois juste d'un mauvais œil cette API. Oui elle est réimplémentable, oui elle l'a déjà était pour ubuntu. Mais logind a ou va en présenter une nouvelle et celle de systemd peut très bien changer ou s’agrandir (c'est un logiciel en développement actif). Ça n'est pas un standard, ça tente de se présenter comme un standard de fait, mais aujourd'hui ça n'est pas le cas.
Mais c'est pas une bonne chose de changer aussi régulièrement les API linux, c'est peut être l'un des gros problèmes de linux sur desktop. C'est les API du bureau linux. Le problème n'est pas fonctionnel. Avoir une vitesse de boot ou une gestion des sessions utilisateurs dans l'absolu c'est joli, mais ça apporte plus de bug d'intégration que de fonctionnalité pour l'utilisateur final.
Bien sûr Lennart comme tout autre vis dans le monde du logiciel libre, un monde où chacun fait bien ce qu'il veut et qui est régis par une méritocratie celui qui fait a le dernier mot, mais ça n'empêche pas de donner son avis.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: dépendance à un système d'init
Posté par Renault (site web personnel) . Évalué à 7.
Personnellement je ne te visais pas trop dans mon propos, je répondais plus à Tanguy qui faisait dans la critique gratuite de systemd alors que le problème est plus profond que ça et ne devrait pas s'attarder uniquement sur systemd. Enfin selon la vision des choses, car je pense qu'il y a deux approches que je vais expliciter plus bas.
Note que je ne suis pas particulièrement en désaccord avec toi, je comprends en tout cas ton point de vue.
Je pense que c'est en soit quelque chose à double tranchant en effet :
C'est un peu comme vouloir la stabilité et l'intégration d'une Debian et les nouveautés de Fedora (par exemple) en même temps, ce sont deux visions à mon sens correctes mais qui s'opposent et qui sont difficiles à concilier. Comme on dit, on ne peut pas tout avoir.
Beaucoup ici aiment les systèmes libres car tout peut être remis en question, que ça évolue suffisamment vite pour être en phase avec l'évolution technique. Ce sont des qualités souvent mis en opposition avec Windows par exemple mais qui nécessite de changer d'API quand on se rend compte que celles existantes ne parviennent pas à convenir à la situation d'aujourd'hui.
Et il sera impossible d'avoir une API stable tant qu'il n'y aura pas de gouvernance suprême. Si le noyau est géré par une poignée de gens qui travaillent main dans la main (ou en tout cas, avec un seul arbre de développement) les couches au dessus ont autant de branches que de projet ce qui rend la coordination difficile. Et certaines tentatives de gouvernances ont été particulièrement rejetées comme la LSB ce qui montre la difficulté de se mettre d'accord pour essayer d'harmoniser l'ensemble.
Si les projets majeurs sont prêts à s'unir sous un même pavillon, sans pour autant vendre leurs âmes au diable, il y aurait moyen en effet d'avoir une conception plus stable des cocuhes du systèmes. Mais étrangement, je n'y crois pas trop pour le moment à la possibilité d'une telle entreprise.
[^] # Re: dépendance à un système d'init
Posté par Zenitram (site web personnel) . Évalué à 2.
Tu préfères un OS sans bug pas du tout utilisé à un OS avec un peu de bugs un peu utilisé, perso je préfère le contraire.
Parce qu'ayant gouté à un OS (en fait deux : Windows et Mac OS X) qui bootent très rapidement, en tant qu'utilisateur desktop il est hors de question d'imaginer utiliser un OS qui prend son temp à booter, on n'est plus au 20è siècle.
Les bugs sont un problème, mais ça ne cautionne pas de geler un OS, ce sont les bugs qu'il faut chasser.
De la mème manière, si il faut attendre x (combien pour que ça te va? OK, le W3C dit 2 par exemple) implémentations, déjà que Linux est à la ramasse sur le desktop (Windows et Mac OS X bootent rapidement depuis quelques années maintenant), ça va être encore pire…
Et les autres non plus ;-).
[^] # Re: dépendance à un système d'init
Posté par barmic . Évalué à 5.
Tu ne peux pas nier qu'il y a un vrai problème d'intégration des nouveautés. L'évolution pourrait très bien prendre en compte l'existant. C'est sur ce genre de petite chose que MacOS fait son beurre.
Pff sérieusement tu crois que personne le vois venir ton homme de paille. Il n'y a pas d'autres choix possible ?
L'intérêt de systemd n'est pas la vitesse de boot. Si on voulais juste faire quelque chose de rapide, on peut le faire de pleins de façons. Le problème est plus dans les dépendances entre le bureau et le système d'init. L'intérêt n'est pas notable (en tout cas pour moi).
Si je ne l'avais pas dis tu aurais était le premier à me répondre que je n'ai qu'à implémenter l'API en question et que si ce n'est pas fait c'est que tout le monde s'en fout (ça fait partie des tes arguments récurrent que tu sort à loisir).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: dépendance à un système d'init
Posté par xcomcmdr . Évalué à 3.
C'est le cas pour systemd, qui prend en charge les scripts d'init.
Quant à GNOME 3, quelques parties peuvent avoir besoin de logind ou d'un service équivalent (c'est pour ça que les patchs de Canonical pour que ça fonctionne sur Ubuntu ont été acceptés).
logind, lui, a besoin de systemd.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: dépendance à un système d'init
Posté par xcomcmdr . Évalué à 0. Dernière modification le 01 février 2014 à 11:56.
Tout à fait.
Non, pas vraiment. Le plus gros problème de la vitesse de boot sur SysV, c'est que SysV attend que chaque service ait fini de démarrer avant de démarrer un autre. Utiliser ureadahead, un SSD, ou autre astuce n'y changera pas grand chose du point de vue du temps de boot.
Le boot de systemd est parallélisable parce que les dépendances entre les services sont bien décrites, et que l'usage de udev et dbus font qu'elles sont plus faciles à gérer :
http://0pointer.de/blog/projects/the-biggest-myths.html
OpenRC est rapide pour la même raison : il démarre les services de manière parallèle.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: dépendance à un système d'init
Posté par jyes . Évalué à 5.
Non.
L’implémentation du boot SysV de Debian aussi.
[^] # Re: dépendance à un système d'init
Posté par xcomcmdr . Évalué à 4. Dernière modification le 01 février 2014 à 16:13.
Ah bon, j'ai sûrement rêvé quand SysV se bloquait lamentablement une fois sur deux sur un truc trivial comme le réseau. Alors que j'aurais bien voulu qu'il me démarre le display manager pendant ce temps. ;-)
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: dépendance à un système d'init
Posté par Sylvain Blandel . Évalué à 1.
Ça dépend probablement des distributions, et de leurs versions. Lorsqu'Archlinux utilisait encore SysVinit, on pouvait démarrer des services en parallèle.
[^] # Re: dépendance à un système d'init
Posté par kna . Évalué à 1.
Oui, et de plus, le réseau est considéré comme une dépendance pour beaucoup de services, donc une fois que le réseau a démarré, les services se lancent en parallèle.
Sur la plupart des distribs, le display manager se lance à la fin par défaut. C'est pas optimal, mais au moins tu sais que quand tu es loggué, tu n'as pas à attendre le démarrage d'un service en arrière plan, quelque soit l'action que tu veux faire.
[^] # Re: dépendance à un système d'init
Posté par gnx . Évalué à -2.
Génial, comme ça Lennux aura achevé de reproduire Windows. S'il y a bien un truc insupportable qui nous a pourri la vie des années durant dans Windows, c'est ces $@*#% de dizaines de secondes (ou de minutes) pendant lesquelles le système et l'interface graphique semblent avoir démarré alors qu'en fait les services continuent à être démarrés en arrière plan et toute action pendant ce laps de temps a un résultat indéfini (le seul truc sûr c'est de faire mouliner la machine à donf et de simuler des freezes).
[^] # Re: dépendance à un système d'init
Posté par Zenitram (site web personnel) . Évalué à -10.
Je ne sais pas de quel Windows tu parles, mais le mien out of the box est utilisable en moins de 10 secondes, alors que le Linux n'a pas fini de démarrer.
Faudrait arrêter un jour le FUD, et se demander pourquoi Linux est absent du Desktop (et non, ce n'est pas à cause d'une quelconque position domainante qui est une bonne excuse pour ne pas regarder le problème en face : il ne répond pas au besoin).
[^] # Re: dépendance à un système d'init
Posté par xcomcmdr . Évalué à 2. Dernière modification le 01 février 2014 à 17:38.
SI. C'est bien grâce à la livraison et préinstallation d'un système Windows (en fait ça a même débuté avec MS-DOS), que ses APIs se sont imposées aux développeurs tiers.
Et aujourd'hui on a une infinité d'applications qui ne fonctionne qu'avec Windows. Des milliers de gens qui n'ont connu que Windows sur le bureau. Ça continue depuis plus de 30 ans. Le nombre d'ordinateurs que l'on peut acheter avec Linux ou sans OS est ridicule. Windows est trop bien implanté (sur le desktop) pour que GNU/Linux le remplace un jour.
Ce ne sont pas les utilisateurs qui sont à convaincre, mais les constructeurs.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: dépendance à un système d'init
Posté par Sufflope (site web personnel) . Évalué à 10.
Ouais bah je ne sais pas de quel Windows tu parles non plus. Mon Seven est inutilisable pendant 1 à 2 minutes après l'apparition du bureau, et non j'ai pas installé de toolbar.
[^] # Re: dépendance à un système d'init
Posté par Kioob (site web personnel) . Évalué à 6. Dernière modification le 02 février 2014 à 12:12.
Inversement, je confirme que Windows 8 est démarré et «utilisable» en moins de 10 secondes.
Mais oui les précédentes versions sont des veaux et mettent bien plus longtemps à booter que mes Debian :/
À mon avis l'hardware joue beaucoup là dedans, tout comme le remplacement du BIOS par l'UEFI.
alf.life
[^] # Re: dépendance à un système d'init
Posté par dave_null (site web personnel) . Évalué à 3.
Il est temps d'investir dans un bon SSD. Windows7 démarre en 20 secondes et Windows 8 en quelques secondes.
[^] # Re: dépendance à un système d'init
Posté par fravashyo . Évalué à 2.
Il est temps de configurer la mise en veille ou l'hibernation, parce que c'est quand même plus pratique que de redémarrer son ordinateur tous les jours…
« I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond
[^] # Re: dépendance à un système d'init
Posté par dave_null (site web personnel) . Évalué à 2.
Oui mais là on parle du démarrage. En hibernation, windows 8 est aussi très bon. Je n'ai aucune idée de comment il fait mais j'ai 16go de ram et la reprise est instantanée même après 3 mois sans électricité.
[^] # Re: dépendance à un système d'init
Posté par Renault (site web personnel) . Évalué à 3.
De mémoire il y a plusieurs astuces.
Windows 8 ne semble démarrer que le strict minimum avant de présenter l'écran de connexion (plusieurs fois j'ai vu l'interface Ethernet classique ou Wifi ne s'activer que quelques secondes après l'affichage de cet écran). Ils semblent mieux paralléliser les services au lancement au lieu d'un truc plus séquentiel et profite ben mieux de la technologie SSD (quand c'est disponible) que ses prédécesseurs.
En soit l'idée n'est pas nouvelle, ni débile. Le temps que l'utilisateur entre son mot de passe le système peut légitimement lancer des tâches en arrière plan plutôt que de ne rien faire si cela permet à l'utilisateur que le système paraît plus réactif. Alors que GDM ici n'est lancé qu'une fois tous les services du système lancés même quand il n'en a pas forcément besoin le temps de se connecter.
[^] # Re: dépendance à un système d'init
Posté par Zenitram (site web personnel) . Évalué à 4.
Je confirme, mon écran de connexion est toujours disponible avant la connexion de Wifi (qui est lente chez moi), et… Ca ne me dérange pas du tout! (je n'ai pas besoin de Wifi pour entrer mon mot de passe)
En gros, ça milite pour systemd qui remplace tous les vieux autres système d'init :)
En fait, le pire je crois est que certains trouvent que cette façon de faire est "horrible" sans qu'ils puissent vraiment expliquer pourquoi ça ne va pas de ne pas avoir le Wifi pendant qu'ils entrent leur mot de passe.
Bref, plus on parle du système d'init de Linux, et plus on se rend compte qu'il a quelques années de retard… Et ça le fait pas trop pour un produit qu'on pusse sur le desktop (et je comrpedn encore mieux pourquoi tout le monde ou presque se jette sur systemd qui semble simplifier, optimiser tout ça).
[^] # Re: dépendance à un système d'init
Posté par Renault (site web personnel) . Évalué à 3.
Le problème est que Microsoft est allé trop loin dans l'affaire dans le passé.
Sous XP en tout cas, l'interface du bureau était affichée mais inutilisable pendant des dizaines de secondes ce qui est plutôt gonflant. Quitte à ne pas être utilisable, je préfère que l'affichage soit différent.
Le coup de la fenêtre de connexion est une astuce qui est bien mieux pensée et intéressante pour l'utilisateur.
[^] # Re: dépendance à un système d'init
Posté par anaseto . Évalué à 2. Dernière modification le 04 février 2014 à 21:06.
Parler de retard laisse sous-entendre qu'il y a un chemin tout tracé à suivre dans le logiciel vers un certain objectif unique obscur, alors que c'est pas du tout le cas. Perso, j'aime voir d'un coup d'œil que tous les services se lancent correctement, et c'est pas comme si ça mettait un temps fou : il y a plus de dix ans oui, mais aujourd'hui non, alors, à quoi bon de tout vouloir faire à la fois ?
Ah, petite remarque : parler du système d'init sous Linux dans un journal qui parle des différents systèmes d'init, c'est rigolo.
[^] # Re: dépendance à un système d'init
Posté par Zenitram (site web personnel) . Évalué à 1.
D'autres considèrent que c'est encore trop long, ne t'en déplaise…
Ca tombe bien, on s'interesse aux gens en général, qui s'en foutent complet et veulent pouvoir taper leur pass pendant que ça charge en attendant, par exemple. Pourquoi ton besoin serait supérieur aux autres? Libre à toi d'avoir ta distro aux petits oignons, mais libres aussi aux autres de répondre au besoin général.
Ah, petite remarque : parler du système d'init sous Linux ça veut dire parler de la fonction "initialisation" de l'OS, pas dire qu'il y a un seul logiciel unique capable de le faire.
systemd et plein d'autres sont le module qui s'occupent du système d'init sous Linux. Le système d'init de Linux peut être géré par différents logiciels etc…
[^] # Re: dépendance à un système d'init
Posté par Renault (site web personnel) . Évalué à 3.
En quoi est-ce incompatible avec les démarrages rapides et parallèles ?
Et le fait que ce soit stocké dans des logs te permet de vérifier si tu en as vraiment besoin.
Des palliatifs existent, cela ne signifie pas que les idées de Microsoft ou de systemd sont ridicules ou incompatibles avec ton besoin.
Bah quand j'allume mon ordinateur, c'est préférable qu'il soit utilisable le plus tôt possible. Je sais que certains aiment en profiter pour lancer le café en même temps et le siroter mais ce n'est pas un cas d'utilisation très pertinent.
Surtout, je ne vois pas pourquoi on devrait faire moins vite si aller plus vite ne dégrade pas la qualité du service (et ici ce n'est pas le cas).
[^] # Re: dépendance à un système d'init
Posté par anaseto . Évalué à 2. Dernière modification le 05 février 2014 à 19:33.
Ce que je veux dire c'est que si ça démarre en une seconde j'ai le temps de rien voir, et pire encore si j'ai un écran de connexion qui apparaît avant que tout soit démarré.
Je suis d'accord, mais j'aime bien avoir un rendu visuel sur le moment, et s'il y a un souci je vais ensuite voir les logs pour les détails, car je vais pas systématiquement voir les logs après chaque démarrage non plus :)
Mais bon, mes préférences sont sans doute particulières, je voulais juste dire que démarrer instantanément et sans infos ne fait pas l'unanimité, et non sous-entendre l'opposé et que tout le monde doit avoir mes habitudes comme semble l'avoir compris Zenitram, désolé si je me suis mal exprimé. Et bon, je suis même pas si attaché que ça à mes habitudes en matière de boot, c'est pas comme si j'éteignais mon ordi juste après, content de l'expérience ;) Ni d'ailleurs que mon choix d'os ou distribution se fonde sur ce type de considérations.
Edit : Ah, et d'ailleurs, je pense à une chose : le seul moment où j'ai l'impression que le démarrage est trop long, c'est quand fsck fait son check des disques, et là je vois pas comment on pourrait raccourcir (enfin, peut-être, j'en sais rien).
[^] # Re: dépendance à un système d'init
Posté par Renault (site web personnel) . Évalué à 3.
Les logs sont là pour ça, puis y une époque sous un GDM de Fedora il était possible de voir une icône qui avertissait en cas de service mal lancé et qui pouvait te montrer le texte de démarrage si tu ne l'avais pas vu).
D'autant que soyons honnêtes, en général les services se lancent bien et cet état ne change pas à chaque boot. L’usage de journaux me semble plus pertinent, car après tout on ne regarde pas le bon fonctionnement en permanence de toutes les applications sinon on ne pourrait rien afficher d'autres sur l'écran.
GDM te proposait de visualiser s'il y avait eu des erreurs au démarrage, je pense qu'il doit être possible de coder facilement un programme similaire qui t'avertit une fois connecté s'il y a eu des soucis. Cela t'évite de devoir être derrière ton écran au démarrage et de perdre du temps pour rien en ralentissant volontairement la durée du démarrage.
[^] # Re: dépendance à un système d'init
Posté par anaseto . Évalué à 1.
Je suis plutôt d'accord, je reste pas toujours devant l'écran au démarrage d'ailleurs. Après, peut-être que comme j'ai une configuration plutôt minimale, et j'utilise un simple tiling wm, que je démarre avec startx, ça fait longtemps que j'ai l'impression que tout est suffisamment rapide, d'où le fait que j'aie pas un vision claire de ce sujet sans doute.
[^] # Démarrage séquentiel avec systemd
Posté par Sylvain Blandel . Évalué à 1. Dernière modification le 05 février 2014 à 20:03.
J'imagine qu'on peux obtenir un démarrage séquentiel (plutôt que parallèle) avec systemd. Comment ? En listant les différentes unités qui sont lancées au démarrage (il y en a un paquet) et en les personnalisant à coup de After :
C'est certainement fastidieux à faire, mais ça me semble un bon exercice pour comprendre le déroulement d'un boot. Le schéma des différentes target du boot est un point de départ pertinent pour ce travail.
[^] # Re: dépendance à un système d'init
Posté par xcomcmdr . Évalué à 2.
C'est vachement plus court en ext4, et encore plus sur un SSD.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: dépendance à un système d'init
Posté par anaseto . Évalué à 2.
Oui, je confirme qu'avec un SSD c'est rapide, mais sur un autre ordi j'ai un disque dur plutôt vieux en ext3 qui rame pas mal.
[^] # Re: dépendance à un système d'init
Posté par xcomcmdr . Évalué à 2.
Non mais vraiment, ext4 est plus rapide pour fsck
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: dépendance à un système d'init
Posté par anaseto . Évalué à 2.
Pas mal, en effet, je formatterai ce disque en ext4 un de ces jours alors.
[^] # Re: dépendance à un système d'init
Posté par GnunuX (site web personnel) . Évalué à 2.
Pas la peine de formatter pour passer en ext4.
[^] # Re: dépendance à un système d'init
Posté par xcomcmdr . Évalué à 3.
Si on fait une conversion ext3 -> ext4, on n'obtient pas un fsck rapide, comme le remarque Ted Ts'o dans les commentaires du lien.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: dépendance à un système d'init
Posté par Anonyme . Évalué à 4.
Pourquoi tout démarrer en meme temps ? Par ce qu'avec un systeme d'init qui gere correctement les interactions entre les differents services on peut se le permettre, et il n'y a pas d'interet à ne pas le faire.
[^] # Re: dépendance à un système d'init
Posté par ariasuni . Évalué à 0.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: dépendance à un système d'init
Posté par zebra3 . Évalué à 3.
Si le logiciel peut évoluer et obtenir les mêmes résultats sans devoir acheter du nouveau matos, c'est quand même pas plus mal.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: dépendance à un système d'init
Posté par gnx . Évalué à 9.
Tous jusqu'à Seven. Seven est un peu mieux, mais c'est pas encore ça.
Zenitroll detected.
[^] # Re: dépendance à un système d'init
Posté par Kioob (site web personnel) . Évalué à 1.
Je viens de «mesurer» sur mon Laptop, en UEFI : entre le bouton «power» et l'écran de connexion GDM3, il se passe 9 secondes (dont 1 seconde d'attente pour GRUB, que je pourrais désactiver).
En l'état, ça me semble plutôt rapide, et oui je suis plutôt d'accord avec toi : sur un Laptop la vitesse de démarrage est importante.
alf.life
[^] # Re: dépendance à un système d'init
Posté par lolop (site web personnel) . Évalué à 5.
Disons que ça aide beaucoup.
J'aimerais bien que dans les boutiques le matériel soit vendu séparément du logiciel, carrément en deux boites distinctes, comme quand tu achètes ta lessive dans un autre rayon que ta machine à laver. Juste pour voir, que les gens puissent voir combien ça leur coûte et puisse choisir des alternatives.
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: dépendance à un système d'init
Posté par xcomcmdr . Évalué à 1.
Non. Les API Windows changent aussi souvent, depuis bien plus longtemps que Linux n'existe. Et pourtant, Windows est toujours largement dominant sur le desktop.
Source ? Tu veux revenir à HAL + SysV ? Sérieusement ?
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: dépendance à un système d'init
Posté par xcomcmdr . Évalué à 3.
…Parce que MS fait attention à la rétrocompatiblité, que la plupart des applications tierces sont pour Windows, et que la vente liée Wintel est pratiquée depuis des décennies.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: dépendance à un système d'init
Posté par barmic . Évalué à 3.
Leur qualité c'est de gérer proprement la compatibilité avec l'existant. Ça ça a de la valeur pour le bureau.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: dépendance à un système d'init
Posté par gnumdk (site web personnel) . Évalué à 0.
NON
Ubuntu, ils ont pris le code source de systemd, ils ont fait un beau paquet qui ne build que les utilitaires systemd (et pas l'init) et voilà, ça fonctionne…
[^] # Re: dépendance à un système d'init
Posté par claudex . Évalué à 5.
Il faudra mettre à jour le wiki de systemd alors http://www.freedesktop.org/wiki/Software/systemd/InterfacePortabilityAndStabilityChart/ (voir la colonne Other implementations)
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: dépendance à un système d'init
Posté par anaseto . Évalué à 3.
Perso, ce n'est pas le mot systemd qui me dérange, mais l'impression que ces derniers temps le problème du système d'init semble si important que si on n'accueille pas toutes les nouveautés avec enthousiasme en acceptant sans broncher qu'elles sont universellement supérieures aux solutions existantes c'est qu'on est un vieux conservateur qui veut en rester à la préhistoire. Le plus logique ne serait pas que, suivant les besoins, les ressources et les objectifs d'une distribution, un ou plusieurs de ces systèmes soient supportés ?
C'est comme HAL ou udev, c'est très bien, ça permet à un plus ample public de pouvoir monter des clés USBs facilement etc… mais est-ce vraiment utile dans tous les contextes? (vraie question, j'en sais rien si c'est possible de s'en passer sous linux) Et sinon, pourquoi faudrait-il voir d'un mauvais œil une distribution qui déciderait de ne pas les supporter ? (l'idée ne me semble pas choquante a priori)
Et en ce qui me concerne, le système d'init et udev ne sont pas des choses qui impactent mon utilisation quotidienne de type desktop, et je ne suis peut-être pas un cas isolé. Le seul truc qui change chez moi, c'est que si je devais passer à systemd, il me faudrait écrire un unit pour par exemple configurer mon réseau, ce qui est peu de chose, même s'il me semble un peu plus compliqué (peut-être parce que nouveau pour moi ?) que deux lignes dans /etc/conf.d/net avec openrc de gentoo, ou l'interfaces de debian, ou encore le hostname.if d'openbsd.
[^] # Re: dépendance à un système d'init
Posté par Maclag . Évalué à 10.
De ce que je comprends, moi qui suis également un utilisateur desktop, je ne pense pas non plus être sévèrement impacté. J'ai trouvé sympa journald, mais on ne peut pas dire que ça change ma vie (utilisateur desktop: c'est pas comme si j'avais quelque chose à y chercher toutes les semaines…). Le temps de boot n'a jamais été ma priorité (ça le serait plus sur un laptop ou un netbook).
Par contre, je crois bien que ce sont les mainteneurs de paquets qui sont impactés. D'abord parce qu'il faudra tout convertir, mais surtout ensuite parce que la maintenance sera autrement plus simple avec systemd.
Des développeurs seront impactés aussi s'ils se mettent à utiliser les API offertes par systemd. Si ça leur plait, ce sera positif.
Alors personnellement, je pencherais pour systemd parce que ça a l'air bien branlé de loin (je veux dire en tant que pas-du-tout-expert), et qu'on sent quand même une large vague d'adoption. Je me dis que si c'est tellement bon pour tous les autres, ça ne doit pas être si mal pour Debian, et puis autant de distros qui l'utilisent ne peuvent que le rendre plus robuste et pérenne.
Du côté Upstart, je vois qu'il n'y plus qu'Ubuntu (?), dont les choix techniques font de moins en moins, voire plus du tout d'émules, et RedHat l'a laissé tomber. Et si Ubuntu décide de le lâcher aussi un jour?
[^] # Re: dépendance à un système d'init
Posté par anaseto . Évalué à 1.
Je suis d'accord qu'avant tout le plus important est ce qu'en pensent les mainteneurs, et si systemd permet de faciliter les choses, tant mieux. Mais pour les distributions (ou des *BSD), qui se contenteraient de fonctionnalités basiques du type start-stop-restart-reload-check, je ne pense pas que la maintenance soit forcément plus facile avec systemd.
[^] # Re: dépendance à un système d'init
Posté par gnx . Évalué à -3.
Ç'est un des arguments principaux avancés en faveur de systemd. Le problème, c'est que jamais je n'ai vu cette supposée charge de travail de maintenance démontrée. Intuitivement, je me demande qu'est-ce qu'il y a de lourd à maintenir des scripts de démarrage de démons qui n'évoluent pas tous les quatre matins. et dont la plupart suivent le même modèle. Il est possible que cette intuition soit fausse mais à chaque fois (dans les discussins que j'ai suivies) qu'on en arrive là, c'est "vous ne pouvez pas comprendre", "puisqu'on vous le dit", "vous n'avez qu'à participer", "vous êtes maintenant banni de la liste", etc. J'aimerais voir autre chose que des arguments d'autorité ou des cas particuliers.
Donc si quelqu'un pouvait par exemple comparer les commits concernant les scripts de démarrage par rapport au nombre de commits totaux d'une distrib, ça m'intéresserait.
[^] # Re: dépendance à un système d'init
Posté par Sylvain Blandel . Évalué à 9.
D'après son site officiel, Nginx est
Quand les mainteneurs d'un système d'exploitation packagent Nginx, ils doivent écrire un fichier adéquat : un script shell pour les distributions utilisant SysVinit, un fichier
.servicepour celles utilisant systemd, etc.Comme les développeurs de Nginx sont des gens bons, ils proposent des fichiers prêts à l'emploi sur leur wiki. On y trouve des fichiers pour démarrer Nginx sous Debian, sous FreeBSD, sous Fedora, sous Ubuntu, et même sous OSX ! Mais malheureusement, rien pour OpenSUSE, ni pour Archlinux. Pendant que les packageurs de Debian et FreeBSD se contenteront d'un copié-collé, ceux d'OpenSUSE et d'Archlinux devront écrire eux-mêmes leur fichier. C'est vraiment injuste, ce monde est bien cruel.
Mais en fait, non.
OpenSUSE et Archlinux ont un point commun avec Fedora : l'utilisation de systemd. Lorsqu'on regarde le fichier pour lancer Nginx sous Fedora, on lit ceci :
Aaah ! Finalement, les packageurs d'OpenSUSE et d'Archlinux pourront eux aussi copier-coller joyeusement. Ça va mieux.
Bref : toutes les distributions utilisant systemd peuvent partager le même fichier
.service. Ainsi, les packageursrepompent comme des goretss'inspirent du travail déjà réalisé par les autres packageurs. Le travail est mutualisé.Pour répondre à ta question : j'ignore si l'écriture de scripts shell pour démarrer/arrêter un démon est pénible, et j'ignore si la maintenance de ces scripts est chronophage. C'est juste que les scripts shell ne sont guère efficaces pour encadrer les processus.
[^] # Re: dépendance à un système d'init
Posté par barmic . Évalué à 1.
Bof si. Tu peut très bien gérer des groupes de contrôle dans uns script shell, rien ne t'en empêche.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: dépendance à un système d'init
Posté par xcomcmdr . Évalué à 3.
Mouais, du temps de SysV, quasiment à chaque fois où j'arrêtais un daemon bloqué, je me retrouvais avec des processus zombie.
Les control groups, c'est mieux :
https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Resource_Management_Guide/ch01.html
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: dépendance à un système d'init
Posté par barmic . Évalué à 3.
C'est pas parce que les distributions utilisent des scripts qui ne se servent pas des cgroups que c'est impossible. Tu peut le faire avec
cgexecpar exemple et donc avecsysvourc.dsans problème notable.Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: dépendance à un système d'init
Posté par Shuba . Évalué à 2.
Je pense qu'il voulait dire qu'il était possible de configurer de faire de la supervision par les cgroups via le shell également. Le problème à mon sens étant que ça demanderait de faire spécifiquement appel à du boilerplate dans chaque script d'init pour en profiter, alors qu'avec systemd c'est garanti par le système.
[^] # Re: dépendance à un système d'init
Posté par barmic . Évalué à 1.
Je pense que ça demanderait une mise à jour d'init-functions avec probablement une mise à jour de l'API qui va avec. Ça ne me paraît pas plus moche que ce qu'il y aujourd'hui.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: dépendance à un système d'init
Posté par vv222 . Évalué à 1.
Ça c'est le cas à partir du moment ou tout le monde utilise le même système d'init.
Que ce soit systemd ou un autre n'a rien à voir.
[^] # Re: dépendance à un système d'init
Posté par Renault (site web personnel) . Évalué à 10.
Si, les scripts init SysV sont uniques par distribution, ceux de Debian n'ont rien à voir avec ceux de Fedora pour un service donné. C'est d'ailleurs l'un des principaux soucis.
[^] # Re: dépendance à un système d'init
Posté par vv222 . Évalué à 3.
Merci, je comprends mieux le débat maintenant que je me rends compte d'à quel point je me plante sur les systèmes déjà en place.
[^] # Re: dépendance à un système d'init
Posté par anaseto . Évalué à 4.
Sur openbsd nginx est installé par défaut depuis un certain temps, le script d'init est ici (dernière modification il y a presque deux ans), et représente moins de dix lignes de code que quiconque connaissant un peu de shell serait capable de faire, même si c'est son premier script d'init. Il faut qu'il connaisse aussi un peu nginx bien sûr, mais si celui qui écrit un script d'init pour un logiciel ne le connaît pas au moins un peu…
Donc je dirais que la réponse à :
est plutôt non.
Par contre, ici, en effet ça ne serait probablement pas optimal, car non prévu spécifiquement pour ce genre de choses. Et pour comble, sur le script que j'ai signalé ce ne serait même pas possible vu qu'openbsd ne supporte pas ce genre de fonctionnalités.
Tout dépend des fonctionnalités dont on a besoin, mais l'argument de la simplicité de maintenance des scripts d'init semble être valide ou non qu'au cas par cas, suivant les distributions et os (en supposant qu'un systemd ou équivalent fut possible ailleurs que sous linux). En ce qui concerne debian, vu qu'il a vocation à être un os universel, généraliste et populaire, le plus logique c'est que systemd soit supporté (par défaut ou non c'est une autre histoire), mais ça ne m'étonnerait que ça devienne le seul système supporté, tout simplement parce qu'il y a trop de gens derrière debian, avec des besoins variés et avis divergents, et qu'il y aura probablement bien quelqu'un pour packager openrc ou autre, m'enfin, peut-être que je me trompe totalement.
[^] # Re: dépendance à un système d'init
Posté par Maclag . Évalué à 4.
Là je dirais: d'un côté non, ça ne devrait pas être le seul supporté.
Mais de l'autre, il y a une deuxième question au vote: est-il autorisé ou non de dépendre d'un système init en particulier?
Si la réponse est oui, systemd ou upstart pourraient devenir les seuls supportés de fait, à cause d'un gros nombre de services pas compatibles avec les autres systèmes d'init.
Si la réponses est non, on augmente cette fois pas mal la charge de boulot des mainteneurs, parce qu'il faut se farcir tous les systèmes d'init de la distro. De là à rebuter certains packageurs esseulés…
[^] # Re: dépendance à un système d'init
Posté par anaseto . Évalué à 1.
Peut-être qu'en pratique ce sera quelque chose de plus granulaire : certains paquets comme gnome auraient une dépendance à systemd obligatoire pour simplifier la vie des packageurs, sans que cela affecte le choix d'un système d'init pour le système de base et les paquets pour lesquels supporter plusieurs systèmes d'init n'est pas un problème majeur. C'est de toutes façons comme ça déjà pour d'autres choses que le système d'init dans toutes les distributions, surtout binaires, où on peut pas faire des paquets précompilés pour toutes les options de compilation possibles pour permettre de gérer totalement ce qu'on veut ou non dans son système.
[^] # Re: dépendance à un système d'init
Posté par Moonz . Évalué à 1.
Et utiliser systemd qui est ouvertement et volontairement Linux-only est une avancée sur ce point parce que… ?
Si le but du jeu était de simplifier la vie des mainteneurs de logiciels tiers c’est OpenRC ou initng qui aurait été poussé au forceps, pas systemd.
[^] # Re: dépendance à un système d'init
Posté par Renault (site web personnel) . Évalué à 6.
SysV était aussi Linux-centré dans les faits.
Rien qu'entre Debian et une Red-Hat, les scripts étaient différents ! Alors je n'imagine pas avec d'autres UNIX utilisant SysV mais non Linux.
Bref, avant ce n'était pas du tout portable, aujourd'hui les distribution linux ont un truc portable, c'est mieux qu’avant non ?
[^] # Re: dépendance à un système d'init
Posté par Moonz . Évalué à 1. Dernière modification le 03 février 2014 à 22:29.
Avant une solution portable était possible mais tout le monde s’en foutait (la preuve, initng n’a jamais décollé alors qu’il était là des années avant même que upstart soit en discussion, qui lui-même est antérieur à systemd…)
Maintenant une solution portable est juste impossible.
J’ai du mal à voir l’amélioration sur cet axe d’analyse…
C’est pas grave hein : comme je l’ai dit, en pratique tout le monde s’en fout (tout simplement parce que les distribs tiennent à garder le contrôle de leurs scripts d’init, cf debian qui refuse d’utiliser des unit systemd dans lesquelles les chemins seraient hardcodés, et upstream sait que c’est pas son boulot de fournir 200 scripts d’init mais celui du packageur). Tout ce que je dis c’est qu’il est naïf de croire l’excuse que « systemd c’est fait pour simplifier la vie des mainteneurs upstream ». Ça n’a jamais été son but de toute façon, les buts affichés de systemd c’est :
Pas vraiment non.
[^] # Re: dépendance à un système d'init
Posté par Renault (site web personnel) . Évalué à 4.
Pas SysV en lui même, mais ses scripts inits de Linux ne sont pas utilisables en dehors de ce cadre.
[^] # Re: dépendance à un système d'init
Posté par gnx . Évalué à 1.
Mais ce n'est pas un problème de Linux/!Linux et il n'y a pas de "scripts inits de Linux", puisque SysV n'impose pas grand chose et que chaque distrib, de Linux ou autre, est libre de faire les scripts qu'elle veut pour coller à sa spécificité ou bien de reprendre tels quels les scripts d'une autre si elle ne tient pas à se différencier sur ce point.
[^] # Re: dépendance à un système d'init
Posté par xcomcmdr . Évalué à 5. Dernière modification le 03 février 2014 à 23:35.
Pas du tout.
Et pourtant, dans les faits c'est le cas. Comme par exemple, pour les mainteneurs de Archlinux.
C'est l'une des raisons du passage à systemd, et ils ont eu raison.
Et puis :
Completely wrong. The BSD folks are pretty much uninterested in systemd. If systemd was portable, this would change nothing, they still wouldn't adopt it. And the same is true for the other Unixes in the world. Solaris has SMF, BSD has their own "rc" system, and they always maintained it separately from Linux. The init system is very close to the core of the entire OS. And these other operating systems hence define themselves among other things by their core userspace. The assumption that they'd adopt our core userspace if we just made it portable, is completely without any foundation.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: dépendance à un système d'init
Posté par Moonz . Évalué à 0.
upstream = nginx/mysql/…, pas arch/slackware/debian
Ben, c’est exactement ce que je dis :
- un système d’init portable tout le monde s’en fout
- systemd n’est pas et ne sera jamais portable parce qu’il expose des fonctionnalités spécifiques à Linux, donc prétendre que « systemd c’est bien parce que ça va enfin nous donner un init universel », je ris très fort
[^] # Re: dépendance à un système d'init
Posté par cosmocat . Évalué à 9.
Ris très fort, mais si tu fais exprès de ne pas comprendre, tu peux aller rire tout seul dans ton coin.
Lorsqu'il est dit « systemd c’est bien parce que ça va enfin nous donner un init universel », il faut bien comprendre l'ellipse faite ici qui est : un init universel pour toutes les distribs linux!
Comme çà:
- un utilisateur/admin système peut intervenir sur n'importe qu'elle distrib, il n'aura pas à réapprendre un init différent ou à analyser un script d'init différent,
- le fichier de config d'un service sera le même sur TOUTES les distribs et pourra être contribué en upstream
[^] # Re: dépendance à un système d'init
Posté par gnx . Évalué à -1.
Quand j'ai parlé de gens qui n'avaient rien démontré à ce sujet, je parlais principalement d'eux.
Ah.
[^] # Re: dépendance à un système d'init
Posté par zebra3 . Évalué à 8.
Ce qui est idiot, il suffit de définir pour chaque unité un EnvironmentFile dans lequel tu peux définir les chemins dans des varibles…
Systemd a réellement été conçu pour être le plus générique possible, en fournissant le moyen de séparer configuration et commandes. À l'inverse de SysV où tout est mélangé.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: dépendance à un système d'init
Posté par zebra3 . Évalué à 4.
Justement. Systemd est maintenant un outil en plus en userspace, tu devrais être content :-)
Tu ne l'a pas écrit mais le but initial de Systemd est de simplifier la vie des administrateurs. Et après avoir passé un peu de temps avec c'est bien le cas.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: dépendance à un système d'init
Posté par fmaz fmaz . Évalué à 6.
Ce qui gène fondamentalement la portabilité, c'est que les fichiers sont placés à des endroits différents sur chaque distribution. Et ce pour des raisons historiques et de non concertation. Alors oui, certains choix sont vraiment motivés et il est important que les distrib puissent faire des choix différents. Mais dans pas mal de cas, c'est complètement inutile. Parce que bon, placer un fichier dans /etc/network-conf/ ou /etc/conf-network/ c'est kif kif et haricot, tout ça c'est du même acajou.
Je crois me souvenir que c'était aussi un des but de Poettering quand il a lancé systemd. Forcer un peu d'uniformisation.
[^] # Re: dépendance à un système d'init
Posté par Zenitram (site web personnel) . Évalué à 4.
Ou alors tu avais une belle théorie, et une merde de pratique.
systemd a l'avantage de ne pas que théorique.
1/ Troll sur le "volontairement" alors que c'est juste le développeur principal qui ne veut pas se limiter en fonctionnalités ou perdre son temps dans des trucs qui ne l'interesse pas lui (genre séparer les fonctions en modules), et ça se comprend. libre à toi de te proposer pour aider à le faire (mais sans mettre des batons dans les roues pour le but du projet hein, ralentir le projet n'est pas acceptable et c'est normal)
2/ Tu es libre d'adapter systemd aux autres OS (et de désactiver les fonctionnalités pas supportés par l'OS si besoin, pas grave), d'utiliser le même format de fichier etc… Dur dur la liberté… Juste qu'en pratique, on s'en fou, sinon un gus porterai systemd ou un truc compatible avec les fichiers systemd sur les autres OS. Juste que les gars veulent surtout pas avoir un truc commun, donc ça n'arrivera pas de si tôt (vu le peu d'utilisation de Debian/kfreebsd, ça ne va pas pousser les gens àà avoir un système d'init commun).
Bref, tu parles de théorie, systemd vit dans la pratique.
[^] # Re: dépendance à un système d'init
Posté par xcomcmdr . Évalué à 2.
udev sert à gérer le matériel, et c'est lui qui s'occupe de peupler /dev. Tu vois un exemple où il n'y en a pas besoin ?
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: dépendance à un système d'init
Posté par anaseto . Évalué à 2.
Je pensais à un remplacement plus léger et avec moins de fonctionnalités (genre mdev peut-être, mais je connais pas assez pour dire s'il y a vraiment un intérêt ou non), ou au fork sous gentoo pour se passer d'une dépendance à systemd, je sais pas si c'est vraiment un bonne idée non plus, mais pourquoi pas.
[^] # Re: dépendance à un système d'init
Posté par gnx . Évalué à -2.
Il y a eu une vie avant udev, hein… Et même pendant, vu l'instabilité du machin.
[^] # Re: dépendance à un système d'init
Posté par freem . Évalué à 2.
Je suis assez ignare sur ce sujet, mais il me semble avoir lu par ci et par là qu'avant, c'était un fichier qui contenait une description statique des périphériques.
Du coup, dans le cas, par exemple, d'un téléphone où de toute machine sur laquelle on ne peut pas ajouter de nouveaux périphériques plug-and-play, udev me semble totalement inutile ( si rien ne change, gérer dynamiquement les choses est juste débile ).
Pour les non plug-and-play "actifs" ( j'entends par actif qui ne fasse pas qu'émettre ou recevoir un signal analogique, c'est à dire plus compliqué qu'un bête écouteur ou chargeur de batterie ), je ne sais pas du tout si udev fonctionne ( ça fait bien longtemps que je n'ai pas vu de périphériques non plug-and-play "actifs" ).
Le seul souci étant, au final, d'avoir la bonne table au bon moment, ce qui peut être pénible pour des PCs ( portable ou non ) sur lesquels on branche pour certains régulièrement des périphériques USB par exemple, qui me semble actifs.
Mais, comme j'ai dit, je suis totalement novice en la matière et j'ai probablement effectué de gros raccourcis disgracieux. Si c'est le cas, je suis preneur de toute remarque constructive ( autre que rtfm, parce que, basiquement, ce type de fm nécessite pour être bien compris une certaine connaissance de toute l'archi linux, chose qui n'est pas à ma portée actuelle. ).
[^] # Re: dépendance à un système d'init
Posté par oinkoink_daotter . Évalué à 10.
Cartes SD ?
Périphériques bluetooth ?
Activation dudit bluetooth, du wifi, etc
Périphériques USB, câble hdmi etc …
Bref, c'est loin d'être statique, tout ça…
[^] # Re: dépendance à un système d'init
Posté par Moonz . Évalué à 2.
mknodexiste toujours :)[^] # Re: dépendance à un système d'init
Posté par xcomcmdr . Évalué à 3.
Windows 95 existera toujours !
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: dépendance à un système d'init
Posté par gnumdk (site web personnel) . Évalué à 4.
Faux, il suffit d'utiliser le service systemd en question… En gros, savoir découper correctement un paquet, il me semble que chez Debian ils savent faire…
[^] # Re: dépendance à un système d'init
Posté par Maclag . Évalué à 4.
Je pense qu'arrivé là, tous les votants connaissent les tenants et aboutissants et les conséquences de chaque combinaison.
Tu mentionnes Gnome de plus en plus dépendant de systemd, je peux répondre "quid de Debian/kFreeBSD?"
J'ose espérer qu'ils savent déjà qu'aucune solution n'est parfaite, et quelle que soit la décision, il y aura beaucoup de boulot à abattre. On ne sait juste pas encore par qui… ;)
[^] # Re: dépendance à un système d'init
Posté par freem . Évalué à 1.
J'ai confiance en Debian pour ce genre de choses. Comme tu l'as souligné, quid de kFreeBSD? Après tout, cette version de la distro est bien moins obscure que le port Hurd, donc on peut supposer qu'elle à une certaine importance aux yeux des mainteneurs Debian.
# Simple
Posté par Snarky . Évalué à 10.
Connaissant Debian, ils vont réussir à nous mettre toutes les solutions en même temps !
[^] # Re: Simple
Posté par iOops (site web personnel) . Évalué à 1.
Je peux très bien imaginer lors d'une installation, que "l'installeur" me propose une solution par "défaut" tout en me laissant le choix d'opter pour un autre système d'init.
[^] # Re: Simple
Posté par vv222 . Évalué à 7.
Ceux qui ont lu le journal avant de troller ont d'ailleurs déjà constaté que la décision concerne uniquement le choix du système d'init par défaut, et qu'à aucun moment il n'est évoqué l'idée d'arrêter de maintenir les autres.
[^] # Re: Simple
Posté par freem . Évalué à 3.
En effet. Et peut-être qu'un jour on aura tout le système configurable à partir de l'installateur… le kernel, l'init, le serveur d'affichage, le bureau… ça serai génial ça.
A l'heure actuelle il n'y a que le bureau… pour certains autres outils le seul choix est de ne pas installer.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.