benoar a écrit 4237 commentaires

Effectivement, le Control gauche n'est pas mieux placé qu'ailleurs (et la taille n'aide pas), et fait faire des contorsions qui font mal à force. Du coup, moi j'ai remappé Control sur Tab, un peu comme certains font avec le Caps-Lock (mais bon, là ya pas), et Tab sur l'ancien Alt-Tab (effectivement, il faut passer en 106 touches, qu'il faut réactiver à chaque démarrage…). J'ai également un Echap sur la touche « desktop », car moi j'utilise vim…

Au final, ça fait des raccourcis avec Control assez agréables car on ne va pas le chercher tout en bas (la main ne bouge pas), et que la plupart des raccourcis sont des consonnes qu'on trouve à droite en bépo, et les pouces peuvent être utilisés pour autre chose qu'espace seulement, ce qui est très utile : le petit doigt n'est pas surchargé, etc. Les pouces c'est la modif à laquelle j'ai eu le plus de mal à me faire, mais c'est vraiment sympa, et ça me fait pencher vers les modèles de clavier avec plein de touches sous le pouce.

Pour un bout de ma conf qui n'utilise pas xmodmap : http://dolka.fr/code/gitweb/?p=dotfiles.git;a=blob;f=.xkb/symbols/tmtweaks;hb=refs/heads/work

Autant ta réponse a Interstella était limite mais m'a décroché un sourire, autant là tu t'enfonces dans la bêtise…
En plus, tu ne le verras pas à Paris, il préfère les US !

Je voudrais juste rappeler que c'est un article du Courrier Picard, journal pas réputé non plus pour la qualité de son journalisme… même si je trouve que toi et d'autres vous outrez un peu facilement, peut-être (le journaliste a dû faire un rappel sur la sécurité, l'interviewé a dû se sentir un peu attaqué, et au final le journaliste a dû mettre ça pour se dédouaner, en ne pensant pas forcément aux proches du défunt).

En tous cas je connaissais juste sid par ses articles, et il était une des rares personnes que j'estime dans le monde de la sécu (humble et très compétant, qualités qu'on retrouve peu ensemble dans ce domaine). C'est triste, même si on ne va pas non plus en abandonner notre sens de l'humour.

