9 puan yazan GN⁺ 2025-12-02 | 3 yorum | WhatsApp'ta paylaş
  • Windows NT'nin alt sistem yapısı, farklı işletim sistemleri için uygulama çalıştırmak amacıyla bir API çağrı dönüştürme katmanı olarak gelmiştir
  • WSL1 bu geleneği sürdüren biçimde, Linux çağrılarını Windows çekirdek çağrılarına dönüştüren hafif bir çeviri katmanı olarak çalışır
  • WSL2, performans sorunlarını çözmek için Hyper-V tabanlı tam bir Linux VM'e geçerek gerçek bir Linux çekirdeği çalıştırır
  • WSL2, dinamik bellek yönetimi, Windows sürücü montajı, WSLg ile GUI entegrasyonu gibi özellikleriyle klasik VM'den daha yüksek entegrasyon sağlar
  • Dosya yönetiminin zorlukları ve disk imajına bağımlılık gibi sınırlamalar olsa da, WSL1 ve WSL2'nin artılarını ve eksilerini duruma göre seçebilmeyi sağlayan esneklik önemlidir

Windows NT'deki alt sistem kavramı

  • Windows NT'deki alt sistem (subsystem), farklı işletim sistemlerine ait programları çalıştırmak için bir API kümesi ve çağrı dönüştürme katmanı anlamına gelir
    • Geçmişte NT'de OS/2 alt sistemi (OS2SS.EXE), POSIX alt sistemi (PSXSS.EXE) bulunuyordu
    • CSRSS.EXE, Win32 API çeviri katmanıydı; bazı işlevler çekirdek moduna (WIN32K.SYS) taşındı
  • POSIX alt sistemi, devlet onayı için minimum düzeyde bir uygulamaydı ve daha sonra Interix tabanlı Windows Services for Unix ile değiştirildi

WSL1: Çeviri tabanlı Linux katmanı

  • WSL1 (Windows Subsystem for Linux), Linux sistem çağrılarını Windows çağrılarına çeviren ince bir çeviri katmanıdır
    • Çalıştırıldığında yalnızca birkaç MB bellek kullanan bir bash süreci bulunur ve Task Manager'da normal bir süreç olarak görünür
    • Kök dosya sistemi NTFS üzerindeki tekil dosya yapısında bulunur ve bu nedenle depolama alanı overhead'i neredeyse yoktur
  • Kısıtlamalar
    • I/O performans düşüşü: Linux ile Win32 dosya sistemi API farkından doğan dönüştürme maliyeti
    • GUI çalıştırırken harici bir X sunucusu gerekir (ör. X410)
    • Raw socket desteklenmez; traceroute, nmap, tcpdump gibi araçlar çalıştırılamaz

WSL2: Hyper-V tabanlı Linux VM

  • Kullanıcı taleplerine göre Microsoft, Hyper-V üzerinde çalışan tam bir Linux VM modelini benimsedi
    • Kök dosya sistemi tek bir VHDX dosyası ile yönetilir
    • wsl --set-version "Ubuntu" 2 komutuyla WSL1 ile WSL2 arasında geçiş yapılabilir
  • Performans özellikleri
    • İlk açılış yavaştır ama yerel Linux çekirdeği çalıştırılır
    • Bellek kullanımı dinamik olup, fiziksel belleğin en fazla yarısına kadar genişleyebilir
    • stress testi sonuçlarına göre, bellek kullanımı yük arttıkça yükselir ve sonra otomatik olarak düşer
    • İstenirse wsl --shutdown komutuyla VM kapatılabilir

WSL2'nin entegrasyon özellikleri ve sınırlamaları

  • WSL2, geleneksel VM'lerin aksine Windows ile entegrasyonu güçlendirir
    • Windows sürücülerinin otomatik montajı, Linux sürücülerine \\wsl$ yolu ile erişim, WSLg ile GUI uygulamaları çalıştırma
    • GUI uygulamaları Remote Desktop Protokolü ile akışla iletilir ve DPI veya metin ölçekleme için ayrı ayar gerektirir
  • Dosya yönetimi sorunu
    • Linux iş verisi, ext4.vhdx imajının içinde saklandığı için taşınabilirlik ve kurtarma (recovery) riski vardır
    • wsl --unregister Distro komutu çalıştırıldığında tüm veriler anında silinir
    • Windows sürücüsünü (/mnt/c) kullanırken NTFS + VM ek yükü nedeniyle performans düşer
  • Dosya sistemi protokolü
    • WSL1 drvfs, WSL2 ise Plan9'un 9p protokolünü kullanır
    • Dönüşümde drvfs yüzünden kalan bazı hata örnekleri belirtilir
  • Alternatif
    • Ayrı bir VHDX imajı oluşturarak wsl --mount --vhd ile mount etmek ve iş verisini ayırmak önerilir
    • .wslconfig içinde otomatik ayar yapılamaz, script ile işlenmesi gerekir

