Lanetli Bilgi

 (immich.app)
4 puan yazan GN⁺ 2025-08-08 | 1 yorum | WhatsApp'ta paylaş
  • Immich geliştirme sürecinde edinilen lanetli bilgi listesini paylaşıyorum
  • Farklı yazılım ve altyapı ortamlarında karşılaşılan beklenmedik sorunlar derlenmiş
  • EXIF meta verileri, YAML boşluk işleme, PostgreSQL gibi araç ve dile özgü sorunlardan bahsediliyor
  • Bazı sorunlar doğrudan güvenlik, platform uyumluluğu ve açık kaynak bağımlılığı ile bağlantılı
  • Geliştiriciler için dikkat edilmesi gereken gerçek örnekler ve kök nedenler öne çıkarılıyor

Genel Bakış

Immich geliştirme ekibi, proje sürecinde bir daha yaşamak istemedikleri lanetli bilgileri paylaşıyor. Bu, gerçek bir hizmet geliştirme ve işletme sırasında farklı araçlarda, dillerde ve platformlarda doğrudan karşılaşılan beklenmedik tuzaklar ve sorunları listeler.

Lanetli Bilgi Listesi

  • 4 Haziran 2025

    • Zitadel'deki Actions lanetli bir işlev.
    • Zitadel'in sağladığı özel betikleme özelliği JS motoru tabanlı olsa da, regex adlandırılmış yakalama gruplarını desteklemediği için sınırlı kaldığını gösterir.

  • 30 Mayıs 2025

    • Microsoft Entra PKCE'yi destekler ancak bunu OpenID discovery belgesinde belirtmez.
    • Bunun sonucunda mevcut özellik istemci tarafından algılanmaz.

  • 5 Mayıs 2025

    • Görselleri tanımlayan EXIF meta verilerindeki boyut bilgisi, gerçek görselle farklı olabilir.
    • Bu fark kırpma ve yeniden boyutlandırma işlemlerinde hataya neden olur.

  • 1 Nisan 2025

    • YAML boşluk işleme çoğunlukla öngörülenin aksine çalışır.
    • Biçimlendirmeye hassastır ve içerik yanlış yorumlanabilir.

  • 20 Eylül 2024

    • Windows gizli dosyalar "w" bayrağı ile açılamaz.
    • SMB'nin "hide dot files" seçeneğiyle birleşince dosya gezinimi ve işleme karışıklığı artar.

  • 7 Ağustos 2024

    • Bash betiğinde carriage return (CRLF) sorunu yaşanabilir.
    • Git checkout sırasında otomatik olarak LF'nin CRLF'ye dönüştürülmesi betik çalıştırmada hata yaratır.

  • 7 Ağustos 2024

    • Cloudflare Workers içinde fetch, https belirtilse bile varsayılan olarak http kullanır.
    • Bu, yeniden yönlendirme döngüsü gibi ağ problemlerine neden olabilir.

  • 21 Temmuz 2024

    • Mobil GPS paylaşımı, uygulamanın konum izni yokken görüntülerdeki GPS bilgisini sessizce kaldırır.
    • Konum tabanlı servis doğruluğu ve gizlilik üzerinde etkisi vardır.

  • 3 Temmuz 2024

    • PostgreSQL'deki NOTIFY yalnızca transaction içinde çalışır.
    • socket.ionun postgres-adapter'ıyla birlikte kullanıldığında her 5 saniyede bir WAL kaydı oluşarak yük artar.

  • 3 Temmuz 2024

    • npm script çalıştırıldığında her seferinde npm registry'ye HTTP isteği gönderilir.
    • Bu yüzden sağlık kontrolünü script ile yapmak verimsizdir.

  • 28 Haziran 2024

    • JavaScript topluluğundaki bazı kullanıcılar, "geriye dönük uyumluluk" gerekçesiyle yaklaşık 50 paket bağımlılığı zorunlu olarak eklemiştir.
    • Bu paketlerin tamamını tek bir kullanıcı yönetmektedir.

  • 25 Haziran 2024

    • bcrypt uygulamaları yalnızca stringin ilk 72 baytını kullanır.
    • Geri kalan karakterler yoksayılır, bu da uzun parolaların anlamsız hale gelmesine yol açar.

  • 31 Ocak 2024

    • JavaScript Date nesnesi yılı ve günü 1'den, ayı 0'dan başlatır.
    • Kolayca kafa karıştırıcı bir yapıdır.

  • 9 Ocak 2024

    • Node.js v20.8 öncesinde, --experimental-vm-modules seçeneğini kullanan CommonJS projesinde ES modülünün CommonJS modülünü tekrar çağırması halinde
      • segfault (segmentasyon hatası) ile Node.js çökmesi oluşurdu.

  • 28 Aralık 2023

    • PostgreSQL parametre sınırı 65.535'tir.
    • Büyük hacimli toplu ekleme işlemlerinde performans sınırına neden olur.

  • 26 Haziran 2023

    • Bazı web API'leri yalnızca Secure Contexts içinde kullanılabilir.
    • Örneğin Clipboard API gibi API'ler yalnızca HTTPS veya localhost ortamında çalışır.

  • 23 Şubat 2023

    • TypeORM'un remove uygulaması, giriş değerini doğrudan etkiler.
    • Orijinal nesnenin id özelliğini bile siler.

