Проще для чайников --- хуже для остальных. Но обязательно ли?
При установке поверх старой системы, свежий установщик Ubuntu Server может рухнуть в процессе переразметки корневой файловой системы. Это очень-очень неприличное поведение, оно вынуждает поднимать из бэкапа всё содержимое соседних разделов диска, и вместо получасовой рутины в итоге испорчен целый выходной.
Неужели это у Каноникалов кончились грамотные линуксоиды, и они начали творить такую дичь? Нет, это от тех же грамотных линуксоидов начали требовать то, что было бы под силу только гениальным --- одновременно и "сделать красиво" для чайников, и постараться обеспечить совместимость с растущим год от года зоопарком старых вариантов разметок дисков, драйверов, операционных систем, гипервизоров и т.д. и т.п. Естественно, начало "рваться". Вряд ли кто-то слишком тщательно тестировал сценарий "обновление системы, которая когда-то была тупо перемещена байт в байт с 250Gb жёсткого диска в начало 500Gb SDD" --- слишком уж много таких сценариев. Неподъёмно много. Не развалили находившийся на соседних устройствах RAID --- и на том спасибо. Не попытались запороть всё совсем уж молча, сразу увидели свою ошибку и сразы вылетели с логами и т.д. --- тоже молодцы.
Где выход? На ум приходит опыт старинных САПР-ов, в которых прикладная программа вместо прямого манипулирования объектами чертежа могла писать команды в командную строку САПР-а вместо человека, так что человек при желании видел, какие команды дают какие результаты, мог читать пояснения программы, проговаривавшей, что и зачем она сейчас сделает, мог скопипастить какие-то куски себе на будущее. То есть помимо основной работы, рисования чертежа, хорошо написанная программа выступала учебником по самой себе: смотри, как именно я черчу, смотри, какие дополнительные средства я для этого добавила в САПР, смотри, откуда и какие я беру данные для этого, где их можно расширить/подправить. И даже если конечный результат не устраивал, у человека оставались эти знания и оставался черновик, который можно было подправить.
Раз уж нереально сделать надёжный "чёрный ящик" на все случаи жизни, может пора учиться делать "ящик с регулируемой прозрачностью"? Например, в начале работы "слишком длинной" и "слишком умной" процедуры задавать вопрос, что пользователь сам про себя думает.
--- Он надеется на лучшее и хочет просто самый быстрый путь по умолчанию?
--- Он хочет перепроверять "в общих чертах" параметры того, что будет сделано, а потом смотреть, что происходит?
--- Он хочет отслеживать весь процесс шаг за шагом, просматривая параметры каждой операции перед её выполнением, на манер пошаговой отладки?
Это ведь даже не приведёт к заметному удорожанию разработки, потому что последний режим будет полезен самим разработчикам.