Entretien avec François Tigeot, développeur DragonFly BSD

Posté par antistress (site web personnel) le 26 octobre 2013 à 12:03. Édité par François Tigeot, Benoît Sibaud, Xavier Teyssier et palm123. Modéré par Pierre Jarillon. Licence CC By‑SA.

Étiquettes :

oct.

2013

Nous avons la chance d'avoir quelques développeurs qui fréquentent LinuxFR.org (what else?), dont François Tigeot (lecteur silencieux, dorénavant inscrit sous le pseudo ftigeot) qui contribue au système d'exploitation libre DragonFly BSD, un cousin de FreeBSD au sujet duquel nous avions interrogé tantôt Jean-Sébastien Pédron (quant au portage du Kernel-based mode-setting – KMS – pour les GPU Radeon) puis Baptiste Daroussin (au sujet de « pkgng », le nouveau système de packages binaires qui a été justement repris par DragonFly (les fourbes !) : hasard ou coïncidence ? Autrement dit : y aurait-il une mafia française du logiciel libre ?

Pour répondre à cette lancinante question, rappelons :

ce que Jean-Sébastien Pédron avait fini par avouer, sous la torture, lorsque je lui avais posé la question suivante : « Échanges‐tu avec les développeurs des autres *BSD sur ta partie ? » : « Je suis également en contact avec François Tigeot, de DragonFly, qui s'est occupé du pilote Intel chez eux. Je pense qu'on va travailler de plus en plus ensemble, parce qu'on a sans doute moyen de se répartir le boulot. ».
ce que Baptiste Daroussin avait fini par avouer, avec les mêmes moyens, lorsque je lui avais posé la même question : « Les échanges sont assez nombreux, essentiellement avec DragonFly. En effet sous l'impulsion de John Marino, aidé maintenant par François Tigeot, pkgng et les ports FreeBSD ont été porté sous DragonFly avec des résultats plus que convaincants. La dernière version de DragonFly dispose du support au choix entre pkgsrc ou pkgng + ports, je suis convaincu que la prochaine version de DragonFly sortira avec uniquement pkgng ».

Il semble qu'il y ait définitivement une piste à creuser…

Du coup j'ai bien envie de passer François à la question relativement à la pile graphique de DragonFly ou au port de pkgng, mais on m'indique dans l'oreillette que ces sujets ne sont en réalité qu'une partie de l'activité déployée par François dans DragonFly.

Nous allons donc de ce pas interroger ce personnage – qui semble central dans la communauté DragonFly – afin de tenter d'y voir plus clair.

Quoi qu'il en soit, nous remercions chaleureusement François Tigeot d'avoir accepté de répondre à quelques questions pour LinuxFR.org et aussi pour son implication dans DragonFly !

À noter que les hyperliens ont été ajoutés après coup par les contributeurs à cette dépêche pour en faciliter la lecture.

Pourrais-tu te présenter en quelques mots ?

J'ai 36 ans, un DUT informatique systèmes et réseaux, suis gérant de SARL. Je travaille principalement comme consultant (sysadmin, maitrise d'ouvrage). Ma société vend du matériel serveur, ce qui me permet parfois de faire des benchmarks intéressants.

Pourrais-tu te présenter en plus de mots, finalement ? ;)

Le fait de travailler dans une petite boite permet de voir plein de problématiques intéressantes. Voici en vrac mes tâches les plus courantes :

vente de solutions complètes (matériel+conseil+services). J'ai mis en place des infrastructures de stockage ou des clusters de calcul dans des labos de recherche par exemple ;
sysadmin : infogérance de serveurs, travail en régie sur des missions plus ou moins longues pour différentes sociétés ;
maîtrise d'ouvrage : conception et mise en place d'une infrastructure IT complète depuis zéro, en commençant par l'accès Internet si besoin ;
pompier : diagnostic et mise en place de mesures correctives pour résoudre des problèmes de performance en urgence.

Le matériel serveur installé par ma société n'est jamais mis en production du jour au lendemain. Les machines tournent en atelier pendant une période de rodage qui permet de détecter les problèmes immédiats (disques durs KO dès la livraison, etc.) et me laisse parfois le temps de faire tourner des benchmarks.

J'ai ainsi pu mesurer les performances de plusieurs systèmes d'exploitation avec des charges de travail orientées stockage comme (Blogbench) ou bases de données (Postgres).

Ceci a permis d'améliorer de façon significative les performances et la tenue en charge de DragonFly dans plusieurs domaines.

Comment définirais‐tu ton rapport au logiciel libre, et comment es‐tu entré en contact avec lui ?

Je dirais que, pour moi, les logiciels libres font maintenant partie du paysage et sont tellement pratiques que je n'envisage pas d'utiliser autre chose.

Dans les années 80-90, la plupart des ordinateurs qu'un particulier pouvait acheter étaient livrés avec des outils de développement, même si ce n'était qu'un BASIC en ROM.

Avec la domination de Windows depuis 1995, il était devenu impossible de programmer à partir d'un PC de base, à moins de payer des sommes extrêmement importantes dans des logiciels supplémentaires.

C'est un cherchant un compilateur C abordable que j'ai entendu parler de GCC et que j'ai découvert petit à petit Unix et le monde des logiciels libres.

Comment t'es-tu retrouvé à utiliser DragonFly ?

J'utilisais FreeBSD comme routeur+parefeu ; lors du passage des versions 5.x à la 6.x (en 2006 je crois), le système s'est mis à planter de façon récurrente tous les 2-3 jours. C'était un bug connu et qu'il n'était manifestement pas possible de corriger rapidement.

Je me suis alors souvenu de l'existence de DragonFly, qui avait été forké de FreeBSD quelques années auparavant, l'ai installé sur mon routeur, et n'ai plus eu de problèmes.

Sa stabilité digne de FreeBSD 4.x (des uptimes de plus d'un an n'avaient rien d'exceptionnel) a fait en sorte que je l'ai progressivement installé sur la plupart des machines de ma société par la suite.

Comment es-tu devenu développeur ?

J'étais très enthousiaste à la suite de la création du système de fichier HAMMER, et j'ai donc naturellement voulu l'utiliser dans un contexte entreprise.

J'ai très vite déchanté quand j'ai voulu obtenir une information aussi simple que la liste des cartes RAID supportées, qui n'existait tout simplement pas.

Je me suis donc retrouvé à établir cette liste moi-même, en testant du matériel gracieusement prêté par un grossiste de la région parisienne. C'était en avril 2011.

Petit à petit, j'ai ensuite contribué à faire fonctionner des applications, corriger des bugs, etc… jusqu'à me retrouver développeur DragonFly sans vraiment m'en rendre compte.

Apparemment tu es un vrai touche-à-tout, intervenant au niveau applicatif, benchmarking, développement noyau… Quelles sont, selon toi, tes contributions les plus utiles et importantes ?

Dans l'ordre d'importance, je dirais :

Portage de drm2/gem/kms et des pilotes i915 puis radeon (voir respectivement ici, ici et là). En fait ce n'est que récemment, à l'été 2012, que j'ai commencé sérieusement à m'intéresser à la pile graphique drm utilisée par les nouveaux pilotes X.org et à porter les fonctions et sous-systèmes nécessaires depuis FreeBSD.
C'était devenu une urgence car sans ça il est maintenant impossible d'afficher des graphiques sur une grande partie des machines récentes.
Dports (adaptation des ports FreeBSD et des paquets binaires pkgng à DragonFly). J'ai aidé John Marino à rendre le système utilisable et je m'occupe encore de créer de nouveaux paquets binaires quand j'ai le temps.
C'est essentiel pour rendre le système d'exploitation plus pratique à utiliser.
Portage de LibreOffice. Devoir mettre les mains profondément dans le cambouis m'a permis aussi d'identifier des problèmes non-spécifiques à DragonFly et qui m'ont permis d'améliorer le logiciel pour tout le monde. J'ai ainsi contribué à éliminer du code OS/2 et HP-UX que personne n'utilisait, supprimé des fonctions de gestion de quotas disque qui n'avaient rien à faire dans une suite bureautique, etc.
C'était une tâche importante car, sans applications, un système d'exploitation n'a qu'un intérêt limité.
Portage depuis FreeBSD du pilote ixgbe(4) pour cartes Ethernet Intel 10 Gb/s.
Cela n'a encore qu'un intérêt très limité pour la plupart des gens et c'est pour cela que je le mets en dernier, mais c'est cependant quelque chose d'essentiel pour créer des serveurs de stockage haute performance, domaine dans lequel DragonFly a la possibilité d'exceller.

Et quelles seraient pour toi tes contributions les plus difficiles, et pourquoi ?

La plus difficile est sans conteste la pile graphique drm moderne avec ses gestionnaires mémoire associés. Je n'aurais jamais pu faire marcher cela tout seul d'ailleurs, Johannes Hofmann et Matt Dillon ont permis que le pilote i915/kms fonctionne en implémentant des fonctionnalités essentielles dans le noyau alors que j'avais laissé le projet de côté pour me consacrer à Dports.

Le gestionnaire de mémoire GEM et le pilote i915 ont besoin de gérer le matériel à un niveau auquel on n'était pas habitué jusqu'à présent.

Les GPU Intel utilisent des ressources mémoire partagées avec le processeur, mais les caches de ces deux composants ne sont pas cohérents entre eux.

Il a été nécessaire de modifier le noyau afin que le contenu de certaines pages mémoire ne soient par exemple jamais mises en cache par le processeur ou que les caches soient complètement vidés pour certaines zones mémoire lorsque le pilote le demande.

Maintenant que le plus gros est fait, je m'efforce de garder le code plus ou moins synchronisé avec FreeBSD et de réduire petit à petit les différences historiques du sous-système drm pour le rapprocher de l'implémentation Linux moderne.

Quelle a été exactement ta contribution sur pkgng dont Baptiste Daroussin nous a rebattu les oreilles récemment ? ;)

