Christophe Chailloleau-Leclerc a écrit 575 commentaires

Dans la même série, platine divx h&b dx 3220. Je l'ai. Allez voir sur http://www.platinesdivx.com(...) l'incroyable boulot qui a été fait par la communauté !!!
Nouveaux firmwares, mis à jour, corrigés, skinnables à volonté, interface série pour récupérer des platines mal flashées, ...
Attention, l'utilisation de toute ça est forcément d'une légalité non avérée...

Trop tard, il est déjà tombé plus haut ;)

Y'a pas un Godwin qui s'est perdu, quelque part dans ce thread ? Ami lecteur, je te laisse chercher...

Pour info (quand même), pour Canon, on trouve des drivers sur leur site japonais... Ca fonctionne plutôt bien. Je ne sais pas s'ils sont libres, mais il me semble qu'il y'a au moins une partie des sources...

Mes 2 centimes d'¤

Maintenant, plus qu'à supporter officiellement, à mettre sur le CD, ...

(tout est dans le titre)

Pour les animaux, tu mets quoi ?

---> []

Oui et non.

D'abord, il n'a jamais été question à la base d'essayer de configurer plusieurs applis différentes avec le même fichier. Et là, tu me parles d'applis différentes.

Ensuite, il y'a des paramètres communs, non ? Une connexion ADSL, c'est : un périphérique, un numéro à appeler (? j'en sais rien, j'aurais l'ADSL dans 10 ans :-(), un identifiant, un mot de passe, puis (automatiquement ou non) une adresse IP, un nom de domaine, des serveurs de nom, ... Ca, c'est commun à toute connexion ADSL. Et à toute connexion réseau, quasiment, d'ailleurs.
Alors :
.../net/connectionxxx.txt
device=
dial-number=
user=
password=
ip=
domain=
dns=
...

Après, la manière dont le système traite ces paramètres, ce n'est pas un problème !

Enfin, comme je l'ai dit, il faudrait "simplement" se mettre dans la mesure du possible "tous ensemble" et de faire une "tempête de cerveaux", afin de voir comment on pourrait essayer d'améliorer le bouzin, et de simplifier la vie de tous les jours de l'admin système comme de Luce et Henri, tout en conservant toute la souplesse et les possibilités actuelles...

Et surtout, il ne faut pas partir avec des à priori négatifs en ne cherchant que ce qui posera problème ! Trouvons des solutions !

Les différences de config hard sont déjà un problème pour l'administration d'un parc.
De même, les différences de notation pour un même périphérique d'un système à l'autre en est un.
A quoi bon en rajouter un avec des fichiers de config différents, en termes de FORME, encore une fois...

On peut éventuellement imaginer un fichier de config générique, et un fichier spécifique à chaque machine...

Fich 1:
commande_xxx=yyy %INTERFACE%

Fich 2:
INTERFACE=dsl0

Ou encore un système de filtres en import/export, pour gérer cela de manière automatique, en identifiant tout ce qui est dépendant de la machine ?

Enfin, là, je balance ça au pif, sans réfléchir.

Et je pense que le but d'un projet tel que celui là est d'essayer de réfléchir au meilleur moyen de gérer tout ça de manière cohérente...

Alors, réfléchissons, ensemble, objectivement, et pourquoi pas, pondons un standard (même si ce n'est pas celui que propose ce projet, si tu considères qu'il essaye d'imposer, peut-être sans qu'il y'ait eu une vraie réflexion de l'ensemble de la communauté) ?

Je ne te moinsserai pas.
Mais, voilà. Je REVE de pouvoir avoir un jour l'adsl. Si possible avec un très gros débit. Si si. J'habite à la cambrousse. Et je ne compte absolument pas faire de p2p ni toucher à des serveurs warez. J'ai eu 15 ans, mais c'est vieux déjà...
Pour quoi faire ?
- pour télécharger une distrib de temps en temps, et surtout les mises à jour
- pour échanger des fichiers (photos, vidéos, ... (LEGAUX !)) avec ma famille, mes amis
- pour pouvoir utiliser ma machine comme serveur web
- pour regarder la télé ! Le niveau de réception de la télé chez moi est proche de la probabilité d'avoir l'adsl dans les mois à venir...

Tu vas me dire : " pour faire ça, t'as pas besoin de 8Mb".
Et bien si. En plus de la télé, qui est déjà très gourmande.
Quand je d/l une iso, je n'aime pas attendre des heures. J'aimerai l'avoir dans les 10 minutes. C'est bête, mais c'est comme ça. Parceque quand je me décide à tester une distro, ou installer une nouvelle bécane, ..., c'est que j'ai le temps. Maintenant. Pas dans 4 heures.
Parceque avec les 8Mb, tu as 640kb d'upload. Et que c'est nécessaire, pour envoyer des trucs un peu gros (un film de vacances par exemple ?), ou pour avoir un serveur web qui tient un minimum la route...

Alors, voila. Je n'ai pas besoin de 8Mb en permanence, c'est sur. Mais même si les 8Mb me servent 1h par mois, je trouverais que c'est rentable. Je paye 25¤/mois actuellement pour avoir du RTC illimité... Je suis prêt à allonger de 5¤ !

Mais voilà, je n'ai que 56k.

Je ne prétends pas qu'un grande partie des utilisateurs ne profite pas de ces accès pour d/l des tas de choses toutes plus illégales les unes que les autres, mais ce n'est définitivement pas une obligation...

PS : Je n'utilise depuis des années aucun logiciel ni piraté, ni sans licence. Pourtant, j'ai au boulot un accès au moins équivalent à n'importe quel ADSL, et la possibilité de d/l à peu près ce que je veux (hors p2p) sans aucun risque. Je tenais à le préciser...

C'est sûr. Tout se développe.
Mais quand je veux faire une adition, plutôt que d'écrire un programme en assembleur, je cliques sur l'icône "Calculatrice". C'est con, hein ?

(Oui, enfin, pour l'adition, j'peux même me débrouiller de tête).

Là, on te propose du clé en main, universel.

#! /bin/bash

DISTRIB=uname -jesaispasquoi | grep toto | awk xxx | sed zzz | ...

case $DISTRIB:

  Mandrake)) 

    cat /etc/machin/truc/bidule | grep toto |... > ftemp1

    cat /etc/machin2/truc/biduleX | ... > ftemp2

    cat ftemp1 ftemp2 > MonJoliFichierExport.txt

    ;;

  Redhat))

     blabla

     blabla

    ;;

  ..

  ..

  Unenouvelledistribquejeconnaispasencore))

     Euh ?? Ben je fais quoi ??

   ;;

