You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've already authored some issues on your great tool for QubesOS. The qvm-create-windows-qube is a great tool that alleviates a lot of complexity and adds an extreme level of abstraction over complex Qubes setups.
I am interested to know what you think about qvm-create-windows-qube as a component of other tools that would alleviate even more complexity?
I've been developing qubes-task*[1 in notes] for some months now. I've already authored issue #65 to be able to use qvm-create-windows-qube, but I still have to heavily modify the installation shell script to keep it working.
Benefits for qvm-create-windows-qube
1 Better testing from the developer's side.
During development, I've had to address issues #55, #63, #64, and #65, and notify you. As an user, I probably wouldn't bother to deep in issue#55, as I would only need a working result.
2 Better testing from the user's side.
The first time I installed your tool, I was so excited but, anyway, I only ran it three times. Users quickly become comfortable, and toggling between dom0 and win-mgmt quickly becomes routine for me. With qvm-create-windows-qube integrated into the GUI, I've installed Windows maybe 50 times already. I've run absolutely all installations because it's just easy. So, testability will increase rapidly.
Notes
The qubes-task is aimed only for qubes-enthusiast. I consider any modification of dom0 is a rude violation of QubeOS doctrine. There are no safe changes on dom0. Any change create dangerous precedent. The users who needs aimed Qube's security must not at any circumstances interact with dom0.
on other side Qube's community is full of enthusiast who like to use that system and It would be beneficial for them to have more flexibility
I consider it's not ecological🌏 though 😞
The text was updated successfully, but these errors were encountered:
Thanks for the kind words! Sorry for taking a while to get back to you. Yes, I would welcome a frontend GUI for qvm-create-windows-qube. It would be a good UX for the GUI to integrate with the "Create Qubes VM" dialog (qubes-vm-create command). The code for this dialog can be found in the Qubes Manager repo. As I understand, the Qubes team aims to separate the Qubes Manager into more modular components in the long term. Any contribution is always highly appreciated!
Hi @ElliotKillick!
I've already authored some issues on your great tool for QubesOS. The qvm-create-windows-qube is a great tool that alleviates a lot of complexity and adds an extreme level of abstraction over complex Qubes setups.
I am interested to know what you think about qvm-create-windows-qube as a component of other tools that would alleviate even more complexity?
I've been developing qubes-task *[1 in notes] for some months now. I've already authored issue #65 to be able to use qvm-create-windows-qube, but I still have to heavily modify the installation shell script to keep it working.
Benefits for qvm-create-windows-qube
1 Better testing from the developer's side.
During development, I've had to address issues #55, #63, #64, and #65, and notify you. As an user, I probably wouldn't bother to deep in issue #55, as I would only need a working result.
2 Better testing from the user's side.
The first time I installed your tool, I was so excited but, anyway, I only ran it three times. Users quickly become comfortable, and toggling between dom0 and
win-mgmt
quickly becomes routine for me. With qvm-create-windows-qube integrated into the GUI, I've installed Windows maybe 50 times already. I've run absolutely all installations because it's just easy. So, testability will increase rapidly.Notes
The qubes-task is aimed only for qubes-enthusiast. I consider any modification of dom0 is a rude violation of QubeOS doctrine. There are no safe changes on dom0. Any change create dangerous precedent. The users who needs aimed Qube's security must not at any circumstances interact with dom0.
on other side Qube's community is full of enthusiast who like to use that system and It would be beneficial for them to have more flexibility
I consider it's not ecological🌏 though 😞
The text was updated successfully, but these errors were encountered: