khivapia a écrit 2562 commentaires

À savoir qu'à la Banque Postale, que ce soit une révocation de mandat ou une opposition c'est payant et c'est 12€80 (de mémoire). C'est bien précisé sur le guide tarifaire des opérations de compte.

En espérant que les autres banques ne suivent pas...

Si je ne me trompe pas, un CD audio n'est pas montable : il ne contient pas un système de fichiers, juste des pistes, au contraire d'un CD de données. On peut lire un CD audio avec les applications de type "lecteur CD audio", ou les applications lecteurs multimédia. On peut encoder les pistes avec un encodeur.

Sous KDE, tu peux utiliser le kpart audiocd:/ (à taper dans la barre d'adresse) qui extraira les pistes musicales et les convertira à la volée en fichiers (wav, MP3, Ogg Vorbis au choix).

ses routines ont facilite la tache des craqueurs

quelqu'un pourrait-il expliquer en quoi ? J'ai regardé un peu la discussion sur le forum, mais là je sèche.

Merci

Je n'ai pas compris comment fixer mon architecture
La configuration du noyau permet comme dit plus haut de spécifier la bonne architecture pour laquelle le noyau sera compilé. Si tu veux jouer avec, c'est dans arch/x86/Makefile_32.cpu
Mais bon, c'est rare qu'on en ait besoin en plus vu les différentes architectures déjà prévues dans la config du noyau. Personnellement, je ne m'en suis servi qu'une seule fois, pour un processeur AMD geode dont le support est tout neuf dans gcc-4.3.

tu as bien raison ! les kalachnikov sont en majorité contrefaites [1], c'est comme la musique ce serait un scandale que tous les foyers français y aient accès si facilement. Heureusement que C Albanel veille à ce que les foyers français n'aient pas accès à ce genre de contenu d'une manière qui enfreint les droits de propriété intellectuelle.

[1] http://www.bladi.net/forum/64599-90-kalachnikov-vendues-mond(...) (par exemple)


-------> [] je suis déjà loin loin loin

ben c'est simple, on fera comme aux USA, on obligera à utiliser windows ;-)

http://www.clubic.com/actualite-78765-pirate-condamne-utilis(...) (par exemple)

non, sans rire, il doit y avoir un certain principe de "neutralité" de l'État vis-à-vis des entreprises (qui empêche par exemple un professeur de maths de donner son avis sur telle ou telle calculatrice (par exemple casio vs TI) à ses élèves).
Donc si un décret oblige à n'utiliser qu'une solution tournant sous XP comme seule possibilité de prouver sa bonne foi, ça devrait être attaquable devant le conseil d'État sans trop de difficultés. Après, il faut encore avoir les moyens de le faire...

Lorsque tu déménage, tu fais valoir que tu n'as JAMAIS signé d'autorisation => ils sont donc obligé de te rembourser :]

Attention, tu es quand même censé avoir vu les prélèvements se faire. De mémoire, on a trois mois pour faire opposition sur un prélèvement frauduleux.

Sinon, pour éviter la lettre recommandée avec accusé de réception (important ça), on peut aussi remettre la lettre au guichet contre signature. (dans une enveloppe fermée histoire qu'il ne l'ouvre pas avant d'avoir signé :-)

Et avant de menacer de changer de banque, surtout, leur demander d'écrire noir sur blanc qu'ils refusent la suppression de l'autorisation. En général, ça les fait réfléchir. S'ils refusent (ce qui est probable), venir avec un témoin en leur précisant pourquoi, ça fait réfléchir aussi.

En plus avec shred c'est du 55 à 60 Mo/s sur ma modeste machine, ce qui est le maxim (à 20% d'un coeur). C'est LA méthode pour ce cas.

Là ça m'intéresse, c'est quoi ta source d'aléas ?
man shred parle de l'option --random-source , qui comme son nom l'indique permet de spécifier la source d'aléas à utiliser, par défaut (sous debian) c'est /dev/urandom.

Sinon shred ne fait par défaut pas que des passes avec de l'aléas, comme l'indique shred -v nom_fichier

Ok merci. Je ne pensais pas que ce genre de mesure était fiable :)

Sinon je confirme pour les compteurs d'eau, l'eau chaude est mesurée individuellement, et l'eau froide peut être calculée au prorata de la surface.

Petite question, c'est quoi exactement un compteur de chaleur ?

Merci.

tiens le wiki de gentoo est down, mais le cache google est notre ami :
http://74.125.39.104/search?q=cache:_un-TdGlA4oJ:gentoo-wiki(...)

chercher la chaîne de caractères "random looking data".

Voilà la commande à taper :

head -c 15 /dev/random | uuencode -m - | head -n 2 | tail -n 1 | losetup -p 0 -e AES128 /dev/loop3 /dev/hda
dd if=/dev/zero of=/dev/loop3 bs=4k conv=notrunc 2>/dev/null # This can take a while
losetup -d /dev/loop3

