Larry Cow a écrit 5011 commentaires

Il te propose gentiment. C'est pas s'il te prenait par la main, te téléchargeait l'archive et de demandait gentiment de presser "j'accepte" sans lire le texte afférent.

Il t'explique, en moins de 5 lignes (dont un lien) et sans la débauche d'images (moches) à laquelle la publicité traditionnelle nous a habitué, que OOo existe et que c'est bien. Bon effectivement, il pourrait se rendre compte qu'il est déjà installé, c'est vrai. Maintenant, de là à comparer ça avec les publicités kikoolol pour LiveMessenger...

http://openmoko.org/
http://opie.handhelds.org
http://gpe.handhelds.org
http://maemo.org/

Entre autres.

Pour afficher des images vectorielles, ou des animations simples, le support est effectivement inclus dans Firefox. Pour gérer des géométrie un peu complexes, ça rame assez rapidement.

Ca va forcément s'améliorer (déjà sous FF3), mais pour l'instant l'implémentation libre de SVG dans un navigateur est à la traîne face à la solution proprio. Le seul point positif par rapport à Flash, c'est que le plugin SVG proprio est voué à disparaître _très_ prochainement.

http://www.adobe.com/svg/viewer/install/main.html

Aussi, ceux qui râlent contre firefox + SVG, faudrait d'abord analyser ce qui plombe les perfs dans la page en question. Je n'ai pas regardé, mais si ça se trouve les scripts de cette page sont codés avec les pieds, tant au niveau Javascript, qu'au niveau SVG. En effet, SVG est plutôt riche, et comme dans tout langage, il y a des bonnes et des mauvaises façons pour créer les dessins.

Certes, mais il est comme tout le monde : trop de polygones, et il commence à saturer grave. Et pour ce que j'ai pu en voir, il sature nettement plus vite que le plugin Adobe.

Autant sur certaines applis tu peux te permettre de faire du low-poly, autant sur des applis scientifiques (dont la carto) ce qui prime c'est la précision de tes tracés.

Quelqu'un leur a déjà remonté que c'est dommage de dévoyer ainsi un format ouvert à un greffon fermé ?

Je crois, oui. Au pire, il y a une forge sur l'Adullact, tu dois pouvoir le faire toi même :)

Y'a aussi la carto (libre) de la ville de Meaux: http://www.carto.meaux.fr/

Plugin SVG requis également.

Je serai très heureux pour les utilisateurs de Gnome que KHTML puisse utilise Gtk (projet en développement...).

Maintenant, on dit "Webkit" :)

Un des domaines d'application pour lesquels SVG tend à dominer Flash, c'est bien le SIG (Système d'Information Géographique). Et pour cause, les principaux outils SIG libres savent cracher du SVG :
* PostGIS, l'extension spatiale à PostgreSQL, peut fournir une géométrie (résultat d'une requête, par exemple) sous forme de SVG.
* UMN Mapserver, son complice habituel (spécialisé dans la génération d'images à partir de données géo, postgis ou autres), sait également générer du SVG.

A partir de là, il est facile de deviner que les applicatifs libres (ou utilisant le libre) dans le domaine de la cartographie vont avoir une certaine propension à utiliser le SVG. Car en plus, le modifier à la volée est simple (un peu de PHP le fait très bien), y appliquer des feuilles de style est possible, et en plus on peut l'éditer avec des outils bureautiques libres (Inkscape).

Que demande le peuple?

Bon ok, il demanderait à pouvoir se passer du plugin Adobe (qui est frappé d'obsoléscence par ses concepteurs), mais c'est un détail. Gageons que dans l'avenir, on pourra utiliser les applications carto courantes avec un simple navigateur à jour et sans plugin tordu.

(juste pour info, malgré le plugin Adobe - réputé nettement plus rapide que FF - le truc suisse présenté dans ce journal rame copieusement, alors que les applis SIG sur lesquelles je bosse habituellement pas du tout)

Dolphin a été choisi pour KDE4, mais il existait déjà avant.

Pour moi, c'est l'exemple typique du défonçage sémantique. "Ca rentre pas? Mais si ça rentre!" (imaginer le bruit de matériaux divers forcés à mort, pour plus de réalisme).

En l'occurence, on ne parle pas de la _valeur_ de cette norme, mais de sa pertinence. Il s'agit d'une recommandation afférant à un protocole de communication. Sa valeur se juge - éventuellement - à l'intérêt que peut avoir cette "norme". Et ici, ce qui est mis en défaut, ce n'est pas son intérêt (la preuve, c'est justement un truc qui plaît encore malgré son statut) mais son actualité. La XEP est passée dans la case "trop vieux, poubelle", ce qui n'a pas de lien direct avec sa valeur (ou alors c'est du racisme anti-vieux, au choix).

Typiquement, un protocole comme comme Gopher n'a en rien perdu de son "actualité" dans le sens qui nous préoccupe (sa RFC n'est pas "deprecated" ou "frappée d'obsoléscence", justement). Pourtant, du fait de l'apparition de "nouveaux" protocoles qui le remplaçent (en mieux, de l'avis de beaucoup), Gopher est "déprécié". Il a effectivement perdu de sa valeur. On notera au passage que ce qui rend Gopher "has-been", ce n'est pas tant son age que l'apparition de la relève.