esac

-- Total : 2450 lignes. Peu fiable (est-ce que le script prend en compte toutes les syntaxes possibles de chaque fichier, ou a la moindre modif, perd-il les pédales ?). Inmaintenable. Gros boulot en cas de changement de format d'un fichier par exemple...

vs

# config -export bidule > MonJoliFichierExport.txt

-- Total : 0 lignes. Maintenable. Jamais de changements de format de fichier.

Choisis ton camp.

PS : Oui, je sais, j'ai mélangé la syntaxe de tous les shells existants...

Bon, allez, juste deux trois points puis on va en rester là (en fait, je pense qu'au fond on doit être à peu près d'accord...)

- le problème principal que tu évoques (et c'en est un), c'est que l'utilisateur lambda est souvent administrateur. Ca, c'est un problème, et ça le restera tant qu'on y fera rien. Après, le format des fichiers de conf, du moment qu'il les bidouille alors qu'il ne devrait pas... (D'ailleurs, mais je ne veux pas relancer, il est plus facile pour lui de planter la bécane en essayant d'éditer un fichier avec un formatage complexe comme un fstab par exemple, une erreur de colonne va plus vite qu'un fstype=ext3 remplacé par fstype=/dev/hdxx).
Bref, la gestion des droits, surtout en entreprise, c'est vraiment un problème, quelque soit le système de configuration / administration sous-jacent.
Pour l'utilisateur lambda chez lui, si tu prends le cas d'une mandrake par exemple, par défaut, on ne peut pas se connecter en root (en mode graphique, hein, utilisateur lambda). Ca limite déjà les risques. Certes, ça n'empêche pas le su, mais... En même temps, on ne pourra jamais protéger totalement l'utilisateur contre lui-même. Tout ce qu'on peut faire, c'est le prévenir, l'avertir en long en large et en travers. On ne pourra jamais l'empêcher de faire dd if=/dev/null of=/dev/hdxx en root...

