Sytoka Modon a écrit 4546 commentaires

> Bref, YAML ça pue encore plus que le XML. À quoi bon ?

Dis donc, t'es pas sympa avec le XML. Même moi, je n'ai pas dis cela ;-)

Un truc qui m'amuse sur le YAML, les pro XML déteste et parmi ces personnes, il y en a plein qui adore python. Or comme python, YAML est basé sur l'indentation...

Personnellement, je ne suis pas fanat de python et de l'indentation. J'ai pris l'exemple du YAML car c'est ultra simple a utiliser dans un programme, que c'est facile à lire, que cela commence a être connu et que ca gère une bonne partie du CPAN... Donc, on ne peut pas dire que c'est un truc d'amateur qui ne passe pas la mise à l'echelle.

Mais en fait, je n'ai aucune action chez YAML et je suis ouvert à tout format qui soit humainement conçu. Encore une fois, il faut choisir le bon langage pour le bon usage.

Sinon, effectivement, il y a plein d'outil qui ont été fait autour du XML. Si le dixième de cet énergie avait été mis sur un truc humainement lisible, on aurait aujourd'hui quelque chose de vraiment bien. Quand je vois le nombre d'heure année qui ont été passé pour qu'on utilise le XML à tour de bras et lorsque tu vois le nombre d'heure mis, par exemple sur le YAML (zut, encore lui), tu te dis que le XML, en lui même, est un truc complètement pas rentable...

D'un autre coté, le XML a permis de développer tout un tas de technologie annexe, comme la recherche dans un arbre avec XPath... Mais cela, tu pourrais très bien l'appliquer sur un arbre YAML (Ah non, je ne veux plus en entendre parler !) ou sur un format binaire comme HDF.

D'ailleurs, à mon sens, un gros part de ce qui a été fait sur XML aurait du être fait autour d'HDF ou un équivalent. Quitte à avoir des outils de haut niveau pour manipuler l'arbre de données, autant avoir un format binaire optimisé.

Mon pronostic : le HTML quitte peu à peu le web utilisateur puisque celui-ci rédige de plus en plus avec des syntaxes de type wiki. Très peu d'utilisateur pondent encore du HTML directement. Pour le XML, cela va faire pareil. Cela va devenir une technologie que se déroulera en arrière plan de l'utilisteur et il configurera son outil de configuration de sa titanesque application avec un bête fichier .ini ;-)

C'est sur que ton domin.xml, sans editeur potable, cela ne donne pas du tout envie ;-)

Bon maintenant, tu as un editeur potable qui marche sans X11 ?

Qu'est ce que vous utilisez comme logiciel pour éditer vos XML qui soit libre, génial, convivial... Je n'ai pas fait le tour de la question depuis quelques temps mais à l'époque, c'était pas terrible.

J'aimerais bien voir l'interface de configuration d'un serveur comme exim fait via un schéma ?

Je sens que dans ce débat, il y a les pros XML qui m'ont l'air pour les IHM graphique de configuration et les autres. Pour moi, une IHM graphique pour configurer exim me semble une voie glissante vers le clickodrome Windows ou finalement, tu ne comprends pas grand chose de ce que tu fais. Comment répares-tu ce genre d'usine à gaz, bien tu ré-installe comme tout le monde car c'est quasiment pas réparable sauf par un spécialiste quasi inexistant.

Exemple pris sur un logiciel qui n'est pas un serveur : thunderbird. Je ne sais pas vous mais moi, lorsqu'un de mes utilisateurs a un profile qui pars en sucette (et cela arrive parfois malheureusement), je suis incapable de réparé cette usine à gaz et je repars sur un nouveau profile. L'utilisateur est content mais en réalité, je suis d'une grande incompétence.

Je voudrais éviter d'avoir à faire cela sur mes serveurs de mails, mes apaches, mes machines virtuelles, ma haute disponibilité... Je ne me considère pas comme un très bon administrateur système et pourtant, comme des milliers d'autres, j'arrive à réparer des configurations foireuses si celle-ci ne sont pas noyés dans des IHM graphiques et des fichiers de configurations obscurs.

