GitHub ve Yazılıma Karşı İşlenen Bir Suç

 (eblog.fly.dev)
1 puan yazan GN⁺ 22 시간 전 | 1 yorum | WhatsApp'ta paylaş
  • GitHub, geliştirme altyapısının çekirdeği gibi kullanılsa da sık yaşanan olaylar, yavaş sayfalar ve tarayıcı bozulmaları nedeniyle temel güvenilirliğinin sarsıldığı değerlendiriliyor
  • Microsoft, yükün agentic workflows nedeniyle keskin biçimde arttığını söyledi; ancak GitHub ve Copilot ile agent özelliklerini doğrudan ürüne iterek kullanımı teşvik ettiği yönündeki eleştiriler de büyüyor
  • En küçük depo deneyinde GitHub, 291 istek ile sıkıştırılmış 15MiB yanıt ve açılmış hâlde 544.564 satır indirirken, bu sonuç Codeberg’in 11 isteğiyle keskin bir tezat oluşturuyor
  • Ön uç ölçümlerinde GitHub’un normal heap kullanımı yaklaşık 69MiB, rust-lang pull request sayfasınınki ise 148MiB çıktı; bunun, metin ağırlıklı bir sayfa için aşırı israfçı olduğu değerlendiriliyor
  • Sonuç olarak GitHub’daki israfın basit bir ürün kötüleşmesi değil, kullanıcı sorunlarını çözmek yerine yapay zeka özellikleri ve yatırımcı odaklı öncelikleri öne koyan bir yazılım başarısızlığı olduğu savunuluyor

GitHub’un güvenilirliği ve öncelikleri

  • GitHub, yazılım geliştirme altyapısının çekirdeği gibi kullanılıyor; ancak kesintiler, performans düşüşleri ve tarayıcı uyumluluğu sorunları nedeniyle temel güvenilirliği sorgulanıyor
  • GitHub Status geçmişi her ay onlarca olay gösteriyor ve resmî durum sayfası ile SLA ölçütleri açısından bakıldığında ihlal sayılabilecek durumlar bulunuyor
  • Firefox ve Safari’de sık sık bozulduğu, pull request yorum ve inceleme sayfalarının yavaş olduğu, RAM kullanımı ve heap sıçramalarının aşırı düzeyde görüldüğü eleştirileri yapılıyor
  • GitHub Actions’ın yavaş olduğu, belgelerinin yetersiz kaldığı ve log ekranının yıllardır bellek sızıntıları ile tarayıcı çökmelerine yol açtığı öne sürülüyor
  • setup-go gibi temel action’ların önbellek davranışının da geçersiz kılma olmadan çalıştığı ya da aşırı derecede basit olduğu değerlendiriliyor
  • githubstars.com gibi yıldız satın alımını açıkça reklam eden siteler bulunduğu, ayrıca Carnegie Mellon makalesindeki “fake stars are highly related to malicious activities” ifadesinin alıntılandığı belirtiliyor
  • GitHub’un hedeflemesi gereken şey yüksek performanslı, yüksek erişilebilirlikli, yüksek kapasiteli dağıtık sistemler olsa da, gerçek ürünün temel güvenilirlikten çok yapay zeka özelliklerini ve agent akışlarını önceliklendirdiği değerlendiriliyor

