Olivier a écrit 889 commentaires

J'ai vu divers reportages sur Tchernobyl, dont notamment un qui montrait des hirondelles dont les deux ailes n'avaient pas les mêmes dimensions.

Même si elles arrivaient à voler malgré cette différence, leurs performances de vol étaient moins bonnes que celles des individus aux ailes symétriques. Moins efficace en vol, les animaux s'alimentaient donc moins, et donc mourraient plus rapidement (la sous-alimentation, dans la nature c'est rarement bénéfique !).

Ces mécanismes certes existent, mais lorsque que le niveaux "d'agressions" externe est trop important, ils s'avèrent inefficaces et ne peuvent plus réparer les brins d'ADN altérés. La cellule finit alors par mourir (perte de toutes les données), ou mutent (altération définitive des données).

Dans le cas de mutations, soient elles peuvent être bénéfiques (évolution pour une meilleur adaptation à l'environnement), ou néfastes (cellules cancéreuses).

Sachant que l'ADN peut être modifié par des perturbations environnementales, comme la radioactivité, je ne suis pas sûr que la fiabilité à long terme soit garantie. Les organismes soumis aux radiations de Tchernobyl en sont la preuve (mutations, dégénérescences, …).

Ou alors, il va falloir mettre en place de sacrés mécanismes de validation et de correction d'erreurs !

Et puis la raison officielle, ce sera que si on enlève l'étiquette, les licences Windows seront piratées et pas payées.

Raison d'ailleurs qui peut-être complètement fallacieuse, même si l'utilisateur réinstalle un Windows après s'est fait remboursé sa licence.
En effet, un utilisateur peut tout à fait légalement installer:
- Un Windows en version "boîte", qu'il passe d'un ordinateur à un autre, mais en prenant bien soin de le désinstaller/reformater de la précédente machine avant de l'installer sur la nouvelle
- Certaines entreprises/école/fac/autre, ont des accords avec MS, qui permettent à leurs membres d'acheter à moindre coût des licences de Windows, qui ne sont pas associées à un hardware spécifique (comme c'est le cas pour les licences OEM)
- Et évidement, l'utilisateur peut installer n'importe quel autre OS sur sa machine, qu'il soit libre ou non.

Bonsoir,
l'année dernière j'ai suivit la même procédure que toi pour un remboursement de licences auprès d'asus.
Le sèche cheveux marche très bien, en décollant au fur et à mesure l'étiquette avec un cutter.

Attention cependant : Sur la machine en question, l'étiquette Windows était protégée par une grosse étiquette transparente installée par asus, afin de protéger l'étiquette Windows. Il fallait la retirer au préalable, ce qui se faisait très facilement avec un cutter.

Merci à tout les deux pour vos réponses, je vais déjà voir ce que l'on peut faire avec ces outils.

Bonjour,
sous Linux, est-ce qu'il y existe des moyens de surveillance quand à l'autorité de certification qui est utilisé pour valider tel ou tel site ? L'idée étant de vérifier que lorsque qu'une application demander à vérifier un certificat, l'on puisse savoir quelle CA a été utilisé.

En effet, si c'est un ".gouv." quelconque qui signe un certificat de type google (ou LinuxFr !), on peut avoir quelques doutes…

L'idée serait d'avoir une telle vérification sous forme d'un fichier de log, un peu plus pratique que la consultation des informations de sécurité qui apparaissent dans les navigateurs

Enfin, comment savoir si l'autorité de certification utilisé vient d'une liste intégré au navigateur (firefox, chrome, …) ou du système (sous Linux, des centaines de CA apparaissent dans /usr/share/ca-certificates/ /etc/ssl/certs/ ).

Bonjour,

ce n'est pas que la chauffe d'un CPU qui peut être la cause de reboot inexpliqué.
Parfois, ce soit les barrettes de mémoire vive qui sont instables avec la température (il faut alors les changer). D'autres fois, la carte mère qui pose problème (par exemple, un chipset défectueux, des transistors chimiques qui viellissent, un couplage entre des lignes de bus, …), et là aussi, un changement/réparation de carte mère s'avère nécessaire.

Tu peux commencer à faire un test de mémoire avec "memtest" ou "memtest+" : Quelques heures de tests avec un boîtier fermé (histoire de reproduire les conditions de prod). Si la machine reboote, commence par changer/swaper les barrettes de ram. Si le problème persiste, il est probable que cela vienne de la carte mère.

