benoar a écrit 4244 commentaires

Même pas, puisque les cartes flash gardent de coté des blocs de secours en cas de défaillance de certains. J'ai réfléchi à ça car je compte utiliser des CF comme disque principal, mais c'est assez chaud d'imaginer un "bench" qui permetterai de connaître les caractéristiques de la carte (j'ai déjà vu un mec faire ça, mais j'ai perdu le lien ...)

Nan, les 4Mo c'est la taille de la zone sur lequel il wear-level. Tu écris par page ou bloc (ça dépend de la terminologie) de 4Ko environ, mais tu dois effacer par erase block de 128Ko environ, et la carte (puisque dans le white paper on parle de carte CF il me semble) wear-level par zone de 4Mo environ (tous ces chiffres doivent varier en fonction du constructeur, de la techno et de la taille de la carte).

Ce qui est curieux c'est que la Flash ne fournisse pas les deux modes, disque dur pour la compatibilité et 'natif' pour les performances, j'imagine que les quelques cents d'Euros en couts supplémentaire pour le contrôleur doivent être considéré comme inutile..
Heu ... le plus gros problème, c'est que le protocole ATA (et donc SATA) n'est simplement pas fait pour les périphériques non-"block". Ce n'est pas géré dans le protocole, donc ça ne peut pas être géré par le SSD.

Alors après, comme toujours, on pourrait inventer un petit "hack" pour faire passer des commandes MTD classiques par de l'ATA, mais à ma connaissance ça n'a jamais été fait.

Mais on peut espérer qu'à terme les connexions soit directement sur du PCIExpress..
Il faut voir ce que tu veux dire par "PCIExpress", parce que mettre une NAND connectée à du PCIe, ça veut mettre un contrôleur qui utilisera un certain protocole de communication avec l'hôte. Et pour que ce soit pas le bordel, il faudrait que ce protocole soit standarisé. Vu comme est partie l'industrie (i.e. pas dans cette voie, à part quelques exceptions), je ne pense pas que ça arrivera (tous ceux qui voudraient s'y lancer aujourd'hui auront quelques bons wagons de retard sur la concurrence si leur truc ne marche pas "out of the box").

Heu, il me semble que tu fais une petite erreur, on est obligé d'effacer un erase block si on veut écrire dans un endroit déjà écrit auparavant, en effet. Mais une fois que cette zone a été effacée (128Ko c'est pour donner un ordre d'idée je suppose, mais ça doit être à peu près ça), on peut y écrire en plusieurs fois, par page de 4 ou 8Ko environ (encore variable selon les technos/constructeurs/...), jusqu'à la remplir. Sinon ce serait vraiment la galère.

Sinon, pour les problèmes de perf, je pense aussi que les algos de wear-leveling jouent beaucoup sur la lenteur : si c'est un algo merdique (vu comme le domaine doit être blindé de brevets, aussi ...), le fait d'écrire plein de petits blocs va vraiment le faire ramer. Ça plus les problèmes d'erase block, effectivement ça ne donne pas un joli résultat.

Enfin, en ce qui concerne la SDRAM, j'avais lu qu'elle ne servait pas de cache, mais de mémoire "opératoire" pour le chip qui fait le wear-leveling ; il y stocke diverses infos pour faire ses calculs, mais ce n'est pas un cache de données (à vérifier).

Enfin bon, comme d'hab, dans un domaine ou les constructeurs sont peu bavards, on ne peut pas faire mieux que de spéculer ...

Oui et non.

Oui, c'est clair que comme d'hab ce n'est pas MS qui va faire avancer les choses dans le sens des technologies futures ouvertes pour tout le monde (je les aurai bien vu sortir un truc rien qu'à eux .... tiens, d'ailleurs, voir les actus récentes sur l'ExFAT, le FS standard sur les nouvelles cartes SDXC, utilisable uniquement avec Vista SP1 ...). Et que tant qu'il ne se décident pas à bouger, personne ne le fera (enfin si, les libristes, mais tout le monde va encore leur rire au nez).

