Bruno Michel a écrit 3285 commentaires

1. Quand et comment avez-vous connu DLFP ?
Je ne me souviens plus de comment j'ai connu DLFP, mais ca doit dater de 6 ou 7 ans.

2. Quel est votre niveau de fréquentation ?
Je viens sur LinuxFr plusieurs fois par jour.

3. Quels sont les contenus que vous lisez ? Ceux que vous ne lisez jamais ?
Je lis les dépêches, les propositions d'entretiens, les sondages, les journaux et les entrées du suivi, bref à peu près tout sauf les forums.

4. Quelle est votre opinion personnelle sur DLFP ?
Une opinion forcément faussée vu que j'en suis admin ;-)

5. Quels sont, selon, vous les points forts de DLFP ? Les raisons de son succès ? Ce que vous appréciez le plus ?
Ses lecteurs et leurs grandes implications dans les trolls^Wdiscussions.

6. A contrario, les faiblesses de votre point de vue ?
Templeet et la difficulté à faire évoluer le site. Et aussi la réticence des lecteurs aux nouveautés.

7. Comment percevez-vous l'influence de DLFP dans le monde du logiciel libre ?
Pfff, la question piège... Disons que c'est l'endroit idéal pour que tous les libristes puissent venir troller en tout quiétude.

8. Votre meilleur souvenir/troll/discussion sur LinuxFr (avec un lien si possible) ?
J'ai un faible pour les 1er avril et tout particulièrement le dernier : https://linuxfr.org/2008/04/02/23925.html.

9. Avez-vous déjà posté/proposé du contenu sur DLFP ?
Oui, des dépêches, des journaux et des entrées dans le suivi. Je vais également tâcher de proposer bientôt un entretien, parce que c'est un contenu qui mériterait d'être plus utilisé.

10. DLFP, LinuxFr ou GNU/LinuxFr ?
Pour ma part, définitivement LinuxFr (et LinuxFr.org pour la communication plus officielle).

C'est vrai que c'est plus logique dans ce sens. C'est corrigé.

J'ai supprimé le doublon, et j'ai essayé de reproduire cela, mais je n'y suis pas arrivé. Est-ce que d'autres personnes ont déjà rencontré ce problème ?

Oui, il y a eu pas mal de bugs suite à la mise à jour, mais relativisons, il n'y a rien eu de méchant : pas de données perdues, pas de faille de sécurité, le serveur ne s'est pas écroulé sous la charge, pas d'indisponibilité pendant 30h...

Ce n'était peut-être pas très pro, mais nous ne sommes pas payés pour LinuxFr, et nous comptons sur nos lecteurs pour tester le site et nous remonter les erreurs que nous corrigeons dans l'ensemble rapidement. Ce n'est pas parfait, mais je considère cela comme tout à fait acceptable compte-tenu que nous ne sommes que 2 admins pour faire cela.

Non, il y avait effectivement une erreur dans la conf templeet qui rendait les pages suivantes inaccessibles dans certaines conditions. C'est corrigé.

Pour les liens qui ne fonctionnent plus, c'est étonnant : ce sont de simples liens (pas d'ajax ou de javascript).

Par contre, pour l'erreur javascript, c'était un copier-coller malheureux. Cela devrait mieux marcher maintenant :)

Merci pour le patch. Je l'ai appliqué, et c'est vrai que c'est mieux qu'avant.

> [...] modérateurs qui sont tellement lents [...]

Qu'est-ce qu'il ne faut pas entendre...

Je n'ai pas de statistiques précises sous la main, mais la majorité des dépêches sont relues et modérées en moins de 24h.

Nous attendons ton patch avec impatience.

La pénurie d'articles intéressants est si imporante que ça ?

Oui, c'est l'été et il y a très peu de dépêches en ce moment. N'hésite pas à en proposer.

Voilà, c'est corrigé.

Lien corrigé.

Voilà, ca devrait mieux marcher maintenant.

Je n'ai pas dit que Twitter était compliqué dans l'absolu, mais qu'il était bien plus compliqué qu'une simple tribune. Le nombre de tables ne fait pas tout, il faut aussi tenir compte du nombre de pages, de l'API, de la gestion des SMS, etc. Note également que les tribunes ne gardent généralement pas d'historique contrairement à Twitter. Bref, c'est comme comparer LinuxFR à un simple blog : c'est un peu la même idée, mais ca n'a pas grand chose à voir en pratique.

surtout si des andouilles d'utilisateurs s'amusent à ajouter des centaines d'autres utilisateurs comme "amis"

Si c'était seulement quelques centaines, ca irait encore, mais certains utilisateurs ont plus de 30 000 "amis" (sic).

Je dirais qu'en gros, il voulait dire "XMPP va sûrement remplacer progressivement HTTP pour un certain nombre de choses, et c'est tant mieux".

Qui dit asynchrone dit timeout, je ne sais s'il est tout simplement possible de demander a ror d'effectuer une requète HTTP et de sortir en timeout si en 400 ms aucune réponse n'ai arrivée. De même pour une simple requète DNS.

Bien qu'il faille chercher assez loin pour trouver la réponse, oui, Ruby permet de faire cela, et RoR utilise ces capacités, pour ActiveResource par exemple.

Est-ce que ruby sait tirer profit des processeurs multicore ?

