On Thu, Apr 14, 2016 at 3:37 AM, Carlos E. R. <robin.listas@telefonica.net> wrote:
On 2016-04-14 03:53, Chris Murphy wrote:
On Wed, Apr 13, 2016 at 6:07 PM, Carlos E. R. <> wrote:
...
If you don't believe me, try it, in a virtual environment with two Linuxes that you can afford to destroy.
Yes but that sequence involves multiple instances of sufficiently bad implementation that it's sabotage. Isn't it?
No. The "sabotage" is bypassing the fact that grub does not allow to choose another system to boot while recovering from hibernation, because the scenario I described is known.
I think it's very much approaching sabotage to give users an easy way to corrupt their systems. So if the installer sets up swap and boot parameters to support hibernation, and the desktop environment makes it easy to hibernate (either by default or with an easily discoverable option in the UI), and yet that same DE does not have either the ability to confirm the installed bootloader *will* resume correctly or overwrite the bootloader with one that will, then yes I'd call that sabotage. You're talking about data loss or corruption is the inevitable result. I have a very high burden for how GUI installers and desktop environments behave. I don't care about expert users. The expert users are happy to be left alone and hopefully not have things silently break on them. But regular users need more attention. Breaking their installations isn't fair. So maybe dual boot/multiboot is just too complicated for normal users and it's not possible right now to design something safe for them? And if so, that's fine, then the installer should deny dual boot installations with pre-existing Linux when using the default-automatic partitioning and installation path. Only allow it for custom installations. I mean, this whole idea we'd ever want to foist data damage onto new users because they should learn esoteric bootloader things is silly. That's not required to safely dual boot on Windows or OS X. So I suggest you either deny the user the ease of getting into trouble, or make it fail safe. -- Chris Murphy -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org