Au final, je me fiche pas mal que le XML ait un schéma qui me permette de valider ma configuration. C'est comme un formulaire web, ce n'est pas au javascript de valider les données mais toujours au serveur. Idem pour un fichier de configuration, le serveur ne doit pas prendre le fichier de configuration pour argent comptant. Tant mieux s'il est juste.

Je préfère que le serveur ait un mode ou il charge le fichier de configuration et me disent lui-même ce qu'il en pense. Normalement, un serveur programmé correctement devrait avoir un mode comme cela. Qu'en interne, celui-ci transforme mon fichier de configuration en XML et lance un validateur de schéma, c'est le choix du programmeur et je le respecte entièrement.

> Après, un fichier de configuration c'est surtout fait pour stocker la
> configuration d'un logiciel

J'ai l'impression qu'il y a peut être là un mélange mais je me trompe peut être. On a l'impression que tu parles de l'état du logiciel. Que le logiciel stocke sont état sous un fomat quelconque pour se relancer plus vite et dans le même état ensuite me convient parfaitement. Dans ce cas là, autant avoir un format binaire type HDF par exemple mais toutes les solutions peuvent être bonne en fonction du contexte. Mais il ne s'agit plus vraiment de configuration (donc de /etc) mais plutôt de données donc dans /var ou /data

Les fichiers .INI, c'est un standard, il y a des outils pour les manipuler. Les fichiers YAML, c'est un standard, il y a des outils pour les manipuler. ...

Le XML est un standard récent qui est bien pour certain truc, notament dans les pipelines de type AxKit. Pour charger une configuration, c'est lourdingue et inutilement compliqué.

Sais tu que charger une configuration en YAML dans un programme se fait en deux lignes, une pour charger la bibliothèque et une pour charger la configuration. Sais tu aussi que le YAML est multiplateforme et multilangage, tout comme les fichiers .ini, tout comme...

Non tu es dans ton petit monde du HTML et du XHTML et donc il faut en mettre partout. Et puis c'est ce que veulent les entreprises alors suivont comme un mouton... Ce n'est pas dans ma philosopie ni celle qui m'a fait adoré Linux depuis des années et des années.

Bref, tu ne me donnes aucun argument qui tienne la route. Donne moi vraiment un truc compliqué parce que la configuration de machine virtuelle, c'est un truc que je trouve assez simple.

Ce que j'en pense, avec des logiciels libre ayant des fichiers de configuration en XML, il faut se tapper absolument une interface graphique de configuration. Or écrire ce genre de programme est super chiant, c'est pas si facile à faire, surtout sans bogue. Les boites comme Red-Hat ont peut être tout intérêt à vendre du support la dessus. En tout cas, c'est par exemple un peu la stratégie de XenSource (Citrix) que de vendre l'IHM de configuration.

Bref, c'est peut être une stratégie commercialle mais certainement pas technique.

Petit exercice pour finir : vous mes traduisez en XML un fichier de configuration conséquent des serveurs apache2 et exim4. Faites de même avec samba. Comparez et tirez en la conclusion qui s'impose.

> je dirais que c'est orienté Enterpraise

Les fichiers de configuration sous UNIX sont depuis des années loin d'être en XML et UNIX est loin de ne pas être orienté entreprise !

Les fichiers de conf en XML proviennent de toute la tringlerie insupportable du java avec Tomcat et autres. On sais très bien faire des fichiers de conf lisible par l'homme et par la machine, par exemple le YAML. Pour information, l'ensemble de la cohérence des milliers de module (classe pour la plupart) du CPAN de Perl sont pilotés par de simple fichier YAML. Tu ne va pas me dire que la gestion des tes machines virtuelles est un problème plus complexe et doit être plus professionelle que celui du CPAN !

Faire cela sous XML, c'est effectivement pour simplifier les outils de plus haut niveau qui manipule alors ce genre de fichier facilement avec l'aide des bibliothèques toute faites pour le XML. Enfin, pour la quantité et le type d'information que l'on y retrouve, on fait tout aussi bien en YAML...

Ecrire un générateur, cela revient en pratique à lire et à écrire dans un fichier une structure d'arbre. C'est assez facile, pas besoin encore de se focaliser sur le XML.

Bref, sous des arguments que je considère comme fallacieux : "il me faut des méta outils qui puisse me générer mes fichiers de conf", on va finir par se retrouver avec un /etc imbittable et être obliger d'avoir des clickodromes pour gérer ses machines Linux (voir une base de registre !).

Je gère mes serveurs sans X-Windows, j'ai des dizaines de machines virtuelles et le tout est cohérent avec le tout génial cfengine qui n'a pas une ligne de ce truc imbittable pour l'homme qu'est le XML.

Désolé, je n'ai pas envie de gérer mes serveurs Linux comme des serveurs Windows... Et je vois de plus en plus de personne venant installer des prologiciels sous Linux qui viennent du monde Windows et qui amènent et appliquent les mauvaises méthodes de Windows sous Linux.

Un programme de type service système ne devrait pas avoir une application graphique comme dépendances nécessaires pour l'installation et la maintenance (ce qui ne veut pas dire qu'il n'en faut pas du tout). Cela me semble un défaut de conception à la source. Surtout que comme je l'ai dis en début de réponse, il y a des alternatives au XML qui font le même boulot en pas plus de ligne et qui sont humainement acceptable.

Bref, je ne sais pas si c'est Red-Hat qui pousse à cela mais libvirt, heartbeat2... Moi, cette voie du XML, cela commence à me gonfler sérieusement. D'ailleurs, pour cette raison, j'évite toute application en java sur mes serveurs dans mon laboratoire et pour le moment, aucune ne me manque.

Un seul problème, les fichiers de configuration au format XML ! C'est clairement orienté clickodrome ce truc là.

Moi, je veux des fichiers de conf fait pour les humains comme ceux de Xen à la base. D'ailleurs, Xen les transforme ensuite à un format parent du XML puisqu'ils sont en un dialecte du LISP.

Bref, virt c'est bien mais SVP, pas de XML sous /etc.

Arrêtes avec ton 'nazis', le nazisme n'a rien a voir avec cela.

Merci d'avoir un peu plus de respect pour la mémoire de tous les morts de la seconde guerre mondiale.

N'aidons pas à introduire ce mot dans la langue courante pour parler de tout et de n'importe quoi.

Ils trainent quelques affaires dans les laboratoire de recherche universitaire (lié au CNRS) ou il est arrivé qu'un chercheur pique la publication d'un autre, en profitant généralement de l'absence de celui-ci.

C'est une des raisons pour lesquelles les informaticiens ont des consignes assez strictes de ne pas fournir l'accès en interne aux données d'un chercheur a un autre sans avoir l'aval direct du premier chercheur.

Non, je ne pensais pas au DRM mais a un système de jeton ou d'authentification quelconque...

Sinon, j'espérais que le serveur était open source.

Vous utilisez aussi des outils Apple pour faire le 'cut' sur les films ? Diffusez vous des films a double flux vidéo (type H323 avec H329) ayant donc un flux 'vidéo' et un flux 'data' ayant une meilleure résolution mais moins d'image par seconde.

Merci

Tu utilises quoi comme serveur et comme logiciels. Vos vidéos en VOD sont sécurisés ?

Une infrastructure basé sur Linux et H264 en VOD m'intéresse beaucoup comme solution.

