What happened to domain manager in 4?

[Ro...@tuta.io]

Is it renamed or somewhere different?

[Ro...@tuta.io]

Vm manager...

[Unman]

On Mon, Dec 04, 2017 at 07:37:23AM -0800, Ro...@tuta.io wrote:
> Is it renamed or somewhere different?
>

It has been removed - you can review the rationale behind this on Github
- look at Qubes Issues #2132

[Ro...@tuta.io]

Just read it. Thats fucking stupid.

[Tom Zander]

On Monday, 4 December 2017 16:38:12 CET Ro...@tuta.io wrote:
> Vm manager...

It has been reduced to a single icon in your system tray.

Some features have been moved elsewhere (start menu has a config item per VM)
some are command-line only.
--
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel

[Tai...@gmx.com]

On 12/04/2017 06:34 PM, Ro...@tuta.io wrote:

> Just read it. Thats fucking stupid.

Sure is, I am tired of the linux greybeard obsession with the CLI - it
is not always the best choice.

When it comes to management of many virtual machines a GUI is a must to
speed tasks and avoid 3AM critical mistakes.

[Tom Zander]

The creation of GUIs doesn’t have to be done by the Qubes team, in my
opinion.

I would even argue that the skills required to make fine UX apps are
significantly different and we’ll likely get better interaction from people
that are further away from the core development.

I took a look at this myself and got disengaged when I realized that the
core team does all of its APIs in python. Which means that the only way to
ask the qubes-daemon something is to either write in python, or emulate the
way that python talks to it.

This does not make it impossible just significantly harder to write good GUIs
for Qubes.

[Franz]

Sorry for the obviously stupid question, but why is it harder to write it in python rather than something else?
 

--
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel

--
You received this message because you are subscribed to the Google Groups "qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscribe@googlegroups.com.
To post to this group, send email to qubes...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/7187767.jv0iuaymnc%40strawberry.

For more options, visit https://groups.google.com/d/optout.

[Tom Zander]

On Wednesday, 6 December 2017 13:02:43 CET Franz wrote:
> Sorry for the obviously stupid question, but why is it harder to write it
> in python rather than something else?

Not at all, its a good question.

It is harder to *have* to write it in python instead of any langauge any
developer may be actually good at.

It limits the pool of available developers, available toolkits/libraries and
other such resources quite dramatically.

[Unman]

On Mon, Dec 04, 2017 at 03:34:25PM -0800, Ro...@tuta.io wrote:
> Just read it. Thats fucking stupid.
>

> --

I think it's safe to say that opinion is divided on the removal.

[Elias Mårtenson]

I liked the old tool. However, I am also on the side of agreeing with its
removal.

The old tool was useful, but it wasn't any good. As Tom Zander suggested earlier,
someone else should create a new GUI. Like him, I also took a look at it but
decided not to, since Python is one of the languages I like the least, and when
it comes to unpaid work, I prefer doing it in a language I actually enjoy using.

There may be people out there that enjoy writing GUIs in Python, and I'm sure the
entire Qubes community would be immensly grateful if someone stepped up to the
task. I certainly would be.

[Unman]

"useful, but wasnt any good" - do you mean buggy or poorly designed?
What 2 features should be implemented/fixed?

I confess I rarely use the Manager, so don't have a feel for what's wrong
with it.

[Ro...@tuta.io]

The manager was the main thing I liked about how it helped show what was going on at any given time. Especially when running mulitple vms attached to different VPNs, Tor, etc..

Im a visual person and having this made it feel safe and secure to watch what was going on fast and making changes fast. I know of only 2 other people that use qubes personally. Both of which when I told them had the same response I did.

There was no reason to remove it when you could opt to not use it. Or make the gui more appealing but to replace it and claim "advanced users can use the command line", I stand by my original remark. I definitely will not be using 4.

[Tom Zander]

On Wednesday, 6 December 2017 16:08:28 CET Unman wrote:
> "useful, but wasnt any good" - do you mean buggy or poorly designed?
> What 2 features should be implemented/fixed?
>
> I confess I rarely use the Manager, so don't have a feel for what's wrong
> with it.

To be clear, the main reason the old one is removed seems to be that it
would have had to be reimplemented due to the architecture changes in 4.0

This is relevant to know because that means nobody actively thought
"It is not good enough, lets remove it".
The removal then, in my own opinion, means we have an opportunity to do
better.


To support the point of view of "useful but wasn't any good", let me explain
what I think such a tool should behave like.

The first issue with the old tool, and also with some of the new tools, are
that you already have to know how things work in order to be able to use it.
For instance the terminology 'appvm', 'templatevm' etc are completely not
explained anywhere. You have to go to a website to learn what the mean.

A clear success story of Qubes is its networking, abstracting the netVm is
done to add security without having any significant impact on usability.
Practically speaking, normal users can ignore the whole networking setup as
it "just works".

This is the level of support that we want. And most tools are nowhere near
that just yet.

Some examples of things that in 3.2 as well as in 4.0 are clearly in need of
a lot of love are;

* Which VMs are in which state. If you start something and the netvm/
firewall VM are auto-started, this is not at all clear to the user. If
something fails, it gets even worse.

* Network communication between Qubes. Routing via the firewallVM.

* Port forwarding. FirewallVM again.

* Media-management. Hard drives etc. It just barely works today.

* Graphical configuration of multiple qubes. Even in 3.2 not being able to
open more than one config dialog at a time was silly.


This is just a short list based on my experiments over the last month or so.
I'm sure others can add wishlist items.

[Ted Brenner]

Here are some use cases:

1) The ability to see all the VMs currently running in one easy spot. This helps me remember to shutdown certain VMs that I forgot to shutdown when I was done with them.

2) The ability to know which template VMs need updating.

3) Related to 2, which appVMs need to restart since their template was updated.

4) Easy place to make changes to VMs like expanding their available disk space.

To sum up Rory's point. It is a clean visual way to get a lot of information. I get that there's a new infrastructure so you'd have to rebuild it from scratch but it was a handy tool. Warts and all. At least for me.

--
You received this message because you are subscribed to the Google Groups "qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscribe@googlegroups.com.
To post to this group, send email to qubes...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20171206150828.irsiixodcwb5hu7s%40thirdeyesecurity.org.

For more options, visit https://groups.google.com/d/optout.

--

Sent from my Desktop

[Elias Mårtenson]

On Thursday, 7 December 2017 00:14:04 UTC+8, Tom Zander wrote:

> On Wednesday, 6 December 2017 16:08:28 CET Unman wrote:

> > "useful, but wasnt any good" - do you mean buggy or poorly designed?
> > What 2 features should be implemented/fixed?
> >
> > I confess I rarely use the Manager, so don't have a feel for what's wrong
> > with it.
>
> To be clear, the main reason the old one is removed seems to be that it
> would have had to be reimplemented due to the architecture changes in 4.0

I had a script that updated the templatevms and it was written in Python,
taking advantage of the API. This script stopped working in 4.0. I rewrote
it to use the commandline tools instead.

Perhaps a new UI could also be based on those tools. Without a need to use
Python, such UI could be implemented in any language. That would be an
interesting project.

> To support the point of view of "useful but wasn't any good", let me explain
> what I think such a tool should behave like.

I was the one who said that, and your statement is an almost spot-on summary
of my opinion.

> The first issue with the old tool, and also with some of the new tools, are
> that you already have to know how things work in order to be able to use it.
> For instance the terminology 'appvm', 'templatevm' etc are completely not
> explained anywhere. You have to go to a website to learn what the mean.

The 3.2 VM manager, with all is faults, did help newcomers a single place
to see what was going on. It's not harder in 4.0, but I'd imagine that to
a newcomer it would look a lot more opaque.

This, I believe, is the most important feature of a new UI; the ability
to guide a new user to the proper usage of the OS.

> A clear success story of Qubes is its networking, abstracting the netVm is
> done to add security without having any significant impact on usability.
> Practically speaking, normal users can ignore the whole networking setup as
> it "just works".

For a new UI, I imagine a graphical representation of the networking setup.
Think boxes with arrows, showing connections, ports, IP-addresses, etc.
In fact, hardware assignments could be represented there as well.

Do a Google image search for "flow control ui" to see what I'm thinking of.

> * Which VMs are in which state. If you start something and the netvm/
> firewall VM are auto-started, this is not at all clear to the user. If
> something fails, it gets even worse.

Easy access to the logs from here would be a most welcome quality-of-life
improvement.

> * Graphical configuration of multiple qubes. Even in 3.2 not being able to
> open more than one config dialog at a time was silly.

Yes. The fact that the old VM manager was blocking, and you couldn't do
anything with it while an operation was in progress was one of its biggest
flaws.

[Tom Zander]

On Wednesday, 6 December 2017 17:34:24 CET Elias Mårtenson wrote:
> I had a script that updated the templatevms and it was written in Python,
> taking advantage of the API. This script stopped working in 4.0. I rewrote
> it to use the commandline tools instead.
>
> Perhaps a new UI could also be based on those tools. Without a need to use
> Python, such UI could be implemented in any language. That would be an
> interesting project.

i was pondering between two options;
a) hope that the python APIs are just thin wrappers that send the actual
commands to the daemon process via a unix socket and instead write code that
uses the protocol on the socket in a language of choice.

b) generate an python script for certain calls and then call them in order
to call the APIs.

the first would be beneficial as that allows us to receive notifications
from the daemon (like a new VM starting).

My language of choice is Qt/C++ with QML for the GUI.

[Unman]

On Wed, Dec 06, 2017 at 05:13:56PM +0100, 'Tom Zander' via qubes-users wrote:
> On Wednesday, 6 December 2017 16:08:28 CET Unman wrote:
> > "useful, but wasnt any good" - do you mean buggy or poorly designed?
> > What 2 features should be implemented/fixed?
> >
> > I confess I rarely use the Manager, so don't have a feel for what's wrong
> > with it.
>
> To be clear, the main reason the old one is removed seems to be that it
> would have had to be reimplemented due to the architecture changes in 4.0
>

Tom, this is simply not true.
If you look at issue #2132 you will see that it was a deliberate design
principle. It has nothing to do with the architecture changes and
everything to do with simplifying the UX.

I have to say that most of the users I have helped to work with Qubes
(most unfamiliar to Linux and certainly unused to the command line),
simply DO NOT USE the manager.
The set up is such that with a custom menu they simply don't want (or
need) to know about the implementation, and the Manager would be
confusing.

Of course some people like to have this sort of stuff, just as some people
like to have conky configured with process lists etc, but it shouldn't
be a necessary part of running Qubes. Nor should the Qubes UX be led by
those people.

> This is relevant to know because that means nobody actively thought
> "It is not good enough, lets remove it".
> The removal then, in my own opinion, means we have an opportunity to do
> better.
>
>
> To support the point of view of "useful but wasn't any good", let me explain
> what I think such a tool should behave like.
>
> The first issue with the old tool, and also with some of the new tools, are
> that you already have to know how things work in order to be able to use it.
> For instance the terminology 'appvm', 'templatevm' etc are completely not
> explained anywhere. You have to go to a website to learn what the mean.
>
> A clear success story of Qubes is its networking, abstracting the netVm is
> done to add security without having any significant impact on usability.
> Practically speaking, normal users can ignore the whole networking setup as
> it "just works".
>
> This is the level of support that we want. And most tools are nowhere near
> that just yet.
>
> Some examples of things that in 3.2 as well as in 4.0 are clearly in need of
> a lot of love are;
>
> * Which VMs are in which state. If you start something and the netvm/
> firewall VM are auto-started, this is not at all clear to the user. If
> something fails, it gets even worse.
>
> * Network communication between Qubes. Routing via the firewallVM.
>
> * Port forwarding. FirewallVM again.

