|
|
jp willm , dans le message <rb529b$me3$1>, a écrit :
> S6 ? Principalement, oui. L'auteur connaît très bien son sujet, mais il est assez seul. |
|
|
|
Le 01-06-2020, JKB <jkb> a écrit :
> Le 01 Jun 2020 18:32:04 GMT, Stéphane CARPENTIER <sc> > écrivait : > Non, le fait que ce soit lancé en parallèle ne fait pas toujours > gagner du temps. Oui, OK, je me suis mal exprimé, je voulais dire que ça pouvait faire gagner du temps, pas que c'était toujours le cas. > Quant à l'ordre de démarrage, c'est souvent un peu la roulette > russe. Je ne sais pas si c'est très bien géré, mais dans ce que j'ai vu, tu peux demander un ordre relatif aux tâches (par exemple : ne pas lancer ntp avant d'avoir le réseau). >> Je ne me suis pas plongé dans la compréhension de systemd, j'ai juste >> regardé les parties qui posaient problème lors de l'installation. > En fait, tout pose problème dans systemd lorsqu'on commence à > creuser et qu'on a une configuration Oui, mais encore une fois, c'est pas parce que tu as de bonnes raisons de vouloir partir que je doive être concerné par ces raisons. Je ne dis pas que tu dois y retourner. Je dis que je n'ai pas vu de raison de quitter. J'ai pas de problème de mémoire et mon ordinateur est à côté de moi. > qui n'est pas celle de madame Michu. Parlons-en de madame Michu, justement. Donc, madame Michu, on lui installe Ubuntu parce que c'est facile. Avec Ubuntu il y a plein de trucs qui sont lancés, parce que peut-être que ça pourrait servir mais on sait jamais, en plus des trucs dont elle a besoin. Lorsque madame Michu lance son ordinateur, c'est un super gestionnaire de login graphique qui est lancé. Ce super gestionnaire lance Gnome ou KDE qui déchirent et qui eux aussi lancent plein de trucs qui pourraient lui servir on sait jamais. La première chose qu'elle fait une fois connectée, c'est de lancer Firefox avec plein de plugin parce qu'elle veut aller sur Internet. Et après on voudrait m'expliquer que les problèmes de performance du Linux de madame Michu, ça vient de systemd qui est le mal absolu et que c'est scandaleux. Ben désolé, mais moi j'ai pas de gestionnaire de login graphique, j'ai pas de Gonme/KDE, j'ai pas firefox, j'ai pas de gestionnaire de fichiers qui roxe... Mais j'ai 8 c?urs et 16Go de RAM. Et donc, les problèmes de performance, je ne suis pas concerné. Vraiment pas. Donc, que tu aies des machines limitées qui doivent être optimisées je le conçois. Mais je ne suis pas concerné. > Le problème de systemd vis à vis de Linux est le même que celui de > Linux vis à vis de POSIX. Les sources POSIX sont polluées de > linuxismes, Oui, ça j'ai lu des critiques sur le fait que systemd ne soit pas compatible POSIX. Mais pour moi la question est peut-être posée à l'envers. Est-ce que les incompatibilités répondent à un manque de POSIX ou pas ? S'il n'y a pas de manque du côté de POSIX, c'est mal. S'il y a un manque du côté de POSIX, peut-être qu'il faudrait faire évoluer POSIX pour combler le manque. Je ne suis pas capable de répondre à cette question. Mais s'accrocher à une norme parce qu'elle est bien est une bonne chose. Alors que pour moi, s'accrocher à une norme par principe, même si elle est périmée par une décision prise il y a quarante ans est néfaste. Si le besoin est réel, les gens essayeront de s'en affranchir. Quoiqu'il arrive. Si la norme évolue, ils essayeront globalement de la suivre. Si la norme est figée, ils feront des adaptations chacun dans son coin et ça va augmenter les incompatibilités. |
|
|
Le 01-06-2020, festiventu <festiventu> a écrit :
> Le 28/05/2020 à 18:47, Stéphane CARPENTIER a écrit : >> Ma première distribution, c'était une slackware, j'ai mangé grave pour >> faire reconnaitre le lecteur de CD et la carte graphique. Il fallait >> aussi recompiler mon noyau et tout ça (vers 94/95). À l'époque la doc >> était éparse (plein de HOWTO sur le CD de la distribution) et >> entièrement en anglais (à l'époque c'était un problème pour moi). > Me too, une slack avec un noyo 1.2.13. Quelle époque épique !!! J'avais dû mettre le noyau 1.3.chaipu parce que le lecteur de CD EIDE était encore expérimental. |
|
|
Stéphane CARPENTIER , dans le message
<slrnrdc91b.2ip.sc>, a écrit : > Et après on voudrait m'expliquer que les problèmes de performance du > Linux de madame Michu, ça vient de systemd qui est le mal absolu et que > c'est scandaleux. Je crois que tu as très bien résumé la situation. systemd, sur une machine en train de tourner, ne fait strictement rien. > Oui, ça j'ai lu des critiques sur le fait que systemd ne soit pas > compatible POSIX. Mais pour moi la question est peut-être posée à l'envers. > Est-ce que les incompatibilités répondent à un manque de POSIX ou pas ? POSIX parle d'interfaces système, pas d'administration. Reprocher à systemd de ne pas respecter POSIX est à peu près aussi pertinent que de lui reprocher de ne pas respecter cee-onu ffv-36 (concernant la commercialisation et le contrôle de la qualité commerciale des TOMATES). > Je ne suis pas capable de répondre à cette question. Mais s'accrocher à > une norme parce qu'elle est bien est une bonne chose. Alors que pour > moi, s'accrocher à une norme par principe, même si elle est périmée par > une décision prise il y a quarante ans est néfaste. C'est un autre débat, mais tu as raison, c'est quelque chose dont il faut parler. Internet, et en particulier le web, est envahi de standards moisis, conçus plus pour permettre aux publicitaires de nous traquer et de nous infliger leur daube que pour le bien des utilisateurs. Comme ce sont des standards industriels, ils sont conçus non pas dans un objectif de simplicité et d'efficacité, mais avec comme principale considération le fait d'être compatible avec les produits existants des principaux acteurs payants de la standardisation. Mais les auteurs de logiciels libres ont tellement internalisé l'impératif « il faut respecter les standards » qu'ils essaient d'implémenter ces standards au lieu d'inventer de meilleurs protocoles. Le résultat est que plein de logiciels sont des moussakas géantes, qui marchent si on n'a pas un trop mauvais karma dans les circonstances précises pour lesquelles elles sont prévues, mais qui sont impossibles à adapter à des circonstances particulières, comme les faire tourner sur un VPN. Parfois, ce sont tellement des moussakas géantes qu'il est même impossible de les compiler soi-même, et même les distributions n'y arrivent pas. La seule solution est d'installer des paquets binaires, mais on prétend quand même que c'est du logiciel libre. Exemples : - Les logiciels de vidéoconférence. Il y en a qui prétendent être Open Source, mais pas un ne peut être installé à partir des sources sur une distribution quelconque par un administrateur raisonnablement compétent (qu'on me contredise ! par pitié qu'on me contredise ! qu'on me pointe vers quelqu'un qui a réussi !), donc aucun n'est vraiment libre. - Les serveurs de média, pour compatibilité avec les télés connectées. On voit des paquets multicast passer, personne ne répond, le serveur ne produit aucun log. |
|
|
Le 02/06/2020 à 11:32, Nicolas George a écrit :
> jp willm , dans le message <rb529b$me3$1>, a écrit : >> S6 ? > Principalement, oui. L'auteur connaît très bien son sujet, mais il est assez > seul. Oui, j'ai vu ; je l'aiderais bien si j'en avais les compétences... Et dire que ce gars, pour des raisons d'éthique, a refusé une carrière dont beaucoup rêveraient. <https://sysdfree.wordpress.com/2020/05/24/316/> |
|
|
Le 02-06-2020, jp willm <nicole.jeanpaul.willm> a écrit :
> Le 02/06/2020 à 00:01, Stéphane CARPENTIER a écrit : >> Pour quelle raison me prendre la tête à changer un truc >> qui marche bien alors que j'ai plein de choses à faire ? > Le jour où ce "truc qui marche bien" sera devenu encore plus obèse et > abscons, mais sera indécrottable de toute distribution Linux, on ne se > posera plus cette question. C'est peu probable, des critiques il y en a et elles sont justifiées. Sauf que des arguments expliquant ce qui est mieux (plutôt que de pointer vers ce qui est mieux qui est différent) j'en vois moins. Donc, j'imagine que les concurrents vont monter en maturité et qu'il y aura de vrais arguments dans le futur. Et que à ce moment là, Archlinux (si c'est toujours la distribution que j'utilise) basculera vers ce qui est mieux. Et ça se fera plus simplement que si je bascule de moi-même en avance de phase. La question est surtout de savoir si j'aurai besoin de basculer de moi-même en avance de phase ou si la migration sera faite avant que j'en ai besoin. En supposant que j'en ai besoin, car ils peuvent aussi améliorer systemd. > On est en pleine politique, mais cela vaut le coup de lire un peu : > [..] Voilà, c'est ça. N'importe quoi autre que systemd c'est mieux. Mais sans explication. Moi, je n'achète pas. > Je ne suis pas informaticien, mais j'observe que l'opensource est > partout et commence à être contrôlé par de très grandes multinationales. > Embrace, extend and extinguish : ><https://fr.wikipedia.org/wiki/Embrace,_extend_and_extinguish> Oui, mais en fait, moi, c'est pas la panique qui me fait avancer. Surtout que c'est toujours le même problème et c'est pour ça que les arguments qui disent que tout est mieux sauf systemd sont mauvais. Il n'y a rien de factuel et c'est mauvais. Quand c'est sysV qui est universel, c'est bien ça simplifie la gestion et la portabilité. Quand c'est systemd, c'est d'abord mal parce que c'est plus compatible. Et une fois que tous les systèmes sont compatibles, ça devient mal parce que c'est systemd qui s'est imposé. Donc, la morale à géométrie variable, ça me passe très au dessus. Mais pourquoi est-ce que c'est mieux que sysV soit partout et pas systemd ? Il n'y a pas d'argument sérieux. Les arguments se contredisent parce que tu ne peux pas avoir à la fois une diversité et une homogénéité. Il y a des arguments techniques pour me montrer les problèmes de systemd. Mais il n'y a aucune explication pour me montrer en quoi la conception (et pas leur utilisation) des alternatives est mieux. Donc, moi, j'ai mieux à faire. Et les arguments me disant qu'il faut penser aux autres ne tiennent pas la route. Quand on n'a plus d'argument valable, on bascule sur l'affect et j'arrête d'écouter. Ça n'a pas d'intérêt. Si on me montre que mon action est néfaste, je peux me sentir coupable. Si on me dit que mon action est néfaste mais qu'on est incapable de me montrer pourquoi, je ne me sens pas obligé de l'accepter. >> À mon avis, si systemd est vraiment si mal et que le reste est vraiment >> mieux, Archlinux quittera systemd pour aller vers autre chose. > Je me suis aussi déjà fait cette réflexion : espérons... Je dis Archlinux parce que je suis actuellement dessus et que ça me plaît bien. Mais si ça change trop, je pourrais aussi quitter Archlinux. > Toutefois, j'ai lu qu'un des principaux développeurs de Arch travaille > chez IBM Redhat, chez qui ?uvre aussi l'inventeur de systemd. D'abord, Archlinux est une distribution à la fois minimale et bleeding edge, ce que n'est vraiment pas Red Hat. Le gestionnaire de paquet n'a rien à voir non plus. Les motivations ne sont vraiment pas les mêmes et ça me surprendrait qu'il se focalise juste sur systemd pour homogénéisation alors que tout le reste est différent. Ensuite, systemd est parti d'une bonne chose. Malgré les critiques, son inventeur a fait du bien à l'initialisation des systèmes. Que ce soit avec la création de systemd pour utilisation. Ou que ce soit pour motiver les autres à proposer une alternative. Sans son inventeur, on serait probablement encore à sysV un peu partout. |
|
|
Le 02/06/2020 à 13:02, Stéphane CARPENTIER a écrit :
> La question est surtout de savoir si j'aurai besoin de basculer de > moi-même en avance de phase ou si la migration sera faite avant que j'en > ai besoin. En supposant que j'en ai besoin, car ils peuvent aussi > améliorer systemd. En attendant que la foule suive, "ils" ont aussi besoin des rapports de bugs. |
|
|
Le 02-06-2020, Nicolas George <nicolas$george> a écrit :
> Stéphane CARPENTIER , dans le message ><slrnrdc91b.2ip.sc>, a écrit : > C'est un autre débat, mais tu as raison, c'est quelque chose dont il > faut parler. Oui, je suis conscient que c'est un autre débat. Mais ce que tu expliques après, va dans le sens que j'imaginais et c'est pour ça que j'en ai parlé. Les deux débats sont très liés. |
|
|
Le 02-06-2020, jp willm <nicole.jeanpaul.willm> a écrit :
> Le 02/06/2020 à 13:02, Stéphane CARPENTIER a écrit : >> La question est surtout de savoir si j'aurai besoin de basculer de >> moi-même en avance de phase ou si la migration sera faite avant que >> j'en ai besoin. En supposant que j'en ai besoin, car ils peuvent >> aussi améliorer systemd. > En attendant que la foule suive, "ils" ont aussi besoin des rapports > de bugs. Oui, mais c'est qui « ils » ? Je ne vais pas installer toutes les alternatives en parallèle juste pour pouvoir envoyer des rapports de bugs à tout le monde. Et pourquoi systemd n'aurait pas besoin de rapport de bug pour s'améliorer ? Parce que l'un des trucs qui est reproché à systemd (sur plein de liens que tu m'as montré mais aussi sur d'autres que j'avais déjà vu) est leur arrogance. Mais quand je vois ces sites, ils ne font que de la destruction de systemd sans la moindre proposition d'amélioration. Oui, je sais, c'est la conception qui est mauvaise : c'est pas possible de l'améliorer, il faut le quitter. Mais j'ai du mal à croire que toutes les alternatives sont bien conçues et que seul systemd est mal conçu alors que c'est répandu sur des distributions qui n'ont pas les mêmes objectifs (ie : choix différents, même conclusion). Je ne sais pas comment la situation actuelle en est arrivée là. Mais personnellement, je comprends que les développeurs de systemd, qui font quelque chose de constructif (bien ou pas n'est pas la question : ils avancent), soient arrogant vis-à-vis de ceux qui leur font la chasse aux sorcières. J'ai tendance à faire pareil et à mépriser ceux qui ne savent que critiquer. Et là, comme ça, rien ne me dit que systemd ne va pas s'améliorer. Rien ne me dit que systemd est sûr de me poser problème à court terme. Rien ne me dit que l'éventuel remplacement de systemd existe déjà. Rien ne me dit qu'il y a quelque chose de mieux que systemd que j'ai intérêt à utiliser. Je ne me sens pas obligé d'aboyer avec les loups pour dire que tout est bien sauf systemd. Le pire, c'est qu'au début j'avais envie de détester systemd et d'avoir plein d'arguments pour migrer, en faisant un effort, mais pour faire une bonne action en améliorant mon système. Mais en fait, plus je lis et plus je vois que les raisons de partir sont des cas particuliers (qui sont valables, je ne le nie pas, mais ils ne me concernent pas). Plus j'ai l'impression que c'est une guerre de religion à laquelle je n'ai vu aucune raison de participer. Autant les guerres contre Microsoft, Apple, Android, Google, Facebook, Amazon et Uber (entre autres), j'ai vu plein d'arguments sérieux. Autant la guerre contre systemd je n'ai rien vu. |
|
|
Le Tue, 02 Jun 2020 11:02:47 +0000, Stéphane CARPENTIER a écrit :
>> Toutefois, j'ai lu qu'un des principaux développeurs de Arch travaille >> chez IBM Redhat, chez qui ?uvre aussi l'inventeur de systemd. > D'abord, Archlinux est une distribution à la fois minimale et bleeding > edge, ce que n'est vraiment pas Red Hat. Le gestionnaire de paquet n'a > rien à voir non plus. Les motivations ne sont vraiment pas les mêmes et > ça me surprendrait qu'il se focalise juste sur systemd pour > homogénéisation alors que tout le reste est différent. De mémoire, Archlinux est passée à systemd parce que c'est le truc que tout le monde utilisait et que pour un certain nombre de services les mainteneurs d'Arch allait devoir commencer à maintenir eux-mêmes les scripts à l'ancienne. Du moins c'est ce qu'ils ont annoncé, je ne suis pas allé vérifier. Il me semble que l'annonce indiquait que si des gens étaient vraiment intéressés pour faire ce travail, ils pouvaient se faire connaître. C'est arrivé lors d'un autre choix, quand Archlinux a abandonné le x86 32 bits ; et des gens sont allés mettre en place arch32 pour assurer la maintenance. Arch étant une distribution qui propose des logiciels les moins modifiés possibles, c'est plutôt cohérent de faire comme tout le monde quand les autres se tournent vers une solution technique particulière, à moins qu'une autre solution ait de très gros avantages. Devoir maintenir dans leur coin des spécificités sur tout un tas de paquets, ce n'est pas trop l'esprit de cette distribution (contrairement à Debian par exemple). |
|
|
Yliur , dans le message <rb6tbe$5dc$1>, a écrit :
> De mémoire, Archlinux est passée à systemd parce que c'est le truc que > tout le monde utilisait et que pour un certain nombre de services les > mainteneurs d'Arch allait devoir commencer à maintenir eux-mêmes les > scripts à l'ancienne. Ça ne me semble pas très crédible. C'est de toutes façons le rôle d'une distribution de faire l'infrastructure de lancement des services. |
|
|
Le 02/06/2020 à 16:23, Stéphane CARPENTIER a écrit :
> Autant les guerres contre Microsoft, Apple, Android, Google, Facebook, > Amazon et Uber (entre autres), j'ai vu plein d'arguments sérieux. Autant > la guerre contre systemd je n'ai rien vu. Laissons de côté la guerre, mais intéressons-nous à ce qui reste libre. |
|
|
Le Wed, 03 Jun 2020 09:51:54 +0000, Nicolas George a écrit :
> Yliur , dans le message <rb6tbe$5dc$1>, a écrit : >> De mémoire, Archlinux est passée à systemd parce que c'est le truc que >> tout le monde utilisait et que pour un certain nombre de services les >> mainteneurs d'Arch allait devoir commencer à maintenir eux-mêmes les >> scripts à l'ancienne. > Ça ne me semble pas très crédible. C'est de toutes façons le rôle d'une > distribution de faire l'infrastructure de lancement des services. Du coup je suis allé fouiller. J'ai retrouvé un message dans un forum, qui est pointé directement par la page de wiki systemd comme étant l'explication "officielle". Le message en question : [..] La page de wiki (pour la source) : [..] Donc c'est un des développeurs arch et il dit effectivement qu'ils devaient maintenir les scripts eux-mêmes avant ; par contre il espère que ce ne sera plus le cas avec systemd (je ne sais pas si son v?u s'est exaucé) et que ça va permettre de mettre en commun du travail entre distributions. Les points 5-7 de sa liste d'avantages traitent de ces sujets. Globalement il liste un certains nombre d'avantages qu'il voit à systemd, il semble plutôt enthousiaste. En tout cas le message est intéressant. |
|
|
Le 04-06-2020, Yliur <yliur> a écrit :
> Le message en question : > [..] Ah, ben non. Moi qui voulait détester systemd, tu vas finir par faire de moi un défenseur. Ce qui confirme ce que j'imaginais, c'est que les raisons d'avoir migré sont un peu plus sérieuses que pour faire comme tout le monde. Ce qui confirme aussi ce que j'imaginais, c'est que certains trucs me perturbaient parce que je ne me suis pas plongé dans la doc. Il y a plus de trucs intéressants que ce que j'avais remarqué. Je comprends aussi pourquoi les machines sous-dimensionnées de JKB ont du mal à démarrer. Mais d'un autre côté, devoir attendre deux minutes qu'un périphérique non vital soit reconnu sur ma machine pour pourvoir l'utiliser parce que sinon, les serveurs qui ont 40 ans ne démarrent pas me gêne. Alors, OK, systemd est orienté desktop et pas serveur. Ça tome bien bien, Archlinux est orienté desktop et j'ai un desktop. En tous cas, ça me confirme qu'avant d'accepter que tout est mieux que systemd, il me faudra des explications sur le pourquoi et pas sur le quoi : "I think there might be this other project that possibly is doing something similar. I don't really know anything about it, but I'm pretty sure it is better than systemd" > La page de wiki (pour la source) : > [..] Le problème de cette page en particulier, comme de ce wiki en général, c'est que c'est plus une liste de recettes qu'une doc. Si tu connais systemd, c'est très bien. Si tu découvres systemd en arrivant sur archlinux, tu fais des devinettes en espérant que ça marche. Ils t'expliquent comment faire, mais pas pourquoi. Et se plonger dans la doc de systemd au moment de l'installation d'un OS est quand même très contraignant. |
|
|
Le 05 Jun 2020 10:21:44 GMT,
Stéphane CARPENTIER <sc> écrivait : > Le 04-06-2020, Yliur <yliur> a écrit : > Ah, ben non. Moi qui voulait détester systemd, tu vas finir par faire de > moi un défenseur. > Ce qui confirme ce que j'imaginais, c'est que les raisons d'avoir migré > sont un peu plus sérieuses que pour faire comme tout le monde. > Ce qui confirme aussi ce que j'imaginais, c'est que certains trucs me > perturbaient parce que je ne me suis pas plongé dans la doc. Il y a plus > de trucs intéressants que ce que j'avais remarqué. > Je comprends aussi pourquoi les machines sous-dimensionnées de JKB ont > du mal à démarrer. Dans l'embarqué, tu ne te trimballes pas 4 Go de mémoire pour te faire plaisir. Je ne vois pas en quoi avoir seulement 512 Mo de mémoire est sous-dimensionné pour l'immense majorité des cas. Par ailleurs, certains problèmes de systemd seraient acceptables si, par exemple, on pouvait simplement lui demander de ne pas essayer de tout lancer en parallèle. Parce que tu as exactement le même problème avec des postes diskless (chez moi, tout est diskless sur un gros serveur, et certaines machines allumées une fois de temps en temps mettent jusqu'à une demi-heure pour être utilisables, systemd lançant tout en même temps sur des disques réseau !). Sauf erreur de ma part, je n'ai pas trouvé dans la doc un drapeau de configuration permettant de dire à systemd "merci de ne pas forker comme un goret et d'être gentil en lançant tout séquentiellement". > Mais d'un autre côté, devoir attendre deux minutes > qu'un périphérique non vital soit reconnu sur ma machine pour pourvoir > l'utiliser parce que sinon, les serveurs qui ont 40 ans ne démarrent pas > me gêne. Ce qui me dérange plus, c'est l'attente infinie sur certains périphériques non critiques. Ou le simple fait que l'ordonnanceur ne soit pas fiable : ce qui fonctionnait avec telle version de systemd est fichu de ne plus se lancer dans le même ordre avec la version suivante. Alors il est vrai que c'est sur des trucs comme des disques iSCSI ou des choses bizarres qu'on ne retrouvera pas chez madame Michu (enfin, normalement), mais lorsque tu redémarres une machine, tu aimes bien que ça se comporte de manière prévisible d'une version à l'autre. Avec systemd, ce n'est pas le cas. Ça ressemble vraiment au démarrage de type Windows avec en plus un petit air d'advienne que pourra. Un autre truc m'énerve au plus haut point. Lorsqu'on choisit un système de démarrage, on s'y tient ! Avec systemd, dans certains cas, on ne sait plus ce qui démarre avec une compatibilité SysV en réécrivant à la volée des modules systemd, ce qui démarre en vrai SysV, ce qui est lancé depuis /lib/systemd/system ou /etc/systemd voire /lib/systemd/user et /etc/systemd/user... Lorsque tu as à la fois un module systemd et un script SysV, tu as intérêt de chercher attentivement ce que systemd fera parce que là encore, d'une versionà une autre, il ne se comporte pas forcément de la même manière. J'ai pensé naïvement qu'il utilisait toujours en priorité ses modules. Raté, ce n'est pas toujorus vrai (je n'ai pas cherché à savoir si c'était un bug ou une fonctionnalité). C'est un merdier sans nom d'autant plus que je suis tombé sur une bizarrerie d'un paquet debian qui modifie /lib/systemd/system et... qui est réécrasé à la prochaine mise à jour de systemd. J'ai perdu trois mois sur un problème pareil. Pourquoi est-ce que les devs de systemd n'ont pas tout mis au même endroit en retirant /etc/init.d de l'équation ? Je ne saurais jamais. Mais le résultat est qu'on a un truc qui explose en vol plus souvent qu'à son tour. J'ai un exemple récent où systemd (une certaine version du truc) empêchait le démarrage de pulseaudio sur une machine qui me sert de serveur multimedia. Je passe sous silence les interactions pas maîtrisées avec udev. Il y a belle lurette que j'ai forcé les interfaces réseau de mes serveurs en ethx (en fonction de l'adresse MAC). Il y a quelques mois, l'une des interfaces était renommée en eth254 ! Pourquoi, parce que systemd s'était tiré une balle dans le pied entre udev et le montage des interfaces réseaux (les scripts étaient bons). Ça fait désordre pour ne pas dire bricolage. Il y a aussi un truc étrange depuis quelques semaines. Lorsque mon poste de travail (diskless avec swap en iSCSI) se met à swapper un peu trop, systemd me ferme ma session graphique. C'est très gentil de sa part et très pratique. Je suppose qu'il y a maintenant dans le bouzin un genre de watchdog. Dernière chose, et non des moindres. Les mises à jour de systemd sont problématiques parce une nouvelle version de la chose prend place sur une machine utilisant déjà systemd comme init (pid 1). Et là, le redémarrage peut être problématique avec des processus d'extinction qui ne finissent JAMAIS (attente infinie sur... rien parce que la version du binaire a changé !). En fait, avec systemd, on est arrivé à un état problématique. Plus exactement, il est désespérant de voir que ce que les développeurs de Linux il y a 20 ans reprochaient à Windows se retrouve tel quel avec les mêmes inconvénients dans Linux. [..] > t'expliquent comment faire, mais pas pourquoi. Et se plonger dans la doc > de systemd au moment de l'installation d'un OS est quand même très > contraignant. Après aussi, remarque bien. Systemd est piégeux, son développement n'a visiblement pas été plus ou pas été mieux pensé que celui de PL/1. Nouveau besoin, nouveau patch et, à la fin, on a une usine à gaz avec des fuites qui marche dans 95% des cas. Tant pis pour toi si tu es dans les 5% restants. JKB |
|
|
Discussions similaires | |
Redhat Entreprise ou maj de Redhat 9
|
|
RedHat ES3 et RedHat classique
|
|
Gel de ma Redhat
|
|
4 cds redhat EL 3.0
|
Fuseau horaire GMT +2. Il est actuellement 12h19. | Privacy Policy
|