Par contre, le fait de réutiliser les connexions standards des périphériques magnétiques (ATA et SATA) est quand même un gros avantage, en ce qui concerne les standards matériels.

FTL et MTD ne sont pas vraiment des "modes". FTL c'est le nom de la puce (ou du mécanisme) qui traduit les commandes reçues, spécifiques au périphériques de type "bloc", en quelque chose qui va écrire sur les puces NAND.

Et MTD c'est le nom, sous linux, qu'ont les périphériques NAND qui sont accessibles par leur interface "native" : on ne peut pas choisir d'écrire un bloc au hasard, il faut effacer un erase block si quelque chose avait été écrit auparavant. Et le soft doit aussi gérer lui-même le wear-leveling : c'est un peu demandeur en ressources, mais ça permet de choisir _sa_ technique, et surtout d'évoluer au rythme su soft, et pas du hard.

Dommage que la Flash ne soit accessibles directement comme ça que sur les périphériques embarqués à mémoire inamovible.

PS: il n'existe pas aujourd'hui à ma connaissance de connexion matérielle standard pour relier de la Flash à un ordinateur. C'est con...

Canonical protège son bizness en ne release pas - pour l'instant - des bouts de code qui sont liés directement à son bizness. En gros, qui ne pourrait intéresser personne ... hormis les concurrents directs.
Tu crois pas que des bouts du kernel intéressent plein de monde ? Et que pourtant, certaines parties du kernel sont très spécifiques à celui-ci, et donc quasi non-réutilisables dans d'autres projets ?

Rien ne dit que Canonical ne purge (ou ne purgera) pas certains éléments clés sur ces morceaux de code "critique" et décideront, lorsqu'ils ne seront plus critiques, de les releaser.
Ouai, c'est bien, vive les promesses. C'est ce que tous les libristes et gpl-violations reproche aux constructeurs, de dire "oui, on va le faire bientôt", alors que c'est juste pour gagner du temps et espérer que les gens oublient. Alors, dans notre cas, il ne s'agit pas d'une violation ou quoi que ce soit, mais la phrase "oui on va le libérer bientôt", tant qu'il n'y a rien de concret, je dis que c'est du flan.

Et tiens, pendant que j'y suis, je vais continuer à dériver sur ton post précédent où tu parlais de la méchante concurrence : es-tu pour ou contre la "loi" du marché, le fait de mettre tout le monde en concurrence ? Que penses-tu des conséquences que cela a sur une philosophie comme celle du libre ? Et des manières tordues que tu as de voir les choses afin de pouvoir l'adapter à cette doctrine libérale ?

Pas seulement, toutes les cartes SD/CF/..., clés USB, et SSD, contiennent un FTL (en:Flash_Translation_Layer) qui les font apparaître comme un périphérique de type "bloc", c'est à dire typiquement fait pour les disques durs et autres périphériques magnétiques. Bref, c'est complètement inadapté (il vaudrait mieux pouvoir y accéder comme un périphérique MTD (en:Memory_Technology_Device)) mais c'est comme ça. Et donc on ne peut (enfin, on pourrait, mais il vaut mieux pas) que utiliser des FS faits pour les disques.

Bah non sinon il n'y aurait plus de postes instructifs sur la correction d'orthographe/grammaire/conjugaison ...

Moi j'imagine plutôt un truc du genre "on ne peut que ajouter du texte, au début ou à la fin de son poste", pour garder quand même l'original tout en signalant qu'on a souhaité plus tard le modifier.

