Tage seit dem letzten GitHub-Ausfall

• Days Without GitHub Incidents ist eine Seite, die die Anzahl der Tage seit dem letzten GitHub-Incident anzeigt
• Der Bereich für die aktuelle Tageszahl wird derzeit nur als ... days angezeigt, sodass die konkrete Zahl der Tage nicht erkennbar ist
• High Score wird als Jahr 2026 angezeigt
• Die wichtigsten auf der Seite sichtbaren Kennzahlen sind die aktuelle Tageszahl und der High Score
• Die aktuelle Tageszahl erscheint nicht als Zahl, sondern in Form eines Platzhalters

[GN⁺]

Hacker-News-Kommentare

• Ich habe kürzlich alle meine Projekte auf eine selbst gehostete Forgejo-Instanz umgezogen und bin bisher ziemlich zufrieden. Sie ist auch schnell
  Wenn du nach einer GitHub-Alternative suchst, ist das einen Blick wert, und es gibt Auswahlmöglichkeiten

  • Zwar nicht mehr modern, aber als selbst hostbare GitHub-Alternative verdient auch Phabricator eine ehrenvolle Erwähnung
    Gerade die „altmodische“ UI wirkt inzwischen fast wie ein Vorteil, weil vieles andere heutzutage so schlecht geworden ist
  • Ich hatte GitHub gegenüber schon immer eine gewisse Abneigung, aber git fand ich direkt nach dem ersten Kontakt beeindruckend
    Ich habe mein persönliches Projekt von einer alten Gitea-Instanz zu Forgejo migriert und bin sehr zufrieden
  • Wie ist Gitea?

• Ich finde es nicht fair, die gesamte Plattform auf eine einzige Zahl zu reduzieren. Das ist ähnlich, als würde man AWS insgesamt zu einer Zahl zusammenfassen

  • Andererseits wird man beim Betrieb auch nur einigermaßen komplexer Deployments leicht von Dashboards mit CPU, Speicher, I/O, Applikationsmetriken, Registrierungen sowie aktiven Nutzern/Sitzungen erschlagen
    Deshalb ist es sinnvoll, darüber nachzudenken, wie man den Gesamtzustand eines Systems als eine einzelne Zahl ausdrücken kann. Man könnte zum Beispiel aktive Nutzersitzungen durch die Anzahl der Datenbankverbindungen teilen und nach Speicherkapazität korrigieren
    Wenn es eine einstellige Zahl ist, gewöhnt man sich an den Normalbereich und kann sie immer gut sichtbar platzieren. Sie zeigt zwar keine Details, aber wenn sich der Wert ändert, kann man sich die konkreten Metriken ansehen. Als verkürzte Grundprüfung für „Ist alles in Ordnung?“ kann das gut funktionieren
  • Selbst wenn man die Statusseite noch feiner aufteilt und Ausfälle von git push und git pull getrennt verfolgt, ist das kaum mehr als ein leicht überzeichneter Witz. Das kommt Täuschung und SLA-Aufblähung nahe und sollte nicht durchgehen
    Es gibt zentrale Bereiche, die fast alle nutzen, etwa Git, Issues, Pull Requests und Actions. Wenn auch nur einer davon kaputt ist, ist die Seite kaputt. Die Statusseite sollte zeigen, wie oft so etwas passiert
  • Das ist offensichtlich eine Meme-Seite, und je niedriger die Zahl, desto lustiger das Meme
    Wer tatsächlich genaue Informationen sucht, geht auf die offizielle Statusseite
  • Wenn man nur S3, EC2, EKS und RDB nimmt und diese insgesamt eine ähnliche Verfügbarkeit hätten wie GitHub als Ganzes, wüsste das jeder
    Probleme bei Repository-Wikis, Commit-Statistiken oder gist sind nicht besonders wichtig. Entscheidend ist die Kombination von Diensten wie PRs, Actions und Discussions, die zusammen genutzt werden und voneinander abhängen
    Selbst wenn man für jede Komponente beider Systeme eine einzelne Prozentzahl bilden würde, würde GitHub immer noch schlechter abschneiden. Vielleicht gäbe es ein paar mehr störungsfreie Tage, aber das ist kein einfacher Vergleich
  • Aus Nutzersicht ergibt diese Berechnung Sinn. Aber aus Sicht von MSFT oder GitHub ist diese Zahl ein ziemlich peinlicher Indikator
    Sie wollen vermutlich, dass man alle Funktionen der Plattform nutzt und eine starke Abhängigkeit entsteht. Wenn aber Teile davon ständig ausfallen, fällt es Nutzern schwer, Vertrauen in die Einführung weiterer Funktionen zu gewinnen
    Je mehr man nutzt, desto größer die Wahrscheinlichkeit, dass irgendetwas davon Probleme macht, aber bei solchen Unternehmen scheint Zuverlässigkeit inzwischen kein Ziel mehr zu sein

