News GitHub: 4 Millionen zusätzliche CPU-Kerne und 160 Petabyte Speicher

[luckysh0t]

Das sind mal ein paar Kerne…dafür nun Broadcom VCF lizenzieren… schnapper..
Wie wir es aktuell machen..wenn auch für „minimal“ weniger Kerne xD

 

[Hoebelix]

Edit: Ab auf die Ignore-Liste.

Junge junge, wo sind wir mittlerweile angekommen? Disussionsfähigkeit liegt hier bei Null (obwohl man diese Nichtigkeit nicht mal als Diskussion bezeichnen würde).
Da schreibt jemand, was sein persönlicher Eindruck bisher von der Plattform Github war und dass er nicht gedacht hätte dass das so groß ist.
Und dann kommt da ein dritter angelaufen, als ob er persönlich in seinen politischen Grundüberzeugungen beleidigt wurde und macht ein Fass auf...
Und bei so ner unwichtigen Sache dann gleich mit "Ignore" drohen und umsetzen, als ob für @lowrider20 jetzt ein gigantischer Fundus aus Wissen verloren gehen würde...

Weiß nicht ob es so schlau ist, da jetzt dem Gegenüber kindisches Verhalten vorzuwerfen - Selbstreflexion und Atemübungen vor dem unüberlegten Schreiben könnte manchmal helfen.
Man muss doch bei so nem nichtigen Thema nicht immer gleich so ausflippen - versteh ich echt nicht.

Möchte nicht wissen wie du in politischen Diskussionen auftrittst. 😅

Zum Thema:
Ich bin selbst erstaunt was GitHub für Investitionen tätigt, da auch ich nicht aus der Programmier-Szene komme und Github vor allem aus der Spiele Modding-Szene kenne. Hier aber nur als Nutznießer. Hab mich da nie viel mehr mit befasst.
Sehr interessant, Horizont mal wieder etwas erweitert. 👍

 

[Feuerbiber]

Schon irgendwie interessant, dass ausgerechnet Microsoft dafür sorgt, dass das von Linus Torvalds für die Linux-Kernel-Entwicklung initiierte Versionsverealtungssystem "git" durch "github" eine milliardenschwere remote Infrastruktur hat. Gewissermaßen das Ying und Yang der (Open-Source-) Softwareentwicklung. ☯️

 

[ranzassel]

Wer soll denn da wohin abwandern... Nenn mir eine vergleichbare zentrale Repo mit Code Validierung, Riesen-Community und zentraler Integrierung in sämtlichen relevanten Betriebssystemen.

Ich rede von professionell im Sinne von kommerziell.

Unternehmen haben ihren Code in privaten Repos/Organisationen in Github. Dank der irren Orange geht der Trend eh schon leicht in die Richtung Dinge wieder selbst zu betreiben. Ein Gitlab oder TeamCity überfordert da niemanden. Und die "Riesen-Community" ist in der Hinsicht vollkommen irrelevant. Github wurde genutzt, weil es einfach und billig war. Wenn Software nicht mehr in-time ausgeliefert werden kann, weil Github gerade mal wieder Migräne hat, stehen Kosten und Nutzen ganz schnell in keinem Verhältnis mehr.

Und am Ende sind es genau diese zahlenden Unternehmen, mit ihren privaten Repos und Runnern, mit denen Github Geld in die Kassen bekommt. OpenSource-Projekt sind spannend und edel. Kosten ein Github aber nur Geld.

 

[nn|none]

Wenn Software nicht mehr in-time ausgeliefert werden kann, weil Github gerade mal wieder Migräne hat, stehen Kosten und Nutzen ganz schnell in keinem Verhältnis mehr.

Einerseits ist Git dezentral aufgebaut, was es erlaubt auch dann noch zu deployen, wenn einer der Remotes nicht verfügbar ist.
Andererseits hat GitHub auch eine selbstgehostete Variante (GitHub Enterprise Server / GHES), die von vielen Kunden genutzt wird und mit der öffentlichen Seite auf GitHub.com verknüpft werden kann, so dass einzelne Repositories dann dort gespiegelt werden.

Ergänzung (Freitag um 14:07)

Schon irgendwie interessant, dass ausgerechnet Microsoft dafür sorgt, dass das von Linus Torvalds für die Linux-Kernel-Entwicklung initiierte Versionsverealtungssystem "git" durch "github" eine milliardenschwere remote Infrastruktur hat.