Résumé : F. Elie pense que ce qu'il faut enseigner, c'est la science (et non pas la technologie ou l' usage)

Je pense que c'est évoqué dans le communiqué par ce point :

• un véritable enseignement de la science informatique ;

où ils insistent bien sur le terme « _science_ informatique ».

Tout d'abord, merci pour le boulot de continuer à propager le bépo encore plus loin ! Perso, je suis sous Debian donc je l'ai déjà simplement en console, et c'est effectivement très agréable d'avoir du bépo même dans un shell de secours dans un initrd (!) lorsque ta racine ne monte pas…(expérience datant d'une semaine) Contrairement à ce qui a été dit plus haut, c'est vraiment plus facile pour le coup d'avoir la bonne carte clavier, pour se concentrer sur le vrai problème.

Franchement, à ceux qui se posent la question de l'adéquation du bépo avec X, Y ou Z, je leur dirai toujours que c'est largement mieux que de l'azerty (que je peux bien sûr continuer à taper au cas où, quand je suis sur une machine que je ne peux pas contrôler) et que les défauts du bépo (dont effectivement les chiffres pas directement accessibles, plus gros bémol pour moi) ne sont pas pires que ceux de l'azerty ; bref, qu'il ne peut y avoir que du mieux. Et qu'on le trouve en standard dans plein de distros linux, même si moi aussi j'ai mes quelques modifications persos, mais je peux m'en passer (j'essaye de les minimiser).

En tous cas, en ce qui concerne l'entrée du français, ça facilite tellement la frappe que ça change vraiment la manière d'interagir avec la machine. Pour cela, il faut aussi apprendre à taper à l'aveugle — en passant, ça règle le problème de trouver un clavier avec des symboles corrects sur les touches. Mais une fois cet apprentissage fait, l'entrée des lettres se fait tellement naturellement que ça change vraiment l'ergonomie de son poste. Plus de mal de coup à regarder trop bas. Moins de bruit quand on tape (bonus pour un typematrix avec skin). Plus de mal au poignet (et pour les jeunes qui ne voient pas ce que je veux dire, oui, après un certain nombre d'années, ça va vous arriver). Les mots défilent vraiment à toute vitesse, sans que le clavier ne vous ralentisse (trop ; on n'en est pas encore à ce que l'ordinateur lise dans vos pensées). Et ça n'est pas une question de rapidité, mais plutôt d'avoir un moyen d'entrée agréable, fluide, et qui ne vous handicape pas.

En ce qui concerne la configuration, et vu les difficultés qu'ont certains, moi j'ai trouvé un truc pas trop bidouille qui marche quasi-uniquement en utilisateur (et encore, c'est parce que je veux remapper des touches pour un clavier au-dessus de 105), avec du xkbcomp ; cf http://dolka.fr/code/gitweb/?p=dotfiles.git;a=tree;f=.xkb;hb=refs/heads/work pour mon répertoire ~/.xbk et qui se charge à coup de xkbcomp comme là http://dolka.fr/code/gitweb/?p=dotfiles.git;a=blob;f=bin/load_my_tm.sh;hb=refs/heads/work

Inspire toi de git, par exemple : son utilisation des SHA1 est faite justement pour ne pas dépendre d'un quelconque identifiant ; tout est « contenu » dans le hash de la donnée que tu « adresses ». C'est une propriété très sympa pour éviter les collisions, comme tu as déjà noté.

Par contre, pour les humains, git a des références, qui sont comme une arborescence de fichiers, mais qui pointe vers un objet (SHA1) particulier, genre refs/heads/master, refs/tags/v1.0, … Et quasiment sans contraintes sur la manière de les écrire. Quand on merge le contenu d'un autre dépôt, l'import des objets, indexés par leur hash, se fait sans problème ; par contre, pour les références (surtout les tags, quand on merge), il faudra résoudre « à la main » s'il y a conflit.

Mais je suis d'accord avec quelques autres sur le fait de ne pas se créer de faux problème trop tôt : si tu ne veux pas te soucier de la liaison référence <-> objet, reste sur du SHA1. Si tu penses par contre que la lisibilité des noms est importantes, fais-toi un système qui lie les deux, mais ne t'embête pas trop avec les règles de nommage et essaye plutôt de faire suivre des conventions. “Conventions over configuration”, comme disent les américains.

J'ai retravaillé le code pour qu'il soit « plus clair », et j'ai minimisé l'information « arbitraire » pour ne plus avoir que la taille des codes pour chaque octet. Le résultat est également donné sous forme de tableau plutôt que des variables a à f, où les octets sont à lire de i à 0. Ce qui donne :

unsigned int bits = hexa;
unsigned char code_size[] = [7, 4, 5, 5, 5, 5];
unsigned char result[] = [0, 0, 0, 0, 0, 0];
size_t i = 0;

for (unsigned int total_code_size = 1<<code_size[0];
        hexa >= total_code_size;
        i++, total_code_size <<= code_size[i]) {
    result[i] |= 0x80; // utile seulement à la première itération
    result[i+1] = (result[i]>>1) | 0x80;
    result[i] |= bits & 0x3f;
    bits >>= 6;
}
result[i] |= bits;

Ça doit sûrement paraître uxamifiant à certains, et ce code n'a pas été testé, mais je pense qu'il est bon (aux casts près, je me rends compte en relisant). Ça n'est pas le top niveau lisibilité, mais niveau quantité d'information donnée et calculée ça doit s'approcher du minimum.

Avec ton code, tout est exécuté : du premier test au dernier en passant par tous les décalages & masques et les écritures que contient ton code : 5 tests conditionnels, 15 écritures et un nombre décalages & masques trop volumineux pour être répertorié ici en si peu de temps.

Petite correction : oui pour les 5 tests, mais une seule affectation, la dernière, tout les tests échouant. L'ensemble des shifts & masks ne sont exécutés que pour la zone la plus « haute ».

Au final, je pense que tu as fournis le pire exemple de "simplification" qui soit, tant au niveau 1) de la lisibilité,

Effectivement, au départ je me disais que ça serait « mieux » niveau lisibilité car il n'y a pas de répétition, mais ça fait un peu étrange quand même ; je comprends le côté uxamifiant.

2) du codepath,

Pas tant que ça, même s'il y a effectivement beaucoup de branchements.

3) de l'exécution

