Sytoka Modon a écrit 4546 commentaires

Google ne peut pas modifier les sources d'IE alors qu'il peut sans problème proposer des patch pour Firefox.

Mauvaise réponse, Qt n'est pas en standard sous Windows... Donc si tu met Qt, tu peux mettre la librsync dans le paquetage que tu distribues.

> Qu'est ce qui garanti que seules des personnes autorisées à accéder au réseau de la
> boite ont accès à ton serveur externe, et donc au tunnel ?

Auncun. Dis donc, mon serveur, il est pour tous les gens de mon labo, pas seulement pour ce contrat avec cette boite. Si la boite veut un accès exclusif, qu'elle achète son serveur et les logiciels qui vont avec !

Cela dis, ça ne leur pose aucun soucis car encore une fois, un accès via ajaxterm est en pratique équivalent, en plus chiant pour l'utilisateur, a un accès via ssh.

> Dans les faits, si c'est un peu la mort :) il faut réserver des IP fixes

Désolé, je ne marche qu'en IP fixe... Effectivement, si chez vous, tout le monde change tout le temps, je comprends que vous ayez des soucis. Chez moi, une machine a toujours la même IP. Une IP, cela se spoof par une personne malveillante mais il y a alors un acte conscient, réfléchi et donc faute grave en regard du règlement intérieur.

> L'équipe en charge de l'infra à souvent d'autres chats à fouetter que de gérer ces
> accès qui découlent le plus souvent d'une organisation a l'arrache

Tu mélange deux choses. Déjà, pour moi, le service informatique est au service de la recherche donc des utilisateurs et non l'inverse. Ensuite, il y a un contrat de collaboration. Que je sois d'accord ou non est une autre chose. Ce contrat a été signé par les directions, donc je le met en place si techniquement cela est possible.

Parce que les DSI sont coincés pour ouvrir un port en sortie vers une SEULE ip fixe (IP Renater, fonction publique, risque effectivement MONSTRUEUX pour la boite !), je me fais chier à monter un serveur Apache + AjaxTerm. Votre incompétence en terme d'organisation dans vos DSI, avec le poids des lourdeurs et le fait de ne rien ouvrir fait qu'heureusement, il y a des gens comme nous qui ouvre quand même pour qu'à la fin, cela marche.

Mais cela me prends un temps fou et ce sont mes utilisateurs qui trinquent.

Toi, tu es dans ta tour d'ivoire... Tu as l'impression de ne pas avoir pris de risque mais tu m'as tout reporté sur moi pour que notre contrat de collaboration marche. Au final, le risque global toi + moi est bien plus élevé mais tu t'en fou car ta petite DSI pourra dire que rien ne passe et que vous tournez toujours avec votre firewall à 10 règles ! Mais tu te mens en passant puisque en pratique, tu acceptes du SSH sur HTTP...

Combien de gens dans ta boite commence a utiliser leur iphone ou équivalent dans le cadre du boulot ? Maîtrise-tu ce nouveau réseau ? A force de trop fermer, moi je dis que vous allez vous prendre un réseau parallèle sans vous en rendre compte.

> OK, on a qu'a laisser les machines en direct faire ce quelles veulent sur internet,

C'est la réponse classique des DSI quand je dis cela !

Il y a une différence entre tout bloquer et bloquer intelligemment. Pour ce problème, il aurait du autoriser la machine interne X a venir faire du SSH sur mon serveur Y. La personne faisant des aller et retour physique entre les sites X et Y, elle peut déjà transporter autant de données qu'elle le souhaite en pratique.

Ouvrir vers un nombre finie et limité de machine en sortie quelques protocoles non HTTP, ce n'est pas la mort, c'est aussi savoir quels sont les besoins et savoir un peu ce qui passe. Tout mettre dans du HTTPS, c'est se rendre aveugle.

Mais les DSI ne veulent pas gérer des règles de firewall variable et les maintenir dans le temps ! Donc on ferme tout. A ces gens là je dis, attention à la 3G, vous allez vous amuser avec les ponts ;-)

Baladeur est passé dans le langage courant mais au moment de sa sortie, c'était pas gagné et franchement, baladeur faisait bizarre et sonnait pas alors que walkman parlait à tout le monde.