“Agentic” yükü ve Microsoft’un sorumluluğu

  • GitHub, ‘an update on github availability’ başlıklı yazısında 2025’in ikinci yarısından itibaren agentic development workflows kullanımının hızla ivmelendiğini, depo oluşturma, pull request etkinliği, API kullanımı, otomasyon ve büyük depo iş yüklerinin hızlı biçimde arttığını söyledi
  • Bu açıklama yük artışını dışsal bir olgu gibi ele alıyor; ancak bunun GitHub ve ana şirketi Microsoft’un yapay zekayı ve “agents” özelliklerini birçok ürüne iterek kullanımı bizzat teşvik ettiği yönünde eleştirilmesine yol açtığı belirtiliyor
    • GitHub’daki neredeyse tüm sayfaların üst çubuğunda 3 yapay zeka düğmesi var ve bunların 2’si doğrudan agent başlatmaya ayrılmış durumda; birçok sayfada bu sayı 4’e çıkıyor
    • Sıradan bir depo açılış sayfasının sağ üst alanında Copilot’u başlatmanın 4 yolu bulunuyor
    • GitHub’un yıllardır araç kullanım maliyetini sübvanse ederek benimsemeyi teşvik ettiği, bunun da fiilen kendi kendine dağıtık hizmet reddi yükünü finanse etmekle aynı şey olduğu yönünde bir eleştiri bağlantısı veriliyor
  • Microsoft, tek bir pull request’in Git deposu, birleştirilebilirlik kontrolleri, branch protection, GitHub Actions, arama, bildirimler, yetkiler, webhooks, APIs, arka plan işleri, önbellekler ve veritabanlarını etkileyebileceğini açıklıyor
  • Büyük ölçekte küçük verimsizlikler bile kuyruk derinleşmesine, cache miss’lere, veritabanı yüküne, indeks gecikmelerine ve yeniden deneme trafiğinin büyümesine yol açabilir; ancak GitHub’daki verimsizliklerin “küçük” değil, devasa ve ezici olduğu savunuluyor
  • Microsoft, “availability first, then capacity, then new features” dedi; ancak GitHub genel changelog’unda bu güncellemeden sonraki 30 günde yama notlarında “copilot” 59 kez, “agent” 8 kez geçerken “performance” ve “reliability” hiç geçmiyor
    • changelog filtresinde ayrı bir copilot kategorisi var, ancak performance ve reliability kategorileri yok
    • Visual Studio Code’un da GitHub ve “agentic” işlevlerle doğrudan entegre olduğu, yerleşik terminal gibi temel özellikler kötüleşirken bile agent özelliklerinin eklenmeye devam ettiği eleştirisi yapılıyor
  • Microsoft’un “unnecessary work”ü azaltma, önbelleği iyileştirme, kritik servisleri yalıtma, tekil hata noktalarını kaldırma, performansa duyarlı yolları taşıma, gizli bağlılıkları azaltma, etki alanını sınırlama ve graceful degradation uygulama planlarını açıklaması, sistem tasarımının hatalı olduğunun kabulü olarak yorumlanıyor

Ön ucun arka uç sorunlarına işaret etmesinin nedeni

  • GitHub’un güvenilirlik sorunlarının kökü arka uç ve veritabanlarında olsa da bunlar dışarıdan görülemez; buna karşılık her seferinde indirilen HTML, JavaScript ve CSS gibi ön uç kodu gözlemlenebilir
  • Bir pizzacının oturma alanında fare görmenin mutfağın temiz olduğuna güvenmeyi zorlaştırması gibi, GitHub ön ucundaki görünür çürümenin arka uç sorunlarına işaret ettiği ama bunu kanıtlamadığı söyleniyor
  • GitHub, GitLab ve Codeberg depo açılış sayfaları; bağlantı listeleri, küçük UX öğeleri, düğmeler, sekmeler ve arama kutularından oluşuyor; etkileşimli medya ya da görseller gibi pahalı öğeler neredeyse hiç yok
  • Bu tür sayfaların iyi bir internet bağlantısı olmasa bile neredeyse her bilgisayar veya telefonda düşük maliyetle çalışması gerektiği, GitHub’un geçmişte iPhone 4 ve 3G bağlantıda gerçekten böyle çalıştığı belirtiliyor
  • İşlevler aynıysa en iyi kod, ağ bant genişliğini, CPU zamanını ve RAM’i en az kullanan, ayrıca en az hataya sahip kod olarak tanımlanıyor
  • Ön uçtaki hata sayısı doğrudan bilinemese de tarihsel araştırmalar, hata sayısının genellikle kod satırı sayısıyla orantılı olduğunu öne sürüyor
    • Steve McConnel, Code Complete, 2nd Ed (2004) teslim edilen yazılımlarda sektör ortalaması hata oranının 1000 kod satırı başına 1 ila 25 hata olduğunu aktarıyor
    • Microsoft Applications Division’ın dahili testlerde 1000 kod satırı başına 10 ila 20 kusur, yayımlanmış ürünlerde ise 1000 satır başına 0,5 kusur deneyimlediği aktarılıyor

