barmic 🦦 a écrit 5211 commentaires

Donc ce que tu as perdu, c'était surtout un faux sentiment de sécurité.

Je ne suis pas un spécialiste, mais je doute fortement de ça.

L'existence de méthodes qui, sous certaines conditions, permettent de by-passer une sécurité n'en fait pas un faux sentiment de sécurité. Tu n'utilise pas un cadenas inviolable pour ton vélo.

D'autant que firewall n'est pas inviolable non plus.

Et même avec tout ça, ça ne remet pas en cause le fait d'en profiter pour améliorer sa sécurité.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

C'est gênant que ce soit la seule quand même…

Bof quand tu parle des avantages pour Chrome c'est encore plus petit (une peut-être sensation que ça va un peu plus vite).

(et surtout, depuis Quantum, ça passe par un hack, on se tape les onglets quand même en haut car impossible à enlever par l'extension, il faut un hack CSS qui ne peut s'enlever automatiquement si on n'a plus le panneau visible, donc expérience utilisateur bof, pas la priorité de Mozilla d'être différent)

Alors ne me considérant pas utilisateur lambda je vais me garder de parler pour eux. Mais en ce qui me concerne ça me permet à la fois de supprimer cette barre, mais aussi d'autres parties et d'en redimensionner certaines. Je m'en servais bien avant Quantum. Donc je suis plutôt satisfait que ça existe. Je doute que l'utilisateur lambda s'intéresse au fait de mettre les onglets en vertical.

Plus (mini subjectivement, voir autres commentaires) rapide à un moment, moins de pb de compatibilité (et de la faute de Mozilla hein, exemple), faire comme les potes et comme on a pas grand chose de nos jours pour dire que Firefox est mieux et qu'on n'est pas anti-Google que Mozilla met quand même en avant, toutes les erreurs de com' de Mozilla qui ont fait qu'on veut "punir" en quittant et que Google est certes pas mieux mais eux n'ont pas un manifeste disant qu'ils sont plus mieux bien, et j'en passe.

Un argument objectif clair et net d'un coté et de l'autre le seul argument intrinsèque à Firefox c'est "à une époque c'était subjectivement plus rapide" ? Ça n'est pas léger ?

