totof2000 a écrit 9656 commentaires

Plus sérieusement, étant donné l'architecture complètement différente des itanium par rapport aux x86, je ne suis pas certain que l'on puisse transposer le gain en performances entre les architectures…

Soit, mais l'idée est surtout d'illustrer le fait que dire "l'hyperthreading ne sert à rien donc désactivez-le" est un peu radical. Il faut voir au cas par cas, selon la façon dont les applis utilisent les CPUs. Dans ce cas précis, les projets nous soutenaient que l'HT n'apportait aucun gain de perfs, et ils ont freiné jusqu'au bout pour l'activer. Ils ont passé leur temps à demander l'achat d'1 module CPU supplémentaire. Au final, on a testé et on s'est rendu compte des gains de perfs, et l'hyperthreading a été activé. La raison pour laquelle ils ont freiné? C'est tout simplemment parce qu'ajouter une carte leur coutait moins cher à eux (le cout ne leur était que faiblement refacturé), alors que l'actiation du HT faisait monter leur cout de licence.

De plus, selon les logiciels utilisés et le niveau d'optimisation atteint (utiliser complètement le CPU d'un itanium semble être un art obscur) tu pourrais avoir un terrain bien plus favorable à l'HT.

C'est pour ça que j'ai précisé que j'ai constaté ce gain de perfs dans un contexte donné. D'ailleurs, j'avais d'autres applis qui tournaient sur des machines sur lesquelles on avait délibérément désactivé l'HT parce que ces applis ne bénéficiaient que d'un léger gain de perfs (moins de 10%). On aurait pu le laisser parce que finalement 10% c'est toujours ça de pris, mais l'activation de l'HT aurait entrainé des surcoûts de licence.

Pour ma part, j'ai constaté une amélioration de perfs de 20 à 35% sur des traitements effectués sur des serveurs Itanium à une époque ou j'administrais encore ce genre de machines.

Bof, depuis l'arrivée des liens, on a pas mal perdu en réflexion je trouve.

1/ eh oui, ça arrive de rechercher la cause d'un dysfonctionnement en prod, ne t'en déplaise: tous les bugs ne peuvent être reproduits en environnement de préprod, et en pratique, on n'en a pas toujours sous la main. C'est la vraie vie, ça.

2/ parfois sur des machines, je n'ai pas de vim mais nano, ou alors, une version de vim qui n'inclue pas la coloration syntaxique (ubuntu par exemple), sans avoir la possibilité d'installer autre chose. Et surtout pour visualiser un fichier je préfère des commandes telles que less par exemple (ça évite la modification accidentelle des confs).

J'ai l'impression que tu fais expres de ne pas comprendre : sur une machine de prod, quand un truc ne marche pas, je dois parfois aller voir le contenu du fichier installé pour savoir s'il est conforme à ce que j'attends, et pour faire ça, je n'ai pas forcément la possibilité d'utiliser un éditeur à coloration syntaxique.

Et je vais arrêter là, la discussion est stérile.

Dans la mesure ou tu es à côté de la plaque, c'est sur.

que tu as de la coloration syntaxique

Non : en prod, ça m'arrive de déployer des VMs avec un envirponnement très restreint, sans éditeur me fournissant une coloration syntaxique. Imagine le délire lorsqu'il faut débugger une conf xml.

J'aimerais bien voir des cas concrets de ce genre de truc, parce que jusqu'à maintenant, je n'ai jamais vu (je ne dis pas que ça n'existe pas).

Le mot que tu cherche c'est verbeux, ça n'a rien à voir (même hors langage informatique).

Ah ben si quand même, surtout dans le cas qui nous concerne : la verbosité xml rend les fichiers xml difficile à lire. Ce n'est pas la seule raisn qui les rend difficile à lire (pour un humaion), mais ça y joue beaucoup.

Bof …. Se prendre la tête et la tête des utilisateurs avec un xml illisible juste parce que potentiellement un éditeur de conf va avoir besoin de l'éditer … hum. En fait xml me pose des problèmes avec Ansible, et à l'époque ou je me suis intéressé à spacewalk, c'était la grosse galère pour gérer les confs xml également. Donc pour moi c'est un faux problème. Enfin, la gestion du xml avec un gestionnaire de conf me pose aussi de gros problèmes, pour des pseudos avantages que tu cites mais qui en pratique n'existent pas.

Arrêtez les conneries les gars : un xml, c'est illisible. En plus c'est imbitable quand tu fais des diffs avec un gestionnaire de version tel que git. Je suis confronté à Maven ici au taf, et j'ai aussi à bosser avec du yaml, et définitivement, yaml est bien plus lisible que xml.

Pour moi, le gros défaut der Maven, c'est le XML : ça rend le truc difficile à lire et à comprendre.

plus moderne