Oui, il suffit de lancer plusieurs processus.

Est-ce que son modèle de threads ne passe pas sont temps à mettre des lock empéchant tout simplement toute notion de parallèlisation ?

La question est biaisée. Oui, le modèle de threads de Ruby est catastrophique, mais rien n'empêche de paralléliser avec des processus.

Un langage adapté, et ce n'est pas le cas de ruby.

En l'absence d'arguments, c'est du FUD.

Documente toi sur le modèle Acteur, regarde Scala, Erlang, Haskell, essaie de comprendre la raison d'être de ses langages, tu verras que ruby n'est rien d'autre qu'un n ieme langage sans réel intérêt...

Je me suis documenté sur tout cela. Ruby n'est probablement pas le langage le plus adapté pour la haute disponibilité, mais Ruby présente un réel intérêt à mes yeux. Pour développer des frontaux web, Ruby (ou Python) reste à mes yeux largement préférable aux langages que tu as cité. D'ailleurs, est-tu seulement capables de me donner le nom d'un seul site web à fort trafic qui utilise Scala ou Haskell ? Pour Erlang, c'est facile, Twitter a déjà été cité (et visiblement utiliser erlang n'a pas suffit à résoudre leurs problèmes de montée en charge).

Relis tout ce qu'à ecrit Zen Shaw, auteur de mongrel, et ce qu'il pense de la communauté ruby...

Zen Shaw est connu pour être un personnage avec un certain tempérament. Bien que très justes sur le point technique, ses écrits mettent surtout en avant ses relations tendues avec certaines personnes influentes de la communauté Ruby. Il n'y a pas de remise en cause de Ruby.

Bref creuse le sujet de la scalabilité, car tu fais fausse route...

Des sites à fort trafic s'en sortent très bien avec RoR. Je ne pourrais pas en dire autant d'autres langages. Haskell est par exemple connu pour avoir des performances très difficiles à prédire, ce qui est, à mon avis, un point bloquant pour assurer des montées en charge dans de bonnes conditions.

Pour finir, je te ferais remarquer que tu as tendance à mélanger haute disponibilité et scalabilité. Bien que ces deux notions soient souvent liées, elles ne se recouvrent pas totalement. En particulier, pour la scalabilité, respecter certains grands principes est souvent moins important que l'expérience empirique. L'exemple typique est l'utilisation d'un cache : on cache telles ou telles données en testant et en regardant ce qui marche le mieux. Cela aide grandement à la montée en charge à un point tel que le site ne peut plus fonctionner sans un cache "chaud", ce qui est loin d'être idéal pour la haute disponibilité.

Twitter est bien plus compliqué qu'une simple tribune. Ce ne serait que cela, ils n'auraient aucun problème de scalabilité. Mais twitter est bien plus que cela : l'effet "réseau social" joue un rôle considérable. On peut trouver quantité d'articles sur ce sujet, mais http://www.hueniverse.com/hueniverse/2008/03/on-scaling-a-mi(...) me semble être un bon point de départ pour comprendre les problèmes aux quels sont confrontés les développeurs de twitter.

Je suis également un utilisateur bien malheureux de ce site. J'utilise assez souvent la version mobile du site[1] bien mieux foutue, mais ce n'est pas toujours possible (choix limité pour les gares de départ/arrivée, pas toutes les options, etc.). Et quand je suis obligé de me rabattre sur la version classique, c'est l'horreur.

[1] http://voyages-sncf.mobi/

L'étape suivante se passe sur http://bearstech.com/shop

Oui, ca se passe sur http://bearstech.com/openmoko/register pour le moment. Si tu veux plus d'informations, tu peux envoyer un mail à contact (at) bearstech (dot) com.

Bearstech va faire une commande groupée d'OpenMoko, et aux dernières nouvelles, la production est sur lancée et ils devraient les premiers exemplaires recevoir mi-juin. On est quand même assez loin du vaporware.

Effectivement, les plus gros sites ne sont pas forcément les plus connus. Je pense que ma.gnolia, gravatar ou A List Apart sont plus connus des lecteurs de LinxuFr.org que scribd ou hulu.

La débandade. Y'a pas d'admin ou bien ? Les niouzes sont tirées au sort ?

Si, il y a des admins, et ils n'ont rien trouvé à redire cette dépêche. As-tu une critique envers la dépêche ou seulement envers son auteur ?

Et si tu veux jouer aux attaques personnelles, la moindre des choses seraient d'être un contributeur : as-tu déjà proposé une dépêche ? as-tu déjà proposé un patch pour le site web ? une feuille de style (le site en aurait bien besoin) ?

D'après http://rails100.pbwiki.com/ , Twitter n'est pas le site rails avec le plus de traffic. Il ne serait même que le 6ème ! Je n'ai jamais entendu parler de problème de montée en charge pour les autre sites rails de ce top 100.

Malheureusement, camping n'est plus maintenu de façon régulière. Il existe par contre d'autres frameworks en Ruby. Je pourrais par exemple citer merb ( http://merbivore.com/ ), ramaze ( http://ramaze.net/ ), sinatra ( http://sinatrarb.com/ ), mais il en exuste beaucoup d'autres.

Sinon, ce n'est pas normal que RoR mette plus de temps à générer ta page que Camping : markaby est très sympa à utiliser, mais aussi très lent.