Alan_T a écrit 242 commentaires

Je pense que le fait que Linux est portable sur Xbox est plus un avantage pour les Logiciels Libres que pour Microsoft.

La communauté Linux démontre une fois de plus la grande portabilité de cet OS et le dynamisme des gens qui la compose. C'est un énorme coup de pub (une fois de plus). Le fait que Windows ne tourne que pour des x86 le limite déjà, le fait qu'il n'innove que rarement (meme s'il tente de masquer cela derriere des tonnes de marketing) l'enfonce carrement.

Meme si personne n'utilise cette version pour X-Box (qui a utilisé la version de Linux pour Playstation ?), cette démonstration est 'utile' pour enfoncer le clou sur la portabilité et le dynamisme de Linux (et des logiciels libres en général).

> AMHA il ferait mieux de faire parler de lui en sortant un OS fonctionnel.

Hum, quelqu'un l'a deja fait avant lui. Il va falloir qu'il trouve autre chose. :-)

D'après ce que je sais de Linus, il doit être entre 70 et 130 (il travaille pour transmeta qui fait du logiciel propriétaire, est plutôt favorable à l'Open Source, utilise des logiciels propriétaires comme Bitkeeper, est plutôt pragmatique qu'idéaliste, ....). Bref, un vrai opportuniste. :-) <je-deconne> Arretons d'utiliser Linux, tous sous Hurd, allez zou ! </je-deconne> Non, mais c'est quoi ce test à la con ? Je parie que même Stallman tombe dans la catégorie des 40 à 70 (alors que la vanité et l'ambition ce n'est pas ce qui lui manque!!!). Si ça continue comme ça, après les tests foireux, on aura droit à l'horoscope... Alors, je suis Gnu ascendant pingouin, donc cela veut dire que je vais avoir à utiliser des logiciels propriétaires dans un avenir proche.... hum ! Si on arretais les conneries, je ne trouve même pas ce test drôle (cela sent trop le 'sérieux'.

Ça veut dire qu'ils l'ont rajouté après ????

C'est bizarre ! Quelles modifications ont-ils eut à faire sur le système de fichiers (à moins que cela ne soit seulement sur la commande 'mv' ?).

En tout cas, chapeau Apple ! :-)

En fait, qu'il y ai eut une backdoor ou pas, n'est pas la vraie question. A partir du moment où l'on a un doute, cela détruit toute l'impression de sécurité que l'on avait avant.

Comment peut-on faire une confiance aveugle à un logiciel fermé pour gérer notre sécurité ? Notre intimité ?

À une époque où les états et les organismes internationaux bafouent les libertés individuelles en se disant "lutter contre le terrorisme", il est important de se prémunir contre tous.

Sans vouloir pousser au "tout logiciel ouvert", je pense qu'il existe toute une gamme de logiciels "critiques" qui se doivent d'être ouverts. L'exemple des logiciels de cryptographie n'est une occurence de ce problème. On devrait avoir le même réflexe pour les format de documents (écrits, sonores ou audio-visuels), ou encore pour les protocoles réseaux (inter-opérabilité).

C'est surement ça, il a fait un DENY ALL avec ses alumettes. ;-)

Dans les deux cas, il n'est pas à la banque

En fait si, il est à la banque. L'argent électronique est une nouvelle sorte de créance (et non une monnaie à part entière comme je le croyais au début). Du coup, l'information présente sur ton porte-monnaie électronique dit seulement: "La banque machin doit payer 1 euro contre cette information". Mais le 1 euro est toujours à la banque machin.

2) ils te fournissent un service, ils te le vendent. Que eux ca les avantage ne change rien à l'histoire, tu n'es pas obligé d'acheter leur service (enfin ca c'est la théorie). Que la chose soit rentable pour eux ou pas n'a rien à voir avec le prix.

Je comprends tout à fait que les banques produisent un service. Mais j'ai trois remarques:

- Si l'on compare la monnaie électronique à la monnaie réelle (ou plutôt une autre forme de créance, ce qui se conforme plus à la réalité), cela reviendrait à dire que l'état fait payer pour que l'on utilise sa monnaie (entre nous, c'est un peu vrai car les impôts financent la création et le maintient des pièces et billets). C'est une idée qui me parait assez choquante.

- Si on admet tout de même qu'il faut payer pour ce service. Faire payer à la fois au débit (par l'utilisateur) et au crédit (par le commerçant) me semble un peu exagéré. Surtout au vue des coûts réels qu'engendre le système (du moins je suppose).

- Enfin, si un coût fixe me semble 'raisonnable', le fait que le commerçant soit obligé de payer un pourcentage sur les sommes échangées, me semble étrange.

4) on parle d'énormément de choses dans la news principale, y compris de grosses conneries, s'il ne faut pas croire sur parole le boniment des banques il ne faut pas croire sur parole celui des opposants. Toujours est'il que au pire ca sera comme la CB, au mieux ce sera non tracable (mais je n'y crois pas, ca laisserait trop la porte ouverte à des acces frauduleux et écraserait tout le systeme au premier faussaire connu, si on veut de la sécurité il faut que la banque trace)

Oui, je pensais aussi que la news originale n'était pas tout à fait exacte.

Pour ce qui est des faussaires, et d'imposer la tracabilité de l'argent électronique, je ne pense pas que cela soit une solution. Je pense que le simple fait de limiter les débits de ce porte-feuille électronique à 30 euros limite suffisamment les possibilités de fraudes pour pouvoir éviter d'avoir recours à la suppresion de l'anonymicité (qui est quand même le principe de base du porte-feuille électronique, sinon, ce ne serait qu'une carte bleue++, ou comme au Danemark à l'heure actuelle une DK-kort).

5) la réponse est 42

Bon sang, mais c'est bien sûr !!!! :-)

Je me réponds à moi-même:

http://www.droit-ntic.com/pdf/paiementenligne.pdf(...)
http://www.rd.francetelecom.fr/fr/conseil/mento13/chap7.pdf(...)

Dites, est-ce que quelqu'un sait où l'on peut trouver l'explication des algorithmes utilisés dans Moneo ?

Je connais grossièrement le principe de l'argent électronique, mais je me pose plusieurs questions sur des détails comme:

1) Comment assure-t-on la non-répudiation lors du chargement du porte-monnaie électronique ? (Comment éviter de faire de la fausse monnaie).

2) Pourquoi les commerçants doivent-ils payer un pourcentage sur la somme versée, puisque le principe de l'argent électronique est justement de se débarasser d'un tier de confiance comme c'est le cas pour la carte bleue.

3) Comment sécurise-t-on le payement (i.e. comment s'assurer que l'argent débité de la carte est bien débité)

4) Est-ce que l'anonymicité est bien préservée (c'était l'idée de base de l'argent électronique. Mais on parle dans la news initiale d'un traçage des habitudes des clients et je ne comprends pas comment cela serait possible).

5) D'autres questions surement, mais là je ne m'en souvient pas... :-)

pourquoi ne pas utiliser uniquement la carte bancaire pour ce type d'achat ?

Je crois que c'est surtout une question d'anonymicité.

En fait, ta carte bancaire est une clef pour t'authentifier comme le propriétaire de ton compte en banque et permettre de faire des transactions dessus.

Le problème, c'est que toutes les transactions doivent passer par un accord central de la banque (en théorie du moins, car en pratique c'est autre chose. L'affaire des Yescard l'a montré) et que donc tu es tracé pour tous tes achats.

Le porte-monnaie éléctronique n'est pas une clef, c'est une réserve d'argent électronique. On y met de l'argent dessus (de façon non répudiable si possible) et on débite _de_la_carte_ (et non de la banque) l'argent en question. Cet argent électronique est totalement anonyme (toujours en théorie), exactement comme le sont les pièces de monnaie ou les billets. En quelque sorte, cet argent électronique est une nouvelle sorte de monnaie qui est controlée, non plus par l'état, comme le sont les pièces et les billets, mais par les banques. On peut imaginer que tout ce qui se passe pour les pièces et les billets va se reporter aussi sur cet argent électronique (fausse monnaie, mécanisme d'inflation/déflation, ...).

Je crois que le problème que nous avons là, c'est surtout que les banques vont avoir un total contrôle d'une monnaie à elles. Avec la monnaie électronique l'état ne sera plus le seul à avoir le droit de gérer ses devises. C'est une réelle révolution d'un point de vue financier (et peut-être, de façon indirecte, économique).

Je pense que les banques essayent plus ou moins de noyer le poissons en jouant sur le fait que payer par carte est déjà largement répandu. Du coup faire en sorte que tout le monde fasse la confusion entre débiter son compte et utiliser de la monnaie électronique les arranges bien. :)

Pour ce qui est du futur, il faut se demander si l'on veut réelement faire confiance aux banque pour prendre en charge la gestion de cette monnaie parallèle...

