Microsoft ने Windows Update को सभी third-party apps के लिए खोलना शुरू किया

• Microsoft ने एक नया platform preview में जारी किया है जो third-party apps को भी Windows Update के ज़रिए update होने देता है
• नया Windows Update orchestration platform, drivers और business apps सहित सभी updates को एकीकृत रूप से manage करने के लिए design किया गया है
• user activity, battery status, और green energy timing जैसी चीज़ों के आधार पर update schedule को optimize किया जा सकता है
• Win32, MSIX, और APPX apps तक support मिलता है, और Windows Update history में app update history भी शामिल होगी
• मौजूदा Microsoft Store या Winget तरीकों की सीमाओं से आगे बढ़ते हुए, business के custom apps को भी शामिल करने की संभावना है

---

Windows Update, सभी app updates का hub बनने की दिशा में

• Microsoft ने हाल ही में Windows Update को OS और driver updates से आगे बढ़ाकर सभी apps के लिए एक unified update platform बनाने की योजना की घोषणा की है
• यह बदलाव खास तौर पर enterprise environment में internal apps तक updates को unified तरीके से manage करने की मांग को दर्शाता है

नए orchestration platform का overview

• Windows Update Orchestration Platform नाम से इसे फिलहाल private preview में उपलब्ध कराया जा रहा है
• यह मौजूदा Windows Update capabilities का विस्तार करता है, ताकि app updates भी scheduling और user experience optimization का हिस्सा बन सकें

“हम एक unified intelligent platform बना रहे हैं जो apps, drivers और अन्य किसी भी updates को Windows Update के साथ orchestrate कर सके।” — Microsoft product manager Angie Chen

मौजूदा app update तरीकों की समस्या

• ज़्यादातर Windows apps में हर developer अपना अलग update system चलाता है
• नतीजतन update timing और quality में consistency नहीं रहती
• MS Store के ज़रिए कुछ apps के updates unified किए जा सकते हैं, लेकिन कई apps Store में listed नहीं होते या वे enterprise के internal apps होते हैं

मुख्य features और फायदे

• user activity, battery status, और sustainable energy timing पर आधारित scheduling
• Windows Update के default notifications और history UI में integration
• MSIX / APPX apps के साथ कुछ Win32 apps का भी support
• platform के future updates का automatic inheritance
• मौजूदा installers को replace करने की संभावना (उदाहरण: Adobe जैसे बड़े apps, जो अपना background installer चलाते हैं, वे भी target बन सकते हैं)

मौजूदा समाधानों से तुलना

तरीका	विवरण	मुख्य कमी
Microsoft Store	Store से app installation और updates manage करना	listed apps सीमित, enterprise apps पर लागू करना कठिन
Windows Package Manager (winget)	command-line आधारित package install/update tool	मुख्यतः power users और developers के लिए, आम users में कम प्रचलित
Windows Update orchestration	OS/drivers के अलावा सामान्य apps तक updates को unify कर सकता है	फिलहाल private preview चरण में

आगे की दिशा

• शुरुआत में enterprise app update integration की मांग सबसे अधिक रहने की संभावना है
• इसके बाद Adobe, Zoom, और अन्य commercial software तक विस्तार संभव है
• लंबी अवधि में यह macOS की तरह system-wide update unification की दिशा में बढ़ सकता है

Microsoft बिखरे हुए app update experience को एकीकृत करने की अपनी कोशिश को फिर से तेज़ कर रहा है, और developers व enterprises की साझेदारी इस ecosystem transition की कुंजी बन सकती है.

[GN⁺]

Hacker News की राय

• Windows में अब भी ऐसी स्थिति बनी हुई है जहाँ Chrome privilege escalation समस्या से बचने के लिए updates संभालने हेतु एक विशेष service का उपयोग करता है, और Spotify जैसे कई apps भी इसी कारण AppData में install होते रहते हैं; कई programs के uninstallers अब भी ठीक से काम नहीं करते, जिससे files या अन्य निशान बचे रह जाते हैं; MSI हमेशा यह मांग करता है कि नई key को एक पुरानी key से sign किया जाए जिसे “chain signing” कहा जाता है, और जब 10 साल से अधिक लंबे समय तक updates manage करने हों तो यह बहुत कठिन समस्या लगती है; उम्मीद है कि किसी दिन यह सब साफ-सुथरे ढंग से व्यवस्थित हो जाएगा
  • Chrome जिस install/update program का उपयोग करता है वह open source Omaha है, और जिन अन्य apps का उल्लेख हुआ है वे Squirrel का उपयोग करते हैं; दोनों को AppData में रखा जा सकता है (खासकर Squirrel केवल user directory में ही install होता है); Squirrel का दर्शन यह है कि admin permission के बिना भी user install कर सके
  • AppData में install करने का कारण privilege escalation से बचने के इरादे को छिपाना नहीं है; Microsoft लगभग 10 साल से भी अधिक समय से AppData installation model को recommend करता रहा है, और आजकल अगर कोई program बिना privilege escalation के चल सकता है, तो AppData installation को ही ‘सही’ तरीका माना जा सकता है
  • non-containerized apps जिनके पास root/admin access होता है, उनके मामले में installer के लिए leftover files को पूरी तरह संभालना लगभग असंभव है; ऐसे apps कहीं भी files बना और लिख सकते हैं, और Microsoft या app vendor द्वारा दिया गया uninstaller भी हर file नहीं ढूंढ सकता; जब तक program के पूरे behavior flow को ठीक-ठीक reproduce न किया जाए, complete removal कठिन है
  • GNU/Linux environment के packages भी अक्सर leftover files छोड़ते हैं
