barmic 🦦 a écrit 5918 commentaires

On parle du deuxième téléphone produit par l'entreprise tous les constructeurs ont eu des cas problématiques. 2 ans après la sortie du fairphone 2, Samsung sortait le galaxy note 7 dont les batteries explosaient. Tous les constructeurs ont eu des cas problématiques.

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

https://www.frandroid.com/marques/fairphone/1224295_fairphone-est-ce-un-bon-plan-ou-une-galere-des-utilisateurs-temoignent
https://grisebouille.net/fin-de-partie-pour-mon-fairphone/
malheureusm

Donc le fairphone 2 a eu des problèmes et quelqu'un a été déçut de ne pas garder plus de 6 ans son téléphone alors que ces précédents tenaient 2 ans et demi c'est donc de mauvais téléphones ?

C'est un peu comme quand on leur reproche de ne pas être 100% issus de matériaux recyclé ou de ne pas être entièrement issu de production responsable.

Si tu n'est pas parfait dans le domaine dont tu parle alors tu es mauvais et autant prendre ceux qui ne s'en soucis pas du tout ?

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

C'est marrant comme RMS, ESR ou GKH (Greg Kroah-Hartman) sont bien plus utilisés que d'autres.

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

Perso je suis profondément contre les crypto donc je n'achèterait pas un produit qui se vend comme portefeuille de crypto/nft/web3 etc

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

Qui utilise encore Perl par choix et pour quoi, quel domaine ?

L'un des grands usages de perl reste le code glue où il est en concurrence avec le shell. C'est un domaine où il excelle d'une part le pas entre les outils POSIX et lui est simple, mais la gestion des processus est aussi simple comme en shell. Ça en fait l'outil idéal quand tu veut faire du shell/grep/sed/awk/… mais en ayant tout dans un même langage et la possibilité d'utiliser des bibliothèques pour faire du réseau ou parser du json/yaml/etc.

Pour faire la même chose python sera plus rébarbatif au profit d'une certaine lisibilité (pas de variables autodéclarées, pas d'identifiant de variable d'un seul caractère non alphanumérique, mais plus de construction comme re.search() qu'il faut importer pour utiliser une expression régulière, pas non plus de os.system subprocess pour lancer des commandes,…).

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

Je fais confiance à Debian pour ce genre de choix. Je n'ai pas encore essayé Wayland ni pipewire. Tant que ce n'est pas dans debian stable, je n'ai pas très envi d'expérimenter.

J'espère que pipewire sera au moins aussi bien outillé que pulseaudio pour quelle source va où avec quel volume.

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

De plus, Netflix pourrait faire du broadcast pour les films les plus regardés, chose impossible pour le jeu vidéo.

Non c'est pas vraiment possible il faudrait que tout soit à peu près synchronisé. Par contre j'avais entendu qu'ils proposent des proxy directement installés chez les FAI.

Bien vu par contre pour les contraintes de latence

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

Il n'y a pas de mutualisation de carte graphique

La carte graphique que tu aura louée pour 2h pourra très bien être utilisée par un américain puis un coréen dans les même 24h.

Tout le monde ne joue pas tous les jours, ça permet aussi un roulement.

Dans l'empreinte écologique il faut aussi prendre en compte le transport de l'information avec une faible latence et le fonctionnement des algorithmes de compression décompression.

Ça représente quoi face à la production et l'acheminement vers chez toi ?

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

En théorie si tu ne reproduit pas aussi la création de l'environnement de build (l'image docker fournie), c'est de la poudre de perlinpinpin, ça ne vérifie absolument rien.

Tu peux aussi l'auditer. J'ai regardé vite fait c'est une ubuntu avec quelques étapes pour installer les outils de builds.

Ce qui est pratique d'avoir une image docker c'est qu'une fois que tu l'a validée, tu peut facilement savoir s'ils ont fait évoluer leur environnement de build.

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

Système propriétaire, ça me semble assez clair, pas fourni sous licence libre.