Je ne vois absolument pas ce que vient faire la "modernité" entre nohup et screen : ces outils répondent à deux besoins différents, qui n'ont rien à voir avec la modernité. J'utilise les deux solutions en fonction des circonstances : nohup lorsque je ne dois pas avoir d'interactivité avec ce que j'exécute, et un screen lorsque je dois avoir de l'interactivité avec ce que j'exécute.

Tu pourras choisir sereinement et te familiariser avec la distribution.

Normal, puisque tu ne fais le print que s'il y a remplacement. Il faut que tu sortes le print du bloc qui est exécuté lorsque tu rencontres la chaine 'PAR'.

Ensuite, ta regexp dans le gsub me pose un petit problème: dans ton cas, tu lui demandes de remplacer tous les chiffres de ta colonne par "3027008440109". Si tu as 3 chiffres, il va te reproduire 3 fois la chaine ""3027008440109"". Est-ce bien ce que tu veux ?

exemple :

 echo ' a b c 1234' | awk '{ gsub (/[0-9]/,"azert", $4);print }'

Mieux, si tu dois remplacer systématiquement la colonne , tu fais un truc du genre:

echo "a b 1234" | awk '{$3 = 42 ; print }'
a b 42

Dans mon exemple je remplace systématiquement la colonne 3. Dans ton cas, remplace le gsub par $8 = valeur_que_tu_veux_forcer dans ton expression.

Je suppose une erreur dans le gsub : que veux-tu faire exactement ?

chez moi :

$ echo "a b 1234" | awk '{gsub("[^0-9]","42",$3) ; print }'
a b 1234

Par contre un truc du genre :

$ echo "a b 1234" | awk '{gsub("^[0-9]*","42",$3) ; print }'
a b 42

ferait mieux l'affaire

tu as supprimé le print, pourquoi ? C'est normal dans ce cas que tes fichiers soient vides :)

Pour être plus précis: si j'ai bien compris, l'option inplace permet de modifier directement le fichier par awk (un peu comme l'option -i de sed). Mais à cause de l'UUOC, awk ne connait pas le fichier que tu veux modifier : il prend ses données depuis stdin.

Encore une raison de se débarasser de ces sales UUOC.

for i in *.txt remplacera avantageusement le for i in ls *.txt, de meme que awk ' ….' $i remplacera cat $i | awk …

Faut sortir de ta cave, on n'est plus en 2003, on est en 2018, la plupart des gens qui étaient dans les hautes sphères de MS sont parties. La boite n'est plus la même.

Bah, d'autres peuvent revenir à leur place. Dans la même veine, qui aurait pu dire il y a trois ans, que les US iraient surtaxer l'acier importé par ses partenaires ?

Ca ne me choque pas à partir du moment ou CVS répond à leur besoin.

Comme je l'ai dit plus haut, le vol de code n'est pas le seul danger : une entreprise qui sait ce que tu déveloippes en interne peut adapter sa stratégie pour te passer devant, sans voler une seule ligne de code.

Dans le cas de GH/Microsoft, si Microsoft va lire le code source d'un concurrent, c'est une violation de contrat assez lourde.

Certes, mais ce ne sont que des mots : en pratique :
- qui pourra l'en empêcher ?
- comment pourra-t-on le détecter ?

une boite qui se fait voler le code source par son hebergeur qui a dit "je le ferait pas", c'est une autre paire de manche, parce que tu as 2 entités avec de l'argent des 2 cotés, et un contrat clair qui dit "on va pas faire ça".

Encore une fois, ce ne sont que des mots. De plus le 'vol' de code n'est pas le seul riqsque : tn code peut révéler des infos sur la stratégie de ta boite, et sans voler de code, un concurrent comme Microsoft saura ou mettre les moyens en interne pour te passer devant.

Tout ça a un coût et ne sont pas forcément des compétences que tu as en interne.

A la limite, une boite qui développe du libre peut externaliser le code car de toute façon, celui-ci sera accessible tôt ou tard, d'une façon ou d'une autre, mais une boite qui développe son business model sur la propriété intellectuelle et sur du code fermé a intéret à investir dans ce genre de compétences, ou elle devrait changer de business model.

Par contre, une chose que personne n'a accès publiquement, ce sont les milliers de dépôt privés de sociétés petites ou grosses, dont certaines probablement des concurrents directs. Microsoft va avoir accès à des milliers de "secrets industriels".

C'est aussi la réflexion que je me suis faite dans le train ce matin, après avoir posté ce commentaire. Et ce rachat pose la question de l'externalisation de ses données.

Avec le rachat de github, des sociétés potentiellement en concurrence avec Microsoft peuvent se faire du souci. Mais d'un autre côté, il faut se poser la question pour toutes les données qu'on externalise. Pour ma part je trouve aberrant que des boites externalisent leur messagerie à des tiers. Je suis peut-être le seul à penser ainsi, mais supposons qu'une grosse banque a externalisé sa messagerie ches Microsoft, et que demain, Microsoft décide de revendre son service d'hébergement à une banque concurrente, ou qu'une banque concurrente vienne à prendre des participations dans le service de messagerie de Microsoft ?