Garbit

C'est raincoat, et il est installé d'origine avec la xebian (qui tourne impec).

Ca n'a rien d'illégal dès lors que le réseau n'est pas crypté. Il me semble que des cas ont fait jurisprudence en dans ce sens-là...

Merci pour l'analogie Je pensais que c'était des trous. Ben alors les soudures sont faciles !

Salut, Le coup de la soudure ça parait quasi indispensable... bien sur on peut se débrouiller sans, mais si tes ponts pètent (et pas "si t'es pompette", hein ) pendant le flash, adios amigos, pose de puce obligée. Le coup de l'étain, je n'y crois pas trop : les trous sont plus petits que tout fil d'étain que tu trouveras. Ce qui pourrait passer, à la limite, c'est une épingle, et encore je ne sais pas. Sinon, encre conductrice, ouais ça doit marcher. Je me souviens d'un mec qui faisait ses ponts avec un spray de peinture conductrice, le tout passant par un tuyau qui passait par les fentes de ventilation (il le faisait xbox fermée)... j'ai posté le lien sur le forum il y a un an ou deux (ça nous rajeunit pas). Bref, moi je te conseilles la soudure. Si tu ne veux pas le faire, demande à quelqu'un. Mais le coup de l'étain à froid...

Ouaip, mais cette limitation n'existe que dans les applis xbox qui utilisent le fatx. Tu peux te débrouiller avec un truc basé sur linux, genre phototoox.

Oui, enfin tu as compris ce que je voulais dire : tu réponds super vite, super efficace...et tant mieux. N'empêche, avec une cheapmod, tu n'engraisses personnes. Enfin, bon on ne va pas retomber dans le débat "exploit vs puce"... si ?

tout a fait d'accord, et je me disais la meme chose. Ca me rappelle ceci : Microsoft deleted my data - remotely, without my permission, and... without even bothering to ask!

Jp33, t'es vraiment incroyable ! ...je suis sûr que tu as des actions chez les developpeurs d'exploits ...