Pour rappel même à la grande époque de firefox n'avais qu'un seul argument (et demi si on veut être gentil) : les onglets (le blocage de popup était possible sur IE, mais c'était pas une fonctionnalité de base. La barre de google par exemple le permettait).

On est surtout devant des logiciels qui sont arrivé à un point où il devient difficile d'innover. Que les développeurs aient une fibre libristes (comme Mozilla), qu'ils soient des armées à temps pleins (comme Google) ou qu'ils aient toujours fais de l'innovation leur marque de fabrique (comme Opera), il semble clair qu'on est arrivé à un plateau d'innovation. Ça n'est pas la faute de Mozilla. Tu peux leur reprocher de ne pas être irréprochable en terme de vie privée (à raison), mais ça ne changerais rien à l'affaire.

Regarde un exemple très simple. Zoom est un pur carnage en terme de vie privée, c'est probablement la pire solution possible, ils ont eux-même reconnu leurs problèmes. Ça ne les empêche pas d'avoir beaucoup mieux tirer leur épingle du jeu cette années que n'importe quelle autre solution de visoconf. Les gens pour qui l'UX est important comme tu le rappel ne choisissent pas du tout leurs logiciels en fonction de l'étique des développeurs. Être irréprochable n'est pas un argument pour eux.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

C'est pour ça que je parlais de réduire.

donc leur principal intérêt c'est côté mémoire & perf et boilerplate.

C'est pas ce qu'ils indiquent pour la mémoire et la perf :

Goals

• Devise an object-oriented construct that expresses a simple aggregation of values.
• Help programmers to focus on modeling immutable data rather than extensible behavior.
• Automatically implement data-driven methods such as equals and accessors.
• Preserve long-standing Java principles such as nominal typing and migration compatibility.

Non-Goals

• It is not a goal to declare a "war on boilerplate". In particular, it is not a goal to address the problems of mutable classes which use the JavaBeans naming conventions.
• It is not a goal to add features such as properties or annotation-driven code generation, which are often proposed to streamline the declaration of classes for "Plain Old Java Objects".

Je ne vois rien qui parle de performance ou de mémoire, par contre je trouve drôle qu'ils cherchent à simplifier la création de structures simples sans faire la guerre au boilerplate. Je comprends plus ou moins l'idée, mais la façon dont c'est présenté dans la JEP me semble surtout chercher à montrer qu'ils ne veulent pas intégrer cette syntaxe dans les objets classiques.

De mon humble avis l'un des gros objectif finaux des records même si ce n'est pas encore implémenté c'est de pouvoir les déconstruires.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Le problème est que ça devient de plus en plus le seul argument pour Firefox : être contre Chrome.

Je trouve que c'est aller un peu vite. Personnellement mes onglets sont verticaux (grâce à tabcenter-redux que je préfère à Tree Style Tab) c'est impossible avec chrome par exemple. Je ne sais pas par contre ce qui fait utiliser Chrome pour un utilisateur éclairé (c'est à dire qui a connaissance des 2, qui sait les installer,…). Je crois avoir entendu dire que les outils de dev étaient un peu mieux, mais je suis pas sûr que ce ne soit pas un problème d'habitude par exemple.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Si tu indiquait un élément concret, ça pourrait peut être amener une discussion.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Compter sur un hypothétique pare-feu qui peut aussi être désactivé par inadvertance ou mal configuré est AMHA une erreur.

Compter sur le fait que tous les services de toutes les machines qui passent sur ton réseau soient bien configurer me semble aussi une erreur, d'autant que tu n'administre pas forcément toutes les machines de ton réseau. Entre le pc du pote qui vient passer la soirée, les smartphones d'amis venu prendre l'apéritif et voulant montrer leur photo de vacances, la console de jeu dont tu n'est pas administrateur, cette ampoule connectée qu'on t'a offert et qui bien que non hackable fait quand même le taff, l'imprimante réseau dont il n'est pas sûr que son implémentation soit solide, etc

Bref ça que l'on cherche à bien configurer ses machines c'est une bonne chose, mais ça ne me semble pas pour autant remettre en cause une solution simple.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Oui, mais il faut aussi le voir à l'envers. Aller voir un médecin pour avoir un arrêt de travail parce que tu as 3 symptômes bénins qui ne t'empêchent pas vraiment de travailler (même moins productif). C'était pas non plus forcément très bien vu.

C'est moins une question de responsabilité personnelle que de prise en compte et d'organisation collective (simplification des démarches, accepter qu'une maladie ou un symptôme n'est pas inventé, mise en place du télétravail, de rendez-vous médicaux à distance, arrêter de regarder bizarrement quelqu'un qui porte un masque, etc).

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

• de plus, bien que Chrome était initialement plus lent que Firefox sur presque tous les benchmarks, il s’appuyait sur de nombreuses astuces de conception qui donnaient l'impression que le produit était plus rapide — et les utilisateurs ont adoré cela.

Je trouve ça très intéressant. C'est un super exemple pour montrer comment se concentrer sur des benchmarks sans les remettre en cause et sans prendre le temps de remettre l'utilisateur au centre peut mener à des problèmes.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Dans un pays qui ne s'est pas remis de ses difficultés économiques depuis la crise débutée en 2007, je trouve improbable qu'aucun décideur n'ait vu là une occasion exceptionnelle de faire accepter quelques régressions d'un coup ; tester des changements dans une économie souffrante ; tester la société et sa réaction face à des pertes de liberté supplémentaires ; ou, encore, détourner à court terme les inquiétudes d'une partie de la population de la situation économique et sociale.

Tu décris des méchants de totally spies et tu dis que ce n'est pas manichéen ?

Les gens ne se disent pas qu'ils vont tester des lois comme dans les mission impossible on test des virus avant de les répandre sur le monde avec un rire de méchant. Non ils ont juste une idée différente de l'économie et suivent dur comme fer des économistes de renom bien plus caler que nous ne le seront jamais. Ce qu'il y a c'est qu'ils ne remettent pas en question ce qu'ils savent ou croient savoir alors que :

• ces éléments sont moins de la science dure que de la doctrine
• a énormément évolué récemment grâce à l'arrivée de recherches expérimentales dans le domaine

Donc je réfute le machiavélisme que tu semble leur donner.

Pour ce qui est de la communication, encore une fois l'expérience montre qu'ils font peur même quand il n'y a aucun enjeu. Affirmer sans autre argument que "ça doit bien exister" qu'il y a un dessein derrière cela est plus proche de la théorie du complot que de l'argumentation éclairée.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

c'est une simple croyance

Non c'est juste la rasoir d'ockham et tes deux arguments ne tiennent pas pour moi.

On ne peut pas être terrorisé en continue donc oui comme tous ils font des erreurs dans la pratique. Ils sont aussi bien plus surveillé. C'est tellement agréable de pouvoir montrer qu'ils fautent.

La mesure de la peur est relativement compliquée et nous avons des exemples précédents le virus qui montrent que l'état français applique une doctrine qui engendre la peur sans la remettre en cause. C'est particulièrement difficile de prendre le risque de remettre en cause ce genre de doctrine pendant la crise. Je pense par exemple à l'incendie de Nantes.

Loin de moi l'idée de tout pardonner juste une explication moins manichéenne et diabolisante.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Je ne connais pas.

Pour les pool d'objets dont tu parlais plus haut, c'est tout de même assez relou à faire. Tu reconstruit un fonctionnement à la malloc/free avec tous les problèmes qui vont avec (use after release, fuite mémoire,…) et ton pool ne doit pas être un point de contention vu que tu va l'utiliser sur une partie du code plutôt stressée.

Je crois que ça peut être plus propre en C++ en utilisant un allocateur personnalisé (c'est transparent à l'usage tant que tu utilise du RAII).

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Avec le code des jeux qui l'utilisent, ça fait une majorité du code final sous GC.

Ça n'est pas la partie critique.

Bref les GC modernes ne sont pas un problème dans les jeux.

On ne les utilise pas dans les parties critiques donc ce n'est pas un problème ? Soit.

Dis autrement ce n'est pas une question de performance des gc qui permet ça. Juste qu'on a construit des frameworks pour dissocier la partie critique de l'application. C'est une très bonne chose, hein pas une critique du tout.

Ni dans les applis web

Là c'est encore très différent. Pour un deamon qui aura par nature une durée de vie plus longue, c'est bien plus simple d'utiliser un gc pour limiter la fragmentation mémoire. Mais même comme ça les appli qui ont une certaine criticité vont faire du off the heap.

ni dans 99% des applis

De mon avis perso, « 99 % des appli » devraient plus s'intéresser à la correction qu'à la performance et donc éviter à tout prix de manipuler à la main la mémoire.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

libgdx, pygame,… sont en C ou C++ plus qu'en python ou java quand ce n'est pas simplement sdl qui fait toutes la partie critique en terme de perf par exemple

Pourquoi ces jeux sont fluides et n'ont pas de gros ralentissements dû à un ramasse miette Arrête Le Monde?

Parce que la mémoire n'est pas géré par le garbage collector. Quand ut garde une taille de heap petite ça fonctionne bien.

les GC modernes ramassent les mettes de façon incrémentales et concurrentes, d'autre part les développeurs de jeux font la chasse aux allocations/désallocations en pré-allouant un maximum de choses, en utilisant des pools, en préférant des tableaux fixes aux hashmaps dynamiques…

Qu'il y ai des optimisations possibles on est d'accord, mais elles ne peuvent pas tout. Tu ne peux pas allouer directement un objet en old generation par exemple ce qui permettrait de ne pas voir ton gc passer des objets que tu sais qu'ils ne sont pas à détruire.

Cette chasse est faite aussi dans les jeux en C/C++, car comme je l'ai déjà dit aussi, les malloc/free, c'est coûteux pour tout le monde, pas seulement quand c'est un GC qui les fait.

Je crois que l'allocation mémoire est plus coûteuses en natif que dans la JVM qui gère déjà sa mémoire vis à vis de l'OS.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Tu veux dire le nombre de jeux qui utilisent un gc en frontend ? Oui il y en a pas mal, mais il n'y a aucune contrainte pour ce genre de code. Ce n'est pas la prouesse de leur gestion mémoire qui permet ça, mais leur capacité à s'interfacer avec du code natif. C'est pour ça qu'on trouve lua par exemple.

Pour parler de java, je doute que l'on trouve une application dont la mémoire est crucial qui ne fasse pas du off the heap.

C'est comme dire que la gestion mémoire de python est sacrément bonne parce que si on utilise numpy ça déchire. C'est moins sa gestion mémoire que la qualité de son interface avec du natif que l'on estime.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Mais ça n'est pas stable non plus.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

il faut l'exécuter plusieurs fois (> 1000 ? > 10 000 ?)

Jusqu'à ce que la moyenne se stabilise.

Mais très clairement, un écart-type élevé est bienvenu pour la génération de l'entropie.

Du code qui fait des io est pratique pour ça.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Aujourd'hui les vraies pauses sont si petites qu'on ne les remarque plus (CTB !).

Dépend des usages, ça. ZGC qui est monstrueux annonce 2ms, ce qui est bien trop important pour un jeu vidéo temps réel.

Il y a même un GC pauseless pour Java, mais il n'est pas libre :(

Je n'ai jamais essayé azul zing.

Note aussi que le temps d'exécution des autres modes de libération de la mémoire n'est pas NULL non plus.

Ils ne bloquent jamais toute l'application, ils sont totalement prédictibles, ils ne prennent pas de temps CPU hors de la libération de la mémoire,…

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

L'autre "problème" des langages managés en termes de perfs c'est le JIT (compilation à la volée).

C'est discutable. Le JIT a beaucoup plus d'info que la compilation AOT pour faire ces choix et ce n'est pas quelque chose de continue aucun langage managé que je connais ne compile du code continuellement (sinon c'est plus proche d'un code interprété en fait), une fois que le JIT est passé, c'est juste du code natif qui s'exécute. Si ton jeu s'exécute peu de temps ça pose un problème, mais sinon ça ne fait pose pas tant de problème que ça.

Je pense que c'est plus la gestion de la mémoire qui pose problème (les gc créent un overhead en consommation mémoire, ça demande un certains tunning d'avoir un gc qui s'exécute correctement sur du temps réel comme ça,…).

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Les premiers GC stoppaient le monde.

Les derniers aussi. Ils sont plus efficaces, mais oui le stop the world existe toujours.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Euh, les fuites mémoires à cause d'évènements ou d'objets non-disposés (utilisant des connexions à des bases de données, des ressources réseau, des Span, …), ça arrive et ça fait mal.

Tu as bien plus drôle à faire : utiliser des lambda comme callback sans te rendre compte que ce que tu capture dans ta fermeture. Ça touche tous langages objet qui a des lambdas et personne ne peux rien pour toi. C++ est peut être un peu mieux loti car il rends explicite la capture, mais pas au point de voir quel objet est dans la capture.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Sans vouloir être défaitiste, mon expérience m'a rendu dubitatif quant à la mise en place d'un environnement libre à long terme dans un milieu pour lequel l'informatique n'est qu'un outil, au même titre que l'agrafeuse ou le balai: si la relève n'est pas aussi sensibilisée, formée et motivée et que tu ne l'es sur le sujet, il y a de forte chance que, dès ton départ, tout ce que tu auras mis en place soit remplacé par la solution GAFAM du moment, services et postes de travail inclus.

Euh… C'est normal. Tu met en place une solution, il est bien possible qu'une fois que tu parte, la personne qui prendra le relais utilise une autre solution. Ça marche avec le libre ou non, ça. Ça peut être Office 365 de MS, GSuite de Google, les diverses options libres qui sont listées par ici,…

Croire qu'on peut mettre en place un outil (informatique d'autant plus) et qu'il restera à vie d'Homme c'est une chimère. Les besoins auront peut être évolués dans 5 ans, les solutions aussi. Et de toute manière qui sommes-nous pour dire au successeur de cette tâche comment il doit la faire ? Comment prendrais-tu quelqu'un qui te pousse à utiliser une solution qui ne te plaît pas ou que tu ne connais pas (libre ou pas) ?

La seule chose possible c'est de faire au mieux pour ne pas faire de la rétention d'informations.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Il faut voir aussi que la surface du die n'est pas ce qui coûte le plus cher (en fait on sait pas trop quoi faire de toute cette place et on remplit avec des mégaoctets de mémoire cache).

Sur ton wafer 32" si tu sort N dice ou 25% de plus c'est quand même une légère différence, non ?

Les trois trucs qui empêchent de minaturiser les cpus aujourd'hui c'est le nombre de pins nécessaires pour les connecter à la carte mère, la dissipation de chaleur, et la consommation électrique qui empêche de faire des connections trop petites au moins pour l'alimentation.

Je comprends le premier point (on arrive probablement a des tailles de soudures en dessous des quels elles perdent en fiabilité), par contre les 2 points suivants je ne vois pas trop, ils sont liés à la densité et pas à la taille. Si tu as besoin de la surface de ton CPU 32 cœurs même pour refroidir 16 cœurs, ça ne doit pas très bien se passer quand tu 32 cœurs sont effectivement utilisés.

Ces critères définissant en gros la taille du package du cpu, autant mettre du silicium qui fait à peu près la même taille dedans.

Alors non parce que tes chaines de productions produisent moins par wafer et il y a une différence énorme entre la taille du PCB et celle du die par exemple :

pour un socket de 37.5mm de côté donc 85% de surface sans die.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

ce qu'un bon compilo pour langage à garbage collector peut gérer automagiquement

Rien compris à cette phrase.

En les interdisant?

Je ne sais pas. Je dis juste que rust gère la mémoire automatiquement, même s'il n'utilise pas de gc pour ça. Tu n'a pas a libérer manuellement ce que tu as alloué sur le tas. Qu'il y ai des contraintes c'est tout à probable, le gc aussi posent des contraintes.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Une comparaison n'est pas une compétition. Il n'y a rien de con à comparer des langages. Observer des approches différentes et leurs impactes. S'inspirer des autres langages est nécessaire. Rust étant utilisé à des endroits où C ou C++ règnent en maîtres depuis plusieurs décennies c'est difficile de ne pas en parler. Mais encore une fois C++ n'a pas tué C, rust ne tuera pas ses prédécesseurs. Je ne vois pas pourquoi s'en offusquer.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Ok je trouve ça fou tout de même.

Ils ont cité 80% de dies pleinement fonctionnels en début de production, le reste dégradé.

Ce qui signifie qu'ils vendent un paquet de puces totalement fonctionnel au prix du milieu de gamme (en les ayants évidement configurés pour).

J'ai pas de doute qu'ils ont fais leur choix de manière aussi intelligente que possible.

Merci pour l'info :)

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll