Yusei a écrit 4649 commentaires

http://translate.google.fr/translate_t?sl=fr&tl=en&t(...)

Tu vois la nuance ?
Non. Mais je ne voulais pas relancer le débat, juste te taquiner un peu.

C'est simple, chez moi je n'installe jamais un paquet non-signé.

Et dire que tu me traitais de parano parce que j'utilise https quand c'est disponible... hôpital, charité, tout ça... ;)

(oui oui, c'est hors-sujet, -1)

Pour le chiffrement, ça concerne les mots de passe mais aussi d'autres données sensibles comme le numéro de carte bleue, le numéro de sécurité sociale, tout ce qui peut être exploité par des petits malins aux grandes oreilles, quoi.

Le problème, c'est que le protocole ne peut pas décider ce qui est sensible et ce qui ne l'est pas, ça dépend des applications. C'est pour ça qu'on passe d'un protocole à l'autre selon les différentes pages d'un site, avec toutes les ambiguités que ça crée. D'où la suggestion d'utiliser https quand c'est possible, comme ça on est sûr que les données sensibles seront chiffrées.

Quant à l'effort nécessaire, de mon point de vue d'utilisateur, choisir d'utiliser linuxfr en https ne demande que l'effort de taper un "s" après http lors de la première connexion... même si le gain est infime, le coût étant nul, je ne vois pas pourquoi m'en passer.

Du point de vue de l'administrateur du serveur, le coût est un peu plus élevé, puisqu'il faut générer une signature, la faire certifier, configurer le serveur, etc. Évidemment dans l'état actuel des choses, je n'imagine pas que les hébergeurs génèrent des certificats pour chacun de leurs hébergés. Quand je parlais de mettre une couche de crypto par défaut, c'était dans le cadre d'un scénario de science fiction où j'aurais à créer le web aujourd'hui :) Sur le principe, je pense que le protocole à la base du web (et des emails) devrait être un minimum sécurisé. S'il l'était, ce serait transparent pour l'utilisateur. Il est évident qu'en pratique c'est un peu tard.

«Quand un serveur commencera à s'écrouler sous la surcharge due à HTTPS (alors que le même serveur modeste n'aurait pas eu de problèmes en HTTP), l'utilisateur s'en rendra compte...»

Même argument, autre démonstration: coder en unicode prend plus de place que coder en iso-8859-1, et quand la RAM de l'utilisateur (ou du serveur en face) sera saturée, il s'en rendra compte. Donc il ne faut pas généraliser l'usage d'Unicode.

«Quand tous les administrateurs réseau et fournisseurs d'accès devront mettre leurs proxies à la poubelle»

En cette ère de "Web 2.0" à base d'Ajax et de contenus dynamiques/personnalisés, je serais curieux de savoir quelle est l'efficacité des proxies webs.

«À l'heure où tout le monde cherche comment réduire sa consommation d'énergie, il est contre productif d'inciter à ce gaspillage de puissance, pour apporter un service dont on se passe très bien !»

L'argument de la dépense d'énergie se tient, et je suis à deux doigts de désactiver le chiffrement de ma connexion Wifi (d'autant plus qu'il ne vaut rien). Mais à deux doigts seulement. Par contre, puisque le chiffrement et l'authentification sont des services dont tu te passes plus facilement que moi, je t'encourage à le faire, si ce n'est pas déjà fait.

Visiblement, je n'arrive pas à faire comprendre ma position et je passe pour un paranoïaque. Sur le fond, il n'y a aucune différence avec le fait que la CNIL oblige à ce que la case "ne me contactez pas pour vos pubs" soit cochée par défaut: la protection de la vie privée ne devrait pas nécessiter de démarche active de la part de l'utilisateur.

C'est la même opposition que celle entre blacklist et whitelist en sécurité. Tous les gens qui parlent de sécurité s'accordent à dire que les whitelists sont la seule solution crédible.

Ici, la blacklist, c'est HTTP en général et HTTPS quand on veut de la sécurité. La whitelist, ce serait HTTPS en général et HTTP quand on ne veut pas de sécurité. La seule objection à un système de whitelist, c'est "oh ben moi j'm'en fiche, personne en veut à mes communications". On admet que c'est mieux, mais on postule que ce n'est pas nécessaire.