Ouais, c'est sur que 8 Mb/s ( et pas 8 Mo/s ) ça commence à faire boeuf. Ce n'est déjà plus de la pompe à échelle humaine, c'est sûr. Mais bon, je persiste à croire qu'on en voudra toujours plus. Ce qui me chagrine, c'est quand même que les opérateurs se croient crédibles quand ils disent que le 20 Mb/s qu'ils fournissent sert au téléchargement légal :-(. <mode="c'était mieux avant">Rendez-moi mon 56k, mon vieil internet tout propre, mon napster premier du nom...</mode>

Ca dépend. Avant, la traduction, par exemple sur les consoles 16-32 bits, ça n'était pas évident, étant donné qu'on avait des roms monolithiques (en un seul fichier) : il fallait repérer le texte original, qui était parfois compressé, et si la traduction dépassait, il fallait changer les pointeurs pour dire que ça a bougé. S'il y avait des checksums, il fallait aussi les recalculer et les modifier. Bref, ça n'était pas simple. Maintenant, les roms ne sont plus des roms à proprement parler (depuis longtemps... dès que les consoles ont commencé à utiliser un système de fichiers. Plus ou moins dès le début des consoles "à cd", je dirais), et la traduction a dû pas mal évoluer. Je n'y ai jamais touché, par contre, donc je ne saurais pas te dire. Je pense néanmoins que ça permet de faire plus de choses. Et puis, je ne sais pas si on se fait ch*** de nos jours à compresser les textes, par exemple. Enfin voilà, une réponse "temporaire", en attendant que quelqu'un puisse être plus précis. Moi ce que je te dirais, c'est : essaye de voir quelle tête ça a, essaye de changer quelques chaînes, et tu verras bien

Je disais pareil de mon adsl 512k quand j'ai quitté le 56k

VOilà, je réaffirme ma position. Merci fantomas de ne pas me laisser seul. Non, là il faut le dire, le truc ci-dessus n'est pas une avancée, c'est la connerie de qqn qui n'a pas reflechi (et ce n'est pas pour ça que j'en veux à qui que ce soit) ! exactement le genre de truc qui ne sert à rien et qui ne mènera à rien.

Euh, apparemment il faut passer "root=/dev/hda1" au kernel. Par contre avec cromwell je sais pas comment on fait.... (append="root=/dev/hda1" ? faut aller voir sur la doc de cromwell sur xbox linux).

Ben en même temps je vois comment est l'emplacement de la memory stick dans la psp et ca suffit largement pour ce genre de recherche c'est pas de la modification de psp c'est un complément Ouais fin bon faut arrêter de croire qu'on peut tout interfacer, et n'importe comment... tu transformeras pas un lecteur de disquettes et lecteur de disquettes usb en soudant le bus usb sur la tête de lecture... J'exagère un peu mais c'est ça qui se passe. Les adaptateurs c'est pas des boites noires magiques qui "convertissent" du memorystick en USB (d'ailleurs usb hôte, usb client, c'est pareil hein... on peut copier une clé usb sur une autre en soudant les fils de la même couleur...). Enfin voilà, le travail de Rayns and co au moins c'est sérieux, après le reste c'est du délire de crameur de psp.

Ben déjà, le vmlinux.bin correspond au kernel tout ce qu'il y a de plus brut : personne ne boote ça. Au contraire, on boote sur une image compressée, avec compress (un vieil utilitaire d'unix, alors l'image s'appelle zImage), ou avec bzip (et alors l'image s'appelle bzImage). Donc ce que tu fais, c'est que tu copies bzImage (normalement dans le même repertoire que vmlinux.bin je crois) dans /boot en le renommant à la volée en vmlinuz-2.6.12-1 (j'aime bien faire vmlinuz-version-build, où build représente le nombre de fois que tu compiles un noyau de ce type sur ta bécane, ça évite d'avoir des vmlinuz.old, vmlinuz.very_old, etc). Donc la commande magique c'est : cp repertoire/a/la/con/bzImage /boot/vmlinuz-2.6.12-1 Ensuite, le System.map (et non system.map... sous unix tout est sensible à la casse) normalement il y en avait déjà un donc ça doit aller, enfin je n'ai jamais bien compris quand il fallait le changer et quand il pouvait rester... et enfin le .config, plusieurs remarques. 1/ c'est ton fichier de config, celui qu'on est allés chercher sur le cvs. 2/ on le met souvent dans /boot pour ne pas avoir à se retaper la config lros d'un upgrade de noyau. Maintenant, les noyaux modernes permettent de récupérer le .config à la volée, il suffit d'ajouter une option au kernel. Je pense que celui-ci le permet, mais bon au pire sauvegardes le quelque part. 3/ si tu as l'impression de ne pas en avoir, c'est parce que c'est un fichier caché. Sous unix, les fichiers cachés sont les fichiers dont le nom commence par un point. Ils n'apparraissent pas quand on fait "ls", mais en revanche ils apparraissent quand on fait "ls -a" (comme "dir /ah" sous dos). Ensuite, fais le petit changement dans linuxboot.cfg. Assures-toi d'avoir un cd bootable linux, au cas ou ça merdoie (ce qui est plus que probable - et je ne remets pas en cause tes compétences). Pour récupérer ton système, montes ton disque dur depuis le cd, et réedites linuxboot.cfg, et rebootes... Ah oui, si tu n'as jamais édité de fichiers sous linux, ce sera l'occasion de découvrir "vi". Ah oui, au fait, je me répètes, mais pas de fatx pour les kernels 2.6. J'espère que ton linux n'est pas installé sur une partition xbox, sinon tu vas avoir un magnifique kernel panic au boot. Bonne chance !

Yop, Ce truc ne peut pas marcher... réflechis un peu au cable que tu vas mettre entre ton truc acheté et ton disque dur... tu essaye de relier deux appareils en usb et aucun des deux n'est hôte. De l'autre coté aussi ça va merder puisque tu relies deux hôtes ensemble (la psp et le lecteur coté MS). Bref c'est cramage assuré. cf http://gueux-forum.net/index.php?showtopic=68182

Oui, j'ai oublié de préciser, il n'y a pas de mot de passe donc entrée ça suffit Je n'ai toujours pas booté sur ce kernel, il a l'air de bien s'être compilé pourtant. Et pour l'aide, ben de rien je ne fais que rendre l'aide qu'on m'a donnée il y a un certain temps ici no soucy, c'est normal. Ca fait plaisir de voir que quelqu'un n'est pas rebuté par tout ça.

Non, sur l'usb les 4 fils servent.

Pose des puces xbox :-) ou des exploits bien sûr.

