1 puan yazan GN⁺ 2025-05-30 | 1 yorum | WhatsApp'ta paylaş
  • Compiler Explorer, paylaşılan bağlantıların uzun süre yaşaması için 2012’den beri depolama biçimini değiştirdi; ancak goo.gl’nin kapanması, geçmişteki godbolt.org/g/abc123 bağlantılarını korumayı acil hale getirdi
  • Başta tüm derleyici durumunu URL’ye koyuyordu; 2014’te Google URL kısaltma servisini ekledi, 2016’da Stack Overflow’un kısa URL yasağından sonra godbolt.org/g/abc123 yönlendirme bağlantılarını oluşturdu
  • URL uzunluğu sınırının daha büyük bir sorun haline geldiği 2018’den itibaren durumu S3’te JSON belgeleri olarak saklayan ve kısa hash ile tam yol eşlemesini DynamoDB ile yöneten kendi yöntemine geçti
  • Google, goo.gl bağlantılarını Ağustos 2025’te kapattığında mevcut goo.gl tabanlı bağlantıları çözümlemek zorlaşacağından, açık web ve loglarda bulunan yaklaşık 12.000 g bağlantısını ve yönlendirme hedeflerini kendi veritabanında topluyor
  • Eski Compiler Explorer bağlantıları olan kullanıcılar bu bağlantıları şimdi ziyaret ederse koruma listesine girme olasılığı artar; uzun süre kalması gereken paylaşılan bilgi, temel altyapı doğrudan sahiplenildiğinde daha güvenlidir

Compiler Explorer bağlantı depolama yönteminin değişimi

  • 2012’de Compiler Explorer tüm durumunu URL’nin içinde saklıyordu
  • Tüm derleyici durumunu URL’ye kodlama yöntemi uzunluk nedeniyle yönetilmesi zor hale geldi ve Mart 2014’te Google’ın goo.gl kısa URL desteği eklendi
  • O dönemde kısa bağlantılar goo.gl/abc123 biçimindeydi; tıklandığında Compiler Explorer sitesindeki tam URL’ye yönlendiriliyor, ardından URL içindeki durum çözümleniyordu

Stack Overflow yasağından sonraki dolaylı bağlantılar

  • 2016’da Stack Overflow, gerçek hedefi gizleyebildiği gerekçesiyle bağlantı kısaltma servislerini yasakladı
  • Bu adım Compiler Explorer bağlantılarını da etkiledi; o dönemde kullanıcı verilerini doğrudan saklama niyeti yoktu
  • Çözüm, goo.gl’yi kullanmaya devam edip kullanıcılara godbolt.org/g/abc123 biçiminde bağlantılar sunmaktı
    • abc123, goo.gl’nin benzersiz ID’siydi
    • /g/abc123 erişimi goo.gl/abc123 adresine yönlendiriliyordu
    • goo.gl de tekrar durumu içeren tam godbolt.org URL’sine yönlendiriyordu
  • Daha sonra, birden fazla adımdan oluşan yönlendirme zincirinden kaçınmak için Google API kullanıldı

2018’de kendi depolama sistemine geçiş

  • 2018’de URL uzunluğu sınırı daha büyük bir sorun haline geldi ve URL içindeki veriler zaten sıkıştırılıyordu
  • Compiler Explorer, durumu doğrudan saklayan bir yapıya geçti
    • Girdi hash’leniyor
    • Durum S3 üzerinde JSON belgesi olarak saklanıyor
    • Hash’in kısa biçimi godbolt.org/z/hashbit URL’si olarak sunuluyor
    • Kısa hash ile tam yolun eşlemesi DynamoDB ile saklanıyor
  • Kısa bağlantı hash’inde rahatsız edici kelimeler olup olmadığı da kontrol ediliyor
    • Rahatsız edici bir kelime çıkarsa farklı bir hash oluşması için belgeye kasıtlı olarak ek bilgi konuyor
    • Bu davranış bug #1297 ile sonuçlandı

