__o a écrit 218 commentaires

Voir aussi http://www.korben.info/waka.html qui nous parle du côté bidon du site et des faux intervenants qui peuplent les commentaires

Et http://www.pcinpact.com/actu/news/57107-waka-commentaire-lib(...) à propos de la censure qui règne sur ce site

Ce n'est pas plus HTML5 que n'importe quel site web, c'est juste quelques images et un peu de javascript pour faire bouger les images (et du flash pour le son, parrait-il).

Ou alors HTML5 c'est le nouveau mot pour dire "page web avec des trucs qui bouge" ? Quand enfin plus personne n'utilise le mot DHTML, HTML5 vient le remplacer ? ;)

C'est juste que l'œil doit faire des efforts particuliers pour voir l'image d'un grand écran dans son ensemble, surtout à 0.5 fois la diagonale. À force tu développes (ou agrave) une myopie.

Fais un "lsof -nX|egrep '(deleted|inode=)'", ça affichera tous les fichiers ouverts supprimés

Merci pour le glossaire :)

Par contre OneToMany et ManyToOne (citons aussi ManyToMany) sont des termes utilisés pour définir la cardinalité d'une relation, et c'est utilisé en dehors du monde Java.

Si c'est comme le const en C++, ça ne concerne pas la valeur de retour, mais ça voudrait dire que la méthode size() ne fait aucune écriture et n'appelle que des méthodes qui elles aussi sont @ReadOnly.

Par contre le lien dit que ce ne sont que des exemples et qu'aucune annotation n'est proposée; que ça ne change pas la sémantique de java au moment de la compilation ni au runtime.

Et même en Latin : http://www.dmoz.org/World/Lingua_Latina/

Non, il y a vraiment des gens qui pensent que c'est une bonne idée de continuer à maintenir artificiellement en vie des langues mortes, parce que ça favorise la diversité, et que la diversité c'est la culture, la division des peuples, les conflits, etc.

Il devait aussi y avoir Thunderbird en Corse, mais les indépendantistes ont forkés.

(faites vous plaisir, vous pouvez moinsser)

Pas en Mégaoctet-seconde ;)

Si Perl utilise 2 fois moins de mémoire pendant 100 fois plus de temps, Java utilise 50 fois moins de mémoire ;)

Dans le benchmark "fasta":
- Perl consome 2,124KB pendant 342.60 secondes, soit 727682,4 KB-seconde
- Java consome 12,808KB pendant 7.75 secondes, soit 99262 KB-seconde
Donc Java consome 7 fois moins de mémoire sur ce benchmark.

Les benchmarks valent ce qu'ils valent, mais ils ont pas l'air du tout d'accord avec toi :
http://shootout.alioth.debian.org/u32q/benchmark.php?test=al(...)

Il y a [1], qui porte sur des projets open source uniquement. Le graphique ne contredit pas les résultats de TIOBE; C et C++ reprennent de la vitesse après une longue chute; inversement pour Java et C#; Perl n'arrête pas de tomber, Python est passé devant PHP et Ruby reste derrière Perl.

[1] http://www.ohloh.net/languages/compare?measure=contributors&(...)

J'ai cru voir qu'il y avait déjà un module en développement pour PHP, je suppose qu'il y en aura aussi pour d'autres langages (il suffit que quelqu'un s'y mette).

Free

Forcément tu vas retrouver les mêmes features dans tous les langages qui utilisent la lib PCRE ;-) (PCRE = Perl Compatible Regular Expression).

Tu veux dire qu'un logiciel libre c'est pas un logiciel qui est libre de droits, dans le domaine publique, freeware, shareware, non commercial et gratuit ?

__o/

Avec gensub ça marche:

echo 'class="foo">'|awk '/class=".+">/ { print gensub(/class="(.+)">/, "classe = \\1", "g"); }'

Le comique de répétition c'est rigolo, mais ce n'est pas là que je voulais en venir :)

C'est quand on vois des gens appeler IE "Internet", sans "explorer" , qu'on se rend compte du vrai problème. Les gens qui ne savent pas quoi choisir ne vont pas aller chercher plus loin que le truc estampillé "Internet", ils vont choisir Internet Explorer parce que c'est marqué Internet dessus, et que Mozilla Firefox ça leur dit trop rien.

C'est clairement un atout pour IE, et Mozilla aurait eu tout intérêt à glisser un petit "Internet" dans le nom de son navigateur sur ce coup là.

Plus que Windows, on peut y lire le mot Internet..

À défaut d'autre solution, tu peux créer une clé spécialement pour ce besoin et restreindre ses droits dans le authorized_keys:

command="/usr/bin/svnserve --tunnel --tunnel-user=xxx --root=/var/xxx",no-port-forwarding,no-X11-forwarding,no-user-rc,no-pty,no-agent-forwarding ssh-rsa xxxkeyxxx

