100 işletim sisteminde çalışan curl

• curl, eski ortamlarda da derlenip test edilmeye devam edebilmesi için değişiklikleri sınırlıyor; yakın tarihli bir pull request’te de 32 bit time_t ve eski platform uyumluluğunu bozmama şartı arandı
• Asıl mesele uzun bir platform listesini korumak değil, kullanıcılar yükseltme yaptığında da çalışmanın sürmesini sağlayan ABI/API kararlılığı sözünü tutmak
• Belirli bir işletim sisteminin kullanıcı sayısından çok, ona gerçekten bakıp sorunlarını düzelten birinin olup olmadığı daha önemli; bakımcısı kaldığı sürece az kullanıcılı platformlar da desteklenmeye devam edebilir
• curl ve libcurl, işletim sistemleri, CPU mimarileri ve sıra dışı yapılandırmalar genelinde “derlenip çalışır” durumda kalmayı hedefleyen taşınabilirlik odaklı ilke sayesinde yaygınlaştı
• Eski curl komutlarının başarısız olmasının başlıca nedeni curl’deki değişimlerden çok, host’ların ve URL’lerin ortadan kalkması ile HTTP’den HTTPS’ye geçiş gibi internet ortamındaki değişimlerdir

---

Eski platformları bozmayan değişiklik ölçütü

• Yakın tarihli bir curl pull request’inde, değişikliklerin eski platformlardaki derlemeyi veya testleri bozmayacak şekilde olması şartıyla git kod deposuna birleştirilebildi
• Söz konusu değişiklik time_t ile ilgili bir alandaydı ve curl zaten 32 bit time_t türünü desteklediği için bu davranışın korunması gerekiyordu
• 32 bit time_t kullanımı zaten sınırlı ve 2038 yaklaştıkça kısıtları daha da artabilir; ancak birçok eski platform hâlâ 32 bit sürümlerde kalmış durumda
• Bu tür gereklilikler katkı sağlayanların işini zorlaştırsa da curl’de değişikliği daha eksiksiz hâle getirme sürecinin parçası olarak görülüyor

Uyumluluk, platform sayısından daha büyük bir söz

• curl projesi ABI ve API kararlılığını ve uyumluluğu korumak için sürekli çaba gösteriyor
• 2000’lerin ortalarında libcurl kullanan bir uygulama, uygulamayı yeniden derlemeden en güncel libcurl’e yükseltildiğinde de aynı şekilde çalışabilir
• 2000’lerin başında yazılmış curl betiklerinin de en yeni curl sürümlerinde neredeyse aynı şekilde çalışması beklenebilir
• Bu uyumluluk basit bir pazarlama ifadesi değil, curl ve libcurl’ün sunduğu temel ilkelerden biridir
  • Kullanıcılar curl’e güvenebilir
  • Hata içeren bir sürüm olsa bile, genel yazılım yükseltme sancıları yaşatmadan yeni sürüme geçilebilecek güncellemeler sunulmaya çalışılır
• Zaten iyi çalışan şeyleri gereksiz yere bozmama yaklaşımı bakım ölçütlerine dahildir

Desteği belirleyen şey bakımcıdır

• Belirli bir platformun kullanıcı sayısı, curl’ün o platformu desteklemeye devam edip etmeyeceğine karar vermedeki ana motivasyon değildir
• Daha önemli ölçüt, işi kimin üstlendiği ve gereken bakımın gerçekten yapılıp yapılmadığıdır
• Bir platformda curl’ün çalışmaya devam ettiğini doğrulayan bir katkıcı varsa, az kullanıcılı olduğu bilinen platformlarda bile curl çalışmayı sürdürebilir
• Bir platformun curl’den fiilen kaybolduğu an, o platform için gereken kodun artık bakımının yapılmadığı zamandır
  • Bakımı yapılmayan kod bile yıllarca çalışır durumda kalabilir
  • curl’ün belirli bir platformda artık çalışmadığını fark etmek bile uzun sürebilir
• Tersine, çok kullanıcılı bir platformda bile o platforma özgü sorunlarla ilgilenme isteği ve bilgisi olan bakımcılar eksikse bakımı zorlaşır