Et puis, si les onglets sont en haut de la page, autant avoir un gestionnaire de fenêtre qui gère les onglets ! (comme pwm et bien d'autres maintenant) Cela devient son boulot.

Pas vraiment, tous les navigateurs s'appellent mozilla en interne et cela depuis des années (le début ?). Idem, le système interne dans la 'packaging' s'appelle chrome et cela depuis aussi pas mal de temps.

C'est le nom final, public qui change. Pas les noms de code interne.

Chrome, c'est un peu un nom de code dans les applications mozilla depuis des années... Lorsque j'ai lu l'annonce, je me suis dis que ce navigateur était basé sur mozilla ! Ben non, sur WebKit.

Vis à vis de mozilla, ils auraient pu choisir un autre nom...

Je ne suis pas sur que les développeurs de gnome teste celui-ci sous autant d'architecture que debian...

Il ne faut pas croire que parce que tu sors une nouvelle version stable, celle-ci le soit rééellement sur des distributions aussi complète que debian (ou fedora...).

Ne prenons pas non plus les uns et les autres pour des manchots. Comme dis le proverbe, il n'y a que clui qui ne fait rien qui ne casse pas les oeufs. Donc bien sur, tout le monde prends des risques !

Bref, le travail des équipes est complémentaire et les deux sont nécessaires.

X a été conçu pour la transparence réseau et en cela, il est formidable. X devient de plus en plus modulaire et la transparence réseau oblige a avoir un code plus propre au niveau noyau de séparation des tâches. Bon historiquement, X a transgressé pas mal de chose mais c'était pour être multi-UNIX.

Car oui, c'est un point important dans UNIX, d'être multi version de l'esprit UNIX.

L'administration de MacOSX me rappelle parfois celle de Windows 98... Les panneaux graphiques sont simplifiés à l'extrème, on n'arrive même pas a avoir toutes les informations que l'on souhaite. Configure par exemple un imprimane réseau et essaye de retrouver ensuite tes paramêtres de configuration sans aller trifouiller dans le système.

Parfois GNOME (que je ne suit pas du tout) me semble prendre la même voie de trop simplifier l'interface utilisateur pour faire croire que c'est simple. Du coup, on finit par manquer de molette.

Contrairement aux autres UNIX, MacOSX ne s'intègrent pas bien dans ce type de parc, en tout cas, pas mieux qu'un Windows en domaine !

Ce n'est pas un vrai 'UNIX' puisqu'il n'y a pas X par défaut et pas de troisième bouton à la souris (ni de second). Tu copie colle comment ? Le clavier est à chi... en tout cas, il n'est pas fait pour la ligne de commande.

L'IHM ne peut suivre un programme fonctionnant en Follow Mouse ce qui est le mode par défaut des applications traditionnelles graphiques...

La gestion du partage de fichier est un samba mais le nombre de réglage est .... plus que minimaliste.

Il y a du /Library un peu partout... Cela ne suit pas du tout la FHS. Le Library est traduit en francais, ce qui est une abérration à mon sens. Heureusement, en ligne de commande, cela reste Library contrairement à Microsoft qui a inventer les 'special folder' histoire de compliqué inutilement la structure du système.

Bref, c'est un UNIX très très à la marge.

C'est à dire ? Les choix justement fait par Apple

Ok, je -> []

> Gni ? Tu peux développer ?

J'ai déjà vu du code Java planté lamentablement sous Firefox Linux et marcher sous Windows... Je ne citerait pas le constructeur ici.

> D'ailleurs sur les gros sites la scalabilité est de loin plus importante
> que la performance. Mais on y pense tout de même.

Je suis entièrement d'accord. A propos de compilation JIT, c'est effectivement une voie possible (par exemple en C, il y a TinyCC qui fait cela). Cependant, pour les gros codes, la voie d'un bon compilateur qui prend son temps pour optimiser un maximum me semble préférable mais peut être ai-je tord.

> Mais concrètement pour des sites web tu as le choix entre: PHP,
> Perl, Python, Ruby, Java, .Net.

Je n'ai pas dis que Java était lent. Il suffit de voir ses performances pour voir qu'il scotch maintenant tous les langages de script.

Cependant, l'énergie mis sur Java pour arriver à cela aurait pu être mis sur autre chose...

A propos du développement Web, je suis 100% d'accord avec toi. C'est incroyable qu'autant de choses soit encore faites en langage de script. Cela ne viendrait à personne de faire un serveur NFS en Perl, mais un serveur web oui.

A mon sens, il ne devrait pas y avoir de différence notable entre une application web, Qt, GTK... dans la manière de programmer. A quand un Web3 qui serait POSIX ;-)

