26/11/13 18:26, intrigeri wrote:
> 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.
Ok.
>> 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?
Yes.
> 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.
Given the default timeout of 120 s, "a bit more" could be up to 120 s.
I'd consider that an at least equally bad experience -- many users would
probably assume that Tails "crashed" and turn the computer off.
> 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.
What about my approach + showing a notification if udev didn't settle
after the first 10 seconds, using two consecutive `udevadm settle`:s?
Furthermore, after the first `udevadm settle`, if MAC spoofing isn't
enabled, or if it is enabled *but* *it* *didn't* *fail*, then we can
ignore ignore the second `udevadm settle`, because we have the exact
conditions we were waiting for before we dare starting NetworkManager.
> 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.
Ok. I'd still appreciate a quick read of the above and a comment about
if you think my new solution is the way to go; if positive, I'll add
something to the blueprint so this isn't lost in case we need it.
Cheers!
