Días transcurridos sin incidentes de GitHub

• Days Without GitHub Incidents es una página que muestra los días transcurridos sin incidentes de GitHub
• Actualmente, la sección de días solo aparece como ... days, por lo que no se puede verificar la cifra exacta
• El High Score aparece como 2026
• Las métricas clave que se pueden ver en la página son el conteo actual de días y el High Score
• El conteo actual no aparece como un número, sino en forma de marcador de posición

[GN⁺]

Comentarios en Hacker News

• Hace poco moví todos mis proyectos a una instancia de Forgejo autoalojada y hasta ahora estoy bastante satisfecho. También va rápido
  Si estás buscando una alternativa a GitHub, vale la pena echarle un vistazo; sí hay opciones

  • Ya no está de moda, pero Phabricator también merece una mención honorífica como alternativa a GitHub que se puede autoalojar
    De hecho, su UI “vieja” hasta se siente como una ventaja ahora que tantas otras cosas se han vuelto tan malas
  • Siempre me causó rechazo GitHub, pero git me impresionó desde poco después de conocerlo
    Moví mis proyectos personales de una vieja instancia de Gitea a Forgejo y estoy muy contento con el cambio
  • ¿Qué tal Gitea?

• No me parece justo reducir toda la plataforma a un solo número. Es parecido a sumar todo AWS en una sola cifra

  • Por otro lado, cuando operas un despliegue algo complejo, es fácil ahogarse en dashboards de CPU, memoria, I/O, métricas de la aplicación, suscriptores, usuarios/sesiones activas, etc.
    Por eso sí puede ser útil pensar en una forma de expresar el estado general del sistema con un único número. Por ejemplo, podrías dividir las sesiones activas de usuario entre las conexiones a la base de datos y ajustarlo por capacidad de memoria
    Si es una cifra de un solo dígito, te acostumbras rápido al rango normal y puedes tenerla siempre en un lugar visible. No muestra el detalle, pero si cambia, entonces ya vas a ver las métricas concretas; como resumen para una revisión básica de “¿todo está bien?” puede funcionar bastante bien
  • Aunque separaran la página de estado todavía más y rastrearan por separado las caídas de git push y git pull, si eso apenas alcanza para convertirlo en una broma un poco exagerada, entonces eso se parece más a maquillaje y a inflar el SLA y no debería dejarse pasar
    Hay áreas centrales que casi todo el mundo usa, como Git, issues, pull requests y Actions, y si una sola de ellas falla, entonces el sitio está roto. La página de estado debería mostrar qué tan seguido pasa eso
  • Claramente este es un sitio de memes, y mientras más bajo sea el número, más gracioso es el meme
    Quien de verdad busque información precisa se va a ir a la página oficial de estado
  • Si tan solo S3, EC2, EKS y RDB hubieran tenido una disponibilidad similar a la de GitHub en su conjunto, todo el mundo ya se habría enterado
    Que haya problemas en el wiki del repositorio, estadísticas de commits o gist no importa tanto. Lo importante es la combinación de servicios que se usan juntos y dependen entre sí, como PR, Actions y Discussions
    Incluso si hicieras un único porcentaje por cada componente de ambos sistemas, GitHub seguiría quedando peor. Tal vez tendría algunos días más sin incidentes, pero esta no es una comparación simple
  • Desde la perspectiva del usuario, este cálculo tiene sentido. Pero desde el punto de vista de MSFT o GitHub, este número es un indicador bastante vergonzoso
    Quieren que la gente use todas las funciones de la plataforma y generar una fuerte dependencia, pero si algunas partes siguen fallando, es difícil que los usuarios ganen confianza para adoptar más funcionalidades
    Mientras más cosas uses, mayor es la probabilidad de que una de ellas cause problemas, pero para estas empresas ya ni parece que la confiabilidad sea una meta

• Para nosotros esto es un problema real de continuidad del negocio. Estamos algo atados a GitHub Enterprise, pero si esto sigue así, quizá tengamos que pasar de la nube a on-premise

  • Si van a ir por ese camino, conviene cachear localmente todas las Actions necesarias. Si no, la mejora no va a ser gran cosa

• Ahora mismo estoy configurando Knot autoalojado para usarlo en tangled.org
  La razón principal es que AtProto está genial y autoalojar cosas es divertido, pero también porque quiero ir hacia un modelo en el que yo mismo sea dueño de la infraestructura que hospeda mis proyectos
  El sistema Knot de Tangled se siente como una abstracción muy fuerte en ese sentido. Tus datos se alojan en un AtProto Repository, pero puedes delegar a terceros el alojamiento y la administración de la AtProto Application que los muestra al mundo
  Si Tangled desaparece, puedo llevar mi login de AtProto a otra plataforma y apuntarlo a mi Knot, y la configuración de hosting seguiría igual. Es muchísimo más cómodo que alojar por mi cuenta toda una webapp aislada en algún rincón de internet