Pas d'intégration du patch debian ajoutant la fonction de blacklist de clef ssh. Dommage, vu l'envergure du problème debian... il va rester plein de serveur au monde acceptant les mauvaises clefs.

Je n'ai rien vu aussi à propos des clefs DSA. Je n'ai pas tout compris a leur sujet mais debian conseille de ne plus faire de clef DSA.

Bref, les changements dans OpenSSH sont dans la continuité et améliore surtout les parties MATCH et SFTP.

yahoo, ebay... Des jeunes pousses ?

Je n'ai jamais dis que Java est une bouze et qu'il ne marche pas.

Je dis simplement que pour des gros codes coté serveur, comme ceux pour ebay ou yahoo, avoir un java compilé serait tout aussi bien. Ils gagneraient en performance. Ces codes là n'ont pas besoin de la compatibilité binaire inter-plateforme (qui marche d'ailleurs plus ou moins bien).

Par ailleurs, les boites que tu donnes n'ont certainement pas un serveur en frontal mais toute une ferme.

Il y a plein de logiciels qui fonctionnent à la fois sous Windows, Linux et MacOS e t qui ne sont pas programmé avec mono. Il suffit de programmer dans un environnement multiplateforme et de recompiler sur chaque.

Bref, je comprends que certaines personnes programme avec .NET parce qu'elles aiment cet environnement. Mais d'un point de vue personnel, je ne vois pas ce qu'il apporte de plus a par des inconvénients.

Java a été très mal vu à l'époque sous Linux. Il y a cependant un différence de taille entre les deux projets :

- Java s'est voulu dès le début multiplateforme et non limité aux seuls produits SUN.

- Java vient de SUN qui n'a pas la culture du nombril et du monopole comme Microsoft. Enormément de protocole réseau viennent de SUN : NFS, NIS...

Ceci dis, SUN s'est planté avec Java car celui-ci était destiné aux clients et on le retrouve surtout au niveau des serveurs. Or je ne suis pas sur que cela soit une très bonne idée d'un point de vue sécurité et performance d'avoir du code binairement portable. Pour un serveur, autant recompiler son code...

D'ailleurs l'argument de la portabilité est assez bidon, les grosses applications embarquent leur propre copie de la JVM pour ne pas avoir de problème de compatibilité (exemple Matlab). Sur un poste Windows, on est obligé d'avoir plusieurs version de .NET... A ce niveau là, Perl est bien plus portable et je n'ai jamais eu plus d'une version de Perl sur mes postes !

Bref, au final, ni Java ni .NET ne sortent du chapeau, .NET dérive de Java et Java d'OpenStep dont SUN n'avait que la moitié des parts... Finalement, tout cela pour éviter aux programmeurs de développer en ObjectiveC...

Qui développe des applications sous Wine ?

Wine est un truc que je suit depuis le début et que je n'ai jamais vu en production (sauf le machin de crossover).

Après un paquet d'année, Wine est juste en train de sortir sur quelques applications. Encore une fois, que d'énergie pour un si piètre résultat. la chance de Wine est que Microsoft veut changer son API avec Vista et donc pour les migrations des vieux logiciels, le passage par Wine peut être rentable.

A mes yeux, Wine n'est pas du tout un environnement pour innover au niveau logiciel. Si Wine est un modèle pour Mono, et j'en doute, je ne trouve pas cela très positif.

Miguel a simplement basculé du coté obscur de la force

-> []

Parce que Fedora est ouvert au non-libre ?

Je te rappelle que chez debian, il y a les parties contrib et non-free, donc on installe le java de SUN avec un simple apt-get !

Avant de sortir des grands mots d'exclusion, merci d'être un peu plus respectueux du travail des autres.