Issues...* When launching a program from the Qubes menu, particularly if thetarget appVM has to be started, the program often fails to belaunched. This happens very frequently with the Text Editor.
Since I had been using Linux distributions based, directly orindirectly, on Debian, when I first set up Qubes, I created my appVMsbased on Debian. That was painful as I then had to install a lot ofbasic software.When I re-read the documentation, I realized the security reasons,so I switched all my appVMs (except one!) back to Fedora. It was notpainful, but I would have rather have spent the time doing somethingelse.
Since Firefox and Flash were working fine on my Linux Mint laptop(which I use "to play with"), I re-based my untrusted appVM on Debianand, lo and behold, Firefox and Flash worked just fine. This, by theway, was when I attempted to use Chromium.
At least for some people, it seems Debian is a necessity, but it isnot given the attention it deserves. At a minimum, a GUI softwareinstaller should be included in the Qubes distribution which wouldmake it much easier for people to install other software they feelinclined to use.
* Screenshot only appears to work from Qubes Tools. I can "add""Screenshot" to appVMVs based on Fedora (but not on Debian). But itdoes not work -- The dialog comes up but, having chosen to select anarea, I cannot do so.Subsequent attempts to use Screenshot do not even present a dialog.Although I have not seen this documented anywhere (which does notmean it is not), it seems logical -- dom0 owns the screen (monitor),so it makes sense that it handles screenshots. However, that meansscreenshots are saved in dom0 and have to be moved (or, I suppose,copied) to the desired appVM. It seems a bit awkward. If one is in aprogram in an appVM and decides a screenshot would be nice, it isprobably focussed on that window or a portion of it. Since the OSdisplaying the window "knows" what it is displaying, it seems logicalthat some kind of screenshot could be made by that OS, but restrictedto its window.
"The current Firefox ESR does have a tendency to freeze temporarily when
memory gets low. I'm considering switching to the non-ESR 'firefox'
package in Debian to see if the newer versions are better in this respect."
My computer (Intel NUC7i7) has 32 GB RAM, so I doubt I am having low memory issues -- but I suppose with my tendency to open a lot of tabs, it could happen.
I finally got around to trashing the ESR version of Firefox and installing the latest "regular" release. It is too early to tell (less than a day), but I have not run into a problem yet (I had been running into the problem at least once or twice a day).
--
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...@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/9fbf11f4-2ca3-45f5-ba11-b708b405ba3a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
As much as is really quantifiable...what percent of the real-world risk of the Intel ME to end-user is related to the fact that the manufacturer-whitelisted networking chipsets are directly usable by the firmware, primarily in support of the AMT feature set (and anything remotely hijacking via AMT, potentially without local compromise)?
Which is to say: isn't one important mitigation of remote pwnage the disabling and/or removing (as appropriate) of the manufacturer-supplied network connections? Without a custom firmware, one can always use a USB-based wifi/ethernet connection..and with custom firmware (when possible) you can bypass the hardware whitelist and supply your own third-party wifi/bt card that the local AMT portion of the firmware has not been designed to talk to.
Brendan
Marc Griffiths
marc.d.g...@gmail.com
--
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...@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/d84a4fe5-1dcf-4c77-b86a-663672532fcd%40googlegroups.com.
This is based on my personal experience on using qubes on a daily basis for almost over a year already.
So far I've only encountered corruption of data through the use of qvm-copy/qvm-move commands to move stuff from vm to vm and this is a rare case too since it probably only happens once or twice over a hundred times. With this in mind, the LVM thin fs of Qubes I believe, is extremely reliable.
So with that I believe the problem most likely leans more towards the software that you are using, with respect to the distro that you are using as well.
I haven't had much trouble using any software so far in my experience of using qubes provided they have the right dependencies installed, with respect to my usage of fedora minimal template.
Despite that however, I agree with your sentiment about USB devices and the detaching notification though I am not entirely dependent on it since I can go ahead and confirm myself whether or not the usb device was detached by running "sudo lsblk" on the qube where the USB was attached and on the sys-usb qube itself. Convenience-wise, it is bad yes and there is definitely room for improvement.
Also mind you that flash is a HUGE BLOB of SECURITY RISK. If you're using qubes for security reasons then using flash is really counterproductive against it not unless you really know what you're doing.