Jux a écrit 743 commentaires

La question fondamentale c'est où s'arrête le service d'un moteur de recherche ? Pour moi ça va plus loin que juste afficher 10 résultats. Dans l'idéal un moteur de recherche doit me trouver l'information que je veux.
Dans ce cadre là, si je cherche à acheter des chaussures, le fait que le moteur affiche une comparaison de prix entre tout à fait dans le cadre du service du moteur de recherche. De même que si je cherche une adresse, je trouve normal qu'il m'affiche une carte.

Par contre si je cherche "service de comparaison de chaussures", alors il doit me proposer des services qui font la comparaison (dont peut-être celui intégré, mais pas seulement).

Si je cherche pour mail par exemple, le fait de ne me proposer que gmail ne m'aide pas à trouver l'information que je veux. Par contre s'il m'affichait un comparatif (genre avec Google squared) des services disponibles, ça serait utile.

Bref, je trouve que c'est trop limitatif de définir le service d'un moteur de recherche comme une boîte noire qui sort 10 résultats.

Ce que tu appelle Google shopping, c'est la boîte "Shopping Results" avec une liste de produits/prix ?
En quoi est-ce déloyal ? Je ne vois pas en quoi le fait de comparer des prix devrait être un produit séparé. C'est une fonctionnalité du moteur de recherche. C'est la même chose que quand on cherche une adresse et qu'une petite carte s'affiche. Est-ce de la concurrence déloyale pour les autres fournisseurs de carte ?

Vu le nombre de backend supportés par Cairo (X, Quartz, Win32, Image, PDF, SVG, etc...), il ne doit pas être compliqué d'en écrire un pour Qt.

Wayland est capable de faire tourner Xorg (d'après les screenshots. Donc pour les applications utilisant des toolkits non portés, on doit pouvoir imaginer un mode compatibilité

On ne peut pas utiliser le GPU de la PS3 pour effectuer certains calculs de la même façon qu'on le fait sur les PC ?

Le fil de discussion sur la LKML parle de modules qui utilisent et link avec des headers/structures internes au kernel.

Le message de Linus dans ce fil, dont Florian Muller cite une partie, discute de la différence entre "avoir le droit d'utiliser un programme" et "avoir le droit de linker avec ce programme". Mais c'est toujours dans le contexte des modules kernel qui linkent avec des structures internes au noyau parce qu'il n'existe pas d'API pour les modules.

Bref, la citation de Linus dans l'article de M. Muller est complètement sortie de son contexte.

L'argument sur lequel se fonde Florian Mueller pour dire que la GPL devrait se transmettre à la lib bionic est que cette dernière contient ce genre de fichiers (il s'agit de fcntl.h ici):
http://android.git.kernel.org/?p=platform/bionic.git;a=blob_plain;f=libc/kernel/common/asm-generic/fcntl.h;hb=HEAD

Il s'agit en fait de headers auto-générés qui reprennent les structures nécessaire pour communiquer avec le noyau.

Maintenant, si on s'intéresse à la glibc, que Florian Muller conseille d'utiliser à la place de la lib bionic pour résoudre le problème, on se rend compte qu'elle fait exactement la même chose. Sauf qu'il n'y a pas de notice dans le header qui dit que ça a été généré automatiquement. Par exemple pour fcntl.h, il se trouve là pour la glibc :
glibc-2.9/sysdeps/unix/sysv/linux/i386/bits/fcntl.h

Et on trouve dans les deux fichiers des définitions de macros et de structures similaires. Sauf que pour la bionic ça ne serait pas normal mais pour la glibc oui ?
C'est quoi le problème alors ? Que pour bionic ça a été fait automatiquement ?

Donc pour suivre le raisonnement de ce cher Monsieur, la GPL du kernel va se propager à la glibc qui va se propager à n'importe quelle application tournant sur Linux. Cool, je veux les sources d'Oracle.

Aucun doute, un beau troll bien vellu du vendredi.

