Antoine a écrit 5722 commentaires

(sachant qu'au final avec mq on fait du rebase en gros)

Bof. mq est beaucoup plus puissant que rebase, qui se contente de linéariser l'historique. Avec mq, tu empiles des patches que tu peux reprendre à ta guise, etc. Rien que la liste des commandes fournies par mq devrait te faire comprendre qu'il y a un fossé entre les usages des deux extensions.

Étant donné que la plupart des utilisateurs de Mercurial se passent de rebase (malgré sa disponibilité sous forme d'une extension), je crois que c'est assez exagéré de présenter ça comme une fonctionnalité tueuse :)

L'ironie c'est qu'OpenSSL fournit des contre-mesures par défaut, mais beaucoup d'utilisations d'OpenSSL les désactivent en utilisant l'option SSL_OP_ALL (censée améliorer la compatibilité avec les implémentations SSL buguées, et recommandée en tant que telle).

Là où ça devient surréaliste c'est la doc OpenSSL qui dit que “It is usually safe to use SSL_OP_ALL to enable the bug workaround options if compatibility with somewhat broken implementations is desired” (*). Une documentation exacte ne devrait pas être un luxe.

((*) c'est moi qui souligne)

Ce que je voulais pointer, c'est que les prix sont encore plus hauts à cause du CD/DVD "offert".

Je ne pense pas qu'un CD/DVD coûte 2€50, c'est probablement que dalle à presser en série.
À vrai dire, vu l'abondance de ressources en ligne concernant le logiciel libre (tant en documentation qu'en sources d'actualité), j'imagine difficilement la viabilité d'un magazine papier avec ses coûts de réalisation, d'impression et de distribution.

Il vaut mieux utiliser (plusieurs passes d')un algo particulièrement lent que MD5 ou SHA qui sont conçus pour être rapides.

Oui, enfin il faut quand même un algo suffisamment robuste pour que la seule attaque possible soit la force brute.

Ça dépend aussi de la résolution de ton time(). Si tu inclus des nanosecondes, ça devrait limiter la prédictibilité.

Ce n'est pas seulement qu'il est lent, c'est qu'il est limité et fragile (pour les mêmes raisons).

D'où l'intérêt de rester en IPv4 qui fait augmenter (quelque peu) les chances :-)

Non, la valeur n'a rien à voir avec "le prix auquel on est prêt à acheter" quelque chose. Les bulles spéculatives sont là pour en attester.
À ce sujet, écouter l'éclairante conférence de Frédéric Lordon, « ce que la valeur esthétique fait à la valeur économique » :
http://www.dailymotion.com/video/xmk3e6_frederic-lordon-ce-que-la-valeur-esthetique-fait-a-la-valeur-economique-spinoza_news

Ce sont ces points qui mériteraient un appel au don car ils ne seront jamais faits gratuitement contrairement à des choses plus motivantes...

C'est une idée fausse. La doc de CPython est faite entièrement par des bénévoles : http://docs.python.org/dev/
Et l'API C y est dûment documentée :
http://docs.python.org/dev/c-api/index.html

J'ai été capable d'implémenter 2 fonctionnalités de Python 3 dans PyPy sans avoir toucher a un interpréteur avant.

Tant mieux.

L’exécutable a peu de chances de crasher car on le fait tourner d'abord au dessus d'un interpréteur Python avant le build pour vérifier que tout fonctionne.

Fais-moi confiance, ça arrive.

Un développeur web est censé suivre les standards. C'est son job de faire en sorte que son site (public) soit lisible partout

Non, ça c'est ta vision de ce que devrait faire un développeur Web. Je vois bien que ça t'embête (ainsi que cette andouille que Glazman) que certains développeurs Web raisonnent différemment, et je partage la préoccupation de fond concernant l'interopérabilité du Web. Par contre l'attitude consistant à culpabiliser les développeurs alors qu'ils utilisent des extensions implémentées par les éditeurs (eux-mêmes membres du W3C) est d'une lâcheté incroyable.

Si vous aviez un semblant de courage politique, vous porteriez le fer là où est le problème : dans l'attitude des éditeurs qui, je te cite, « implementent les trucs BIEN AVANT de proposer des specs au W3C ».

des trucs experimentaux. LES DEVELOPPEURS NE SONT PAS CENSES LES UTILISER

Oui, oui, bien sûr. Les trucs sont publiquement disponibles, certainement documentés, bref tout est fait pour que les développeurs puissent les utiliser, mais ce sont les développeurs les méchants car ils les utilisent !

Décidément, il n'y a pas pire aveugle que celui qui ne veut pas voir.

Les gens qui se plaignent et ceux qui développent les navigateurs ne sont pas forcément les mêmes personnes :)

Non, mais c'est la même organisation, à savoir le W3C (par la voix d'un de ses représentants). Ce qui rend la complainte bien hypocrite.

C'est vrai pour la chaîne d'outils mais pas pour l’interpréteur

Pourtant, j'ai touché à l'interpréteur et c'était un joli bordel. Le seul point qui aide un peu, c'est que l'architecture interne de l'interpréteur reprend souvent celle de CPython (mais en largement plus confus, et sans docs).

Il n'y a pas besoin de traduire l’interpréteur la plupart du temps, seulement pour savoir si le code peut être traduit, et le build crash dans les 5-10 premières minutes rarement après

5-10 minutes d'attente après chaque modif, c'est déjà énorme (compilation incrémentale de CPython : quelques secondes, selon le fichier modifié).
Mais quand le build réussit et que l'exécutable produit crashe, c'est le pompon : 30-60 minutes de rebuild par itération.

Quelques raisons en vrac :
- PyPy n'est pas (encore) compatible Python 3
- l'écosystème n'est pas prêt (extensions C, par exemple, ou bien la possibilité d'embarquer l'interpréteur)
- il est difficile de rentrer dans le code de PyPy (touffu, très peu documenté ni commenté, y compris RPython lui-même)
- le système de build peut rendre fou (traduire l'interpréteur en code natif prend 30 à 60 minutes, et il n'y a pas de traduction incrémentale)

Visiblement, GNOME 3 s'oriente vers une délégation de la gestion de l'agencement des infos au applications elle-même. C'est pas idiot.

Si, c'est complètement stupide dès que tu utilises plusieurs applications à la fois. Exemple : un éditeur de texte + une terminal.

Des esclaves de qui ? Dans quelle société ?

Il est vrai qu'il est rare qu'un auteur cède son droit moral.

C'est d'autant plus rare que c'est impossible.

il est clair qu'un utilisateur d'un logiciel libre en est aussi le propriétaire

Non, Zenitram a raison (*) : tu as tordu la définition de la propriété (tes interprétations entre parenthèses pour chacun des points) afin de parvenir à ta conclusion.

Démonstration par l'absurde: si tu étais propriétaire de ta copie, tu aurais autant de droits sur cette copie que l'auteur n'en a sur l'original (dont, lui, est « propriétaire »). Or ce n'est pas vrai : tu as moins de droits que lui. Donc tu n'es pas propriétaire de la copie.

(*) incroyable !

ET donc on en arrive à avoir des sites "optimisés pour webkit". Bref, c'est le nouveau IE6, avec toutes les conséquences que l'on connait.

Si j'utilise disons une fonction non-POSIX, mon but n'est pas de faire chier un organisme de normalisation mais de satisfaire un besoin. Le jour où POSIX inclut une fonctionnalité équivalente, eh ben tant mieux : je peux migrer mon code vers une API plus portable.

De plus, des gens comme google ou apple, implémentent des propriétés en -webkit-, sans soumettre les spécifications au W3C. Tu veux que le W3C fasse quoi fasse à ça ?

Je ne m'attends certainement pas à ce qu'il fasse des communiqués pour culpabiliser les développeurs ! Si les éditeurs en question décident d'implémenter les propriétés et que les développeurs décident de les utiliser, c'est qu'il y a un besoin. Au W3C de les fournir à la nouvelle itération et tout le monde sera content. En attendant, qu'ils évitent de la ramener...

tu sembles ne pas connaitre le fonctionnement du W3C, alors je vais te l'apprendre : les membres d'un groupe de travail, comme le CSSWG, sont composés... d'employés des sociétés qui fabriquent les navigateurs

Je ne vois pas pourquoi leurs problèmes d'organisation interne les autorisent à incriminer les développeurs Web qui, eux, n'y sont pour rien.

L'argument jésuitique qui consiste à dire que les développeurs sont coupables alors que c'est 1) le W3C qui définit les standards 2) les éditeurs membres du W3C qui écrivent les implémentations (y compris les extensions), c'est du foutage de gueule.

Le problème se pose massivement sur les navigateurs mobiles, où webkit domine très largement, car il est le navigateur par défaut des appareils iOS et Android. Daniel Glazman, co-chairman du CSS Working Group, a donc lancé un appel, avec l'appui du CSS Working Group.

Donc, le « problème » c'est que les développeurs Web essaient de résoudre les besoins qui se posent à eux ?
Il n'est pas un peu gonflé, Daniel Glazman co-chairman du CSS Working Group avec l'appui du CSS Working Group ? S'ils se sortaient les doigts du cul pour répondre aux besoins des développeurs, peut-être que ceux-ci n'auraient pas besoin d'extensions. Un standard est là pour suivre l'évolution de l'écosystème, pas pour jouer les pères-la-morale.

Sérieux, pourquoi pas râler contre le fait que Linux offre des appels système en plus de POSIX ?

D'accord, mais utiliser une ligature ou pas ("ff") n'a pas d'incidence sur l'orthographe.

LES ROMAINS NE CONNAISSAIENT PAS LES MINUSCULES, TOUT ÉTAIT ÉCRIT EN MAJUSCULES.

(cf. http://fr.wikipedia.org/wiki/Alphabet_latin)

Je ne sais pas ce que tu appelles une "lettre" exactement, mais majuscules et minuscules sont bien des symboles distincts sur le plan de la langue : il y a des règles orthographiques qui gouvernent leur usage (si j'avais commencé cette phrase par "je" au lieu de "Je", ç'aurait été une faute).

J'imagine même pas combien d'applications cela casserait.

Pourquoi régler le umask correctement casserait-il quoi que ce soit sur un hébergement où les utilisateurs sont censés être totalement cloisonnés les uns des autres ?

Ce qui est parfaitement idiot puisqu'une ligature n'est pas une lettre, juste un enjolivement graphique.