Tu parles aussi d'un système embarqué : Les autres périphériques qui sont attachés à ce système peuvent aussi être la cause des plantages. Tu peux donc réduire le champ des recherches en les déconnectant temporairement.

https://www.google.fr/#q=wget+gui+linux

J'ai déjà utilisé le système d'accès au disque dur en mode "raw", afin d'améliorer les performances : cela évite de passer par différentes accès logiciels ntfs->vdi->ext4->disque physique.

Par contre, le booter le système tel qu'indiqué doit faire que le Windows 7 a l'impression de changer de hardware à chaque voit que l'on switch de virtualisation à mode réel. Je me demande ce qu'en dit le mécanisme d'activation / protection contre le piratage.

Sinon, en terme de virtualisation il y a aussi Xen à la place de VirtualBox. Mais pour le tester actuellement, je trouve que ce n'est pas super simple ! :)

• Est-ce que le problème ne vient pas du RPC ? A voir si portmap ou rpcbind fonctionne correctement des deux coté
• Est-ce que tu n'as pas un filtrage via les /etc/hosts.allow et /etc/hosts.deny ?

Enfin, si tu ne trouves rien, lance un sniffer de trame (wireshark/tcpdump), afin de regarder le trafic. Cela permettra de voir si la connexion se ferme dès la communication RPC (TCP/111) ou NFS (UDP/2048 ?)

Il y a quelques années, j'ai eu un problème similaire avec l'hibernation d'un Windows XP Pro + NTFS et une Debian en dual boot.

Afin de sécuriser tout cela, la solution est de ne monter par défaut la partition NTFS qu'en "ro" / read-only (via le paramètre "ro" des options du /etc/fstab), et uniquement à la main. Quand à hiberner le Linux, il faut auparavant systématiquement démonter la partition Windows (démontage manuel, ou via les scripts d'hibernation).

Bravo pour le boulot que vous faites sur Nouveau

Le travail de retro-engineering sur des drivers proprio doit être quelque chose de très complexe, et cela m'épate que l'on puisse y arriver !

Il devrait le faire. Mais ce n'est pas si évident que cela.

Sur Debian Testing/Wheezy, et suite à des mises à jour, j'ai remarqué un temps de mise en hibernation plus long qu'à l'accoutumé (et ce, même après un reboot de la machine). Depuis que j'ai rajouté un script qui fait opérations, j'ai retrouvé un temps de mise en hibernation qui soit rapide.

il purge d'abord les caches afin d'atteindre une certaine taille définie dans le fichier /sys/power/image_size

Personnellement, je purge complètement les caches d'écriture ("sync") et de lecture ("echo 3 > /proc/sys/vm/drop_caches") lors de l'hibernation

Ainsi, je libère toute la ram "cache" d'un coup, et ne sauve sur le disque que la ram réellement utile (programmes + données).

La commande "free" lancée avant et après la purge permet de savoir combien l'on a économisé.

• Dans tes options de montages de partitions (/etc/fstab), tu devrais rajouter: noatime,nodiratime

Par défaut, lorsque Linux LIT (je dis bien lit) un fichier, il modifie l'information "last_access_time" dans le système de fichier. Ce type de comportement ne sert pas à grand chose (notes quand même que c'est du POSIX), si ce n'est dans les serveurs de type newsgroups. Par contre, il est évidement que si ta machine lit des données (par exemple si c'est un serveur web), alors il y aura modification du système de fichiers

• J'ai aussi l'option: async

qui permet par défaut de rendre les accès disques asychrones

Ainsi, les lignes de mon /etc/fstab ressemble à cela:
UUID=xxxx /home ext4 defaults,async,commit=60,noatime,nodiratime 0 0

Cependant, je pense qu'il y a un problème plus spécifique à ta machine. D'après tes logs, ils ont tous lieux à la même seconde : "[413654.". Ce qui sous-entend BEAUCOUP d'écritures. Ou alors, c'est que lorsque tu as regardé ces logs, tu avais généré beaucoup d'accès en même temps.

Aussi, je pense qu'il faut que tu fasses ceci:
- Arrêtes au fur et à mesure tout les programmes et démon de ta machine, en commençant par l'environnement X:
- pour cela : Ctrl+alt+f1
- /etc/init.d/[mettre ici kdm, gdm, gdm3, etc… suivant ce que tu utilises]
- puis tu jongles progressivement avec du "ps -edf" pour voir la liste des programmes en mémoire, "dmesg" pour étudier les écritures, et /etc/init.d/xxxx pour arrêter les programmes (commencent par ceux qui ont le PID le plus élevé). Au final, tu devrais finir par trouver le ou les programmes qui forcent à faire des écriture sur le disque.