- Je suis POUR la doc. A fond. Des kilomètres. Mais encore une fois, une doc de conf serait tellement plus efficace si elle décrivait seulement les paramètres, les options, et pas des formats de fichiers... Toujours la distinction entre le fond et la forme. La doc est totalement indispensable !

- Pour la remontée d'erreurs / changement de disques... Je ne sais pas. De toutes façons, nos métiers vont évoluer. On trouvera bien autre chose à faire... Au pire, on passera nos journées à venir troller sur linuxfr ;)
Mais c'est vrai, si l'informatique évolue "dans le bon sens", fiabilité, robustesse, elle pourrait presque finir par tuer l'informaticien... Une informatique autonome, qui se répare toute seule, ... C'est des projets vieux comme le monde (enfin presque), et qui est remise au goût du jour. L'informatique sans informaticiens. Enfin, il restera toujours du boulot dans le domaine applicatif, les nouvelles plateformes, et tout ce qu'on imagine pas mais qui sera là dans quelques années... C'est difficile de prédire l'avenir dans le domaine informatique, alors, y'a qu'a attendre de voir (ou agir si on a des idées !). Et puis, entre l'idée de mettre en place une conf uniforme et la suppression des admins, y'a encore du chemin à faire ! Une petite 20aine d'années au moins sans doute...
Et puis après, on ira s'occuper de nos patates ou de nos tomates en attendant le crash disque, et puis on ira tranquillement le changer avant de ramasser les salades :)

RTFM !!!

As-tu lu l'article ? les liens ? les commentaires ?!

Pour la xxxème fois, il ne s'agit en aucun cas d'une "base de registre" type win, odm, ...
Il s'agit, comme tu le suggères si bien, d'une normalisation des fichiers de conf...

M'en vais me saoûler la gueule, moi, y'en a marre de répéter les mêmes choses, tiens... ---- hips --->[]

Je rajouterais que quand ton serveur à des problèmes, Windows ou Un*x, de toutes façons, tu n'as pas forcément encore une "simple" connection ADSL qui fonctionne... Surtout pour des problèmes de conf réseau...