• UniGetUI का पता चला, जो WinGet, Scoop आदि कई package managers को अच्छी तरह invoke करता है और ignore list जैसी customization सुविधाएँ भी देता है; Windows में आम तौर पर इस स्तर की customization की उम्मीद करना कठिन लगता है
• हमेशा यह सवाल रहा कि Windows में macOS जैसा integrated install, update और uninstall framework शुरू से क्यों नहीं था; यह स्पष्ट रूप से एक अनसुलझी कमी लगती है; आज भी enterprise customers को applications manage करने के लिए अलग-अलग खुद packaging करनी पड़ती है; अनुमान है कि शुरुआत से Microsoft ने DLL sharing को बढ़ावा दिया और backward compatibility देनी पड़ी, इसलिए .MSI या उन्नत software management framework को अनिवार्य नहीं किया गया
  • macOS में भी ऐसा integrated framework शुरू से नहीं था; कई apps को बस drag-and-drop से Applications folder में डालना आसान है, लेकिन काफी apps में installer चलाना पड़ता है और system-wide support files install करने के लिए admin authentication मांगा जाता है; कुछ apps अपने खुद के updater को startup पर auto-run भी कराते हैं; पहले extension या control panel elements System Folder में install होते थे और reboot की जरूरत पड़ती थी; और इनमें से काफी apps में अपना uninstaller भी नहीं होता था, इसलिए settings files और cache files वगैरह भी user को खुद ढूंढकर delete करनी पड़ती थीं ताकि reinstall बिना समस्या के हो सके
  • Microsoft के पहले प्रसिद्ध operating system MS-DOS के प्रभाव के कारण, शुरुआती Windows तीसरे पक्ष के software installation के मामले में लगभग DOS की तरह काम करता था; अलग installation concept नहीं था, बस vendor द्वारा दिए गए INSTALL.COM/INSTALL.EXE को चलाया जाता था; आम तौर पर root directory में नया folder बनाकर files copy की जाती थीं, और कुछ मामलों में user खुद folder बनाकर manual copy करता था; app data handling किसी एक खास directory (जैसे C:\Program Files) पर केंद्रित नहीं थी और UNIX की तरह /bin, /etc, /var में विभाजित भी नहीं थी; MS-DOS को IO.SYS, MS-DOS.SYS, CONFIG.SYS, AUTOEXEC.BAT के अलावा files कहाँ हैं, इसकी लगभग कोई परवाह नहीं थी; जब Windows 3.x आम हो गया तब भी यही DOS-style workflow जारी रहा, और ‘integrated installation system’ बहुत देर से आया; .MSI भी काफी बाद में आया, इसलिए पुराने programs ने उसे अपनाया नहीं — यही ऐतिहासिक पृष्ठभूमि है
  • जब macOS पर गया तो यह देखकर सचमुच हैरानी हुई कि सामान्य installation experience Windows से कहीं बेहतर है; download की गई file को बस folder में copy कर देना और installation पूरा हो जाना बहुत प्रभावशाली लगा; और अगर अलग installer चाहिए भी हो, तो वह लगभग हमेशा system-provided familiar flow में होता है, इसलिए असहज नहीं लगता
  • drivers, system extensions, library version management जैसी जटिल समस्याएँ integrated install/uninstall system बनाना कठिन बनाती हैं; अगर internet connection की गारंटी भी न हो तो यह और मुश्किल हो जाता है; और ऐसा feature बना भी दिया जाए तो software vendors को उसे अपनाने के लिए मनाना पड़ेगा, साथ ही यह चिंता भी है कि management इसे नए profit channel की तरह न देखने लगे
  • प्रमुख software vendors आम तौर पर GPO deployment के लिए msi packages उपलब्ध कराते हैं; पिछले 10 सालों में खुद packaging करनी पड़ी हो, ऐसा लगभग याद नहीं; अधिकतर मामलों में बस installation parameters tune करने जैसा हल्का काम होता है; फिर भी सुधार की काफी गुंजाइश अब भी है