• Aquí hay muchos comentarios defendiendo a GitHub. Ya es raro de por sí defender a una empresa de miles de millones de dólares, y más todavía cuando esa empresa controla una mayoría abrumadora del software open source
  Puede que sea por buena voluntad. Pero siempre me ha costado tragar la idea de que para participar en un proyecto que amas tengas que aceptar la política interna y las prácticas de una gran corporación. No siento que le deba nada a GitHub
  Y menos aún si ellos no están cumpliendo con su parte del trato. A cambio de una enorme suma en créditos de Azure, básicamente obtienen acceso libre al repositorio de software del mundo

  • Si le das vuelta a la pregunta, ¿qué motivo hay para estar tan en contra de GitHub como para creer que los otros seres humanos que intentan mantenerlo funcionando no merecen ni un mínimo de amabilidad y respeto?
    ¿No se puede separar al negocio de la gente que trabaja duro detrás de él?
    Ellos no ignoran que personas como nosotros dependen de su trabajo. Saben que su servicio es el “tono de marcación” de la capacidad de desarrollo de software del mundo, y son muy conscientes del impacto que tienen
    ¿Qué pasó con #hugops? ¿Desaparece de inmediato solo porque esa gente trabaja para una empresa que no te gusta?
  • Para ser exactos, están defendiendo a Microsoft, una empresa de billones de dólares
  • Creo que depende de si estás pagando o no. Si pagas, deberías tener expectativas fuertes y exigir responsabilidades
    Si recibes un servicio gratuito, es razonable enojarte, pero al mismo tiempo estás recibiendo exactamente por lo que pagaste
  • Sorprende que la percepción sobre GitHub no haya cambiado demasiado incluso después de la adquisición
    Junto con WSL, para mucha gente eso volvió a equilibrar la balanza y pareció poner otra vez a Microsoft en la categoría de “vamos a darles el beneficio de la duda”
    Esto está revirtiendo bastante de esa buena voluntad, no solo por el costo operativo. De repente, la mala prensa se nota más y cuesta más ignorarla
  • Los dos grupos que defienden con la vida a una empresa multimillonaria son los usuarios de HN y los fans de Nintendo

• Dicen que los commits en GitHub aumentaron 14 veces interanual

  • ¿Los agentes de AI los están empujando como spam?
  • ¿Commits o pushes? Desde la perspectiva de medir carga, la cantidad de commits no es una métrica particularmente útil
  • 14x es una locura, sobre todo porque la calidad y la cantidad del software del mundo real casi no se han movido
    Uno podría haber esperado que esa nueva capacidad de programación estilo agente produjera valor real y mejorara la calidad. Pero lo que se ve es enshittification y estancamiento. ¿Qué demonios están haciendo con todos esos tokens?
  • Que los commits en GitHub hayan aumentado 14 veces interanual, ¿y qué?
    Si Microsoft no puede escalar, ¿quién puede? Si no pueden prestar el servicio, entonces deberían dejar de venderlo hasta que sí puedan
    Esto es una repetición del fiasco de la señal de ocupado de AOL a mediados de los 90. Solo que esta vez, en lugar de enojarse, la gente está inventando excusas para una pobrecita empresa valuada en billones
  • De verdad me cuesta entender la idea de que esto se deba a commits de AI y que todo sea simplemente un tema de volumen de tráfico
    Un aumento de carga de un solo orden de magnitud, o sea, 14x de incremento, no debería terminar en caídas de este nivel
    Si comparas lo que hace GitHub y su volumen con empresas de redes sociales, pagos, plataformas de video, etc., no parece cuadrar la explicación de que sea solo un problema de carga
    Parece mucho más que una plataforma con problemas básicos preexistentes recibió más carga y eso amplificó todo

• La razón por la que este chiste funciona es que todos aceptamos en silencio un riesgo considerable de concentración a cambio de la comodidad

• https://repo.autonoma.ca/treetrek
  Es un visor de Git primitivo en PHP puro que hice yo: gratis, open source, minimalista, sin caché, sin dependencias y sin autenticación ni autorización
  Lo hice porque GitList reventó el espacio en disco y la memoria de mi hosting compartido por un bug de caché, y quería integrar repositorios de GitHub, BitBucket y GitLab
  Tiene su recompensa autoalojar tus cosas y no quedar a merced de los caprichos de terceros

• Es muy probable que esta app, que también parece una app de vibe coding, esté contribuyendo a la ofensiva de apps de vibe coding que están tirando abajo GitHub
  Me dan pena los empleados de GitHub intentando mantener a flote el barco como sea, mientras que Microsoft parece estar haciendo todo lo posible por hundir el suyo