niol a écrit 403 commentaires

C'est en regardant le code source du driver il y a longtemps que j'ai vu ce que le -2 voulait dire, ce que je te traduis plus haut.

Ca ne vient pas du 2.6.23. Car chez moi ca marche.

Vu que tu dis plus loin que ca marche si tu le met en module, je pense que ca venait du fait que s'il n'est pas en module, il essaye de démarrer à un moment où il n'a pas encore le système de fichier et donc pas le firmware, mais je peux me tromper...

Salut,

ipw2200: Unable to load firmware: -2 correspond en gros à Aucun fichier ou répertoire de ce type.

Donc tu t'es trompé d'endroit pour ton microcode. De mémoire, mais sans pouvoir le vérifier tout de suite sur mon ordi, le firmware se place dans le répertoire /usr/lib/hotplug/firmware/.

Voir éventuellement la doc : http://ipw2200.sourceforge.net/faq.php#qa_1_7

La liste des particularités de ton installation, c'est justement cette image disque.

Moi aussi mon intuition me disait que c'était une méthode bourrine, mais en fait, quand on réfléchit, on ne voit pas bien ce que ca va apporter de plus de tout réinstaller : on aura après beaucoup d'efforts le même résultat. Le concept d'installation propre n'a pas la même pertinence que sous un autre OS : en général, les seules choses à nettoyer, ce sont des paquets que tu n'utilises plus, et sous Debian, c'est aptitude purge.

Il faut bien noter que avec udev, le matériel est détecté à chaque démarrage, il n'y a donc rien au niveau driver de figé par rapport à ton matériel. Le reste, c'est les mêmes binaires, donc je repose la question de la pertinence de tout réinstaller.

Je ne demande qu'à changer d'avis mais pour le moment j'ai zéro argument contre la technique de l'image disque.

En général, et j'ai pu le vérifier, en mettant un disque dur dans du nouveau matériel, tout fonctionne impécablement.

La seule manipulation à connaître consiste à nommer correctement les cartes réseau. En général, effacer /etc/udev/rules.d/z25_persistent-net.rules pour qu'il soit regénéré suffit.

Ensuite y'a deux trois trucs annexes un peu plus évidents, comme le nom des disques durs / lecteurs DVD si tu changes tes branchements, ou le xorg.conf si tu changes de carte graphique.

Là où tu n'as pas le choix, c'est si tu changes d'architecture (du genre i386 -> amd64) où là il faut utiliser la méthode décrite plus haut.