Farklı ortamlara yayılmasının nedeni

• curl ve libcurl, mümkün olduğunca çok ortamda derlenip çalışmaya güçlü biçimde odaklanır
• Benzersiz ya da tuhaf yapılandırmalarda bile çalışır durumda tutma yaklaşımı, birçok işletim sistemine ve CPU mimarisine yayılmasının nedenlerinden biridir
• Pek çok kullanıcı ve şirket eski, niş veya legacy platformları kullanmaya devam eder
• Bu kullanıcılar için curl’ün aktarım işlevlerini çalışır tutmak, çoğu zaman kendi geliştirdikleri alternatif uygulamalardan güvenlik açısından daha iyidir
• Bir işlevi bozmak gerekmiyorsa, mevcut kullanıcıların curl’e güvenmeyi sürdürmesine izin vermenin daha iyi olduğu değerlendirmesi uygulanır

Desteği kaldırma yavaş ve açık biçimde yapılır

• curl de zaman zaman bazı destekleri kaldırır
• Başlıca kaldırma hedefi, kullanımı azalıp yok olmaya yüz tutan üçüncü taraf kütüphane desteğidir; ancak başka alanlarda da destek kaldırma yaşanabilir
• Desteği sonlandırma yavaş, dikkatli ve açık iletişimle yürütülür
  • Bilmek isteyen kullanıcılar değişikliği önceden öğrenebilmelidir
  • Kullanıcılar hazırlanabilmeli veya öneri haksız görünüyorsa itiraz edebilmelidir
• Kullanıcılar davranış değişikliğini fark edemiyorsa, bu değiştirilmiş sayılmaz
• curl kullanıcılar için yapılmıştır ve kullanıcılar belirli bir davranışın sürmesini istiyorsa o davranış korunmalıdır

Eski komutların başarısız olmasının gerçek nedeni

• İnternet protokolleri ve sürümleri zamanla ortaya çıkar ve kaybolur
• 2002’de yazılmış curl komut satırlarının çoğu bugün olduğu gibi çalışmayabilir
• Başarısızlığın nedeni curl’ün kendisi değil, o dönemde kullanılan host adları ve URL’lerin artık çalışmaması olabilir
• 2002 tarihli bir curl komutunun bugün aynen çalışmamasının büyük nedenlerinden biri HTTP’den HTTPS’ye geçiştir
• 2002’de TLS veya SSL kullanan siteler olsa bile o dönemde bu yaygın değildi; o zaman kullanılan TLS protokol sürümü bugün güvensiz kabul edilebilir
• Güncel TLS kütüphaneleri ve curl, güncellenmemiş eski TLS ayarlarına bağlanmayı reddedebilir
• 2002’den kalma bir curl çalıştırılabilir dosyasını saklayıp bugün çalıştırsanız bile modern HTTPS sitelerine bağlanamayabilir
  • Bu, curl’deki değişikliklerden değil, aktarım protokolü katmanındaki değişimlerden kaynaklanır

[GN⁺]

Hacker News yorumları

• Büyük başarı. Curl gerçekten nimet gibi bir araç.
  Daniel’ın 32-bit time_t’yi uyumluluk açısından önemli bir nokta olarak vurgulaması ilginç. Hedefiniz çok sayıda işletim sisteminde çalışmayı sürdürmekse tamamen mantıklı. Öte yandan 2038’e artık yalnızca 14 yıl kaldı ve bugün, curl’ün ilk çıktığı zamandan çok daha yakın. 32-bit zamanı desteklemek için harcanan emeğin ne zaman artık değmez sayılacağını merak ediyorum. Tahminimce Y2K38 tarihi geçtikten yaklaşık 3 ay sonra, belki de daha uzun süre.

