Jux a écrit 743 commentaires

On va tapper sur Bjarne alors.

Concernant les failles de sécurité, si on code comme en C++ (et pas comme en C), on évite pas mal de problèmes. C'est à dire :
- string au lieu de char*
- vector au lieu de T*
- scoped_ptr au lieu de T*
- const T& au lieu de T*
- etc...

Je pense comme toi. Il m'arrive assez régulièrement d'acheter et de lire des bouquins au hasard (enfin, je lis quand même le titre et le quatrième de couverture). Je suis souvent agréablement surpris et parfois déçu.

Tu soulève d'ailleurs un problème important des systèmes de recommandations (last.fm, amazon, tout le reste). A force de ne nous recommander que des choses qu'on aime, il y a un risque de se fermer sur son univers. J'aimerais bien que ces derniers intègrent une fonctionnalité qui me propose quelque chose qui est justement éloigné de mes goûts.

Désolé mais l'image idyllique du petit libraire de quartier qui te conseille magnifiquement car il connait tes goûts et qu'il a lu tous les livres...ben c'est une chimère !

Et pourtant c'est vrai dans ma librairie de quartier. On a probablement beaucoup de chance, mais pour les clients réguliers, les libraires (2) savent quels livres ils ont lu et quelles nouvelles parutions ils pourraient aimer. Il m'arrive même de vouloir faire un cadeau à un de leur client régulier et de demander au libraire si le client a déjà tel ou tel bouquin.

Pour cette raison, je n'achète jamais de roman sur Amazon. J'utilise internet pour les bouquins techniques en anglais que mon libraire n'aura pas, mais pour tout le reste, je préfère largement la librairie. Surtout que j'adore l'ambiance d'une librairie et le fait de pouvoir toucher/feuilleter les bouquins.

Euh, comme je comprends, ça utilise purement du HTTP. Donc pour la répartition de charge & co, c'est comme avec n'importe quel autre site web.

Quand Linus s'énerver, il en sort quelque chose de bien (git). Reste à espérer qu'il s'énervera suffisamment sur make pour écrire un remplaçant :)

Sérieusement, les webmasters de journaux n'ont jamais entendu parlé de session, de cookie et d'autres méthodes qui permettent de savoir si l'utilisateur visite le site pour la première fois dans tel intervalle de temps ou pas ?

Un nombre impressionant de personnes que je connais, spécialement chez les plus tout jeunes, utilisent Google à la place de la barre d'URL (j'avais d'ailleurs vu quelque part que 'facebook' est une des requetes les plus fréquentes).
Ca va être drôle pour tout ceux-là, parce qu'ils risquent d'aller lire un autre journal à terme.

Si tu as des paquets uniques pour x86 32/64bits (peut-être certains ARM si des notebook ARM sortent) tu couvres la vaste majorité des cas d'utilisations. Pour les autres architectures, tu laisse les sources et les gens font comme au bon vieux temps. Bref, le but c'est de rendre la vie plus simple aux utilisateurs de base.

Bon maintenant, je pense que c'est un format de paquets qui s'adresse plutôt aux logiciels "haut niveau", genre des trucs bâtits sur GTK et QT. Donc pas des logiciels qui utilisent directement des appels systèmes au noyau. Il me semble que Qt a une ABI compatible à l'intérieur d'une version majeure. Comme Qt fournit des abstractions pour tout un tas de choses (threads, mutex, réseau), ça permet peut-être de limiter le problème ?

J'ai jeté un oeil au journal auquel tu fais référence.
Voilà la liste des fils de discussion :

• Le premier est une vrai question sur la génération de C89 vs C99
• Le second une remarque avec une petite pique sur le fait que tout soit en construction sur le site. Pas très pertinent, mais pas dévastateur.
• Le troisième part assez vite en discussion entre 3 personnes sur des détails qui n'ont plus grand chose à voir avec lisaac. Ca commence à causer de JS, .Net et de l'univers. Bref, ça dévie, comme souvent sur linuxfr.
• Le quatrième est un commentaire sur l'orthographe, qui ne sert à rien
• Les 3 derniers soulèvent des questions techniques.

Bref, je ne vois pas trop le problème. Personne n'a été insultant, les questions posées sont pertinentes.

C'est rigolo comme tu considère que les gens qui ne sont pas d'accord avec toi le sont parce qu'ils n'ont pas la "connaissance".

Je suis informaticien, je crois que le logiciel libre est une bonne idée, j'y contribue de temps à autre, j'aime beaucoup les discussions philosophiques sur la liberté et le contrôle et pourtant je suis chez gmail (pour une partie de mes mails).
Premièrement, parce que gmail permet un accès POP, donc je fais des backups régulière de mes mails, du coup je vois pas trop le contrôle que je perds. J'utilise gmail simplement parce que c'est la meilleure interface web, que ça fonctionne bien, etc...

