WinBoat ได้เกิดขึ้นมาเป็นโซลูชันใหม่สำหรับการรันแอปพลิเคชัน Windows บนระบบ Linux โดยวางตำแหน่งตัวเองเป็นทางเลือกแทนเครื่องมือที่มีอยู่แล้วอย่าง WinApps และ Wine ซอฟต์แวร์เบต้าตัวนี้ใช้เทคโนโลยีเสมือนจริงเพื่อสร้างสิ่งที่นักพัฒนาเรียกว่าการรวมเข้าด้วยกันอย่างราบรื่นระหว่างแอป Windows และสภาพแวดล้อมเดสก์ท็อป Linux อย่างไรก็ตาม แนวทางการตลาดของโปรเจกต์นี้ได้จุดประกายการถกเถียงภายในชุมชน Linux เกี่ยวกับความคาดหวังที่สมจริงเทียบกับการอ้างสิทธิ์เพื่อการส่งเสริมการขาย
 |
|---|
| มุมมองของ repository GitHub ของ WinBoat ที่แสดงให้เห็นความก้าวหน้าในการพัฒนาและการมีส่วนร่วมจากชุมชน |
ข้อความที่ขัดแย้งกันเกี่ยวกับประสบการณ์ผู้ใช้
การอภิปรายที่ถกเถียงกันมากที่สุดหมุนรอบข้อความที่ขัดแย้งกันของ WinBoat เกี่ยวกับความง่ายในการใช้งาน ในขณะที่โปรเจกต์โปรโมตการรวมเข้าด้วยกันอย่างราบรื่นและการรันแอปโดยไม่มีปัญหาใดๆ แต่ในเวลาเดียวกันก็เตือนผู้ใช้ให้คาดหวังปัญหาและบั๊ก และแนะนำให้คุ้นเคยกับการแก้ไขปัญหา ความขัดแย้งนี้ทำให้สมาชิกชุมชนบางคนรู้สึกหงุดหงิดที่ต้องการการสื่อสารที่ตรงไปตรงมาเกี่ยวกับข้อจำกัดของซอฟต์แวร์เบต้า
หากมันราบรื่นและไม่มีปัญหา นั่นหมายความว่าไม่มีปัญหาและบั๊ก หากมีปัญหาและบั๊ก มันก็ไม่ราบรื่นและไม่ปราศจากปัญหา
ชุมชนดูเหมือนจะแบ่งออกเป็นสองฝ่ายในการตีความการอ้างสิทธิ์เหล่านี้ โดยบางคนมองว่าการรวมเข้าด้วยกันอย่างราบรื่นเป็นคำอธิบายทางเทคนิคของวิธีที่แอปปรากฏบนเดสก์ท็อป มากกว่าที่จะเป็นคำสัญญาของการทำงานที่ไร้ข้อบกพร่อง
ข้อจำกัดที่ทราบ:
- ไม่รองรับ Podman
- ไม่รองรับ Docker Desktop
- ไม่รองรับการใช้ containerization แบบ rootless
- ไม่มีการเร่งความเร็วด้วย GPU (ต้องทำ GPU passthrough ด้วยตนเอง)
- ต้องมีใบอนุญาต Windows สำหรับ VM
- เป็นซอฟต์แวร์เบต้าที่คาดว่าจะมีข้อบกพร่องและปัญหาต่างๆ
สถาปัตยกรรมทางเทคนิคทำให้เกิดคำถาม
การวิเคราะห์ของชุมชนเผยให้เห็นว่า WinBoat ทำงานโดยการรันเครื่องเสมือน Windows ภายใน Docker container จากนั้นใช้ Remote Desktop Protocol (RDP) กับส่วนขยาย RemoteApp ของ Microsoft เพื่อแสดงแอปพลิเคชัน Windows แต่ละตัวบนเดสก์ท็อป Linux แนวทางนี้ต้องการทรัพยากรระบบและการพึ่งพาที่สำคัญ รวมถึงการเสมือนจริง KVM, Docker, FreeRDP เวอร์ชัน 3.x และโมดูลเคอร์เนลเฉพาะ
นักพัฒนาบางคนตั้งคำถามว่าการตั้งค่าที่ซับซ้อนนี้สมควรที่จะสร้างโปรเจกต์ใหม่หรือไม่ เมื่อฟังก์ชันการทำงานที่คล้ายกันมีอยู่แล้ว เครื่องมือนี้โดยพื้นฐานแล้วห่อหุ้มเทคโนโลยีที่มีอยู่แล้วอย่าง dockur/windows (Windows VM ใน Docker) ด้วยอินเทอร์เฟซที่ใช้งานง่ายที่สร้างด้วย Electron และ Go
ความต้องการของระบบ:
- RAM: ขั้นต่ำ 4 GB
- CPU: ขั้นต่ำ 2 threads
- Storage: พื้นที่ว่าง 32 GB ใน /var
- Virtualization: เปิดใช้งาน KVM ใน BIOS/UEFI
- Dependencies: Docker, Docker Compose v2, FreeRDP 3.x.x พร้อมการรองรับเสียง
- Kernel modules: iptables และ iptable_nat
ทางเลือกและการแข่งขัน
ภูมิทัศน์ของการเล่นเกมบน Linux และความเข้ากันได้ของแอปพลิเคชันมีทางเลือกที่ได้รับการยอมรับหลายตัวที่สมาชิกชุมชนพูดถึงอย่างแข็งขัน Steam กับ Proton ได้รับความนิยมเป็นพิเศษสำหรับการรันแอปพลิเคชัน Windows โดยผู้ใช้รายงานความสำเร็จแม้กับซอฟต์แวร์ที่ไม่ใช่เกม เครื่องมืออย่าง Lutris และ umu-launcher ที่ใหม่กว่าให้โซลูชันที่ใช้ Wine พร้อมฐานข้อมูลความเข้ากันได้ของเกมที่กว้างขวาง
สำหรับผู้ใช้ที่สนใจเฉพาะการรวมแอป Windows อย่างราบรื่น โปรเจกต์ WinApps ต้นฉบับให้ฟังก์ชันการทำงานที่คล้ายกันผ่านสคริปต์ bash แม้ว่าจะต้องการการตั้งค่า Windows VM ด้วยตนเอง ชุมชนสังเกตว่าแม้ WinApps จะขาดอินเทอร์เฟซที่ขัดเกลาของ WinBoat แต่ก็ให้ฟังก์ชัน RemoteApp หลักเดียวกันโดยไม่มีความซับซ้อนเพิ่มเติม
การเปรียบเทียบ WinBoat กับทางเลือกอื่น:
| โซลูชัน | เทคโนโลยี | ความซับซ้อนในการติดตั้ง | การใช้ทรัพยากร | ลิขสิทธิ์ |
|---|---|---|---|---|
| WinBoat | VM + Docker + RDP | ปานกลาง (อัตโนมัติ) | สูง | MIT |
| WinApps | VM + RDP | สูง (ติดตั้งด้วยตนเอง) | สูง | GPLv3 |
| Steam/Proton | ใช้ Wine เป็นฐาน | ต่ำ | ปานกลาง | หลากหลาย |
| Lutris | ใช้ Wine เป็นฐาน | ปานกลาง | ปานกลาง | GPLv3 |
การพิจารณาใบอนุญาตและกฎหมาย
ข้อกังวลที่สำคัญที่ชุมชนยกขึ้นเกี่ยวข้องกับการออกใบอนุญาต Windows สำหรับสภาพแวดล้อมเสมือนจริง เนื่องจาก WinBoat รันการติดตั้ง Windows แบบเต็มภายใน Docker ผู้ใช้ต้องได้รับใบอนุญาต Windows ที่เหมาะสมสำหรับเครื่องเสมือนของพวกเขา ข้อกำหนดนี้เพิ่มต้นทุนและความซับซ้อนทางกฎหมายที่เอกสารของโปรเจกต์ไม่ได้อธิบายอย่างชัดเจน
บทสรุป
WinBoat แสดงถึงความพยายามที่ทะเยอทะยานในการทำให้การเข้าถึงแอปพลิเคชัน Windows บน Linux ง่ายขึ้นผ่านการบรรจุภัณฑ์และการออกแบบอินเทอร์เฟซผู้ใช้ที่ทันสมัย อย่างไรก็ตาม การตอบรับของชุมชนแสดงให้เห็นว่าความสำเร็จจะขึ้นอยู่กับการจัดการความคาดหวังของผู้ใช้อย่างมีประสิทธิภาพมากขึ้นและการแสดงให้เห็นถึงข้อได้เปรียบที่ชัดเจนเหนือโซลูชันที่มีอยู่แล้ว สถานะเบต้าของโปรเจกต์ให้พื้นที่สำหรับการปรับปรุง แต่คำถามพื้นฐานยังคงอยู่ว่าการห่อหุ้มเทคโนโลยีเสมือนจริงที่มีอยู่แล้วในอินเทอร์เฟซใหม่ให้คุณค่าเพียงพอที่จะสมควรกับความซับซ้อนและข้อกำหนดทรัพยากรเพิ่มเติมหรือไม่
อ้างอิง: WinBoat