Hi,
anonym wrote (26 Nov 2013 17:11:27 GMT) :
> Actually this relates to an interesting potential issue; do we want to
> potentially block the post-login script from finishing (and hence the
> GNOME desktop from starting, leaving an empty blue screen) for up to 120
> (or whatever) seconds? I suppose this could happen with some faulty
> hardware and/or crappy udev rules.
I suggest we just leave this aside until we are shown the problem can
actually arise in practice. Note that this very same UX is already
happening thanks to the implementation of the additional
software feature.
> Something that would make the exposure to this smaller would be to only
> replay network device-related triggers, and I've tried to add
> `--subsystem-match=net` to the `udevadm trigger` call in
> tails-unblock-network, but that only added my wired NIC, not my wireless
> NIC. To get the latter to load (I got hints by looking at `udevadm
> monitor`) I needed to add the following too
> --subsystem-match=module --subsystem-match=queues \
> --subsystem-match=drivers
> While adding those too wouldn't be a problem, I just don't feel
> confident this will be enough for all network devices imaginable.
Agreed, this isn't confidence inspiring.
> Another way to completely avoid this type of blocking would be to:
> 1. (re)start network-manager in tails-unblock-network, not in TG's
> post-login script like now, and
> 2. start tails-unblock-network in the background in TG's post-login
> script (now it starts "blocking").
> That looks better to me, and starting NM in there instead actually makes
> sense.
I'll trust you on where the code should be, but I'm unsure about the
timing and UX: in the situation you're trying to adress here, doing it
this way would indeed log the user in sooner, but they would be left
in a desktop session with non-working networking for a while, right?
I'm clearly no HCI expert, but as a user, I prefer waiting a bit more,
and then being logged into a working session. Having to wait for the
time sync' etc. is already confusing enough.
So, *if* we really want to preemptively address this potential
problem, I think I'm slightly in favour of having the user wait before
being logged in, and ideally being explained that they might have to
wait a bit, and if it's too long, they should report a bug.
But again, I personally don't think we should worry about this right
now. I bet we'll have enough very real problems to take care of after
the first release that has this branch in, let's save time and energy
for those ones.
Cheers!
--
intrigeri
| GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
| OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
