greendev a écrit 80 commentaires

On fait tous globalement la même chose aux toilettes, tu laisse donc la porte ouverte puisque tu n'a rien à cacher ?

Si vous considérez Internet comme vos chiottes, pas étonnant que Linuxfr soit un bon gros tas d’étrons.

Désactivez JS, vous auriez gagné du temps.

Le contenu est inaccessible ? Bon ben au-revoir. (le plus rigolo c’est que ce sont souvent les sites ayant le pire ratio signal sur bruit qui font le coup…)

https://zet-ethique.fr/2022/05/20/les-sciences-raciales-ne-sont-pas-quun-vestige-du-passe/

https://zet-ethique.fr/2022/11/04/qui-voudra-revolutionner-le-genre-aux-rencontres-de-lesprit-critique/

https://www.livredepoche.com/livre/quest-ce-que-la-science-9782253055068
https://www.kobo.com/fr/fr/ebook/la-philosophie-des-sciences-3
https://www.kobo.com/fr/fr/ebook/sociologie-des-sciences-3

cité par l’auteur du texte sur lequel pointe le lien (je vous hais, je vais finir par faire un buffer-overflow avec ma fifo de lecture) :

https://www.kobo.com/fr/fr/ebook/le-metier-de-chercheur-regard-d-un-anthropologue-2e-edition-revue-et-corrigee

Le concept des données probantes porte en effet toutes les caractéristiques du positivisme, ce courant philosophique né au XIXe siècle qui soutient qu’il existerait des vérités, voire des lois qui expliqueraient la totalité de l’expérience humaine. Pour identifier ces lois, il suffirait d’exploiter des outils ou des instruments de mesure suffisamment précis.

En philosophie de la connaissance, une telle posture n’est pas tout à fait nouvelle. Elle est cependant loin de faire consensus dans le domaine scientifique et plus encore, dans celui des sciences humaines et sociales. Plusieurs chercheurs et philosophes sont en fait très critiques de la capacité du positivisme d’expliquer les choses humaines. Ils soulignent notamment que, pour assurer la validité de leurs modèles, les approches découlant du positivisme doivent réduire de façon artificielle le nombre de variables en présence dans une situation.

L’est encore bien gentil le monsieur. Le positivisme logique se fait démonter sa gueule bien comme il faut, Popper a connu le même destin. Et ça vaut pour toutes les sciences, y compris les bien dures qui font bander les vieux mâles blancs issus des domaines de l’ingéniérie.

Oui et quand la forme du message c’est du 42ºC dans ta gueule ça t’arrache tellement qui tu préfères t’enfermer dans le déni.

Ou alors on fait un poil attention à la rétrocompatibilité, à la stabilité des interfaces, on fait en sorte, de l’autre côté de moins donner de crédit au time-to-market (autre formatage purement capitalistique) pour ne pas chercher la lib dans sa dernière version bien trop hypée. Et ainsi on laisse les intégrateurs faire leur boulot sans leur compliquer la tâche.

C’est quand même rigolo de lire votre discussion en 2023 où les store sont devenus la norme.

C’est pas une question de compétences. Z’êtes tous formatés. À commencer par les informaticiens qui ont pris l’habitude de pondre du bloat, parce que le matos arrivait à suivre derrière…

sert de s'assurer de pas avoir une optimisation trop agressive du genre

Tu te rends compte que tu as réussi à écrire un simple compteur d’une manière bien tordu (et bien obfusquée), et que tout ce que fait ton compilo c’est de dénouer le sac de nœud qui te tiens lieu de pensée ?

C’est ce que ton compilo fait (au mieux), de ton propre aveux. Pour trouver ça plus simple à lire que int a(int n) {return n;} t’es payé à la ligne de code, c’est pas possible autrement !

Rhô ça sert à rien de faire l’intelligent, la réalité c’est que vous savez pas coder un algo récursif et que vous vous cachez derrière des choses que vous maîtrisez pas. Pour preuve, j’ai bien signalé que les goto n’était pas obligatoires (dans la très grande majorité des cas je m’en passe), j’ai aussi dit que je présentais le cas le plus général (donc pas une optimisation…).