En gros :
head | | crée une clef AES
losetup ... -e AES128 ... /dev/hda crée un device loopback chiffré AES par-dessus le disque dur hda
puis on remplit le loopback device avec zero, les données écrites sont automagiquement chiffrées en AES, et pas par le mode ECB (voir https://secure.wikimedia.org/wikipedia/en/wiki/Block_cipher_(...) ) donc c'est bon.
puis on défait le loopback device et c'est bon.

Après c'est sûr que personne n'ira chercher à récupérer les données du disque d'un particulier, mais la méthode est utile à connaître au cas où. Nombreuses sont les entreprises qui ne font pas attention à détruire leurs disques avant de s'en débarrasser, et souvent un disque contient plus d'info de valeur qu'on ne croit.

Ben fais l'essai au lieu de moinsser, c'est pas très compliqué à vérifier. Je te retrouve le lien dès que possible. C'est LA méthode recommandée pour remplir une partition de données aléatoires le plus vite possible.

Commandes pour créer une partition : 2 minutes à partir d'un tutoriel si on donne le lien, Sinon mettons deux heures pour le trouver et l'exécuter (je compte large).
Vitesse d'écriture :
(sur ma config normale, partition chiffrée)
dd if=/dev/zero of=./tempfile bs=10M
157286400 bytes (157 MB) copied, 8,86431 s, 17,7 MB/s

alors qu'avec urandom tu obtiens pas beaucoup plus que 5 MB/s (et encore avec une très bonne config. Ici, P4 HT 3GHz j'ai 2.5 MB/s, Pentium-M 1.60GHZ 1.5 MB/s).

Résultat : pour un disque de 80GB :
avec la méthode partition chiffrée : 1h 20 de remplissage, 2h de tutoriel = 3 heures 20 minutes
avec urandom : 4h35.

Pour un disque de 200GB : 5h25 vs 11h25.

Pour un disque de 1TB... Non je m'arrête là je pense que c'est clair :)

Sinon pour répondre au post du forum, badblocks fait appel à la fonction C random() qui n'est pas cryptographiquement sécurisée (le générateur pseudo-aléatoire fourni est hautement prédictible. Il est bon pour des simulations, pas pour faire de la sécurité) - c'est-à-dire qu'il y a peu de différences avec utiliser /dev/zero directement.

mais c'est très lent quand même. La solution préconisée sur le wiki de gentoo est de créer une partition chiffrée sur le disque, puis de la remplir de zéros (qui seront chiffrés avant écriture sur le disque). Le chiffrement est plus rapide que l'obtention de pseudo-aléas par /dev/urandom, et un bon algorithme de chiffrement paraît aléatoire (sinon on a un distingueur et le chiffrement n'est plus considéré comme sûr).
Après pour plus de paranoïa, on peut faire ça plusieurs fois avec des clefs différentes, ajouter un peu d'aléas de temps en temps histoire de modifier les données chiffrées, etc. etc.

C'est une citation de Nietzsche.

caler la journée sur 4h-20h
C'est déjà le cas au Japon il me semble. Enfin, ils se lèvent beaucoup plus tôt qu'en Europe, et se couchent pas beaucoup plus tard que le soleil.

cela me semble compliqué pour quelques euros :(
c'est d'ailleurs là-dessus que se basent un certain nombre de business-models... Quelques euros/quelques clauses abusives fois quelque millions d'utilisateurs = beaucoup d'argent !

Ok merci beaucoup ça marche :)
pour indexation si d'autres ont le problème, voici les modules chargés :
kernel 2.6.26
rt73usb
rt2x00usb
et leur dépendances.

lsusb doit retourner quelque chose comme ça (l'important est l'ID)
Bus 001 Device 002: ID 18e8:6238 Qcom

PC : fit-pc slim, geode LX800, chipset ralink RT2571W

ok merci je vais essayer ça ! lsusb ne me liste que les hubs (Bus 001 et 002).

je crois que pour le moment, il n'y a que le padlock de Via et l'AMD Geode qui en possèdent un (en tous cas ce sont les seuls qui apparaissent dans la config du noyau Linux), sans compter les modules cryptographiques type carte PCI/USB. Ensuite, c'est vrai que c'est pas comme si ça coûtait très cher à produire, la moindre carte à puce en contient un, et elle coûte quelques centimes d'euros à l'achat en masse...

lshw ne m'a rien donné à ce sujet en effet, et il n'y a pas de fichier dans /dev/ avant l'insertion du module.
En général la présence du générateur matériel est quelque chose sur lequel les fabricants/revendeurs font de la pub, c'est comme ça que je l'ai su,

merci de ta réponse, aurais-tu une idée concernant mon problème alors ? je pensais à /etc/network/interfaces mais quoi que j'y mette concernant rausb0 ou autres l'interface n'apparaît pas... Impossible ne serait-ce que de scanner les points d'accès à proximité ! Ce n'est pas que j'en aie un grand besoin pour le moment, mais ça me permettrait de savoir si tout le matériel fonctionne au besoin.

en te remerciant

-O3 et les divers paramètres sont fournis par défaut dans nbench. Étant donné que tous sont des x86, ça a déjà une influence plus faible :)
Sinon c'est bien le problème de tous les benchmarks, on ne compare pas seulement les processeurs mais aussi le compilateur, la libc, le noyau etc. etc. Mais ça permet de se faire une (petite) idée... Sinon j'avais plutôt fait les bench pour voir l'influence des options de compilation sur la performance du code, pour déterminer quelle était la meilleure combinaison.
Il faudrait refaire le bench sur d'autres architectures, dans les mêmes conditions (même version du compilateur, mes noyaux & libc), pour pouvoir comparer un peu plus finement. Ce n'est pas très long, il suffit de télécharger le tar.gz, de modifier (le Makefile avec les options désirées, et

Salut,

tout d'abord ce comparatif n'est pas complet :) je ne me suis absolument pas intéressé aux performances graphiques par exemple...

