Garbit

Est-ce que en "arrivant à faire péter le verrou en écriture" d'une disquette tu peux y écrire 5 mo ? non, ben la c'est pareil.

Non, le verrou en écriture c'est un petit interrupteur pour verrouiller l'écriture, comme sur les disquettes ou les clés usb.

A priori, c'est un controlleur + une flash, avec deux-trois gadgets qui viennent se greffer sur le controlleur (un verrou en écriture, peut etre autre chose encore).

Je doute qu'ils mettent un plus gros chip de flash dans les MS, étant donné qu'il y a déjà plusieurs types de MS. Je m'explique : sur xbox il y a des 8 go et des 10 go, de manière invisible pour l'utilisateur (qui n'a pas payé plus cher pour avoir un 10 go), donc c'est normal de "brider", mais là je ne vois pas trop l'intéret de faire des petites MS avec des grosses puces (encore que, il y avait eu une affaire de cartes graphiques bridées il y a une paire d'années...)

Salut, Qu'est-ce que tu entends exactement par "débrider" ?

Salut à toi, A mon avis tu dois pouvoir trouver des "cartes de dev" (mini systèmes embarqués, ex la carte TS7200 qui peut tourner sous NetBSD) qui fonctionnent avec ça, donc en particulier les chips tout intégrés que proposent ces cartes de dev doivent etre compatibles. Je pense que c'est faisable. Pour le port série, tu veux faire quoi ? si j'ai bien compris, il y a un port GPIO accessible de l'extérieur de la PSP ? Au pire tu peux bricoler un peu les MMU de l'ARM et rajouter de la mémoire sur la puce, si tu es juste en mémoire. La c'est carrément du suicide...le moindre fil que tu va mettre va avoir une impédance terrible (ex : un fil de 1 µH va avoir une impédance complexe d'environ j*1 kohm). Pour peu que la résistance du circuit soit du même ordre de grandeur que l'impédance de l'inductance, ca va déphaser dans tous les sens... J'imagine que ça se fait mais il faut faire du travail de pro (avec du matériel de pro donc) C'est du BGA, non ? (article sur Wikipédia Bref, ... En tous cas, ca peut se déssouder avec un "fluide de soudure à phase vapeur", qui quand il chauffe, se condense sur les soudures et les fait fondre (c'est comme ça que ce genre de composants est soudé). Problème : ça coute cher, et ça n'est pas vendu aux particuliers. Tu veux dire, pour pouvoir être un truc commercialisable ? ça a mon avis ça viendra plus tard En tout cas bravo pour ton taf, bon courage pour trouver des partenaires. Essaies peut être de contacter les "grosses" team de hack, ça marchera peut être. ++

Salut, Je ne vois pas en quoi l'utilisation d'un live cd aidera en quoi que ce soit... Ce qu'il y a sur cette "distro" peut être utilisé sur une "vraie" distro (xebian, gentoox), donc pourquoi s'emm***** avec ça ? Si tu trouves une carte tuner usb 1 dont tu as un driver, rien ne t'empêche de l'utiliser sur la xbox.

Si tu veux voir tous tes modules de son, va faire un tour dans /lib/modules/2.6.12/kernel/sound. Normalement tu va trouver quelques modules (peut etre meme un seul si ça se trouve), le nom correspond à ce qu'il faut modprober. Et gdm, une fois le système booté, reste présent en tant que processus, mais ne prend pas de mémoire. Si tu veux un truc *vraiment* léger, utilise non pas gdm mais xdm (c'est super light)

Euuh, non, souvent le son est géré en tant que modules. Il faut que tu modprobes le module correspondant (snd-i810, un truc du genre). Pour ce qui est de ton X, le système de démarrage est assez merdique, d'après ce que j'ai compris. Explication : case `tty` in/dev/vc/1) STARTX=`grep nox /proc/cmdline` if [ "$STARTX" == "" ]; then while true; do /usr/bin/X11/startx > /dev/null 2>&1 done fi;; Comment ce merdier fonctionne-t'il ? Alors : on commence par executer la commande 'tty' (elle renvoie le nom du terminal courant). Si c'est pas /dev/vc/1, alors on ne fait rien. Sinon, on définit une variable STARTX : si la ligne de commande du noyau (celle qu'on configure dans linuxboot.cfg) contient "nox", alors on met STARTX à "nox", sinon, STARTX reste vide (""). Ensuite on compare STARTX et "". Si ça concorde, alors on fait une boucle infinie de lancement de serveur X (comme ça, quand on quitte le serveur X, ça redémarre tout seul X). Sinon, rien ! Le problème, c'est qu'un script de lancement pareil, ça dépend de plusieurs choses. Déjà, le nom des terminaux. Rien ne dit que c'est toujours /dev/vc/1. Ensuite, la ligne de commande du kernel (mais bon, là, pas de soucis). Donc, VRAIMENT, à ta place j'installerais gdm. et je dégagerais ce bout de code de ton bash_profile ! Je rends la monnaie de la pièce qu'on ma donnée il y a une paire d'années ;-)

C'est une idée ils sont dans ton répertoire personnel (/home/streaming), mais n'oublie pas : un point au début -> fichiers cachés. Si tu peux les mettre en copier/coller direct, ce serait plus simple que de les joindre, aussi Et euh, oui, juste startx dans l'un des deux fichiers ça suffirait. Gdm c'est pour faire beau ou pour gérer plusieurs utilisateurs, mais bon, si tu n'en as pas besoin

Salut à toi ! Tu as quel bios ? un cromwell j'imagine ; un récent ? (dernière version : 2.40) Pas assez de mémoire ? il parle de mémoire tout court ? à la limite c'est peut etre pas trop grave, souvent les progs d'installation sont plus "lourds" que la distro elle-même. Tu comptais faire une partition en ext2, une en ext3 et une de swap ? je te conseille de tout mettre en ext3 (sauf le swap bien sur). Tu avais partitionné comment ? Sinon, ben mandriva c'est loin d'etre le top ! pourquoi ne pas prendre xebian (ou gentoox, à la limite) ?

J'ai déjà remarqué que ce genre de phénomène arrive plus souvent quand on est en manque de sommeil et en overdose de café, mais c'est vrai que quand on connait pas, ça fait serieusement flipper de se dire "j'ai déjà vécu ça".

Ok, super ! le truc que tu avais oublié, ça devait être un truc dans input core support, un truc du genre, non ? Ca c'est bizarre. Normalement, même si l'autologin se fait, le serveur X doit etre lancé par quelque chose. Quand ton shell (bash) se lance (donc juste après le login), il execute le contennu des fichiers .bashrc ou .bash_profile (selon que ce soit un "login shell" comme dans les terminaux virtuels (que tu obtiens avec Ctrl-Alt-Fx), ou avecc un "interactive shell" que tu obtiens par exemple dans un emulateur de terminal (xterm, konsole...)). Donc à mon avis il doit y avoir une ligne "startx", ou autre, dans l'un de ces deux fichiers, sinon je ne sais pas comment il démarre X. Si tu veux faire un truc mieux, oublie l'autologin, et installe gdm. Ensuite tu place une ligne dans ton inittab ou tu dis de démarrer gdm (c'est très bien documenté), et miracle, au boot tu te retrouve directement avec une invite de login graphique (comme sur toutes les distributions sur pc par exemple). Ca me parait etre la meilleure solution ! Au fait, tu utilises ta xbox sur un écran vga ?

Du calme... avant de contacter M6 pour "Normal / Paranormal", calme-toi et refléchis... des truc peuvenet sembler bizarre, mais tout trouve son explication. Les trucs bizarres ça a toujours fasciné les gens, et on met toujours les phénomènes étranges en avant, mais le monde reste comme il est : physique. Il est bien régi par les équations de Maxwell : et pas par les apparitions. Même si vous avez un problème, que vous ne savez plus quoi faire... une équipe de spécialistes est là, pour vous. Cette équipe, c'est l'équipe de sans aucun doute. Non, plus sérieusement, c'est obligé : y'a une explication ! c'est obligatoire.

Le support fatx, c'est pas vraiment un vrai support. En fait, les partitions fatx ne sont pas vraiment des partitions non plus... d'ou leur numérotation bizarroide. Donc au lieu de fatx, mets auto, il s'y retrouvera parfaitement. Et le coup du rouge et noir, c'est juste dû à vi.

Donc pour celui-là, déjà, c'est reglé :-)

Quelque part dans device drivers -> usb, mais pour l'instant je ne peux pas t'en dire plus. J'irai voir ce soir, je te dirais ça

Non, niveau logiciel y'a pas de problème, tu n'es pas obligé de rebooter. Le reboot c'est vraiment pour faire le ménage niveau noyau. Si par exemple tu as installé un service qui se lance au démarrage (ex : le serveur web apache), tu peux le démarrer à la main (genre /etc/init.d/apache start). Sinon, la mémoire se libère bien. Le seul truc qui plante communément c'est le serveur X (xorg, surtout).

RTFM ? man steam ? sinon, sont-ce les mêmes versions ?

...normal :-) Tu as ajouté le support clavier/souris, mais pas clavier/souris.... USB ! tada ! ils ne sont pas rangés au meme endroit. Qui c'est qui va recompiler son kernel ? ;-)

Je parlais du support clavier et souris au démarrage. Pour ça, le code doit etre chargé dans le noyau, et pour ça, tu as deux solutions : -soit tu met le code dans le noyau directement ("en dur"), et pour ça il faut recompiler. Pour ça, tu vas dans ton /usr/src/linux-2.X.Y, tu fais make menuconfig, tu charges ton ancienne configuration (celle que tu es allé chercher sur le CVS), et tu édites deux choses : tu changes "USB Keyboard", qui est coché en tant que module (m), en dur (y), et pareil pour "USB mouse". Ca doit etre dans devices drivers -> USB -> input devices, un truc comme ça. Ensuite, tu quitte le menuconfig, tu enregistres ta configuration, et tu compiles le kernel par "make", (pas besoin de refaire les modules, normalement), et tu retrouves ton kernel, avec en plus le support clavier/souris, dans arch/i386/boot/ (enfin, là ou il se trouve d'habitude, quoi). -soit tu lui dis de charger automatiquement les modules au démarrage. Pour ça, il y a plein de méthodes différentes. Une méthode propre, ce serait d'aller voir dans /etc/modules.conf, mais je n'ai jamais utilisé, donc je ne peux pas t'aider (en plus je crois que c'est pas évident). Une autre méthode, c'est d'utiliser les scripts de démarrage. Juste à la fin du boot, les lignes de /etc/rc.local sont exécutées, donc tu peux y placer "modprobe usbkbd" et "modprobe usbmouse" pour charger les modules automatiquement au démarrage. J'espère avoir été plus clair :-)

Le serveur X, pour être franc je n'en sais rien. Mais bon, à ta place je bricolerais ça pour installer gdm (login graphique), c'est plus simple. Les modules, ben c'est simple : avant, ces fonctions là étaient codées en dur dans le noyau (pas en modules), donc il n'y avait pas besoin de les charger ... ! Donc, deux solutions : -soit tu recompiles ton noyau en activant le support en dur de ton clavier et de ta souris (ça va mettre 2 secondes puisque tout est déjà compilé : il n'y a plus qu'a linker tout) -soit tu ajoutes à la fin de /etc/rc.local les deux lignes permettant de charger les modules. C'est moins propre, mais ça t'évite de recompiler un kernel (si c'est laborieux). Sinon, il me semble que cromwell 2.40 permet de faire un "boot menu" avec une liste des kernels à booter, ça peut etre interessant. Pour le problème du lancement de X, tu peux mettre ton /etc/inittab s'il te plait ? merci

Euh je poste à vitesse lumière ("56k hors forfait"-style) : essaye de modprober "usbmouse", ça doit etre la meme chose. Réponse moins succinte demain ! (ou pas). Désolé

Sinon, on peut faire tu transfert de fichiers par ssh, ça s'appelle scp. Sous windows, les gars de chez putty ont fait un client, qui s'appelle pscp.

Mais non ! Tout ce qui est runlevel, etc, ça se passe avec tous les fichiers genre inittab... Le kernel n'a rien à voir avec tout ça. Le kernel, c'est juste un binaire d'environ 1 Mo que le bootloader (cromwell, ici) copie en mémoire et execute, en lui passant certains paramètres ("root=/dev/hdaX" par exemple). On peut accéder à ces paramètres après le boot, c'est ce qui permet de définir, au niveau bootloader, le runlevel désiré. Je m'explique : Tu appuies sur le bouton power de la xbox : le bios, cromwell, se charge, et te permet de booter sur un kernel. Donc cromwell copie décompresse le kernel en mémoire (bzImage -> c'est du bzip2), et l'exécute (c'est un format qu'il connait). A ce niveau là, personne ne sait que tu as linux d'installé sur ta bécane. Rien de ta partition hda1 n'est connue par le kernel. Elle a juste servi a aller chercher le kernel. Donc, c'est dans cette phase que tu vois : "Uncompressing Linux....OK, booting the kernel" (enfin, ça c'est sur PC, je crois que sur xbox, le temps que la vidéo s'initialise, on ne voit pas ce message). Ensuite, il t'affiche une petite carte de la mémoire (genre, le kernel est chargé là, "vous etes ici"), et le kernel s'amorce veritablement, et il détecte les périphériques. Pendant cette période, tu vois des trucs genre : eth0 : Realtek machinchose PCI ethernet adapter hda : Maxtor truc-o-tron 123456 MBytes ... Et quand il a fini son petit tour de manège, il se dit que bon, il est peut etre temps de démarrer le système, c'est à dire, le reste de la distro. Pour ça, il appelle le programme "init". Problème : où le trouver ? par défaut, il va le chercher sur la partition d'ou il a été appellé (en l'occurence, hda1), et en /bin/init. La première chose que init affiche, c'est en général un petit message d'acceuil, genre : Init : version 2.84 booting (de nos jours, on trouvera 2.84, 2.85 ou 2.86) Welcome to Mandrake Linux 9.1 ! Press 'I' for Interactive startup. A ce moment là, init va consulter le runlevel qu'on veut lui imposer : pour ça il va voir la ligne de commande avec laquelle on a lancé le kernel (append="root=/dev/hdaX kbd-reset ... ") et cherche si il y a dedans un "nombre seul" (genre root=/dev/hdaX kbd-reset N). Le cas échéant, il démarre en runlevel N (où N=1...5. Les runlevels 0 et 6 sont des runlevels reservés correspondant respectivement à l'arret et au reboot de la machine). Sinon, il démarre au runlevel par défaut, comme spécifié dans /etc/inittab. Question : comment init, un programme qui tourne sur le disque, peut avoir accès à la ligne de commande du kernel ? via le pseudo-système de fichiers monté dans /proc. C'est un ensemble de "faux fichiers" que le kernel met à la disposition de l'utilisateur. En l'occurence, c'est dans /proc/commandline (ou /proc/sys/commandline, je ne sais plus). Inint affiche alors : INIT: entering runlevel : N Ensuite, selon le runlevel désiré, une "collection" de services se démarre. En fait, pour démarrer les services du runlevel N, il lance tous les executables se trouvant dans le repertoire /etc/init.d/rcN.d/ (ou un truc du genre, je me trompe toujours). Par exemple, s'il y a un fichier nommé "apacheS20", cela correspond au démarrage ("S") du serveur apache, avec une priorité 20 (dans l'ordre des lancements je crois), ce qui se traduira visuellement par : Starting Apache Web server... [ OK ] Etc etc. Quand il a fini, il "spawne" (je ne sais pas quel est le mot en français...) les terminaux virtuels accessibles via Ctrl-Alt-FX (X=1..5 habituellement), et dans es terminaux il met généralement une invite de login, ou un machin pour démarrer un "graphical login manager", genre gdm, xdm ou kdm (qui s'occupent comme des grands de démarrer le serveur X par un processus que je ne connais pas bien. Y'a du xsession, du xauth, du startx, beuah) Bon, ça c'est un boot mandrake 9.1, xebian c'est plus ou moins les memes idées. Tout ça, ça s'appelle le système d'init "System V" (ou SysV) (V = 5), en reference à une vieille version d'Unix d'ou ecla est tiré. En général, on oppose les init SysV aux inits BSD, qui fonctionne différemment. Certaine ditributions de gnu/linux offrent des inits BSD, mais c'est encore rare (Ex, et pub : Arch Linux). Voilà, je voulais clarifier tout ça, pour dédiaboliser les runlevels, j'espère que j'ai réussi Et tu me diras ce qu'il en est de ton serveur X