Microsoft, Windows Update’i tüm üçüncü taraf uygulamalara açmaya başlıyor

• Microsoft, üçüncü taraf uygulamaların da Windows Update üzerinden güncellenebilmesini sağlayan yeni bir platformu önizleme olarak duyurdu
• Yeni Windows Update orkestrasyon platformu, sürücüler ve kurumsal uygulamalar dahil tüm güncellemeleri birleşik şekilde yönetmek için tasarlandı
• Kullanıcı etkinliği, pil durumu ve çevre dostu enerji zamanlaması gibi etkenlere göre güncelleme takvimi optimize edilebiliyor
• Win32, MSIX ve APPX uygulamalarına kadar destekleniyor ve Windows Update geçmişine uygulama güncelleme kayıtları da ekleniyor
• Mevcut Microsoft Store veya Winget yaklaşımının sınırlarını aşarak, kurumlara özel uygulamaları da kapsama potansiyeli taşıyor

---

Windows Update, tüm uygulama güncellemelerinin merkezi olma yolunda

• Microsoft kısa süre önce, Windows Update’i yalnızca işletim sistemi ve sürücü güncellemelerinin ötesine taşıyarak tüm uygulamalar için birleşik bir güncelleme platformuna genişletme planını açıkladı
• Bu değişiklik özellikle, kurumsal ortamlarda iç uygulamaların güncellemelerini de merkezi olarak yönetme talebini yansıtıyor gibi görünüyor

Yeni orkestrasyon platformuna genel bakış

• Şu anda Windows Update Orchestration Platform adıyla özel önizleme olarak sunuluyor
• Mevcut Windows Update yeteneklerini genişleterek, uygulama güncellemelerini de zamanlama ayarlaması ve kullanıcı deneyimi optimizasyonu kapsamına alıyor

> “Uygulamalar, sürücüler ve diğer tüm güncellemeleri Windows Update ile birlikte orkestre edebilen birleşik ve akıllı bir platform inşa ediyoruz.” — Microsoft ürün yöneticisi Angie Chen

Mevcut uygulama güncelleme yöntemlerinin sorunu

• Windows uygulamalarının çoğu için her geliştirici kendi ayrı güncelleme sistemini işletiyor
• Bunun sonucunda güncelleme zamanlaması ve kalitesi tutarlı olmuyor
• Microsoft Store üzerinden bazı uygulamalar birleşik biçimde güncellenebiliyor, ancak pek çok uygulama Store’da yer almıyor ya da şirkete özel iç uygulama olarak kullanılıyor

Başlıca özellikler ve avantajlar

• Kullanıcı etkinliği, pil durumu ve sürdürülebilir enerji zamanlamasına dayalı planlama özelliği
• Windows Update’in yerleşik bildirim ve geçmiş arayüzüne entegrasyon
• MSIX / APPX uygulamalarının yanı sıra bazı Win32 uygulamalarına kadar destek
• Platformun gelecekteki güncellemelerini otomatik olarak devralma
• Mevcut installer’ların yerini alma potansiyeli sunuyor (örneğin Adobe gibi kendi arka plan yükleyicisini kullanan büyük uygulamalar da kapsama girebilir)

Mevcut çözümlerle karşılaştırma

Yöntem	Açıklama	Başlıca dezavantaj
Microsoft Store	Uygulama kurulumu ve güncellemeleri Store’dan yönetilir	Kayıtlı uygulama sayısı sınırlı, kurumsal uygulamalara uyarlamak zor
Windows Package Manager (winget)	Komut satırı tabanlı paket kurma/güncelleme aracı	Daha çok ileri kullanıcılar ve geliştiricilere hitap ediyor, genel kullanıcı için ana akım değil
Windows Update orkestrasyonu	OS/sürücü dışında genel uygulamaların güncellemelerini de birleştirebilir	Şu anda özel önizleme aşamasında

Geleceğe bakış