goo.gl’nin kapanmasının yarattığı koruma sorunu

  • Compiler Explorer hâlâ godbolt.org/g/abc123 bağlantılarını destekliyor
  • Google, mevcut bağlantıların amaçlanan hedefe yönlendirilmeye devam edeceğini söylemişti; ancak goo.gl birkaç yıl önce salt okunur hale geldi ve Ağustos 2025’te tamamen kapatılması planlanıyor
  • Kapanıştan sonra goo.gl tabanlı bağlantılar artık çözümlenemeyecek
  • Gerçek goo.gl bağlantılarının kendisi Compiler Explorer tarafında çözülemez; ancak godbolt.org/g/abc123 bağlantıları kendi veritabanıyla korunabilir

Mevcut bağlantıların toplanması ve kendi veritabanı

  • Son birkaç gündür herkese açık çeşitli kaynaklardan mevcut bağlantılar ve onların yönlendirme hedef URL’leri toplanıyor
  • Şimdiye kadar yaklaşık 12.000 bağlantı bulundu
    • Google web arama API’si
    • GitHub API’si
    • Kendi web logları
    • archive.org üzerindeki Stack Overflow veri dökümü
    • Archive.org’un arşivlediği web sayfası listeleri
  • İçeride goo.gl yerine kendi veritabanını önceliklendirecek şekilde değişiklik yapıldı
  • Veritabanında henüz olmayan yeni g bağlantıları da izleniyor
  • Yerelde bir sqlite veritabanı, production tarafında ise Dynamo kullanılıyor

Kullanıcıların yardımcı olmak için yapabilecekleri

  • Eski godbolt.org/g/abc123 bağlantılarını ayrıca saklıyorsanız, şimdi her bir bağlantıyı ziyaret etmeniz yardımcı olur
  • Bağlantı ziyaret edildiğinde web loglarına düşer ve daha sonra veritabanına eklenebilir
  • Aksi halde Ağustos 2025’ten sonra ilgili bağlantı çalışmayabilir
  • Bu örnek, önemli altyapıyı üçüncü taraf servislere bağımlı kılmanın riskini gösteriyor
  • “Sonsuza kadar süren URL” vaadini tutmak için tüm yığına doğrudan sahip olmak gerekir

