1 คะแนน โดย GN⁺ 2025-05-20 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • มีการยืนยันอย่างเป็นทางการถึงการพัฒนา Karton ตัวจัดการเครื่องเสมือน สำหรับ KDE Plasma โดยเฉพาะ
  • โครงการนี้สร้างบนพื้นฐานของ Qt Quick และ Kirigami จึงถูกปรับให้เหมาะกับสภาพแวดล้อม KDE
  • ตั้งเป้าใช้ libvirt API เพื่อควบคุมเครื่องเสมือนหลากหลายแบบ และรองรับหลายแพลตฟอร์มในอนาคต
  • ฟีเจอร์หลักได้แก่ SPICE viewer แบบคัสตอม, snapshot, อินเทอร์เฟซที่ใช้งานง่าย และการสลับไฮเปอร์ไวเซอร์ระหว่างระบบ/ผู้ใช้
  • ตามกำหนดการของ Google Summer of Code 2025 คาดว่า จะเสร็จสมบูรณ์ราวเดือนกันยายน 2025

ที่มาและความจำเป็นของการพัฒนา Karton

  • ในฝั่ง GNOME มี เครื่องมือรันเครื่องเสมือน ที่ใช้งานง่ายและสม่ำเสมออย่าง GNOME Boxes ให้ใช้อยู่แล้ว
  • ผู้ใช้ KDE เคยใช้ทางเลือกอย่าง qt-virt-manager ที่ค่อนข้างเก่า แต่ต้องเผชิญทั้งการหยุดพัฒนาและ ปัญหาที่ขาดความเป็น KDE โดยเฉพาะ
  • ทำให้ความต้องการ โซลูชันจัดการ VM ที่ผสานเข้ากับ KDE Plasma รุ่นใหม่ได้อย่างเป็นธรรมชาติ สูงขึ้น

ภาพรวมโครงการ Karton

  • Karton เริ่มต้นจากความพยายามทำ ฟรอนต์เอนด์ของ QEMU ก่อนที่ Harald Sitter นักพัฒนา KDE จะผลักดันต่ออย่างจริงจังในฐานะโครงการ Google Summer of Code
  • ขณะนี้ Derek Lin จาก University of Waterloo กำลังพัฒนาอย่างต่อเนื่องในฐานะผู้เข้าร่วม Google Summer of Code 2025
  • เป้าหมายของ Karton คือ มอบเครื่องมือจัดการเครื่องเสมือนแบบเนทีฟที่เหมาะกับระบบนิเวศ KDE

เทคโนโลยีหลักและจุดเด่น

  • Karton พัฒนาด้วย Qt Quick และ Kirigami เพื่อให้ทำงานร่วมกับ KDE Plasma ได้อย่าง กลมกลืนทั้งด้านภาพลักษณ์และประสบการณ์ใช้งาน
  • ใช้ libvirt API เพื่อจัดการเครื่องเสมือนและรองรับการขยายความสามารถ พร้อมคำนึงถึง การรองรับหลายแพลตฟอร์ม ในอนาคต
  • แทนที่จะเรียกใช้ virt-install CLI โดยตรง โครงการกำลังใช้ libosinfo เพื่อทำการรู้จำอิมเมจระบบปฏิบัติการอัตโนมัติและสร้าง libvirt XML แบบอัตโนมัติ
  • การขยายการรองรับ การตั้งค่าอุปกรณ์และไฮเปอร์ไวเซอร์หลายประเภท ก็เป็นอีกหนึ่งงานพัฒนาสำคัญ

ฟีเจอร์หลักและกำหนดการเป้าหมาย

ฟีเจอร์ที่ Lin ระบุไว้ในข้อเสนอ Google Summer of Code มีดังนี้

  • การติดตั้งและตั้งค่าเครื่องเสมือนผ่าน libvirt XML format
  • การพัฒนา SPICE viewer แบบคัสตอมบน Qt Quick (มาแทน virt-viewer)
  • ฟีเจอร์ snapshot ของเครื่องเสมือน (สำรอง/กู้คืน)
  • GUI และหน้าพรีวิว ที่ใช้งานง่ายและสวยงาม พร้อม สะท้อนข้อเสนอแนะจากชุมชน
    • อ้างอิงดีไซน์จากเลย์เอาต์รายการของ MacOS UTM
    • รองรับอินเทอร์เฟซที่เหมาะกับอุปกรณ์พกพา
  • จัดการ การอัปเดตสถานะแบบเรียลไทม์ อย่างมีประสิทธิภาพด้วยฟังก์ชัน virEventRegisterImpl
  • ฟังก์ชัน browse สำหรับแสดงรายการระบบปฏิบัติการหลัก
  • กราฟการใช้ GPU/หน่วยความจำ (สไตล์ virt-manager)
  • ฟังก์ชันสลับโหมดของ QEMU hypervisor ระหว่าง session (ผู้ใช้)/system (root)

