TheBreton a écrit 932 commentaires

Et surtout quelqu'un comme moi qui donne des avis sur le net ;-)
Les distributions linux grand publique sont par défaut très permissive.
Pour te rassurer l'article en question montre surtout le danger de laisser une session ouverte car en branchant une clef qui va simuler un clavier et la frappe de tout un ensemble de commande ou raccourci.
Déja, si tu est en login utilisateur, seule tes données personnelles sont en danger (mais tout le monde fais souvent des sauvegardes régulière n'est ce pas) ?

Si effectivement on veut neutraliser ce genre d'attaque il suffit d'écrire des règles udev voir ici
pour n'autoriser que ton clavier sur l'usb par exemple (faut penser à mettre la souris aussi peut être), on peut affiner les régles udev pour n'autoriser que le numéro de série que d'un clavier précis et sont branchement sur un port usb précis du système.
En rajoutant une règle qui verrouille automatique le poste en cas de débranchement du clavier.
Donc la sécurité serait renforcé au niveau ou l'attaquant devrais éteindre le PC et partir avec le disque dur.

Voici la page en détail expliquant le processus

http://kernelnewbies.org/UpstreamMerge

En version (fr) résumée, toutes les modifications faites par Ubuntu pour le support des différents composants matériel du PC sont disponible pour tout le monde à l'avenir dans le kernel (et pas gardées dans son coin par Ubuntu/Dell).

Remets ta ligne qui ne fonctionne pas dans les règles et ensuite, suivant la version du package udev installé, utilise "udevtest" ou bien encore "udevadm test", je te laisse voir la doc. de ces outils qui te sortiront plein de ligne permettant de debbuger les règles udev.
Ensuite poste le résultat ici pour que l'on puisse de donner d'autres pistes.

Rien ne dit que les logiciels nécessaires soit installés sur cette machine virtuelle.
Pour identifier un linux il faut utiliser la commande "uname -a" et quand on est en mode console on utilise la commande "startx" pour lancer un environnement graphique.
Essai et dis nous le résultat.
Par hasard, essai aussi la commande "mc" pour voir si midnight commander est installé, ou pire il te permettra de naviguer graphiquement entre tes répertoires.

Mais la version Aurore. Après avoir fais bien le tour de toute la question il me semble avoir lu à plusieurs reprise que les pc Ldlc était de bases des Clevo. peut être que directement chez le constructeur tu trouveras tes batteries ?
http://www.clevo.fr/shop/accessoires/batteries.html
Quand au "pack extension de garantie"…no comment, je ne prend jamais ce genre d'option qui ne sert qu'as gonflé la note finale au profit du vendeur uniquement.

"Do not try to put OpenBIOS in a real boot ROM, it will not work and may damage your hardware! " et "OpenBIOS can be used directly as a boot ROM for QEMU system emulators for PPC, PPC64, Sparc32 and Sparc64. "

Tout est dit, il ne faut pas espérer booter ton PC avec ce bios.

ne pas mettre à jour une page est un non-acte
La loi française punie aussi l'absence d'action
Légifrance Art. 223-6 lien
Quiconque pouvant empêcher par son action immédiate, sans risque pour lui ou pour les tiers, soit un crime, soit un délit contre l'intégrité corporelle de la personne s'abstient volontairement de le faire est puni de cinq ans d'emprisonnement et de 75 000 euros d'amende.

Je ne connais pas la loi américaine, mais ne pas empêcher quelque chose de se produire et risquant d'induire un risque pour l'état (de leur point de vue) doit être assimilable à une action volontaire mettant en danger l'état.

Si ton PC est récent et dispose d'une interface SATA2 à 6Gb tu trouvera une vrai différence entre le disque dur et le SSD.
Mais si tu est en SATA à 1.5Gb (vieil ordi) un disque dur récent à 7200trs aura des débit similaires à un SSD qui moulinerai plus vite que ne le permet le débit ton interface.
Sur mon PC récent (SATA6Gb), le SSD est au environ de 340Mo/s en débit utile et mon disque dur (un 5200tr car j'aime le silence) est à 110Mo/s.

D'abord vérifier à qui appartient le répertoire par un 'ls -l'
Ensuite si besoin de le changer 'chmod -Ru +rw nomdurepertoire'

Cela ou bien l'utilisateur n'as pas les droits d'accès complet sur l'arborescence que tu as copié

Ce que je ferais c'est regarder ce que vaut la variable
LD_LIBRARY_PATH
peut être faire un coup de 'ldconfig -p' ,jeter un coup d'oeil sur '/etc/ld.so.conf'
en root faire un 'ldconfig' ou un 'ldconfig -v'
regarder les droit d'acces sur le fichier en question 'ls -l' des fois qu'il soit réserver à 'root'

Dur de connaitre tout les PC en vente…
Mais d'après ce que je crois savoir, MicroSoft IMPOSE à tout fabricant de PC-ARM vendu avec Windows8-RT que le SecureBoot soit présent, activé et NON désactivable.
A contrario sur x86 Secure boot doit être présent mais le constructeur doit laisser l'option de le désactivé.

voici un article qui résume la situation

Normalement Optimus fonctionne depuis peut sous linux
voir ici

Ce n'est pas UFI mais EFI
Marrant pour moi c'est un mixe des deux,les bios sont UEFI (Unified Extensible Firmware Interface ), l'EFI c'est la premier mouture utilisé avec les Itanium.

Ce dont il faut se méfier c'est, si le portable acheter est pré-équipé de Windows , il faut vérifier que l'option SecureBoot soit bien désactivable.

Voila la référence d'un processeur core 4 bits UPD17207GF avec lequel j'ai travaillé.
A l'époque on utilisait le terme "quartet" pour désigner le groupe de 4 bit et j'ai toujours utiliser "byte" pour 8 bits.

Cela me fais penser qu'il existe une plateforme sur une base libre (Arduino) qui dispose d'un module sur lequel tu peut développer et télécharger ton soft, qui dispose d'une liaison Zigbee et d'une entrée analogique et d'une sortie tout ou rien (collecteur ouvert 100mA). Cela tourne sur une batterie ou peut s'alimenter par une prise mini usb.
Voici le concept en vidéo http://vimeo.com/59998795
Reste à savoir si cela à été commercialisé l'auteur

udev gère aussi les UUID et comme chaque partition de disk dispose d'un UUID a lui tu devrais ne pas avoir de soucis

Il ne sera pas reconnu car ce n'est pas standard.
Par contre les utilitaires fdread et autre devrait fonctionner sous freedos comme cela marchait sous dos.
Puisque les jeux pour dos arrive a fonctionner, je pense que fdread devrait le faire.

Pour démarrer Freedos depuis une clef usb utilise rufus qui l'inclus d'origine.

+1 Pour Freedos, par contre je te conseille fortement de ne pas perdre trop de temps à faire marché fdread avec un lecteur usb si ca marche pas du premier coup. Il faut certainement un vrai controleur de floppy sur la carte mere et branché en IDE.

Je te conseille de faire une passe avec Testdisk puis photorec sur ton disque dur, pour voir ce qu'ils peuvent faire comme recupération.
Normalement certaine information sont dupliqué sur le disque et des fois on peut les récupérer (avec TestDisk) et sinon retrouver les fichiers avec PhotoRec.
Voici un petit tuto

Sur les risques encourus à jouer avec l’électricité près de l'aquarium.
Je ne connais pas se milieux mais je suis presque certains que c'est des circuits d'alimentation basse tension (tbts) et avec double isolation qu'il faut utiliser.
Voila pour la partie avertissement, maintenant pour la technique, ton écran "surveille" qu'il reçoit des informations vidéo de la carte graphique pour décider (ou non) de passer en veille. Il faut donc générer un signal vidéo valide au minimum (avec un petit montage à base de fpga par exemple voir la )pour qu'il continu de fonctionner.
A voir la tolérance qu'il aurait à fonctionner avec un simple montage oscillant à une fréquence de 50Hz générant des petits pulses (par exemple en se synchronisant sur le secteur).

Voir ma réponse dans l'autre thread…

C'est linux donc tu as les sources du driver/module en question non ?

En lisant les sources du module I2C il faut chercher la déclaration de la structure file_operations c'est elle qui fait le mapping entre les opérations de fichiers en userland et les fonctions dédié du module
Exemple :

struct file_operations my_fops = {
 llseek:  my_llseek,
 read:  my_read,
 write:  my_write,
 ioctl:  my_ioctl,
 open:  my_open,
 release: my_release,
};

Et mes fonctions

ssize_t my_read (struct file *, char *, size_t, loff_t *);

etc…

PS : Zut pas j'ai cliqué au bon endroit…

Mais il y a une chose de sur, la frontière User/Kernel est inviolable sous linux et tous les échanges User/Kernel doivent se faire par ioctl,open,read,write,select.

Après tous les modules kernel sont dans le même espace, mais chacun n'exporte (ne rend public) que ce qu'il veut bien comme fonction ou variable (voir la doc à propos de EXPORT_SYMBOL() ) .

Donc si deux module doivent inter agir par des fonctions, elles doivent être déclarer public pour que ce soit possible.

Laisse tourner plus longtemps memtest (toute la nuit par exemple) pour voir si sur la durée des erreurs n'apparaisse pas.