Hash: SHA256

On 08/01/2017 01:02 PM, Marek Marczykowski-Górecki wrote:
> On Tue, Aug 01, 2017 at 11:25:11AM +0200, Zrubi wrote:

>> - The isntall process is really looooong. Not debugged jet but
>> the creating initramfs seems to be running forever. But at least
>> was successfull at the end :)
> Is it just about initramfs and "post installation tasks" - compared
> to the whole installation time? There may be some bug causing
> initramfs being generated twice (or more...) - I think I've fixed
> something like this before, but maybe not all the places.
Yes, this is the case.
But have no time to install it again and again to identify the root
cause :(

>> - the missing Qubes Manager is a pain. - the 'replacement' in the
>> task bar is small and buggy: the tooltip? like thing is randomly
>> shirk to unusable. But too samll in general. I have 40 vm's right
>> now.
> What do you mean by "randomly shirk to unusable"? Can you provide
> a screenshot?

> What do you mean? Domains widget is specifically there to show you 
> VM status.

Can't see the networking stuff.
The most important is (at least for me) the actual NetVM used by a Qube.

>> - the 'new' Qubes firewall solution causing more confusions. -
>> mixed iptables and nftables? why?
> What do you mean by mixed? Setting for VMs are applied using
> nftables if supported (Fedora), or iptables when not (Debian). Not
> both.

the default "self defending rules" are Iptables based, the VM traffic
forwarding rules are nftables based.

Custom firewall scripts now have to handle both.
My opinion that there is no real need for nftables until it can really
replace iptables. We are using just a really few rules here and the VM
based chains achievable by iptables too.

I plan to continue the L7 filtering thing I started to play with. Can
you point the related documentation - if any - or at least the VM side
code processing the Qubes firewall rules please?

>> - even if Allow is the default policy I see a DROP rule at the
>> end. Why? :o
> To fail closed - if something goes wrong, there will be that DROP
> rule at the end anyway.

It should be decided by the user, by selecting default policy.
IMHO Qubes should not try to override the user decisions.

>> - the default login screen is just ugly. I know that this is not
>> the first priority, and not even a technical issue. But new users
>> will see that ugly thing first. So it's should be a Qubes skinned
>> one. at least.
> Hmm, I do see Qubes logo in the background there. Do you have
> something different?

Nope, I see the qubes backround. :)

But still feels like a bare naked login screen.
IMHO this should be just as important as the Qubes boot (splash) screen.

- -- 
Version: GnuPG v2


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+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
For more options, visit https://groups.google.com/d/optout.

Reply via email to