GitHub'dan Dillo Projesinin Taşınması

 (dillo-browser.org)
2 puan yazan GN⁺ 2025-12-01 | 1 yorum | WhatsApp'ta paylaş
  • Web tarayıcısı Dillo projesi, GitHub'dan kendi barındırdığı bir sunucuya taşınıyor
  • GitHub'un JavaScript bağımlılığı, tekil kontrol yapısı ve yavaş performansının ana geçiş nedenleri olarak sunulduğu belirtiliyor
  • Yeni sunucu dillo-browser.org alan adında çalışacak ve cgit tabanlı hafif bir Git ön ucu ile kendi geliştirdikleri hata takipçisi ‘buggy’ kullanılacak
  • Tüm veriler Git deposu olarak yönetilerek Codeberg ve Sourcehut’a yansıtılıyor, böylece veri kaybı riski en aza indiriliyor
  • OpenPGP imzası ile DNS kaybında bile güvenilirlik korunabiliyor; bu da projenin bağımsızlığını ve sürekliliğini güçlendiriyor

Arka Plan

  • Dillo'nun önceki ana sitesi dillo.org idi; içinde Mercurial deposu, e-posta sunucusu, hata takipçisi ve e-posta listesi arşivi bulunuyordu
    • 2022 yılında alan adı kaybedildi ve üçüncü bir taraf tarafından yapay zeka reklamlarıyla dolu bir taklit site açıldı
    • Bazı materyaller kurtarıldı ancak tam olarak geri getirilemedi
  • Bu deneyim nedeniyle, tek bir siteye bağımlılıktan kaçınmak ve dağıtık bir yedekleme yapısı kurmak kararlaştırıldı
  • Başlangıçta kodlar GitHub’a yüklendi, ancak uzun vadede uygun olmadığına karar verildi

GitHub'ın Sorunları

  • GitHub, CI iş akışları ve depo yönetiminde kullanışlı olsa da, birçok sınırlaması vardı
    • JavaScript olmadan ön yüz çalışmıyor, bu nedenle Dillo tarayıcısı ile issue ve PR’ler görüntülenemiyordu
    • Sayfalar aşırı kaynak tüketiyor, basit HTML render için gereksiz yük oluşturuyordu
  • Hesabın tek bir kontrol birimi tarafından kilitlenme riski nedeniyle erişim engellenebilir
  • Platform giderek yavaşlıyor ve daha hızlı internet bağlantısı gerektiriyor
  • GitHub’ın “push modeli” bildirim sistemi, çevrimdışı odaklı geliştirme yaklaşımıyla uyumlu değil
  • Geliştirici olmayan kullanıcı oranı yüksek projelerde topluluk yönetimi araçlarının eksikliği, geliştirici yorgunluğunu artırıyor
  • GitHub, LLM ve üretken yapay zeka odaklı bir yapıya kaydıkça siteler LLM tarayıcılarını engellemek için JavaScript duvarı ya da tarayıcı parmak izi takibi gibi yöntemleri güçlendirmeye başladı
    • Bunun sonucunda Dillo kullanıcı erişimi engellenen yan etkiler oluştu
    Reklam

Kendi Barındırma Altyapısı Kurulumu

  • Mevcut depo hizmetleri, tek arıza noktasını ortadan kaldırma ile hafif çalıştırma ihtiyaçlarını aynı anda karşılayamıyordu
    • Bu nedenle doğrudan sunucu işletmeye ve birden fazla yansıyı korumaya karar verildi
  • dillo-browser.org alan adı satın alındı ve küçük bir VPS kuruldu
    • Beklenenden daha stabil çalışıyor ve çoğunlukla yapay zeka bot trafiğini işliyor
  • Git ön ucu olarak cgit seçildi
    • C dilinde yazıldığı için RAM ve CPU kullanımı düşük ve JavaScript olmadan çalışıyor
    • Dillo’da düzgün görünmesi için CSS’de bazı düzenlemeler yapıldı
    • https://git.dillo-browser.org/ adresinden erişilebiliyor
  • Hata takip sistemi olarak doğrudan geliştirilen ‘buggy’ kullanıldı
    • Markdown dosyaları ayrıştırılarak HTML sayfalar oluşturuluyor, her hata Git deposunda saklanıyor
    • Commit sırasında git hook’u sayfaları otomatik olarak güncelliyor
    • Çevrimdışı düzenleme mümkün, güvenlik açığı endişesi bulunmuyor
    • https://bug.dillo-browser.org/ adresinden erişilebilir
    Reklam
  • E-posta listesi arşivi 3 farklı dış hizmette dağıtılmış durumda; ileride kendi kopyası da eklenecek