Pour limiter les accès, j'ai aussi ceci :

# Regroupe les opération de lectures/écritures, afin d'économiser les batteries
# La valeur est un nombre de secondes, avant que l'écriture soit effective
LAPTOP_MODE=5            ; # "5" -> Attend 5s pour regrouper les opérations d'écritures
echo "$LAPTOP_MODE" > /proc/sys/vm/laptop_mode

# Pourcentage de pages mémoires occupées pour les données en attente d'écriture qu'il faut atteindre, avant de forcer l'écriture des données sur le DD
# La valeur est un pourcentage
DIRTY_RATIO=80           ; # Pourcentage, utiliser une valeur assez elevée
echo $DIRTY_RATIO > /proc/sys/vm/dirty_ratio

# Pourcentage de pages mémoires occupées pour les données en attente d'écriture que le système N'écrit PAS sur le disque, après une opération de "write". Cela permet de ne pas écrire tout d'un coup. Une valeur faible est préferable
# La valeur est un pourcentage
DIRTY_BACKGROUND_RATIO=5 ; # Pourcentage, utiliser une valeur faible
echo $DIRTY_BACKGROUND_RATIO > /proc/sys/vm/dirty_background_ratio

# Taille de fichier que le kernel va lire d'un coup, lors de l'accès en LECTURE à un fichier.
# Pour faire simple, si un fichier fait une taille inferieur ou égale à READAHEAD, alors le fichier sera lit d'un seul morceau. Si le programme qui lit ce fichier le lit séquentiellement, il n'y aura qu'une seule lecture
# La taille est en mega-octet
READAHEAD=32           ; # Lit les fichiers par blocs de 16Mo
# Liste de periphériques sur lequels cette option va se pratique
#READAHEAD_DEV="/dev/hda /dev/hdc" ; # Modifie les paramètres sur les DD hda et hdc

READAHEAD_DEV="`/sbin/fdisk -l 2>/dev/null|sed -e '/^\/dev/!d' -e 's/^\([^ ]\+\) .*/\1/g' -e 's/[0-9]\+$//g'|sort -u`"
for DEV in $READAHEAD_DEV; do 
  blockdev --setra $(($READAHEAD * 2048)) $DEV
#  blockdev --getra $DEV
done

Et les deux options que tu as déjà donné :

# Cache en ecriture. Le système attendra un certain nombre de centième de secondes avant de procéder à l'écriture des blocs sur le DD.
# Ce delai sera bien sûr fonction de la quantité de mémoire vive disponible pour le cache disque
# La valeur est ici est en secondes
AGE=600                  ; # Attend 600 secondes (10 minutes) avant d'écrire des données sur les DD
echo "$((AGE * 100))" > /proc/sys/vm/dirty_writeback_centisecs
echo "$((AGE * 100))" > /proc/sys/vm/dirty_expire_centisecs

Sinon, bonne idée que ton "service syslog stop" dans ton précédent message ! :)

Au passage, vu que tu archives tes données dans un zip/tgz/autre, tu peux en profiter pour le chiffrer en GPG.

Ainsi, personne (ni sur la connexion, ni chez Dedibox), ne pourra avoir accès au contenu du fichier…

Quel retour d'expérience vous avez avec les systèmes graphiques hybrides, intel + nvidia ? Ca marche sous linux (pour de vrai) ?

J'ai acheté pour mon père un portable ASUS doté de la techno Optimus. Sur une Debian Wheezy/Testing c'est très simple à mettre en oeuvre, via un dépôt à part : http://suwako.nomanga.net/ . Sinon la page officiel Debian est ici : https://wiki.debian.org/Bumblebee#Installation

