barmic 🦦 a écrit 6068 commentaires

Quel est le problème avec le hello world en java ?

Pour être parfaitement honnête c'est encore en preview, mais je tiens à souligner qu'il ne demande pas d'étape de compilation.

Même avec la version LTS tu met dans un fichier hello.java

class hello {
  public static void main(String[] argv) {
    System.out.println("Hello world!");
  }
}

% java hello.java
Hello world!

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

au moins 16 [banques] dans 3 pays

TRACFIN est sur tes côtes

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

Extensions déférées

Si une XEP expérimentale n’est pas mise à jour pendant plus de douze mois, elle sera déplacée de "Expérimental" à "Différée". Une mise à jour ultérieure permettra de remettre la XEP à l’état "Expérimental".

Pour la cohérence si j'en crois la version anglaise c'est bien "déférée" et non "différée" j'aurais pu comprendre l'un comme l'autre.

AMHA ça pourrait être bien de présenter le processus avec un diagramme par exemple avec une machine à états.

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

Mon avis personnel c'est que je ressens ça comme des outils invasifs. Jusque là l'écosystème Python a toujours été autonome, on a donc toujours eu la possibilité de faire des contributions en Python pour nos outils en Python.

Il me semble que l'une des particularité de l'écosystème python c'est d'avoir toujours eu une grande permissivité en vers le code natif avec des bibliothèques comme numpy pour le plus évident qui mixent du code python et du code C.

C'est toujours plus satisfaisant d'avoir les outils dans le même langages, mais le plafond de performance de python et de rust sont pas les même.

Après c'est un outil de plus, il y en aura 5 nouveaux d'ici le printemps.

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

Tu peux même le faire en java avec jbang.

Mais pour l'un comme pour l'autre je n'ai pas trouvé d'IDE qui me supporte correctement. C'est à dire qui tire les dépendances et ne te met pas des erreurs partout et peut faire de l'autocomplétion.

Kotlin a une fonctionnalité similaire en expérimentation ça décidera peut être a donner un support correct à intellij

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

Ça vient de pip 21.1 (ça a était intégré comme un bug fix) en avril 2021 et toute la discussion se trouve là : Discourage usage of pip as root.

Edit: Pardon c'est une autre modification aussi de mai 2021 : PEP 668 – Marking Python base environments as “externally managed”

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

Je n'avais pas fait gaffe mais oui on utilise énormément de bibliothèque en Java. Ce qui fait que java est différent de python c'est le classpath. Un programme java a une configuration lui indiquant la liste de ses dépendances, il n'y a donc aucun problème à avoir plusieurs versions d'une bibliothèque dans des versions différentes qui sont utilisées en même temps.

Qu'est-ce qui est complexe là dedans ?

C'est un peu verbeux, même maven se prépare a faire en sorte que ce soit une seule ligne (pour maven 5 il me semble, maven 4 - qui est en RC2 - étant la préparation de la version 5).

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

chaque projet devrait avoir son environnement créé avec le module venv et ce n'est pas la peine de le suivre avec git, un venv python c'est jetable et facile à reconstruire, par contre le fichier requirements.txt (pip freeze > requirements.txt) lui doit être suivie avec git

Moi je me suis trouvé un champion, il gère venv pour moi et je commit 3 fichiers (un lock file, un pour la version de python et un pour la description du projet) et pour les cas les plus simples (ce que je fais le plus) il peut simplement se baser sur un commentaire dans le fichier.

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

Pour le coup non puisque je ne le compile pas moi-même j'ai décidé il y a bien longtemps de faire confiance à mon gestionnaire de paquet. Ça demande d'installer quelque chose plutôt que d'utiliser ce qui est dans une installation de python vanilla (ou en tout cas ce qui est sur ma machine), mais je trouve que le confort de l'usage en vaut la peine.

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

Oui j'ai oublié d'ajouter le lien après la rédaction et j'ai toujours du mal à la retrouver.

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

Quand c'est amateur oui, mais quand c'est RedHat c'est difficile à invoquer.

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