Deney tasarımı ve veri toplama yöntemi

  • Karıştırıcı değişkenleri azaltmak için internet hızı “fast 3G” bağlantısıyla sınırlandırıldı
    • Bu ayar, ağ koşullarındaki dalgalanmaların etkisini azaltmak ve kırsal bölgeler gibi daha az ideal koşullardaki GitHub müşteri deneyimini simüle etmek için kullanıldı
  • Her üç hizmette de aynı en küçük depo olan ghsucks kullanıldı
    • tek branch master
    • tek dosya README.md
    • issue, etiket gibi ek öğe sayısı 0
  • Aynı tarayıcı ve aynı bilgisayar kullanıldı
    • Firefox
    • Apple Macbook Pro M5 Max
    • 48GiB RAM
  • Her hizmette dört sayfa incelendi
    • “landing” sayfası: kod yerleşimi
    • “pull requests” veya “merge requests” sayfası
    • “issues” sayfası
    • “settings” sayfası
  • Temiz önbellek durumunda HTTP Archive (HAR) toplanarak ağ istekleri analiz edildi; yükleme tamamlandıktan sonra ise heap snapshot alınarak durağan durum RAM kullanım tahmini elde edildi
  • HAR analizi için özel yazılmış anhar, sıkıştırma desteği analizi için testcompress, çapraz doğrulama içinse pagespeed.web.dev kullanıldı

Heap kullanımı ve bellek israfı

  • Varsayılan depo sayfasının heap kullanımı GitHub için 69MiB, GitLab için 68MiB, Codeberg için 14MiB, eblog.fly.dev için 1.3MiB olarak ölçüldü
  • https://github.com/rust-lang/rust/pulls adresindeki ilk issue sayfasını render etmek için 148MiB RAM kullanıldı
  • 148MiB, ilk iPhone’dan daha fazla bellek anlamına geliyor ve birkaç bağlantı içeren metin ağırlıklı bir sayfa için aşırı israf olarak değerlendiriliyor
  • Karşılaştırma için verilen cihaz bellekleri arasında Apple iphone 1 128MiB, iphone 4 512MiB, Sony playstation 2 32MiB ve Nintendo wii 88MiB yer alıyor