T'es nouveau par ici ? Ça s'étripe à tour de bras pour savoir ce qui est libre ou non. Tout le temps. Tu as au moins 3 ou 4 entités reconnues qui ont leurs définitions de logiciels libres. Elles se recoupent en grande partie évidement, mais qui ne sont pas identiques pour autant.

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

Il me semble que certaines passes de llvm étaient loin d'être optimales pour rust. Plus exactement que la transcription de rust vers le format/langage pivot de llvm était difficile à faire.

Dis autrement rust utilise llvm, mais si le backend est aussi mature que le projet llvm lui-même le frontend est une nouveauté construite pour rust (pas from scratch, mais on est pas à la maturité de backend).

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

C'est ce que j'ai tendance à faire particulièrement à l'étranger où il n'est pas forcément évident de connaître la vitesse limite.

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

Je vais tenter d'exprimer ce que je pense qu'a voulu dire pulkomandy de manière encore plus neutre.

Si le projet choisi des systèmes qu'ils supportent et d'autres qu'ils ne supportent pas pour des raisons politiques : qu'est-ce qui décrit de manière clair et pas sujet à interprétation les systèmes acceptables ou non par le projet ?

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

Là encore, fais des suppositions, puis tu tires des conclusions à partir des suppositions que tu as tirées – qui sont donc fausses.

J'ai décris comment moi j'ai fais et fini en disant que ça ne suffit peut être pas pour tout le monde. On arrivait à le faire aussi avec jenkins via les secrets.

Je ne dis pas que tu ne rencontre pas de problème, mais que dire que dès que tu es multi-dépôts ça ne marche pas c'est faux. Ils ne gèrent probablement pas tous les cas (j'imagine par exemple que selon le runtime que tu utilise ça va coincer), ça pourrait être plus simple, ça pourrait être mieux géré (jenkins en soit est relou à ustiliser).

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

Tu déformes mon propos et tu réponds à la déformation, on ne va pas aller loin comme ça.

Le problème des « cases » n'est pas « les vieilles technologies ».

Ce n'était pas ma volonté, mais quand j'entends « projet sur le quel on a pas la main » c'est généralement pour expliquer que la dette technique elle est chère etc.

D'ailleurs le pire pom.xml que j'ai croisé (près de 10 000 – dix mille – lignes était un projet qui avait quatre ans, en Java 11, et qui respectait la structure habituelle des projets Maven.

Je ne vois pas comment c'est expliquable (autrement que par de l'incompétence¹). Donne leur le build tool que tu veux ils feront n'importe quoi avec. D'ailleurs être en mesure de sortir ça avec maven, ça me fait peur d'imaginer ce que ça pourrait donner avec gradle.

Non, quand je parle de « cases » qui sont trop petites et qui nécessitent des contournements, il ne faut pas aller chercher loin. Par exemple, avoir trois dépôts Docker séparés pour les builds snapshot / release / nightly.

On gère ça avec une properties dockerRepository qu'on set comme on le souhaite. On a pas de nightly, mais dev par défaut, qlf on surcharge via la CLI et release c'est reset dans un completion goal du release prepare. Ça convient peut être pas chez vous.

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

Ça, et la gymnastique imposée par le langage autour des types signés uniquement, dans un contexte embarqué où il faut discuter avec des chips par messages fignolés au bit près, c'est gavant.

On pourrait dire l'inverse sur l'utilisation d'entiers plus ou moins longs (signés ou non) et de caractères (?) (toujours signé ou non (???)) pour représenter une suite de bit. Tout le monde est naît avec ça du coup on le voit plus mais ça n'est pratique que parce qu'on a des années d’expérience. Utiliser quelque chose qui représente un champ de bit est beaucoup plus pratique.

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

[…] ils sont conçus pour ce cas de build simple où tu rentres très exactement dans les cases prévues, mais pas pour la vie réelle où tu as des cas plus complexes sur lesquels tu n’as pas la main.

