Antoine a écrit 5722 commentaires

Tu fais du Python maintenant ?

Si le système est virussé, il est capable d'intercepter l'exécution de ce genre de programmes.

Tu pourras même remarque que pour une même marque, les barrettes "value" ont un taux de retour moins élevé.

Elles n'ont pas le même public non plus, et les zozos overclockers qui achètent des barrettes "haut de gamme" ont tendance à les pousser dans leurs derniers retranchements.
(ils seront peut-être aussi plus du genre à lancer memtest régulièrement, alors que l'utilisateur lambda ne soupçonnera même pas un défaut de mémoire s'il a un plantage tous les mois)

En fait, concernant les barrettes noname, on peut faire une observation intéressante, liée à la réputation. Lorsqu'une compagnie A produit des chips ou barrettes qui se trouvent être défectueuses, il y a deux cas possibles :
- ces barrettes étaient vendues en "noname", la responsabilité se perd donc (sauf client très perfectionniste qui va essayer de retrouver des références sur Internet)
- ces barrettes étaient vendues sous la marque de la compagnie, et la réputation de la compagnie peut en souffrir (s'il y a beaucoup de cas)

Conclusion logique : une compagnie a intérêt à appliquer un processus qualité plus contraignant sur les barrettes vendues sous marque, que sur les barrettes vendues en noname, parce que c'est sur les premières que se fera la réputation (bonne ou mauvaise) de la compagnie.

Et j'ai failli oublier, le mode insulte ... J'ai activer ça sur les serveurs, tu te fais insulter quand tu entres faux ton mot de passe ... C'est vraiment bien.

Vachement intelligent, ça. On sent l'administrateur système qui aime rendre la vie facile et agréable à ses utilisateurs. J'espère qu'ils ne se gênent pas pour te retourner la pareille :-o

http://www.inria.fr/valorisation/brevets/index.fr.html
(ça s'arrête en 2005, pas ma faute si le site de l'INRIA est pas à jour)

L'INRIA étant un établissement de recherche en informatique, la majorité des brevets déposés sont logiquement des brevets logiciels.
Un exemple (2003) : « Algorithme d'optimisation pour la poursuite d'un point de fonctionnement sur la sphère de Poincaré appliquée aux transmissions optiques ».
Donc, voilà, l'INRIA brevète des algorithmes.

Bosser = déposer des brevets logiciels ?

Dans ce cas, autant prendre un bon framework tout-en-un ala Django.

Le jour où Django supportera correctement SQLAlchemy, peut-être ;)

C'est un peu le bordel, oui. D'ailleurs je suis étonné de cette dépêche car n'importe quel nouveau projet devrait utiliser la version 2.0 (ou la 2.1 quand elle sera sortie) plutôt que la 1.1.
(la présence de MochiKit comme bibliothèque Javascript est un bon avertissement :-))

En même temps, ça montre qu'ils n'abandonnent pas leurs utilisateurs, ce qui est plutôt chouette.

je pense/pensais que l'immense majorité des programmeurs (entre autres, mais là on parle d'outils pour programmeurs) est très confortable avec la lecture de l'anglais.

Certains zozos en entreprise sont parfois bien mal à l'aise avec l'anglais (même sa simple lecture).
Ceci dit, ces zozos produisent souvent aussi un code assez horrible, au point qu'on a du mal à leur accorder le titre de programmeur.
(pour un rendu plus précis, remplacer zozo par « ingénieur Java » par exemple :-))

Il y a bien le rendu HTML clignotant en deux images de "Germaine se déchaîne"...

Je ne suis pas sûr qu'une grosse institution comme l'ISO réussisse à s'auto-financer rien qu'en vendant des exemplaires de leurs normes... Qui ici a déjà acheté une norme ISO ?
(mais je ne demande qu'à être convaincu, hein)

Et c'est écrit en Javascript...
« Much of the code of the shell is written in Javascript »
http://live.gnome.org/GnomeShell

C'est pas un publi-reportage, c'est un communiqué de presse :)

Oui, STUN aide mais on se retrouve dans la situation louffoque où un protocole sans établissement de connection (UDP, par exemple) à besoin d'un établissement de connection

Si tu veux prendre "connexion" au sens large, alors de toute façon la plupart des protocoles applicatifs passant en UDP ont en général une notion de "connexion" ou "session".
SIP, par exemple, est un protocole dédié à l'ouverture de session.

On se retrouve dans une situation où un système distribué et résistant aux pannes devient dépendant de la survie d'un intermédiaire

