devnewton 🍺 a écrit 8778 commentaires

On me demande parfois de corriger des erreurs dans les commentaires. En tant que modérateur, je préfèrerais juste avoir à valider ces changements.

Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

La tradition des journaux inutiles répondant aux journaux inutiles est ancienne :-)

Tu veux nous parler de https://datapio.co/ pour changer?

Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

J'ai cru que ce serait des sexbots :(

Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

https://go.dev/blog/gofmt par exemple ?

Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

Les antipass provax sont très peu nombreux, on attend leur manif pour compter si ils pensent être si nombreux.

On fait de la résistance passive: les restaurateurs et commerçants le demandent de moins en moins, les clients ne s'en plaignent pas.

Avec un peu de chance, cette mesure finira avec la pile des lois inutiles.

Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

Pour retrouver le charme de l'assembleur: https://github.com/wiz-lang/wiz

Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

J'aime bien cet article pour ne plus craindre le grand méchant GC : https://dlang.org/blog/2017/03/20/dont-fear-the-reaper/

Une autre approche de la gestion de la mémoire semiautomatique: https://ziglang.org/documentation/master/#Memory

Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

Pour trouver un système mieux fait, il faudrait regarder du côté d'Android où le runtime "java made in google" est vraiment partagé par toutes les applis.

Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

Peut être que l'approche "empaquetage" est mauvaise alors.

En tout cas la conséquence, c'est que tout fini dans /opt ou sur docker…

Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

Sauf jouer sur iPad, faut aimer avoir très mal.

Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

Oui mais le problème est que aucun système parallèle de distribution des paquets (npm, pip, toussa) n'offre les garanties de confiance qu'offre les distributions.

Pourquoi les voir comme des systèmes parallèles? Les distribs devraient avoir leurs propres dépôt maven/npm/pip/… au lieu de réinventer la roue.

La condition pour que les distributions soient un peu plus au service des besoins des développeurs est donc peut être que les développeurs soient un peu moins capricieux et court-termistes et s'intéressent plus aux contraintes de maintenance à terme.

La maintenance à long terme demande:

• d'avoir des libs à jour et qui fonctionnent ;
• un seul système de build (et pas un par distrib).

Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

Le problème c'est justement que les distribs ne font pas leur job du point de vue des développeurs: se mettre d'accord sur un système de paquets commun, intégrer les systèmes de build existants, s'assurer d'avoir des API / ABI stables, faire en sorte que le tout soit simple.

Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

Pour montrer que flatpak ne consomme pas trop de runtime et de disque, l'auteur explique que sur sa machine il a seulement 18 runtimes pour un total de 8.7 GB.

Le runtime Java, que beaucoup considèrent comme bloated, embarqué dans Newton Adventure fait 51 mo. Dans 8.7 GB, on pourrait ainsi avoir presque 175 versions du JRE non dédupliqués…

En voulant démonter la critique initiale de Flatpak, il montre au contraire que c'est bien bien bien bloated :-)

Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

Il y a l'approche du CDi qui est de fournir une API standardisée et d'interdire aux jeux d'accéder directement au matériel. Et d'avoir plusieurs implémentations incompatibles du matériel pour s'assurer que c'est bien le cas.

C'est que font les brouteurs web :-)

Mais c'est assez bloated. Il faudrait un brouteur jeu !

Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

Les consoles sans même un BIOS, ça ne court pas les rues. Peut être la PC Engine et encore uniquement pour les jeux sur hucards?

Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

Tu ne dois pas faire le test avec n matériel x m distributions.

Faire le test, c'est prendre le risque de se rendre compte que ça bugge :-)
https://linuxfr.org/nodes/118350/comments/1788497

Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

Mais pas Newton Adventure :( Cf https://linuxfr.org/nodes/118350/comments/1788497

Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

Les jeux ont une problématique spécifique:

• des mises à jour fréquentes et obligatoires pour les jeux en ligne ;
• le besoin d'un accès "direct mais pas trop" aux piles graphiques, audio et inputs.

Plutôt que les considérer comme des applis natives à sandboxer, est-ce qu'il ne faudrait pas un conteneur spécialisé?

Ce qui s'en rapproche le plus aujourd'hui:

• le brouteur avec les API canvas/webgl/webaudio/gamepad : la sécurité est bonne, mais il est difficile de jouer hors ligne ou même de faire des jeux avec des gigots de ressources, les perfs ne sont pas au top ;
• libretro : le hors ligne et les gros jeux sont possibles, les perfs sont top, mais il n'y a aucune sécurité.

Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

Est-ce que Flatpak est tombé en marche depuis https://linuxfr.org/nodes/118350/comments/1788497 ? :-)

Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

Pas vraiment l'avantage puisque le source compilé l'aura été avec les mêmes gardes-fours

Les gardes fours, c'est pour éviter les voleurs de pizza?

Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

Rust est une révolution car il apporte le mémory safe dans les langages compilés (sans VM) sans avoir a s'en pré-occuper réellement

Bof, il faut se préoccuper de la mémoire 42 plus que dans un langage à ramasse miette :-)

(pour rappel Go et d'autres compilent leur VM dans le binaire).

Gnii? VM != GC

Alors on peut classer les langages du plus productif au plus performant/sécurisé ainsi Python, Go/Java, Rust, Ada.

Pas sûr que Rust soit plus sécurisé que Java :-)

Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

Heureusement on a une solution moderne et plus sécurisé: OpenID Connect !

Plus qu'à trouver une implémentation KISS parce qu'Open Identity Platform ou Keycloak sont aussi bien bloated :(

Arg on ne s'en sort jamais !

Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

LDAP est quand même super bloated pour gérer des users { login, password, group } dans 99% des cas (chiffre Dave Newton Institute Of Identity & Access Management).

Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

Un grand père esclavagiste?

Le mien a laissé une page blanche comme testament, ses héritiers étaient déçus.

Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

Pour les journaux, est-ce qu'il serait possible d'accepter les data uris (avec limitation de taille)?

Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.