Idem.

aini que 4) de l'atteinte du but que tu veux viser

Ah, là, je n'ai jamais exprimé de but dans ce commentaire ;-) j'avais juste une intuition qu'on pouvait faire « mieux », et je voyais des relations entre les différents préfixes et les décalages, j'ai sorti ce bout de code qui exprimait « mieux » le cœur du problème, je trouve. C'est vrai qu'au final il est un peu étrange. Note qu'on pourrait même en faire une boucle, mais pour la « clareté » je l'ai déroulée.

On peut faire un peut mieux que répéter les shift & masques dans ta fonction hexatochars() :

unsigned int bits = hexa;
if (hexa >= (1<<26)) {
    a |= 1<<2;
    f = (bits & 0x3f) | 0x80;
    bits >>= 6;
}
if (hexa >= (1<<21)) {
    a |= 1<<3;
    e = (bits & 0x3f) | 0x80;
    bits >>= 6;
}
if (hexa >= (1<<16)) {
    a |= 1<<4;
    d = (bits & 0x3f) | 0x80;
    bits >>= 6;
}
if (hexa >= (1<<11)) {
    a |= 1<<5;
    c = (bits & 0x3f) | 0x80;
    bits >>= 6;
}
if (hexa >= (1<<7)) {
    a |= (1<<6) | (1<<7);
    b = (bits & 0x3f) | 0x80;
    bits >>= 6;
}
a |= bits;

J'ai écrit les constantes différemment car je trouve que ça permet de mieux se rendre compte que les intervalles proposés par ce standard encodent 7, 4, 5, 5, 5 et 5 bits chacun, pour un total 31 bits pour un “code point”. En plus, avec le fait qu'on shift toujours de 6 bits, ça m'avait embrouillé sur le calcul, mais en fait ça marche exactement comme ça car chaque octet qui s'ajoute vient rétrécir d'un bit la place qu'on a dans le premier (sauf au premier ajout, où on perd 2 bits car on ne peut pas prendre le préfixe « réservé » 0b10xxxxxx)

1) je répondais à […]

OK, excuse pour l'homme de paille, je suis remonté un peu loin dans le thread sans réfléchir. Mais…

2) Le problème est bien plus général que ça, la ne concerne pas que le trim : les firmwares sont buggués, pas assez testés, difficiles à mettre à jour, … C'est un fait. Déplacer vers l'OS résout 99,478% de tout cela.

Je ne suis pas du tout contre le trim. Je suis pour la fonctionnalité passe vers les les OS.

… je t'ai montré en quoi je pensais que ça n'arriverait pas. Donc, en « attendant », le TRIM est indispensable et est quelque chose qui marche plutôt bien. CQFD.

http://www.tomshardware.com/reviews/intel-x25-m-firmware,2461.html
http://www.tomshardware.com/news/Intel-SSD-Firmware-TRIM-X25-M,8944.html

Les problèmes de firmware sont légions en général.

Heu… un problème de firmware sur un SSD d'il y a quatre ans et qui a été le premier (de mémoire) à implémenter le TRIM ? Houa, génial comme argument pour discréditer le TRIM.

Oui, il y a quelques problèmes de firmware parfois, sur plusieurs aspects y compris le TRIM, surtout chez les constructeurs pas consciencieux, mais de la à dire que le TRIM « est trop problématique à plein de niveau », tu exagères beaucoup.

Il pourrait au moins avoir 2 modes :

L'actuel
Le raw

Et quand tu switches de l'un à l'autre, qu'est-ce qu'il se passe ?
Après, je joue l'avocat du diable mais j'aimerais effectivement que ça soit possible. Mais je t'ai exposé mes arguments sur les raisons du peu d'espoir que j'ai…

Crucial n'est pas le seul qui a eu des problèmes. Cela a été de même avec intel et pleins d'autres.

Perso, je m'intéresse un peu aux SSDs, et je n'ai jamais entendu parler de problèmes sur le TRIM. Je veux bien croire qu'il y en a eu à un moment, mais pour que tu conseilles ainsi de se passer de TRIM, là, ça me semble exagéré.

J'essaye toujours de remonter les problèmes quand je peux :
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=710803

Super, merci pour la référence. Je m'y mettrais un jour si je trouve un peu de temps.

Encore faut-il connaître les touches à appuyer pour joindre le service que l'on souhaite : sur le répondeur de ma banque, il te demande 3 fois de prononcer le nom de l'agence que tu veux joindre avant de tomber sur le « tapez le département sur votre clavier ». Et au menu suivant, alors que tu es toujours dans un environnement bruyant et tu sais très bien que ça va merder, il te redemande 3 fois de prononcer le nom de ton conseiller, avant de te proposer de taper 1 pour avoir l'accueil… Ça fait perdre un temps fou pour rien.

C'est exactement ce genre de conneries que j'espère, qu'on va supprimer. Et arrêter avec les milliers d'implémentation buguées de trim faites par les fabricants. Un SSD vide mais néanmoins pleins c'est quand même bien merdique.

Bah, ce que je te décris c'est la situation avant le TRIM, et le fait d'être « vide mais néanmoins plein » ça ne dépend pas que d'une implémentation « buggée » du trim, mais également de sa non-implémentation. Bref, un trim bien implémenté (comme il l'est sur pas mal de SSD quand même, perso je n'ai jamais eu de problème même si ma base de test est faible) ça ne pose pas de problème.

Ce que je veux c'est du RAW Flash et que l'OS fasse tout.

Moi aussi je voulais ça à une époque et j'ai arrêté de rêver depuis. Ça n'arrivera jamais, car les vendeurs de Flash sont trop contents de vendre 3 fois plus cher leurs puces de Flash en les accompagnant d'un contrôleur pas cher + du soft proprio qui leur permet de segmenter le marché comme ils veulent. Car oui, aujourd'hui les vendeurs de SSD (donc y compris le contrôleur, qui est de toutes façons un ARM dans 99% des cas) sont des fabricants de mémoire. Accessoirement, ça évite les implémentations pourries en soft du wear-leveling (OK, au début tu retrouves des implémentations pourries en « hard », ce qui est… différent).

