At Fri, 28 Feb 2014 14:03:19 -0300, Claudio Freire wrote:
On Fri, Feb 28, 2014 at 10:51 AM, Takashi Iwai firstname.lastname@example.org wrote:
Yet another example: you boot (lid closed) with the connection to a TV while TV is powered off. Then no external monitor is detected, so the machine goes to suspend, because logind thinks you turned on the machine accidentally.
There must be some reasons why such an action (checking the lid state at start up and going to suspend immediately) wasn't implemented in the desktop environment. It's different from closing the lid while running.
Problem is, you can't ever know if something like that was accidental or not. You have to assume.
If a user regularly does that sort of thing, they have to consciously decide to disable the suspend-on-lid-switch thing, knowing they'll risk accidental boots inside backpacks when they do - but hey, if they're careful it's their choice.
The software (any software) can't really know the difference between accidental and purposeful bootup with any degree of certainty, so user input is the only way to go.
Hence, the only proposal that is needed assuming that .conf works as one would assume (I tried systemd's documentation and found little of use - for the amount of documentation it has, it's horribly structured to say the least), if it works like that, then yast needs an easy-to-use config option for users to switch. That's all.
But how would you start YaST if you can't boot properly at all? You can't choose no matter how it's easy-to-use. No boot, no dice.
I don't mind if the system boots up and reaches to the desktop environment properly, then it tries to react more smartly. Most of DEs have enough controls to adjust. It allows even different setups depending on the current user. But, when a lowlevel service like logind starts behaving too smart without knowing what's really doing (literally it cannot know, as you mentioned), it's a bigger problem.
That said, if the system was once installed properly, and if user already chose the action such a case, this is the matter of configuration. But, deciding a too smart policy secretly out of sudden as default by a version update is no good way.