1 điểm bởi GN⁺ 2025-05-20 | 1 bình luận | Chia sẻ qua WhatsApp
  • Đã chính thức xác nhận thông tin phát triển Karton, một trình quản lý máy ảo dành riêng cho KDE Plasma
  • Dự án này được xây dựng trên nền Qt Quick và Kirigami, tối ưu cho môi trường KDE
  • Sử dụng libvirt API để điều khiển nhiều loại máy ảo khác nhau và hướng tới hỗ trợ đa nền tảng trong tương lai
  • Các tính năng chính gồm trình xem SPICE tùy biến, snapshot, giao diện trực quan và hỗ trợ chuyển đổi hypervisor giữa chế độ hệ thống/người dùng
  • Theo lịch trình Google Summer of Code 2025, dự kiến hoàn thành vào khoảng tháng 9/2025

Bối cảnh phát triển và nhu cầu của Karton

  • Trong môi trường GNOME, đã có những công cụ chạy máy ảo dễ dùng và nhất quán như GNOME Boxes
  • Người dùng KDE từng dùng các lựa chọn thay thế như qt-virt-manager đã cũ, nhưng gặp vấn đề ngừng phát triển và thiếu bản sắc riêng của KDE
  • Nhu cầu về một giải pháp quản lý VM tích hợp tự nhiên với môi trường KDE Plasma hiện đại ngày càng tăng cao

Tổng quan dự án Karton

  • Karton bắt đầu từ một nỗ lực xây dựng frontend cho QEMU, sau đó được nhà phát triển KDE Harald Sitter thúc đẩy thành dự án Google Summer of Code
  • Derek Lin từ University of Waterloo hiện đang phát triển dự án rất tích cực với vai trò người tham gia Google Summer of Code 2025
  • Mục tiêu của Karton là cung cấp công cụ quản lý máy ảo native phù hợp với hệ sinh thái KDE

Công nghệ chính và đặc điểm nổi bật

  • Karton được phát triển bằng Qt Quick và Kirigami, hướng tới tích hợp hoàn chỉnh về mặt thị giác và trải nghiệm sử dụng với KDE Plasma
  • Thông qua libvirt API, dự án cung cấp khả năng quản lý máy ảo và mở rộng, đồng thời tính đến hỗ trợ đa nền tảng trong tương lai
  • Thay vì gọi trực tiếp virt-install CLI như trước, dự án đang triển khai việc dùng libosinfo để tự động nhận diện image hệ điều hành và tự động tạo libvirt XML
  • Việc mở rộng cấu hình thiết bị và hỗ trợ nhiều hypervisor cũng là một nhiệm vụ phát triển

Tính năng chính và mốc mục tiêu

Các tính năng Lin nêu trong đề xuất Google Summer of Code gồm:

  • Cài đặt và cấu hình máy ảo thông qua định dạng libvirt XML
  • Phát triển trình xem SPICE tùy biến dựa trên Qt Quick (thay thế virt-viewer)
  • Tính năng snapshot cho máy ảo (sao lưu/khôi phục)
  • GUI trực quan, đẹp mắt và có phần xem trước, đồng thời phản ánh phản hồi từ cộng đồng
    • Tham khảo thiết kế từ bố cục danh sách của MacOS UTM
    • Cung cấp giao diện thân thiện với thiết bị di động
  • Xử lý cập nhật trạng thái theo thời gian thực một cách hiệu quả bằng hàm virEventRegisterImpl
  • Tính năng duyệt cung cấp danh sách các hệ điều hành chính
  • Biểu đồ mức sử dụng GPU/bộ nhớ (kiểu virt-manager)
  • Tính năng chuyển đổi giữa chế độ phiên (người dùng) / hệ thống (root) của QEMU hypervisor

Lịch trình phát triển

  • Ngày bắt đầu coding chính thức của Google Summer of Code 2025 là 2/6/2025
  • Kế hoạch là hoàn thành prototype cho đợt đánh giá giữa kỳ vào 14/7, và hạn chót nộp bản hoàn chỉnh cuối cùng là 1/9

Kết luận

  • Karton là một dự án mới có thể giải quyết vấn đề tồn tại lâu nay về việc thiếu một công cụ quản lý máy ảo native được tối ưu cho môi trường KDE
  • Việc đồng thời mang lại khả năng hiển thị và trải nghiệm sử dụng phù hợp với các công nghệ cốt lõi hiện đại của Qt và KDE là một thay đổi có ý nghĩa cho cả người dùng desktop Linux lẫn nhà phát triển

