2 puan yazan GN⁺ 3 시간 전 | 2 yorum | WhatsApp'ta paylaş
  • Microsoft tarafından satın alındıktan sonra GitHub’ın erişilebilirliği (uptime) gözle görülür biçimde kötüleşti; resmi durum sayfası bile endişe verici rakamlar gösterirken, resmi olmayan durum sayfası daha da ciddi bir tablo ortaya koyuyor
  • Copilot’un aşırı kullanımı ve yapay zeka üretimi düşük kaliteli kodun (slop) taşması nedeniyle GitHub’ın adeta kendine DDoS uyguladığı bir durum ortaya çıktı; botlar ve sahte yıldız ekonomisi platforma olan güveni zedeliyor
  • Git açık kaynaklı bir dağıtık sürüm kontrol sistemidir ve GitHub olmadan da çalışır; bu yüzden GitHub’ı Git’in kendisiyle aynı şey sanan algıdan çıkmak gerekiyor
  • Codeberg, Tangled, Gitea, GitLab, self-hosted Forgejo gibi çeşitli alternatif Git forge seçenekleri mevcut ve geçişe hemen başlamak gerekiyor
  • Birçok tanınmış geliştirici art arda GitHub’dan ayrıldığını duyuran yazılar yayımlarken, GitHub bağımlılığından kurtulmak tüm ekosistemin görevi olarak öne çıkıyor

GitHub’dan ayrılmak için nedenler

Git ≠ GitHub

  • GitHub, “kaynak yönetimi” ile eşanlamlı hale gelmiş olsa da çok fazla kullanıcı Git’in GitHub olmadığını bilmiyor
  • Git ve GitHub aynı şey değildir; Git’in temel teknolojisi açık kaynaklıdır ve dağıtıktır, bu yüzden tüm depolar eşittir ve merkezi bir hizmet olmadan da çalışabilir
  • Merkezi hizmetler sosyal kolaylığın ürünüdür; GitHub başlangıçta yalnızca yararlı bir ek araçtı, ancak Microsoft bunu pahalı bir yüke dönüştürdü
  • Ağ etkisi güçlü olsa da GitHub’ın sahte yıldız ekonomisi değersizdir ve platform botlarla ve slop ile doludur
  • GitHub Actions, aşırı karmaşık CI hatlarının bir parçasıdır. Başka çözümler bulmak zahmetli olabilir, ancak GitHub’ın istikrarına güvenilip güvenilemeyeceğini sorgulamak gerekir
  • Gemi batıyor; her şeyi tek seferde taşımayacak olsanız bile geçiş sürecini hemen başlatmanız gerekiyor

Alternatifler ve geçiş yöntemleri

  • En yakın kaçış yolu başka bir merkezi Git forge hizmetine geçmektir; kayıt olduktan sonra depoyu yeni upstream’e push etmek yeterlidir
  • Bazı hizmetler geçişi otomatikleştirebilir ve issue içe aktarmayı destekleyebilir, ancak GitHub’daki issue’ları olduğu gibi bırakmayı seçmek de mümkündür
  • Aşağıdaki alternatiflerin hiçbiri kusursuz değildir; ortak noktaları sadece GitHub olmamalarıdır
  • Merkezi Git forge alternatifleri

    • Codeberg — Kâr amacı gütmeyen, topluluk odaklı bir proje; geçmişi kanıtlanmış güvenli bir alternatif. Forgejo için öne çıkan instance’tır
    • Tangled — Alfa aşamasındaki bir startup; AT protocol entegrasyonu ilginç bir seçenek. Küçük kişisel projeler için değerlendirilebilir
    • Gitea — Yönetilen bulut Git hosting sunar; Codeberg/Forgejo’nun çatallanıp ayrıldığı özgün açık kaynak projedir
    • GitLab — Kurumsal düzeyde olduğu için ağır ve karmaşık olabilir, ancak kurum içi karar süreçlerine uygun bir seçenek olabilir
    • Bitbucket — Tavsiye edilmese de “GitHub olmayan” kategorisine girer
    • Game of Trees, Radicle, Sourcehut — Ek alternatiflerdir ve ayrıca araştırılmaları gerekir
  • Self-hosting

    • Kurumlar ya da bireyler kendi Git forge’larını self-hosted olarak çalıştırabilir; actions ve releases da işletilebilir
    • Önerilen self-hosted seçenek Forgejo
    • Açık işbirliği gerekiyorsa Codeberg’e bir kopya push etme yöntemi kullanılabilir
    • Gitea ve GitLab da self-hosting seçenekleri sunar, ancak GitLab görece çok daha ağırdır
    • Yalnızca GitHub değil, diğer forge’lar da Git’in kendisinden ayrıdır; forge’un ek özelliklerinin gerçekten gerekli olup olmadığı sorgulanabilir
    • Git, yalnızca SSH ile bile doğrudan kullanılabilir
      git clone user@192.168.1.67:/path/to/repo  
      
  • İşbirliği yöntemi ayrı bir mesele olsa da, Linux e-posta listeleri üzerinden patch alışverişiyle sürdürülebiliyorsa, bunun sadece ölçek nedeniyle imkânsız olduğunu kesin olarak söylemek zordur
  • Merkezi Git forge’lar pratik bir uzlaşma olabilir, ancak GitHub gibi çökebilecekleri akılda tutularak her zaman bir kaçış planı bulundurulmalıdır

