Matafan a écrit 103 commentaires

Un cache qui oblige à réclamer la page 15 fois, je sais pas vous, mais moi je trouve ça un peu contre-nature... En plus d'être terriblement enervant. [-1]

Pour info il y a aussi JOnAS (http://www.evidian.com/jonas/(...)), un serveur d'EJB libre (JOnAS et JBoss en étant les seuls exemples). Même s'il est moins connu, il est généralement considéré comme supérieur à JBoss, voir même du niveau des ténors commerciaux du genre (Weblogic, Websphere).

Faut pas généraliser, non plus. Dans l'école d'ingé d'où je suis issu, les linuxiens étaient plutôt nombreux, et une bonne partie des autres étaient tout à fait conscients des faiblesses des produits microsofts...

Côté enseignement, on a fait pas mal de TD ou BE (des TD en plus longs) sous unix. Et même un BE firewall sous linux. Sans compter les cours de systèmes Unix. Et je pense que c'est également le cas dans bon nombre d'autres écoles.

Toutafé, je m'en suis rendu compté juste après avoir posté (d'ailleurs je t'ai mis [+], pour la peine, et je me flagellerais dès mon retour chez moi ;)

Il n'empêche que la clé de 56 bits a été trouvée en 250 jours, ce qui n'est tout de même pas une preuve flagrante de la faiblesse de l'algo. D'ailleurs ça montre aussi que si le RC5-56 avait au départ une raison d'être (prouver que des clés de 56 bits sont insuffisantes), le RC5-64 en revanche n'a pas vraiment d'intéret.

Ce que je veux dire c'est que pour moi, ni la fin (prouver quoi ?) ni les moyens (force brute...) ne justifient de sacrifier sa puissance CPU à ce projet, par rapport aux projets "concurents" (Seti ou ORG-25 par exemple).

Extrait de http://stats.distributed.net/rc5-64/(...) :
Time Working: 1,488 days
Keyspace Checked: 61.902%

Montrer aux Us que le cryptage sur 56 bits est insuffisant ? Compte tenu des moyens mis en oeuvre, je trouve que couvrir en 4 ans seulement 62% de l'espace de recherche tend plutôt à prouver le contraire... Non non, le seul vrai projet utile, toujours sur distributed.net, c'est OGR-25 ;)

N'empêche qu'il y a quelque jours, je suis allé acheter des disquettes (si si, ça sert encore des fois). Et bien quelle que soit la marque, sur les boîtes on pouvait lire "Mac" ou "IBM"... Il y a des habitudes qui ont la dent dure.

Je ne vois pas le problème. Le système de linuxfr permet d'associer une clée publique à un utilisateur authentifiée. Elle te permet de savoir qu'un mail qui te serait envoyé par un utilisateur a bien été émis par cet utilisateur. Si tu reçois un mail signé par ma clé, et tant que je ne me suis pas fait voler mon login linuxfr (ou bien voler ma session), alors tu est sûr que ce mail est bien issu de celui qui poste ici sous le pseudo "Matafan". Inversement, si tu m'envoie un mail chiffré avec la clé que tu peux trouver ici, tu est sûr (avec les mêmes réserves) à 100% que seul celui qui poste ici sous le pseudo "Matafan" pourra le lire.

Un sytème comme linuxfr te permet, de façon assez sûre, d'associer une clé à l'utilisateur d'un site. Evidemment, rien ne te garantit que la clé appartient bien à une personne physique particulière (moi) ; mais tu elle tout de même associée de façon certaine à "l'entité" que tu côtoie sur le site.

Un seul problème peut donc apparaître : un utilisateur X de linuxfr peut voler le pseudo d'une autre personne Y que tu connais par ailleurs sous ce même pseudo, tout en indiquant dans son profil sa vrai clé publique. Alors si tu envoie un mail à Y (ton copain) en le chiffrant avec la clé publique récupérée sur linuxfr, la personne X (l'usurpateur) pourra le déchiffrer. Mais dans ce cas, le problème vient de ce que tu mélange les rôles. Linuxfr te garentit que la clé appartient à la personne que tu cotoie sur linuxfr (donc X), pas à celle que tu connais pas ailleurs (Y).

Mais le problème ce n'est pas que ladite photo est sans rapport avec le texte (ça arrive souvent dans les journaux), c'est que comme l'a fait remarque quelqu'un plus haut cette photo semble bien avoir été ajouté sur l'image scanée : elle ne suit pas les ondulations du papier, notamment en bas à droite. Il y avait certainement autre chose à cet endroit, sur le journal.

