Guillaume Knispel a écrit 2474 commentaires

Un des critère de distinction est le déterminisme de la libération, et bien que l'état de l'art des GC soit impressionnant, il reste en dessous des shared_ptr.

Reste que conceptuellement la sur-utilisation des shared_ptr est un problème lorsque l'on utilise des objets dont le contrôle de la durée de vie est important: mieux vaut un système pour interdire statiquement les utilisations (ou tentatives) trop tardives. Mais a défaut, c'est sûr que mieux vaut souvent une logique impropre à cause d'une durée de vie trop allongée (ou une suppression des derniers accès—ou un crash déterministe suite à la détection déterministe dynamique du problème) qu'une undefined behavior.

Arrêtez moi si je dis une connerie mais je crois bien que Rust est intrinsèquement conçu depuis le début pour, entre autres, intégrer de la sûreté poussée dans son type system relativement au multithreading. Bien meilleure que le C++, ça va sans dire (le C++ même le plus moderne ne propose jamais de sûreté garantie ou au pire d'identifier explicitement de manière obligatoire les sections de code potentiellement dangereuses, la moindre "mauvaise" utilisation de tout truc ressemblant conceptuellement à une référence engendrera potentiellement un UB, la plupart du temps sans aucune détection statique, et ça inclut par ex les string_view tout neufs)

Et en pratique, dès que vous avez 2 threads (pour de la concurrence) dans un programme non trivial qui ne propose pas de garantie sur ce point, vous avez des tonnes de data races (sauf théoriquement s'il a été écrit intégralement par des experts de ce domaine, mais cette théorie ne se réalise pas en vrai, de plus ce type de raisonnement permettrait de conclure qu'on peut concevoir n'importe quoi parfaitement avec n'importe quel langage de merde et sans aucune analyse statique automatique, donc étant donné qu'on n'est plus en 1950 je considère que cette approche n'est plus pertinente)

Ouai je rouscagne, parce que c'est franchement la loose que la première chose qui accueille les visiteurs du site d'une des plus hautes institutions françaises, c'est Macron en train de sucer symboliquement la bite de Zuckerberg. Et me relance pas sur l'aspect sécurité du bouzin, surtout au moment ou Chrome est en train de basculer vers l'avertissement par défaut que les sites non-https sont non dangereux (ce qui est vrai).

L'App Store d'Apple n'est pas que en "position dominante" en direction des smartphones iOS. Il est intrinsèquement en situation de monopole, par construction.

Je connais pas suffisamment le droit, mais ça m'étonnerait même pas que l'EU juge ça illégal un jour ou l'autre.

La liberté consisterait aussi a pouvoir vendre sur un marché gigantesque autrement qu'en passant par son organisateur arbitrairement obligatoire qui taxe 30% au passage. Ou alors on dit qu'Apple est un état et que les 30% c'est sa TVA? On attend toujours de voir la redistribution des "taxes" en question par contre :p

C'est une question de taille, et la limite sera forcement un tantinet flou. Mais clairement pour Apple, elle est dépassée. Pour Google sur le point unique des magasins, c'est plus ambigu, vu qu'ils autorisent les autres magasins ainsi que les installations de programmes sans passer par un magasin. Et vu leur condamnation et leur position, ils ne vont probablement pas changer ça vers plus de restrictions…

Quand tu es minoritaire, tu n'es pas en situation de position dominante. Tu peux donc faire des choses que tes concurrents dominants n'ont pas le droit de faire, et s'ils le font tu peux te plaindre qu'ils abusent de leur dominance.

Certes MS l'a été dans d'autres contextes et en a alors aussi abusé, et a été condamné d'une manière similaire. Mais concernant les smartphone sous Windows, ils ne l'ont jamais été.

Pour en revenir au schmilblick, à la décharge de Google il faut se souvenir de ceci: https://www.statista.com/statistics/266136/global-market-share-held-by-smartphone-operating-systems/ . Jusqu'en 2011 Android n'était pas majoritaire. Google a eu le temps de construire un système dans un autre contexte, et n'a pas su le remettre en question, quand, le contexte changeant, ils se sont retrouvés dans des pratiques illégales. Mais cette inertie (et en fait plus probablement cet aveuglement/obstination/comportement de rapaces, vu qu'ils contestent) a été bien pratique pour eux, et à leur taille ils ne pouvaient que être conscient de ce qu'ils faisaient.

Ça reste par définition un langage de prog, et donc des lignes de code. Dans un langage assez peu pratique pour faire des lignes de code, mais des lignes de code quand même.

Des tentatives proches de créer de tels langages prétendument pour les moins "techniques", voire pour les non techniques, ont ponctué l'histoire de l'informatique y compris à ses tous débuts, avec invariablement le résultat le plus prévisible qui soit, qui est qu'on a juste au final un très mauvais langage peu adapté vu qu'il est invariablement peu expressif, peu puissant, et/ou peu précis pour ce qu'on en fait, utilisé par des testeurs (dans ce cas, mais ça peut aussi être développeur, selon les langages) qui ne s'en servent pas de manière juste occasionnelle, donc qui passent du temps à faire tout cela, et qui donc pourraient et devraient investir ce temps à apprendre un vrai langage (au début de l'histoire de l'info y avait parfois pas d'autre choix, mais on a fait des progrès depuis…)—de toute manière leur technicité va forcement augmenter sauf que là on les fait apprendre un truc de niche avec tous les inconvénients que j'ai cité, au lieu de leur faire apprendre des trucs puissants généralisables dans d'autres domaines - voire même intrinsèquement plus puissants pour faire de meilleurs tests couvrant plus.

Alors évidement ça fonctionne quand même. Tout comme le Cobol a fonctionné au point qu'on en a encore en quantité astronomique. Est-ce que son pari de simplifier l'info en écrivant des conneries à là "ADD NUM1 TO NUM2" au lieu de NUM1 += NUM2 a permis, pour faire un parallèle, à des "fonctionnels qui ne savent pas écrire une ligne de code" de comprendre la programmation ? Je ne crois pas. Je ne crois pas non plus que les projets de tests utilisant le Gherkin qui réussissent le fassent grâce au Gherkin.

Pas du tout le même profil de perf en tout cas, et une ptite clef USB est à des années lumières d'un bon SSD. Et les algos de wear levelling n'impliquent pas que les accès random n'auront pas de latence supplémentaire par rapport aux accès linéaires.

Même l'Optane, qui a des perfs qui défoncent la plupart des SSD dans la plupart des workloads, conserve une latence en random par rapport à du linéaire. Faible, certes, mais mesurable. On verra pour l'Optane en DIMM si ça sort un jour, mais en fait même la RAM a cette propriété… :p Faut vraiment atteindre les caches les plus bas pour que ça soit plus le cas.

L'augmentation de la conso due aux switch est linéaire avec f. L'augmentation due à la tension est quadratique avec V. Au delà d'une certaine f il est nécessaire d'augmenter V.

Il parle d'une clef USB, pas d'un disque SSD.

D'un autre côté, si iOS triche lors des bench en débridant des limites habituellement utilisées pour limiter la conso, ça donne une encore meilleure idée à ce qu'il sera possible de faire sur laptop.

Pour être franc je pense même pas qu'il y ait un tel comportement, et de toutes manières le ressenti des utilisateurs correspond globalement aux bench "synthétiques". Enfin les bench synthétiques sont consistant entre les différentes générations de proco Apple et d'avant. En plus c'est relativement facile de "débrider" les téléphones Android pour faire des bench et personne n'a réussi a les faire remonter au niveau de l'iPhone X avec cette technique… et encore une fois ça voudrait pas dire grand chose pour l'affaire qui nous intéresse, ça voudrait juste dire que en plus yaura ptet des laptops Windows ARM qui rament pas trop, du moins en code natif.

Après certes s'ils consomment déjà "trop" durant les bench, c'est plus dur pour Apple de progresser encore plus. Mais Intel est aussi soumis à la physique des semi-conducteurs, donc encore une fois rien d'impossible. Surtout que le plus important sera la microarch : pour le procédé, je pars du principe que l'écart avec Intel sur ce point, si toutefois il en reste un, est devenu plus que gérable et va continuer à le devenir encore plus ; concernant les facilités ou non de l'ISA j'aurais tendance à dire que l'ARM part avec un avantage théorique. Je continue à croire qu'absolument rien n’empêche, en faisant l'hypothèse d'une équipe compétente, qu'Apple conçoive un CPU concurrentiel pour MBP. Pour un MP évidemment c'est plus dur, mais si leur principe de base est scalable, pourquoi pas.

Enfin certaines pistes d'accélération sont évidentes en passant de ce CPU de téléphone portable à un pour laptop: par exemple augmenter la BP ram. Rien qu'avec des ajustements évidents et à "faible" coût de R&D ils peuvent "immédiatement" augmenter les perfs du CPU pour une nouvelle cible.

Bref du point de vue de la technique pure, je ne vois rien qui bloque. AMA ça sera pas ces aspects là de techniques pures qui seront décisifs, de toutes façons, et il est plus que probable que rien de soit tranché aujourd'hui.

D'un autre côté, le rendement énergétique diminue aussi à très haute fréquence, probablement principalement parce qu'on doit aussi augmenter la tension, et peut être aussi à causes d'autres effets.

Il y a un donc un sweet spot au niveau duquel le rendement est maximum pour un design donné, et certains modèles de Xeon (beaucoup?) privilégient ptet un peu les perfs au rendement.

Les avions de ligne sont quand même assez loin du tout automatique aujourd’hui, même hors crise. Je ne crois pas qu'un seul puisse décoller tout seul. Même l’atterrissage auto nécessite des étapes manuelles, et à les observer je pense que l'industrie entière devrait se reconfigurer assez radicalement pour autoriser le full auto. C'est certainement développable en quelques années, voire plus probablement quelques décennies, mais c'est pas dispo (du tout) maintenant. D'une manière plus générale la gestion des crises va probablement être encore plus complexe que tout le reste et nécessiter des humains pendants encore plus de décennies (et même si on peut ptet les déporter, si on arrive à faire des liaisons de données fiables, il faut provisionner suffisamment de monde au sol).

Et en plus la durée de vie de ces bestiaux est grande.

Bref je suis pas sûr qu'on verra moins de 2 pilotes dans les avions de ligne de sitôt.

Et le coût des pilotes est-il si important que ça pour que ça soit vraiment intéressant ?

que les revenues ne sont plus un moyen de calculer la richesse d'une personne ce qui était pourtant la norme depuis la fin de la guerre

C'est de la foutaise, comme cette députée qui disait être payée tellement peu qu'elle allait devoir sortir des fringues de la cave et manger des pâtes. Je veux bien que leur sentiment soit "réel", mais il est au moins en partie auto infligé et ils ont largement les moyens de prendre des mesures pour changer leur situation s'ils le veulent et se sentent si "mal" que ça : pour l'instant ils choisissent de continuer à accumuler leur richesse sous forme d'un patrimoine immobilier (sauf si le marché crash à bloc mais c'est peu probable)—ce qui leur procure EN PLUS les avantages d'habiter là où ils habitent même s'ils trouve ça vaguement petit (et même là franchement 100m² à 4, c'est pas si horrible—de plus j'imagine que c'est dans un endroit plus pratique que ceux qui sont vraiment pas riches et qui font des trajets délirants pour aller néanmoins bosser à Paris)

L'inconvénient de prix immobiliers débiles c'est qu'ils peuvent affecter le train de vie (et pas la richesse, hors crash au mauvais moment) pendant des périodes de vie potentiellement assez longues si la répartition du budget est déséquilibrée, mais en premier lieu l'équilibre du budget est un choix (influencé par là où on est, certes, mais il y a aussi une part de choix la dedans), et en plus c'est un choix qui n'est jamais irrévocable.

La notion de "oui je gagne beaucoup mais comparé à certains pauvres je suis limite à plaindre" est une absurdité totale.

On dirait plus un Roi parfois. Genre "il faut que les entreprises respectent mes citoyens et mes règles."

C'est ptet pas connoté exactement pareil en Anglais, je sais pas trop, mais j'ai trouvé la manière de le dire un peu curieuse.

Attention, je parle des Android et iOS qui sont fournis en masse, et de la praticité de configurer un tel système pour obtenir un environnement de dev capable nativement de se self-hoster (sur la plupart des systèmes après tout il faut installer une chaine de dev et potentiellement un peu de config avant de pouvoir le faire en pratique, mais il ne faut certainement pas développer les chaînes de dev en question)

Pas du fait qu'il est conceptuellement potentiellement possible de boostrapper un Android vaguement capable de se self-hoster, ni d'utiliser un trick quelquonque style faire tourner un autre système dans une VM ou un conteneur sur l'Android en question.

Parce qu'après tout oui, pourquoi on ne pourrait pas potentiellement techniquement le faire se self-hoster ?

Ça n'est pas le point.

Le point c'est qu'actuellement il ne l'est pas. Et que je doutes qu'il le devienne, hormis peut-être chez 1 ou 2 hackers qui vont faire ça dans leur cave juste pour "prouver" que j'ai tords :p (et encore la dernière fois que j'ai regardé pour construire une vrai image AOSP il était recommander d'avoir 16G de ram pour la builder, ça m'étonnerait pas que ça ait encore augmenté, donc pour en revenir à la praticité du bousin, même les plus gros systèmes Android largement commercialisés ont rarement autant de RAM—encore une fois c'est probablement possible de diminuer les exigences en RAM avec beaucoup de travail, mais ça n'est pas le point)

C'est la vision d'Emmanuel Macron et seulement la sienne. L'emploi du "Je" (enfin du "I") est constant. Le dialogue, c'est bien, mais au final, la décision, c'est la sienne. Pour la revalorisation du Parlement, on repassera.

Effectivement et ça donne des choses très bizarres parfois :

"That is one of the main reasons why I want to be part of this revolution and even to be one of its leaders."

On a limite l'impression qu'il veut démissionner de président de la république, et devenir chercheur en IA. :p

C'est mieux que rien.

Néanmoins tu remarquera que ni iOS ni Android ne sont self-hostés.

Donc déjà, les capacités de productions dans le domaine informatique sont très insuffisantes.

Le truc ciblé par un possible Mac ARM ?

Bof c'est impossible de comparer ça maintenant. Le truc vient de sortir alors que l'autre c'est une théorie potentiellement en développement pour 2020. Du coup tes hypothèses sur la théorie en question sont AMA complètement à côté de la plaque ; Apple sait déjà faire un CPU pour téléphone avec des perfs impressionnantes comparé avec certains CPU Intel pour… plus gros. S'ils ont un projet explicitement pour MBP (voire plus), il n'y a pas trop de raison qu'ils n'arrivent pas a concurrencer très largement Intel.

Quand à la convergence iOS/macOS, elle n'a pas strictement besoin d'une ISA commune pour se produire (même si ça peu un peu aider, voire servir de prétexte).

Nan, dans beaucoup de workloads l'OS importe peu. Et puis c'est pas comme ci Apple aller passer à Android ou Windows. Si vraiment ils arrivent a être en avance grâce à leur soft, ben tant mieux pour eux. (Et c'est le même noyau sous OS X et iOS.)

Apple a déjà fait 1 passage incompatible (obligé de recompiler) d'archi à une autre (PPC à x86)

Deux en fait ; avant ils ont fait 68k -> ppc

Concernant l'hétérogénéité c'est d'autant plus vrai que pour la majorité des programmes, le jeu d'instruction du processeur cible est un problème extrêmement trivial (jusqu'au point où le plus souvent on s'en bas complètement les couilles) par rapport aux différences soft des plateformes qui ont des vrais impacts.

Au final les seuls un peu impactés seraient les utilisateurs pendant une période de transition. Mais Apple a la stratégie (et les fanboys qui suivent et rachètent tout tout le temps) de ne pas laisser les transitions durer trop longtemps, et de faire disparaître "rapidement" la compat avec les technos obsolètes.

Je prédis un réveil difficile pour Intel dans les années 2020 (pas par AMD dont je ne suis pas encore complètement convaincu par la nouvelle archi qui fait certes souvent mieux mais pas partout et donc faut voir leur "v2", mais par ARM et ses copies) si ils ne se donnent pas un gros coup de pied dans le derrière niveau R&D.

Le problème c'est qu'Intel a déjà voulu donner en quelque sorte un coup de pied dans le derrière de leur R&D, plusieurs même, mais aux derniers coups de pieds ils ont fort mal visé ou dosé la puissance AMA. De plus leur stratégie all-in x86 (et même là ou PERSONNE n'en a rien a battre) est tellement naze… d'ailleurs elle a lamentablement échouée dans le domaine des mobiles.

Quant à AMD, c'est vrai qu'ils n'ont que commencé a rattraper leur retard et leur propres erreurs stratégico-techniques passées (et oui, le temps d'incub d'un proco est long), mais honnêtement leur capacité à sortir quelques astuces et à obtenir un résultat qui a étonné tout le monde est classe. Ça va être dur de le refaire sur de la simple evol, mais bon on sait jamais, et en tous cas vu que tout le monde galère à obtenir de vraies accélérations ils vont rester dans la course un bout de temps.

Tu fais l'hypothèse d'un modèle.

Pour l’anecdote, j'ai refusé de relicencier zlib (on peut le faire car la licence permet "tout") comme fortement suggéré en expliquant la raison (je n'ai pas touchée à la lib, par respect pour l'auteur je ne me voyais pas forker pour juste relicencier en GPLv3+/MPL2+) et le rapport final des scrutateurs a donné un point négatif à notre livraison pour cette raison.

Waouh. Tu pourrais leur demander ce qu'ils fument, j'ai envie d'essayer.

J'ai déjà jeté un œil sur des specs de chip graphique moderne.

Ce qu'il m'a semblé, c'est que coder un noyau de SE, c'est du pipi de chat par rapport à développer les couches basses de ce genre de bêtes, surtout si c'est pour espérer avoir des perfs potables. Surtout sans support de la R&D d'origine.

Il doit y avoir des gens plus habitués à faire ça et qui trouvent donc l'activité plus facile, néanmoins je pense que 31k€ ça reste modeste pour ce qui est envisagé. Alors reverse et refaire absolument tout… Bon j'espère déjà que la démarche initiale aboutira comme voulu.

J'attends avec impatience la brillante démonstration probablement ultra pédante que tu vas nous faire pour appuyer tes propos…
(ouai mon commentaire est aussi vide que le tient, c'est voulu, assumé, car je suis relativement sûr de moi sur le fait que tu dis de la merde et que le ridicule te guette—frappe préemptive; tu nous épargnera une pirouette du style "oh, mais ya plein d'API systèmes que tout le monde réutilise sans les redistribuer", c'est pas de ça qu'on parle)