2 yorum

 
kimjoin2 1 시간 전

Sunduğu özellikler düşünüldüğünde, %99’dan fazlasını karşılıyor olması bile şaşırtıcı.

 
GN⁺ 3 시간 전
Hacker News görüşleri
  • Herkes bunu Microsoft satın alımına ya da beceriksizliğe bağlamak istiyor ama GitHub’ın paylaştığı verilere bakınca, yapay zeka yüzünden GitHub’a commit edilen kod miktarının 10 kat arttığı ve bunun etkisinin CI, Actions, kod toplama gibi her yere yayıldığı oldukça açık görünüyor
    Yazı sahibi nedeni MS Copilot gibi tuhaf unsurlarda arıyor ama bu, nedensellik kurmaktan çok hoşlanmadığı şeyleri sıralıyormuş gibi duruyor
    Asıl ortadaki kocaman mesele olan yapay zeka kaynaklı kod patlaması ise görmezden geliniyor

    • Yazıdaki grafiğe bakılırsa kesinti örüntüsü Ocak 2020’de başlıyor
      OpenAI GPT-3.5’i Kasım 2022’de çıkardı, fiilen Aralık sayılır; anlatılan türden büyük dil modeli/ajan kodlama ise ancak 2024’te gerçekten hızlandı, hatta pratikte 2025’e daha yakın
      O halde yapay zeka tartışması başlamadan önce, satın alımdan sonraki yaklaşık 4 yıllık kötü erişilebilirlik nasıl açıklanacak?
    • Yazıyı okuyunca benim tepkim de tam olarak buydu
      Microsoft eleştirisine katılmak güzel ama ortadaki kocaman gerçeği kaçırmamak lazım
      Yarın GitHub’ın kusursuz bir alternatifi çıksa bile, milyonlarca satır yapay zeka üretimi kodun oranın altyapısını da bozmasını ne engelleyebilir?
      Merkezi kod barındırma, yapay zeka yüzünden neredeyse ölecek gibi görünüyor. Sosyal medyada olanlara benzer bir durum
    • GitHub satın alımdan sonra olumlu yönde hiç değişmedi
      10 yıl uzun bir süre ve sonuç artık ortada
      GitHub Actions, Copilot ve kapatılamayan o çirkin yapay zeka araması. Bir de Azure’a taşınma
      Microsoft ağ etkisini bozmayı başardı ve arızalar da bardağı taşıran son damla oldu
    • Bu doğru olsa bile Microsoft’un elinde tüm bulut platformu var
      Kendi içinde devasa kod tabanları var ve yaklaşık 200 bin çalışanı bulunuyor
      Hele özel depoları ücretsiz yapmak gibi kararları da bilinçli biçimde verdiklerine göre, buna mazeret demek zor
    • Bazen Microsoft’un GitHub’ı Azure bulutunda Windows üstünde çalıştırdığını hayal ediyorum
      GitHub her çöktüğünde “Herhalde biri GH’nin üzerinde çalıştığı Windows Server’ı güncelledi de hepsini yeniden başlatmak zorunda kaldılar” diye düşünüyorum
      Bunun %99 doğru olmadığından eminim ama böyle düşünmek içimi rahatlatıyor ve her kesintide biraz komik geliyor
  • Bugün GitHub’da bir depoya bakmaya çalışıyordum
    Commit geçmişini görmek için “xxx commits” bağlantısına tıkladım, bu kez de secondary rate limit’e takıldığımı ve beklemem gerektiğini söyledi
    Bu ağda GitHub’a bakan tek kişi benim ve bağlantı da CGN değil, ayrılmış bir IP

    • Siteyi düzgün gezmenin tek yolu oturum açmış durumda bakmak
    • Bende de tamamen aynı durum var ve oldukça sık yaşıyorum
    • Slack’teki normal bir bağlantıya tıklıyorum, bana 404 dönüyor ama başkalarında düzgün açılıyor; bu da sık oluyor
    • Masaüstündeysen Ctrl + Shift + R ile sayfa önbelleğini yenileyebilirsin
      Sonra sayfa düzgün yükleniyor
    • Bu tipik bir techbro gaslighting örneği
      Gerçekte yıllardır rate limit’ten çok varsayılan reddetmeye yakın bir durum var ama kullandıkları metni gerçeğe uyacak şekilde değiştirmeyi reddediyorlar
  • “GitLab - Kurumsal seviye demek; hantal ve kafa karıştırıcı ama yöneticine etkileyici görünür demektir. Seçmek için birden çok toplantı gerekiyorsa bunu seç.”
    Komik

    • İş yerinde GitLab kullanıyoruz ve açıkçası hayal kırıklığı yaratıyor
      En basit işleri yapmak için bile arayüz fazla karmaşık. Mesela bir MR’ı onaylamak için fiilen menü olan bir düğmeye basman gerekiyor, diff okumak zor, ‘To-do list’te ise zaten merge edilmiş MR’lar bile duruyor. Bu nasıl eyleme dönük bir yapılacaklar listesi olabilir?
      Zaten merge edilmiş MR’ların ‘To-do list’te kalması sorunu yıllar önce açılmıştı ama iyileşme pek hızlı görünmüyor
      Buna karşılık Bitbucket’e yönelik tepki biraz şaşırtıcı. Arayüzü çok sade ve net, yeni katılanlar da böyle düşünüyor. Script Runner kullanınca oldukça etkileyici şeyler de yapılabiliyor ve devasa depoları iyi kaldırıyor
    • Komik ama doğru değil
      GitLab, GitHub’dan özellikle daha hantal ya da daha kafa karıştırıcı değil
      Hatta gerçek anlamda kurumsal seviye yazılım bile sayılmaz. Öyle bir şey istiyorsan Jira’ya ya da Microsoft’un yaptığı herhangi bir şeye bak
    • Güldüm
      Biz self-hosted GitLab kullanıyoruz; git ve container registry olduğu için ben seçmiştim
      Web arayüzünü sık kullanmıyorsan arayüz gerçekten kafa karıştırıcı olabilir
  • Aylık 5 dolara bir sunucu barındırıp üzerine birden fazla proje koyabilirsin
    Depolara milyon yıldız gelmez ama benim ihtiyaçlarıma fazlasıyla yetiyor ve istediğim kişilere de erişim verebiliyorum

  • Grafiğin nasıl okunması gerektiğinden pek emin değilim
    Bir yandan GitHub satın alımı yüzünden erişilebilirlik kötüleşmiş olabilir
    Öte yandan satın alma öncesi erişilebilirliğin %100,00 görünmesi şüpheli; belki de sadece durum sayfası daha iyi güncellenmeye başlamıştır
    GitHub’ın son dönemde erişilebilirlik sorunları yaşadığını biliyorum ama grafikteki sorun 2020’de başlıyor gibi görünüyor ve büyük ölçüde kötüleşmiş de görünmüyor

  • Büyük açık kaynak depolarını sonunda rahat bırakmanın imkansız olduğu hissi var
    SourceForge’un bozulup gittiğini hatırlıyorum; GitHub’da da aynı şeyin yaşandığını görmek gerçekten üzücü
    Ek olarak URL’yi “dBus hell” diye okudum. Herkes en az bir kez yaşamıştır

    • Hayır, nushell dBu birimi tabanlı olduğu için adı dBu Shell
  • Şirket yönetseydim ne yapardım diye sık sık düşünüyorum
    Tüm kod incelemelerini e-posta üzerinden yapmanın nasıl olacağını gerçekten görmek isterdim
    Depolar için sadece git amaçlı SSH erişimi olan basit bir VPS tarzı sunucu yeterli olurdu; incelemeye girecek kod için for-review/ diye bir branch namespace’i bulunur, CI ise branch’in görünmesini bekleyen bir bot olur ve geçip geçmediğini belirtmek için ref’lere yorum ya da etiket eklerdi. Sonuçları e-posta zincirine yanıt olarak da gönderebilirdi
    Posta listesine elbette eski incelemeleri görmek için bir web arşiv görüntüleyicisi eklenirdi. Zaten böyle çözümler var, sonuçta sadece HTML
    Sohbet için IRC kullanılır, bir bot da kanalı arşivlerdi. Aşırı kolay
    Tüm sistem, daha güçlü donanım gerektiren CI çalıştırıcıları hariç, çok ucuz sunucularda çalışabilir
    GitHub, yazılım projelerini yürütmek için gerekenden çok daha fazla mühendislik barındırıyor. Linux çekirdeğine bak; basit bir posta listesi kullanıyor ve gelmiş geçmiş en başarılı yazılım projesi olduğuna itiraz etmek pek kolay değil
    Ama issue/bug takibi biraz daha korkutucu. Kendi çözümümü yazmaya kalkarsam şirketin asıl işinden çok onunla uğraşırım gibi geliyor. Belki de gidip bug takip yazılımı şirketi olmak gerekir?

    • İdeal olarak kod incelemelerinin de sürüm kontrollü olması ve kolay erişilebilir bir geçmişi bulunması iyi olurdu
      Yani yorumların tam olarak hangi satıra bağlı olduğunu, o satırın ne zaman değiştiğini görmek ve ileri geri gezebilmek isterim
      E-posta bu veriyi taşımak için bir protokol olarak yeterli olabilir ama e-posta istemcileri bunu görüntülemek için iyi bir yol değil
      Belki de dağıtık bir kod inceleme sistemine ihtiyaç vardır
  • Doğu Avrupa’da yaşamanın bir avantajı da var
    Saat dilimi sayesinde büyük GitHub kesintilerini neredeyse hiç fark etmiyorum
    Ücretsiz barındırma ve Actions konusunda da oldukça cömert olmalarından memnunum

  • Evdeki sunucuma Forgejo kurduğumdan beri arkama bakmadım
    Tek sorun, uygulamaları DigitalOcean App Platform veya Vercel gibi yerlere barındırırken ortaya çıkıyor; bunlar sadece GitHub’a bağlanıyor

    • DigitalOcean App Platform, yalnızca GitHub değil GitLab’dan da dağıtımı destekliyor
      Yalnız self-hosted GitLab instance’ı değil, gitlab.com’daki barındırılan instance’ı kullanman gerekiyor
      Zaten self-hosted bir forge kurduysan, DigitalOcean App Platform’a bağlanmak için gitlab.com’u köprü gibi kullanabilirsin. Sadece bir kez gitlab.com hesabı açıp self-hosted forge’unun gitlab.com’a bir kopya göndermesini ayarlaman yeterli. Fiilen GitLab’ı kullanman pek gerekmiyor
      Yine de DigitalOcean’ın IaaS/PaaS satan bir şirket olup kendi altyapısında çalışan self-hosted Forgejo gibi şeylere bağlantı vermemesi mantıklı değil
      Aslında self-hosted forge isteyen çok kişi var ama doğrudan kurup işletmek isteyen az kişi olduğunu düşününce, DigitalOcean’ın Forgejo’yu ya da bir alternatifini alıp yıllık 20 dolar gibi ciddi indirimli yarı yönetilen tek tık dağıtım seçeneği sunmaması ve App Platform bağlantısını birinci sınıf desteklememesi de tuhaf
    • GitHub’dan kaçınmak için geçerli olan her neden, DigitalOcean App Platform ve Vercel’den kaçınmak için de geçerli
      DigitalOcean kullanıyorum ama sadece VPS için
      Böyle ara katmanlarda vendor lock-in yaşamamak, kontrolü elinde tutmak ve mümkün olduğunca evrensel stack katmanlarını hedeflemek gerekir
    • Benzer durumdayım
      Forgejo çatallanmasından yıllar önce Gitea’ya geçtim ve hiç pişman olmadım
      GitHub gerektiğinde depoyu oraya mirror’layıp çalıştırabildim. Yalnız kodu senkron tutmak zahmetli
    • Apple’ın Xcode Cloud’unda da benzer bir durum var
  • GitHub zorlanıyor çünkü yapay zeka destekli kodlama yüzünden son 1 yılda commit sayısı 14 kat arttı ve bu artışın hızı da hâlâ yükseliyor
    Site buna yetişmekte zorlanıyor
    GitHub COO’su bunu burada doğruluyor: https://x.com/kdaigle/status/2040164759836778878
    Platform etkinliği patlama yaşıyor. 2025’te 1 milyar commit vardı, şimdi ise haftada 275 milyon commit var; yani büyüme sadece doğrusal kalsa bile bu yılın temposu 14 milyar eder. Tabii muhtemelen doğrusal kalmayacak
    GitHub Actions, 2023’te haftada 500 milyon dakikadan 2025’te haftada 1 milyar dakikaya çıktı; bu hafta ise şu ana kadar şimdiden 2,1 milyar dakikaya ulaşmış durumda
    Bu yüzden daha fazla CPU, hizmet ölçekleme ve GitHub’ın temel işlevlerini güçlendirme için inanılmaz bir yüklenme içindeler