Yansılama (Mirror) Ayarları

  • Tüm temel veriler Git deposu biçiminde tutuluyor ve Codeberg ile Sourcehut üzerinde yansıtılıyor
    • Belirli bir depo durdurulsa bile, düşük geçiş maliyetiyle başka bir yansıma ile devam edilebilir
  • Tek arıza noktası DNS (dillo-browser.org)
    • DNS kaybı durumunda e-posta listesi, Fediverse ve IRC üzerinden kullanıcılara bildirim yapılabilir
    • Veriler Git’te çoğaltıldığı için felaket boyutunda kayıp yaşanmaz

OpenPGP İmzası

  • Bu sayfa, Rodrigo Arias Mallo’nun GPG anahtarı (32E65EC501A1B6FDF8190D293EE6BA977EB2A253) ile imzalanmış
    • Dillo’nun en son sürümüyle aynı anahtardır ve GitHub hesabına da kayıtlıdır
    • İmza dosyası (index.html.asc), <link rel=signature> ile bağlanır
    Reklam
  • OpenPGP imzası, DNS kaybında bile güvenin sürdürülmesini sağlar
    • TLS sertifika zinciri yerine imza güvenine dayalı sahiplik kanıtı
    • Tüm Git yansılarında imzanın bulunması, veri kaybına karşı dayanıklılığı artırıyor