J'ai pris le meme kernel, j'ai fait le nettoyage (make mrproper), appliqué le patch, ok tout fonctionne. Je fais ma config tranquille pépère, sauf que je ne mets pas le support du son (parce que j'ai la flegme d'aller voir quels modules il faut ), et ça bloque sur l'apm (advanced power management), pareil, manque une fonction. Je vais chercher sur la ML de xbox-linux, y'a ptet qqch qui merdouille sur ce 2.6.12. Au pire on peut tenter sur un 2.6.8 ou un truc de cette époque-là. RTFM -> "read the f*cking manual". Par extension, ça veut aussi dire "se documenter" :-) EDIT: j'ai récupéré un fichier de config sur le cvs de xbox-linux compilation en cours... EDIT2 : ça a marché.Comment le récupérer : $ su# apt-get install cvs# cd /root# cvs -d:pserver:anonymous@cvs.sf.net:/cvsroot/xbox-linux/ login# cvs -d:pserver:anonymous@cvs.sf.net:/cvsroot/xbox-linux/ checkout kernel-2.6/kernel.config# cvs -d:pserver:anonymous@cvs.sf.net:/cvsroot/xbox-linux/ logout# mv kernel-2.6/kernel.config /usr/src/linux-2.6.12/cvs.config# rm -rf kernel-2.6 Et là, tu retournes dans ton /usr/src/linux, tu fais un make clean pour faire le ménage sur ce qui s'est précédemment passé, puis make menuconfig, tu fais "load from...", puis cvs-config, tu quittes le menuconfig, tu enregistres, puis make, make modules, make modules_install, et tu fais le reste (installation and co)

Il me semble qu'il y a l'option dans les émulateurs de la team xport :-)

L'avantage de cette méthode, c'est qu'elle est sans driver puisque le protocole de l'amiga est très simple : un pin par bouton EDIT : Et non ta méthode ne marcherait pas, il faudrait réinclure le driver dans l'émulateur, ce qui serait très caca.

(re) Salut, S'attaquer à un kernel en premier, c'est pas vraiment grave mais il faut bien comprendre comment fonctionne la compilation sous linux (et autres) : Admettons que j'aie un programme en C, disons prog.c, qui a besoin de fonctions qui sont dans un fichier aux.c. Première étape : on compile tout ça séparément, c'est à dire qu'on va créer des "fichiers objets" prog.o et aux.o. Pour ça on utilise un compilateur, par exemple gcc. Deuxième étape : on "relie" (link) tout ça, ce qui nous permet d'avoir un exécutable, par exemple "test" (ce serait "test.com" ou "test.exe" sur un système windows). Bien sûr, c'est dans cette étape qu'on met en relation les différents fichiers objets...Pour cette opération, on utilise un linker, par exemple ld. La compilation d'un kernel, ça suit plus ou moins le même schéma, mais bien sûr tout est dans plein de fichiers (bien) rangés dans des répertoires. Pour simplifier la compilation, on utilise la commande "make". Le principe de make, c'est à la fois simple et compliqué : d'un point de vue simple, make permet de voir ce qui a besoin d'être compilé et ce qui n'a pas besoin de l'être. Make peut aussi faire d'autres choses, comme par exemple "make menuconfig" qui lance un script de configuration. Quand tu lances le "make" tout seul, c'est make lui-même qui va voir dans le fichier de configuration ce qui a besoin d'être compilé, et qui appelle gcc et ld au besoin. Dans ton cas, ce qui s'est passé, c'est qu'il manquait surement un petit fichier .o, et que le linker (ld) cherchait quelque chose qui n'avait pas été compilé, donc l'erreur est normale...Comme ld a été invoqué par make, l'erreur "remonte" une couche, et make arrête tout et t'affiche le message d'erreur. Donc, euh, pourquoi ? ben j'en sais rien. Des fois on oublie de cocher un truc et ça fait tout planter. Je vais essayer d'en faire un, je te dirai si j'ai réussi, et je te donnerai éventuellement mon fichier de config :-) EDIT: ça compile, ça a l'air de marcher. EDIT2: en fait non :-) Je vais rtfm pour voir si il n'y a pas une connerie à déclarer lors de la compilation...

http://scummvm.org/downloads.php Il y a les cutscene packs pour broken sword (=les chevaliers de baphomet), je pense qu'il faut les inclure à part pour les faire tourner avec scumm.

... et avoir une xbox qui prend tout de suite plus de place...