barmic 🦦 a écrit 6259 commentaires

ne risques pas de les perdre

Tu fais des sauvegardes parce que tu risque de les perdre.

Des outils super il en existe pleins. Le problème est pas leur existence à mon avis mais est-ce qu'il cherchent à créer un workflow parfait, rationnel, voir scientifique ou s'intéresser à l'usage actuel et comment y répondre.

Dire à quelqu'un qui a un usage complètement désordonné qu'il va se tenir à un workflow structuré, installer, synchroniser sur tous ces devices un outil de plus, etc ne me paraît pas pertinent

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

Comme je l'ai dit ce n'est pas une façon de lister tous les avantages de la pratique mais de montrer en quoi l'usage est différent.

Rester arcbouté sur les onglets dont l'usage n'a pas changé depuis 25-30 ans sans se poser pour voir pourquoi c'est peu utilisé par rapport au maintien d'onglets ne résoudra pas le problème. Ce n'est pas l'injonction qui va faire évoluer les usages.

Le concept de place, si je me souviens bien, introduit par Firefox a été une tentative de créer quelque chose par rapport à ça : maintenant le navigateur sauvegarde tout et même si tu as fermé un onglet, tu sais que tu pourras le retrouver même longtemps plus tard.

À mon avis il y a moyen de faire quelque chose pour améliorer les choses. Aller je me lance dans de la feature fiction 😇