• Für uns ist das ein echtes Problem der Business Continuity. Wir sind in gewissem Maß an GitHub Enterprise gebunden, aber wenn das so weitergeht, müssen wir vielleicht von der Cloud zurück On-Premises wechseln

  • Wenn ihr in diese Richtung geht, solltet ihr am besten alle benötigten Actions lokal cachen. Sonst verbessert sich die Lage nicht wesentlich

• Ich richte gerade selbst gehostetes Knot ein, um es auf tangled.org zu verwenden
  Der Hauptgrund ist, dass AtProto cool ist und Self-Hosting Spaß macht, aber auch, dass ich mich dahin bewegen will, die Infrastruktur, die meine Projekte hostet, selbst zu besitzen
  Das Knot-System von Tangled wirkt in dieser Hinsicht wie eine starke Abstraktion. Die Daten werden in einem AtProto Repository gehostet, während Hosting und Verwaltung der AtProto Application, die sie der Welt zeigt, an Dritte ausgelagert werden können
  Selbst wenn Tangled verschwindet, kann ich meinen AtProto-Login zu einer anderen Plattform mitnehmen und ihn auf mein Knot zeigen lassen, und das Hosting-Setup bleibt unverändert. Das ist viel bequemer, als eine komplette Web-App direkt selbst zu hosten, die in irgendeiner Ecke des Internets isoliert herumsteht

• Hier wird viel gesagt, um GitHub zu verteidigen. Es ist schon etwas seltsam, eine Multimilliarden-Dollar-Firma zu verteidigen, besonders wenn sie den überwältigenden Großteil von Open-Source-Software beherbergt
  Vielleicht wirkt hier Wohlwollen. Aber dass man, um an geliebten Projekten mitzuarbeiten, die interne Politik und die Gepflogenheiten eines Großkonzerns akzeptieren muss, war immer schwer zu schlucken. Ich habe nicht das Gefühl, GitHub etwas zu schulden
  Besonders dann nicht, wenn sie ihren Teil der Abmachung nicht einhalten. Im Gegenzug für eine riesige Summe in Form von Azure-Credits erhalten sie faktisch freien Zugriff auf die Software-Repositories der ganzen Welt

  • Wenn man die Frage umdreht: Was genau spricht so sehr gegen GitHub, dass die Mitmenschen, die versuchen, den Betrieb am Laufen zu halten, nicht einmal ein Mindestmaß an Freundlichkeit und Respekt verdienen?
    Kann man das Unternehmen nicht von den Menschen trennen, die dahinter hart arbeiten?
    Ihnen ist sehr wohl bewusst, dass Menschen wie wir von ihnen abhängen. Sie wissen, dass ihr Dienst das „Freizeichen“ der weltweiten Softwareentwicklung ist, und sie sind sich der Auswirkungen sehr bewusst
    Wo ist #hugops geblieben? Verschwindet das sofort, nur weil diese Leute bei einem Unternehmen arbeiten, das man nicht mag?
  • Genauer gesagt wird hier Microsoft verteidigt, eine Billionen-Dollar-Firma
  • Ich denke, es hängt davon ab, ob man dafür bezahlt. Wenn man zahlt, sollte man hohe Erwartungen haben und Verantwortlichkeit einfordern
    Wenn man einen kostenlosen Dienst nutzt, ist Ärger zwar ebenfalls nachvollziehbar, aber gleichzeitig bekommt man dann eben das, wofür man bezahlt hat
  • Es überrascht mich, dass sich die Wahrnehmung von GitHub seit der Übernahme kaum verändert hat
    Zusammen mit WSL schien das für viele Menschen das Gleichgewicht wiederherzustellen und Microsoft zurück in die Kategorie „erst einmal eine Chance geben“ zu bringen
    Diese Sache macht nun nicht nur Betriebskosten zunichte, sondern auch viel von dem über die Jahre aufgebauten Wohlwollen. Plötzlich fallen negative Berichte stärker auf und lassen sich schwerer ignorieren
  • Die beiden Gruppen, die mit vollem Einsatz Multimilliarden-Dollar-Firmen verteidigen, sind HN-Nutzer und Nintendo-Fans