• İlk aşamada kurumsal uygulama güncellemelerini birleştirme talebinin yüksek olması bekleniyor
• Sonrasında Adobe, Zoom ve diğer ticari yazılımlara doğru genişleme ihtimali var
• Uzun vadede ise macOS benzeri şekilde sistem genelindeki güncellemeleri tek elde toplama yönünde bir yaklaşım izleniyor

Microsoft, dağınık uygulama güncelleme deneyimini birleştirme yönündeki girişimini yeniden güçlendiriyor ve geliştiriciler ile şirketlerin iş birliğine ne ölçüde katılacağının bu ekosistem dönüşümünde belirleyici olacağı düşünülüyor.

[GN⁺]

Hacker News görüşleri

• Windows'ta Chrome'un güncellemeleri işlemek için yetki yükseltme sorununu aşmak adına hâlâ özel bir servis kullanması durumu sürüyor ve Spotify gibi pek çok uygulama da aynı nedenle AppData'ya kurulmaya devam ediyor; birçok programın kaldırıcı programı da hâlâ düzgün çalışmayıp dosya ya da başka izler bırakabiliyor. MSI ise yeni anahtarların "chain signing" denen eski bir anahtarla imzalanmasını sonsuza kadar zorunlu kılıyor; 10 yılı aşan uzun süreler boyunca güncellemeleri yönetmek gerektiğinde bu oldukça zorlayıcı geliyor. Bir gün tüm bunların temizce toparlanmasını umuyorum.
  • Chrome'un kullandığı kurulum/güncelleme programı açık kaynaklı Omaha, bahsedilen diğer uygulamalar ise Squirrel kullanıyor. İkisi de AppData'da bulunabiliyor; özellikle Squirrel yalnızca kullanıcı dizinine kuruluyor. Squirrel'ın felsefesi, yönetici yetkisi olmadan kullanıcı kurulumu yapılabilmesini sağlamak.
  • AppData'ya kurulmasının nedeni yetki yükseltmeyi gizlice aşmak değil. Microsoft neredeyse 10 yıldan uzun süredir AppData'ya kurulum yöntemini teşvik ediyor ve bugünlerde yetki yükseltme olmadan çalışabilen programlar için AppData kurulumu bence "doğru" yöntem.
  • Konteynerleştirilmemiş ve root/yönetici erişimine sahip uygulamalarda, kurulum programı açısından artık dosyaları tamamen temizlemek neredeyse imkânsız bir sorun. Bu uygulamalar istedikleri dizinde dosya oluşturup yazabiliyor ve Microsoft'un ya da uygulama sağlayıcısının sunduğu kaldırıcı bile tüm dosyaları bulamıyor; programın tüm çalışma akışını birebir yeniden üretmeden tam kaldırma zor görünüyor.
  • GNU/Linux ortamındaki paketler de çoğu zaman geride artık dosyalar bırakıyor.