A contrario, le SMTP est un protocole passé d'age, mais faute de vraiment mieux, il reste (malheureusement?) d'actualité. Bon, ok, il y a ESMTP, mais on voit l'idée :)

En tous cas, déprécié ne convient pas du tout.

- meilleure gestion des smileys sous Psi (le principal développeur de gajim ne veut pas supporter les .jisp car la XEP est déprécié, mais ne propose rien en contre-partie)

Si je ne m'abuse, on ne traduit pas "deprecated" par "déprécié" (qui - en français - signifie "qui a perdu de sa valeur") mais par "obsolète" ("qui n'est plus d'actualité").

Ca doit pouvoir permettre - notamment - d'agréger des données géo et des données non-géo. Comme par exemple de mettre en lien une table spatiale des clients et des données non-spatiales concernant ces mêmes clients. Quelque-chose comme ça. Ou pas.

Je ne connaissais pas ce "-O", faudra que je vois s'il apporte vraiment quelque-chose (par rapport aux .pyc qui - rappellons-le - sont générés par défaut dès que les droits en écriture sont présents).

Parce que pour rendre du Python plus rapide, j'ai tendance à être plus intéressé par Psyco que par une forme à peine plus succinte du bytecode (sans compter que la taille ne fait pas tout, loin s'en faut).

Pour info, la première doc que je trouve sur ce flag:

When the Python interpreter is invoked with the -O flag, optimized code is generated and stored in ‘.pyo’ files. The optimizer currently doesn't help much; it only removes assert statements. When -O is used, all bytecode is optimized; .pyc files are ignored and .py files are compiled to optimized bytecode.

-- http://www.network-theory.co.uk/docs/pytut/CompiledPythonfil(...)

Pas super transcendant, même si ça a du s'améliorer depuis.

oui compilé , car faut optimiser

Python? Compiler? Comment?

(ceci est une vraie question)

Franchement, PyQT4 est assez terrible. J'ai pu l'utiliser pour de (petites) applications en entreprise, et ça le fait bien. Sous Windows (comme c'est souvent le cas en entreprise), tu peux toujours générer un binaire autonome avec py2exe (ou pyInstaller, mais j'ai pas testé), et bien malin le lambda qui devinerait que ton truc est en Python - surtout s'il ne sait pas ce que c'est.

Au final, j'avais ramené chez moi mon code du boulot, à l'époque, et je l'avais testé sur Linux et Mac : il marchait à l'identique. Bien évidemment, ça n'est valable que si évite les fonctions monoplateformes de Python (genre COM ou win32), mais ça tu le sais déjà.

Sinon, les rares tests que j'ai fait avec Jambi marchaient pas mal. Niveau déploiement, si j'ai tout compris, ça demande juste de rajouter un .jar dans ton déploiement. Mais, comme toi, je suis plus à l'aise avec Python que Java.

L'authentification se fait par le site qui héberge ton OpenID qui lui possède le SSL. La communication entre le site visité et le serveur OpenID est toujours cryptée (SSL). Grâce à cette technique le site visité n'a pas besoins de certificat SSL. Il est client de ton serveur OpenID comme toi tu es clients de sites SSL et que tu ne possèdes pas non plus de certificats sur ton PC.

Cela dit, si le site visité n'a pas les certificats signant ton serveur OpenID, comment peut-il être certain que c'est bien lui?

En fait, tout ça c'est un gros coup marketing ;)

Aller qui on loue un car et on y va ?

Autant prendre l'avion, comme ça on paiera qu'un aller-simple.

C'est facile : boycotter Total.

Accor, aussi, non?

I have see dozens of images of militaries shooting and beating to death demonstrators. Your government is killing itselft by doiing this.

I have seen lots of pictures showing soldiers shooting at demonstrators and beating them to death. Your government is commiting suicide by doing this.

(par exemple, et il y a surement encore matière à améliorer)

Si je ne m'abuse, le problème de licence n'est pas le seul obstacle de l'intégration de ZFS à Linux. Il y a une histoire comme quoi l'ami ZFS vient avec sa propre couche VFS, ce qui ferait double emploi avec celle de Linux.

Quels sont les avantages d'un noyau solaris plutôt que Linux ou BSD ?

ZFS, DTrace, etc... Non?

Non, ça c'est la piraterie.

Euh, bein si justement : pour moi l'intérêt est justement qu'en important le certif racine de CaCert, on accepte les autres, alors qu'en faisant sa pki maison, on ne marche qu'avec soi.

Rien n'empêche d'importer AUSSI la (les?) certificats de CaCert là où ils sont nécessaires. Mais j'aime autant séparer ce qui n'a rien à voir.

Et dire que "l'on ne veux pas forcément accepter tout ce qui a été signé par CaCert" cela veut dire enlever __aussi__ tous les autres certificats racine et ne pas les accepter "par défaut" alors que les navigateurs les packagent ... dur.

Ouimaisnon. Les vérifications d'identité effectuées par les professionnels de la PKI, quelque discutable que soient leurs méthodes et leurs plans tarifaires, n'ont rien à voir avec les pratiques de CaCert. Valider d'office les signatures de tous les clients de Thawte, ça n'est pas exactement la même chose que valider d'office tous les utilisateurs de CaCert.