Nombre de jours sans incident GitHub

• Days Without GitHub Incidents est une page qui affiche le nombre de jours écoulés sans incident GitHub
• La zone du nombre de jours actuel n’affiche pour l’instant que ... days, ce qui ne permet pas de connaître le nombre exact de jours
• Le High Score est affiché comme étant 2026
• Les principales métriques visibles sur la page sont le nombre de jours actuel et le High Score
• Le nombre de jours actuel apparaît non pas comme un chiffre, mais sous la forme d’un espace réservé

[GN⁺]

Commentaires sur Hacker News

• J’ai récemment déplacé tous mes projets vers une instance Forgejo auto-hébergée, et jusqu’ici j’en suis assez satisfait. C’est aussi rapide
  Si vous cherchez une alternative à GitHub, ça vaut le coup d’y jeter un œil, il y a des options

  • Ce n’est plus vraiment à la mode, mais Phabricator mérite aussi une mention honorable parmi les alternatives à GitHub auto-hébergeables
    Son interface « vieillotte » semble même presque être un avantage vu à quel point beaucoup d’autres solutions sont devenues mauvaises ces derniers temps
  • J’ai toujours eu une certaine aversion pour GitHub, mais git m’a impressionné dès ma première utilisation
    J’ai déplacé mes projets personnels d’une vieille instance Gitea vers Forgejo, et j’en suis très content
  • Et Gitea, ça vaut quoi ?

• Je ne pense pas qu’il soit juste de résumer toute la plateforme à un seul chiffre. C’est un peu comme additionner tout AWS en un seul nombre

  • À l’inverse, dès qu’on exploite un déploiement un peu complexe, on se retrouve facilement noyé sous des tableaux de bord CPU, mémoire, E/S, métriques applicatives, abonnés, utilisateurs actifs/sessions
    Donc réfléchir à une manière d’exprimer l’état global du système par un chiffre unique est utile. Par exemple, on pourrait diviser le nombre de sessions utilisateur actives par le nombre de connexions à la base de données, puis corriger selon la capacité mémoire
    Si c’est un nombre à un chiffre, on finit par connaître sa plage normale et on peut l’afficher en permanence à un endroit bien visible. Il ne montre pas les détails, mais si la valeur change, on peut alors aller voir les métriques précises ; comme résumé de base pour savoir « est-ce que tout va bien ? », ça peut très bien fonctionner
  • Même si on découpait la page d’état encore plus finement, au point de suivre séparément les pannes de git push et de git pull, si cela ne reste qu’une blague un peu exagérée, alors on est proche du tour de passe-passe et du gonflage de SLA, et ça ne devrait pas être toléré
    Il y a des domaines essentiels que presque tout le monde utilise — Git, les issues, les pull requests, Actions — et si l’un d’eux casse, alors le site est cassé. La page d’état devrait montrer à quelle fréquence ce genre de chose arrive
  • C’est clairement un site de mèmes, et plus le chiffre est bas, plus le mème est drôle
    En pratique, ceux qui cherchent une information exacte iront sur la page d’état officielle
  • Si S3, EC2, EKS et RDB avaient à eux seuls une disponibilité comparable à celle de l’ensemble de GitHub aujourd’hui, tout le monde le saurait
    Que ce genre de problèmes touche le wiki des dépôts, les statistiques de commits ou les gist n’a pas tant d’importance. Ce qui compte, c’est l’ensemble des services utilisés ensemble et dépendants les uns des autres, comme les PR, Actions et Discussions
    Même si on fabriquait un pourcentage unique pour chaque composant des deux systèmes, GitHub serait encore derrière. Il y aurait peut-être quelques jours de plus sans panne, mais ce n’est pas une simple comparaison
  • Du point de vue de l’utilisateur, ce calcul a du sens. Mais du point de vue de MSFT ou de GitHub, ce chiffre est un indicateur assez embarrassant
    Ils veulent sûrement pousser les utilisateurs à adopter toutes les fonctions de la plateforme et créer une forte dépendance, mais si certaines tombent régulièrement en panne, il devient difficile d’avoir confiance pour en adopter davantage
    Plus on utilise de choses, plus il y a de chances que l’une d’elles pose problème, mais on a l’impression que pour ce genre d’entreprise, la stabilité n’est plus vraiment l’objectif

• Pour nous, c’est un vrai problème de continuité d’activité. Nous sommes liés dans une certaine mesure à GitHub Enterprise, mais si ça continue, nous devrons peut-être passer du cloud à l’on-premise

  • Si vous allez dans cette direction, mieux vaut mettre en cache localement toutes les Actions nécessaires. Sinon, ça n’améliorera pas grand-chose

• Je suis en train de configurer Knot auto-hébergé pour l’utiliser sur tangled.org
  La raison principale est qu’AtProto est cool et que l’auto-hébergement est amusant, mais aussi parce que je veux aller vers un modèle où je possède directement l’infrastructure qui héberge mes projets
  Le système Knot de Tangled donne ici l’impression d’une abstraction solide. Les données sont hébergées dans un AtProto Repository, tandis que l’hébergement et l’administration de l’AtProto Application qui les expose au monde peuvent être confiés à un tiers
  Même si Tangled disparaît, je peux emporter ma connexion AtProto vers une autre plateforme, la faire pointer vers mon Knot, et conserver la même configuration d’hébergement. C’est bien plus pratique que d’héberger soi-même toute une web app isolée dans un coin d’Internet

