J'utilisant Linux depuis approximativement 2 ans. J'insiste sur ce point car il me semble que cela n'est pas encore beaucoup, et cela expliquera peut être ma réflexion simpliste. De plus je ne voudrais pas passer aux yeux de mon journal favori comme un réveur, révolutionnaire et fanatique, alors si c'est une erreur, mettez ça sur le compte de la jeunesse.
En utilisant et en apprenant linux, petit a petit, en passant en revue au cours de mon apprentissage différents pans (ex :serveur apache, montage des disques, compilations, traduction, compilation du noyau, utilisation des cartes pcmcia, carte son, sudo, firewall...)
bref des truc très variés...,
je me suis rendu compte qu'a chaque fois que j'apprenais a me servir d'un truc, il fallait quasiment repartir a zéro. Cela surtout par le simple fait que tout est trop variés au niveau de la configuration et de l'utilisation.
Un exemple simple serait les fichiers de configurations, qui n'ont absolument pas, et jamais la même syntaxe. Alors oui, c'est normal que shorewall et apache n'est pas les mêmes fichiers de conf, mais quand même, n'y aurait il pas moyen d'unifier cela un peu plus?
Tout le monde connait XML, et ne serait ce pas un mal d'appliquer cela a toutes les couches d'outils de linux, pour un peu plus d'unifications??
Un autre exemple serait le fichier fstab, lui aussi dans son monde question logique de configuration. sudo est un autre exemple, et j'en passe... Un truc aussi qui m'a surpris est la traduction, qui utilise des *.po, des *.mo et des *.gmo, encore une fois dans une logique des plus étranges (et l'arborescence de ces fichiers l'est plus encore).
Un dernier exemple qui me sidère sont les logiciels d'autoconf, qui se révèlent être un beau boxon si on veut initier un projet dessus. Et le fait d'utiliser autant de macros m4, complètement incompréhensibles, font vraiment peur. (cela ne limiterait pas par hasard le fait de développer un outil graphique de compilation?)
Bref, tout cela est vraiment compliqué, et trop éparpillé, ce qui fait que l'on a souvent l'impression de réapprendre la roue quand on passe d'un secteur à l'autre de linux (entendez linux au niveau distribution), et c'est parfois pénible de se dire, qu'il va falloir encore chercher de la doc sur internet pour savoir configurer un jabber, le son ou un serveur ftp.
Voila, j'espère que vous m'avez compris, et dites moi si vous pensez qu'il serait un jour (pas nous), possible d'améliorer ce shmilblick
PS: L'argument du logiciel libre qui se développe sous forme d'un chaos n'est pas accepté ici, car il y a surement moyen d'unifier tout autour d'une norme maintenant non (xml?)?
# Re: Remplacer les outils de base de Linux
Posté par Ano nyme (site web personnel) . Évalué à 3.
[^] # Re: Remplacer les outils de base de Linux
Posté par Nicolas Ternisien (site web personnel) . Évalué à -1.
Forum Software Reviews: Comparez et testez les logiciels de forums Internet!
[^] # Re: Remplacer les outils de base de Linux
Posté par Yhar Gla . Évalué à 2.
Pour un fichier de conf qui sera le plus souvent édité par vi (ou emacs), je trouve ceci:
option1=valeur1
option2=valeur2
beaucoup plus clair et intuitif que:
<config>
<option name="1" value="valeur1" />
<option name="2" value="valeur2">
</config>
Le 2eme exemple pique les yeux et tient sur 2 fois plus de lignes.
Ce serait plus agréable avec une coloration syntaxique éventuellement, mais je préfère néanmoins du texte brut.
J'ajouterais que la lisibilité du fichier de config n'est pas le plus important, qu'il soit en texte bizarre ou en xml, il faudra de toute façon apprendre le fonctionnement du logiciel en question et lire des docs. Toucher à la config ça vient bien après, au moment ou normalement on a pigé comment ça fonctionne.
Autre argument pour le format texte aproprié à l'appli, en bash par exemple il est plus simple (et probablement plus rapide) de sourcer un fichier de config comme ceci:
. ~/.config_file
que de récupérer un fichier xml et de le parser (je ne sais meme pas si des outils existent pour faire cela en shell :) Alors à moins de faire en sorte que bash comprenne le xml en natif :
<shell-script>
<if arg="$1" op="equal" value="12">
<echo>
Ah ben oui c'est bien 12!
</echo>
</if>
<if arg="$1" op="not_equal" value="12">
<echo>
Ah ben non, perdu!
</echo>
</if>
</shell-script>
Voilà j'ai lancé le XPL (xml programming language :)
[^] # Re: Remplacer les outils de base de Linux
Posté par Pinaraf . Évalué à 0.
LE XPL !!!!
Vite faut commencer une implémentation.
Non sans déc ça pourrait être bien, en plus avec ça avoir un IDE simple et clair ne devrait pas être difficile...
[^] # Re: Remplacer les outils de base de Linux
Posté par Yhar Gla . Évalué à 0.
Le XPL est (r) (c) (tm) Yhargla 2004 - 2999
La licence d'utilisation est au tag : 1 / tag écrit
On peut acheter une licence illimitée pour 1 million d'
Merci de donner vos numéros de CB + date de validité + code + cryptogramme en commentaire pour payer.
Dépéchez vous, pour les 10 premiers je fais les 20 premiers tags gratuits!
[^] # Re: Remplacer les outils de base de Linux
Posté par Yhar Gla . Évalué à 1.
Donc tout comme mozilla fire thunder bird, je renomme mon XPL en YPL (Yhargla Programming Language)
Étant donné les frais de communication pour annoncer à la communauté XPL le changement de nom les tarifs sont augmentés :
2 / tag
Forfait illimité à 2 millions d'
10 tags gratuits pour les 10 premiers souscripteurs
Dépéchez-vous (avant le prochain changement de nom :)
[^] # Re: Remplacer les outils de base de Linux
Posté par imr . Évalué à 1.
[^] # Re: Remplacer les outils de base de Linux
Posté par ckyl . Évalué à 3.
ServerRoot "/opt/apache"
PidFile /opt/apache/logs/httpd.pid
ScoreBoardFile /opt/apache/logs/httpd.scoreboard
Timeout 200
===============================
<?xml version="1.0" encoding="UTF-8"?>
<!-- Do not edit this file, it will be overwritten on instal -->
<apache_config xmlns="http://apache.org/(...)" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance(...)" xsi:schemaLocation="http://apache.org/(...) file:///usr/share/apache/rc.xsd">
<gobalEnvironement>
<ServerRoot>/opt/apache</ServerRoot>
<PidFile>/opt/apache/logs/httpd.pid</PidFile>
<ScoreBoardFile>/opt/apache/logs/httpd.scoreboard</ScoreBoardFile>
</globalEnvironement>
Le XML c'est facile a lire pour les machines, pour les humains bof bof y'a plus sexy
[^] # Re: Remplacer les outils de base de Linux
Posté par Nicolas Ternisien (site web personnel) . Évalué à 2.
Je pense que une des raisons pour lesquels il n'y a pas de bcp de frontend au fichier de conf est que celui ci varie bcp au cours du développement. (mais ce n'est pas la seule raison)
Forum Software Reviews: Comparez et testez les logiciels de forums Internet!
[^] # Re: Remplacer les outils de base de Linux
Posté par Yhar Gla . Évalué à 1.
Le fichier de conf représente l'adaptation du logiciel (donc de la machine) à son environnement et aux désirs de l'administrateur.
L'ordinateur ne peut que mettre des réglages par défaut, il ne peut pas deviner de lui même la config. Alors fichier ou interface, l'intervention humaine sera toujours necessaire pour cette phase.
Et entre (pour reprendre mon précédent exemple) :
// l'option1 fait ceci
option1=valeur1
// l'option2 fait cela
option2=valeur2
et une GUI qui afficherait:
option1 [ valeur 1 ]
option2 [ valeur 2 ]
les [] représentants selon l'option un champs texte, une liste, un "ascensceur"... et avec un tooltip qui afficherait la même chose que les commentaires du 1er exemple.
Le coût du dev de l'interface par rapport à la valeur ajouté (voyez comme je parle bien le dissaïdeur pressé :) me semble prohibitif.
[^] # Re: Remplacer les outils de base de Linux
Posté par ckyl . Évalué à 1.
Ou de le faire dans le sens inverse :-)
[^] # Re: Remplacer les outils de base de Linux
Posté par Colin Leroy (site web personnel) . Évalué à 1.
Et je trouve beaucoup plus pratique de taper /body_checks dans vi pour modifier les vérifications de corps de message de Postfix, que d'utiliser un outil, fut-il en mode texte, qui me force à aller de menu en menu du genre "Configuration > Incorporation > Checks > Body checks" puis me présente un champ texte ou un menu déroulant avec des boutons Browse, Type, Order, et ou l'équivalent de "permit_mynetworks, regexp:/etc/postfix/body_checks" prendrait plein de clics pas pratiques).
[^] # Re: Remplacer les outils de base de Linux
Posté par Nicolas Ternisien (site web personnel) . Évalué à 1.
Personnellement, j'ai toujours commencé a comprendre un serveur en passant par webmin, et quand ca me soulait au bout d'un certain temps de passer par l'interface web, hop directement dans le fichier de conf.
Forum Software Reviews: Comparez et testez les logiciels de forums Internet!
[^] # Re: Remplacer les outils de base de Linux
Posté par Hardy Damien . Évalué à 1.
Moi le XML je trouve ca tres lisible et d'autant plus que c'est structuré et verbeux.
Avec une belle indentation c'est tres facile de s'y retrouver. E t comme tu le souligne il y sera plus facile d'en faire des IHM . et lamodif manuelle sera toujours possible.
Dam
[^] # Re: Remplacer les outils de base de Linux
Posté par LaBienPensanceMaTuer . Évalué à 2.
Non, franchement, la présentation des fichiers de conf est accessoire. Ton le réel problème est de comprendre que fait telle ou telle directive etc... Une fois cela assimilé, la syntaxe du fichier de conf ne représente plus un problème.
Le fichier de conf est en quelque sorte un outil, comme un stylo.
A partir du moment que tu sais écrire, peu importe le stylo que tu utilises. Il te faudra certes un certain temps d'adaptation mais tu t'en sortira.
# Re: Remplacer les outils de base de Linux
Posté par Colin Leroy (site web personnel) . Évalué à 4.
La difficulté pour apprendre à configurer un truc vient t'elle surtout du fait qu'il faille faire
mon_option=y
$MON_OPTION='y'
ou plutôt du fait qu'il faille savoir à quoi sert mon_option ?
(le XML est vraiment présenté comme La Solution Ultime par beaucoup de monde en ce moment...mais je ne vois pas, intrinsèquement, l'intérêt de l'utiliser partout).
[^] # Re: Remplacer les outils de base de Linux
Posté par Calim' Héros (site web personnel) . Évalué à 1.
je prefere :
$Mon_Option='y'
à
<Options personnelles>
$Mon_Option='y'
</Options Personnelles>
ou meme
<Options personnelles>
<Mon_Option>
'y'
</Mon_Option>
</Options Personnelles>
[^] # Re: Remplacer les outils de base de Linux
Posté par Nicolas Ternisien (site web personnel) . Évalué à 1.
<Options personnelles Mon_Option="y" />
Forum Software Reviews: Comparez et testez les logiciels de forums Internet!
[^] # Re: Remplacer les outils de base de Linux
Posté par Calim' Héros (site web personnel) . Évalué à 1.
==> http://www.pella.com/images/products/gallery/PhtEntryDoor01_img.jpg(...)
[^] # Re: Remplacer les outils de base de Linux
Posté par Benoît Bailleux (Mastodon) . Évalué à 1.
Bon en fait, je suis assez d'accord sur le fait que pour un humain, se coltiner un fichier de configuration en XML est peu pratique. Je vois surtout le problème de la faute de frappe (genre balise mal fermé ou dont le nom est mal orthographié) qui fait planter le parseur.
Cependant, je lui trouve un grand intérêt de lisibilité dans le cas de directives de configuration par domaine. Par exemple :
<servers>
<server name="port80">
<document-handling>
<documentRoot path="..." />
...
</document-handling>
<security> ... </security>
<mimeTypes> ... </mimeTypes>
</server>
<server name="securise">
...
</server>
</servers>
Etc.
L'avantage, c'est qu'on comprend mieux le domaine d'application de chaque directive et sa "portée.
Savoir si l'ajout de complexité en vaut la peine est autre chose ...
NB : quand la CSS linuxfr permettra-t-elle un traitement correct de <tt> ?
# Re: Remplacer les outils de base de Linux
Posté par ckyl . Évalué à 7.
Tu apprends l'outil de zero c'est normal. En quoi apache t'as appris quelque chose sur postfix ?
> Un exemple simple serait les fichiers de configurations, qui n'ont absolument pas, et jamais la même syntaxe. Alors oui, c'est normal que shorewall et apache n'est pas les mêmes fichiers de conf, mais quand même, n'y aurait il pas moyen d'unifier cela un peu plus?
L'unification de quoi ?
XML est juste un langage de balisage. Si out les projets utilisaient XML et leur propre DTD tu serais pas tellement plus avancé hormis d'avoir un fichier illisible rempli de < > </ >.
Autrement ce que tu cherches se nomme une base de registre.... :-)
> qui utilise des *.po, des *.mo et des *.gmo, encore une fois dans une logique des plus étranges
Bin c'est pas les GNUs qui ont inventés ca ? :-)
> Un dernier exemple qui me sidère sont les logiciels d'autoconf, qui se révèlent être un beau boxon si on veut initier un projet dessus.
Encore des GNUseries.... va voir du coté de PMK, http://pmk.sourceforge.net/(...)
> chercher de la doc sur internet pour savoir configurer un jabber, le son ou un serveur ftp.
Tu voudrais que ca se configure tout seul ?
> car il y a surement moyen d'unifier tout autour d'une norme maintenant non (xml?)?
Encore une fois uniformiser quoi ? Defini deja clairement le problème et il y aura peut etre une solution.
[^] # Re: Remplacer les outils de base de Linux
Posté par Nicolas Ternisien (site web personnel) . Évalué à 1.
(désolé j'arrive pas a me dépatouiller avec templeet)
Bah c'est quand meme plus lisible qu'une suite de baragouinement avec des 0 0 sync,rw et consort.
Ca ne t'apprend pas a te servir du truc, mais tu sais de quoi ca parle au moins, et si il manque une virgule ou autre chose, tu a la dtd pour directement validé ton document et pas s'appuyer sur un vi spécial comme ceux utilisé pour l'édition de la crontab et de sudo.
En plus, la coloration est directement faite (en s'appuyant sur celle du xml, et cela peut s'éditer dans tout bon editeur de texte, sans avoir la coloration pour fstab ou autre).
Et enfin, ca faciliterait et éviterait l'éparpillement des outils spécifiques au distrib, en fournissant par exemple un noyau a ceux-ci, qu'il implémenterait en ajoutant leur interface dessus.
Et sinon, a propos de pmk, ya beaucoup de projet qui l'utilise?
Forum Software Reviews: Comparez et testez les logiciels de forums Internet!
[^] # Re: Remplacer les outils de base de Linux
Posté par Yhar Gla . Évalué à 2.
la ligne ci dessus se code :
< se code &lt; et > se code &gt;
la ligne ci dessus se code :
&lt; se code &amp;lt; et &gt; se code &amp;gt;
bon d'accord j'arrête :)
[^] # Re: Remplacer les outils de base de Linux
Posté par Nicolas Ternisien (site web personnel) . Évalué à -1.
Forum Software Reviews: Comparez et testez les logiciels de forums Internet!
[^] # Re: Remplacer les outils de base de Linux
Posté par Yhar Gla . Évalué à -3.
Je suis collé à 0.9 depuis je ne sais plus combien et c'est pas cool :/
[^] # Re: Remplacer les outils de base de Linux
Posté par Nicolas Ternisien (site web personnel) . Évalué à -1.
Forum Software Reviews: Comparez et testez les logiciels de forums Internet!
[^] # Re: Remplacer les outils de base de Linux
Posté par Yhar Gla . Évalué à -1.
Il ne fait pas bon être un mendiant, ni dans la rue ni ici...
[^] # Re: Remplacer les outils de base de Linux
Posté par ckyl . Évalué à 2.
Non la syntaxe d'fstab te donne tout de suite ce que tu cherches. La ligne est simple clair conscise. Ton charabiat d'XML il faut chercher les infos avec les yeux. Un fstab comme le tien avec 25 partitions de montées serait d'une lisibilité folle.
> Ca ne t'apprend pas a te servir du truc, mais tu sais de quoi ca parle au moins, et si il manque une virgule ou autre chose, tu a la dtd
lire une DTD est follement plus amusant que de faire less fstab
1 # /etc/fstab: static file system information.
2 # <file system> <mount point> <type> <,options> <dump> <pass>
vi spécial comme ceux utilisé pour l'édition de la crontab et de sudo
rien ne t'oblige d'utiliser un vi special. C'est juste pour t'eviter de casser ton systeme. Le XML ne t'empechera pas de faire ca.
> En plus, la coloration est directement faite
Heu moi vim me dit quand j'ai tappé
proc /proc proc defaulst (le defaulst est pas en jaune)
Alors que des editeurs de textes qui serait capable de detecter qu'un
<option> defaulst<> c'est plus rare.
> Et enfin, ca faciliterait et éviterait l'éparpillement des outils spécifiques au distrib, en fournissant par exemple un noyau a ceux-ci, qu'il implémenterait en ajoutant leur interface dessus.
Ca c'est un vrai problème pour faire une interface unifiée pour la config.
> Et sinon, a propos de pmk, ya beaucoup de projet qui l'utilise?
Pas enormement c'est jeune et comme tout projet jeune dans ces domaines avoir une dependence contre PMK est pénalisante. CONS et SCONS ont le même problème il me semble.
[^] # Re: Remplacer les outils de base de Linux
Posté par Nicolas Ternisien (site web personnel) . Évalué à 1.
et pour la ligne de fstab, oui elle t'apporte toutes tes infos directement au yeux, mais ya 2 ans, elle me faisait plus peur qu'autre chose cette ligne... et pour y toucher il ma fallu du courage et mes cd de mdk pour réinstaller (ancienne logique windowsienne ;-)
Forum Software Reviews: Comparez et testez les logiciels de forums Internet!
[^] # Re: Remplacer les outils de base de Linux
Posté par ckyl . Évalué à 1.
Un exemple flagrant est l' ebuild contre spell (gentoo / sourcemage). On peut faire a peu pres la meme chose mais l'expressivité n'est pas vraiment la même...
[^] # Re: Remplacer les outils de base de Linux
Posté par Nicolas Ternisien (site web personnel) . Évalué à 2.
Et encore une fois, la dtd, c'est pas pour lire, c'est pour que le fichier soit analysé AUTOMATIQUEMENT après la modif du fichier.
Et le xml permettrait en cliquant sur ctrl+une balise, de directement pointé vers la rubrique d'aide du fichier, sans passer par man fstab
Forum Software Reviews: Comparez et testez les logiciels de forums Internet!
[^] # Re: Remplacer les outils de base de Linux
Posté par Colin Leroy (site web personnel) . Évalué à 2.
Bonne idée; je pense qu'on pourrait étendre le concept à une espèce de petit trombone animé qui aiderait l'utilisateur à jouer à l'admin système: "It looks like you're trying to mount a partition. How could I help you?"
Je le répète, les cas que tu cites sont des configurations de serveurs, c'est un métier, la façon actuelle dont ça marche est la plus puissante. On voit ce que ça donne les serveurs Windows administrés par "machin qui connait bien windows" : des brouettes trouées qui marchent quand elle veulent/peuvent.
[^] # Re: Remplacer les outils de base de Linux
Posté par Nicolas Ternisien (site web personnel) . Évalué à 1.
Forum Software Reviews: Comparez et testez les logiciels de forums Internet!
[^] # Re: Remplacer les outils de base de Linux
Posté par Colin Leroy (site web personnel) . Évalué à 1.
cp /etc/sudoers /tmp/xxxxyyyy
vi /tmp/xxxxyyyy
des vérif sur /tmp/xxxxyyyy
mv /tmp/xxxxyyyy /etc/sudoers
# Re: Remplacer les outils de base de Linux
Posté par Infernal Quack (site web personnel) . Évalué à 2.
Par contre il ne faut pas croire que XML est la solution miracle. Le XML n'est qu'une technique de formatage et en aucun cas un format de fichier.
Et puis Apache n'est pas un soft Linux, ni Sendmail, ni.... Bref casser la conf de ces softs va un peu faire raller les administrateurs réseaux :)
Par contre pour les applications "de bureau" la configuration est normé pour les applis KDE et de même pour les applciations Gnome (mais ils utilisent pas le même format ni la même gestion d'accès).
Je pense que l'unification des fichiers de conf commençera par les applications "utilisateur" d'abord avec les projets comme freedesktop.org. Pour le reste ça demande de casser pas mal de trucs hérités d'Unix donc c'est pas demain la veille
L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
[^] # Re: Remplacer les outils de base de Linux
Posté par Nicolas Ternisien (site web personnel) . Évalué à 1.
Et sinon, bon point pour les applis kde et gnome, mais encore une fois, pas unifié...
Forum Software Reviews: Comparez et testez les logiciels de forums Internet!
[^] # Re: Remplacer les outils de base de Linux
Posté par Infernal Quack (site web personnel) . Évalué à 1.
penses tu (finalement c'était ça l'intérêt de mon journal), que cet éparpillement est normal
C'est normal au sens "Oui vu le nombre de softs, et leur origines diverses".
Non c'est dommage car une norme devrait être conseillée.
C'est en partie ce pourquoi XML a été créé. Ca évite d'avoir à recoder des parseurs différents pour chaque applications. Ca permet aussi aux autres applications de pouvoir relire ce format plus facilement. De plus le format XML a été pensé pour être le plus générique possible de façon à inclure tout type de représentation de données dont les représentation arborescente de niveau quelconque. De plus des techniques de validations de formats XML existent déjà (DTD ou XML Schema), des techniques de transformations (XSL),... Bref XML a tout ce qui faut. Ca ne sert à rien pour un soft de réinventer la roue.
XML a des défauts pour les configurations basique (plus chiant à lire mais c'est subjectif car moi je trouve que lire du XML c'est simple) mais à plein de qualités.
et que cela devra un jour évoluer?
Bin ça serait bien mais je doûte que ça se fasse avant très longtemps.
L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
# base de registres en xml
Posté par Juke (site web personnel) . Évalué à 1.
Ensuite tu genere tes fichiers de configurations à partir du fichier xml.
Comme ça tu as tout tes parametre sous les yeux, des que tu change un truc, tu fait un :
regxml.update -a
Ca evite de changer tout ces fichiers de conf quand on change un parametre et de repenser tout les outils.
Cependant cela necessite de bien connaitre les fichiers de configuration.
Quand le fichier de configuration change, tu n'a qu'a changer ton parser.
# Re: Remplacer les outils de base de Linux
Posté par Bernez . Évalué à 1.
Cette phrase démontre ta totale méconaissance de GNU Gettext, et critiquer quand on ne connait pas, c'est mal (TM). C'est comme si tu disais "c'est nul le C, t'as des fichiers .c d'un côté et des executables de l'autre. Pouvaient pas se contenter d'un seul fichier, comme en PERL?". ;-)
Pour ce qui est du format de fichier de conf unifié, il y a des cas où ce n'est pas du tout souhaitable. Par exemple pour une conf de serveur web ou de MTA, c'est l'efficacité et la clarté qui doivent primer, et ça nécessite des formats qui leur sont propres.
[^] # Re: Remplacer les outils de base de Linux
Posté par Nicolas Ternisien (site web personnel) . Évalué à 1.
Et sinon, je suis d'accord avec toi pour le fait que la configuration doit etre clair et efficace, et xml n'est pas forcément THE solution, mais ne faudrait il pas quand même tout unifier...
Forum Software Reviews: Comparez et testez les logiciels de forums Internet!
[^] # Re: Remplacer les outils de base de Linux
Posté par Pascal . Évalué à 1.
Je lève le doigt et je reponds SendMail....
sendmail.st = clarté + efficacité.
Preuve que les fichiers de conf ne sont pas toujors adaptés
# Re: Remplacer les outils de base de Linux
Posté par Mark Havel . Évalué à 1.
Bref, c'est vrai qu'une certaine unification sur la façon de les organiser, de mettre les différentes options pourrait être une bonne idée. Mais il faudrait que tout ce beau monde se mette d'accord et c'est déjà moins gagné. Peut-être que cela se fera un jour dans le cade d'un Linux Standard Base ou assimilé.
[^] # Re: Remplacer les outils de base de Linux
Posté par Glenn Y. R. (site web personnel, Mastodon) . Évalué à 1.
D'un autre coté, je serais plutot pour la création d'une DTD par "type" de logiciels/serveurs, par exemple :
- une DTD pour les serveurs HTTP
- une DTD pour les serveurs WEB
- etc...
afin de pouvoir parser/configurer de la meme facon n'importe quel daemon d'un même type... puisque dans une certaine catégorie de logiciels on retrouve les "grosso-modo" les mêmes options entre les logiciels...
[^] # Re: Remplacer les outils de base de Linux
Posté par LaBienPensanceMaTuer . Évalué à 1.
(Je vois d'ici les geeks mal de trolls me dire "Ah ouai mais apachessl c'est un serveur Web mais pourtant il fait que https .... bon ça va hein !)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.