Il me semble que le point est un peu différent. Prenons un logiciel comme Ansible, il appartiens à RedHat ou IBM, ces entreprises paient des développeurs pour travailler dessus. Moi aussi développeurs de profession est-ce que j'ai réellement du point de vu de l'URSAFF le droit de contribuer bénévolement à Ansible (j'ai aucune idée de s'ils acceptent les contributions extérieures) ?

Je peux tout à fait comprendre qu'il s'agit là d'un cas où mon travail représente une concurrence déloyale à l'embauche chez IBM/RH et que non seulement ça tomberait sous le coup de la loi mais que c'est réellement ce que le législateur a tenté d'empêcher.

C'est différent pour le logiciel qui sont géré par des fondations par exemple.

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

Devrait-on interdire le bénévolat, quelque soit le secteur d'activité, au prétexte que certains vont faire du profit, avec ou sans contrepartie, grâce à cette activité ?

Je ne sais pas comment ça se passe d'ailleurs en France. Si le logiciel est clairement maintenu par une entreprise, je vois mal comment le distinguer d'un travail déguisé (et je suis même pas sûr que ça n'en soit pas).

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

jour au lendemain

Je doute que ce soit arrivé. Je pense que c'est arrivé lors d'une mise à jour. Et c'est à voir avec les développeurs de savoir pourquoi est-ce qu'ils ont retirer le support. Il y a pleins de raisons possibles (des remontés de bugs dessus avec personnes dans l'équipe en mesure de les reproduire/tester, volonté de garder un code simple, impossibilité de faire quelque chose qu'ils voudraient avec OpenGL4, une dépendance qu'ils utilisent qui ne supporte plus OpenGL4,…). Ça t'énerve peut être, mais c'est à voir avec les développeurs.

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

Quand on y pense, même les choses comme X11/Wayland, c'est pareil.

Pour ce cas là, ça pourrait être au linkage avoir une implémentation pour chacun pour le cas des stack graphiques.

[…]

Si tu parles de chargement dynamique, du type tu as une bibliothèque avec les implémentations génériques, une bibliothèque avec implémentations SSE2, etc. Puis tu choisis quelle version charger à l'exécution.

Alors oui je parlais évidemment du linkage dynamique le link des bibliothèque pour être statique ou dynamique

Le "pour ce cas là" fait référence au cas où tu as une implémentation X11 (xcb ou xlib pour être exact) et wayland (et frame buffer et d'autres choses si besoin) et il permet de ne pas avoir a implémenter la sélection dans ton code. L'installation n'installe que l'un ou que l'autre ou la distribution peut te faire linker avec l'implémentation qui correspond à ce qui correspond actuellement à l'environnement. C'est en ça que le fait qu'il y a pleins de techniques pour faire de la sélection tardives d'implémentation et que le fait que ça existe pour X/Wayland n'indique pas du tout que c'est possible par ailleurs.

Même sans ça le fait que le serveur d'affichage te permet de détecter sa présence n'indique pas que le CPU te permet de savoir quel jeu d'instruction existe ou pas.

Bref c'est intéressant de savoir que cpuid récupère ces informations depuis le CPU lui-même et pas depuis une base de connaissance.

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

Quand on y pense, même les choses comme X11/Wayland, c'est pareil.

C'est pas le concept générique qui est oublié, mais la possibilité de découvrir à l'exécution ce qui est disponible ou non sur le cpu. Surtout que les techniques peuvent être très différentes. Pour ce cas là, ça pourrait être au linkage avoir une implémentation pour chacun pour le cas des stack graphiques

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

Je savais pas (ou j'ai oublié) qu'on pouvait avoir un branchement au runtime pour en vérifiant l'existence des instructions.

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

OpenMP ne peut pas inventer le processeur sur le quel il va tourner. Donc ça va dépendre de la cible que tu donne à ton compilateur. Tout le point plus haut est de justement être en mesure d'utiliser les instructions de ton CPU qui vont permettre d’accélérer l’exécution.

Il n'y a pas vraiment de magie pour ça ou plutôt il y en a une mais elle est pas gratuite c'est d'avoir du JIT.

L'idée c'est de compiler le code sur la machine cible au moment où tu as sais quel CPU tu utilise et tu as des stats pour faire de la compilation guidé par des profile. C'est java et probablement C#. Après il faut que le code intermédiaire aide à trouver les optimisations possibles donc par exemple ai une abstraction de SIMD.

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

bien vu

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

En fait en reformulant, j'essaie de comprendre l'intérêt de l'un par rapport à l'autre.

En fait tu peu le faire avec des containers, mais il faut instancier un container par utilisateur différent (c'est pour ça que le faas a du sens).

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

Il doit bien accéder au FS pour créer un dossier non ? Ou quelque chose m'échappe …

Ce n'est pas lui qui crée le dossier, je lui dis quel dossier il a le droit de lire et m'assure qu'il n'a le droit de lire que ce dossier

deno run --allow-read=/run/random-bidule/dir script.ts /run/random-bidule/dir

Le premier pour qu'il ai le droit de lire ce dossier et le second pour que le script puisse savoir quel dossier il peut lire.

Tu as la doc ici:

https://docs.deno.com/runtime/fundamentals/security/#file-system-access

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

Ce que tu décris me fait penser un peu aux cloud functions de GCP ou lambda AWS, mais …

Tout à fait et faire du FAAS aurait put être une option, mais disons que faire un choix de déploiement et un choix de dev n'est pas les même personnes ni les même enjeux.

Quel genre de fonctions ? J'ai du mal à me représenter les cas d'utilisation. Tu parle d'interaction avec stdin/stdout/stderr, mais ces 3 canaux doivent bien être interfacés avec des entréess ou des sorties non ? Je suis assez curieux car ça pourrait me servir en début d'année prochaine …

Interaction est un bien grand mod pour être tout à fait précis :

Le code qui reçoit la requette va :

• créer un dossier dédié (avec des fonctions spécifiques pour) et stocker des fichiers de configuration en particulier un fichier js qui doit exporter une fonction
• appeler un nouveau process en lui donnant uniquement accès au dossier (il y a des limitations fortes qui font que tu ne peut pas appeler un fichier ../file.txt par exemple)
• envoyer dans le stdin de ce nouveau process grosso modo l'équivalent de la requête

Le processus lit sa conf, regarde la requête dans son stdin et fait son job.

Si tous se passe bien il écrit le résultat dans sa sortie standard, sinon il écrit l'erreur dans sa sortie d'erreur.

Le parent pose un timer pour limiter le temps d’exécution du sous processus.

Du coup c'est juste un bête request/response, ça aurait pu être fait en HTTP sur l'interface loopback. Je sais pas si deno sait utiliser une socket UNIX.

Je sais pas si c'est suffisamment clair.

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

Je me sers justement de deno pour ça :)

Ma boite donne une fonctionnalité qui permet grosso modo à des utilisateurs d'écrire une fonction js que l'on exécute en suite nous sur nos serveurs. C'est une forme de plugin.

Et ben pour ça on a un service qui spawn un deno pour exécuter cette fonction (et quelques autres trucs) et communique avec via std{in,out,err}. C'est une forme de séparation de privilège comme le décrit le projet openbsd où ils découpent les logiciels entre la partie qui a besoin de privilège et celle qui n'en a pas.

A noter aussi qu'il est possible d'être plus fin et par exemple de limiter l'accès uniquement à une partie du système de fichier.

Alors que je me suis jamais vraiment penché sur node, j'aime vraiment bien deno qui est devenu l'un des interpréteurs que j'utilise pour différents scripts juste pour moi en remplacement de python. J'ai des scripts qui ne font plus ou moins que des appels rest, typescript est très bon pour ça sans la moindre dépendance en plus (bon deno du coup). Et pour les fois où je fais du scrapping fetch + domparser est plus pratique pour moi que request + beautifulsoup.

Une fonctionnalité que je trouve vraiment sympa, c'est que tu peut avoir de la persistance simple sans prise de tête avec deno puisqu'il implémente le localstorage. Ça permet à certains de mes scripts d'avoir un cache sans m'embêter plus que ça.

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

Une de mes grandes fiertés de cette année, c'est d'avoir sur quelques mois :

• réalisé une analyse statistiques de données de prod
• choisi un modèle mathématiques en rapport avec ce que j'observais
• évalué la viabilité de mon modèle par des benchmark et des expérience pour vérifier la fiabilité fonctionnelle (comme ça utilise des proba vérifier qu'on ne tombe véritablement pas dans les cas problématiques)
• choisi un meilleure architecture lié à ce modèle mathématiques pour réduire la taille des données manipulées
• utilisé des optimisations bas niveau accessibles grâce au fait d'avoir réduit la taille des données (pour faire simple chaque élément tiens maintenant dans un registre)

et ainsi obtenu des gains de 50% de nos débits (sous charge sinon ça se voit pas) sur un pan assez important de notre logiciel.

C'est une illustration de ce que je décrivais, il ne faut pas opposé la complexité algo et le CPU, il faut les coordonner pour arriver au résultat que tu attends.

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

Entre l'éducation universitaire qui pense en complexité algorithmique et en machine abstraite

Je ne pense pas qu'il faille opposé la complexité algorithmique et en mémoire sur la compréhension du CPU.

l'industrie qui pousse pour des solutions vite implémentées pour pas cher en jetant des « Engineering time is expensive, memory is cheap »

Les utilisateurs aussi poussent à cela.

le délire de la montée en puissance considérée comme acquise

Parce qu'elle l'est encore plus ou moins et l'a était pendant des décennies.

la culture du one-liner

Souvent aussi poussé par le même genre de personnes qui ont une bonne maîtrise du CPU

le fantasme du compilateur qui optimise tout

Jamais entendu ça, j'ai entendu "si tu veux pas t'y intéressé plus, écris un code simple, ça aidera le compilateur".

La performance en informatique est immensément plus complexe que ce que la majorité des gens qui en parlent décrivent. Il y a un paquet de façon de comprendre ce qu'est la performance (amélioration de la latence, du débit, de la consommation de ressources, du temps d’exécution,…) et je n'ai jamais vu de critique prendre véritablement le temps de se poser sur ces questions, d'ensuite décrire comment est-ce qu'on mesure (Mozilla s'est cassé les dents à être plus rapide avec un ressenti plus lent que son adversaire) pour ensuite expliquer comment est-ce qu'on y parvient.

Dire que les gens ne comprennent pas les CPU c'est vrai je suis d'accord, mais c'est sauter à la conclusion, ils ne comprennent pas plus les IO par exemple, ni leur stack d'affichage,… selon ce qu'ils écrivent comme logiciel le CPU ne sera pas forcément le plus important.

Et la performance n'est pas le seul critère, la sécurité est très largement ignorée, on parle vite fait de performance, mais que ce soit avoir un code véritablement sûr ou supprimer les supply chain attack ça ne fait parler que vite fait quand un drame se produit sans pour autant dire qu'il y a de solution sûre à ce sujet. Il en existe pas, mais est-ce que c'est une bonne raison pour ne pas s'attaquer au sujet ?

Je suis personnellement beaucoup plus pour un processus d'amélioration où on pose la question de qu'est-ce qui est important (rapidité, efficacité, sûreté, réactivité,…) et qu'on regarde comment l'améliorer ou le maintenir dans le temps. Ça peut consister à connaître le CPU ou peut être à en faire tout simplement moins (et à considérer que des fonctionnalités n'ont pas leur place) ou tout un tas d'autres choses.

Clean code met l'accent sur la maintenabilité du code, lui reprocher son manque de performance est une évidence, c'est toujours une histoire de compromis. Personnellement tu ne me verra pas écrire un duff's device sans qu'il y ai un besoin absolument critique de cette ignominie.

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