Geçişin İlerleyişi ve Görünümü

  • GitHub deposu hemen silinmiyor, geçiş tamamlanana kadar güncellemeler devam edecek
    • Tamamlandıktan sonra depo ‘archived’ (arşivlenmiş) duruma alınacak ve resmi sitede duyuru yapılacak
    • Mevcut commit’ler ve yayın dosyaları, eski yapı uyumluluğu için korunacak
  • Yeni altyapı düşük maliyet ve düşük enerji tüketimiyle bağımsız şekilde çalışabiliyor
    • Mevcut bağış ve sunucu maliyeti hesaplarıyla en az 3 yıl sürdürülebilir
    • Destek olmak isterseniz Liberapay üzerinden bağış yapabilirsiniz (https://liberapay.com/dillo/)

İlgili okumalar

1 yorum

 
GN⁺ 2025-12-01
Hacker News yorumu

  • Yıllardır GitLab’ı self-hosted bir alternatif olarak kullanıyorum. Hoşuma gidiyor ama kaynak tüketimi çok yüksek
    Son zamanlarda Codeberg ekibinin yaptığı Forgejo’yu test ediyorum ve gerçekten harika
    En büyük fark bellek kullanımı. GitLab Ruby on Rails tabanlı olduğu için aynı anda birden fazla servis çalışıyor, ama Forgejo Go ile yazılmış tek bir binary yapısına sahip
    GitLab 16GB’lık VM’in belleğini giderek tamamen tüketiyor, ama Forgejo sunucu ve runner birlikte çalışsa bile yaklaşık 300MB kullanıyor
    GraphQL yok ama REST API yeterince iyi görünüyor
    gitea ile forgejo arasındaki farkı tam bilmiyorum, ama Forgejo karşılaştırma belgesine bakınca 2022’de yönetişim sorunları nedeniyle bir soft fork olarak ayrılmış gibi görünüyor

    • Bizim stüdyo yaklaşık 50 kullanıcının her gün git kullandığı bir yer ve 2 yıl önce tamamen Forgejo’ya geçtik
      Go tabanlı basit yapı sayesinde bakım ve maliyet çok düşük. Dahili araçlarımızı da doğrudan Forgejo üzerine kurduk
      On-premise barındırma sayesinde internet kesilse bile geliştirme ve CI durmuyor. Paket yöneticisi cache desteği de olduğu için bağımlılık yönetimi kolaylaşıyor
    • Bakım kolaylığı açısından gitea açık ara önde. 5 yılı aşkın süredir kullanıyorum ve yükseltme işi yeni sürümü pull edip daemon’u yeniden başlatmakla bitiyor
      GitHub’dan 10 kat daha az downtime yaşadı; bunun da çoğu planlı bakımdaydı
      GitHub’ın erişilebilirliğinin daha iyi olduğunu iddia eden yazıları görünce gülüyorum
    • Kişisel projeler için sadece bir SSH sunucusu ve dosya sistemi yeterli diye düşünüyorum
      Yeni depo oluştururken iş git init --bare ile bitiyor, yedekler de otomatik dönüyor
      Tek başına geliştiriyorsanız UI’a gerçekten gerek olmadığını hissediyorum
    • Forgejo Actions temel kavramlar belgesi CI sisteminin iyi düzenlendiğini gösteriyor
      Bence GitLab tarzı CI, GitHub Actions’tan çok daha iyi; GitHub popülerliği sayesinde standart oldu ama tasarımı hayal kırıklığı yaratıyor
    • Daha minimal bir alternatif istiyorsanız Gerrit de var. Java uygulaması ama harici DB bağımlılığı yok ve yapılandırma ile çalışma zamanı bilgilerini git repo’sunda saklıyor
      Paylaşımlı dosya sistemiyle bile ölçekleme ve yedekleme kolay

  • Bölgemde bir matematik kulübü yürütüyorum ve çocuklar LaTeX ve Python ödevlerini teslim ederken Forgejo kullanıyor
    Giriş yönetimi ve parola sıfırlama kolay olduğu için eğitim amaçlı kullanımda da çok faydalı

  • GitHub’ın push bildirim modelinden hoşlanmıyorum; güncellemeleri sadece kendim kontrol ettiğimde görmek isteme fikrine katılıyorum
    E-posta filtreleme kullanırsanız push bildirimlerini pull modeline benzer hâle getirebilirsiniz. Bildirimleri özel bir klasörde toplar, ihtiyaç olduğunda bakarsınız

    • Yine de tatmin etmiyorsa GitHub arayüzünün kendi bildirim özelliğini kullanabilirsiniz. Açıkçası bu biraz sorun bulmak için sorun üretmek gibi geliyor

  • Basit bir ‘buggy’ hata takip sistemini kendisi yapan kişinin anlattıkları ilginçti. Markdown parse edip HTML sayfaları üreten bir C aracıymış
    Hacker ruhu yaşıyor

    • Ama böyle bir yaklaşımı neredeyse kimsenin tercih etmeyeceğini düşünüyorum. Ben olsam bana daha çok sorun çıkarırdı
    • Artıları da eksileri de olan bir yaklaşım

  • “Push model” ile “pull model” arasındaki farkı soran bir soru vardı

    • Sanırım Source Hut veya Linux kernel gibi e-posta tabanlı workflow’lardan söz ediliyor. IMAP ile patch’leri yerelde çekip çevrimdışıyken de çalışabilirsiniz
    • Push, “hemen şimdi yap” türünden bir zaman baskısı yaratıyor; pull ise benim belirlediğim aralıkta kontrol etmeye dayalı bir zaman yönetimi farkı

  • Şu an birçok GitHub alternatifinin ortaya çıktığı bir diaspora aşamasında olduğumuzu düşünüyorum
    Birkaç ay içinde ana akımın tek bir seçenek etrafında toparlanması da mümkün. Tanınmış bir şirket ya da kişi yeni bir platform çıkarırsa pazarı yönlendirebilir

    • Bu akım aslında 10 yıl önce de vardı. O zamanlar GitLab’a geçiş dönemi yaşanıyordu ve bugün bile GitHub’ın keşfedilebilirliği (discoverability) hâlâ rakipsiz
      GitHub’dan ayrılan projeler çok az olduğu için bunun için hâlâ erken olduğunu düşünüyorum
    • Geliştiricilerin işbirliği yöntemleri farklı olduğu için tek bir çözüme yakınsamak zor
      Hatta tam tersine bir yeniden merkezsizlikten çıkış (re-decentralization) yaşanıyor. Herkesin kendi kontrol, yargı alanı ve workflow ihtiyaçlarına uygun forge’u seçtiği bir dönemdeyiz
    • Gelecekte hedef GitHub gibi merkezi değil, federation temelli bir yapıya geçmek. Böylece tek bir varlığa bağımlı kalınmaz
    • Esas mesele “tek bir alternatif” isteyip istemediğiniz ya da 5 yıl sonra aynı durumu tekrar yaşamak isteyip istemediğiniz
    • Biz tam olarak bunu deniyoruz. Tangled adında indie odaklı bir işbirliği platformu hazırlıyoruz ve yakında büyük bir duyurumuz olacak

  • Dillo projesini Tangled’a davet etmek isterim → tangled.org

    • JavaScript olmadan da gayet iyi çalışması etkileyici
    • Git dışındaki sürüm kontrol sistemlerini de desteklese iyi olurdu

  • GitHub’ın giderek yavaşlayan kullanılabilirliği en büyük sorun bence

    • “more and more slow” ifadesinin doğal olup olmadığını merak ediyorum. “slower and slower” daha mı yaygın?
    • Eskiden iyiydi ama son dönemde sayfa yüklemeleri aşırı yavaş. Bunun tek nedeni React gibi görünmüyor
      Kod gezintisini github.dev ile çözüyorum ama PR ve Actions hâlâ yavaş ve bunaltıcı

  • VM’e Forgejo kurmak istiyorsanız, sunucu ile runner’ı tek seferde ayarlayan bir script hazırladım → easyforgejo

  • Bu konuda uzman değilim ama ilgiyle okudum
    Tek bir sürüm kontrol sistemi kurarken bu kadar çok unsur olması şaşırtıcı
    Ben Fossil kullanıyorum ve küçük ölçekli bir organizasyonda geliştirici, sistem yöneticisi ve destek sorumlusu rollerini tek başıma üstleniyorsam çok daha basit geliyor
    GitHub’ın deploy key kısıtları da rahatsız edici. Birden fazla uygulama ve sunucu işletirken anahtarları ayrı ayrı ayarlamak zorunda kalmak uğraştırıcı