J'utilise darcs car lorsque la question s'est posée, c'était le seul qui permettait d'enregistrer seulement un changement dans un fichier et pas forcément tous les changements d'un fichier.
(c'est maintenant apparemment possible avec mercurial au moins grâce à http://www.selenic.com/mercurial/wiki/index.cgi/RecordExtens(...) )

mercurial était trop jeune et git trop compliqué en apparence. J'aime la simplicité "un dépot, une seule branche". Darcs s'apprend en quelques minutes. Ca c'est vraiment bien.

De plus, je ne me suis pas encore heurté de manière bloquante aux problèmes connus de darcs (voir http://wiki.darcs.net/DarcsWiki/FrequentlyAskedQuestions#hea(...) )

L'environnement Maemo (rootstrap dérivé de Debian pour le Nokia N770 et N800) a aussi ca sous le nom de Single-click install. Pour ceux qui sont familiers avec Debian, c'est tout simplement un fichier servi par http qui ressemble à ca :

[install]
repo_name = Foo Catalogue
repo_deb  = deb http://foo.com/maemo mistral user
package   = foo-app

Ca ajoute le dépot et ca installe le logiciel spécifié le cas échéant. La spéc : https://stage.maemo.org/svn/maemo/projects/haf/trunk/osso-ap(...)

Essaye de lancer tzconfig en root et de mettre (ou au moins vérifier) le bon fuseau horaire.

Une page[1] du wiki officiel dit que pour sarge, c'est les paquets qui vont attérir dans la stable rN. En effet, la version stable de debian est mise à jour régulièrement avec les corrections de bugs non intrusives et les mises à jour de sécurité, voir l'exemple de l'annonce de sarge r6[2]. Aucune idée de savoir si c'est valable pour etch, mais y'a pas de raison.

[1] http://wiki.debian.org/DebianVolatile
[2] http://www.debian.org/News/2007/20070407

A noter que même en 2D, le gain de performance entre le driver libre nv et le driver propriétaire nvidia est énorme.

Par exemple, pour lire une vidéo en 1280x720 (DX50) via XV, ce n'est tout simplement pas possible sur mon ordi avec le driver libre (Xorg utilise tout le temps CPU) alors qu'avec le driver propriétaire, ca passe (moins de 30% du temps CPU pour mplayer et Xorg).

Je ne pense pas que ce soit un cheval de troie mais plutôt une très mauvaise façon de controuner un problème dans leur driver.

Pour nautilus, aucune idée.

Pour ce que je te conseille, rien de bien simple. Perso, ce que je ferais, c'est exécuter le scipt d'installation en enlevant ces lignes setuid. Ensuite, voir les droits minimum dont a besoin xsane pour fonctionner, créer un groupe dédié qui a les droits sur les bons périphériques de /dev (apparemment /dev/mfpports et le port série) et s'ajouter dans ce groupe. Mais je sais pas si c'est possible. A voir, par tatonnement en utilisateur normal en regardant ce qui ne marche pas (éventuellement à coup de strace)...

Pour info, c'est comme celà que fonctionne l'usb, la carte son, etc (au moins sur Debian et ubuntu) : si tu n'es pas dans le groupe audio, tu ne peux pas écouter de musique car seul les utilisateurs du groupe audio on le droit d'écrire dans /dev/snd/*.

Dans le source du script d'instalaltion des drivers, on peut voir :

        wrap_setuid_third_party_application xsane
        wrap_setuid_third_party_application xscanimage

        wrap_setuid_ooo_application soffice
        wrap_setuid_ooo_application swriter
        wrap_setuid_ooo_application simpress
        wrap_setuid_ooo_application scalc

et :

wrap_setuid_third_party_application() {
        if echo "$1" | grep -q "/" ; then
                APP_NAME=$1
        else
                APP_NAME=`which $1 2> /dev/null`
        fi
        NEW_NAME=${APP_NAME}.bin

        if test -n "$APP_NAME" ; then
                if ! test -f "$NEW_NAME" && ! test -d "$NEW_NAME"; then
                        mv "$APP_NAME" "$NEW_NAME"
                        cp -af /opt/${VENDOR}/mfp/bin/suwrap "$APP_NAME"
                        chown root:root "$APP_NAME"
                        chmod 4755 "$APP_NAME"
                fi
        fi
}

wrap_setuid_ooo_application() {
        WRAPPING_BIN=`ls /usr/lib*/*/program/$1.bin /opt/*/program/$1.bin 2> /de
v/null | head -1`
        if test -n "$WRAPPING_BIN" ; then
                ${2}wrap_setuid_third_party_application $WRAPPING_BIN
        fi
}

Donc en gros il te copie les exécutables ooo dans /opt avec l'extension .bin et il te les remplace par un script setuid qui les appelles. Je n'ai jamais vu une telle horreur.

Et pourquoi donc ne fermes-tu pas stdin après avoir forké vers mplayer (comme fait dans l'exemple que je te donne)?

Pour piloter le stdin et le stdout d'un fils, il faut, juste après le fork(), fermer stdin et stdout et faire un dup() de deux descripteurs de fichier au préalable défini sur respectivement stdin et stdout. Les deux descripteurs de fichier étant connu du père, en écrivant dessus, on pilote mplayer (avec de préférence -slave mais pas obligé).

Exemple de code repompé d'un d'un de mes vieux projets (le programme à lancer s'appelait apt, rien à voir avec Debian) par flemme de chercher dans Google:

#include <stdio.h>
#include <unistd.h>
#include <stdlib.h> // exit()
#include <string.h> // memset(), strcat()...

#include "apt.h"
#include "msg.h"
#include "init.h"
#include "parse.h"

#define STDIN 0
#define STDOUT 1
#define STDERR 2


/* The size should be around 500, because of the mvts answer */
#define APT_OUTPUT_LINE_MAX_LENGTH 1000

extern config* current_configuration;

int APTIN_K,APTOUT_K;
FILE* STREAM_IN;
FILE* STREAM_OUT;

void APTlaunch(const char *apt_path,int* aptin_k,int* aptout_k){

  int childPid;
  int pipefdin[2],pipefdout[2];

  /* Pipes init */  
  if( pipe(pipefdin) == -1 || pipe(pipefdout) == -1 ){
    perror("Creating apt communication pipes");
    exit(1);
  }

  childPid = fork();
  
  if( !childPid ){

    // son, so we launch apt and we connect
    // its standards channels to pipes

    // close unused channels
    close(pipefdin[1]);
    close(pipefdout[0]);

    // Duplicate stdin to our pipe
    close(STDIN);
    if( dup(pipefdin[0]) == -1 ){
      perror("duplicating apt stdin");
      exit(1);
    }

    // Duplicate stdout to our pipe
    close(STDOUT);
    if( dup(pipefdout[1]) == -1 ){
      perror("duplicating apt stdout");
      exit(1);
    }

    // Duplicate stderr to the same pipe as stdout
    close(STDERR);
    if( dup(pipefdout[1]) == -1 ){
      perror("duplicating apt stderr");
      exit(1);
    }

    // Launch apt
    if( execl(apt_path,apt_path,NULL) == -1 ){
      perror("can't find apt");
      exit(1);
    }

  }else{

    // father, this process, continues execution

    // Close unusable channels
    close(pipefdin[0]);
    close(pipefdout[1]);

    // Return the right values to control the apt
    *aptin_k = pipefdin[1];
    *aptout_k = pipefdout[0];

  }

}

void APTstart(const char* apt_path){

  // Launch the apt upon the connection
  APTlaunch(apt_path,&APTIN_K,&APTOUT_K);

  // Use stdio to manipulate the commands
  STREAM_IN = fdopen(APTIN_K,"w");
  STREAM_OUT = fdopen(APTOUT_K,"r");

}

void APTstop(){
  write(APTIN_K,"q\n",2);
}

int APTloadDataFile(const char* filename){
  int written;
  
  written = fprintf(STREAM_IN,"load %s%s\n",current_configuration->apt_data_path
,filename);
  fflush(STREAM_IN);

  return written;
}

int APTsendCommand(const char* cmd){
  int written;
  
  written = fprintf(STREAM_IN,"%s\n",cmd);
  fflush(STREAM_IN);

  return written;
}

char* APTgetNextLine(){
  char* line;
  line = (char*)malloc(APT_OUTPUT_LINE_MAX_LENGTH*sizeof(char));

  fgets(line,APT_OUTPUT_LINE_MAX_LENGTH,STREAM_OUT);

  // Careful, the \n is still in line
  return line;
}

char* APTgetOutputTillEmptyLine(){
  char* buffer;
  lineList* acftList = (lineList*)malloc(sizeof(lineList));
  lineList* otherLines;
  int byteCounter = 0;
  
  acftList->line = APTgetNextLine();
  acftList->nextLines = NULL;
  otherLines = acftList;

  if( acftList->line[0] != '\n' ){
    buffer = APTgetNextLine();

    while( buffer[0] != '\n' ){
      byteCounter += strlen(buffer);
      otherLines = addToLineList(otherLines,buffer);
      buffer = APTgetNextLine();
    }
  }

  buffer = lineList2string(acftList,byteCounter);
  freeLineList(acftList);

  return buffer;
}

void APTflushOutput(){
  char* line = APTgetNextLine();

  while( strcmp(line,"\n") ){
    free(line);
    line = APTgetNextLine();
  }
  free(line);
}

Pour la taille de la vidéo en plein écran, utilise -vo xv ou vo=xv dans le fichier de conf de mplayer.

Essaye un grep sur ton profile Firefox.

voir http://lists.debian.org/debian-security/2006/09/msg00040.htm(...)

En général, pour ce genre de problèmes, commence par renommer ton répertoire avec ton profile Firefox pour avoir un Firefox tout neuf et tester.

Est-ce que ca n'aurait pas un rapport avec cà :
https://bugs.launchpad.net/ubuntu/+source/avahi/+bug/94940

Je ne sais pas si il y a des règles toutes faite. De mon exprérience, j'essaye de séparer :
- ce qui est donnée de ce qui est programme (pour pouvoir réinstaller facilement)
- ce qui change souvent de ce qui change rarement (pour éviter les corruptions)
- ce qui est à sauvegarder de ce qui ne l'est pas (pour pouvoir idnetifier facilement ce qui est à sauvegarder)

Le Partitioning HOWTO semble confirmer ce que je pense : http://tldp.org/HOWTO/Partition/requirements.html

Après, les choses classiques :
- /var à part car ca change souvent
- /home ou /var/www (selon ce que tu choisis) à part car c'est à sauvegarder
- la swap à part comme d'habitude
- éventuellement /boot à part pour gérer les problèmes de boot
- éventuellement une partition de sauvegarde à part.

Avant, tu peux voir si tu veux faire du RAID.

Pour finir, je te donne l'exemple de mon ordi qui peut être bon ou mauvais mais bon, c'est un exemple :
Sys. de fich. Tail. Monté sur
/dev/hda1 259M /
/dev/hdc1 19G /backup
/dev/mapper/maxtor-home 53G /home
/dev/mapper/maxtor-tmp 496M /tmp
/dev/mapper/maxtor-usr 2,0G /usr
/dev/mapper/maxtor-var 18G /var
/dev/mapper/seagate-fileserv 147G /var/fileserv

Cet article dit qu'il faut activer le démon rsync pour faire du rsync à travers ssh ce qui n'est pas le cas. La partie où l'on touche au fichier /etc/default/rsync est donc à zapper.

Darcs:

alias darcsify='darcs init && darcs add $(darcs whatsnew -ls | awk '\''/^a\ / {print $2}'\'') && darcs record -a -m'\''Initial import'\'''
alias dgrep='find . -path '\''*/_darcs'\'' -prune -o -print0 | xargs -0 egrep -I'

Apache:

alias lastreferers='awk "{print \$4 \" \" \$11}" /var/log/apache2/access.log | grep http | grep -v my.host.com'
alias lastreferers_old='awk "{print \$4 \" \" \$11}" /var/log/apache2/access.log.1 | grep http | grep -v my.host.com'

Musique :

alias maestro='mpc volume 40 && mpc toggle'

Debian:

alias mettreajour='su -c "apt-get update && aptitude --with-recommends dist-upgrade && apt-get autoclean"'

ou

alias mettreajour='sudo apt-get update && sudo aptitude --with-recommends dist-upgrade && sudo apt-get autoclean'

A ce propos, je me demande maintenant depuis un grand moment pourquoi la version 2 ne vient pas par les mises à jour automatiques. A la sortie de Firefox 2, j'avais cru lire quelquechose comme quoi il fallait attendre une mise à jour de Firefox 1.5 qui permettrait de refuser une mise à jour.
Mais depuis, plus de nouvelle. Qu'en est-il?
Que va-t-il arriver à ces milliers d'utilisateurs de Firefox 1 qui n'en on rien à faire du planning des sorties des produits Mozilla lorsque Firefox 1 ne sera plus supporté?

Je te conseille Thinking in C++ de Bruce Eckel qui m'a beaucoup appris.

http://www.mindview.net/Books/TICPP/ThinkingInCPP2e.html

(par contre je ne sais pas si ca existe en français)

Je rappelle à tous l'existence d'une vidéo fort intéressante sur les ensembles de développement pour les applications Web.

C'est en quelque sorte un comparatif.

C'est par exemple ici :
http://video.google.com/videoplay?docid=6297126166376226181&(...)

Tu peux regarder dans ton cours, ou à cette page :
http://caml.inria.fr/pub/docs/manual-ocaml/manual004.html#ht(...)

Bon courage.

Oui mais la seule info prix que je trouve me fait fuir : 280 euros HT!

http://gizmodo.com/gadgets/pcs/linutop-pc-keeps-computing-mi(...)

Perso j'ai un Sempron 64bits, donc ton affirmation "car sempron c'est pas 64 bits" me semble fausse, à moins que je n'ai rêvé.

$ cat /proc/cpuinfo | grep -i sempron
model name      : AMD Sempron(tm) Processor 2800+
$ uname -a
Linux ripley 2.6.18-4-vserver-amd64 #1 SMP Mon Jan 1 01:12:52 CET 2007 x86_64 GNU/Linux