• On voit ici beaucoup de commentaires qui défendent GitHub. Défendre une entreprise pesant des dizaines de milliards de dollars est déjà un peu étrange, et encore plus quand elle gère l’écrasante majorité des logiciels open source
  C’est peut-être l’effet de la sympathie. Mais le fait de devoir accepter la politique interne et les pratiques d’une grande entreprise pour contribuer à un projet qu’on aime a toujours été une pilule difficile à avaler. Je n’ai pas l’impression d’avoir une dette envers GitHub
  C’est d’autant plus vrai s’ils ne tiennent pas leur part du marché. En échange d’une énorme somme sous forme de crédits Azure, ils obtiennent en pratique un accès libre aux dépôts logiciels du monde entier

  • Si on renverse la question, pour quelles raisons êtes-vous à ce point opposé à GitHub que les êtres humains qui s’efforcent de faire tourner le service ne mériteraient même pas un minimum de gentillesse et de respect ?
    Est-il impossible de distinguer l’entreprise des personnes qui travaillent dur derrière ?
    Eux aussi savent que des gens comme nous dépendent d’eux. Ils savent que leur service est la « tonalité » de la capacité mondiale de développement logiciel, et ils sont très conscients de leur impact
    Qu’est devenu #hugops ? Ça disparaît d’un coup simplement parce que ces gens travaillent pour une entreprise qui ne vous plaît pas ?
  • Pour être précis, c’est une entreprise valorisée en milliers de milliards de dollars, Microsoft, qui est défendue
  • À mon avis, tout dépend si vous payez pour le service. Si vous payez, vous devez avoir de fortes attentes et demander des comptes
    Si vous profitez d’un service gratuit, il est raisonnable d’être agacé, mais en même temps vous en avez pour ce que vous payez
  • Il est surprenant que la perception de GitHub n’ait pas tant changé après le rachat
    Avec WSL, beaucoup ont eu le sentiment que l’équilibre se rétablissait, et que Microsoft repassait dans la catégorie « donnons-leur une chance »
    Cette affaire ne remet pas seulement en cause les coûts d’exploitation, elle efface aussi une bonne partie du capital sympathie accumulé. Soudain, la mauvaise presse se voit davantage et devient plus difficile à ignorer
  • Les deux groupes qui défendent bec et ongles les entreprises pesant des dizaines de milliards de dollars, ce sont les utilisateurs de HN et les fans de Nintendo

• On dit que les commits sur GitHub ont augmenté de 14× sur un an

  • Les agents IA les poussent comme du spam ?
  • On parle de commits ou de push ? Du point de vue de la mesure de charge, le nombre de commits n’est pas un indicateur très significatif
  • 14×, c’est complètement délirant. D’autant plus que la qualité et la quantité des logiciels du monde réel n’ont presque pas bougé
    On aurait pu espérer que ces nouvelles capacités de programmation pilotées par agents produisent une vraie valeur et améliorent la qualité. Mais ce qu’on voit, c’est surtout de l’enshittification et de la stagnation. Que font-ils donc avec tous ces tokens ?
  • Les commits sur GitHub ont augmenté de 14× sur un an, et alors ?
    Si Microsoft n’arrive pas à passer à l’échelle, qui le pourra ? S’ils ne peuvent pas fournir le service, ils devraient arrêter de le vendre jusqu’à ce qu’ils le puissent
    C’est une répétition du fiasco du signal occupé d’AOL au milieu des années 90. Sauf que cette fois, au lieu de se mettre en colère, les gens trouvent des excuses à une multinationale qui vaut des milliers de milliards et qui souffre tant, la pauvre
  • J’ai vraiment du mal à comprendre l’argument selon lequel tout cela viendrait des commits IA et ne serait qu’un problème de volume de trafic
    Une hausse de charge à un seul chiffre multiplicatif, donc de l’ordre de 14×, ne devrait pas entraîner des pannes de ce niveau
    Si l’on compare ce que fait GitHub et son débit à des entreprises de réseaux sociaux, de paiement ou de vidéo, l’explication par la seule charge ne tient pas vraiment
    Cela ressemble bien davantage à une plateforme qui avait déjà des problèmes de fond, sur lesquels une hausse de charge est venue se greffer et amplifier la situation

• Si cette blague fonctionne, c’est parce que tout le monde a silencieusement accepté un important risque de concentration au nom de la commodité

• https://repo.autonoma.ca/treetrek
  C’est un outil gratuit, open source, minimaliste, sans cache, sans dépendances, sans authentification ni autorisation : un simple visualiseur Git brut en PHP que j’ai créé
  Je l’ai développé parce que GitList faisait exploser l’espace disque et la mémoire de mon hébergement mutualisé à cause d’un bug de cache, et parce que je voulais unifier des dépôts GitHub, BitBucket et GitLab
  Il y a quelque chose de gratifiant à s’auto-héberger et à ne pas dépendre des caprices d’un tiers

• Il est très probable que cette application soit elle aussi une app de vibe coding, et qu’elle ait contribué à la vague d’apps de vibe coding qui mettent GitHub à genoux
  Les employés de GitHub qui essaient désespérément de maintenir le navire à flot font peine à voir, et Microsoft donne l’impression de faire tout son possible pour couler son propre bateau