ecyrbe a écrit 633 commentaires

Ça ne contredit rien du tout.

Elles peuvent influer sur les gouvernements, ce n'est pas pareil.
N'importe qui peut faire du lobbying auprès des institutions. Le monde du libre aussi fait du lobbying.

L'obligation de passer par un juge dans HADOPI est clairement issue issue d'un lobbying anti-HADOPI. Par contre laisser des outils de flicage aux main du pouvoir c'est ça qui est dangereux pour la démocratie.

Aujourd'hui la loi informatique et liberté protège tout un chacun sur les données agrégées par une société sur ses utilisateurs. Si vous avez fournit sciemment des informations, vous avez un droit d'accès et de répudiation sur celles-ci.

Si une société rechigne à se conformer à la loi sur ce point, vous pouvez attaquer en justice pour faire valoir vos droits.

Il y a une différence de taille : d'un côté la fourniture de données est volontaire, de l'autre elle est involontaire, c'est pour moi une grosse différence qui m'empêche de mettre les deux situations en relation.

Personnellement, que des données soient exploités à des fins commerciales (Google) ou à des fins sécuritaires (état) ce n'est pas du tout la même chose.
D'un côté à l'extrême t'es spammé de pub ciblées, de l'autre dès que tu dis un mot de travers tu risque le goulag... non franchement, laisser l'état ficher les gens on a déjà vu ou celà peu mener et c'est pourquoi ce n'est pas tolérable à l'inverse d'une société commerciale aussi riche soit elle qui n'a aucun pouvoir législatif, exécutif, militaire...

Si c'est déjà implémenté dans Gtk+ 2.18 avec Client Side Windows... news que j'avais rapporté il y a quelques temps

Et bien tu as tout faux...
Gtk donc Gnome utilise cairo comme backend graphique. Dans cairo il y a aussi un mode raster, opengl (en cours de refonte actuellement), xlib, xcb, svg, pdf, ps, etc... par défaut c'est le mode xlib qui est employé et il utilise quand celà est disponible XRender...

Non, n'importe qui qui achète un produit contenant du code GPL peut faire valoir ses droits à recevoir ce code!
Donc si les plaignants ont acheté le matériel mis en cause, ils ont le droit d'attaquer... pas seulement ceux qui contribuent au code.

La chine est aujourd'hui une des plus grande source d'attaques informatique... bloquer leur ip, c'est un peu se préserver de leurs attaques.
ça à l'air con, mais sur pas mal de serveurs que j'administre les tentatives d'attaques viennent souvent de chine...

Tout plein de systèmes de blacklist :
- Blacklist IP
- Blacklist geoIP (bloquer toutes les IP chinoises par exemple)
- Blacklist FAI

Utiliser un système de noeuds de serveurs décentralisés pour la recherche de clients et de fichiers. cf DHT

Ne permettre à l'IP du logiciel que d'être envoyé à ceux qui ne sont pas sur les blacklists.

Ca fait quand même un bail que c'est connu.
Contrairement au titre, il ne s'agit pas de vrai push, mais d'une sorte de polling persistant. On appelle cette technique long polling et dans sa version plus poussée, http streaming.
En gros on garde une connexion ouverte avec le serveur (jusqu'à ce qu'elle soit coupé ou perdue) pour être notifié par le serveur quand il y a des changements.
Celà demande donc de mettre en place un protocole au dessus d'http pour pouvoir parser les notifications de manière générique.
Par souci de simplicité on utilise généralement JSON, car c'est un format naturel pour le javascript.
Toutes les grosses plateformes du marché utilisent déjà ce genre de techniques : gmail, facebook etc...
Dans la même veine qu'APE il existe donc gwt-comet.

Sous Gnome, il y a un plugin youtube pour voir les vidéos directement sans flash...
C'est incroyablement plus fluide et moins consommateur en CPU.
Dans Moovida de fluendo il y a aussi un plugin pour youtube.
http://www.moovida.com/ (en GPL)

Il doit y en avoir d'autres...

Je parles de théorie... je ne suis absolument pas pour la mise en pratique d'un tel système, ne serait-ce que pour la perte de l'anonymat.
Je dis juste que rendre le vote électronique infalsifiable est possible.
Pour continuer dans la spéculation la plus totale, on pourrait vérifier que son vote est le bon, en ayant un lecteur de carte portable...
Tout ceci c'est mettre en place une artillerie lourde pour écraser des mouches... le cout du vote électronique est de toute façon trop cher.
De plus, le recompte des votes s'il y a un soupçon devrait se faire en relisant les cartes électroniques (donc refaire venir les gens ayant votés). Donc en pratique infaisable.
Dans élaborer quand même sur ce type de systèmes, c'est la carte électronique qui doit signer le vote et l'envoyer à la machine.
Ainsi la clef privée n'est jamais connu de la machine, ce qui évite que la machine puisse falsifier ton vote.
La lecture des votes se fait grâce à la clef publique transmise en même temps que le vote signé par la machine.
La partie qui pourrait être compromise dans ce système serait le système de lecture des votes qui pourrait s'en foutre royalement de ce qu'il lit et présenter un résultat différent...
La solution à ce problème serait de faire en sorte que la machine ne serve qu'à stocker les votes... et d'avoir des machines indépendantes pour lire le résultat des votes ( lecteurs open sources par exemple) et chaque citoyen pourrait vérifier le résultat en utilisant sa propre machine de lecture... la validation du bon fonctionnement de la machine de lecture pourrait se faire en lui donnant un carte témoins et vérifier que le résultat sorti est celui escompté.
bref, super compliqué, cher, non anonyme à cause des signatures...