• Angeblich sind die Commits auf GitHub im Jahresvergleich um das 14-Fache gestiegen

  • Wird das von AI-Agenten wie Spam hineingedrückt?
  • Sind Commits gemeint oder Pushes? Für die Lastmessung ist die Anzahl der Commits kein besonders aussagekräftiger Maßstab
  • 14x ist absurd. Vor allem, weil sich Qualität und Menge realer Software in der Welt kaum verändert haben
    Man hätte hoffen können, dass die neu gewonnene agentische Coding-Fähigkeit echten Wert schafft und die Qualität verbessert. Stattdessen sieht man Enshittification und Stillstand. Was genau machen all diese Token eigentlich?
  • Dass die Commits auf GitHub im Jahresvergleich um das 14-Fache gestiegen sind, und?
    Wenn Microsoft nicht skalieren kann, wer dann? Wenn sie den Dienst nicht bereitstellen können, sollten sie aufhören, ihn zu verkaufen, bis sie es können
    Das ist eine Neuauflage des AOL-Besetztzeichen-Debakels aus der Mitte der 90er. Nur dass die Leute diesmal nicht wütend sind, sondern Ausreden für ein armes, gequältes Billionenunternehmen finden
  • Ich finde es wirklich schwer zu verstehen, wie man sagen kann, das liege an AI-Commits und nur an der Menge des Traffics
    Ein einstelliger Anstieg, also eine 14-fache Laststeigerung, sollte nicht zu Ausfällen auf diesem Niveau führen
    Wenn man GitHubs Aufgaben und Durchsatz mit Social-Media-Unternehmen, Zahlungsanbietern, Video-Plattformen und ähnlichen Diensten vergleicht, wirkt die Erklärung als reines Lastproblem nicht stimmig
    Es sieht viel eher so aus, als sei eine ohnehin schon problematische Plattform durch zusätzliche Last weiter destabilisiert und verstärkt worden

• Dieser Witz funktioniert, weil wir alle stillschweigend ein erhebliches Konzentrationsrisiko zugunsten der Bequemlichkeit akzeptiert haben

• https://repo.autonoma.ca/treetrek
  Das ist ein von mir gebauter kostenloser Open-Source-, Minimal-Feature-, No-Cache-, No-Dependency-, No-Auth-reiner-PHP-Roh-Git-Viewer
  Ich habe ihn gebaut, nachdem GitList wegen eines Cache-Bugs den Plattenplatz und Speicher eines Shared-Hosting-Pakets gesprengt hatte, und um GitHub-, BitBucket- und GitLab-Repositories zusammenzuführen
  Es hat etwas Befriedigendes, selbst zu hosten und nicht den Launen Dritter ausgeliefert zu sein

• Auch diese App ist wahrscheinlich eine Vibe-Coding-App, und hat womöglich zu dem Ansturm von Vibe-Coding-Apps beigetragen, der GitHub in die Knie zwingt
  Die GitHub-Mitarbeiter, die verzweifelt versuchen, das sinkende Schiff irgendwie über Wasser zu halten, tun mir leid, und Microsoft scheint alles zu tun, um das eigene Schiff selbst zu versenken