niclone a écrit 349 commentaires

C'est la merde. Tant que linux n'aura pas un support du temps réel dur en standart, il n'y aura rien de valable. Mais si tu y tiens vraiment, regarde du coté de "jackd" (il te faudra patcher ton kernel avec low-latency et premptive), et du coté des effets "LADSPA", je crois que "jack-rack" te permet de faire ce que tu souhaite. Bon courage....

Un faux contact quelque-part (en général, une soudure qui à laché). Ca ce situe en général sur une petite plaque au cul du tube. Avec un bon oeil, un fer a souder, et du fil de soudure, tu peux t'en sortir. Mais attention, cette partie du tube est tres fragile, et tres dangereuse -> ne surtout pas forcer (risque d'implosion du tube), et faire attention ou tu fou les mains (très haute tensions allant de 7 a 15kV selon les tubes/taille, même débranché). En bref, mieux vaut laisser ca a quelqu'un qui s'y connait un peu :)

en fait, c'est surtout la compression qui est plus lente. Je doute que ca change grand chose à la décompression.

Après reflexion, je m'auto-corrige, je dis n'importe quoi :)

Il faut bien 2 lectures, et 2 écritures pour écrire 1 bloc!

désolé :)

Je ne vois pas pourquoi en écriture, il est utile de lire l'ancien contenu du bloc. J'oublis peut être un détail? si c'est le cas, merci de m'en faire part.

Ensuite, dans le cas de la lecture comme de l'écriture, pour un RAID 5 (prenons le cas du 3 disques, qui est le minimum pour du RAID 5), il y a, pour l'écriture:

3 écritures (1 par disques). Mais il faut pas oublier quand même, que c'est 3 écritures sont faitent en //, les données sont envoyés certe 3 fois par le(s) bus IDE/SCSI, mais l'attente réel est faite par chaques disques dur, en même temps. Sans parler des caches/tampons interne au disque dur, et ceux de la carte IDE/SCSI. Bref, concretement, avec un bon controlleur RAID, un RAID 5 ne devrait pas être plus lent qu'un seul disque, sauf dans de très rare cas.

"Afin de combler les dépenses de santé lié au cancer du poumon..."

A remplacer par:

"afin de combler le manque à gagner du à la reduction du temps de travail (35h)"

Tiens, c'est marant, ta phrase en perd tout son sens du coup...

Je t'ai boutonMilieu-moinssé, ca marche toujours ;-)

Je voulais dire, a lancer comme ca:

nohup ./script.sh &> script.log &

:o)

Je confirme, l'ajout de ces options, c'est mieux :)
J'ai un peu amélioré le script du coup, et amélioré pour avoir un peu des logs.
Je propose une liste de USERAGENT, histoire que ca soit pas toujours le même, il faut donc décomenter une ligne, selon votre humeur ;)

a lancer comme ca:

nohup ./script.sh &> script.log


le script:

#!/bin/bash

#USERAGENT="Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.4) Gecko/20030714 Debian/1.4-2"
#USERAGENT="Mozilla/5.0 (Macintosh; U; PPC Mac OS X; fr-FR; rv:1.2.1) Gecko/20021130"
#USERAGENT="Mozilla/5.0 (Windows; U; Win 9x 4.90; fr-FR; rv:1.4) Gecko/20030624"
#USERAGENT="Mozilla/5.0 (Windows; U; Windows NT 5.1; fr-FR; rv:1.4) Gecko/20030624"
#USERAGENT="Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.5a) Gecko/20030728 Mozilla Firebird/0.6.1"
#USERAGENT="Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.4) Gecko/20030703"
#USERAGENT="Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.4) Gecko/20030827 Debian/1.4-3"
#USERAGENT="Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.4) Gecko/20030908 Debian/1.4-4"
#USERAGENT="Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.4) Gecko/20030908 Galeon/1.3.9"
#USERAGENT="Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20030701"
#USERAGENT="Mozilla/5.0 (compatible; Konqueror/3.0; i686 Linux; 20021224)"
#USERAGENT="Mozilla/5.0 (compatible; Konqueror/3.1; Linux 2.4.22; X11; i686; fr)"
#USERAGENT="Mozilla/5.0 Galeon/1.2.5 (X11; Linux i686; U;) Gecko/20020623 Debian/1.2.5-0.woody.1"

if [ "$USERAGENT"x == x ]; then echo "Erreur: Vous devez choisir un USERAGENT." >&2; exit 1; fi


while true; do
echo `date`" - On commence..."
sites=`wget -o /dev/null -O - "http://w3blacklist.tuxfamily.org/list.php?lang=fr(...)" | grep "\[http://" | sed "s/.*\[http:/http:/" | sed "s/\].*//"`
for url in $sites; do
echo `date`" + site: $url"
lynx -nopause -connect_timeout=30 -accept_all_cookies -source -useragent="$USERAGENT" "$url" > /dev/null 2>&1 | grep -v L_y_n_x
done
dodo=`awk 'BEGIN { srand(); print int(rand()*24*60*60) }'`
echo `date`" - Fini pour cette fois, on recommence dans $dodo secondes!"
sleep $dodo
done