Sonuç

  • Windows NT'nin modüler tasarımı ve kararlı çekirdek ABI'si, eski sürücü uyumluluğunu korur
  • WSL1 hafif bellek kullanımının avantajına sahiptir; WSL2 ise gerçek Linux çekirdeği ile daha yüksek uyumluluk ve performans sağlar
  • WSL2, VM'in dezavantajlarını en aza indirip ana işletim sistemiyle entegrasyonu güçlendiren bir yapıdır
  • Geleneksel bir tanıma göre VM'e yakın olsa da, hafif entegre bir ortam olarak “alt sistem” denmeye değer

3 yorum

 
crawler 2025-12-02

Vay, geliştiriciye hafif bir laf sokma da varmış.

 
GN⁺ 2025-12-02
Hacker News yorumu
  • WSL2, Hyper-V'nin bir alt kümesi üzerinde çalışır; yani temelde hypervisor üstündeki bir VM'dir
    Ancak normal bir Hyper-V VM'inden farklı yönleri vardır. Örneğin WSL2 Linux dağıtımları, GPU partitioning (yani PCI/GPU passthrough) ve DirectX'in özel bir uygulaması sayesinde X veya Wayland ortamlarında da GPU hızlandırmasını kullanabilir
    Bu tür özellikler PowerShell vb. ile yapılan hack'lerle normal Hyper-V'de de mümkün olabilir, ancak resmî olarak yalnızca Windows Server üzerinde desteklenir

    • GPU passthrough'nun varsayılan Windows 11'de de çalıştığını sanıyordum, ama ayrıntılı bakmadım. Yine de oldukça etkileyici bir özellik
    • Sonuçta bu sadece normal bir VM, ama otomatikleştirilmiş olması güzel
      Yalnız “render işini X veya Wayland yapıyor” demek yanlış olur. GPU'yu gerçekten kullanan uygulamanın kendisidir; X/Wayland ise render tamamlandıktan sonra esas olarak pencere birleştirme işini yapar
      Renk dönüşümü gibi daha karmaşık işler de vardır ama hesaplama yükü düşüktür
    • WSL2 ile WinNT çekirdeği de aslında ikisi de Hyper-V üzerinde neredeyse aynı seviyede çalışmıyor mu? Tabii NT çekirdeğinin donanıma erişim yetkisi daha fazladır
    • Linux çalıştırmak için Windows Server lisansı satın alıp kurmak gerektiğini hayal etmek komik
    • WSL2'nin grafik entegrasyonu beklediğimden daha hayal kırıklığı yarattı. Eskiden X-server kurulumları daha iyiydi. Ama X modern API'leri desteklemediği için geliştiriciler yavaş yavaş ilgisini kaybediyor. WSL2 desteği arttıkça umarım iyileşir
  • WSL1, pico process tabanlıdır ve Drawbridge araştırmasından türeyen bir teknolojidir
    İlgili videolar: The Linux Kernel Hidden Inside Windows 10 ve WSL Pico Process Overview
    Aynı Drawbridge teknolojisi, SQL Server'ı Linux üzerinde çalıştırırken de kullanılmıştır
    Ayrıntılar Ars Technica makalesinde yer alıyor

  • WSL2'ye geçiş nedenini anlıyorum, ama WSL1 geliştirmesinin tamamen durdurulması üzücü
    CI ortamımızın çoğu Linux tabanlı, ancak bazı toolchain'ler Wine üzerinde iyi çalışmıyor (örneğin MSVC)
    Bu yüzden Windows üzerinde Linux build'lerini sorunsuz çalıştırabilecek bir ortama ihtiyacımız vardı. WSL1 bunu mümkün kılıyordu, ama WSL2 process namespace veya file descriptor paylaşmadığı için çeşitli geçici çözümler gerekiyor
    IO hızı artmış olsa da dosya paylaşımı yavaş olduğundan pratik kullanım için uygun değil

    • WSL2'de de /mnt/c üzerinden Windows dosyalarına erişmek mümkün
    • MSVC yerine clang-cl ile xwin kombinasyonunu denemek de bir seçenek olabilir.
      Geçmişte Python C extension modüllerini bu yöntemle derlemiştim
  • WSL2, Windows ortamıyla çok sıkı entegre edilmiş bir VM'dir
    Şirket politikası gereği Windows kullanmak zorundayım ve geliştirme için her gün kullanıyorum; çoğu durumda oldukça rahat

    • Şirketin verdiği VM üzerinde çalışıyorum ama performans giderek can sıkıcı hâle geliyor. WSL2'ye geçmeyi düşünüyorum.
      Ancak RHEL8 tabanlı bir ortam kullanıyoruz, Debian tabanlı sistemlerin desteklenmesi can sıkıcı. Grafik uygulama desteği bugünlerde nasıl merak ediyorum
    • “Sıkı entegrasyon” deniyor ama gerçekte ps veya top içinde sadece VM süreçleri görünüyor.
      docker run -it ubuntu ile de benzer şeyler yapılabiliyor; farkın tam olarak ne olduğunu merak ediyorum.
      Bana göre ayrılmış çalışma alanı çok rahatsız ediciydi
  • WSL2 sonuçta hafif bir VM'dir. Firecracker'a benzer bir fikirle hızlı açılış ve düşük bellek kullanımı hedeflenmiştir
    Ancak birden fazla Docker çalıştırınca bellek ihtiyacı büyüyor. Rahat kullanım için en az 20 GB gerekiyor

    • Neyse ki artık 32 GB RAM'li dizüstüler eskisi kadar pahalı değil
    • WSL2'nin 1-2 saniyede açılması çok etkileyici; bunun nasıl yapıldığını merak ediyorum. BIOS ekranını atladığını anlıyorum ama onun dışında da bazı optimizasyonlar var gibi görünüyor
  • Bana göre WSL1 çok daha kullanışlı. C++ ve .NET toolchain'leri, ssh/scp gibi çoğu CLI aracı sorunsuz çalışıyor
    Buna karşılık WSL2'nin pek bir faydası yok. Linux VM gerekiyorsa VMware kullanıyorum
    VMware, snapshot ağacı, 3D hızlandırma, USB aygıt bağlantısı, sanal ağ yapılandırması gibi zengin özellikler sunuyor ve GUI'si de kullanışlı

  • WSL içindeki VM diski \\wsl$ yolu üzerinden erişilebilir
    Eski yazılımlar UNC yolunu desteklemiyorsa bunu bir sürücü harfine eşleyerek çözebilirsiniz

  • VHDX dosyasının durmadan büyümesi gibi bir sorun var. Elle compact etmek gerekiyor

    • sparse VHD etkinleştirilirse yardımcı olur. Kusursuz değil ama systemd-trim servisiyle kısmen çözülebilir
      İlgili sorun için GitHub WSL #12103'e bakabilirsiniz
      Bu da işe yaramazsa manuel optimizasyon yöntemini kullanabilirsiniz
    • Otomatik küçültme özelliği var ama bazen tersine sorun da çıkarabiliyor
  • Ayrıca WSL'nin varsayılan olarak Windows güvenlik duvarı kurallarını baypas ettiği söyleniyor. Microsoft'un bunu neden böyle tasarladığını merak ediyorum

    • Gerçekten öyle mi? WSL içinde ssh bağlantılarıyla hep sorun yaşadım
  • Gerçek bir ext4 bölümünü mount ederek, image dosyası tabanlı block device simülasyonundan kaynaklanan performans kaybını azaltmak mümkün olur mu diye merak ediyorum

 
tangokorea 2026-04-23

WSL2’yi sık kullanmaya başladıkça Linux kullanımım giderek azalırken, bunun da EEE olup olmadığını düşünmeye başlıyorum.
EEE - Benimse, genişlet ve yok et (Embrace, Extend, and Extinguish)