Microsoft ist der größte Contributor zu Open-Source-Projekten, gemessen an der Anzahl der aktiven Mitarbeiter, die auf Plattformen wie GitHub Commits veröffentlichen.
Bei der Menge an Code hat Google die Nase vorn.

 

[Sun_set_1]

Unternehmen haben ihren Code in privaten Repos/Organisationen in Github. Dank der irren Orange geht der Trend eh schon leicht in die Richtung Dinge wieder selbst zu betreiben. Ein Gitlab oder TeamCity überfordert da niemanden

Ich glaub Du hast noch nie eine Unternehmensmigration von einer Systemumgebung in die nächste mitgemacht. Das fängt bei simplen Sachen wie Commits, Ticketstrukturen übertragen ohne Auswertbarkeit zu verlieren an, geht über die User-Migration, Rechteverwaltung-Anpassung, Rollenkonzepte, Ausbau der Sub-Umgebungen usw usf fort. Da hast Du schon ein Jahr Aufwand ohne das man sich überhaupt mal mit der eigentlichen Repo-Migra beschäftigt hat.

Dann müssen die User geschult und trainiert werden, Kompatibilitäten und Systemintegrationen sicher gestellt werden und so setzt es sich weiter fort. Das ist alles andere als trivial. Und da haben wir noch gar nicht über den generellen Funktionsumfang etc gesprochen. Den Punkt, welche andere Umgebung eine gleiche tiefe und Funktionsumfang wie Github bietet, haben wir auch noch nicht gelöst.


Was ich sagen will, die Schmerzgrenze ist schon sehr hoch, um als Unternehmen nach Jahren dortiger Entwicklung "mal eben" abzuwandern.

 

[stefan92x]

Das fängt bei simplen Sachen wie Commits, Ticketstrukturen übertragen ohne Auswertbarkeit zu verlieren an, geht über die User-Migration, Rechteverwaltung-Anpassung, Rollenkonzepte, Ausbau der Sub-Umgebungen usw usf fort. Da hast Du schon ein Jahr Aufwand ohne das man sich überhaupt mal mit der eigentlichen Repo-Migra beschäftigt hat.

Nur, wenn das alles mit GitHub gemacht wird. Wenn das Ticketsystem eh sowas wie Jira ist etc, dann schrumpft der Aufwand deutlich.

 

[Sun_set_1]

@stefan92x Gehe ich so nicht mit. Auch wenn Du das ganze URS und Ticketing in Jira hast musst auch da dann alle syncs, Verlinkungen, User-Alias Verknüpfungen usw usf rüberbringen. Das musst Du ja so aus dem alten Github rauslösen und ins neue portieren, dass da auch alles rückwirkend zertifizerbar bleibt wenn eine Kunde mal wieder ne Auditierung durchführen möchte.

 

[stefan92x]

@Sun_set_1 klar muss man sich auch um sowas kümmern. Aber es wird einfacher, als wenn man alles nur in Github hat.

Ergänzung (Freitag um 15:29)

Nachtrag noch: Wenn man sonstiges als Ticketsystem nutzt und sich von Anfang an darauf einigt, dass git (und zwar nur git) die Wahrheit ist, dann kann man sich vieles einfacher machen. Wenn Tickets zwingend im Commit stehen müssen, tatsächlich durchgeführte Deployments als git tags markiert werden (mit Ticketnummer) und ähnliche Maßnahmen ergriffen werden, dann ist die Plattform auf der das ganze läuft wirklich egal für die Nachvollziehbarkeit/Zertifizierbarkeit.

Wie überall gilt auch hier, je tiefer man sich in den Vendor-Lock-In begibt und spezifische Funktionen nutzt, desto aufwendiger wird ein Wechsel auf was anderes.

 

[Sun_set_1]

Nachtrag noch: Wenn man sonstiges als Ticketsystem nutzt und sich von Anfang an darauf einigt, dass git (und zwar nur git) die Wahrheit ist, dann kann man sich vieles einfacher machen. Wenn Tickets zwingend im Commit stehen müssen, tatsächlich durchgeführte Deployments als git tags markiert werden (mit Ticketnummer) und ähnliche Maßnahmen ergriffen werden, dann ist die Plattform auf der das ganze läuft wirklich egal für die Nachvollziehbarkeit/Zertifizierbarkeit.

Naja aber ich bitte dich. Da ist doch der Wunsch Vater des Gedanken. Welches Unternehmen hat das denn vor 10-15-20 Jahren mitbedacht und vor allem durchgehend stringent korrekt gepflegt.

