Objectivement, la publication d'un journal scientifique demande quand même une certaine quantité de travail "ingrat", qui n'est pas valorisable par des chercheurs, comme le sont les rôles d'éditeur et de reviewer. On peut citer (i) l'assistance technique (soumission de gros fichiers, problèmes de compilation Latex, etc), (ii) le boulot de composition et de PAO, (iii) le boulot de marketting et de référencement, etc. En gros, il y a besoin, en plus du staff scientifique, d'au moins trois personnes : un secrétaire/gestionnaire/assistant de direction, un ingénieur IT, et une personne qui peut faire la composition et la com. Bien sûr, ces moyens peuvent être mutualisés et l'équipe peut publier plusieurs journaux, même si la quantité reste limitée—je ne pense pas qu'une équipe comme celle-la puisse publier plus de 20 articles par mois au total. En terme de coût total, on est dans les 12 k€ en masse salariale en étant radin, si on compte le loyer pour les locaux et les charges (y compris la location du serveur et la bande passante + solutions de sauvegarde), on ne va pas se retrouver loin des 1000€ par article HT : on est bien dans l'ordre de grandeur des frais de publication "standard". Et ça, c'est dans une optique non lucrative. Baisser les couts ne pourrait se faire qu'en rognant sur la qualité, par exemple en ne relisant pas les articles.
Bien sûr, les gros organismes de recherche pourraient couvrir de tels frais, on pourrait avoir des revues CNRS, INRA, INSERM, etc. Cependant, ça poserait un certain nombre de problèmes ; d'une part, on pourrait avoir des doutes sur la neutralité du procédé (par exemple, les comptes rendus des académies des sciences, quel que soit le pays, est biaisé en faveur des membres "locaux"), et d'autre part, ça reviendrait pour l'État français à couvrir les frais de publication du monde entier. Sans compter les problèmes réglementaires liés à une concurrence directe entre le service public et des entreprises privées.
Dans l'ensemble, quand on parle de l'écosystème économique autour de la publication scientifique et de l'Open Access, on oublie souvent qu'on peut avoir accès à des données importantes, par exemple le bilan financier des PLoS, qui sont une organisation non-lucrative. Or, les PLoS ont des tarifs parmi les plus élevés du marché (pour une qualité très élevée aussi pour la plupart de leurs journaux), et pourtant, ils ne font pas d'argent. Au final, je pense qu'il est donc important de réaliser que les marges que les éditeurs font sur l'OpenAccess n'ont probablement rien à voir avec les marges qu'ils faisaient dans le modèle traditionnel.
Pousser des acteurs académiques à organiser leur propre système de publication revient à en faire porter les coûts de manière indirecte sur les labos. Bien sûr, on peut demander au gars qui fait la maintenance informatique de s'occupper à mi-temps du support technique pour le journal, bien sûr, la secrétaire du labo peut aussi faire une partie du boulot, etc. Mais à l'heure où la gestion de l'argent public est au centre du débat politique, c'est un peu étrange de trouver raisonnable de dépenser une quantité d'argent et des ressources humaines de manière détournée pour éviter de payer un service rendu par des entreprises privées, dans des conditions de concurrence relativement honnêtes (contrairement, encore une fois, à la situation qui précédait).
Non non, je n'ai pas essayé, je répondais juste au post précédent!
De manière générale, j'imagine (peut-être naivement) que l'algorithme revient à peu près au même que de minimiser le temps. Mais je suis tout à fait d'accord pour dire qu'en vélo, surtout en rando, les bosses ne sont pas forcément le plus désagréable!
C'est très discutable pour tout ce qui est artistique. Chacun utilise l'outil qu'il maitrise le mieux.
On peut aussi regarder ça du point de vue de la licence libre. Le png est au binaire ce que le svg est au code source. Du coup, si tu places ton code sous GPL ou équivalent, tu es censé fournir le code source pour les logiciels, les images, les sons, etc.
Mais ce n'est pas le problème de la distribution !
Visiblement, Debian considère que si. Tu ne peux pas reprocher à une distrib de ne pas faire de contrôle qualité : Debian vérifie les licences, la qualité générale du soft (pas de virus ni de malware, le logiciel s'exécute, etc), la conformité avec le règlement (de mémoire, il y avait eu des problèmes avec les jeux de mots débiles de weboob), etc. D'une manière générale, Debian reste concerné par la stabilité du système et la pertinence des logiciels packagés; si un soft pourrit le système parce qu'il est mal codé, c'est quand même le problème de la distribution! D'une manière générale, je pense qu'une distribution ne doit rien aux développeurs ; inclure un logiciel dans Debian, c'est un peu comme inclure un patch dans le noyau ; on peut te demander tout un tas de trucs et finir par dire "non". Tu as le droit de le prendre mal, tu as le droit d'être en désaccord avec la décision, mais si tu as accepté de passer autant de temps à essayer de faire passer ton truc, c'est que tu considères que la qualité du projet fait que ça valait la peine de faire des efforts. Or, cette qualité, c'est justement la raison qui fait que le processus est aussi chiant. À moins d'être complètement schizophrène, je ne vois pas comment tu peux te plaindre de la rigidité d'une projet, que tu as choisi justement du fait de sa qualité.
Sur le fond, je ne connais pas les tenants et les aboutissants spécifiques des problèmes rencontrés, mais ils me semblent tous aller vers une amélioration de la qualité du logiciel, en privilégiant les solutions générales (réutilisation de bibliothèques existantes, refus de divers bricolages à des fins de portabilité, demande de compilation à partir des vraies sources…). Ça se fait au détriment de la portabilité par contre (notamment en proposant d'utiliser des trucs Debian spécifique), mais ça, j'aurais tendance à dire que ça n'est pas le problème de Debian (ou seulement indirectement, car ils prennent le risque de ne pas pouvoir proposer certains logiciels à leurs utilisateurs).
Par contre dans la vraie vie ça permet de faire moins d'efforts dans plus de 1% des cas ?
Sur les petits trajets, ça me parait peu probable. Par contre, sur les grandes randos, ça doit être significatif, parce que les détours sont beaucoup moins couteux…
Ils sont à polytechnique, tes élèves? :-) Je doute que beaucoup d'élèves de terminale, même scientifique, pigent le coup de R et Z.
Le problème de fond, c'est que c'est faux de dire que l'ordinateur ne sait pas faire. La vérité, c'est que le langage demande parfois une conversion explicite, qui est une étape pénible due à la complexité du stockage des données numériques par un ordinateur. Cette complexité ne pourra pas être cachée éternellement, mais elle n'est absolument pas nécessaire à l'apprentissage de la programmation, surtout quand on parle d'approche ludique ou intuitive.
J'ai l'impression que l'idée, c'est de réduire la taille de la marche intiale, celle qu'il faut escalader pour faire son premier programme, comprendre comment programmer un ordinateur permet de répondre à des besoins. Quand on écoute ce que raconte un informaticien à un public de débutant, on se demande comment il apprendrait à conduire à quelqu'un :
OK, donc là, tu rentres dans le véhicule, et tu vois tout de suite en bas l'allume-cigare. À côté de l'allume-cigare, il y a les boutons pour ouvrir les vitres (mais ces boutons ne sont pas tout le temps à la même place entre les différentes marques de voiture). Là c'est l'autoradio, les boutons sont en anglais, je vais te les traduire parce que sinon tu ne pourras pas conduire : "Vol" c'est le volume, "Stat 1" c'est la première station, etc. Je t'ai collé des post-its partout. Tiens, plus bas, il y a la pédale d'embrayage. Elle est connectée à un cable, qui arrive à un dispositif constitué d'une butée et d'un disque, qui va frotter sur le volant moteur. Quand tu tires sur le cable, ça déconnecte le disque et le volant moteur. Il faudra faire ça quand tu passeras les vitesses, mais on parlera des vitesses plus tard. Là pour le moment, tu as quand même compris le coup du cable? Non, parce que le cable, c'est comme ça sur tous les modèles. Sauf sur ceux qui ont des vitesses automatiques. C'est beaucoup plus facile et je n'aurais pas eu besoin de t'expliquer tout ça, mais c'est moins pédagogique, tu comprends? De toutes manières, les automatiques ont aussi des boutons pour remonter les vitres. Je t'ai dit que l'allume-cigare servait à brancher des trucs électriques? Non non, on ne peut pas y mettre des clopes. Il est branché sur la batterie. En fait, il y a des gens qui s'en servent pour allumer des clopes, mais ça ne sert pas à ça normalement.
La notion de type est très très loin d'être une notion technique.
C'est justement ce que je conteste. La notion de type est une notion technique induite par la manière dont l'ordinateur stocke les données et par l'utilisation que tu peux en faire.
Pour un débutant, il pourrait n'exister que deux types de données : les nombres et les chaines de caractères. Les booléens sont inutiles, parce que dans du code de débutant, ils sont implicites : aucun débutant de va faire "bool ans = a > 2; if (ans) {…}". À l'adolescence, j'ai codé des années sans tilter qu'on pouvait stocker le résultat d'un test dans une variable, et ça ne m'a pas gêné plus que ça.
Il ne faut pas prendre le débutant pour un débile. Quand il fait des cin >> pour lire des données entrées au clavier et les stocker dans des variables, il sait très bien qu'il tape les touches "4" et "2" pour rentrer 42, et que c'est le programme qui les transforme en nombre ou en caractères. Et, contrairement à ce qu'on peut prétendre après 10 ans d'expérience en programmation, ça n'a rien de logique. Sur une feuille de papier, "42" et 42 sont conceptuellement exactement identiques. C'est pareil que pour la différence entre un int et un float ; la différence n'existe qu'à cause d'une contrainte technique. La programmation typée crée une différence artificielle entre les deux, et en fonction du langage, le transtypage peut être plus ou moins complexe. Mais je vois ça comme un défaut inhérent à la formalisation d'un programme, ça n'est pas intuitif, et ça n'est pas important pour comprendre la logique d'un programme.
À mon avis, l'intérêt du typage fort ne saute aux yeux qu'après des années à avoir expérimenté les bugs dus aux ambiguités du typage faible. On demande un password et on n'a pas prévu que l'utilisateur rentre "1234", etc. Mais d'une manière générale, un argument du type "C'est compliqué et ça vous gêne maintenant, mais vous verrez plus tard que c'est important" est un argument très faible ; c'est un argument d'autorité, souvent d'ailleurs employé pour justifier une pédagogie archaïque (apprentissage des instruments de musique, par exemple: fais des gammes pendant 3 ans, et après seulement tu auras le droit de jouer un morceau).
En fait, je me demande même si des enfants de moins de 10 ans comprennent les structures logiques du langage courant. Est-ce que pour un gamin, la différence entre "tant que" et "jusqu'à" est très nette? Du coup, utiliser des mot-clés qui ne veulent rien dire pour eux n'est peut-être pas plus mal, on n'est pas pollués par une compréhension approximative des concepts en français.
Je n'ai jamais compris pourquoi le premier cours de programmation était toujours dédié aux structures de contrôle. Il y en a plein qui ne sont presque jamais utilisées (while, do…until, etc), et elles sont presque toutes redondantes.
Je ne comprends pas pourquoi tu dis ça… Tu as des infos qui feraient penser qu'il y a un problème particulier avec cette machine? Pour l'avoir fait il y a peu de temps, ce n'est pas très compliqué d'installer Linux sur une machine UEFI, c'est juste la gestion du boot qui est un peu aléatoire (il faut essayer plusieurs manips les unes après les autres, y compris en réparant le boot à partir de Windows, mais ça finit par marcher).
Le plus stressant, finalement, c'est qu'Ubuntu (ou d'autres installeurs probablement) ne savent pas gérer l'installation, et ne donnent aucune indication sur la marche à suivre. Il faut repartitionner et installer "à l'aveugle", comme s'il n'y avait pas de Windows. On risque évidemment de tout pêter, mais ça a toujours été plus ou moins le cas avec les double boot…
Ce que je ne comprends pas, par contre, c'est pourquoi mettre une distribution folklorique alors que visiblement, on ne sait même pas si le matériel est reconnu.
Ce qui me dérange c'est plutôt la possibilité pour une variable de changer de type en cours de route. Là ça devrait pas être possible.
Pourquoi? Est-ce un argument technique, ou c'est juste parce que c'est (presque) toujours ainsi? Il y a pourtant très peu d'ambiguité. 4+"4", c'est évidemment 8 ; 4."4", c'est "44". Personne ne propose de faire ça en C, mais dans les langages de haut niveau, je ne vois pas le problème. D'une manière générale, est-ce raisonnable de s'attendre à ce que 42 == "4.2e1" donne FALSE?
Surtout pas. La notion de type est importante à comprendre
La notion de pointeur aussi, l'optimisation aussi… Tout est important, mais l'essentiel est de commencer. Si tu apprends à l'université, tu peux défendre le point de vue d'un théoricien, qui va commencer son cours avec le binaire, le stockage des tableaux en mémoire, le code ASCII, etc. Mais là, on parle d'approche pédagogique : l'objectif, c'est d'aller le plus vite possible vers un code qui fonctionne et qui fait à peu près ce que l'élève souhaite. Plus il y a de choses intuitives et plus l'élève va pouvoir se concentrer sur les aspects logiques du code. Les aspects techniques, il les apprendra plus tard.
Je ne dis pas que c'est facile, il est évident que pour un informaticien, tout est important, l'idée d'oublier volontairement un aspect essentiel comme le typage semble insupportable. Mais pourtant, objectivement, le typage, quand on débute, ça n'a aucune espèce d'importance, parce que c'est indépendant de la logique du code. 42, 42.0, "42", c'est pas grave. Tu vas mettre 10 ans à te former à la programmation, et parmi ces 10 ans, tu passeras 9 ans et 6 mois à faire gaffe aux types. Je pense que ça suffira largement :-)
Contrairement à python pour la psychorigidité? Ou alors le contraire, je trouve le ; de fin moins rigide que la fin d'instruction en \n, parce que ça me permets de formater mon code.
Il existe de nombreux langages où on termine les instructions avec un saut de ligne ET où on peut formatter le code. À commencer par le shell. Quand l'instruction est terminée, on l'exécute, autrement, on continue sur la ligne suivante.
Bah, c'est aussi évident que sans contexte, c'est difficile de tirer des règles générales : on n'enseigne pas de la même manière à des enfants, à des adolescents, à des jeunes adultes, ou à des seniors. De même, ça dépend de la formation en question : est-ce que les gens ont une formation scientifique (et donc une solide base en maths), ou pas. Enfin, ça dépend tout bêtement des gens, certains vont capter quelque chose du premier coup, d'autres ne capteront jamais. En particulier, j'ai l'impression que certaines personnes sont totalement inaptes à "exécuter" un programme de tête (a = 1; b = 2; b = (a+b)/b; a=(a+b)/2; est-ce a == b ? "euuuuuhhhhh"), ce qui rend la programmation beaucoup plus difficile pour eux (ils ne s'en sortent qu'en copiant des patterns, mais ne peuvent pas innover).
Pour le typage, à mon avis, le frein principal est le traitement des entrées/sorties, avec ce p*** de problème de la différence entre 42 et "42" qui fait perdre un temps fou à tout le monde. S'il y a un seul truc que je garderais de perl, c'est les conversions implicites entre les nombres et les chaines de caractères qui représentent des nombres. Parce que bon, il faut être honnête, 99.9…% des opérations de ce style ne sont absolument pas ambigües, et je trouve ça super sympa de pouvoir lire une ligne d'entrée du style "tomate oignon 2 carottes 3 poireaux" avec une seule variable…
la sémantique n'a pas une interprétation automagique pour coller à tes besoins non exprimés
C'est peut-être quand même une faiblesse des langages de programmation, non? Et peut-être même des logiciels en général. Souvent, quand on veut concevoir un truc plus intuitif, on peut, et je trouve que certains langages sont bourrés d'inutilités syntaxiques psychorigides. Par exemple, tous les compilateurs C ou C++ récents sont capables de te dire "ligne 318, il manque un ; à la fin". Bah oui, en effet, 99.99% du temps, le ";" est inutile, il suffirait d'interpréter les sauts de ligne comme des ;.
En gros, le problème n'est pas de demander à la machine de choisir entre deux options quand les instructions ne sont pas claires. On est d'accord, c'est quasiment impossible. Le problème est plutôt de concevoir des interfaces souples, qui donnent quelque chose de sensé plutôt qu'une erreur de compilation. Typiquement, les fonctions à arguments facultatifs sont une avancée considérable; mais tous les langages de programmation sont systématiquement truffés d'inutiles lubies psychorigides qui peuvent vraiment rebuter les débutants.
On a déja vu passer de nombreuses tentatives de traduction de langages informatiques, et, personnellement, je n'en ai jamais compris l'intérêt. Ça semble partir de l'hypothèse que les langages existants sont en anglais, et que cela pourrait constituer une barrière à l'apprentissage.
Or, d'après mon expérience, c'est complètement faux. D'une part, les langages informatique ne sont pas en anglais (seuls quelques mot-clé, souvent très rares, le sont), et d'autre part, la barrière à l'apprentissage est la logique de la programmation, et pas la syntaxe (sauf évidemment pour les langages à la con où on écrit "(Si (< (Nombre (Demander)) 18)"). Personnellement, je me rappelle avoir appris à programmer dans l'espèce de basic moche des calculatrices scientifiques, avec 5 mots clés qui se battent en duel. Ce qui est compliqué, c'est de comprendre le fonctionnement d'une boucle "for", ça n'est pas de piger que "for" veut dire "pour". D'ailleurs, je me rappelle bien avoir compris des années après que "goto" voulait dire "go to". Beaucoup de mots clé sont transparents (library, return, function, vector, stop, break, continue, …), beaucoup sont complètement obscurs même pour un anglophone (cout, cerr, fork, push, chomp, grep…), et dans tous les cas, il est strictement impossible de comprendre intuitivement comment les utiliser.
Si je devais enseigner la programmation à un vrai débutant dans de bonnes conditions, je prendrais un langage simple (if(a>0) et pas if(>(a 0))), interprété (le principe de la compilation est hyper-complexe, en fait), sans pièges syntaxiques (style if (a = 0) vs. (a == 0)), sans trucs énervants (du genre les points virgule…), non-typé (la rigueur, ça viendra après), et avec une bibliothèque graphique simple et naive (parce que les débutants, ils ne voient pas l'intérêt de rentrer des valeurs dans un terminal). Deux structures de contrôle (if/else et for), et c'est parti. En plus, utiliser des mot-clés qu'on ne comprend pas vraiment permet de dissocier la logique de la langue (par exemple, le "ou" qui tend à être exclusif) avec celle du formalisme informatique.
C'est juste rigolo de voir que les gens semblent tellement persuadés qu'ils auront des problèmes avec Linux qu'ils se renseignent même quand tout marche, au cas où il y aurait quand même des problèmes :-D
C'est vrai uniquement dans le cas où tu visites les mêmes sites que la majorité des clients de ton FAI.
Bah non, si on en croit le document, les requêtes du résolveur ont l'IP du résolveur comme source : le résolveur récupère la réponse, met à jour son cache, et te répond directement. Du coup, toutes les communications avec les autres serveurs DNS sont anonymisées, à moins que tu sois le seul client de ton FAI…
D'après justement le document "DNS privacy considerations", seul le résolveur connait ton adresse IP. Le reste du monde discute avec ton résolveur, ils ne peuvent pas remonter jusqu'à toi, à moins que tu héberges ton propre résolveur.
Je fais une fixation sur le FAI parce que c'est la configuration "naturelle" quand on parle de vie privée: tu es chez toi, derrière ta box configurée par défaut, et tu ne veux pas qu'un tiers sache ce que tu fais sur Internet. Cette situation semble assez peu risquée, puisque pas grand chose ne fuite vers l'extérieur, à moins que tu n'aies choisi volontairement d'interroger des résolveurs publics (mais là, il faut assumer).
Je ne prétends pas que le DNS ne pose aucun problème, mais je trouve ça finalement assez secondaire par rapport aux vrais problèmes de vie privée, notamment du fait du tracking permanent via des cookies ou Google Analytics. Comme il a été remarqué plus haut, toute visite de page web déclenche des dizaines de requêtes DNS, il n'y a aucun moyen de savoir s'il s'agit de sites dont tu as tapé le nom, un lien sur lequel tu as cliqué par inadvertance (comme par exemple le site de fesses dont le nom a été pris pour exemple dans cette discussion, que j'ai visité en m'attendant à un lien humouristique, alors que non), ou simplement une publicité qui s'est affichée sans ton consentement. Les DNS sont résolus par différents niveaux de cache, tu n'es donc jamais sûr de collecter un aperçu exhaustif de ce que les gens visitent. Et si tes résolveurs sont locaux ou chez ton FAI, tes requêtes ne sortent jamais avec des données nominatives.
Après, j'ai peut être complètement loupé la partie inquiétante, ou alors je ne visite que des sites qui ne posent problème à personne…
Certes, mais quelles infos sortent de la boucle de confiance toi + FAI? Ce qui sort du navigateur, c'est forcément très informatif sur ce que tu gladouilles sur Internet. Quelqu'un qui écoute entre moi et mon FAI sait exactement ce que je fais, à qui j'envoie des mails, quels sites je visite, etc. Le trafic DNS, c'est de la gnognotte si tu est avant le FAI.
Et, même si on fait confiance au résolveur utilisé, on peut être inquiet des gens sur le trajet qui écoutent (le trafic DNS étant en clair, c'est trivial).
Des gens qui écoutent le trafic entre toi et ton FAI? Je ne vois pas comment tu peux te prémunir contre ça. Autant tu peux chiffrer le contenu, mais je ne vois pas comment tu peux cacher qui tu es et ce que tu veux voir à ton FAI. C'est comme si tu voulais commander une pizza sans donner ton adresse…
A moins que tu ne penses que tous les scientifiques présent soient complices
Pas nécessairement, mais le protocole est tellement foireux que le concept de "validation indépendante" est risible. Le protocole est simple : Rossi se pointe avec son appareil, il le branche au courant pour le "mettre en route", les autres ne font que regarder et monitorer les sorties. Et Rossi débranche son truc et se barre avec. Personne ne manipule le truc, ni rien ; et l'appareil reste branché pendant tout le test au courant, par les fils qui ont permis de le "démarrer". Et le protocole de mesure de l'énergie semble complètement folklorique, il ne correspond à aucune procédure communément considérée comme acceptable dans les labos.
On a deux possibilités : (i) Rossi a inventé une machine magique qui contredit toutes les lois de la physique. (ii) l'appareil est une résistance sophistiquée de 2kW qui est restée branchée au courant de manière frauduleuse, avec ou sans la complicité des scientifiques présents.
J'attends avec impatience le premier prototype vendu, et la tronche du pigeon qui l'aura acheté :-)
D'après ce que j'ai vaguement compris, il faut quand même aller chercher loin pour aller chercher des problèmes de vie privée avec les requêtes DNS. D'une part, il faut considérer qu'une requête DNS est privée (ça contient peu d'information, quand même, et surtout, ça n'est pas nominatif). D'autre part, les requêtes qui sortent du serveur de cache (voire du cache de Firefox) doivent être hyper-minoritaires—du coup, pas de quoi constituer une base de données exhaustive, loin de là. Enfin, je n'ai pas compris en quoi ça concernait les gens qui n'hébergent pas leur serveur DNS chez eux. En particulier, il est fait référence à ceux qui utilisent un serveur DNS qui n'est pas celui de leur FAI, mais du coup c'est normal que ce serveur reçoive des données, il faut forcément lui faire confiance.
Peut-être le problème vient-il de la définition de la vie privée sur Internet. L'utilisation d'internet impose l'envoi d'informations : je veux voir tel site, voici mon mot de passe, je veux envoyer un email à l'utilisateur machin sur le serveur truc, etc. Est ce que "je veux connaire l'IP du serveur connu comme www.google.com" est une donnée privée? C'est une donnée, OK, ça peut être utilisé de manière pas forcément réglo, OK, mais est-ce pour autant une donnée privée? On l'a volontairement transmise à un tiers, quand même.
L'acharnement devient réellement ridicule. Le principe d'une gouvernance, même quand elle est collective, c'est de se mettre d'accord sur un système de prise de décision, et de s'y soumettre. J'imagine que ces personnes sont sincères et qu'elles pensent réellement agir pour le bien de Debian, mais il est évident qu'elles se trompent. Mieux vaut tous aller dans la même direction, même si elle n'est pas forcément la meilleure, plutôt que de risquer de déchirer une communauté.
Sur le fond, on sent quand même la rage du conservatisme. Ça doit faire peur de devoir apprendre quelque chose de nouveau à un stade avancé de sa carrière ; les jeunes pigent plus vite, et seront plus efficaces. On perd son expertise et son expérience. Mais c'est quand même moche de réagir de manière aussi violente, et finalement, aussi puérile.
Je ne vois pas de problème avec le raisonnement. Faire plus ou moins de requêtes change le coût par requête, mais pas le coût total. Du coup, se casser le cul à diminuer le nombre de requêtes ne change rien, ça va augmenter le coût par requête, mais ça ne va sauver aucun bébé phoque.
[^] # Re: Un autre modèle
Posté par arnaudus . En réponse à la dépêche L’Académie des sciences française prétend vouloir l’ouverture des publications scientifiques. Évalué à 8. Dernière modification le 30 octobre 2014 à 15:00.
Objectivement, la publication d'un journal scientifique demande quand même une certaine quantité de travail "ingrat", qui n'est pas valorisable par des chercheurs, comme le sont les rôles d'éditeur et de reviewer. On peut citer (i) l'assistance technique (soumission de gros fichiers, problèmes de compilation Latex, etc), (ii) le boulot de composition et de PAO, (iii) le boulot de marketting et de référencement, etc. En gros, il y a besoin, en plus du staff scientifique, d'au moins trois personnes : un secrétaire/gestionnaire/assistant de direction, un ingénieur IT, et une personne qui peut faire la composition et la com. Bien sûr, ces moyens peuvent être mutualisés et l'équipe peut publier plusieurs journaux, même si la quantité reste limitée—je ne pense pas qu'une équipe comme celle-la puisse publier plus de 20 articles par mois au total. En terme de coût total, on est dans les 12 k€ en masse salariale en étant radin, si on compte le loyer pour les locaux et les charges (y compris la location du serveur et la bande passante + solutions de sauvegarde), on ne va pas se retrouver loin des 1000€ par article HT : on est bien dans l'ordre de grandeur des frais de publication "standard". Et ça, c'est dans une optique non lucrative. Baisser les couts ne pourrait se faire qu'en rognant sur la qualité, par exemple en ne relisant pas les articles.
Bien sûr, les gros organismes de recherche pourraient couvrir de tels frais, on pourrait avoir des revues CNRS, INRA, INSERM, etc. Cependant, ça poserait un certain nombre de problèmes ; d'une part, on pourrait avoir des doutes sur la neutralité du procédé (par exemple, les comptes rendus des académies des sciences, quel que soit le pays, est biaisé en faveur des membres "locaux"), et d'autre part, ça reviendrait pour l'État français à couvrir les frais de publication du monde entier. Sans compter les problèmes réglementaires liés à une concurrence directe entre le service public et des entreprises privées.
Dans l'ensemble, quand on parle de l'écosystème économique autour de la publication scientifique et de l'Open Access, on oublie souvent qu'on peut avoir accès à des données importantes, par exemple le bilan financier des PLoS, qui sont une organisation non-lucrative. Or, les PLoS ont des tarifs parmi les plus élevés du marché (pour une qualité très élevée aussi pour la plupart de leurs journaux), et pourtant, ils ne font pas d'argent. Au final, je pense qu'il est donc important de réaliser que les marges que les éditeurs font sur l'OpenAccess n'ont probablement rien à voir avec les marges qu'ils faisaient dans le modèle traditionnel.
Pousser des acteurs académiques à organiser leur propre système de publication revient à en faire porter les coûts de manière indirecte sur les labos. Bien sûr, on peut demander au gars qui fait la maintenance informatique de s'occupper à mi-temps du support technique pour le journal, bien sûr, la secrétaire du labo peut aussi faire une partie du boulot, etc. Mais à l'heure où la gestion de l'argent public est au centre du débat politique, c'est un peu étrange de trouver raisonnable de dépenser une quantité d'argent et des ressources humaines de manière détournée pour éviter de payer un service rendu par des entreprises privées, dans des conditions de concurrence relativement honnêtes (contrairement, encore une fois, à la situation qui précédait).
[^] # Re: On gagne combien ?
Posté par arnaudus . En réponse au journal rv/hervé : recherche d’itinéraire vélo minimisant l'énergie en utilisant les données d'OSM. Évalué à 2.
Non non, je n'ai pas essayé, je répondais juste au post précédent!
De manière générale, j'imagine (peut-être naivement) que l'algorithme revient à peu près au même que de minimiser le temps. Mais je suis tout à fait d'accord pour dire qu'en vélo, surtout en rando, les bosses ne sont pas forcément le plus désagréable!
[^] # Re: Bonnes pratiques
Posté par arnaudus . En réponse au journal Pourquoi vous ne devriez pas packager vous-même votre logiciel pour Debian ?. Évalué à 4.
On peut aussi regarder ça du point de vue de la licence libre. Le png est au binaire ce que le svg est au code source. Du coup, si tu places ton code sous GPL ou équivalent, tu es censé fournir le code source pour les logiciels, les images, les sons, etc.
Visiblement, Debian considère que si. Tu ne peux pas reprocher à une distrib de ne pas faire de contrôle qualité : Debian vérifie les licences, la qualité générale du soft (pas de virus ni de malware, le logiciel s'exécute, etc), la conformité avec le règlement (de mémoire, il y avait eu des problèmes avec les jeux de mots débiles de weboob), etc. D'une manière générale, Debian reste concerné par la stabilité du système et la pertinence des logiciels packagés; si un soft pourrit le système parce qu'il est mal codé, c'est quand même le problème de la distribution! D'une manière générale, je pense qu'une distribution ne doit rien aux développeurs ; inclure un logiciel dans Debian, c'est un peu comme inclure un patch dans le noyau ; on peut te demander tout un tas de trucs et finir par dire "non". Tu as le droit de le prendre mal, tu as le droit d'être en désaccord avec la décision, mais si tu as accepté de passer autant de temps à essayer de faire passer ton truc, c'est que tu considères que la qualité du projet fait que ça valait la peine de faire des efforts. Or, cette qualité, c'est justement la raison qui fait que le processus est aussi chiant. À moins d'être complètement schizophrène, je ne vois pas comment tu peux te plaindre de la rigidité d'une projet, que tu as choisi justement du fait de sa qualité.
Sur le fond, je ne connais pas les tenants et les aboutissants spécifiques des problèmes rencontrés, mais ils me semblent tous aller vers une amélioration de la qualité du logiciel, en privilégiant les solutions générales (réutilisation de bibliothèques existantes, refus de divers bricolages à des fins de portabilité, demande de compilation à partir des vraies sources…). Ça se fait au détriment de la portabilité par contre (notamment en proposant d'utiliser des trucs Debian spécifique), mais ça, j'aurais tendance à dire que ça n'est pas le problème de Debian (ou seulement indirectement, car ils prennent le risque de ne pas pouvoir proposer certains logiciels à leurs utilisateurs).
[^] # Re: On gagne combien ?
Posté par arnaudus . En réponse au journal rv/hervé : recherche d’itinéraire vélo minimisant l'énergie en utilisant les données d'OSM. Évalué à 2.
Sur les petits trajets, ça me parait peu probable. Par contre, sur les grandes randos, ça doit être significatif, parce que les détours sont beaucoup moins couteux…
[^] # Re: Décalage
Posté par arnaudus . En réponse à la dépêche MicroAlg: langage et environnements pour l’algorithmique. Évalué à 9. Dernière modification le 24 octobre 2014 à 16:47.
Ils sont à polytechnique, tes élèves? :-) Je doute que beaucoup d'élèves de terminale, même scientifique, pigent le coup de R et Z.
Le problème de fond, c'est que c'est faux de dire que l'ordinateur ne sait pas faire. La vérité, c'est que le langage demande parfois une conversion explicite, qui est une étape pénible due à la complexité du stockage des données numériques par un ordinateur. Cette complexité ne pourra pas être cachée éternellement, mais elle n'est absolument pas nécessaire à l'apprentissage de la programmation, surtout quand on parle d'approche ludique ou intuitive.
J'ai l'impression que l'idée, c'est de réduire la taille de la marche intiale, celle qu'il faut escalader pour faire son premier programme, comprendre comment programmer un ordinateur permet de répondre à des besoins. Quand on écoute ce que raconte un informaticien à un public de débutant, on se demande comment il apprendrait à conduire à quelqu'un :
OK, donc là, tu rentres dans le véhicule, et tu vois tout de suite en bas l'allume-cigare. À côté de l'allume-cigare, il y a les boutons pour ouvrir les vitres (mais ces boutons ne sont pas tout le temps à la même place entre les différentes marques de voiture). Là c'est l'autoradio, les boutons sont en anglais, je vais te les traduire parce que sinon tu ne pourras pas conduire : "Vol" c'est le volume, "Stat 1" c'est la première station, etc. Je t'ai collé des post-its partout. Tiens, plus bas, il y a la pédale d'embrayage. Elle est connectée à un cable, qui arrive à un dispositif constitué d'une butée et d'un disque, qui va frotter sur le volant moteur. Quand tu tires sur le cable, ça déconnecte le disque et le volant moteur. Il faudra faire ça quand tu passeras les vitesses, mais on parlera des vitesses plus tard. Là pour le moment, tu as quand même compris le coup du cable? Non, parce que le cable, c'est comme ça sur tous les modèles. Sauf sur ceux qui ont des vitesses automatiques. C'est beaucoup plus facile et je n'aurais pas eu besoin de t'expliquer tout ça, mais c'est moins pédagogique, tu comprends? De toutes manières, les automatiques ont aussi des boutons pour remonter les vitres. Je t'ai dit que l'allume-cigare servait à brancher des trucs électriques? Non non, on ne peut pas y mettre des clopes. Il est branché sur la batterie. En fait, il y a des gens qui s'en servent pour allumer des clopes, mais ça ne sert pas à ça normalement.
[^] # Re: Décalage
Posté par arnaudus . En réponse à la dépêche MicroAlg: langage et environnements pour l’algorithmique. Évalué à 4.
C'est justement ce que je conteste. La notion de type est une notion technique induite par la manière dont l'ordinateur stocke les données et par l'utilisation que tu peux en faire.
Pour un débutant, il pourrait n'exister que deux types de données : les nombres et les chaines de caractères. Les booléens sont inutiles, parce que dans du code de débutant, ils sont implicites : aucun débutant de va faire "bool ans = a > 2; if (ans) {…}". À l'adolescence, j'ai codé des années sans tilter qu'on pouvait stocker le résultat d'un test dans une variable, et ça ne m'a pas gêné plus que ça.
Il ne faut pas prendre le débutant pour un débile. Quand il fait des cin >> pour lire des données entrées au clavier et les stocker dans des variables, il sait très bien qu'il tape les touches "4" et "2" pour rentrer 42, et que c'est le programme qui les transforme en nombre ou en caractères. Et, contrairement à ce qu'on peut prétendre après 10 ans d'expérience en programmation, ça n'a rien de logique. Sur une feuille de papier, "42" et 42 sont conceptuellement exactement identiques. C'est pareil que pour la différence entre un int et un float ; la différence n'existe qu'à cause d'une contrainte technique. La programmation typée crée une différence artificielle entre les deux, et en fonction du langage, le transtypage peut être plus ou moins complexe. Mais je vois ça comme un défaut inhérent à la formalisation d'un programme, ça n'est pas intuitif, et ça n'est pas important pour comprendre la logique d'un programme.
À mon avis, l'intérêt du typage fort ne saute aux yeux qu'après des années à avoir expérimenté les bugs dus aux ambiguités du typage faible. On demande un password et on n'a pas prévu que l'utilisateur rentre "1234", etc. Mais d'une manière générale, un argument du type "C'est compliqué et ça vous gêne maintenant, mais vous verrez plus tard que c'est important" est un argument très faible ; c'est un argument d'autorité, souvent d'ailleurs employé pour justifier une pédagogie archaïque (apprentissage des instruments de musique, par exemple: fais des gammes pendant 3 ans, et après seulement tu auras le droit de jouer un morceau).
[^] # Re: Décalage
Posté par arnaudus . En réponse à la dépêche MicroAlg: langage et environnements pour l’algorithmique. Évalué à 2.
En fait, je me demande même si des enfants de moins de 10 ans comprennent les structures logiques du langage courant. Est-ce que pour un gamin, la différence entre "tant que" et "jusqu'à" est très nette? Du coup, utiliser des mot-clés qui ne veulent rien dire pour eux n'est peut-être pas plus mal, on n'est pas pollués par une compréhension approximative des concepts en français.
Je n'ai jamais compris pourquoi le premier cours de programmation était toujours dédié aux structures de contrôle. Il y en a plein qui ne sont presque jamais utilisées (while, do…until, etc), et elles sont presque toutes redondantes.
[^] # Re: Décalage
Posté par arnaudus . En réponse à la dépêche MicroAlg: langage et environnements pour l’algorithmique. Évalué à 5.
… envoyer 10000 mails à la seconde en combinant les deux… :-)
[^] # Re: déconseillé
Posté par arnaudus . En réponse au message Lenovo IdeaPad Flex 10 : remplacer Windows 8. Évalué à 2. Dernière modification le 23 octobre 2014 à 23:55.
Je ne comprends pas pourquoi tu dis ça… Tu as des infos qui feraient penser qu'il y a un problème particulier avec cette machine? Pour l'avoir fait il y a peu de temps, ce n'est pas très compliqué d'installer Linux sur une machine UEFI, c'est juste la gestion du boot qui est un peu aléatoire (il faut essayer plusieurs manips les unes après les autres, y compris en réparant le boot à partir de Windows, mais ça finit par marcher).
Le plus stressant, finalement, c'est qu'Ubuntu (ou d'autres installeurs probablement) ne savent pas gérer l'installation, et ne donnent aucune indication sur la marche à suivre. Il faut repartitionner et installer "à l'aveugle", comme s'il n'y avait pas de Windows. On risque évidemment de tout pêter, mais ça a toujours été plus ou moins le cas avec les double boot…
Ce que je ne comprends pas, par contre, c'est pourquoi mettre une distribution folklorique alors que visiblement, on ne sait même pas si le matériel est reconnu.
[^] # Re: Décalage
Posté par arnaudus . En réponse à la dépêche MicroAlg: langage et environnements pour l’algorithmique. Évalué à 1.
Pourquoi? Est-ce un argument technique, ou c'est juste parce que c'est (presque) toujours ainsi? Il y a pourtant très peu d'ambiguité. 4+"4", c'est évidemment 8 ; 4."4", c'est "44". Personne ne propose de faire ça en C, mais dans les langages de haut niveau, je ne vois pas le problème. D'une manière générale, est-ce raisonnable de s'attendre à ce que 42 == "4.2e1" donne FALSE?
[^] # Re: Décalage
Posté par arnaudus . En réponse à la dépêche MicroAlg: langage et environnements pour l’algorithmique. Évalué à 7.
La notion de pointeur aussi, l'optimisation aussi… Tout est important, mais l'essentiel est de commencer. Si tu apprends à l'université, tu peux défendre le point de vue d'un théoricien, qui va commencer son cours avec le binaire, le stockage des tableaux en mémoire, le code ASCII, etc. Mais là, on parle d'approche pédagogique : l'objectif, c'est d'aller le plus vite possible vers un code qui fonctionne et qui fait à peu près ce que l'élève souhaite. Plus il y a de choses intuitives et plus l'élève va pouvoir se concentrer sur les aspects logiques du code. Les aspects techniques, il les apprendra plus tard.
Je ne dis pas que c'est facile, il est évident que pour un informaticien, tout est important, l'idée d'oublier volontairement un aspect essentiel comme le typage semble insupportable. Mais pourtant, objectivement, le typage, quand on débute, ça n'a aucune espèce d'importance, parce que c'est indépendant de la logique du code. 42, 42.0, "42", c'est pas grave. Tu vas mettre 10 ans à te former à la programmation, et parmi ces 10 ans, tu passeras 9 ans et 6 mois à faire gaffe aux types. Je pense que ça suffira largement :-)
[^] # Re: Décalage
Posté par arnaudus . En réponse à la dépêche MicroAlg: langage et environnements pour l’algorithmique. Évalué à 2.
Il existe de nombreux langages où on termine les instructions avec un saut de ligne ET où on peut formatter le code. À commencer par le shell. Quand l'instruction est terminée, on l'exécute, autrement, on continue sur la ligne suivante.
[^] # Re: Décalage
Posté par arnaudus . En réponse à la dépêche MicroAlg: langage et environnements pour l’algorithmique. Évalué à 4. Dernière modification le 23 octobre 2014 à 16:45.
Bah, c'est aussi évident que sans contexte, c'est difficile de tirer des règles générales : on n'enseigne pas de la même manière à des enfants, à des adolescents, à des jeunes adultes, ou à des seniors. De même, ça dépend de la formation en question : est-ce que les gens ont une formation scientifique (et donc une solide base en maths), ou pas. Enfin, ça dépend tout bêtement des gens, certains vont capter quelque chose du premier coup, d'autres ne capteront jamais. En particulier, j'ai l'impression que certaines personnes sont totalement inaptes à "exécuter" un programme de tête (a = 1; b = 2; b = (a+b)/b; a=(a+b)/2; est-ce a == b ? "euuuuuhhhhh"), ce qui rend la programmation beaucoup plus difficile pour eux (ils ne s'en sortent qu'en copiant des patterns, mais ne peuvent pas innover).
Pour le typage, à mon avis, le frein principal est le traitement des entrées/sorties, avec ce p*** de problème de la différence entre 42 et "42" qui fait perdre un temps fou à tout le monde. S'il y a un seul truc que je garderais de perl, c'est les conversions implicites entre les nombres et les chaines de caractères qui représentent des nombres. Parce que bon, il faut être honnête, 99.9…% des opérations de ce style ne sont absolument pas ambigües, et je trouve ça super sympa de pouvoir lire une ligne d'entrée du style "tomate oignon 2 carottes 3 poireaux" avec une seule variable…
C'est peut-être quand même une faiblesse des langages de programmation, non? Et peut-être même des logiciels en général. Souvent, quand on veut concevoir un truc plus intuitif, on peut, et je trouve que certains langages sont bourrés d'inutilités syntaxiques psychorigides. Par exemple, tous les compilateurs C ou C++ récents sont capables de te dire "ligne 318, il manque un ; à la fin". Bah oui, en effet, 99.99% du temps, le ";" est inutile, il suffirait d'interpréter les sauts de ligne comme des ;.
En gros, le problème n'est pas de demander à la machine de choisir entre deux options quand les instructions ne sont pas claires. On est d'accord, c'est quasiment impossible. Le problème est plutôt de concevoir des interfaces souples, qui donnent quelque chose de sensé plutôt qu'une erreur de compilation. Typiquement, les fonctions à arguments facultatifs sont une avancée considérable; mais tous les langages de programmation sont systématiquement truffés d'inutiles lubies psychorigides qui peuvent vraiment rebuter les débutants.
# Décalage
Posté par arnaudus . En réponse à la dépêche MicroAlg: langage et environnements pour l’algorithmique. Évalué à 10. Dernière modification le 23 octobre 2014 à 14:05.
On a déja vu passer de nombreuses tentatives de traduction de langages informatiques, et, personnellement, je n'en ai jamais compris l'intérêt. Ça semble partir de l'hypothèse que les langages existants sont en anglais, et que cela pourrait constituer une barrière à l'apprentissage.
Or, d'après mon expérience, c'est complètement faux. D'une part, les langages informatique ne sont pas en anglais (seuls quelques mot-clé, souvent très rares, le sont), et d'autre part, la barrière à l'apprentissage est la logique de la programmation, et pas la syntaxe (sauf évidemment pour les langages à la con où on écrit "(Si (< (Nombre (Demander)) 18)"). Personnellement, je me rappelle avoir appris à programmer dans l'espèce de basic moche des calculatrices scientifiques, avec 5 mots clés qui se battent en duel. Ce qui est compliqué, c'est de comprendre le fonctionnement d'une boucle "for", ça n'est pas de piger que "for" veut dire "pour". D'ailleurs, je me rappelle bien avoir compris des années après que "goto" voulait dire "go to". Beaucoup de mots clé sont transparents (library, return, function, vector, stop, break, continue, …), beaucoup sont complètement obscurs même pour un anglophone (cout, cerr, fork, push, chomp, grep…), et dans tous les cas, il est strictement impossible de comprendre intuitivement comment les utiliser.
Si je devais enseigner la programmation à un vrai débutant dans de bonnes conditions, je prendrais un langage simple (if(a>0) et pas if(>(a 0))), interprété (le principe de la compilation est hyper-complexe, en fait), sans pièges syntaxiques (style if (a = 0) vs. (a == 0)), sans trucs énervants (du genre les points virgule…), non-typé (la rigueur, ça viendra après), et avec une bibliothèque graphique simple et naive (parce que les débutants, ils ne voient pas l'intérêt de rentrer des valeurs dans un terminal). Deux structures de contrôle (if/else et for), et c'est parti. En plus, utiliser des mot-clés qu'on ne comprend pas vraiment permet de dissocier la logique de la langue (par exemple, le "ou" qui tend à être exclusif) avec celle du formalisme informatique.
[^] # Re: Dégoogliser
Posté par arnaudus . En réponse à la dépêche Framasoft veut dégoogliser Internet !. Évalué à 4.
Ah bon? Ils font dans le matériel d'haltérophilie?
[^] # Re: Pilotes intégrés...
Posté par arnaudus . En réponse au message Pilote ordinateur Hp dv7 portable. Évalué à 3.
C'est juste rigolo de voir que les gens semblent tellement persuadés qu'ils auront des problèmes avec Linux qu'ils se renseignent même quand tout marche, au cas où il y aurait quand même des problèmes :-D
[^] # Re: Qui est au courant ?
Posté par arnaudus . En réponse au journal Création du groupe de travail IETF sur « DNS et vie privée ». Évalué à 2.
Mouais, si l'attaquant a accès à tes requêtes HTTP, je ne vois pas tellement ce qu'il a à faire de tes requêtes DNS…
[^] # Re: Qui est au courant ?
Posté par arnaudus . En réponse au journal Création du groupe de travail IETF sur « DNS et vie privée ». Évalué à 2.
Bah non, si on en croit le document, les requêtes du résolveur ont l'IP du résolveur comme source : le résolveur récupère la réponse, met à jour son cache, et te répond directement. Du coup, toutes les communications avec les autres serveurs DNS sont anonymisées, à moins que tu sois le seul client de ton FAI…
[^] # Re: Qui est au courant ?
Posté par arnaudus . En réponse au journal Création du groupe de travail IETF sur « DNS et vie privée ». Évalué à 3.
D'après justement le document "DNS privacy considerations", seul le résolveur connait ton adresse IP. Le reste du monde discute avec ton résolveur, ils ne peuvent pas remonter jusqu'à toi, à moins que tu héberges ton propre résolveur.
Je fais une fixation sur le FAI parce que c'est la configuration "naturelle" quand on parle de vie privée: tu es chez toi, derrière ta box configurée par défaut, et tu ne veux pas qu'un tiers sache ce que tu fais sur Internet. Cette situation semble assez peu risquée, puisque pas grand chose ne fuite vers l'extérieur, à moins que tu n'aies choisi volontairement d'interroger des résolveurs publics (mais là, il faut assumer).
Je ne prétends pas que le DNS ne pose aucun problème, mais je trouve ça finalement assez secondaire par rapport aux vrais problèmes de vie privée, notamment du fait du tracking permanent via des cookies ou Google Analytics. Comme il a été remarqué plus haut, toute visite de page web déclenche des dizaines de requêtes DNS, il n'y a aucun moyen de savoir s'il s'agit de sites dont tu as tapé le nom, un lien sur lequel tu as cliqué par inadvertance (comme par exemple le site de fesses dont le nom a été pris pour exemple dans cette discussion, que j'ai visité en m'attendant à un lien humouristique, alors que non), ou simplement une publicité qui s'est affichée sans ton consentement. Les DNS sont résolus par différents niveaux de cache, tu n'es donc jamais sûr de collecter un aperçu exhaustif de ce que les gens visitent. Et si tes résolveurs sont locaux ou chez ton FAI, tes requêtes ne sortent jamais avec des données nominatives.
Après, j'ai peut être complètement loupé la partie inquiétante, ou alors je ne visite que des sites qui ne posent problème à personne…
[^] # Re: Qui est au courant ?
Posté par arnaudus . En réponse au journal Création du groupe de travail IETF sur « DNS et vie privée ». Évalué à 2.
Certes, mais quelles infos sortent de la boucle de confiance toi + FAI? Ce qui sort du navigateur, c'est forcément très informatif sur ce que tu gladouilles sur Internet. Quelqu'un qui écoute entre moi et mon FAI sait exactement ce que je fais, à qui j'envoie des mails, quels sites je visite, etc. Le trafic DNS, c'est de la gnognotte si tu est avant le FAI.
[^] # Re: Qui est au courant ?
Posté par arnaudus . En réponse au journal Création du groupe de travail IETF sur « DNS et vie privée ». Évalué à -1.
Des gens qui écoutent le trafic entre toi et ton FAI? Je ne vois pas comment tu peux te prémunir contre ça. Autant tu peux chiffrer le contenu, mais je ne vois pas comment tu peux cacher qui tu es et ce que tu veux voir à ton FAI. C'est comme si tu voulais commander une pizza sans donner ton adresse…
[^] # Re: Magic happens.
Posté par arnaudus . En réponse au journal Douche froide pour la fusion. Évalué à 5. Dernière modification le 20 octobre 2014 à 16:11.
Pas nécessairement, mais le protocole est tellement foireux que le concept de "validation indépendante" est risible. Le protocole est simple : Rossi se pointe avec son appareil, il le branche au courant pour le "mettre en route", les autres ne font que regarder et monitorer les sorties. Et Rossi débranche son truc et se barre avec. Personne ne manipule le truc, ni rien ; et l'appareil reste branché pendant tout le test au courant, par les fils qui ont permis de le "démarrer". Et le protocole de mesure de l'énergie semble complètement folklorique, il ne correspond à aucune procédure communément considérée comme acceptable dans les labos.
On a deux possibilités : (i) Rossi a inventé une machine magique qui contredit toutes les lois de la physique. (ii) l'appareil est une résistance sophistiquée de 2kW qui est restée branchée au courant de manière frauduleuse, avec ou sans la complicité des scientifiques présents.
J'attends avec impatience le premier prototype vendu, et la tronche du pigeon qui l'aura acheté :-)
[^] # Re: Qui est au courant ?
Posté par arnaudus . En réponse au journal Création du groupe de travail IETF sur « DNS et vie privée ». Évalué à 5.
D'après ce que j'ai vaguement compris, il faut quand même aller chercher loin pour aller chercher des problèmes de vie privée avec les requêtes DNS. D'une part, il faut considérer qu'une requête DNS est privée (ça contient peu d'information, quand même, et surtout, ça n'est pas nominatif). D'autre part, les requêtes qui sortent du serveur de cache (voire du cache de Firefox) doivent être hyper-minoritaires—du coup, pas de quoi constituer une base de données exhaustive, loin de là. Enfin, je n'ai pas compris en quoi ça concernait les gens qui n'hébergent pas leur serveur DNS chez eux. En particulier, il est fait référence à ceux qui utilisent un serveur DNS qui n'est pas celui de leur FAI, mais du coup c'est normal que ce serveur reçoive des données, il faut forcément lui faire confiance.
Peut-être le problème vient-il de la définition de la vie privée sur Internet. L'utilisation d'internet impose l'envoi d'informations : je veux voir tel site, voici mon mot de passe, je veux envoyer un email à l'utilisateur machin sur le serveur truc, etc. Est ce que "je veux connaire l'IP du serveur connu comme www.google.com" est une donnée privée? C'est une donnée, OK, ça peut être utilisé de manière pas forcément réglo, OK, mais est-ce pour autant une donnée privée? On l'a volontairement transmise à un tiers, quand même.
[^] # Re: Oubli ?
Posté par arnaudus . En réponse au journal Un fork de Debian à cause de systemd ?. Évalué à 5.
L'acharnement devient réellement ridicule. Le principe d'une gouvernance, même quand elle est collective, c'est de se mettre d'accord sur un système de prise de décision, et de s'y soumettre. J'imagine que ces personnes sont sincères et qu'elles pensent réellement agir pour le bien de Debian, mais il est évident qu'elles se trompent. Mieux vaut tous aller dans la même direction, même si elle n'est pas forcément la meilleure, plutôt que de risquer de déchirer une communauté.
Sur le fond, on sent quand même la rage du conservatisme. Ça doit faire peur de devoir apprendre quelque chose de nouveau à un stade avancé de sa carrière ; les jeunes pigent plus vite, et seront plus efficaces. On perd son expertise et son expérience. Mais c'est quand même moche de réagir de manière aussi violente, et finalement, aussi puérile.
[^] # Re: Ça ne change rien de ne pas rechercher :)
Posté par arnaudus . En réponse au journal Rechercher au plus juste, ça sauve des bébés morses ! Et toi ?. Évalué à 3.
Je ne vois pas de problème avec le raisonnement. Faire plus ou moins de requêtes change le coût par requête, mais pas le coût total. Du coup, se casser le cul à diminuer le nombre de requêtes ne change rien, ça va augmenter le coût par requête, mais ça ne va sauver aucun bébé phoque.