Sonuç

Bu tür lanetli bilgiler, gerçek hizmet geliştirme ve işletme ortamlarında sık karşılaşılan tuzaklardır. Geliştiriciler her araç, programlama dili ve ortamda gizli kısıtları ve sorunları önceden tespit ederek etkin problem çözümü ve stabil bir hizmet geliştirme sürecine katkı sağlar.

İlgili okumalar

1 yorum

 
GN⁺ 2025-08-08
Hacker News Yorumu

  • Bunu ilk gördüğümden beri gerçekten beğenmiştim. Örnek commitini (burada) inceledikten sonra daha da çok beğendim. Sorunu çözmeye yönelik kodla birlikte “lanetli bilgi”nin kaydedilmesi özellikle iyi. Bu özelliğin her projede olması gerektiği ilk aklıma gelen şeydi. Günlükler sadece bir katarsis olmaktan öte, her türlü baş ağrısı veren sorunu olumlu bir öğrenme deneyimine dönüştürüyor. Dışarıya açık olduğunda, aynı sorunu yaşayan insanlarla empati kurulabiliyor ve gelecekteki olası arızaları önleyen bir araca dönüşebiliyor.

    • Genelde bu tür bilgileri doğrudan commit mesajlarına yazarım. Birisi bir satır koda bakıp “Neden böyle dağınık yazılmış? Sadece ___ yapsak olmaz mı?” diye düşündüğünde, doğrudan nedenini görmek çok işe yarar.

  • “Tek bir sorguda 65 bin PostgreSQL placeholder bağlanamaz” maddesini görünce şaşırdım. Başından itibaren böyle bir fikrin çok iyi olmadığını düşünüyordum; bu yüzden PostgreSQL’i suçlamak adil değil. GitHub issue yorumlarına bakınca, ORM’i yeniden düzenleyip büyük sorguyu birden fazla küçük sorguya bölmenin mantıklı bir yaklaşım olduğuna dair örnekler gördüm. Benim için tek bir sorguda 3.000-5.000 satır kadar çalıştırmak uygun görünüyor. Birileri önce TEMP tabloya veriyi yükleyip sonra join yapan yöntemi, özellikle de COPY … FROM, performans için daha iyi olabileceği gerekçesiyle önerdi; ama bu çok büyük kod değişikliğine yol açtığı için son olarak bu stratejiden vazgeçildi. Genel olarak çok iyi tecrübelerden oluşan faydalı bir derleme; uyarı amaçlı örnek olarak çok işlevsel.

    • “Bunu denemenin kendisi zaten lanetli bir fikir” fikrine katılıyorum. Listeyi tümüyle okuyunca, “lanet listesi”nin gerçekten bir tıkanıklık ya da tasarım tuzağından çok, geliştiricinin yaşayarak kazandığı dersler gibi olduğunu hissettim. Elbette her bilgi aynı olgunlukta değil ve bazıları hâlâ süreçte, ama bunlar bir mühendislik günlüğündeki kişisel tecrübelere dönüştürüldüğünde daha değerli oluyor.

    • Tüm dosya adlarını tek seferde, NUL karakteri olmadan xargs gibi araçlarla işlemeye çalışmaya benziyor. Garip veya bozuk dosya adları varsa, belleğiniz yeterli değilse sorun olabilir. Bu yüzden find -print0 ile parallel -0/xargs -0 gibi araçlar kullanılmalı. Ayrıca sed, grep gibi araçları LC_ALL=C olmadan çalıştırırsanız çok baytlı karakter dizisi hataları çıkabiliyor, dikkat etmek lazım.

    • Ben de bu “65 bin bağlama” hatasını ORM ile toplu upsert yaparken birebir yaşadım. Özellikle tabloda SQL dizi türlü bir kolon varsa, eklenen her kayıt için bağlama yapmak gerektiğinden bağlanacak değişken sayısı salınım yapıyor. Bu nedenle iki kez çalıştırılsa bile satır/sütun sayısı aynı gibi görünse bile bağlama değişkeni sayısı farklı olabilen dengesiz bir duruma düşüyor.

    • Bir diğer yaklaşım olarak, değerleri dizi argümanı (text[] veya int[] gibi) olarak geçirmek de mümkün. PostgreSQL bunu da iyi şekilde yönetiyor. ANY() işlemi IN() işleminden biraz yavaş ama tek parametre içinde birden fazla ID taşınabiliyor. Muhtemelen ORM bunu desteklemiyordur.

    • Ben de bu noktayı gördüm; bu kadar çok parametre bağlamak kesinlikle lanetli bir yöntem. Büyük hacimli işlerde çoğu durumda COPY kullanmak gerekiyor. Bir de gerçek bir “lanetli Postgres” örneği: prepared statement adları yalnızca NAMEDATALEN-1 kadar sessizce kesiliyor (NAMEDATALEN = 64). Bu durum 2001'den beri vardı, aslında daha önce de vardı. ORM'lerin bunu mutlaka bilmesi gerekir. İnsanların 60 karakterden uzun prepare name kullanması az görülür ama ORM'larda bu bir istisnadır.

  • “50 ek paket kurma” maddesi gerçekten şok ediciydi. O paket yazarı büyük olasılıkla indirme sayısını çok artırdı. Dünya çapında israf edilen bant genişliği ve disk alanını düşününce çok üzgünüm. Acaba sadece itibarını artırmak için mi yaptı dersiniz?

    • Bu “lanetli bilgi”de işaret edilen paket bakımcısı TC39 üyesi. Birkaç ünlü JavaScript projesinde sık sık tartışma konusu olmuş birisi. Belirli polyfill meseleleriyle ilişkilendirilen para motivasyonu iddiaları da vardı; ama GitHub Sponsor ya da Tidelift gelirleri çok yüksek olmadığı için, sanırım gerçekten uyumluluğu bir inanç olarak benimsiyor. 2025 itibarıyla buna bakışım biraz değişti. Kritik bakımı düzenli yapıyor ve topluluk içinde sürekli tartışma yaratan görüşleri dillendirme rolü belki gereklidir.

    • Sadece itibar veya garip mizaçla açıklanabilir ama bir de bunun, devasa ölçekte yazılım tedarik zinciri saldırısı için bir ön hazırlık olduğu yönünde uç bir yorum var.

    • Bu yazarın kim olduğundan neredeyse eminim: ljharb.

  • Windows'un NTFS Alternate Data Streams (ADS) özelliği, mevcut bir dosyanın içinde sınırsız miktarda dosya saklanmasına izin verir.
    macOS ise data fork, xattr ve Spotlight (md) indekslemesi dahil olmak üzere taşınabilir her birime varsayılan olarak sayısız gizli ve geçici dosya yazar. Çözüm: mdutil -X /Volumes/path/to/vol
    Ve opt-out telemetri çok fazla: go, yarn, meilisearch, homebrew, vcpkg, dotnet, Windows, VS Code, Claude Code, macOS, Docker, Splunk, OpenShift, Firefox, Chrome, flutter ve daha niceleri.

    • Opt-out telemetri: go tarafında telemetri verileri varsayılan olarak yalnızca yerelde saklanır. Kullanıcı isterse yalnızca bazı onaylanan veriler telemetry.go.dev'a yüklenebilir. Yüklemeyi açmak “go telemetry on”, tamamen kapatmak ise “go telemetry off” komutuyla yapılabilir (dokümantasyon).

    • Gerçekten işe yarayan tek telemetri opt-out telemetridir.

  • “npm script’i çalıştırıldığında her defasında npm registry'ye HTTP isteği gidiyor” iddiasının doğru olup olmadığını merak ediyorum. Doğruysa bir paket yöneticisi için saçma bir davranış olurdu.

    • Muhtemelen npm güncellemesi kontrolü yapılıyor. Eski sürüm kullanıyorsanız zaman zaman bir güncelleme uyarısı çıkar.

    • Büyük ihtimalle yine güncelleme kontrolü; bazen güncelleme banner'ları görünür.

  • Eksik kalmış bir şey var gibi görünüyor. EXIF meta verisindeki tarih/saat işleme kısmı zaten uzun süredir süren bir tartışma.
    İlgili issue1, İlgili issue2, İlgili issue3

    • Zaman verilerinin kendisi de lanetli olmaya açık. Güzel çalışsa bile ilgili özellikte her zaman bir şey patlayabilir. Özellikle saat dilimi veya yaz saati bilgisi içeriyorsa bu daha da hassas.

  • Hadoop ve Kerberos ile ilgili “Madness beyond the gates” (bağlantı) belgesi aklıma geldi. Bu yazı sayesinde delirme noktasından birden çok kez kurtuldum. Yazar Steve'e bir teşekkür borçluyum; bu “lanetli bilgiyi” üretmek için ne kadar uğraştığını hayal bile edemiyorum.

  • Bu “lanetli bilgiyi” tek bir yerde derleme fikri çok iyi. Gerçekten, bir projede derine indikçe karşılaşabileceğiniz tecrübelerin çoğu böyle yaşanır. Bundan sonra her projede böyle bir liste tutmayı düşünüyorum.

  • Bu madde ise lanet değil; mobil işletim sistemlerinde izin yönetimiyle ilgili güvenlik ve gizlilik meselesi.

  • Harika bir fikir! Başkalarının da kendi “lanetli bilgilerini” paylaşma isteği olur mu bilmiyorum.
    Kendi deneyimlerime göre MacOS dosya adları da bir lanet:

  1. Varsayılan olarak MacOS’ta dosya adları case-sensitive değil; file.txt ile FILE.txt eşdeğerdir.
  2. MacOS, dosya adını NFC olarak saklasa bile bazen NFD'ye dönüştürülebiliyor.

  • 1995'te Windows 95 Beta'da CDDB'yi ilk yaptığım zaman. CD albümlerinin parça adlarını toplayıp .ini dosyasıyla dağıttık; 64 KB'lık .ini dosya boyutu sınırı nedeniyle proje durdurulmuştu.

  • Doğru. Sistem veya veri volümünde case-sensitive APFS ya da HFS+ hacmi oluşturursanız mutlaka sorun yaşarsınız.

  • “1.” maddesi varsayılan ayar; HFS ve APFS’te de büyük-küçük harf ayrımı seçeneği var. NTFS de benzer şekilde çalışır. Bu dosya sistemleri case-retentive olduğu için şöyle yapabilirsiniz:

 $ echo yup > README.txt
 $ cat ReAdMe.TXT
 yup
 $ ls
 README.txt

Asıl sorun, Steam’in case-sensitive dosya sistemlerinde kurulumu kendisi bile reddetmesi (Linux sürümü bulunsa bile).