Sytoka Modon a écrit 4544 commentaires

La carte DELL marche-t-elle sur d'autres types de serveur que les DELL ?

En gros, ce genre de carte est-il universel ?

Moi je vais sur debian.org car je suis sur que mes utilisateurs ni vont jamais ;-)

CUPS ! C'est pas un peu le marteau pilon !

a2ps -o - mon_fichier | ps2pdf - monfichier.pdf

Et tu bloques linuxfr aussi ?

cfengine est ton amis ;-)

Ce me semble loin de la facilité d'nedit. Ctrl+Souris bouton gauche et tu es en sélection carré. To changement de mode fait qu'en pratique, pas grand monde doit l'utiliser.

Bref, avec nedit, la sélection carré, c'est comme une sélection classique mais avec la touche Ctrl appuyé.

Après, il y a d'autres éditeurs qui le font mais je ne l'ai jamais vu avec cette souplesse.

Sur la page suivante, on voit une config

http://code.google.com/p/finefs/wiki/InstallationInstruction(...)

C'est un peu pénible d'avoir un fichier différent pour chaque noeud. Cela signifie que ce fichier ne peut pas être déployés brut de brut.

Le serveur ne pourrait-il pas détecter que peers[]=arnold, c'est lui même et transformer cette ligne en local=arnold ?

En fait, cela me fait plus penser à Tahoe

http://allmydata.org/trac/tahoe

Qu'elle est la particularité de FineFS par rapport à Tahoe ?

Je suis d'accord avec toi. Lorsque je lis PHP et ensuite que ce n'est pas POSIX, je trouve les comparatifs quand même plus qu'osés...

Maintenant, pour être vraiment généralisable, il faut pouvoir monter le système de fichier et le tester de manière classique. Sinon, cela restera un produit de niche.

Attention, je ne dis pas que XSLT est une mauvaise chose. Ce type de programmation, de type moteur d'inférence (prolog, make) sont géniaux pour certaines taches.

C'est uniquement la syntaxe qui est lourding pour un langage de programmation. Sans IDE qui complète ou sans copier-coller de bout de code d'un fichier dans un autre, c'est hyper chiant... C'est uniquement ce point là qui me gène.

Tu veux dire que l'emacsien est plongé dans sa doc pour retrouver le control qui va lui permettre de quitter emacs sans perdre son boulot de l'après midi et donc qu'il n'a pas le temps de venir sur dlfp ?

Il est bien mais aussi sobre que nedit. J'aime mieux la police de caractère de nedit. Mais surtout, il est nul en sélection carré... et j'en ai besoin souvent.

tout comme toi. De plus en plus de vim mais historiquement du nedit, notament pour ce que tu as dis : rapidité, simple et lisible, selection carré ultra efficasse...

Mon soucis, je cherche de plus en plus dans nedit avec / et je evux aller à la ligne 123 en 123G ! Bref, je veux un mode vi dans nedit !

Je crois qu'il y a des schémas YAML mais je n'ai jamais utilisé. Ce que je veux dire, c'est que YAML tout comme XML ne sont qu'une représentation d'un arbre. Ton validateur, si ce n'est pas du SAX mais du DOM charge tout. Dans le cas d'un fichier de config, c'est pas illogique. Donc tu valides un DOM et non directement un XML. Du coup, valider un DOM écrit en YAML plutot qu'en XML ne pose pas de problème puisque la transformation YAML->XML est facile.

Bref, pour moi, c'est des mauvaises raisons pour ne pas développer d'autres backend au DOM et vouloir du XML partout.

Un exemple pour moi de folie, c'est le XSLT... Vouloir faire des programmes, en plus de type moteur d'inférence, en XML, c'est grandiose ;-)

Sinon, au niveau des fichiers de conf, je parlais de modif de dernières minutes fait à l'arrache avec vi ou a une conf propagé par cfengine... Il arrive de se planter... donc le serveur doit valider son fichier de conf au chargement. A vrai dire, c'est pas cela qui lui prends non plus des heures.

Si tu fait un programme qui génère du code, tu n'est plus réellement dans l'admniistration système mais dans la partie dev. Tu tomberas un jour ou l'autre à générer un arbre avec une syntaxe ayant des subtilités. Cela peut êre pénible à faire mais c'est un développement comme un autre.

Après, c'est vrai que le format SVG n'est pas simple...

Tu n'es jamais assuré que le fichier n'a pas été modifié avant de relancer le serveur donc ton serveur doit vérifier le fichier. La validation qu'a priori est une erreur et dans la conception de site web, amène a de grave erreur si on ne vérifie pas sur le serveur tous les paramêtres POST et GET.