Curieusement, alors que peu de gens s'offusquent que leurs mots de passe sur myspace (au hasard) transitent en clair, ils ne tolèreraient pas ça sur le site de leur banque. C'est idiot, d'autant plus que beaucoup de gens utilisent le même mot de passe partout.

De la même manière, beaucoup de gens aiment bien avoir la garantie que quand ils cliquent sur un lien, ils tombent bien sur le site qu'ils veulent. En réalité, très peu de gens sont prêts à concevoir que ça puisse ne pas être le cas. C'est pour ça que le phishing marche aussi bien. Là encore, la solution la plus immédiate serait l'utilisation d'HTTPS de manière généralisée.

En dehors de l'argument "flemme", qui est tout à fait valable, la seule objection à une utilisation élargie d'HTTPS serait un éventuel coût subi par l'utilisateur, en rapidité ou en facilité d'utilisation. Le ralentissement pour l'utilisateur est largement négligeable en pratique, à moins d'utiliser un 486. Il n'y a guère que côté serveur qu'on peut voir une différence, lorsque le serveur commence à être violemment chargé. Plus la puissance des machines augmente, et moins ça sera sensible.

C'est un pari ou tu gagnes toujours: dans le pire des cas, si tu te retrouves quand même au chômage, tu auras une PS3 pour t'occuper.

Tu ne confondrais pas l'affichage du prix en magasin avec l'affichage du prix sur le produit lui-même ?

Je n'ai jamais vu personne prétendre, par exemple, que le prix d'un tshirt devait être imprimé dessus. C'est à ça que ressemble ton argument pour les timbres. (À moins, bien sûr, que le prix des carnets de timbres ne soit pas indiqué dans les bureaux de Poste.)

Tu ne nous dis pas le plus important, à savoir: est-ce que le nutella est meilleur avec du liquide vaisselle ou sans ?

Il dit qu'il ne veut pas installer Java, il ne dit pas qu'il ne veut pas que Freenet soit codé en Java. J'en déduis que si Freenet était compilable avec GCJ, ça lui conviendrait peut-être...

(Si ça se trouve, c'est compilable avec GCJ, je n'ai ni testé ni cherché sur le web)

Pour citer une phrase beaucoup trop citée: « la dictature c'est "ferme ta gueule", la démocratie c'est "cause toujours" » (il paraît que c'est de Coluche).

Freenet, c'est pour les dictatures.

Je ne suis pas terriblement convaincu par l'analogie avec la parole, pour plein de raisons, et je ne sais pas trop par où commencer, alors je vais me défiler et répondre par une autre analogie, que j'ai déjà utilisée.

La plupart des gens, lorsqu'ils envoient du courrier, mettent une enveloppe. Pas seulement quand ils veulent raconter des détails compromettants sur le chef. J'avancerais même que la plupart d'entre eux ne réfléchit pas avant de mettre une enveloppe, mais serait outré si tout d'un coup le gouvernement interdisait les enveloppes et obligeait tout le monde à utiliser des cartes postales. Donc, quelque part, les gens tiennent à leur vie privée.

Pourquoi cette différence entre courier écrit et parole ? Peut-être parce que quand on parle à quelqu'un, en regardant autour de soi on peut évaluer simplement la probabilité d'être entendu par d'autres gens. On ne peut pas faire ça lorsqu'on envoit du courier, on ne peut pas faire ça sur Internet. Peut-être aussi parce qu'il n'est généralement pas pratique de s'isoler lorsqu'on parle avec quelqu'un.

Dans la plupart des cas, la crypto, c'est comme une enveloppe: ça n'a aucune conséquence négative et, même si ce n'est pas un rempart contre quelqu'un de très motivé, c'est un obstacle pour ceux qui ne sont pas des espions, mais qui auraient bien jeté un oeil sur ton courier, simplement par curiosité.

Je suis persuadé que si on demandait aux gens: "voulez-vous que vos communications transitent en clair ou en chiffré, sachant que vous ne verrez pas la différence ?", ils opteraient pour le chiffrement.

Pour les développeurs web, avoir de nombreux moteurs de rendu à gérer est une bonne chose. S'il y en a deux ou trois, ça veut dire qu'il faut gérer les subtiles différences entre eux, mais s'il y en a douze, ça veut dire qu'on ne peut plus travailler comme ça, et qu'on est obligé de coder "pour les standards".

Un développeur web ne peut pas dire "je code pour les standards, si IE ne fait pas du bon rendu, c'est son affaire", mais c'est dû à la supprématie d'IE. Plus le marché des moteurs de rendu est compétitif et plus les standards vont s'imposer.

Par contre, je suis d'accord que KDE ne devrait pas avoir à gérer deux moteurs différents ayant le même but, c'est une source de problèmes inutile. Avoir un moteur puissant et lourd pour le web ainsi qu'un moteur ultra-léger mais simpliste pour afficher la documentation et les emails, par exemple, serait justifiable, mais avoir deux moteurs avec le même objectif...

Comme dit précédemment, Ruby n'a pas bougé depuis 2003 au moins, et PHP5 est sorti en 2004, donc si ce que tu cherches c'est remplacer PHP par quelque chose d'équivalent et de stable, pourquoi ne pas utiliser Ruby ?

Rails, quant à lui, est trop jeune pour qu'on lui demande de ne plus bouger, je pense. Je n'ai aucune idée de la durée de vie programmée de la branche 2, d'ailleurs je suis resté à Rails 1 pour mon usage personnel (différentes versions de rails cohabitent bien si elles sont installées avec Gem).

Je ne comprends pas ce que tu essayes de dire. Visiblement, tu critiques Rails parce que Passenger n'est pas inclus dans les versions d'Ubuntu déjà sorties (arrête-moi si je me trompe).

Je suppose que tu es au courant que Rails est inclus dans les précédentes Ubuntu (au moins les deux dernières), et ne nécessite pas Passenger pour fonctionner. Je n'arrive pas à comprendre en quoi l'arrivée de Passenger remet en question la stabilité de Rails, ou la pertinence du choix de Rails pour développer un site.

Il y a des critiques à faire concernant Rails, mais celle là me semble complètement infondée. Autant que de critiquer PHP5 parce que Redhat 5.2 ne l'inclue pas.

"Alors que pensez de ce texte ou l'auteur du PHP semble considérer son langage comme équivalent d'un framework (comme pouvant fournir les services que fournissent un framework)"

Je suppose qu'il faut préciser ce qu'on veut dire par framework, puisque c'est un mot qui n'est pas clairement défini. Si on décide qu'un framework, c'est un langage associé à un ensemble de bibliothèques, alors PHP est un framework, ainsi que Ruby, Python, Perl, Java, et les autres.

Dans ce cas, Rails n'est pas un framework, mais quelque chose qui se situe un niveau au dessus, de la même manière qu'en PHP on trouve CakePHP, Horde, et autres. Mais comme je ne les ai pas utilisés, je ne peux pas commenter.

Maintenant, après avoir jeté un oeil sur l'article en lien, j'ai simplement l'impression que l'auteur montre comment on code un framework MVC simple en PHP. Il y en a plein, des frameworks reposant sur PHP, mais ça n'empêche pas PHP d'être un langage, pas plus.

"PHP est bien en tant que tel un "modèle" de déploiement"

Si "cp" est un modèle de déploiement, alors oui. Mais ça n'a rien à voir avec PHP, il s'agit juste du fait qu'apache sait exécuter des scripts si on le configure bien. On peut obtenir la même chose avec d'autres langages de scripts, y compris Ruby-tout-seul, et en règle générale tous les langages pour lesquels il existe un mod_langage pour apache.

Pour remplacer PHP par Ruby, il faut activer mod_ruby. Ruby est livré avec un système de templates (ERB) semblable à celui de PHP, qui permet de l'utiliser de la même manière.

Il y a un moment où il faut redescendre sur Terre, et ne pas espérer qu'une distribution sortie en 2006 package un logiciel sorti en 2008. Baser son argumentaire là dessus pour "pousser" Linux en entreprise serait pour le moins amusant.

Si on veut vraiment utiliser un logiciel plus récent que sa distribution, il faut assumer le fait de l'installer soi-même.

D'autre part, Ruby fournissant un gestionnaire de packages qui lui est propre (rubygems), et rubygems étant packagé par Ubuntu, l'installation des extensions ruby se fait très simplement. Un coup de "gem install package" et c'est bon.

Difficile de comparer PHP et Rails, PHP étant un langage et Rails un framework. Il faudrait comparer un framework PHP avec Rails, ou bien comparer PHP et Ruby.

Je ne connais pas de framework PHP, mais je peux comparer les langages PHP et Ruby. J'ai commencé à utiliser massivement Ruby aux alentours de 2003, et je n'ai pas remarqué de changement ou d'instabilité depuis au niveau de la version principale, la 1.8. PHP 5, quant à lui, est sorti en juillet 2004, il existe donc depuis moins longtemps.

Maintenant, niveau framework, Rails est très jeune, et bouge pas mal. Il y avait assez peu de changements problématiques entre la 1.0 et la 1.2, mais il y en a plus entre la 1.2 et la 2.0, ce qui semble logique. Certains ont reproché à Rails de trop souvent casser la compatibilité ascendante au lieu de simplement déprécier les choses.

Quant à modrails, il vient de sortir, pas étonnant qu'il ne soit pas encore dans les distributions. Il faut quand même relativiser la difficulté de déploiement de Rails. C'est un peu plus pénible que de simples scripts à placer dans un répertoire accessible à apache, mais c'est beaucoup moins problématique depuis que la méthode "officielle" consiste à coupler mongrel et apache+mod_proxy.

Le principal obstacle au déploiement, c'est surtout que l'on a besoin de contrôler la config du serveur pour configurer mod_proxy. modrails ne changera ça que s'il commence à être activé massivement par les hébergeurs, ce qui est loin d'être gagné.

J'ai pense que Ruby a remplacé Perl. Il y a encore beaucoup de gens qui font du Perl parce que c'est ce qu'ils ont appris, mais je n'ai pas l'impression que ce soit un langage que beaucoup apprennent aujourd'hui, en dehors de domaines spécifiques comme la bio.

Quand j'ai appris Perl, c'était le langage novateur qui permettait de coder très vite de manière naturelle, maintenant cette description est plutôt appliquée à Ruby et Python.

Et en tout cas, en ce qui me concerne, j'ai commencé à utiliser Ruby à la place de Perl, puis à la place des autres langages aussi (dans la mesure du raisonnable).

Ruby sera stabilisé dans environs -5 ans, si j'en crois mon expérience. Je ne sais pas s'il est prévu qu'il remplace Python, mais je doute que les pythonnistes soient d'accord dans les années à venir.

Ça donnerait un nouveau sens au terme LiveCD...

J'aimerais rappeler que le libre c'est avant [tout] le choix: le choix d'utiliser du libre ou du non-libre

"J'aimerais rappeler que..." suppose que le sujet est dépassé, archi-connu, à tel point qu'on a parfois tendance à oublier l'évidence.

Malheureusement, cette phrase qu'on voit ressurgir de temps en temps, "le libre c'est le choix d'utiliser du libre ou du non-libre", j'ai bien peur que ça ne veuille rien dire. (Manger des pommes, c'est avant tout le choix: le choix de manger des pommes ou de manger des bananes.)

La notion de logiciel libre n'a rien à avoir avec le fait que tu aies le choix de les utiliser ou non. Elle concerne le fait que tu aies le droit de les étudier, modifier ou redistribuer. Le choix, tu le dois à ton libre arbitre, pas au logiciel libre.

(C'était la minute d'affection envers les drosophiles, vous pouvez retourner à vos occupations maintenant.)

Tu veux un screenshot d'emacs ou de nethack ?

Je ne comprends pas. Pourquoi gaspiller du temps à rendre une Ubuntu inutilisable par les gens normaux, alors que ce temps pourrait être réattribué à des projets beaucoup plus utiles ? Ce projet, dont le nom se prononce "gee, nuisance" en anglais, m'a tout l'air d'être une tentative de récupération par la FSF, qui trouve que Canonical lui vole son succès...

Soyons réalistes, qui envisagerait de donner à sa grand-mère une distribution sans accélération 3d, ne pouvant lire ni les mp3 ni le flash, et sans driver pour sa carte wifi ? Une distrib dont la principale feature est l'installation obligatoire du package vrms ?

(Bon voila, ça, c'est fait. Go.)

J'ai déjà répondu à ça, ici, ce qui confirme que la discution tourne en rond: https://linuxfr.org/comments/927758.html#927758

J'ai pris note de ta position et de ton mépris, je ne souhaite pas te faire perdre ton temps en t'obligeant à les répéter. D'autre part rassure-toi, mon égo reste intact. Bonne continuation, et au plaisir de te lire (en clair) dans tes prochains commentaires.