Stéphane Bortzmeyer

Quand même ça me rassure : je ne suis pas le seul à faire des démons et services critiques en PHP ^^ (et ça marche incroyablement bien)

@bohwaz J’espère que tes services critiques sont moins vaporware que ce truc :-)

Concernant la réponse de l’auteur, @stephane, tu es de mauvaise foi. En effet, celui-ci explique pourquoi il ne donne pas de réponses, et de même pourquoi il trouve tes propos à l’égard de ton article déplacés : le logiciel est en version alpha privée, et sa version beta publique sera dévoilée à partir de la semaine prochaine. Il regrette donc que tu qualifies de « vaporware » une solution qui n’est pas encore disponible au public, sur la foi d’éléments pour le moins incomplets.

Pour ce qui est du choix du PHP, je ne peux qu’aller dans son sens, même si l’on peut faire des solutions à base de ce langage, comme nous le rappelle @bohwaz, d’ailleurs, en plus du présent projet. Facebook repose essentiellement sur le PHP, s’il ne fallait que nommer que ce grand portail, dont la stabilité est relativment bonne, pour ce qui est de sa stabilité logicielle, ou de sa « scalabilité » (quel terme francophone équivalent ?)

Pour ceux qui se demandent pourquoi le PHP n’est pas une bonne solution, et quelle solution il vaut mieux adopter, la réponse est liée aux couches logicielles additionnelles que cela implique.

En effet, le PHP est un langage compilé au vol (ou Just in Time, JIT), ce qui implique que son code source est habituellement hébergé sur la machine qui l’héberge. Un logiciel malveillant qui modifierait ce code source pourrait éventuellement mettre en branle le système plus facilement que du code déjà compilé.

Qui plus est, le code exécuté produit par le PHP reste assez médiocre, d’un point de vue des performances, autant en termes de CPU que de RAM. C’est lié à deux choses. D’une part, le convertisseur de code source vers le bytecode, lui-même non pas compilé en langage natif, mais interprété ; d’autre part, le langage lui-même, non typé, capable de faire du code auto-modifiable, générer des variables au vol, etc. bref, tout ce qu’il faut dans la logique pour le rendre pratique à développer, mais au coût de performances moindres. Des solutions existent, comme HipHop de facebook. Mais celle-ci n’est que partielle, puisqu’elle produit bien du code natif, sans toutefois résoudre le problème du langage lui-même. En outre, elle va moins loin que son alter-ego JavaScript, V8 de Google, qui va plus loin dans les optimisations de compilation liées aux difficultés spécifiques du langage.

Un autre facteur reste non négligeable : la stabilité. En reposant sur des couches intermédiaires telles que l’interpréteur de bytecode, on est dépendant de sa stabilité. Or, il existe de nombreuses failles, notamment de fuite mémoire, dans plusieurs versions du PHP. Nul doute qu’il y en a encore qui persistent. Les programmes PHP eux-mêmes est souvent sujet aux fuites mémoire, très peu de développeurs PHP y faisant attention, le langage lui-même étant peu adapté à ce type de mise-au-point.

Bref, le choix d’un langage qui permet de produire du code natif maîtrisant mieux la stabilité, la mémoire, et les performances, tels le C ou le C++ me semble plus pertinent pour ce type d’usages.

@martin Le choix de PHP est un détail, ce n’est pas, et de loin, le principal problème, et je ne suis pas étonné que ce soit le seul où ait réagi l’auteur, il a pris la voie la plus facile.

Personne (ni sur le site de l’auteur, ni ici) n’a répondu sur le fond et notamment sur le mode de fonctionnement d’ODDNS. Comment fonctionne ce truc ? Par quel miracle sera-t-il insensible à la censure ? Que se passera-t-il si deux personnes réclament le même nom ? Aucune réponse à ces points.

L’argument que le code n’est pas encore prêt est de la blague : on n’écrit pas le code d’un truc aussi délicat et complexe sans avoir une idée précise de ce qu’on veut. C’est cela qui manque ici : aucune idée directrice.

À une époque, j’aurais été d’accord avec toi, @stephane. En effet, j’ai tendance à préparer, réfléchir à ce que j’entends faire avant de procéder à l’écriture du code.