Donc, une fonction check sur le serveur est absolument nécessaire. Ce check peux te prendre le YAML, te le transformer en XML (binaire - mémoire / comme cela, il n'y a pas de XML fichier si cela te va mieux) et le valider ainsi. En fait, tu n'en seras rien. Ce n'est pas ton problème, toi tu es utilisateurs, tout cela est programmé / scripté.

Ensuite, je veux un éditeur sans X-Window. Je ne veux pas de l'erreur de Windows d'imposer le graphique sur les serveurs. Et puis, je ne vois pas pourquoi on ne pourrait pas complèter du YAML puisque ce n'est qu'une autre manière d'écrire un arbre...

Je répondrais rapidement car l'heure est avancé...

Je préfère le YAML ou le JSON lorsque j'édite les fichiers à la main. Les fichiers XML sont très pénible à faire à la main. D'ailleurs tu le sous entend toi même en parlant d'éditeur spécialisé.

La règle numéro un devrait être de rester simple et donc de pouvoir faire tourner un serveur sans X. Les éditeurs en question ont besoin de X je suppose.

La règle numéro deux voudrait qu'on puisse configurer directement sans passer par un méta outil parfois web pour configurer...

Le YAML, pour quasiment une grande partie des fichiers de config (qui reste en général simple) se travaille très bien avec grep, sed, cfengine. C'est important pour faire des scripts sur un parc conséquent.

Je n'ai plus en tête les fichiers Tomcat car dès que je vois un serveur en java avec Tomcat, je choisis une solution équivalente sans Tomcat. Je n'en ai plus sous la main. En gros, si mes souvenirs sont bons, c'est un arbre donc en YAML, c'est juste un arbre sous forme

clef: valeur

Pas besoin de <> et "" qui alourdissent sans rien apporter. Remarque, le JSON me convient tout à fait mais la news parle de YAML...

Donc pour finir "En quoi YAML est plus adapté qu'XML pour le META.yml ? " Tout simplement parce que j'écris ce fichier à la main, que je le modifie à la main... C'est comme un Makefile, c'est fait pour être manipuler par des êtres humains.

Avec la folie du XML, l'idée est de simplifier la vie de la machine et de mettre l'homme dans une syntaxe rigide et absolument lourde. Lex et Yac ont été inventé il y a longtemps, c'est pas un soucis pour la machine de lire autre chose que du XML.

Mauvais exemple... un fichier inkscape n'est pas un fichier de configuration donc il n'y a pas besoin de l'éditer à la main sauf en cas de deboguage pour les développeurs du logiciel. Donc on est sur un autre problème ou justement le XML est tout aussi bien que le YAML puisqu'on serialize puis de-sérialize. On pourrait utiliser le YAML si cela apportait un plus dans ce cas. A priori, comme cela, il n'y a pas de plus donc l'un ou l'autre me sont indifférents.

Il est trivial de faire yaml2xml donc valider un yaml est facile...

Mais comme dans les formulaires, même si le client valide son fichier (formulaire), c'est au serveur de valider le fichier de conf au lncement.

Cette histoire de validation est à mon sens bidon. Il y a plus de 10000 modules je crois sur le CPAN et cela MARCHE !

ssh aussi...

Ces programmes ont été conçu pour éviter les scripts "crades" avec les mots de passe en clair. Donc ils lisent le tty et non l'entrée standard.

Après, il y a moyen de tricher pour faire croire à un tty, expect en est un bon exemple. Mais lorsqu'on fait cela, on est conscient de tricher avec la philosophie du concepteur du programme.

En tant que responsable d'un service informatique, je commence par appliquer les règles venant d'au dessus à mon même ;-)

Pour les fenêtres flotantes, tous ces gestionnaires de fenêtres sont mauvais (pour simplifier). Le problème est que ces gestionnaires de fenetres sont principalement utilisé par des admins systèmes et réseau ou par des développeurs. Un de mes soucis est que l'application cluster-ssh est indispensable sur un parc conséquent et qu'elle permet de paver la totalité des écrans avec des xterm... S'il y a un mode compatible entre cluster-ssh et i3, alors vous allez faires beaucoup d'heureux ;-)

En fait, au niveau des flotants, il faut bien gérer le multi écran (pas le cas de wmii aujourd'hui) et garder un fonctionnement basique. La seule idée nouvelle que j'ai eu serait de pouvoir stacker les fenêtres flotantes mais là, on doit pouvoir reprendre le code de la partie tabulée pour la gestion de la pile. Pour la gestion de l'accrochage, à la souris, c'est identique au déplacement d'une fenêtre d'un pile dans une autre en environnement tabulé. Donc ce n'est pas non plus révolutionnaire et peut donner une touche geek par rapport aux autres window manager du même type ;-)

Pour la gestion des kill, j'ai le souvenir que xkill (sous fvwm donc cela remonte à loin chez moi) tuait l'application instantanément... J'aurais dis que c'était du kill -9 brut de brut, donc pas très gentil avec la fenêtre.

Sinon, il y a les formats comme NetCDF (limité mais simple) ou HDF qui sont fait pour cela.

Comme je l'ai déjà il y a quelques temps ici, on aurait mis un toute petite partie de l'énergie mis sur XML a faire une API équivalente a celle d'XML sur le format HDF (ou un autre équivalent), on aurait aujourd'hui un XML binaire...

En effet, le XML est mauvais dans les fichiers de conf mais a du bon dans d'autres cas d'utilisation, et souvent, dans ces cas la, on aurait un arbre binaire que ce serait pas plus mal.

Je ne sais pas de quand cela date mais tous les modules Perl dans le CPAN ont un fichier de spécification en YAML. Je pense que le CPAN est donc l'utilisateur numéro 1 du YAML.

Après, je vois que les fanatiques de java et de Tomcat trouvent leur fichier XML lisible et super. Je voudrais voir un serveur d'application Tomcat avec autant de module que le CPAN ;-)

Moi j'ai horreur du XML dans le fichiers de conf (merci Red-Hat et Novell de nous en mettre plein en ce moment)...

Pas d'IRC à la fac ! C'est interdit et coupé...

Pour la config, je ne me fait pas de soucis pour la refaire... C'est plus que au vu des liens avec wmii, autant reprendre les mêmes raccourcis lorsqu'il sont bien.

Merci de faire remonter cela. Demain, je doit préparer mes vacances et donc la doc du SI en cas de panne. La mise à jour va me prendre toute la journée ;-(

Il coupe à 8 en faisant deux fois 8. Il faut donc aller à 17 lettres...

C'est pour cela que j'imposais un mot de passe compliqué sur les 8 premières lettres. Imposer plus de 16 lettres, cela devient dur...