Et le CI s'appuie sur les hooks¹. Pourquoi ne pas les utiliser ? Pourquoi ne pas se créer un système de tickets par fichiers directement dans le dépôt git du projet ? Pourquoi ne pas accepter des patchs² simplement envoyés par mail ? Bref pourquoi s'emprisonner volontairement avec un outil ou un service d'hébergement qui ne garantit pas l'indépendance et l'autonomie ? Du plus les forges forcent souvent le partage de l'historique du développement, or la décentralisation de git est bien plus poussée : chaque contributeur gère son historique comme il l'entend et n'est pas tenu de le partager : cela peut être critique en terme de performances sur de très gros projets. Les forges sont plus le fait de la programmation en entreprise où le travail est uniformisé, normé et segmenté. Le libre perd son âme à trop vouloir singer le monde professionnel, qui est aussi très souvent la réduction au plus petit commun dénominateur : un code et des outils de piètre qualité qui ont pour seul mérite une prise en main rapide, pour ne pas subir le turnover, et pour s'assurer qu'un collègue pas très compétent sera capable de comprendre et maintenir les sources.
Que le chasseur soit bon ou mauvais, un cycliste ou un sanglier sera abattu (à moins que ce ne soit le contraire). Mais à la fin le résultat est le même : un être vivant est assassiné.
Je ne m'embarrasse pas de subtilités (je laisse ça aux esprits fins et intelligents qui ont su si bien combattre Trump).
Plus rapidement : la mesure du temps est maintenant calée sur des horloges atomiques car c'est ce qu'il y a de plus précis (c'est le TAI¹). Mais dans la vie de tous les jours on veut quelque chose qui soit plus ou moins calé sur la rotation de la terre et sa révolution autour du soleil (c'est UT1 et notre calendrier de manière plus générale), parce que c'est quand même plus pratique…
Le temps UTC est une mesure bâtarde entre les deux : il est calé sur UT1 tout en garantissant l'absolue régularité de la seconde du TAI (on a le meilleur des deux mondes). Pour arriver à ce résultat il faut de temps à autre rajouter une 61ème seconde (on a donc h:m:60 tout à fait légal, 2 fois par an), la seconde intercalaire.²
Le problème Posix est qu'il se cale sur UTC, mais ne représente pas l'heure sous la forme h:m:s, mais d'un unique nombre (donc impossible de rajouter cette fameuse seconde intercalaire). Il y a plusieurs solutions possibles pour résoudre le problème³ mais rien n'a été fait.
--
¹ La conservation de l'énergie (l'une des plus importantes loi de la physique) est directement déductible de l'invariance par translation du temps. En ce sens le TAI est le seul temps physique qui vaille.
² À noter que le cycle solaire connaît des variations plus importantes (±15 min. de souvenir) mais ces variations sont elle-mêmes cycliques (elles s'annulent au bout d'un an), et seule la dérive sur le temps long est prise en compte. UT1 est un temps lissé, ne subsiste que la dérive sur le temps long.
³ http://www.madore.org/~david/computers/unix-leap-seconds.html, donc non dans certains cas d'applications "faire confiance à la lib. écrite par des experts" n'est pas la bonne stratégie. Dans le même genre je ne compte plus la multiplication de l'usage des flottants en lieu et place des décimaux pour représenter des éléments de comptabilité…
[^] # Re: Ça donne envie de le rallumer
Posté par Computer (site web personnel) . En réponse au journal De la nostalgie du 486. Évalué à 1.
Merci pour ce journal et ces commentaires très instructifs… sans le vouloir.
C’était le salaire de mon père ; je n’ai appris l’existence de l’informatique qu’au mitan des nineties.
Ils appellent ça la méritocratie qu’ils disent.
[^] # Re: Besoin d'interopérabilité
Posté par Computer (site web personnel) . En réponse au journal Forge publique et privée : centralisation ou décentralisation ?. Évalué à -1. Dernière modification le 06 mai 2025 à 15:20.
Et le CI s'appuie sur les hooks¹. Pourquoi ne pas les utiliser ? Pourquoi ne pas se créer un système de tickets par fichiers directement dans le dépôt git du projet ? Pourquoi ne pas accepter des patchs² simplement envoyés par mail ? Bref pourquoi s'emprisonner volontairement avec un outil ou un service d'hébergement qui ne garantit pas l'indépendance et l'autonomie ? Du plus les forges forcent souvent le partage de l'historique du développement, or la décentralisation de git est bien plus poussée : chaque contributeur gère son historique comme il l'entend et n'est pas tenu de le partager : cela peut être critique en terme de performances sur de très gros projets. Les forges sont plus le fait de la programmation en entreprise où le travail est uniformisé, normé et segmenté. Le libre perd son âme à trop vouloir singer le monde professionnel, qui est aussi très souvent la réduction au plus petit commun dénominateur : un code et des outils de piètre qualité qui ont pour seul mérite une prise en main rapide, pour ne pas subir le turnover, et pour s'assurer qu'un collègue pas très compétent sera capable de comprendre et maintenir les sources.
¹ https://git-scm.com/docs/githooks
² https://git-scm.com/docs/git-format-patch
[^] # Re: Mauvais esprit
Posté par Computer (site web personnel) . En réponse au lien Remettre en cause la propriété intellectuelle : une arme pour riposter à Trump . Évalué à 0.
Que le chasseur soit bon ou mauvais, un cycliste ou un sanglier sera abattu (à moins que ce ne soit le contraire). Mais à la fin le résultat est le même : un être vivant est assassiné.
Je ne m'embarrasse pas de subtilités (je laisse ça aux esprits fins et intelligents qui ont su si bien combattre Trump).
# Mauvais esprit
Posté par Computer (site web personnel) . En réponse au lien Remettre en cause la propriété intellectuelle : une arme pour riposter à Trump . Évalué à 0.
Le nombre de contenus anti-copyright sur Linuxfr depuis que les IAs sont réputées pomper à mort les véritables créateurs.
[^] # Re: Volontaire ?
Posté par Computer (site web personnel) . En réponse au journal Pâques, le bug d'Excel et la difficile adaptation de LibreOffice. Évalué à 2.
Plus rapidement : la mesure du temps est maintenant calée sur des horloges atomiques car c'est ce qu'il y a de plus précis (c'est le TAI¹). Mais dans la vie de tous les jours on veut quelque chose qui soit plus ou moins calé sur la rotation de la terre et sa révolution autour du soleil (c'est UT1 et notre calendrier de manière plus générale), parce que c'est quand même plus pratique…
Le temps UTC est une mesure bâtarde entre les deux : il est calé sur UT1 tout en garantissant l'absolue régularité de la seconde du TAI (on a le meilleur des deux mondes). Pour arriver à ce résultat il faut de temps à autre rajouter une 61ème seconde (on a donc h:m:60 tout à fait légal, 2 fois par an), la seconde intercalaire.²
Le problème Posix est qu'il se cale sur UTC, mais ne représente pas l'heure sous la forme h:m:s, mais d'un unique nombre (donc impossible de rajouter cette fameuse seconde intercalaire). Il y a plusieurs solutions possibles pour résoudre le problème³ mais rien n'a été fait.
--
¹ La conservation de l'énergie (l'une des plus importantes loi de la physique) est directement déductible de l'invariance par translation du temps. En ce sens le TAI est le seul temps physique qui vaille.
² À noter que le cycle solaire connaît des variations plus importantes (±15 min. de souvenir) mais ces variations sont elle-mêmes cycliques (elles s'annulent au bout d'un an), et seule la dérive sur le temps long est prise en compte. UT1 est un temps lissé, ne subsiste que la dérive sur le temps long.
³ http://www.madore.org/~david/computers/unix-leap-seconds.html, donc non dans certains cas d'applications "faire confiance à la lib. écrite par des experts" n'est pas la bonne stratégie. Dans le même genre je ne compte plus la multiplication de l'usage des flottants en lieu et place des décimaux pour représenter des éléments de comptabilité…
[^] # Re: Volontaire ?
Posté par Computer (site web personnel) . En réponse au journal Pâques, le bug d'Excel et la difficile adaptation de LibreOffice. Évalué à 1.
Loin de moi l'idée de défendre Microsoft (c'est de la daube on est bien d'accord). Mais dans le monde Unix les informaticiens ont bien merdé aussi.
Heure Unix.
Sur ce genre de sujet, qui passe à tort pour trivial, les informaticiens ont tendance à surestimer leur compréhension.