Pas besoin des NAT pour cela, tu auras du mal à communiquer avec quiconque si le backbone de ton FAI ne répond plus.

ou un module de tracking de connection (ftp, ...) est nécessaire pour compenser.

Le dit module de tracking de connexion est en général déjà implémenté pour les firewalls, de toute façon.

Si, ça gène. car par exemple pour bittorrent, il faut forwarder des ports mais bon voila, j'ai plusieurs machines derrière le nat. En conclusion, une seule machine peut faire du bittorrent.

??? Bittorrent réclame 65535 ports par machine ?

Quel dépense d'énergie inutile !

Ah, je suis d'accord que ça fait bosser des développeurs tout ça :)

PC1 dit à intermédiaire HELLO Je suis là et PC2 fait de même. L'intermédiaire établi une connection fixe entre PC1 et PC2,

Tu n'as pas l'air de comprendre. Seuls les premiers messages passent par l'intermédiaire, afin de percer un trou dans les deux NATs. Les messages suivant passent directement de PC1 à PC2.

C'est un peu comme quand ton navigateur va voir www.google.com, tu te connectes une première fois à un DNS qui te donne l'IP du serveur, puis tu ne retournes plus voir le DNS.

C'est donc un mandataire temporaire, et en régime permanent tu te retrouves dans le cas simple, à savoir :

PC1 -- ( NAT ) --- ( NAT ) --- PC2

De plus, les boites effectuants du nat doivent effectuer du trackage de connection même pour l'UDP

Pas vraiment une connexion, juste un mapping. Les ports ne sont pas réservés et n'importe qui peut s'immiscer. Il n'y a rien qui s'apparente à une connexion au niveau réseau.

Sans nat, c'est PC1 envoit un paquet UDP à PC2 et c'est tout. Il n'y pas d'établissement de connection. Les réponses passent aussi facilement.

Ah, ben, on a jamais dit le contraire...

pc1 --- nat1 --- intermediaire --- nat2 ---- PC2

Ce schéma n'est nécessaire que lors de la mise en relation entre PC1 et PC2. Ensuite, si les NATs sont du bon type (full-cone, le type majoritaire chez les particuliers), les paquets subséquents peuvent aller directement de PC1 à PC2 sans passer par l'intermédiaire.

Du reste, tu as déjà un NAT dans ta *box, et je ne crois pas que cela gêne trop l'accès aux réseaux P2P, si ?

Qu'appelles-tu "connecté" ? Beaucoup de réseaux P2P fonctionnent en UDP.
De toute façon, pour entrer sur un réseau P2P, il faut bien passer par un premier pair connu (pas question d'avoir une liste statique de pairs, au pire un cache), celui-là ou un autre pourra ultérieurement servir d'intermédiaire de mise en relation.

Ben, ils ont plutôt raison... Qui comprend encore comment fonctionne la gestion matérielle sous Linux ? Entre le noyau, hal, udev, dbus, gnome-volume-manager, et maintenant evdev et xorg... Bonjour la merde quand t'as un truc à débugger ou configurer à la main.

Pour remédier au problème de typage, des solutions ont été pensées:
http://www.sitepen.com/blog/2009/06/23/unobtrusive-javascrip(...)

Mignon mais ça ne remédie pas à la conversion implicite des types de base etc.
Ça convertit Javascript en une sorte de langage à typage statique faible, avec des vérifications aux interfaces définies par l'utilisateur mais pas à l'intérieur des implémentations.

En général, tu ouvres le trou avec un petit paquet, pas besoin d'envoyer un MP3 pour ça :-)

Non, IA.

Un peu jeune pour être en production mais c'est tellement plus naturel que du SQL

Et pour les jointures, les requêtes imbriquées etc., ça reste "naturel" ? :)

Le typage ultra mou et la gestion d'erreurs foireuse de Javascript ne le rendent pas très agréable à mon goût (en fait, ce sont les points qui le rapprochent le plus de PHP).
Le modèle objet un peu foutraque ne donne pas non plus du code très lisible.

Ça doit être énorme ce genre de logs. Il faut conserver toutes les associations (IP, port) ouvertes pendant la durée légale (un an ?), avec évidemment les dates et heures associées.

Si ton FAI ne te permet de pouvoir dire "tout ce qui arrive sur le port tcp/xxx est destiné au client yyyy, alors pas mal d'applis, mais pas seulement de P2P, aurons des problèmes.

Oui, mais le FAI ne veut pas perdre de clients, donc il va chercher à éviter ce genre de cas de figure.