Désolé, mais l’affichage sera juste exactement comme suit. Une puce avec le signe => puis le texte.
Mea culpa, je n'ai pas encore tout bien appris, juste zieuté de loin et cherché un ou deux clients qui m'intéressent. En recherche d'un serveur, aussi, il y en a plein, mais je suis (trop) chiant :)
Autrement dit, une bénédiction pour ceux dont la connexion est foireuse ou payante au volume: ils peuvent ainsi lire le texte et jauger de l'intérêt de télécharger la grosse vidéo de chat qui se casse la gueule, avant de dépenser du temps, de l'argent, de l'électricité pour un truc qui ne leur sert à rien ou pire, sert à les espionner.
Une chose que tu n'as pas précisée, c'est: le logiciel est-il un "client lourd", ou un serveur (ou un cgi ou … tu m'as compris)?
Dans le cas d'un serveur, pas de souci, après tout: le code est libre dès lors que le client à le code et les droits. Rien ne te force à diffuser le code au monde entier: la seule raison qui fait que les logiciels libres sont souvent aussi des gratuiciels, c'est parce que se baser sur l'espoir qu'aucun utilisateur ne diffuse le code serait… ridicule, donc impossible de monétiser l'accès au code (et aux droits).
Dans ton cas, et si la partie à développer est destinée à être hébergée sur «la machine de l'admin», il est possible que tu aies juste une version particulière pour ce client et qu'au bout de deux ans (ou période fixée par le mécène) tu merges.
Ça reviens effectivement à s'auto-forker, et à maintenir 2 branches, mais pas de problème du point de vue légal et coupeurs de cheveux: l'utilisateur (aka le mécène) de la version B dispose des 4 libertés et du code, il s'agit donc bien d'un logiciel libre. S'il diffuse, c'est son problème (reste évidemment la surcharge de travail de devoir maintenir 2 branches en permanence, mais tu as dis qu'il paye plutôt bien, alors à toi de voir si c'est rentable).
Au moins on permet à de nombreuses personnes d'accéder au contenu
L'avantage de gemini, c'est que chaque personne à son propre client :)
Bon, et sinon, on parle d'accessibilité? Je ne compte plus le nombre de sites web qu'il me faut zoomer malgré mon écran de merde pour arriver à lire… ou les couleurs avec un contraste trop faible… "on permet à de nombreuses personnes d'accéder au contenu" j'en suis pas si sûr, du coup.
Je sais, il y a le mode lecture maintenant… qui n'apporte à gemini que les images embarquées, j'ai l'impression (qui peuvent donc être utilisées pour traquer tout).
À côté de ça, gemini, vu que c'est du texte brut, c'est utilisable facilement par les liseuses, et il semblerait qu'il y ait eu des échanges avec les premiers concernées (des aveugles, donc) pour encore améliorer ce point.
Du coup, il n'est pas impossible que justement, gemini soit utilisable par plus de personnes que le web.
Avec Gemini, n'importe quel dev à peine sorti (ou pas) de l'école peut coder son client, la ou, pour le web, les seuls que l'ont peut considérer comme les auteurs initiaux du moteur de rendu qu'ils utilisent, c'est Mozilla, et ils galèrent.
Aussi, du point de vue de la personne qui veut juste publier:
TLS oui, mais TOFU, nul besoin de se prendre la tête avec le Web of Untrust (qui a une chiée de maillons pouvant péter à tout moment, et dont la solution préconisée pour avoir rapidement son certificat, c'est d'installer une application python qui s'exécutera en root, tout en accédant au système de fichiers. Ah oui, il faut aussi un serveur web supportant CGI. Sympa, la «sécurité facile»… je ne parle pas de ce qui arrive quand une «autorité» à une fuite)
Voici un exemple de code HTML honteusement pris sur wikipedia:
<htmllang="fr"><head></head><body><header><nav><ul><li><ahref="#contenu-principal">contenu principal</a></li></ul></nav></header><mainid="contenu-principal"><!-- Contenu principal de la page --></main></body></html>
Son équivalent gemini? Probablement un truc dans ce goût la:
* => #contenu-principal contenu principal
contenu principal de la page
En terme de lisibilité, je dirais qu'il n'y a pas photo. Ah, et autre chose dont j'apprécie l'idée: pas besoin de se faire chier avec cette horreur qu'est CSS.
Alors, oui, forcément, gemini c'est pas adapté pour un site bancaire, mais bon, le web ne l'est pas vraiment non plus, pour rappel, les cookies, c'est juste un hack, et c'est aussi le problème: le web, c'est une pile de hacks plus ou moins grossiers, dont parfois je me demande s'ils sont pas faits pour faire chier (JS peut créer des onglets, c'est super, hein? Et les images animées, on en reparle? Ou les vidéo en auto-play?).
les warning dont je suis sur qu'ils sont la manifestation quasi tout le temps d'un vrai problème, je les passe en WError
Hum… ça m'intéresse, ça. Tu peux passer une seule catégorie de warnings en -Werror? Avec quel compilo?
Parce que je sais comment changer tous les warnings en erreurs (mais c'est pas vraiment viable, certains warnings type -Wpadded étant parfois obligatoires) ou alors aucun (et on rate tous les warnings importants habituellement, parce que noyés dans la masse de ceux potentiellement utiles)…
pour les warnings TRES nombreux (je pense en particulier au signed/unsigned mismatch), le soucis c'est qu'il sont à 99,99% inoffensifs
C'est pour ça que j'essaie de les corriger tous, y compris ceux-la, sur mes projets perso et mes patchs. À condition que je ne sois pas obligé de désactiver le warning pour y voir clair dans les logs, bien sûr…
Mercurial, c'est tout aussi puissant et ça peut s'utiliser via une interface graphique (HgWorkbench).
Sous windows, il doit bien y avoir tortoiseGit, me semble?
Après comme on a une réputation a tenir, on active la console en bas de l'interface histoire qu'il y ait plein de commandes qui défilent.
Si c'est ça la raison qui te fait utiliser la ligne de commande, j'espère que tu as au moins mis un thème "matrix-like", en vert sur noir.
je ne vois pas ce qu'il a de mieux
Ne connaissant pas mercurial, ni dart, ni bazaar, et très, très peu fossil, je ne peux répondre sur «l'aspect métier» (je n'ai vraiment utilisé que SVN, et encore, en étant seul sur le projet, un peu de fossil et git).
Le seul truc que je peux dire en gros c'est:
Sur le plan technique à minima (et sur ma debian), git dépend grosso merdo de C et de perl, le paquet lui-même pèse 36.2M. Mercurial, lui, pèse lui-même 923K+13.2M (~14M) et dépend de python, à vue de nez, l'installation totale me consommerait donc ~30.8M, un peu moins que git.
Pour être franc, ça me surprend énormément, ça a du changer à un moment (git aurait pris de l'embonpoint peut-être? Je vois une chiée de binaire qui sont probablement peu utilisés dans l'archive… bref), parce que c'est l'un des trucs auxquels je fait attention quand je choisis un outil.
Toujours sur le registre technologique, mercurial est implémenté dans un langage qui n'est lié à aucun standard. À l'heure actuelle, la version proposée dans les dépôts stables de Debian dépends de python2. Qui n'est plus maintenu et est considéré obsolète depuis combien de temps, déjà? (je sais, ce sont 2 dates différentes).
En gros: git est codé en C, mercurial en python. J'ai personnellement un fort biais envers les langages qui ont un vrai standard, et plusieurs implémentations dont aucune n'est "l'implémentation de référence".
Ça se discute probablement, mais vu que j'aime l'idée de pouvoir utiliser un logiciel 20 après avec les correctifs et améliorations apportées depuis, ben le fait d'être codé en python est déjà un désavantage monstre.
Maintenant, je veux bien croire qu'il puisse être supérieur à git, reste à savoir en quoi ça impacte l'utilisateur final?
Dans le cas, par exemple, de fossil, l'avantage sur git est clair: c'est une forge, pas un simple DVCS. De plus, c'est facile et robuste à migrer: un seul fichier à déplacer.
Dans le cas de mercurial? Je n'ai jamais vu d'arguments qui me semblent si importants.
Elle reviens de très loin l'implémentation, on dirait… la source préconise d'attendre au moins la v13.1 avant de s'en servir, et suppose que ça sera pas intégré par défaut mais la v13.
On passe d'un truc qui a du sens à un truc qui n'en a pas → tout le monde en à rien à foutre.
On passe d'un truc qui n'en a pas à un truc qui n'en a pas → c'est offensant.
De quand date le 1er changement dont tu parles? Pour moi, il y a fort a parier que le but était de se détacher justement de CVS/SVN, l'histoire. Le terme master à probablement été utilisé depuis la 1ère jeunesse, donc pas sûr qu'il y ait eu un changement réel, si ce n'est un changement de terminologie en changeant d'outils et de paradigme (la réplication des repo est au coeur des DVCS, contrairement à SVN/CVS).
En revanche, le 2nd lui, à bien lieu, dans un logiciel considéré comme une référence. Il y a donc une forte résistance au changement, c'est logique, ce qui est aggravé (à mon avis) par le fait que la seule raison soit clairement moralisatrice et très centrée géographiquement parlant, et non un changement qui ait un impact positif sur l'ensemble des utilisateurs.
Sur un marché, tu entends plus le marchand de poisson qui crie, ou celui qui se contente d'attendre?
C'était ça, l'image.
Mais du coup des plateformes que tu n'utilisent pas
Que j'utilise au minimum, nuance.
changent la configuration par défaut d'un nom de branche et ça a l'air de t'horripiler ?
Je suis loin d'être horripilé. Je m'amuse notamment dans le message auquel tu réponds du fait que, la personne qui semble avoir introduit le terme "master" à un nom qui m'évoque plutôt l'europe de l'est, que le far west, tout en lisant que le changement est fait pour résorber un problème typiquement nord-américain.
Et ce, en citant le très respectueux "Ding ding ding! On a un gagnant.".
Un truc qui avait l'air sympa sur le papier, mais que je n'utilise pas: les numéro de ligne relatifs: set relativenumber voire la solution hybride: set number relativenumber.
qui se sentent meurtri quand on leur proposent de passer de master à main.
Je trouve ça logique, moi, la branlette, c'est pas bon pour la santé qu'ils disaient, les anciens :)
Puis justement, peut-être que ça aurait moins râlé de repasser à «trunk» qui a, justement, un histoire dans l'informatique, continue l'analogie, etc etc, contrairement à «main» qui ne veut rien dire. (surtout dans le cas d'un VCS distribué?)
d'écrire des outils plus solides qui vont chercher le nom de la branche par défaut
Bon, qui c'est qui se dévoue pour envoyer un patch qui permets d'établir une "branche par défaut" repérable logiciellement dans git, du coup?
Non parce que cette notion, elle existe pas vraiment… En fait, «master» ou «main» c'est juste la 1ère branche, que l'on utilise par facilité comme référence… c'est tout. Une simple convention, rien de technique ici.
Posté par freem .
En réponse au journal Adieu vieille branche.
Évalué à 5.
Dernière modification le 17 mars 2021 à 10:18.
Ding ding ding! On a un gagnant. Les us ont effectivement une croûte de racisme très épaisse. C’est illustré précisément par l’utilisation abusive de maître/esclave.
Mince alors, moi qui avais cru lire "Petr Baudis dit quand même que c’est un mauvais terme et qu’il a été choisi principalement à cause de son manque de maîtrise de l’anglais à l’époque."… ou alors ce "Petr Bandis" serait un citoyen des USA qui ne parle pas anglais?
Possible, mais vu que j'imagine que cet individu est celui auquel réfère "Founder Interview with Chief AI Architect Petr Baudiš | Rossum" j'en doute fort, ou alors on m'a menti et les anglais connaissent les accents?
En fait le problème avec ce renommage, c'est qu'il se base sur des problèmes intrinsèquement locaux aux USA mais touche tout le monde.
Peut-être que ce problème de racisme et d'esclavagisme noir est encore réel et présent aux USA, mais personnellement, si un jour je tombe sur un projet qui arbore un Svastika (hé oui, c'est moi qui l'ait atteint! Enfin, pas encore rattrapé mon retard, peut-être que quelqu'un l'a eu avant…) je n'irai pas leur demander de le changer sous prétexte que ma région du monde a un très, très mauvais souvenir de ce symbole.
Restent les questions suivantes par contre: à partir de combien d'utilisateurs gênés doit-on changer des choses? Et une fois ce seuil établi, pourrait-on avoir les études qui estiment le nombre d'utilisateurs gênés par le terme master anciennement utilisé par git, par défaut?
À noter quand même, qu'au final, ce changement n'a aucun impact sur ceux qui utilisent le site, tout comme pour github: c'est le nom de la branche par défaut…
Je sais pas pour vous, mais moi, je commence par coder dans un dépôt local, puis éventuellement je crée un repo accessible aux autres, puis j'y pousse mes modifications.
De ce fait, le changement de nom de la branche principale, ben, je le verrais juste passer quand Debian intégrera la version de git qui le change. Mon code n'est pas organisé par des trucs comme github ou gitlab: ces machins ne sont que de stupides outils, que j'évite d'ailleurs au maximum tant je trouve coûteux en temps le fait d'utiliser ces «forges», qui sont en réalité bien plus proches de «places du marché» tellement on y cause et on y crie plus qu'autre chose.
Par contre, les cookies, perso, ça va pas me manquer. Pour ce qui est du système de certificats, ma foi, un client pourrait très bien trouver un moyen de rendre ça ergonomique. Je ne sais pas comment, il faudrait y réfléchir, évidemment, mais au moins ça sera pas juste un workaround parce que le protocole n'incluais pas la possibilité dès le départ, contrairement au web. Pour lequel il s'agit même d'un workaround sur-exploité.
À ce sujet, j'ai récemment été "râler" sur IRC que kristall ne permettait pas de faire de saisie sur gopher://gopher.floodgap.com:70/7/v2/vs et ça a été corrigé rapidement. Ce qui en fait le 3ème bug que je rapporte qui est corrigé en moins de deux semaines, je crois.
L'idée d'intégrer les certificats clients pour des forums pourrais probablement faire son chemin aussi, reste à construire et défendre l'idée suffisamment pour qu'elle séduise les devs, et éventuellement à l'implémenter soi-même s'ils ne sont assez convaincu que par l'idée, mais ont la flemme de l'implémenter (ils ne sont pas payés, après tout).
Effectivement. Enfin, oui et non… il reste possible d'envoyer des données au serveur, techniquement, mais ça reste bien plus primitif.
Par contre, les cookies, perso, ça va pas me manquer. Pour ce qui est du système de certificats, ma foi, un client pourrait très bien trouver un moyen de rendre ça ergonomique. Je ne sais pas comment, il faudrait y réfléchir, évidemment, mais au moins ça sera pas juste un workaround parce que le protocole n'incluais pas la possibilité dès le départ, contrairement au web. Pour lequel il s'agit même d'un workaround sur-exploité.
Par contre, on peut fort bien tenir un blog
Exactement, et je pense que c'est la l'intérêt principal: une page gemini, c'est pas de prise de tête pour la présentation, pas de prise de tête pour le certificat TLS, contrairement au web, pour lequel ces deux aspects nécessitent quand même un peu plus que de simples notions.
Non, finalement on peut surtout se demander pourquoi se rendre toujours plus dépendants des bons vouloirs d'une grosse boite dont on sait qu'elle n'est pas notre pote.
Qu'est-ce qui empêchera Google un matin de décider que le serveur de sync exigera une signature fournie uniquement par la version proprio de Chrome?
Perso, je me suis fait mordre une fois par opera, même si certes, je ne payais pas la synchro, mais depuis, c'est niet les trucs de synchro. À la rigueur, si j'en avais le contrôle, pourquoi pas, mais je préfère ne rien avoir plutôt qu'avoir un truc qui risque d'être viré aléatoirement sans que l'on ne puisse discuter la décision (de mémoire, j'avais reçu un mail comme quoi j'étais banni alors que je n'avais fait qu'essayer d'utiliser une des fonctionnalité, sans y arriver?).
Comme on dit, mieux vaut être seul que mal accompagné.
Et ça, ça vaut clairement autant pour la MoFo, la MoCorp, vivaldi (la boîte derrière) ou Alphabet.
Si un navigateur proposait, nativement un service de synchro qui soit configurable sans aller modifier à la main le about:config (que je considère l'équivalent de regedit, en moins bien foutu), j'y réfléchirais.
Je viens de regarder, ce n'est pas le cas de firefox: dans les préférences, il ne semble pas y avoir moyen de renseigner une URI de référence pour «sync».
c'est quoi la part des utilisateurs qui diraient "bouh vilains méchants" avant d'installer Chrome (mais "à contre-cœur", bien entendu) ?
Ben vois-tu, déjà je pense que tous les utilisateurs de vivaldi ou opera râleraient sévère. Ceux qui utilisent chromium sur Debian feraient la gueule, et je n'ai aucun doute que ça finirait à ce que Debian maintienne chromium. Probablement avec l'aide des devs de vivaldi et opera, ainsi que d'autres ici et la (otter browser, peut-être? Tiens, ça fait longtemps que j'ai vérifié ce qu'il vaut…).
Ça n'est certes pas au niveau des devs de Firefox, donc le résultat serait certainement à la ramasse comparé à Chrome, mais je pense que pas mal d'utilisateurs de ces solutions préféreraient largement ça. De ce que j'ai lu, il semble (basé sur le très sérieux indicateur pifométrique(tm), édité par la société très professionnelle MyFeelingCorp) que les utilisateurs de vivaldi me ressemblent sur un point: il préféraient utiliser un opera 12 non maintenu, plutôt que firefox ou chromium ou opera-blink, après tout.
Mais on est dans l'idée du « something like 64k ».
Oui, clairement. Et je soupçonne cette limite d'avoir une raison d'être de type (oui, je sais, c'est vieux, mais c'est un des docs avec lesquels j'ai appris à coder début 2000 :) et en français s'il vous plaît!) "on copie la ROM BIOS dans la RAM pour l'exécuter, sans nettoyer derrière, voire en réutilisant" des très, très vieilles applications, qui du coup ont un intérêt à mapper cette plage mémoire.
Cela dis, je n'ai aucune certitude (j'avais lu pas mal de trucs sur le boot à l'époque, comprendre les séquences initiales m'a toujours botté…) ça date trop.
Très probablement.
En l'occurrence, on parle de synchroniser les bases de données sous-jacentes, n'étant pas utilisateur, je ne sais pas si la connection se fait en permanence ou ponctuellement, mais même le cas du "en permanence", en pratique, tu ouvres une connection TCP/TLS, dès qu'un passe ou un truc est ajouté/supprimé, tu balances ton message au serveur, qui redonde sur les autres clients connectés.
Quand un client s'ouvre, il récupère son retard, quand un client se ferme, il vérifie (par acquis de conscience) que tout est OK.
Rien de bien sorcier à priori.
De l'autre côté, tu as l'UI. La, je me risquerais déjà pas à implémenter la gestion des onglets, des boîtes de dialogues et tout le toutim sans une bibliothèque (c'est ce qu'ils font d'ailleurs, gtk me semble?). Bon, on peut déléguer à une lib, mais il reste à faire une UI qui plaise et qui soit portable et qui s'intègre pas trop mal dans les OS supportés. Très, très difficile ça.
Et le pire, c'est le rendu des pages elles-mêmes. Tu dois interpréter/compiler 3 langages, dont l'un est "turing-complete". La complexité par rapport aux 2 autres éléments est nettement supérieure, sans même y ajouter de gestion des plugins et des hooks.
Bref, je vois pas en quoi c'est un problème, de pas être root. Bon, ce serveur est un jouet mal géré, faut que je nettoie, mais quand même, pas grand chose n'a ma confiance pour être lancé avec les droits root dessus.
Je sais, les processus peuvent drop les droits, en théorie. Sauf que bon, même si j'essaie d'aller lire le code un minimum, je trouve tellement plus simple qu'il n'aient pas à le faire eux-mêmes, ça m'évite d'aller lire le code en détails.
Non, ça ne répond pas à la question du forumW journal, certes, mais bon, ça répon au "besoin d'être root" par l'exemple.
[^] # Re: M'ouaif
Posté par freem . En réponse au journal HtmGem v1.0.0, un client Gemini en Php. Évalué à 3.
Mea culpa, je n'ai pas encore tout bien appris, juste zieuté de loin et cherché un ou deux clients qui m'intéressent. En recherche d'un serveur, aussi, il y en a plein, mais je suis (trop) chiant :)
[^] # Re: Puisqu'on parle de gemini
Posté par freem . En réponse au journal HtmGem v1.0.0, un client Gemini en Php. Évalué à 3.
Autrement dit, une bénédiction pour ceux dont la connexion est foireuse ou payante au volume: ils peuvent ainsi lire le texte et jauger de l'intérêt de télécharger la grosse vidéo de chat qui se casse la gueule, avant de dépenser du temps, de l'argent, de l'électricité pour un truc qui ne leur sert à rien ou pire, sert à les espionner.
# logiciel lourd ou serveur?
Posté par freem . En réponse au message Droits d'utilisation réservés et licence libre. Évalué à 5.
Une chose que tu n'as pas précisée, c'est: le logiciel est-il un "client lourd", ou un serveur (ou un cgi ou … tu m'as compris)?
Dans le cas d'un serveur, pas de souci, après tout: le code est libre dès lors que le client à le code et les droits. Rien ne te force à diffuser le code au monde entier: la seule raison qui fait que les logiciels libres sont souvent aussi des gratuiciels, c'est parce que se baser sur l'espoir qu'aucun utilisateur ne diffuse le code serait… ridicule, donc impossible de monétiser l'accès au code (et aux droits).
Dans ton cas, et si la partie à développer est destinée à être hébergée sur «la machine de l'admin», il est possible que tu aies juste une version particulière pour ce client et qu'au bout de deux ans (ou période fixée par le mécène) tu merges.
Ça reviens effectivement à s'auto-forker, et à maintenir 2 branches, mais pas de problème du point de vue légal et coupeurs de cheveux: l'utilisateur (aka le mécène) de la version B dispose des 4 libertés et du code, il s'agit donc bien d'un logiciel libre. S'il diffuse, c'est son problème (reste évidemment la surcharge de travail de devoir maintenir 2 branches en permanence, mais tu as dis qu'il paye plutôt bien, alors à toi de voir si c'est rentable).
[^] # Re: M'ouaif
Posté par freem . En réponse au journal HtmGem v1.0.0, un client Gemini en Php. Évalué à 3.
L'avantage de gemini, c'est que chaque personne à son propre client :)
Bon, et sinon, on parle d'accessibilité? Je ne compte plus le nombre de sites web qu'il me faut zoomer malgré mon écran de merde pour arriver à lire… ou les couleurs avec un contraste trop faible… "on permet à de nombreuses personnes d'accéder au contenu" j'en suis pas si sûr, du coup.
Je sais, il y a le mode lecture maintenant… qui n'apporte à gemini que les images embarquées, j'ai l'impression (qui peuvent donc être utilisées pour traquer tout).
À côté de ça, gemini, vu que c'est du texte brut, c'est utilisable facilement par les liseuses, et il semblerait qu'il y ait eu des échanges avec les premiers concernées (des aveugles, donc) pour encore améliorer ce point.
Du coup, il n'est pas impossible que justement, gemini soit utilisable par plus de personnes que le web.
[^] # Re: M'ouaif
Posté par freem . En réponse au journal HtmGem v1.0.0, un client Gemini en Php. Évalué à 1.
Tu as oublié un point important:
Avec Gemini, n'importe quel dev à peine sorti (ou pas) de l'école peut coder son client, la ou, pour le web, les seuls que l'ont peut considérer comme les auteurs initiaux du moteur de rendu qu'ils utilisent, c'est Mozilla, et ils galèrent.
Aussi, du point de vue de la personne qui veut juste publier:
TLS oui, mais TOFU, nul besoin de se prendre la tête avec le Web of Untrust (qui a une chiée de maillons pouvant péter à tout moment, et dont la solution préconisée pour avoir rapidement son certificat, c'est d'installer une application python qui s'exécutera en root, tout en accédant au système de fichiers. Ah oui, il faut aussi un serveur web supportant CGI. Sympa, la «sécurité facile»… je ne parle pas de ce qui arrive quand une «autorité» à une fuite)
Voici un exemple de code HTML honteusement pris sur wikipedia:
Son équivalent gemini? Probablement un truc dans ce goût la:
En terme de lisibilité, je dirais qu'il n'y a pas photo. Ah, et autre chose dont j'apprécie l'idée: pas besoin de se faire chier avec cette horreur qu'est CSS.
Alors, oui, forcément, gemini c'est pas adapté pour un site bancaire, mais bon, le web ne l'est pas vraiment non plus, pour rappel, les cookies, c'est juste un hack, et c'est aussi le problème: le web, c'est une pile de hacks plus ou moins grossiers, dont parfois je me demande s'ils sont pas faits pour faire chier (JS peut créer des onglets, c'est super, hein? Et les images animées, on en reparle? Ou les vidéo en auto-play?).
[^] # Re: Memory leak et warnings
Posté par freem . En réponse au journal 723, +5736, -5696… un mois de travail de résurrection d'un projet libre…. Évalué à 5.
Hum… ça m'intéresse, ça. Tu peux passer une seule catégorie de warnings en -Werror? Avec quel compilo?
Parce que je sais comment changer tous les warnings en erreurs (mais c'est pas vraiment viable, certains warnings type -Wpadded étant parfois obligatoires) ou alors aucun (et on rate tous les warnings importants habituellement, parce que noyés dans la masse de ceux potentiellement utiles)…
C'est pour ça que j'essaie de les corriger tous, y compris ceux-la, sur mes projets perso et mes patchs. À condition que je ne sois pas obligé de désactiver le warning pour y voir clair dans les logs, bien sûr…
[^] # Re: [HS] Mercurial
Posté par freem . En réponse au message git et merge graphique. Évalué à 3.
Sous windows, il doit bien y avoir tortoiseGit, me semble?
Si c'est ça la raison qui te fait utiliser la ligne de commande, j'espère que tu as au moins mis un thème "matrix-like", en vert sur noir.
Ne connaissant pas mercurial, ni dart, ni bazaar, et très, très peu fossil, je ne peux répondre sur «l'aspect métier» (je n'ai vraiment utilisé que SVN, et encore, en étant seul sur le projet, un peu de fossil et git).
Le seul truc que je peux dire en gros c'est:
Sur le plan technique à minima (et sur ma debian), git dépend grosso merdo de C et de perl, le paquet lui-même pèse 36.2M. Mercurial, lui, pèse lui-même 923K+13.2M (~14M) et dépend de python, à vue de nez, l'installation totale me consommerait donc ~30.8M, un peu moins que git.
Pour être franc, ça me surprend énormément, ça a du changer à un moment (git aurait pris de l'embonpoint peut-être? Je vois une chiée de binaire qui sont probablement peu utilisés dans l'archive… bref), parce que c'est l'un des trucs auxquels je fait attention quand je choisis un outil.
Toujours sur le registre technologique, mercurial est implémenté dans un langage qui n'est lié à aucun standard. À l'heure actuelle, la version proposée dans les dépôts stables de Debian dépends de python2. Qui n'est plus maintenu et est considéré obsolète depuis combien de temps, déjà? (je sais, ce sont 2 dates différentes).
En gros: git est codé en C, mercurial en python. J'ai personnellement un fort biais envers les langages qui ont un vrai standard, et plusieurs implémentations dont aucune n'est "l'implémentation de référence".
Ça se discute probablement, mais vu que j'aime l'idée de pouvoir utiliser un logiciel 20 après avec les correctifs et améliorations apportées depuis, ben le fait d'être codé en python est déjà un désavantage monstre.
Maintenant, je veux bien croire qu'il puisse être supérieur à git, reste à savoir en quoi ça impacte l'utilisateur final?
Dans le cas, par exemple, de fossil, l'avantage sur git est clair: c'est une forge, pas un simple DVCS. De plus, c'est facile et robuste à migrer: un seul fichier à déplacer.
Dans le cas de mercurial? Je n'ai jamais vu d'arguments qui me semblent si importants.
[^] # Re: Choix distribution
Posté par freem . En réponse au message Choix de distribution. Évalué à 2.
Il me semble que LMDE est basée sur Debian sid, donc j'imagine qu'on peut considérer comme rolling relase?
# mieux vaut attendre selon la source
Posté par freem . En réponse au lien Wireguard en voie d'intégration dans FreeBSD. Évalué à 4.
Elle reviens de très loin l'implémentation, on dirait… la source préconise d'attendre au moins la v13.1 avant de s'en servir, et suppose que ça sera pas intégré par défaut mais la v13.
[^] # Re: Et dans Pijul ?
Posté par freem . En réponse au journal Adieu vieille branche. Évalué à 5.
C'est de sa faute aussi, elle est arrivée à point!
[^] # Re: SVN
Posté par freem . En réponse au journal Adieu vieille branche. Évalué à 5.
De quand date le 1er changement dont tu parles? Pour moi, il y a fort a parier que le but était de se détacher justement de CVS/SVN, l'histoire. Le terme master à probablement été utilisé depuis la 1ère jeunesse, donc pas sûr qu'il y ait eu un changement réel, si ce n'est un changement de terminologie en changeant d'outils et de paradigme (la réplication des repo est au coeur des DVCS, contrairement à SVN/CVS).
En revanche, le 2nd lui, à bien lieu, dans un logiciel considéré comme une référence. Il y a donc une forte résistance au changement, c'est logique, ce qui est aggravé (à mon avis) par le fait que la seule raison soit clairement moralisatrice et très centrée géographiquement parlant, et non un changement qui ait un impact positif sur l'ensemble des utilisateurs.
[^] # Re: Est-ce un problème?
Posté par freem . En réponse au journal Adieu vieille branche. Évalué à 7.
Sur un marché, tu entends plus le marchand de poisson qui crie, ou celui qui se contente d'attendre?
C'était ça, l'image.
Que j'utilise au minimum, nuance.
Je suis loin d'être horripilé. Je m'amuse notamment dans le message auquel tu réponds du fait que, la personne qui semble avoir introduit le terme "master" à un nom qui m'évoque plutôt l'europe de l'est, que le far west, tout en lisant que le changement est fait pour résorber un problème typiquement nord-américain.
Et ce, en citant le très respectueux "Ding ding ding! On a un gagnant.".
# Complément
Posté par freem . En réponse au message [Éditeur/Vim] Numeroter les lignes sous VIM. Évalué à 4.
Un truc qui avait l'air sympa sur le papier, mais que je n'utilise pas: les numéro de ligne relatifs:
set relativenumbervoire la solution hybride:set number relativenumber.PS: bienvenue.
[^] # Re: Les prochains sur la liste
Posté par freem . En réponse au journal Adieu vieille branche. Évalué à -7.
Ben, pour moi, ça, ça sonne un peu comme «autiste» qui est clairement un handicap… je préfère auteure, à la rigueure.
[^] # Re: SVN
Posté par freem . En réponse au journal Adieu vieille branche. Évalué à 6.
Je trouve ça logique, moi, la branlette, c'est pas bon pour la santé qu'ils disaient, les anciens :)
Puis justement, peut-être que ça aurait moins râlé de repasser à «trunk» qui a, justement, un histoire dans l'informatique, continue l'analogie, etc etc, contrairement à «main» qui ne veut rien dire. (surtout dans le cas d'un VCS distribué?)
[^] # Re: Est-ce un problème?
Posté par freem . En réponse au journal Adieu vieille branche. Évalué à 2.
Bon, qui c'est qui se dévoue pour envoyer un patch qui permets d'établir une "branche par défaut" repérable logiciellement dans git, du coup?
Non parce que cette notion, elle existe pas vraiment… En fait, «master» ou «main» c'est juste la 1ère branche, que l'on utilise par facilité comme référence… c'est tout. Une simple convention, rien de technique ici.
[^] # Re: Est-ce un problème?
Posté par freem . En réponse au journal Adieu vieille branche. Évalué à 5. Dernière modification le 17 mars 2021 à 10:18.
Mince alors, moi qui avais cru lire "Petr Baudis dit quand même que c’est un mauvais terme et qu’il a été choisi principalement à cause de son manque de maîtrise de l’anglais à l’époque."… ou alors ce "Petr Bandis" serait un citoyen des USA qui ne parle pas anglais?
Possible, mais vu que j'imagine que cet individu est celui auquel réfère "Founder Interview with Chief AI Architect Petr Baudiš | Rossum" j'en doute fort, ou alors on m'a menti et les anglais connaissent les accents?
En fait le problème avec ce renommage, c'est qu'il se base sur des problèmes intrinsèquement locaux aux USA mais touche tout le monde.
Peut-être que ce problème de racisme et d'esclavagisme noir est encore réel et présent aux USA, mais personnellement, si un jour je tombe sur un projet qui arbore un Svastika (hé oui, c'est moi qui l'ait atteint! Enfin, pas encore rattrapé mon retard, peut-être que quelqu'un l'a eu avant…) je n'irai pas leur demander de le changer sous prétexte que ma région du monde a un très, très mauvais souvenir de ce symbole.
Restent les questions suivantes par contre: à partir de combien d'utilisateurs gênés doit-on changer des choses? Et une fois ce seuil établi, pourrait-on avoir les études qui estiment le nombre d'utilisateurs gênés par le terme master anciennement utilisé par git, par défaut?
À noter quand même, qu'au final, ce changement n'a aucun impact sur ceux qui utilisent le site, tout comme pour github: c'est le nom de la branche par défaut…
Je sais pas pour vous, mais moi, je commence par coder dans un dépôt local, puis éventuellement je crée un repo accessible aux autres, puis j'y pousse mes modifications.
De ce fait, le changement de nom de la branche principale, ben, je le verrais juste passer quand Debian intégrera la version de git qui le change. Mon code n'est pas organisé par des trucs comme github ou gitlab: ces machins ne sont que de stupides outils, que j'évite d'ailleurs au maximum tant je trouve coûteux en temps le fait d'utiliser ces «forges», qui sont en réalité bien plus proches de «places du marché» tellement on y cause et on y crie plus qu'autre chose.
[^] # Re: Puisqu'on parle de gemini
Posté par freem . En réponse au journal HtmGem v1.0.0, un client Gemini en Php. Évalué à 3.
À ce sujet, j'ai récemment été "râler" sur IRC que kristall ne permettait pas de faire de saisie sur gopher://gopher.floodgap.com:70/7/v2/vs et ça a été corrigé rapidement. Ce qui en fait le 3ème bug que je rapporte qui est corrigé en moins de deux semaines, je crois.
L'idée d'intégrer les certificats clients pour des forums pourrais probablement faire son chemin aussi, reste à construire et défendre l'idée suffisamment pour qu'elle séduise les devs, et éventuellement à l'implémenter soi-même s'ils ne sont assez convaincu que par l'idée, mais ont la flemme de l'implémenter (ils ne sont pas payés, après tout).
[^] # Re: Puisqu'on parle de gemini
Posté par freem . En réponse au journal HtmGem v1.0.0, un client Gemini en Php. Évalué à 2.
Effectivement. Enfin, oui et non… il reste possible d'envoyer des données au serveur, techniquement, mais ça reste bien plus primitif.
Par contre, les cookies, perso, ça va pas me manquer. Pour ce qui est du système de certificats, ma foi, un client pourrait très bien trouver un moyen de rendre ça ergonomique. Je ne sais pas comment, il faudrait y réfléchir, évidemment, mais au moins ça sera pas juste un workaround parce que le protocole n'incluais pas la possibilité dès le départ, contrairement au web. Pour lequel il s'agit même d'un workaround sur-exploité.
Exactement, et je pense que c'est la l'intérêt principal: une page gemini, c'est pas de prise de tête pour la présentation, pas de prise de tête pour le certificat TLS, contrairement au web, pour lequel ces deux aspects nécessitent quand même un peu plus que de simples notions.
[^] # Re: tuyauteries en PVC, planché en bois, eau + électricité, câble non ignifugé ...
Posté par freem . En réponse au lien OVH et la protection incendie. Évalué à 2. Dernière modification le 11 mars 2021 à 10:51.
Et du coup, c'est une photo "en fonctionnement" la, ou bien en cours de travaux?
Qu'est-ce qui pourrait empêcher d'appliquer un backup à une autre machine?
[^] # Re: En conclusion
Posté par freem . En réponse au journal AlienBob et les dédales de Chromium sous Slackware. Évalué à 3.
Perso, je me suis fait mordre une fois par opera, même si certes, je ne payais pas la synchro, mais depuis, c'est niet les trucs de synchro. À la rigueur, si j'en avais le contrôle, pourquoi pas, mais je préfère ne rien avoir plutôt qu'avoir un truc qui risque d'être viré aléatoirement sans que l'on ne puisse discuter la décision (de mémoire, j'avais reçu un mail comme quoi j'étais banni alors que je n'avais fait qu'essayer d'utiliser une des fonctionnalité, sans y arriver?).
Comme on dit, mieux vaut être seul que mal accompagné.
Et ça, ça vaut clairement autant pour la MoFo, la MoCorp, vivaldi (la boîte derrière) ou Alphabet.
Si un navigateur proposait, nativement un service de synchro qui soit configurable sans aller modifier à la main le about:config (que je considère l'équivalent de regedit, en moins bien foutu), j'y réfléchirais.
Je viens de regarder, ce n'est pas le cas de firefox: dans les préférences, il ne semble pas y avoir moyen de renseigner une URI de référence pour «sync».
Ben vois-tu, déjà je pense que tous les utilisateurs de vivaldi ou opera râleraient sévère. Ceux qui utilisent chromium sur Debian feraient la gueule, et je n'ai aucun doute que ça finirait à ce que Debian maintienne chromium. Probablement avec l'aide des devs de vivaldi et opera, ainsi que d'autres ici et la (otter browser, peut-être? Tiens, ça fait longtemps que j'ai vérifié ce qu'il vaut…).
Ça n'est certes pas au niveau des devs de Firefox, donc le résultat serait certainement à la ramasse comparé à Chrome, mais je pense que pas mal d'utilisateurs de ces solutions préféreraient largement ça. De ce que j'ai lu, il semble (basé sur le très sérieux indicateur pifométrique(tm), édité par la société très professionnelle MyFeelingCorp) que les utilisateurs de vivaldi me ressemblent sur un point: il préféraient utiliser un opera 12 non maintenu, plutôt que firefox ou chromium ou opera-blink, après tout.
[^] # Re: Une grande inconnue
Posté par freem . En réponse au journal Slackware 15 en approche ?. Évalué à 2.
Oui, clairement. Et je soupçonne cette limite d'avoir une raison d'être de type (oui, je sais, c'est vieux, mais c'est un des docs avec lesquels j'ai appris à coder début 2000 :) et en français s'il vous plaît!) "on copie la ROM BIOS dans la RAM pour l'exécuter, sans nettoyer derrière, voire en réutilisant" des très, très vieilles applications, qui du coup ont un intérêt à mapper cette plage mémoire.
Cela dis, je n'ai aucune certitude (j'avais lu pas mal de trucs sur le boot à l'époque, comprendre les séquences initiales m'a toujours botté…) ça date trop.
[^] # Re: En conclusion
Posté par freem . En réponse au journal AlienBob et les dédales de Chromium sous Slackware. Évalué à 5.
Très probablement.
En l'occurrence, on parle de synchroniser les bases de données sous-jacentes, n'étant pas utilisateur, je ne sais pas si la connection se fait en permanence ou ponctuellement, mais même le cas du "en permanence", en pratique, tu ouvres une connection TCP/TLS, dès qu'un passe ou un truc est ajouté/supprimé, tu balances ton message au serveur, qui redonde sur les autres clients connectés.
Quand un client s'ouvre, il récupère son retard, quand un client se ferme, il vérifie (par acquis de conscience) que tout est OK.
Rien de bien sorcier à priori.
De l'autre côté, tu as l'UI. La, je me risquerais déjà pas à implémenter la gestion des onglets, des boîtes de dialogues et tout le toutim sans une bibliothèque (c'est ce qu'ils font d'ailleurs, gtk me semble?). Bon, on peut déléguer à une lib, mais il reste à faire une UI qui plaise et qui soit portable et qui s'intègre pas trop mal dans les OS supportés. Très, très difficile ça.
Et le pire, c'est le rendu des pages elles-mêmes. Tu dois interpréter/compiler 3 langages, dont l'un est "turing-complete". La complexité par rapport aux 2 autres éléments est nettement supérieure, sans même y ajouter de gestion des plugins et des hooks.
[^] # Re: Nginx
Posté par freem . En réponse au journal Recherche d'un reverse proxy. Évalué à 3. Dernière modification le 06 mars 2021 à 12:27.
Perso, sur mon serveur, j'ai dans /etc/runit/2 (entres autres):
Puis dans le sv/httpd/run:
Et: sv/httpsd/run:
Bref, je vois pas en quoi c'est un problème, de pas être root. Bon, ce serveur est un jouet mal géré, faut que je nettoie, mais quand même, pas grand chose n'a ma confiance pour être lancé avec les droits root dessus.
Je sais, les processus peuvent drop les droits, en théorie. Sauf que bon, même si j'essaie d'aller lire le code un minimum, je trouve tellement plus simple qu'il n'aient pas à le faire eux-mêmes, ça m'évite d'aller lire le code en détails.
Non, ça ne répond pas à la question du forumW journal, certes, mais bon, ça répon au "besoin d'être root" par l'exemple.
[^] # Re: Fedora
Posté par freem . En réponse au journal Les méfaits d'Ubuntu. Évalué à 5.
Utiliser
sudo -ifait le job aussi, non?