J'avais contribué à fournir des machines puissantes à John Marino pour la mise au point de Dports, grâce à l'aide de Dell et du CNRS - plus précisèment le Centre de Mathématique Laurent Schwartz (Ecole Polytechnique/Institut National des Sciences Mathématiques et de leurs Interactions) et l'Institut d'Astrophysique Spatiale (Paris-Sud/Institut National des Sciences de l'Univers) que je remercie chaleureusement au passage.

J'ai aussi contribué à faire fonctionner plusieurs logiciels importants, et surtout passé beaucoup de temps à faire tourner Poudriere, et remonter tous les bugs que j'ai trouvés.

Poudriere, l'outil de création de paquets en parallèle, stresse tellement le système d'exploitation et le matériel qu'on avait presque des kernel panics toutes les cinq minutes au début.

Quand c'est devenu assez stable, j'ai cherché d'où venaient certains problèmes de performance pour les éliminer, ce qui a été fait par des développeurs noyau ayant de la bouteille. Matt Dillon a corrigé à lui seul la majorité des bugs et des problèmes de performance les plus critiques si je me souviens bien.

C'est moi qui ait fait les benchmarks et les graphiques qui sont repris dans la dépêche sur DragonFly 3.4.

Ils proviennent de deux posts sur la liste de discussion kernel@ : celui-ci et celui-là.

Maintenant, je continue d'utiliser Poudriere pour produire les paquets binaires officiels avec John.

Tes autres contributions, en vrac ?

Au niveau applicatif :

Portage de Java : j'ai fait fonctionner le jdk 1.5 en utilisant une technique de bootstrapping mise au point par OpenBSD, puis je me suis occupé du jdk 1.6. J'ai également participé à faire fonctionner le openjdk 1.7 (le travail a principalement été fait par Chris Turner pour celui-là).

Au niveau benchmarking :

Juillet 2011 : benchmarks Blogbench/RAID. Cela a fait apparaître un problème : avec un système disque trop chargé, Hammer avait tendance à trop privilégier les requêtes en lecture, au détriment de celles en écriture.
Problème corrigé au bout de quelques jours (parcourir la liste de diffusion pour plus de précisions).
Septembre 2011 : benchmarks Blogbench/RAID. Confirme qu'il n'y a plus de problème de montée en charge. Le sous-système disque peut traiter de plus en plus de transactions au fur et à mesure qu'on ajoute des disques.
Novembre 2011 : benchmarks Postgres (pgbench) : DragonFly 2.10 vs 2.13 vs FreeBSD 9.1-RC1. Les résultats ont montré des problèmes de stabilité sous fortes charges, corrigés en quelques jours.
Aout 2012 : benchmarks Postgres (pgbench) : DragonFly 3.0 vs 3.1 vs FreeBSD 9.1-RC1 vs Scientific Linux 6.2. Pas de problème majeur avec DragonFly 3.1, mais Linux est loin devant d'un point de vue performances.
Octobre 2012 : benchmarks Postgres (pgbench). Collaboration continue ce mois-ci entre Matt Dillon et moi-même pour améliorer les performances de DragonFly et mieux monter à l'échelle en fonction des ressources processeur disponibles. Voir le résultat.
Avril 2013 : Poudriere et Sysbench file/io sur tmpfs : DragonFly 3.2 vs DragonFly 3.4. Mesure des améliorations de performance réalisées dans le cadre de l'intégration de Poudriere.

Au niveau du développement noyau :

Mon idée est toujours de rendre DragonFly plus utilisable dans un contexte professionnel. Pour cela, j'ai essayé de corriger des manques flagrants au niveau du système d'exploitation :

Août 2011-Avril 2012 : implémentation de quotas VFS suivant une ancienne idée de projet GSoC.
HAMMER est capable de rivaliser avec ZFS sur bien des points, mais personne n'avait tout simplement pensé à y inclure un système de quotas.
Les quotas VFS permettent d'ajouter des limites d'utilisation à chaque point de montage, quel que soit le système de fichiers sous-jacent. On peut ainsi limiter les quantités de données pouvant être écrites dans un /tmp monté depuis un ramdisk par exemple.
Mars-avril 2012 : élimination d'une ancienne limite de 64 ko maximum pour les entrées-sorties sur les périphériques de stockage (disques, clés USB, etc.).
Mai 2012 : portage des pilotes ichwd et amdsbwd(4) depuis FreeBSD.
Il s'agit de pilotes de watchdog permettant un reboot matériel d'une machine en cas de plantage du système d'exploitation.
DragonFly avait des problèmes de stabilité à cette époque suite à l'élimination des derniers verrous qui empêchaient le noyau de fonctionner en parallèle sur tous les processeurs par défaut.

Collabores-tu avec les développeurs des autres *BSD sur tes parties ?

Oui, j'ai par exemple discuté de problématiques communes et poussé des patchs pour Robert Nagy d'OpenBSD et Baptiste Daroussin de FreeBSD du temps où j'étais développeur LibreOffice.

J'ai bien sûr continué à échanger avec Baptiste sur tout ce qui concerne pkgng et Poudriere.

Aujourd'hui, je suis principalement le travail fait par Jean-Sébastien Pédron et l'équipe qui s'occupe des pilotes graphiques FreeBSD. Je m'efforce de synchroniser le code autant que possible et récupère périodiquement leurs contributions. La pile graphique drm2 de DragonFly a été portée depuis FreeBSD et non directement depuis Linux au départ.

Dans l'autre sens, FreeBSD récupère aussi certains des changements introduits par DragonFly.

Ceci dit, les implémentations drm2 de DragonFly et FreeBSD ne sont pas identiques : j'ai également récupéré des fonctions importantes depuis OpenBSD et nous avons des implémentations locales de certaines APIs Linux qui nous permettent d'être plus proches du code drm Linux.

Notre but commun avec Jean-Sébastien est de réduire au maximum les différences historiques entre les piles drm et de se rapprocher le plus possible de l'implémentation Linux afin de faciliter la maintenance du code sur le long terme.

Qu'est ce qu tu aimerais (voir) changer/améliorer dans DragonFly, quels sont les prochains sujets et même les futurs enjeux pour DragonFly ?

À mon sens, le projet souffre d'un gros manque de marketing et n'est par conséquent pas assez connu.

J'aimerais également qu'il soit plus facilement utilisable en entreprise en pouvant l'intégrer dans un annuaire ldap dès l'installation par exemple.

Pour des considérations plus long terme, le chantier le plus important est le développement du système de fichier Hammer 2 qui est prévu pour fonctionner à terme en multi-maître sur un cluster de machines.

Quels distribution et environnement graphique utilises‐tu ?

J'utilise principalement DragonFly, les serveurs de ma société et mon poste de travail tournent avec. Je gère aussi des FreeBSD et des distributions Linux diverses chez les clients.

Mon environnement graphique préféré est Windowmaker que j'ai utilisé aussi longtemps que possible avec des composants de kde3. Kpdf était pour moi le meilleur lecteur PDF existant sous Unix; maintenant qu'il a été abandonné, je cherche toujours un remplaçant capable de bien imprimer.

Quel est ton avis sur les évolutions en cours de la pile graphique ?

Je n'ai pas grand-chose à redire sur le fond. C'est assez logique que le noyau gère le matériel et que X.org se contente d'être une application classique et cesse d'essayer d'être un système d'exploitation à lui tout seul.

Et sur Systemd ?

J'ai l'impression que ces dernières années, pas mal de développeurs qui tournent autour des distributions Linux sont devenus fous et rendent leurs produits inutilisables. Mais c'est très bien : qu'ils continuent dans cette voie. Systemd est aujourd'hui l'une des meilleures raisons qui existe pour migrer vers un système d'exploitation *BSD.

Aller plus loin

Site officiel de DragonFly (195 clics)
DragonFly sur Wikipédia (153 clics)
Dépêche sur la sortie de la dernière version (3.4) de DragonFly (60 clics)

# C’est du propre

Posté par ariasuni le 26 octobre 2013 à 15:06. Évalué à 10. Dernière modification le 26 octobre 2013 à 15:07.

Portage de LibreOffice. […] J'ai ainsi contribué à éliminer du code OS/2 et HP-UX que personne n'utilisait, supprimé des fonctions de gestion de quotas disque qui n'avaient rien à faire dans une suite bureautique, etc.

Et le pare-feu? Plus sérieusement, ça fait froid dans le dos ce genre d’informations…

J'ai l'impression que ces dernières années, pas mal de développeurs qui tournent autour des distributions Linux sont devenus fous et rendent leurs produits inutilisables. Mais c'est très bien : qu'ils continuent dans cette voie. Systemd est aujourd'hui l'une des meilleures raisons qui existe pour migrer vers un système d'exploitation *BSD.

Si au moins on avait des arguments, là on pourrait discuter, mais là, c’est vraiment du troll pur et simple.

Écrit en Bépo selon l’orthographe de 1990
- [^] # Re: C’est du propre
  
  Posté par Sylvain Blandel le 26 octobre 2013 à 15:56. Évalué à 4.
  
  Si au moins on avait des arguments, là on pourrait discuter, mais là, c’est vraiment du troll pur et simple.
  
  Effectivement. Autant l'entretien est intéressant, détaillé et bien écrit, autant la réponse à cette dernière question est bâclée. C'est dommage, l'opinion argumentée d'un développeur *BSD sur systemd est certainement intéressante à connaître.
  - [^] # Re: C’est du propre
    
    Posté par Raphael R le 26 octobre 2013 à 16:32. Évalué à 5.
    
    Je ne vois pas ce que pourrait dire un développeur *BSD pourrait véritablement dire sur systemd à part qu'il n'est pas évident à porter (voir impossible ?) sur d'autres OS que Linux à cause de l'utilisation des cgroups.
    
    Ceci dit, les débats entre Linuxiens sur systemd virant souvent au troll ont du tellement avoir d'échos que vu de l'extérieur (quoi que François Tigeot utilise aussi du Linux) que cela donne une piètre image d'une communauté avec des personnes qui aiment donner leur avis sur des choses qu'elles ne connaissent pas sans véritablement argument de surcroît.
    
    Donc ça dernière remarque que l'on pourrait trouver bien "déplacée" donne tout de même à réfléchir au final.
    
    NB: j'utilise avec mes différentes distributions, aussi bien sysvinit et systemd (depuis près d'un an pour ce dernier).
  - [^] # Re: C’est du propre
    
    Posté par ariasuni le 26 octobre 2013 à 16:38. Évalué à 7.
    C'est dommage, l'opinion argumentée d'un développeur *BSD sur systemd est certainement intéressante à connaître.
    
    Ça dépend s’il est allé au fond des choses et n’est pas resté sur une mauvaise impression. Après tout, j’ai eu une mauvaise opinion de systemd au début (en partie à cause du FUD d’ailleurs), et pourtant je suis fervent utilisateur aujourd’hui. Au passage, tout ce remue-ménage m’a permit d’apprendre pas mal de choses sur ce composant plutôt méconnu du système.
    
    En plus, il faut voir que même si systemd n’est pas parfait ça a moins le mérite d’être plus simple, d’ajouter des fonctionnalités utiles, d’être plus rapide, etc. Mais surtout, beaucoup de distributions (avec des gens compétents donc) ont trouvé que c’était une bonne idée de l’adopter (et c’est un vrai pas en avant pour l’unification, donc travail commun et facilité de support des différentes distributions).
    
    D’ailleurs je vous invite à jeter un œil aux objectifs d’amélioration du support de systemd sur une récente dépêche concernant Debian.
    
    Globalement, systemd fait plus de trucs mais reste simple à utiliser. Les seuls arguments qui semblaient tenir la route contre systemd, c’est:
    - C’est dépendant de Linux, mais vu la dernière réponse j’ai pas l’impression que ça les aurait pas intéressé de toute façon, il reste le cas particulier de Debian où clairement ça demande un peu de travail (mais ça demandera beaucoup moins de maintenance une fois correctement intégré).
    - Oulà c’est pas la philosophie Unix, ce qui est faux quand on sait que la plupart des fonctionnalités de systemd sont des binaires séparés de systemd lui-même.
    - Oulà dbus c’est le mâââl, mais bon si ils avaient réinventé la roue on aurait gueulé, là on utilise un standard et du coup pour les applications c’est facile de communiquer avec.
    - On s’en fout que ça démarre plus vite, mais bizarrement quand c’est autre chose qui vachement rapide bah tout de suite c’est une fonctionnalité intéressante.
    - Lennart Poettering y fait que de la merde, mais PulseAudio m’énerve aussi des fois mais c’est pas une raison.
    À la limite la seule raison valable qui me viens à l’esprit, c’est que c’est compliqué d’utiliser udev indépendamment de systemd. Ça c’est vrai que c’est pas cool, mais bon c’est pas un fork sauvage d’udev qui aurait tué le dépôt original, à priori il n’y avait de gros .
    
    Donc en aucune façon un point technique, même si j’imagine qu’il a quelques cas tordus où systemd ne répond pas trop au besoin.
    
    À force de répondre et de lire des réponses à des trolls (Trollfr oblige) sur systemd, on apprend des tas de choses.
    
    Écrit en Bépo selon l’orthographe de 1990
    - [^] # Mon opinion sur systemd
      
      Posté par Enj0lras le 27 octobre 2013 à 12:08. Évalué à -2.
      Personnellement, je pense qu'il y a de très bonnes idées dans systemd, les plus importantes étant :
      
      suivi des processus (via les cgroups) permettant de faire de la supervision de daemons
      
      gestion fine des dépendances et parallélisme.
      
      gestion des évènements et démarrage de services conditionnels
      
      Le problème c'est que je n'aime pas l'implémentation. Dire que systemd est découpé plein d'outils est très partiellement vrai. Un des plus gros problèmes c'est que systemd est écrit en C. Je trouve incroyable qu'on écrire un logiciel si gros en C de nos jours. Du coup, il me semble qu'un tel logiciel devrait vraiment être simplifié et découpé en plusieurs processus. Parce que systemd est gros. Presque un million de ligne de code en regardant tout ses composants.
      
      Par exemple, le code pour parser les fichiers de conf tourne dans l'init, en mode privilégié, alors que ça pourrait très bien être un utilitaire séparé. De même, systemd sait monter des systèmes de fichier, alors que du code montant des systèmes de fichier existe déjà : il serait bon de le réutiliser, en faisant appel à un utilitaire séparé. Il en va de même pour le code de monitoring des processus, qui pourrait tourner dans un daemon distinct. L'overhead en communication n'est pas ce qui va ralentir l'éxécution de manière dommageable, je pense.
      
      Pour résumer, je pense que le coeur d'init devrait n'ếtre capabable que de gérer des noms de service et garder la trace de ceux qui sont lancés, ainsi qu'une structure de donnée représentant les relations de dépendance (qui peut même être conservée sur le disque, sur le FS). Quand il veut lancer un service, il délègue au bon daemon (mountd, netd, …) et recevoir les événements de daemons de monitoring ( (u)devd, netd, mountd, monitord, pour regarder quels process meurent, etc).
      
      La surface d'attaque est grandement diminuée, et si un des daemons plantes, tout les processus du système ne meurent pas. La tolérance au bug est beaucoup plus forte, ainsi que la ré-utilisation de code. Il est ainsi possible de démarer en mode dégradé dans n'importe quelle condition.
      - [^] # Re: Mon opinion sur systemd
        
        Posté par Zenitram (site web personnel) le 27 octobre 2013 à 14:17. Évalué à 5.
        
        Je trouve incroyable qu'on écrire un logiciel si gros en C de nos jours.
        
        Clair, Linux est une grosse merde, c'est incroyable qu'on continue avec un tel bousin si énorme et en C, vivement que Linux soit ré-écrit en Python (ou en Java, ha non, mieux ! en bash) pour que ce soit mieux et Enj0lras ne dise plsu que le gros problème de Linux est qu'il est écrit en C.
        
        Bref, cet phrase :
        
        Un des plus gros problèmes c'est que systemd est écrit en C
        
        montre surtout qu'il y a un tel manque d'arguments devant systemd qu'on en vient à inventer tout et n'importe quoi pour lui trouver des problèmes.
        Conclusions logique : en fait, il n'y a pas de problèmes avec systemd si les anti-systemd en sont à balancer de telle phrases des plus ridicules sans se dire qu'il y un soucis.
        
        [^] # Re: Mon opinion sur systemd
        
        Posté par Enj0lras le 27 octobre 2013 à 14:22. Évalué à 2.
        
        Ta capacité à être détestable me sidère chaque jour un peu plus. Mais pour répondre rationnenellement à ton troll, j'aimerais que tu relises et que tu remarques que ré-écrire un logiciel de plusieurs millions de ligne de code en C n'a rien à voir avec écrire un nouveau logiciel en repartant de zéro, en C.
        
        [^] # Re: Mon opinion sur systemd
        
        Posté par xcomcmdr le 27 octobre 2013 à 14:25. Évalué à 9.
        
        Je ne vois pas en quoi le choix du C serait mauvais.
        
        "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
        
        [^] # Re: Mon opinion sur systemd
        
        Posté par Enj0lras le 27 octobre 2013 à 14:33. Évalué à 5.
        
        Pour préciser, les choses, j'ajoute un autre commentaire.
        
        J'aimerais un jour que tu arrêtes de répondre en considérant qu'il y a une vérité, avec des gens qui ont raison et des gens qui ont tord, et que tout le monde est con quand il ne pense pas comme toi. Je ne suis pas anti-systemd mais je considère que j'ai quand même le droit d'avoir une opinion sur la manière de développer des logiciel (relis le titre). Et si tu ne penses pas que le fait qu'un logiciel soit écrit en C soit un problème, soit. Mais admets quand même que certains puissent le penser, et je te prie d'arrêter de prendre ce ton hautain quand tu réponds à mes commentaires (et ceux des autres si possible). Tu aurais pu me demander pourquoi je considérais ça comme un problème au lieu de répondre comme si je venais de proférer la pire merde de l'histoire du monde et de troller inutilement.
        
        Le C est quand même un langage très très faible au niveau du typage et de la sureté qu'il apporte. Il est très simple d'ajouter des failles et des bugs dans un code en C. Si tu relis mon commentaire précédant, tu te rendras compte que je disais qu'a mon avis, un logiciel écrit en C ne devrait pas avoir ce genre de design monolithique. En effet, la surface d'attaque et de bugs est plus grande. De plus, en re-codant divers services, il y a plus de chance d'introduire de nouveaux bugs alors que réutiliser du code existant est potentiellement plus fiable et plus simple, car le code a été utilisé pendant des années et a plus de chance d'être stable. Donc, à mon avis quand on code en C, on a tout intérêt à coder de manière modulaire et de séparer les privilèges dans différents contextes de sécurités, en utilisant les mécanismes de l'OS sous-jacent. POur unix, ça revient à séparer le code en plusieurs processus qui ont différente permission, et à communiquer via l'IPC, essentiellement des pipes ou des sockets unix. Maintenant, si tu considères que ça n'est pas souhaitable, dis moi pourquoi au lieu de troller.
        
        [^] # Re: Mon opinion sur systemd
        
        Posté par barmic le 27 octobre 2013 à 15:10. Évalué à 10.
        
        Tu rentre dans un troll sur les systèmes d'init avec un troll sur les langages et tu te plains, c'est du foutage de gueule.
        
        systemd souhaite utiliser les API du noyau, elles sont en C, il a donc choisi d'utiliser du C (et un langage qu'il connaît bien).
        
        Donc, à mon avis quand on code en C, on a tout intérêt à coder de manière modulaire et de séparer les privilèges dans différents contextes de sécurités, en utilisant les mécanismes de l'OS sous-jacent.
        
        Alors que quand on écris du ruby, écrire un bon gros script d'un million de lignes qui réinvente la roue ce n'est pas un problème ? Tu mélange 2 choses totalement séparée, l'architecture et le langage utilisé. Une architecture est bonne ou mauvaise indépendamment du langage (en fait le langage peut donner des facilité d'architecture ou non, mais ce n'est pas ce dont tu parle).
        
        Si tu as des arguments contre l'architecture de systemd parles-en, zenitram a juste dis que troller sur le langage (ce que tu fais) c'est puéril (et il a 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: Mon opinion sur systemd
        
        Posté par Enj0lras le 27 octobre 2013 à 15:28. Évalué à -1.
        
        Mon but n'était pas de lancer un troll sur les langages, juste de faire remarquer qu'écrire un logiciel en C apporte des contraintes d'architecture qu'à mon avis systemd ne respecte pas. Je ne suis pas d'accord avec le fait que l'architecture est entièrement dé-corrélée du langage. Si tu écris ton logiciel dans un langage qui a une notion de propriété de la mémoire forte, tu n'as pas forcément besoin de séparer les composants dans différents processus, parce que la séparation de privilèges a lieue déjà au niveau du langage d'une certaine manière.
        
        Si tu prends l'exemple de rust, vu que les pointeurs définissent la propriété de la zone mémoire pointée, c'est directement au niveau du langage que la séparation des espaces mémoire est gérée, donc il n'y a pas forcément besoin de séparer les contextes d’exécution dans des espaces mémoire distincts. Quand au fait de s'interfacer avec le noyau, je trouve que c'est un faux argument. Il y a des bindings avec l'API unix dans quasiment tout les langages que je connaisse. Tu n'as vraiment pas besoin de C pour effectuer des syscalls.
        
        [^] # Re: Mon opinion sur systemd
        
        Posté par xcomcmdr le 27 octobre 2013 à 15:33. Évalué à 4.
        
        Il y a des bindings avec l'API unix dans quasiment tout les langages que je connaisse. Tu n'as vraiment pas besoin de C pour effectuer des syscalls.
        
        systemd n'utilise pas l'API Unix, mais l'API Linux, notamment les cgroups.
        
        "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
        
        [^] # Re: Mon opinion sur systemd
        
        Posté par Enj0lras le 27 octobre 2013 à 15:36. Évalué à -2.
        
        ça ne change strictement rien… C'est des appelles systèmes. Et libcgroups est largement assez petite pour que des bindings puisses être écrits en moins d'une après midi. Surtout que c'est même inutile, car la majorité des opérations sur les cgroups peut se réaliser en utlisant l'API unix sur les fichiers. C'est un des points forts des crgoups.
        
        [^] # Re: Mon opinion sur systemd
        
        Posté par xcomcmdr le 27 octobre 2013 à 16:19. Évalué à 8. Dernière modification le 27 octobre 2013 à 16:21.
        
        Ben pourtant :
        
        Portability to OSes:
        
        systemd is not portable to non-Linux systems. It makes use of a large number of Linux-specific interfaces, including many that are used by its very core. We do not consider it feasible to port systemd to other Unixes (let alone non-Unix operating systems) and will not accept patches for systemd implementing any such portability (but hey, it's git, so it's as easy as it can get to maintain your own fork…). APIs that are supposed to be used as drop-in .c files are exempted from this: it is important to us that these compile nicely on non-Linux and even non-Unix platforms, even if they might just become NOPs.
        
        Mais bon soit. Que systemd soit dépendant fortement ou non des API Linux, un binding aurait été possible.
        Mais le choix aurait été tout autant critiqué, voir plus :
        -> C++ (ça aurait invoqué le refrain classique comme quoi le C++ est "trop compliqué")
        -> Ruby/Java/Python ("une VM pour l'init, what ?!")
        -> D ("quoi, un langage pas connu ?!")
        -> …
        
        Le choix du C, en plus d'être classique, évite de maintenir un binding, d'avoir un langage connu (par les auteurs de systemd et par les développeurs *nix en général), portable, rapide, avec des compilateurs matures (gcc, clang).
        
        "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
        
        [^] # Re: Mon opinion sur systemd
        
        Posté par barmic le 27 octobre 2013 à 18:23. Évalué à 4.
        
        Je ne suis pas d'accord avec le fait que l'architecture est entièrement dé-corrélée du langage.
        
        Tu répond à qui là ? Parce que ce n'est pas ce que j'ai écris, ni ce que j'ai sous-entendu. J'ai dis que des fois le langage porte des contraintes sur l'architecture, mais que ce n'est pas le cas dans tes arguments. Avoir un gros binaire qui fait tout c'est aussi mauvais (d'un point de vu architectural) en C qu'en rust.
        
        Si tu écris ton logiciel dans un langage qui a une notion de propriété de la mémoire forte, tu n'as pas forcément besoin de séparer les composants dans différents processus, parce que la séparation de privilèges a lieue déjà au niveau du langage d'une certaine manière.
        
        C'est faux.
        
        La séparation en processus n'est pas faites que pour la sécurité. C'est fait pour améliorer la testabilité, la gestion des erreurs etc
        
        La séparation des privilèges se fout éperdument du langage que tu utilise.
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
      - [^] # Re: Mon opinion sur systemd
        
        Posté par Anonyme le 29 octobre 2013 à 15:25. Évalué à 2.
        
        Du coup, il me semble qu'un tel logiciel devrait vraiment être simplifié et découpé en plusieurs processus
        
        systemd est deja découpé en plusieurs processus.
        
        Par exemple, le code pour parser les fichiers de conf tourne dans l'init, en mode privilégié, alors que ça pourrait très bien être un utilitaire séparé
        
        Tu voudrais qu'ils fassent ca comment ? Un fork avec un processus séparé qui lit les fichiers de conf, les parse, et serialize tout ca pour le renvoyer sur un socket unix au processus principal ? Quel serait l'interet ? Qu'est ce que ca apporterait à part une complexification inutile ?
        
        Il en va de même pour le code de monitoring des processus, qui pourrait tourner dans un daemon distinct. L'overhead en communication n'est pas ce qui va ralentir l'éxécution de manière dommageable, je pense.
        
        C'est facile de dire "ca pourrait tourner dans un daemon distinct", mais ils sont ou les patchs qui montrent que ca peut vraiment etre fait ?
  - [^] # Re: C’est du propre
    
    Posté par François Tigeot le 26 octobre 2013 à 16:41. Évalué à 10.
    
    C'est dommage, l'opinion argumentée d'un développeur *BSD sur systemd est certainement intéressante à connaître.
    
    C'était la question piège et j'ai marché dedans.
    
    Je pense que le reproche principal qu'on peut faire à systemd est que c'est quelque-chose qui s'éloigne complètement de l'esprit Unix:
    - petits composants logiciels qui font une seule chose et la font bien
    - communication entre ces composants pour obtenir des choses plus complexes
    - utilisation de fichiers texte directement lisibles et modifiables par les utilisateurs
    
    Systemd ne se contente pas d'être un remplaçant à init et de gérer le démarrage du système et des divers démons, il vise aussi à remplacer syslog, gérer automatiquement les devices dans /dev, etc…
    Qui plus est, il fait cela en remplaçant des fichiers texte par des fichiers binaires qui ont ensuite besoin de programmes spéciaux pour être manipulés.
    
    Fini les commandes tail -f /var/log/messages ou le grep dans maillog. Fini le débugage de scripts de démarrage avec vi. On se retrouve avec une usine à gaz qui met en l'air 30 ans de pratiques industrielles et je ne suis pas sûr qu'on gagne quelque-chose en échange.
    - [^] # Re: C’est du propre
      
      Posté par ariasuni le 26 octobre 2013 à 17:03. Évalué à 8. Dernière modification le 26 octobre 2013 à 17:04.
      petits composants logiciels qui font une seule chose et la font bien
      
      communication entre ces composants pour obtenir des choses plus complexes
      
      cf. mon commentaire au-dessus.
      
      utilisation de fichiers texte directement lisibles et modifiables par les utilisateurs
      
      On peut utiliser journalctl > fichier pour avoir du texte pur, et surtout journalctl possède des fonctions de recherche très pratiques.
      
      Quelqu’un avait commenté sur une précédente dépêche du fait que quand systemd est H.S. tu ne peux pas lire les journaux systèmes de la machine sans systemd sur une autre machine.
      
      Mais franchement, est-ce que ça vous est déjà arrivé d’avoir le système d’initialisation H.S.? Si ça vous importe, il est possible d’utiliser un autre gestionnaire de journaux.
      
      Fini le débugage de scripts de démarrage avec vi.
      
      Maintenant on a un truc qui est utilisé par beaucoup plus de monde (Fedora, openSUSE, Arch Linux, Frugalware, etc) dont potentiellement moins bugué, alors qu’avant c’était chacun son truc donc potentiellement plus bugué et surtout, il fallait réapprendre pour chaque distribution.
      
      On a un format déclaratif (les .unit et autres dans le style) pour lancer des démons (entre autres), tout en ayant la possibilité de lancer ses propres scripts shell si on le souhaite.
      
      Bref, à part les journaux binaires qui peuvent être problématique dans des cas extrêmes, les autres points me semblent invalides.
      
      Je te remercie de ta réponse, car c’est vrai que c’est pas forcément facile de bien vouloir répondre sur Linuxfr quand on commence à se faire critiquer négativement dès le premier commentaire. Anéfé j’ai tendance à partir au quart de tour, parce que les trolls sur systemd ça me gave.
      
      Écrit en Bépo selon l’orthographe de 1990
    - [^] # Re: C’est du propre
      
      Posté par xcomcmdr le 26 octobre 2013 à 17:26. Évalué à 10. Dernière modification le 26 octobre 2013 à 17:26.
      Je pense que le reproche principal qu'on peut faire à systemd est que c'est quelque-chose qui s'éloigne complètement de l'esprit Unix:
      
      Faux. systemd c'est une soixantaine de binaire, tous remplaçables et on peut tous éviter de les utiliser (sauf le coeur, évidemment), voire de les compiler.
      
      $ pacman -Ql systemd | grep /usr/bin
      systemd /usr/bin/bootctl
      systemd /usr/bin/hostnamectl
      systemd /usr/bin/journalctl
      systemd /usr/bin/kernel-install
      systemd /usr/bin/localectl
      systemd /usr/bin/loginctl
      systemd /usr/bin/machinectl
      systemd /usr/bin/systemctl
      systemd /usr/bin/systemd-analyze
      systemd /usr/bin/systemd-ask-password
      systemd /usr/bin/systemd-cat
      systemd /usr/bin/systemd-cgls
      systemd /usr/bin/systemd-cgtop
      systemd /usr/bin/systemd-coredumpctl
      systemd /usr/bin/systemd-delta
      systemd /usr/bin/systemd-detect-virt
      systemd /usr/bin/systemd-inhibit
      systemd /usr/bin/systemd-machine-id-setup
      systemd /usr/bin/systemd-notify
      systemd /usr/bin/systemd-nspawn
      systemd /usr/bin/systemd-run
      systemd /usr/bin/systemd-stdio-bridge
      systemd /usr/bin/systemd-tmpfiles
      systemd /usr/bin/systemd-tty-ask-password-agent
      systemd /usr/bin/timedatectl
      systemd /usr/bin/udevadm
      
      :)
      
      petits composants logiciels qui font une seule chose et la font bien
      
      Voir au dessus.
      
      communication entre ces composants pour obtenir des choses plus complexes
      
      Voir au dessus.
      
      utilisation de fichiers texte directement lisibles et modifiables par les utilisateurs
      
      On peut éviter d'utiliser ces binaires pour modifier la config et modifier les fichiers texte cibles à la main à la place.
      
      Systemd ne se contente pas d'être un remplaçant à init et de gérer le démarrage du système et des divers démons, il vise aussi à remplacer syslog,
      
      Non, c'est journald qui remplace syslog.
      
      gérer automatiquement les devices dans /dev,
      
      Non, ça reste le rôle de udev.
      
      etc…
      
      etc quoi ?
      
      Qui plus est, il fait cela en remplaçant des fichiers texte par des fichiers binaires qui ont ensuite besoin de programmes spéciaux pour être manipulés. Comme modifier /etc/locale.conf au lieu d'appeler localtcl.
      
      Seul le journal est binaire.
      
      Fini les commandes tail -f /var/log/messages ou le grep dans maillog.
      
      En même temps, journald fournit tout ce qu'il faut pour analyser le journal (man journalctl). Et il fournit un journal au format standardisé (fini les 26 formats de dates différents, par exemple).
      
      Et on peut toujours reverser le contenu du journal de journald sous forme texte vers syslog (ça reverse dans les deux sens, en fait, avec le daemon approprié).
      
      Fini le débugage de scripts de démarrage avec vi.
      
      Tant mieux :
      
      Myth: systemd is not debuggable.
      False. Some people try to imply that the shell was a good debugger. Well, it isn't really. In systemd we provide you with actual debugging features instead. For example: interactive debugging, verbose tracing, the ability to mask any component during boot, and more. Also, we provide documentation for it.
      It's certainly well debuggable, we needed that for our own development work, after all. But we'll grant you one thing: it uses different debugging tools, we believe more appropriate ones for the purpose, though.
      
      Et puis les unit files sont bien plus simples, et ils sont uniformisés (idéalement, l'unit file provient de l'upstream du projet, et non pas de la distribution)
      
      On se retrouve avec une usine à gaz qui met en l'air 30 ans de pratiques industrielles et je ne suis pas sûr qu'on gagne quelque-chose en échange.
      
      On y gagne énormément en échange. Quelques exemples :
      * Hotplug support
      * Démarrage bien plus rapide
      * Compatibilité avec les shellscripts
      * Support du multi-seat
      * systemd est scriptable ( systemctl, loginctl, timedatectl, hostnamectl, localectl , …)
      * Arrêt bien plus fiable des services (fini les zombies) grâce aux cgroups du kernel
      * Intégration avec Linux (comme l'init BSD est fait pour BSD)
      * unification des unit files (plutôt que d'avoir 36 variantes du script d'init pour un même logiciel, un par distrib'…)
      * unification des runlevels (fini les différences à ce niveau entre les distributions)
      * on ne réinvente pas la roue : systemd utilise linux, udev, d-bus, tout ce qui existait déjà.
      
      Bref, tu devrais lire ceci :
      http://0pointer.de/blog/projects/the-biggest-myths.html
      
      "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
      - [^] # Re: C’est du propre
        
        Posté par ariasuni le 26 octobre 2013 à 19:33. Évalué à 5.
        
        Je pense que c’est lui qui est gavé par les explications sur systemd maintenant… xD
        
        Écrit en Bépo selon l’orthographe de 1990
        
        [^] # Re: C’est du propre
        
        Posté par xcomcmdr le 26 octobre 2013 à 20:41. Évalué à 2.
        
        Oui, on a dégainé en même temps ! :o
        
        En plus j'ai pourri une citation. Ceci :
        
        Qui plus est, il fait cela en remplaçant des fichiers texte par des fichiers binaires qui ont ensuite besoin de programmes spéciaux pour être manipulés. Comme modifier /etc/locale.conf au lieu d'appeler localtcl.
        
        Seul le journal est binaire.
        
        Devrait se lire ainsi :
        
        Qui plus est, il fait cela en remplaçant des fichiers texte par des fichiers binaires qui ont ensuite besoin de programmes spéciaux pour être manipulés.
        
        Seul le journal est binaire. Pour le reste, on peut par exemple modifier /etc/locale.conf directement au lieu d'appeler localtcl.
        
        Mais je ne peux plus corriger ! grrr.
        
        "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
      - [^] # Re: C’est du propre
        
        Posté par Arthur Accroc le 27 octobre 2013 à 08:50. Évalué à 10.
        
        Je me permets de répondre à sinma et à xcomcmdr dans le même commentaire, parce que mes éléments de réponse sont en partie liés.
        
        sinma :
        
        Maintenant on a un truc qui est utilisé par beaucoup plus de monde (Fedora, openSUSE, Arch Linux, Frugalware, etc) dont potentiellement moins bugué,
        
        « Potentiellement », oui ; systemd est encore jeune. Peut-être atteint-il maintenant un stade assez mature, mais pas depuis très longtemps.
        La version pourrie qui était sur la Fedora 17 causait des dysfonctionnement d’autofs.
        Je sais que systemd a une fonctionnalité d’automontage, mais elle n’est pas à la hauteur d’autofs : pas de possibilité de charger les points de montage d’une table NIS ou d’un annuaire LDAP, ni d’auto-démonter après un certain temps sans utilisation.
        
        xcomcmdr :
        
        Myth: systemd is not debuggable.
        False. Some people try to imply that the shell was a good debugger. Well, it isn't really. In systemd we provide you with actual debugging features instead. For example: interactive debugging, verbose tracing, the ability to mask any component during boot, and more. Also, we provide documentation for it.
        
        Ça, c’est quand le bug est dans l’enchaînement du démarrage ou dans les composants eux-mêmes. Pour les dysfonctionnements d’autofs, qui impliquaient un traitement spécial au niveau de systemd lui-même (autofs est un service qui monte des répertoires pour d’autre utilisateurs que celui sous lequel il tourne ; apparemment, ça rentre mal dans les cases des cgroups), les développeurs de Fedora avaient marqué le bug en « fix next release ». Sachant que les versions plus récentes de systemd le corrigeaient, mais que les développeurs de Fedora conservaient sa version d’origine dans la 17 (probablement pour éviter des modifications trop importantes du système, les définitions des unités systemd ayant beaucoup évolué entre la version de Fedora 17 et celle qui corrigeait le problème ; c’est ce qui m’a dissuadé de résoudre le problème en remplaçant moi-même la version de systemd), il n’y avait pas d’issue.
        
        sinma :
        
        alors qu’avant c’était chacun son truc donc potentiellement plus bugué et surtout, il fallait réapprendre pour chaque distribution.
        
        Ben c’est-à-dire que quand un script d’init de quelques dizaines de lignes était pourri, je pouvais le déboguer moi-même. S’il faut déboguer systemd (je parle bien de l’exécutable de systemd, pas des unités) pour un problème non trivial, c’est cuit.
        
        Bon, maintenant, Fedora fait en sorte de mettre à jour systemd. Je ne sais pas dans quelle mesure ça leur fait un boulot important ou pas, mais c’est certainement plus raisonnable que d’essayer de backporter des modifications de systemd dans une version plus ancienne.
        
        xcomcmdr :
        
        On y gagne énormément en échange. Quelques exemples :
        * Démarrage bien plus rapide
        
        Ou pas. Sur mon portable sous Arch, avant systemd, je démarrais les quelques services dont dépendent vraiment les autres séquentiellement, puis quasiment tout en parallèle. Au début (quand systemd n’était que dans les contributions), systemd démarrait aussi rapidement, mais avec la multiplication des micro-unités et des fichiers de configuration, ça demande plus d’accès disques et c’est finalement plus lent.
        
        À l’opposé, sur un serveur, le démarrage parallélisé, voire à la demande, rend plus difficile de vérifier que tous les services ont démarré correctement.
        
        Compatibilité avec les shellscripts
        
        C’est une fonctionnalité de systemd, mais pas un gain. Les systèmes de démarrage basés sur le shell n’avaient pas trop de problèmes de compatibilité avec les scripts shells.
        
        Arrêt bien plus fiable des services (fini les zombies) grâce aux cgroups du kernel
        
        C’est bien sur un serveur.
        En pratique, sur un poste client que tu veux redémarrer, c’est moins clair.
        Il arrive que des points de montage NFS restent après l’arrêt du réseau (léger souci dans l’enchaînement quand même… et ça, c’est sous Fedora 19 avec un systemd récent, sur les versions plus anciennes, ce genre de problème était plus fréquent et bien plus long) et alors systemd patine pendant un certain temps dessus… Alors que de toute façon, il ne se produira pas de miracle pour finir une hypothétique opération sur un système de fichier réseau sans le réseau, et que tout ce que tu veux, c’est redémarrer.
        
        D’un autre côté, si on considère que l’alternative actuelle dans les distributions populaires, c’est upstart, finalement systemd fonctionne quand même plus facilement avec des services réseau…
        
        Intégration avec Linux (comme l'init BSD est fait pour BSD)
        
        Non, l’intégration avec le système, pour le meilleur (meilleure gestion du hotplug, que tu cites) ou le pire (quasiment plus possible d’éviter systemd), c’est une nouveauté de systemd.
        Avec un Unix normal, le système d’init est globalement indépendant du noyau. Il suffit de voir la Slackware avec un init BSD ou la Debian/BSD avec un init System V.
        
        unification des unit files (plutôt que d'avoir 36 variantes du script d'init pour un même logiciel, un par distrib'…)
        
        Avec le bémol que la distribution la plus populaire n’a pas adopté systemd.
        
        on ne réinvente pas la roue : systemd utilise linux, udev, d-bus, tout ce qui existait déjà.
        
        Il remplace (hormis le système d’init) l’automontage (mal), la gestion de la veille (sans fournir toutes les fonctionnalités non plus), les journaux système…
        
        Bref, systemd n’est pas dépourvu d’intérêt, mais tout n’est pas rose non plus.
        Si tout ce que veulent les développeurs des *BSD, c’est un système d’init simple et fiable et pas autre chose, ils sont certainement mieux avec leur système actuel.
        
        « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
        
        [^] # Re: C’est du propre
        
        Posté par Zenitram (site web personnel) le 27 octobre 2013 à 09:23. Évalué à -8.
        
        C’est bien sur un serveur.
        En pratique, sur un poste client que tu veux redémarrer, c’est moins clair.
        
        hum… De nos jours, un poste client redémarre aussi souvent qu'un serveur.
        On n'est plus en 1990 (avec 30 ans de pratiques industrielle adapée uniquement à 1990 au passage), les usages on évolués.
        
        Non, l’intégration avec le système, (…) ou le pire (quasiment plus possible d’éviter systemd), c’est une nouveauté de systemd.
        
        Conneries : personne ne force à utiliser systemd : si "quasiment plus possible d’éviter systemd", c'est la volonté de tes mainteneurs, pas de systemd. Accuse plutôt tes mainteneurs de vouloir se faciliter la vie plutôt que d'en chier pour ta personne.
        
        Avec le bémol que la distribution la plus populaire n’a pas adopté systemd.
        
        Tu parles de qui?
        Debian? C'est pas la plus populaire, et c'est non pas à cause que systemd est nul, mais que ça pose un petit problème avec leur version BSD, sinon il y seraient passée.
        Ubuntu? Tu parles des gens qui essayent d'imposer Mir la… Ce n'est pas un argument
        
        Et le pire dans ce que tu dis, c'est qu'en quelques ligne tu dis une chose est son contraire : "quasiment plus possible d’éviter systemd" puis "la distribution la plus populaire n’a pas adopté systemd", désolé mais quand la disstribution la plus populaire n'adopte pas x, j'ai du mal à imagine que tu ne peux pas éviter x, suffit de prendre la plus populaire (la popularité d'un distro t'étant importante dans ton argumentation, ça devrait aller).
        
        Il remplace (hormis le système d’init) l’automontage (mal), la gestion de la veille (sans fournir toutes les fonctionnalités non plus), les journaux système…
        
        ben oui, c'est lié… Pareil, on n'est plus en 1990, les besoins ont évolués.
        
        Bref, systemd n’est pas dépourvu d’intérêt, mais tout n’est pas rose non plus.
        
        Personne n'a dit le conraire. Il rpond juste au besoin de 2013 ce que ne fait pas le "truc stable avec 30 ans de pratiques industrielle"
        
        Si tout ce que veulent les développeurs des *BSD, c’est un système d’init simple et fiable et pas autre chose, ils sont certainement mieux avec leur système actuel.
        
        Donc leur système actuel ne répond pas à leur besoin ("simple", ha ha ha) ok :)
        Après qu'ils fassent ce qu'ils veulent, mais à eux de faire le boulot chiant (les scripts) parce que les projets feront juste une fichier pour systemd simple, c'est tout aussi normal que les autres n'ai pas envie de se faire chier.
        Personne ne les force à adopter systemd comme personne ne force les projets à passer du temps pour d'autres système d'init que systemd.
        
        [^] # Re: C’est du propre
        
        Posté par Arthur Accroc le 27 octobre 2013 à 10:11. Évalué à 5.
        
        hum… De nos jours, un poste client redémarre aussi souvent qu'un serveur.
        
        De nos jours, il y a encore des logiciels qui n’existent que sous Windows.
        Donc sur un poste en double boot…
        
        hum… De nos jours, un poste client redémarre aussi souvent qu'un serveur.
        
        Quand tu mets à jour le noyau ou la glibc, il faut bien le redémarrer. Si tu peux le faire proprement sans que ça bloque, c’est bien aussi.
        
        Conneries
        
        Toujours aussi poli.
        
        personne ne force à utiliser systemd
        
        Si tu veux toutes les fonctionnalités de certains logiciels (notamment des environnements graphiques), tu ne peux pas vraiment faire autrement.
        
        Ubuntu? Tu parles des gens qui essayent d'imposer Mir la… Ce n'est pas un argument
        
        Ils font des conneries, donc les gens qui utilisent leur distribution, même nombreux, ne comptent pas ?
        
        Et le pire dans ce que tu dis, c'est qu'en quelques ligne tu dis une chose est son contraire : "quasiment plus possible d’éviter systemd" puis "la distribution la plus populaire n’a pas adopté systemd", désolé mais quand la disstribution la plus populaire n'adopte pas x, j'ai du mal à imagine que tu ne peux pas éviter x, suffit de prendre la plus populaire (la popularité d'un distro t'étant importante dans ton argumentation, ça devrait aller).
        
        C’est-à-dire que tu peux éviter systemd soit en acceptant de te passer de fonctionnalités qui existaient avant (notamment celles liées auparavant à console kit, que systemd a remplacé aussi), soit en développant comme Ubuntu ce qu’il faut pour simuler son API, soit en utilisant Ubuntu, la distribution avec un système d’init plus merdique que systemd.
        En gros, tu as le choix de ne pas utiliser systemd en ayant moins bien que ce qui existait avant. Pas terrible.
        
        Il remplace (hormis le système d’init) l’automontage (mal), la gestion de la veille (sans fournir toutes les fonctionnalités non plus), les journaux système…
        ben oui, c'est lié… Pareil, on n'est plus en 1990, les besoins ont évolués.
        
        Je ne vois pas le rapport avec le point auquel tu réponds.
        Mais tu veux dire qu’avant, on pouvait vouloir que son portable éteigne juste l’écran quand on le replie alors qu’il est sur secteur, et qu’il mette le portable en hibernation si on est sur batterie, mais qu’en 2013 ce n’est plus un besoin légitime ?
        
        C’est facile de dire que les besoins ne sont plus les mêmes qu’en 1990.
        Déjà, c’est de la mauvaise foi, puisque les besoins comme les fonctionnalités ont évolué entre 1990 et l’avènement de systemd, et d’autre part, les besoins existent toujours pour une bonne partie. Il y a plus de portables, mais les postes fixes en réseau sont encore nombreux en environnement professionnel.
        
        Donc leur système actuel ne répond pas à leur besoin ("simple", ha ha ha) ok :)
        
        Simple, ce n’est pas la même chose que facile.
        C’est peut-être plus facile pour l’utilisateur d’une distribution Linux de configurer ses services avec systemd, mais si je veux comprendre entièrement le système d’init en lisant son code, j’aurai beaucoup plus vite fait avec un init BSD. Si je maintenais un système Unix non Linux, j’aurais aussi beaucoup moins de mal à avoir un init BSD que de me coltiner l’adaptation du noyau à systemd ou l’inverse.
        Donc je persiste : l’init BSD est plus simple.
        
        « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
        
        [^] # Re: C’est du propre
        
        Posté par pikapika le 28 octobre 2013 à 01:33. Évalué à -2.
        
        systemd vu par ses fans, ça me fait toujours penser à ça
        
        [^] # Re: C’est du propre
        
        Posté par Psychofox (Mastodon) le 28 octobre 2013 à 08:36. Évalué à 4.
        
        Pfff, il ne répare même pas les motos russes.
        
        [^] # Re: C’est du propre
        
        Posté par pikapika le 28 octobre 2013 à 18:38. Évalué à -1.
        
        pas content et pas d'humour les fans
        
        [^] # Re: C’est du propre
        
        Posté par Sylvain Blandel le 27 octobre 2013 à 12:41. Évalué à 10.
        
        Systemd remplace (hormis le système d’init) l’automontage (mal), la gestion de la veille (sans fournir toutes les fonctionnalités non plus), les journaux système …
        
        → Systemd propose une alternative à autofs (avec l'option x-systemd.automount à ajouter dans le fstab). Si cette solution ne satisfait pas ton besoin, libre à toi de ne pas l'utiliser, et de préférer autofs.
        
        → Systemd se propose de gérer la mise en veille. Si tu préfères qu'il ne le fasse pas, voici comment faire : avec un éditeur de texte, modifie le fichier /etc/systemd/logind.conf, et utilise les options suivantes :
        
        HandlePowerKey=ignore
        
        HandleSuspendKey=ignore
        
        HandleHibernateKey=ignore
        
        HandleLidSwitch=ignore
        
        Bien entendu, tu peux utiliser le traditionnel démon acpid pour gérer la mise en veille, l'hibernation, etc.
        
        → Systemd centralise les journaux système, et tu peux utiliser syslog qui écrira les logs dans des fichiers texte.
        
        Bref : que ce soit pour l'automontage, la gestion de l'énergie ou le format des logs, l'utilisateur a le choix.
        
        À l’opposé, sur un serveur, le démarrage parallélisé, voire à la demande, rend plus difficile de vérifier que tous les services ont démarré correctement.
        
        Pour vérifier qu'un service a bien démarré :
        
        journalctl --unit=reseau.service --all
        
        Pour déboguer :
        
        journalctl --unit=reseau.service --all --follow
        
        Les mêmes options, en version courte :
        
        journalctl -u reseau.service -a -f
        
        Si le lancement d'un service à la demande ne répond pas à ton besoin, tu peux lancer ce service automatiquement au boot :
        
        ln -s /usr/lib/systemd/system/machin.service /etc/systemd/system/multi-user.target.wants/
        
        Si le démarrage parallélisé des services ne répond pas à ton besoin, tu peux personnaliser les fichiers .service pour imposer un ordre de démarrage :
        
        $ cat /etc/systemd/system/truc.service.d/personnalisation.conf [Unit] # truc.service doit être lancé après machin.service : Requires=machin.service After=machin.service
        
        Il arrive que des points de montage NFS restent après l’arrêt du réseau
        
        Ah.
        Peut-être avec en personnalisant nfsd.service ?
        
        $ cat /etc/systemd/system/nfsd.service.d/personnalisation.conf [Unit] # nfsd.service doit être *lancé après* reseau.service, # et *stoppé avant* reseau.service : Requires=reseau.service After=reseau.service
        
        Au démarrage, reseau.service sera d'abord lancé, puis ensuite nfsd.service. Et à l'extinction, nous aurons l'ordre inverse : nfsd.service sera stoppé le premier, puis ensuite reseau.service sera stoppé (comme expliqué sur ce lien).
        
        [^] # Re: C’est du propre
        
        Posté par Arthur Accroc le 28 octobre 2013 à 07:04. Évalué à 9.
        
        Merci pour tes indications, je connaissais déjà (à part pour le coup du truc.service.d), mais j’espère que ça pourra servir à d’autres.
        
        Bref : que ce soit pour l'automontage, la gestion de l'énergie ou le format des logs, l'utilisateur a le choix.
        
        Je ne dis pas le contraire, mais je répondais à l’affirmation « on ne réinvente pas la roue ».
        
        Après, si Lennart réécrit une bonne partie des services pour qu’ils s’interfacent mieux avec systemd, pourquoi pas. Pour journald, c’est assez réussi, puisqu’il fait le boulot des syslogs traditionnels, mais permet en plus d’avoir des traces du tout début du démarrage.
        
        Le problème avec une partie des autres, c’est qu’il faudrait en finir un avant d’en ajouter d’autres. Un automount suffisant sauf si on en a vraiment besoin, une gestion de l’ACPI suffisante sauf si on en a vraiment besoin, c’est quand même dommage. Autant en faire moins, mais les faire jusqu’au bout.
        
        On me prend pour un anti-systemd primaire parce que j’ose émettre des critiques, mais ce n’est pas le cas. Quand systemd ou ses services associés peuvent faire le boulot, je les utilise de préférence, ne serait-ce que par souci de cohérence ou pour limiter le nombre de services en jeu.
        
        Après, quand Lennart prétend remplacer l’ACPI, sauf que pour avoir les fonctionnalités qu’on peut attendre de l’ACPI, on finit avec une double configuration, une pour désactiver l’utilisation de son service et une autre pour l’ancien, ce n’est pas une amélioration par rapport à l’ancienne situation.
        
        D’un côté, on a systemd qui remplace le système d’init en faisant aussi le café et la vaisselle, d’un autre, on a des services associés qui ne font que la moitié de leur boulot. Il ne sont pas à la hauteur.
        
        « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
        
        [^] # Re: C’est du propre
        
        Posté par Sylvain Blandel le 10 novembre 2013 à 02:42. Évalué à 1.
        
        si Lennart réécrit une bonne partie des services pour qu’ils s’interfacent mieux avec systemd, pourquoi pas. […] Le problème avec une partie des autres, c’est qu’il faudrait en finir un avant d’en ajouter d’autres. Un automount suffisant sauf si on en a vraiment besoin, une gestion de l’ACPI suffisante sauf si on en a vraiment besoin, c’est quand même dommage. Autant en faire moins, mais les faire jusqu’au bout. […]
        
        D’un côté, on a systemd qui remplace le système d’init en faisant aussi le café et la vaisselle, d’un autre, on a des services associés qui ne font que la moitié de leur boulot. Il ne sont pas à la hauteur.
        
        C'est nouveau, ça vient de sortir : systemd proposera prochainement systemd-networkd pour gérer le réseau (plus d'explications par ici).
        
        [^] # Re: C’est du propre
        
        Posté par Arthur Accroc le 28 octobre 2013 à 07:34. Évalué à 4.
        
        Peut-être avec en personnalisant nfsd.service ?
        
        Non, puisque là, on est sur les postes clients et qu’il n’est pas lancé.
        C’est autofs qui est lancé et il est bien stoppé au bon moment… sauf qu’il reste parfois des répertoires encore montés derrière.
        
        J’ai ajouté un appel à umount avant l’arrêt du réseau et ça marche… sauf quand il traîne des verrous sur des fichiers.
        Peut-être faut-il que j’utilise l’option KillUserProcesses dans logind.conf. C’est ce que j’avais essayé avant d’ajouter le umount (avec un résultat moins convaincant) et ça ne suffisait pas, mais je vais peut-être réessayer les deux en même temps.
        
        « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
        
        [^] # Re: C’est du propre
        
        Posté par ariasuni le 28 octobre 2013 à 09:55. Évalué à 2.
        
        Essaie ça. Ça manche pour SSH donc je pense que ça fonctionnera aussi pour les autres services dépendants du réseau.
        
        Écrit en Bépo selon l’orthographe de 1990
        
        [^] # Re: C’est du propre
        
        Posté par Sylvain Blandel le 28 octobre 2013 à 10:09. Évalué à 3.
        
        Non, puisque là, on est sur les postes clients et qu’il n’est pas lancé.
        C’est autofs qui est lancé et il est bien stoppé au bon moment… sauf qu’il reste parfois des répertoires encore montés derrière.
        
        Si systemd s'obstine à « patiner pendant un certain temps dessus », l'option TimeoutStopSec=, placée dans le service qui patine, diminuera l'attente (mais ne résoudra pas le problème).
        
        Le problème avec une partie des autres, c’est qu’il faudrait en finir un avant d’en ajouter d’autres. […] Autant en faire moins, mais les faire jusqu’au bout.
        
        Entièrement d'accord sur ce point. J'utilise systemd pour remplacer cron, mais pour la gestion de l'énergie, je préfère utiliser le service acpid plutôt que systemd. Systemd veut faire trop de trucs, il se propose même de remplacer la commande mount. Par exemple, si vous avez un point de montage /media/data dans votre fstab, on peut remplacer
        
        $ mount /media/data $ umount /media/data
        
        par
        
        $ systemctl start media-data.mount $ systemctl stop media-data.mount
        
        [^] # Re: C’est du propre
        
        Posté par ariasuni le 27 octobre 2013 à 15:26. Évalué à 7.
        
        systemd est encore jeune. Peut-être atteint-il maintenant un stade assez mature, mais pas depuis très longtemps.
        
        Bah écoute, à part une unité que j’ai dû modifier pour que la session ssh se coupe avant l’arrêt du réseau sur un serveur (voir le wiki d’Arch Linux), je n’ai jamais rien modifié et ça fonctionne au poil. Et vu son adoption en masse j’ai l’impression qu’il est déjà bien mature.
        
        Ben c’est-à-dire que quand un script d’init de quelques dizaines de lignes était pourri, je pouvais le déboguer moi-même.
        
        C’est le plus mauvais argument tout catégories confondues que j’ai entendu à propos de systemd. Si tu dois modifier le code du système d’initialisation c’est qu’il est mal foutu. Est-ce qu’on gueule parce que Linux n’est pas en Bash et qu’on peut pas le modifier facilement?
        
        Par contre, si tu dois modifier un fichier de configuration ou une unité c’est tout à fait acceptable vu que c’est fait pour ça.
        
        Sur mon portable sous Arch, avant systemd, je démarrais les quelques services dont dépendent vraiment les autres séquentiellement, puis quasiment tout en parallèle. Au début (quand systemd n’était que dans les contributions), systemd démarrait aussi rapidement, mais avec la multiplication des micro-unités et des fichiers de configuration, ça demande plus d’accès disques et c’est finalement plus lent.
        
        Chez moi et chez la plupart des gens c’est plus rapide. En plus je vois pas ce que ça fait qu’il y ai plusieurs fichiers, comme si l’init à la BSD ou SystemV c’était pas plusieurs fichiers. Donc je ne pense pas que ça soit ça; essaie de faire systemd-analyze blame ou systemd-analyze plot > graphe.svg, ça te donnera une idée de ce qui ralentit le démarrage.
        
        Avec le bémol que la distribution la plus populaire n’a pas adopté systemd.
        
        Ils n’adoptent pas Wayland alors qu’il fait consensus partout ailleurs.
        
        Il arrive que des points de montage NFS restent après l’arrêt du réseau (léger souci dans l’enchaînement quand même… et ça, c’est sous Fedora 19 avec un systemd récent, sur les versions plus anciennes, ce genre de problème était plus fréquent et bien plus long) et alors systemd patine pendant un certain temps dessus…
        
        J’ai eu le même genre de problème avec SSH (voir plus haut), mais c’est tout. Ce genre de cas devient de plus en plus rares.
        
        Écrit en Bépo selon l’orthographe de 1990
        
        [^] # Re: C’est du propre
        
        Posté par Arthur Accroc le 29 octobre 2013 à 01:43. Évalué à 4.
        
        Et vu son adoption en masse j’ai l’impression qu’il est déjà bien mature.
        
        Ubuntu aussi est utilisée en masse. Et pourtant upstart essaie de démarrer ypbind sans le réseau.
        Le fait que quelque chose soit utilisé en masse dans un contexte personnel ne garantit pas que ce soit prêt « à la sortie de la boîte » pour un environnement plus exigeant.
        
        Est-ce qu’on gueule parce que Linux n’est pas en Bash et qu’on peut pas le modifier facilement?
        
        Avant, je ne pouvais pas facilement corriger un bug dans Linux, mais facilement dans le système de démarrage.
        Maintenant, c’est aussi difficile pour le système de démarrage. De ce point de vue-là, c’est une régression.
        
        Par contre, si tu dois modifier un fichier de configuration ou une unité c’est tout à fait acceptable vu que c’est fait pour ça.
        
        Oui, et j’ai dû en modifier un ou deux, mais je suis justement tombé sur un cas où ça ne suffisait pas.
        
        Si tu dois modifier le code du système d’initialisation c’est qu’il est mal foutu.
        
        Ah ? Moi, j’avais seulement dit que systemd manquait de maturité…
        
        Chez moi et chez la plupart des gens c’est plus rapide.
        
        C’est parce que vous ne parallélisiez pas le démarrage avant.
        
        En plus je vois pas ce que ça fait qu’il y ai plusieurs fichiers, comme si l’init à la BSD ou SystemV c’était pas plusieurs fichiers.
        
        Le nombre de fichiers entre un init BSD et toutes les micro-unités de SystemD n’a rien à voir.
        
        Donc je ne pense pas que ça soit ça; essaie de faire systemd-analyze blame ou systemd-analyze plot > graphe.svg, ça te donnera une idée de ce qui ralentit le démarrage.
        
        Perte de temps, l’activité disque est à fond, c’est tout.
        Le truc qui remettait les deux systèmes de démarrage au même niveau (et dans le sens de l’amélioration pour les deux), c’est e4rat, mais les versions récentes foirent le système de fichier…
        De toute façon, je n’ai pas dit que c’est une catastrophe, juste que c’est moins rapide.
        
        « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
        
        [^] # Re: C’est du propre
        
        Posté par claudex le 29 octobre 2013 à 09:23. Évalué à 4.
        
        C’est parce que vous ne parallélisiez pas le démarrage avant.
        
        Je parallélisais le démarrage avant systemd et c'est quand même plus rapide avec systemd. C'est valable avec un système sur SSD, sans SSD, le temps de démarrage est sensiblement le même.
        
        « 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: C’est du propre
        
        Posté par Arthur Accroc le 29 octobre 2013 à 20:26. Évalué à 2.
        
        Je parallélisais le démarrage avant systemd et c'est quand même plus rapide avec systemd. C'est valable avec un système sur SSD, sans SSD, le temps de démarrage est sensiblement le même.
        
        J’ai un bête disque dur, et pas une flèche (un vieux portable au boulot et un portable perso bas de gamme), l’impact du nombre de fichiers et de leur dispersion sur le disque est donc bien plus important qu’avec un SSD.
        On perd avec ça ce qu’on gagne à paralléliser plus.
        
        « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
        
        [^] # Re: C’est du propre
        
        Posté par barmic le 31 octobre 2013 à 10:58. Évalué à 3.
        
        Il n'y a pas que la parallélisation qui accélère le boot, le fait de ne pas lancer 40 fois sed, grep, awk, test, etc joue pas mal aussi à mon avis.
        
        Si c'est vraiment l'accès disque qui te ralentis, je pense que c'est du au fait que systemd parallélise vraiment beaucoup ce qui stress plus le système. Tes têtes de lecture ne doivent plus savoir où donner de la tête…
        
        Peut être qu'en configurant ton noyau pour avoir un cache plus grand, il gagnerait beaucoup en performance (jben en avait parlé, il y a maintenant longtemps : https://linuxfr.org/news/supercopier-3#comment-1426182).
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: C’est du propre
        
        Posté par ariasuni le 29 octobre 2013 à 10:17. Évalué à 4.
        
        Ubuntu aussi est utilisée en masse. Et pourtant upstart essaie de démarrer ypbind sans le réseau.
        Le fait que quelque chose soit utilisé en masse dans un contexte personnel ne garantit pas que ce soit prêt « à la sortie de la boîte » pour un environnement plus exigeant.
        
        Bah systemd est utilisé dans plein de distributions différentes, orientée grand public ou utilisateur avancé, donc il y a potentiellement plus de chance qu'une équipe s'occupe du problème/de rapporter le problème.
        
        De plus c'est un projet en amont auquel tout le monde peut contribuer. Upstart est un projet Ubuntu qui nécessite d'accepter le Canonical contributor agreement. Je pense que ça aide.
        
        Et vu son adoption en masse j’ai l’impression qu’il est déjà bien mature.
        
        Avant, je ne pouvais pas facilement corriger un bug dans Linux, mais facilement dans le système de démarrage.
        Maintenant, c’est aussi difficile pour le système de démarrage. De ce point de vue-là, c’est une régression.
        
        Par contre, si tu dois modifier un fichier de configuration ou une unité c’est tout à fait acceptable vu que c’est fait pour ça.
        
        Oui, et j’ai dû en modifier un ou deux, mais je suis justement tombé sur un cas où ça ne suffisait pas.
        
        T'es sûr? Parce que ça ressemble vachement à un problème de dépendance entre service, et dans le pire des cas c'est possible de former le démarrage du réseau avant.
        
        C’est parce que vous ne parallélisiez pas le démarrage avant.
        
        Mais qu'est-ce que t'en sais? Avec Arch Linux je lançais tout en parallèle, à part dbus et KDM que je lançais séquentiellement à la fin (si je me souviens bien).
        
        Le truc qui remettait les deux systèmes de démarrage au même niveau (et dans le sens de l’amélioration pour les deux), c’est e4rat, mais les versions récentes foirent le système de fichier…
        
        Essaie ça alors.
        
        Écrit en Bépo selon l’orthographe de 1990
        
        [^] # Re: C’est du propre
        
        Posté par Arthur Accroc le 29 octobre 2013 à 20:19. Évalué à 2. Dernière modification le 29 octobre 2013 à 20:23.
        
        T'es sûr?
        
        Oui.
        J’avais affaire à ce bug avec des messages du style :
        Error: chdir(/home/auto/afsuser) failed: Too many levels of symbolic links
        
        La description du bug est très liée à l’utilisation de celui qui l’a soumise.
        En fait, pour le déclencher à tous les coups, il suffisait de mettre pour un répertoire en automount avec autofs un programme quelconque qui y accédait régulièrement, mais moins souvent que le délai avant démontage automatique.
        Au bout de quelques montages (quelquefois dès le premier montage, d’autre fois au bout d’un certain nombre), le bug se déclenchait et plus moyen de remonter le même répertoire au même endroit.
        
        Le bug a donné lieu à un correctif, qui a finalement été backporté pour la version de systemd de la Fedora 17… au moment de la sortie de la Fedora 18.
        
        Essaie ça alors.
        
        Merci de la suggestion. J’avais utilisé ça avant e4rat, mais je n’ai pas pensé du tout à le remettre après (en même temps, c’était inutile, donc je l’avais enlevé).
        Je gagne environ 5 s (contre 10 s pour e4rat… quand il marchait), c’est déjà ça. Ça doit me remettre à peu près à mon temps de démarrage sans systemd.
        
        « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
        
        [^] # Re: C’est du propre
        
        Posté par djano le 28 octobre 2013 à 11:38. Évalué à 4.
        
        unification des unit files (plutôt que d'avoir 36 variantes du script d'init pour un même logiciel, un par distrib'…)
        
        Avec le bémol que la distribution la plus populaire n’a pas adopté systemd.
        
        Tu es en train de sous entendre que c'est la faute a systemd. Trop gros passera pas.
        Ca fait quand meme beaucoup de simplifications sur toutes les autres distribs qui ont adoptees systemd ou meme a l'interieur d'une seule distrib.
        
        Ensuite, tes commentaires lies au fait que systemd marche pas sur fedora version x ou y dans tel cas ou tel autre, ca ressemble plus a se plaindre de l'implementation que de systemd lui-meme.
        Ca me fait penser a pulseaudio dont tout le monde se plaignait au debut, mais qui finalement semble se faire sa place petit a petit.
        
        Certes, c'est chiant, mais ca va se stabiliser.
        Enfin, j'ajouterais que se plaindre que Fedora n'est pas stable sur telle ou telle config me fait me poser la question sur ton choix de distrib. Peut etre devrait tu changer de distrib pour une plus stable?
        
        [^] # Re: C’est du propre
        
        Posté par Arthur Accroc le 29 octobre 2013 à 02:07. Évalué à 2.
        
        Tu es en train de sous entendre que c'est la faute a systemd.
        
        Non, du tout. Mais on tombe parfois sur un logiciel développé uniquement pour Ubuntu (tout comme il existe des logiciels libres développés uniquement pour Windows).
        Et là, le fait d’uniformiser plein de trucs entre les autres distributions n’empêchera pas qu’il faut adapter au moins une fois.
        
        Ensuite, tes commentaires lies au fait que systemd marche pas sur fedora version x ou y dans tel cas ou tel autre, ca ressemble plus a se plaindre de l'implementation que de systemd lui-meme.
        
        Oui, enfin rappel : systemd est le même partout. En l’occurrence, c’était une mauvaise version, mais pas une autre implémentation que systemd.
        
        Certes, c'est chiant, mais ca va se stabiliser.
        
        Enfin, j'ajouterais que se plaindre que Fedora n'est pas stable sur telle ou telle config me fait me poser la question sur ton choix de distrib.
        
        J’ai des utilisateurs qui veulent des versions très récentes de logiciels libres. D’autres qui veulent continuer d’utiliser des logiciels propriétaires datant de plusieurs années faute de payer les mises à jour, et même certains qui veulent les deux. Le tout en environnement client serveur.
        Pendant très longtemps, Fedora tenait très bien la route par rapport à de tels besoins (logiciels récents, bibliothèques de compatibilité pour les logiciels anciens, multilib, clairement prévue dès l’installateur pour être utilisée en environnement pro).
        Ça s’est un peu dégradé depuis quelques versions (avec la 17 qui est tombée très bas, mais ça a remonté depuis).
        
        Peut etre devrait tu changer de distrib pour une plus stable?
        
        Si je pars de CentOS ou Debian, il va falloir que je me tape la compilation d’une pelleté de trucs pour avoir des versions assez récentes (et encore, si ça veut bien compiler avec les bibliothèques qui son dessus). Donc bof…
        Sinon, que voyais-tu comme distrib plus stable ?
        
        « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
        
        [^] # Re: C’est du propre
        
        Posté par djano le 29 octobre 2013 à 08:35. Évalué à 2.
        
        Une distrib stable et a jour?
        Perso j'utilise Linux Mint, pour la stabilite ca va, mais je pense qu'il ne faut pas aller trop loin en terme de configuration ou de besoin avances.
        
        Peut etre que les autres lecteurs peuvent te conseiller d'autres distrib?
    - [^] # Re: C’est du propre
      
      Posté par Raphael R le 26 octobre 2013 à 19:01. Évalué à 1.
      
      Malheureusement, c'est le cas typique de bashing systemd avec une méconnaissance de l'objet "critiqué". Au moins avec systemd, ce dernier n'essaie pas de lancer ntpd avec des interfaces réseau qui n'ont pas encore initialisées, comme ça m'est arrivé dernièrement sur une distribution pourtant récente sous sysvinit. Une des raisons de l'existence de systemd c'est justement la gestion de dépendances de ce genre, et franchement, de ce point de vue la, ce n'est pas 30 ans d'histoire, mais plutôt vu comme 30 ans de retard.
      
      Dommage que ce dérapage trollesque gâche un peu l'interview intéressante surtout en tant qu'utilisateur de FreeBSD (certes moins que Linux maintenant).
      - [^] # Re: C’est du propre
        
        Posté par Loïc Blot (site web personnel) le 26 octobre 2013 à 19:37. Évalué à 4.
        
        Je pense que ta distribution n'a pas bien géré ses dépendances, que ce soit un BSD ou un Linux. Debian définit des prérequis dans son INIT, c'est également le cas pour FreeBSD
        
        Veepee & UNIX-Experience
      - [^] # Re: C’est du propre
        
        Posté par reno le 27 octobre 2013 à 09:41. Évalué à 1.
        
        Au moins avec systemd, ce dernier n'essaie pas de lancer ntpd avec des interfaces réseau qui n'ont pas encore initialisées,
        
        Ça m'étonne ce que tu dis: systemd "résout" les problèmes de dépendances locaux mais je ne vois pas trop comment il pourrait faire avec un serveur dhcp dans la boucle..
        
        [^] # Re: C’est du propre
        
        Posté par Arthur Accroc le 27 octobre 2013 à 10:18. Évalué à 3.
        
        Peut-être attendre que l’interface ait une adresse (je dis ça, mais je ne sais pas s’il le fait).
        
        « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
        
        [^] # Re: C’est du propre
        
        Posté par Arthur Accroc le 27 octobre 2013 à 10:32. Évalué à 4.
        
        J’ai jeté un coup d’œil, et je dirais qu’il doit gérer ça grâce à sa dépendance à network.target et au service NetworkManager-wait-online.service, défini « before network.target », et qui attend que Network Manager signale que c’est bon.
        
        « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
        
        [^] # Re: C’est du propre
        
        Posté par reno le 27 octobre 2013 à 15:23. Évalué à 3.
        
        Donc c'est une regle explicite de fonctionnement, ce qui n'est pas tellement différent des scripts de lancement en shell, si tu met la mauvaise regle ou si le shell teste le mauvais truc ça marche mal.
        
        [^] # Re: C’est du propre
        
        Posté par Arthur Accroc le 28 octobre 2013 à 08:01. Évalué à 2. Dernière modification le 28 octobre 2013 à 08:02.
        
        Je serais curieux de savoir quelle est la « distribution récente sous sysvinit » de Raphaël R qui n’a pas défini de dépendance au réseau pour ntpd.
        
        Le seul cas de ce style que j’ai vu, ce n’est pas une init System V mais upstart : la dernière Ubuntu LTS (pas regardé les autres versions) ne définit pas dé dépendance au réseau pour ypbind…
        
        Cela dit, les dernières versions de ntpd sont tolérantes au fait que le réseau ne soit pas connecté (il n’y a même pas à l’avertir de la disponibilité du réseau comme c’est le cas pour chrony ; je ne comprends pas que Fedora soit passé récemment à chrony par défaut), mais il faut peut-être quand même que l’interface réseau soit démarrée.
        
        « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
    - [^] # Re: C’est du propre
      
      Posté par C. OB (site web personnel) le 26 octobre 2013 à 20:59. Évalué à 2.
      
      A titre personnel , je trouve un intérêt dans systemd surtout en embarqué: De la même façon que busybox, le fait d'avoir un seul (gros) binaire qui gère tout permet des démarrages plus rapide (c'est très net en embarqué) lorsque la machine sous jacente est lente à lire le support de stockage, lente à forker, lente à changer de contexte…
      
      Sous OpenEmbedded par exemple c'est flagrant la différence de vitesse de boot sur une carte.
      
      Après sur un PC qu'on met en veille plus souvent qu'on reboot, bon…. J'admets que la complexité de systemd me fait parfois peur, quand je passe des heures à comprendre pkoi un process refuse obstinément de voir l'instance de d-bus, ou un autre truc tordu :-)
      - [^] # Re: C’est du propre
        
        Posté par claudex le 26 octobre 2013 à 21:45. Évalué à 5.
        
        Vu que systemd, ce n'est pas un seul binaire, je ne suis pas sûr que ça aide. Peut-être que le fait de ne pas avoir un lancer un shell pour chaque service permet d'y gagner un peu par contre.
        
        « 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: C’est du propre
        
        Posté par ariasuni le 26 octobre 2013 à 23:15. Évalué à 2.
        
        Je me demande si systemd optimisé pour l’embarqué peut aussi consommer moins de ressources. Par défaut il en prend un peu plus, mais j’ai l’impression qu’on peut plus facilement en enlever des bouts que d’autres systèmes d’init.
        
        Écrit en Bépo selon l’orthographe de 1990
    - [^] # Utiliser syslog avec systemd
      
      Posté par Sylvain Blandel le 27 octobre 2013 à 01:23. Évalué à 7.
      Fini les commandes tail -f /var/log/messages
      
      Oui et non.
      Les logs générés par journald sont des fichiers binaires ; pour autant, il est parfaitement possible d'utiliser syslog avec systemd. Voici comment faire :
      
      Installez syslog (chez moi, syslog-ng)
      
      Demandez le lancement automatique de syslog-ng au démarrage, avec la commande systemctl enable syslog-ng.service
      
      Pour que journald redirige les logs vers syslog, ajoutez l'option ForwardToSyslog=yes dans le fichier de configuration /etc/systemd/journald.conf (ce fichier de configuration est un fichier texte, comme tous ceux contenus dans le répertoire /etc/systemd/).
      
      Au démarrage suivant, le répertoire /var/log/ contiendra les fichiers habituels générés par syslog :
      
      daemon.log
      
      everything.log
      
      messages.log
      
      user.log
      
      errors.log
      
      auth.log
      
      kernel.log
      
      syslog.log
      
      Tous ces fichiers sont des fichiers texte. Je viens d'essayer un
      
      tail -f /var/log/messages.log
      
      et ça fonctionne : les nouveaux évènements du système s'affichent en temps réel.
      - [^] # Re: Utiliser syslog avec systemd
        
        Posté par Zenitram (site web personnel) le 27 octobre 2013 à 09:27. Évalué à -7. Dernière modification le 27 octobre 2013 à 09:28.
        
        pour autant, il est parfaitement possible d'utiliser syslog avec systemd (…) et ça fonctionne 
        
        Oui, mais la, tu demandes aux gens d'être objectifs (zut, si ils peuvent utiliser leur vieux truc lent et bouffeur de place juste pas activé par défaut car lent et bouffeur de place), ça empècherait de troller…
        
        [^] # Re: Utiliser syslog avec systemd
        
        Posté par flagos le 27 octobre 2013 à 10:48. Évalué à 1.
        
        Bon après, je peux comprendre qu'on regrette de ne pas avoir ce genre d'infos dans des fichiers textes.
        
        Je pense a quelqu'un qui administre sa machine ou son serveur et qui s'est scripte quelques grep pour debugguer plus rapidement sa machine, voir même couple avec cron pour être averti en cas de prob.
        
        Pour le coup, en tant qu'utilisateur, je trouve que c'est (ou plutôt c'était) un des vrais problèmes poses par systemd.
        
        [^] # Re: Utiliser syslog avec systemd
        
        Posté par claudex le 27 octobre 2013 à 11:01. Évalué à 7.
        
        Justement journalctl facilite l'écriture de tels scripts parce qu'il permet de filtrer plus simplement.
        
        « 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: Utiliser syslog avec systemd
        
        Posté par Enj0lras le 27 octobre 2013 à 11:39. Évalué à 3.
        
        Chez moi, journald facilite surtout l'utilisation de mon CPU. Ceci n'est pas un troll, j'observe très souvent journald qui prend 80% d'un de mes deux coeurs, sur un netbook c'est assez génant.
        
        [^] # Re: Utiliser syslog avec systemd
        
        Posté par xcomcmdr le 27 octobre 2013 à 13:30. Évalué à 0.
        
        Pas chez moi (ASUS X71SL), ni sur mon netbook (ASUS 1005 HA).
        
        Peut-être un service qui génère trop d'entrées dans le journal, en permanence ?
        
        "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
        
        [^] # Re: Utiliser syslog avec systemd
        
        Posté par Enj0lras le 27 octobre 2013 à 13:34. Évalué à 1.
        
        Que tu n'aies pas le problème ne rend pas le problème moins réel pour autant.
        
        Et je trouve assez incroyable que tu blames les daemons générant les logs quand un système de log scale mal. Syslog est parfaitement capable de traiter le volume de donnée.
        
        [^] # Re: Utiliser syslog avec systemd
        
        Posté par xcomcmdr le 27 octobre 2013 à 14:03. Évalué à 1.
        
        Que tu n'aies pas le problème ne rend pas le problème moins réel pour autant.
        
        Non, ça veut juste dire qu'il ne concerne que toi.
        
        Et je trouve assez incroyable que tu blames les daemons générant les logs quand un système de log scale mal. Syslog est parfaitement capable de traiter le volume de donnée.
        
        Pour ma part je trouve assez incroyable que tu blâmes journald alors que le problème vient de chez toi. Il "scale" bien ailleurs, notamment sur de multiples serveurs.
        
        Et je ne blâmais pas les daemons en général, mais un daemon supposément mal écrit.
        
        "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
        
        [^] # Re: Utiliser syslog avec systemd
        
        Posté par Zenitram (site web personnel) le 27 octobre 2013 à 14:37. Évalué à -10.
        
        Syslog est parfaitement capable de traiter le volume de donnée.
        
        syslog pose problème sur ma machine à moi --> syslog c'est de la grosse merde (logique tirée d'un commentaire d'Enj0lras).
        
        Il n'y a pas à dire, les anti-systemd ont toujours autant d'argumetation objective…
        
        [^] # Re: Utiliser syslog avec systemd
        
        Posté par Enj0lras le 27 octobre 2013 à 14:40. Évalué à 7.
        
        Merci de me rapeller pourquoi j'avais cessé de fréquenter linuxfr. Moi qui avais eu l'envie de recommencer à lire les commentaires, tu m'en fais passer l'envie à nouveau. J'économiserai du temps.
        
        [^] # Re: Utiliser syslog avec systemd
        
        Posté par hercule_savinien le 30 octobre 2013 à 17:50. Évalué à 5.
        
        Merci de me rapeller pourquoi j'avais cessé de fréquenter linuxfr. Moi qui avais eu l'envie de recommencer à lire les commentaires, tu m'en fais passer l'envie à nouveau. J'économiserai du temps.
        
        Zenitram est hautain et méprisant --> linuxfr c'est de la grosse merde (logique tirée d'un commentaire d'Enj0lras).
        
        Il n'y a pas à dire, les anti-linuxfr ont toujours autant d’argumentation objective…
        
        (Pardon aux familles, toussa. Allez fais pas la gueule et reviens ;))
        
        Le FN est un parti d'extrême droite
        
        [^] # Re: Utiliser syslog avec systemd
        
        Posté par Sylvain Blandel le 27 octobre 2013 à 13:43. Évalué à 6.
        
        j'observe très souvent journald qui prend 80% d'un de mes deux cœurs
        
        Même constatation chez moi. C'est parce que journalctl affiche tous les logs enregistrés, qui peuvent remonter à plusieurs mois. journalctl -b n'affiche que les logs du boot actuel, la consommation processeur est alors infiniment moindre.
        
        Il y a d'autres options pour afficher moins d'informations, et ainsi diminuer la consommation du processeur :
        
        $ journalctl --since=2013-09-27 --until=2013-09-30 $ journalctl --since=yesterday $ journalctl --since=-2h
        
        À noter que journald peut utiliser beaucoup d'espace disque (répertoire /var/log/journal et commande journalctl --disk-usage). On peut limiter cet espace disque en utilisant les bonnes options dans le fichier texte /etc/systemd/journald.conf. Chez moi, j'ai mis MaxRetentionSec=3week.
        
        [^] # Re: Utiliser syslog avec systemd
        
        Posté par Enj0lras le 27 octobre 2013 à 14:38. Évalué à 5.
        
        Je te remercie pour tes conseils. J'en ai déjà appliqués quelques uns, ce qui a rendu journalctl bien plus utilisable. Toutefois, les pics d'utilisation CPU que je remarque encore de manière épisodique (moins d'une fois par semaine en général) ont lieu dans journald lui même alors que je ne fais aucune requête utilisateur. C'est assez agacant d'entendre soudainement son ventilateur se mettre à souffler pendant une petite minute pendant que journald sature les accés disque et le cpu.
        
        [^] # Re: Utiliser syslog avec systemd
        
        Posté par claudex le 27 octobre 2013 à 14:49. Évalué à 5.
        
        Ce ne serait pas un archivage à la logrotate qui serait (mal) fait ?
        
        « 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: Utiliser syslog avec systemd
        
        Posté par Enj0lras le 27 octobre 2013 à 14:58. Évalué à 2.
        
        C'est très possible. J'ai la configuration par défaut pour SystemMaxFileSize cependant. J'ai suspecté la compression aussi, mais en la désactivant, le problème persiste.
        
        [^] # Re: Utiliser syslog avec systemd
        
        Posté par claudex le 27 octobre 2013 à 15:13. Évalué à 4.
        
        Il y a aussi MaxFileSec qui indique combien de temps le fichier doit être conservé avant une rotation.
        
        « 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: Utiliser syslog avec systemd
        
        Posté par Enj0lras le 27 octobre 2013 à 15:21. Évalué à 1.
        
        Je vais essayer ça, mais la doc semble dire que c'est pas la peine d'utiliser ça si on utilise déjà une limitation de taille.
        
        [^] # Re: Utiliser syslog avec systemd
        
        Posté par claudex le 27 octobre 2013 à 15:22. Évalué à 5.
        
        Ah oui, je ne parlais de le spécifier mais de vérifier que ça ne l'était pas déjà. Par contre, il faut peut-être spécifier une taille plus petite pour que la rotation se fasse plus souvent et consomme moins de ressource.
        
        « 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: Utiliser syslog avec systemd
        
        Posté par Enj0lras le 27 octobre 2013 à 16:09. Évalué à 2.
        
        Tu as sûrement raison. J'ai réduit la taille, je vais voir si ça joue dans les semaines qui vienne. Merci.
        
        [^] # Re: Utiliser syslog avec systemd
        
        Posté par Sylvain Blandel le 27 octobre 2013 à 16:42. Évalué à 0.
        
        les pics d'utilisation CPU […] ont lieu dans journald lui même alors que je ne fais aucune requête utilisateur. […] journald sature les accès disque et le cpu.
        
        Ah. J'avais mal compris.
        
        Si les modifications proposées par Xavier Claude ne fonctionnent pas, tu pourras diminuer la priorité de journald pour accéder aux ressources (je viens d'essayer chez moi, ça marche) :
        
        $ cat /etc/systemd/system/systemd-journald.service.d/personnalisation.conf [Service] Nice=15 IOSchedulingClass=idle
        
        Les paramètres Nice et IOSchedulingClass sont expliquées sur cette page.
        
        Peut-être faudra-t-il faire de même avec les unités systemd-journal-flush.service et systemd-journal-gatewayd.service ?
        
        [^] # Re: Utiliser syslog avec systemd
        
        Posté par claudex le 27 octobre 2013 à 17:51. Évalué à 4.
        
        Changer la priorité ne va pas tout du diminuer la charge, ça va juste permettre aux autres processus d'avoir plus de temps d'exécution mais au final, il aura toujours le problème des ventilateurs qui tourneront. À la limite, avec les cgroup, je crois qu'il y a moyen de limiter l'accès au processeur et aux disque mais ça devient un peu tordu.
        
        « 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: Utiliser syslog avec systemd
        
        Posté par Sylvain Blandel le 27 octobre 2013 à 19:00. Évalué à 1.
        
        Changer la priorité ne va pas tout du diminuer la charge, ça va juste permettre aux autres processus d'avoir plus de temps d'exécution mais au final, il aura toujours le problème des ventilateurs qui tourneront.
        
        C'est parfaitement exact, nous sommes d'accord. Le changement de priorité permettra juste d'éviter que
        
        journald sature les accès disque et le cpu
        
        Autrement dit, l'ordinateur restera utilisable, même lorsque journald fera des opérations lourdes.
        
        [^] # Re: Utiliser syslog avec systemd
        
        Posté par flagos le 28 octobre 2013 à 11:31. Évalué à -1.
        
        Je ne doute pas qu'on puisse faire la même chose avec journaltcl. C'est juste une considération de compatabilité avec l'existant.
        
        [^] # Re: Utiliser syslog avec systemd
        
        Posté par claudex le 28 octobre 2013 à 11:42. Évalué à 5.
        
        La compatibilité avec l'existant existe déjà puisqu'on peut demander à journald de tout envoyer à syslog.
        
        « 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: Utiliser syslog avec systemd
        
        Posté par flagos le 28 octobre 2013 à 14:29. Évalué à 2.
        
        Et c'est donc pour ca que cette précision initiale n'est pas inutile et que je répondais a la charge de Zenitram.
        
        Bref, tout ca se passe 50 messages plus haut, ca devient illisible les trolls a rallonge.
# nazisme

Posté par Krunch (site web personnel) le 26 octobre 2013 à 17:25. Évalué à 5.

Il manque une espace insécable avant le troisième et quatrième deux-points de la deuxième question.

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
- [^] # Re: nazisme
  
  Posté par Benoît Sibaud (site web personnel) le 27 octobre 2013 à 19:13. Évalué à 3.
  
  Corrigé, merci.
# Quand même

Posté par ariasuni le 26 octobre 2013 à 19:31. Évalué à 5.

On pourrait faire autre chose que troller sur cette dépêche, non mais oh! Bon.

Portage de drm2/gem/kms et des pilotes i915 puis radeon (voir respectivement ici, ici et là).

Ça doit être difficile de suivre les changements de Linux à ce niveau-là non? Surtout avec les différents systèmes qui ont l’air d’être très bas niveau. Quels sont les différences de performances avec Linux? Est-ce que Wayland tourne sous DragonFlyBSD grâce à ça?

Portage de LibreOffice. […] J'ai ainsi contribué à éliminer du code OS/2 et HP-UX que personne n'utilisait, supprimé des fonctions de gestion de quotas disque qui n'avaient rien à faire dans une suite bureautique, etc.

Ce «etc», ça représente beaucoup de code? Qu’est-ce que du code concernant les quotes disques fout dans une suite bureautique? Parce que j’ai du mal à voir comment ça pourrait être utilisé… (passé à la trappe dans mon premier commentaire visiblement)

Poudriere, l'outil de création de paquets en parallèle, stresse tellement le système d'exploitation et le matériel qu'on avait presque des kernel panics toutes les cinq minutes au début.

Tu aurais plus de détails sur ça? Je ne savais pas qu’on pouvait faire des kernel panic en poussant la machine à fond.

Écrit en Bépo selon l’orthographe de 1990
- [^] # Re: Quand même
  
  Posté par François Tigeot le 26 octobre 2013 à 21:23. Évalué à 10.
  
  Ça doit être difficile de suivre les changements de Linux à ce niveau-là non? Surtout avec les différents systèmes qui ont l’air d’être très bas niveau. Quels sont les différences de performances avec Linux? Est-ce que Wayland tourne sous DragonFlyBSD grâce à ça?
  
  Le gros problème c'est surtout que les piles drm non-Linux n'ont pas vraiment évolué depuis environ 10 ans. Je me trompe sans doute sur certains détails mais j'ai la désagréable impression qu'entre le moment où Eric Anholt est parti chez Intel et le réveil en catastrophe d'il y a un ou deux ans, personne ne s'est vraiment préoccupé des évolutions des drivers graphiques dans les noyaux *BSD.
  
  Je n'ai aucune idée des différences de performance avec Linux; je suis déjà content de pouvoir continuer à afficher des graphiques en 2D sous Xorg. Le pilote i915 est plus rapide que xf86-video-vesa et c'est déjà pas mal.
  
  A ma connaissance, nous n'avons pas encore ce qu'il faut pour faire tourner Wayland. De nombreuses mises à jour au niveau des logiciels utilisateur sont nécessaires, en particulier pour Mesa si je ne me trompes pas.
  Il y a une équipe dédiée qui s'occupe de cela chez FreeBSD et qui fait un très bon travail, mais le retard accumulé est de plusieurs années.
  
  Ce «etc», ça représente beaucoup de code? Qu’est-ce que du code concernant les quotes disques fout dans une suite bureautique? Parce que j’ai du mal à voir comment ça pourrait être utilisé… (passé à la trappe dans mon premier commentaire visiblement)
  
  Le code inutile voir purement délirant dans LibreOffice était énorme; le logiciel a été conçu au départ dans les années 1980 et les couches n'ont cessé de s'empiler. Du temps de StarOffice ou OpenOffice, le management du projet avait interdit toute tentative de nettoyage ou ré-écriture et la dette technique ne cessait de s'accumuler.
  Michael Meeks, le leader du projet LibreOffice, a donné de très bonne présentations à ce sujet lors des Fosdems 2011 et suivants, et qui doivent toujours être disponibles en vidéo.
  Le problème de la gestion de quotas venait apparemment de l'époque où StarOffice essayait de réinventer le bureau Windows 95 (avec menu démarrer, gestionnaire de fichiers, et tout le reste) dans la suite bureautique…
  
  Poudriere, l'outil de création de paquets en parallèle, stresse tellement le système d'exploitation et le matériel qu'on avait presque des kernel panics toutes les cinq minutes au début.
  
  Tu aurais plus de détails sur ça? Je ne savais pas qu’on pouvait faire des kernel panic en poussant la machine à fond.
  
  Afin d'aller le plus vite possible, Poudrière fonctionne par défaut en compilant un projet différent par coeur ou thread cpu disponible, le tout en parallèle.
  Ceci fait énormément travailler le système d'exploitation qui doit gérer des milliers d'événements et d'appels systèmes intervenants de manière aléatoire au même moment. Le moindre sous-système qui n'est pas parfaitement verrouillé peut être source de bugs aux conséquences catastrophiques.
  
  Bien que la version DragonFly de l'époque était capables d'obtenir sans problème des uptimes de plusieurs mois avec des charges de travail classique, faire tourner Poudrière a permis de découvrir des bugs qui n'avaient qu'une probabilité infinitésimale de se produire en temps normal.
  Pour prendre l'exemple le plus frappant, il y avait une race-condition dans le sous-système tty. Afficher du texte au mauvais moment dans un terminal virtuel ou un xterm pouvait faire planter le noyau. Cela faisait des années que les gens affichaient du texte dans des terminaux et n'avaient jamais eu de problème, mais il était impossible de faire tourner Poudrière plus d'un quart d'heure sans tomber sur ce bug et obtenir un kernel panic.
  - [^] # Re: Quand même
    
    Posté par ariasuni le 26 octobre 2013 à 23:58. Évalué à 2.
    
    Le problème de la gestion de quotas venait apparemment de l'époque où StarOffice essayait de réinventer le bureau Windows 95 (avec menu démarrer, gestionnaire de fichiers, et tout le reste) dans la suite bureautique…
    
    Hahaha… Non sérieux?
    
    Pour prendre l'exemple le plus frappant, il y avait une race-condition dans le sous-système tty. Afficher du texte au mauvais moment dans un terminal virtuel ou un xterm pouvait faire planter le noyau. Cela faisait des années que les gens affichaient du texte dans des terminaux et n'avaient jamais eu de problème, mais il était impossible de faire tourner Poudrière plus d'un quart d'heure sans tomber sur ce bug et obtenir un kernel panic.
    
    Faire planter le noyau en affichant du texte, GG quand même. C’est le genre de trucs qui me donne une (très) petit aperçu de la complexité d’un noyau…
    
    Écrit en Bépo selon l’orthographe de 1990
    - [^] # Re: Quand même
      
      Posté par neil le 27 octobre 2013 à 04:31. Évalué à 8.
      
      Faire planter le noyau en affichant du texte, GG quand même. C’est le genre de trucs qui me donne une (très) petit aperçu de la complexité d’un noyau…
      
      Et d’entendre Tanenbaum hurler : « Je vous l’avait bien dit ! »
    - [^] # Re: Quand même
      
      Posté par djano le 28 octobre 2013 à 11:57. Évalué à 2. Dernière modification le 28 octobre 2013 à 11:57.
      
      Faire planter le noyau en affichant du texte, GG quand même. C’est le genre de trucs qui me donne une (très) petit aperçu de la complexité d’un noyau…
      
      Boarf n'importe quelle application avec des algorithmes sophistiques en son sein peut planter de maniere aleatoire sous forte charge (certes les consequences sont moins grandes que pour un noyau).
      
      Vu que toute application a vocation a devenir un bloatware, ca arrive assez souvent. Je ne te parle meme pas des applications d'entreprise qui par definition sont des bloatware.
      - [^] # Re: Quand même
        
        Posté par riba le 30 octobre 2013 à 17:45. Évalué à 1.
        
        Je ne te parle meme pas des applications d'entreprise qui par definition sont des bloatware.
        
        mais bien sûr…
        
        [^] # Re: Quand même
        
        Posté par djano le 30 octobre 2013 à 17:55. Évalué à 4.
        
        Si tu as une experience differente, ne te gene pas pour la partager.
- [^] # Re: Quand même
  
  Posté par Bapt (site web personnel) le 26 octobre 2013 à 21:23. Évalué à 10.
  
  C'est assez simple, poudrière, load presque tous les sous-systèmes de ta machine:
  - La vfs,
  - La VM,
  - Le CPU,
  - même les tty :)
  - beaucoup plus,
  
  Du coup tu te retrouves avec un serveur stressé dans tous les sens de manière pratiquement impossible a avoir autrement. Ce qui faire apparaitre des bugs, des races conditions etc qui ne serait pas visible autrement.
  
  Sous FreeBSD par exemple, beaucoup de problèmes de contension de la VM ont été découvert, des problèmes de dead lock zfs, tmpfs, nullfs etc.
  
  Sous Dragonfly je n'ai plus les détails, mais beaucoup de bugs on aussi pu être découvert et corrigés.
  - [^] # Re: Quand même
    
    Posté par Enj0lras le 27 octobre 2013 à 11:37. Évalué à 6.
    
    À tel point que moi, je me sers de poudrière comme test de régression. Par exemple, j'ai du modifier le code de résolution des chemins de fichier. Après les tests basique, une exécution de poudrière : si ça survit plus de 15 minutes, ça veut dire que c'est déjà pas mal stable.
    
    Je sais que récemment Matt Dillon s'en est servi pour tester un peu HAMMER2, le nouveau système de fichier. Il s'en est servi aussi pour éliminer le plus de contention de verrous possible dans le noyau, voir ce mail pour ces que poudrière a permis d'identifier :
    - http://lists.dragonflybsd.org/pipermail/users/2013-October/090181.html
    - http://lists.dragonflybsd.org/pipermail/users/2013-October/090181.html
- [^] # Re: Quand même
  
  Posté par Jean-Sébastien Pédron (site web personnel) le 28 octobre 2013 à 15:23. Évalué à 8.
  Est-ce que Wayland tourne sous DragonFlyBSD grâce à ça?
  
  Concernant Wayland, Koop Mast (kwm@FreeBSD) a déjà un port disponible. Mais Wayland tout seul est inutile. Le plus gros morceau est Weston.
  
  Avoir le support de KMS est une étape indispensable pour faire marcher Weston. Mais il y a d'autres manques importants :
  - Weston dépend de udev pour, par exemple, obtenir des informations sur la carte graphique (son PCI ID, le nom du driver dans le noyau, etc.).
  - Weston dépend aussi de briques de Mesa (par exemple GBM) qui ne sont pas encore disponibles dans les ports, pour la même raison que le point précédent : udev.
  - Je ne suis pas sûr de moi (je n'ai pas étudié le problème) mais je crois que Weston utilise une API spécifique Linux pour manipuler les périphériques d'entrées (clavier, souris, etc.). Sous FreeBSD, nous avons un gros retard sur cette partie et l'ensemble n'est pas aussi souple que sous Linux.
  Koop Mast et Pierre-Emmanuel Pédron travaillent là-dessus. Mais ce n'est pas une priorité pour l'instant.
  - [^] # Re: Quand même
    
    Posté par Enj0lras le 28 octobre 2013 à 17:01. Évalué à 5.
    
    À noter que DragonFly inclu une implémentation d'udev. Cela dit, il manque des fonctions dans libdevattr (l'équivalent de libudev), et udev utilise sysfs sous linux pour nommer ou rechercher les devices. Il n'y a pas de sysfs dans dragonfly (sauf une vieille implémentation pour l'architecture i386).
    
    La question est de savoir s'il est plus simple de compléter cette implémentation de udev, ou de tout convertir dans wayland/mesa pour utiliser les mécanismes bsd.
- [^] # Re: Quand même
  
  Posté par hercule_savinien le 30 octobre 2013 à 18:01. Évalué à 8.
  
  Je trouve ça honteux que des BSD fanboy hijackent une news systemd avec leurs commentaires sur drangonfly.
  
  Merci de rester centrés sur le sujet.
  
  Namého.
  
  Le FN est un parti d'extrême droite
  - [^] # Déçu
    
    Posté par antistress (site web personnel) le 31 octobre 2013 à 01:20. Évalué à 6. Dernière modification le 31 octobre 2013 à 01:22.
    
    Bon, ayant été déconnecté depuis l'envoi en modération de cet entretien relatif à Dragon Fly, je découvre d'un bloc ses 94 commentaires dont 76 sur systemd (plus de 80%). Vous n'êtes pas raisonnables.
    Je ne pensais pas que cette partie de l'entretien serait prise au 1er degré et éclipserait le reste, c'est un peu démoralisant pour moi, alors imaginez pour notre invité.
    Voilà c'est dit, vous pouvez moinsser à présent.
    
    (PS : ce n'est pas un message contre le tien, hercule_savinien, qui au contraire souligne opportunément le problème dont je parle)
    - [^] # Re: Déçu
      
      Posté par ariasuni le 31 octobre 2013 à 10:20. Évalué à 5.
      
      C'est de ma faute, mais je pensais que ça prendrais une telle ampleur! M'enfin j'ai aussi poser des questions en rapport avec la dépêche pour contrebalancer.
      
      Écrit en Bépo selon l’orthographe de 1990
# Communication

Posté par MTux le 27 octobre 2013 à 09:30. Évalué à 9.

À mon sens, le projet souffre d'un gros manque de marketing et n'est par conséquent pas assez connu.

Pas faux, j'étais persuadé que DflyBSD était tombé aux oubliettes jusqu'à ce que je lise une dépêche sur Linuxfr annonçant la sortie en grandes pompes de la 3.2 (avec les performances Postresql). Sur le coup ça m'a donné envie de l'essayer.

Les interview de développeurs c'est très intéressant et ça fait de la com pour le projet.
- [^] # Re: Communication
  
  Posté par Enj0lras le 27 octobre 2013 à 15:00. Évalué à 7.
  
  J'ai essayé d'écrire une dépêche pour chaque nouvelle version récemment pour faire exactement ça. Ça me fait plaisir que ça ai fonctionné dans une certaine mesure. Le problème c'est que c'est toujours plus marrant de coder que de passer du temps à raconter ce que l'on code !
# Fond d'écran

Posté par Thom (site web personnel) le 27 octobre 2013 à 11:30. Évalué à 1.

Il y a un gestionnaire de fenêtre par défaut installé sur Dragonfly-BSD ?

La réalité, c'est ce qui continue d'exister quand on cesse d'y croire - Philip K. Dick
- [^] # Re: Fond d'écran
  
  Posté par François Tigeot le 27 octobre 2013 à 11:50. Évalué à 7.
  
  Il y a un gestionnaire de fenêtre par défaut installé sur Dragonfly-BSD ?
  
  Il y a deux sortes d'images d'installation, dont une avec un environnement graphique mais que je ne trouve pas conviviale du tout (un vieux fvwm avec clavier qwerty codé en dur).
  
  A mon humble avis, il vaut mieux utiliser une image non gui et ensuite installer le gestionnaire de fenêtre ou de bureau de son choix.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.

Aller plus loin

Portability to OSes: