Ph Husson a écrit 2699 commentaires

Bah bien sûr, un disque dur en SATA avec des communications de blocs de 8Ko (si j'ai bien compris la discussion plus haut), est capable de deviner à l'avance si l'ensemble de la communication dure plus ou moins de 512Ko, et sait (à coup sûr !) s'il peut effacer le bloc sous-jacent, ou s'il doit déplacer tout ça (ce qui induit des pertes énormes de perfs dans la bataille). Non, clairement, il met les requêtes en cache, et après il peut décider s'il faut/fallait effacer ou déplacer.
Un FS comme nilfs2 n'a pas besoin de cache de par sa manière même de travailler, il sait exactement et très facilement là où sont les données, et là où il peut effacer. Je ne vois juste pas comment un SSD pourrait savoir ça à coup sûr.

Pas besoin de faire des fsync pour ça ...
La seule utilité du fsync c'est si l'OS plante.

Les SSD des netbooks tiennent plus de la carte SD que du "vrai" SSD.
Pour ce genre de disques, je conseille vivement du nilfs2, chez moi la différence est énorme. (mais attention au garbage collector)

3W c'est ce que mon laptop consomme en utilisation normale :D

nilfs2 est bien un système de fichier pour "SSD", ie pour périphériques flash apparaissant comme des périphériques blocs normaux.
Son principe est significativement le même que celui de logfs, en remplaçant les effacement par des TRIMs. Il reste un peu moins efficace que logfs sur une flash "pure" à cause du wear-leveling qui ne sert alors plus à rien, mais je pense que c'est mineur.
Et sur une carte SD (qui correspond à la définition de "SSD" que j'ai donné plus haut, qui est aussi la définition de SSD à la sortie des EEE, vu que c'était quasiment la même chose que des cartes SD comme technologie...), la différence de performance entre nilfs2 et ext* est énorme, mais avec l'inconvenient assez important de nécessiter un garbage collector (et l'interêt des snapshots automatiques).
Bon après sur un "vrai" SSD, à ma connaissance la différence de performance est assez faible (ils ont assez de cache pour compenser les problemes d'effacement je pense)

C'est pas parce que les médias/politiques disent/font n'importe quoi les agrocarburants que les agrocarburants c'est n'importe quoi.
En particulier, les (micro/)algues n'ont aucun des problèmes que tu cites, et ont des rendements d'au moins un ordre de grandeur supérieur à du colza par exemple.
Donc comme le dit un autre commentaire ici, la question c'est ce qu'on voudrait pour demain, on ce qu'on pense qu'il y aura ?
Ce que j'imagine réalisable pour l'avenir c'est nucléaire + biocarburants à base d'algues (et pas ces imbécilités d'éoliennes ou de panneau photovoltaiques), mais vu les politiques actuelles, je doute très fortement qu'on ait ça.

Euh ... Je me dois de protester.
D'accord à la base OpenTTD n'est qu'un clone/fork/whatever de TTD, mais il a énormement évolué !
En particulier, la gestion des trains permet de vraiment s'éclater à faire de beaux réseaux, avec des trains gigantesques alors qu'avec le jeu original, on ne pouvait faire que des réseaux assez triviaux.

Je pense qu'il parlait par rapport à la consommation de RAM.

Mouais. Le problème n'existe plus depuis longtemps sur les distribs rpm. Concernant le "va plus loin", je ne pense qu'aux trucs à base de qemu dans le binfmt, et dont je ne vois pas bien l'interêt à l'heure actuelle. (bon quand ARM commencera leur phase 2 en vue de la domination du monde, ça servira effectivement)

Et tu sais combien coùtent les 50 moteurs de nao ?

Peut être QoS minimale, "ok, je vous laisse remplir les trous, bon ok suffit d'un abonné qui télécharge comme un porc pour vous bloquer mais bon"

Les cartes graphiques ont du matériel dédié à la décompression vidéo, alors que ça coùte cher aux constructeurs, donc je ne pense pas que ce soit sans raison, et je me demande si faire du décodage par shader est efficace niveau consommation éléctrique.

Si c'est pour se retrouver avec un système qui chauffe encore plus qu'un décodage par le CPU, l'interêt se limite aux petites configs niveau cpu mais puissantes niveau GPU.

Euh ... Un groupe qui a les moyens de se faire un nao du point de vue mécanique, ont les moyens de se faire une carte avec un bon gros FPGA avec 1000 I/Os

je vois pas comment on pourrait "naivement penser" que c'est comme un PC... C'est vendu avec des OSs de smartphones, vendu comme des smartphones (ie "c'est bien pour aller sur internet et jouer".), avec des technologies de smartphone (écran tactile, au lieu d'écran "à stylet").

Même si effectivement je reverrais d'une tablette genre TC1100 en ARM avec l'autonomie/poids qui va avec, je vois pas comment on peut confondre les deux.. Même le nom est différent, le commercial a toujours été fait sur le terme de TabletPC, jamais de tablette ..

Euh non, une tablette c'est exactement comme un smartphone, sauf que ça a un grand écran.

Ça s'appelle un HTC TouchPro(2) :D (mais faut être motivé niveau CPU, et pour meego/android/shr, faut quand même bidouiller, mais j'ai déjà fait tourner les trois dessus)

Porter debian sur smartphone est presque facile (le truc le plus évolué que je connaisse dans ce sens, c'est rhobuntu), le problème est d'avoir des applications utilisables sur smartphone, et ça c'est beaucoup plus compliqué et quasi-inexistant.

java (design pattern, interface, absence de pointer)

Hahahaha très drole ! J'espère que ton post est ironique, sinon j'ai très peur .... En C++ effectivement on peut se passer de pointeurs, en Java par contre, tout est pointeur ... En ce qui concerne les interfaces, le concept d'interfaces en java n'est là que pour palier à l'absence du multihéritage que le C++ a, qui évite de se retrouver avec une difference entre MouseListener et MouseAdapter (par exemple) qui ne devraient n'être qu'une et unique classe !

Euh ...
Le temps de give-up est de combien en SMS ? Il est pas de 2s non plus, sinon on perdrait beaucoup de SMS

Ça dépend, l'adresse cible est cachée ou pas ?

Euh ...
Dire que Zeroconf est une technologie Apple, c'est comme dire que le HTTP est une technologie Microsoft parce qu'ils ont un serveur web ..

Thunderbolt expose une interface PCI Express. Ça ajoute des avantages indéniables sur l'USB 3.0 : accès direct à la mémoire (DMA, d'ailleurs j'espère qu'il y a un mécanisme d'autorisation quand on branche un nouveau périphérique !), indépendance par rapport au processeur.

C'était déjà un des avantages du firewire, pourtant les produits dispo sur firewire et ceux dispos sur usb sont significativement les même.
En ce qui concerne l'accès direct à la mémoire, firewire a déjà fait cette erreur, pourquoi thunderbolt ne la ferait pas :p (plus sérieusement, comment tu voudrais contrôler ça ? des drivers signés ?)

1.2Mbps. À moins qu'ils se paient un bon encodeur ('fin x264 quoi.), ça va être dégueulasse.

La chose moins performante que les smartphones actuels ? :D
Autant attendre la génération suivante (qui est censée sortir très peu de temps après) basé sur du Tegra 2 (3?), qui a un CPU et un GPU nettement plus intéressant

Euh .... On a pas NX = !X ?
Si c'est le cas.... pourquoi rajouter un bit ?