Pour répondre à tes questions, de ce que j'ai compris sur internet le fit-pc ne consomme que 5W tout compris (et même si je n'ai pas d'ampère-mètre ça m'a l'air plutôt vrai) là où les solutions à base d'Atom consomment plutôt au minimum 20W voire 35 (le processeur tout seul consommant 5W, ajouter chipset, puce graphique etc (qui sont intégrés dans le cas du geode), etc. etc. ).
Après, je pense qu'entre un geode de 2005 cadencé à 500 MHz et un Atom conçu en 2007/2008 et fonctionnant à 1.6GHz, il n'y a pas de comparaison possible :) le geode est beaucoup moins performant (sauf en génération d'aléas et chiffrement AES, mais bon... ;). D'ailleurs si quelqu'un veut faire le nbench pour comparer ! (télécharger sur le lien du journal)

Après ce qui m'a fait l'acheter, c'est bien évidemment le côté totalement silencieux (si l'on excepte le disque dur, mais neuf ça va c'est plutôt tolérable ;), la consommation très faible, et le fait qu'il soit largement suffisant pour mes besoins - serveur web, fichiers, quelques applications tournant 24h/24, voire plus tard comme ordinateur de bureau quand j'en aurai vraiment marre de mon vieux portable sans autonomie. Et bien sûr, sur une petit config ça force à geeker un peu pour voir si en tunant un peu les paramètres on gagne vraiment en performances ressenties :) Je n'ai pas vraiment pensé à l'eeeBox.

D'après d'autres retours d'expérience sur internet, le geode est convenable pour à peu près tout, sauf lire des vidéos flash (étonnant, non ? encore que en désactivant l'anti-aliasing et en diminuant la résolution il paraît que ça passe) et parfois la vidéo (ne pas compter lire de la HD). Pour compiler des projets, c'est certes un peu lent, mais de mon point de vue c'est tout à fait correct tant qu'on reste en -O0, en tout cas c'est comparable aux netbooks à base de Celeron.

pour citer wikipedia, à la page http://en.wikipedia.org/wiki/Urandom random est de bien meilleure qualité que urandom et devrait être utilisé pour tout ce qui nécessite de l'aléas de qualité, à savoir la génération de clefs cryptographiques et les nonces.
Ça implique comme le dit plus haut Aefron les clefs de chiffrement temporaires de partition, mais (normalement aussi) tout ce qui est clef ssl, etc. Après, ça dépend des données à protéger, mais ça ne peut qu'améliorer la sécurité (et parfois on trouve des problèmes, qui ne sont certes pas à la portée de tout le monde, mais qui rappellent que rien n'est sûr, voir par exemple http://www.blackhat.com/presentations/bh-usa-06/BH-US-06-Gut(...) qui avait un peu étudié urandom, ou le papier complet ici http://eprint.iacr.org/2006/086.pdf ).

La partie de l'article wikipedia sur FreeBSD explique que dans le pire des cas (pas de disque dur donc très peu d'aléas interne), le pool d'entropie est quasiment sous contrôle de l'adversaire (par le réseau), ce qui n'est pas une bonne idée. On évite complètement ce problème avec un générateur matériel. Par exemple si le PC geode sert comme routeur et serveur ssh, il y a des risques !
D'une manière générale obtenir et utiliser facilement de l'aléas de bonne qualité est une meilleure chose :-) ça évite de se retrouver avec des surprises plus tard.

Pour ce qui est des partitions en effet ça ne sera pas très rapide :) mieux vaut alors utiliser urandom (qui est lui-même bien lent pour tout un disqueà ou bien, mieux, un chiffrement de flot dont on réinitialise la clef (avec random) régulièrement.

Enfin un dernier avantage est que ça évite les attaques DoS par exhaustion du pool d'entropie (faites un cat /dev/random et essayez de générer une clef gpg par ailleurs, ça devrait moins bien se passer :)

tiens, j'ai reçu le mien récemment aussi, mais impossible de faire fonctionner le wi-fi sous debian. Que ce soit en chargeant le module rt73usb (avec le package firmware-ralink installé), ou bien en installant le paquet rt73-modules-`uname -r` (2.6.26-1-486) ), dmesg m'indique "usbcore: registered new interface driver rt73" (ou rt73usb) mais sans plus ! pas d'autre interface que l'interface réseau eth0, à fil (je ne compte pas lo).

Aurais-tu une idée ? je pensais peut-être à une désactivation dans le BIOS, mais je n'ai pas d'écran pour vérifier...