Je pense que t'as la bonne réponse, car il me semble que ssh fait un truc du genre "$(SHELL) -c 'arguments passés à ssh'", et que donc ici rien n'est passé en paramètre, donc il lance un bash en interactif ... (d'ailleurs, pour vérifier, tu pourrais essayer de taper des commande quand "il ne se passe rien" pour voir).

Dommage, rythmnbox quitte quand on ferme la fenêtre, et pourtant il est toujours présent dans la barre de notification ...

Oui oui, c'est vrai, excusez-moi. Mais remarquez que je n'ai pas dit qu'ils l'avaient inventé, j'ai juste pris OSX en exemple.

Attend, ressort ta phrase pour n'importe quel autre projet libre, et n'importe quel autre boîte qui fait du libre, et tout le monde, y compris toi, trouvera ça inadmissible. Pourquoi faire une exception pour Canonical ?

Je voudrais pas dire, mais Launchpad me semble être la seule grosse chose qu'ait fait Canonical. Je ne veux pas minimiser le travail des packageurs et autres faiseurs d'Ubuntu, mais le plus gros boulot de Canonical c'est Launchpad, et il n'est pas libre ... ça en dit long sur une boîte qui veut le libre comme sa principale philosophie.

C'est marrant, ce qu'il décrit c'est exactement le dock d'OS X :
- il sert à lancer les applis
- il sert de taskbar (on voit une petite flèche sous l'icône pour montrée qu'elle est lancée)
- il sert pour la notification (l'icône "sautille")

À mon avis ils n'ont pas fait ça pour rien, vu le nombre d'ergonomes qu'ils emploient, et c'est vraiment pas mal. OK, c'est un peu limite pour les notifications car il faut switcher sur l'appli pour savoir ce qu'elle veut, mais des trucs comme Growl palient ces problèmes.

Bon, t'as rien suivi, quoi.

Tu peux très bien faire des libs qui sont compatibles entre Python 2.x et 3. Le "cassage" fait qu'il faut juste changer quelques trucs pour qu'ils passent en 3.0, mais ça restera compatible 2.x.

Attend là, on est quand même en train de comparer un langage interprété à typage dynamique à un autre compilé à typage statique, tu ne peux pas les trouver comparables même à bibliothèque standard équivalente ...

Et en ce qui concerne le "cassage" de la 2.x, faudrait vous renseigner, c'est pas du cassage de tordu : c'est juste pour quelques trucs qui étaient déjà "borderline" ...

Putain mais de quel cassage tu parles ? Python est resté rétro-compatible durant toute la série 2.x (2000-2009, voire plus jusqu'à la fin de la maintenance du 2.6 qui n'est pas pour tout de suite), c'est déjà pas mal, non ?

Les lancés de troll, c'est fait pour être subtil, non ?

Bon, je ne vais pas parler exactement de la même distro, ni des mêmes objectifs, mais les drivers libres ATI marchent très bien avec les cartes récentes : une Debian il y a 4 mois m'a configuré ma HD 3200 sans problème avec le driver radeon.

Certes, je n'ai pas la 3D (d'où le "pas même objectif"), mais ça permet d'avoir un bureau tout à fait utilisable en 2D "out-of-the-box". Ça m'étonne (qu'à moitié, en fait) qu'Ubuntu ne la gère pas ...

Les prix sont dans le PDF en bas de la page. A noter qu'ils sont différents du montant remboursé chez Darty pour cette même marque ...

Je me demande ce que ça va donner cette histoire ...
Rappelons que VIA est connu pour être complètement bordellique vis à vis de sa politique de propriété intellectuelle, que l'écosystème des drivers VIA a toujours été un champ de bataille sans nom, et que Tungsten Graphics appartient maintenant à VMWare, pas très renommé pour son ouverture.

Je ne serai pas si optimiste que ça quant à la sortie sous une licence libre de ce driver ...

C'est marrant parce que il existe l'équivalent de make/ant pour python comme par ex scons.
Gni ? Scons est écrit en python, mais n'est pas destiné pour python à la base ... T'as un exemple ?

Le langage Java est compilé en bytecode.
Le bytecode est en partie interprété, en partie Traduit en code natif "à la volée" (JIT).
Python aussi est compilé en bytecode, et le bytecode est interprété. OK, il ne fait pas encore de JIT à part en utilisant PyPy, ce qui est plutôt expérimental.

J'avais en tête Django, qui me génère automatiquement le fichier de conf (pour faire une comparaison à peu près valable, puisqu'il n'y a pas de compilation). Et on y passe 10 min sur 2 mois de dev ... Quant à la redondance, j'en vois un peu quand même, je pense que si ce fichier pouvais être généré automatiquement à la base ça pourrait être pas mal.