• Geliştiricilerin operasyon ekiplerine yaklaştıkça öğrendiği bir şey var: Size bağımlı olan taraflar arttıkça yükünüz büyür. Altyapı ve merkezi sistemlere yeterince çok şey bağımlı hale gelince çevikliklerini kaybederler; ufak değişiklikler bile gerçekten zorlaşır.
  Kendi servisinizde backend ve frontend varsa ve aralarındaki API’yi kökten değiştirmek istiyorsanız kimin umurunda? Yaparsınız geçersiniz.
  Ama sırf “çirkin” diye varsayılan şablondaki tuhaf bir edge case’i kaldırmak istiyorsanız, 20 eski servise, insanların dokunmak istemediği yarı modernize edilmiş 20 servise ve onu kullanan 50 servise daha bakmanız gerekir. Bu sadece değişikliğin ne kadar büyük bir iş olduğunu anlamak için gereken emek. Bu aşamada gerçek değişikliği uygulamaktan ya da anlaşılması zor sırları tersine mühendislikle çözmekten söz etmiyoruz bile.
  Gösterişli bir iş olduğunu söylemem; ama kimse fark etmeden alttaki her şeyi değiştirirken parlayan yıldızı ayakta tutmaya devam etmek roadie’lere ya da yöneticilere gurur verir.

• Listede 25 yıldan uzun süredir sürüm çıkarmayanlar da epey var. SCO, Xenix, OS/2, NextStep için hâlâ güncel derlemeler mi yapılıyor?
  Bunları çalıştırmışlığım var ve oralarda da curl bulunduğunu biliyorum; ama deneyimime göre o curl her zaman en az 15 yıllık bir sürümdü.
  Bir destek matrisini bozmak istemediğinizi söylüyorsanız, ama o matrisin ciddi bir kısmı son derlemeden bu yana 10 yıldan çok daha fazla zaman geçirmişse, gerçekten bozulmadığını nasıl bilebilirsiniz?

  • 25 yıl bile oldukça cömert bir küçümseme gibi geliyor.
    Xenix için derlenebilir mi emin değilim. Hedeflenebilecek en yeni GCC 2.7, o da zaten antik bir sürüm. Ağ kodunu da düşününce daha da öyle. Muhtemelen “bir noktada bu sistemlerde çalışmıştı” anlamındadır.
  • Buna kıyasla AmigaOS hâlâ gayet canlı. En son sürümü 2021’de çıktı.
  • Xenix ya da OS/2 değişmediyse, eski bir Curl derlemesi neden birden orada bozulmuş olsun?
  • SkyOS da iyi bir örnek. Bu noktada birinin gerçekten SkyOS üzerinde çalıştırdığını varsaymaktansa kaldırmak daha güvenli gibi.

• “Çok sayıda kullanıcı ve şirket eski, niş ve legacy platformlarda ısrar ediyor; bizim de yapabileceğimiz bir şey yok” sözüne gelince, çoğu insan, kapalı kaynak özel mülk yazılım geliştiricileri de dahil, lisansın başında “Bu program faydalı olacağı umuduyla dağıtılmaktadır, ancak hiçbir garanti verilmez; satılabilirlik ya da belirli bir amaca uygunluk konusunda zımni garanti de yoktur” gibi ifadeler bulunan yazılımlar yapar.
  Bunun maliyeti düşüktür.
  Buna karşılık, benim de dahil olduğum bazı kişiler, amaca uygunluğu garanti edilen, garantisi açık ve mutlak olan yazılımlar geliştirir.
  Bu çok pahalı ve yavaştır.
  Bir şey bozulduğunda insanlar ölebilir, çevre zarar görebilir ya da milyonlarca dolarlık hasar oluşabilirse, 30–40 yıl boyunca çok yavaş ve dikkatli geliştiriciler tarafından didik didik incelenmiş eski ve niş platformları kullanmaya devam etmek mantıklıdır.
  En azından PowerPC üzerinde INTEGRITY’de Ada’ya bakarken kendime böyle söylüyorum.

  • O tek cümlenin içinde kendi kendinizle çelişiyorsunuz.
    Bir kişinin ölmesi milyonlarca dolarlık zarara yol açabiliyorsa, geliştirici havuzu “Wilson hastalığı olan Fransız jonglörlerin sayısı” kadar küçük olan bir yazılımı ya da platformu kullanmamak daha doğru olur.