Mais bon c’pas grave continue comme ça. C’pas grave hein si t’es pas bon en algorithmie, t’as l’droit. Pas besoin de s’inventer une excuse.

leur expérience tendra à être de plus en plus proche peu importe la distribution voire la version de la distribution utilisée

Vivement que GNU/Linux devienne un système aussi privateur et fermé qu’un Windows ou un Mac.

Là il sera prêt pour le Desktop !

…

Avec 0.5% de part de marché.

J'ai des incompatibilités de vision

Sur des problématiques techniques, on répond de manière technique. Il y a des arguments factuels, objectivables et objectivés à soumettre et évaluer. Il reste correct de ce que j’ai vu, et ce malgré le contexte (vu qu’il espérait en vivre de ce que j’ai compris). Il a tout à fait raison.

Et même si ça fait mal à la petite susceptibilité des auteurs qui font de la merde, ce n’est pas être un connard.

Faut savoir mettre son ego de côté et arrêter de se comporter comme des narcissiques à un moment donné (et croire que tout le monde est comme ça…). Lui reprocher d’être un connard c’est vraiment prendre personnellement ce qui est une critique argumentée de Darktable.

une partie des codeurs qui ont du temps ne sont pas professionnels

Il n’a jamais dû coder dans un contexte pro. S’il savait…

Être brillant

Ma main à couper qu’il sait être critique sur son propre travail et, spoiler alert c’est pour cette raison qu’il fournit un très bon travail.

J’ai oublié de signaler. La call stack utilise une pile qui est implémentée dans le CPU, avec des instructions spécifiques si je ne m’abuse. Il y a effectivement possiblement un gain de performance à aller gratter de ce côté là.

MAIS.

Ça ne compense pas, très largement, l’overhead de la call stack (on empile/dépile tout le contexte d’exécution de la fonction en lieu et place des seules données propres à la récursion). Si je présente un algo avec des goto c’est aussi pour mettre en lumière cet aspect : l’instruction pointer par exemple va être empilé à tort lors d’un appel récursif (c’est le principe même d’une call stack).

D’aussi loin que je me souvienne, la qualité des release Darktable a toujours été en dent de scie, occasionnant frustrations et abandons pour ma part. Mais faute d’alternative pour le moment…

Le contributeur en question dit aussi beaucoup de conneries. Pour sûr c’est déjà bien mieux que l’informaticien moyen (où savoir gérer une pile dans un algorithme passe pour un truc d’extraterrestre…). Il me fait l’impression d’un autodidacte.

et des choses qui s'expriment simplement en récursif deviennent un enfer en itératif.

Non. C’est juste que tu n’as pas appris et que tu n’as pas l’habitude. C’est tout mon propos. Problème de formation. Un code récursif n’explicite pas les éléments de ta pile et peut poser quelques inconvénients à l’implémentation (variable locales & arguments sont confondus avec les éléments de ta pile, obligation souvent d’avoir une fonction chapeau pour initier la récursion).

Un algo récursif définit explicitement les éléments de ta pile. En C par exemple j’ai pris pour habitude d’avoir une struct el _stack[SIZE], *stack=_stack;. Mon struct el est explicite donc plus lisible, d’autant plus qu’il va être souvent non spécifique (dans le parcours d’un arbre/graphe par exemple c’est les node du graphe). Empiler et dépiler sont des opérations on ne peut plus simple que stack++ ou stack-- où tu transmet/alimente les valeurs nécessaires (arguments et valeur de retour sur la pile) et contrôle les dépassements avec la possibilité d’allocation dynamique (l’empilage et le dépilage sont implémentées comme des petites macro ou fonction inline).

Tu as aussi une grosse méconnaissance des langages type C. Car c’est exactement ce qu’ils mettent un œuvre, un algo récursif avec comme pile la fameuse “call stack”. Donc rien d’insurmontable.

L’appel à une fonction ce n’est rien d’autre qu’un empilage/rebouclage.
Le retour d’une fonction un dépilage. Sans avoir rien à tordre, ton appel récursif est trivialement transposable en un pseudo-code récursif de la forme —très— universelle suivante :

appel:
  ...

retour:
  ...

decision:
  si appel récursif:
  {
    empiler
    goto appel
  }
  sinon:
  {
    dépiler
    si la pile est vide on a terminé.
    sinon goto retour
  }
...

Note qu’on fait sans les goto en général, mais c’est pour montrer qu’on peut être plus universel encore que l’appel récursif — car là où un retour à l’appelant suit forcément l’appel à une fonction (le pointeur d’instruction est mis sur la pile puis dépilé), le goto/label est bien plus souple (la forme que je présente n’est pas possible avec une fonction récursive — il faut tordre l’algo).

C'est un drame de se dire que le codeur de base fait mieux que le compilo pour optimiser

J’aimerai sincèrement que soit faite la démonstration que le compilo est capable de distinguer très exactement la pile de ton algo de la call stack et de les séparer. S’il y arrive, la call stack ne doit plus être manipulée lors de la récursion et c’est tout l’enjeu. En commençant par bien distinguer les arguments de ta fonction récursive, entre ceux qui participent à la récursivité de ceux qui sont invariants dans la récursion, ensuite en étant capable de faire sauter la limitation en taille de la call stack, idem les variables locales qui n’ont pas forcément à être empilées.

Et pas uniquement dans le cas de la mal nommée “récursion” terminale (qui est toujours trivialement transposable en itératif ceci dit en passant).

Et non c’est pas du tout lisible : si je lis un appel récursif je m’attend à un algo récursif, pas un truc oui-mais-en-fait-non. Il s’agit aussi d’évaluer la complexité et la performance d’un bout de code (itératif : je sais que je suis en O(𝑛), récursion je m’attends à un truc du genre O(𝑛log(𝑛))), et de ne pas se rajouter de la charge mentale (il est beaucoup plus difficile d’appréhender le comportement d’un code buggé qui a une pile, donc j’aime savoir si la pile est vraiment justifiée).

Qui plus est il ne s’agit pas d’optimiser, mais précisément de ne pas créer un code inutilement complexe pour le compilo. En plus de ça, dès que tu vas vouloir faire des algos sur des données un minimum couillues tu vas vouloir contrôler ta taille de pile (donc exit la call stack).

Mais tout mon propos c’est bien justement de dire, faite ce que vous voulez (je sors juste les popcorns à chaque fois que vous venez pleurer, sur linuxfr notamment).

Mais laissez moi faire ce que je veux.

Là il s’agit de croire que vous allez réussir à imposer une nouvelle norme qui n’a pas été réfléchie pour être compatible avec la précédente. Forcément c’est une fin de non-recevoir. D’ailleurs c’est révélateur de prendre l’exemple de ssh : des personnes qui ne réfléchissent pas plus loin que le bout de leur nez et ne l’ont manifestement jamais utilisé sérieusement. La gestion des clefs privées tu n’as vraiment pas envie de confier ça à ta distrib’ et avoir des surprises dessus. Dans un contexte un poil sensible (d’ailleurs vous n’avez toujours pas dit si c’était de la conf ou de la donnée utilisateur).

Personnellement je suis bien content que Linux n'impose pas de compiler son propre noyau, que beaucoup de choses fonctionnent sans même y penser. C'était rigolo 5 minutes de configurer Xorg à la main pour avoir un affichage qui tourne, mais c'est quand même à la longue bien plus sympa d'avoir des systèmes qui gèrent le multi écran dynamiquement sans même qu'on ait à y passer 20 plombes à lire le manuel.

Tu n’imagines même pas à quel point c’est facile et rapide d’administrer un Unix old-school sur une machine perso ou un serveur (c’est même tout l’intérêt de la manœuvre). Et c’est bien plus passionnant pour qui s’intéresse (réellement) à l’informatique. C’est précisément pour ça que je veux éviter la bullshitisation de Linux (qui est en voie avancée… pour rien en plus vu qu’il prendra jamais de parts de marché sur du cro$oft). On est en train d’abandonner les qualités et points forts de Linux pour viser une hypothétique cible d’utilisation inatteignable.

