Dias sem incidentes no GitHub

• Days Without GitHub Incidents é uma página que mostra quantos dias se passaram sem incidentes no GitHub
• Atualmente, a área da contagem de dias aparece apenas como ... days, então não é possível verificar o número exato de dias
• O High Score aparece como 2026
• Os principais números visíveis na página são a contagem atual e o High Score
• A contagem atual aparece no formato de marcador de posição, e não como um número

[GN⁺]

Comentários do Hacker News

• Recentemente movi todos os meus projetos para uma instância Forgejo auto-hospedada e, até agora, estou bem satisfeito. Também é rápida
  Se você está procurando uma alternativa ao GitHub, vale a pena dar uma olhada; há opções

  • Não está mais na moda, mas como alternativa ao GitHub que pode ser auto-hospedada, Phabricator também merece uma menção honrosa
    Na verdade, a interface “antiga” parece até uma vantagem hoje, considerando o quanto as outras pioraram
  • Sempre tive certa rejeição ao GitHub, mas o git me impressionou desde logo depois que o conheci
    Migrei meus projetos pessoais de uma instância antiga do Gitea para o Forgejo e estou muito satisfeito
  • E o Gitea?

• Não acho justo reduzir a plataforma inteira a um único número. É parecido com somar a AWS inteira em um único número

  • Por outro lado, quando você opera uma implantação minimamente complexa, é fácil se afogar em dashboards de CPU, memória, I/O, métricas da aplicação, inscritos, usuários/sessões ativos
    Então é útil pensar em uma forma de expressar o estado geral do sistema com um único número. Por exemplo, dá para dividir sessões ativas de usuários pelo número de conexões com o banco de dados e ajustar pela capacidade de memória
    Se for um número de um dígito, você se acostuma com a faixa normal e pode deixá-lo sempre em algum lugar bem visível. Ele não mostra os detalhes, mas quando o valor muda você pode ir ver as métricas específicas, então pode funcionar bem como um resumo básico para checar “está tudo normal?”
  • Mesmo que a página de status fosse dividida como está agora, rastreando separadamente falhas de git push e git pull, se isso ainda for só uma piada com um pouco de exagero, então está mais para ilusionismo e inflação de SLA e não deveria ser aceito
    Há áreas centrais que quase todo mundo usa, como Git, issues, pull requests e Actions, e se qualquer uma delas quebra, o site está quebrado. A página de status deveria mostrar com que frequência isso acontece
  • Isso é claramente um site de memes, e quanto menor o número, mais engraçado fica o meme
    Quem estiver procurando informações realmente precisas vai para a página oficial de status
  • Se só S3, EC2, EKS e RDB tivessem uma disponibilidade parecida com a do GitHub inteiro hoje, todo mundo saberia
    Não importa tanto se repositório wiki, estatísticas de commits ou gist têm esse tipo de problema. O que importa é a combinação de serviços usados em conjunto e que dependem uns dos outros, como PR, Actions e Discussions
    Mesmo que você criasse uma porcentagem única para cada componente dos dois sistemas, o GitHub ainda ficaria para trás. Talvez houvesse mais alguns dias sem incidentes, mas isso não é uma comparação simples
  • Do ponto de vista do usuário, esse cálculo faz sentido. Mas, do ponto de vista da MSFT ou do GitHub, esse número é um indicador bem constrangedor
    Eles vão querer que você use todos os recursos da plataforma e criar uma forte dependência, mas se partes dela continuam quebrando, fica difícil para o usuário ganhar confiança para adotar mais funcionalidades
    Quanto mais coisas você usa, maior a chance de alguma delas causar problema, mas para essas empresas já não parece que estabilidade seja um objetivo

• Para nós, isso é um problema real de continuidade de negócios. Estamos razoavelmente presos ao GitHub Enterprise, mas se isso continuar, talvez tenhamos de sair da nuvem e ir para on-premises

  • Se forem nessa direção, é melhor fazer cache local de todas as Actions necessárias. Caso contrário, a melhora não será grande coisa

• Agora estou configurando um Knot auto-hospedado para usar no tangled.org
  O principal motivo é que o AtProto é legal e auto-hospedagem é divertida, mas também porque quero caminhar para possuir diretamente a infraestrutura que hospeda meus projetos
  O sistema Knot do Tangled parece uma abstração forte nesse sentido. Os dados ficam hospedados em um AtProto Repository, enquanto a hospedagem e a gestão do AtProto Application que os mostra ao mundo podem ser deixadas para terceiros
  Mesmo que o Tangled desapareça, eu posso levar meu login do AtProto para outra plataforma, apontá-lo para meu Knot e manter a configuração de hospedagem como está. É muito mais prático do que hospedar por conta própria um webapp inteiro isolado em algum canto da internet