İstek sayısı ve yanıt boyutu karşılaştırması

  • anhar, HAR JSON’u parse eden, yanıtlardaki HTML·CSS·JavaScript içeriğini deno fmt ile otomatik biçimlendiren ve ardından istek·yanıt boyutları, MIME türüne göre toplamlar, yükleme süresi ve yanıt satır sayısını hesaplayan bir Go programıdır
  • Başlıca metrikler; istek boyutu, fiilen alınan küçültülmüş yanıt boyutu, deno fmt uygulandıktan sonraki genişletilmiş yanıt boyutu ve satır sayısı, temel HTML yükleme süresi olan Content-Load ve tüm içeriğin yüklenme süresi olan Load’dur
  • Codeberg depo sayfası toplamda 11 istek, 9KiB istek, 1MiB yanıt, 1MiB genişletilmiş yanıt, 3,480 genişletilmiş satır, 2.934s Content-Load ve 3.172s Load olarak ölçüldü
  • GitHub depo sayfası için 291 istek, 178KiB istek, 15MiB küçültülmüş yanıt, 22MiB genişletilmiş yanıt, 544,564 genişletilmiş satır, 843ms Content-Load ve 21.330s Load ölçüldü
    • application/javascript: 214 istek, 12MiB yanıt, 19MiB genişletilmiş yanıt, 481,849 genişletilmiş satır
    • text/css: 42 istek, 2MiB yanıt, 60,016 genişletilmiş satır
    • GitHub pulls: 266 istek, 14MiB küçültülmüş, 20MiB genişletilmiş, 487,922 genişletilmiş satır, 592ms Content-Load, 6.754s Load
    • GitHub settings: 255 istek, 14MiB küçültülmüş, 20MiB genişletilmiş, 486,067 genişletilmiş satır, 778ms Content-Load, 6.963s Load
  • GitLab, GitHub’dan daha küçük olsa da hâlâ ağır
    • GitLab deposu: 78 istek, 8MiB yanıt, 101,682 genişletilmiş satır, 6.880s Content-Load, 12.941s Load
    • GitLab merge_requests: 65 istek, 7MiB yanıt, 90,567 genişletilmiş satır, 6.947s Content-Load, 12.096s Load
    • GitLab edit: 117 istek, 7MiB yanıt, 71,916 genişletilmiş satır, 6.964s Content-Load, 13.302s Load
  • GitHub, boş bir depoyu göstermek için bile yaklaşık 540 bin satır kod ve veri indiriyor; bunun DOOM’un 35 bin satırı, Windows Quake’in 120 bin satırı, MS-DOS 4.0’ın 332 bin satırı ve Zig toolchain’in 460 bin satırından daha fazla olduğu karşılaştırması yapılıyor
  • Tek tek sayfaların 40 CSS dosyası ve yüzlerce JavaScript dosyası getiren yapısı sorun olarak değerlendiriliyor
  • Webpack’in chunk bölme yaklaşımı teoride çekirdek işlevlerle isteğe bağlı işlevleri ayırabilir ve cache·CDN açısından avantaj sağlayabilir, ancak burada her dosya için bağımsız HTTP isteği gerektirdiği ve bunun yüklemeyi yavaşlattığı şeklinde yorumlanıyor
  • Boş bir sayfayı görmek için 22 saniye beklemek kabul edilemez bulunuyor; 1GiB/s üzeri fiber bağlantı ve yüksek performanslı tüketici işlemcilerde bile bir deponun bir ölçüde kullanılabilir hâle gelmesi için 1 saniyeden fazla gerektiği değerlendiriliyor

Sıkıştırma desteği karşılaştırması

  • Sıkıştırma, istemci·sunucu·ara yol üzerindeki yükü azaltan faydalı bir yöntem olarak sunuluyor
  • gzip, kendini kanıtlamış bir sıkıştırma standardı olarak tüm web sitelerinin desteklemesi gereken bir teknoloji; zstd ise iyi performans özelliklerine sahip ama daha modern bir yaklaşım olduğundan desteği “olursa iyi olur” düzeyinde görülüyor
  • testcompress, URL’nin gzip ve zstd sıkıştırmasını destekleyip desteklemediğini test eden; destek yoksa yanıt gövdesini doğrudan sıkıştırarak potansiyel tasarrufu gösteren bir Go programıdır
  • eblog.fly.dev/startingsystems3.html: desteklenen encoding zstd gzip, özgün 575.77KiB, gzip 67.64KiB, zstd 60.17KiB
  • github.com/ef0xa/ghsucks: desteklenen encoding gzip, özgün 224.70KiB, gzip 43.27KiB, zstd 37.96KiB
  • gitlab.com/efronlicht/ghsucks: desteklenen encoding gzip, özgün 43.08KiB, gzip 11.48KiB, zstd 11.34KiB
  • codeberg.org/efronlicht/ghsucks: desteklenen encoding n/a, özgün 43.88KiB, gzip 13.00KiB, zstd 12.79KiB

PageSpeed mobil sonuçları

  • pagespeed.web.dev mobil ölçümünde Codeberg, First Contentful Paint 1.2s, Largest Contentful Paint 1.3s, Interaction to Next Paint 86ms ile PASS aldı
  • eblog.fly.dev, First Contentful Paint 1.1s, Largest Contentful Paint 1s, Interaction to Next Paint N/A ile PASS aldı
  • GitHub, First Contentful Paint 1.8s, Largest Contentful Paint 2.1s, Interaction to Next Paint 242ms ile FAIL aldı
  • GitLab, First Contentful Paint 2.1s, Largest Contentful Paint 2.4s, Interaction to Next Paint 243ms ile FAIL aldı

Hizmetlere göre değerlendirme

  • GitHub

    • Yaklaşık 300 dosya, kod ve veri olarak yaklaşık 550.000 satır getiriyor; tahmini hata sayısı da 550 olarak veriliyor
    • Content-Load yaklaşık 800ms, toplam Load yaklaşık 7s, kararlı durum heap kullanımı ise yaklaşık 69MiB olarak özetleniyor
    • gzip destekleniyor ancak zstd desteklenmiyor
    • Değerlendirme notu F; kod ağırlığının aşırı yüksek olduğu belirtiliyor
    • GitHub'ın, kullanılsın ya da kullanılmasın, tüm sayfalarda tüm temaları yüklediği eleştirisi yapılıyor
    • pagespeed.web.dev, JavaScript ve CSS'nin 528KiB'ının hiç kullanılmadığını gösterdiği için azaltmaya buradan başlanabileceği düşünülüyor
    • GitHub'da kalınacaksa, bunun GitHub'ın kendi SLA'sini ihlal ettiği değerlendirilerek geri ödeme almak için bir destek talebi gönderilmesi öneriliyor

  • GitLab

    • Content-Load yaklaşık 7s, Load yaklaşık 13s; 70'ten fazla dosyada 7MiB ve yaklaşık 10.000 satır getiriyor
    • Kararlı durum heap kullanımı yaklaşık 68MiB, gzip destekleniyor ancak zstd desteklenmiyor
    • Değerlendirme notu D+; GitHub kadar savurgan olmasa da çok fazla kaynak çektiği ve bunları düzgün kullanamadığı söyleniyor
    • 1MiB'den fazla JavaScript ve CSS getiriliyor ancak bunun bir kısmı gerçekte hiç kullanılmıyor; kullanılan kod tarafında da yalnızca parse edilmesi 255ms süren 3MiB'lık bir parça bulunuyor
    • Landing page için 55.000 satır CSS'e gerek olmadığı, hem CSS hem de JavaScript'in mevcut seviyenin onda birine kadar indirilebileceği düşünülüyor

  • Codeberg/Forgejo

    • Content-Load 2.9s, Load 3.1s; 11 dosyada 1MiB ve yaklaşık 1.100 satır getiriyor
    • Kararlı durum heap kullanımı yaklaşık 14MiB ve ne gzip ne de zstd destekleniyor
    • Değerlendirme notu C+; temel yeterlilik var ama ayrıntılara dikkat ve deneyim eksikliği olduğu belirtiliyor
    • HTML minify yapılmaması küçük bir sorun olarak görülürken, sıkıştırma desteğinin olmaması büyük bir eksiklik sayılıyor
    • JavaScript ve CSS'nin büyük kısmı sayfanın render edilmesi için gerekli değil, ancak render'ı engelleyecek şekilde yüklendikleri belirtiliyor
    • İstek sayısını azaltmak için JavaScript ve CSS yüklerinin birleştirilmesi, ayrıca HTML dahil HTTP yükleri için gzip ve zstd sıkıştırmasının desteklenmesi öneriliyor
    • Özgür yazılım olması nedeniyle başka bir instance'a ya da self-hosting'e taşınabilmesi avantaj olarak sunuluyor

  • eblog.fly.dev

    • eblog.fly.dev/startingsystems3.html, Content-Load 76ms, Load 1.1s, 5 dosya 766KiB, yaklaşık 3.800 satır olarak ölçülüyor
    • Tek bir HTML dosyası 576KiB boyutunda ve zstd ile yaklaşık 70KiB'a kadar sıkıştırılabiliyor
    • Kararlı durum heap kullanımı yaklaşık 11MiB ve hem zstd hem de gzip destekleniyor
    • Değerlendirme notu A-; genel olarak iyi bulunuyor ancak HTML'nin sıkıştırma hesaba katılsa bile şişkin ve tekrarlı olduğu, ayrıca tek istekte bitebilecek bir sayfanın 5 istek gerektirdiği belirtiliyor

