Sytoka Modon a écrit 4556 commentaires

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é.

> Le Fortran il est vieux

C'est faux ! Le fortran est un des plus vieux langage mais aussi un langage qui sais evoluer donc je lui prédit encore pas mal d'année devant lui.

Avec le fortran 90, on a la notion de type, de pointeur et d'interface, avec le fortran 98, tu as les attributs "allocatable", avec le fortran 2003, tu as l'héritage simple, avec le fortran 2008, on aura les tableaux distribués... J'oublie les boucles FORALL et les fonctions PURE ainsi que la possibilités d'écrire du Fortran comme du Pascal ou de l'Ada, les fichiers d'en tête en moins. Bref, que de changement depuis les premiers Fortran. A coté, le C est un langage qui sent carrément la poussière !

Bref, le Fortran n'est pas vieux, j'ai rarement vu un langage aussi jeune ;-)

C'est pour cela que je n'ai pas pris l'exemple de SPIP ou d'autres fork libre (Inkscape, Webkit...) car dans ces cas là, le fork est libre.

Je voulais prendre l'exemple de Mosaic mais Netscape n'était pas un fork de Mosaic et je ne suis pas sur que Mosaic était libre...

Bref, j'ai pas vraiment d'exemple en tête ou je sois sur. Il y a eu des craintes je crois du coté de Nessus ou de produits de ce genre mais là, je n'ai pas le temps de faire un coup de biblio pour vérifier tout cela ? Cela me rappelle le cas de Tripwire qui a quasiment disparu et je n'ai pas l'impression que les systèmes comme AIDE l'ont vraiment remplacé.

> Il y a d'autres implémentations du protocole SSH.

Ah oui ? Lesquelles ? J'aimerais avoir une solution qui marchait 10 ans en arrière. En 2000, il n'y avait qu'OpenSSH qui marchait. Ensuite, pourquoi changer de logiciel alors que celui-ci marche bien et continue son bonhomme de chemin.

Je n'aime pas trop le ton de ton post qui sous entend que parce que c'est fait par l'équipe d'OpenSSH, alors c'est forcément mieux que n'importe quelle solution car ils sont top moumoute ! Il font du bon boulot et c'est tant mieux !

Il se sont imposé car ils étaient organisé et ont su maintenir et faire évoluer le code de ssh tout en gardant en vue la sécurité. Ils ont commencé au bon moment. A partir de ce moment là, il n'y avait pas de raison d'avoir une équipe concurrente...

Il y a quand même des "trous" dans le protocole SSH, par exemple, les clefs n'ont pas de durée de vie !

On sais que les grosses boites font un lobbying fou pour modifier les lois a leur avantage. Je ne suis pas capable de te dire dans quel sens on va mais ils essayent. Ils auraient bien aimé avoir des OS signé dans les BIOS à une époque et auraient ainsi éliminé Linux... A mon avis, c'est trop tard pour cela mais ils vont essayer autre chose.

Essayons un autre exemple. Moi en tant qu'individus, je ne suis privé de rien mais imagine qu'un groupe dont pas mal de membre travaillent dans l'éducation nationale participe à une suite office libre type BSD et qu'une grosse boite pompe le code et impose sa solution a toute l'éducation nationale ! Sur que les mecs peuvent encore utiliser leur suite chez eux mais ce n'était pas complètement leur objectifs ! Dans ce cas là, le code peut tout simplement mourrir de ne plus être nourrie !

Vie d'un code : Un code qui n'évolue pas est à terme un code mort... Le code existe toujours mais il est tout simplement périmé, impossible à maintenir car trop de chose ont évolué. Pour que le code reste, il doit vivre donc évoluer. Si la boite te bouffe toute ta communauté, tu auras perdus ton code à terme. C'est juste un exemple.

> Et bien ? Ca te prive de quoi ?

