Guillaume Knispel a écrit 2474 commentaires

Même si je connais pas trop ça m'a l'air de ressembler pas mal à un Cell toussa. Pour ressembler à une CG moderne il faudrait pas aussi un moyen d'augmenter massivement le parallélisme des ALU ? Et peut-être d'avoir des modèles comme le SIMT (vrai questions je ne connais pas assez le milieu pour savoir si c'est toujours à l'ordre du jour)

Le problème c'est qu'à programmer sans moulinette magique qui te mâche le boulot, c'est chiant (les développeurs de jeux vidéos sur PS3 semblent majoritairement de cet avis). On y arrivera sans doute mieux depuis l'écosystème PC (les drivers de CG, CUDA et autre semblant faire office de moulinette magique acceptable) que depuis ce que Sony avait proposé aux développeurs, mais reste à voir quel ouverture va avoir un tel écosystème. Si on reste dans l'état présent où les meilleurs moulinettes sont propriétaires et celles libres sont au mieux moyen-moins (et que sur du matos lui même moyen-moins) c'est mal barré.

Reste aussi que pour les x86 ça ne fera pas disparaître la taille prise sur le die par la cohérence de cache pour le jeu d'instruction x86 généraliste. (Mais en fait je ne sais pas quelle proportion ça représente, donc si ça se trouve OSEF)

Le jour où un employé de Casino (ou autre) choppe une gastro en mangeant un truc périmé d'un jour, bim procès.

Tu t'es cru aux states ?

Dans une optique très traditionnelle avec deux partis majeurs peut être que ce système est moins pire que d'autres variantes. Mais mathématiquement, même si on a prouvé qu'il n'y avait pas de système de vote permettant de satisfaire simultanément l'intégralité de tout un tas de critères qui seraient souhaitables, celui là est quand même un des plus pourris... :/

Il s'agit de politique. Chef de guerre, je ne sais pas exactement ce que c'est mais si ça ressemble à général alors ça ne serait pas plus malin de le tirer au sort que de tirer au sort un mec dans la rue pour qu'il t'opère.

De plus, il serait souhaitable de ne pas prendre les partisans du tirage au sort (au juste ceux qui en parlent) pour des abrutis : l'idée n'est évidemment pas de proposer un pack tout compris (de la vente liée ? :p ) au sein duquel les femmes n'auraient pas le droit de se présenter et seraient cantonnée à la cuisine, ainsi le rétablissement simultané de l'esclavagisme.

D'une manière générale il est souhaitable de regarder la vidéo proposée ou de s'informer sur le sujet par tout autre moyen avant de sortir des arguments hors sujet (ou, j'anticipe facilement contrable tels que "oui mais on pourrait tirer au sort des connards")

Sur x86 il y a zéro chance que le modèle mémoire "de base" soit relâché (rétrocompatibilité, toussa), même s'il serait tout à fait envisageable de requérir explicitement un modèle mémoire plus laxiste (c'est déjà possible principalement pour pouvoir faire de l'IO et des frames buffer pas trop moisis). Néanmoins étant donné que le modèle de base doit survivre, la place prise sur le die pour l'implémenter restera...

Sur ARM je sais pas trop, je connais pas assez (et en plus il n'y a pas de plateforme ARM équivalente à la plateforme PC, même si l'arrivée de windows 8 va probablement changer fortement la donne sur ce point)

Le vrai problème est que Apple s'érige en censeur sur plateforme IOS. Le fait de bannir flash serait en soit grandement bénéfique puisque flash est une technologie primordialement privatrice. Mais l'intention d'Apple n'avait absolument rien à voir avec cette raison, et il est probable qu'aujourd'hui l'iPhone & co cause 10x plus de dommages que flash en son temps.

Enfin bon, là dans ce cas présent je propose le lait à la communauté. Si je voulais vraiment le beurre et l'argent du beurre, je ne penserais pas à l'open source.

Quelle communauté ? Celle que ton projet indéterminé pas libre ni open-source ne manquera pas d'attirer ?

Worse is better aussi parce que la simplicité permet la souplesse à bas coût. Faire des usines à gaz, c'est interdire de les attaquer par les outils traditionnels Unix habituels génériques. The Right Thing n'est souvent que Right dans la tête et pour les besoins du concepteur. À voir les conceptions de Lennart, elles sont sans doute d'un très bon niveau mais ressemblent fortement à Win32 : une API géante avec des interdépendances de partout, et fuck les adeptes de la philosophie Unix.

Ça ne me gênerait pas si ce n'était pas fait par un type et une boite qui ont une telle influence sur l'écosystème, car d'un point de vue égoïste j'ai juste envi de continuer tranquillement d'utiliser un GNU/Linux qui ressemble dans sa philosophie technique à un Unix (même si l'érosion a malheureusement débuté depuis quelques années) et non à un hybride Unix-Windows mal fini.