Ça demande une certaine mauvaise fois ou à minima un haut niveau d’exagération d'affirmer ça quand on voit un maven qui a était conçu pour normaliser à fond les builds et qui a rencontré un gros succès. Cette même normalisation d'ailleurs sur la quelle s'appuient gradle/sbt/ant+ivy pour ne pas avoir à réinventer la roue.

Je ne dis pas que l'inverse n'existe pas, mais affirmer que « dans la vie réelle » les conventions ça marche pas et tu dois tweaker c'est y aller fort.

Après c'est toujours pareil, les softs qui continuent de tourner en Java5, de compiler qu'avec gcc 2.92, d'utiliser une interface XUL,… personne n'a envi de payer leur dette à leur place. Ça peut être vu comme une forme de jeunisme, mais c'est aussi une question de ne pas ossifier les technologies.

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

1. Toute la complexité est masquée derrière une syntaxe et des « outils » qui se veulent simples.
2. La partie masquée de la complexité est rendue artificiellement inaccessible, parce que les API mises à disposition sont trop partielles et n’ont pas de points d’extension :
3. Même configurés à fond de leurs capacités, les meilleurs IDE n’ont pas les moyens de donner des conseils pertinents.
4. On doit donc se reposer entièrement sur la documentation, qui est souvent mauvaise.
5. La notion même de DSL rends complexe le lien entre une déclaration et le code exécuté – ce qui empêche l’exploration pour savoir ce qui va être fait exactement.
6. On peut mettre du code arbitraire ou presque, mais le debug est impossible (notamment les points d’arrêt).
7. Rien n’est typé et la syntaxe est trop libérale, on découvre toutes les typo au runtime.
8. Comme le DSL masque la complexité, plus personne ne comprends ce qui se passe réellement2. Conséquence : les plugins sont d’une qualité catastrophique et conçus pour ne gérer que le cas précis de la personne qui les a développés – or ces plugins sont indispensables.
9. Pire : les documentations pour développer (ou aider à la maintenance) des plugins sont elles-mêmes mauvaises, ce qui empire le phénomène.

Tout ce que tu décrit au choix :

• marche aussi bien pour l'utilisation de langages déclaratifs (1, 2, 4, 5, 8)
• n'ont rien d'intrinsèque à l'utilisation d'un langage impératif (7, 9)
• le typage est très dépendant du langage que tu choisi (7)
• je ne vois pas beaucoup d'outil véritablement aider pour le 3, par exemple netbeans est le seul outil à faire une intégration poussée de maven, les gens se contente très bien d'intelij qui a une intégration à peu près équivalente pour maven et gradle

Le seul point qui reste c'est d'avoir du code que tu ne peux pas facilement debugger. La solution est toute trouvée c'est de ne pas fournir un outil qui se configure via un DSL, mais une bibliothèque que tu utilise dans le build que tu implémente. C'est comme ça que fonctionne le gestionnaire de fenêtre xmonad par exemple.

Personnellement je trouve qu'il y a infiniment plus de valeur à avoir un build simple qui ne cherche pas à triturer pleins de choses parce que "tu comprends mon projet il est différent de tous les autres donc je vais pas me contenter de faire comme tout le monde" et je pense que si un outil de build passe à se paradigme ça va donner des builds infernaux à maintenir dans le temps et à comprendre.

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

Depuis 2008, l'article 18 de la Constitution autorise le président de la République à tenir un discours devant le Parlement réuni en congrès. Avant c'était autorisé mais sous forme de message (pas de présence personnelle du président). Le Parlement peut débattre mais aucun vote ne peut avoir lieu dans un tel cadre, justement dans le but d'éviter un coup d'Etat orchestré par le président qui pourrait faire pression directe sur les parlementaires.

Ce qui n'a rien à voir avec la venu d'un président à l'Hôtel de Lassay. Strictement rien.
Ce n'est pas illégal pour autant ce n'est pas l'hémicycle. Mais pour ce qui est de l'esprit de la règle ça avait fait débat.