• Bu popülerliğin bir nedeni permissive lisans olabilir. MIT lisansı sanmıştım, ama biraz farklı gibi [1]. MIT’den temel farklarının ne olduğunu basitçe bilen var mı? Telif hakkı sayfasında ayrıntılı açıklama yok.
  [1] https://curl.se/docs/copyright.html

  • MIT lisansıyla karşılaştırıldığında ana ek madde şu bölüm gibi görünüyor:
    “Bu bildirimde yer alanlar dışında, telif hakkı sahibinin önceden yazılı izni olmadan telif hakkı sahibinin adı bu yazılımın satışını, kullanımını veya diğer işlemlerini reklam ya da tanıtım amacıyla kullanılamaz.”
  • Sayfada yazdığı gibi MIT/X11 lisansından esinlenmiş özel bir lisans gibi görünüyor. MIT/X11’den farkı, garanti reddinin baş kısmının kısaltılmış olması gibi. SPDX’te ayrı bir girdisi var [1].
    [1] https://spdx.org/licenses/curl.html
  • MIT lisansına BSD 3-Clause lisansının üçüncü maddesini karıştırmışlar gibi.

• Neredeyse 100 tanesinin yalnızca Linux sürümleri olacağını sanmıştım; tüm Linux sürümlerini tek bir işletim sistemi saysak bile 100’e ulaşması şaşırtıcı.

  • Öyle gerçi, ama iOS, iPadOS ve watchOS’u ayrı işletim sistemleri olarak sayıyorlar; yani gerçekte yaklaşık 98 işletim sistemi. O kadarı da… herkes yapar zaten…

• Çeşitli legacy sistemleri dikkate alarak kod yazınca, kişisel deneyimime göre kod genel olarak daha iyi oluyor.
  İsimlendirme, tipler, modülerlik gibi iyi bilinen kodlama pratiklerine daha iyi uyuyorsunuz; açıkça işaretlenmiş bölümler dışında standartlara uyum da daha iyi oluyor. Soyutlamalar daha sağlam hale geliyor, özellikle modern platformlarda hatalar azalıyor, build sistemi de daha dayanıklı oluyor. Gelecekteki platformlarla ya otomatik olarak uyumlu hale geliyor ya da en azından uyumlu hale getirmesi çok kolay oluyor.
  Ancak yalnızca birkaç legacy sistemi hedefliyorsanız, tuhaf yamalar ve hack kombinasyonlarıyla idare edebileceğiniz için bu söz geçerli olmayabilir.

• FreeDOS, DR-DOS ve MS-DOS’u birbirinden ayrı işletim sistemleri olarak listelemek garip. Bunlar birbirine çok benziyor ve farklı Unix türevlerinin aksine fiilen ABI uyumlu.

  • Neredeyse öyle. Hepimizin bildiği gibi DR-DOS, MS-DOS ve PC-DOS yaklaşık %99 uyumluydu; sorun, şanssızlıkla o %1’e denk geldiğinizde çıkıyordu. DR-DOS, MS-DOS’u tersine mühendislikle çözmüştü; IBM’in PC-DOS lisansı bile Microsoft’un MS-DOS’ta yaptığı her şeye erişim hakkı vermiyordu.
  • DR-DOS, MS/PC-DOS ABI uyumluluğuna sahip CP/M’in doğrudan soyundan geldiği için kesinlikle ayrı bir işletim sistemidir. FreeDOS da öyle. İç yapıya bakınca her biri yeterince farklıdır.
  • OPENSTEP ve NeXTSTEP’i de ayrı işletim sistemleri olarak listelemişler…

• Buna rağmen insanlar bunu Rust ile yeniden yazmak istiyor. Rust gerçekten tüm bu mimarileri ve işletim sistemlerini hedefleyebiliyor mu?

  • Neden biri curl’ü yeniden yazmak istesin ki? C kullanmanın nesi bu kadar sorun?

• İlgili okuma: curl’ün nasıl doğduğunu ve nasıl bir tarihçeden geçtiğini anlatan yazı (1)
  (1) https://daniel.haxx.se/blog/2023/03/20/twenty-five-years-of-...