• Há muita gente aqui defendendo o GitHub. Já é meio estranho defender uma empresa de bilhões de dólares, e mais ainda quando ela é responsável pela esmagadora maioria do software open source
  Pode ser só boa vontade funcionando. Mas sempre foi difícil engolir a ideia de que, para participar de um projeto que você ama, você precisa aceitar a política interna e as práticas de uma grande empresa. Não sinto que devo nada ao GitHub
  Ainda mais se eles não estão cumprindo a parte deles no acordo. Em troca de uma soma enorme em créditos Azure, eles basicamente ganham acesso livre ao repositório de software do mundo inteiro

  • Colocando a pergunta ao contrário: o que exatamente faz você ser tão contra o GitHub a ponto de achar que os outros seres humanos que se esforçam para manter a operação de pé não merecem nem o mínimo de gentileza e respeito?
    Não dá para separar a empresa das pessoas que trabalham duro por trás dela?
    Eles também sabem que pessoas como nós dependem deles. Sabem que o serviço deles é o “tom de discagem” da capacidade mundial de desenvolvimento de software e têm plena noção do impacto disso
    Para onde foi o #hugops? Ele some na hora porque essas pessoas trabalham numa empresa de que você não gosta?
  • Tecnicamente, o que está sendo defendido é a Microsoft, uma empresa de trilhões de dólares
  • Acho que depende de você pagar ou não pelo serviço. Se paga, deve ter expectativas fortes e cobrar responsabilidade
    Se está recebendo um serviço gratuito, é razoável ficar irritado, mas ao mesmo tempo você recebe pelo que pagou
  • É surpreendente como a percepção sobre o GitHub mudou tão pouco desde a aquisição
    Junto com o WSL, isso equilibrou muita coisa para muita gente e pareceu recolocar a Microsoft no campo do “vamos dar um voto de confiança”
    Desta vez, eles estão devolvendo não só custos operacionais, mas também muita da boa vontade acumulada. De repente, más notícias ficam muito mais visíveis e mais difíceis de ignorar
  • Os dois grupos que defendem com unhas e dentes uma empresa de bilhões de dólares são usuários do HN e fãs da Nintendo

• Dizem que os commits do GitHub aumentaram 14 vezes em relação ao ano anterior

  • Será que são agentes de IA empurrando spam?
  • Estamos falando de commits ou de pushes? Do ponto de vista de medição de carga, número de commits não é um critério muito significativo
  • 14 vezes é um nível insano. Ainda mais porque a qualidade e a quantidade do software no mundo real mal se mexeram
    Dava para esperar que essa nova capacidade de programação estilo agente gerasse valor real e melhorasse a qualidade. Mas o que se vê é enshittification e estagnação. O que, afinal, estão fazendo com todos esses tokens?
  • Os commits do GitHub aumentaram 14 vezes em relação ao ano anterior, e daí?
    Se a Microsoft não consegue escalar, quem vai conseguir? Se não consegue fornecer o serviço, deveria parar de vendê-lo até isso se tornar possível
    Isso é uma repetição do fiasco do sinal de ocupado do AOL dial-up em meados dos anos 90. Só que desta vez, em vez de ficarem com raiva, as pessoas estão inventando desculpas para uma empresa de trilhões que estaria sofrendo coitada
  • Realmente não consigo entender essa conversa de que isso é por causa de commits de IA e de que é tudo apenas questão de volume de tráfego
    Um aumento de carga de um dígito, ou seja, algo como 14 vezes, não deveria levar a falhas desse nível
    Comparando o que o GitHub faz e seu volume com empresas de redes sociais, pagamentos, plataformas de vídeo etc., a explicação de que é só problema de carga não parece bater
    Parece muito mais que uma carga maior se somou a problemas básicos que a plataforma já tinha e amplificou tudo

• Essa piada funciona porque todo mundo aceitou em silêncio um risco considerável de concentração em troca de conveniência

• https://repo.autonoma.ca/treetrek
  É um visualizador bruto de Git em PHP puro, gratuito, open source, com funcionalidade mínima, sem cache, sem dependências, sem autenticação nem autorização, que eu fiz
  Eu o criei porque o GitList estourou o espaço em disco e a memória da hospedagem compartilhada por causa de um bug de cache, e porque eu queria integrar repositórios do GitHub, BitBucket e GitLab
  Há algo recompensador em fazer auto-hospedagem e não ficar à mercê dos caprichos de terceiros

• Este app, que provavelmente também é um app de vibe coding, muito possivelmente contribuiu para a onda de apps de vibe coding que está derrubando o GitHub
  Dá pena dos funcionários do GitHub tentando manter o navio afundando de alguma forma flutuando, enquanto a Microsoft parece fazer tudo o que pode para afundar o próprio barco