“L’évolution” proposée est typique d’un truc totalement moulin à vent, qui ajoute de la complexité, casse la rétro-, oblige à des tâches de maintenance (et donc du temps passé) sans valeur ajoutée.

Oh! et je met régulièrement à jour mon noyau avec recompilation. Ça me prend 30s. J’ai du multi-écran. Rien ne m’empêche d’avoir udev, xorg automatisé (qui ont une vraie plus-value). Vraiment.

Dans ce cas précis, l’argumentaire est archivé ici

D’autant plus rigolo que dans le cas du .ssh. Tu n’as VRAIMENT PAS envie de traiter ce répertoire comme les autres (je n’en dis pas plus, je m’attends à qu’ils tombent les pieds joints dans le piège…).

Et des répertoires idiots Documents/Downloads/Music/Pictures/Public/Templates/Videos c'est pas de la connerie inspirée de windows ça?

Très pénible d’ailleurs. Firefox a un bug là-dessus (création aléatoire du Downloads). Mais ce n’est lié à XDG que je sache. Par contre, comme les fichiers sous .config ne sont pas masqués, ça empêche un bon vieux et très salutaire

export $XDG_CONFIG_HOME=$HOME

\o/

Ce que tu dis ne pas être le sujet est précisément le sujet du lien.

Et c’est précisément le problème. Qu’une lubie aussi puérile et narcissique puisse être prise au sérieux. On répond gentiment au début, mais à la fin face à un pénible on l’envoie balader (on est vendredi hein, mais ne crois pas que j’ai pu prendre au sérieux ta thèse, ni même l’auteur du lien, qui a selon toute vraisemblance posté ça pour le troll).

Enfin, non, c’est pas aussi simple que « Un répertoire = une appli », ça fait partie du problème. Il y a même un exemple dans le morceau de code que tu cites…