1 bình luận

 
GN⁺ 2025-05-20
Ý kiến trên Hacker News
  • Tôi nghĩ KDE nên tập trung vào các tính năng nền tảng như sắp xếp cửa sổ, render cửa sổ, biểu tượng launcher ứng dụng. Nếu cần máy ảo thì tôi sẽ dùng phần mềm máy ảo riêng. Bộ sản phẩm tích hợp của KDE có một số phần mềm tốt, nhưng theo tôi không nhất thiết phải gắn chặt với môi trường desktop. Chỉ cần trình quản lý tệp, VTE và trình soạn thảo văn bản là đủ. Sẽ tốt hơn nếu quản lý biểu tượng riêng cho từng ứng dụng. Các nỗ lực hợp nhất biểu tượng chỉ gây ra vấn đề như biểu tượng không hiện, hoặc biểu tượng đen trên nền đen

    • Có vẻ đang có sự nhầm lẫn giữa dự án KDE và Plasma. Plasma là môi trường desktop, còn dự án KDE phát triển và phát hành nhiều ứng dụng khác nhau. Nhiều ứng dụng KDE chạy được trên các OS khác như Windows, và bạn vẫn có thể chỉ cài Plasma mà không cần các ứng dụng KDE khác. Về mặt lịch sử, môi trường desktop từng được gọi là KDE, nhưng giờ đây nó chỉ là một trong nhiều phần mềm do dự án KDE phát triển. Về chủ đề theme biểu tượng thì tôi cũng đồng ý, và bản thân tôi cũng không dùng theme biểu tượng

    • KDE đã phát triển nhiều công cụ trong hơn 20 năm qua. Trình duyệt, ứng dụng email, ứng dụng quản lý liên hệ, v.v. Ngay từ thời KDE 1 đã có trình duyệt tệp, và bộ ứng dụng văn phòng cũng đã được phát triển. Bộ sản phẩm của KDE đã tồn tại từ thuở ban đầu. Plasma chỉ là một phần rất nhỏ trong những gì KDE làm ra. Nếu chỉ muốn vai trò window manager thì có những lựa chọn tối giản hơn như LXDE, Hyprland, Sway, i3

    • Việc biến biểu tượng thành tài sản dùng chung rồi tích hợp vào ứng dụng luôn thất bại. Cộng đồng GNOME đã làm tốt ở điểm này. Xem https://stopthemingmy.app/. Hỗ trợ sự nhất quán theme xuyên ứng dụng chỉ là một ảo tưởng của thập niên 90, ngoài đời thực nó chỉ trông ổn trong ảnh chụp màn hình

    • Vì lý do đó mà tôi chuyển sang sway. Cần có sự liên kết giữa các phần của hệ thống, nhưng từng phần vẫn nên tách rời. gnome và kde chỉ ổn khi dùng toàn bộ mọi thứ. XFCE thực ra mô-đun hơn nhiều

  • Hơi tiếc vì phần lớn bình luận lại nói sang chuyện khác thay vì nội dung bài viết. Tôi rất mong chờ trình quản lý VM mới này. Tôi chủ yếu dùng virt-manager nhưng nó gần như không được bảo trì, nên vấn đề scaling trên màn hình HiDPI rất nghiêm trọng. GNOME Boxes thì nhiều bug và thiếu tính năng. Có vẻ mọi người chỉ quan tâm đến CLI là virsh, nên hiện giờ không có GUI VM nào thực sự dùng ổn

  • Tôi đang dùng KDE Plasma trên Arch và rất thích môi trường này. Nó còn có sẵn bộ lọc ánh sáng xanh. Tôi không có ý định quay lại Windows. KDE nhanh hơn, đẹp hơn, và không có quảng cáo hay theo dõi ngoài ý muốn. Rất tuyệt cho dùng hằng ngày

    • Tôi đang thử Cachy và Plasma trong VM, và dự định cài ngay tổ hợp này lên chiếc PC tiếp theo. Hiện tại tôi dual boot Ubuntu và Windows nhưng đã hơn 6 tháng không đăng nhập Windows. Có lẽ chiếc PC sau tôi sẽ không cài dual boot nữa

    • Tôi đã dùng gnome một năm rồi quay lại plasma. gnome quá bất tiện. Tôi phải vá víu bằng extension nhưng cứ cập nhật là lại hỏng. Giao diện tiếng Anh và thiết lập đơn vị ISO cũng rườm rà. Muốn quản lý chương trình khởi động cùng hệ thống còn phải cài app riêng. Scaling màn hình, đa màn hình, ghi hình màn hình đều tệ. Màn hình của tôi là 60fps mà con trỏ chuột vẫn giật. Việc ẩn bàn phím tiếng Thụy Điển, Sami, svdvorak cũng chẳng giúp ích gì. Copy-paste không hoạt động giữa các màn hình. Đổi cửa sổ bằng alt+tab thì drag & drop không hoạt động. Khi menu ngữ cảnh hiện ra thì toàn bộ focus bị khóa, nên nếu Nautilus mở hộp thoại sao chép tệp thì không thể bấm sang ứng dụng khác. Sau khi vô tình thử KDE trong VM, tôi nhận ra chẳng có lý do gì để tiếp tục chịu đựng gnome. Tôi quay lại opensuse ngay trong ngày hôm đó

    • Tôi dùng KDE 1.0 lần đầu hơn 20 năm trước. Khi đó nó có hơi mang cảm giác bắt chước Windows, nhưng theo tôi nhớ thì độ hoàn thiện thậm chí còn tốt hơn

    • Tôi đã dùng Ubuntu + Plasma làm máy chính suốt 3 năm. Theo tôi đây là hình hài mà Windows 7 từng mơ tới. Ở góc nhìn một kỹ sư dotnet, devops, thì trong thập niên 2020 bộ công cụ Linux và độ hoàn thiện của mã nguồn mở khớp với nhau gần như hoàn hảo. Rider, datagrip, vscode đều chạy tốt. Cũng không có sự phiền toái của docker hay wsl. Tôi chỉ khởi động Windows khi cần chạy các phiên bản cũ của .NET Framework, và tôi cảm thấy hoàn toàn có thể thoát hẳn bằng cách thiết lập boot Windows NVMe trong VM bất cứ lúc nào

  • Điều KDE cần không phải tính năng mới mà là ít bug hơn

    • Tôi cũng từng luôn phàn nàn về bug của KDE, nhưng từ bản 6.3 trở đi thì suốt 10 năm nay tôi chưa gặp bug nghiêm trọng nào. Nếu bạn đã bỏ dùng một thời gian thì giờ rất đáng để thử lại

    • Tôi cũng nghĩ tương tự. Tôi đã thử nhiều lần nhưng KDE lúc nào cũng cho cảm giác kém ổn định và kém hoàn thiện hơn gnome. Có lẽ vì KDE thiên về khả năng tùy biến cao. Ý tưởng thì hay nhưng khó bảo trì, và có vẻ các lập trình viên cũng bị hấp dẫn bởi việc thêm tính năng mới hơn là sửa bug

  • Tôi muốn KDE cung cấp một giải pháp VM tích hợp. Sẽ rất hay nếu ứng dụng chạy trong VM có thể xuất hiện như cửa sổ Kwin. Có thể điều này sẽ cần một helper daemon trong guest OS. Trước đây cũng từng có tính năng tương tự, nhưng nếu một DE lớn chính thức cung cấp thì sẽ thật tuyệt

    • Điều thú vị là Windows hỗ trợ việc này thông qua WSL2. Trước đây tôi từng đùa chạy thử "nautilus" và khá bất ngờ

    • Tôi đang tạo ra trải nghiệm gần giống như vậy với VirtualBox. Tôi chạy nhiều VM trên laptop và khi cắm màn hình ngoài thì có thể chỉnh kích thước cửa sổ tùy ý. Khi rút màn hình ra thì cửa sổ tự thu nhỏ lại. Nhờ chia sẻ clipboard và các thứ tương tự, cảm giác gần như native. Tôi tách VM theo mục đích sử dụng như chỉ để duyệt web hằng ngày, chỉ cho dự án hợp đồng, v.v. Tôi gán desktop ảo cho host, còn một desktop duy nhất cho VM. alt+tab được cấu hình chỉ hoạt động bên trong VM. Dù vẫn phải chấp nhận đủ loại bug lặt vặt của VirtualBox và rủi ro pháp lý từ Oracle, tôi vẫn bám vào VirtualBox vì QEMU hay KVM hiện vẫn chưa đủ hoàn thiện

    • Về mặt kỹ thuật thì cần khá nhiều hack. Trên các OS đóng thì khó, và chỉ Windows hỗ trợ qua RDP

    • Có thể thử cách nhẹ hơn và ít tốn tài nguyên hơn bằng debboostrap và chroot mounting

    • Trong các giải pháp hiện tại chưa có cái nào hỗ trợ hoàn hảo. X11 forwarding thì làm được nhưng cần thiết lập và không mượt. Tôi vẫn chưa tìm thấy client/server nào hỗ trợ việc này theo kiểu native trên Linux

  • Tôi rất vui vì có thể chọn một lựa chọn thay thế cho virt-manager. Đặc biệt là nó dùng Qt. Điều hơi tiếc là nó dùng Kirigami và Qt Quick. Tôi thấy cả giao diện lẫn tính năng đều kém hơn so với nền tảng Qt Widgets

    • Tôi nghĩ cần có một lựa chọn thay thế virt-manager. Ngay cả các tính năng bình thường như tìm kiếm văn bản trong XML hay undo cũng còn bất tiện. Cách gắn tên KDE thì hơi lỗi thời, nhưng cái tên Karton nghe vẫn ổn hơn

    • Bản thân Plasma shell được xây trên Kirigami và Qt Quick, nên khó có môi trường nào tích hợp nhất quán đến vậy

    • Kiểu giật lag đặc trưng của render QML chỉ tránh được nếu có giấy phép Qt thương mại. Đổi lại, nó có ưu điểm là có thể làm ứng dụng bằng cú pháp gần giống JSON

    • Qt Quick có tính phổ dụng hơn, còn Kirigami là một lớp chuyên biệt hơn ở phía trên nó

  • Tôi thích độ hoàn thiện và sự phong phú của KDE, nhưng thiết kế của nó so với các OS hay DM khác ngày nay vẫn có cảm giác cũ. Dù có thể tùy biến, càng chỉnh nhiều thì hệ thống càng chậm và trông càng gượng gạo. Vì vậy tôi chọn gnome

    • Tôi thấy thú vị vì rất nhiều người lại có quan điểm hoàn toàn ngược lại. Với tôi KDE mới là môi trường duy nhất trông hiện đại và đẹp

    • Không biết bạn đã thử Plasma 6 chưa. Cá nhân tôi thấy nó hiện đại hơn gnome rất nhiều

    • Tôi nghĩ thiết kế của KDE vượt xa Windows. Với tôi Windows luôn liên tục phá kỷ lục về độ tệ trong thiết kế desktop

    • Chỉ cần thêm menu hamburger là tôi sẽ quay lại KDE ngay. Vừa kiểm tra thì KDE cũng đã chạy theo xu hướng này, nhưng may là có thể tắt bằng tùy chọn

  • Tôi không chắc có thực sự cần thêm một GUI nữa cho kvm/qemu không. Tôi thấy cockpit-project đã được làm rất tốt cho mục đích này rồi

    • virt-manager đến giờ vẫn đủ làm tôi hài lòng, nên tôi không rõ có thực sự cần một lựa chọn mới không. Dù sao thì cạnh tranh luôn đáng hoan nghênh

    • Giao diện web phù hợp với người dùng chuyên sâu hơn, nhưng với người dùng bình thường thì khó tiếp cận. Ngay cả khái niệm VM cũng đã khó rồi, nên UI quen thuộc kiểu VirtualBox hay VMWare lại dễ tiếp cận hơn

  • Tôi đã dùng virt-manager lâu năm, nên rất mong chờ một giải pháp native của KDE. Tôi cũng đang chờ hỗ trợ render Vulkan của virt-manager (libvirt). UI dựa trên Kirigami có margin quá rộng nên tạo cảm giác bí bách. Tôi cũng từng có trải nghiệm tương tự với UI Kirigami của print-manager

  • Trước đây aqemu là frontend tôi thích nhất. Thật tiếc là nó đã không được bảo trì hơn 10 năm rồi

    • Trước đây tác giả từng làm Kickstarter để bổ sung tính năng, nhưng tiếc là thất bại nên dự án rơi vào trạng thái đình trệ