Je suis tout à fait conscient que les ordinateurs de Google vont lire mes mails et afficher des pubs qui correspondent à ce qui est dans le mail. Ca ne me pose pas de problèmes parce que c'est le moyen de payer pour le service.

Maintenant, je comprends que certaines personnes ne veuillent pas que leur mail soient scannés par Google et je ne force personne à utiliser gmail. C'est d'ailleurs la beauté du mail, tu peux héberger ton propre serveur ou payer une entreprise pour le faire.

Et pourtant, je fais tout ça avec la pleine conscience des problèmes de liberté et de contrôle et je ne pense pas être plus con que toi.

Euh, c'est juste faux. Pour autant que tu aies configuré ton serveur correctement, avec un reverse DNS fonctionnant (ce qu'un serveur installé par un virus n'aura pas), personne ne va blacklister ton serveur. Je gère moi-même mon serveur mail depuis 4 ans et je ne me suis jamais fais blacklisté par personne...

Jamendo et les Creative Commons, ça n'a d'autre avantage par rapport à la culture propriétaire que de donner la possibilité de télécharger de la musique gratos sans se faire choper.

Ca permet de télécharger de la musique gratos parce que l'artiste en a décidé ainsi. C'est fondamental.

Ce sont les mêmes que pour les autres services Google :
http://www.google.com/intl/en-US/+/policy/
http://www.google.com/intl/en/privacy/privacy-policy.html

Donc les informations peuvent être utilisé pour améliorer le service de Google (ça inclut la pub), par contre elles ne sortent pas de chez Google sans avoir été agrégées (sauf si il y a une décision de justice, etc...).

J'étais sûr que quelqu'un allait me répondre ça. Mais les tests unitaires ne te permettent pas de tester toutes les interfaces, parce qu'en général les interfaces complexes, tu les implémente via des mock. Donc même si ton interface a changé entre deux, il y a de grandes chances que ton mock continue à fonctionner.

Java et Python ne couvrent pas (tous) les mêmes cas d'utilisation. Python n'est pas compilé et si ce n'est pas un problème pour des petits à moyen projet, c'est un gros problème pour des gros projets. La compilation permet de vérifier les interfaces, d'avoir une erreur de compile quand un petit malin a changé une interface. Ca permet d'éviter un certain nombre (pas tous) de problèmes en amont alors qu'avec Python ça va péter lors de l'exécution, ce qui est vraiment lourd quand ton programme prend 10 minutes à se lancer (distribué sur plusieurs machines, toussa).

Dans le cas d'un débordement d'indices de tableaux, une ArrayIndexOutOfBoundException (ou n'importe quelle autre exception) ne permet pas d'écriture arbitraire en mémoire alors que C/C++ ne garantit pas d'avoir une segfault. De même, un déréferencement de pointeur non-initialisé ne va pas forcément se traduire par une segfault (si tu n'as pas de chance et qu'en fait ton pointeur pointe sur quelque chose d'atteignable).

Après, bien sûr que si on code de manière potable en C++ en s'interdisant les trucs vraiment dégeu, en évitant l'arithmétique de pointeurs et en utilisant une macro CHECK pour spécifier des contrats sur les méthodes et en lançant régulièrement valgrind et de l'analyse statique de code, on arrive à avoir quelque chose de sécurisé.

C'est juste que Java est plus sécurisé par défaut que C++. De toute manière, même en ASM ou en brainfuck tu peux faire un programme sans failles, la question intéressante c'est que certains langages ont choisit d'imposer plus de sécurité par défaut. Ca a évidemment un coût et j'imagine que c'est la raison pour laquelle développer un kernel en Java n'a pas tellement de sens.

Ceci dit ça dépend fortemment de ce que fait l'application. Pour Transmission, c'est relativement simple niveau interface (il faut afficher une progression et des options) et la grosse partie de l'intérêt de l'application c'est ce qu'il y a derrière (télécharger des torrents).
Pour une application à la Inkscape, Gimp ou Digikam ou il y a nettement plus d'interactivité et de fonctions liées à l'interface, c'est je pense nettement plus dur de faire une séparation nette sans pondre un code horriblement compliqué.

Je ne vois pas l'intérêt de rajouter une couche. Surtout qu'il y a des différences fondamentales dans l'ergonomie entre QT et GTK et même avec un framework par-dessus, ça va être difficile à gommer.

En plus, QT est nettement plus portable que GTK. GTK hors du monde Linux, c'est assez l'horreur niveau ergonomie alors qu'une application QT ressemble à quelque chose sous Windows ou OSX.

