Buf a écrit 449 commentaires

(ok il faut cliquer sur les chiffres pour le mot de passe donc normalement un keylogger ne peut pas l'intercepter)

Non. Ce genre de méthodes n'apportent qu'une illusion de sécurité, en se basant sur le fonctionnement le plus courant des keyloggers. Mais d'un point de vue théorique, ça n'apporte strictement aucune sécurité supplémentaire : on peut facilement imaginer un "mouselogger" qui enverrait un screenshot de la zone sous le pointeur à chaque clic (ça existe surement déjà)

1) Oui, sauf que là, on parle d'un Windows qui a lancé tout l'environnement graphique ainsi que les services de base. Il y a donc un bon paquet de libs déjà chargées.

2) cf point 1. On parle d'une station de travail avec environnement graphique chargé

3) Sauf quelques cas très particuliers, on gagne beaucoup plus en utilisant la mémoire qu'en la laissant libre. Pour les benchmark, si on vide les caches avant, c'est avant tout pour avoir des résultats reproductibles, je suis pas sûr que le résultat du bench soit moins bon si les caches ne sont pas vidés avant de le lancer.

Je vois pas le problème.

De la mémoire inutilisée, ça sert à rien, alors autant l'utiliser pour cacher/précharger un maximum de choses. Ça veut pas dire que les 370 MB en question sont définitivement réservés à l'OS, j'imagine que quand une application aura besoin de mémoire et qu'il n'y en a plus assez de libre, le kernel va commencer à distribuer une partie de la place utilisée par ses caches.

C'est assez compliqué de juger si un système gaspille ou pas de la mémoire, et se baser sur ce qui est utilisé après le boot n'est certainement pas représentatif. Un OS qui laisse 90% de la mémoire inutilisée après le boot, je suis pas sûr qu'il utilise les resources de la meilleure façon possible...

J2EE n'a pas été conçu pour permettre de faire facilement des trucs simples, mais pour rendre possible la réalisation d'application très complexes.

C'est 500 000 en tout, ou 500 000 versions Linux ? Parce qu'il y a aussi la version Mac qui peut avoir un certain succès (vu que Wine marche assez mal sur ce système)

J'AURAIS PENSÉ QUE C'ÉTAIT LE JOUR DE LA MORT, NORMALEMENT, IL N'Y A QUE LUI QUI PARLE EN MAJUSCULE !

