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 _______________________________________________ tails-dev mailing list [email protected] https://mailman.boum.org/listinfo/tails-dev