Basit bir ürün bozulmasından değil, maliyet sorunundan söz ediliyor

  • “enshittification”, iyi bir ürünün önce kullanıcılar ve kurumsal müşteriler lehine başlayıp, sonra kullanıcıların aleyhine, ardından kurumsal müşterilerin de aleyhine değişerek sonunda işletmecinin lehine hale gelmesi süreci olarak özetleniyor
  • Microsoft ve GitHub'ın Embrace, Extend, Extinguish yaklaşımıyla ilgisiz olmadığı belirtilse de, buradaki farkın sorunun yalnızca kullanıcılar ve kurumsal müşteriler için değil, Microsoft için de maliyet üretmesi olduğu savunuluyor
  • Şişmiş bir kod tabanı, sunucu ve bant genişliği maliyetlerini doğrudan artırırken; kararsız ve hantallaşmış bir kod tabanını sürdürmek için mühendislik zamanını da dolaylı olarak tüketiyor
  • GitHub'da yaklaşık 800 mühendis olduğu ve kişi başı haftada 40 saat, yılda 48 hafta çalışıldığı varsayılırsa bu, yılda 1.536.000 mühendis-saat anlamına geliyor
  • Frontend sorunlarının büyük kısmının, yalnızca pagespeed önerilerine uyulsa bile, yetkin mühendisler tarafından bir hafta içinde düzeltilebileceği veya hafifletilebileceği düşünülüyor
  • Daha düşük seviyeli iyileştirmelerin maliyet azaltabileceği halde ihmal edilmesinin nedeni; ilgisizlik, aşırı yetersizlik ya da yapay zeka ve yatırımcı odaklı liderlik tarafından engellenme olarak yorumlanıyor
  • Yazılım, bir kez doğru yazıldığında kusursuz biçimde, sonsuza kadar ve ücretsiz olarak kopyalanıp herkes tarafından kullanılabilmesi nedeniyle güçlü ve güzel bir araç olarak tanımlanıyor
  • Sonuç olarak GitHub ve benzeri hizmetlerdeki savurganlık ve yetersizlik, sadece kötü bir ürün değil, yazılıma karşı işlenmiş bir suç olarak değerlendiriliyor

İlgili okumalar