Et ? Encore une fois en quoi XDG va arranger les choses ? Tu peux me mettre tous les défauts du monde du système actuel (réels ou fantasmés). Faut montrer en quoi le nouveau système règle le pb posé. Si tu juges que c’est un gros foutoir dans .* t’auras le même foutoir dans .config/*

Le cache non-persisant c’est dans /tmp. Il n’a rien à faire dans $HOME. Il manque dans l’Unix old-school un tmp privatif. Perso je créé un /run/user/$USER, pointé par $TMPDIR. Je conserve ainsi une excellente compat’ ascendante tout en prenant en compte les contraintes modernes, comme quoi….

~ ls
data/  doc/  photo/  prog/  pub/  redac/  taf/  zik/

C’est juste de la sodomie de coléoptère de débattre de savoir si on doit faire ~ ls -d .* ou ~ ls .config. C’est pas le sujet hein…¹

Par contre, le jour où j’ai voulu faire du ménage là-dedans, ça a été la grosse galère, notamment à cause de tous les logiciels qui collent des caches gigantesques n’importe où, et de ceux qui ne font pas le ménage à la montée de version (exemple que je découvre à l’instant : .sonarlint qui est devenu .sonar).

Et ? Un répertoire = une appli. Backup et ménage facile. Avec XDG on multiplie les répertoires ; non seulement il ne règle en rien les problèmes que tu évoques, mais il les empire!

¹ Et c’est précisément ce que je reproche à l’auteur : vouloir mettre le merdier pour un objectif extrêmement futile…

Ce sont des choses que les logiciels et distributions font en permanence, c'est d'ailleurs une partie de leur boulot.

Non. C’est le boulot de l’administrateur. Le taf des distributions c’est de… distribuer (et faire un peu d’intégration). On a complexifié la pile logicielle à un tel point que les distributions se sont mises à faire de l’administration, et que les dév. se sont mis à faire de la distribution (un gestionnaire de paquet dans un langage informatique — cargo ou autres — mais wtf quoi).

C’est pas que le proprio-le-méchant-qui-veut-controler-la-machine-utilisateur. Le libre prend exactement la même voie : avec un système Linux “moderne” vous avez de moins en moins la main sur votre machine. Vous déléguez.

Perso je m’en cogne, c’est la raison pour laquelle je reste sur un old-school Unix avec une distrib’ qui m’y autorise. Mais que chacun reste à sa place (XDG me fait déjà bien assez chier comme ça, comme dit dans un autre commentaire il y a eu des choix très discutables…).

Si tu veux repartir de 0 en terme de configuration sans perdre de données personnelles, cela devient trivial comme opération aussi.

Non mais lol. Mon $HOME est très propre. Mes données sont dans leurs répertoires dédiés qui au demeurant, sont fonction, entre autres de ma politique de sauvegarde (très variée, j’ai du raid, du rsync, du non backup). Donc non, c’est pas un argument, vu que j’arrive à le faire très bien en mode Unix old-school.

Après si vous foutez tout un tas de fichiers à plat dans votre $HOME, c’est vous les gorets, pas Unix.

C’est un drame les appels récursifs : on présente ça aux étudiants dans le cadre de la formation. Soit. Mais ça devrait être banni d’un contexte professionnel ; pour un ingé qui a un peu de bouteille, c’est le minimum syndical de savoir coder un algo récursif avec sa propre pile (et pas celle du langage, car rien ne le justifie — quand il est impératif).

Les machines changent, pas le code. Présentement je travaille à transformer une pile logicielle qui a été mise en place il y a plus de 20 ans. Je côtoie du code qui peut en avoir plus (on sait même pas, vu qu’on n’a pas la vision de l’historique au-delà de 1999). 10 ans, c’est grosso modo la durée de rétention juridique qu’on doit observer pour toute notre activité informatique. Et c’est aussi l’âge minimum de l’écrasante majorité du code sur lequel je travaille. L’autre jour on m’a appelé pour une évolution sur un logiciel que j’ais écrit il y a 5 ans et qui n’a jamais reçu de maintenance corrective depuis (`fier).

Toutes les dates que tu avancent sont antérieures à XDG. CQFD.

La plupart des gens ont franchement autrement chose à foutre que de se prendre la tête avec des maintenances à la con, non justifiées, impactantes, inintéressantes, sans valeur ajoutée, du style pointé par ce lien. Si pisser du kleenex à longueur de journée vous passionne, rester sur des applis à la con, mais n’allez pas croire que ça concerne le monde entier (en particulier le monde pro).

L’informatique est en passe de devenir un pur bullshit job, et vous sautez les pieds joints dans la merde.

On est bien d’accord :-° c’est XDG qui est venu mettre le merdier (Unix 1969, Free Desktop Group : 2000). Unix ce n’est rien d’autre qu’une norme de fait (plus ou moins heureuse).

ruptures de compatibilité pour d'autres raisons

Il voulait casser ssh quand même. Pas le truc sensible du tout. Je te laisse imaginer son délire…

sous Windows [à cause des jeux]

Connais pas. Moi je parle d’outils de travail, pas de jouets.

Plus sérieusement, l’informatique date des années 50. Il y a des gens qui font du code de gestion et industriel qui doit durer. Ceux qui pissent du code kleenex¹ feraient mieux d’arrêter de péter plus haut que leur cul et croire que leurs idées sont autre chose qu’une réinvention de la roue en plus mauvais.

Il n’explique nul part pourquoi le fonctionnement actuel lui pose un réel vrai problème en pratique — on dirait plutôt un mec qui veut faire chier son monde “pour la beauté du geste”.

--

¹ on les reconnaît à ce genre de préjugés : « 10 ans c’est une éternité en informatique ».

Parce que nier la rétro-compatibilité pour psychologiser (“ils ont peur”, ils sont “ignorants”, des “arrogants” et j’en passe). C’est d’une crétinerie crasse. Et c’est l’auteur qui parle de complexe de supériorité…