Sytoka Modon a écrit 4546 commentaires

Il y a une fonctionalité super avec svn, c'est le HTTP (ou HTTPS). Un dépot et tu explore la dernière version de ton dépot avec un simple navigateur sur l'url du dépot. Un petit xsl te transforme le XML du serveur en html tout bien jolie.

Question : pourquoi le XML que le serveur SVN génère a si peu d'information. On a le droit d'avoir en double le nom du fichier, donc une fois de trop, mais pas le poids (taille) du fichier, la personne qui a réalisé la dernière révision, ni la date de modification.... Bref, pas mal d'information accessible facilement en ligne de commande.

Avec ce type d'information, en modifiant un peu le filtre xsl fourni, on pourrait avoir un affichage avec un navigateur du même type que celui que donne Apache d'un dossier. L'utilisateur lambda ne verrait même pas qu'il a affaire à un gestionnaire de version.

C'est aussi cela qui me plait avec SVN, c'est qu'il arrive à se faire oublier et que l'on peut avoir l'impression de travailler sur des dossiers comme les autres.

Dans le même ordre d'idée, un module fuse : "svnfs", me paraît complètement indispensable ;-)

Rien à voir, quoique...

Je me suis amusé à faire un partage WebDav avec autoversionning subversion. C'est la meilleure méthode que j'ai trouvé pour faire du WebDav avec une gestion, modeste, des droits sur les fichiers (Je dis modeste car il y a quasiment toutes les briques pour faire avec svn la grande mode actuelle : les bureaux virtuels. Mais pour en arrivé là, il faut que le client puisse gérer les droits).

Les utilisateurs montent cela sur leur postes, Windows, Mac, Linux. Et là, le problème des Mac avec la pollution des dossiers que ces bestioles génèrent...

D'où ma question : est-il prévu dans svn d'avoir des hooks tout près à l'emploi qui élimine dès le commit ces fameux, et pour le moins épouvantable, fichier spécifique au Mac ? En effet, je ne dois pas être le seul qui a un repository complètement pollué par ces fichiers.

Justement, sur un parc conséquent, de plus en plus de personnes n'y connaissent rien en administration système, et cela est normal. A chacun son boulot.

Je ne comprends pas pourquoi tu cherches a avoir un état de sid qui te convienne pour le distribuer sur un parc. Ton truc ne sera jamais maintenable dans la durée. C'est justement ça : une stable. Une stable est juste une sid sans bogue à un instant donné qui est ensuite suivis.

Pour avoir des machines qui ont eu la slink, puis la patate, puis la woody, maintenant la sarge et qui risque de finir leur vie sur etch, la période de transition d'une version à l'autre n'est pas toujours triviale, même si debian est pour cela exemplaire. Cela ne marche pas à tous les coups et ça prends du temps.

Ensuite, l'idéal est effectivement d'avoir un parc homogène comme cela tu essayes sur une machine et tu propages. Malheureusement, je n'ai pas de parc homogène, les seuls que je connaisse qui ont des parcs très homogènes sont ceux qui gèrent des salles de cours pour les étudiants. Dans ces cas là, oui, c'est plus facile. Même au niveau des secrétariats d'administration, c'est assez hétéroclite, surtout en ce moment où avec le même nom, deux machines ayant six mois d'écarts sont très différents (je pense notament au DELL Optiplex GX620).

Enfin pour finir sur l'utilisateur qui n'y connais pas grand chose, que tu lui mettes gnome 2.14 ou gnome 2.16, il s'en fiche un peu. S'il ne connait que la version 2.14, cela lui conviendra tout à fait (en plus, elle est pas si mal cette version). J'ai même eu des personnes qui ne voulaient pas openoffice2 car ils ne voulaient pas changer leur habitudes et la version 1 leur allaient.

J'ai par ailleurs vu des développeurs qui en ont marre que leur code ne compile plus tous les mois à cause d'une bibliothèque qui change sans cesse et qui, après avoir été "bleeding edge" quelques temps, me demande une stable bien stable (qui surtout ne bouge plus).

Bref, faut presque se battre pour avoir le droit d'installer juste les mises à jour de sécurité ;-)

J'ai même testé pkgsync sur un poste. C'est radical d'efficacité !

Le problème est que ca ne marche pas toujours... Dans mon boulot actuel, nous sommes sur plusieurs bâtiments. Il est donc pour moi hors de question de faire le tour des postes de travail le matin en arrivant.

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 ?