Sytoka Modon a écrit 4551 commentaires

Je me réferrais a ce bout de mail sur la liste

"
To solve the fundamental problem, the plan is to replace /sbin/init
with an implementation that is able to handle kernel events. It will
allow us to modify the boot system for the early boot to become event
based, while keeping the existing boot stuff working. We could rewrite
sysvinit to become event based, or have a look at the existing boot
systems that handle kernel events. After checking the options and the
systems used in other distributions, upstart seems like the most
promising candidate. It is used by Ubuntu and Fedora at the moment,
and solves the problem in a backwards compatible way. The plan is to
change upstart to actually use /etc/inittab, to ease the switch
between sysvinit and upstart. We will also change the init.d script
handling to treat upstart jobs as init.d scripts, to provide an
alternative for architectures lacking upstart support. These changes
should make it transparent for the users which package provides
/sbin/init, and thus make it easier to migrate from sysvinit to
upstart.
"

J'ai lu cela comme une annonce du scénario le plus probable... A mon sens, c'est pas encore tranché définitivement pour squeeze car il faut intégrer dans upstart la gestion des scripts init pour être conforme a la LSB.

Dans le même ordre d'idée, debian va aussi basculer vers GRUB2 pour Squeeze, si cela marche bien entendu.

Erlang est un langage qui a été développé pour cela. On peut modifier son code à chaud pour mettre des mises à jour de sécurité.

C'est intéressant comme concept et je pense que cela va se propager petit à petit comme philosophie. Déjà avec le noyau et ksplice, on peut recharger un module à chaud...

Pour les serveurs, on pourrait laisser le serveur traiter les requêtes en cours et utiliser la nouvelle version pour les requêtes suivantes... C'est un peu ce que fait ssh lorsqu'on le relance. J'utilise comme QPSMTP comme serveur de mail qui fork pas mal d'instance pour répondre à la charge et régulièrement, il fork son processus principal... Une mise à jour se fera donc automatique au fork suivant (c'est pas un fork au sens UNIX du terme...). Parfois, on n'est pas à 10mn pour une mise à jour de sécurité si on peut éviter un interruption de service.

Je sais bien, j'ai déjà lu la dépêche... Mais je pense que su tu fais un sondage sur linuxfr avec comme question :

Comprenez-vous la phrase : << générateur d'application centré autour d'un générateur de formulaire avec une persistance de fichiers au format N3 >> et êtes vous capable d'expliquer en pratique par un exemple concret ce qu'elle veut dire ?

Je suis persuadé que plus de 90% des gens de ce site répondrons NON.

J'ai vaguement travaillé il y a 4 ans avec des personnes qui bossaient sur les ontologies donc je vois a peu près ce que signifie une ontologie. Mais je ne suis pas sur que beaucoup de personne savent ce qu'il y a derrière.

Bref, ta réponse ne me satisfait pas du tout car je demandais juste si on pouvait avoir une explication avec du français de base, sans acronyme et des exemples concrets. Pour moi, ta phrase : << générateur d'application centré autour d'un générateur de formulaire avec une persistance de fichiers au format N3 >>, je la lis sans problème mais elle est vide de sens car je ne vois pas ce que tous ces mots mis bout à bout ont comme relation dans la vraie vie.

Quand au lien que tu donnes, je suis désolé mais cela parle un charabia qui est pour moi incompréhensible... Il faut que tu comprennes que les personnes de ce site ne sont pas du tout proche du domaine que tu évoques dans tes nouvelles. C'est très bien d'en parler mais cela passe en premier par une étape de sensibilisation à la matière. Il faut commencer par partager le vocabulaire et les habitudes du domaine.

Ce serait possible d'avoir la prochaine fois un paragraphe expliquant en français "de base" à quoi cela sers en pratique. Bref, des exemples pratique d'utilisation. Je crois que nous sommes nombreux a n'avoir pas compris grand chose dans l'objectif du logiciel et dans son utilisation.

Il y a aussi un avantage, chaque script est un processus indépendant... En cas de plantage, bogue, on a une très grande indépendance des services les uns par rapport aux autres.

Moi je suis pour rester simple, orthogonal, indépendant... Cela permet la robustesse mais aussi l'évolution.

Moi j'aime bien les scripts shell. On a ainsi un système souple qui se modifie facilement. Il est aussi facile de deboguer un script....

Pour moi, une grande force d'UNIX est justement d'avoir encore plein de bout de sa config qui se font en script (BASH pour la plupart). Je ne suis pas sur que mettre de la syntaxe avec du méta langage permettent à terme une telle souplesse et une telle durée de vie.

On peu avoir un init en script qui soit parallèle...

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.