Et quoi qu'il en soit, je reste persuadé que c'est au niveau de l'OS que ça doit se faire.
C'est ce qu'Intel semble avoir choisi (et feu Sun avec ZFS) avec leur système de cache à venir (mais c'est pas encore très clair, ça serait lié à un chipset de carte mère particulier mais aussi à l'OS…).
Ceci dit, il serait tout à fait possible de créer des choses complexes mais faciles à réparer, en standardisant les composants et les rendant facilement remplaçables… comme ce qui existe avec les PC (enfin malheureusement les grandes marques ont tendance à dévier des normes). Ça ne doit pas intéresser le grand public, qui veut son produit tout de suite sans trop réfléchir à sa pérennité.
Côté alim' les machines de supermarché et même certaines d'assembleur sont vendues avec des blocs d'alim génériques qui délivrent des courants anormaux, ça entraine forcément de la casse.
C'est d'ailleurs assez désespérant de voir (et entendre, car elles sont aussi bruyantes) ces machines… Et bien sûr impossible d'avoir des infos sur une alimentation de PC (ou Mac (troll)) de marque avant l'achat, alors que c'est un des composants les plus essentiels, qui a vu un grand nombre d'évolutions ces dernières années.
tmpfs peut se retrouver en swap (contrairement à l'autre, ramfs), donc si tu en as, il est tout à fait envisageable de dépasser la limite (par défaut elle est en dur à 50% de la ram).
Pour compiler c'est effectivement génial, et en plus, on évite de réduire la durée de vie de son matériel.
Le 320 c'est la nouvelle version, sans très grands changements à priori, les X25 vont disparaître à terme.
Les cartes qui permettent d'overclocker demandent le P67 qui empêche d'utiliser la carte graphique. La solution c'est le Z68 qui… n'est pas encore sorti :(
Par exemple, quand je vois l'offre no!box d'OVH qui ne propose en ipv6 qu'un /128
Incroyable ! Pourtant avec leurs dédiés ils ne sont pas avares d'IPv6 (ni même d'IPv4).
Je comprend pas ce choix, surtout que la clientèle OVH a bien plus de chance de savoir ce qu'est une IPv6 que la clientèle Orange…
C'est ce que fait le Momentus XT de Seagate. Concrètement c'est loin derrière un SSD même pour les tâches auquel il est sensé être efficace (utilisation d’applications les plus utilisées, démarrage de l'ordinateur, etc.).
Avec peut-être moins de limitations et plus de performance, mais moins accessible, il y a le L2ARC de ZFS.
Note que le 80 Go est aussi plus rapide que le 40 Go − car il y a plus de modules NAND en parallèle (ça change de gamme par ailleurs, -V à -M). Tu as besoin de toute cette RAM ? Tu peux éventuellement diminuer la RAM et prendre le plus gros SSD, quitte à avoir de la swap pour les jours de besoin.
Les senseurs des cartes ASUS sont généralement mieux supportés que ceux des Gigabyte (enfin, ça reste mon expérience, limitée). Ça ne changera pas ta vie.
Ah, dernière chose : c'est peu utile d'avoir un processeur 'K' avec du H67 car il n'y a pas d'overclocking avec ce chipset. Autant prendre un processeur non 'K' à un meilleur prix.
Il me semble que Madelin parle d'erreurs de jeunesse pour son passé à Occident. Il est en revanche toujours libéral si j'en crois ses interventions sur BFM. Et pour un libéral, il n'y a absolument aucun problème avec la charité… privée.
Les SSD "modernes" se font passer pour des disques durs afin de fonctionner avec les OS qui eux ne le sont pas. Du coup, ça fait un moment qu'ils gèrent la réallocation en permanence des secteurs modifiés, pour limiter les phénomènes d'usure. Bref : il y a peu de chances de perdre ses données à cause d'une usure de la NAND, mais il y en a plus d'en perdre à cause d'un bug dans ces contrôleurs très complexes qui font ce que le système de fichiers devrait faire.
Sinon j'utilise plusieurs SSD dans des contextes plutôt gourmands en écriture et c'est sans problème pour l'instant… et tellement plus rapide !
Intel va sortir un SSD de 20 Go (dans les 50€), dans le but qu'il soit un « cache » sous Windows, mais c'est particulièrement intéressant pour y mettre tout / sous Linux. Actuellement on trouve rien en dessous de 40 Go et 90€ !
Les performances augmentent mais les prix ne baissent pas aussi vite. :(
Tu as vraiment besoin de 120 go ? Ça ne sert à rien d'y mettre des données lourdes, juste ses applications, et les applications pour Linux ne sont pas vraiment gourmandes en place.
Ah, c'est intéressant. Les SSD ont cette tendance à mentir à l'OS pour écrire ensuite plus tard, ou différemment (en parallèle car il y a plusieurs mémoires, etc.)
Il est possible que le condensateur qui permet l'écriture après extinction soit mauvais ou sous-dimensionné.
Les Mo/s ce n'est pas vraiment l'intérêt des SSD, c'est assez fatiguant de voir tout le temps ça et pas ce qui compte vraiment, les IOPS.
Sinon, les OCZ ne sont pas vraiment fiables (cf. le lien vers hardware.fr dans un autre commentaire) sans compter qu'il vaut mieux mettre à jour son firmware (même quand tu l'achète neuf tu as pas forcément une version moins pleine de bugs).
Mon conseil est simple : aller chez Intel, qui propose moins de performances racoleuses mais qui est tout aussi rapide pour l'utilisateur, tout en étant beaucoup plus fiable. Le SSD Intel que j'utilise actuellement expose d'ailleurs pas mal d'informations intéressantes via SMART contrairement à l'OCZ que j'ai mis ailleurs (note : ce n'est pas un Vertex 2 ni même un Sandforce, et il fonctionne toujours malgré tous les abus qu'il subit, je me demande juste pour combien de temps).
Ah ? Si je regarde autour de moi, c'est majoritairement à l'électricité (tout mes appartements sauf l'actuel l'étaient par ailleurs, pour eau et chauffage).
D'ailleurs j'ai découvert ce que c'était un appart mal isolé dans une région humide qui plus est… j'ai très largement dépassé la consommation électrique prévue :(
Ou des hôtels, qui quand ils te demandent ta carte bleue, ce n'est pas pour la mettre dans un terminal, mais pour noter sur une feuille de papier le numéro.
Je pense comme les autres qu'il vaut mieux utiliser la librairie de Python pour le faire.
Cependant : déjà tu devrais faire grep -e '^To: ' plutôt que grep -e "To:", sinon tu pourrais récupérer des lignes qui ne sont pas du tout un header.
Et tu devrais séparer le contenu avant de faire le grep des headers. Ils sont séparés de manière très simple : c'est la première ligne vide. Donc quelque chose comme… grep -m1 -n -e '^$' pour obtenir le numéro de cette ligne vide, et ensuite tu peux tail/head.
[^] # Re: Sécurité
Posté par DLFP est mort . En réponse au journal Et vous, quelle sécurité pour vos sauvegardes?. Évalué à 10.
En fait, c'est une idée géniale.
Étape 1 : trouver la sextape d'une célébrité.
Étape 2 : par stéganographie, ajouter ta sauvegarde à la vidéo
Étape 3 : diffuser
Tu es sûr que tes données ne seront jamais perdues !
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: Cher
Posté par DLFP est mort . En réponse au journal Les SSD, ce n'est pas au point. Évalué à 2.
C'est ce qu'Intel semble avoir choisi (et feu Sun avec ZFS) avec leur système de cache à venir (mais c'est pas encore très clair, ça serait lié à un chipset de carte mère particulier mais aussi à l'OS…).
DLFP >> PCInpact > Numerama >> LinuxFr.org
# Autre problème
Posté par DLFP est mort . En réponse au journal Et vous, quelle sécurité pour vos sauvegardes?. Évalué à 4.
Euh vraiment ? J'en ai jamais vu dans ce cas. Sinon, rsync.net a l'air très bien, et il y a le choix des protocoles.
Ce qui m'embête le plus c'est que je n'ai certainement pas l'upload suffisant pour sauvegarder mes données.
Pour l'instant, je dépose des disques durs (cryptés donc pas besoin de les sécuriser plus que ça) en dehors de chez moi.
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: Intérêt ?
Posté par DLFP est mort . En réponse au journal Synchronisez vos données avec Dropbox. Évalué à 1.
Oui, il fait des "deltas". Si tu as des gros besoins en fichiers binaires (moi pas vraiment, c'est 90% du texte) tu as https://github.com/apenwarr/bup
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: Intérêt ?
Posté par DLFP est mort . En réponse au journal Synchronisez vos données avec Dropbox. Évalué à 1.
La même idée, avec git : http://mayrhofer.eu.org/dvcs-autosync
Pas testé, j'utilise juste git avec des alias.
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: Ne pas tous confondre
Posté par DLFP est mort . En réponse à la dépêche Obsolescence du matériel et taux de panne. Évalué à 10.
Ceci dit, il serait tout à fait possible de créer des choses complexes mais faciles à réparer, en standardisant les composants et les rendant facilement remplaçables… comme ce qui existe avec les PC (enfin malheureusement les grandes marques ont tendance à dévier des normes). Ça ne doit pas intéresser le grand public, qui veut son produit tout de suite sans trop réfléchir à sa pérennité.
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: Solidité et copie
Posté par DLFP est mort . En réponse à la dépêche Obsolescence du matériel et taux de panne. Évalué à 2.
C'est d'ailleurs assez désespérant de voir (et entendre, car elles sont aussi bruyantes) ces machines… Et bien sûr impossible d'avoir des infos sur une alimentation de PC (ou Mac (troll)) de marque avant l'achat, alors que c'est un des composants les plus essentiels, qui a vu un grand nombre d'évolutions ces dernières années.
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: SSD : idéal pour compiler ?
Posté par DLFP est mort . En réponse au journal Les SSD, ce n'est pas au point. Évalué à 3.
tmpfs peut se retrouver en swap (contrairement à l'autre, ramfs), donc si tu en as, il est tout à fait envisageable de dépasser la limite (par défaut elle est en dur à 50% de la ram).
Pour compiler c'est effectivement génial, et en plus, on évite de réduire la durée de vie de son matériel.
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: Non
Posté par DLFP est mort . En réponse au message Nouvelle config pour ma Debian. Évalué à 2.
Le 320 c'est la nouvelle version, sans très grands changements à priori, les X25 vont disparaître à terme.
Les cartes qui permettent d'overclocker demandent le P67 qui empêche d'utiliser la carte graphique. La solution c'est le Z68 qui… n'est pas encore sorti :(
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: On passera à ipv6 que lorsque les prix seront cher ? le prix de l'ipv4 ou le prix de l'ipv6 ?
Posté par DLFP est mort . En réponse au journal une place de marché pour les adresses IPv4. Évalué à 2.
Incroyable ! Pourtant avec leurs dédiés ils ne sont pas avares d'IPv6 (ni même d'IPv4).
Je comprend pas ce choix, surtout que la clientèle OVH a bien plus de chance de savoir ce qu'est une IPv6 que la clientèle Orange…
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: Cher
Posté par DLFP est mort . En réponse au journal Les SSD, ce n'est pas au point. Évalué à 2.
C'est ce que fait le Momentus XT de Seagate. Concrètement c'est loin derrière un SSD même pour les tâches auquel il est sensé être efficace (utilisation d’applications les plus utilisées, démarrage de l'ordinateur, etc.).
Avec peut-être moins de limitations et plus de performance, mais moins accessible, il y a le L2ARC de ZFS.
DLFP >> PCInpact > Numerama >> LinuxFr.org
# Non
Posté par DLFP est mort . En réponse au message Nouvelle config pour ma Debian. Évalué à 3.
Tout ça me semble tout à fait compatible.
Note que le 80 Go est aussi plus rapide que le 40 Go − car il y a plus de modules NAND en parallèle (ça change de gamme par ailleurs, -V à -M). Tu as besoin de toute cette RAM ? Tu peux éventuellement diminuer la RAM et prendre le plus gros SSD, quitte à avoir de la swap pour les jours de besoin.
Les senseurs des cartes ASUS sont généralement mieux supportés que ceux des Gigabyte (enfin, ça reste mon expérience, limitée). Ça ne changera pas ta vie.
Ah, dernière chose : c'est peu utile d'avoir un processeur 'K' avec du H67 car il n'y a pas d'overclocking avec ce chipset. Autant prendre un processeur non 'K' à un meilleur prix.
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: Pire qu'un retournement de veste !
Posté par DLFP est mort . En réponse au journal Alain Madelin et le projet Sankoré.. Évalué à 2.
Il me semble que Madelin parle d'erreurs de jeunesse pour son passé à Occident. Il est en revanche toujours libéral si j'en crois ses interventions sur BFM. Et pour un libéral, il n'y a absolument aucun problème avec la charité… privée.
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: SSD : idéal pour compiler ?
Posté par DLFP est mort . En réponse au journal Les SSD, ce n'est pas au point. Évalué à 3.
Les SSD "modernes" se font passer pour des disques durs afin de fonctionner avec les OS qui eux ne le sont pas. Du coup, ça fait un moment qu'ils gèrent la réallocation en permanence des secteurs modifiés, pour limiter les phénomènes d'usure. Bref : il y a peu de chances de perdre ses données à cause d'une usure de la NAND, mais il y en a plus d'en perdre à cause d'un bug dans ces contrôleurs très complexes qui font ce que le système de fichiers devrait faire.
Sinon j'utilise plusieurs SSD dans des contextes plutôt gourmands en écriture et c'est sans problème pour l'instant… et tellement plus rapide !
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: Cher
Posté par DLFP est mort . En réponse au journal Les SSD, ce n'est pas au point. Évalué à 4.
Intel va sortir un SSD de 20 Go (dans les 50€), dans le but qu'il soit un « cache » sous Windows, mais c'est particulièrement intéressant pour y mettre tout / sous Linux. Actuellement on trouve rien en dessous de 40 Go et 90€ !
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: Cher
Posté par DLFP est mort . En réponse au journal Les SSD, ce n'est pas au point. Évalué à 8.
Les performances augmentent mais les prix ne baissent pas aussi vite. :(
Tu as vraiment besoin de 120 go ? Ça ne sert à rien d'y mettre des données lourdes, juste ses applications, et les applications pour Linux ne sont pas vraiment gourmandes en place.
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: OCZ ça suxe sa reum!
Posté par DLFP est mort . En réponse au journal Les SSD, ce n'est pas au point. Évalué à 6.
C'est plus que tous les disques durs, par la même source :
http://www.hardware.fr/articles/831-6/taux-pannes-composants.html
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: Alors là je dis non !
Posté par DLFP est mort . En réponse au journal Les SSD, ce n'est pas au point. Évalué à 10.
Ah, c'est intéressant. Les SSD ont cette tendance à mentir à l'OS pour écrire ensuite plus tard, ou différemment (en parallèle car il y a plusieurs mémoires, etc.)
Il est possible que le condensateur qui permet l'écriture après extinction soit mauvais ou sous-dimensionné.
DLFP >> PCInpact > Numerama >> LinuxFr.org
# Intel
Posté par DLFP est mort . En réponse au journal Les SSD, ce n'est pas au point. Évalué à 10.
Les Mo/s ce n'est pas vraiment l'intérêt des SSD, c'est assez fatiguant de voir tout le temps ça et pas ce qui compte vraiment, les IOPS.
Sinon, les OCZ ne sont pas vraiment fiables (cf. le lien vers hardware.fr dans un autre commentaire) sans compter qu'il vaut mieux mettre à jour son firmware (même quand tu l'achète neuf tu as pas forcément une version moins pleine de bugs).
Mon conseil est simple : aller chez Intel, qui propose moins de performances racoleuses mais qui est tout aussi rapide pour l'utilisateur, tout en étant beaucoup plus fiable. Le SSD Intel que j'utilise actuellement expose d'ailleurs pas mal d'informations intéressantes via SMART contrairement à l'OCZ que j'ai mis ailleurs (note : ce n'est pas un Vertex 2 ni même un Sandforce, et il fonctionne toujours malgré tous les abus qu'il subit, je me demande juste pour combien de temps).
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: Article nul
Posté par DLFP est mort . En réponse au journal [ HS ] : Pourquoi le gouvernement fait le choix d’une électricité chère et dangereuse. Évalué à 2.
Ah ? Si je regarde autour de moi, c'est majoritairement à l'électricité (tout mes appartements sauf l'actuel l'étaient par ailleurs, pour eau et chauffage).
D'ailleurs j'ai découvert ce que c'était un appart mal isolé dans une région humide qui plus est… j'ai très largement dépassé la consommation électrique prévue :(
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: Euh
Posté par DLFP est mort . En réponse au journal [DÉTENTE] Liste de logiciels débiles. Évalué à 1.
DLFP >> PCInpact > Numerama >> LinuxFr.org
# La POO
Posté par DLFP est mort . En réponse au journal Le problème de la POO pratiquée par des étudiants. Évalué à 5.
C'est CACA.
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: Comme souvent, les gens éteignent leur cerveau en allumant leur ordinateur,
Posté par DLFP est mort . En réponse au journal Toujours confiance ?. Évalué à 4.
Ou des hôtels, qui quand ils te demandent ta carte bleue, ce n'est pas pour la mettre dans un terminal, mais pour noter sur une feuille de papier le numéro.
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: La lecture du fichier marche pas...
Posté par DLFP est mort . En réponse au journal GNU/RTL. Évalué à 10.
$ mplayer http://media.rtl.fr/online/sound/2011/0414/7677115497_et-si-vous-adoptiez-linux.mp3
Pourquoi faire plus compliqué ? ;-)
DLFP >> PCInpact > Numerama >> LinuxFr.org
# Tentative
Posté par DLFP est mort . En réponse au message Découpage d'un fichier EML. Évalué à 3.
Je pense comme les autres qu'il vaut mieux utiliser la librairie de Python pour le faire.
Cependant : déjà tu devrais faire grep -e '^To: ' plutôt que grep -e "To:", sinon tu pourrais récupérer des lignes qui ne sont pas du tout un header.
Et tu devrais séparer le contenu avant de faire le grep des headers. Ils sont séparés de manière très simple : c'est la première ligne vide. Donc quelque chose comme… grep -m1 -n -e '^$' pour obtenir le numéro de cette ligne vide, et ensuite tu peux tail/head.
DLFP >> PCInpact > Numerama >> LinuxFr.org