กำหนดการพัฒนา

  • วันเริ่มเขียนโค้ดอย่างเป็นทางการของ Google Summer of Code 2025 คือ 2 มิถุนายน 2025
  • มีแผนให้ ต้นแบบสำหรับการประเมินกลางภาคเสร็จภายใน 14 กรกฎาคม และ ส่งผลงานฉบับสมบูรณ์ขั้นสุดท้ายภายใน 1 กันยายน

บทสรุป

  • Karton คือโครงการใหม่ที่อาจเข้ามาแก้ปัญหา การขาดแคลนเครื่องมือจัดการเครื่องเสมือนแบบเนทีฟที่เหมาะกับ KDE ซึ่งค้างคามายาวนาน
  • การที่มันมอบทั้งรูปลักษณ์และการใช้งานที่สอดคล้องกับ เทคโนโลยีสมัยใหม่หลักของ Qt และ KDE ทำให้เป็นความเปลี่ยนแปลงที่มีความหมายทั้งต่อผู้ใช้ Linux เดสก์ท็อปและนักพัฒนา

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

 
GN⁺ 2025-05-20
ความคิดเห็นบน Hacker News
  • สำหรับ KDE ผมคิดว่าควรโฟกัสกับฟังก์ชันพื้นฐานอย่างการจัดเรียงหน้าต่าง การเรนเดอร์หน้าต่าง และไอคอนตัวเรียกแอป ถ้าต้องการ VM ก็ใช้ซอฟต์แวร์ VM แยกไปเลย ชุดซอฟต์แวร์แบบบูรณาการของ KDE มีบางตัวที่ดี แต่ผมไม่คิดว่าจำเป็นต้องผูกกับเดสก์ท็อปเอนไวรอนเมนต์เสมอไป มีแค่ตัวจัดการไฟล์, VTE และตัวแก้ไขข้อความก็น่าจะพอ อยากให้ไอคอนถูกดูแลแยกในแต่ละแอปมากกว่า ความพยายามทำไอคอนแบบรวมศูนย์กลับสร้างแต่ปัญหา เช่น ไอคอนไม่ขึ้น หรือไอคอนสีดำบนพื้นดำ

    • ดูเหมือนจะสับสนระหว่าง KDE project กับ Plasma อยู่ Plasma คือเดสก์ท็อปเอนไวรอนเมนต์ ส่วน KDE project พัฒนาและแจกจ่ายแอปจำนวนมาก แอป KDE หลายตัวทำงานได้บน OS อื่นอย่าง Windows ด้วย และคุณสามารถติดตั้งแค่ Plasma โดยไม่ต้องใช้แอป KDE ตัวอื่นเลยก็ได้ ในเชิงประวัติศาสตร์คนเคยเรียกเดสก์ท็อปเอนไวรอนเมนต์นี้ว่า KDE แต่ตอนนี้มันเป็นแค่หนึ่งในซอฟต์แวร์จำนวนมากที่ KDE project พัฒนาเท่านั้น เรื่องธีมไอคอนผมก็ไม่เห็นด้วยเหมือนกัน และผมเองก็ไม่ใช้ธีมไอคอนด้วย

    • KDE พัฒนาเครื่องมือหลากหลายมานานกว่า 20 ปีแล้ว ทั้งเบราว์เซอร์ ไคลเอนต์อีเมล แอปจัดการรายชื่อติดต่อ ฯลฯ ตั้งแต่สมัย KDE 1 ก็มีตัวสำรวจไฟล์แล้ว และชุดออฟฟิศก็อยู่ระหว่างการพัฒนาด้วย ชุดผลิตภัณฑ์ของ KDE มีมาตั้งแต่แรก Plasma เป็นเพียงส่วนเล็กมากของสิ่งที่ KDE พัฒนา ถ้าต้องการแค่บทบาทแบบ window manager ก็มีทางเลือกที่มินิมอลกว่ามาก เช่น LXDE, Hyprland, Sway, i3

    • ความพยายามทำไอคอนให้เป็นทรัพยากรร่วมและผนวกเข้ากับแอปนั้นล้มเหลวมาโดยตลอด ชุมชน GNOME ทำเรื่องนี้ได้ดี ดู https://stopthemingmy.app/ การรองรับความสอดคล้องของธีมข้ามแอปเป็นเพียงภาพฝันยุค 90 และในทางปฏิบัติก็ดูดีได้แค่ตอนแคปหน้าจอเท่านั้น

    • ด้วยเหตุนี้ผมเลยย้ายไปใช้ sway ผมคิดว่าจำเป็นต้องมีการเชื่อมต่อกันระหว่างส่วนต่าง ๆ ของระบบ แต่แต่ละส่วนก็ควรถูกแยกออกจากกัน gnome กับ kde จะโอเคก็ต่อเมื่อใช้ทั้งชุดทั้งหมดเท่านั้น XFCE กลับโมดูลาร์กว่ามาก

  • น่าเสียดายนิดหน่อยที่คอมเมนต์ส่วนใหญ่พูดเรื่องอื่นนอกจากตัวบทความ ผมค่อนข้างตื่นเต้นกับการเปิดตัว VM manager ใหม่ ปกติใช้ virt-manager แต่แทบไม่ได้รับการดูแลแล้ว ทำให้มีปัญหาสเกลบนจอ HiDPI หนักมาก GNOME Boxes ก็มีบั๊กเยอะและฟีเจอร์น้อย ดูเหมือนคนจะสนใจแค่ CLI อย่าง virsh กัน ตอนนี้เลยแทบไม่มี VM GUI ที่น่าใช้

  • ผมใช้ KDE Plasma บน Arch และชอบสภาพแวดล้อมนี้มาก มีตัวกรองแสงสีฟ้าในตัวด้วย ไม่คิดจะกลับไป Windows แล้ว KDE เร็วกว่า สวยกว่า และไม่มีโฆษณาหรือการติดตามที่ไม่ต้องการ ยอดเยี่ยมที่สุดสำหรับการใช้งานประจำวัน

    • ตอนนี้กำลังทดสอบ Cachy กับ Plasma ใน VM และมีแผนจะติดตั้งคู่นี้ลงเครื่องถัดไปเลย ตอนนี้ยังดูอัลบูต Ubuntu กับ Windows อยู่ แต่ไม่ได้ล็อกอิน Windows มาเกิน 6 เดือนแล้ว คิดว่าเครื่องหน้าคงไม่ติดตั้งดูอัลบูตเลยด้วยซ้ำ

    • ผมใช้ gnome อยู่ปีหนึ่งแล้วก็กลับมา plasma อีกครั้ง gnome ใช้งานลำบากเกินไป ต้องอาศัยส่วนขยายเป็นทางออกชั่วคราว แต่พออัปเดตก็พังทันที อินเทอร์เฟซภาษาอังกฤษและการตั้งค่าหน่วยแบบ ISO ก็ยุ่งยาก จะจัดการโปรแกรมเริ่มต้นพร้อมระบบก็ต้องลงแอปแยก การสเกลหน้าจอ หลายจอ และการอัดหน้าจอล้วนแย่ จอ 60fps แต่เมาส์กระตุก ซ่อนคีย์บอร์ดสวีเดน ซามี และ svdvorak ก็แทบไม่ช่วยอะไร คัดลอกวางข้ามจอไม่ได้ alt+tab เปลี่ยนหน้าต่างแล้ว drag & drop ไม่ทำงาน ถ้ามี context menu โผล่มา โฟกัสทั้งระบบจะถูกล็อก เช่น เปิดกล่องคัดลอกไฟล์ของ Nautilus แล้วจะคลิกแอปอื่นไม่ได้ พอเผลอลองใช้ KDE ใน VM ก็รู้เลยว่าไม่มีเหตุผลต้องทนกับความไม่สะดวกของ gnome อีกต่อไป วันนั้นก็กลับไป opensuse ทันที

    • ผมลองใช้ KDE 1.0 ครั้งแรกเมื่อราว 20 ปีก่อน ตอนนั้นมันก็มีกลิ่นอายเลียนแบบ Windows อยู่บ้าง แต่เท่าที่จำได้ ความสมบูรณ์กลับดีกว่าด้วยซ้ำ

    • ผมใช้ Ubuntu + Plasma เป็นเครื่องหลักมา 3 ปีแล้ว มันคือภาพที่ Windows 7 เคยใฝ่ฝันไว้ ในมุมของวิศวกร dotnet และ devops ช่วงทศวรรษ 2020 คือยุคที่ Linux toolchain กับโอเพนซอร์สลงตัวสมบูรณ์ Rider, datagrip, vscode ทุกอย่างทำงานดีหมด ไม่มีความยุ่งยากแบบ docker หรือ wsl ด้วย จะบูต Windows ก็ต่อเมื่อต้องรัน .NET Framework รุ่นเก่าเท่านั้น และตอนนี้ตั้งค่าให้บูต Windows NVMe ผ่าน VM ได้แล้ว เลยรู้สึกว่าน่าจะหนีออกมาได้อย่างสมบูรณ์ทุกเมื่อ

  • สิ่งที่ KDE ต้องการไม่ใช่ฟีเจอร์ใหม่ แต่คือการลดบั๊ก

    • ผมเองก็เคยบ่นเรื่องบั๊กของ KDE ตลอด แต่ตั้งแต่เวอร์ชัน 6.3 เป็นต้นมา 10 ปีแล้วที่ยังไม่เจอบั๊กหนัก ๆ เลย ถ้าเป็นคนที่พักจากมันไปสักพัก ตอนนี้น่าลองกลับมาใช้อีกครั้ง

    • ผมก็รู้สึกคล้ายกัน พยายามหลายครั้งแล้วแต่ KDE มักให้ความรู้สึกด้อยกว่า gnome ในด้านเสถียรภาพและความเนี้ยบ น่าจะเป็นเพราะ KDE เน้นการปรับแต่งได้สูง แนวคิดดีนะ แต่ดูแลรักษายาก และดูเหมือนนักพัฒนาจะถูกดึงดูดให้เพิ่มฟีเจอร์ใหม่มากกว่าปิดบั๊ก

  • อยากให้ KDE มีโซลูชัน VM แบบบูรณาการ ถ้าแอปที่รันอยู่ใน VM โผล่มาเป็นหน้าต่างแบบ Kwin ได้ก็คงดีมาก อาจต้องมี helper daemon ใน guest OS ด้วย เคยมีฟีเจอร์คล้ายกันมาก่อน แต่ถ้า DE หลักรองรับอย่างเป็นทางการก็คงยอดเยี่ยมมาก

    • น่าแปลกที่บน Windows ฟีเจอร์นี้มีผ่าน WSL2 ผมเคยลองรัน "nautilus" เล่น ๆ แล้วตกใจเลย

    • ผมกำลังทำประสบการณ์ที่เกือบเหมือนกันด้วย VirtualBox บนโน้ตบุ๊ก เปิดหลาย VM และเมื่อเสียบจอนอกก็ปรับขนาดหน้าต่างได้ตามใจ พอถอดจอหน้าต่างก็ย่อกลับอัตโนมัติ มีการแชร์คลิปบอร์ด ฯลฯ จนเกือบเหมือนเนทีฟ แยก VM ตามงาน เช่น ใช้ท่องเว็บประจำวัน หรือใช้สำหรับโปรเจกต์สัญญาจ้าง กำหนด virtual desktop ให้ฝั่งโฮสต์ และใช้เดสก์ท็อปเดียวใน VM ตั้งค่าให้ alt+tab ทำงานเฉพาะใน VM ต้องแบกรับทั้งบั๊กจุกจิกของ VirtualBox และความเสี่ยงด้านกฎหมายจาก Oracle แต่ก็ยังยึด VirtualBox เพราะ QEMU หรือ KVM ยังไม่สมบูรณ์พอสำหรับผม

    • ในเชิงเทคนิคต้องอาศัยการแฮ็กค่อนข้างมาก บน OS แบบปิดทำได้ยาก และมีแค่ Windows ที่รองรับผ่าน RDP

    • คุณยังลองวิธีที่เบาและใช้ทรัพยากรน้อยกว่าได้ เช่น debboostrap กับ chroot mounting

    • ในบรรดาโซลูชันปัจจุบันยังไม่มีตัวไหนรองรับได้สมบูรณ์ X11 forwarding ทำได้ก็จริง แต่ต้องตั้งค่าและไม่ลื่นไหลนัก บน Linux ผมยังไม่เจอ client/server แบบเนทีฟที่รองรับสิ่งนี้ได้ดี

  • ดีใจมากที่มีทางเลือกแทน virt-manager โดยเฉพาะที่มันใช้ Qt ด้วย แต่ก็เสียดายที่เลือกใช้ Kirigami กับ Qt Quick ผมรู้สึกว่าทั้งหน้าตาและฟังก์ชันสู้ Qt Widgets ไม่ได้

    • ผมคิดว่าควรมีทางเลือกแทน virt-manager สักตัว ตอนนี้แม้แต่ฟีเจอร์ธรรมดาอย่างค้นหาข้อความใน XML หรือ undo ก็ยังใช้งานลำบาก การตั้งชื่อให้มี KDE นำหน้านั้นดูเชยไปหน่อย แต่ชื่อ Karton อย่างน้อยก็ดีกว่า

    • Plasma shell เองก็สร้างบน Kirigami และ Qt Quick อยู่แล้ว ดังนั้นแทบไม่มีอะไรที่ผสานรวมได้สอดคล้องไปกว่านี้อีก

    • อาการหน่วงแบบเฉพาะของ QML rendering จะหลีกเลี่ยงได้ก็ต่อเมื่อมีไลเซนส์ Qt แบบเชิงพาณิชย์ แต่ข้อดีคือสามารถสร้างแอปด้วยไวยากรณ์คล้าย JSON ได้

    • Qt Quick มีความเป็นเครื่องมือทั่วไปมากกว่า ส่วน Kirigami เป็นเลเยอร์ที่เฉพาะทางกว่าซึ่งอยู่ด้านบนมัน

  • ผมชอบความสมบูรณ์และความครบเครื่องของ KDE แต่ดีไซน์มันให้ความรู้สึกเก่าเมื่อเทียบกับ OS หรือ DM สมัยนี้ ถึงจะปรับแต่งได้ แต่ยิ่งปรับก็ยิ่งช้าและดูแปลก ๆ นี่แหละเหตุผลที่ผมเลือก gnome

    • ผมว่าก็น่าสนใจดีที่หลายคนกลับมีความเห็นตรงกันข้ามสุดขั้ว สำหรับผม KDE นี่แหละคือสภาพแวดล้อมเดียวที่ดูโมเดิร์นและสวยจริง

    • สงสัยว่าเคยลอง Plasma 6 หรือยัง ส่วนตัวผมรู้สึกว่ามันทันสมัยกว่า gnome มาก

    • ผมคิดว่าดีไซน์ของ KDE ดีกว่า Windows มาก Windows เหมือนคอยทำลายสถิติความแย่ของดีไซน์เดสก์ท็อปตัวเองอยู่เรื่อย ๆ

    • ถ้ามีแค่เพิ่มเมนูแฮมเบอร์เกอร์เข้ามา ผมก็พร้อมย้ายกลับ KDE ทันที เพิ่งเช็กดูแล้ว KDE ก็ร่วมกระแสนี้เหมือนกัน แต่โชคดีที่ยังปิดเป็นตัวเลือกได้

  • สงสัยว่าจำเป็นต้องมี GUI สำหรับ kvm/qemu เพิ่มอีกหรือไม่ เพราะผมคิดว่า cockpit-project ทำมาเพื่อจุดประสงค์นี้ได้ดีอยู่แล้ว

    • virt-manager ทำหน้าที่ได้ดีพอมาตลอด ผมเลยไม่แน่ใจว่าจำเป็นต้องมีตัวเลือกใหม่ไหม แต่การแข่งขันก็ยินดีต้อนรับเสมอ

    • เว็บอินเทอร์เฟซเหมาะกับผู้ใช้ระดับมืออาชีพมากกว่า แต่สำหรับผู้ใช้ทั่วไปมันยากเกินไป แนวคิดเรื่อง VM ก็ยากอยู่แล้ว UI ที่คุ้นเคยแบบ VirtualBox หรือ VMWare จึงเข้าถึงง่ายกว่า

  • ผมใช้ virt-manager มานานและตื่นเต้นมากกับโซลูชันแบบเนทีฟของ KDE อีกทั้งยังรอการรองรับ Vulkan rendering (libvirt) ใน virt-manager อยู่ด้วย UI ที่ทำด้วย Kirigami ให้ความรู้สึกอึดอัดเพราะใส่มาร์จินกว้างเกินไป เคยรู้สึกแบบเดียวกันกับ UI ของ print-manager ที่ทำด้วย Kirigami

  • เมื่อก่อน aqemu คือฟรอนต์เอนด์ที่ผมชอบที่สุด เสียดายที่ไม่ได้รับการดูแลมานานเกิน 10 ปีแล้ว

    • นักพัฒนาเคยทำ Kickstarter เพื่อเพิ่มฟีเจอร์ในสมัยก่อน แต่ก็น่าเสียดายที่ไม่สำเร็จ เลยอยู่ในสภาพหยุดนิ่งมาจนถึงตอนนี้