Effectivement, je crois que le gros problème des jeux comme Quake, c'est qu'ils laissent au client la gestion d'évenements qui devraient être géré par des machines de 'confiance' (le serveur par exemple).

En fait, si j'essaye de faire une synthèse, les hypothèses de base sont:

1) Le client ne peut être digne de confiance.
2) Le serveur est considéré comme un tier de confiance par tous les clients.

Et pour l'instant, la triche se fait par:

1) Une main mise complète sur les choix qui sont laissés au client.

La solution pour contrer cela étant de diviser en deux catégories claire, les évènements qui peuvent être décidés par le client et ceux qui doivent être décidé par le serveur.


2) L'utilisation d'information envoyée au client mais pas visualisées par celui-ci.

La solution pour contrer cela étant de n'envoyer au client que les informations minimum car on ne peut pas faire confiance au client.


Évidemment, nous avons exclu ici toute idée de performance. Ce qui simplifie considérablement les données du problème. D'un autre coté, si la triche détruit le jeu, il serait bon de diminuer ces performances et de respecter un peu plus les règles citées ci-dessus.

En lisant un peu tous les messages qui ont constitué cette discussion, je vois qu'en fait la "triche" de certains participants repose en grande partie sur l'exploitation de données supplémentaires qui ne sont pas visualisée ou qui sont "dormantes".

Arretez-moi si je me trompe, mais, je crois avoir compris que dans des jeux comme Quake, le nombre d'informations qui sont envoyées à chaque client est beaucoup plus importante que ce que le joueur peut voir/entendre dans son environement proche.

Peut-être est-ce là une erreur de la part des concepteurs des jeux. Après tout, les "tricheurs" ne font que tirer partie de toutes les informations dont dispose leur client. Vouloir cacher des informations après les avoir envoyées au client me semble un peu utopique.

Pourquoi ne pas faire des protocoles qui n'enverraient au client que les informations nécessaires et rien de plus ?

Évidemment, il y a des moyens d'obtenir des informations supplémentaires, par exemple en connectant des joueurs fantômes et en les plaçant judicieusement sur la map. Mais cela se verrait assez facilement.

Reste le problème de la gestion de la position du personnage. J'avais entendu parler d'un programme qui changait la coordonnée Z (altitude) de tous les shoots. Ce qui faisait que le joueur apparaissait "invulnérable". Il faudrait trouver un méchanisme (rapide si possible) pour empecher le joueur de modifier des données qui viennent du serveur. La signature par clef privé du message est un solution qui requière vraiment beaucoup de CPU et un simple CRC est trop facile à craquer... Quant à gérer tous les mouvements du joueur sur le serveur même (et non plus sur le client), on perd l'aspect distribué du logiciel (et le serveur doit avoir une puissance de calcul importante).

Bref, c'est une question intéressante.

Quelqu'un connait-il les différentes méthodes qu'emploient les jeux en réseau actuellement pour résoudre ce genre de problème ?

Bah, si on arrive à automatiser un test de Turing alors, on peut automatiser les réponses du bot !

Réfléchis un peu voyons !!!!! :o)

Allez hop --> -1 (Ah bah non, pas -1, zut alors!)

Ça existe ?

Des noms, des URL !!!!! Viiite. :-)

Et pourquoi ne pas faire un jeu qui permette la "triche" comme tu dis. Après tout, le triche dont tu parles demande l'analyse du code, la conception de programmes, dont certains peuvent s'avérer complexes, etc...

Pourquoi ne pas définir un jeu dans lequel, par exemple, on pourrait disposer d'un language (le langage C ?) qui permettrai de décrire ses armes, ses véhicules, etc... Une sorte de 'Matrix' où tous les bons programmeurs pourraient débarquer avec leur code et s'affronter ou coopérer pour atteindre des buts....

