barmic 🦦 a écrit 5976 commentaires

Oui même s'il faut y faire attention, nous serions déçu si ce genre de règlement avait était passé il y a 5 ans forçant à utiliser le micro usb et que la mise à jour de cette loi ne s'applique qu'en 2024.

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

Pouvoir utiliser le même chargeur pour son téléphone, ses différents casques/écouteurs audio, les lampes de vélo sur batterie, recharger une powerbank, charger l'enceinte bluetooth,… Sans avoir un nouveau chargeur à l'achat si on en a déjà un. Ça me aller avec l'idée de produire plus que nécessaire.

Pour le moment il n'y a que ma frontale pour qui je voir avoir un adaptateur usb c → micro usb et la recharge par induction n'est pas aussi généralisée et a un rendement bien plus faible qu'un chargeur usb correct.

Mais c'est de la même manière que l'absence de micro jack sur le fairphone 4 est dommageable, soit tu passe par du bluetooth soit tu doit passer par des adaptateurs micro-jack / usb c.

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

C'est dans leur tableau : https://xon.sh/contents.html#comparison

Je comprends pas la moitié du tableau :

• c'est quoi un langage pratique ?
• native cross-plateform support → oui/non ? C'est le genre de question ou on donne la liste de ce qui est supportée
• Typed variables → je connais pas plumbum, mais il y en a en bash et zsh
• Syntax highlighting → ça existe en zsh, ce n'est pas en standard, mais c'est un paquet et une ligne de commande dans ma distribution (debian pas un truc très spécifique) et c'est de base dans mon ipython sans jupyter
• Pun in name → fish ça en est pas un ?

Le Easily scriptable n'a pas de sens pour ipython qui n'est pas un langage, son langage c'est python. Donc c'est peut être vrai (je ne sais pas quels sont les difficultés qui se passent quand on essaie d'utiliser ipython comme sheban), mais c'est un moyen assez facile de retirer une coche à une alternative.

Du coup je vois pas quoi tirer de ce tableau.

Ou juste parce-que c'est surtout un environnement de débogage et de test avant tout https://www.ics.uci.edu/~dock/manuals/IPython/node7.html ?

On parle de ce qui est la base de jupyter. C'est bien plus qu'un environnement de debogage. C'est un shell python qui permet de se servir de python de manière interactive (chose que perl a mis du temps à avoir). Le fait qu'il puisse aider au debuggage (c'est ce qu'on doit comprendre de ton lien ?) n'indique pas du tout que c'est "surtout" à ça qu'il sert.

Si on prend la plus vielle version de la page du projet qu'on peut trouver dans waybback machine : https://web.archive.org/web/20110721132832/https://ipython.org/

The goal of IPython is to create a comprehensive environment for interactive and exploratory computing.

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

Ça c'est vraiment ta subjectivité et on pourrait arguer la même chose quand tu utilise /me. Évidemment que pour l'auteur ça va de soit, il n'écrit pas volontairement un message cryptique. Il écris avec sa subjectivité, son savoir, sa culture et ne s'est pas posé la question de si l'une de ses références est connu de tous ou pas.

Ça arrive partout peut-être un peu plus sur internet où il peut y avoir un brassage culturel plus large et où l'on a que nous écrits pour savoir qui est l'autre (les belges peuvent se baser sur l'accent pour éviter d'utiliser nonante devant des français pour ne pas avoir de remarques, un jeune peu imaginer que quelqu'un qui a la soixantaine n'aura pas la référence du dernier dessin animé qu'il a regardé à la télé,…).

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

Ne pas comprendre ce que quelqu'un dit ça arrive. Ce n'est pas forcément du gatekeeping. On communique tous à l'oral comme à l'écrit avec nos connaissances, nos cultures, etc. Particulièrement dans les commentaires contrairement aux journaux ou aux dépêches le travail de poser toutes ses références n'est pas toujours fais car c'est des textes cours voir que c'est simplement plus léger à écrire et à lire.

Il faut plus voir ça comme une opportunité de découvrir quelqu'un que comme un entre soit. C'est une discussion d'initiés comme il y en a toujours eu ici, mais je n'ai jamais vu quelqu'un se faire ridiculiser ou ignorer ici parce qu'il ne connaissait pas une référence.

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

Ils ne sont pas dans l'installation de base des distributions. Ça n'aide pas à leur adoption.

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

Toute l'histoire de Nokia à partir des smartphones est triste…

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

Et ben c'est tant mieux. L'important c'est de ne pas changer son matériel régulièrement. Donc ils concurrencent l'un des meilleurs du marché sur ce point dès leur deuxième téléphone. Je ne sais pas pour le prix, mais ils me proposent avec un Android qui est flashable. Contrairement à Apple leur téléphone ne demandent pas de chargeur ou d'adaptateur spécial (ce qui reste un coût environnementale). Si on regarde les garanties constructeur c'est d'un an côté Apple alors que tous les fairphones 4 sont garantis jusqu'en 2027. Ils restent les seuls à ma connaissance à tenter de s'assurer que leur chaîne d'approvisionnement et montage est aussi fair que possible et ils communiquent sur ce qu'ils arrivent à faire ou non.

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

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