Et oui je suis d'accord que les coutumes ont un certains poids, j'ai juste dis qu'en France on est habitué à inscrire dans les textes beaucoup plus de choses.

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

Meme si la tradition veut qu'il n'utilise aucun de ces pouvoirs, constitutionnellement, il a quand meme pas mal de pouvoirs.

Ça paraît choquant vu qu'en France j'ai l'impression que les hommes politiques jouent au maximum avec le degrés de liberté que les textes leur donnent.

En France à cause du coup d'État de Napoléon, le président n'a plus le droit d'aller à l'assemblée nationale. Au Royaume-Uni je suis persuadé qu'ils ne ce seraient pas embêté à l'écrire sur un texte chez nous c'est constitutionnel. Malgré ça n'a pas empêché Hollande de jouer avec la règle en allant à l'Hôtel de Lassay, mitoyen du Palais Bourbon.

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

Oui je suis allé un peu vite.

Après pour faire la même chose il faut ajouter pas mal annotation dans ton code (pour utiliser le sharing de splint). Ça revient un peu à dire que les langages objets n'apportent rien face au C puisque le C++ ou l'ObjectiveC existent.

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

C'est loin d'être au niveau de ce qui est pointé plus haut. En particulier aucune de ces options ne s'approche de ce que fait le borrow checker alors que splint si. Il faut ajouter pleins d'annotations à ton code, mais il fait des vérifications approchantes. Bon il n'a pas reçu de mises à jour ces 12 dernières années donc il maîtrise probablement bien moins de cas que le borrow checker de rust qui est régulièrement amélioré sur ce point.

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

D'autant plus pour un éditeur d'au moins 3 plateformes (windows, azure, xbox). C'est pas anormal de donner son avis. Surtout qu'on peut pas les taxer de mettre en avant un de leur produit (comme ça pourrait être le cas avec C# ou F# par exemple).

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

• https://github.com/NASA-SW-VnV/ikos/
• http://splint.org/
• … (voir https://github.com/analysis-tools-dev/static-analysis )

L'analyse statique ne fais que ce qu'elle peut quand le langage ne te donne pas la sémantique de ce que tu veux analyser. D'après-toi, pourquoi est-ce que ces solutions ne sont pas incluses dans gcc ou clang ? Pourquoi est-ce que c'est à ajouter à ton processus de build et pas directement inclut dans ton installation et activé avec un -pdantic ?

vous savez que les applications qui monitorent/contrôlent les réacteurs nucléaires, ou machines médicales à rayons X, ou autre trucs qui peuvent tuer des gens sont minoritaires ?

Les plus hautes sécurités ne sont pas liées au langage. C'est le processus de développement qui assure la qualité et non une silver bullet derrière la quelle on se sentirait protégé. Ça peut incorporer comment faire des tests, quand, sur quelle partie, comment suivre les défauts, la traçabilité des choix, ça peut inclure de la preuve de programme aussi, dans certains cas ça peut aller jusqu'à faire une enquête de de moralité des intervenants.

Aucune solution technique ne te protègera d'un bug fonctionnel hors dans les cas les plus critiques tu ne veux pas avoir de problème fonctionnel.

Vous savez que Rust n'a rien inventé ?

Comme tout langage rust est un équilibre choisi entre tout un tas de paramètres (sécurité mémoire, taille du runtime, sémantique du langage, système de type, etc) en prenant en compte l'état de l'art au moment de sa conception. L'équilibre choisi entre sécurité mémoire par défaut et légèreté du système de type le rend populaire.

C'est aussi bête de croire que rust résout toutes les difficultés sans surcoût que de se cacher les yeux en affirmant qu'il n'apporte rien.

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

pédagogie : jamais été mis comme exception

C'est des fois décrit comme exception. Dans un cadre pédagogique c'est autorisé grâce au ministère qui fait ce qu'il faut pour : Exception pédagogique

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