search

QubesOS / qubes-issues

The Qubes OS Project issue tracker
https://www.qubes-os.org/doc/issue-tracking/
541 stars 48 forks source link

Qubes Manager Decomposition for Qubes 4.0 #2132

Closed rootkovska closed 6 years ago

rootkovska commented 8 years ago

For Qubes 4.x we would like to radically simplify the UX of Qubes OS, by hiding as much Qubes internal infrastructure (e.g. net/usb/firewall VMs) as possible, and by making the UX more coherent, and less confusing. One of the culprits of the current UX model is our infamous Qubes Manager. We would like to decompose and simplify it for Qubes 4.0. This ticket describes how I see this being done.

First we should observe that currently Qubes Manager is (confusingly) used for two different types of interactions/tasks: 1) those that involve creating or modifying the persistent configuration of the system (e.g. creation or removal of new AppVMs, setting their properties), and 2) those that involve observing or modifying the ephemeral state of the system (e.g. checking which VMs are running, stopping them, attaching devices to them). This confusing mix of duties is made worse by the fact that the user is expected to launch applications via the "Start Menu", which is not part of the Manager. I saw many users who looked into the Start Menu in order to create a new VM, as well as into the Qubes Manager in order to start an application...

So, we would like the next-gen manager for Qubes 4.0 (which we need to rewrite anyway because of the changes in the core-ng) to be essentially a widget for ephemeral system state observation and management (e.g. stop/restart/kill AppVMs). In other words the Qubes Manager should provide an answer to "What is currently happening with my Qubes system". And also allow some ways to fix/change this current state (e.g. stop VMs, start updates).

Practically-wise I imagine this to be a simple widget for the Xfce4 panel, just like e.g. audio mixer, or clock, and located in the top main taskbar somewhere to the far right, next to all the other icons/widgets for ephemeral state monitoring (network, clock, audio mixer, tray icons, etc). Here's an example screenshot to help your imagination.

This means that when the user clicks on the Q icon for this widget, a drop-down list of the running VMs will appear, potentially also showing other info, such as CPU/MEM resources, and also presenting buttons to shut down each of the VM.

This list should primarily show user AppVMs and optionally (if enabled in config, and in different color, e.g. grayed out, or after a separator - TBD) the system VMs (net/usb, firewall, tor, perhaps templates).

All persistent actions related to VM configuration, such as changing their template, netvm, etc, should be accessible through the appmenu via the Start Menu. In fact we're already exposing this way of modifying VM settings, via the "Add more shortcuts" appmenu for each of the AppVMs. This appmenu should now be called "Settings..." and should open the same window as today, only focused on the Basic Tab, instead of on the Applications tab. Additionally we should add "Delete this AppVM" button to the Setting dialog box.

We need a few more appmenus, for actions which operate on the global system configuration. These are:

  1. An entry for changing global system setting,
  2. An entry for creation of new AppVMs,
  3. An entry for Backup/Restore of the system.
  4. In the future: starting of our to-be-implemented Qubes "Appstore" (a GUI app allowing user to select additional templates and "recipes" to install/deploy)

Creation of all the above appmenus is trivial and requires essentially creation of a .desktop file which calls the already-implemented dialog boxe from the current manager (which we might later rewrite or not), and updating the Xfce4 main menu.

The QM widget should also handle device attachments to running VMs. I think the best way to implement this would be by having an additional (additional to the 'Q' icon which pops up the list of running VMs) tray icon appearing whenever there is at least one device to connect (this might be either a block device, or USB device). In that case a dropdown list with available devices and their assignment (similar to a combined output of qvm-block -l and qvm-usb -l) should be popped out.

Two UI-related rules we would like to stick to:

  1. All the common operations should not require a right click, only left clicks.
  2. Icons/status should only be displayed when it makes some sense -- e.g. no point in displaying an empty list of devices to attach -- in that it's better to just not display the icon for showing the list of devices, etc. More advanced users can always resort to command line, which would be very powerful in Qubes 4.

  3. We should hide as much of the Qubes infrastructure as practically possible. As mentioned above this means e.g. not showing system VMs by default, allowing for simple one-click updates of all the templates and Dom0 (which we can now implemented easily with the management stack).

    Compact list of things to do:

rootkovska commented 8 years ago

Additionally should display status/messages from the Health Monitoring Deamon (#2134). E.g. updates available (and offer a button to click), or "unrecoverable program with one of your system VMs, please restart the system".

Additionally the actual icon in the panel (the 'Q') might double as global security status indicator: green - all good, yellow - something's not ok (e.g. proprietary BIOS used), red - insecure configuration (e.g. VT-d not present or enabled, USB controllers or Network devices assigned to Dom0, etc). This is essentially implementing (the UI frontend part of) #6.

marmarek commented 8 years ago

@bnvk do you have any opinion on this?

tasket commented 8 years ago

I have been forming some ideas in this general direction. Perhaps a column of start/stop buttons next to the vm names in QM? Or 'update available' icons that become buttons when appropriate to launch updates.

Also, since vm / application often become synonymous in the Qubes workflow (e.g. "I need this app, so appvm X starts to run the app, but quitting the app does not provide an opportunity to quit the vm") then maybe more can be done to make this convenient. Although monitoring of app processes from dom0 doesn't seem likely, some alternative to the regular 'close' widget may be both easy to learn and implement. My first thought is to use a modifier key along with the close widget to mean "stop the vm along with the app".

What complicates this is that Linux is bad at handling app run cycles to begin with. Although services get red-carpet treatment, user-facing applications are routinely obliterated on system shutdown, for instance. Apps that do a bit of routine maintenance on shutdown may close their windows some time before exiting. So there is a question of how to synchronize behaviors between apps and vm management functions to improve UX.

marmarek commented 8 years ago

On Mon, Jul 04, 2016 at 02:57:24PM -0700, ttasket wrote:

Also, since vm / application often become synonymous in the Qubes workflow (e.g. "I need this app, so appvm X starts to run the app, but quitting the app does not provide an opportunity to quit the vm") then maybe more can be done to make this convenient. Although monitoring of app processes from dom0 doesn't seem likely, some alternative to the regular 'close' widget may be both easy to learn and implement. My first thought is to use a modifier key along with the close widget to mean "stop the vm along with the app".

This is already discussed here: https://github.com/QubesOS/qubes-issues/issues/832

Generally the idea is to detect if the VM is "inactive" from inside of the VM (no dom0 involved at all); by checking if there are any visible windows + some timeout (for both handling long application shutdown, and also to have quick app startup if someone want to just restart application).

Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing?

kalkin commented 8 years ago

After reading @rootkovska post. I did some thinking about the UI & workflows a user has and how to lower the barrier for usage of QubesOS. This is what I come up with, sorry that it's so lengthy, please bear with me.

Introduction

First let me define some vocabulary: Allow me for just this post to introduce the word Space. The words Domain and AppVm/TemplateVM are loaded with too much of technical meaning, which is not interesting to the basic user™.

Space is a bundle of Apps you use (Firefox,OpenOffice,Xterm) to do some Activity (work, banking, image editing, anti NK propaganda), the Data you need for that and the Network Access. There are other Spaces, were you do other Activities, connected to other networks, but Qubes uses all technical abilities to keep them separate. I hope this vocabulary will us help concentrate on what we really want to show to the basic user.

Basic users:

Not basic users:

Any one who says: “…but Fedora-23 sucks because $REASON…”. If you think you are capable to judge a GNU/Linux Distribution, then congratulations you are not a basic user any more. The needs of this users should be taken care off, but we can assume that this users are capable reading the manuals, documentation or in app help. Of course All the options known from R2 & R3 should be there for the power user, but hidden for the basic user.

1. A Preferences App

I actually have no opinion on that, because I don't know how much do we think that the basic user understands the concept of NetVm, ClockVm, TorVm, RAM and so on… May be we can keep it complex, because we assume the basic user will never need to fiddle with it? Can we make sure that the basic user never needs to change the settings?

2 Add Space App

This is as simple dialog screen for creation and customization of the users space. The user has to enter the following values:

I would even go as far and propose that once a Space has a Network Connection assigned, it SHOULD NOT be possible for the user to easily change the Network Connection, because this can leak information in form of i.e. Firefox Cookies.

Advanced Options:

In a tab, or hidden to be shown on request we complement all the other settings provided by the current qvm-create dialog and may be some more options like storage. Here you could manually set the preferred NetVM, even if basic usage doesn't allow it.

2.1 Add Apps to Space

A dialog screen for adding and removing Apps to a space. Just Left Colum ←→ Right Column.

This should be called directly after new Space creation, but can called from the Q-Menu → SpaceName → “Add Apps to Space".

Future Advanced Options

Add package names which will be installed by package Manager. Under the hood a new TemplateVM based on the default fedora-23 is created and the App is installed, and the new TempateVM is assigned as template to the AppVM of the current Space. We can do this because volume snapshots are cheap in R4.

Far Future

3. A Backup App

For a Backup App the following bits are important for the basic user:

Spaces to backup

A list of Spaces by default all are selected, to back up.

Backups is about saving your work, which is in Spaces. The backup system should be smart enough to figure out when to backup which TemplateVMs and which templates could be easily recreated from other TemplateVMs (see above) and only backup the bare minimum.

Scheduling

User has to choose How often to back up & How long to keep old backups.

Technical Details

The user SHOULD be able to trust the scheduling. We could try to do live backups of running VMs, assuming that we use LVM Thin by default, this should workout fine at least from qubes storage perspective. If we can't do backups of running machines, we should check if i.e.: xscreensaver is running, if so just suspend all the running machines, force them write to disk, backup-up and resume the machines.

Destination

User chooses Backup location & Folder. Available Backup locations:

Technical Details

This part needs to have a good API so we can plug different Backup Implementations. Behind the scene the backup mechanism creates an AppVM appropriate for the chosen backup method, which mounts the Network or Device and awaits data.

Restore specific Spaces

Chose Space → choose date → Go!

Restore All

Chose date, Check the check box Restore System Configuration → Go

Technical Details

I count as System Configuration the following:

4. App Store

The user chooses an App and installs it. After Installation he can choose to which Spaces he adds the App.

Technical Details

The current QubesOS Storage system allows the creation of a very specific kind of volume. A volume can be snapshot at start of a vm from a source (Think AppVM root snapshots). A volume can also saved when the vm stops (i.e.: a private image of an AppVM or the root of the TemplateVM). An interesting side effect is that you can define a volumeB with a source volumeA, which on start makes a snapshot of the source A, but on the shutdown it saves the changes to disk as volumeB.

So imagine you have fedora-23 TemplateVM. The user install the App “Qubes Development Tools". The app is just an RPM package installed in the AdminVM which contains the script to used in a vm at start containing something like this: 


dnf groupinstall “Development Tools” -y

if [ -d /home/user/qubes-builder ]; then 
   git clone $URL /home/user/qubes-builder  && chown -R user:user /home/user/qubes-builder fi

If the user adds “Qubes Development Tools” in the “Add App to Space”-App to a Space behind the scene the following is happening:

  1. A dyn-qubes-dev TemplateVM is created. It's root volume is a volume which will be a read-writeable snapshot from the default fedora-23 TemplateVM root.
  2. The dyn-qubes-dev TemplateVM is started, at start the above script is executed.
  3. The vm shutdowns. On shutdown the root changes are not discarded but stored.
  4. The AppVM of the Space where the user added “Qubes Development Tools” is set to have as it's TemplateVM dyn-qubes-dev
  5. On update of fedora-23 repeat steps 2 & 3.

Of course it's not a set in stone solution, just my mentioning of what can be achieved with the tech which is already available.

5 Other Important bits

5.1. Storage Management App

5.2 Space Manager

The basic user sees here by default all active spaces in a table (grid). Active means they waste resources in some way. He can “close them”. He also can view here all his other (inactive) Spaces.

(Reasoning: Tables are good, people understand Tables. See abuse of Excel)

Advanced User

This is the place to observe the ephemeral state of the system. This is the counterpart of qvm-ls(1) in fancy and dynamic. We should provide an advance grid which shows the Domains, which is filterable and have same fields as qvm-ls(1). At this point I can't stress enough, that this should be easily filterable. Bot the current qubes-manager as the all current implementations of qvm-ls(1) (R3,R4) are suboptimal especially if you deal with a lot of domains. This is why I maintain a script for that.

This should be the replacement for the body part of the current qubes-manager.

Technical Details

Both grids (Space and VM) should be reusable. Use the Space Grid allowing the user to choose the Space in basic mode, show the VM Grid when in Advanced views.

5.3 Audio/Video Managment

Tasks to be accomplished by the user: assign microphone, Webcam and mute a Space While this should be available from the Space Manager, for day-to-day usage the user should use a small widget integrated in the xfce-panel.

Last Words

I hope I have not forgotten anything. This is what i come up with, thinking about this thread and reading the source code of qubes-manager (let us bury it ☺). I welcome all the feedback you've got.

I also don't insist on using the word Space, it's probably patented by some cloud company anyway ☺.

If we the list of Apps makes sense, we should create dedicated issues and discuss the different Apps there.

kalkin commented 8 years ago

Off course all the Qubes Apps, like Backup, Preferences and so on… should be at the appropriate places in the Q-Menu and also be available from the Xfce-Settings App.

tasket commented 8 years ago

Most of the irritation in using Qubes comes from having to interact with task manager and window manager and launcher and VM manager separately. In particular, closing an app often entails the extra step of going to QM to issue a shutdown command. Breaking up QM functions can serve to alleviate this... but we might have to go as far as offering task management functions as well. It might even be less work and more user-accessible to instead extend existing task manager a bit to handle Qubes use cases. We can't keep task and window and vm management separate and expect praise for UX.

Also, keeping in mind that windows are the fulcrum of the Qubes UI--providing security context seamlessly with window management--we may want to add a vm-management function or two to the titlebars. The vm name/identity is right there, so why not? How else do users normally do task management? A: Via the window gadgets. This could be key.

FWIW, I don't think the term 'vm' is much of a problem apart from the far-off day we may see a non-hypervisor implementation of Qubes. Picking an often-used DE term like "space" with no isolation connotations as a replacement could increase confusion. The main problem is that adjectives denoting the vm types are incomplete (and a little misleading). "Netvm" is a misnomer when its used to denote the setting for an upstream interface. Meanwhile "standalone" and "HVM" overlap with most other descriptive lables and we use them imprecisely. There is a certain amount of irreducible complexity here, unfortunately. It could be the subject of a style guide and also forum etiquette.

FOSS distros almost always make their problems worse when they assume interfaces must be either "for grandma" or "leet h4x0rs"; the results are there for all to see. A balance must be struck in the easiest interface modes, lest a project descend to the sort of idiotic experiments circa 2005 where even browsers tried to banish location bars (the term "domain name" is not for innocent eyes). The sad thing is this spilled over into production software and we see it still; For example, browsers removed important visual context in the form of the status bar so that hovering over links now displays the target URL on the page canvas. These aberrations planted seeds of diminished security.

We certainly do need to assume the user can read manuals and howtos... and in the process learn terms and concepts that are meaningful. They need to learn some of the language that describes context, in addition to the usual PC and internet stuff. Good PC interfaces have always been about moderate learning curves and UIs that make features discoverable. That discover-ability causes people to ask questions which can seem inconvenient to us; some projects actively discourage this quality so they are not bothered. Something to keep in mind while going forward...

tasket commented 8 years ago

While we're talking about "burying QM" its worth noting that the ultimate direction things could go might just as well elevate QM to an all-encompassing status, in a ubiquitous mode such as a panel. This seems especially true given QM already has a certain degree of app management built into it. Adding launcher functions would be no stretch at all.

Combined with window widget/hotkey access to shutdown/pause/prefs functions, that leaves two focal points for managing windows, apps and vms together. The only things that wouldn't be integral are functions like backup/restore. I can easily imagine this as a winning combination.

andrewdavidwong commented 8 years ago

@kalkin: Thanks for sharing your thoughts! Just one small comment. ISTM that your term "Space" serves the same function as "qube".

andrewdavidwong commented 8 years ago

@ttasket:

Meanwhile "standalone" and "HVM" overlap with most other descriptive lables and we use them imprecisely. There is a certain amount of irreducible complexity here, unfortunately. It could be the subject of a style guide and also forum etiquette.

Or perhaps a glossary? :)

rootkovska commented 8 years ago

While we appreciate that everybody has an opinion on how a UI/UX should looks like, we also recognize that almost everyone see this differently. I'd thus like to ask anybody commenting in this ticket to provide direct response to the original message I posted. Rather than writing essays on how they would like to do that. Or we would not get anywhere.

rootkovska commented 8 years ago

Also, I'd like to ask everybody that we save our grandmas, mothers, wives, sisters, and daughters (as well as all other members of our families, or other groups of people) the doubtfully prestigious roles of models for "non-technical" and/or "absent-minded" users.

Even if one considers their mother or sister to be indeed such a damn good example of a less advanced person in the art of Linux KungFu than themselves, please, please, use the correct term, such as... "non-technical user", or "absent-minded user" instead.

I'm sure every Linux wizard will be given dozens of other opportunities to prove their supremacy on the Command Line over the mere mortals like their mothers or sisters, outside our ticketing system, mailing lists, or Website documentation, or other resources.

Thank you.

kalkin commented 8 years ago

@rootkovska

Also, I'd like to ask everybody that we save our grandmas, mothers, wives, sisters, and daughters (as well as all other members of our families, or other groups of people) the doubtfully prestigious roles of models for "non-technical" and/or "absent-minded" users.

I agree. Thank you for the reminder. I try to live up the CCC Hackerethik, which states: “You should only judge humans but what they do and not their looks, age, gender, species…”, but I'm sorry if I offended you(?) . I will replace mother & Jeff with genderless Alex & Sam, if you are okay with this.

The objective of the narrative was to make the more technical minded people understand, that there are humans who just want to get their stuff done and who are not interested in understanding all the VM magic behind the scene. IMHO good examples of average people to which you can relate can open eyes to the some other minded people. Which IMHO is important when talking about human interfaces, on an openly accessible ML/Ticketsystem where every one can respond and has an opinion.

Jeeppler commented 8 years ago

I like this idea for advanced users: We should provide an advance grid which shows the Domains, which is filterable and have same fields as qvm-ls

it would be nice to have something like:

qm --fields=all --where label=green and template=like("fed") --order-by desc --format=table

or

qm --fields=all --where vm-type=pvh --order-by asc --format=json

or

qm --where label=green and type=template --action=qvm-start

I think it is important to have a powerful solution for advanced users. I know it seams a little bit off topic, but issue is also about UI/UX simplification. I think all users are important and should have a tool to get their work done.

Jeeppler commented 8 years ago

The current Qubes Manager has some issues with dark themes. I would be happy if the new solution would look good with dark and bright themes.

rootkovska commented 8 years ago

Advanced users are envisioned to use qvm-* commandline tools. Much more powerful these are gonna be in Qubes 4, especially qvm-ls.

andrewdavidwong commented 8 years ago

User suggestion: Provide some way to keep VMs organized, similar to the way that we can currently group app launcher menu entries into folders.

"Folders" may or may not make sense in the new decomposed system, and the VMs that are part of the "infrastructure" may not be included. The general idea is to provide the user with some way to organize their VMs.

Discussion thread

Also see: #2946.

kalkin commented 8 years ago

Device Widget

devices-widget1 devices-widget2 devices-widget3

Domain Widget

qubes-widget-hide-interna qubes-widget-show-interna

PS: I use the red stop sign, because the audio-stop icon, looks really bad and is almost invisible.

rootkovska commented 8 years ago

The aesthetics of the icons used is questionable, so to say. I suggest to use monochromatic, some shade of gray, and much small icons. The most important info we want to show is the name and color of the VM, everything else (mem, setting & stop buttons) should secondary.

Also, we talked the QM icon should the first-class citizen widget icon, rather than a tray icon. This would allow more flexibility in positioning it in various places.

kalkin commented 8 years ago

The aesthetics of the icons used is questionable, so to say. I suggest to use monochromatic, some shade of gray, and much small icons.

This are the default Gnome/Gtk icons. We could use the "symbolic" icons if you wish. You can install gtk3-icon-browser to see all the available stock icons. I would need some suggestions, so I can better understand how you envision it.

If you are not happy with the stock icons, we would need to design our own, but this is kind of out of my league.

The most important info we want to show is the name and color of the VM, everything else (mem, setting & stop buttons) should secondary.

ACK, but we do display the colour and the domain name prominently. According to my notes at least the stop button, was important to you and we do have the space for it.

Should I get rid of the buttons?

Also, we talked the QM icon should the first-class citizen widget icon, rather than a tray icon. This would allow more flexibility in positioning it in various places.

From the technical point it doesn't matter. We just load the content in a Gtk.Window instead of using Appidicator to display the items.

kalkin commented 8 years ago

Here is an example using symbolic icons and the media-playback-stop-symbolic icon instead of process-stop, from above.

qubes-widget-symbolic

rootkovska commented 8 years ago

Looks better IMHO. Also I think we should make the mem text gray too, as it's not really that important. We might also move the mem values to the right edge, while keeping the setting/stop "buttons" closer to the VM name:

{padlock} {vmname} {padding} {settings} {stop} [{mem}] [{cpu}]

I put these last {mem} and {cpu} in square brackets, as we might give user an option to hide all or any of these. Which is another reason to show them "after" the buttons.

jpouellet commented 7 years ago

Whatever you end up doing, may I recommend that the ability to be used efficiently via a keyboard not be forgotten.

andrewdavidwong commented 7 years ago

User suggestion: Per-VM disk usage indicators (or just a warning when approaching full).

Details and discussion:

On 2016-12-02 14:29, Chris Laprise wrote:

On 12/02/2016 02:21 PM, Micah Lee wrote:

I also find that I forget to increase the size of my appvms' private image, and instead just run out of disk space. And occasionally, when I'm doing something that writes a lot of data to /tmp, I fill that up too.

I'd love to see a service running in all appvms that monitors disk space usage. If you're running low, or run out, of space in /rw, it pops up a window asking if you'd like to increase the size of your private storage. If you say yes, it launches a simple tool in dom0 that lets you specify how many GB you want to make it, and maybe how free much space you have available. (There have been several times where it wasn't immediately clear that the reason everything broke is because I ran out of disk space, and I had to spend time troubleshooting to figure this out. I think less experienced users might just think it's broken and give up.) And likewise, if you run low or out of disk space in /tmp, it should pop up a window and let you remount your tmpfs with more disk space, without having to lookup the commands to do it.

It shouldn't be hard to have the successor to Qubes Manager show a warning indicator as a disk image approaches its maximum.

What we could also use is a quick summary of VM-allocated space vs total space available (though a simple disk space widget on dom0 desktop does help in this regard).

jpouellet commented 7 years ago

It shouldn't be hard to have the successor to Qubes Manager show a warning indicator as a disk image approaches its maximum.

This is not as simple as it sounds. Deleting files in most filesystems does not immediately zero them, but only unlink them from the indexing data structures. Also, new files are not guaranteed to prefer previously-allocated space vs never-allocated space. Therefore, the size of a disk image relative to its quota is not necessarily indicative of the amount of usable space remaining. We would need some kind of diskinfo-writer service inside the VM to know that correctly.

I would also say that is off-topic for this issue.

marmarek commented 7 years ago

On Sat, Dec 03, 2016 at 12:09:30PM -0800, Jean-Philippe Ouellet wrote:

It shouldn't be hard to have the successor to Qubes Manager show a warning indicator as a disk image approaches its maximum.

This is not as simple as it sounds. Deleting files in most filesystems does not immediately zero them, but only unlink them from the indexing data structures, therefor the size of a disk image relative to its quota is not necessarily indicative of the amount of usable space remaining. We would need some kind of diskinfo-writer service inside the VM to know that correctly.

Actually, we mount /rw with "discard" option, which do notify lower layer(s) of freed blocks. It is supported by the whole path ext4(VM)->xen-blkfront/back->loop->ext4(dom0).

-- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing?

jpouellet commented 7 years ago

@marmarek wrote:

Actually, we mount /rw with "discard" option, which do notify lower layer(s) of freed blocks. It is supported by the whole path ext4(VM)->xen-blkfront/back->loop->ext4(dom0).

You are correct. I widthdraw my previous statement. Verified in https://github.com/QubesOS/qubes-issues/issues/2478 (just does not work for DispVMs).

jpouellet commented 7 years ago

(just does not work for DispVMs)

or data outside /rw and /home on StandaloneVMs or TemplateVMs, or likely most non-qubes-originating HVMs. See https://github.com/QubesOS/qubes-issues/issues/2479

tasket commented 7 years ago

@jpouellet Standalone appVMs have /rw mounted with discard support. Its easy to add it to / also (or just run fstrim periodically). Main concern should be /rw where data lives.

jpouellet commented 7 years ago

On Sat, Dec 3, 2016 at 10:42 PM, tasket notifications@github.com wrote:

@jpouellet https://github.com/jpouellet Standalone appVMs have /rw mounted with discard support. Its easy to add it to / also (or just run fstrim periodically). Main concern should be /rw where data lives.

Yes, I meant for /. Off topic for this issue though, see #2479

andrewdavidwong commented 7 years ago

Subtask: There should be a GUI frontend for qvm-usb similar to qvm-block.

marmarek commented 7 years ago

There should be also indicator about disk space - especially when we'll use LVM thin provisioning, because then just df in dom0 (or any GUI equivalent - like standard disk usage Xfce applet) wouldn't return meaningful information. It may be a separate widget or so. Or maybe there is something monitoring LVM thin pool already?

andrewdavidwong commented 7 years ago

There should be also indicator about disk space - especially when we'll use LVM thin provisioning, because then just df in dom0 (or any GUI equivalent - like standard disk usage Xfce applet) wouldn't return meaningful information. It may be a separate widget or so. Or maybe there is something monitoring LVM thin pool already?

Related: #2016

grey-olli commented 7 years ago

Hello. Here're my whishes:

I would like similar behavior after logon after power off as firefox shows on start after kill, if configured to 'restore last state' - show list of options includgin vm list to be autostarted on same virtual desktops them were started on.

Also I vote for ability to set desktop range for a color or a single VM in qubes app manager

marmarek commented 7 years ago

Screenshot of domains widget in Qubes 4.0rc1: domains-widget-submenu

zander commented 6 years ago

Related #3417

Shane-Optima commented 6 years ago

I guess this has been in the pipeline for a while, but t's hard to convey how big of a disappointment this news has been to so many of us enthusiastic Qubes users (and evangelists.) Not just of the loss of the Qubes Manager (yes, I know it's been brought back in a more limited form "by popular demand"), but the news that this is apparently the long term UX goal that will be aimed for.

Right now, the underserved segment of tech users are the power users. These are the people who understand what VMs do and roughly how they work, but do not know enough of the details, or have enough proficiency on the command line, to quickly see everything that needs seeing and do everything that needs doing.

It is possible to cater to these users--who are a massive part of the Qubes fanbase and are getting the word out there (for whatever that's worth)--without "confusing" people. To a power user, it is not at all confusing to have a list of all VMs with their configuration, their current state, and ways to alter or connect them easily at their fingertips. What is confusing is being told that we have to go hunt down a different part of the UI to do what needs doing. Why? If we know that a VM exists, we want to be able to look at a list of VMs, find it, click on it and do that thing, somehow. We're not fussy on how it gets done. Left click instead of right click, sure. And perhaps in the name of UNIX-y modularity, another GUI program could be launched as a result. But a requirement that I be aware of, track down and use a totally separate GUI to interact with the VM I'm staring a...?

Do you know what the UX feature that power users have appreciated the most in the past 10 years, the thing that gets the most mileage? It's that little box in the start menu (or equivalent) that searches for and suggests the program you're going to launch or the setting you want to alter. And that's because it does EVERYTHING. "I know exactly what I want to do... just tell me where I can relay that command to the OS!"

I've a tremendous amount of respect for the philosophies and the finished products that have come out of Rutkowska and the rest of the Qubes team (years before hearing about Qubes, I'd actually hacked together something superficially very similar using Virtualbox's "transparent desktop" feature, with different colored windows in each VM) but I believe that information hiding can be done without alienating the power users. It would be more work, probably. Every new demographic you cater too is more work. That is an inescapable fact of life, and obviously your time and money is limited. So if it is a tradeoff, I can only say, maybe just ask yourself... how important is the NON-power user demographic to you right now?

I've been pushing Qubes as the greatest thing since sliced bread over on Slashdot. Emphasizing how easy and intuitive it is; how it occupies that magical middle power-usery ground where you don't need to be so concerned with the specifics of how things are done, just knowing the 50,000 foot view is enough to get a lot out of it. They don't make distros like Qubes any more. I don't just mean there aren't other secure hypervisors out there; they don't offer UXes that occupy that wondrous middle around that so many of us part-time geeks are trapped in. Instead, everywhere we look the UXes have become extremely polarized: everything is either dumbed down into oblivion or requiring a CLI pipe proficiency that I never had the time to develop.

Do you understand how frustrating it is to be informed enough to know EXACTLY what you want to see or so but not be able to easily configure it? To not have enough hours in the day to become the highly proficient masters we'd all prefer to be?

I understand and even agree with many of the specific issues with the Qubes Manager, but the big picture verdict and philosophy sounds very disheartening. It is not "confusing" to us to have a centralized way of viewing and interacting with all of the VMs any more than the little search box in the start menu was confusing.

You guys do what you have to do, and I really can't applaud you enough for everything you've already done... but on behalf of all power users everywhere, I just felt like I need to make that detail perfectly clear.

comods commented 6 years ago

allowing for simple one-click updates of all the templates and Dom0 (which we can now implemented easily with the management stack).

1) With a fresh install of Qubes R4.0, updating from fedora-26 to fedora-28 was needlessly tedious. Having to use the Terminal to download 28, then being required to close VMs before I could change their template, instead of being able to have the change go into effect on the next reboot. This one-click update would be very useful.

2) During installation, I was asked if I wanted the list of default qubes setup. There should be a one-click resetup of any default qubes that have been deleted.

andrewdavidwong commented 6 years ago

@evadogstar:

2th Such a command is present (salt, the same command executed on setup). But unfortunately I don't remember it. @andrewdavidwong please, place it to update docs.

Sorry, I don't understand what you're asking for. Could you try rephrasing?

andrewdavidwong commented 6 years ago

Look at @RefinedSoftwareLLC question #2. As I remember, Qubes already have some beautiful way to re-setup all of default VMs (sys-net, sys-firewal, etc.) Can you add this command to the documentation?

I'm not aware of such a command, but I'd be happy to add it to the documentation if someone who knows it can provide it.

marmarek commented 6 years ago

See readme here for the list of states. You can apply a single state with qubesctl state.sls STATE_NAME. For example qubesctl state.sls qvm.personal will create personal VM (if not already there), with all its dependencies (template, sys-firewall, sys-net). The same for others.

andrewdavidwong commented 6 years ago

Should that README be moved into qubes-doc and replaced with a link pointing to the appropriate URL on our website?

comods commented 6 years ago

@andrewdavidwong Can you include @marmarek 's how to use explanation along with the list of states. With the addition of running from dom0 and using sudo. "From dom0, you can apply a single state with sudo qubesctl state.sls STATE_NAME. For example sudo qubesctl state.sls qvm.personal will create personal VM (if not already there), with all its dependencies (template, sys-firewall, sys-net). The same for others."

marmarek commented 6 years ago

Should that README be moved into qubes-doc and replaced with a link pointing to the appropriate URL on our website?

Yes, good idea.