• UniGetUI ile tanıştım; WinGet, Scoop gibi çeşitli paket yöneticilerini iyi şekilde çağırıyor ve yok sayma listesi gibi özelleştirme özellikleri de sunuyor. Windows'ta bu seviyede özelleştirme beklemenin zor olduğunu düşünüyorum.
• Windows'ta neden macOS'taki gibi birleşik bir kurulum, güncelleme ve kaldırma çerçevesinin en baştan beri olmadığını hep merak etmişimdir. Bence bu açıkça hiç çözülmemiş belirgin bir eksiklik. Bugün bile kurumsal müşteriler uygulamaları yönetmek için tek tek kendileri paketlemek zorunda. Tahminimce bunun nedeni Microsoft'un baştan DLL paylaşımını teşvik etmesi ve geriye dönük uyumluluk sağlamak zorunda olması; bu yüzden .MSI ya da gelişmiş bir yazılım yönetim çerçevesinin kullanımını zorunlu kılamadı.
  • macOS da en başından beri böyle birleşik bir çerçeve sunmuyordu. Birçok uygulama Applications klasörüne sürükle-bırak kolaylığına sahip olsa da, hatırı sayılır bir kısmında kurulum programı çalıştırmak gerekiyor ve sistem geneline destek dosyaları kurmak için sık sık yönetici doğrulaması isteniyor. Uygulamaların kendi güncelleyicileri başlangıçta otomatik de çalışabiliyor. Eskiden eklenti ya da denetim masası öğelerinin System Folder'a kurulup yeniden başlatma gerektirdiğini hatırlıyorum. Ayrıca bu uygulamaların çoğunda kendi kaldırma özelliği de yoktu; sorunsuz yeniden kurulum için ayar dosyaları ve önbellek dosyalarını kullanıcının kendisinin bulup silmesi gerekirdi.
  • Microsoft'un ilk ünlü işletim sistemi olan MS-DOS'un etkisiyle, ilk Windows sürümleri üçüncü taraf yazılım kurulumu açısından fiilen DOS gibi çalışıyordu. Ayrı bir kurulum kavramı yoktu; üreticinin verdiği INSTALL.COM/INSTALL.EXE çalıştırılırdı. Genelde kök dizinde yeni bir klasör oluşturulup dosyalar kopyalanırdı; bazen kullanıcı klasörü kendisi oluşturup elle kopyalardı. Tüm uygulama verisi işlemleri belirli bir dizinde yoğunlaşan bir yapıdaydı (ör. C:\Program Files); UNIX'teki /bin, /etc, /var gibi bir ayrım yoktu. MS-DOS, IO.SYS, MS-DOS.SYS, CONFIG.SYS, AUTOEXEC.BAT dışındaki çeşitli dosyaların nerede olduğuna hiç önem vermeyen bir yapıdaydı. Windows 3.x yaygınlaştığında da bu DOS tarzı çalışma biçimi sürdü ve "birleşik kurulum sistemi" çok geç geldi. .MSI'ın da oldukça geç gelmesi, mevcut programların bunu benimsememiş olmasının tarihsel arka planını açıklıyor.
  • macOS'a geçtiğimde tipik kurulum deneyiminin Windows'tan çok daha iyi olmasına gerçekten şaşırmıştım. İndirilen dosyayı klasöre kopyalamakla kurulumun bitmesi çok etkileyiciydi. Ayrı bir kurulum programı gerektiğinde bile neredeyse her zaman sistemin sunduğu tanıdık akış kullanıldığı için rahatsız edici gelmiyordu.
  • Sürücüler, sistem uzantıları, kütüphane sürüm yönetimi gibi karmaşık sorunlar birleşik bir kurulum/kaldırma sistemi yapmayı zorlaştırıyor. İnternet bağlantısının bile garanti edilemediği durumlarda bu daha da zor. Böyle bir özellik yapılsa bile yazılım üreticilerini bunu kullanmaya ikna etmek gerekir; ayrıca yöneticilerin bunu yeni bir kâr kapısı olarak görüp görmeyeceği de endişe verici.
  • Büyük yazılım üreticileri genelde GPO dağıtımı için msi paketleri sunuyor. Son 10 yılda bir şeyi kendim paketlemek zorunda kaldığımı neredeyse hiç hatırlamıyorum; çoğu zaman yalnızca kurulum parametrelerini ayarlamak gibi basit işler yeterli oluyor. Yine de iyileştirme için hâlâ bolca alan var.
• Windows 10'da tüm güncellemeleri kapatıp bir yıldan uzun süredir hiçbir sorun yaşamadan kullanıyorum. Microsoft sanki "güncelleme" kelimesini bile olumsuz çağrışımlı hâle getirdi; Nadella'nın Windows'a neden bu kadar ilgisiz göründüğünü anlamıyorum.
  • Güvenlik kaygıları nedeniyle güncelleme yapmayınca ortalığın karışacağı kullanıcılar olabilir, ancak çoğu ev tipi PC NAT arkasında olduğundan uzaktan açıkların (ör. EternalBlue) istismarı da zor oluyor; trojan bulaşmadıkça büyük bir sorun çıkmıyor. Tarayıcı güncelse pratikte güvende olunduğunu düşünüyorum. Öte yandan istisna olarak trojan bulaşırsa yönetici yetkisi olmadan da belgeleri şifrelemek ve botnete katılmak mümkün olduğundan, yalnızca Windows Update tüm tehditleri durduramaz görüşü de var.