FTP est aussi complètement basé sur TCP (cf RFC 959 [http://www.faqs.org/rfcs/rfc959.html])

Même s'il est pas forcément conçu pour, il le fait très bien quand même, tout aussi bien que FTP en fait (d'ailleurs, beaucoup de mirroirs de FTP publics sont aussi accessibles en HTTP, par exemple [http://mirror.switch.ch/ftp/mirror])

On a tout ce qu'il faut pour : transfert en binaire brut (pas d'encodage qui augmenterait le volume de données), et possibilité d'arrêt/reprise du téléchargement.

En plus de ça, c'est un protocole qui passe sans soucis tous les NAT/firewalls (au contraire du FTP, même anonyme)

C'est pour ça que je parle d'HTTP pour les trucs qu'on veut diffuser publiquement...

Le manque de sécurité n'est que le moindre des défauts du FTP... S'il n'y avait que ça, on pourrait effectivement se contenter d'utiliser SSL, mais c'est la conception même du protocole qui fait qu'il n'est plus adapté aux contraintes des réseaux actuels.

Bref, à part quand la compatibilité avec quelque chose d'existant est primordiale, FTP ne devrait plus être utilisé. Quand il s'agit de mettre des fichiers à disposition de tout le monde, HTTP fait parfaitement l'affaire, et quand l'envoie de fichiers est nécessaire, SFTP est nettement meilleur.

HTTP, tcp, udp n'ont pas les défaut de FTP.

Mon reproche est spécifiquement dirigé contre FTP. Le problème est qu'il a besoin de 2 connexions, et la deuxième pose des tas de problèmes. Dans le cas où elle est créée dans le sens serveur => client (FTP actif), ça ne passe pas le NAT (ou alors avec réécriture des paquets sur le routeur), dans le sens client => serveur (FTP passif), ça pose problème au niveau du serveur si on veut mettre un firewall un peu restrictif. Bref, FTP est un mauvais protocole, pas parce qu'il a été conçu au siècle passé, mais parce qu'il s'adapte mal aux contraintes des réseaux actuels, et c'est pour cette raison qu'il faudrait éviter de l'utiliser.

Quand il s'agit de mettre des fichiers à disposition de tout le monde (FTP anonyme), on peut parfaitement utiliser HTTP.

SFTP est très bien, mais à part le nom et la fonction, ce protocole n'a strictement rien à voir avec FTP, il est basé sur SSH et n'utilise qu'une seule connexion, ce qui fait qu'il n'a pas les défaut que je cite au dessus.

C'est aussi typiquement la configuration des serveurs DNS que les FAI fournissent à leurs clients.

Surtout, FTP est un protocole du siècle passé, avec des limitations qui s'accordent mal aux réseaux actuels (problèmes avec le NAT et les firewalls principalement), et une sécurité très faible (mot de passe transmis en clair). Ce protocole est à éliminer au plus vite...

La violation de la GPL pour laquelle Skype a été condamné n'a rien à voir avec QT. En effet, QT est aussi disponible avec une autre licence, payante, qui autorise à l'utiliser pour faire du proprio (à part Skype, il y a aussi Opera qui fait du QT proprio)

Non, le problème est lié à un téléphone Skype tournant sous Linux, et pour lequel les sources n'étaient pas fournies.

Voir cet autre journal pour plus d'info : http://linuxfr.org/~eastwind/24991.html

J'ai regardé un peu l'article associé. Ce qui me "choque", c'est qu'ils disent qu'il suffit de mettre la clé pour que le virus s'installe tout seul... Un peu comme les CDs qui s'auto-exécutent sous Win.
Pas très sécurisé tout ça...

Ils le disent, mais rien ne dit que ça soit vrai. Le "virus" n'est pas téléchargeable, pas moyen de vérifier quoi que ce soit.

À ma connaissance, sous Mac OS X, il n'y pas moyen de faire exécuter du code automatiquement à l'insertion d'un média amovible (clé USB, CD, disque dur externe, etc) Dans le pire des cas, on peut lancer automatiquement une application à l'insertion d'un disque d'un type particulier (lecteur DVD quand on met un DVD vidéo, par exemple), mais c'est toujours une application déjà installée, jamais du code contenu sur le support amovible.

À moins qu'il y ait une faille de sécurité exploitée quelque part, je pense que ce "virus" n'en est pas un, et qu'il s'agissait juste de faire une vidéo marrante.

Il y a quelques jeux d'aventure de Revolution Software qui sont passés officiellement en freeware : Beneath a Steel Sky, Flight of the Amazon Queen et Lure of the Temptress (il y en a peut-être d'autres)

Ils tournent tous avec ScummVM, donc pas besoin de passer par Wine ou Dosbox.

Je ne vois pas ou est la logique la dedans. Pourquoi ne pas se représenter avec Blocher de nouveau ? Enfin je ne connais pas trop le système suisse moi .

La position de l'UDC, c'est "Blocher ou rien". Blocher battu, ça serait logique qu'on retienne le "rien". Mais bon, il a déjà annoncé qu'il serait de nouveau candidat dans le cas où madame Widmer-Schlumpf renoncerait. Je ne l'imagine pas être élu (ceux qui étaient contre lui vont le rester, et j'imagine qu'une partie de ceux qui l'ont soutenu ne doivent pas forcément apprécier de voir une décision du parlement remise en question comme ça)