Die Realität sieht anders aus, Ticketstrukturen ändern sich über den Lauf der Zeit, verschiedene Development und Deployment States, zugehörige Testingverfahren etc. Das alles muss sauber gesynched und 100%ig korrekt neu aufgebaut werden.

Na Prost Mahlzeit dem, der/die das bei ner Umgebung wie Git(hub) über ne Laufzeit von Dekaden migrieren darf.

 

[stefan92x]

Naja aber ich bitte dich. Da ist doch der Wunsch Vater des Gedanken. Welches Unternehmen hat das denn vor 10-15-20 Jahren mitbedacht und vor allem durchgehend stringent korrekt gepflegt.

Die die keine Wahl hatten, weil es sowas wie GitHub einfach noch nicht in der Form gab, als sie damit angefangen haben.

Das alles muss sauber gesynched und 100%ig korrekt neu aufgebaut werden

Oder "einfach" nur archiviert werden und man nutzt die Migration um eine aktuelle Struktur aufzubauen. Es muss nicht alles eins zu eins wieder erstellt werden. Gilt auch dann, wenn man sonstiges umstellt.

 

[ranzassel]

Einerseits ist Git dezentral aufgebaut, was es erlaubt auch dann noch zu deployen, wenn einer der Remotes nicht verfügbar ist.

Erzähl das mal deinen BuildRunnern in ECS oder bei Github selbst. Wenn die, weil Github mal wieder nicht erreichbar ist, den Code von dort nicht auschecken können. Die Build-Infrastruktur ist aus guten Gründen geschützt, so dass da nicht Hinz und Kunz mal eben ihre lokalen GitRepos reinkopieren können. Komplexe Builds mit massenhaft Integrations- und Contracttests lässt du auch nicht spontan lokal auf irgendeinem Dev-Rechner laufen. Und selbst wenn.... dann musst das gebaute Artefakt von deinem Dev-Rechner auch erstmal in die Produktionsumgebung bekommen. Auch die ist natürlich nicht für jeden zugänglich, damit eben nicht jeder Heiopei dort zweifelhaftes Zeug deployt. Womöglich brauchst du auch noch signierte SBOMs.

Wie oben schon gesagt: Ich rede von kommerziellen Unternehmen. Nicht von Privatentwicklern oder Frickelbuden. Und wenn du mittlerweile öfter vor dem Problem stehst, dass du dringende Fixes nicht zeitnah ausgerollt bekommst, dann steigert das die Bereitschaft Geld für andere Lösungen in die Hand zu nehmen ganz ganz schnell. Auch wenn die tatsächliche Umsetzung etwas dauern kann. Aber die Github-Probleme dauern ja jetzt auch schon das eine oder andere Jahr lang an.

 

[nn|none]

Erzähl das mal deinen BuildRunnern in ECS oder bei Github selbst.

Ich erzähle das sogar beruflich, um großen Firmen zu erklären wie sie Git und GitHub richtig nutzen, ohne sich in den üblichen Sackgassen zu verfahren, wie Du sie hier schilderst. Wer Services am Laufen hat, die wirklich kritisch sind, sollte sich darüber Gedanken machen, welche Alternativen man hat, wenn ein Dienstleister wie GitHub nicht verfügbar ist. Dabei geht es nicht darum von einem beliebigen Entwicklerlaptop zu deployen.

Ich rede von kommerziellen Unternehmen. Nicht von Privatentwicklern oder Frickelbuden.

Ich rede von den wirklich großen Läden, die jeder kennt und deren Namen ich hier dennoch nicht nennen kann.

 

[Feuerbiber]

Microsoft ist der größte Contributor zu Open-Source-Projekten, gemessen an der Anzahl der aktiven Mitarbeiter, die auf Plattformen wie GitHub Commits veröffentlichen.
Bei der Menge an Code hat Google die Nase vorn.

Diese Aussage ist veraltet. Google und Red Hat liegen inzwischen vorn. Außerdem gilt das nur für Projekte auf github. Und: auch nur wenn man Tochterfirmen für sich betrachtet und Red Hat z.B. nicht IBM zurechnet.

Wie dem auch sei. Interessant ist diese Tatsache allemal.

 

[nn|none]

Diese Aussage ist veraltet.

Danke! V.a. auch für die Quellenangabe. 🙇🏼‍♂️