Si la société en face devient en situation de quasi monopole, si la société en face fait du lobby pour changer les lois a son avantage, tu peux tout perdre ;-(

La GPL n'empêche pas le profit, mais elle ne veut pas que le profit se retourne contre l'oeuvre originelle ni contre les utilisateurs. D'ou le copyleft.

Dans les couches bases, la licence BSD a aussi du bien car il a été montré que les industriels en utilisant le code et en le modifiant a leur usage ont finit par normaliser les usages sur internet.

Donc les deux licences sont bien, a chacun de choisir en fonction du contexte et de ce que l'on pense que sera l'avenir.

> openssh s'est imposé grâce à la BSD

OpenSSH s'est imposé parce qu'il beaucoup mieux que telnet !

S'il y aurait eu un équivalent avec version GPL de réalisé à la place d'OpenSSH à l'époque, on utiliserait tous cette version de nos jours. D'ailleurs, j'ai utilisé ssh avant qu'OpenSSH n'existe ! Il ne faut pas refaire l'histoire, le truc génial, c'est le protocole SSH et cela, ce n'est pas OpenSSH qui l'a inventé mais Tatu Ylönen.

Lors du changement de licence de SSH, l'équipe d'OpenSSH a repris la suite en partant de la dernière version libre mais cela aurait pu être une autre équipe (voir OSSH) tellement SSH était bien. A partir du moment ou OpenSSH était très bien, pourquoi vouloir a tout prix en avoir un autre ?

http://www.openssh.org/fr/history.html

A noter qu'il existe tout de même lsh, une réalisation GNU GPL du client et du serveur que je n'ai pas testé depuis des années et que sous Windows, il y a l'excellent client putty qui a ma connaissance ne partage pas la moindre ligne de code avec OpenSSH.

lsh : http://www.lysator.liu.se/~nisse/lsh/

putty : http://www.chiark.greenend.org.uk/~sgtatham/putty/

ossh : ftp://ftp.nada.kth.se/pub/krypto/ossh/

Debian a toujours fournit un gros effort coté licence pour avoir les choses les plus claires possible. Cela a coûté a quelques projets pendant un certain temps. Debian a ainsi obligé pas mal de développeur à spécifier une licence...

D'un autre coté, Debian a toujours eu son dépôt non-free car dans sa charte, il est bien précisé que c'est une distribution pour utilisateurs. Si un logiciel est bloquant et qu'il n'y a une solution non libre, il va dans non-free. C'est le cas de flash aujourd'hui.

Je préfère un flash propre dans non-free plutôt que chacun fasse son truc crade et ne mettent jamais à jour. Au moins, le .deb lorsque je le dé-installe, il ne reste plus rien d'adobe. Je ne suis pas sur de cela lorsque je fais une installation à la main...

Bref, le non-free de Debian ne fait pas tâche, il rappelle le principe de réalité et indique des points à traiter. Il montre aussi la modestie de la distribution qui malgré tous ses efforts pour faire du libre à l'honnêteté de dire qu'il y a quelques trucs important pour un certain nombre de personne et donc réalise des paquetages marqués non-free qui tu es libre ou non d'utiliser.

Je pense qu'à chaque fois qu'un paquetage est mis dans non-free, le développeur Debian doit avoir mal au coeur de faire cela. Il le fait donc par respect.

Après, tu es libre de ne pas mettre contrib et non-free dans ta liste de paquetage.

Sauf qu'il n'y a qu'un windows et qu'il y a plein de distrib linux.

Je préfère qu'adobe file un tar.gz clair et propre sous linux et que les distributions enrobe cela dans de la crème chacun de leur coté. Si le tar est propre, la moulinette pour en faire un rpm, un deb... n'est pas des plus dur à maintenir (a mon avis).

> Les développeurs pourront s'essayer à Perl 6, présent en parallèle du PHP 5.3 (pratique
> pour les montées de version)

Il faut arrêter de fumée ;-)

Je veux bien qu'il y ait aussi perl 5.10 mais je ne vois pas le rapport avec php.

C'est toi ... qui fait vieux boudeur aigris ;-)

Historiquement, Horde était le groupware, et IMP le webmail associé.

Dans le cas de Grande-Dixence en Suisse, il y avait un barrage voûte avant, qui existe toujours d'ailleurs mais est complètement noyé !

A mon sens, sauf configuration de terrain très particulière, il n'y aura plus beaucoup de barrage voûte parce que avec un barrage poids, on pousse encore les limites en terme de taille, en terme de hauteur et on place le barrage plus en aval ! Par ailleurs, on peut le faire concave... C'est pas mécanique mais c'est impressionnant.

http://www.trekearth.com/gallery/Europe/Switzerland/West/Val(...)

http://www.swissvisite.ch/component/option,com_datsogallery/(...)

Comme j'avais lu la version anglaise 1h avant, ton commentaire traduction correspondait exactement à ce que j'avais dans ma mémoire. Voila pourquoi j'ai parlé de traduction sans regarder au mot près.

D'un autre coté, une bonne traduction sais s'affranchir du texte initial pour s'adapter à la langue choisie ;-)

> ubuntu est sur la même marche que fédora et/ou mandriva.

Pas tout à fait, fedora est au même niveau que debian, c'est un des laboratoires de base d'ou dérive plein de distrib.

Il aurait mieux valu dire : ubuntu est sur la même marche que red-hat et/ou mandriva.

Mais la, le problème, c'est qu'historiquement, c'est red-hat qui était le laboratoire avant que fedora existe. Et puis, fedora, c'est quand même beaucoup red-hat. Donc la phrase ci-dessus un a un gout qui sonne faux.

Bref, ubuntu est sur la même marche que mandriva. C'est simple, basique ;-)

Son vrai petit nom est sid : Still In Developpement !

unstable est juste un lien...