ecyrbe a écrit 633 commentaires

Ce serait bien de remettre un lien en haut avec un bouton bien visible plutôt qu'un lien...

Alors j'espère que l'insertion d'images dans les commentaire ne se fera qu'avec discernement. Car sinon, bonjour la pollution visuelle. Bon, de toute façon il y aura toujours le pertinentage pour faire disparaitre les images indésirables

Bah il a raison, c'est moche... on peux souligner le travail et le souci de bien faire, mais le résultat n'est décidément pas très probant.
Celà n'a rien a voir avec la gratitude. En l'état, ce n'est pas utilisable, il faut savoir le reconnaitre et ne pas se fourvoyer pour justement espérer que celà soit corrigé.
C'est comme si tu reprochais aux utilisateurs d'un logiciel de remonter des bugs d'un logiciel sous prétexte que le programmeur l'a fait bénévolement...
Et bien justement, le développeur bénévole est généralement content qu'on lui remonte les bugs pour qu'il les corriges.
Ici, même combat. On espère que ça s'améliorera.

Faire un thread par client, à la vue actuelle du coût d'un thread (en mémoire et temps CPU pour le changement de contexte) est une très mauvaise idée.
Actuellement la meilleure stratégie consiste à utiliser le pattern Reactor (avec epoll ou select), associé à pool de thread (2 thread par processeurs est un bon consensus) pour gérer les travaux à effectuer (lecture/ecriture entrée/sortie asynchrones, calculs complexes, lancement de scripts [php/python/java/rails etc] etc ).

- quel est l'avantage de epoll sur select ?
L'avantage se situe sur l'algorithme de parcours et le nombre de connections simultanées que tu peux gérer. En effet, actuellement, tu es obligé après le select de parcourir tous les descripteurs pour savoir s'il y a quelque chose a lire. Avec epoll tu ne parcours que les descripteurs ou il y a quelque chose a lire. Dans un contexte avec de multiples connections, c'est indéniablement plus rapide.

j'ajoute le flag MSG_DONTWAIT
Tu peux utiliser fcntl(fd, F_SETFL, O_NONBLOCK) pour faire en sorte que la socket ne soit pas bloquante.

Socket: tu veux dire avec des fork et/ou threads ?
Non, celà signifie d'utiliser une boucle et d'employer des callbacks quand ce que tu as demandé a lire est disponible.
C'est le même principe pour les fichiers. on peut utiliser epoll aussi bien pour des sockets que pour des fichiers. Tu utilises O_NONBLOCK aussi sur tes fichiers et quand tu fait un read(fd,buf,count) tu dois gérer EAGAIN comme un cas particulier a la lecture asynchrone.

Petites suggestions techniques :

- utiliser epoll au lieu de select
- utiliser des socket non bloquantes
- mieux : utiliser des sockets asynchrones pour éviter qu'un client ne bloque les autres
- lire de manière asynchrone les fichiers sur le disque dur pour ne pas bloquer le processus sur un fichier
- annuler les requêtes d'un client s'il se déconnecte en cours de route pour ne pas bouffer de ressources pour rien.

Je te conseille vivement d'utiliser Boost::Asio (c++) pour faire ton serveur ou bien libgio si tu tiens a rester en C... ces librairies te permettent de programmer de manière asynchrone très facilement.

Alors, même avec visual c++ v6 sortie en 98 avait déjà la STL, ce n'est donc pas une excuse.

J'ai ouvert plein de fichiers... et je trouve le code très moyen sur mes critères actuels.

- Le code système dépendant mélangé avec le code indépendant. --> portabilité nulle pour linux
- Parfois utilisation du C, parfois du C++, pas de règles de nommage claire ---> maintenance affreuse
- pas d'utilisation de la STL ---> roue réinventée

Mon avis est que s'il fallait porter Arx Fatalis sous linux on aurait plus vite fait de recoder...

