M a écrit 2988 commentaires

ln: lien direct n'est pas permis pour un répertoire
man ln

Avec les implémentations existant actuellement, seul le Super-User peut
créer un lien matériel sur un répertoire, et encore, c'est souvent
totalement impossible. POSIX interdit aux appels système link(2) et à
l'utilitaire ln de créer des liens physique sur un répertoire (mais
n'interdit pas les liens matériels entre différents systèmes de
fichiers).
-d, -F, --directory
Autoriser le Super-User à créer un lien physique sur un réper-
toire.

t'as demander au developpeur du driver de ta webcam ?

si tu utilise les driver pwc, apparament il supporte le mode raw, il devrait suffire de le modifier un peu pour que tu puisse envoyer les bonne valeurs...

Oui, mais, cette image iso possède un partie ElTorito, qui permet donc de booté ce cd dans n'importe quel CD, et c'est un peu chiant a faire.

Tu peux pas recuperer l'image avec cdfs et la repasser a mkisofs ( -b) ?

g++-3.4 /tmp/to.cpp
/tmp/to.cpp:2: erreur: « string » ne nomme pas un type
c'est donc bien mieux :)

chez moi (mozilla sous linux), je tombe sur http://www.http.com(...)

Cela ne semble pas provenir de mldonkey.
Qd j'ai essaye mld il y a 1 an sur du bittorrent c'etait la cata, mais ca peut etre change.

Essaye qd meme le client officiel, pour verifier que ça ne vient pas de mld...

sinon pour le firewall, verifie que mld utilise les bon ports et
ACCEPT net $FW tcp 6881:6889 # bit torrent
devrait etre suffisant.

t'as oublier http://slashdot.org/article.pl?sid=04/04/15/1649250&mode=thread(...) ;)

setbuf ( stdout, NULL ); doit aussi marcher

d'ailleur sous konqueror 3.2.2 (qui marche au passage), ça rame quasiment pas...
Pb d'optimisation de mozilla ?

c'est peut etre aussi un pb iptable (cf https://linuxfr.org/~stealth/11614.html(...) )

Bref, pour le moment pas de problème à part des plantés violentes lors de l'utilisation de amule ! (affichage bloqué, plus de clavier ni souris, pas de réponse sysrq...)
driver nvidia ?

Par contre chez moi le prout est ecrit dans le fichier plouf....
j'ai rien dis

Comme dis plus haut, printf (ou quelque chose d'autre) doit voir qu'on ecrit dans un fichier, et le met en cache.
Mais comme on ferme indirectement le fichier, ça chie...

printf("prout2\n"); /* marche pas */
close(STDOUT_FILENO); /* amusant :

le strace donne :
close(1) = 0
write(1, "prout2\n", 7) = -1 EBADF (Bad file descriptor)

c'est marrant (l'assembleur est bon) et si on met un sleep apres le printf, ca change rien (l'attente se fait avant le close)

Par contre chez moi le prout est ecrit dans le fichier plouf....

PS le strace complet

execve("./a.out", ["./a.out"], [/* 30 vars */]) = 0
uname({sys="Linux", node="mat-pc", ...}) = 0
brk(0) = 0x804a000
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40017000
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=46963, ...}) = 0
old_mmap(NULL, 46963, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40018000
close(3) = 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
open("/lib/tls/libc.so.6", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\240X\1"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=1271388, ...}) = 0
old_mmap(NULL, 1281772, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40024000
old_mmap(0x40152000, 36864, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x12d000) = 0x40152000
old_mmap(0x4015b000, 7916, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x4015b000
close(3) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4015d000
set_thread_area({entry_number:-1 -> 6, base_addr:0x4015d2a0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0
munmap(0x40018000, 46963) = 0
open("plouf", O_WRONLY|O_CREAT|O_TRUNC, 010000713231) = 3
close(1) = 0
dup2(3, 1) = 1
close(3) = 0
write(1, "prout\n", 6) = 6
fstat64(1, {st_mode=S_IFREG|S_ISVTX|0611, st_size=6, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40018000
close(1) = 0
write(1, "prout2\n", 7) = -1 EBADF (Bad file descriptor)
munmap(0x40018000, 4096) = 0
exit_group(0)

(au cas ou, autorisation de booter sur CD dans le BIOS)
et si le bios est proteger par un password (oui la plupart des admin n'aime pas qu'on le modifie...)

heu le manga n'etait pas finit quand le film est sortie (anime ver.

Pour la petite histoire, Miyazaki ne voulait pas au debut faire de version anime mais face au succes du manga il a plus ou moins ete force par son producteur de le faire.
Au final, il ne s'en est pas trop mal sorti pour faire tenir tout en 2H et sans faire d'ombre a la version papier

Donc j imagine qu il faudra que je parcourre tout l arbre /proc/bus/usb jusqu a trouver le bon periph ...
l'on se que tu accepte le peripherique lors de l'enregistrement du connais le chemenin...
de plus je suis pas sur qu'il faille que tu utilise directement /proc/usb, mais il faut plutot que tu creer une autre entree dans proc genre /proc/driver/...

Tu peux deja regarder la doc du ernel sur l'usb

ajoute dans ton ~.Xresources
xterm*CharClass: 33:48,37:48,45-47:48,64:48,126:48
pour xterm
Rxvt*cutchars: \"&'()*,;:<=>?@[\\]^`{|}~
pour rxvt

Pour plus d'info man xterm puis recherche sur CharClass...

la topologi-linux le fait (http://topologi-linux.sourceforge.net/index.php(...)), mais j'ai jamais essaye.

Le live-cd de suse, creer aussi un home de 100Mo sur une partition ou l'on peut ecrire et ainsi qu'un mini swap...

Vu que IE est une vrai passoire niveau secu ( la derniere faille date de moins d'une semaine et permet d'ecraser et de lancer des executable avec les privilege de l'utilisateur http://slashdot.org/article.pl?sid=04/04/09/0546203&mode=thread(...)) c'est comprensible que les utilisateurs utilise autre chose

s/exemple/contre exemple et ça change tout...

Ben ca prouve rien : je t'ai donné un exemple de non stabilité des drivers proprio, alors que toi tu me dis que c'est stable chez toi.
Donc au final les driver proprio sont stable sur certaines machines et pas sur d'autres donc au final c'est PAS STABLE.

formellement :
proposition : les driver nvidia sont stable
contre exemple : mon experience -> proposition refutee
exemple : ton experience -> c'est valide dans certaines circonstances, mais tu ne prouve pas que c'est valide pour toutes


Et puis apres moi aussi je peux dire que windows est super stable : je peux le laisser tourner des années sans y toucher : il aura un super uptime....

PS : vive les votes sans reflexion...

A l'epoque (moz 1.3) qd j'avais essayer je n'avais pas non plus de couleur :(

Depuis le 1er avril dernier, une nouvelle version principale de LilyPond, 2.2.0, est disponible.
Et 3 jour avant sortait une nouvelle version de timidity (http://timidity.sourceforge.net/(...) ) avec un nombre impressionant de modif : http://timidity-docs.sourceforge.jp/cgi-bin/hiki/hiki.cgi?NEWS-2.13(...)

> le driver nv est moins stable
avec le driver proprio crash de X entre 1 à 24 H
avec nv aucun crash (j'ai fait plus de 1 mois d'up)

CQFD

Bon, j'ai recopié les sessions dans /etc/dm/...
lequel ?
celle en .desktop ?
chez moi ca a marche...