En faisant cela, non seulement on résoud le problème de la 'triche' (en l'intégrant au jeu), mais en plus on ouvre les portes de la créativité.

La programmation d'un tel jeu serait plus liée à la programmation de l'environnement dans lequel joue les participants (c'est à dire le code qui tourne sur le serveur), après, c'est aux participants de tirer avantage de toutes les informations que l'on leur envoi pour visualiser ce monde. :-)

Je me demandais justement comment faire tourner un environnement graphique sur de vieilles machines. En effet, XFree 4.x est devenu très gourmand à la fois en mémoire RAM et en puissance CPU. Hélas, la version 3.3 n'est plus maintenue.

Existe-t-il des projets qui ont pour but de construire une interface X qui soit 'légère' ? (je pense à des initiatives comme XGGI (http://www.stacken.kth.se/~mackan/ggi/xggi/(...)) ou Berlin (http://www.berlin-consortium.org/(...)) par exemple).

Il y a aussi le commande etags qui permet de faire cela de façon plus spécifique.

Ok, donc si je comprend bien, on pourrait avoir une version de DaCode pour Templeet, non ?

C'est un peu ce que fait le nouvelle version de Linuxfr…

Mais, si j'ai bien compris, si je veux avoir un CMS, soit je prend DaCode, ce qui m'épargne pas mal de travail car toutes les primitives sont déjà là, soit je prend Templeet et je dois (presque) tout implémenter par moi-même en utilisant le langage.

http://www.templeet.org/ (NdM: modifié en 2021 pour pointer vers archive.org)
http://www.templeet.org/doc/ (NdM: modifié en 2021 pour pointer vers archive.org)

Je crois que je comprends mieux maintenant.

Merci.

J'ai été voir les pages de DaCode et Templeet, les deux me semblent bien, mais je n'arrive pas très bien à voir quelles sont leur différences (quand doit-on utiliser l'un plus que l'autre).

Un autre question: Templeet ne nécéssite pas de base de données pour tourner, comment fait-il pour stocker les dépèches, alors ?

Quelqu'un a testé ipfw2 ?

Qu'y a-t-il de nouveau ?

Y-a-t-il une homepage (je ne l'ai pas trouvée).

Je viens de lire le document un peu en diagonal, mais les sujets sur lesquels je me suis arreté et la table des matières m'a convaincu que c'est une excellente introduction à la programmation (sécurisée ou pas).

L'auteur introduit les précautions de base que tout programmeur devrait avoir à l'esprit quand il code des logiciels qui vont être utilisé par d'autres.

Au passage, je suis toujours épaté de voir des gens qui écrivent de vrai livres et qui les mettent Open-Source, surtout avec cette qualité là. Même, si l'auteur ne lira pas ce forum, je voudrais le féliciter. :-)

Que dire de plus, si ce n'est que je suis totalement d'accord avec ton point de vue. :-)

Oui, cette feature semble utile, et oui, cela ne devrait pas faire partie de la configuration par défaut.

De plus, je suis impatient de lire ton papier à propos de Netfilter.

Hop --> -1, parceque cela sent le <aol>me2</aol>

Pour en revenir a la feature, elle est dangereuse quand elle n'est pas comprise, et il est vrai que le doc reste ambigue sur ce point. Maintenant, rien ne vous empeche d'ajouter un --syn avec toutes vos regles TCP en etat NEW.

Oui, mais il est difficile de documenter une telle fonctionalité. Plutôt que de dire que c'est un bug, je préfère dire que c'est une erreur de design.

Pour avoir un algorithme en O(1), il faut donc être capable de trouver la règle correspondant à ton paquet en O(1)....

Non, et c'est là l'astuce ! ;-)

Le problème fondamental que l'on traite dans les firewalls c'est la classification de paquets basé sur leur header.

En gros, si tu considères chaque champs du header comme une variable entière qui a un domaine fixé (entre 0 et 255 par exemple), tu peux traduire chaque règle de ta configuration comme autant de formules logiques. Ensuite, tu peux 'compiler' ces formules logiques en une seule (en faisant attention de conserver l'ordre de précedence sur les règles).

Le fait de 'compiler' ces formules en une seule est un problème NP-complet. Cependant, tu peux très bien compiler tout ça en dehors du noyau. Une fois que tu as ta formule logique, tu la met dans le noyau et tu n'auras pas à évaluer chaque champs du header plus d'une fois (au plus), ce qui fait que c'est en temps constant puisque tu as un nombre de champs fixé (du moins sur ipv4).

Mais, on explique tout ça mieux dans: http://www.cs.auc.dk/~fleury/papers/CF-infocom2003-submitted.ps.gz(...)

En gros, on retire du noyau toutes les opérations qui ne sont pas nécessaires. Et cela donne une accéleration assez intéressantes (du moins sur les prototypes que l'on a fait jusqu'à présent).

De plus, sur des fichiers de configuration réalistes, on s'en tire à quelques secondes de compilation (il y a une table dans le papier à ce propos). Et on a quelques idées pour encore optimiser le compilateur.