Le navigateur te propose de faire un nettoyage. Tu passe dans un mode de vu où tu vois tous tes onglets comme l'ancienne vue des groupes d'onglets. Dans cette vue, tu pourrais voir les onglets sans accès ou interaction depuis très longtemps, les doublons, ceux qui sont déjà en marque page, tu pourrais les grouper par site, par liens (le genre d'arborescence tree style tab), tu pourrais voir ceux qui sont consommateurs, pour ceux que ça intéresse il pourrait même y avoir une catégorisation IA,… Bref une vue dédiée qui permet de regrouper un tas d'informations déjà existantes et quelques nouvelles avec des actions possibles: fermer, sauvegarder en marque pages, déplacer dans des groupes, envoyer dans un pocket like, décharger,… Et même pouvoir pluguer des extensions (par exemple pour envoyer tout à notebookml ou demander à un llm quelconque de faire un compte rendu).

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

Bref ma question sur les avantages/inconvénients d'avoir deux fonctionnalités distinctes mais utilisées de la même façon en pratique.

S’il y a bien une chose d’évidente c’est qu’en pratique ça n’est pas du tout la même façon de s’utiliser.

• c’est visuel
• tu garde le contexte de la page (par exemple si tu était entrain d’écrire dans un input texte)
• ouvrir ou fermer un onglet et bien plus rapide que de créer ou supprimer un marque page (créer un onglet ouvre une popup et pour supprimer un marque page il faut aller le chercher)
• les onglet ont ce côté « je garde sous les yeux » là où des marques pages sont cachés

Je ne dit pas que c’est une bonne idée ni que ce qui est une impression se révèle utile à terme, mais c’est une évidence pourquoi c’est théoriquement la même fonctionnalité, mais en pratique non.

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

S'y retrouver dans 10 onglets c'est tout de même pas particulièrement compliqué.

Le fait de réduire son nombre d'onglets est une action à faire donc oui c'est facile de voir des utilisateurs avec beaucoup d'onglets.

Par exemple j'ai genre 4 ou 5 onglets "dashboard" qui sont ouvert en permanence (2 webmail, mon outil de flux rss, la board de mon équipe,…). Ajoute 1 ou 2 onglets pour ce que tu es entrain de regarder (la page lien ici et la page pour rédiger une réponse). Tu fais une réponse un peu construite ? Tu as un moteur de recherche et 2 onglets de réponse ouvert.

Réduire ce genre de workflow demande à jongler non plus visuellement mais avec une charge cognitive en plus à ta charge (par exemple en passant du temps à faire des aller retours sur l'historique ou en devant ouvrir régulièrement les tâches pour voir s'il y a eu des changements).

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

Rancunier

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

Non ça n’a rien à voir. Cette philosophie n’est pas là pour faire des logiciels opiniated au point de laisser des bugs trainer ainsi parce qu’ils ne toucheraient que des utilisateurs qui font des choses jugées pas intéressantes.

C’est une approche d’achitecture qui consiste à privilégier le découpage à l’ajout builtin de fonctionnalité. Ici il pourrait s’agir de déléguer cette partie à un autre logiciel qui, pour respecter le reste des principes unix, devrait avoir une API texte via stdin/stdout.

Mais c’est vraiment une règle qui n’a jamais était respectée à la lettre. Le nombre d’outils de base qui sont turing complete, la quantité de fonctionnalités qui sont implémentées plusieurs fois,… Rien que par exemple pourquoi tous ces outils ont implémenté la manipulation de fichiers ? Ils auraient pu laisser ça au shell qui est fait pour et qui le fait bien. Elle est extrêmement subjective (elle dépend beaucoup de l’échelle à la quelle tu te place) et n’est pas une règle incassable. Par exemple l’option -u de sort est faite parce que filtrer avant le pipe peut économiser pas mal de ressources.

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

Du coup ton point c’est qu’un tableur ne devrait pas gérer de dates ou que’Excel gère bien les dates ?

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

Merci pour le lien

Without proper tests or documentation, developers are often hesitant to touch old code. The risk of breaking something far outweighs the reward of fixing a non-critical bug.

J’ai ce problème actuellement avec une de mes PR qui n’est pas mergée parce que le code qu’elle corrige parait trop complexe.

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

donc non dans certains cas d'applications "faire confiance à la lib. écrite par des experts" n'est pas la bonne stratégie.

Ça l’est sauf quand gérer le temps fait parti de ton travail. Par exemple parce que tu as des besoin de précision important, mais ça peut aussi être parce que tu fais des opérations non triviales (multi calendrier par exemple) mais dans ces cas là tu es sensé savoir ce que tu fais. Gérer les dates antérieures à 1900 ne me semble pas en faire parti. Pour les dizaines de milliards d’utilisateurs d’Excel qui activent toutes les optin qu’ils trouvent et font des arrêt cardiaque quand ils voient un message, assumer que savent ce qu’ils savent ce qu’ils font au sujet des dates me semble pas une bonne idée.

Il y a plusieurs solutions possibles pour résoudre le problème³ mais rien n'a été fait.

POSIX a un certains nombre de problèmes dont des plus graves que ça et oui c’est un problème, mais justement ceux qui doivent sortir des logiciels (et pas juste des PDF) ne s’interdisent pas de traiter ces problèmes sous prétexte que ça prend pas 5 minutes et que oulala… c’est compliqué.

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

C’est quoi l’unique chose que le bourn shell fais ? C’est quoi l’unique chose que fait awk ? L’outil pour dédupliquer c’est unique, pourquoi sort a l’option -u ?

Cette phrase est souvent très mal utilisée. L’idée c’est de ne pas ajouter des features trop orthogonales pour ne pas avoir bloat le logiciel, mais ici l’outil a déjà une gestion de date.

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

Cela fera un certain nombre de gens qui choisiront la mauvaise option quand tu as un optin, etc…

Pardon mais c’est pas crédible. Si tu trouve que garder des bugs c’est la meilleure chose à faire et que si t’arrive avec un peu de mauvaise fois à trouver des problèmes à mes quelques idées griffonnées c’est bien qu’il est impossible de faire mieux. Ça ne me dérange pas de passer pour un extra terrestre à tes yeux.

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

Mettre un warnings c’est le danger absolu ? Maintenant une bonne part de leurs utilisateurs sont en version web, tu va me dire qu’ils ne font pas de feature flip et canary release ? Un optin ça casse quoi à qui ?

C’est une API et oui ça se gère on l’a tous fait. Ça doit être fait avec sérieux, mais ça se fait très bien faut arrêter de sortir des arguments d’autorité.

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

Donc ne créons des outils que pour un seul usage et surtout ne corrigeons pas les bugs si l’usage ne semble pas digne d’intérêt. Ce serait dommage que des utilisateurs s’imagine qu’on fasse les logiciels pour eux.

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

Je suis pas sûre de savoir le problème (la seconde intercalaire ? la limite de taille de t_time ? la précision à la seconde ?), mais mon problème n’est pas qu’ils aient fait une erreur mais qu’ils ne fassent rien pour l’adresser. Je ne connais aucun OS de type unix qui ne gère pas correctement tous ces problèmes.

Sur ce genre de sujet, qui passe à tort pour trivial, les informaticiens ont tendance à surestimer leur compréhension.

Et c’est justement une bonne raison pour ne pas laisser des bugs trainer dans les outils.

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

(Tiré d’un commentaire plus bas). lol, c’est un peu l’hôpital qui se fout de la charité, la quand même. Toi non plus, t’as pas d’arguments, à part l’anecdote de tes parents.

Les 2 seules choses que je dis c’est :

1. c’est un bug
2. il est parfaitement possible de l’adresser sans rien casser pour les utilisateurs j’ai déjà plusieurs fois cité des exemple de façon

Si pour vous garder des bugs qui empêche des usages légitimes de logiciel c’est OK ne soyez pas surpris qu’on dise que vous ne faites pas un travail de qualité.

Par contre, ce qui me parait clair, c’est que 40 ans plus tard, ça devient extrêmement difficile de corriger le problème.

En y réfléchissant 10 minutes je trouve plusieurs façons de l’adresser. Je n’ai aucun doute sur le fait qu’ils sont bien plus compétents que moi et que ce n’est qu’une question de volonté. Tu parler de la littérature au sujet de ce bug (qui doit être assez creuse vu qu’à part dire qu’il existe il n’a pas de solution de contournement), on a 1000 fois plus de contenu sur la conduite du changement.

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

Ils peuvent créer de nouvelles fonctions correctes, ils peuvent mettre un warning si une date peut être poser problème, ils peuvent gérer des calendriers pour pouvoir choisir lotus/grégorien/chinois,…

S'ils voulaient s'en occuper, ils le feraient

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

Voir aussi https://fr.m.wikipedia.org/wiki/Atomicit%C3%A9_(informatique)

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

La qualité ce n'est pas résoudre des bugs qui n'affectent quasiment personne au détriment des choses ci dessus.

Ça c'est une hypothèse avancée sans argument. C'est mes parents généalogistes amateurs qui m'ont décrit le problème. C'est quelque chose de connu dans ces communautés. Je présume que c'est aussi un fait qu'on apprend si on fait des études d'histoire.

Le mode de distribution d'excel et sa popularité rend cette hypothèse très délicate. Il y a potentiellement un biais du survivant.

qui donne des résultats corrects

Ce n'est pas le cas du coup.

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

Je ne comprends pas ce que tu veut. Je dis que trainer cette dette technique montre selon moi qu’ils ne sont pas piloté par la qualité de leur produit. Tu me dit que oui mais bon c’est pas la priorité.

Tu ne fais que me répéter des choses que je sais déjà et qui sont la raison de mon avis.

En 40 ans ils ont trouvé le temps de faire un paquet de choses, mais rien pour gérer cela (même pas en optin, même pas une détection du problème pour avertir, même pas une gestion de calendrier pour pouvoir dire qu’ils gèrent par la même occasion le calendrier chinois,…).

Une équipe qui a des moyens considérables sur plusieurs décénies et qui laisse trainer ce genre de bug montre un intérêt limité pour la qualité de ce qu’ils livrent.

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

Faire un changement amène toujours un risque de régression.

Comme tout changement pourtant ils arrivent encore à travailler.

Une dette technique ne s'efface pas avec le temps, elle s'alourdit. Si vraiment ils trouvent que c'est trop dangereux aujourd'hui, ils ne la corrigerons jamais. Ce n'est pas la complexité intrinsèque le problème, c'est l'envie de le faire.

Encore une fois ils avaient l'occasion de corriger facilement avec ooxml ils ne l'ont pas fait.

C'est bien ce que je leur reproche. Ils se foutent de la qualité de leur produit tant que ça se vend. C'est une logique assez répendue, mais ce n'est pas pour ça que je trouve que c'est une bonne choses.

Ce qui les empêche de le faire ce n'est pas de la compatibilité ou les risques pour les utilisateurs, ça c'est leur travail et ils gèrent ça quotidiennement, c'est la volonté de s'en occuper.

Ce n'est pas MS qui la mort dans l'âme s'empêche de corriger des bugs pour protéger ses utilisateurs de problème de compatibilité, mais MS qui en a rien à faire d'un bug si tu montre pas que ça fait fuir suffisamment d'utilisateurs

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

A oui c’est les ressources limitées de Microsoft avec les moyens très réduits donné à l’unique développeur, les utilisateurs se sentaient en danger sans Clippy.

Ou alors c’est un bug qui leur en touche une sans faire bouger l’autre à tel point qu’ils se sont même pas posé la question au moment de faire ooxml.

Si on te mettait comme project manager de Excel demain et que tu avais devant toi la liste de toutes les choses à faire, ce serait loin d'être la priorité.

C’est bien ce que je dis. Si tu ne montre pas ce que ça peut apporter comme abonnement rien à faire de nettoyer sa dette technique.

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

Le problème de cette approche c’est quelle rend l’outil que t’es entrain de créé limité par design. Ce n’est pas parce que tu n’imagine pas quelque chose que ça n’existe pas.

Pourquoi est-ce que ce serait une mauvaise idée de travailler les données du début du siècle dernier à part le fait que MS est trop bon en rétrocompatibité pour payer ces dettes techniques ?

C’est juste bête. Ça ne va pas leur faire perdre de l’argent. C’est juste la différence entre un travail fait pour être bon et un travail à minima où non seulement on bâcle la conception, mais on refuse de le corriger parce que ça coûte trop chère de corriger le travail fait à la rache.

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

si tu gères une grappe de serveurs pour une base données ou un Kubernetes ou tout autre cas où il faut x machines actives pour que ça marche, alors tu ne peux pas redémarrer des services ou une machine entière quand tu veux sans aucun ordonnancement ou sans procédure particulière (genre cordon/uncordon, attente de fin des connexions en cours, etc.).

C’est ce qui se fait de plus en plus. Ça a l’énorme intérêt de te faire te rendre compte de ce qu’il se passera quand la machine disparaîtra pour des raisons que tu ne connaît pas.

La gestion très fine des connexions pour ne jamais casser de connexion c’est rare et compliqué, vraiment compliqué. Même des logiciels fait pour comme haproxy ont vraiment du mal avec ça.

Et puis bon quand tu redémarres le service docker/lxc/…, ça a un effet sur tout ce qui est porté par docker/lxc/…

Pour lxc je sais pas pour docker non. Tout comme tu peut redémarrer systemd sans redémarrer tes services.

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

Mais là on est loin de la critique de NixOS.

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

Merci, ça fait toujours plaisir.

Arrête ton char c’est toi qui a commencé le thread avec condescendance et qui continue par exemple juste un peu plus haut à tenter de faire autorité, moi j’ai 20 ans d’XP, comme si ce n’était pas le cas de tes interlocuteurs.

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