Toutefois, autre époque, autres mœurs, la mode semble être d’écrire du code avant de réfléchir, puis d’avancer par itérations successives. Ainsi, le premier jet est simpliste, mais fonctionnel, quitte à n’implémenter aucune fonction attendue, et s’améliore avec le temps, à chaque nouvelle itération.

Quant au fond du problème, je ne suis pas compétent pour juger au-delà de remarquer qu’en effet, la description du projet manque de précisions, alors que le projet est ambitieux. Mais compte tenu de la faible quantité d’informations, est-il utile d’en parler autant, et d’aller jusqu’à remettre en question les qualités de l’auteur (cf. l’un de tes récents tweets), en plus du projet ?

Il faudrait au moins que les treize serveurs soient arrêtés

N’y aurait-il pas un abus de langage ici ?

Dans un autre article de ingnu.fr, on peut lire :

On écrit dans un langage, qu’une machine virtuelle va traduire en langage de plus bas niveau. On gagne peut-être en syntaxe, mais on perd un temps fou en exécution.

Il en est donc conscient :-p

Sur l’argument de PHP pas stable car langage de script, il existe des centaines de serveurs et démons en Python aussi. Sinon dans PHP en l’utilisant avec des types explicites et en faisant attention à ne pas faire n’importe quoi avec les variables stockées en mémoire, il est relativement aisé d’avoir qq chose de stable (bon sauf si on utilise une vieille version qui a des fuites mémoire), et de léger aussi. Le problème c’est qu’on est habitués en contexte web à faire n’importe quoi car la mémoire on s’en fout un peu elle sera libérée à la fin du script, au bout de quelques secondes.

@ledeuns Euh, je ne comprends rien à votre message. Quel rapport entre la partie de mon article citée (sur les treize serveurs racine) et celle de l’article d’Ingnu sur les machines virtuelles ?

@bohwaz J’ai supprimé la mention sur PHP car plusieurs personnes ont jugé plus facile de pinailler sur ce point de détail, plutôt que de répondre aux questions de fond.

@martin La question n’est pas le problème (récurrent en programmation) « est-ce que je réfléchis d’abord ou bien est-ce que je commence par coder ? » Les deux points de vue se défendent. Mais, ici, le problème est que l’auteur ne sait même pas ce qu’il veut faire. « Un DNS en pair-à-pair » n’est pas un cahier des charges. On ne peut pas coder sans savoir au moins ce qu’on veut faire (alors qu’on peut coder sans savoir exactement comment on va le faire). Pour prendre une comparaison avec les langages de programmation, on peut écrire un compilateur C sans trop réfléchir au début, parce qu’on connait le but (le langage C est bien défini). Ici, le projet ODDNS dit qu’il va écrire un compilateur mais ne sait pas encore pour quel langage !

Quant au choix d’en parler (en mal), plutôt que de l’ignorer (comme j’ignore des tas de projets qui sont à un stade préliminaire), il est entièrement dû au fait que l’auteur a choisi la voie du battage médiatique (PC Inpact et TorrentFreak) plutôt que celle, plus ingrate, d’écriture de code et de documentations.

@stephane ah ben tout à fait j’argumentais juste sur ce détail, sur le fond du truc j’ai juste lu un fichier du code, ça me semblait plutôt propre et fonctionnel mais grosse flemme de lire pour comprendre le fonctionnement du truc. Comme toi, sur les principes technologiques j’ai besoin qu’on m’explique clairement (d’où l’intérêt des RFC : l’assurance d’avoir une doc correcte qui explicite le machin), j’ai pas de temps à perdre à essayer de comprendre le code pour savoir comment ça marche.

@stephane Désolé si ce n’était pas clair, les deux parties du message n’ont pas de lien.
La première est une question, qui vous est adressée, sur l’infrastructure DNS. Ne doit-on pas parler de « 13 instances » plutôt que de « 13 serveurs » ?
Et la seconde remarque visait juste à faire remarquer que l’auteur de Ingnu.fr critique les langages interprétés dans un article et se demande quel est le problème avec PHP dans un autre.

@ledeuns Sur le nombre de serveurs racine, tout dépend de ce qu’on mesure http://www.bortzmeyer.org/combien-serveurs-racines.html