3 คะแนน โดย GN⁺ 2025-05-29 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Microsoft เปิดตัวพรีวิวของแพลตฟอร์มใหม่ ที่เปิดให้แอปของบุคคลที่สามสามารถอัปเดตผ่าน Windows Update ได้ด้วย
  • แพลตฟอร์ม Windows Update orchestration ใหม่ ถูกออกแบบมาเพื่อให้สามารถ จัดการอัปเดตทั้งหมดแบบรวมศูนย์ รวมถึงไดรเวอร์และแอปธุรกิจ
  • สามารถปรับตารางเวลาอัปเดตให้เหมาะสมได้ตาม กิจกรรมของผู้ใช้ สถานะแบตเตอรี่ และช่วงเวลาพลังงานที่เป็นมิตรต่อสิ่งแวดล้อม
  • รองรับทั้งแอป Win32, MSIX และ APPX และประวัติการอัปเดตแอปจะถูกรวมในประวัติของ Windows Update ด้วย
  • ก้าวข้ามข้อจำกัดของ Microsoft Store หรือ Winget แบบเดิม ๆ และอาจ ครอบคลุมถึงแอปคัสตอมสำหรับองค์กร ได้ด้วย

Windows Update เดินหน้าสู่การเป็นศูนย์กลางของการอัปเดตแอปทั้งหมด

  • Microsoft เพิ่งประกาศแผน ขยาย Windows Update จากเดิมที่ใช้กับการอัปเดต OS และไดรเวอร์ ไปสู่การเป็นแพลตฟอร์มอัปเดตรวมสำหรับทุกแอป
  • การเปลี่ยนแปลงนี้ดูเหมือนจะสะท้อนความต้องการโดยเฉพาะใน สภาพแวดล้อมองค์กรที่ต้องการรวมการจัดการอัปเดตแม้กระทั่งแอปภายใน

ภาพรวมของแพลตฟอร์ม orchestration ใหม่

  • ขณะนี้เปิดให้ใช้งานในชื่อ Windows Update Orchestration Platform ในรูปแบบ private preview
  • เป็นการต่อยอดความสามารถของ Windows Update เดิม เพื่อให้อัปเดตแอปถูกรวมเข้าไปอยู่ในกระบวนการ จัดตารางเวลาและปรับประสบการณ์ใช้งานให้เหมาะสม เช่นกัน

> “เรากำลังสร้าง แพลตฟอร์มอัจฉริยะแบบรวมศูนย์ ที่สามารถ orchestration การอัปเดตทุกประเภท ไม่ว่าจะเป็นแอป ไดรเวอร์ และอื่น ๆ ร่วมกับ Windows Update ได้” — Angie Chen ผู้จัดการผลิตภัณฑ์ของ Microsoft

ปัญหาของแนวทางอัปเดตแอปแบบเดิม

  • แอปบน Windows ส่วนใหญ่ยังคงใช้ ระบบอัปเดตแยกกันตามผู้พัฒนาแต่ละราย
  • ส่งผลให้ ช่วงเวลาและคุณภาพของการอัปเดตไม่สม่ำเสมอ
  • แม้บางแอปจะอัปเดตรวมผ่าน Microsoft Store ได้ แต่ อีกจำนวนมากไม่ได้อยู่ใน Store หรือเป็นแอปภายในสำหรับองค์กร

ฟีเจอร์และข้อดีหลัก

  • ความสามารถในการจัดตารางตาม กิจกรรมผู้ใช้ สถานะแบตเตอรี่ และช่วงเวลาที่เหมาะกับพลังงานอย่างยั่งยืน
  • ผสานเข้ากับระบบแจ้งเตือนและ UI ประวัติเดิมของ Windows Update
  • รองรับทั้งแอป MSIX / APPX รวมถึงแอป Win32 บางส่วน
  • รับช่วงการอัปเดตของตัวแพลตฟอร์มในอนาคตโดยอัตโนมัติ
  • ชี้ให้เห็นถึงความเป็นไปได้ในการ ทดแทน installer แบบเดิม (เช่น แอปขนาดใหญ่ที่รันตัวติดตั้งเบื้องหลังของตัวเองแบบ Adobe ก็อาจเป็นเป้าหมายได้)

เปรียบเทียบกับโซลูชันที่มีอยู่เดิม

