benoar a écrit 4229 commentaires

Bah, techniquement c'est sûrement pas mal, mais bon, éthiquement, le trusted computing ça le fait beaucoup moins ... Bon, c'est juste mon avis personnel, hein (j'ai pas besoin de stage).
On pourrait savoir quel genre de produit vous faites, à quel genre de client c'est destiné ? Ou alors c'est confidentiel ?

Sinon, j'ai envoyé une proposition de stage à l'IFSIC il n'y a pas longtemps, apparemment ils cherchent des stages pour les M1 car il y en a beaucoup (mais le tiens ne correspond pas trop), et pour les M2 aussi mais ça commence à être un peu tard vu leur planning (certains commencent en février, et ont déjà dû trouver, je suppose, mais bon, il y a toujours les retardataires).

En fait, j'ai mal répondu parce que je me rend compte que je n'ai pas compris la question : tu veux savoir quoi exactement avec ce test ?

Pour les problèmes de NAT, l'autre solution s'appelle IPv6. Vous allez gueuler que c'est pas dispo chez votre FAI, mais c'est l'oeuf et la poule : tant que personne ne se bougera le cul pour passer en IPv6, les applis n'avanceront pas, et tant qu'elles n'avancent pas, l'IPv6 ne percera pas.

Quand certains me demandent l'utilité de l'IPv6, bah voilà un bon exemple, le tableau blanc !

Moi j'aurai juste enlevé la virgule ...

Merci du lien, je ne savais pas qu'il pensait ça.

D'un coté, il n'a pas complètement tort, ça permet d'abstraire les différences du hard, et de mieux optimiser le wear-leveling en fonction du matos particulier, même si je trouve sa comparaison avec la DRAM un peu foireuse, vu que ce que fait le contrôleur de la DRAM est très basique par rapport à ce que doit faire le contrôleur de la NAND.

Mais bon, dire qu'on devrait plutôt ne pas acheter le mauvais matos, c'est facile à dire mais pas à faire : en gros, on doit éviter _toutes_ les cartes SD/CF/... qui ont toutes du wear-leveling pourri, et quasi tous les SSD saufs peut-être ceux d'Intel. Ça limite quand même beaucoup le choix ...

Sinon, moi la chose qui me plaisait dans le "raw access" à la flash, c'est le coté on est libre de wear-leveler comme on veut.

Comment se compare-t-il aux wikis qui utilisent la syntaxe de reStructuredText [http://docutils.sourceforge.net/rst.html] ?

Non, je voulais dire qu'au contraire, quand tu fermes rythmnbox, il quitte l'application, ce qui n'est pas le même comportement que d'autres applis qui sont "présentes" dans la systray (comme pidgin par exemple). C'était la différence de comportement que je trouvais "dommage", pour donner un contre argument au commentaire auquel je répondais.

Heu, un secteur effacé une fois n'est plus lisible par le disque. La méthode que tu préconise (écrire plusieurs fois) n'est valable que pour les gens qui sont prêts à démonter le disque et y aller avec du matos très spécifique et très cher. La sécurité c'est une question de moyens qu'on y met, et il me semble que le but ici n'est "que" de se prémunir du cas où quelqu'un va "simplement" vouloir trouver des données non-écrasées sur le disque ...

Un peu comme il est dit plus bas que le chiffrement peut se faire en soft, c'est la même chose pour la QoS !
Il me semble que la QoS des cartes wifi se base sur quelques files (queue) hard classées par ordre de priorité. On peut faire ça en soft sous linux avec des qdisc et tc, et bien plus !

Bah, c'est juste que si t'as lancé du gros troll, ta correction va se retrouver 15km plus bas ...

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.