• Windows 10 में सभी updates disable करके एक साल से अधिक समय से बिना किसी समस्या के उपयोग कर रहा हूँ; लगता है Microsoft ने ‘update’ शब्द को ही नकारात्मक बना दिया है, और समझ नहीं आता कि Nadella Windows के प्रति इतना उदासीन क्यों दिखते हैं
  • सुरक्षा की चिंता से updates न करने पर कुछ users के लिए खतरा हो सकता है, लेकिन अधिकतर home PCs NAT environment में होते हैं, इसलिए remote vulnerabilities (जैसे EternalBlue) का exploit करना आसान नहीं होता; जब तक Trojan न लग जाए, बड़ी समस्या नहीं होती; browser updated रहे तो व्यावहारिक रूप से काफी सुरक्षित माना जा सकता है; अपवाद यह है कि Trojan लगने पर admin permission के बिना भी documents encrypt किए जा सकते हैं या botnet में शामिल किया जा सकता है, इसलिए केवल Windows updates से हर threat नहीं रुकता
• Windows Update का तरीका सभी Linux package managers द्वारा इस्तेमाल किए जाने वाले मॉडल से बहुत मिलता-जुलता लगता है; लेकिन Chocolatey, Scoop, WinGet जैसे विकल्पों की तुलना में Windows Update बहुत अधिक simple और फीचर-कम लगता है
  • यह जानकर शर्मिंदगी हुई कि WinGet मौजूद है, लेकिन बहुत देर से पता चला; Ubuntu जैसे Linux environments में रहने के बाद Windows package manager खोजते-खोजते बाद में इसका पता चला
  • Windows Update बेहद धीमा महसूस होता है; अगर update components की संख्या या data volume 10 गुना बढ़ जाए, तो वह स्थिति कल्पना से परे लगेगी
• जो सामान्य users developer/advanced user नहीं हैं और Winget/command line से apps update करना उनके लिए कठिन है, उनके लिए open source app UniGetUI की जोरदार सिफारिश; इसका UI intuitive है, management अच्छा है और यह बहुत smooth तरीके से काम करता है
  • UniGetUI project के बारे में पहली बार पता चला और यह वाकई बहुत polished लगा; अच्छी जानकारी साझा करने के लिए धन्यवाद
• इस thread की वजह से UniGetUI जैसा एक बहुत शानदार tool पता चला; अब इसे अपने सभी Windows devices पर ज़रूर install करूंगा; इस app का मुख्य लक्ष्य WinGet, Scoop, Chocolatey, Pip, Npm, .NET Tool, PowerShell Gallery जैसे विभिन्न Windows package managers के लिए intuitive GUI देना है; supported package managers से मनचाहा software आसानी से install/update/delete करने के लिए यह एक आकर्षक app है; लिंक देखें (16.2k stars)
• शंका है कि यह बदलाव ऐसी स्थिति पैदा करेगा जहाँ 7zip update में भी 20 मिनट लगेंगे और reboot भी मांग लिया जाएगा
  • ज़रूरी नहीं कि ऐसा ही हो; Windows Update बहुत से ऐसे updates भी संभालता है जिनमें forced reboot नहीं चाहिए होता, और 7zip को भी शायद इसी तरह configure किया जा सकता है
• अन्य लेखकों की तरह यह बदलाव भी बहुत देर से आया हुआ लगता है, लेकिन वजह सिर्फ यह नहीं कि पहले किसने किया; व्यक्तिगत रूप से लगता है कि Win32 API और desktop apps का युग कम-से-कम 10 साल पहले समाप्त हो चुका था; अब desktop पर install किए गए apps बहुत कम हैं, और अधिकांश users mobile apps तथा web browser पर ज्यादा निर्भर हैं; मैं खुद भी ज्यादातर utilities ही install करता हूँ, और यह Microsoft के business model से भी मेल नहीं खाता; इसलिए सवाल है कि आखिर target users हैं कौन
• चिंता है कि अगर Windows Update service में समस्या आ जाए तो यह बहुत बड़ा single point of failure बन जाएगा; संबंधित search trend से भी दिखता है कि Windows Update का instability का लंबा इतिहास रहा है
  • अगर यह update का एकमात्र साधन बन जाए तो चिंता वास्तविक होगी, लेकिन लगता नहीं कि योजना Windows Update को एकमात्र रास्ता बनाने की है, इसलिए ‘single point’ वाली चिंता उतनी बड़ी नहीं लगती