À mon avis tout ce bordel relève du complexe de "oh mon dieu "Linux" est toujours pas prêt pour le desktop" qui est une connerie phénoménale (pas le diagnostique mais la malheureuse conclusion que certains veulent en tirer qui est d'essayer de le rendre prêt, et qui font des choses inadaptés pour et qui niquent toute la philosophie en passant) et aujourd'hui encore plus une connerie qu'avant vu les nouveaux marchés (téléphone tablette "cloud") et la pérennité de ceux existants sur lesquels GNU+Linux sous philosophie Unix à du succès (serveurs, box).

Quand j'ai la diarrhée je suis moi aussi prolifique d'une substance dont pourtant personne ne raffole.

Le problème par rapport à l'unilatéralité qu'on retrouve souvent ailleurs et qui fait moins bondir notre microcosme dans ces autres cas est que dans ce cas là RH a une position importante et ambiguë dans le monde des distro GNU/Linux, et que là elle est de plus à la fois upstream et distributeur (majeur).

Heureusement, le noyau ne tombe pas dans ce travers

Linux fournit de la retrocompatibilité dans ses interfaces externes.

Concernant ton argument plus général, l'idée principale du journal cité n'est pas de refuser l'évolution mais de débattre de la solution proposée, notamment à la lumière des autres solutions existantes, et de tenter d'analyser le comportement de RH vis à vis de leur plateforme et l'implication pour les plateformes GNU/Linux en général.

L'euro fort n'est pas forcement une bonne politique pour tout.

nos enfants ne pourront plus emprunter (plus de confiance dans les taux --> Emprunts très chers), eux seront niqués.

L'emprunt c'est très sympathique à petite dose.
A grande dose, hm, not so much.
Quant à niquer les banques, il faudrait déjà avoir l'assurance qu'elles ne sont pas inversement en train de niquer le reste de la planète (peut-être pas complètement volontairement pour certains rouages du système d'ailleurs.)

Oui, de même si on fait exploser une bombe nucléaire elle rasera pas mal de choses et certains propriétaires seront embêtes par la destruction de leur logement.

En quoi le fait que le public possède partiellement une boite fausse intrinsèquement la concurrence ? Attention je ne dis pas non plus que c'est impossible et dans le cas Allemand cité en question, je n'en sais rien. Mais il n'y a rien qui oblige intrinsèquement à ce que ça soit le cas.

Et de toute façon même si c'est le cas en quoi c'est forcement mal ? Le dogme de la concurrence libre et non faussée a prouvé que c'était juste de la merde en boite lorsque poussé à l'extrème. D'ailleurs absolument personne de sérieux ne considère ni n'a jamais considéré que ce modèle simpliste est un modèle pertinent au delà de conditions strictes qui ne sont remplis que partiellement sur les marchés les plus chiants et presque pas si ça devient un chouilla plus intéressant. Donc l'ériger en grand principe inaltérable est vain.

les centrales de prochaine génération (EPR) seront capables de ne tourner qu'avec ce seul combustible.

Complètement faux. Elles peuvent très bien tourner avec de l'uranium enrichi.

Tu as du lire "ne seront que capable de tourner" au lieu de "seront capable de ne tourne qu'avec"

Une déflation massive de la monnaie, c'est une inflation (vu l'effet attendu) ? où c'est un truc super ouf ?

Et toi tu fais semblant de pas comprendre que le multiprocessing élimine toute une classe de problèmes, et est donc très important pour permettre aux neuneus^W^W à tous de programmer, au même titre que les langages managés. Comme j'ai précisé, on peut transiger dans de nombreux cas. Mais pour en revenir un peu à la choucroute l'argument initial pour firefox de "oh mon dieu nettoyer vraiment toussa c'est dur et tout, faisons plutôt des trucs biens à court terme" est in my not at all humble opinion un mauvais calcul pour les deux raisons magiques en question : stabilité (sur un code volumineux on obtient des effets statistiques, donc la stabilité serait mécaniquement meilleure si l'architecture cherchait à empêcher des classes de pb par sa conception), accessibilité aux contributions. Je peux en ajouter d'autre : revues et raisonnements plus faciles...

Sur la multiprogrammation, je ne sais pas si j'ai tout compris, mais en tout cas j'ai compris pas mal de chose en effet. Mon taf m'a amené à débugger du code multithreadé dans divers couches télécoms libres, où malheureusement les fameux deadlocks se ramassent à la tracto-pelle. Bref, en résumé, j'ai nettoyé à moultes reprises la merde laissée par d'autres, qui pensaient sans doute être suffisamment malins pour ne pas avoir fait caca partout. A voir certaines immondices je suis certain d'être plus malin que certains d'entre eux, mais sans doute pas que tous. Partant de ce constat, j'estime qu'il est futile d'étaler sa maîtrise du multithreading ad-hoc car soit on est juste plus mauvais qu'on croit et on fait caca partout, soit certes on fait un truc qui fonctionne, mais celui qui passe après ne va pas comprendre toutes les subtilités et le château de carte en équilibre instable va finir par s'effondrer. Ce schéma transparaît clairement dans le code de nombreux logiciels. Seules des revues poussées permettent d'éviter cela (cf. Linux) mais tous les projets ne les imposent pas et/ou les revues peuvent être inapplicables dans certains contexte (exemple : plug-in tiers), et si une architecture permet d'avoir des revues moins poussées et/ou de tolérer un peu plus du code tiers buggé alors elle est préférable. (On peut aussi choisir la solution très tendance du moment de MS et d'Apple : interdire les plugins.)

C'est pas des arguments d'autorité toussa (de quelle autorité d'abord ???), c'est des règles d'ingénierie et des constats de gestion de projet logiciel. Mais je sais, je sais, l'ingénierie c'est plus vraiment à la mode.

Libre software : Terme poussé par des personnes dans des pays anglophones, très peu dans les pays francophones et hispanophes, contrairement à ce qu'on pourrait penser. Avantage, clair. Inconvénient : Pas massivement adopté (voire même carrément confidentiel).

Ah. Et on a aussi arrêté de dire "logiciel libre" en France ? Et plus généralement on s'est tous mis à parler comme Van Damme ?

Si tu veux un système léger et instable, utilise windows 3.11 (ou mac os 5 ou je sais pas combien)

Question sans intérêt.

Question sans intéret de savoir si on prend dès le départ le risque que ça plante après avoir fait le constat que 3/4 des programmeurs ne comprenent rien à la concurrence, ou si les revues sont particulièrement bonne de se priver des 3/4 des programmeurs qui ne comprennent rien à la concurrence ???

Ce qui compte c'est de savoir quel modèle permet le plus facilement d'écrire des applications avec des opérations concurrentes.

Le multiprocessing, car alors on n'a pas à se soucier des problèmes de corruption, deadlock, etc., dus aux erreurs de synchronisation.
Les GUI sont typiquement dans un seul thread donc très mauvais exemple puisque le multiprocessing non seulement se fait naturellement dans ce cas mais permet d'augmenter les perfs des multiples GUI sur un multiprocesseur. Après dans certains cas on peut transiger et utiliser uniquement un modèle de message passing dans une application multithreadée (ce qu'il vaut mieux faire pour éviter de jouer avec le feu si on veut vraiment faire du multithreading, surtout en prévision d'un projet à long terme)
Malheureusement les GUI ne sont pas le seul domaine dans lequel l'architecture est à la ramasse et on trouve aussi des horreurs sans nom dans des logiciels télécoms libres très connus.

Il y a combien de personnes capables de partager correctement en multithreading des choses avec des pointeurs (hors trucs triviaux genre const char *, ou hash table avec un big lock) ?

Vaguement meilleures ? Je n'ose pas imaginer les perfs du multiprocessing sous Windows, qui n'a pas de fork() (et donc pas d'optimisation copy-on-write non plus). Ça doit être super 50 processus Firefox à 50 Mo de RAM chacun...

Chrome fonctionne très bien sous Windows.

alors qu'entre des threads le partage est implicite et sans limite arbitraire

Oui, et c'est justement le problème...

Dans la vraie vie sur du vrai matos moderne, les blocs n'évoluent pas indépendamment. Le dernier contrôleur graphique intégré à la mode à besoin d'interagir avec différentes couches de contrôle de la mémoire soft et hard par exemple. Fournir une archi adéquate n'est pas triviale en monolithique et le passage en micro-noyaux ne la rend certainement pas plus facile, surtout si en plus on veut garder des perfs convenables.

Le truc c'est que le domaine du serveur a été attaqué par le côté contrôleur de domaine. À partir de là c'était plus facile de détourner le reste des application Unix sur des serveurs NT existants surtout à une époque ou on n'installait pas des VMs partout en criant "AHHHHH LAVEZ VOUS LES MAINS GRACE AU CLOUD COMPUTING" (seuls quelques initiés apprécieront ce pétage de câble à sa juste valeur)