benoar a écrit 4229 commentaires

D'après ce que j'ai compris, le jumper sur les WD sert uniquement à mettre l'alignement à -1 bloc en cas d'OS ne pouvant pas être aligné (de façon à ce que le 63 bloc soit aligné).

Pourtant, je peux parfaitement ne pas utiliser la Livebox et mettre n'importe quel autre modem à la place.. C'est à se demander ce qui leur est passé par la tête en écrivant ça.

Et ton autre modem, tu peux le flasher ? Non, il doit aussi respecter la législation en vigueur ...

Regarde un peu ce qui s'est passé pour le N770, puis pour les N8x0, et tu comprendras peut-être un peu mieux.

La fragmentation n'est pas "géré", il est fait comme si elle n'existait pas avec un pseudo système journalisé, qui forcément dégrade les performances pour faire les copies quand il n'y a plus de place dispo.

Je parle de la fragmentation sous la forme du wear-leveling : au contraire des disques classiques, il faut essayer de répartir les écritures sur le plus de zones possibles (enfin, tout en rassemblant les données le plus possible dans des blocs entiers).

Un "TRIM", c'est juste un "erase" pour rendre le secteur vierge.

Oui, et ? Sans TRIM, tu copies l'équivalent de la capacité de ton disque dessus et tu n'as plus aucun secteur libre ...

La taille des zones peut être lu sur les SSD.