(désolé, l'indentation passe pas...)
PS: N'oubliez pas de virer le (...) dans l'url du wget.

J'eu posté ca un jour:

http://linuxfr.org/comments/260104.html(...)

(Pensez dans le script à enlenver le (...) de l'url pour que ca marche).

Si quelqu'un peut faire un divx...

Non.

Les cartes PCI avec un CPU x86 dessus pour mac n'étaient pas de simple cartes processeurs, c'etaient des petits PC complet, ils embarquaient VGA, audio, et mémoire. Tout ce qui passait par le PCI etaient les acccés disques (comme tout PC passent par le bus PCI pour les disques), le clavier, la souris, et diversent connerient qui n'ont pas besoin de vitesse a ce niveau.

Aujourd'hui, la raison principale pour laquel ces cartes ne sont plus commercialisé est:
1/ commercialement, ca n'a jamais été vraiment un gros marché
2/ les processeurs sont devenu bien trop gourmand en énergie (problème d'alimentation du bus PCI limité), et la taille de leur radiateur/ventilateur devient bien trop imposante. Embarquer ca, avec le chip graphique qui a le même problème sur une seul carte PCI, ca devient un peu du délire.

Ce sont les 60GXP et 75GXP. Moi j'ai eu un 60GXP qui a tenu 6 mois, il m'a été remplacé par un 120GXP (je sais pas trop ce qu'ils valent eux).

Apparament, tu as été entendu, il y a maintenant le format sxc aussi.

Mozilla fait (faisait?) pareil, j'ai trouvé une solution, mais je sais pas si ca marche avec firebird: Tu fais un "Work Offline" avant (via le menu File de mozilla, ou le petit icon en bas a droite des 2 prises branchés ensemble).

Ouaip, j'ai vu des température de 60° sur le disque dur. Déja qu'un serveur sans Raid 1 ou 5, j'ai du mal a l'imaginer, mais alors en plus avec le disque a cette température, c'est carrement suicidaire. Alors il y a la solution de backuper régulièrement, etc. Mais bon, en général, quand on prends une machine dédidé, c'est qu'on va avoir pas mal de donnés mouvantes, et pas un bête serveur web statique.

J'ai entendu dire que les Kodak GOLD sont réputés très fiable.
Mais un truc qui est quand même très important, c'est la qualité du graveur.

Personnelement, je l'ai vu passer la barre des 10000 hier soir je crois, puis ce matin, il est passé a 7000 et des poussierres, puis, 3 ou 4 minutes après a 8700 je crois, et maintenant, je vois que c'est a 178, alors que bituur_esztreym dit qu'il vient de signer le 179eme ...

Mouais, apparament, selon mes recherches, le virus se propage par le carnet d'adresse, mais il cherche aussi dans le disque dur tout les fichiers qui peuvent contenir un email, donc, très probablement toute les pages qui ce trouve en cache de IE. Dans tout les cas, il falsifie l'adresse e-mail de l'expéditeur. Donc, envoyer un email a l'expediteur ne sert définitivement a rien.

A mon avis, tu te prends la tête pour rien...
Je n'ai jamais trop cherché de docs sur ce virus, mais il apparait évident que:

1/ Il ne se base pas sur le carnet d'adresse, mais peut être sur des adresses alétoirement trouvé sur le web? je ne sais pas, mais il est évident que personelement, je ne reçoit ce virus que dans mes boites a spam, et uniquement de gens que je ne connais pas.

2/ Il utilise une adresse expediteur qui n'a rien a voir avec l'expediteur réellement (il doit prendre au hazard dans la même liste que le 1/). La preuve en est que j'ai reçu déja quelques mails de retour pour me dire que j'avais envoyé un mail avec un virus. Alors que je n'ai 1/ pas de windows, 2/ jamais envoyé ce mail.

En bref, ton adresse est utilisé a ton insu par ce virus, aussi bien pour envoyer que pour recevoir. Envoyer un mail a l'expediteur, qui n'est pas le vrai expediteur ne sert a RIEN, vu que c'est n'es pas le vrai expediteur.

c'est de l'ipv6
::::1 est l'équivalent de 127.0.0.1 pour l'ipv4

host_accept_relay = 127.0.0.1:192.168.0.2

le &> permet de rediriger a la fois stdout (sortie standard) et stderr (sortie erreurs), et non seulement stdout.
Pour la complétion, je suppose que bash bufferise sont entrée standard (stdin), et n'execute ce que tu as tapé qu'au retour chariot.

Pour résoudre le problème du prompt pas affiché au bon endroit (et d'autres problèmes d'ailleurs):

bash -i < fifo1 &> fifo2

Version 2 :)
Il va chercher directement les sites sur w3blacklist.tuxfamily.org :)

#!/bin/bash

USERAGENT="Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030714 Debian/1.4-2"

sites=`wget -o /dev/null -O - "http://w3blacklist.tuxfamily.org/list.php?lang=fr(...)" | grep "\[http://" | sed "s/.*\[http:/http:/" | sed "s/\].*//"`

while true; do
for url in $sites; do
lynx -source -useragent="$USERAGENT" "$url" > /dev/null
done
sleep `awk 'BEGIN { srand(); print int(rand()*24*60*60) }'`
done

Oui, je suis très nul en expressions régulières aussi, mais... ca marche ;)