Neither of these are core tasks in Qubes, and I would expect that
someone who wants to implement this should be capable of setting it up,
and understand the risks in doing so.
It's possible that this could be implemented into a separate network GUI
but I see little advantage in including it in the manager. Frankly, it
has enormous scope for subverting the benefits of Qubes and I see great
danger in making it too easily available.

>
> * Media-management. Hard drives etc. It just barely works today.

Not my experience. There are occasional issues, but generally this seems
to work well. BUT basic users generally want little more than to load
data from USBs/phones and to backup to disk, and for them the new (and
old) tools seem to work fine.

[Tom Zander]

On Wednesday, 6 December 2017 19:28:54 CET Unman wrote:
> > the main reason the old one is removed seems to be that it
> > would have had to be reimplemented due to the architecture changes in
> > 4.0

> Tom, this is simply not true.
> If you look at issue #2132

That issue actually supports the point, to quote.
> the next-gen manager for Qubes 4.0 (which we need to rewrite anyway
> because of the changes in the core-ng)

But your reply is unnecessarily confrontational, it really doesn't matter
what the core devs decide on the GUI front as they also state they have an
open API.

As it turns out people are interested in a different GUI experience than the
one outlined in the quoted issue.

It is good to realize that a better GUI will allow a more secure usage.

> > * Media-management. Hard drives etc. It just barely works today.
>
> Not my experience. There are occasional issues, but generally this seems
> to work well

If you use a larger amount of features, stuff starts to fall apart fast,
though.
For instance I added a second drive, attached it to a VM. Noticed that the
only thing that happened was the appearance of a strangely named file in
/dev/
As far as I can tell you need to somehow guess which file to use in /dev and
then type a 'mount' command to actually access it. That requires CLI
interaction...

And thats just the most simple usecase I can come up with.

> BUT basic users generally want little more than to load
> data from USBs/phones and to backup to disk

How do you rate usecases like having your homedir (private partition) on a
second drive on a desktop computer?
Extremely common setup on desktops when you end up having many gigabytes
in your homedir. A multi-TB spinning disk costs a fraction of an ssd.

How about the usecase of auto-attaching and auto-mounting several drives on
a specific VM startup, every time it starts.
For instance a read-only (aka CDRom or Loopback) mountpoint in your homedir
of firefox settings shared between some of the VMs.

[Chris Laprise]

I also take this view. Qubes 4.0 shows what can happen when you change
UIs without consulting the community.

The devs seem to think that combining status info and functions in the
same window is bad design and/or intimidating to users. Now we have two
tiny icons on opposite sides of the screen and the user is starved of
info. I would welcome the return of Qubes Manager.

--

Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

[a.mc...@yandex.com]

I will support that point of view.
Could we please have a choice to stay with the manager or to use console/whatever?
Thank you.

[Unman]

Hi Tom

I'm sorry if you found my reply confrontational - I was just pointing
out that your assertion was false, and that it was a design decision to
remove the manager in it's 3.2 form.

Of course, if people want a GUI manager they can produce one - equally
people who don't want one can use command line tools or scripts to
provide the functionality they want.

On your "simple usecase" I'm just baffled - in both nautilus and
dolphin, when you attach USB devices to a qube, they appear in the file
manager and can be mounted simply by double clicking the device. No
command line, no looking in /dev (although the location isn't THAT hard
to find). Is this not your experience?

On the "homedir" on a second drive issue, I've done this for some users.
I've even talked someone through it on the phone. Should there be a GUI
for that? Really?

Don't misunderstand me - I understand that some users are dismayed at
the loss of the manager. I hardly used it, so the loss means nothing to
me. Few of the users I work with use it much, so the loss won't mean
much to them. But some people want something like it in 4, and it's
probably worth spending a little time on it, if only so that folk can
see the state of all their qubes in one window.

unman

[Unman]

Marek has made it clear that a rewritten VM Manager might be included as
an alternative, so there isn't TOTAL opposition to this, provided the
manager uses the core API.

[mikih...@gmail.com]

> Of course, if people want a GUI manager they can produce one - equally
> people who don't want one can use command line tools or scripts to
> provide the functionality they want.
>