Comme quoi, je pense qu'il faut laisser du temps au temps pour que le concept derrière un mot trouve sa signification.

Oui, mais.

Mais il y a les timeout, même sur tcp, donc ta connexion sur le flux RSS ne durera pas 5 jours s'il n'y a des posts que tous les 5 jours. Donc pour la maintenir, il faudra de temps en temps qu'un paquet circule pour dire que tu existes encore.

Tout cela pour dire qu'une connexion pour qu'elle se maintienne doit avoir un certain flux, même si on n'a rien a se dire.

Si les specs ne sont pas implémentés rapidement dans Apache et Firefox, elles ne servent pas à grand chose à court terme...

Justement, est-ce que Google participe au développement d'Apache car a vrai dire, leur serveur à eux, on s'en "fou" un peu !

Je travaille avec un boite qui interdit ssh en sortie pour soi disant des questions de sécurité. Bilan, ils me demandent de monter un serveur web avec ajaxterm pour pouvoir avoir un accès à une console sur mes machines de calcul !

Avez-vous plus confiance dans le couple Apache+AjaxTerm qu'en OpenSSH ?

Pour moi, une grosse partie des DSI sont responsables d'avoir limité internet au port 80 et 443 et de limiter en plus cela au HTTP ! A limiter le nombre de protocole, on complexifie HTTP.

Un jour, le firewall HTTP sera indispensable et on aura des cartes réseau qui feront les calculs "offload" du HTTP pour ne pas surcharger les machines ;-)

> Logram n'est absolument pas une distribution à vocation serveur. Sur un serveur, installez
> une Debian,

Le problème est que sur un parc important, je veux avoir la même distribution sur les serveurs et sur les postes de travail pour gagner du temps.

Donc, il me faudrait une Logram dérivée de debian au minimum ;-)

DAV, c'est bien mais le peu que je l'ai utilisé, ce n'est pas imaginable de transférer 10000 fichiers et 600Go de fichier avec.

J'avais essayé il y a quelques années de faire un serveur HTTP/DAV avec apache et c'était d'une lenteur insupportable. Bref, intenable en production sur des gros fichiers.

Quelqu'un utilise le WebDav sur un vrai serveur de fichier, avec une utilisation normale ?

Il y a aussi le FTPS ou le FTP sur SSL, a ne pas confondre avec le SFTP (module dans SSH).

Avec FTPS, tu peux chiffrer les deux canaux ou seulement l'un des deux. Donc tu peux chiffer le canal de controle ou passe le mot de passe et le login mais pas le canal de données. C'est très intéressant.

Je connais des boites qui sont a 100% pour de la sécurité, HTTPS partout... et qui t'envoi pas mail des documents top secret !

Bref, FTPS, permet de résoudre le problème du mot de passe en clair tout en profitant de la bande passante du FTP ou effectivement, très souvent, on n'a pas besoin de chiffrement.

Dernier exemple, je dois rapatrier 600Go de données non archi secrete de l'IDRIS sur une de mes machines, je reste a 100% sur le réseau Renater. Le FTPS avec le seul chiffrement du canal de contrôle est une solution intéressante.

Je le fais très rarement mais par exemple en bash en début de script, il m'arrive d'écrire


commande=$1; shift

Ainsi, on vide la pile d'un élément en même temps que la copie. Je trouve cela moins dangereux que de mettre le shift à la ligne suivante ou on se demande bien ce que viens faire ce truc la !

Cela me rappelle le ColorForth par Chuck qui est un Forth colorié avec encore moins de symbole. Cela pose des problèmes à l'impression et puis, à force de trop réduire, cela n'est pas forcément plus lisible.

La couleur est un plus mais ne doit pas être essentielle (en plus, il y a des daltoniens en nombre non négligeable).

Spice c'est génial, Spice c'est ceci... Moi, j'attend de voir dans la vraie vie et pour le moment, je ne connais personne qui a vu pour de vrai sur son poste de travail.

NX, ca existe, c'est libre depuis des années et cela marche. Merci NoMachine d'avoir montré qu'on pouvait optimiser le flux X-Window alors que plus personne n'y croyait !

D'ou le fait de pouvoir définir en Fortran ses propres opérateur comme .scalar. qui ne porte pas à confusion car effectivement, la surcharge de l'opérateur * est souvent un enfer pour les relecteurs.

