On sait que GNOME a choisi de dépendre de certaines fonctions offertes par systemd. C'est le cas notamment pour logind, le module permettant de gérer les sessions utilisateurs.
Cela a provoqué de nombreuses polémiques parce que plusieurs personnes ne veulent pas de cette dépendance et préféreraient que leur ordinateur ne contienne aucun code issu du projet systemd.
Pour ces gens là il fallait donc opter pour un bureau différent et KDE pouvait, par exemple, servir de refuge.
Ce sera de moins en moins le cas puisque KDE va lui aussi s'appuyer directement sur certaines fonctions de systemd.
Ce post de David Edmundson explique en détails les choix techniques effectuées dans Plasma 5 :
http://blog.davidedmundson.co.uk/blog/systemd-and-plasma
C'est très intéressant à lire et on voit que les développeurs de Plasma ont été séduits par le côté "propre et intégré" des modules de systemd (logind, timedated, hostnamed…etc).
Selon David, le code sera plus sûr, plus propre, plus rapide.
Bien entendu il est conscient que systemd est réservé aux systèmes Linux et il ne souhaite pas abandonner les utilisateurs tournant sous BSD. Pour eux il évoque des projets offrant une compatibilité mais c'est encore assez flou à ce stade.
# Dépendance obligatoire ou optionelle
Posté par moi1392 . Évalué à 8.
Je n'arrive pas à trouver l'info dans l'article de David Edmundson, mais il me semble que la différence avec GNOME est que KDE à choisi de ne pas dépendre de manière inconditionnelle de systemd.
S'il est présent (à la compilation ou en runtime, je ne sais pas ce qui a été choisi de ce coté là) alors les fonctionnalités seront présentes, mais si systemd n'est pas trouvé, il y aura juste moins de fonctionnalités, mais l'environement KDE sera toujours utilisable.
Maintenant ton message et certaines tournures de phrases de David me mettent un léger doute sur le fait que cela va continuer à fonctionner ainsi.
[^] # Re: Dépendance obligatoire ou optionelle
Posté par navaati . Évalué à 9.
Heu, comment dire…
Voilà. Stop au FUD.
[^] # Re: Dépendance obligatoire ou optionelle
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 2.
Vraiment ? Qu'appelle-t-on un environnement Gnome alors ? Jusqu'à très récemment (et encore aujourd'hui me semble-t-il) il m'était impossible d'installer Gnome, ou même simplement gdm sans systemd. En revanche gtk reste installable sans cette dépendance. Est-ce ce que vous entendez par « environnement Gnome » ?
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: Dépendance obligatoire ou optionelle
Posté par nud . Évalué à 10.
Tu peux installer gnome sans systemd, tu as juste besoin de libsystemd-whatever pour le côté "client dbus", mais tu n'as pas besoin de l'init system en lui-même.
Et ça sera vraisemblablement pareil avec KDE sauf si ta distribution s'amuse à compiler sans support pour systemd, ce qui risque pas d'arriver sauf si tu utilises gentoo ou assimilé.
[^] # Re: Dépendance obligatoire ou optionelle
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 2.
Justement pour Gentoo, il ne semble pas y avoir d'option d'installation d'une librairie libsystemd-… ?
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: Dépendance obligatoire ou optionelle
Posté par david.g . Évalué à 5. Dernière modification le 04 février 2015 à 13:41.
Sous Gentoo tu as deux types de profile pour GNOME:
eselect profile list
Available profile symlink targets:
…
[4] default/linux/amd64/13.0/desktop/gnome
[5] default/linux/amd64/13.0/desktop/gnome/systemd
Du coté de Funtoo, Daniel Robbins est même fier de proposer GNOME 3.14 en utilisant un système avec OpenRC. Certes il y'a quelques petits patch downstream pour que çà fonctionne, mais ce n'est visiblement pas impossible.
# Abstractions...
Posté par Seazor . Évalué à 10.
Je n'ai pas encore été lire le post de David, mais KDE a toujours eu l'habitude de faire des couches d'abstraction envers les API extérieures au projet (Phonon, Solid,…)
Après ca, il "reste" les différents backends à faire… et suivant les avancées, les fonctionnalités ne seront pas forcément égales dans tous les candidats.
Que certaines fonctionnalités aient un backend utilisant SystemD ne me pose pas vraiment de problème, et ne devrait a priori déranger personne ("yaka" faire les backends)
Maintenant, si c'est de la dépendance plus dure, ce sera plus délicat…
[^] # Re: Abstractions...
Posté par Antoine Mottier . Évalué à 1.
A priori la couche d'abstraction actuelle (kdisplaymanager) pose quelques problèmes :
L'enchaînement avec le paragraphe suivant :
me laisse penser que le choix s'oriente vers une suppression de la couche d'abstraction.
[^] # Re: Abstractions...
Posté par Seazor . Évalué à 9.
En gros, de ce que j'ai compris, aussi bien dans l'article de David que dans les commentaires ici, pour régler leur problème, ils ont besoin de plus que le dénominateur commun défini actuellement, et en ont marre de courir derrière les 5ou6 projets existants pour mettre à jour les backends. ("constantly broken")
En gros, ce sera quasi comme avant. La seule différence étant que l'abstraction sera toujours utilisée par KDE, mais sera assurée par Dbus. La définition de cette couche sera celle qui a été fournie par logind, et le backend sera celui qui pour le moment fait ce dont ils ont besoin, celui de logind.
Libre aux autres projets (kdm, consoleKit, etc) de s'installer à la place de logind, derrière la même interface Dbus et répondre aux appels lancés par Plasma (de préférence en faisant ce qui est attendu par KDE, quelle que soit leur manière de faire).
Et comme le montre le lien qu'il fournit dans son article, une implémentation de ces fonctions est même en développement pour BSD.
Quand Gnome a décidé d'utiliser SystemD, ont-ils pris le même principe ? si pas, qqun peut me résumer les différences ?
[^] # Re: Abstractions...
Posté par nud . Évalué à 4.
Exactement le même principe. Et on les a descendus en flamme en disant que KDE arrivait bien à faire tout fonctionner avec une couche d'abstraction :-D
# Adoption de systemd
Posté par Xinfe (site web personnel) . Évalué à 10.
Quand je vois à la vitesse à laquelle systemd se répand, ce n'est pas justement la preuve que c'est quelque chose d'élégant, efficace et fonctionnel ? Juste un choix pragmatique plus que politique.
Je veux bien comprendre que ça change des habitudes mais si au final on a quelque chose qui fonctionne bien sans avoir besoin de mettre ses propres scripts mal testés dans l'init, pourquoi s'en priver ?
Perso, le choix de l'init me touche pas plus que ça dans la mesure où je suis un utilisateur simple : je veux utiliser mon ordinateur pour bosser et me divertir. La bidouille, c'est plus occasionnel et j'ai un Pi pour ça.
Allez, souhaitons vite une intégration de Wayland, LibreOffice et Firefox dans systemd !
[^] # Re: Adoption de systemd
Posté par MTux . Évalué à 7.
Oui alors c'est parce que c'est une occasion de laisser RedHat faire tout le boulot au lieu de maintenir des scripts maison et des bidouilles.
[^] # Re: Adoption de systemd
Posté par Astaoth . Évalué à 9.
Un peu comme Internet Explorer par rapport à ses alternatives quoi.
Emacs le fait depuis 30 ans.
[^] # Re: Adoption de systemd
Posté par xcomcmdr . Évalué à -1.
LOL
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Adoption de systemd
Posté par Astaoth . Évalué à 0. Dernière modification le 03 février 2015 à 23:31.
C'est bien, y en a au moins quelques uns qui saisissent l'aspect humoristique de ma remarque.
Emacs le fait depuis 30 ans.
[^] # Re: Adoption de systemd
Posté par gst . Évalué à 1.
tragi-comique alors ;)
[^] # Re: Adoption de systemd
Posté par pasBill pasGates . Évalué à 8.
A l'époque ou il s'est répandu il était certainement bien meilleur que Netscape 4 oui. Il fut un temps ou IE5 et 6 étaient les meilleurs browsers existants.
Ensuite, son évolution les qques années suivantes… une autre histoire.
[^] # Re: Adoption de systemd
Posté par kursus_hc . Évalué à 2.
J'ai même le vague souvenir d'avoir vu IE5 en vente en version boîte à cette époque, quelqu'un peut confirmer ?
[^] # Re: Adoption de systemd
Posté par shbrol . Évalué à 1.
Surtout IE5, qui était disponible pour Solaris et HP-UX.
[^] # Re: Adoption de systemd
Posté par Le Gab . Évalué à 3.
Je suis curieux de savoir de quels services on parle qui nécessite une infra telle que SystemD et qui seraient restaurés tout seuls.
Quand un service déconne, ça n'a rien à voir avec l'init mais plutôt à un bug/exception; perte de réseau (ex nfs); file system full; etc… essayer de relancer le service sans corriger le problème au niveau du service lui-même, ça ne fait rien avancer.
Donc, à quoi sert systemd? Il n'exclue pas l'intervention d'un sysadmin pour remettre sur pieds le service/serveur applicatif.
Le boot rapide? je l'ai déjà depuis un moment.
[^] # Re: Adoption de systemd
Posté par xcomcmdr . Évalué à 0.
Pourquoi systemd ?
Une des réponses est là.
Mais systemd c'est bien plus que l'init. (logind remplace consolekit par exemple, et fait mieux que ce dernier)
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Adoption de systemd
Posté par Astaoth . Évalué à 2.
En effet, c'est aussi bientôt un bootloader (qui sert à lancer, entre autre, l'init).
Ce qui est louable, mais n'utilisant pas consolekit avant, je ne vois pas l'intérêt de le remplacer. Je trouve vraiment dommage que systemd ne soit pas sub-divisé en différents projets.
Emacs le fait depuis 30 ans.
[^] # Re: Adoption de systemd
Posté par xcomcmdr . Évalué à 1. Dernière modification le 04 février 2015 à 10:24.
Parce qu'il n'était plus maintenu et posait des problèmes de conception et de sécurité.
Ça n'aurait aucun sens, ils seraient toujours tous dépendants d'une partie du projet systemd.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Adoption de systemd
Posté par Astaoth . Évalué à 3.
Ils seraient remplacables surtout. Ainsi, les différentes interfaces exposés par les composants de systemd pour communiquer entre eux seraient devenus des standards de faits, et les autres projets (non systemd) auraient pu s'interfacer avec eux. Là, si on ne veut utiliser qu'une partie de systemd mais d'autres choses à la place de d'autres de ses composants, on se retrouve donc avec plusieurs programmes qui font la même chose d'installé, mais dont un seul est utilisé. Je trouve ca un peu ridicule.
Emacs le fait depuis 30 ans.
[^] # Re: Adoption de systemd
Posté par claudex . Évalué à 10.
Si, ça peut permettre de corriger le problème. Si sshd se crash, je préfère que systemd le redémarre1 pour pouvoir me logger sur la machine pour corriger le problème. Si chef-client ou puppet-machin se crash sur les clients, je préfère que systemd redémarre le processus pour pouvoir propager les mises à jour.
Il y a a plein de cas où un processus crash sur des cas particuliers qui n'arrivent pas souvent (voire n'arriveront plus jamais): paquet réseau bizarre, oom killer qui est passé par là, filesystem full mais qui a été vidé par une tâche cron entre temps, réseau qui est revenu, et ça vaut le coup de redémarrer le service en attendant de pouvoir le corriger.
et systemd ne fait pas ça n'importe comment, si un démon se crash trop souvent, il arrête d'essayer de le redémarrer. ↩
« 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: Adoption de systemd
Posté par Le Gab . Évalué à 0.
Mais dans ce genre de crash, en tous cas, le plus souvent, une relance ne corrige rien (corruption, filesystem full, etc…)
Dans le cas contraire, c'était faisable avec des scripts .sh que tout bon sysadmin doit maîtriser.
[^] # Re: Adoption de systemd
Posté par xcomcmdr . Évalué à 4.
Ou peut-être que le sysadmin en a marre de faire 100 fois le même problème.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Adoption de systemd
Posté par claudex . Évalué à 10.
Euh, le chef-client qui crash, je l'ai vu se crashé tout seul, et un redémarrage marche très bien (après, on peut corrigé le soucis qui l'a fait se crasher, mais c'est plus pratique s'il tourne à se moment là).
Bien, sûr, comme toutes de fonctionnalités de systemd (les langages étaient Turing complet avant systemd), il y a même d'autres outils qui faisaient déjà ça. Mais ça veut dire beaucoup de développement personnel pour adapter les scripts d'init. Avec systemd, si je veux que sshd redémarre en cas de crash, j'ai juste à ajouter un fichier /etc/systemd/system/sshd.d/restart.conf qui contient:
Et je n'ai pas besoin d'écraser un fichier fournit par la distribution, ni de l'adapter en cas de mise à jour. Accessoirement, ça facilite aussi la configuration automatique.
systemd, ce n'est pas une révolution des fonctionnalités mais une adaptation à l'adminsys d'aujourd'hui.
« 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: Adoption de systemd
Posté par totof2000 . Évalué à -5.
man inittab : respawn.
Pas besoin de systemd.
[^] # Re: Adoption de systemd
Posté par claudex . Évalué à 7.
man lecture des commentaires déjà écrits
« 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: Adoption de systemd
Posté par totof2000 . Évalué à -2.
man je lis de haut en bas donc j'ai pas vu le commentaire déjà écrit avant d'écrire le mien.
[^] # Re: Adoption de systemd
Posté par barmic . Évalué à 3.
Non pas besoin du tout, avec respawn on peut arrêter de relancer un service s'il plante à répétition, on peut relancer proprement des services en erreur (qui ont encore des processus qui tournent),…
Les cgroups c'est totalement inutile d'ailleurs. La preuve ? Avant on faisait sans.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Adoption de systemd
Posté par xcomcmdr . Évalué à 3. Dernière modification le 04 février 2015 à 17:29.
Et tu fais comment pour tuer une chiée de processus qu'un service a lancé (avec des double forks dans tous les coins, évidemment, donc plus de process tree) ?
(si possible, pas manuellement, hein… Le sysadmin, il est pas là pour être au service du système d'informations)
Sans cgroups, t'es baisé !
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Adoption de systemd
Posté par Albert_ . Évalué à 3.
Vous etes pas en train de melanger allegrement cgroup un truc du kernel avec un outil qui utilise cgroup?
[^] # Re: Adoption de systemd
Posté par xcomcmdr . Évalué à -7.
Ah tiens, un enculeur de mouches.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Adoption de systemd
Posté par Albert_ . Évalué à 1.
Tu es en train de dire que il afut systemd pour utiliser les cgroup? Car si c'est ca que tu dis c'est faux et comme je sais que c'est pas ca que tu dis, je en suis pas en enculeur de mouche je montre juste que systemd n'etait pas une obligation.
[^] # Re: Adoption de systemd
Posté par xcomcmdr . Évalué à -1.
Il te faut un outil qui contrôle les services efficacement, et cette manière efficace passe par l'usage des cgroups. C'est ce que te donne systemd aujourd'hui.
On pouvait certes utiliser les cgroups avant, mais on s'en fiche totalement ici.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Adoption de systemd
Posté par Albert_ . Évalué à 0.
Ah oui ta logique est imparable… je soupconne que les grecs anciens auraient quelques commentaire sur le sujet mais bon perso je prefere arreter maintenant.
[^] # Re: Adoption de systemd
Posté par Anthony Jaguenaud . Évalué à 3.
OpenRC ?
C’est compliqué à mettre en place ;-) par contre, il faut mettre dans
rc.conf:rc_controller_cgroups="YES". Donc, non, systemd n’est pas obligatoire ne vous en déplaise.[^] # Re: Adoption de systemd
Posté par xcomcmdr . Évalué à 0. Dernière modification le 04 février 2015 à 20:37.
J'ai pas dis qu'il était obligatoire.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Adoption de systemd
Posté par Albert_ . Évalué à 0.
Il faut savoir ce que tu veux mais en meme temps comme tu melanges allegrement systemd et cgroup pour justifier le premier c'est assez complique de te suivre. Oui toujours le meme probleme de logique.
[^] # Re: Adoption de systemd
Posté par barmic . Évalué à 3.
Je te retourne la question comment fait tu pour les utiliser dans inittab, puis que d'après toi c'est suffisant pour faire du redémarrage de service.
Qu'il existe autre chose que systemd pour le faire c'est évident, par exemple supervisor est capable de le faire, mais toi tu nous parle de l'option respawn de inittab. La seule solution propre et intégrée à sysvinit.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Adoption de systemd
Posté par Albert_ . Évalué à 3.
Non non moi je ne parle de rien de tout cela et surtout pas de respawn. Je viens juste dire que systemd et cgroup c'etait pas la meme chose. Tu te trompes d'interlocuteur.
[^] # Re: Adoption de systemd
Posté par totof2000 . Évalué à -6.
C'est le but de systemd : tout mélanger.
[^] # Re: Adoption de systemd
Posté par xcomcmdr . Évalué à 10.
C'est le but de totof2000 : troller comme un goret.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Adoption de systemd
Posté par octane . Évalué à 10.
Cet argument de redémarrage qui tend à "prouver" que systemd fait bien les choses est quand même étonnant.
init, le bon vieux binaire qui date du millénaire dernier sait redémarrer des démons qui se sont arrétés, man inittab pour les détails. Le fichier contient des lignes:
id:niveaux_exécution:action:processus
Avec l'action qui peut être respawn afin de redémarrer le processus après son arrêt (ou plein d'autres choses comme once, bootwait, etc..). Et init ne fait pas ça n'importe comment, si un démon se crash trop souvent, il arrête d'essayer de le redémarrer (vous n'avez jamais lu: "XXX is respawning too fast, disabled for 5mn" ?)
J'utilise systemd car j'utilise une distribution qui l'a mis par défaut, mais j'ai toujours autant de mal à comprendre les arguments des pro-systemd qui annoncent des fonctionnalités aussi anciennes comme étant une révolution dûe à la génialité de systemd. Un état d'esprit proche des apple fanboy? Je ne sais pas.
[^] # Re: Adoption de systemd
Posté par Spack . Évalué à 7.
+1 pour
respawnque j'utilise. On ne peut cependant pas dénier que systemd apporte un paquet de simplifications comme les fichiers Unit, le démarrage parallèle, la gestion intégrée des conteneurs, etc…Seul l'aspect bloatware me fait un peu peur (beaucoup de différentes fonctions à gérer pour un seul projet) mais si cela permet d'avoir une gestion plus intégrée, pourquoi pas ? Une organisation du projet en sous-systèmes un peu à la manière du noyau pourrait aider sur ce point.
[^] # Re: Adoption de systemd
Posté par claudex . Évalué à 10.
Je vais encore l'écrire une fois : systemd n'invente pas grand chose mais il simplifie la façon de faire. Par exemple, avec inittab, on ne peut pas lui spécifier d'arrêter de respawner la config. Avec systemd, un systemctl stop chef-client, stop le service le temps que tu fasse ta maintenance (tu peux aussi modifier la config inittab, sighup init, remodifier après, mais il ne faut pas oublier, avec systemd, un reboot redémarrera le service vu qu'on aura toucher à aucune conf). Autre point, la possibilité de modifier la configuration sans toucher les fichiers de la distribution. Encore un avantage, c'est l'utilisation des cgroups, avec init si le service à redémarrer a des enfants, il ne me semble pas qu'ils seront tués au redémarrage, ce qui peut poser problème en fonction des services, avec systemd, ce sont tous les processus appartenant au cgroup qui seront tués, ça évite de se retrouvé avec des process un peu partout.
Toutes ces choses rendait plus compliqué l'utilisation d'init pour redémarrer un service, ce qui fait que peu de monde l'utilisait au final.
Je te signale qu'ici, le premier qui a parlé de cette fonctionnalité, c'était pour critiqué systemd. Personne n'a débarqué en disant que ça révolutionnait le monde.
« 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: Adoption de systemd
Posté par Tonton Benoit . Évalué à 10.
respawn, magnifique, sauf que ça marche pas avec les processus forkés et de fait avec rien de ce qui se trouve dans /etc/init.d
Utiliser une fonctionnalité historique qui n'est plus utilisée que pour lancer le rc lui-même et les tty afin de nier l'utilité de systemd, comment dire ?
Sous Debian avec SysvRC y'a aucun moyen de faire un vrai suivi de processus, on à même lancés des dizaines de projets pour pallier à ce manque (runit, munit, deamontools, supervisord…) et aucun de ces projet ne s'est vu reprocher de ne servir à rien car y'a déjà l'inittab.
# Attends Roger, on est déjà vendredi ?!
Posté par needs . Évalué à 10.
Nan mais hips Roger, t'as entendu bon dieu ? Ouai nan mais c'est hips scandaleux… Snuuurff Vindious J'te l'avais dit ! ha! de toutes hips façon j'ai un peu envie de dire que vu comme KDE est hips bloated, je trouve que leur décision est assez co -hips- rhérente. Voila.. Nan mais hips t'as compris ou bien ? ouai D'ailleurs je comprends hips comprends toujours pas comment GNAULE il.., hein? Ouai GNOME, c'est bien qu'est-ce-que j'ai dit, ouai donc GNAULE, et ben hips je vois pas comment il fait pour ne pas être hips dépendant de systemd… m'enfin les gars hips ! Réveillez vous ! Rhaaaa
Snurrflll, boaf puis bon, hé! , les BSD, ouai, les BSD, ils nous hips cassent les co*illes à vouloir toujours faire hips faire différent, bien fait pour eux, ha!. Nan mais ho hips ! mais c'est vrai quoi, pff, hips..
Ouai nan mais c'est ça hips… T'sais quoi ? hips J'ai hâte que systemd deviennent dépendant de béteur-fesse, quoi? Mais oui tu sais là hips… le système à fichiers tout nouveau qu'ils disaient, hips. Voila, c'est ça, avec les bize-tri, ouai, je sais pas, hips c'est des arbres à deux hips branches j'crois, haha, 'doivent pas être bien beaux ses arbres hips…, OUAI donc qu'est-ce-que je disais, voila, béter-eiffel, hips et ben on pourra avoir toutes les applications sandboxed dans des hips containers
docker-systemd, qu'ils disaient ha. Ha nan mais t'es c*n bon dieu, hips pas les containeurs du port, hips, nan les containeurs DOCKER… Snurrrfll… Pfff, hips, laisse tomber tu comprends rien à rien, vin -hips- dious.RogeeeEEEEERRR hips ! Mais qu'il est ou bon sang..
Ouai, Snurrrfll, ah oui la dernière fois hips, ouai, hier jcroa bien hips, y'a Labévu qui est venu, Rhoooaaa, ça faisait hips longtemps.. Il disait qu'il fallait mettre une baise hips de donnée dans systemd, qu'il disait hips, SQL ouai, hein? OUAI dans le cloud, hips, quoi? le claoud, le claude… Tsé bien, le nuage, bon dieu.. T'es bou - hips - ché ou quoi ? Rhaaa
Roger… ROGEERRRRR, Une bièèèèèè hips èèèree !
# Borg
Posté par Arthur Accroc . Évalué à 10.
You will be assimilated. Resistance is futile.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
# Youhou faut coder !
Posté par cedric . Évalué à 10.
Bon, je participe sur un desktop autre que KDE ou GNOME, mais on discute pas mal entre developeur de nos petits problemes respectif et ils sont souvent identique. Il faut bien voir un truc simple, maintenir les 15000 abstractions differentes pour chaque distribution passe et a venir, c'est un boulot que meme KDE ne peut plus se permettre. systemd propose un standard et en general leur solution sont bien pense et facilement utilisable. De plus contrairement a la croyance general, on peut reimplementer ce standard dans la distribution facilement (voir sur un autre noyau).
Oui, et ca c'est une evidence, le but des desktops est de pousser le travail de specialisation dans les distributions. Il faut bien voir que la capacite des differents environnement de bureau a maintenir plein de variante a ses limites. Combien de developpeur implique dans KDE utilise encore Ubuntu ? Combien utilise un BSD ? Repeter la question pour chaque environnement. La question devient alors, pourquoi les utilisateurs de ces environnements sous ses distributions/kernel different ne s'impliquent pas ? Pourquoi ils ne font pas d'effort de portage ?
Le comportement classique et celui-ci est le meme pour tous les utilisateurs de GNOME, KDE et Enlightenment, est d'attendre la release pour enfin tester si ca marche chez eux… Et si ca marche pas, ils vont majoritairement grogner sur un forum, peu ouvriront un bug report et encore moins un bug report utile. Bien entendu si vous voulez que votre alternative continue de bien se porter avec votre environnement favori, il faudrait compiler les versions beta a minima et faire des bugs report utile (J'irais meme jusqu'a rever et dire proposer des patchs…).
C'est bien joli de grogner sur systemd, mais ca repond a un vrai probleme, la factorisation du code et la redirection de l'effort de developpement pour ameliorer le projet, plutot que de perdre du temps dans quelque chose qui devrait juste marcher ! Bien entendu, il faut compter avec le vieillissement des contributeurs et la tendance au non renouvellement de la base de developpeur. Ce qui fait que le choix entre faire de la maintenance inutile ou ameliorer le systeme accelere ces choix…
Donc petit scoop, avec le temps, il n'y aura que les interfaces avec systemd qui seront bien supporte si vous ne vous bougez pas pour maintenir le morceau qui vous interresse.
[^] # Re: Youhou faut coder !
Posté par Trollgouin . Évalué à 6.
J'ajouterais que la nécessité (sans systemd) de re-coder toutes ces petites abstractions génère non seulement du boulot en plus comme évoqué précédemment, mais aussi une bonne quantité de bugs dans ces parties!
J'espère même que ça va simplifier le boulot d'administration pour régler tous ces problèmes pénibles où quelque-chose fonctionne sur un bureau et pas sur un autre. Je veux bien apprendre plus de systemd pour déboguer, mais je n'est pas envie de m'investir à étudier finement les couches d'abstraction de chacun des bureaux de mes utilisateurs.
Je me demande aussi si l'intégration de beaucoup de petites abstractions dans systemd ne va pas simplifier le développement des petits WM (je pense entre autres à i3) en leur donnant un accès à des informations qu'ils se refusaient à aborder pour éviter de faire trop grossir leur code…
[^] # Re: Youhou faut coder !
Posté par freem . Évalué à 3.
Euh… i3 n'en à rien à faire de la taille de son code, c'est pas twm ou ratpoison hein. i3 limite ses fonctionnalités, pas le code. Et comme il ne s'agit «que» d'un gestionnaire de fenêtres, je ne vois strictement aucune raison pour qu'il dépende, de près ou de loin, de l'init.
[^] # Re: Youhou faut coder !
Posté par cedric . Évalué à 2.
Pour par exemple avoir le support Wayland…
[^] # Re: Youhou faut coder !
Posté par freem . Évalué à 2. Dernière modification le 09 février 2015 à 15:03.
Wayland est un protocole, qui ne dépends pas de systemd.
Il me semblait que weston, l'implémentation de référence, utilisais dbus, et je pensais que c'est pour ça que tu disais ça… maintenant il semble qu'il y ait également une dépendance à libsystemd (sous Debian en tout cas).
Bien. Mais justement: libsystemd est une lib qui permets d'utiliser des fonctionnalités systemd si celui-ci est disponible sur le système. C'était d'ailleurs une réplique habituelle aux trolls sur systemd, sur la ml internationale de debian.
Donc, utiliser systemd n'est absolument pas nécessaire pour supporter wayland. Conséquence: le support de systemd n'est pas nécessaire à i3 s'ils veulent supporter wayland. Sauf erreur de ma part.
[^] # Re: Youhou faut coder !
Posté par cedric . Évalué à 2.
Il est impossible de faire tourner une implementation de Wayland (Weston, KWin, GNOME, Enlightenment) sans logind. Et ne vient pas me faire rire qu'il suffit de faire les faire tourner en root pour regler le probleme :-)
Apres, c'est un protocole, donc si tu as une solution alternative qui marche et fourni logind, tu n'auras pas besoin de systemd lui meme…
# Et la conclusion ?
Posté par Pinaraf . Évalué à 10.
Il suffit de lire la conclusion…
«As maintainers we have a duty to balance what will provide the best experience for the majority of our Plasma users without leaving anyone with a broken system. Projects like this bring the interfaces we need to BSD and as it gets more stable we should be able to start distributing features.»
En tant que mainteneurs, nous avons le devoir d'arbritrer ce qui fournira la meilleure expérience pour la majorité des utilisateurs de Plasma sans laisser personne avec un système cassé. Des projets comme celui-ci [https://uglyman.kremlin.cc/gitweb/gitweb.cgi] implémentent les interfaces dont nous avons besoin sur les systèmes BSD, et leur stabilisation nous permettra de commencer à distribuer des fonctionnalités.
Ce n'est pas flou. Du tout. Plasma va dépendre des APIs DBus implémentées sous Linux par systemd pour certains services. Point. L'absence de ces APIs rendra les-dits services non utilisables. Ça s'arrête là. Comme à l'époque de HAL par exemple, les utilisateurs BSD auront un léger retard sur certaines fonctionnalités. C'est tout. Et c'est pas une dépendance à libsystemd.so ou équivalent, juste une dépendance à un service dbus…
[^] # Re: Et la conclusion ?
Posté par Le Gab . Évalué à 1.
Avec 1 000 000 $, entre autre, BSD devrait pouvoir bloquer 1 ou 2 dev pour créer le support. A moins qu'ils dépensent ce fric dans un projet OPW. :p
[^] # Re: Et la conclusion ?
Posté par robin . Évalué à 3.
Pour ma culture, que veux dire OPW ? Je suis aller regarder sur duckduckgo, mais il y avait trop de sens différents pour cette abréviation.
bépo powered
[^] # Re: Et la conclusion ?
Posté par Moonz . Évalué à 3. Dernière modification le 04 février 2015 à 15:24.
http://gnome.org/opw/
Qui avait reçu des critiques de devs gnome selon lesquels l’argent pour le programme aurait pu être mieux utilisé.
[^] # Re: Et la conclusion ?
Posté par robin . Évalué à 1.
merci !
bépo powered
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.