Salut, nal,
Lors du dernier dist-upgrade, j'ai encore eu systemd qui s'est glissé dans les dépendances à installer. Et je ne sais pas trop comment, j'ai eu un éclair de génie à propos d'un outil que j'utilise d'habitude dans un sens, mais dont j'ai réalisé l'utilité dans un autre : apt-mark (enfin, c'est une fonctionnalité de dpkg à la base, il enrobe juste les choses).
En effet, on peut par exemple avec cet outil marquer des paquets qu'on avait installés manuellement comme devant être de nouveau gérés automatiquement (marque auto), ou alors demander de garder la version actuelle d'un logiciel malgré les mises à jour qui pourraient arriver (comme quand on a fait une version sur mesure d'un paquet ; marque hold). C'est cette dernière marque qui peut être utile dans l'autre sens : si on a déjà auparavant supprimé un paquet, et qu'on marque ce paquet comme étant « bloqué », le calcul des dépendances d'installation se fera toujours en essayant de garder non-installé ce paquet ! C'est peut-être évident pour certains, mais je n'avais encore jamais pensé à l'utiliser comme ça.
Ça donne, en root (pour l'aventure) :
apt-get remove systemd
apt-mark hold systemdapt-get avec joie !
# Sinon
Posté par pikapika . Évalué à 10. Dernière modification le 26 novembre 2014 à 23:52.
J'ai ça :
cat /etc/apt/preferences.d/systemd
Package: systemd
Pin: origin ""
Pin-Priority: -1
Pour l'instant, ça m'a préservé de systemd
# Mwai
Posté par gnumdk (site web personnel) . Évalué à 10.
Et sinon, ça vous dit pas de changer de distrib plutôt que de poster des journaux inutiles?
Quand systemd sera le seul init disponible, vous ferez comment? :p
[^] # Re: Mwai
Posté par groumly . Évalué à 10.
Ils prendront le probleme main une bonne fois pour toute.
En faisant une e-petition pour demander a lennart d'aller elever des chevres dans le larzac.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Mwai
Posté par lolop (site web personnel) . Évalué à 10.
C'est pas sympa pour les chèvres !
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: Mwai
Posté par Sébastien Wilmet . Évalué à 10.
C'est surtout pas sympa pour les développeurs de systemd !
Toutes ces attaques gratuites envers systemd et ses devs (en particulier Lennart Poettering, mais c'est loin d'être le seul dev de systemd), ce n'est pas un comportement très civilisé. Lennart a écrit un article sur google plus à ce sujet:
Bref, ça va un peu trop loin.
[^] # Re: Mwai
Posté par Kaane . Évalué à -10.
Bref, ça va un peu trop loin.
Autant les menaces de mort ou les injures je suis contre, autant les invitations à considérer l'élevage de chèvre ou le tricot comme reconversion professionnelle je suis tout à fait pour.
La communeauté Open Source est pleine de connards certes, mais c'est clairement pas lui qui va faire baisser les stats.
[^] # Re: Mwai
Posté par Zenitram (site web personnel) . Évalué à 9.
Ha oui, quand on est pas d'accord avec une personne, on l'insulte, c'est tellement productif (ça serait trop improductif de plutôt passer son temps à coder une alternative meilleure et à convaincre qu'elle est meilleure).
Merci pour le commentaire (ce n'est pas le seul dans le genre) très révélateur de la manière de (non) penser des anti-systemd.
[^] # Re: Mwai
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 10.
Les généralisations outrancières, c'est le mal.
[^] # Re: Mwai
Posté par groumly . Évalué à 10.
En general, oui.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Mwai
Posté par Kaane . Évalué à 2.
de la manière de (non) penser des anti-systemd
Houlà attention, je suis anti-Lennart - mais je n'ai absolument rien contre systemd. C'est un produit qui ne me concerne pas et dont je n'ai pas (et n'aurai probablement jamais) l'usage. Ceci dit je comprend parfaitement qu'il puisse servir - juste pas du tout pour mes besoins.
[^] # Re: Mwai
Posté par jben . Évalué à 8.
Ah. Autant j'arrive à comprendre les gens qui sont contre une solution, même si je ne partage pas leur avis. Autant je conçois que le fait d'être contre une solution peut avoir tendance à se situer en opposition avec son développeur, même si cela ne me semble pas être le plus constructif.
Mais là tu dis que tu n'a rien contre systemd, mais que tu voudrais refroidir, ou du moins bâillonner Lennart. Très bien. J'espère juste que tu n'es pas armé.
[^] # Re: Mwai
Posté par Kaane . Évalué à 6.
Mais là tu dis que tu n'a rien contre systemd, mais que tu voudrais refroidir, ou du moins bâillonner Lennart.
Euh non, j'ai juste dit que l'inviter à élever des chèvres dans le Larzac ne me choquait pas outre mesure. Si il faut détailler :
a) Je ne considère pas que d'inviter quelqu'un à élever des chèvres dans el Larzac n'est pas une menace ou une agression telle qu'elle devrait faire l'objet de l'opprobe populaire
b) Je ne considère pas non plus que ce serait une perte pour Linux, ou l'Open Source en général si L.Pottering en venait à se détourner de l'écriture du code pour Linux.
Je ne souhaite ni sa mort ni sa mutilation, mais très honnêtement son retrait partiel ou total du monde Linux ne me touchera pas. Maintenant à l'inverse son maintien dans Linux, avec sa capacité à détruire l'expérience utilisateur et son dedain vis à vis de toute tentative de création d'environnement un poil perenne, me casse franchement les pieds.
[^] # Re: Mwai
Posté par Zenitram (site web personnel) . Évalué à -5.
J'adore les gens qui disent le contraire de ce qu'une personne fait pour explication de pourquoi il ne l'aime pas.
La vérité semble différente : tu ne l'aimes pas justement parce qu'il aide dans l'expérience utilisateur et créé un environnement pérenne, alors uqe tu veux un truc conservateur qui ferait toujours "comme avant" (donc chiant, pas pour rien que tout le monde veut changer) qui ne change pas tes habitudes à galérer pour le plaisir.
Salaud de personnes qui dérangent les gens qui voudraient que tout reste "comme avant". Rigolo de constateur le mensonge que tu fais à toi-même en disant que tu voudrais certaines choses mais rejette ces choses quand elles sont faites.
PS : on attend toujours ta solution alternative, depuis le temps où tu penses qu'il a faux.
[^] # Re: Mwai
Posté par Kaane . Évalué à 10.
La vérité semble différente : tu ne l'aimes pas justement parce qu'il aide dans l'expérience utilisateur et créé un environnement pérenne
Oh mon dieu tu as raison. Je ne m'en rendais pas compte parce que j'avais un blocage psydhologique, que lui même a déclaré que la poursuite d'un environnement pérenne était idiot et que Kay Sievers ET Greg KH l'ont appuyé dans cette décision. Je ne m'en rendais pas compte non plus parceque jusqu'à présent j'avais un environnement pérenne et que donc au moment ou je l'ai gardé ca a fait un tel choc que j'ai fait un rejet.
Je te félicite pour tes talents de psychanaliste, et d'ailleurs je te conseille vivement d'aller également élever des chèvres dans le Larzac, ce serait dommage que tu fasses usage de ce talent sur une personne sensible - là pour le coup vu tes capacités il pourrait y avoir des victimes.
on attend toujours ta solution alternative
Tu vas attendre longtemps, comme déjà dit plusieurs fois, y compris à toi
a) Je n'ai aucun problèmes avec les solutions existantes
b) Ecrire une alternative à systemd nécessite quasiment de devoir recréer toute une distribution
c) Je suis AdminSys/architecte pas développeur système.
[^] # Re: Mwai
Posté par Zenitram (site web personnel) . Évalué à -10.
Donc tu n'auras aucun problème à les maintenir. (tu dis bien que tu n'as aucun problème, donc pas possible que tu ais un problème)
Ou est le problème avec systemd qui ne sera jamais chez toi puisque tu maintiens une version sans systemd?
A moins que tu mentes, et que ton problème avec l'existant est que plus personne ne veut faire le boulot pourri de maintenance à ta place car il y a mieux.
Ha oui, surtout insulter, dire de dégager, quand on est mis face à ses propres contradictions…
Ton métier (AdminSys/architecte qui n'aime pas systemd) va disparaitre, le problème va donc être plutôt ce que toi tu vas faire.
(Bon, je sais, en pratique tu vas râler pendant quelques années et après faire comme tout le monde : soit t'adapter et utiliser systemd en cachant le fait que tu étais contre avant, soit partir à la retraite).
[^] # Re: Mwai
Posté par Kaane . Évalué à 10.
Donc tu n'auras aucun problème à les maintenir.
Aucun non. C'est très simple un système d'init quand c'est pour tes besoins à toi.
Ou est le problème avec systemd
Une fois de plus je n'ai aucun problème avec systemd.
A moins que tu mentes, et que ton problème avec l'existant est que plus personne ne veut faire le boulot pourri de maintenance à ta place car il y a mieux.
J'ai plutôt le problème inverse, ni Red hat ni Suse n'ont accepté de garantir une maintenance quelconque de nos systèmes si on passait sous systemd.
Ha oui, surtout insulter, dire de dégager, quand on est mis face à ses propres contradictions…
Est-ce que tu peux pointer une contradiction s'il te plait ?
Ton métier (AdminSys/architecte qui n'aime pas systemd) va disparaitre, le problème va donc être plutôt ce que toi tu vas faire.
Tu es madame Irma en plus d'être psychanaliste ? Enfin bon avec les contrats que l'on a avec IBM d'un coté et Intel de l'autre je ne me fais pas trop de soucis pour mon métier. Et une fois de plus j'en ai rien à cirer de systemd, vu que je ne l'utilise pas.
soit t'adapter et utiliser systemd en cachant le fait que tu étais contre avant
Une dernière fois je ne suis pas contre systemd. Je ne peux matériellement pas me servir de systemd même si je le voulais, et en plus je ne veux pas.
[^] # Re: Mwai
Posté par Anonyme . Évalué à 3.
Ce qui ne t'empeche pas de savoir exactement comment doit etre fait un systeme de boot.
C'est souvent comme ca. Des experts pour venir t'expliquer que tu fais n'importe quoi, il y en a des tas. Mais beaucoup moins pour fournir des patches.
[^] # Re: Mwai
Posté par Adrien . Évalué à 10. Dernière modification le 27 novembre 2014 à 18:04.
À mon avis tu te trompes de cible… Pottering développe un logiciel libre, c'est quand même son droit, il n'y a rien à critiquer là dessus.
EDIT : En plus c'est faut, Pottering ne « détruit » rien, il ajoute ses travaux au reste !
Après plein de gens utilise massivement ses logiciels. Donc deux choses :
– soit Pottering fait du lobbying intense pour que tout le monde utilise ses logiciels… dans ce cas, je veux bien tes sources d'info
– soit beaucoup de gens trouvent ses logiciels intéressants, et les utilise… Dans ce cas, la seule solution démocrate c'est de convaincre les gens d'utiliser autre chose.
Comme on est dans le monde du logiciel libre, tu peux créer des alternatives à ses logiciels, et c'est d'ailleurs la voie recommandée… celle qu'à suivie Pottering par exemple, pour « imposer » ses logiciels.
Pense que dans la vraie vie, c'est nettement plus violent. Tiens, en ce moment on « impose » à l'éducation supérieure et la recherche les « COMUE ». Malgré 800 directeurs d'unités (sur 1200) contre, des avis de comité technique contre, le Conseil national du CNRS contre, les syndicats contre, ça va a priori se faire. À côté, Pottering passe vraiment pour une lopette dans sa logique de domination du monde.
[^] # Re: Mwai
Posté par gnumdk (site web personnel) . Évalué à 4.
Ah, chez moi les "COMUE" sont déjà en place ;)
[^] # Re: Mwai
Posté par Adrien . Évalué à 2.
Chanceux va ! ;-)
[^] # Re: Mwai
Posté par needs . Évalué à 3.
C'est un petit peu des deux. systemd est intéréssant, mais systemd est trop complexe, trop gros (80 binaires qui font des choses totalement différentes et normalement indépendante : logind, udev, networkd, …), et enfin difficile à maintenir. D'un autre côté, systemd est plus « performant », plus standardisé, peut-être plus facile à utiliser pour les developeur.
Le fait que Lennart travail pour RedHat, et le fait que RedHat controle quasi entièrement Fedora et RHEL a fortement aidé à l'adoption de systemd. Le libre, ce n'est pas que des gens qui travaillent sur leur temps libre.
Si on me paye pour ça, si on me donne la capacité de le mettre ensuite par défaut dans deux des plus grosses distributions Linux, je fonce, comme Lennart. Sortir cet argument à chaque fois c'est vraiment de mauvaise foi.
En plus il est fait en sorte que se soit difficile d'écrire une alternative car ils « standardisent » tout, en utilisant dbus, même des modules qui sont en théorie parfaitement indépendant d'un système d'initialisation,
udevetnetworkdsont les exemples parfait. Ensuite les pro-systemd viennent dire : « Ah mais tu peux réécrire chaque module de systemd, ils sont totalement indépendants car ils utilisent une interface dbus standardisée ». Beuuuuurk.Autre gros point faible: quasi tout les projets de Lennart sont très mal documentés.
[^] # Re: Mwai
Posté par Zenitram (site web personnel) . Évalué à -2.
Si c'est à la Linux (le noyau), c'est horrible un gros binaire
Si c'est à la Linux (l'idée un outil par tache), c'est horrible trops de binaires.
Et puis, Debian c'est trop gros (tu te rends comptes, des milliers de paquets), c'est pas bien…
Argument présent uniquement pour avoir un truc à dire, mais ça reste pourri.
Clair, une distro (en plus du rpm "qui pue") ça impacte toutes les autres ditros (même celles qui aiment deb, tiens d'ailleurs pourquoi deb est toujours la alors que rpm est utilisé par RH et Fedora?)
Argument pourri encore.
La c'est plus que pourri, c'est carrement du mensonge foutage de gueule en espérant que les gens ne réfléchissent pas.
Impressionnant tout ce qu'on peut inventer quand on a décidé d'être contre sans avoir régardé, juste pour le principe (et ensuite on invente tout ce qu'on peut pour ne pas changer de position).
Et plus ça va dans le temps, plus les anti-systemd doivent chercher loin de chez loin dans leurs "explications"…
[^] # Re: Mwai
Posté par needs . Évalué à 2.
Mon dieu, tu mélanges tellement tout…
…Mais ne me fait pas dire ce que je n'ai pas dit.
Pour avoir tenté de configurer PulseAudio à la main, pour avoir tenter d'utiliser DBus (abandonné devant l'horreur du truc, essayes), OUI, LA DOCUMENTATION DES PROJETS DE LENNART EST À CHIER. D'ailleurs, je tente régulièrement tout les mois (ou les deux mois) de mettre pulseaudio sur ma machine, mais il refuse toujours de marcher, toujours, toujours, TOUJOURS. Et oui je reprend a chaque fois la doc, j'y passe des heures, je ne déconne pas, juste parce-que j'ai besoins de skype pour des clients ou des amis.
Je rêve…
[^] # Re: Mwai
Posté par Prosper . Évalué à 10.
Dbus n'est pas un projet de lennart mais de Havoc Pennington , donc tu cites UN seul projet de lennart que TU trouves mal documenté , personnellement je trouve que avahi ou systemd ( qui sont pour le coup la des projets initiés par lennart ) sont plutôt TRES bien documenté .
C'est quand même dingue cette fâcheuse habitude de cracher sur Lennart même sur des trucs qu'il n a pas fait, on le voit souvent accusé d'avoir aussi commis network-manager.
[^] # Re: Mwai
Posté par gnumdk (site web personnel) . Évalué à 4. Dernière modification le 28 novembre 2014 à 08:28.
yum install pulseaudio
pacman -S pulseaudio
apt-get install pulseaudio
zypper in pulseaudio
Vas y, explique nous la distrib pourrie que tu utilises… Le projet est très bien documenté: http://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/
Après, il faut la lire et la comprendre… Mais ça reste le boulot des intégrateurs, je ne connais plus une seule distrib ou pulseaudio ne fonctionne pas out of the box.
Idem pour dbus, 1erement ce n'est pas un projet de lennart mais d'un dev de gnome, tu confonds avec udev, ça montre ton niveau d'incompétence.
[^] # Re: Mwai
Posté par barmic . Évalué à 5.
Je suis très content de PA, mais les débuts ont été difficile (au moins sous Debian sur mes machines).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Mwai
Posté par GnunuX (site web personnel) . Évalué à 3.
Les difficultés étaient dû à PA ou alors PA étaient le révélateur de problème dans les drivers audio ?
[^] # Re: Mwai
Posté par barmic . Évalué à 3.
En quoi le fait qu'il est possible qu'il y ai des bug dans les drivers dédouanes PA d'être fiable ? Que certaines fonctions ne marchent pas parce que ce n'est pas possible vu l'état d'un driver c'est une chose, ne pas avoir de son du tout alors que le driver permet techniquement de le faire (ALSA y arrivait) c'était un vrai problème.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Mwai
Posté par Renault (site web personnel) . Évalué à 4.
Sauf que Alsa contenait une grande liste de correctifs pour palier les bogues des pilotes pour communiquer avec ces cartes là, PulseAudio ne l'a pas fait (si le pilote est mauvais, on corrige le pilote ou le périphérique mais pas le serveur de son…).
Bref, non, ce n'est pas si déconnant que ça.
[^] # Re: Mwai
Posté par gouttegd . Évalué à 5.
Je ne comprends pas, là. PulseAudio est en aval de ALSA (ou en amont, ça dépend du point de vue), si ALSA fait le nécessaire pour « palier les bogues des pilotes », PulseAudio devrait en bénéficier automatiquement (comme n’importe quel programme qui utiliserait ALSA directement)…
Pourquoi faudrait-il que PulseAudio refasse ce qui est déjà fait dans ALSA ?
[^] # Re: Mwai
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 5.
C'est une supposition, mais je pense que PA utilise seulement l'API bas-niveau de Alsa pour pouvoir faire ce qu'il veut faire.
[^] # Re: Mwai
Posté par GnunuX (site web personnel) . Évalué à 6.
Si je résume … s'il y a un problème dans l'espace noyau, le responsable n'est pas le noyau et il n'est pas nécessaire de faire des corrections. C'est à l'espace utilisateur de s'adapter aux bugs. C'est bien cela ton point de vue ?
Je suis bien content que Lennart ne soit pas de ton avis :)
Il y eu aussi des discussions au moment du développement de gnome-shell ou firefox sur les problèmes liés aux drivers graphiques. Je suis bien content également qu'il n'y ait pas de contournement hideux dans ces logiciels.
A titre personnel je ne suis pas nostalgique de l'avant PA en tout cas …
[^] # Re: Mwai
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 5.
Je me rappelle encore de l'époque où il fallait écrire un fichier de config pour dmix à la main… Et même avec ça on avait pas le quart des fonctionnalités de PA.
C'est de plus en plus difficile de savoir ce que fait sa machine, mais c'est aussi de plus en plus facile de l'utiliser.
[^] # Re: Mwai
Posté par fearan . Évalué à 3.
Moi je me souviens très bien de l'arrivée de pulseaudio, qui a foutu en l'air plein de truc qui marchaient; perso j'étais sous arts (artsd) à l'époque, j'avais tout qui marchait, (dont l'usage à travers de réseau), et lorsque pulseaudio a été imposé par la distrib, ça a tout cassé.
Bon aujourd'hui ça marche, (encore que je n'ai pas encore essayé le réseau, j'en ai plus besoin), mais sachant qu'a l'époque il y'avait déjà jack (jackd), qui faisait la même chose, je me demande s'il était vraiment nécessaire de pousser un truc aussi immature dans les grande distributions, un peu comme kde4.0…
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Mwai
Posté par Prosper . Évalué à 5.
Non justement , ils ne font pas la même chose et n'ont pas le même but
http://0pointer.de/blog/projects/when-pa-and-when-not.html
[^] # Re: Mwai
Posté par fearan . Évalué à 0.
1) c'est vendredi, j'ai le droit :)
2) MacOS le fait bien,
3) Arts répondait déjà au besoin autre que professionnel, pourquoi développer un nouveau truc?
4) j'aime bien déterrer les vieux trolls ;)
5) c'est vendredi.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Mwai
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 5.
Sauf erreur de ma part, aRts a cessé d'être développé en 2004 (due to a variety of fundamental development and technical issues, cf wikipedia), et pulseaudio a été installé par défaut sur Ubuntu (une des premières distribs à l'avoir installé par défaut) à partir de 2008.
Et puis faire marcher l'ensemble des applis Linux à l'époque de aRts, il fallait quand même drôlement s'accrocher, avec des couches de compatibilité dans tous les sens, parce qu'entre oss, alsa, aRts, et esd, c'était pas folichon.
Et pulseaudio fait bien plus que ce que faisait aRts (une gestion simple du multi carte-son, ce qui est loin d'être un cas particulier aujourd'hui).
[^] # Re: Mwai
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 3.
Je rajoute aussi que systemd n'est pas un système d'init. C'est un ensemble de logiciels bas niveau (tout comme kde est un ensemble de logiciels graphiques). Du coup, oui, il est moins complexe à comprendre que ce qu'il remplace.
[^] # Re: Mwai
Posté par Yann Hodique (site web personnel) . Évalué à 7.
C'est simpliste comme raisonnement. La question n'est pas celle de la responsabilité (évidemment que le composant qui a le bug est responsable, et doit être corrigé), mais du maintien des fonctionnalités: si il existe un moyen de faire marcher, aussi moche soit-il, il est normal que tout composant ne l'utilisant pas soit perçu comme fautif.
En gros, non il n'est pas normal de remplacer un composant qui marche par un autre qui marche moins sous prétexte qu'un tiers est pourri. La bonne démarche est de (faire) corriger les bugs, puis seulement de procéder au remplacement, et d'utiliser les contournements dans l'intervalle. Forcément ça prend plus de temps (notamment parce qu'on ne peut pas mettre la pression sur le composant fautif par le biais d'utilisateurs frustrés), mais au moins il n'y a pas de dommages collatéraux.
Sinon en allant par là on pourrait aussi estimer que les applis n'ont pas à contourner les bugs des libs, les libs n'ont pas à contourner les bugs des drivers, les drivers n'ont pas à contourner les bugs du noyau, le noyau n'a pas à contourner les bugs du compilateur, et le compilateur n'a pas à contourner les bugs du CPU (et du reste du matos d'ailleurs). Alors oui, à la fin on aurait sans doute un système très élégant où tout le monde fait exactement ce qu'il doit…
Ou alors peut-être qu'on n'aurait rien du tout parce que tout le monde serait en train d'attendre qu'un fondeur produise le CPU parfait, alors qu'aucun fondeur ne survit plus de 3 mois puisque virtuellement personne n'achète de CPU (pourquoi faire quand on n'a même pas de compilo fonctionnel?)
Bref, sans pragmatisme on ne va pas très loin. Ou, dit autrement, le fantasme de la réécriture complète qui va corriger tous les problèmes par la pureté architecturale n'est que ça, un fantasme. De ce point de vue la gestion de l'introduction de PA était un désastre: pas d'un point de vue "scientifique", mais d'un point de vue d'ingénieur.
La seule raison pour laquelle c'est "passé", c'est que ce n'était "que" de l'audio.
C'est un fait, en matière d'informatique le monde entier tourne sur des workarounds dégueu.
[^] # Re: Mwai
Posté par Renault (site web personnel) . Évalué à 6.
Tu oublis que les problèmes ont été révélés grâce à PulseAudio, pas avant, donc quand certaines distributions comme Fedora ont rempli des rapports de bogues là dessus il me semblait bien plus sage d'attendre la correction dans le noyau directement plutôt que d'attendre et de corriger à l'arrache dans PulseAudio.
[^] # Re: Mwai
Posté par Bapt (site web personnel) . Évalué à 2.
tu rigoles ça fait des années que des serveurs audio sont pondu pour palier aux déficiences d'alsa (et de OSS version linux avant) pulseaudio n'a été que le nième révélateur de ces problèmes.
[^] # Re: Mwai
Posté par GnunuX (site web personnel) . Évalué à 6.
Sauf que Lennart n'a rien remplacé. Il a proposer et des mainteneurs de distributions ont décidés de replacer.
[^] # Re: Mwai
Posté par gouttegd . Évalué à 9.
Une partie au moins devait être dû à la complexité inhérente de PulseAudio, dont Lennart Poettering, probablement plus réaliste que ses fan-boys, est d’ailleurs bien conscient. Il n’a jamais caché que « intégrer PulseAudio dans une distribution n’est pas une mince affaire » — “Adopting PA in a distribution is a fair amount of work, given that it interfaces with so many different things at so many different places.”
[^] # Re: Mwai
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 10.
C'est peut-être là que le bat blesse : d'antan l'étape intégrateur n'était pas indispensable. Le pékin moyen (sous linux, pas Mme Michu) pouvait s'installer à peu près n'importe quel programme. En ce qui me concerne, j'ai essuyé mes premiers échecs définitifs à installer/configurer des programmes (autrement fonctionnels) à la main seulement très récemment, après plus de 15 ans sous Linux ou autres Unix. Alors même si je ne souhaite pas prendre position dans la querelle des anti/pro systemd c'est vrai que cet état de fait ne laisse pas de me chagriner. J'aurais apprécié, en tant qu'utilisateur moyennement averti, de ne pas me retrouver laissé sur le bord de la route par l'apparition de docs outrageusement techniques et jargonneuse que je ne suis plus capable d'employer, et qui sont visiblement destinées uniquement à des intégrateurs experts.
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: Mwai
Posté par Renault (site web personnel) . Évalué à 10.
D'un autre côté, toute l'informatique était plus simple avant.
Avant n'importe quel programmeur était capable d'avoir une bonne vision du code de la plupart des logiciels qu'il utilisait, il pouvait connaître le fonctionnement de son matériel et l'exploiter très facilement. Aujourd'hui rien qu'une CG c'est bien plus complexe que n'importe quel ordinateur du début des années 90. Maîtriser la pile réseau ou USB d'un OS est un véritable challenge (les normes étant très volumineuses), tu as des couches d'abstraction de partout et de la sécurité de partout là où avant tu pouvais faire n'importe quoi n'importe quand.
Les programmes aussi ont grossi et se complexifient, plus personne ne connait le code de Linux ou d'un autre gros programme sur le bout des doigts, ils sont trop gros alors qu'avant même un développeur moyen pouvait maitriser tout ceci.
Bref, c'est inhérent à toute l'informatique, cet univers évolue trop vite pour que tout le monde suive et s'est énormément complexifié pour répondre aux besoins de tous ce qui laisse sur le carreau de nombreux amateurs. Mais c'est comme ça et ce n'est pas propre au libre ou à Linux en lui même.
L'informatique est peut être le seul domaine et la seule science où personne n'a maitrisé tout l'état de l'art à un instant t car comme tout secteur après la 1ère GM, ça évolue trop vite pour qu'une personne seule puisse suivre le rythme.
[^] # Re: Mwai
Posté par FantastIX . Évalué à 7. Dernière modification le 29 novembre 2014 à 15:32.
J'aime bien cette phrase. J'ai fait le même constat.
Mais, plutôt que de me dire «l'informatique est devenue compliquée et il faut s'y faire», j'ai tenté de répondre à la question «pourquoi?»
Il n'y a pas qu'une seule réponse. Mais ce que j'ai constaté — et de plus en plus — c'est que les gens, dont les développeurs, ont de moins en moins la capacité à comprendre l'énoncé d'un problème et ont de moins en moins la capacité à résoudre un problème complexe autrement qu'en mettant en place des solutions compliquées (j'utilise complexe et compliquée à dessein). J'ai fait ce constat en observant les gens autour de moi (mais pas seulement), ainsi que les logiciels mis en place et en faisant bilan sur bilan tout au long de ma vie.
L'informatique est-elle donc plus compliquée? ou plus complexe?
Est-elle plus compliquée? Impossible de répondre sans généralisation excessive. Mais si elle est plus compliquée, c'est peut-être aussi parce que ceux qui sont derrière n'ont pas la capacité à trouver une solution logique et optimisée à un problème complexe. J'insiste sur le fait que «complexe» et «compliqué» ne sont pas inter-dépendants.
Est-elle plus complexe qu'avant? Certainement. Mais si c'est le cas, est-ce que cela justifie des solutions si compliquées, que seuls des experts de haut niveau soient à mêmes de les comprendre et de les maîtriser?
Parfois il est des problèmes qui ne doivent pas être résolus. Je veux dire par là que, lorsqu'on définit un projet, une limite claire et incontestée doit être tracée entre les problèmes inhérents au projets, c-à-d auxquels le projet lui-même fournit une solution et ceux qui sont hors-sujet. Or c'est précisément définir ce qui est hors-sujet la tâche la plus ardue et la tentation est grande. Vouloir résoudre des problèmes qui n'entrent pas dans le cadre du projet rend la solution finale non seulement complexe mais compliquée.
Pendant l'évolution d'un projet, grande est la tentation à ajouter des fonctionnalités. Mais avec l'ajout de fonctionnalités, si elle n'a pas été planifiée scrupuleusement depuis le début, il arrive que certaines d'entre elles remettent en cause la raison même de l'existence du projet. Ceci n'est qu'un exemple de ce que j'ai observé. Il en résulte des projets tentaculaires, des monstres voraces en ressources ou que sais-je encore.
Dans mon expérience personnelle, par exemple, j'ai rarement vu des projets qui prenaient en compte les aspects sociaux et humains. Il n'est pas rare d'entendre «C'est à l'utilisateur de s'adapter» ou «Il faut vivre avec son temps», qui vont à l'encontre des bases de l'analyse des systèmes d'information. Et ce sont des phrases de ce type qui sont invoquées lorsque des utilisateurs, réfractaires aux changements, provoquent la lassitude et l'agacement des intégrateurs. Et c'est cet agacement qui provoque l'erreur classique consistant, in fine, de guerre lasse, à appliquer cette sentence à tous ceux qui s'y opposent, fourrant dans le même sac opposants légitimes et crétins réfractaires-tout-court. On pourrait comparer cette situation à la loi de Godwin dans les discussions: classer les opposants à un projet dans une catégorie revient à tomber dans le cliché du nazisme dans une discussion qui s'éternise et qui finit par lasser. Dans tous les cas, c'est l'incompréhension et la frustration qui gagnent.
Je ne dis pas que systemd répond à ce paradigme mais je retrouve dans les litanies d'opposition à systemd des arguments que j'ai moi-même observés depuis le début de ma carrière, bien avant qu'on parle de systemd. C'est suffisant pour moi à considérer que ceux qui s'opposent à ce projet ont probablement de bonnes raisons de le faire. Ceci ne signifie pas qu'il n'y a pas, dans le tas, de crétins sectaires et conservateurs mais ranger, improprement, tous les contestataires dans cette catégories est une grave erreur de jugement.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Mwai
Posté par gnumdk (site web personnel) . Évalué à 4.
Faut pas abuser non plus, la doc de pulseaudio est compréhensible, je dis juste que ça "juste marche".
Sinon, je galérais plus sous Linux y'a 15 ans quand je devais compiler 15 libs juste pour lire un divx avec LAMP…
Linux A??? Media Player, quelqu'un se souvient ce que voulait dire la A? C'était un soft développé par un étudiant français.
[^] # Re: Mwai
Posté par Prosper . Évalué à 2.
A pour Animation http://pauillac.inria.fr/lamp/
[^] # Re: Mwai
Posté par Tonton Benoit . Évalué à 9.
On parle pas d'un logiciel que tu ./configuke && make && make install là, mais d'une brique du systeme.
Non les briques de base du systeme n'ont jamais été faciles à installer, surtout quand tu veut être en avance sur ton temps en utilisant un distrib testing (donc avec des programmes pas encore totalement intégrés/configurés dedans) voir encore plus en installant les nouveautés toi-même pour griller tout le monde.
[^] # Re: Mwai
Posté par Liorel . Évalué à 9.
C'est qui le pékin moyen sous Linux ?
D'expérience, parmi les utilisateurs de Linux, on voit vraiment de tout. Tu as des devs, des vrais, des barbus, qui prennent du café en argument et retournent du C++. Tu as des profils moins, voire pas du tout techniques, qui trouvent l'éthique du logiciel libre intéressante. Tu as quelques types dont la machine Windows avait tellement ralenti à coup de bloatwares que Linux lui a offert une seconde vie. Tu as la mère/la grand-mère/la copine (et leurs équivalents de sexe masculin) de linuxiens, elles veulent que ça juste marche, et coup de bol, ça juste marche. Tu as des opposants chinois/syriens/cubains/whatever. Tu as des sysadmins comme des utilisateurs de machines de bureau. Tu commences même à avoir des gamers ! Et encore, là je te présente des catégories discrètes mais tu as tout un continuum au sein de chacune.
Au final, il y a une telle diversité d'usages et de profils que la notion de moyenne n'a pas grand sens. On a des groupes, assez hétérogènes, mais aux frontières poreuses malgré tout. Ce qui ne fait que refléter la diversité des usages de l'informatique au sens large.
Et c'est tant mieux ! C'est comme ça que Linux a une chance de se démocratiser. Si la liberté 0 était une condition sine qua non, les libertés 1 et 3 seraient fictives et le logiciel libre ne libérerait finalement que du code (pour citer un blog bien connu). Il est là le boulot des intégrateurs ! Il permet à des gens dont les connaissances techniques sont faibles, nulles, ou orientées dans un autre domaine d'utiliser des logiciels efficaces, de qualité, et qui marchent, honnêtement, remarquablement bien quand on voit à quelles tortures on les soumet.
Ça, ce sont les sources. Le mouton que tu veux est dedans.
[^] # Re: Mwai
Posté par xcomcmdr . Évalué à 10.
La doc de systemd est très bonne et complète. De plus, c'est le système d'init le plus documenté que j'ai jamais vu. Quand on compare à la non-doc de SysV ou Upstart, y'a pas photo !
Non, systemd a aussi reçu beaucoup de résistance interne chez RH et a été au départ un sideproject de Lennart. Et Archlinux a été une des premières à l'adopter, pour les raisons expliqués ici : pas de trace de RH là dedans.
Il est plus facile à utiliser, tout simplement : plus de fiabilité, plus de retour sur les problèmes, plus d'informations utiles dans le journal, etc…
Et concrètement ? Un pot de vin aux mainteneurs, tu crois ? Ha !
networkd est optionnel.
udev permet de peupler /dev, c'est un peu important pour booter.
Et oui, systemd est un ensemble d'outils maintenus dans un seul dépôt, "à la BSD" : ça permet d'avoir un tout cohérent.
Quant au fait que faire une alternative à systemd revient à re-créer systemd : ça tient du fait que systemd est généralement adopté et que revenir en arrière ne sera pas accepté.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Mwai
Posté par groumly . Évalué à 10.
Tu suggeres quoi alors?
Qu'on mette les 80 binaires en un? En quoi ca va arranger les choses?
Qu'on sorte les 80 binaires de systemd et dans leur propre projet? En quoi ca changerais la complexite? Ca revient juste a changer leur nom, ca va pas nous avancer des masses.
Qu'on se separe des 80 binaires tout simplement? Et que donc on se passe des fonctionalites des 80 binaires (qui servent bien a quelque chose quand meme, quoi que t'en penses).
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Mwai
Posté par needs . Évalué à -8.
C'est exactement ce que je suggérerai. C'est même exactement ce que je ferais. Cela permet d'avoir des interfaces claires, des trucs (plus) facilement debugable et maintenable et cela permettrait aux autres de facilement développer une alternative. De mon point de vue, on perd en complexité, on divise le problème en plusieurs sous problèmes indépendant.
[^] # Re: Mwai
Posté par groumly . Évalué à 10.
En quoi on aurait des interfaces plus claires?
Tu changes juste le nom du projet, ca va pas magiquement resoudre le probleme de l'interdependence intrinseque de tous ces composants. Au contraire, ca va juste rendre plus dure la tache de comprendre le tout.
Dit autrement, les 80 binaires ne sont pas le probleme, le probleme c'est qu'un systeme d'init moderne est complexe par nature. Gueuler sur lennart va pas changer grand chose au probleme, et on entends pas beaucoup de suggestion constructives, juste des gens qui gueulent que "pffouuulala, l'informatique, c'est dur de nos jours, c'etait mieux avant quand ca en faisait vachement moins".
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Mwai
Posté par needs . Évalué à 2.
Parceque justement, si on veut que tout fonctionne bien il faut que « l'interface » soit claire. Il faut que le rôle du programme soit clairement établi.
Tu ne changes pas juste le nom, tu le rends independant, et c'est là ou est la différence majeure. Dit moi, tu comprends mieux comment fonctionne un système d'init (si on peut encore appeller cela comme ça) aujourd'hui (systemd upstart), ou avant, à l'époque de SysvInit/runit/etc.. ? Moi c'était avant.
C'est très juste.
Non, je ne pense pas. Bon il faut maintenant clairement définir ce qu'est un système d'init, parceque si on considère que tout ce que fait systemd (y compris networkd et les autres) fait partie du rôle du système d'init, alors oui, c'est complexe. Mais le système d'init n'est pas censé s'occuper du réseau, s'occuper de
/dev, il est censé coordonner l'initialisation de ton système. Et la, c'est plus simple.Exactement comme l'argument du « Ben vasi, fork ! », c'est de mauvaise foi. Mon temps n'est pour l'instant pas infini.
[^] # Re: Mwai
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 2.
Si tu parles du fonctionnement interne du système d'init (le code), alors ça ne change rien, je ne le connais pas plus maintenant qu'avant.
Si tu parles de comment utiliser le système d'init, alors je trouve ça plus facile maintenant. Un tas de scripts d'init étaient imbitables, différent d'une distribution à une autre, non-documentés…
C'est vachement plus facile pour moi aujourd'hui d'écrire un script d'init que ça ne l'était avant, et je peux le faire avec plus de fonctionalités.
[^] # Re: Mwai
Posté par needs . Évalué à -2.
Si l'on compare SysVInit et systemd, je te rejoins. Mais par exemple je trouve
runit(par défaut dans Debian 6 je crois bien) plus facile à utiliser, et beaucoup plus souple. Je faisais quasi tout avec runit et j'en était très très content.[^] # Re: Mwai
Posté par coid . Évalué à 5.
Et les dév de LL ont un bien sûr un temps infini qui doit servir à régler tes problèmes ? Qu’est-ce qu’on doit comprendre ? Tu n’as pas le temps… mais les autres devrait l’avoir ?
[^] # Re: Mwai
Posté par groumly . Évalué à 10.
Ah ben heureusement que t'es la pour accorder le peu de ton temps disponible a lennart et lui donner des conseils, parce qu'il y avait pas pense. D'ailleurs personne n'y avait pense.
Bon, maintenant que tu nous a rappele ce qu'on apprends aux etudiants a leur deuxieme cour d'informatique en deug, si tu passais a la vitesse superieure?
Prend n'importe lequel de ces 80 binaires, et explique nous en quoi son role est mal defini, et ce que tu ferais pour le definir plus precisement, ainsi que comment tu modifierais son interface.
Oui, c'est sur que quand on remplace des actions concretes par une vague phrase qui ne veut pas dire grand chose, ca parait plus simple. Qu'est ce que tu disais deja sur l'importance d'avoir des roles clairement definis?
Tant qu'on y est , si tu pouvais nous expliquer en quoi sysv coordone quoi que ce soit, ca serait sympa. De ce que j'en sait, sysv coordonne pas grand chose, il se contente de lancer des scripts dans un ordre defini par l'utilisateur, qui se coordonent tant bien que mal eux meme.
Et d'ailleurs, en quoi le reseau et /dev ne font pas partie de l'init? Remplir /dev, ca parait etre qq chose d'assez important a l'init quand meme, non? Ca va etre vachement plus dur de demarrer si tes disques ne sont pas dans /dev, tu crois pas?
Et demarrer tes services reseaux, ton pare feu et ce genre de choses, ca marcherait pas un chouilla mieux apres que tes interfaces reseaux soient montees?
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Mwai
Posté par needs . Évalué à -1.
« le peu de ton temps disponible », non, ne me fait pas passer pour le chevalier blanc, ni batmand.
« et lui donner des conseils », je ne lui donne pas de conseils, je dis juste comment j'aurais fait, et peut-être comment je ferais.
« parce qu'il y avait pas pense. D'ailleurs personne n'y avait pense. », FUD ? Je crois bien oui…
Voila. Si tu as la flemme de cliquer, je pourrais résumer assez facilement: « on nous apprend à être des automates de traduction UML vers Java ».
Je veux bien mais cela vas me prendre beaucoup de temps : je le ferais plus tard, quand la motivation sera revenu. Je dit ceci car cela doit faire à peu près 1 heure que j'écris ce commentaire et je commence à saturer.
Okay, tu m'en veux et je ne sais pas pourquoi.
L'importance d'un rôle clairement défini, c'est que cela vas directement dans le sens de la fameuse maxime (version courte) : « Écrivez des programmes qui effectuent une seule chose et qui le font bien ». Et si tu veux comprendre pourquoi c'est important, je t'invite avec enthousiasme à lire « The Art Of Unix Programming » (TAOUP). Car non seulement tu trouveras une réponse bien meilleur que ce que j'aurais pu t'écrire, mais aussi parceque cela ne concerne pas uniquement UNIX, mais belle et bien la programmation en général.
D'ailleurs, je ferais bien enseigner la plupart des principes et de la méthodologie présente dans le TAOUP en DUT. Sisi, tu peux d'ores et déjà cliquer sur « inutile », si ce n'est pas déjà fait.
Il est vrai que « coordonner » n'est peut-être pas le meilleur mot, mais tu as parfaitement décrit l'idée : « il se contente de lancer des scripts dans un ordre defini par l'utilisateur ». C'est simple, c'est efficace, ça marche. Comme
systemdà ses début. Oh oui, si Lennart et les autres contributeurs avaient cessé d'ajouter des fonctionnalités, je n'aurais rien à dire. En gros avant que systemd ne « mange »udev, systemd faisait son boulot, et rien d'autre.Lancer le programme qui gère le réseau et le programme qui gère
/devfait partie de l'init, mais gérer le réseau et/devne font clairement pas partie de l'init. Si tu comprends toujours pas alors je ne vois vraiment pas comment l'expliquer. C'est la différence qu'il y a entre « lancer » (ou exécuter) et « gérer ».Sisi, d'ailleurs c'est à cela que servent les systèmes d'init normalement : gérer l'ordre de lancement des programmes, comme tu l'as si bien décrit plus haut.
[^] # Re: Mwai
Posté par groumly . Évalué à 4.
Blabla, tu tournes autour du pot, au final tu dis rien de concret, a part enoncer des banalites vielles de 35 ans sans expliquer en quoi les choses sont mal faites, tout ca pour finir par un "j'expliquerais plus tard, j'ai la flemme la".
Mais bizarrement, t'as quand meme prit le temps de pondre un long commentaire.
Ca tombe bien, ils ne font pas partie de l'init, c'est pour ca qu'ils sont dans des binaires a part. Par conre, il semble qu'ils soient suffisament proche de l'init pour justifier une integration poussee avec systemd, ce qui est justement la discussion ici. Ca aide beaucoup que systemd soit au courant de ce qu'ils ont fait/ou ils en sont pour savoir ce qu'il doit faire ensuite.
Tout le monde n'est pas d'accord, visiblement. Macosx a launchd, solaris smf. Meme windows le gueux a un fonctionnement similaire.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Mwai
Posté par gnumdk (site web personnel) . Évalué à 6.
Rassure moi, t'es pas développeur?
[^] # Re: Mwai
Posté par needs . Évalué à -2.
Haha, non, je suis programmeur.
[^] # Re: Mwai
Posté par gnumdk (site web personnel) . Évalué à 4.
Je vais répondre à ton post précédent… Tu veux que chaque binaire assure un rôle établi mais sauf erreur de ma part,c'est le cas des binaires de systemd,en tout cas plus que le nombre de commandes internes d'un shell…
Dire que sysvinit était moins complexe que systemd,c'est juste oublier qu'il est basé sur un composant complexe dont le rôle dans l'init de ta machine est encore plus absurde que networkd…
[^] # Re: Mwai
Posté par vv222 . Évalué à 3.
On perdrait en factorisation, c’est certain.
Mais en complexité, j’ai des doutes.
La factorisation du code, c’est le point que j’apprécie le plus dans l’adoption de systemd (l’éco-système) par la plupart des grandes distributions.
[^] # Re: Mwai
Posté par needs . Évalué à 0.
De quel « code » parles tu ? Si tu parles du code source, il y a peu de réutilisation dans le code de systemd. Et ce n'est pas très étonnant car il n'y pas vraiment de parties commune dans
networkdet danslogindpar exemple…[^] # Re: Mwai
Posté par Sufflope (site web personnel) . Évalué à 10.
Le code des scripts d'init. Fini les 150 implems quasi (tout est dans le quasi) identique de start/stop/restart (si je l'implémente en faisant stop puis start, je mets un sleep entre les deux ? si oui, de combien de secondes ? je fais quoi si le stop n'a pas tout stoppé ? et d'abord je le sais comment qu'il a pas tout stoppé ?) et j'en passe.
[^] # Re: Mwai
Posté par Anonyme . Évalué à 6.
Pourquoi est ce que ce sont des choses "normalement indépendante" ? Qu'est ce qui interdit à un meme projet de fournir des outils pour ces differentes choses ?
mkdir et md5sum ce sont des commandes totalement différentes, et pourtant elles font toutes les 2 partie de coreutils (qui lui meme fait partie du projet GNU).
Et de manière generale, le projet GNU fournit tout un tas d'outils pour faire des choses totalement différentes. Et ca n'a l'air de déranger personne.
Les developeurs de systemd n'ont pas l'air d'avoir de problème particulier à le maintenir.
Oui par ce qu'il est evident que systemd a été adopté par tout un tas de distribution uniquement par ce que Lennart travail pour Red Hat.
En réalité, systemd a été introduit dans Fedora en suivant le processus normal. Et les gens qui se sont chargés de l'introduire dans differentes distributions ont été convaincus de l'interet de systemd par ce que Lennart a été capable de l'expliquer de facon convainquante (voir les nombreux postes sur son blog qui expliquent en detail toutes les raisons qui ont poussé à la création de systemd), pas par ce qu'il y a ecrit Red Hat sur sa carte de visite.
Et tu proposes quoi ? De surtout pas standardiser de moyen de communication entre les differents modules ? En quoi standardiser cela est il une mauvaise chose ?
C'est une blague ?
Il faut vraiment etre de mauvaise fois pour affirmer que systemd est très mal documenté …
Le blog de lennart contient des tas de tutoriels pour présenter toutes les fonctionnalités de systemd, et toutes les options sont documentées dans des pages de man.
[^] # Re: Mwai
Posté par gnumdk (site web personnel) . Évalué à -1.
C'est l'avantage avec toi, pas besoin de souhaiter ton retrait vu que tes contributions doivent se résumer à peau de zob…
[^] # Re: Mwai
Posté par xcomcmdr . Évalué à 10.
Alors chez moi avahi je m'en suis jamais servi mais je comprends très bien le besoin.
Wikipédia donne l'exemple suivant :
Un truc qui automatise la découverte de services, pour moi c'est clairement une amélioration de l'expérience utilisateur.
Quant à systemd… Je vais pas tout refaire, mais en gros :
Alors oui ce n'est pas le premier systemd-like, ni le premier à résoudre les problèmes que j'ai cité, mais c'est le premier à être accepté par les distributions, et ça change tout. Parce que un systemd super mais utilisé par 3 tondus, c'est joli mais ça sert à rien.
D'ailleurs, systemd est tellement "mauvais" qu'il fait fait même des émules chez BSD… ;-)
Et pour PulseAudio est aussi clairement un plus pour l'expérience utilisateur :
Si ce que fait Lennart et ses collègues et si "mauvais", qu'est ce que ça va être quand il va coder sérieusement ! ;-)
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Mwai
Posté par Kaane . Évalué à 3.
Alors pour faire rapide, "casser" l'expérience utilisateur ça veut dire faire qu'un truc qui fonctionnait avant ne fonctionne plus maintenant. C'est parfois nécessaire (mais c'est rare) et c'est parfois même souhaitable (virus et compagnie).
Le fait d'apporter quelque chose de nouveau c'est "enrichir" l'expérience utilisateur. Donc Oui Lennart enrichit ET casse l'expérience utilisateur.
Cependant ce qui est nocif c'est de n'en avoir rien à faire de casser l'expérience utilisateur, c'est à dire que l'on se moque bien de savoir si il y a des régressions, perte de compatibilité ou autre effets de bords quand on passe de la version N à la version N+1. Et là dessus Lennart est champion. Le problème avec ce genre de direction de projet c'est que du coup une entreprise (c'est à dire un service client à maintenir, des contrats à honorer, des workflow certifiés à respecter etc. ) ne peut pas s'appuyer sur le projet. Parce que rien ne garanti que la version N+1 sera encore compatible avec tout ce qui a été mis en place. Donc on s'en passe.
[^] # Re: Mwai
Posté par gnumdk (site web personnel) . Évalué à 1. Dernière modification le 27 novembre 2014 à 19:22.
T'en as pas marre de raconter des conneries…
3 mises à jour de Debian pour un logiciel de backup propriétaire, 3 fois que je modifie le script sysvinit pour qu'il reste compatible…
[^] # Re: Mwai
Posté par Kaane . Évalué à 4.
Là je veux bien que tu détailles. Parce que honnêtement sur Debian même la structure de fichiers est super stable, donc à moins que tu ne sois victime de udisk2 (qui a décidé de jouer les Lennart niveau pérennité) je vois pas trop ce qui peut provoquer ça.
[^] # Re: Mwai
Posté par needs . Évalué à -1.
De backup propriétaire, tu es sur Debian, c'est l'éditeur du logiciel que tu utilises qu'il faut blamer.
Tu sous entends que toi, tu as des problèmes avec SysVInit, et donc que tout le monde à des problèmes avec SysVInit ?
[^] # Re: Mwai
Posté par Zenitram (site web personnel) . Évalué à -10.
Impressionnant la capacité à ne pas voir que l'interface n'est pas stable contrairement à ce que les anti-systemd veulent faire croire.
Tiens, remplace SysVInit par systemd dans ta phrase et…
De pire en pire les conneries (désolé, pas d'autres mots) qu'on peut lire de la part des anti-systemd.
[^] # Re: Mwai
Posté par Kaane . Évalué à 3.
Impressionnant la capacité à ne pas voir que l'interface n'est pas stable contrairement à ce que les anti-systemd veulent faire croire.
Ah non au contraire. J'ai hâte de voir cette interface non stable qui fait qu'après une mise à jour de Debian le script d'init casse. Je suis même vraiment curieux. J'ai même filé une porte de sortie en parlant de udisk2 qui a changé son format de nommage du jour au lendemain (Bon ça fait un cassage, il y en aura encore deux autres à expliquer).
[^] # Re: Mwai
Posté par gnumdk (site web personnel) . Évalué à -1.
J'ai changé de taf et je ne me souviens pas des détails mais bon, un peu de lecture pour toi:
Init script broken
[^] # Re: Mwai
Posté par Kaane . Évalué à 7.
Tu es au courant que sur la recherche que tu me donnes, les 2 premières pages sont exclusivement dues à des mises à jour du script d'init qui ne marche plus ?
Ça clairement ça arrive souvent, tu veux rajouter une option ou corriger un bug dans un script d'init et ça casse quelque chose ailleurs. Mais c'est juste un bug dans le script. Et là c'est pour des scripts génériques qui font 12 000 tests et doivent prendre en compte 200 configurations.
Mais le comportement inverse, I.E je fais une mise à jour du système et mon ancien script d'init ne marche plus sur un binaire qui n'a pas été mise à jour, est rarissime.
J'ai fait des centaines de script d'init et sur des versions early alpha, sur des pull CVS compilés à la mano avec des options bizarres, et même sur du matos pas encore commercialisé avec des pilotes constructeurs à peine sortis du labo. J'ai du avoir peut-être trois ou quatre fois le coup ou après une mise à jour j'ai du modifier le système d'init. Une fois à cause de udisk2 (qu'on a bazardé depuis), une fois suite à une modification de bash (c'était il y a 7 ou 8 ans de mémoire, et encore c'est plutôt de ma faute, j'aurai pas du écrire un script en bash au lieu de sh) et encore une fois parce qu'était passé de DHCPv6 à NDP (donc là encore c'est plutôt de ma faute).
Mais un script d'init qui casse trois fois suite à trois mises à jour Debian sur un binaire qui ne bouge pas, j'ai jamais vu. Donc là je vais me sentir obligé de dire BULLSHIT.
[^] # Re: Mwai
Posté par gnumdk (site web personnel) . Évalué à 4.
Bah faudrait savoir, on vient de m'expliquer que sysvinit c'est trop de la balle parce que ça fonctionne sans jamais rien modifier…
Oui, tout le monde a des problèmes avec ce truc, en particulier les mecs qui font des distribs, les éditeurs de logiciels, …
[^] # Re: Mwai
Posté par coid . Évalué à 3.
Trop dur pour les entreprises de ne plus pouvoir compter sur le boulot des autres pour satisfaire ses clients. Et fournir un dév pour maintenir ce qui doit l’être, c’est sans doute trop dur aussi…
Donc, en fait, tout va bien.
[^] # Re: Mwai
Posté par Zenitram (site web personnel) . Évalué à -4. Dernière modification le 27 novembre 2014 à 19:30.
FUD (il ne casse pas plus que les merdes qu'il y avait avant, juste que tu considère "normal" quand ça casse avec les logiciels d'avant que tu ne t'en rends même plus compte).
Ouais, clair, RH et SUSE ils font que de la vente aux particuliers tellement systemd ne répond pas aux besoins des entreprises.
Encore une fois, Lennart ne t'empèche aucunement de payers les mainteneurs qui vont se faire chier à maintenir les trucs à l'ancienne (tu as dit n'avoir aucun problème, donc tu n'as aucun problème pour financer le service que toi seul veut aujourd'hui). Lennard ne te fdérange aucunement. Alors pourquoi le détester?
C'est triste de lire ce genre de mensonges, aveuglements et incohérances juste à cause de la résistance aux changement… Le conservatiste est très imaginatif dès qu'il faut tout faire pour rester "comme avant" (je viens de sortir d'une A.G. pour un immeuble, j'ai eu le droit aux mêmes délires incohérants sur pourquoi il faut "garder comme avant" des choses, même comportement conservatiste de partout, si ça peut te rassurer)
[^] # Re: Mwai
Posté par Kaane . Évalué à 10.
FUD (il ne casse pas plus que les merdes qu'il y avait avant, juste que tu considère "normal" quand ça casse avec les logiciels d'avant que tu ne t'en rends même plus compte).
Je t'invite vivement à lire The Linux Way et également Bashage de Linus
On peut aussi citer Ca sert à rien d’espérer que les chose soient différentes de la réalité
En ce qui concerne le "cassage" avec les logiciels d'avant (à savoir les API kernel, udev et rsyslog), ça s'est produit (rarement), je m'en suis rendu compte (assez vite je pense - c'est quand même vital ces choses là) - j'ai ouvert des bugs et ça a été corrigé. Je n'ai jamais eu de commentaires du type "Dans 2 mois on casse le truc qu'on a mis en place il y a trois mois, mettez à jour tout de suite ou ne venez pas pleurer plus tard". Et ça tombe bien d'ailleurs, parce que deux mois pour faire les tests de régression sur une archi, c'est quand même très court.
Ouais, clair, RH et SUSE ils font que de la vente aux particuliers tellement systemd ne répond pas aux besoins des entreprises.
Il font du support développement chez RH et Suse ? Genre si je décide de créer une appli basé sur une fonctionnalité systemd et que cette fonctionnalité disparait ils me filent un billet ? Genre si j'ai des connexions avec udev en netlink ils me filent combien ?
Non mais sérieusement, évidemment que RH et Suse sont capable d'adapter leur distrib aux modifs systemd, c'est leur métier - mais toi si tu n'as pas une équipe de 30 devs et les machines de tests qui vont bien en 24/24 je continue franchement à te déconseiller de te baser sur une API systemd pour quoi que ce soit de non trivial.
Lennart ne t'empèche aucunement de payers les mainteneurs qui vont se faire chier à maintenir les trucs à l'ancienne
Ben vu que notre matériel ne peut pas fonctionner avec systemd, c'est ce qui se passe. Par contre tu fais bien de dire qu'ils se font chier, les pauvres ils n'ont quasiment rien à faire.
Lennart ne te dérange aucunement. Alors pourquoi le détester
Il ne m'impacte pas, mais il me dérange dans son attitude que ce soit vis à vis du noyau, des divers mainteneurs extérieurs, des utilisateurs etc.
C'est triste de lire ce genre de mensonges, aveuglements et incohérances juste à cause de la résistance aux changement…
C'est triste les gens bornés. Es-tu tellement sur que la seule raison au monde que pourrait avoir une personne de ne pas vouloir utiliser systemd c'est d'être un vieux schnock aigri, mythomane et réactionnaire ? Si oui je ne peux plus rien pour toi.
[^] # Re: Mwai
Posté par Thomas Douillard . Évalué à 2.
Ça fait pas 10 ans que tu joue ce rôle sur linuxfr ? J'ai un peu souvenir de trolls waylands entre toi et misc ou il réfutait entièrement un post "argumenté" de toi, et je suis à peu prêt certain de pouvoir remonter le temps et trouver d'autres évolutions ou tu joues très bien ce rôle.
[^] # Re: Mwai
Posté par Kaane . Évalué à 3.
J'ai un peu souvenir de trolls Waylands entre toi et Misc ou il réfutait entièrement un post "argumenté" de toi
Sur Wayland ? J'ai toujours eu plutôt de la sympathie pour ce projet, à part peut être tout au début. Quand à Misc on s'est frité plusieurs fois sur systemd, mais généralement je répondais à ses arguments.
Je viens rapidement de regarder mes commentaires (En tant que Kaane, phxonx ou khane). J'ai souvenir de m'être fait démonté point par point sur OpenGL et sur Erlang principalement, mais sur wayland ? Franchement si tu retrouves la source je veux bien (ceci dit sans aucune arrière pensée)
[^] # Re: Mwai
Posté par gnumdk (site web personnel) . Évalué à 2.
T'es plus crédible à la première phrase…
Tu te souviens le nombre d'outils différents qu'il y a eu sous Linux avant udev pour faire ce que fait ce dernier aujourd'hui?
Alors dire que sous Linux, rien ne casse, c'est juste une grosse blague… Bien, sur avec un exemple comme syslog, tu te mouilles pas trop… Les fichiers de conf de vim n'ont pas bougé non plus, c'est fout ça!
Ensuite, tu nous parles des API de systemd mais dans le cas de remplacer un script bash dégueulasse par un fichier d'init systemd, je dis que je vois pas le rapport…
[^] # Re: Mwai
Posté par xcomcmdr . Évalué à 2. Dernière modification le 27 novembre 2014 à 19:59.
Source ? Preuves ?
Je suis passé par des dizaines de versions de PA et de systemd (j'utilise PA depuis qu'il a été intégré à Ubuntu, et systemd depuis qu'Archlinux l'a adopté vers mi-2012) : aucune régression (j'ai pas dit aucun bug, hein).
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Mwai
Posté par totof2000 . Évalué à -3.
Sur un serveur, ou justement tu cherches à limiter les ressources auxquelles celui-ci se connecte, c'est sur que c'est utile.
Sur un serveur, je m'en moque.
Encore une fois sur un serveur j'en ai rien à faire. Systemd, sur un poste de travail, ça ne me gèil permet de changer la sortie sonore de n'importe quelle application
essaie de gérer des enceintes bluetooth avec ALSA… tu vas vite revenir vers PA
il est compatible avec l'existant (genre FlashPlayer qui ne connaît que ALSA)
il a une architecture légère (CoW), une latence faible (c'est juste hyper-important pour du son), et il est modulaireas plus que ça mais sur un serveur, je ne vois pas à quoi ça sert.
[^] # Re: Mwai
Posté par xcomcmdr . Évalué à 6.
Si tu installe et actives avahi sur ton serveur, c'est ton problème.
Très bien, c'est pas imposé.
Si tu installe et actives PulseAudio sur ton serveur, c'est ton problème.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Mwai
Posté par modr123 . Évalué à -7.
En gros un truc qui utilises des ressources pour quelque chose dont j'ai pas besoin au mieux …
des trucs qui me servent a rien encore
pareil….
[^] # Re: Mwai
Posté par Zenitram (site web personnel) . Évalué à -1. Dernière modification le 28 novembre 2014 à 11:40.
tu viens de découvrir que sur ta machine 99% des fonctionnalités (regarde juste le noyau Linux) ne te sont pas utiles mais c'est quand même la? Bravo!
Linux à la poubelle, il y a plein de fonctionnalités dont tu ne te sers pas (quelle idée de risquer une MAJ, autant rester en 2.6 par exemple, pour la maintenance c'est toi qui paye comme pour la distro sysV, ça n'a pas l'air de te déranger de payer si plus personne n'est interessé à le faire gratos dans une mutualisation, la mutualisation ne t'es pas utile)
qu'est-ce qu'il ne faut pas lire dans le genre égoiste mais qui veut quand même que les autres bossent gratos (pour la maintenance, par exemple)…
[^] # Re: Mwai
Posté par vv222 . Évalué à 5.
Ça ne te sert à rien, donc tu ne l’utilises pas, donc… tu te sens en position de le critiquer ?
[^] # Re: Mwai
Posté par Zenitram (site web personnel) . Évalué à -2. Dernière modification le 27 novembre 2014 à 20:06.
Faut vraiment que tu explique aux idiots comme moi pourquoi tu es anti-Lennart.
- Lennart n'a pas décidé d'inclure systemd dans les distros (pourquoi les gnes sont contre Lennart alors qu'il n'a aucun droit de décision sur l'inclusion ou non de ses projets dans les distros? Pourquoi ne pas en vouloir aux mainteneurs qui ont fait le choix?)
- Tu en as pas besoin, donc tu n'as pas à utiliser (libre à toi d'utiliser une autre distro faite par des mainteneurs qui te plaise).
- En fait, Lennart n'a aucun impact sur toi, il ne décide de rien sur toi, il ne peut même pas imposer quoi que ce soit (grande liberté, c'est même pas un personnage d'Etat avec un choix unique pour tous les citoyens, tout le monde est libre de choisir comme il veut), pourquoi être anti une personne qui ne fait rien contre toi?
Plus j'écris, et plus je n'ai qu'une conclusion : tu es anti-toi-même, seul décisionnaire (si à la limite tu en voulais aux mainteneurs qui ont décidé de ne plus bosser gratos pour toi, on pourrait dire que tu as la haine de ne plus avoir des travailleurs gratos… Mais on peut même pas dire ça).
[^] # Re: Mwai
Posté par fearan . Évalué à 3.
C'est marrant que ce soit toi qui tienne ce genre de discours…
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Mwai
Posté par Philippe F (site web personnel) . Évalué à 5.
Et toi non-plus. Au fait, tu sais qu'il y a pas que le Larzac, tu peux aussi ouvrir une boucherie porcine en Arabie Saoudite, ou un restaurant de fruits de mer au Tibet, ne te gènes pas pour nous.
[^] # Re: Mwai
Posté par KiKouN . Évalué à 3.
Pour les plus libristes, on peut aussi aller vendre du sable dans le sahara.
[^] # Re: Mwai
Posté par modr123 . Évalué à 8.
ça se vendrait ….
le sable du sahara est rond et ne peut servir a faire du ciment par exemple
dubai importe beaucoup de sable
[^] # Re: Mwai
Posté par Nitchevo (site web personnel) . Évalué à 2.
C'est triste ton avis sur les connards
[^] # Re: Mwai
Posté par stopspam . Évalué à 10.
Tu voulais plutôt dire :
[^] # Re: Mwai
Posté par reynum (site web personnel) . Évalué à 9.
Ouai tout compte fait vaut qu'il continue à faire des logiciels informatiques, parce que vivre dans un monde sans roblochon, saint nectaire, étorki, tomme, camemdert, raclette, coulommiers, mimolette, compté, brie, bleu, roquefort, munster, livarot, morbier, et j'en passe moi je ne considère pas ça possible :-D
kentoc'h mervel eget bezan saotred
[^] # Re: Mwai
Posté par Okki (site web personnel, Mastodon) . Évalué à 5.
En tant qu'amoureux du fromage, tu pourrais donc faire un petit don XD
[^] # Re: Mwai
Posté par IceCat (Mastodon) . Évalué à 4.
Du REblochon !
http://www.youtube.com/watch?v=mWwAqffa6Tc
[^] # Re: Mwai
Posté par Guillaume Denry (site web personnel) . Évalué à 2.
Je sais, il y a un "et j'en passe" dans ta phrase mais je tiens à évoquer également le Banon, un petit fromage de chèvre qui, quand il est bien affiné, me donnerait envie de faire des centaines de kilomètres jusque dans le Vaucluse pour aller en manger.
[^] # Re: Mwai
Posté par reynum (site web personnel) . Évalué à 2. Dernière modification le 27 novembre 2014 à 22:20.
Ba non j'ai volontairement évité tout fromage de chèvre.
car le formage de Lennart est un chèvre :-D
Au passage je ne connais pas le Banon tu viens d'éveiller ma curiosité.
kentoc'h mervel eget bezan saotred
[^] # Re: Mwai
Posté par ariasuni . Évalué à 3.
Ajoute ta suggestion!
Écrit en Bépo selon l’orthographe de 1990
# rédac'
Posté par BAud (site web personnel) . Évalué à 9.
rho, bah, tu peux faire un tour sur https://linuxfr.org/redaction/news/systemd-a-t-il-des-problemes-d-init pour y ajouter ta prose, sans partir du postulat "je ne veux pas de systemd" mais en indiquant ce que cela t'enlève de l'avoir
# Ca ne règle pas la source du problème
Posté par Zenitram (site web personnel) . Évalué à -1. Dernière modification le 27 novembre 2014 à 08:09.
Ca ressemble surtout à soigner les symptomes mais pas la source du problème.
Il faudrait en parallèle aller voir un psy pour soigner cette hantise dont tu es incapable de décrire objectivement les raisons (non, la résistance au changement n'est pas une raison objective, on ne ferait plus de changements sinon).
[^] # Re: Ca ne règle pas la source du problème
Posté par jyes . Évalué à 10.
Systemd évoluant, mes griefs à son égard disparaissent petit à petit (quoi qu’ils n’ont jamais vraiment porté sur la partie technique du projet), mais parler de problème psy à propos de contrôle de mise à jour, c’est vraiment n’importe quoi !
Ici benoar ne parle pas d’un système fraîchement installé mais de son système du quotidien, sur lequel l’init utilisé lui importe, ce qui laisse présager qu’il a déjà touché à la gestion de son init (j’utilise Debian et j’ai des scripts init custom auxquels je devrai faire attention lors de la mise à jour). Éviter une mise à jour silencieuse de l’init me paraît la moindre des choses, et sa solution est élégante puisqu’elle laisse le gestionnaire de dépendances travailler en lui donnant l’information « pas de systemd ». Le jour où il n’y aura plus de solution, il lui faudra alors relâcher cette règle et porter ses scripts de démarrage persos (ajouter les unités correspondantes etc.). Ce n’est pas de la résistance au changement que de s’assurer qu’en attendant ça marche sans surprise !
Visiblement tu n’as jamais touché à ton système d’init et tu t’en fous, très bien, mais certains ont déjà mis les mains dans le cambouis sur leur système et un changement d’init peut être une migration majeure, d’où la « hantise » d’une mise à jour non-souhaitée.
Tu peux aussi aller voir un psy pour comprendre d’où te vient ce besoin de critiquer les choix des autres dès qu’ils diffèrent des tiens, en leur prêtant des intentions qu’ils n’ont pas exprimées. Une fois ce problème compris, je te promets que les commentateurs de LinuxFr se feront un plaisir de t’aider à écrire des commentaires pertinents et cordiaux, deux qualificatifs que tu cumules rarement (bien que séparément, je ne remets pas en question ta contribution souvent positive au contenu du site).
[^] # Re: Ca ne règle pas la source du problème
Posté par xcomcmdr . Évalué à 4.
A-t-il essayé au moins ? Chez moi j'ai touché à mon init quand c'était SysV, et je suis passé à systemd sans m'en rendre compte (grâce à sa rétrocompatibilité).
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Ca ne règle pas la source du problème
Posté par Christophe . Évalué à 6. Dernière modification le 27 novembre 2014 à 09:59.
Si son système marche bien actuellement, pourquoi prendre le moindre risque ? L'init SysV est encore maintenu par Debian, après tout.
[^] # Re: Ca ne règle pas la source du problème
Posté par CrEv (site web personnel) . Évalué à 6.
Oué enfin avec cette logique il n'aurait jamais du essayer de mettre à jour sa distrib si elle marchait bien.
[^] # Re: Ca ne règle pas la source du problème
Posté par Christophe . Évalué à 10.
Entre installer un système d'init et mettre à jour des logiciels et bibliothèques, le risque n'est pas le même… Je pensais que c'était évident.
[^] # Re: Ca ne règle pas la source du problème
Posté par Adrien . Évalué à 7.
Concrêtement, ça change quoi ?
des paquets indispensables, il y en a plein : linux-image, libc, apt, etc. Qu'est ce qui fait que systemd est différent du reste ?
[^] # Re: Ca ne règle pas la source du problème
Posté par Christophe . Évalué à 9.
C'est différent car il a déjà un système d'init. On parle ici de remplacer une brique de base par une autre très différente. Il n'a peut-être pas envie / pas le temps de modifier son GRUB fait maison. Il n'a peut-être pas envie, ou pas le temps, d'apprendre à utiliser un nouveau système d'init alors que celui qu'il a en ce moment fonctionne.
Le vieil init est encore officiellement supporté par la distro, pour rappel.
Je te retourne la question: concrètement, pourquoi passer à systemd là-tout-de-suite-maintenant, pour lui ? Je ne vois aucune urgence, et s'il n'a pas le temps de regarder ce que ça change pour lui, il va juste se retrouver avec un init qu'il ne maîtrise pas.
Tout ça me fait penser à quelqu'un qui va installer Linux sur la machine d'un pote "parce que c'est mieux que Windows", sans se demander si ça lui est d'une quelconque utilité.
[^] # Re: Ca ne règle pas la source du problème
Posté par xcomcmdr . Évalué à 2.
Y'a pas à toucher GRUB, pourquoi toucher à GRUB ??
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Ca ne règle pas la source du problème
Posté par Christophe . Évalué à -1.
Je savais que je n'aurais pas dû parler de ce détail: tu n'as retenu que ça de mon commentaire. C'est le reste qui est important.
[^] # Re: Ca ne règle pas la source du problème
Posté par kursus_hc . Évalué à 1.
Enfin ce que tu n'as pas retenu du sien, c'est que concrètement rien ne va changer.
[^] # Re: Ca ne règle pas la source du problème
Posté par Anonyme . Évalué à 2.
car lorsque tu foire l'INIT systemV->systemD , comme son nom ne l'indique pas tu ne démarre pas, et dans ce cas tu te retrouve couillon avec ton grub et sa console pour tenter d'avoir un accès root.
ouais ouais je sais il n'y a aucun problème à le faire
[^] # Re: Ca ne règle pas la source du problème
Posté par Chris K. . Évalué à 2.
Ça dépend aussi de comment tu t'y prends.
Dans la procédure Debian de mise à jour vers systemd ( https://wiki.debian.org/systemd#Configuring_for_testing ) tu ne changes pas directement l'init par défaut, tu changes d'abord le paramètre de boot à la main la première fois pour vérifier que le système démarre et si tout s'est bien passé, tu peux alors le définir en tant qu'init par défaut.
Lors de ce genre de manipulations, avoir une clé USB sous la main pour pouvoir démarrer en mode rescue, ça permet d'avoir l'esprit tranquille si quelque chose doit absolument mal se passer.
[^] # Re: Ca ne règle pas la source du problème
Posté par Adrien . Évalué à 5.
C'est quoi une brique de base ? Non parce que des briques qui changent il y en a:
– linux-image : change de version tout les 6 mois… et pourtant ça peut casser pas mal de chose !!
– libc/eglibc: changement de projet pour la libc…
– dernier exemple : gnome. Ils sont passé de gnome2 à 3, qui change complètement.
Pour l'utilisateur final, il me semble que le changement de gnome2/3 est nettement plus perturbant que systemd, qui est totalement transparent pour une grande partie des gens !
Remarque que je n'ai rien contre le fait de rester sur sysvinit, c'est la liberté de chacun. L'auteur a sûrement ses raisons, je ne critique pas.
Mais quand tu parle de « risque », je ne suis pas convaincu : à mon avis il y a bien plus de risque à rester sur un truc obsolète plutôt que de suivre le choix par défaut de la distribution, qui s'inscrit dans une tendance générale.
C'est d'ailleurs un des rôles des distributions : diminuer le risque de panne pour les utilisateurs, mais c'est une autre histoire.
[^] # Re: Ca ne règle pas la source du problème
Posté par Christophe . Évalué à 6.
Merci, enfin un argument qui cherche élever le débat. Oui, ok, il y a un risque à rester sur un vieil init qui va disparaître. Mais pour l'instant, c'est là, c'est supporté par Debian et ça marche pour lui.
Lorsqu'il voudra un jour installer un .deb extérieur qui ne sera prévu que pour systemd, il aura alors un problème. Donc un besoin. Donc une raison d'installer et apprendre systemd. Mais pour l'instant, le besoin, il n'existe pas.
Et dans ce fil de commentaires, tu es bien le seul… Les autres lui reprochent de ne pas installer systemd !
[^] # Re: Ca ne règle pas la source du problème
Posté par totof2000 . Évalué à 10.
Parce que sinon il est résistant au changement.
[^] # Re: Ca ne règle pas la source du problème
Posté par Albert_ . Évalué à 7.
C'est vrai il aurait meme du garder son bash tout troue de la version original de 2013…
Les mises a jour cela ne concerne pas que "je met la derniere version du logiciel".
[^] # Re: Ca ne règle pas la source du problème
Posté par Zenitram (site web personnel) . Évalué à -6.
Il faut qu'on m'explique comment systemd peut être installé comme ça par une update de sécurité de Debian Wheezy (la dernière stable en date, donc si tu veux pas autre chose que des mises à jour de sécurité on a celle-la, on est bien d'accord) qui a systemd en "technology preview" seulement.
Je suis étonné d'ailleurs par "dist-upgrade" dans le journal, et pas "update". Ou alors on ne parle pas de la même chose…
[^] # Re: Ca ne règle pas la source du problème
Posté par Albert_ . Évalué à 0. Dernière modification le 27 novembre 2014 à 12:13.
Il faut qu'on m'explique comment systemd peut être installé comme ça par une update de sécurité de Debian Wheezy
Je n'ai pas de debian sous la main mais sous ubuntu (qui n'a pas encore systemd comme init) tu as tout de meme systemd qui est installe car demande par certains applications (je sais ce n'est pas un systemd complet mais le paquet il est la).
Je suis étonné d'ailleurs par "dist-upgrade" dans le journal, et pas "update". Ou alors on ne parle pas de la même chose…
Et pourquoi voudrais tu faire un "update" tout court plutot que un "dist-upgrade"?
Je rappelle:
[^] # Re: Ca ne règle pas la source du problème
Posté par Zenitram (site web personnel) . Évalué à -10. Dernière modification le 27 novembre 2014 à 12:18.
Comme Debian. Donc peur irrationnelle de l'auteur du journal et des auteurs de commentaires qui ont peur que les scripts d'init cassent, CQFD.
"upgrade", typo.
qui donne "de même, des paquets qui ne sont pas déjà installés ne sont ni récupérés ni installés"
[^] # Re: Ca ne règle pas la source du problème
Posté par Christophe . Évalué à 7.
Tu as vraiment tendance à prêter aux autres des propos qu'ils n'ont pas dits. Il a "peur que les scripts d'init cassent" ? Où as-tu lu ça ?
Le risque existe, même infime. Par ailleurs, il y a deux possibilités:
* la mise à jour installe un sous-morceau de systemd, sans le reste --> ça n'apporte rien fonctionnellement et ton système est moins simple. Autant l'éviter, donc
* la mise à jour installe systemd en complet, à la place de l'init SysV --> même si tout se passe bien, il faudra passer du temps à apprendre systemd. Son système d'init SysV le satisfait aujourd'hui, il n'y a donc aucun besoin en face. Ce n'est donc pas une priorité.
Je vais finir par une conclusion à la Zenitram:
C'est marrant les gens qui pensent que ce qui est mieux pour eux est forcément mieux pour la Terre entière. TOI tu as envie que LUI mette à jour son init vers systemd. Sauf que lui, il n'a pas envie, peut-être pas le temps, et apparemment pas besoin. Il a le droit de respirer ?
[^] # Re: Ca ne règle pas la source du problème
Posté par xcomcmdr . Évalué à -4.
Quel risque EXACTEMENT ?
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Ca ne règle pas la source du problème
Posté par Christophe . Évalué à 2.
Oh allons, pitié, disons, un bug ? Un script particulièrement pourri qu'il aurait conçu ? Le risque zéro n'existe pas en informatique.
Mais sinon, j'en déduis que tu es d'accord avec le reste ?
[^] # Re: Ca ne règle pas la source du problème
Posté par xcomcmdr . Évalué à -2.
Alors pourquoi il accepte les mises à jours de toute le reste (y compris du kernel, qui peut tout autant avoir des bugs et qui est bien plus critique que l'init) et pas de SysV vers systemd, d'autant plus que ce dernier est compatible avec les scripts ?
C'est pas cohérent !
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Ca ne règle pas la source du problème
Posté par Christophe . Évalué à 6.
Parce que pour systemd ce n'est pas une mise à jour, c'est un changement de logiciel. Il va, magiquement, savoir utiliser systemd juste après la mise à jour ?
C'est très cohérent: vu qu'il a le choix (enfin en vous lisant, j'ai des doutes…), il choisit la mise à jour la moins impactante, et donc de rester sur SysV.
Bizarrement, personne ne conteste l'élément essentiel de mes commentaires: il n'a pas besoin de passer à systemd.
[^] # Re: Ca ne règle pas la source du problème
Posté par xcomcmdr . Évalué à -10. Dernière modification le 27 novembre 2014 à 15:31.
Passer de linux 3.14 à linux 3.15, c'est pas un changement de logiciel peut-être ?
Une mise à jour, ça ne change pas le logiciel… Ben ça met à jour quoi alors ?
Quant à savoir utiliser systemd :
- y'en a pas besoin pour booter avec systemd, ça va fonctionner avec les scripts existants
- les commandes se ressemblent fortement (et c'est voulu)
- une mise à jour de sysV ver systemd, l'utilisateur lambda ne voit aucune différence… (il touche pas à l'init)
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Ca ne règle pas la source du problème
Posté par Christophe . Évalué à 10. Dernière modification le 27 novembre 2014 à 15:53.
Ça vire à la mauvaise foi, là. J'ai dit: un changement de logiciel. Tu es la première personne que je rencontre à comprendre ça comme un changement de version d'un même logiciel.
Passer de linux 3.14 à linux 3.15, c'est une mise à jour.
Passer de linux 3.14 à hurd 0.008, c'est un changement de logiciel.
Si tu ne vois pas la différence, on peut arrêter là la discussion.
Sinon, continuons. Systemd c'est mieux, la mise à jour c'est automagique, génial. Je suis d'ailleurs assez d'accord sur ces points, de toute façon.
Par contre:
- les commandes se ressemblent, certes… se ressemblent. Donc lorsqu'il fera /etc/init.d/network restart, ça va marcher ? non. Ou à moitié. En tout cas, ce n'est pas la bonne méthode.
- l'utilisateur lambda ne saurait même pas que le système d'init a changé lors de l'upgrade. Hors-sujet: on n'est pas face à l'utilisateur lambda, on est face à quelqu'un qui a bidouillé son init et souhaite en garder la maîtrise.
Bref, on en revient toujours au même point, inlassablement: systemd c'est super, mais ce n'est pas une raison suffisante pour le forcer à changer son init.
Je vais arrêter là, parce que ça fait déjà 4 quatre fois que je me répète, et j'ai l'impression de parler à un mur.
[^] # Re: Ca ne règle pas la source du problème
Posté par vv222 . Évalué à 3.
service network restartfonctionne tout aussi bien avec systemd qu’avec SysV.Je ne serais d’ailleurs pas étonné que ça fonctionne aussi avec OpenRC et autres upstart…
[^] # Re: Ca ne règle pas la source du problème
Posté par xcomcmdr . Évalué à -1.
Toujours pas convaincu, et ce commentaire exprime ma pensée.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Ca ne règle pas la source du problème
Posté par Misc (site web personnel) . Évalué à 3.
Ceci dit, wheezy a forcé un support obligatoire des tags LSB dans les scripts d'init. C'est aussi une source d'erreur potentiel, et j'ai vu 0 personnes en parler et/ou raler et/ou demander un GR sur le sujet.
Bien sur qu'il y a des trucs qui ne vont pas marcher, comme par exemple, un script interactif au boot ( mais qui n'aurait pas marcher sans doute en wheezy non plus ). Maintenant, d'une part, y a encore quelques mois avant la release de jessie, et il y a encore quelques mois après la release. Et si le souci, c'est que Debian release trop vite, on peut difficilement dire que ç'est la fate à systemd.
Car des changements, y en a a toujours. L'exemple que je donne sans arrêt, c'est apache 2.4, mais je peux aussi donner les versions majeurs de php au moment de php4 et je peux te dire que du code php, c'est autrement plus long à fixer que 3/4 scripts d'inits.
Donc perso, je pige pas le fait de se focaliser sur systemd et d'idéaliser complétement le reste en occultant les pétages réguliers de la compatibilité par divers upstreams.
[^] # Re: Ca ne règle pas la source du problème
Posté par Christophe . Évalué à 3.
Parce qu'au bout de trente répétitions, il y a quelque chose que je n'arrive pas à faire rentrer dans la tête de ceux qui me répondent: jusqu'à preuve du contraire, l'auteur du journal n'a pas besoin de systemd. C'est tout ! point.
C'est bien gentil de défendre systemd bec et ongles, sauf que ce n'est pas systemd que je critique, c'est le fait de vouloir absolument que quelqu'un l'installe alors qu'il n'en a pas le besoin. systemd, c'est un init qu'il ne connaît peut-être pas encore, et manifestement il souhaite maîtriser son init. Il faudrait arrêter de faire semblant de ne pas voir la différence entre le passage d'une version à une autre d'un logiciel qu'on connaît déjà, et le passage d'un logiciel à un autre qui n'a pas du tout la même logique.
[^] # Re: Ca ne règle pas la source du problème
Posté par eingousef . Évalué à 4.
+1
Perso je suis pas super expert sur le sujet, et je saurais pas te dire de deux systèmes d'init lequel poutre le plus du mammouth dégraissifié, mais l'histoire avec les mises à jour chelous ça me fait penser à la situation suivante :
L'autre jour je vais récupérer ma voiture chez le garagiste. C'était un problème tout bête, fallait juste faire la vidange de la courroie d'entraînement de l'autoradio et des essuies-glaces :o En deux jours c'était torché, mais au moment de récupérer ma bagnole le garagiste me dit « Ouais alors on a fait tout ce qu'il fallait, par contre on a aussi changé les pompons sur le rétroviseur et le chien qui remue la tête à l'arrière, ils étaient tout pourris on vous en a mis des mieux. » Alors là jménerve tu vois j'étais sur le point de lui faire manger du poivre au mec ! Pis après il me dit « C'est gratuit. ». Ah bon ok.
C'est vrai que c'est pas super grave tu vois, après tout c'est juste un putain de chien qui remue la tête, c'est pas comme si j'en avais besoin tous les jours, déjà il était tellement moche qu'on pouvait difficilement faire pire, et puis même si c'est pire, au pire, tant pire je le remplace par un autre en deux secondes c'est super simple.
Mais avec systemd c'est plutôt la situation suivante :
L'autre jour je vais rerécupérer ma rebagnole chez ce putain de regaragiste. C'était un problème tout bête, y fallait juste faire le dégivrage du réservoir diesel du starter de la roue de secours :o Un truc tout simple en trois jours c'était torché, mais au moment de récupérer ma bagnole le mec y me dit « Ouais alors on a fait tout ce qu'il fallait, par contre on a aussi changé le moteur celui d'avant était nul on en a mis un mieux. ».
Je suis désolé< mais NON ! Putain de bordel de manche à couilles jvais te faire manger 6 kilos de poivre par l'autre boutte moi tu vas voir ! :o Alors là après il me dit « C'est gratuit. ». Mais t'inquiète mon poulet, le poivre je vais pas te le facturer non plus ! :o « Nan mais vous allez voir il est mieux ce moteur l'autre il était vraiment nul avec celui-là ça ira plus vite et puis tous les problèmes que vous aviez pas avant, ben là vous les aurez pas non plus ! En plus ça vous dérange pas la dernière fois pour le chien qui remue la tête vous avez pas fait autant votre difficile ! ».
Bon alors qu'une chose soit claire. Quand on me change des applications de haut niveau jore le chien qui remue la tête, je m'en fous. Il y a des chances qu'il soit mieux, des chances qu'il soit pareil, des chances que ce soit moins bon, mais l'enjeu est pas énorme et en cas de problème je peux m'en débarrasser facilement, c'est pas comme si tout le fonctionnement de la bagnole reposait dessus.
PAR CONTRE quand on me change un truc comme le moteur EXCUSE-MOI mais ça me fait dinguelinguelingue dans le fond de la tête avant même que j'aie appuyé sur le bouton start :o Certes les chances que ce soit effectivement moins bon que le précédent sont pas plus grandes que pour le chien qui remue la tête, mais là l'enjeu n'est pas le même ! Là j'avais un moteur peut-être pas au top du top fashieunne de la collection printemps-automne, mais que j'utilise depuis 10 ans et que je connais bien, et on veut me le remplacer du jour au lendemain par un truc que je connais pas du tout, en me disant que peu importe si les interfaces sont pas pareil ce qui compte pour toi c'est juste la couleur du tableau de bord, le reste tu n'as pas besoin de le savoir, blablabla. Mais mayrde ! Surtout que ça marchait déjà très bien avant :o
Alors t'es gentil mon poulet, tu retires tout ton merdier et tu me remets le moteur que j'avais avant. Le jour ou j'aurai besoin de ton nouveau moteur à la mode je te ferai signe.
« Euh ben c'est-à-dire que… En fait cette nouvelle génération de moteur elle est très complexe… et le moteur pour qu'il tienne il doit être soudé à tout le reste… alors on va pas pouvoir vous le changer comme ça… D'ailleurs on avait prévu de vous changer toutes les autres pièces au fur et à mesure dans les jours qui suivent pour assurer une compatibilité maximale… »
Putain ! NAN mais je RAAAAAAAAIYVE !! \°□°/
C'est pas juste du poivre que je vais te faire bouffer mon canard ! C'est ton putain de moteur, avec la carrosserie, le châssis, l'autoradio, la roue de secours, le bouton start et le chien qui remue la tête !
DAIGAJE sale tchakapan ! (╯°□°)╯ ︵ ʇɐH pǝᴚ ǝʇsıƃɐɹɐ⅁
La dernière fois qu'un truc pareil m'était arrivé c'était quand j'utilisais Gnome 2 sous debian, et que du jour au lendemain je me suis retrouvé avec un nouvel environnement de bureau - visiblement un truc très expérimental, sûrement une version alpha - auquel je ne m'attendais pas du tout, et où je ne trouvais même pas le bouton "redémarrer" ! Bon apt-get install xfce-desktop, puis le problème était résolu.
Là avec systemd j'ai été plus prudent, je l'ai mis on hold (c'est avec la touche "=" dans aptitude), mais du coup les jours suivant à chaque mise à jour il voulait me supprimer un paquet ! Un coup c'était network-manager, un autre coup c'était le display manager, un autre coup c'était le machin pour monter les disques. À chaque fois j'ai du trouver des alternatives, ça m'a bien fait chier. Bon là y'a une période de calme, ouf. J'avais peur qu'on me demande de virer DéBuCe :o
Ouais alors du coup quand je voyais des gens dire que sysvinit c'était de la merde que que systemd allait résoudre tous mes problèmes, ça me faisait bien marrer. J'intervenais, jore :
Qu'est-ce que tu veux répondre à ça :/
Alors ptet que ça sert pas à grand chose de faire des journaux qui critiquent systemd, ok je veux l'admettre, mais en tout cas c'est bien de faire des journaux qui expliquent comment on peut s'en passer. Parce que pour ceux qui veulent pouvoir continuer à utiliser Linux sans systemd, ça fait avancer le schmilblick. Par contre ça ne plaît pas aux systemdiens, allez savoir pourquoi.
Les systemdiens, tu critiques systemd sans proposer de solution, ils râlent. Tu critiques systemd en proposant une solution, ils râlent. En fait ce qui les emmerde c'est que tu critiques systemd. Et après il vont dire que c'est les anti-systemd qui râlent tout le temps. :o
*splash!*
[^] # Re: Ca ne règle pas la source du problème
Posté par coid . Évalué à 0. Dernière modification le 29 novembre 2014 à 19:18.
L’analogie avec ta bagnole est super pertinente! Mon dieu, il fallait le dire que Linux t’appartenait! Personne n’était au courant. Faut pas faire des cachotteries comme ça… Les dévs, ils savaient même pas que tu leur avais demandé de réparé ton Linux, ils ne savaient même pas qu’ils n’étaient que des garagistes mal dégrossis qui touchent impunément à ton OS. Ces couillons graisseux, ils croyaient qu’ils pouvaient développer ton Linux comme bon leur semble. C’est quand même couillon, ça!
Merci d’avoir prévenu. Tout va bientôt rentrer dans l’ordre maintenant que tu les as avertis de leur grosse bévue. Ils vont remettre le vieux moteur que tu ne leur as pas demandé de changer.
;)
[^] # Re: Ca ne règle pas la source du problème
Posté par Anonyme . Évalué à 2.
T'as du rater un truc important la, c'est pas trop comme ca que ca fonctionne. Les developeurs Debian mettent à disposition gratuitement un OS. Si la facon dont il évolue ne te convient pas, tu es libre de ne pas l'utiliser, ou d'y contribuer pour essaier de le faire évoluer comme tu le souhaite. Mais pas d'éxiger qu'ils fassent ce que toi tu as décidé.
Il y a une petite difference avec ton garagiste: dans un cas tu es un client, dans l'autre non.
Oui et puis le noyau linux d'il y a 10 ans fonctionnait egalement très bien. Et l'enjeu est au moins aussi important que pour le systeme d'init. Pourquoi est ce qu'il a été mis à jour ?
[^] # Re: Ca ne règle pas la source du problème
Posté par Misc (site web personnel) . Évalué à 5.
j'ai pas besoin de certaines fonctions de la glibc, je fait pas un foin car elles sont disponible, car je sais que trop de modularité a un cout. J'ai pas besoin de 90% des paquets dispo dans ma distributions, et ça prends du temps pour calculer les dépendances, et pareil, je demande pas à les virer spécialement pour moi.
C'est pareil ici. C'est bien joli de croire que le libre s'écrit tout seul, mais c'est pas le cas. A un moment, tu te dit que plutot que faire 2 fois le travail, tu va le faire qu'une fois, et tant pis si il y a des choses dont les gens ont "pas besoin", car ce qui est rare, c'est le temps de contribution, pas les besoins utilisateurs. Donc on optimise pour réduire les "couts" en terme de temps sur le contributeur, pas l'utilisateur de la contribution la plupart du temps ( j'écarte le cas plus complexe ou il y a plusieurs contributeurs chainés dans la chaine de de production vers l'utilisateur final ).
[^] # Re: Ca ne règle pas la source du problème
Posté par Albert_ . Évalué à 2.
Comme Debian. Donc peur irrationnelle de l'auteur du journal et des auteurs de commentaires qui ont peur que les scripts d'init cassent, CQFD.
Tu es con ou quoi? Ubuntu n'utilisera systemd pas avant la version 15.04 c'est a dire l'annee prochaine. Donc oui je suis desole mais je n'utilise pas systemd car ma distrib ne l'a pas encore.
ton deuxieme point rien compris mais j'ai comme l'impression que tu trolls sur des trucs que tu ne connais pas/plus…
[^] # Re: Ca ne règle pas la source du problème
Posté par Adrien . Évalué à 10.
systemd devient super courtant, donc il y a fort à parier qu'il sera mieux testé, mieux gérés par les logiciels, il y aura plus d'aide dessus, etc.
Donc rester sur un système obsolète n'est pas forcément un bon choix non plus.
[^] # Re: Ca ne règle pas la source du problème
Posté par gnumdk (site web personnel) . Évalué à 4.
Si il veut un système quotidien n'évolue pas, il utilise Debian stable!
[^] # Re: Ca ne règle pas la source du problème
Posté par vv222 . Évalué à 6.
Le paquet
systemdpour Debian ne fournit pas les liens lui permettant d’être utilisé comme système d’init. L’installation de ce paquet ne change pas le système en place.benoar ne fait donc pas ça pour éviter/retarder un changement d’init mais pour éviter toute trace de systemd sur sa machine.
[^] # Re: Ca ne règle pas la source du problème
Posté par Cyril Brulebois (site web personnel) . Évalué à 3.
Cela doit être rigolo, une vie sans
/lib/systemd/systemd-udevd.Debian Consultant @ DEBAMAX
[^] # Re: Ca ne règle pas la source du problème
Posté par vv222 . Évalué à 8.
Les vrais barbus utilisent MAKEDEV enrobé de scripts shell (POSIX le shell bien sûr).
C’est tellement KISS tu vois…
[^] # Re: Ca ne règle pas la source du problème
Posté par Anthony Jaguenaud . Évalué à 2.
Sinon, il y a eudev comme solution intermédiaire…
[^] # Re: Ca ne règle pas la source du problème
Posté par vv222 . Évalué à 0.
Vu qu’il s’agit d’un fork d’udev, ça ne suffira pas à satisfaire les allergiques au "code de Lennart".
[^] # Re: Ca ne règle pas la source du problème
Posté par Anthony Jaguenaud . Évalué à 2.
D’un autre coté, il ne me semble pas que μdev contiennent beaucoup de code de Lennart…
De plus, il faut arrêter de penser que les gens critiques juste parce qu’ils allergiques.
[^] # Re: Ca ne règle pas la source du problème
Posté par Thomas Douillard . Évalué à 9.
Quand on est pas convaincus par les arguments techniques et qu'on a migré en 2 secondes à systemd sans le moindre problème, on a des doutes sur la rationnalité des critiques.
[^] # Re: Ca ne règle pas la source du problème
Posté par Anthony Jaguenaud . Évalué à 1.
Je ne suis pas convaincu pour plein de raison technique que je ne réexposerai pas pour me mettre au même niveau que :
Néanmoins, pour l’avoir actif sur une debian Jessie, je n’aime pas le fait de n’avoir que deux lignes pendant la phase de démarrage… mes partitions sont clean, et la LED du disque tourne… je préférais l’ancien système parce qu’au moins je savais où il en était. L’autre raison, c’est que je m’attendais bêtement à un démarrage rapide, ce n’est pas le cas. Donc voilà, oui, il fait le job, mais si tu vas par là, pourquoi utiliser GNU/Linux puisque Windows et MACOS font le job.
Moi, j’ai choisi GNU/Linux pour la liberté de pouvoir choisir et configurer son OS.
[^] # Re: Ca ne règle pas la source du problème
Posté par Thomas Douillard . Évalué à 3.
Aaah, les trolls sur le boot graphique et l'affichage de l'état du boot et la référence à "autant utiliser windows", merci, je viens de rajeunir de 10 ans.
[^] # Re: Ca ne règle pas la source du problème
Posté par Anthony Jaguenaud . Évalué à 1.
Détrompe toi, le boot n’ai pas graphique, c’est du texte avec un jolie curseur. Enfin, un écran vide avec de ligne et un curseur.
Quand à la « référence » je me mets au niveau.
[^] # Re: Ca ne règle pas la source du problème
Posté par Anthony Jaguenaud . Évalué à 1.
Oups, pardon pour l’orthographe, grammaire… je vais aller me coucher !
[^] # Re: Ca ne règle pas la source du problème
Posté par Sufflope (site web personnel) . Évalué à 8.
Sous ma Fedora le boot est graphique, mais si j'appuie sur echap j'ai une ligne par démarrage de service avec [OK] quand c'est fini. Certes ça fait moins d'info que sous ma debian de 2006, sauf que sur celle-ci j'avais 1500 lignes qui défilaient en 30s donc je ne voyais au final rien.
Bref ce qu'on peut déduire de nos messages : avec systemd + fedora on sait où le boot en est, et avec systemd + debian non. Le problème est donc debian.
[^] # Re: Ca ne règle pas la source du problème
Posté par Renault (site web personnel) . Évalué à 3.
Sans compter que les logs restent quoiqu'il arrive disponibles après le boot effectué, tu peux même coder un programme qui t'envoie une notification s'il y a eu une erreur au démarrage (Fedora en avait un avant). Je trouve plus intelligent d'être prévenu en cas d'erreur que de vérifier systématiquement au démarrage si tout s'est bien passé (ce qui est difficile car le démarrage est rapide).
[^] # Re: Ca ne règle pas la source du problème
Posté par Thomas Douillard . Évalué à 0.
Quel niveau exactement ? Tu peines à trouver des problèmes qui sont des problèmes.
[^] # Re: Ca ne règle pas la source du problème
Posté par Anthony Jaguenaud . Évalué à 5.
Je réponds à ça :
Que j’interprète, sûrement à tort comme :
Il y a plein de population qui utilise GNU/Linux, mon père, ma mère… eux le système d’init il s’en moque. Le geek un peu intéressé, systemd c’est bien, ça marche chez moi, et je peux facilement faire des petites modifs. L’admin qui administre plein de machines chez différents clients, qui a investi des centaines de jours pour avoir un système qui marche. Et qui derrière cette petite révolution voit les centaines de jours d’adaptation et de validation arriver avant que son client (banque, grand compte…) n’accepte ça.
Et une fois déployé, pas de chance une faille de sécurité oblige à prendre une version corrigé, à mince, il faut prendre la dernière version dans la branche
masterce qui tire de nouveau, noyau… et là tu repars sur un cycle de vérification pendant que la faille est disponible. Tant qu’il n’y aura pas une versionLTSde systemd avec des mise à jour de sécurité, une partie des admin freinera forcément des quatre fers.Mais ce n’est pas parce que tu es dans une des populations que les inquiétudes des autres sont ridicules.
Je en sais pas si c’est plus clair.
[^] # Re: Ca ne règle pas la source du problème
Posté par Prosper . Évalué à 7.
Genre Redhat ou Suse ne vont pas backporter les patchs comme les 2000 autres logiciels qui sont dans leur distrib ?
[^] # Re: Ca ne règle pas la source du problème
Posté par Prosper . Évalué à 0.
Et puis c'est quoi encore cette histoire du master de systemd qui dépend du dernier noyau en date ? systemd 217 dépend de la version 3.7 a minima ( quasiment 2 ans donc ) , pas de de la version 3.17. Je vois que les FUDs que balance kaane< dans la news en cours de rédaction ont bien pris.
[^] # Re: Ca ne règle pas la source du problème
Posté par Kaane . Évalué à 7.
Je vois que les FUDs que balance kaane< dans la news en cours de rédaction ont bien pris.
Bonjour,
N'hésite surtout pas à dénoncer mes "FUD" dans la dépêche en cours de rédaction. Pour information le "FUD" doit faire référence à ce texte :
Qui est un post de Lennart Pottering. cf Post Original
Donc a) merci de ne pas appeler FUD ou déni chacun de mes posts b) si vous avez quelque chose à me dire n'hésitez pas, je n'ai jamais mordu personne et c) n'hésitez pas non plus à me ridiculiser, par exemple en postant des sources crédibles qui me contredisent.
Pour le problème du jour : Lennart a annoncé dans le post déjà cité plu haut :
Ce qui se traduit par, "Veuillez aussi prendre note qu'à partir de maintenant nous avons l'intention d'utiliser kdbus comme protocole de communication pour udev, et de nous débarrasser de la liaison userspace vers userpace basé sur netlink que nous utilisions jusque là".
Dont acte dans le source trunk du dernier udev il n'y a plus de liaison netlink. Donc le prochain systemd/udev (sauf revirement) ne sera compatible qu'avec les kernel ayant kdbus.
C'est quoi le premier kernel avec kdbus déjà ?
[^] # Re: Ca ne règle pas la source du problème
Posté par Prosper . Évalué à 5.
Bon bah testons alors :)
le kernel n'est pas le dernier donc surement pas avec kdbus
uname -a => Linux plop** 3.14.25**-1-lts #1 SMP Fri Nov 21 19:41:09 UTC 2014 x86_64 GNU/Linux
je viens juste de compiler la branche master de systemd
pacman -Qv systemd-git => systemd-git 217.443.g895b3a7-1
et pourtant :
1/ ca boot sans erreur
2/ networkd que j'utilise fonctionne et networkctl ne me retourne aucune erreur.
Bref, quel est le problème ?
[^] # Re: Ca ne règle pas la source du problème
Posté par Christophe . Évalué à -1.
Le problème est que tu es en train d'utiliser une fonctionnalité obsolète de systemd, qui n'est là que pour assurer la transition et qui est vouée à disparaître. Effectivement, ça marche pour la version 217. C'est tout ce qu'on peut en déduire.
L.P. a toujours dit que systemd serait fortement lié au noyau, et utiliserait le plus possible ses fonctionnalités. Donc, comme il le dit lui-même, ça marchera avec des noyaux un peu plus vieux, mais faudra pas pousser trop loin.
C'est un choix qui apporte des avantages au niveau technique, mais qui peut apporter aussi des pièges niveau maintenance.
[^] # Re: Ca ne règle pas la source du problème
Posté par Prosper . Évalué à 4.
Heureusement que j ai precisé avoir compilé depuis le trunk master…. c'est un peu le sujet .
[^] # Re: Ca ne règle pas la source du problème
Posté par Misc (site web personnel) . Évalué à 0.
Nan mais c'est Kaane aussi. Il va te dire "tel truc trunk marche pas sans ça", et rien que le fait qu'il soit pas foutu d'utiliser le bon terme ( trunk, c'est pour svn, pas git ) montre qu'il maitrise pas vraiment le sujet.
Ensuite, tu va lire le code source, tu va voir que udevd utilise encore un socket netlink ( genre dans worker_new, http://cgit.freedesktop.org/systemd/systemd/tree/src/udev/udevd.c#n174 ), et la, tu as compris qu'il a du prendre sans doute du faire une faute dans un grep et qu'il conclue à la vavite.
Jamais il va pointer vers du code, ou ce genre de choses, faut toujours passé du temps à double vérifier ses affirmations, car ça a l'air sérieux, mais en pratique, non. Suffit de voir les dépêches sur systemd d'il y a 1 ou 2 ans, ou j'ai quand même passé un bon paquet de temps à expliquer les choses, car ce genre de comportement est à mon sens toxique pour la communauté, car ça masque les critiques légitimes en les recouvrant de bullshit.
[^] # Re: Ca ne règle pas la source du problème
Posté par Kaane . Évalué à 10.
Nan mais c'est Kaane aussi.
Perdu, là en l'occurence c'était Christophe Chapuis.
_ Il va te dire "tel truc trunk marche pas sans ça", et rien que le fait qu'il soit pas foutu d'utiliser le bon terme ( trunk, c'est pour svn, pas git ) montre qu'il maitrise pas vraiment le sujet._
Si il y avait dans le GIT systemd une seule autre branche que master, je serais presque tenté d'être d'accord avec toi. Mais trunk ca veut dire tronc, et quand il n'y a pas de branches à l'arbre ça décrit parfaitement l'endroit ou se trouve le code source.
et la, tu as compris qu'il a du prendre sans doute du faire une faute dans un grep et qu'il conclue à la vavite.
J'ai peut être fait une faute dans un grep, ou été perdu par le va et vient des connections udev et de sd-bus, mais j'aimerai également te rappeler que c'est la position officielle de Lennart :
Donc niveau conclusion à la va-vite, c'est pas franchement ça. Il s'agit du point de vue officiel de la personne en charge du projet systemd.
Non mais je pointe vers des project leader qui suivent le code de très près, ce qui permet a) d'éviter de mauvaises interpretations du code, b) de ne pas mélanger mon opinion personnelle avec cette interprétation et c) de rendre le truc compréhensible par des gens qui ne lisent pas le C système (dont j'avoue volontiers faire partie).
Le comportement qui consiste à traiter sans distinction toutes les personnes qui ne sont pas intéressées par systemd d'ignorants nocifs est elle beaucoup plus constructive. Il y a des histoires de pailles et de poutres sur le sujet je crois.
[^] # Re: Ca ne règle pas la source du problème
Posté par Kaane . Évalué à 3.
Bref, quel est le problème ?
Plusieurs, à commencer par le fait que je ne sais pas à quelle version de commit correspond systemd-git 217.443.g895b3a7-1 (mais bon c'est accessoire). Ensuite le problème de liaison netlink ne se pose que sur les machines ne disposant pas de libsystemd. C'est systemd/udev qui est cassé niveau expérience utilisateur, pas systemd intégralement.
Donc avant soit on utilisait libsystemd avec tout le reste de l'environnement systemd derrière, soit on utilisait netlink.
Dans l'état actuel du trunk (et je suis prêt à parier que ca va rester en place) soit on utilise libsystemd, soit il faut se rabattre sur kdbus (et donc coder toute une API userspace pour interfacer kdbus). L'option netlink n'existe plus.
Si tu préfères il n'est absolument plus possible d'utiliser la nouvelle version de udev en l'état sans systemd complet sur un kernel sans kdbus.
Pour finir il ne s'agit pas d'un délire personnel, mais bien d'une position 100% assumée par Lennart, pour laquelle j'ai donné et le lien et la traduction.
[^] # Re: Ca ne règle pas la source du problème
Posté par Prosper . Évalué à 2.
C est le naming d'arch qui est un peu étrange cf https://wiki.archlinux.org/index.php/VCS_PKGBUILD_Guidelines#Git , mais en gros c est compilé depuis le trunk d'il y a quelques heures ( j'ai vu qu il y avait eu quelques commit après )
Donc en gros t'es un peu hors sujet , on parlait évidement de l'utilisation classque de systemd en entier pas d'un cas particulier ou on utilise juste la version udev de systemd avec un autre init.
[^] # Re: Ca ne règle pas la source du problème
Posté par Kaane . Évalué à 0.
Donc en gros t'es un peu hors sujet
Euh.. Tu m'accuses de FUDer, je prend le seul truc qui pourrait éventuellement correspondre à tes accusations et j'étaye. J'y peux rien si le seul truc qui ressemble vaguement de loin, de nuit et dans le brouillard au FUD dont tu m'accuses porte sur systemd/udev.
Je me défend contre ce sur quoi tu m'attaques, donc je ne vois absolument pas en quoi je pourrais être hors sujet.
[^] # Re: Ca ne règle pas la source du problème
Posté par Prosper . Évalué à 0.
Ce que je te reproche c'est que tu parles d'une utilisation de udev bien particulière et trop vague ( volontairement ? ) dans la dépêche en cours de redaction ( apparement il y a eu des modifs récentes qui sont bien plus claires et je t'en remercie ) et que certains personnes comme la personne a laquelle j'ai répondu ont compris "si on utilise l'init systemd et qu'on upgrade faut aussi upgrader le noyau !!!" ce qui est factuellement faux. Pour moi fin du débat.
[^] # Re: Ca ne règle pas la source du problème
Posté par Misc (site web personnel) . Évalué à 5.
Je ne sais pas si tu fudes, mais il est clair que soit tu selectionnes tes points, soit tu fait preuve d'ignorance.
Parce que avoir un kernel à jour en même temps que l'userspace, ça arrive relativement plus souvnet que tu veux faire croire.
Exemple, udev avant que ça devienne part au projet systemd :
http://lwn.net/Articles/193603/
( 2006, pour les gens qui veulent pas cliquer ). Et pour les gens qui veulent pas cliquer aussi, on voit GKH poser la question de "pourquoi on va supporter les trucs que les créateurs refusent de supporter plus longtemps".
Autre exemple ? Iptables, et notamment des projets approchants comme ipset, etc. Tu mets à jour ta distro, et il te faut une version plus à jour de tel ou tel truc interne.
Des APIs exposés sous la forme de chemin dans le système de fichier, y en a des tonnes. Le changement de pilote pour les disques IDE et le renommage des noms de disques qui a suivi ( hda/sda ) est un exemple de trucs qui a du casser des scripts. Les changements dans /sys aussi.
Le monde s'est pas arrêté de tourner pour autant. Découvrir juste aujourd'hui le problème des ABI/API c'est juste avoir été sous un igloo depuis longtemps.
Et le mail de Lennart prévient à l'avance qu'il va falloir s'adapter au changement. Je pense avoir lu sur lwn que l'idée est de déprécier l'interface au bout de ~2 ans, ce qui laisse largement le temps de pouvoir faire des mises à jours, donc on est loin des suppositions de "on va devoir mettre à jour le jour de la sortie".
[^] # Re: Ca ne règle pas la source du problème
Posté par Kaane . Évalué à 3.
On est parti
Il a posé la question et la réponse a été le support de HAL jusqu'en 2010 à peu près et le retrait total des distribs qui n'a eu lieu que vers 2011. On est loin de la rupture d'API du jour au lendemain.
hda c'etait (et c'est toujours à ma connaissance) pour le PATA de base (nappe de 40 connecteurs) ou le PATA 60Mb/s, SDA c'est pour le scsi, le SATA et certains mode en PATA (généralement 80 et 100Mb/s - nappe 80 connecteurs). Pour se retrouver avec un changement de nom qui casse le script il faut soit changer le disque, soit trifouiller dans le bios soit carrément changer de carte mère. On va dire que c'est pas franchement de la faute du kernel sur ce coup là.
Il te faut une version plus à jour si tu veux utiliser les nouvelles fonctionnalités.Mais pour le reste… Quand on est passé de IPCHAINS à NetFilter Linus a tout fait pour que les scripts soient compatibles (il y avait des modifications minimes à faire) et plus fort encore, vu le tollé que la migration de 2.0 à 2.2 avait été suite à la rupture entre IPFWADM et IPCHAINS, NetFilter était aussi compatible avec IPFWADM. Donc on pouvait passer de 2.0 à 2.4 quasiment sans toucher à ses règles firewall.
Les trois exemples que tu donnes vont exactement dans le sens contraire de ce que tu veux démontrer, le maintien de l'expérience utilisateur est une priorité du noyau (et du système Linux en général) depuis des années. Et ce n'est pas par réactionnite aiguë, c'est parce que quand le systèmes bouge trop ou trop vite, les administrateurs perdent confiance et soit changent de produit, soit restent sur le produit précédent.
[^] # Re: Ca ne règle pas la source du problème
Posté par gnumdk (site web personnel) . Évalué à 4.
sda n'a pas toujours été utilisé pour les disques SATA, j'ai eu au tout début du support du hda si ma mémoire est bonne… C'était sous Mandrake, Misc peut surement confirmer ou dire que j'ai un peu la mémoire qui flanche…
Ensuite, essaye de faire tourner une vieille distrib sur un noyau récent, tu verras que plein de chose partent en couille…
[^] # Re: Ca ne règle pas la source du problème
Posté par Kaane . Évalué à 3.
sda n'a pas toujours été utilisé pour les disques SATA, j'ai eu au tout début du support du hda si ma mémoire est bonne…
Tout au début il n'y avait pas le support AHCI/SATA natif dans Linux pour de nombreux chipsets. On devait donc régler le bus en mode compatibilité ou legacy - grosso-modo une émulation du PATA. Donc le disque était reconnu comme PATA par le noyau.
Ensuite, essaye de faire tourner une vieille distrib sur un noyau récent, tu verras que plein de chose partent en couille…
Ben Honnêtement pas tant que ça. Il y a bien sur tout ce qui dépend des linux-headers qui est à recompiler à la main et Xorg est une cause perdue si il y a plus de 9/10 mois de différence entre les deux noyaux. Mais pour le reste ca passe pas mal du tout. Honnêtement en environnement serveur entreprise (qui est à mon sens le seul genre d'environnement ou il y a un interet à se livrer à ce genre de pratiques) ca se fait. La période horrible à ce genre de jeux là ca a été le passage de GCC 4.2 à GCC 4.4 et une liste d'incompatibilités longue comme le bras. Là oui quand tu veux migrer ton kernel et les outils liés à ce kernel dans une version récente, tout en gardant tout le reste sur des versions obsolètes mais en ayant quand même les nouvelles bibliothèques systèmes qui sont linkables par les vieux paquets. Là tu douilles.
Ceci dit quand tu fais ça c'est que tu cherche à préserver un ou deux logiciels (généralement proprios) pas toute une distrib fonctionnelle donc tu fini par y arriver quand même.
[^] # Re: Ca ne règle pas la source du problème
Posté par Misc (site web personnel) . Évalué à 3.
Je confirme, mais visiblement, c'est un temps que Kaane a du soit oublier, soit ne pas connaitre, car ça remonte quand même à longtemps ( facile 7 à 10 ans ).
[^] # Re: Ca ne règle pas la source du problème
Posté par barmic . Évalué à 10.
Mais des gens s'en plaignent depuis longtemps. Sérieux tente de lancer Unreal Tournement 2003 ou 2004 sur une distribution aujourd'hui. Prend même Debian old stable si ça te fais plaisir. A mon dernier essaie il y avait à minima un problème sur la manière dont était géré le son. Tu peut probablement le lancer, mais il va te falloir une série de hacks.
Ces problèmes on en a déjà beaucoup trollé dessus et c'est être dans le déni que de ne pas le voir. On expliquera que ce n'est un problème que pour les logiciels propriétaires, que pour les logiciels qui ne sont pas maintenus, etc, oui dans un monde parfait tout le monde est totalement à jour, on a des armés de millions de packageurs pour chaque distribution, tous les logiciels qui ne sont pas tout à fait maintenus sont inutiles, mais bon en attendant il y a des gens qui essaient de se servir de linux dans des conditions pas optimales.
Ces gens n'ont pas l'air très intéressants pour la communauté vu qu'au lieu d'essayer de stabiliser les choses, on accélère la fuite en avant.
Ces gens pourtant c'est ceux qui font la fierté de linux (HPC et calcul scientifique). Je présume que ça ne représente pas quelque chose de très important pour l'habitué des flamewares.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Ca ne règle pas la source du problème
Posté par Misc (site web personnel) . Évalué à 2.
je sais, même déjà à l'époque de UT99, c'était compliqué. Le faire tourner 3/4 ans après, il fallait ressortir les vielles libs dans un chroot.
Je suis d'accord pour dire que c'est un souci, je suis juste pas d'accord pour dire que systemd est le premier exemple, et donc ralé sur ça spécifiquement sur systemd, c'est faire preuve de mauvaise foi. Et accuser spécifiquement lennart alors qu'il ne fait que suivre la voie tracée par les codeurs noyaux et tout le reste de l'écosystème depuis des années, c'est simplement n'importe quoi. Des gens utilisent ça pour se donner un argument de respectabilité illusoire auprés des nouveaux venus. Et c'est un peu comme les gens du mouvement gamergate qui parle d'éthique dans le journalisme dans le jeu video d'un coup, alors que c'est un souci depuis des années ( exemple connu, Marc Lacombe aka Marcus ayant quitté Gameone à cause des pressions d'Infogramme sur la redaction ), et certains s'en servent pour se donner une image présentable pour juste se défouler et attaquer les gens. C'est moindre dans le libre, mais on retrouve quand même au moins un mec qui fait parti des 2 mouvements ( aka MikeeUSA, aka Gregory Smith, etc ).
mais si c'était tellement un souci pour le libre, les gens utiliseraient Netbsd, Centos ou ce genre d'OS qui promettent une compatibilité plus longue. Si c'était un souci suffisamment important, les gens ne rejetteraient pas la LSB comme contraignante mais l'adopteraient. Ou on aurais plus de tests automatisés d'ABI/API via http://ispras.linuxbase.org/index.php/ABI_compliance_checker . moins de gens à se jeter sur ruby/go/node etc et la catastrophe d’écosystème pas ultra mature et stabilisé.
Et ce qu'on voit plutôt, c'est que les devs veulent les nouvelles versions des libs ( Google Chrome et RHEL 6 pour ne citer que cet exemple, gcompris qui avait besoin d'un gtk récent et les discussions de son auteur ici il y a une paire d'année ).
C'est que ça fait chier de garder la compatibilité alors qu'on peut juste faire un code dump sur ruby.
[^] # Re: Ca ne règle pas la source du problème
Posté par barmic . Évalué à 5.
On est d'accord.
Tu mélange beaucoup de choses :
Non, parce que NetBSD n'a pas les même performances que linux et parce qu'il n'a pas le même support (autant matériel que logiciel).
CentOS et RHEL (et peut être Suse) c'est ce qui est utilisé oui, mais ça n'empêche pas d'avoir des cassures franches.
Ce ne sont pas les même personnes, ni les même applications. Il y a une grosse partie de technophiles, qui font du web entre autres qui veulent utiliser les toutes dernières techno pour présenter des interfaces les plus agréables possibles à leur client (c'est entre autre ce que fait Google, Amazone, Twitter, Facebook, etc). Mais ça n'empêche pas d'avoir des gros utilisateurs de linux utiliser du code Fortran, C, C++ et ADA pas ou moyennement maintenu pour faire du calcul haute performance, du trading haute fréquence, pour faire tourner leur banque, leur production industrielle, pour faire tourner des applis scientifiques (je pense à ce qu'on trouve par exemple dans les accélérateurs de particules).
On parle bien de types d'utilisateurs totalement différents. C'est vrai qu'on voit sur le web plus de personnes qui font du web (comme c'est bizarre), comme ils sortent une nouvelle techno tous les dimanches matin ils ont toujours pleins de choses à dire.
Pour savoir pourquoi ces gens ne participent pas à la LSB et au test automatisées d'ABI. Je pense que c'est pas leur habitudes, que les trolls (et les fortes personnalités) font peur. Qu'ils maintiennent des vielles appli donc qu'ils ne peuvent pas comme ça être LSB compliant.
Je ne dis pas que ces gens n'ont pas de défaut et que la faute reviens qu'aux mainteneurs, je dis que le problème existe et que c'est entre autre là dessus qu'AIX fais son beurre.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Ca ne règle pas la source du problème
Posté par Misc (site web personnel) . Évalué à 4.
Certes, mais on peut pas avoir le beurre et l'argent du beurre. La compatibilité a un cout humain, et le temps que tu passes à tester et à vérifier que rien ne casse, c'est du temps que tu passes pas à optimiser et à coder pour du nouveau hardware.
Un exemple stupide. Tu codes ton unix like avec l'infra video du moment, et en l'espace de 5 ans, tout change et il te faut de la 3d partout. Si tu t'occupes de la compatibilité, alors tu va maintenir 2 couches. Si tu t'en fout, alors tu va t'occuper que de la dernière. Et tu va passer plus de temps à rendre la dernière rapide/propre/etc que si tu avais que la moitié ou 75% du temps.
Bien sur, ça n'explique pas tout pour netbsd, mais ça explique une partie.
Et peut être qu'une innovation rapide mais chaotique et cahoteuse à la Linux marche mieux pour avoir le support du hardware et des perfs, ce qui ensuite attire plus de gens, dans un cercle vertueux.
Et en effet, des boites comme IBM, HP, RH font leur beurre sur les demandes de stabilité.
[^] # Re: Ca ne règle pas la source du problème
Posté par barmic . Évalué à 4.
Ça n'est surtout pas pour ça que kNetBSD est moins performant que linux. C'est plus une question de main d’œuvre. S'occuper des performances c'est long, pas tout le monde veut ou est capable de le faire. NetBSD s'intéresse à d'autres problématique (à 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: Ca ne règle pas la source du problème
Posté par claudex . Évalué à 4.
Je ne suis pas sûr que s'occuper des performances est plus coûteux en terme de main d'œuvre que de faire évoluer un système sans régression. Intuitivement, je dirais d'ailleurs que c'est l'amélioration des performances avec régressions (minimes) qui est plus facile.
« 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: Ca ne règle pas la source du problème
Posté par xcomcmdr . Évalué à 8. Dernière modification le 28 novembre 2014 à 08:05.
Il te suffit d'enlever quiet aux arguments de boot… Par défaut systemd est plutôt bavard.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Ca ne règle pas la source du problème
Posté par gnumdk (site web personnel) . Évalué à 4.
Vois ça avec debian, ce n'est pas systemd:
http://bencord0.files.wordpress.com/2013/09/systemd-boot.png
[^] # Re: Ca ne règle pas la source du problème
Posté par Zenitram (site web personnel) . Évalué à -7.
Tu rigoles? quelle utilité à râler sur les vrais coupables quand on a le plaisir d'avoir un bouc émissaire?
J'ai l'impression que le pire dans cette histoire est qu'il y ai si peu de monde à faire remarquer que les coupables sont les mainteneurs de distros (coupables du choix, coupables de la configuration…), c'est triste ces gens aiment s'inventer des coupables (des fois, on se demande comment l'Etat de droit arrive à fonctionner avec autant de gens ne s'interessant pas à la recherche de coupable mais juste à la recherche d'une personne sur qui concentrer sa haine).
[^] # Re: Ca ne règle pas la source du problème
Posté par Bigon . Évalué à 0.
Le tout setuid root, sinon c'est pas drôle
[^] # Re: Ca ne règle pas la source du problème
Posté par benoar . Évalué à 2.
Merci, tu as bien résumé ma pensée, avec un ton très intelligent et mesuré, j'aime bien ça.
C'est effectivement problématique qu'il y ait des attaques agressives des deux côtés. Mais laissons les méchants cracher leur bile, et trollons ensemble gentiment dans la joie !
Perso, j'attends de voir si
uselessddevient une alternative potable, il me semble vraiment intéressant.[^] # Re: Ca ne règle pas la source du problème
Posté par MTux . Évalué à 8.
On a droit de faire ce qu'on veut non ? Le sysadmin est maître de sa machine ?
Alors ce genre de remarque…
# Dépendances
Posté par moulator . Évalué à 2.
Et quand tu auras la moitié des paquets qui dépendront de systemd, et qui ne voudront donc pas s'installer, il faudra bien trancher dans le vif (accepter systemd ou changer de distrib/OS)…
[^] # Re: Dépendances
Posté par Okki (site web personnel, Mastodon) . Évalué à 8.
Et encore. Même FreeBSD commence à s'y mettre. FreeBSD Plans for the Next Ten Years :
« The last item about service start-up improvements comes down to dramatically redoing or replacing /etc/rc.d and becoming more systemd-like. In fact, this FreeBSD presentation even earned the praise of Lennart Poettering. »
[^] # Re: Dépendances
Posté par Nitchevo (site web personnel) . Évalué à 10.
Heureusement MS Windows semble épargné par cette épidémie.
----->
[^] # Re: Dépendances
Posté par zurvan . Évalué à -1. Dernière modification le 27 novembre 2014 à 13:50.
ainsi que Mac Os X (en plus c'est libre, mais ça semble ressembler à systemd).
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
[^] # Re: Dépendances
Posté par xcomcmdr . Évalué à 5.
Euh, c'est l'inverse : c'est systemd qui s'en inspire (enfin de ça, et d'upstart).
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Dépendances
Posté par Sufflope (site web personnel) . Évalué à 3.
Et plus précisément, launchd a inspiré systemd sur ce qu'il fallait faire, et upstart sur ce qu'il ne fallait pas faire.
[^] # Re: Dépendances
Posté par zurvan . Évalué à -2.
je sais que c'est antérieur (les dates sont indiquées sur wp), quoi qu'il en soit les deux se ressemblent, c'est pas parce que launchd ressemble à systemd que ça indique un sens d'inspiration.
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
# ou alors installer init
Posté par ZeroHeure . Évalué à 1.
Autre solution, tu installes init qui est un méta-paquet pour choisir son syteme d'init parmi systemd, upstart et sysvinit. Par la suite, si un paquet demande spécifiquement systemd (il y en a) ton init ne changera pas.
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Non…
Posté par Cyril Brulebois (site web personnel) . Évalué à 5.
Le paquet init garantit la présence d'un des trois systèmes d'init, rien d'autre.
Debian Consultant @ DEBAMAX
[^] # Re: Non…
Posté par ZeroHeure . Évalué à 2.
Ah oui tiens… flute je croyais qu'on pouvait choisir avec debconf.
Je profite de l'expert : c'est possible à faire (pour plus tard) ou ce serait trop compliqué ou inutile?
Note pour ceux qui l'ignoreraient: Cyril est un éminent developeur Debian.
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: Non…
Posté par Cyril Brulebois (site web personnel) . Évalué à 2.
Pour l'absence de debconf etc., il suffit de constater l'absence de scripts de mainteneur (
{pre,post}{inst,rm}) :/var/lib/dpkg/info/init.*.Je ne vois pas trop à quoi pourrait servir de forcer une telle chose. L'approche qui consiste à utiliser l'apt pinning pour indiquer une préférence au gestionnaire de paquets me semble relativement appropriée. Il manque probablement un patch ou deux dans les release notes pour avoir « I want to keep sysvinit. » dans la documentation qui va bien.
(Ton commentaire est gentil mais c'est exagéré.)
Debian Consultant @ DEBAMAX
[^] # Re: Non…
Posté par vv222 . Évalué à 4. Dernière modification le 27 novembre 2014 à 16:16.
Pourquoi se casser la tête avec du pinning alors qu’on a le paquet
systemd-shimqui sert justement à éviter l’installation du système d’init de systemd ?Et pour ceux qui ne supportent pas de voir la chaîne de caractères "systemd" dans un nom de paquet (ne riez pas, j’en connais), ne leur reste plus que le boycott de tous les paquets dépendant d’une quelconque libsystemd-foo.
Et pour ce qui est de conserver SysV comme système d’init lors du passage à Jessie, c’est un jeu d’enfant :
1. ajout des depôts de Jessie à la Wheezy
2. apt-get update
3. apt-get install systemd-shim sysvinit-core
4. apt-get dist-upgrade
5. Hop, une Jessie avec SysV
[^] # Re: Non…
Posté par Cyril Brulebois (site web personnel) . Évalué à 5.
J'ai indiqué que je trouvais l'approche mentionnée au départ (apt pinning) appropriée, et que la notion de sélection via debconf ne me semblait ni convaincante ni nécessaire. Pas que le pinning était la seule et unique vraie façon véritable d'arriver au résultat désiré.
Quant à systemd-shim, cf. les discussions concernant libpam-systemd etc. L'ordre dans les dépendances alternatives peut donner des résultats différents en fonction de l'ensemble de paquets de départ et de l'ensemble des paquets à installer/mettre à jour.
Debian Consultant @ DEBAMAX
[^] # Re: Non…
Posté par Arathor . Évalué à 1. Dernière modification le 30 novembre 2014 à 18:06.
C’est dingue comme ça déchaîne les passions… quel besoin de tourner en dérision les gens qui ne sont pas d’accord avec toi ?
Ça risque d’être un peu compliqué, en tout cas sur un desktop :
% apt-cache rdepends libsystemd-login0
libsystemd-login0
Reverse Depends:
systemd-dbg
systemd
python-systemd
libsystemd-login-dev
pulseaudio
mate-screensaver
systemd
libsystemd-login-dev
pulseaudio
dbus-1-dbg
dbus
[^] # Re: Non…
Posté par pikapika . Évalué à 1.
Je viens de découvrir un paquet s'appelant init-select qui semble pouvoir permettre le choix entre les init
[^] # Re: Non…
Posté par moulator . Évalué à -5. Dernière modification le 27 novembre 2014 à 21:55.
C'est un peu ça le problème de Daubian aujourd'hui : même des admins qui l'utilisent depuis plus de 10 ans en sont maintenant à aller à la pêche pour trouver comment ça peut se configurer…
Bref, y'a longtemps que KISS s'est barré en courant/pleurant.
# Alternative (uselessd, ...)
Posté par Tarnyko (site web personnel) . Évalué à 1.
Bloquer systemd "en attendant que" est intéressant à savoir faire, mais un pis-aller.
Comme l'a dit benoar, il y a uselessd, qui peut constituer une alternative intéressante, techniquement et philosophiquement.
(à titre personnel, j'ai réussi à lui faire booter un des mes systèmes jusqu'à la GUI, mais attends de peaufiner un peu avant d'en faire un journal)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.