Autrement je trouve le texte vide et assez puéril. Il est là aussi difficile de croire que c'est l'oeuvre d'un journaliste...

Deux idées pour limiter les possibilités de DoS depuis un LAN :

- Ne pas router vers l'extérieur les paquets dont l'adresse source n'appartient pas au domaine (j'imagine que c'est fait en général)
- Configurer autant que faire se peut des tables ARP statiques, pour éviter l'utilisation d'outils du style arpspoof. En plus c'est à peu près la seule manière d'empêcher les sniffers sur un lan.

-1 parce que finalement je sais pas ce que ça vaut :-P

Si les IPs sont souvent spoofées dans une attaque de type DoS, ce n'est pas seulement pour ne pas se faire repérer, ni pour éviter de se faire black-lister. C'est aussi parce que les attaques DoS sont en général basée sur le principe du SYN-flooding : c'est bien parce que l'IP est spoofée que personne ne reçoit jamais le SYN-ACK, et que la connexion reste pendante sur la machine attaquée. Si au contraire une machine physique recevait ce SYN-ACK, elle retrounerait un RST qui fermerait la connexion chez le serveur cible... Ce qui est précisément le contraire de l'effet recherché.

Ca c'est pour le principe de base. Maintenant certaines attaques DoS un peu plus évoluées (cf. les attaques de type "Naptha", très bien décrites d'ailleurs sur le site du CERT) nécessitent justement que l'on (ou mieux un collègue) reçoive le fameux SYN-ACK, pour répondre à notre convenance et laisser la connexion serveur dans un état arbitraire (LISTEN ou LAST-ACK en général). Dans ce cas, le spoofing d'IP sert justement à ce que la SYN-ACK du serveur soit routée jusqu'à la machine du copain. Ici l'attaquant doit donc spoofer une IP du domaine de son "complice".

Si mes souvenirs sont bons, on appelle kernel (ou noyau, ça se dit aussi) d'une application linéaire f de A vers B l'ensemble des points de A dont l'image par f est le zero de B.

Mais à priori, le kernel linux n'a aucun rapport avec cette définition là. C'est juste que "kernel" est la traduction allemande (finlandaise ?) de "noyau".

(-1 parce qu'enfonçage de portes ouvertes :)

Le problème avec les jeux, c'est qu'on à le choix entre :

- Un jeu sous linux dont on ne peut jamais être sûr qu'on saura/pourra le faire marcher. Et même si on y arrive à un instant T, on ne peut jamais être sûr qu'après des upgrades d'X ou de drivers video ça marchera encore.
- Le même jeu sous windows, dont on est (à peu près) sûr qu'il marchera sans problème, et en tout cas souvent un chouilla mieux que sous linux (je ne parle pas des performances graphiques, qui se valent en OpenGL, mais de la qualité de rendu, de la gestion de la souris...)

Si on ajoute que dans beaucoup de cas (cf. Quake 3), on peut acheter la version windows et la convertir en version linux à coups de point releases, le choix est malheureusement vite fait...

Moi j'aurais plutôt vu les choses comme ça :

L'eau de la douche est chaude, et réchauffe l'air à l'intérieur de la cabine. Cet air chaud "monte" et s'échappe par dessus le rideau de douche, créant une dépression qui l'attire vers l'intérieur. Vient le moment fatidique où le rideau, jusqu'alors collé au rebord du bac de douche, cède et vient envahir le précieux espace. Et là c'est perdu, n'espérez même pas recoller le rideau au bac : un puissant courant d'air assendant s'instaure, et l'air froid qui s'engouffre par dessous le rideau anéanti tous vos efforts.

D'ailleurs on peut remarquer que si on prend sa douche dans une salle de bain surchauffée, le phénomène met plus de temps à s'instaurer.

Voilà ma contribution à la science ;)

L'indentation est mal faite sous Vim ? Essaie donc d'ajouter les lignes suivantes dans ton .vimrc :

set tabstop=4 " Tabulation width
set shiftwidth=4 " Indentation width
set smartindent " Auto indentation for C-like languages
set expandtab " Use spaces rather than tabs
set smarttab " Treat heading tabs differently from inline tabs

Et hop, on retrouve à peu près l'excellent système d'indentation par défaut d'Emacs :)

Tu dois vouloir parler de Zend, le "moteur" du langage.

