Sytoka Modon a écrit 4567 commentaires

Le problème est que l'on ne parle pas ici des avantages de XML en général mais du cas particulier de subversion. Je suis d'accord pour dire que XML a des avantages dans certains problèmes mais pas dans tous.

Ici, pour subversion, il a l'air de s'agir essentiellement de sauver et recharger, par une seule application. Donc autant prendre un truc plus rapide que XML au moment ou l'API est stabilisé et marche.

Au niveau de YAML, j'aime bien l'exemple du CPAN car c'est un GROS machin avec des dépendances dans tous les sens et les fichiers descriptifs en YAML ont l'air de convenir à tous. Tant mieux.

Je l'ai sur toutes mes machines ! Je gagne donc un temps fou avec cela.

cron-apt télécharge mais n'installe pas chez moi. Par contre, je suis devant un terminal pour voir comment se passe les mises à jour. Surtout que sur les serveurs, il y a parfois des choses à reprendre, heureusement très rarement. Et puis, c'est pas vraiment un problème, avec clusterssh, je fais 25 machines d'un coup. Le jour ou j'aurais 400 machines, je reverrais ma manière de faire.

Pour les fichiers de configurations, il y a par exemple le format YAML qui est très bien, rapide et simple. Tu peux le travailler à la main (sous vi ou l'éditeur qui te plait) mais faire une couche graphique est aussi très facile.

Bref, il y a d'autres format que le XML qui sont aussi bien fichu.

Si tu te balades dans le CPAN, tu verras que tous les modules Perl ont maintenant un fichier YAML pour les décrire.

Mon choix est vite fait personnellement, je fais tous mes fichiers de configuration en YAML depuis que je l'ai découvert.

On est tous d'accord, sur la fin, la woody commençait a être viellle. Ce n'est pas encore le cas de woody.

Pour ce qui est de la stable, je suis en totale opposition. Combien de machines gères-tu ? Sur quel type de réseau ? Pour ma part, je suis sur du réseau à accès gigabits en frontal sur le net, mes machines sont toujours à jours, au minimum deux à trois fois par semaines ! Idem pour les serveurs, par exemple, la dernière mise à jour concerne gzip donc là, tu as tout ton parc à mettre à jours... (merci clusterssh)

Par ailleurs, j'utilise cfengine pour autoconfigurer les postes. J'ai donc tout intérêt a avoir un parc homogène d'un point de vue logiciel. Si j'installai un poste pour ne plus y toucher après, je ne serais pas sur à 99% que mes routines cfengine ne fassent pas le bazard ici ou là.

Ta technique ne me parait valable que pour des petits parcs qui ne sont pas en frontal sur le net avec des grosses liaisons.

Je suis 100% d'accord. D'ailleurs, je tourne de plus en plus sous noyau 2.6.16 en sarge.

Heureusement, il y a les backports. Une chose qui manque à la stable est justement une meilheure visibilité de ces backports. Nous n'utilisons ici que les backports pour le noyau (matériels récents), openoffice, firefox et thunderbird. De manière très ponctuel, et pour quelques serveurs, d'autres paquets comme le serveur ssh...

Il y a des installeurs sarge avec des noyaux plus récent (2.6.15) mais comme rien n'est officiel, il faut faire confiance...

Bref, un backports un peu plus officiel mais ayant les recommendations du backport actuel (à utiliser avec précauin et parcimonie...) avec des images aussi plus récentes pour les cas difficiles serait les bienvenues. Une bonne partie du travail est à mon avis déjà réalisées. C'est "juste" un problème de "com".

> S'il s'agissait d'une distrib déstinée aux utilisateurs de bureau, là je
> comprendrai bien, on veut les dernières nouveautés que proposent
> nos logiciels favoris, mais la branche stable ne s'adresse pas à cette
> catégorie là.

Ah bon !

Ben chez moi, tout le monde est sur stable. Il n'est pas question de mettre du testing et de l'unstable sur les postes de bureautique. Sur quelques serveurs, en nombre très limité, pourquoi pas.

Je ne vais pas faire le tour des postes de bureautique pour expliquer aux gens tous les quatre matins que tout a changé.

Bon, pour une machine perso, c'est autre chose...

Sauf que je ne souhaite pas deux nouveaux symboles mais une police où le 7 est barré, idem pour le Z même si effectivement, comme je le dis, c'est beaucoup moins utilisé. Je n'ai rien à faire de deux nouveaux symboles personnellement mais merci tout de même pour cette information.

Au niveau de l'affichage, la barre sur le 7 sera peut être moins lisible (et encore, le 'f' est lisible...) mais il y a moyen de faire propre, je fais confiance aux graphistes. Par contre, au niveau de l'impression, cela serait vraiment mieux.

Prenez un bouquin, aucun 7 n'est barré (sauf certain cahier de travail du primaire), ce n'est pas normal. Il n'y a plus aucune objection aujourd'hui pour ne pas la mettre.

Je ne sais pas pour vous, mais pour moi, le signe officiel de la division est horrible. Je préfère le slash. Quand à la croix pour la multiplication, merci les erreurs avec la variable x utilisé en math comme variable par défaut dans 90 % des problèmes. Ces deux symboles sont pour moi une plaie.

Rien à voir (quoique), existe-t-il une police où on aurait le chiffre 7 barré. Mêmes les américains nous envie notre typographie sur ce point là (enfin, ceux que j'ai croisé). Il n'y à pas à dire, la barre rend ce chiffre bien plus lisible.

Dans la même veine, pas mal de personne barre le Z majuscule (moi dans le lot). Ce serait possible d'après vous de mettre ça dans la typographie officielle ?

Normalement, avec une bonne bibliothèque partagée (.so), la mémoire de n processus ne devrait pas être beaucoup plus grande que d'avoir ces n processus compilés dans le même exécutable.

Je ne connais pas ce cas particulier (pas d'icône sur mon bureau ion) mais cela me parait une bonne piste.

C'est comme pour les problèmes mémoires de Firefox, pour moi, c'est à l'OS de gérer la mémoire et de gérer son cache pour accélérer les applications. C'est ce qui est fait au niveau des systèmes de fichier. Il y a peut être aussi une piste de ce coté là ?

Avec deux écrans, cela marche ;-)

On passe la fenêtre sur l'autre écran, on change de bureau sur le premier et on repasse la fenêtre sur le premier écran...

Bon, je sais, solution de riche !

Je ne te rejoins pas du tout.

Les grosses centrales nucléaires ne sont pas du tout souples. Tu n'ajuste pas du tout la production avec la consommation en 2 mn. C'est justement le rôle des barrages que de faire cet ajustement. Tu ouvres les vannes et tu as en quelques secondes toute la puissance nécessaire (dans la limite possible par l'installation).

C'est justement le danger d'être en aval des barrages. Une ouverture de vanne et le niveau de l'eau de la rivière peut monter quasiment instantanément. Le drame du Drac où de jeunes enfants en sortie scolaire sont décédés a malheureusement frayé la chronique il y a quelques années.

Je te trouve de super mauvaise foi. Je donne un très bon thème de reflexion que manisfestement pas grand monde ne connaissais. Bien sur, j'ai pris un des barrages les plus connu et surtout typique car Grand Maison fait partis des Grands Barrages et il a été construit exprés pour cela. Je considère personnellement que c'est le premier barrage nucléaire digne de ce nom.

Ensuite, le débat initial porte sur la part de l'hydraulique dans la production française et personne ici ne sais si la production de Grand Maison est classé nucléaire ou hydraulique ?

Enfin, il y a d'autres barrage comme Grand Maison en France, mon but n'était pas de les citer tous ici.

Qu'on fasse du thermique, de l'éolien... On a à l'heure actuelle besoin de barrage hydraulique de type Gand Maison pour stocker temporairement l'énergie. Encore une fois, je suis plutôt pour ce genre de barrage.

Cependant, au vu de la production Française, ce type de barrage est, on peut le dire quasi exclusivement nucléaire. C'est dommage.

Evidement, je sous entendais que l'on parlait de la fusion controlé par l'Homme...

Quand au soleil, je croyais que pas grand monde ne savait ce qu'il y avait au centre (idem pour les grosses planêtes de type Jupiter). Les réactions de fusion se font vers la surface à ma connaissance.

J'ai toujours eu l'impression que les chiffres Français était faussé (pour les Suisses, je ne les connais pas). On parle de 78% de nucléaire et en gros 15% d'hydraulique.

Ce que l'on oublie, c'est qu'un très grand nombre de barrage turbine à l'envers la nuit et consomme du courant. Il y a même des barrages qui ont été conçu pour cela comme le barrage de Grand Maison au dessus de Grenoble. Ce dernier barage consomme par exemple plus de courant qu'il n'en produit ! (en fait, il y a deux barages, un supérieur et un inférieur). La nuit, le courant coûtant moins cher que le jour, ce barrage est tout de même rentable. En gros, c'est une énorme batterie.

Bref, dans les 15% d'hydraulique, combien sont nucléaires ??? jamais eu de réponse claire sur ce point.

Eolienne, chauffage solaire et Pile à combustible pour les particuliers me semblent les meilheures pistes pour dimininuer fortement la part du nucléaire.

Surtout ne pas s'emballer... La fusion, on en parle depuis longtemps mais on n'a pas vu grand chose. De là à récupérer de l'energie, c'est loin, très loin d'être gagné. Enfin, vu les énergies développées dans le coeur d'ITER, rien n'assure que tu n'aura pas de la radioactivité de l'ensemble de la machine. Personnellement, je suis très méfiant. Surtout après le coup de SuperPhenix.

Pour ceux qui ne connaissent pas ce genre de vis (on est là aussi pour découvrir même si cela n'a aucun rapport avec le pingouin), il faut aller voir du coté des toitures. En effet, les tôles ondulés sont fixés sur une charpente en bois à l'aide de vis "invisable", il faut donc les frapper au marteau comme un clou. Le pas de vis ne sers que lors du démontage pour déviser la vis de son support lors d'un changement de tôle.

Il suffit par exemple de cliquer sur la colonne Date, et avoir le trie par date.

> C'est pas surprenant que les salariés fuient HP à Grenoble.

Lors du précédent plan social d'HP (2001), des salariés ont pu partir à 53 ans avec 90% du salaire ! Qui ne partirais pas...

Cet fois ci, HP a été moins généreux, mais suffisament pour avoir trop de candidats.

Bref, les employés d'HP quitte HP mais pas vraiment pour des motifs d'incompatibilité avec l'entreprise. Je ne dis pas qu'HP, c'est parfait, mais pour avoir cotoyé des employés, c'est pas l'enfer non plus.

Détrompez vous, je n'aime pas le XML et l'ai dis pleins de fois sur cette tribune.

Mais il y en a qui aime et il faut avouer que ca peut être un format d'échange de données statique pratique.

Pour en revenir au RFC, ils sont diffusés en version ASCII, effectivement lisible par tous mais je ne peux pas croire que ce soit l'original. Ce texte ASCII provient bien d'un formateur.

Si les auteurs écrivent directement le texte en ASCII, chapeau. Cela ne me serais pas venu à l'idée d'écrire des choses si longue sous ce format là. Je serais passé par un formateur : LaTeX, Groff, TexInfo...

Le texte original des RFC est sous quelle forme ? Toujours en ASCII ?

Si oui, pourquoi ne le mettent ils pas en XML ?

Si non, n'est-il pas transformable en XML puis avec des feuiles de styles XSLT, on pourrait en faire du HTML.

Merci pour cette suite qui donne pour ma part des résultats excelents.

GREYCstoration a une dépendance avec la xlib pour faire un affichage en cours de calcul. Cet affichage étant facultatif (option à mettre en ligne de commande), la dépendance est toujours forte ou faites selon le nouveau système de plugin ?

En gros, peux t'on maintenant l'utiliser sur une machine ou il n'y a pas la xlib ?

Pour les quelques paquetages qui nécessitent vraiment des versions plus récentes que ceux de sarge, il y a les backports !

Bref, la stable va encore très bien sur les postes clients et sur les serveurs.

Je ne sais pas combien de machines vous avez à gérer pour pouvoir changer tous les quatre matin de distribution ;-)

Je suis d'accord pour un récapitulatif par an papier et le reste en éléctronique.

Pour le moment, le CNRS ne m'a jamais envoyé de récapitulatif annuel ! Surprenant, c'est le premier organisme public ou je vais ou je dois moi même regarder la fiche de paye de décembre.

Sinon, en général, ces récapitulatifs sont des torchons, mais cela est améliorable ;-)

Mon pari (puisque les paris sont gratuit aujourd'hui) est que "Vista Server" aura un hyperviseur intégré qui ne tolèrera pas un autre.

Si Microsoft est sympa, cet hyperviseur ne verra que les Vista ;-) S'il est encore plus sympa, Vista Server ne tournera que dans leur hyperviseur...

Bon ok -> []

C'est pas un peu exagéré de dire que SME est dérivé de CentOS et non plus de RedHat sachant que pour moi, à ce que j'ai compris, CentOS est juste une RedHat recompilé.