วิธีการ คำอธิบาย ข้อเสียหลัก
Microsoft Store จัดการติดตั้งและอัปเดตแอปผ่าน Store แอปที่ลงทะเบียนมีจำกัด และใช้กับแอปองค์กรได้ยาก
Windows Package Manager (winget) เครื่องมือติดตั้ง/อัปเดตแพ็กเกจผ่านบรรทัดคำสั่ง เน้นผู้ใช้ระดับสูงและนักพัฒนาเป็นหลัก ผู้ใช้ทั่วไปไม่ค่อยใช้
Windows Update orchestration รวมการอัปเดต แอปทั่วไปนอกเหนือจาก OS/ไดรเวอร์ ได้ ขณะนี้ยังอยู่ในขั้น private preview

แนวโน้มในอนาคต

  • คาดว่าความต้องการแรกเริ่มจะมาจาก การรวมการอัปเดตแอปองค์กร
  • หลังจากนั้นมีโอกาสขยายไปยัง Adobe, Zoom และซอฟต์แวร์เชิงพาณิชย์อื่น ๆ
  • ในระยะยาวมีทิศทางมุ่งสู่ การรวมศูนย์การอัปเดตทั่วทั้งระบบแบบเดียวกับ macOS

Microsoft กำลังเร่งความพยายามอีกครั้งในการ รวมประสบการณ์การอัปเดตแอปที่กระจัดกระจาย และดูเหมือนว่า การที่นักพัฒนาและองค์กรจะเข้ามาร่วมมือมากน้อยเพียงใด จะเป็นกุญแจสำคัญของการเปลี่ยนผ่านระบบนิเวศนี้