L'idée d'un double processeur vidéo est bonne (le nvidia est au repos tant que l'on ne lance pas un programme qui demande spécifiquement son activation).

Par contre, en terme de performances je dois dire que je suis déçu, ou alors je n'ai pas trouvé le bon benchmark qui prouve que le bénéfice est réel.

En fait, d'après le wiki officiel https://github.com/Bumblebee-Project/Bumblebee/wiki/FAQ , le mécanisme Linux actuel (Bumblebee, indépendant de NVIDIA) bride exprès les performances à 60fps, afin de ne pas trop solliciter le CPU. Donc pour un benchmark, c'est mort.

Enfin, il y a eu une news récemment qui prétendait que NVIDIA allait réellement faire quelque chose pour Optimus sous Linux http://www.engadget.com/2012/09/05/nvidia-linux-optimus-driver/ . Mais les avis sont partagés, et l'on peut se demander si ce n'est pas juste une annonce sans suite, histoire de calmer le jeu après https://linuxfr.org/users/patrick_g/journaux/quand-linus-enerve-linus-faire-ca

J'ai donc dus convertir mes partitions ext3 en ext4
Tu rigoles pas quand tu fais des tests toi!

Ce n'est pas non plus très compliqué. D'après https://ext4.wiki.kernel.org/index.php/Ext4_Howto#Converting_an_ext3_filesystem_to_ext4 , il y a 2 commandes à taper pour les partitions non-système, et à remplacer le ext3 par ext4 dans le /etc/fstab.
Pour la partition système, j'ai rebooté la machine sur un distribution live afin de lancer les commandes. Ce n'est pas le plus simple, mais cela m'a paru plus sécurisé.

En fait, le temps de la conversion se résume grosso-modo à celui de faire un e2fsck .

L'effet collatéral est que je ne peux plus monter mes partitions qu'en ext4 . Mais ce n'est pas un problème, puisque toutes les distributions majeurs ou en live le supporte par défaut.

Et même un peu plus que le démarrage, car il est possible d'y faire rentrer une ou deux applications utilisée fréquemment (browser, éditeur,..) ce qui n'est pas négligeable, surtout sur les petites machines.

Oui, tout à fait, il suffit lancer ces applis lorsque le "e4rat-collect" fonctionne.

Je ne connaissais pas e4rat, et je n'ai pas installé systemd pour faire de benchmark. Cependant, ce e4rat a piqué ma curiosité, aussi je l'ai testé et en voici le retour:

• Site web : http://e4rat.sourceforge.net/
• pré-requis :
  • dans mon cas, il faut télécharger le paquet Debian proposé par le site http://sourceforge.net/projects/e4rat/files/0.2.3/ , car e4rat n'est pas disponible en Debian/Testing
  • e4rat ne fonctionne que sur les partitions ext4. J'ai donc dus convertir mes partitions ext3 en ext4 : https://ext4.wiki.kernel.org/index.php/Ext4_Howto#Converting_an_ext3_filesystem_to_ext4
  • Une procédure d'utilisation : https://wiki.archlinux.org/index.php/E4rat#Getting_it_to_work
• Test
  • Machine de test : Desktop Core2 Quad @2.4Ghz / 4Go ram / disque 500Go / Debian Testing (à jour) / Environnement KDE4 + autologin
  • Temps de boot (pris entre le menu de sélection de grub jusqu'à la musique de démarrage de KDE):
  • Boot par défaut : 38s pour kdm / 1min 30s pour le boot complet
  • Boot avec e4rat : 29s pour kdm / 1min 1s pour le boot complet. Gain : 30%

Conclusions :
- pour un disque "standard/à plateaux", e4rat apport un gain indéniable en terme de temps de démarrage
- comme e4rat est basé sur la défragmentation de ext4, et sur la pré-allocation, il n'y a gère de gain à attendre pour un disque SSD
- son utilisation n'est pas transparente, dans le sens où après des mises à jours significatives de la machine, il faut repasser par les étapes "d'apprentissage" (e4rat-collect) et "d'optimisation" (e4rat-realloc). Ce n'est pas très compliqué à faire, mais pas vraiment à mettre entre les mains d'un néophyte.

pas Debian en tous cas.

Pourtant, systemd est bien dans Debian (Testing et +) : http://packages.debian.org/search?keywords=systemd&searchon=names&suite=all&section=all&sourceid=mozilla-search

Il n'est pas présent par défaut, mais est instable :

# aptitude install systemd
Les NOUVEAUX paquets suivants vont être installés : 
  libpam-systemd{a} libsystemd-id128-0{a} libsystemd-journal0{a} systemd 
**Les paquets suivants seront ENLEVÉS : 
  klogd{a} sysklogd{a}**
0 paquets mis à jour, 4 nouvellement installés, 2 à enlever et 0 non mis à jour.
Il est nécessaire de télécharger 1 558 ko d'archives. Après dépaquetage, 3 774 ko seront utilisés.

Je ne suis cependant pas assez joueur pour avoir testé sur ma machine principale… :)

D'abord il faut savoir que la plupart des systèmes de fichiers utilisés par Linux fragmentent extrêmement peu

Cela dépend des usages.
- Certes, les partitions de type ext* ont un mécanisme qui mémorisent les emplacements libres, et savent donc qu'à tel endroit, il y a xx blocs contigus de libres. Ainsi, si il faut écrire un fichier dont la taille est de xx blocs (ou moins), cette emplacement-là sera utilisé.

• Par contre, certains usages "récents" de Linux bouleversent la donne. Par exemple, dans le cas du P2P/torrent, le client torrent qui crée les fichiers ne peut pas écrire le fichier d'un coup. De plus, le fichier est écrit par segments, et pas forcément dans l'ordre logique. Il en résulte alors une fragmentation du fichier. Certains client de torrent peuvent pré-allouer la taille complète du fichier avant de commencer le téléchargement, mais ce n'est pas forcément suffisant.

• Les logs (/var/log/) aussi peuvent beaucoup fragmenter, car le processus d'écriture n'est jamais prédictif. Il en va de même pour toutes les opérations qui écrivent des fichiers au fur et à mesurent, sans connaître la taille finale du fichier.

• Autres applications qui peut fragmenter un disque: Un serveur FTP sur lequel on upload des fichiers, ou un serveur SMB/NFS qui reçoit des écritures en parallèle.

Ces dernières années, lors de maintenances sur des machines Linux, j'ai de plus en plus vu des taux de fragmentation de l'ordre de 20%, ou plus.

Pour voir la fragmentation d'une partition ext, la seule méthode que je connaisse est le "fsck.ext? -f /dev/sd?" . **Attention de bien démonter la partition avant de lancer la commande !*

Et si tu veux une autre entrée avec des options différentes et une troisième sans utiliser e4rat, au cas où tu aurais un jour un problème avec ?

Tu as les fichiers /etc/grub.d/*_custom dans lesquels tu peux rajouter les entrées que tu veux

Le numéro (10, 20, .., 99) sert juste à définir l'ordre dans lequel cela apparaîtra dans le menu

Adepte inconditionnel de grub1, et notamment du mini-shell que l'on a en pré-boot avant le chargement des OS, je dois avouer que j'ai vu son arrivée il y plus de 2 ans, sur Debian Testing, avec une certains crainte.

Mais franchement, il n'y a pas de quoi faire un plat.

La syntaxe du grub.cfg est différente du menu.lst ? La belle affaire, ce n'est qu'une syntaxe.

Réinstallation de grub from scratch, notamment après des manips "foireuse" du genre effacement du MBR par un Windows fraichement installé ?

Il y a plusieurs méthodes:
- la technique "old school" : copier-coller d'un /boot/grub venant d'une autre machine, et lancement d'un "grub-install /dev/sdxx". Quand au /boot/grub/grub.cfg, il s'édite à la main sans problème

• la méthode "dans les règle de l'art" (les commandes sont pour une Debian/Ubuntu)
  • boot sur un live CD
  • montage du "/" defectueux en /mnt/casse
  • montage en bind des répertoires système: mount -o bind /dev /mnt/casse/dev mount -o bind /proc /mnt/casse/proc mount -o bind /sys /mnt/casse/sys
  • chroot: chroot /mnt/casse
  • restauration du mbr, création du /boot/grub/grub.cfg update-grub dpkg-reconfigure grub-pc
  • démontage des "bind" et de la partition
  • reboot sur le disque dur

Enfin, grub2 permet des trucs réellement sympa, comme le boot à travers une image ISO, sans avoir besoin de la décomprésser (*). C'est idéal pour avoir plusieurs distribs linux sur une même clé USB. Il suffit simplement de copier/coller l'image iso, en temps que fichier simple.

(*): Exemple pour de l'Ubuntu:
menuentry "Ubuntu 11.10 - Desktop - i386" {
insmod ext2
insmod loopback
insmod iso9660
set isofile="/iso/ubuntu-11.10-desktop-i386.iso"
loopback loop $isofile
linux (loop)/casper/vmlinuz locale=fr_FR bootkbd=fr console-setup/layoutcode=fr iso-scan/filename=$isofile boot=casper file=/cdrom/preseed/ubuntu.seed noprompt quiet splash --
initrd (loop)/casper/initrd.lz
}

Bref, grub2 c'est bon !