zlacker

[parent] [thread] 3 comments
1. hatedu+(OP)[view] [source] 2017-11-19 19:15:14
Could they just copy how iOS does interaction? Different menus like the share menu for example or the password manager menu? I can’t really think of what interaction I need besides maybe ide or terminal stuff.. are both of those systems restrained by qubes? Every bash command is in its own vm? Even so the terminal should still be able to redirect outputs between programs so that can’t really be a problem can it?

Is chromes process per tab model restricted? Forking and piping in general perhaps?

replies(1): >>hyperf+y
2. hyperf+y[view] [source] 2017-11-19 19:21:27
>>hatedu+(OP)
That definitely is the first thing that comes to mind, but applications need to be built under that model.

Currently all applications assume they get access to everything by default, so even if one was to be able to implement a confirmation dialog, the user would be victim to a battery of requests.

This is not to mention that isolation excludes discoverability, so users would have to manually make files visible to other applications beforehand.

replies(1): >>hatedu+91
◧◩
3. hatedu+91[view] [source] [discussion] 2017-11-19 19:28:02
>>hyperf+y
Hmm so I suppose the only problem is that developers are t aware they’re targeting qubes/ aren’t designing around qubes yet? Seems like a non issue really, since if qubes gets any traction it will literally solve itself.. although if it doesn’t get traction I suppose that’s slightly annoying tk deal with
replies(1): >>hyperf+g2
◧◩◪
4. hyperf+g2[view] [source] [discussion] 2017-11-19 19:40:12
>>hatedu+91
Being incompatible with most available software is not a 'non issue'.

The problem won't solve itself by adoption if it never gets to that point, that's almost a perfect catch-22.

[go to top]