1 yorum

 
GN⁺ 2025-05-30
Hacker News yorumları
  • 2010’dan önce linklerin sonsuza kadar kalıcı olduğuna doğal olarak inanır, tarayıcı yer imlerini çok kullanırdım
    Sonradan yer imlerimin epeyce bir kısmının link çürümesi yüzünden fiilen kullanılamaz hale geldiğini fark ettim; ondan sonra web sayfalarını PDF olarak yazdırıp saklamaya başladım
    Okuyucu görünümü özelliği oldukça istikrarlı biçimde yaygınlaştıktan sonra da, okuyucu görünümündeki içeriği kopyalayıp RTF dosyası olarak kaydetme yöntemine geçtim

    • Ziyaret ettiğim her sayfayı arşivlemek için SingleFile eklentisini kullanıyorum
      Ayarlaması kolay, ama çok disk alanı yediğine dikkat etmek gerek

      $ du -h ~/archive/webpages
      1.1T /home/andrew/archive/webpages

      https://github.com/gildas-lormeau/SingleFile

    • Resmî Web Archive tarayıcı eklentisini kurarsanız, ziyaret ettiğiniz her sayfayı otomatik arşivleyecek şekilde ayarlayabilirsiniz

    • Benim çözümüm, önemli içeriğin kendisini hatırlamak ya da en azından nerede bulabileceğimi hatırlamak yönündeydi
      Henüz ölmediğime göre çalışıyor sayılır

    • Bir link zaman aşımına uğradığında otomatik olarak web.archive.org’a giden bir tarayıcı eklentisi var mı merak ediyorum

    • Tarayıcıların bu gerçeği hâlâ yansıtıp yer imi özelliğini düzeltmemiş olması gerçekten akıl alır gibi değil
      Her yer imi yalnızca linki değil, render edilmiş sayfanın tamamının bir kopyasını da saklamalı. Artık var olmayabilecek dinamik içeriğe bağımlı olan ham kaynak kodunu saklamakla yetinmemeli

      Açık sekmeler de aynı şekilde olmalı. İnternet bağlantısı yokken bir sekmeye geri döndüğümde, tarayıcı o sekmeyi nazikçe bellekten attı diye ağ hatası görmek istemiyorum
      Bu durumda ben elle yenileyene kadar durum ağdan değil diskten yeniden yüklenmeli

  • Goo.gl için ArchiveTeam projesi[1] ile işbirliği yapmaya değer
    “URL kısaltma gerçekten berbat bir fikirdi”[2]

    [1] https://wiki.archiveteam.org/index.php/Goo.gl

    [2] https://wiki.archiveteam.org/index.php/URLTeam

    • Doğru hatırlıyorsam ArchiveTeam ‘bilinen’ linkleri takip etmiyordu; Goo.gl kısa URL’lerini brute-force ediyordu
      Bu yüzden Compiler Explorer URL’lerinin önemli bir kısmına, hatta tamamına sahip olma ihtimalleri yüksek; iletişime geçmek iyi olur gibi görünüyor
    • Projenin canlı durumuna bakınca 42 milyar goo.gl URL tarayıp 7,5 milyarını bulmuş durumdalar: https://tracker.archiveteam.org:1338/status
  • URL’lerin sonsuza kadar kalıcı olması güzel bir hayaldi, ama gerçekte URL’lerin %99’u kalıcı değil gibi görünüyor
    Sürekli kaybedilen bir savaş vermek yerine, teknolojiyi altyapının kalıcı olmadığı varsayımı üzerine kurmamız gerekebilir

    • Evet. Ayrıca URL kısaltma servislerini altyapı olarak kullanmamak da gerekiyor

    • URN, nesnenin kimliğini konumundan ayırarak bu sorunu çözmeye çalışıyordu
      Ama yaygınlaşamadı; sonrasında link kısaltma servisleri bu fikri berbat biçimde yeniden uyguladı

      https://en.m.wikipedia.org/wiki/Uniform_Resource_Name

    • Alan adlarının sahipleri sık sık değişir; sonsuza kadar kalıcı olması gereken URL’ler bile zamanla kötü amaçlı phishing linklerine dönüşebilir

    • URL, ağ üzerindeki bir kaynağın konumunu tanımlar; kaynağın kendisini tanımlamaz, dolayısıyla kalıcı ya da benzersiz olmak zorunda değildir
      Zaten adı da bu yüzden “uniform resource locator”

      Bu sorun 1997’de zaten fark edilmişti; Digital Object Identifier da bu yüzden oluşturuldu

  • Link kısaltma servislerini veritabanı gibi kötüye kullanıp, sonra özgün referansları kaybederek internetin dört bir yanından değerli linkleri geri toplamaya çalışmakta şiirsel bir yan var

    • Uzun URL’leri kısaltmak, URL kısaltma servislerinin amaçlanan kullanım senaryosu
      Asıl kötüye kullananlar, dolandırıcılık, spam ve yasa dışı web sitelerini ortak bir alan adının arkasına saklayıp her yere yayan kişiler
    • Sadece URL’yi sıkıştırmak için link kısaltma servisi kullanmışlar gibi değil mi
      Veritabanı gibi kullanılan şey kısa URL değil, kendi URL’leri; yani derleyici durumunu barındıran kısım gibi görünüyor
  • https://killedbygoogle.com/

    “Google Go Links (2010–2021)”

    “Yaklaşık 4 yıl önce kapatıldı. Google Short Links olarak da biliniyordu ve bir URL kısaltma servisiydi. Google Workspace müşterileri için özel alan adlarını da destekliyordu. Yaklaşık 11 yıllık bir servisti”

    • Yeni link oluşturmayı durdurmak anlamında bir servisi “öldürmek” pek de önemli bir şey değil ve özellikle anmaya bile değmez
      Ama mevcut linkleri de kırmak çok daha kötü bir davranış. Özellikle Google bunu kendi uygulamaları içinde bir şekilde hâlâ sürdürüyor ise
  • Google’ın salt okunur sürümü bile kapatmaya değecek kadar uğraş gerektirdiğini düşünmesi biraz şaşırtıcı
    Tabii internette kalan gizli link yönlendirmeleri yüzünden hukuki risklerden endişe etmiyorlarsa

    • Dışarıdan bilmek zor, ama servis artık işletmek istemedikleri eski ya da güvensiz kütüphanelere, runtime’lara, servislere vb. bağımlı olabilir
      Açıkçası maliyet önemsiz olsa bile hâlâ net bir maliyet; bu yüzden sempatiyi ya da geçmiş vaatleri bir kenara bırakıp doğrudan kesmeleri de benzer ölçüde olası görünüyor
  • “Bu yazı bir insan tarafından yazıldı, ancak link önerileri ve dilbilgisi denetimi bir LLM tarafından yapıldı”

    Bugün böyle bir LLM kullanım bildirimi gördüğüm ikinci kez. Yeni bir trendin başladığını izliyor gibiyim

    • İnsanların böyle bir bildirim koymaları gerektiğini hissetmesi garip
    • Böyle bir bildirimin hiç gerekli olduğunu düşünmüyorum
      İçerik kendi başına ayakta durabiliyorsa yeterli. İçerik çöplükse, bunun yapay zekanın ürettiği çöp mü yoksa insanın ürettiği çöp mü olduğu neden önemli olsun?

Birinin bildirim istemesinin ya da bunu bilmek istemesinin tek nedeni, içeriğin kalitesini kendi başına ayırt edemeyip yapay zeka üretimi olup olmadığını düşük kalite için vekil bir gösterge olarak kullanmasıdır.

  • Söylemek istemem ama çok sağlam finanse edilen bir vakıf işin içinde olmadığı sürece Compiler Explorer ve godbolt.org da sonsuza dek var olmayacak
    O zamana gelindiğinde tüm bilgiler, 487 kentilyon parametreli bir her şey modelinin içine damıtılmış olabilir

    • Şimdiye kadar epey iyi idare ettik. Bu hafta itibarıyla 13. yıl
      Büyümenin sürdüğünü ve mevcut sponsorların hepsinin çekildiğini varsaysak bile, bir yıldan biraz fazla dayanacak fonumuz var

      Yine de vakıf gibi bir şeyi düşünüyorum. Tek hata noktası finansman değil, “ben”im

    • Doğru, ama en azından artık Compiler Explorer bağlantıları Compiler Explorer ortadan kalktığında kırılacak; ondan önce değil
      Uzun süre hayatta kalması en değerli Compiler Explorer bağlantılarının hata raporlarındakiler olduğunu düşünüyorum
      Kolaylık olsun diye hata raporlarında Compiler Explorer’a bağlantı veriyoruz, ama raporun içine kodu da koyuyor, hatayı yeniden üretirken kullanılan derleyiciyi ve sürümü de belirtiyoruz
      Compiler Explorer’ın yakında yok olmasını beklemiyorum, ancak hata raporlarını bu şekilde kendi kendine yeterli hâle getirmek o durumda da koruma sağlar

    • No-hiding teoremi sayesinde bilgi sonsuza dek kalacak ;)

  • Google içinde birinden veritabanını sorgulayıp godbolt.org’a giden tüm kısa bağlantıları bulmasını istemenin muhtemelen bir yolu yoktur

  • Alan adını elde tutmak para gerektiriyor; URL’lerin nasıl sonsuza dek sürebileceğini bilmiyorum
    URL’nin ölümü iyi bir şey olabilir mi diye merak ediyorum. İnsanlık iyi olanı bırakmak için özellikle çaba gösterir, geri kalanı ise tarihin garbage collection’ına gider

    • Tarihçiler muhtemelen tarihte daha fazla çöp olmasını isterdi
      Çünkü yalnızca korunmaya değer görülen kısımlar değil, “gerçek” hayata dair daha fazla içgörü elde edebilirlerdi

      Zaman yolculuğu yapabilseydik, dijital ortamların çürümesiyle pek çok bilginin iz bırakmadan yok olacağı çağımıza bin yıl sonraki tarihçilerin nasıl bakacağını görmek ilginç olurdu

    • Katılıyorum. Daha önce bununla ilgili düşüncelerimi burada yazmıştım: https://boehs.org/node/internet-evanescence