Et bien c'est faux! Il te suffit d'utiliser des techniques UDP du type STUN / TURN ou mieux ICE (cf : http://en.wikipedia.org/wiki/Interactive_Connectivity_Establ(...) )

ça dépend de ta religion...

La taxe ne s'applique qu'aux équipements vendus, me trompe-je ?

Oui, la taxe s'applique aux constructeurs de matériel permettant la copie privée. Il n'y a pas besoin de vente, il suffit de construire du matériel répondant aux critères pour des usages définis.
cf la loi en question : http://admi.net/jo/loi85-660.html

Je serais d'avis que les modérateurs changent la dépêche pour corriger ces erreurs, voire même qu'ils la suppriment.
Laisser passer un tel torchon en dépêche c'est vraiment moche.

Je pense que les modérateurs devraient prendre le temps de recouper les informations qu'ils valident en dépêche.

Non, Free est ici le constructeur, pas l'acheteur de disques "multimedia". J'ose espérer pour Free qu'il achète ses disques dur "interne" en gros et qu'il fait assembler le tout dans ses boites dans une usine.
Donc, Free construit des Freebox et à la fabrication il n'y a aucune taxe qui s'applique à ce moment là de la fabrication.
Cependant, la loi est claire. La taxe s'applique au constructeur, pas à l'acheteur et c'est la que tout le monde oubli qu'il ne paie pas directement la taxe, mais qu'elle est répercutée.
Donc Free, même s'il ne vend pas la Freebox, doit payer la taxe pour chaque Freebox construite.
Hors une exception pour les NAS professionnels est sortie entre temps, ce qui fait qu'ils ont eu l'idée d'intégrer le disque dur dans la Freebox Server et pas la Freebox Player...espérant du coup être exonéré de la fameuse taxe.
Mais ce n'est pas fini. Au 1er Novembre les choses ont été clarifiés et l'exception pour les NAS ont été précisées. Les NAS de salons (comme la freebox) tombent sous le coup de la taxe!!!!
cf : http://www.sorecop.fr/explicatif_decision_n12.pdf

Conclusion :
Free a construit son NAS pour être exonéré de cette taxe. Mais l'exception a été modifié pour prendre en compte les NAS aux particuliers. Donc Free l'as dans l'os, et devra s'acquitter quand même de la taxe.

Les dépenses de wikipedia c'est pour les chiffres les plus gros :
- 3,4 Million de $ en salaires pour 59 employés d'après le site de wikimedia
- 1,8 Million de $ en contractuels extérieurs
- 1 Million de $ pour l'agrandissement de l'infrastructure d'hebergement
- 1 Million de $ pour l'hébergement
- 690 000 $ pour la location des bureaux et les fournitures/matériel pour les employés
- 424 000 $ en déplacement. des employés
- 233 000 $ pour faire les campagnes de dons
- 180 000 $ pour les réunions/formations des employés.

En gros ce qui coute à mort, ce sont les employés et tout ce qui en dérive...j

Si tu parle de décentralisation chez l'utilisateur, c'est plus que compliqué. Le web n'a pas été conçu pour que les liens des serveurs sur lesquels sont hébergés le contenu changent à la volé.
ça pose des problèmes de rapidité pour retrouver qui héberge quoi, pour synchroniser les duplicata entre eux (pour assurer la fiabilité), pour gérer les conflits d'édition, pour qu'un utilisateur télécharge son article rapidement.
Par exemple le p2 c'est rapide, mais pas au démarrage. Le démarrage d'une session de p2p demande de faire des centaines des requêtes pour trouver l'information, puis la rapatrier.
Le temps de chargement d'une page web serait trop long. La décentralisation est plus adaptée pour de grandes données, des temps de latences pas important, et des données statiques.

Je ne connaissais pas. Certainement le type de backdoor le plus difficile a éradiquer, tous systèmes confondus.

C'est dans la V2 aussi, mais c'est moins explicite que dans la V3 : Cf la clause 7 :

For example, if a patent license would not permit royalty-free redistribution of the Program by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Program.

Donc, en gros, si Oracle distribue en GPLv2, ils donnent implicitement le droit à tous d'utiliser et de forker leur OpenJDK. S'ils attaquent, il n'auront pas d'autre choix que de ne plus distribuer OpenJDK d'après cette clause...

OpenJDK est sous GPLv2, du coup tu fork mais tu n'as de licence pour les brevets que tu viole (ni tes potentiels utilisateurs).

C'est faux. C'est écrit dans la GPL. Si tu met un logiciel sous GPL et que tu détient des brevets dessus, tu donne automatiquement le droit de ces brevets à tous les travaux dérivés de ton logiciel. Donc, tous les Forks d'OpenJDK son valides et ne violent aucun brevet.

Par contre, si tu ne fork pas (comme harmony d'apache), tu n'as pas cette protection sur les brevets, et le TCK ne te donne pas plus de droits. C'est pour celà qu'apache n'est pas contant et se retire.

J'ai l'impression qu'ils veulent se distinguer de KDE. En effet, les versions majeures ne sortent pas en même temps que KDE.
Je vois ça comme une volonté de sortir une version multiplateforme sans donner l'impression qu'il faut pour cela installer KDE.

>Parce que bon le modèle client-serveur, ça a ses limites. Surtout sur un simple ordinateur.

Je crois que tu veux dire client réseaux /serveur, non? parce que wayland est complètement fondé sur le principe du client serveur !
D'ailleurs, on peut créer un client wayland qui soit un serveur X, et ainsi avoir la couche réseau (et les autres fonctionnalités de du serveur X) sans grand effort.

Il n'y a plus de brevets sur le format JPEG. Depuis 2007, les 20 ans se sont écoulées sur la possibilité de demander quoi que ce soit sur ce brevet. De plus en 2012, plus personne ne pourra réclamer la moindre chose au format JPEG, puisqu'il a été officiellement normalisé en 1992.

Bah, tiens, vu qu'on a développeur de Firefox sous la main....
Peut tu nous dire, si le support de Direct2D sera rétroporté sur la version officielle de Cairo 1.10?
Est-ce que justement, le nouveau Backend OpenGL de Cairo ne fait pas un peu plus que permettre le compositing, mais aussi d'accélérer le rendu 2D comme pour Direct2D?
Vu que des drivers Gallium3D sous linux commencent à être utilisables et qu'il y a un support (certes encore incomplet) d'OpenVG, y aura il moyen d'activer ce dernier aussi sous linux? vu que cairo supporte aussi OpenVG...

Non sérieux? Et tu es ingénieur Microsoft?
DirectDraw c'est de juste une API pour faire du rendu accéléré, comme XV sous linux... ça n'accélère en rien le rendu de primitives 2D (ça ne fait que du blit accéléré). Direct2D ça fait bien plus, à savoir permettre le rendu accéléré de primitives de rendu 2D. L'équivalent d'OpenVG en somme.
Bref, faut arrêter de comparer des choux et des carottes...

Tu veux dire que biff tannen est bill gates dans notre continuum? c'est pas le pieds!

sinon, j'imagine que firefox collabore étroitement a Cairo (vu qu'ils s'occupent de la version Direct2D) sait-on s'il on intègré Cairo 1.10 (ou approchant) dans leur dernière bêta de 4.0 ?

A la vue du code sur le dépôt de firefox, il semble qu'ils en soient encore à la version 1.7 qu'ils synchronisent (avec des patch) plus ou moins avec les dernières version de cairo...
ça se trouve par là :
http://hg.mozilla.org/mozilla-central/file/58575263536b/gfx/(...)