Là ça autorise un utilisateur à se logger avec cette clé, mais il ne pourra parler qu'à l'entrée standard de svnserv (c'est ce que fait svn+ssh://) en tant que l'utilisateur spécifié par --tunnel-user et dans le repos spécifié par --root .

man authorized_keys et man svnserv :)

Joomla ou phpBB sont des trucs que tu peux utiliser si tu as besoin de leurs fonctionnalités d'origine (CMS/forum) et de les étendre, mais dans ce cas ce n'est pas forcément adapté, en effet :)

Je parlais plutôt de choses comme Symfony ou Zend Framework (ou des trucs plus petits), qui peuvent simplement être installés en tant que bibliothèques sur le système et utilisés par n'importe quelle application (et même plusieurs d'entre elles en même temps). Ça n'ajoute aucun pré-requis pour ton application (pas de base de donnée propre au framework par exemple) , leur installation se limite à une copie de fichiers (si il n'y a pas déjà des paquets dans la distribution), et ça s'héberge très bien sur des petites machines.

Bonjour,

Bravo pour cette contribution.

Comme tu le demandes, j'ai quelques remarques :
- Tu affiches des données venant de l'utilisateur ($_GET, $_POST, et tout ce que tu n'as pas définie toi même) sans les échapper, il est donc possible d'y injecter du code javascript (et voler mots de passe, cookies, comptes, exploiter une faille du navigateur, etc).
- De la même manière tu met des données venant de l'utilisateur directement dans des requêtes SQL, ce qui permet d'injecter / modifier la requête, et ainsi faire un peu ce qu'on veut avec ta base de données.

Pour corriger ces deux problèmes je te conseil de chercher "injection SQL" et "cross site scripting" sur ton moteur de recherche préféré.

Sinon, c'est toujours une bonne idée d'utiliser un framework, si petite l'application soit elle; car ceux-ci ont déjà tout ce qu'il faut pour ce genre de problématiques.

En plus des cookies il faut aussi :
- supprimer les "cookies" du plugin flash
- les différentes variétés de sessionStorage / localStorage ( http://www.google.fr/search?q=sessionStorage%20localStorage&(...) )
- et tous les autres trucs qui permettent de stocker explicitement des données chez le client

Et les features qui peuvent et sont détournées :
- Lorsque le navigateur a une resource en cache il fait quand même une requête avec des entêtes ETag et If-Modified-Since. La valeur de ces entêtes étant fixée par le serveur lors d'une requête précédente, ça sert aisément de cookies. (Solution : supprimer ces entêtes de vos requêtes, ou déactiver le cache)
- Le fameux CSS history hack, qui permet de trouver quels sites vous visitez ( http://www.google.fr/search?q=css%20history%20hack&hl=fr ) (Solution : désactiver l'historique)

Et votre unicité :
Parce que des "Iceweasel/3.5.2-debian-lenny-42 x86_64 fr_FR" avec le plugin gnash et des fontes russes installées il n'y en a pas 40, on peut être tout à fait unique sans le vouloir (et donc traçable). Voir https://panopticlick.eff.org/

> Tu n'es pas obligé de tout lire en une fois...

C'est sûr. Mais entre la rc1 ou la rc2 et la release il y aurait déjà matière à faire de bons articles sur les trucs importants :)

> Si c'est segmenté, on aura du mal à retrouver nos "petits" quand on voudra voir les nouveauté du noyaux.

Je verrais bien une news comme ça :

<article>
Les nouveautés :
* nouveauté 1 : lien vers l'article
* nouveauté 2 : lien vers l'article
* etc.
En bref:
...
</article>

1) Est-ce que c'est trop long à lire ou pas ?
2) Si oui qu'est-ce qu'il faut enlever ?
3) Z'avez d'autres suggestions ?

Ça serait bien de faire des articles plus petits, mais plus souvent (façon « release often »). On a rien pendant des mois, puis un article géant d'un coup :-)

Je pense qu'il serait profitable de publier certaines parties séparément, à des moments différents, entre deux releases (puis de les lier dans la news après).

« Stockage distribué DRBD », « Transaction TCP par cookie », et toutes les autres parties de « Nouveautés » auraient fait des news ou journaux à part entière. L'interview aussi. Etc.

Il y a plusieurs problèmes, même si on utilise pas le service explicitement :

- Déjà il y a des images hébergées sur gravatar sur pleins de blogs, ce qui leur permet de te tracer (sur quels blogs tu va, etc). Sur ce point ils n'ont rien à envier aux régies publicitaires, mais ces dernières ont le mérite de le faire explicitement. Gravatar on ne sais pas trop ce qu'ils font de ces données, mais il est évident que leur business-model est basé sur la revente de celles-ci.

- Ensuite quand tu commentes un blog: l'avatar générique qui t'est attribué est généré à partie de ton adresse email ou de ton pseudo. On peut donc savoir où tu postes, d’où tu postes, quand tu postes, etc.