1 ความคิดเห็น

 
GN⁺ 2025-05-29
ความคิดเห็นบน Hacker News
  • ยังมีสถานการณ์บน Windows ที่ Chrome ยังคงจัดการอัปเดตผ่านบริการพิเศษเพื่อหลีกเลี่ยงปัญหาการยกระดับสิทธิ์ และแอปจำนวนมากอย่าง Spotify ก็ยังคงติดตั้งลงใน AppData ด้วยเหตุผลเดียวกัน นอกจากนี้ตัวถอนการติดตั้งของหลายโปรแกรมก็ยังทำงานได้ไม่สมบูรณ์จนทิ้งไฟล์หรือร่องรอยอื่น ๆ ไว้ อีกทั้ง MSI ยังบังคับให้ใช้คีย์เก่าในการ “chain sign” คีย์ใหม่ไปตลอด ซึ่งเป็นปัญหาที่รู้สึกว่ายุ่งยากมากเมื่อจำเป็นต้องดูแลการอัปเดตเป็นเวลายาวนานเกิน 10 ปี หวังว่าสักวันหนึ่งเรื่องทั้งหมดนี้จะถูกจัดระเบียบให้เรียบร้อยเสียที
    • ตัวติดตั้ง/อัปเดตที่ Chrome ใช้คือ Omaha แบบโอเพนซอร์ส และแอปอื่นที่ถูกกล่าวถึงใช้ Squirrel ซึ่งทั้งคู่สามารถอยู่ใน AppData ได้ โดยเฉพาะ Squirrel จะติดตั้งได้เฉพาะในไดเรกทอรีของผู้ใช้เท่านั้น เพราะแนวคิดของ Squirrel คือทำให้ผู้ใช้ติดตั้งได้โดยไม่ต้องมีสิทธิ์ผู้ดูแลระบบ
    • เหตุผลที่ติดตั้งใน AppData ไม่ใช่เพื่อซ่อนหรือเลี่ยงการยกระดับสิทธิ์ แต่เป็นผลจากการที่ Microsoft แนะนำแนวทางติดตั้งใน AppData มานานเกือบ 10 ปีขึ้นไป และทุกวันนี้ถ้าเป็นโปรแกรมที่ทำงานได้โดยไม่ต้องยกระดับสิทธิ์ ก็คิดว่าการติดตั้งใน AppData คือวิธีที่ ‘ถูกต้อง’
    • สำหรับแอปที่ไม่ได้อยู่ในคอนเทนเนอร์และมีสิทธิ์เข้าถึงระดับ root/ผู้ดูแลระบบ มองว่าแทบเป็นไปไม่ได้เลยที่ตัวติดตั้งจะจัดการไฟล์ตกค้างได้อย่างสมบูรณ์ แอปเหล่านี้สามารถสร้างและเขียนไฟล์ในไดเรกทอรีไหนก็ได้ และแม้แต่ตัวถอนการติดตั้งที่ Microsoft หรือผู้ให้บริการแอปจัดให้ก็ไม่สามารถค้นหาไฟล์ทั้งหมดได้ มองว่าหากไม่จำลองลำดับการทำงานทั้งหมดของโปรแกรมขึ้นมาใหม่ ก็ลบออกให้หมดจริง ๆ ได้ยาก
    • แพ็กเกจในสภาพแวดล้อม GNU/Linux จำนวนมากก็ทิ้งไฟล์ตกค้างเช่นกัน
  • ได้ค้นพบ UniGetUI ซึ่งช่วยเรียกใช้แพ็กเกจแมเนเจอร์หลายตัวอย่าง WinGet, Scoop ได้ดี และยังมีฟีเจอร์ปรับแต่งอย่างรายการยกเว้นด้วย คิดว่าบน Windows ปกติคงคาดหวังความสามารถในการปรับแต่งระดับนี้ได้ยาก
  • สงสัยมาตลอดว่าทำไม Windows ถึงไม่มีเฟรมเวิร์กการติดตั้ง อัปเดต และลบออกแบบรวมศูนย์ตั้งแต่แรกเหมือน macOS มองว่าเป็นช่องโหว่ที่ชัดเจนและยังไม่เคยถูกแก้ ทุกวันนี้ลูกค้าองค์กรก็ยังต้องแพ็กแอปกันเองทีละตัวเพื่อจัดการแอปพลิเคชัน คาดว่าสาเหตุคือ Microsoft ส่งเสริมการแชร์ DLL มาตั้งแต่แรกและต้องรักษาความเข้ากันได้ย้อนหลัง จึงไม่ได้บังคับให้ใช้ .MSI หรือเฟรมเวิร์กจัดการซอฟต์แวร์ที่ก้าวหน้ากว่านี้
    • macOS เองก็ไม่ได้มีเฟรมเวิร์กแบบรวมศูนย์เช่นนั้นมาตั้งแต่แรก หลายแอปติดตั้งง่ายด้วยการลากแล้ววางลงในโฟลเดอร์ Applications แต่ก็มีอีกมากที่ต้องรันตัวติดตั้ง และมักขอการยืนยันสิทธิ์ผู้ดูแลเพื่อวางไฟล์สนับสนุนในระดับทั้งระบบ แต่ละแอปก็อาจมีตัวอัปเดตของตัวเองที่รันอัตโนมัติตอนเปิดเครื่องด้วย สมัยก่อนยังจำได้ว่ามีส่วนขยายหรือองค์ประกอบของแผงควบคุมที่ต้องติดตั้งลงใน System Folder และต้องรีบูต และในบรรดาแอปเหล่านี้ก็มีจำนวนมากที่ไม่มีฟังก์ชันถอนการติดตั้งของตัวเอง ทำให้ต้องไปตามลบไฟล์ตั้งค่าและไฟล์แคชเองจึงจะติดตั้งใหม่ได้โดยไม่มีปัญหา
    • เนื่องจากได้รับอิทธิพลจาก MS-DOS ซึ่งเป็นระบบปฏิบัติการตัวแรกที่มีชื่อเสียงของ Microsoft ทำให้ Windows ยุคแรกทำงานจากมุมมองการติดตั้งซอฟต์แวร์ภายนอกแทบไม่ต่างจาก DOS คือไม่มีแนวคิดเรื่องการติดตั้งแบบแยกเฉพาะ แต่ใช้วิธีรัน INSTALL.COM/INSTALL.EXE ที่ผู้ขายให้มา โดยทั่วไปจะสร้างโฟลเดอร์ใหม่ในไดเรกทอรีรากแล้วคัดลอกไฟล์ลงไป และบางกรณีก็ให้ผู้ใช้สร้างโฟลเดอร์แล้วคัดลอกด้วยตนเอง งานจัดการข้อมูลของแอปทั้งหมดจึงกระจุกอยู่ในไดเรกทอรีเฉพาะ เช่น C:\Program Files แทนที่จะแยกแบบ UNIX เป็น /bin, /etc, /var โครงสร้างของ MS-DOS แทบไม่สนใจตำแหน่งของไฟล์ใด ๆ เลยนอกเหนือจาก IO.SYS, MS-DOS.SYS, CONFIG.SYS, AUTOEXEC.BAT และเมื่อ Windows 3.x เริ่มแพร่หลาย แนวทางการทำงานแบบ DOS นี้ก็ยังคงสืบต่อมา ทำให้ ‘ระบบติดตั้งแบบรวมศูนย์’ ถูกนำมาใช้ช้ามาก และ .MSI เองก็ถูกนำมาใช้ค่อนข้างช้าเช่นกัน จึงมีภูมิหลังทางประวัติศาสตร์ที่ทำให้โปรแกรมเดิมจำนวนมากไม่ได้ปรับใช้
    • ตอนย้ายไปใช้ macOS รู้สึกประหลาดใจมากที่ประสบการณ์การติดตั้งแบบทั่วไปดีกว่า Windows มาก ความง่ายของการติดตั้งที่แค่คัดลอกไฟล์ดาวน์โหลดลงโฟลเดอร์ก็เสร็จนั้นน่าประทับใจ แม้ในกรณีที่ต้องใช้ตัวติดตั้งแยก ก็มักเป็นขั้นตอนมาตรฐานที่ระบบมีให้อยู่แล้วจึงรู้สึกคุ้นเคยและไม่เป็นภาระ
    • ปัญหาซับซ้อนอย่างไดรเวอร์, system extension, การจัดการเวอร์ชันของไลบรารี ทำให้การสร้างระบบติดตั้ง/ถอนการติดตั้งแบบรวมศูนย์เป็นเรื่องยาก และถ้ายังไม่สามารถรับประกันการเชื่อมต่ออินเทอร์เน็ตได้ก็ยิ่งลำบาก ต่อให้สร้างความสามารถนี้ขึ้นมาได้ ก็ยังต้องโน้มน้าวให้ผู้ขายซอฟต์แวร์ใช้งานมันด้วย และก็กังวลว่าฝ่ายบริหารอาจไม่มองว่านี่เป็นช่องทางทำกำไรใหม่
    • ผู้ขายซอฟต์แวร์รายใหญ่โดยทั่วไปก็มักมีแพ็กเกจ msi สำหรับการแจกจ่ายผ่าน GPO ให้อยู่แล้ว ตลอด 10 ปีที่ผ่านมาแทบจำไม่ได้เลยว่าต้องแพ็กเอง โดยมากก็แค่ปรับพารามิเตอร์การติดตั้งเล็กน้อยเท่านั้น แม้ว่าจะยังมีพื้นที่ให้ปรับปรุงอีกมากก็ตาม
  • ใช้งาน Windows 10 โดยปิดการอัปเดตทั้งหมดมานานกว่าหนึ่งปีแล้วโดยไม่มีปัญหาอะไร รู้สึกว่า Microsoft ทำให้คำว่า ‘อัปเดต’ กลายเป็นคำในแง่ลบ และไม่เข้าใจว่าทำไม Nadella ถึงไม่แสดงความใส่ใจต่อ Windows มากขนาดนี้
    • อาจมีผู้ใช้ที่ถ้าไม่อัปเดตแล้วจะเกิดปัญหาใหญ่เพราะกังวลเรื่องความปลอดภัย แต่พีซีตามบ้านส่วนใหญ่อยู่หลัง NAT จึงยากที่จะถูกโจมตีช่องโหว่จากระยะไกลอย่าง EternalBlue และหากไม่ติดโทรจันก็มักไม่มีปัญหาใหญ่ มองว่าแค่เบราว์เซอร์เป็นเวอร์ชันล่าสุดก็ปลอดภัยในทางปฏิบัติแล้ว ข้อยกเว้นคือแม้ติดโทรจันก็ยังเข้ารหัสเอกสารหรือเข้าร่วมบอตเน็ตได้โดยไม่ต้องใช้สิทธิ์ผู้ดูแลระบบ จึงมีความเห็นว่า Windows Update เพียงอย่างเดียวไม่ได้ป้องกันภัยคุกคามทั้งหมด
  • คิดว่าวิธีการของ Windows Update คล้ายกับแนวทางที่แพ็กเกจแมเนเจอร์ของลินุกซ์ทั้งหมดใช้มาก เพียงแต่เมื่อเทียบกับทางเลือกอื่นอย่าง Chocolatey, Scoop, WinGet แล้ว Windows Update ดูเรียบง่ายเกินไปและขาดความสามารถหลายอย่าง
    • รู้สึกอายที่เพิ่งมารู้ช้ามากว่ามี WinGet อยู่ หลังจากใช้ชีวิตในสภาพแวดล้อมลินุกซ์อย่าง Ubuntu แล้วลองค้นหาแพ็กเกจแมเนเจอร์สำหรับ Windows จึงเพิ่งมารู้ทีหลัง
    • Windows Update ให้ความรู้สึกว่าช้ามาก ถ้าจำนวนคอมโพเนนต์ที่ต้องอัปเดตหรือปริมาณข้อมูลเพิ่มขึ้น 10 เท่า ก็นึกภาพแทบไม่ออกเลยว่าจะเป็นอย่างไร
  • ถ้าเป็นผู้ใช้ทั่วไปที่ไม่ใช่นักพัฒนาหรือผู้ใช้ระดับสูง และการอัปเดตแอปด้วย Winget/บรรทัดคำสั่งเป็นเรื่องยาก ก็แนะนำแอปโอเพนซอร์ส UniGetUI อย่างมาก เพราะ UI ใช้งานเข้าใจง่าย ดูแลได้ดี และทำงานได้ลื่นไหลมาก
    • เพิ่งได้รู้จักโปรเจกต์ UniGetUI เป็นครั้งแรก และรู้สึกว่ามันดูประณีตมาก ขอบคุณสำหรับการแบ่งปันข้อมูลดี ๆ
  • เธรดนี้ทำให้ได้รู้จัก UniGetUI ซึ่งเป็นเครื่องมือที่ยอดเยี่ยมมาก และตั้งใจว่าจะติดตั้งมันบนอุปกรณ์ Windows ทุกเครื่องต่อจากนี้ไป เป้าหมายหลักของแอปนี้คือการให้ GUI ที่เข้าใจง่ายสำหรับแพ็กเกจแมเนเจอร์บน Windows หลายตัว เช่น WinGet, Scoop, Chocolatey, Pip, Npm, .NET Tool, PowerShell Gallery ทำให้ติดตั้ง/อัปเดต/ลบซอฟต์แวร์ที่ต้องการจากแพ็กเกจแมเนเจอร์ที่รองรับได้อย่างสะดวก เป็นแอปที่น่าสนใจมาก ดู ลิงก์ (มี 16.2k stars)
  • สงสัยว่าการเปลี่ยนแปลงนี้อาจทำให้เกิดสถานการณ์ที่แม้แต่อัปเดต 7zip ก็ต้องใช้เวลา 20 นาทีและยังต้องรีบูตอีกด้วย
    • คิดว่าไม่จำเป็นต้องเป็นเช่นนั้นเสมอไป มีอัปเดตจำนวนมากใน Windows Update ที่ไม่ได้บังคับให้รีบูต และมองว่า 7zip ก็น่าจะตั้งค่าให้ทำงานในลักษณะเดียวกันได้
  • เช่นเดียวกับผู้เขียนคนอื่น ๆ รู้สึกว่าการเปลี่ยนแปลงครั้งนี้ช้าไปมากแล้ว แต่เหตุผลไม่ใช่แค่ว่าใครทำก่อน เพราะส่วนตัวมองว่ายุคของ Win32 API และแอปเดสก์ท็อปจบลงไปอย่างน้อย 10 ปีแล้ว ตอนนี้แอปที่ติดตั้งบนเดสก์ท็อปเหลืออยู่ไม่มาก และผู้ใช้ส่วนใหญ่พึ่งพาแอปมือถือกับเว็บเบราว์เซอร์มากกว่า สิ่งที่ติดตั้งเองก็มักเป็นพวกยูทิลิตี ซึ่งก็ไม่สอดคล้องกับโมเดลธุรกิจของ Microsoft ด้วย สุดท้ายจึงสงสัยว่าผู้ใช้เป้าหมายจริง ๆ คือใคร
  • กังวลว่านโยบายนี้จะสร้างจุดล้มเหลวเพียงจุดเดียวขนาดใหญ่ หากบริการ Windows Update มีปัญหา ดังที่เห็นได้จาก เทรนด์การค้นหาที่เกี่ยวข้อง ว่า Windows Update มีประวัติความไม่เสถียรมายาวนาน
    • หากกลายเป็นช่องทางอัปเดตเพียงช่องทางเดียว ความกังวลนั้นก็คงเป็นจริง แต่ดูเหมือนจริง ๆ แล้วไม่ได้มีแผนจะทำให้ Windows Update เป็นเส้นทางเดียว จึงคิดว่าความกังวลเรื่อง ‘single point’ ไม่ได้ร้ายแรงมากนัก