Surtout quand on considère (si l'on en croit les médias suisse), que son parti a réalisé le meilleur score aux dernières élections. ...
Ca va pas poser problème pour gouverner ca ensuite ?

Normalement, non. Même si l'UDC est le premier parti de Suisse, ils sont très loin d'avoir la majorité absolue au parlement (62 sièges sur 200 au Conseil National, 7 sur 46 au Conseil des États) Ils n'ont donc pas les moyens de bloquer quoi que ce soit à eux-seuls.

2 cas possibles :
- Madame Widmer-Schlumpf accepte son élection, contre l'avis de la direction de son parti. Dans ce cas, même si la composition du gouvernement ne change pas, il sera quand même moins marqué à droite, et surtout, sans la personnalité de Christoph Blocher (c'est certainement ce qui a le plus joué dans sa non-réélection, plus que sa ligne politique)
- elle refuse. Dans ce cas, il y aura une nouvelle élection. Selon toute logique, l'UDC ne présentera pas de candidats. Le siège reviendra normalement à un candidat PDC (centre) ou éventuellement Vert.

Dans tous les cas, c'est une grosse gifle pour l'aile dure de l'UDC, et une défaite personnelle pour Christoph Blocher, qui s'était beaucoup mis en avant lors de l'élection du parlement cet automne.

L'UDC est loin d'être monolithique. Christoph Blocher fait parti de l'aile "dure", très à droite, alors que la nouvelle élue est beaucoup plus modérée (dans la même ligne que Samuel Schmid, UDC lui aussi, qui a été réélu sans problème)

Source ? pas que je te crois pas, mais ça m'intéresse.

On peut se faire rembourser un bien qui ne marche pas. Ce DVD ne marche pas, donc on peut se le faire rembourser.

Le problème, c'est qu'en l'occurence, le DVD marche bien. Il est protégé par CSS, qui fait parti du standard "DVD-Video". N'importe quel lecteur certifié à cette norme pourra le lire.

On n'est pas dans le cas des CD audio protégés, là, il y a bien tromperie sur la marchandise (vu que le disque ne passe dans un lecteur compatible à 100% CD-Audio)

Bref, même si je pense que CSS est une bouse inutile, couteuse, stupide et complètement inefficace, on ne peut pas dire d'un DVD protégé avec ce truc qu'il "ne marche pas".

Oui, et c'est exactement ce que fait déjà Apple avec Safari (qui reste propriétaire, même s'il se base sur un moteur libre)

Par l'intermédiaire des passerelles Jabber uniquement...

Ce n'est pas ce que j'appelle "gérer" le multi-protocole (ça reste du 100% Jabber au niveau du client, tout le boulot pour les autres protocoles étant fait côté serveur)

Stocker tout ses mots de passe en clair chez une entreprise, qui plus est aussi peut recommandable qu'un fournisseur d'abonnement de téléphone portable en plus, je vois pas ce qu'on peut trouver de réjouissant la-dedans.

Qui te dit que les mots de passe sont stockés en clair ? Par contre, un truc dont je suis sûr, c'est que la plupart des sites sur lesquels je vais ne proposent pas de SSL, donc les mots de passe sont transmis en clair. Avec OpenID, on peut forcer le SSL pour l'envoie du mot de passe, pour tous les sites. Rien que pour ça, c'est intéressant.

Et si vraiment tu veux une sécurité maximale, il y a toujours la possibilité de mettre en place son propre serveur, et là, tu peux être 100% sûr que ton mot de passe n'est jamais stocké en clair (ou alors, on peut aussi d'autres méthodes d'authentification, un certificat X509 par exemple)

Si vous êtes sur beaucoup de postes, etbien retenez vos mots de passe. Les 10 secondes qu'on passe à saisir un mot de passe valent largement le coup par rapport à la sécurité qu'il apporte.

Et si on les oublie, on peut toujours demander un nouveau mot de passe, qui sera envoyé en clair par email.... Géniale la sécurité.

Rien ne t'oblige à divulguer l'adresse email de ton profil OpenID aux sites auxquels tu accèdes (on n'est même pas obligé d'en mettre une)

Tu pourras donc toujours utiliser des adresses jetables pour les sites qui n'inspirent pas confiance, ou utiliser des adresses uniques qui contiennent le nom du site (ça doit même être possible d'automatiser ça si on est son propre fournisseur)