1 yorum

 
GN⁺ 22 시간 전
Lobste.rs yorumları

  • Keşke bu karşılaştırmaya Trac ve Sourcehut da dahil edilseydi

  • Dört AI ajanı düğmesi komik, yazıda verilen göreli sayılar da ilginç, ama GitHub’ı savunmak gibi bir niyetim olmamasına rağmen yazının bazı ayrıntıları bağlamdan yoksun görünüyor ve yazarın tezini desteklemek için yeterli gelmiyor.
    Boştaki bellek kullanımının yüksek olması, GitHub’ın Codeberg’den daha fazla iş yaptığına işaret ediyor olabilir; ancak 48GB RAM’li bir bilgisayar üzerindeki mutlak RAM kullanımını Apollo Guidance Computer ile karşılaştırarak anlamlı bir sonuca varmak zor.
    Küçültülmüş JavaScript bundle’ını biçimlendirip satır sayısı tahmini yapmak ve bunu bağımlılıklar hariç bir Zig projesinin satır sayısıyla karşılaştırmak da elma ile armudu karşılaştırmak gibi. O zaman Zig çalıştırılabilir dosyasını tersine derleyip kaç satır çıktığına da bakın.
    Codeberg’in “istek sayısını azaltmak için JavaScript ve CSS payload’larını birleştirmesi gerektiği” tavsiyesini de anlamıyorum. HTTP isteklerinin “ek yükünden” söz edince yazarın HTTP/2’yi bilip bilmediğinden bile emin olamıyorum.
    Web sayfası performansı hakkında daha çok şey söylenebilir ama onu ayrı bir yazıya bırakayım; benzer bir konu için daha iyi bir bakış açısı olarak Danluu’nun 2017 tarihli web şişkinliği yazısını yeniden okumayı öneririm: https://danluu.com/web-bloat

  • Yazar bunu okuyorsa Casey Muratori ile Uncle Bob tartışmasına bakması iyi olabilir. İlki oldukça ilginç bir performans sorunu bulmuştu.
    “Kendimi tutamadım ve Chrome performans kaydına baktım; suçlunun kim olduğunu öğrendim :) ‘emoji picker’mış!”
    “Koda sadece üstünkörü baktım ama sorun şu gibi görünüyor: Her karakter girildiğinde ‘emoji picker’ geriye doğru gidip az önce yazdığınız şeyin emoji olup olmadığını kontrol ediyor.”
    Off. Yine de bu durumda suçlu GitHub frontend kodu değil, Chromium tabanlı tarayıcı da olabilir

  • “Codeberg bağımsız bağışlara dayanan ve özgür gönüllüler tarafından sunulan bir ürün” ifadesi doğru değil.
    Codeberg, üyelerine dayanıyor. Sadece aidat açısından değil, politika açısından da; ve şu anda aidatlar tam zamanlı çalışan istihdam etmeye yetmediği için gönüllülüğe büyük ölçüde bel bağlasa da, anladığım kadarıyla sözleşmeli çalışanlar da var.
    Codeberg’i çok yakından takip etmiyorum (sourcehut tarafını tercih ediyorum), ancak bir kooperatif olması değer önerisinin temel unsurlarından biri. Harcamalarını da şeffaf biçimde yayımlamaya çalışıyorlar. Örneğin: https://blog.codeberg.org/codebergs-budget-of-2026.html
    Codeberg kullanıyorsanız, şimdi üye olmayı düşünebilirsiniz: https://join.codeberg.org/

  • GitHub’dan gerçekten nefret ediyorum. Benim derdim uptime değil; aşırı yavaş olması ve çok bellek tüketmesi. “Bu boyuttaki diff varsayılan olarak gösterilmiyor” da ne demek, ciddi misiniz?
    Makul geliştirme akışlarında da bozuk. PR’ı rebase edince inceleme geri bildirimleri ve yorumlar kayboluyor, commit’leri squash edince de inceleme geri bildirimleri ve yorumlar kayboluyor.
    Belirli bir yoruma giden bir bağlantınız olsa bile ilgili commit ortadan kalkarsa yorum da onunla birlikte kayboluyor \o/
    Bir bug düzeltmesi varsa PR açmanızı istiyor; o bug başka bir değişiklikle düzeltilmiş olsa bile PR ile bug aynı düzeyde durduğu için ölü PR inceleme kuyruğunda sonsuza kadar kalıyor.
    Bu commit hangi bug’ı düzeltti diye bakmak isteseniz size sadece PR geçmişini gösteriyor. Sanki bug’a değil PR’a bakmanız gerekiyormuş gibi; bug’ı öğrenmek istiyorsanız gidip bug’ı kendiniz bulmalısınız.

    • “pull request” kavramının kendisi, git gibi, Linux çekirdeği geliştirmesinden geliyor. Akış, çekirdek bakımcısından yamaları ana dala “pull” etmesini istemek üzerine kurulu.
      GitHub bu akışı “fork” düğmesiyle daha kullanışlı hale getirdi, merkezi kullanıcı adları ekleyerek daha “sosyal” yaptı, ardından issue tracker ve wiki ekleyip dünyayı ele geçirdi. Ticari açıdan bakınca gerçekten dahiyaneydi.
      Ama bütün akış hâlâ birbirinden ayrı insanların yamalarının “pull” edilmesini istediği açık kaynak geliştirmesine göre tasarlanmış durumda.
      Gerçek mekanizması “branch’i tartış ve merge’i onayla” olan sıkı çalışan bir geliştirme ekibinin neden “pull request” kullanması gerektiğini anlamıyorum. Neyi nereden pull ediyoruz? Aynı repo içindeyiz, değişiklikleri zaten push etmişiz.
      Terminolojiyi bir kenara bıraksak bile biriken değişiklikler, kalıcı yorumlar ve değişiklik seti diff’lerinin eksikliği saçma.
      Yine sıkıcı bir GitHub yakınması yaptığım için kusura bakmayın. Daha iyi bir alternatif var mı? Elbette insanları onu kullanmaya zorlayamazsınız ama…

  • “Eksen etiketleri veya tek tek veri noktaları olmayan grafikler her zaman şüphelidir” tepkisini GitHub’ın yayımladığı grafikler için birkaç kez gördüm.
    Grafikte en yüksek değerler gösterildiğinden, y ekseninin orta noktalarının görsel olarak sırasıyla yaklaşık 45M, 0.7B ve 10M olduğunu tahmin edebilirsiniz. Tabii gizlice log ölçeği kullanmıyor ve yük 100000 kat artmamışsa.
    Buradaki kötü grafikleri “şüpheli” diye nitelendirmezdim; bana daha çok zayıf iletişim gibi geliyor. Kişisel olarak ham ggplot çıktıları bana hep daha iyi gelir.
    Genel havaya katılıyorum ama şişman at ve çok sayıdaki tablo kısmında biraz koptum. Yine de GitHub’ın tüm kusurlarını listeleyen ben olsaydım muhtemelen ben de çıldırıp şişman bir ata binerek gün batımına doğru kaybolduğumu hayal etmeye başlardım.
    Ben de benzer şekilde listelemeye başlamış, UX/performance sorunları yaklaşık 12 maddeye ulaşınca bırakmıştım. Yazının bu kadar kapsamlı olması güzel; umarım GitHub ekibi bunu gerçekten didik didik inceler.
    Daha önce söylediğim gibi Microsoft, GitHub’a biraz performans mühendisi ayırmalı. Temel performans göstergeleri gerçekten KPI’ların parçası olana kadar bu şişkinlik devam edecek ve diğer platformlar daha cazip görünecek. Bir sonraki GitHub CEO’su olursa umarım buna öncelik verir.

    • Y ekseninin 0’dan başladığını varsayıyorsunuz. Oysa bu tür iş dünyası tarzı grafiklerde durum çoğu zaman böyle değildir.
      “Muazzam büyüme” diye sunulurken çizginin tüm grafiği çapraz geçtiği ama y ekseninin aslında sadece 100’den 101’e gittiği grafikler çok yaygındır.

  • “GitHub Actions logları bellek sızdırdığı için yıllardır tarayıcımı çökertiyor ve stdout’u başka bir yere basitçe pipe etmenin hâlâ bir yolu yok” sözlerine katılıyorum.
    Ne yazık ki Forgejo da bunu miras almış. Bazen başarısız build bildirimi alıp telefondan hızlıca bakmak istiyorum ama birçok durumda telefon tarayıcısı çıktıyı hiç yükleyemiyor.

  • Bu başlığa tıkladığımda GitHub uptime’ı hakkında bir şikâyet daha olacağını tamamen bekliyordum, ama bunun yerine GitHub, GitLab ve Codeberg’in mevcut sorunlarını sakin ve makul biçimde değerlendirip çözümler de öneren bir yazı çıkınca hoş bir sürpriz oldu.
    Keşke Tangled da karşılaştırmaya dahil edilseydi.
    Yazarın, sitenin mobilde de okunabilmesi için biraz CSS yazması iyi olurmuş. Tarayıcının okuma modunu kullanmak zorunda kaldım.
    Katılmadığım tek nokta, hiçbir sitenin birden fazla JavaScript/CSS dosyası yüklememesi gerektiği iddiası.
    O 550 bin satır JavaScript tek dosyada olsaydı parse ve execution çok daha uzun sürerdi. CSS bundling yapılabilir ama örneğin bir ortak chunk ve rota başına bir chunk kullanma deseni faydalı olabilir. Bu yaklaşım ya da benzerleri muhtemelen yaygın olarak kullanılmaya devam edecek.

  • Bu sayfa okunamıyor.
    Ayrıca GitHub’dan nefret ediyorsanız kullanmayın. İnsanların bu kadar uzun şikâyet listeleri derlemeye zaman bulmasına şaşırıyorum. Para karşılığı kullanıyorlardır ya da başka bir şey kullanabilirler.