Ensuite, une formule de Math doit avoir des paranthèses dès que l'on dépasse quelques opérations car la aussi, l'interprétation ne doit jamais être confuse. Même sur le papier, je met des parenthèses...

En calcul numérique, on a trop souvent un code qui tourne mais avec un mauvais résultat. Il faut donc que les formules soit le plus facile à contrôler pour éliminer les bogues le plus facilement possible.

Je trouve que la solution des pointeurs du Fortran sont une bonne solution. On ne les déférence jamais, on n'accède jamais à l'adresse et donc pour les affecter, on utilise un autre opérateur que le = (ou le :=), mais dans ce cas là, le =>.

Au final, je trouve que cela fait un code bien plus simple que du code C (ou Ada) pour finalement avoir ce que l'on veut.

Sinon, pour les opérateurs, Fortran a aussi une bonne chose avec les opérateurs de la forme .machin. car cela permet d'avoir autant d'opérateur que l'on veux et pas que des signes cabalistiques dont on ne connaît plus la définition ensuite. Par exemple, il est assez facile de faire un opérateur .scalar. qui prend deux objets et retourne toujours un réel (produit scalaire) alors qu'avec l'opérateur *, on ne sais jamais de quel multiplication on parle...

Bref, les opérateurs du Fortran permettent d'écrire des formules en infixés comme souvent en math et donc que la formule dans le code soit le plus proche possible de la formule de la définition.

Cela est parfait dans le cadre du calcul numérique, ce qui n'est pas forcément le cas aujourd'hui de la majorité des codes que l'on manipule. Mais limiter les opérateurs aux seuls symboles est je trouve dommage.

Pour le dessin, graphivz doit faire cela.

Vu que je pense que 99% des installations tournent encore sur la version 2, je ne suis pas sur qu'il y ai beaucoup de personne déjà très compétente sur la version 3 en Europe. Mais je me trompe peut-être (et je souhaite me tromper).

OAR est un batch scheduler développé en partie par l'INRIA. Quel est ou quel pourrait être les liens entre hwloc et oar ?

http://oar.imag.fr/

J'utilise moi aussi backuppc et les gains sont très faible ;-( Enfin, j'en conclue que mes chercheurs cherchent et que pas grand monde copie sur le voisin !

Sinon, je ne vois pas l'intérêt d'avoir des backup complet et incrémentaux dans backuppc. Cela prends du temps pour rien. Pourquoi ne pas avoir que des backup incrémentaux et mettre à jour la dernière version comme version complète.

Un mail est un mail, il n'y a qu'un seul fichier qui est répartis sur 1 ou plusieurs blocs. Le fichier commence par l'en tête et celui-ci sera différent pour chaque personne. Ensuite, comme dis plus haut, le décalage se poursuit pour tous les block suivants, qu'il y ait des pièces jointes ou pas.

L'en tête n'est pas le même... Le champ "Envelope-to" change pour chaque destinataire.

Bref, c'est une belle idée mais je ne sais pas ce qu'elle fait réellement gagner en pratique.

Chez nous, a part quelques trucs qui trainent encore en 77, tous les codes sont en Fortran 90 et les étudiants en thèse s'en sortent pas mal (ce ne sont pas des développeurs).

Pour le Fortran 2003, c'est vrai que les compilos n'ont toujours pas sortis l'extension sur l'héritage simple et pourtant, c'est pas si compliqué que cela, l'héritage simple, un CAST suffit ! Lorsque j'avais encore le temps de programmer, 1999, je faisais déjà de l'héritage manuel avec Fortran 95.

Un des problème de l'objet dans le calcul parallèle, c'est que c'est lent car souvent les attributs de deux éléments peuvent être loin en mémoire contrairement a une programmation plus "matricielle". Une voie pour s'en sortir serait peut être que le compilateur stocke les objets sous forme inversé, comme il est possible de le faire en Perl5. En objet inversé, les attributs sont stocké dans la classe et non dans l'objet ! C'est un peu bizarre comme concept au début mais, comme en Perl 5, on peut faire comme on veut, cette méthode s'avère pour le Perl assez redoutable ;-) Je ne vois pas comment on pourrait rendre cela efficasse pour un langage compilé comme le Fortran mais bon, j'aime bien ce concept d'avoir tout inversé.