(Les sources de la glibc s'obtiennent via git ici : http://www.gnu.org/software/libc/ )

J'ajouterais aussi qu'une machine performante et multicoeur est très utile lorsqu'on compile du code. J'ai changé récemment de processeur (Core 2 Duo -> Core i5) et je vois une grosse différence sur des projets de l'ordre du dizaine de millier de ligne de code (ce qui reste petit).

Suivant le type de code que l'on fait, ça fait gagner un temps énorme de compiler en 30 secondes sur une machine rapide ou en 2 minutes sur une machine lente. Ca réduit aussi la frustration du développeur.

Certes, mais je ne vois pas en quoi une limitation de la liberté d'expression par les gouvernements à l'époque aurait amené à une meilleure situation.

Chapeau !

Ben oui, Facebook peut être utilisé avec intelligence (organisation de manifestations), mais ça peut aussi être utilisé par les gouvernement pour fliquer. Et alors ? C'est pas le premier outil qui est à double tranchant.

C'est d'ailleurs la même chose avec les mails (le FAI peut garder des traces) et à peu près tous les moyens informatiques (à part Tor?). C'est pas parce qu'on peut en faire une mauvaise utilisation que le moyen est forcément mauvais et qu'il faut trouver ça débile.

Maintenant je pense que les médias occidentaux ont tendance à surévaluer l'utilité de facebook. C'est parce que tous les gens qui utilisent facebook dans le monde occidental pour des trucs futiles vont avoir une sorte d'auto-justification en se disant "ah ouais mais c'est un outil qui aide à la démocratie, c'est bien". Néamnoins, si internet est coupé, c'est bien que ça aide.

En même temps quand un gouvernement doit recourir à l'état d'urgence parce que le peuple manifeste, c'est peut-être que quelque chose ne va vraiment pas dans le pays. Et c'est pas en gardant la même dictature que ça va s'améliorer.

Je trouve choquant qu'on puisse trouver normal de limiter la liberté d'expression au bon vouloir du gouvernement. Un des pilier du système démocratique est qu'on laisse le peuple s'exprimer. Si le gouvernement doit recourir à la censure pour se maintenir au pouvoir, c'est que c'est un mauvais gouvernement.

Il me semble que la majorité des utilisateurs utilisent finalement très peu d'applications (firefox, un lecteur de musique, openoffice, un logiciel de chat et un truc pour gérer des photos et un navigateur de fichiers). Pour ceux-là, c'est plutôt une bonne évolution.

Je me demande comment fonctionne la recherche des applications. Si elle est bien faite, en tapant "internet", tu auras ce qui était auparavant dans la catégorie internet qui apparaîtra.

En fait c'est clairement repompé du fonctionnement de OSX que je trouve plutôt agréable à utiliser à ce niveau-là (y'a d'autres niveaux, notamment la gestion des fenêtres que je trouve horrible).

Hé ho, c'est la volonté des développeurs d'Ubuntu (et des logiciels qui sont dedans) de le fournir gratuitement.

Y'a une espèce de mouvance ces derniers temps qui veut que tous ceux qui utilisent un logiciel fournit gratuitement par l'auteur sont des profiteurs. Il faut arrêter tout de suite. Si les développeurs de logiciels libres voulaient vendre leur logiciel ou forcer les utilisateurs à bêta-tester les nouvelles version, ils le mettraient dans la licence.

Il est intéressant de s'atarder sur la seule phrase en gras de l'article :
it’s the values which are important, and the toolkit is only a means to that end
En gros, ce qui est intéressant, c'est ce qu'une application permet de faire, le besoin auquel elle répond. Le choix de QT/GTK/autre c'est finalement une décision technique dont l'utilisateur final se fiche complètement.

Evidemment, le problème qu'il y aura si des applications Qt sont livrés avec Ubuntu par défaut, c'est le "look and feel". Ca demandera encore du travail pour qu'on ne puisse pas différencier entre une application écrite en Qt et une application GTK. Mais ça devrait être possible.

Je trouve que c'est une excellente nouvelle. Pour ma part, je préfère le "look and feel" des applications GTK (plus minimaliste en général), mais j'utilise Qt plutôt que GTK/Gnome quand il s'agit de développer quelque chose, parce que c'est tellement plus puissant et multi plateformes.

Concernant le choix du langage, on n'a malheureusement pas encore réussi à faire ce que Sweeney demande. C'est en gros un mix entre le typage extrêmement pointu à la Ada, de l'expressivité à la Haskell et des performances à la C++. J'aurais presque envie de proposer Scala, mais il manque les pré-post conditions sur les fonctions et les types d'entiers bornés.

Il y a peut-être une raison qui fait qu'un tel langage n'a pas vu le jour : c'est d'abord difficile à implémenter, mais ça peut être très très chiant à utiliser. Ada par exemple a un système de typage fort ou on peut dire qu'on veut un entier entre 4 et 7. Et ça va être vérifié à la compilation. Du coup, l'adage dit qu'un programme Ada qui compile va fonctionner correctement :-) Ceci dit le désavantage, c'est qu'on se retrouve avec des centaines de types d'entiers différents pour des programmes relativement simple et c'est vite ingérable. Bref, c'est vraiment dur de trouver le juste milieu sans faire un truc complètement illisible.

Et puis bon je ne suis pas sûr que ça soit le langage qui freine le développement des jeux. C/C++ est certes chiant à débugger, mais entre Java, Python et Ruby, on a déjà beaucoup plus de facilités. C'est surtout que les jeux vidéos deviennent vite très compliqués à développer. World of Goo est un bon exemple : le moteur physique tombe pas du ciel en un jour, quel que soit le langage utilisé pour le développer.

Je n'ai pour ma part pas vu beaucoup de bons jeux sortir de "The Game Factory". Ca donne souvent des trucs à la flash, c'est à dire avec 1 heure de durée de vie.

Les échecs sont quand même un jeu à information complète. Il est (théoriquement) possible de calculer l'intégralité de l'arbre des possibilités et donc d'évaluer les chances de victoire d'une position donnée.

Après en pratique on doit utiliser des heuristiques pour éviter de calculer tout l'arbre et c'est difficile à écrire. C'est d'ailleurs la même chose pour le jeu de Go, sauf que l'arbre des possibilités du Go explose beaucoup plus vite que celui des échecs.

Ceci dit, ça n'est pas parce qu'un jeu est déterministe et à information complète que c'est un jeu inintéressant. C'est pas parce qu'IBM a réussi à faire un ordinateur qui gagne au échec qu'il n'est plus intéressant de jouer aux échecs pour des êtres humains. Justement parce qu'un être humain il n'est pas capable de calculer l'arbre en entier et il va donc utiliser des heuristiques, des positions connues, etc... Il va devoir réfléchir quoi :)