• Windows Update yaklaşımının tüm Linux paket yöneticilerinin kullandığı yönteme oldukça benzediğini düşünüyorum. Yine de Chocolatey, Scoop, WinGet gibi alternatiflerle kıyaslandığında Windows Update fazla basit ve özellik bakımından yetersiz geliyor.
  • WinGet diye bir şeyin varlığını bu kadar geç öğrenmiş olmaktan utanıyorum. Ubuntu gibi Linux ortamlarında yaşadıktan sonra Windows için paket yöneticisi ararken bunu sonradan fark ettim.
  • Windows Update çok yavaş hissettiriyor. Güncelleme bileşeni sayısı ya da veri miktarı 10 kat artsa neler olacağını düşünmek bile zor.
• Geliştirici/güç kullanıcı olmayan ve Winget/komut satırıyla uygulama güncellemekte zorlanan sıradan kullanıcılara açık kaynaklı UniGetUI uygulamasını kuvvetle öneriyorum. Arayüzü sezgisel, yönetimi iyi ve çok akıcı çalışıyor.
  • UniGetUI projesini ilk kez duydum; gerçekten çok şık görünüyor. İyi bilgi paylaşımı için teşekkürler.
• Bu başlık sayesinde UniGetUI diye çok harika bir araç öğrendim. Bundan sonra tüm Windows cihazlarıma mutlaka kuracağım. Uygulamanın ana hedefi; WinGet, Scoop, Chocolatey, Pip, Npm, .NET Tool, PowerShell Gallery gibi çeşitli Windows paket yöneticileri için sezgisel bir GUI sunmak. Desteklenen paket yöneticilerinde istenen yazılımları kolayca kurup güncellemeyi ve kaldırmayı sağlayan çekici bir uygulama. Bkz. bağlantı (16.2k stars).
• Bu değişiklik 7zip güncellemesinin bile 20 dakika sürüp yeniden başlatma istemesine yol açacakmış gibi geliyor.
  • Bunun mutlaka böyle olacağını sanmıyorum. Windows Update yeniden başlatmayı zorunlu kılmayan pek çok güncelleme de yapıyor ve 7zip'in de bundan farklı olmayan şekilde ayarlanabileceğini düşünüyorum.
• Diğer yorumcular gibi ben de bu değişikliğin zaten çok geciktiğini düşünüyorum; nedeni sadece kimin önce yaptığı değil. Bana göre Win32 API ve masaüstü uygulamaları dönemi en az 10 yıl önce kapandı. Artık masaüstüne kurulu uygulama sayısı az ve kullanıcıların büyük çoğunluğu mobil uygulamalara ve web tarayıcısına daha fazla bağımlı. Benim şahsen kurduklarımın çoğu da yardımcı araçlar ve bu, Microsoft'un iş modeliyle de pek uyumlu değil. Sonuçta hedef kullanıcının tam olarak kim olduğu sorusu akla geliyor.
• Bu politika, Windows Update hizmetinde sorun çıkarsa devasa bir tek hata noktası oluşturabilir endişesi var. İlgili arama trendleri de gösterdiği gibi Windows Update'in uzun bir istikrarsızlık geçmişi bulunuyor.
  • Eğer tek güncelleme yolu hâline gelseydi bu endişe haklı olurdu, ancak gerçekte Windows Update'in tek yol olması planlanmıyor gibi göründüğünden "single point" kaygısının çok büyük olmadığını düşünüyorum.