That's the point. Since I cannot write one myself,
I stopped using qubes because my use case depends on it.
Some users may only ever use firefox and nothing else, they wouldn't mind
stripping every other (cli)tool from qubes. I see no point in making up lowest possible denominators of useability.
Qubes has a unique architecure of integrating virtual machines. If there are no
proper tools to make it possible for a user to adjust this system to his specific
use case withouth the need to write a program, some people may stop using it
(also last I checked there wasn't a proper documentation on the new commands).
I don't think that's good or bad and maybe I'm the only one who's going back to a
different OS.
regards
Loved 3.2 A truly great software.

[Elias Mårtenson]

On Thursday, 7 December 2017 11:56:13 UTC+8, mikih...@gmail.com wrote:

> I stopped using qubes because my use case depends on it.

I'm not going to judge the way you use the software, but I am curious
as to what kind of use case you have that made the VM manages so important
that you literally can't use Qubes without it?

[Franz]

On Wed, Dec 6, 2017 at 3:28 PM, Unman <un...@thirdeyesecurity.org> wrote:

On Wed, Dec 06, 2017 at 05:13:56PM +0100, 'Tom Zander' via qubes-users wrote:
> On Wednesday, 6 December 2017 16:08:28 CET Unman wrote:
> > "useful, but wasnt any good" - do you mean buggy or poorly designed?
> > What 2 features should be implemented/fixed?
> >
> > I confess I rarely use the Manager, so don't have a feel for what's wrong
> > with it.
>
> To be clear, the main reason the old one is removed seems to be that it
> would have had to be reimplemented due to the architecture changes in 4.0
>

Tom, this is simply not true.
If you look at issue #2132 you will see that it was a deliberate design
principle. It has nothing to do with the architecture changes and
everything to do with simplifying the UX.

I have to say that most of the users I have helped to work with Qubes
(most unfamiliar to Linux and certainly unused to the command line),
simply DO NOT USE the manager.

Well that proves nothing. If you do not much use the manager and are teaching people to use Qubes, then you tend to teach to follow the way you do things and your followers will just do that.

On the contrary I am using the manager for everything also for starting applications and when I teach Qubes teach it this way and it is learned this way, so that loosing the manager means loosing all references to be able to use Qubes.

[mikih...@gmail.com]

It's actually not the sole reason. And I'm glad for everyone who qubes does work for.It's a great software. But having the tools providing the means for people
to 'make' it work may be a positive thing.

[Chris Laprise]

I myself find it strange and frustrating using Qubes VMs without the
visual reminders for the templates they're based on, updates, last
backup date, etc. If I need to see the template for a VM, going into VM
settings feels like cognitive dissonance.

Qubes might benefit from focusing the UI on a Qubes Manager-like
interface, even to the point where guest apps are launched from it. Why
shoehorm the new paradigm into existing DE tools? That will not get you
the attention of the DE projects or potential userbase.

[Elias Mårtenson]

On 7 December 2017 at 12:57, Chris Laprise <tas...@posteo.net> wrote:

 

I myself find it strange and frustrating using Qubes VMs without the visual reminders for the templates they're based on, updates, last backup date, etc. If I need to see the template for a VM, going into VM settings feels like cognitive dissonance.

Qubes might benefit from focusing the UI on a Qubes Manager-like interface, even to the point where guest apps are launched from it. Why shoehorm the new paradigm into existing DE tools? That will not get you the attention of the DE projects or potential userbase.

I don't think anybody disagrees with you. No one in this thread has said that they don't want to see

a new management UI. And I do believe that even the devteam agrees with this. That suggests that

if someone puts something together there is a high chance that it could be included in Qubes

proper.

I have said that I would like to do the work, but there are factors that make it impossible for

me to invest any time into it at this time. The surely must be others who are willing to put

in the time to do it?

There are certainly enough people complaining about it that there should be at least some

people able to scratch that itch.

If you're not capable of doing the work, I understand it can be frustrating to see no progress being

done on aspects of the system that you feel is important, but do keep in mind that the devteam

are resource-constrained and they have to follow their own priorities.

[Hanno 'Rince' Wagner]

Hi everybody!

On Thu, 07 Dec 2017, Unman wrote:

> I'm sorry if you found my reply confrontational - I was just pointing
> out that your assertion was false, and that it was a design decision to
> remove the manager in it's 3.2 form.

This is something I can (and have to ;) accept because the design
decisions of the developer are important and I won't be able in the
near future to see all the consequences.

> Of course, if people want a GUI manager they can produce one - equally
> people who don't want one can use command line tools or scripts to
> provide the functionality they want.

There is a problem: I am no progammer. So I can not do this.
Right now I am not using Qubes-OS. This is because I tried it first on
a USB-Stick (failed of course ;) then on my hard drive. Worked fine
and I was able to define my Network-VMs for VPNs and stuff. Since I
used the official documentation I was able to create my environment.
I love it that I have a GUI which tells me which VMs are there, which
are running, what's the state of them. And to know which templates I
have.
Right now I can not - first of all because I tried Qubes 4 and it
failed; but I don't have the time for debugging, so I'll wait for the
final release. Second, because I hoped and waited for a new Qubes VM
Manager or a replacement, because I did not want to start CLI-Tools
for a desktop environment. For me, this is a step backwards.

I was a sysadmin before, I am very familiar with CLI-Tools, and I will
be able to use them - but I am not sure wether I want to, for my
private laptop. Just because I want to make sure everything is right
and _for me_ the easiest way is some kind of Dashboard like the Qubes
VM Manager was or is.

> On the "homedir" on a second drive issue, I've done this for some users.
> I've even talked someone through it on the phone. Should there be a GUI
> for that? Really?

Why not? for the end user, a graphical interface is better to
understand and to use. For sysadmins who have a bunch of machines to
maintain, of course not, they want and need CLI-Tools - or better: APIs.

> much to them. But some people want something like it in 4, and it's
> probably worth spending a little time on it, if only so that folk can
> see the state of all their qubes in one window.

for me, the documentation and the screenshots helped a lot understand
how QubesOS works. So I'd prefer to have at least a GUI to see the
state of the VMs.

best regards, Hanno Wagner
--
| Hanno Wagner | Member of the HTML Writers Guild | Rince@IRC |
| Eine gewerbliche Nutzung meiner Email-Adressen ist nicht gestattet! |
| 74 a3 53 cc 0b 19 - we did it! | Generation @ |
Fachbegriffe der Informatik : ZConnect
-> Der gescheiterte Versuch eines Künstlers, automatisch übersetzte Fragmente
der UUCP-Dokumentation zu einer Collage zusammenzufügen.
Felix Deutsch

[Zrubi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 12/07/2017 04:56 AM, mikih...@gmail.com wrote:

> I stopped using qubes because my use case depends on it.

> Loved 3.2 A truly great software.

3.2 is the STABLE version of Qubes.
And it will be supported for a full year AFTER the 4.0 release.

So there is no point to bury it because of a missing feature in the
latest release candidate...

Saying it while I'm also think that removing the Qubes Manager was a
big mistake. Thant new thing in the info bar is buggy and useless in
my use case too.


- --
Zrubi
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJaKP30AAoJEBozWgtUjzdkr+cP/RY1dsagzFpv3proaAaQ8VWu
tS6kfiVP5zxOBKY5sAKbY6H960OGfAvMWUm0HrRafeIawYQ/9MW8LnQ+boMdOdD+
t8A1yGqyheb+rqgbFWX01QnCqjtENubibYQkYhGYUdjZzvpk/SM9YX188yqCQnsh
7tZJmozfHgGaM43o1x4I7NOxAEC4rwamv7fsKV616RjyAX4iXMdY945RTBa2x3ir
gawdcsZQ7JMMFavTd5bwD3Edq1YJ2BS1S/5ATtDLubNXo2EunlyT3kJ8t16EIfS3
RVmTzu7d+WdtvNDNh2bLxMwQ77vO9F2HtvQ5NCS8LQlDLKsPhzdk3uPneJBi/N2/
hGn5oAdKdskjzNgu/i+edK2SEOjCFj8jcSoRHH46N2XQ1jL4x6XE0t1o2M53ypEJ
5Yo4nZom4O/f5wLyr+uKFau8cb2Md7UEAhv+9cGNeZzF4Q96Wka3eIjiDhERKi+H
T/u4CfX0U/2fGCNVs6kLbBL4nliRCmP6J5UDwUewISpfRJ7kC5fVnptxZhY4uVmx
sZ07QvyWki2pG8oGP1WyIx5JT91KNbE2RiNjzUo0y0CnxQtZCPoOIxwUHEBipQE2
IqJwZGLpd85PPoE9pNwUhFcViLcnd+VJAaLjWxkpk9R1l/U/ztkx704Dm4Dk7PM9
KcDKAkruk247e98XsU9c
=NelY
-----END PGP SIGNATURE-----

[Ro...@tuta.io]

3.2 also doesnt have current drivers updated for new equipment. I couldn't get 3.2 installed on my new setup but 4 installed.

Saying its supported doesnt say much if cant handle new equipment and just old machines.

I save alot of time using qubes as I need to deploy VMs all the time for clients. But not having an interface to monitor means 4 is useless to me.

[Ro...@tuta.io]

On another note what would it take ($$$) for someone to create this back on 4 as an option for the community (obviously theres quite a few of us) that want this to install?

Im not rich by any means living in one bedroom apt and work from home but this does help me with work and would donate towards getting this done.

[Franz]

On Thu, Dec 7, 2017 at 8:29 AM, <Ro...@tuta.io> wrote:

On another note what would it take ($$$) for someone to create this back on 4 as an option for the community (obviously theres quite a few of us) that want this to install?

Im not rich by any means living in one bedroom apt and work from home but this does help me with work and would donate towards getting this done.

that is an interesting approach, developers can make programs, but non-developers can pay for others to do it. I offer $5000.

Fran

--
You received this message because you are subscribed to the Google Groups "qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscribe@googlegroups.com.
To post to this group, send email to qubes...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/cba6de65-ea32-4692-b740-d8442ed97a07%40googlegroups.com.

[Unman]

Franz,

I choose not to use the manager. But, as I've said before, my
requirements are probably very different from most users. For various
reasons, I don't listen to music/play games/ use YouTube/ etc etc - most
of the stuff I do is in a terminal. Even people who like me think this is
weird.

But the people I help use their computers in very different ways from
that.
I don't teach them not to use the manager, I show them how to use Qubes
without the manager - some of them find it for themselves, and like it
- some don't.

Here are some things these users DONT want to do:
Start a qube
Stop a qube
Start a disposableVM
Look in the manager to see if there are updates.

Here are some of the things they want to do:
Read their emails.
Go online in a secure way.
Browse without risking their emails/bank accounts
Open a web browser that wont keep history/cant compromise their private
stuff.
Look at pictures from phones/ downloads as safely as possible.
Keep their system updated.

Do you see what I mean? For many users the HOW of Qubes is completely
irrelevant, and because the Manager focusses on that it's a distraction.
The default Menu system has the same problem - it draws attention to the
qubes, not the activities.
So by providing a simple menu system, a few templates and some minor
configuration you can have a workable system that almost anyone can use
without knowing anything about the Qubes infrastructure, and without
need for the Manager.

Will this suit everyone? Of course not - it doesn't suit me. It certainly
wont suit many of the people in this thread. If this is any guide then
many current users seem to want something in 4.0
For that reason I think it's worthwhile spending some time on
reinstating something like the old Manager in 4.0. I've started on this
focussing on the "display" side of the current Manager, rather than the
function side that some people seem to want to enhance. Let's see how we
get on.

unman

[Ro...@tuta.io]

The manager isnt a distraction. You dont need to focus on it if you choose not too. Your needs are very basic showing peoples emails. For those of us that use it for work and get others we work with to use it also it is important.

Clearly plenty others here prefer the manager and you keep reiterating why it isnt important to you and teaching people to use email securely.

[Ro...@tuta.io]

Additionally I would rather donate money to devs that can work on what i need added back on here as a priority rather than donate to the project itself that doesnt see these things as a priority.

[Unman]

On Thu, Dec 07, 2017 at 07:46:31AM -0800, Ro...@tuta.io wrote:
> The manager isnt a distraction. You dont need to focus on it if you choose not too. Your needs are very basic showing peoples emails. For those of us that use it for work and get others we work with to use it also it is important.
>
> Clearly plenty others here prefer the manager and you keep reiterating why it isnt important to you and teaching people to use email securely.
>

I think that you replied a little hastily, and didn't get as far as my last paragraph.
I'll say it again:

Will this suit everyone? Of course not - it doesn't suit me. It certainly
wont suit many of the people in this thread. If this is any guide then
many current users seem to want something in 4.0
For that reason I think it's worthwhile spending some time on
reinstating something like the old Manager in 4.0. I've started on this
focussing on the "display" side of the current Manager, rather than the
function side that some people seem to want to enhance. Let's see how we
get on.

I think that the Manager (and the Menu system) focusses too much
attention on the HOW of Qubes, both in 3.2 and 4. But other people dont
share this view, and want to have something like the old Manager. As
Marek has said they would consider including something like that in 4.0,
it's worth seeing what can be done. That is one reason why I asked
which 2 features should be retained - only a few people have actually answered
that question, as far as I can see.

unman

[Ro...@tuta.io]

Ok well talking about 2 features when theres more then 2 features that users prefer.

Backups and restoring backups should be a definite.

When dealing with net VMs the ability to watch which VM is attached to which netvm and what is running properly and didnt shutdown. Same features as even virtualbox uses.

[Unman]

Backup/restore is already on the target list.
What doesnt seem to be at the moment is the ability to show all qubes,
and how they are connected, and what their status is. That's a nice
target.

[Elias Mårtenson]

On 8 December 2017 at 00:16, Unman <un...@thirdeyesecurity.org> wrote:

 

Backup/restore is already on the target list.
What doesnt seem to be at the moment is the ability to show all qubes,
and how they are connected, and what their status is. That's a nice
target.

If by "status" you include the update state, then that would make the new solution on par with the old VM manager, yes?

Regards,

Elias 

[Tom Zander]

On Thursday, 7 December 2017 14:17:52 CET Franz wrote:
> > On another note what would it take ($$$) for someone to create this back
> > on 4 as an option for the community (obviously theres quite a few of us)
> > that want this to install?
> >
> > Im not rich by any means living in one bedroom apt and work from home
> > but
> > this does help me with work and would donate towards getting this done.
>
> that is an interesting approach, developers can make programs, but
> non-developers can pay for others to do it. I offer $5000.

Hi guys,

I've investigated the possibilities today about how this can be done from a
purely technical point of view.

It seems possible, and to test this I am writing a very simple app that
retrieves the current Qubes and their status from the central qubes system.
Just as a proof-of-concept.

Looks promising so far!

[js...@riseup.net]

mikih...@gmail.com:

>> Of course, if people want a GUI manager they can produce one - equally
>> people who don't want one can use command line tools or scripts to
>> provide the functionality they want.
>>

> That's the point. Since I cannot write one myself, I stopped using qubes because my use case depends on it. Some users may only ever use firefox and nothing else, they wouldn't mind stripping every other (cli)tool from qubes. I see no point in making up lowest possible denominators of useability.
> Qubes has a unique architecure of integrating virtual machines. If there are no proper tools to make it possible for a user to adjust this system to his specific use case withouth the need to write a program, some people may stop using it (also last I checked there wasn't a proper documentation on the new commands). I don't think that's good or bad and maybe I'm the only one who's going back to a different OS.
>
> regards

> Loved 3.2 A truly great software.

Keep in mind that 4.0 is still basically in beta and hasn't actually
been released yet (someone else pointed out that it's a "release
candidate" and not beta, and there's a difference, but still). 3.2 is
still the latest stable release. I still use 3.2, and it works great for
me. 3.2 should still be an option for you if the lack of qubes manager
in 4.0 is a show stopper. Unless there's some reason you can't use 3.2?

Anyway, I'm just hoping people don't move away from qubes completely
just because the unreleased beta version is missing a useful feature.
Qubes is a lot less vulnerable than other OSes. It works great for me in
general and I think it's definitely worth a few minor inconveniences.

I will add my vote in favor of the qubes manager though btw. I know
everything qubes manager can do can also be done in command line, and
I'm comfortable enough with the command line that I can make it work,
but it would be less convenient for me to have to do without qubes
manager, despite its flaws!

-Jackie

[Ro...@tuta.io]

I installed my new drive on my laptop and put 3.2 on there and just updated the kernels and fixed so it would boot properly. Alot more time consuming and now working out the minor fixes.

All in all its still a pain that first i found the kernel was too old for 3.2 to be installed so i switched to 4 and then find out that the feature i need was missing and back to 3.2 to get that working.

For all the new computers I setup I assume I'll have the same issue. In no way would I ever consider 4 stripped in its condition even usuable in beta becuase of my needs.

[Drew White]

On Wednesday, 6 December 2017 23:34:21 UTC+11, Tom Zander wrote:
> On Wednesday, 6 December 2017 13:02:43 CET Franz wrote:
> > Sorry for the obviously stupid question, but why is it harder to write it
> > in python rather than something else?
>
> Not at all, its a good question.
>
> It is harder to *have* to write it in python instead of any langauge any
> developer may be actually good at.
>
> It limits the pool of available developers, available toolkits/libraries and
> other such resources quite dramatically.

> --
> Tom Zander
> Blog: https://zander.github.io
> Vlog: https://vimeo.com/channels/tomscryptochannel

Python is bloated and slow.

I wrote my own manager for 3.2 and it does more than what theirs did, and it does it cleaner and more efficiently with much less RAM and CPU utilisation.

They never fixed the issues I told them about in the Manager for 3.2.
They updated it and made it worse.

The things I recommended be fixed, they didn't do it right even when they tried to fix it. But I think that that may have been a limitation of Python rather than them.

[Franz]

@Unman

I understand what you mean, but again it all depends how you teach it. My wife wasn't even able to send an email, but when I told her to look at the manager for updates of templates she did it. Did she likes that? Of course not. But when I explained that an updated system is important for security she keeps updating it. When she asked: how can I start firefox? I replied: Manager, right button, run in VM, firefox. She keeps doing that. On the contrary if I had told her: start menu on the left look for you VM and firefox under that, she would do just that.

4 four mouths ago she was raged against Qubes being to difficult (for some reason when she plugs a usb key into the slot it stopped working) so she bought a Mac, but it is still there because she does not know how to use it. So reverted to Qubes again even if the USB is not working.  What I want to say is that people that do not like to experiment with computer just memorize what they are told and always do the same steps just happy that it works.

[Chris Laprise]

On 12/07/2017 11:17 PM, Franz wrote:
>
> 4 four mouths ago she was raged against Qubes being to difficult (for
> some reason when she plugs a usb key into the slot it stopped working)
>

FWIW, I get this also. In my case some USB3 drives with buggy firmware
can prevent the system from booting.

[Chris Laprise]

On 12/07/2017 12:17 PM, 'Tom Zander' via qubes-users wrote:
> On Thursday, 7 December 2017 14:17:52 CET Franz wrote:
>>> On another note what would it take ($$$) for someone to create this back
>>> on 4 as an option for the community (obviously theres quite a few of us)
>>> that want this to install?
>>>
>>> Im not rich by any means living in one bedroom apt and work from home
>>> but
>>> this does help me with work and would donate towards getting this done.
>> that is an interesting approach, developers can make programs, but
>> non-developers can pay for others to do it. I offer $5000.
> Hi guys,
>
> I've investigated the possibilities today about how this can be done from a
> purely technical point of view.
>
> It seems possible, and to test this I am writing a very simple app that
> retrieves the current Qubes and their status from the central qubes system.
> Just as a proof-of-concept.
>
> Looks promising so far!

There is the question of whether someone should try porting the original
Qt-based Qubes Manager to R4.0. I mention this since the biggest
complaint so far is not having a _comprehensive_ UI; Updating QM for the
new Qubes API could be the most direct path to addressing that need.

I'd like to know what people think...

[Hanno 'Rince' Wagner]

Hi Chris!

On Fri, 08 Dec 2017, Chris Laprise wrote:

> There is the question of whether someone should try porting the original
> Qt-based Qubes Manager to R4.0. I mention this since the biggest complaint
> so far is not having a _comprehensive_ UI; Updating QM for the new Qubes API
> could be the most direct path to addressing that need.

start from scratch. I'd say start with the status of the VMs, follow
with start/stop/update and Backup/Recover.
And then ask what else is needed ;)

Mit freundlichen Grüßen, Hanno Wagner

best regards, Hanno Wagner
--
| Hanno Wagner | Member of the HTML Writers Guild | Rince@IRC |
| Eine gewerbliche Nutzung meiner Email-Adressen ist nicht gestattet! |
| 74 a3 53 cc 0b 19 - we did it! | Generation @ |

#"The slogan for Perl culture is 'There is more than one way to do it.'. [...]
# The Perl slogan on Windows is [...] 'It's a good thing there is more than one
# way to do it, because most of them don't work.'" -- Larry Wall

[Tom Zander]

On Friday, 8 December 2017 06:09:32 CET Chris Laprise wrote:
> There is the question of whether someone should try porting the original
> Qt-based Qubes Manager to R4.0. I mention this since the biggest
> complaint so far is not having a _comprehensive_ UI; Updating QM for the
> new Qubes API could be the most direct path to addressing that need.
>
> I'd like to know what people think...

I’m a big fan of Qt, but the original was written in python (using the Qt
python bindings) which is my least favourite choice in language, and on top
of that the original QM had many problems for the user experience.

I also know that the “state of the art” in creating user interfaces has
moved on and the technology used in the old app is end-of-lifed for some
years now.

All in all, you’ll get a nicer app if you ignore the code of the old one.

[Tom Zander]

On Friday, 8 December 2017 06:09:32 CET Chris Laprise wrote:

> What I want
> to say is that people that do not like to experiment with computer just
> memorize what they are told and always do the same steps just happy that
> it works.

I fully agree with that and it mirrors my observations.

Personally I blame Windows for this as that one breaks so easy, and anyone
else that at any time tells a person they are doing something "wrong".
Being told (as a non-tech person) you are doing it wrong is literally the
worst thing you can do to that person as they will lose their ability to
have confidence and subsequently they will lose their will to experiment.

An OS like Qubes will lose its objective if it starts telling people they
are doing it wrong.
Instead, make every effort to show them the right way, and allow
experimentation.
In other words; enforce correct behaviour and warn against (but do not
forbid) possibly bad behaviour.


Anyhow,

I leared from your post that it was possible to start apps from the old QM,
I never knew that, I never tried! :)

Thanks for sharing that!

[Matteo]

>
> Here are some things these users DONT want to do:
> Start a qube
> Stop a qube
> Start a disposableVM
> Look in the manager to see if there are updates.

at least a bit of the inner working must be known: disp vm is useful and
you have to stop a qube that you don't use to free some resources.
updates could be made automatic (or manual if a usere prefear this).

> Here are some of the things they want to do:
> Read their emails.
> Go online in a secure way.
> Browse without risking their emails/bank accounts
> Open a web browser that wont keep history/cant compromise their private
> stuff.
> Look at pictures from phones/ downloads as safely as possible.
> Keep their system updated.

I always used windows, and i find it easy to use:
just two buttons (mouse) + is all gui.
from long time i started using virtual box to open untrusted exe (any
exe) to increase my security and when i learnt about qubes i have found
it as a natural extension of what i was already doing.

i have found the qubes manager quite similar to the virtual box window
used to start, stop and edit vm settings and both were VERY nice and
EASEY to use.

i have not yet tested qubes 4 because i'm waiting for the definitive
version and because if vt-d and slat become mandatory i don't have them
so qubes will not run (on my pc i have only vt-x).

as a user i don't care in which language is written the manager, if it
is a single big app or small with plugins, i also understand that for a
developer it makes a huge difference.

i hope that a new manager will be written; or something where you can
find the state of the whole system without using the terminal.

i CAN use linux but i DON'T want to use it, i find gui much easier and
faster to use and to learn.
please don't force users to use a terminal, it is not going to work
https://www.xkcd.com/1168/

from qubes manager you could rightclick, open settings and just by
looking and clicking tabs you could see all the possible settings, for
example you could see that a setting " ammount of ram" existed and what
was its value.
how am i supposed to discover that such setting exists using a terminal?

[Unman]

You could make it even easier by providing a custom menu that matches
expectations and "does the right thing".
Menu - Firefox - opens online qube and opens Firefox.
Menu - Banking - opens restricted qube and opens Firefox.
Menu - Email - opens email qube and opens Thunderbird.
Menu - Libreoffice Writer - opens offline qube and opens Libreoffice.

By customising mime handling in the qubes you can enforce opening files
in a disposableVM, etc.

All this has the advantage that almost anyone can start working straight
away, without any instruction, just because it matches their
expectations.
A few launchers in the panel make it even easier.

It helps if users understand how to transfer files from one qube to
another, and the menu items are really helpful there, and build on what
they already know. As I've said before, (many times) it's the funny
cut/paste that takes getting used to.

> 4 four mouths ago she was raged against Qubes being to difficult (for some
> reason when she plugs a usb key into the slot it stopped working) so she
> bought a Mac, but it is still there because she does not know how to use
> it. So reverted to Qubes again even if the USB is not working. What I want
> to say is that people that do not like to experiment with computer just
> memorize what they are told and always do the same steps just happy that it
> works.

Yes, so I take advantage of what they already know.

On the hardware front I always have them run Qubes Live to make sure
that there are no immediate problems. USB can be a problem, particularly
USB3 for some reason, but nothing I haven't found insurmountable.
Naturally, different people have different experiences - but this is the
case for many Linux distros - I don't think Qubes is peculiar in that.
It's interesting how many issues raised in Qubes use can be solved by
googling for solutions in other distros. People forget that in many
cases it will be a Fedora/Debian issue at root.

Anyway, I don't want to labour the point.
Enough people seem to like the Manager style approach to make it worth
putting something like it into 4.0.

unman

[Tom Zander]

On Friday, 8 December 2017 11:50:07 CET Unman wrote:
> Anyway, I don't want to labour the point.
> Enough people seem to like the Manager style approach to make it worth
> putting something like it into 4.0.

You wrote a very interesting mail, with lots of great ideas on how to make
the workflow better.
I really like the idea to have application icons match your VMs.
The 4.0 start menu forces users to first pick a qube and then pick an app.
With a Firefox available in each and every qube...

I think this thread is more about having any sort of user friendly tools
than it is specific about the QM.
Its just that most users have only ever had the QM, and then even that was
taken away from them in 4.0 :(

I'd say you (Unman) are in a great position to brainstorm ideas we can try
to find a good user interface that helps people stay secure and helps them
survive, to even thrive.

I'd like to write a simple app that people whom were used to the QM can
relate to. With some people here stating they are willing to pay for the
service, I can make some time for that.
As that crystallizes, maybe more people can jump in and work on other stuff.

[Chris Laprise]

On 12/08/2017 04:29 AM, 'Tom Zander' via qubes-users wrote:
> On Friday, 8 December 2017 06:09:32 CET Chris Laprise wrote:
>> There is the question of whether someone should try porting the original
>> Qt-based Qubes Manager to R4.0. I mention this since the biggest
>> complaint so far is not having a _comprehensive_ UI; Updating QM for the
>> new Qubes API could be the most direct path to addressing that need.
>>
>> I'd like to know what people think...
> I’m a big fan of Qt, but the original was written in python (using the Qt
> python bindings) which is my least favourite choice in language, and on top
> of that the original QM had many problems for the user experience.
>
> I also know that the “state of the art” in creating user interfaces has
> moved on and the technology used in the old app is end-of-lifed for some
> years now.

Which end-of-life technology would that be?

[William Bormann]

Glad you asked.

I'd prefer the development team focus on the security and stability of the 4.0 release candidate system and not divert any resources to the old 3.2 manager. The CLI is fine as far as I'm concerned.

[Tom Zander]

On Friday, 8 December 2017 14:56:00 CET Chris Laprise wrote:
> > I also know that the “state of the art” in creating user interfaces has
> > moved on and the technology used in the old app is end-of-lifed for some
> > years now.
>
> Which end-of-life technology would that be?

In Qt5 (released 19 December 2012) the qwidget module was split off onto its
own and the APIs in that module have been frozen ever since.
This details the module; https://doc.qt.io/qt-5/qtwidgets-index.html

Newer applications using Qt are suggested to use the declarative APIs which
have the added benefit of using the massive speedups Qt GUIs get from using
modern hardware and new architecture.

[Unman]

Some time back there was discussion about using Salt to produce
different Qubes flavours. I think this is still on the roadmap
somewhere.

The fact is that some users like selecting a qube, and then the
application, and it seems a natural way to work. I dont. But it's good
to have a variety of approaches.
Simple Qubes with custom menus seems to me to be the best way to have a
wider uptake - anything to work against the idea that Qubes is only for
nerds using the command line - "linux greybeards" was the somewhat
sexist phrase I think.