C'est arrivé avec le 2.6.31 quand même ... Mais surtout, je n'ai vu absolument _aucun_ constructeur communiquer dessus. C'est un secret industriel qui n'est que rarement dévoilé. Et j'ai vérifié sur deux SSD chez moi (un "maison" avec des cartes CF, et un Photofast) et aucun n'indique sa taille de "bloc" (d'ailleurs, normalement un SSD n'a pas vraiment de zone (enfin, c'est flou, comme tout ce qui tourne autour des SSDs) contrairement aux SD/CF, car il fait du wear-leveling sur tout le disque ; on pourrait par contr ese demander quelle est sa taille de page et la taille des erase block).

Cela serait bien plus propre gérer au niveau FS. C'est "juste" une couche supplémentaire.

Oui enfin bon, là, cette possibilité, ça fait "longtemps" que les constructeurs l'ont oublié. Maintenant il faut faire avec ...

Bon, en fait ce n'est pas exactement un problème de fragmentation dont je parle, mais de l'histoire d'arriver à faire du wear-leveling correct, surtout quand le disque devient plein (donc encore plus problématique quand le SSD ne gère pas le TRIM). Les performances et la longévité du SSD vont grandement diminuer quand le SSD ne trouve pas facilement de place "libre" pour écrire tes données. En plus, s'il faut qu'il libère un bloc avant de pouvoir écrire (dans le cas où peu de blocs sont disponibles), tu vas avoir droit à un cycle de read/modify/write de la taille d'un erase bloc (plusieurs dizaines de ko, voire plusieurs mégas pour les SSD dans le futur, cf http://www.hardware.fr/news/imprimer/10713/ ), ce qui va prendre du temps.

Mais effectivement, ce n'est pas une histoire de temps d'accès dû à une contrainte physique ; c'est la "logique" derrière qui peut ralentir.

Tu n'as pas du bien comprendre : les SSD utilisent bien ce même "hack" (si tu veux l'appeler ainsi). Ils ont des blocs physiques de 4ko ou plus, mais exposent des blocs logiques de 512o. Comme tout périphérique de type bloc depuis des dizaines d'années. Parce que sans ça, ils ne fonctionneraient pas avec un Windows inférieur à Vista.

D'où le problème que tu cites avec l'alignement, qui est exactement le même sur les WD. C'est dû au décalage taille de bloc physique / logique qu'on trouve dans ces deux types de disque.

Le truc c'est que si tu fais des disques avec des blocs logiques de 4ko, tu peux dire bye-bye à tout Windows inférieur à Vista. Ce qui aurait fâché trop de gens ...

Il a déjà été montré plusieurs choses (dont je n'ai plus les références malheureusement) :
- adapter le kernel à une taille de bloc supérieure à une taille de page (4ko) serait un travail énorme
- le choix de 4ko est un compromis par rapport à l'utilisation qui est faite des petits fichiers

Bref, ce n'est pas si facile à changer, et surtout, ça a été réfléchi avant, quand même.

Les expressions régulière tel que présentées plus haut ne posent pas de problèmes avec les " n'importent où.

Et si, dans le cas où on a un guillemet échappé dans la chaîne ... OK, tu vas me dire, "ça arrivera jamais, aucune ville n'a de guillemet dans son nom", mais "on sait jamais" ... (je ferais bien plus attention aux erreurs de traitement qui pourraient par exemple intégrer un guillemet inséré à cause d'un bug de double échappement ou un truc du genre)

Ma "logique" c'était que tant qu'on a une lib qui suit la "norme" sans se prendre la tête avec les regexp, tout en ayant un langage qui permet d'aussi facilement l'utiliser, autant en profiter.

Enfin, mes excuses pour la pique sur les "vrais langages", c'est vrai que j'ai vu des morceaux de sed et awk assez impressionnant sur ce forum.

Moi je parle de problème de consistance des données en cas de "panne". Actuellement, une écriture de 512 octets est garantie pour être atomique (i.e. quand tu envoies l'écriture au disque et qu'il valide la commande, tu peux être sûr que c'est bien inscrit sur le disque, et pas en cache), mais pour 4ko (physique, et toujours 512o logique) je ne suis pas sûr, vu qu'il faut faire un read de 4ko, modifier les 512o, et écrire 4ko. S'il y a une coupure en plein milieu, je ne sais pas si le disque a le temps ou non d'écrire tout et de garantir l'atomicité.

La fragmentation est gérée en interne par le disque, alors l'OS n'y peut pas grand chose (et rien n'est prévu pour l'instant pour y donner "accès", au moins en lecture, dans les specs ATA). Par contre, la gestion du TRIM va grandement aider le contrôleur du SSD à "faire le ménage" dans ses tables et à éviter de trop fragmenter.

Ha effectivement, je viens de vérifier, et mes ext3 ont effectivement des blocs de 4ko. Attention, on parle bien ici des blocs du FS, pas du disque.

Mais donc cela devrait faciliter le problème de l'atomicité dont je parlais, et dont j'avais surtout entendu parler avec les SSD (qui ont des erase block encore plus gros). Je ne sais tout de même pas vraiment si ces 4ko sont utilisés comme "unité atomique" lors de l'écriture ; ils le sont en tous cas, et c'est leur premier rôle, pour l'adressage des blocs sur le FS.

Oui, effectivement. J'en ai une sur un portable acheté d'occasion, et donc comme j'avais "moins le choix", je fais avec, en utilisant nouveau.

Le CSV a beau être un format un peu bâtard, il existe certaines "normes" qui sont implémentées par les librairies adéquates. En particulier, enlever les guillemets doubles à l'arrache, pourquoi pas, mais on sait jamais, si une donnée est formatée un peu bizarrement ...

Bref, le code, en utilisant csv, en python :

import csv
for line in csv.reader(file("villes.csv")):
  print line[0] + line[1] + line[2]

Encore plus lisible que les solutions précédentes.
Et le mieux, c'est que comme tu es dans un vrai langage, tu pourras même utiliser les bindings SQL pour intégrer ça dans ta base ! Genre, après avoir récupéré un curseur "c", mettre dans la boucle :

c.execute("INSERT INTO matable (pays, ville, num) VALUES ?, ?, ?", line)

Voilà, je trouve ça encore plus efficace que les solutions précédentes.

linux utilise par exemple déjà cette valeur pour stocker les données dans des blocs logiques

Tu aurais une référence pour ça ? Je ne suis pas sur que ce soit vrai ... Linux a déjà la possibilité de s'adapter à des blocs physiques de taille autre que 512, mais là je ne vois pas ce dont tu parles.

Ensuite, j'espère que les FS qui font attention à l'atomicité des écritures sur disque vont être adaptés pour les disques 512o logiques/4ko physiques qui arrivent, car les cycles de read/modify/write changent un peu la sémantique du truc.

Les blocages : principalement les blobs et la gestion de projet vue par Nokia.

Les blobs, c'est connu, on sait que c'est ce qui tue le libre sur le long terme, mais ça se fait toujours. Le N900 aura le même problème (obligé de rester avec des vieilles versions des softs, etc).

Pour la gestion du projet, Maemo est très tenu par Nokia et très peu de décisions viennent de la communauté. Nokia est même très critiqué pour sa gestion de l'aspect communautaire dans Maemo. De plus, c'est une distro un peu spéciale, qui n'est pas si facile à gérer de la part d'une communauté qui n'est pas forcément spécialisée dedans.

On a même vu un fork de Maemo pour ses problèmes de blobs : Mer. Qui est fait par .... Nokia Brésil !

Effectivement à voir : il se tape Balkany, qui est sur le plateau. Enfin, le pire c'est que quasiment tout ce qu'il dit est vrai, et qu'on en rit ...

C'est énervant de devoir toujours "attendre". Le driver nouveau avance lentement parce que très peu de monde l'utilise !

C'était comme lorsque les devs du kernel utilisaient Bitkeeper : ils se disaient que les outils libres évolueraient pendant ce temps, et qu'ils en choisiraient un un peu plus tard. Et puis en fait non, tous ont stagné et au moment où le logiciel proprio leur a fait un coup de pute, paf, il a fallu refaire son propre outil à la va-vite. Mais le pire, c'est que ça a bien marché !

C'est pareil avec Nvidia. Déjà, moi j'ai vu un beau coup de pute avec les pilotes "legacy". Mais personne ne bronche, et garde un vieux Xorg avec. Mais bon, ne faites rien et passez votre temps à attendre ; moi je vous dis que si personne ne fait rien, la situation actuelle de nouveau perdurera encore un bon bout de temps.

Effectivement, la voix se vautre sur les accents : ça commence par "axe dère" pour accéder ... En plus, pleins d'images n'ont pas de alt, il lit l'URL. Bref, pour moi c'est un _mauvais_ exemple.

Sinon, en dehors de la critique justifiée que normalement, la personne visitant ce site aura normalement déjà le logiciel pour lire la page, il faut noter que l'audio est disponible en mp3 direct (lien en bas de la page), donc on "peut" éviter flash.

Merci pour ces vidéos, et la couverture des évènements traitant du libre dans l'embarqué (Free Electron a effectivement fait pas mal de bonnes vidéos). Ça fait de bonnes ressources pour mieux découvrir un projet.

Tu viens de trouver l'intérêt des choix par défaut ...

Ben tu vois on y arrives, tu reconnais que la moitie de la planete n'a pas de solution 100% libre.

Ce n'est pas parce que des cons ont décidé que tes idées ne leurs plaisaient pas qu'il faut en déduire qu'elles ne sont pas valables. Chacun se bat pour sa vision des choses, et pour n'importe quel libriste, selon moi, s'il a fait un bout de code dont il a le droit d'auteur, s'il a envie de le mettre sous une licence libre, alors ce logiciel l'est.

Quand au materiel, TU as du matos 100% libre, moi je te parles de monsieur/madame tout le monde, quelle est la proportion de gens qui pourraient installer une distrib 100% libre sur le PC qu'ils ont a la maison aujourd'hui et en utiliser tous les peripheriques ?

Vu la proportion d'Intel (avec ses intégrés), je pense que pas mal de monde le pourrait.

Bon, en plus t'as l'air sérieux ....

Oui, il fait du H264 en libre (via ffmpeg), comme il fait du divx ou du mp3 ... Ha oui, j'habite en Europe. Donc les brevets je m'assoie dessus. Mais ça n'empêche pas que ceux qui ont codé ffmpeg ont créé eux-mêmes de leurs petites mains ce logiciel, et l'ont distribué sous une licence libre. Ils n'ont eux-mêmes aucun accord de brevet dessus.

Pour le matériel, oui, 100% libre (sauf les firmwares, OK ...) c'est du ATI/AMD. J'aimerais bien avoir des firmwares libres, mais pour l'instant ce n'est pas réaliste, et peu de monde fait mieux.

J'ai un ton un peu agressif parce que je n'aime pas les projets où il y a plein de secrets dont on ne doit pas parler. C'est pour ça que je préfère nettement le libre : tout est public, ouvert. Pour moi, le secret c'est ce qui tue tout le développement de logiciel propriétaire, et je peux te dire que j'ai bossé dans des boîtes où plein de truc ne doivent pas être dits/transmis ; et bien c'est les pire endroits où travailler.

Sinon, en ce qui concerne ton problème, ça "m'énerve" (je sais, je m'énerve pour un rien ...) de se refuser à des solutions simples quand on a des contraintes débiles. (oui, je sais que des fois on doit faire avec des contraintes, mais là, se refuser d'accéder au shell, ça me paraît débile) Comment tes règles iptables vont-elles être "rentrées" sur le serveur en question ? Il y aura bien un programme qui va lancer iptables avec les bons arguments ? Ou appeler la librairie qu'il faut. Et ce programme ne peut pas faire de conditionnelle en fonction du serveur sur lequel il se trouve ?

peu étonnant qu'on obtienne les meilleures perfs quand on peut copier toutes les données d'un côté à l'autre en restant dans le cache...

Oui, je pense que tu as trouvé la vraie raison des chiffres de ce test.