>petit bémol (d'ou mon coup de gueule), meme si Luce et Henri sont >capable de configurer un réseau, je ne les vois pas remonter une >machine dans l'urgence avec /bin/sh et vi comme seul ami... Les >outils pour aider à la configuration, c'est bien. En abuser ca craint !

D'accord avec ça. Mais... C'est quand même un cas extrême, qui dans un système propre et fiable ne devrait pour ainsi dire jamais arriver. Tu connais beaucoupe de *simples* utilisateurs de linux, qui travaillent sous un compte non-root qui se retrouvent dans cette situation ?
Si oui, alors linux a encore du chemin a faire sur le plan de la fiabilité...

>La force >d' *n?x réside justement dans le fait (selon moi) que >pour faire fonctionner le systeme/soft, il faut le comprendre (en >partie).
>D'ou l'avantage de la doc et de la lire !

Bof... Pour moi, la force d'un*x réside dans sa robustesse, sa fiabilité, ses performances, son respect des standards, ...
Si on veut que linux soit "prêt pour le desktop" (c'est pas le moment de lancer des trolls, hein !), il faut qu'on puisse l'utiliser "normalement" sans justement savoir comment il fonctionne. C'est comme ça que l'informatique est devenue grand public...

Je parle du cas Luce et Henri, pas de l'administration de serveurs en entreprise.

>quand tu n'as que /bin/sh et vi qui daignent fonctionner, il vaut >mieux que ca soit au format texte... ou avec des outils 'vraiement >simplistes' odmget odmchange... c'est pas super :(

Toujours pareil, on parle de cas extrêmes, réservés aux bidouilleurs, ou aux machines à utilisation avancée (serveurs, ...). Pas au PC de monsieur tout le monde. Normalement.

ET ENCORE ET TOUJOURS (SNIF, J'ESPERAIS NE PLUS AVOIR A LE DIRE), LE SYSTEME PROPOSE EST ENTIEREMENT BASE SUR DES FICHIERS TEXTES ! ROGNTUDJU ! DANS QUELLE LANGUE FAUT-IL LE DIRE ?! Le passage où xml est cité est pour faire de l'import-export. Ce qui est très judicieux, puisque l'aspect hiérarchique d'xml permet de récupérer la structure hiérarchique des répertoires contenant ces fichiers textes (type .ini, je le répète pour ceux qui n'écoutent pas au fond près du radiateur).

>et quand tu dois maintenir un oracle 7 sur un 'vieil' AIX 4.2.1 ... tu >es bien content de connaitre les 'anciens' trucs.

Je me plaçait dans le contexte de l'évolution future de l'informatique... C'est sûr que pour ce qui est ancien, il faudra continuer à le faire vivre tel quel jusqu'à ce que l'on en ait plus l'usage...
Si on arrive à standardiser les configurations, dans 10 ans, lors des évolutions logicielles, on évitera justement ce genre de problèmes, puisque toutes les applications se configurerons toujours de la même manière...

>Pour résumer ma pensée, je suis contre la création de tels outils >sous Linux car ils simplifient trop la vie du n00b ! :( désolé ! mais >pour moi, si un jour Linux doit etre 'user friendly', c'est parce que >l'utilisateur sera devenu 'Linux friend' et non pas parce que Linux >se sera rabaissé à la non connaissance de l'utilisateur. Utilisateur >qui sous pretexte qu'il a réussit à mettre en place son >systeme/soft tout seul , pense à tord qu'il connait tout sur tout et >que si sa plante, c'est parce Linux sa sux :(

C'est un avis personnel. Et discutable. Tout d'abord, cela simplifie aussi la vie de l'administrateur système expérimenté. Et si tu pense que Linuxcébienparcekecécompliké, c'est ton opinion, pas la mienne. Comme je l'ai dis, pour moi, Linux (devrais-je dire GNU/Linux ? ;)), c'est bien parceque c'est puissant, robuste, fiable, rapide, et plein d'autres qualificatifs... Et puis aussi, parceque c'est libre, "accessoirement".
Et si c'est simple à configurer, tant mieux. Cela facilitera le déploiement, l'augmentation de parts de marché, l'installation chez M. ToutLeMonde, ou chez ses voisins, Luce et Henri...

Je crois que tu confond complexité et puissance / robustesse / fiabilité. On peut faire simple et fiable et robuste et ...

Un utilisateur qui à réussi à mettre en place son système / soft tout seul ? GENIAL ! 2 heures de moins à passer à l'aider à le faire ! 2 heures que l'on pourra consacrer au développement de nouvelles applications, ou à tout autre activité ! Et si en croyant tout connaître , il a configuré n'importe comment, mais que les fichiers de config sont simples et claires, tu mettras d'autant moins de temps à trouver l'erreur et lui corriger son problème... Ceci étant dit, en entreprise, je ne pense pas que le monsieur devrait avoir accès aux fichiers de conf... Par contre, pouvoir propager toute une partie de la conf sur l'ensemble du parc (même avec des distribs différentes !) par un export-import de fichier, ça... Quel admin n'en rêve pas ?!

Enfin, dans un système censé être fiable, si ça plante, oui, sa "sux". Sinon, ça t'avertit que tu n'as pas configuré correctement...

Bonne journée.

Ils demandent ça <--->. Bon, on leur donne ça <->. Mais le pire, c'est qu'ils le prennent !

Merci M'sieur Coluche.

Désolé, j'ai des problèmes avec mon cla

Bêtement, je te proposerai d'étudier le format des fichiers OOo...
C'est bien documenté sur le site, dans mes souvenirs, et pour info, c'est du XML zippé (unzip toto.sxc, regarde le résultat). J'avais fait des essais et en générant un fichier simplifié (même par rapport à un fichier minimalise d'OOo), ça allait.
Il doit bien y'avoir un module de php pour faire du zip ?
Sinon (je ne sais pas si tu es sur un serveur web ou sur une bécane perso), tu peux écrire des progs qui communiquent avec OOo...
Précises un peu ton besoin (site web avec php/mysql, machine perso avec tout ce qu'on veut, machine pro avec peut de choses dispo, compétences en dev php, c, c++, ...)

UNE SOLUTION : TU DEMONTES TON CLAVIER ET TU SHUNTE LA TOUCHE ? :)

A part ça, qu'est-ce que tu deviens depuis l'iut ?

>Besoin différent == souvent façon de faire différent.

>Si, samba sous Red Hat se configure de la même façon que samba sous Debian …

Je ne dis pas. Besoin différents = applis différentes, algos différents,languages différents…

Donc paramètres différents.

Soit.

Mais pourquoi donc ne serait-il pas possible que ces différents paramètres soient exprimés de la même manière ???

Pourquoi parle-tu la même langue que moi ? Nous n'avons pas les mêmes besoins, ni visiblement les mêmes algorithmes (;)). Et pourtant, nous avons besoin de nous comprendre, de nous "interfacer", d'être un minimum compatibles, interopérables. Nous parlons donc la même langue.

Rien n'empêche une discussion entre un ornithologue et un informaticien. Chacun utilisera dans ce cas un sous-ensemble commun du langage. Ils ont un vocabulaire très différents, mais dans une même langue. Ils se comprennent.

C'est sûr, tu vas me dire, il y'a d'autres langues. Et c'est tant mieux, pour des raisons culturelles, ou autres. Mais il en résulte quand même de nombreuses incompréhensions, des incompatibilités (pas seulement d'humeur), des traductions aberrantes, …

Je ne suis pas pour une uniformisation de tout (une seule appli pour faire ceci, une seule pour faire cela, une seule langue, …). Chacun est libre de choisir l'outil qui lui convient le mieux pour réaliser ce qu'il veut.

Mais pour moi, la configuration (du moins le mode de stockage de la configuration) devient quelque chose d'annexe, de plus en plus caché. Ce n'est plus un outil, c'est une sous-couche. Et la notion de préférences devient alors moins importante. Pourquoi vouloir avoir un format particulier, spécifique, pour des fichiers que de toutes façons presque personne ne modifiera plus ? (je m'avance un peu, mais c'est bien à ça que tend l'informatique… d'ici quelques années, les systèmes pourraient même presque entièrement s'auto-administrer…). Alors pourquoi refuser de permettre à ces futurs systèmes d'avoir des bases fiables, communes, standards sur lesquels ils pourront travailler proprement, rapidement, de manière souple et performante ?!

En informatique, la notion de standard est fondamentale, et malheureusement souvent trop tardive… Te rappelles-tu les menus de paramètrage des cartes sons et vidéos dans les jeux sous DOS, autrefois ? 200 cartes sons, 200 modes de configurations différents. Et souvent des heures pour que ça marche.

Idem pour les cartes vidéos. Alors on a inventé VESA. VESA ne permet pas tout. Il ne permet pas d'exploiter les spécificités de telle ou telle carte. Mais un logiciel gérant VESA pourra tourner sur 99,99% des cartes du marché, avec un seul pilote !!!

Une autre analogie peut-être plus intéressante. Je pense que tu es capable de voir des différence entre mozilla, konqueror, netscape, ie…

Pourtant, ils utilisent tous les mêmes "fichiers de configuration d'affichage" !

Et les dysfonctionnements constatés de l'un à l'autre sont dûs au fait qu'ils ne respectent pas entièrement ces standards, que certains ont voulu imposer leurs propres "fichiers de configuration" !

Et avec le même FORMAT de fichiers, n'y a-t-il pas des différences entre http://www.kernel.org et http://www.oiseau-libre.net/Animaux/Animaux%20sauvages/Putois.html (site choisi au hasard, je n'ai pas d'actions, j'ai juste cherché un sujet un rien différent, pour essayer de faire taire ce vilain différend…) (NdM: lien corrigé)

Un même format, un contenu différent, un outil différent, et tout le monde se comprend ! (-ra si on tient compte du non respect actuel des standards…)

Je vais m'arrêter là, j'ai mal aux doigts…

Ok, on y va calmement...

Le métier n'est pas de connaître le format des fichiers, c'est de savoir comme fonctionne une bécane, comment configurer des protocoles, des logiciels pour qu'ils fonctionnent et répondent à un besoin.

Ce qui importe, c'est le FOND, pas la forme. Plus la forme est simplifiée, plus on peut se concentrer sur le fond...
AIX s'administre à la souris. ENTIEREMENT, si on le veut. Et pourtant, on ne s'improvise pas administrateur AIX.

Et puis, quand bien même ? N'importe qui est capable d'administrer un système (on en est loin, je le rappelle) ? Qu'importe. Il faut EVOLUER. Les métiers changent, surtout dans l'informatique ! Au fur et à mesure que les tâches se simplifient, que la technique avance, les métiers se transforment. Connais tu beaucoup de pupitreurs ? Pourtant, ils étaient des milliers il n'y a pas si longtemps ! Il y'a 20 ans, personne n'aurait imaginé que n'importe quel péquin pourrait en 3 clics configurer un partage sur un réseau local d'un accès internet haut-débit. Pourtant, c'est le cas. Même Luce et Henri en sont capables !

Avant, on développait en assembleur. Maintenant, n'importe qui peut faire une petite appli en 3 clics de souris. Et alors ? N'importe qui est-il capable pour autant d'écrire un ERP ?

Rester à jour, ok. C'est à dire suivre les NOUVELLES technologies, pas se faire ch... à apprendre 247 façons de faire la même chose (ancienne en plus, hein !) sur 247 systèmes différents !!!

Je connais l'importance de la doc. Et encore une fois, ce qui importe dans la doc, c'est le FOND, pas la forme. Si les 40 pages décrivant le fond et la forme se résument en 20 pages sur le fond, la forme étand standardisée, universelle, combien de temps de gagné ? (à l'écriture du soft, de la doc, à la lecture de la doc, la configuration du soft...)

ET POUR LA DERNIERE FOIS DANS CE THREAD, J'ESPERE : IL N'A JAMAIS ETE QUESTION D'XML !!! On parle de texte brut, sous la forme clé=valeur, de fichiers ini, pour être clair.

D'ailleurs, si ta doc est dans un format donné, c'est que tu es censé avoir l'outil pour la consulter, mais bon... (et la plupart des softs ont une option "rechercher", qui peut éventuellement remplacer un grep...)

Allez, pour finir [mode humour]Un chef, non seulement ça n'envoie pas de doc, mais si ça en reçoit, ça ne la lit pas... Et si jamais dans un excès de bonne volonté, ça la lit... ça ne la comprend pas[/mode humour].

PS : Désolé d'avoir mis des "pseudo-balises". C'est presque du xml, ça. Je vais me flageller avec des ronces et des orties.

Bon, un peu confus tout ça, mais bon, j'espère que ça reste à peu près compréhensible...

>Quel intérêts d'avoir des réseaux hétérogènes si tout est unifié ?

Parceque pour toi, si la configuration / administration est unifiée, tout est unifié ?
Il n'y a pas de plateformes différentes ? La compatibilité binaire existe entre tous les sytèmes ? Il n'y a aucun logiciel qui ne soit supporté que par certaines plateformes, donc qui oblige une entreprise à posséder cette plateforme, mais qui ne lui convient pas pour d'autres usages ?

>Quel intérêts d'avoir des distribs différentes si tout est unifié ?
Même réponse.
+ Toutes les distribs packagent-elles les mêmes softs ? Ont-elles le même but ? (desktop, serveur, rescue, livecd, ...) ? Et j'en passe, je n'ai pas envie de m'étendre sur le sujet... Enfin, l'uniformité de configuration n'implique pas une similitude pour le reste...

> C'est clair que mettre des fichiers XML à la place d'un simple fichier de type .ini (samba par exemple) c'est plus propre ... :)

Je n'ai pas lu les docs sur le site, mais rien que d'après les commentaires, il ne semble pas que quiconque ait évoqué le XML ?!!!
Des fichiers textes avec des ensembles clé=valeur, si ce n'est pas ce que tu appelles des fichiers .ini ?!

/me send gros bisous to Fabien ! (en tout bien tout honneur, hein) ;)

Peut-être pour rendre humain la tâche d'administrer des réseaux hétérogènes ?
Pour ne pas devoir tout réapprendre pour chaque nouvelle distrib ?
Pour ne pas devoir systématiquement avoir 40 pages de docs par format de fichier et d'être obligé de consulter les formats à chaque modif ou presque pour ne pas foirer le système ?
Parceque c'est plus propre ?
Entre autres...

D'accord avec toi si l'existant est nickel (je ne sais pas, donc je ne m'avance pas...). N'ayant pas lu les liens, je ne sais pas si cette possibilité à été envisagée, voire si ce n'est pas plus ou moins ce qu'ils font ?

Suse : je ne sais pas ce qu'ils en ont fait, je n'ai pas eu l'occasion d'en utiliser depuis longtemps... J'avais beaucoup aimé effectivement les outils d'admin quand j'en avait acheté une il y'a... si longtemps ! (une 5.3 je crois).

Tu l'as dit, il s'agit d'unifier le tout entre les distribs ! D'où l'intérêt ! CQFD !