Bof... Cite moi ne serait-ce qu'une distribution qui ne propose aucun logiciel non libre (sans même parler de non GPL). A ma connaissance il n'y en a pas.

Maintenant il est vrai que s'agissant en plus d'un produit Microsoft, on peut supposer que Debian et Slackware au moins ne l'intègreraient pas. Mais les autres...

Au fait, qui peut me dire si le raid 0 des cartes mères du type Abit KT7A-raid (raid 0 sur deux disques IDE) est utilisable sous linux ?

J'imagine que le système ne voit qu'un disque de capacité double et qu'il n'y a donc aucun problème, mais j'aimerais quand même avoir le témoignage d'un utilisateur.

Ah autant pour moi, je n'avais simplement pas attendu assez longtemps :) OffTime marche parfaitement, seuls StandbyTime et SuspendTime ne fonctionnent pas. C'est d'ailleurs indiqué dans le README.

J'en profite pour rappeler la méthode : dans la section "Monitor", ajouter « Option "DPMS" » ; dans la section "ServerFlags", ajouter « Option "OffTime" "10" » par exemple, pour éteindre l'écran après 10 minutes d'inactivité.

Je les ai installé depuis les tar, et ça marche sans aucun problèmes après les deux make et un reboot (il y a moyen d'éviter le reboot, mais bon...).

Par contre si quelqu'un sait comment activer le DPMS, çà m'intéresse. Ca marchait avec les 9.6, et plus avec les 9.7. Et ça n'a pas l'air de marcher avec cette version.

Ouais. D'ailleurs je joue souvent avec [BDL]Nietsche :P

Voila typiquement le genre de remarques qu'on peut attendre de quelqu'un qui n'a jamais touché à quake (ou si peu).

- Même style de jeu : ah bon ? Doom est un jeu solo. On déambule dans des cartes immenses, où les monstres (beaucoup de monstres différents) sont statiques. Quake est un jeu multi-joueurs, où on évolue dans des arènes souvent petites, en se battant contre des adversaires humain qui bien évidemment on la même liberté de déplacement que toi.
- Même style graphique : quake est graphiquement beaucoup plus varié que doom. dm6, dm13, dm17, tourney4... Ces maps sont si différentes graphiquement que je vois mal comment on peut trouver des similitudes entre elles et doom.
- Mêmes armes : bon doom est peu loin, je sais plus trop. Mais je crois me souvenir qu'il y avait un tronçonneuse par exemple, absente de quake. Et je ne crois pas que le lightning gun ait eu un équivalent sous doom... D'autant plus que dans doom, et c'est le style de jeu "solo" qui veux ça, les armes ont des valeurs très différentes : au fur et à mesure qu'on avance, on rencontre des monstres de plus en plus redoutables, et on acquière des armes de plus en plus puissantes. Au contraire dans quake, toutes ont, en gros, la même valeur. Et il faut savoir en changer rapidement suivant la situation (position de l'adversaire, son niveau de vie...).

Et pour finir sur ta dernière remarque, il suffit d'un jouer un peu "sérieusement" (comprenez en cherchant vraiment à s'améliorer) pour s'appercevoir que quake est bien moins bourrin qu'on ne l'imagine. Stratégie d'équipe, contôle des armes et des items... On est loin du "moi vois, moi tue".

Le burn-proof est supporté par linux ? Ca se manifeste comment exactement ?

Probablement pour éviter que des petits malins ne modifient le code pour gonfler leurs résultats... Ou en tout cas pour leur compliquer la tâche.

Je crois qu'il n'est pas très pertinent de se baser sur les ventes du CD Linux pour tirer des conclusions sur la popularité de Quake sous Linux.

Le fait est que beaucoup de linuxiens ont acheté la version windows du jeu, par impatience ou par prudence. Mais beaucoup jouent tout de même sous Linux, puisqu'il suffit d'installer la point release Linux pour jouer à partir du CD Windows. D'ailleurs, sachant cela, je crois que n'importe quel quaker en dual-boot achèterait la version windows, pour se réserver la possibilité de jouer sous les deux environnements.

Je suis sûr que si ID demandait aux acheteurs du CD Windows l'environnement sous lequel ils jouent, le nombre de quakers sous Linux dépasserait largement le nombre de quakers sous MacOS. Sans parler, mais c'est un autre sujet, de la proportion de serveurs linux dédiés...

La raison qui les a poussé à ne pas diffuser les sources est indiquée sur le site : il s'agit d'éviter que des petits malins ne compilent un code modifié pour traiter plus vite les blocs.