un système infalsifiable et vérifiable pourrait exister... mais il devrait être basé sur un système de clef privé/publique et de signature électronique embarquée dans une carte à puce et que celle-ci puisse garder en mémoire le vote effectué.
Mais celà suppose que le vote anonyme n'existerait plus.

D'ailleurs, le système de vote à bulletin secret est tout sauf infalsifiable... changer une urne est toujours possible.

Donc dans la théorie, seul un système informatique pourrait être infalsifiable. Cependant, le vote électronique actuel, ne met en jeu aucune de ces techniques...

Il existe une version Qt pour maemo en developpement. Je pense qu'elle doit pouvoir s'adapter au desktop aussi :

http://labs.trolltech.com/blogs/2009/10/23/qt-de-spotify-run(...)

D'ailleurs, les développeurs de llvm-gcc souhaitent migrer leur implémentation en utilisant ce système de plugin.
Celà permettra à llvm-gcc d'être à jour avec les dernières versions de gcc sans avoir à forker à chaque fois gcc...

j'en arrive à la même conclusion... il y a une erreur en B

Le souci, c'est que WPF n'est pas utilisable qu'en C++/CLI et non directement en c++ natif! On est donc obligé d'utiliser la plateforme .NET pour en tirer parti... l'idée était bonne, mais l'enfermement de cette techno en fait un frein direct à son utilisation.
Ce serait bien de transmettre le message aussi...

cette monstruosité comme tu l'appelle, il y en a plein dans les MFC... tu ferais bien de transmettre à tes supérieurs....

- pour remplacer gnomecanvas il y as déjà une alternative maintenue et très fonctionnelle :
* gooCanvas

Grâce au développement de client side windows dans gtk, gooCanvas pourra enfin embarquer des widgets natifs Gtk. Chose qui manquait aux développeurs de gtk pour l'inclure.
Je suppute donc que toutes les application dépendant de GnomeCanvas se verront recommandées de passer à gooCanvas.
Si l'intégration dans gtk se fait, celà deviendra certainement un composant nommé GtkCananvas.

Pour appuyer ma définition, je te renvois à la définition donné par wikipedia d'un langage interprété : http://fr.wikipedia.org/wiki/Langage_interpr%C3%A9t%C3%A9_in(...)

Alors non, la CLR nécessaire pour lancer un programme C# est une machine virtuelle. Sans la CLR, impossible d'executer du code C# compilé Byte-Code. C'est bien la définition d'une machine virtuelle, que la machine utilise JIT(Just In Time compilation) pour exécuter le byte-code ne change en rien que la CLR est une machine virtuelle, tout comme la JVM de Java en est une (et qui fait aussi du JIT).
En C# le byte-code est donc bien interprété, cette interprétation utilise la technologie JIT qui permet de gagner en performance, mais celà ne rend pas ma phrase fausse pour autant.

Tout à fait. ça m'apprendra à faire des phrases trop longues.

Oui, le but du projet vala-benchmark est d'être inclu dans le projet "computer language benchmarks game" que tu cites.
Ceci explique qu'ils utilisent les même benchmarks.

Vous pouvez aller jeter un oeil au projet vala benchmark pour voir la difference de performance entre Vala et du C à l'heure actuelle.

http://code.google.com/p/vala-benchmarks/wiki/BenchResults

Non, c'est ce que j'explique, l'ABI et l'API restent identique, vu que le même .h reste généré...
Les langage de script resteront compatible. c'est la beauté de Vala.

Un compilateur sans intermediaire en C ne verra certainement jamais le jour pour la simple et bonne raison qu'on perdrait la possibilité de générer des bibliothèques réutilisable en C.
Le fait qu'il y ait un code intermédiaire en C à été voulu par les concepteurs du langage.
En fait, toutes les librairies au dessus GObject (comme Gtk) pourraient être réimplémenté en Vala et continuer à avoir une ABI et une API compatible avec celle d'aujourd'hui.

Les performances obtenu en vala sont les mêmes que celles obtenues si on avait programmé la même chose avec GObject.
C'est là l'un des gros atouts de vala, pas de perte de performance. Les développeurs de vala ont justement conçu le langage pour que le mapping en C soit très proche de ce que l'on écrit nativement.
En regardant de près le code généré, on remarque qu'il y a quelques différences par rapport à ce que l'on écrirait à la main.
- Les boucles for sont traduites en boucles while ce qui peu réduire les chances de voir les boucles statiques optimisée par le compilateur.
- les déréférencements ont systématiquement un test pour vérifier que le pointeur n'est pas null, chose qui ne pourrait être vérifié qu'une fois.

je ne doute pas qu'il y a d'autres points ou la transcription n'est pas (encore) parfaite, mais il me semble aussi que ces points sont facilement améliorable, et ne remet pas en cause le fait qu'on peut générer un code C aussi rapide que celui qu'on aurait écrit à la main.