Ca peut apporter que si tu n'aimes pas l'idée d'avoir des pubs (ciblées), tu peux les enlever. Honnêtement, avoir mes données sur un service centralisé, je m'en fous. Ce que je veux c'est :
1) Ne pas avoir de pubs
2) Etre sûr que mes données ne seront jamais transmises à un tiers autre que l'hébergeur
3) Pouvoir supprimer mes données
4) Pouvoir faire des backups simplement
5) Contrôler qui à accès à mes données. Je veux que certaines de mes photos soient publiques, d'autres pas.

Google+ offre tout ça sauf le point 1). Je serais prêt à payer un abonnement mensuel pour avoir le point 1). Ca serait aussi un bon moyen de faire taire beaucoup de critiques sur l'exploitation de la vie privée puisque si tu paie l'hébergeur, il n'a pas besoin d'exploiter ta vie privée pour faire de l'argent.

Mouais, je ne suis pas juriste, mais je ne suis pas sûr que ça soit si scandaleux que ça. N'importe quel service en ligne qui héberge des fichiers doit les copier et les transformer (pour faire des aperçus, etc...) et ils mentionnent bien "dans la mesure raisonnable et nécessaire pour le service". Reste à définir ce que raisonnable veut dire, mais comme tout texte juridique, c'est un peu flou :-)

Il me semble que c'est d'ailleurs dans les CGU de la majorité des services en ligne que j'ai lu. C'est probablement pour éviter des poursuites débiles du genre "ahah vous avez reproduit mes fichiers dans un autre datacenter sans ma permission".

Bref, j'ai plutôt l'impression que ce genre de conditions naissent du fait que le droit d'auteur actuel a été fait pour le monde physique et que ça ne se transpose pas bien au numérique.

C'est peut-être aussi dû aux Etat-Unis où les "class action" (procès groupé de client contre une entreprise) sont un gagne-pain pour beaucoup d'avocats et où ça pousse les entreprises à être excessivement prudentes. Par exemple, les pubs pour les médicaments à la télévision, c'est complètement ridicule : Il y a 10 seconde où la voix off vante le médicament suivit par 30 secondes (je n'exagère pas) d'avertissement sur les divers dangers ("ne prenez pas si vous êtes cardiaques / si vous avez de l'hypertension, ce médicament peut, dans certains rares cas, être fatal").

Pour le modèle économique, pourquoi ne pas essayer la pub ? Il faut probablement faire une petite étude pour voir combien de pubs il faudrait pour rentabiliser le développement.

Si tu pars sur un modèle basé sur la pub, tu peux proposer un abonnement aux groupes et/ou aux visiteurs qui leur permet simplement d'enlever la pub. Il est fort probable que la grande majorité des gens préfèrent voir des pubs, mais pour ma part, je serais prêt à payer sur certains sites gratuits que j'utilise.

Le hic, c'est qu'il est aussi extrêmement difficile pour un humain de trouver la solution optimale d'un problème NP-complet non-trivial (bonne chance pour résoudre un voyageur du commerce à 100 noeuds). Le problème fondamental, c'est qu'on utilise en général la notion de complexité algorithmique pour des problèmes sur lesquels les ordinateurs sont justement plus forts que les humains, parce que ce sont en général des algorithmes qui demandent "juste" des calculs. Et les ordinateurs sont très forts au calcul.

Par contre, le lien que tu donnes chez Microsoft demande de reconnaître des photos de chat. La difficulté du problème ne réside pas dans la complexité algorithmique, mais dans le fait qu'on ne connaît juste pas d'algorithme (même NP) qui permette d'approcher la capacité humaine à interpréter une image.

Je pense que si tu veux un CAPTCHA qui ne soit pas crackable automatiquement, il faut plutôt s'orienter sur des domaines où les ordinateurs sont mauvais (reconnaissance d'images, interprétation de texte, etc..).

C'est surtout un peu absurde. Quel est l'intérêt de reconnaître la forme d'un pays sans son contexte ? Ca me semblerait nettement plus intelligent de donner une carte du monde, de laisser certains pays blancs et de demander de remplir. Ca permet d'utiliser d'autres moyens que juste la forme pour reconnaître un pays, genre savoir que le Japon c'est juste à côté de la Corée du Sud, etc...

Ca n'est pas de la sécurité par l'obscurité. Ce que propose l'auteur du journal, c'est d'utiliser SHA(url|password). L'url est facile à connaître, mais ne permet pas de découvrir le mot de passe. Donc si tu utilise un mot de passe fort, ça va être tout autant sécurisé qu'utiliser un gestionnaire de mot de passe. Dans les deux cas, le seul moyen de cracker la chose est de connaître le mot de passe maître.

Ceci dit, la page en question utilise SHA1, qui n'est plus sûr. Il y a SHA2 qui fait ça bien mieux.