Ouais mais justement, l'enjeu c'est que ça ne soit pas H.264 qui devienne le format par défaut sur le web, mais plutôt quelque chose de libre comme WebM / Theora.

Le problème avec H.264 c'est pas tellement qu'il soit propriétaire, c'est qu'il est encombré de brevets et qu'il faut payer des licences pour l'utiliser.

Go fournit des includes pour Makefile qui s'occupent à peu près de tout. Reste à spécifier la liste des fichiers à compiler. Ca a l'avantage de se reposer sur quelque chose qui existe partout (les Makefile) et de rester très simple.
include ../../../Make.inc

TARG=container/vector
GOFILES=\
  intvector.go\
  stringvector.go\
  vector.go\

include ../../../Make.pkg

http://golang.org/doc/code.html

En fait Apple utilise pas mal de GPL. Je te laisse regarder sur cette page qui concernant Mac OSX 10.6.5 :
http://www.opensource.apple.com/release/mac-os-x-1065/

Y'a entre autre Samba, les outils GNU (diff, make), grep, bash et d'autres...

C'est assez fou qu'une boîte qui utiliser énormément de code libre dans son OS[1] réussise à pondre des conditions d'utilisation qui plombent ce même open-source qui leur a permis de revenir sur le devant de la scène avec OSX.

Il faudra penser à mettre dans la GPLv4 que tout linkage entre un AppStore et du code GPL fait que l'AppStore en question doit permettre de distribuer du code sous GPL.

[1] http://www.opensource.apple.com/release/mac-os-x-1065/

Concernant le "bundle", je crois ça dépend comment ton programme utilise txt2tags. Si ton code est "linké" avec txt2tags, tu dois le distribuer sous la GPL (c'est la clause "virale" de la GPL). Comme tu inclus txt2tags dans ton code, j'aurais tendance à dire que c'est du linkage... Mais je ne suis pas juriste.

L'article de wikipedia (en anglais) sur la GPL résume bien le problème :
http://en.wikipedia.org/wiki/GNU_General_Public_License#Comp(...)

De plus, si ça te peine qu'on écrive un front-end propriétaire, pourquoi ne pas opter pour la GPL ? Ca d'évitera une incertitude quant à txt2tags et ça te protège contre cela.

Windows 7 a fait quelque chose de plutôt intelligent à ce niveau-là. Les onglets des applications (mozilla) s'affiche en miniature lorsqu'on passe sur l'icône de l'application dans la barre des tâches.
http://cybernetnews.com/wp-content/uploads/2008/10/windows-7(...)

C'est pas encore le WM qui s'occupe des onglets, mais ça s'en rapproche. Si je ne dis pas de connerie, alt-tab a le même comportement.

Dans un monde idéal, les navigateurs devraient intégrer une machine virtuelle (à la JVM) qui permette d'éxécuter du code écrit en n'importe quel langage dans une "sandbox". C'est ce que tente de faire le projet native client : http://code.google.com/p/nativeclient/

Puisque le monde idéal n'est pas encore là et que le seul langage compris par les navigateurs est Javascript, il serait intéressant de pouvoir compiler n'importe quel langage vers du Javascript. On pourrait ainsi écrire son application web en Python, C++ ou Haskell suivant l'humeur et ensuite déployer le "binaire javascript". Une rapide recherche Google m'a fait découvrir le projet "emscripten" qui permet de convertir du bytecode LLVM (donc à priori n'importe quel langage pouvant être compilé pour LLVM) en Javascript :
http://code.google.com/p/emscripten/

Est-ce que quelqu'un a des expériences avec ces projets (ou d'autres allant dans le même sens) ?

1. Il a jamais prétendu défendre les intérêts de Mme Michu
2. On est pas forcément obligé de toujours raisonner comme le mec lambda. Parfois c'est bien, parfois prendre un peu de hauteur et une vision globale, ça peut être intéressant.

Dans le cas où gmail tombe en panne, le fait que le reste du monde puisse quand même envoyer des mails est important. Si le mail fonctionnait comme skype (en réseau fermé contrôlé par une boîte), il suffirait a une personne mal intentionné de faire un DOS sur les serveurs de Skype pour mettre à genoux l'économie mondiale et probablement également pas mal de systèmes de santé/défense, bref une belle merde.

Alors voilà, un crash sur Gmail ça va clairement être chiant pour les utilisateurs de gmail, mais la répercussion globale va quand même être bien moindre.