On Wed, Dec 06, 2017 at 10:41:23PM +0100, Tom Zander wrote:
> 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.
> -- 
> Tom Zander
> Blog: https://zander.github.io
> Vlog: https://vimeo.com/channels/tomscryptochannel

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






-- 
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 [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20171207011439.244bq26kmlwbn3xc%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Reply via email to