Et regarde du côté du futur, qui est NVM Express : on reprend les même commandes SCSI et on recommence. Tout ce qu'ils ont changé, c'est le bus en support (du PCIe direct vers le SSD au lieu d'un HBA AHCI qui cause SATA) et quelques suppressions de restrictions sur le nombre de queues, la gestion des interruptions, etc. Bref, c'est juste pour avoir des perfs meilleures, mais le paradigme « je suis juste une suite de secteurs consécutifs sans aucune distinction et aucun contrôle » reste. Remarque, ça aurait demandé un sacré changement niveau soft, qui est assez limité pour NVM Express. Et plus de rapidité, ça se vend bien, alors que plus de longévité… tu veux qu'ils vendent moins de disques, c'est ça !? Tueur de marché !

Sur le SSD :

Pas de table d'allocation
Pas de déplacement de bloc
et donc pas de trim

Tu imagines sur le marché des disques « dumb SSD » avec une étiquette « attention, à n'utiliser qu'avec un OS version X.Y blah blah ». Déjà que le passage aux secteurs 4k a l'air de faire peur à beaucoup de monde, là je n'imagine même pas.

Sur l'OS (Zfs et Btrfs en sont capables) :

Peut chercher lui-même où écrire
Peut faire du CoW lui-même
Peut écrire de façon agglutinée via caching
…

Et sous Windows ? Pas d'implém windows = ça ne se fera pas.

Je veux, pour les SSD, ce que font les compact flash bas de gamme : rien. Juste que les blocs soient exposés à l'OS. Tout le reste doit être géré par l'OS.

Bah, même les CF bas de gamme s'amusent quand même à wear-leveler juste un secteur (ou un peu plus, peut-être) : celui de la FAT du FAT32… Et même s'ils sont très débiles, franchement c'est de la merde à l'utilisation, je ne sais pas comment ils font. Ah si, le contrôleur (qui ne fait pas grand chose) est tout merdique, et c'est parce que de toutes façon ils ne feront même pas d'effort pour enlever cette histoire de gestion de FAT32, juste parce que le prix en R&D doit être à peu près zéro, vu le prix proposé au public.

Actuellement, il faut faire du trim, on ne peut faire autrement. Et c'est merdique à pleins de niveau !

Bah, c'est mieux que rien. Franchement, l'accès raw n'arrivera jamais selon moi, ça changerait trop la sémantique de SCSI, et le jour où on se séparera de SCSI… et donc, le TRIM, c'est la seule solution pour bosser avec ce paradigme. Et elle n'est pas si mal, et conceptuellement propre. Reste aux constructeurs de SSD à faire des implém correctes, mais perso je n'ai pas eu de problème : tu devrais peut-être changer de constructeur.

Donc au final, pour avoir un comportement satisfaisant il faut vérifier qu'il n'y a pas de process parasite et régler son délai avant parquage à une valeur adaptée à son utilisation.

Ah ok ; c'est juste que depuis le début je ne me concentrais que sur mon utilisation : là tu dois parler également de ceux qui utilisent un portable et qui veulent que le disque se mette en veille au bout d'un moment pas trop long sans process pour le réveiller trop souvent.

Comme process parasite rigolo, j'ai eu mon lot de surprises : firefox qui synchronisait toutes les 30s,

Ah, firefox qui fsync toute ta navigation… j'aimerais bien montrer la débilité de la chose avec un « vieux » smartphone qui freeze 10s (oui oui, 10s) à chaque visite d'un lien car il le sauvegarde dans l'historique, et je soupçonne que la cause est le contrôleur de la flash qui galère à mort à faire sa tambouille pour trouver de la place en flash… (contrôleur eMMC sans TRIM, je suppose). (ya un thread sur un autre journal là-dessus en ce moment)

des process qui loggaient pour pas grand chose (--mark-- dans syslog),

Oui, mais ça peut parfois être utile pour savoir qu'il ne s'est pas arrêté, peut-être.

des CRON se déclenchant toutes les heures sans réelle utilité, etc.

Oui. Si tu (on ?) pouvais remonter remonter ça upstream avec des bugreports sympas, afin de trouver une solution à ça, ça serait génial… :-)

Les FS modernes (ZFS, Btrfs, …) fournissent par défaut le copy on write et donc presque gratuitement, le premier point, la répartition des écritures sur l'ensemble du device.

Tout à fait. Vu qu'on s'en fout de la localité des accès sur un SSD, ce genre de fonctionnement n'est de plus pas pénalisant pour les SSD, contrairement aux disques classiques.

Ce qui supprime toutes la logique de garbage collection et de CoW au niveau du device.

Alors là pas du tout.

Mettons-nous dans le cas d'un SSD « complètement utilisé » (pas neuf) sans trim, i.e. sur lequel on a écrit au moins autant que sa capacité, et qui a donc tous ses secteurs marqués comme « occupés », quoiqu'en dise le FS dessus (même avec 100% d'espace libre) ; cas on ne peut plus classique pour un support de stockage utilisé normalement. Sa table (interne) de mapping des secteurs est faite d'une certaine manière, propre à sa manière de gérer la répartition des blocs et à l'utilisation qui en a été faite, et n'est pas forcément du tout contiguë par rapport aux secteurs tels qu'on les voit à plus haut niveau.

Quand une écriture pour le secteur S arrive, quel que soit la manière du FS d'écrire dessus, qu'il fasse du CoW ou autre, ton SSD va devoir trouver de la place pour l'écrire, à un endroit qui n'est pas le même que le précédent secteur qu'il remplace si c'est un FS style CoW, certes, mais de toute façon d'une manière où le SSD va devoir lui aussi changer son mapping car il y a beaucoup de chances qu'il doive déplacer tout un bloc (= plusieurs Mo) d'un endroit à un autre, en re-déplaçant d'autres secteurs au passage (= ré-écriture d'autres blocs également) afin de faire de la place (rappelons qu'il n'a plus de place libre, et qu'il doit donc trouver un endroit ou écrire = un bloc vierge dans son espace provisionné pour, dans lequel passera le secteur qui était précédemment présent à cet endroit selon le mapping du SSD). Tu n'as aucun contrôle sur le mapping interne du SSD, et même si tu voulais être optimiste et te dire qu'en faisant des écritures de la taille de « l'unité » qu'il utilise pour gérer son truc, ça serait « optimal », bah aujourd'hui les blocs c'est plusieurs Mo… (oui, il écrit par page, i.e. plusieurs centaines de Ko, mais je parle en erase-block pour simplifier)

Alors après, si ton contrôleur de SSD est pas trop con, il va pouvoir « agglutiner » plusieurs requêtes en écriture (tout en faisant gaffe à l'interaction avec la sémantique d'atomicité (ou pas) de la suite d'instructions qu'il reçoit) afin d'écrire des blocs plus gros, qui nécessiteront de moins faire de déplacement de secteurs, mais ça n'empêche qu'au final, la logique de garbage collection est au contraire beaucoup plus intense et compliquée, et ton amplification en écriture (= rapport de la taille de la requête en écriture / écritures réellement réalisées sur le SSD) est énorme, ce qui entraîne une dégradation de la durée de vie de ton SSD.

Pour ce qui est du 2ème point, il est toujours nécessaire mais ce n'est plus un trim, une opération potentiellement lourde**, mais juste un reset quand c'est fait au niveau du fs.

Je ne comprends pas ce que tu veux dire… tu parles d'un « reset » qui serait ton fstrim, mais fait régulièrement / automatiquement ?

Sur les FS non moderne (extX, …), la véritable question c'est plutôt : « quand faire le trim ? A la demande ou une fois de temps à autre ? ». Je suis d'avis de le faire une fois de temps à autre.

Pour moi ça ne change pas tant que ça des FS modernes ; il y a la même problématique de répartition en dessous (sur le SSD).

Ca utilise les widgets GTK+, l'ordre des boutons est respecte, la boite de dialogue pour selectionner un fichier est celle de GNOME, les icones changent en fonction du theme GNOME, l'alignement des labels est correcte ect…

Bah, l'utilisation de l'espace et le dimensionnement des éléments sont complètement différents. Et ça se repère tout de suite, je ne l'aime pas en Qt. D'ailleurs, Wireshark est (était, du coup) un des rares programmes GTK+ qui arrive à merder à ce niveau en me mettant des boutons partiellement cachés et des fenêtres in-redimensionnables. Ils ont dû coder ça avec les pieds sans suivre les guidelines GTK. Pas étonnant qu'ils soient passés à Qt…

Pour ceux que cela intéresse, je me suis aussi renseigné pour un boîtier externe USB3 dont le chipset gère lui-même la mise en veille (ASMEdia ASM1051 par exemple). Et ben là aussi c'est le far west et je n'ai pas réussi à trouver.

À noter pour les disques USB : certains permettent de passer des commandes directement au disque avec sdparm (plutôt que hdparm). Et depuis l'USB3, il y a normalement l'“USB Attached SCSI” qui permet également cela, dans le standard et donc normalement utilisable partout. Par contre, je ne sais pas ce qu'il en est du support soft.

Mais justement c'est une vrai debian dès le début. Avec une couche proprio au dessus pour avoir une belle interface web, mais c'est tout.

OK. Mais le support de cette plateforme est-il intégré upstream chez Debian ? C'est plutôt de ça dont je parlais. Car les installations de Debian « ad-hoc » pour les NAS, il y en a plein (voire de simples chroot…). Mais dans la durée, ça ne tient pas, car il n'y a aucun support des versions suivantes.

Il y a potentiellement quelques drivers pas libres tout au plus, j'ai pas été vérifier ça.

Ah, on arrive encore aux merdes classiques… mauvais point pour Synology, qui m'a plutôt impressionné avec ton histoire, quand même.

L'intérêt principal pour moi pour cette machine c'était son prix: à 100€ il est difficile faire quelque chose d'équivalent, qui est toujours utilisable par Madame Michu, et bidouillable par ssh. Certains NAS sont moins cher mais complètement fermés, d'autres sont plus ouverts (Synology, firmware libre) mais plus cher. C'était un bon compromis pour moi.

Oui, je comprends que le rapport utilité/prix est vraiment pas mal. Moi je table sur l'occasion pour avoir des prix corrects ;-)

Mais si je colle l'oreille, j'entends bien un petit "tac" toutes les cinq secondes, et la valeur SMART est incrémentée de un à chaque fois…

Ça me rappelle un disque que j'avais sur un laptop, qui est mort d'un trop grand nombre de (dé)chargements de tête. Ça serait pas un Hitashi ? J'avoue ne pas comprendre comment on peut arriver à mettre une si petite période, mais bon… mystère.

Si tu fais du bittorrent à longueur de journée, cela n'a même plus de sens de chercher à parquer les têtes (puisqu'il va probablement y avoir une demande d'accès dans les 5 mn).

A l'inverse, si tu as bien réglé ton délai avant parquage à une valeur raisonnable de 5 mn, cela ne servira à rien si tu as un process parasite qui accède au disque toutes les 3 mn.

Je ne comprends pas : dans les deux cas, tu as une période d'utilisation inférieure à la période de parquage, et donc les têtes ne se parquent jamais. On aurait un accès toute les demi-heure, avec un parquage de 5 min, ça ferait un nombre de chargements raisonnables. Bref, pas besoin de faire « en fonction » de l'utilisation, une valeur genre 5 minutes irait très bien pour une machine fixe. Le mettre à 30s sur un laptop, pourquoi pas, même si je ne suis pas convaincu de l'effectivité de la résistance aux chocs…

Ce n'est pas si compliqué que cela (enfin c'est relatif je te l'accorde). Si cela t'intéresse tu peux faire une demande sur le forum et j'y répondrai.

Merci, c'est sympa, mais je n'ai pas trop le temps de faire ça pour l'instant. Une autre fois, peut-être.

Merci pour le lien, très intéressant. J'ai déjà vu des points de connexions sur des SSD qui ressemblent trop à un port série ou à un JTAG… je me suis toujours dit qu'il fallait que j'essaye un jour. Mais bon, pas le temps…

195 Hardware_ECC_Recovered 0x001a 100 100 000 Old_age Always - 12350589

Avec ce genre de valeur qui ne veut rien dire, effectivement, c'est un disque nase qui ne file pas beaucoup d'info intéressante.

Oui enfin le mieux c'est quand même de choisir un NAS qui supporte une vrai Debian dès le début ! Voir par exemple la page de Martin Michlmayr http://www.cyrius.com/debian/

Du coup, ça démystifie beaucoup le truc et ça devient « normal » d'avoir un ordi comme un autre avec une Debian, sur lequel tu peux installer toute la logithèque Debian, même si c'est un armel et qu'il consomme 5W…