T'es entrain de dire il suffit de poser un binaire, avoir un lien symbolique et un fichier desktop donc tout se vaut. Tu essentialise tellement que ça n'a plus de sens.
Quand tu parle de .tar.gz je ne sais pas de quoi tu parle. Les .tar.gz dont on parle classiquement sont des sources qui demandent ./configure.sh && make && make install.
Ces applications de l'utilisateur ont juste besoin d'ĂŞtre trouvable dans le PATH et d'avoir un .desktop quelque part. Il existe une solution hyper simple :
Donc me dire que j'ai tord parce que "Linus Torvald a dit que" il y a 8 ans, le tout pour souligner que "Debian c'est de la chiasse au moins sous Windows et Mac ça marche", c'est pas de l'irrespect ?
Et est-ce que t'a vraiment envie d'avoir une conversions de string par default, a chaque comparaison, quand tu recode un compilateur, qui auras 10M lignes de code à recompiler le plus rapidement possible ?
Je ne comprends pas ce que tu veux dire de quelle conversion tu parle ?
c'est aussi vouloir lui enlever le choix dans la pratique de ses programmes, c'est un peu incompatible avec le libre comme point de vue?
Je n'affabule pas. Je ne change aucun de tes mots. Tu affirme que faire du web c'est vouloir enlever le choix et tu te demande si c'est compatible avec le libre.
Soit dit en passant il est plus simple de fournir un paquet electron d'une appli web que de fournir une version web via wasm d' une application native (wasm n'est pas fou avec n'importe quel langage, notamment ceux qui ont un gc).
[^] # Re: Go with C
Posté par barmic 🦦 . En réponse au journal Interface graphique en Go!. Évalué à  3.
Pour essayer de repartir sur des bases moins toxique je vais prendre ce qui me paraît cœur.
Le problème c'est que d'un côté c'est une potentialité et de l'autre c'est utilisé au quotidien par tout un chacun.
Dans les fait Windows par de très loin avec quelque chose qui permettais facilement d'installer des choses, mais peu sécurisé et difficile à maintenir et ont beaucoup évolués. L'aspect communautaire fait que sur linux, on a créé des potentialités mais pour le moment aucune n'a suffisamment percée pour être disponible partout et avoir la finition qui convient pour vraiment permettre de le laisser dans les mains d'un utilisateur moyen.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Go with C
Posté par barmic 🦦 . En réponse au journal Interface graphique en Go!. Évalué à  0.
T'es entrain de dire il suffit de poser un binaire, avoir un lien symbolique et un fichier desktop donc tout se vaut. Tu essentialise tellement que ça n'a plus de sens.
Quand tu parle de
.tar.gzje ne sais pas de quoi tu parle. Les.tar.gzdont on parle classiquement sont des sources qui demandent./configure.sh && make && make install.Tout le monde à le droit écrire dans ce /apps ? Il n'est pas définir par HFS actuellement, /opt peut mais il n'est pas aussi normalisé. Comment tu met à jour tout ça ?
Mais du coup ta solution pour dire qu'il n'y a pas de problème avec les systèmes de paquets c'est d'en concevoir un nouveau ?
On ne doit pas être d'accord sur les termes, mais du coup je ne comprends pas quel point de vu tu me donne. Ce dont tu parle c'est d'un système de paquet mis en place par les développeurs d'Apple, mais le boulot de packaging est fait par les développeurs d'application. Comme je le disais dans mon commentaire : une solution qui permet aux développeurs d'application de fournir un logiciel sans que ça n'ajoute du travail aux développeurs Apple.
Les gestionnaires de paquets :
Le boulot de créer des package doit revenir au développeurs des applications à packager.
Le boulot de créer les systèmes de paquets doit revenir aux développeurs de distribution.
Le point initial c'est "la difficulté à créer un package qui soit utilisable à peu près partout sans difficulté est un problème".
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Trop simple ?
Posté par barmic 🦦 . En réponse au journal Interface graphique en Go!. Évalué à  5.
Juste pour ceux qui veulent se renseigner, on parle souvent de virtual DOM et c'est pas lié à Flux. Tout framework déclaratif l'utilise (ce n'est pas toi qui dit comment modifié le dom, tu présente ce que tu veux et le framework fait les changements).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Trop simple ?
Posté par barmic 🦦 . En réponse au journal Interface graphique en Go!. Évalué à  3.
C'est pas parce que tu ne connais pas que tu peux y sortir tous tes poncifs. Le 2 way data bindings consomme énormément de ressource là où flux peut être implémenté de manière triviale. Il en existe des implémentations, mais tu peux très bien suivre cette architecture en js vanilla et ça va être largement plus simple qu'implémenter le 2 way binding.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Go with C
Posté par barmic 🦦 . En réponse au journal Interface graphique en Go!. Évalué à  3.
Pas dans celui que j'ai cité.
Ça ne marche pas et ça ne marchera pas dans l'avenir. Les distributions ont de plus en plus de mal à avoir des contributeurs, le nombre de logiciels est croissants,… Cette découpe cathédralesque « tout le monde reste chez soit et les moutons seront bien gardé » ne fonctionne pas, ce n'est pas ce qui est fait dans tous les systèmes où le packaging n'est pas un problème et où on a un foisonnement de logiciels. On y croyait dans les années 90, mais ça devient compliqué à tenir et ça ne va pas en s’arrangeant. Si c'était réellement le cas on aurait pas vu arriver autant de système de paquets arrivés pour combler un besoin qui n'existerait pas. Les développeurs debian sont satisfait de dpkg.
Ce n'est pas ce qu'il font. Très peu d'utilisateurs de windows et mac ont une véritable toolchaine sur leur machine. Sur windows les gens font pas mal d'installeur et sous mac ça se rapporche (il me semble) d'un appimage mais mieux intégré (le finder les prends automatiquement en compte) et aujourd'hui les 2 poussent vers un store, mais ce n'est pas comme les dépôts debian/redhat, les développeurs poussent eux même leurs paquets.
Quelque soit la manière permettre aux développeurs de fournir un paquet aux utilisateurs linux, qui soit correctement installés (inclus dans le launcher et dans le $PATH à minima) sans devoir attendre le bon vouloir des distribution ou sans que ça représente une charge de travail en plus pour elles. Aujourd'hui on s'en approche à peu prêt (on reste avec au moins 2 solutions très distinctes dans leur utilisation - donc l'utilisateur doit connaître les 2 -), mais ça demande encore du travail.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Go with C
Posté par barmic 🦦 . En réponse au journal Interface graphique en Go!. Évalué à  2.
Juger les gens plutĂ´t que leurs arguments c'est toujours dommageable.
Ces systèmes de packages n'ont pas fondamentalement changé les problématiques. AppImage par exemple n'est pas intégré en tout cas dans les distributions que j'utilise (il faut que je le mette moi dans un dossier de mon $PATH, il n'a pas de .desktop - moi je n'en ai pas besoin, mais c'est un problème,…). Flatpack ne met pas lui applications dans mon $PATH et pose des contraintes (de build si par exemple tu utilise maven, d'intégration si tu a un système de plugin). Dans les faits aujourd'hui tu as encore énormément de développeurs qui font du dpkg/rpm voir du
curl | sh -.Ça va peut être dans le bon sens et on est peut être dans un moment préliminaire, mais on y est pas encore.
Linus les connaissait en 2014 et comme IPv6, on le voit plus, mais il n'est pas dominant loin de lĂ .
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Go with C
Posté par barmic 🦦 . En réponse au journal Interface graphique en Go!. Évalué à  3.
Et être constructif, ne pas se comporter comme un troll c'est de ne pas se contenter de s’arrêter là dessus pour "vaincre l'adversaire".
Aucun n'a pour le moment changé véritablement la donne. Aujourd'hui le packaging de distribution est toujours extrêmement majoritaire et les distributions qui tentent de s'appuyer quasi exclusivement sur ces packgings sont tout à fait expérimental.
Bon et flatpack existe depuis 2007 et appimage depuis 2004.
Le fait que les développeurs ne sont pas en mesure de produire des packages n'est pas un problème pour les systèmes de packaging ?
Œil pour œil dent pour dent, c'est pas moi qui ai commencé,…
L'amour propre ça se travail tu sais.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Trop simple ?
Posté par barmic 🦦 . En réponse au journal Interface graphique en Go!. Évalué à  6.
Flux est un pattern ça peut s'implémenter un peu partout. J'ai déjà des appli qui font du flux pour gérer et mettre à jour leur état avec des composants MVC. Les composants MVC ne modifient jamais eux même leur état, à la place ils propagent des actions au reducer qui une fois qu'il a généré le nouvel état le donne au modèle du MVC.
Ca permet de faire de toujours se contenter d'un simple binding de données ce qui simplifie la vie du framework mvc que tu utilise.
Par contre le fait que ça ne soit pas natif comme avec elm demande plus de rigueur (on a vite fais de s'ajouter un 2way binding pour gérer un truc dans son coin).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Go with C
Posté par barmic 🦦 . En réponse au journal Interface graphique en Go!. Évalué à  5.
C'est une disqualification facile. C'est le point présenté par un speaker à la DebConf 2014. Alors tu peux affirmer que la debconf n'est pas pertinente pour parler de packaging sur linux, mais il va falloir un peu plus d'arguments. De plus Linus ne dis pas « je m'appelle Linus et je vous dis que ça c'est mal », mais il explique son point de vu (il est entrain de dire devant un parterre de Debianeux motivés que le packaging debian a des problèmes).
Bref ce n'est pas parce que l'auteur est connu qu'il est possible de botter en touche comme ça. Oui il a était amené un peu à la truelle ("Linus est du même avis que mois" plutôt que "je suis d'accord avec les arguments de Linus"). Les arguments sont pour autant bien là quelque soit ton manque de respect.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Trop simple ?
Posté par barmic 🦦 . En réponse au journal Interface graphique en Go!. Évalué à  4.
C'est justement contre ça qu'à était pensé le pattern flux (et dérivés). Tu fais du binding de données avec un MVC et dérivés (MVVM et autres). Avec flux tu n'a pas de correspondance direct entre une action utilisateur et une variable qui est modifiée.
La doc de redux est pas mal pour découvrir peut être https://redux.js.org/understanding/history-and-design/prior-art
Grosso modo les 3 implémentation dont j'ai le plus entendu parler c'est elm, redux, vuex.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Survivor
Posté par barmic 🦦 . En réponse au journal C, un âge remarquable. Évalué à  3.
J'ai déjà eu le problème parce que toutes les implémentations de awk ne sont pas en mesure de gérer l'unicode et ma solution c'est toujours de sortir perl.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Survivor
Posté par barmic 🦦 . En réponse au journal C, un âge remarquable. Évalué à  7.
Très caricatural.
grep '^...$'n'est pas un traitement de texte. C'est le travail d'une bibliothèque d'expression régulière ? Alorswc -c ?Rien que pour afficher des données de manière tabulaire comme le fais
ls -l.https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Survivor
Posté par barmic 🦦 . En réponse au journal C, un âge remarquable. Évalué à  3. Dernière modification le 03 mars 2022 à 07:06.
Je ne comprends pas ce que tu veux dire de quelle conversion tu parle ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Survivor
Posté par barmic 🦦 . En réponse au journal C, un âge remarquable. Évalué à  5.
Mozilla n'a plus aucun rapport avec rust.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Je ne comprends pas trop ce qu'on reproche Ă FF
Posté par barmic 🦦 . En réponse au lien Est-ce que Firefox est en bonne santé?. Évalué à  1.
Si un outil peu t'aider https://linuxfr.org/users/jeanclaude-2/journaux/karma-is-considered-harmful
J'aurais réellement essayé que la discussion soit ouverte et me concentré sur ce que tu as dis plutôt que du personnel. Je trouve sincèrement que les discalifications en sophismes et en liberté à tout va sont violent même quand leur ton sont feutrés.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Survivor
Posté par barmic 🦦 . En réponse au journal C, un âge remarquable. Évalué à  4.
Tu sors des poncifs.
Quand je parle de difficultés à gérer la mémoire c'est très simple à vérifier tout outillage qui existe il ne se passe pas plus de 3 ou 4 mois sans de nouvelles cve pointant des gestions de mémoires problématiques.
Quant à la question de l'assembleur elle n'a pas de sens. On parle entre langage turing complet, tu peux compiler les uns vers les autres. Mais si tu as prouvé certaines propriétés dans un, elles seront maintenues à travers ta compilation. Je n'ai pas dit qu'il est impossible de faire un programme C dénué de bug de mémoire, mais sa sémantique ne permet pas de s'en assurer.
Je ne vois pas comment on peut correctement utiliser un langage sans accepter de voir ses défauts (et ils en ont tous).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Survivor
Posté par barmic 🦦 . En réponse au journal C, un âge remarquable. Évalué à  3.
Pas que loin de là . Il y a pleins de logiciels de bureau écrit en C gimp par exemple. Aujourd'hui je n'ai pas l'impression que c'est le langage de prédilection pour ce genre de logiciels.
Ce qui n'a pas était dit plus haut c'est que le C est la lingua franca des langages de programmation et bien des bibliothèques natives même si elles sont implémentées dans d'autres langages offrent une API C. Il n'y a pas d'autres raisons à ça que son statut. C'est très bien parce que ça signifie que la fragmentation une machine vient avec son langage n'a pas tenu, mais c'est aussi un nivellement.
Ce qui est dommage avec le C c'est juste la gestion de la mémoire très difficile et sa propension a permettre les buffer overflow par exemple.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Je ne comprends pas trop ce qu'on reproche Ă FF
Posté par barmic 🦦 . En réponse au lien Est-ce que Firefox est en bonne santé?. Évalué à  2.
Je n'affabule pas. Je ne change aucun de tes mots. Tu affirme que faire du web c'est vouloir enlever le choix et tu te demande si c'est compatible avec le libre.
On est pas vraiment sur un questionnement ni sur une demande, mais sur une attaque sur la démarche du développeur.
Si tu m'a vu agressif tu m'en vois désolé, je critique ton commentaire et pas toi. Je n'ai aucun doute que tu ne sors pas des choses comme ça dans des issues. J'ai tenté de resté descriptif et c'est ce que je continue de faire dans ce commentaire.
Maintenant pour ton problème avec le web qui serait discriminant…
Il est impossible (hors grosses organisations) de fournir un logiciel accessible à tous. Donc oui des fois ça demande un accès au réseau, des fois ce n'est pas disponible si tu es sur MacOS ou haiku, des fois c'est sur terminaux mobile que c'est compliqué ou l'inverse, des fois c'est si tu as des problèmes de vue ou pour utiliser un dispositif de pointage que ça devient compliqué,… Il faut faire au mieux, mais il faut comprendre que les gens font avec les moyens qu'ils ont. Ce n'est pas en se montrant sévère que les choses changent.
Par exemple si trop peu de gens s'intéressent à l'accessibilité aux handicapes, le web fourni il me semble de base une meilleure accessibilité (augmentation des contrastes d'une page, un zoom universel,…). Bien sur je parle de base et il est facile de casser ça, mais avec Qt tu n'a rien et c'est au développeur d'être actif pour avoir un minimum d'accessibilité (grosso modo chez Qt l'accessibilité se limite à une page de conseils).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Je ne comprends pas trop ce qu'on reproche Ă FF
Posté par barmic 🦦 . En réponse au lien Est-ce que Firefox est en bonne santé?. Évalué à  2.
Tu considère comme non discriminent ce qui ne te discrimine pas toi et tu me parle de sophisme ?
Si l'interpréteur c'est une machine virtuelle java ou .Net tu dirais la même chose ? Tu place la barre où elle te convient.
Dans un bon gros cycle en v avec cahier des charges etc. Tout à fait la façon de travailler classique en LL…
Non tu te pose en utilisateur agresseur (et le ton feutré ne rend pas le fond moins aggressif).
Les utilisateurs peut être mais plus haut je ne vois pas une demande, mais un procès en déontologie pour ne pas avoir fais des choix qui te conviennent et c'est d'une violence dont tu ne te rend pas du tout compte. Dire à quelqu'un qui fourni un travail en faisant de sa propriété intellectuelle (on peut discuter de copyleft mais bref), pour se voir intenter un "tu fais du web ça contrevient au libre", c'est :
Et c'est véritablement un truc qui est un vrai problème plus général encore que tu qui t'en prend à un dev. Il y a un effet de halo au libre qui est une simplification : le libre c'est bien donc ce que je considère comme bien doit être libre et la contraposée que tu nous montre : ce qui ne me plaît pas n'est pas libre. Et on voit à longueur de temps ici ou là des inquisiteurs : toi tu n'aime pas le libre, toi tu fais du web tu ne fais pas du libre,…
Personnellement ça me pousse à ne plus me revendiquer d'un quelconque mouvement libre qui qui me semble toxique.
Non. Si tu n'a pas accès au code ce n'est pas du libre. Ça c'est dans toutes les définitions de logiciel libre.
Tout comme tu as des logiciels libres qui s'interfacent avec des logiciels non libre (sur windows ou mac os par exemple) ça existe est c'est largement discuté, mais ce n'est pas ce dont tu parlais.
Ça c'est la promesse dans les faits c'est différent.
Oui et tu dois réimplémenter ton runtime sur wasm et ça n'est pas vraiment transparent. C'est pour ça qu'un paquet de langages ne sont pas directement utilisés sur wasm, on utilise des falvour plus légères (tinygo pour go, blazor pour .Net, native image pour java, micropython pour python,…). C'est un interpréteur pour faire tourner n'importe quel langage… à partir du moment où le langage a était adapté pour.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Je ne comprends pas trop ce qu'on reproche Ă FF
Posté par barmic 🦦 . En réponse au lien Est-ce que Firefox est en bonne santé?. Évalué à  1.
Et on va dire que ne mettre à disposition qu'une version native et pas web, c'est enlever du choix et donc incompatible avec le libre ?
Et si l'appli demande perl le fais de ne pas pouvoir l'utiliser sans c'est aussi incompatible avec le libre ?
…
Le libre ce n'est pas un moyen pour imposer les desiderata des utilisateurs parce qu'ils veulent pouvoir faire tout ce qu'ils imaginent. Demander des choses évidemment, mais il n'y a pas besoin de partir en procès pour atteinte au libre pour autant.
Soit dit en passant il est plus simple de fournir un paquet electron d'une appli web que de fournir une version web via wasm d' une application native (wasm n'est pas fou avec n'importe quel langage, notamment ceux qui ont un gc).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Je ne comprends pas trop ce qu'on reproche Ă FF
Posté par barmic 🦦 . En réponse au lien Est-ce que Firefox est en bonne santé?. Évalué à  1.
Je ne comprends pas en quoi c'est une métrique intéressante.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Dur de résister, déso
Posté par barmic 🦦 . En réponse au journal [LKML] Est-ce le moment de supprimer ReiserFS ?. Évalué à  -1.
Et parce que ce n'est pas un mkfs ce n'est pas un formatage ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Dur de résister, déso
Posté par barmic 🦦 . En réponse au journal [LKML] Est-ce le moment de supprimer ReiserFS ?. Évalué à  6.
Ça va pas tarder. Les disques durs sont généralement vendu pour environ 11 ans d'utilisation continue, mais les arrêts/démarrage les uses plus vite. Si c'est un SSD, ceux d'il y a 15 ans sont pas d'une grande fiabilité c'est déjà beau qu'il ai encore des secteurs de rab.
ReiserFS, ext4 ou fat32 ne change pas grand chose à ça.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Dur de résister, déso
Posté par barmic 🦦 . En réponse au journal [LKML] Est-ce le moment de supprimer ReiserFS ?. Évalué à  7.
Une installation de debian avec popcon d'installé (c'est proposé par l'installeur).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: fuse
Posté par barmic 🦦 . En réponse au journal [LKML] Est-ce le moment de supprimer ReiserFS ?. Évalué à  5.
Ou via un module du noyau, mais disons que ça dépend de son usage. Il représentent un petit coût de maintenance pour la LKML (même s'ils veulent le retirer), ce sera plus de travail d'avoir des gens qui le maintiennent hors noyau est-ce qu'il y a les développeurs pour ça ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll