couriousous a écrit 176 commentaires

Pour être précis, c'est 32kHz dans un montre a quartz.

La fréquence du quartz est mesurée puis la montre est "Programmée" pour qu'elle donne l'ordre au moteur de tourner toutes les secondes.

Qemu supporte l'usb, mais c'est en version 1 uniquement et avec seulement une interface par périférique.

J'ai du patcher qemu pour pouvoir l'utiliser (la M1005 a deux interfaces):
http://lists.gnu.org/archive/html/qemu-devel/2007-04/msg0066(...)

De plus oublie pas de rmmod ehci-hcd afin de forcer linux a être en mode usb1 sinon ca fait planter sévèrement windows dans le qemu (j'ai découvert ca seulement après avoir envoyé le mail sur la ml de qemu).

Et pour sniffer, j'ai au début utilisé usbmon avec l'interface "ascii".
Puis j'ai developpé mon propre outil de sniff qui décodait directement les "paquets" usb spécifique au scanner. C'est pas très compliqué a faire, suffit de trouver les bon ioctl() et le kernel te dump le packet usb dans un buffer.

Ya même des SoC (System on Chip) à base d'ARM9 @ 200MHz avec controleur/accélérateur video et LCD, interface AC97, USB, Ethernet, interface DRAM, coprocesseur FPU et DSP, interface SD et j'en oublie. Je pense en particulier au cirrus logic EP9320 dispo chez farnell et digikey pour moins de 30¤. Et plus linux fonctionne trés bien dessus!!!

Oui, enfin tu semble oublier que la carte de base pour un SoC est bien bien plus compliquée a faire que pour un PIC.
Sur un PIC, tu met 3-4 capa + une alim 5V et ca tourne.
Sur un SoC ARM, tu doit faire au minimum un PCB 5 couches avec un chip dédié à l'alim.
Bref faire une carte pour PIC prend 1 semaine au grand max, et pour un ARM ca prend 1 année ...

Tu veux dire que les machines utilisées par les étudiants (pas seulement ceux en info) étaient presque toute toutes des suns ? J'ai un peu de mal à le croire. Des mac et des linux à la rigueur, mais là j'ai aussi du mal à le croire. En 1998, il me semble qu'apple n'avait pas encore redecollé, et que linux n'était pas assez userfriendly pour etre déployé sur la totalité d'un campus. Ou alors j'ai mal compris ce que tu veux dire ?

Le côté userfriendly n'était pas important à l'époque. J'ai eu mes cours "d'initiation" à l'informatique ( vers l'age de 10-14 ans ) sur des smaky. Et le côté userfriendly des smaky est a vrais dire, inexistant.

Tien ... ca m'a pas l'air très sérieux comme bouquin. Page 6:
"Microsoft a déjà aquis le controle total de l'informatique dans l'éducation suisse".

Il tien ca d'où ?
Certes il y a bcp de Windows, mais les écoles du cantons de Vaud utilisent principalement Apple. Et à l'epfl il y a des salles remplies de fedora ou de solaris et même de ... gentoo.

Ah, et j'ai "appris" l'informatique sur des smaky ... on ne peu vraiment pas dire que MS à le monopole ...

parceque c'est pas vraiment un chiffrage, c'est la méthode utilisé pour de l'étalement de spectre qui fait que tu doit avoir une séquance de nombre pseudoaléatoire qui est orthogonale aux autres signaux ( comme ca tu peux avoir plusieurs canaux de transmission sur la même bande de frequence ).

Le plus de cette méthode, c'est que si t'as pas la séquence de nombre aléatoire, tu peu pas écouter.

Utiliser un périphérique loopback v4l ?
http://www.lavrsen.dk/twiki/bin/view/Motion/VideoFourLinuxLo(...)

Ca risque de demander une modification d'effectv afin qu'il puisse avoir une sortie dans le périph. de loopback, mais sinon ca devrais marcher.

Il est possible d'augmenter la mémoire à l'aide d'une carte pci. Il suffit de dire à linux de créer un périférique de type "block" sur la mémoire d'un périphérique pci ( par exemple, une carte graphique, sa ram est accessible, si on dit à xorg de ne pas utiliser l'entier de la ram dédiée, on peu faire ce hack avec le reste ). Puis de créer une swap sur ce périphérique. Certe, c'est pas de la ram directement accessible, cependant son temp d'accès et son débit sont bien plus élevé que sur un disque dur.

Le réseau est une étape "capitale" lors du boot d'une distribution linux. La plupart des scripts dépendent du réseau soit directement soit indirectement ( par exemple, il requires syslog qui lui requires network ).

Le démarrage des service en parallèle n'est pas la solution miracle. Elle aide dans certain cas ( en général 20% sur un boot "normal" ), mais pas dans tous. Hors dans ton cas le facteur limitant est ta connection adsl. Et pour cela le démarrage des service en parallèle ne peu rien y faire.

Ce que tu peu éventuellement faire, c'est dire à harddrake de ne pas démarrer la conneciton adsl au boot, et le faire à la main dans /etc/rc.d/rc.local .

A part ca, tu a bien mis l'argument "pinit" au boot et patché les service avec les # X-Parallel-Requries: ( et non pas simplement # Requries ).

pinit aussi est "bien pensé" et "bien réalisé".

Je n'irais pas jusque la. pinit est juste une couche supplémentaire sur les scripts sysV. Ca relève plus du quick hack que d'un système aussi poussé que initng

Initng est une refonte totale des script de démarrage. Ce n'est pas compatible avec les scripts sysV.

pinit/prcsys est juste un ajout ( quelque commentaires de plus dans le script ) afin de savoir les dépendances qu'il y a entre les différend services.

Les deux sont évidemment mutuellement exclusif.

Je suppose que initng est plus performant, cependant il faut réécrire tous les scripts et perdre la compatibilité LSB. Ce que aucune distribution "grand publique" veux.

Un centrino avec une carte graphique intel ?

Ca doit bien se trouver ca ...

( et pour le modem 56k, certain sont "géré" par alsa, avec une partie en userspace closed-source, donc bon, c'est à la limite limite )

Déja fait pour mandriva http://archives.mandrivalinux.com/changelog/2005-11/msg02022(...)

est-ce que cooker est différent de la version qui sera releasée ?

Oui, tu test cooker, pas la 2006 la.

Bon, ok c'est pas en français, mais au moin ca vient de source directe: Linus lui même:

http://lkml.org/lkml/2005/8/20/95(...)

Il explique très bien pourquoi il fait ca, pourquoi ca coute, et qu'il ne touche pas un kopeck de cet argent.

J'aimeai bien savoir quel régime transitoire il peu y avoir lorsqu'il y a une résistance ohmique pure ( pas de partie inductive ou capacitive ) ?

AFAIK, c'est dû à la "fatigue" que subit le filament du au dilatations thermique provoqué par les allumages/extinction. Et le fait qu'il soit pas allumé assez longtemp ne lui laisse pas asser de temp pour "relaxer" les contraintes internes => au bout d'une dizaine de "jour,nuit" il casse.

Non, elle clignottent à 100Hz car P=R*I^2 donc quand I est "négatif", ca éclaire aussi.

le 16 2/3 est uniquement la pour des raisons historiques.

Au tout début de la production d'électricité alternative, il n'était possible que de produire avec des turbines du courant à une fréquence de 16 2/3 et ce uniquement pour des raisons techniques.

C'est uniquement lorsque on a voulu faire des lampes avec le courant 16 2/3 que on s'est dit que ca irait mieux de le faire à 50Hz ( car ca donne un clignottement de 100Hz => pas visible contrairement au 32Hz du 16 2/3 ).

Cependant il existe tout de même des "transformateur" entre le réseau civil et le réseau CFF. Mais ceux ci sont d'une puissance limité, et lorsque t'as 4 usines électriques qui tombes, ben ca fait *MAL*.

Ben, ca serait cool de filer le soit disant fichier
car tes explications sont lacunaires et donc j'utilise peu être le mauvais format.

Voici un "essai" codé en C. J'ai pas intensivement testé, donc il peu y avoir des bugs:

#include  <stdio.h>
#include <string.h>
static const char sequence[2] = {0xb1,0xb2};
int main(int argc, char ** argv) {
        int size;
        char buffer[256];
        char * plop;
        FILE * coin;
        if(argc != 2 || (coin = fopen(argv[1],"r")) == NULL)
                return 1;
        while((size = getc(coin)) != EOF) {
                fread(buffer,1,size,coin);
                plop = memchr(buffer, sequence[0],size);
                if(plop == NULL || *(plop+1) != sequence[1]) {
                        putchar(size);
                        fwrite(buffer,1,size,stdout);
                        continue;
                }
                size -= 2;
                memmove(plop,plop+2,size - ( buffer - plop ) -2);
                putchar(size);
                fwrite(buffer,1,size,stdout);
        }
        return 0;
}

C'est simple:

Apple rend le CVS de webcore ( le moteur de safari, basé sur khtml ) dispo à tous.
Ils ouvrent un bugzilla.
Ils crée un chan irc pour discuter avec les dev.
Ils acceptent les contributions.
Ils open-source le code de "glue" qui servait a faire tourner khtml dans OSX.

C'est en gros ce que demendaient les dev kde.

Et tu saurais quelles options il manque ?

pourquoi il ne faut pas utiliser le package de mandriva ?

Une solution:

rpm -qa --queryformat '%{name}\n' > package_list

puis urpmi `cat package_list`


Il me semble qu'il y a une solution pour faire une liste qui soit lisible à l'installation de la distrib comme ca il te sélectionne et installe lors de l'installation de la distrib les packages que tu veux.

s/SS/CRS/