> А sysv init - это вообще один голый мотор, без нифига.Да, но никто не мешает взять для него готовые скрипты.
Задача системы инициализации:
1. Монтирование ФС (виртуальных и реальных), для реальных перед монтированием запуск fsck. Для дестопа это 15 строк.
2. Установка обработчика hotplug - 4 строки.
3. Настройка сети и железа - 20 строк (+ часть в hotplug - 5 строк shell, 70 строк на D).
4. Запуск демонов - 1 строка (еще два запускаются по событиям в hotplug).
5. Запуск Xorg и начальных приложений (15 строк).
ИМХО большинство проблем связанны с переусложнением решения реальных задач. При попытке сделать все-в-одном на shell мы видим десятки нетривиальных скриптов. Можно часть спрятать во внутренностях системы инициализации, но тогда работа системы становится менее понятной, что влечет либо сложные баги из-за непонимания нюансов, либо потерю времени (на изучение все-в-одном понадобится больше времени, чем на специализированное решение). Ну и само собой - любое сложное потенциально больше глючит чем простое, да и сами баги сложнее для исправления.
ИМХО не стоит объединять молоток с микроскопом. Для каждой задачи нужен свой инструмент - лучше изучить два-три простых инструмента, которые тебе нужны, чем мега девайс с тучей функций, который при попытке использования микроскопа может зарядить молотком по предметному стеклу или по пальцам. Насколько я могу понять, у вас уже был аналогичный опыт со сложными решениями типа LLVM - в теории все красиво, но на практике развитие сложнее, а эффективность ниже, чем специализированное решение.
> Да. И я полагаю что этим должен рулить какой-то низкоуровневый системный компонент.
> В идеале чуть ли не бутлоадер, чтобы откатиться можно было из
> любой позы, независимо от степени факапа. Ну накрайняк кернел, или хотя-бы
> стартер - сойдут. Чем выше уровень - тем больше вероятность что
> откат системы не получится и понадобится какой-то отдельный кастом. Как минимум
> некий ребут на запасную die-hard систему (recovery) и уже оттуда. Уже
> дольше и сложнее. Реалистично же - для бутлоадера все это слишком
> сложно, абсолютный минимум кто это технически может - ядро, но большой
> вопрос насколько правильно в него впихать такой кус логики и какое-то
> взаимодействие с юзером. Ну тогда следующим накрайняк системный стартер.
В ядро такое точно тянуть не нужно - ИМХО должно быть отдельное приложение никак не связанное с системой инициализации и другими системами и запускаться вместо init процесса отдельным пунктом в меню бутлоадера.
>> Система с init + несколько скриптов по-прежнему будет работать, без systemd?
> Если вы сформируете такую систему - то будет. А почему нет? Ну
> разве что если вы воткнете какой-то компонент который без systemd не
> работает - тогда да.
Полностью согласен. Рассмотрим дальше: systemd заменяет собой ряд стандартных компонентов, добавляет часть новых. Их нужно использовать (иначе зачем добавлять?) и рано или поздно программы начнут их задействовать. Само по себе это правильно. Но эти компоненты не унифицированы. Я не могу поставить отдельный понравившийся мне компонент, а остальное взять от других проектов. Почему нет претензий к другим системам инициализации? Потому что они заменяют один конкретный компонент и прекрасно взаимодействуют с остальными. Если заменяется несколько компонентов, то это как правило компоненты слабо связаны (могут работать друг без друга) и часто выделяются в отдельные проекты. Стратегия opensource основана на сотрудничестве и разделении труда - каждый сосредотачивается на своем компоненте и использует чужие. Поттеринг не признает этой основы - пытается подмять все под себя. Отсюда и весь негатив против него в сообществе.
> Я тоже гном не использую. Но например если убунта и дебиан поюзают
> системд - я смогу более-менее универсально ими обоими рулить и мне
> будет проще (дедупликация знаний + куча фич которые мне пригодятся).
Да но изучать нужно больше, вдобавок еще один слой абстракции дальше отодвинет понимание того как это все работает на самом деле - использовать специализированные системы станет сложнее, так как просто перестанете их понимать.
>> При подходе, продвигаемым systemd (Поттерингом), альтернативные решения не
>> пострадают и все будет также легко взаимозаменяемо?
> Это уже на усмотрение авторов софта, как обычно. Если некто заложится на
> фичи systemd и этот софт вам понадобится - ну ой, любителям
> альтернатив придется запилить фичи или хотя-бы заглушки и у себя. Грубо
> говоря, если ALL в целом решил что в сети будет 220
> вольт, вы можете использовать и мотор на иное напряжение, но как
> вы его будете адаптировать к 220 - уже ваши сложности и
> может потребоваться некая отдельная возня. Проще всего разумеется взять мотор на
> 220 вольт.
Как же он тогда раньше работало и продолжает работать? Тут ситуация больше похожа на продвижение мультимедиа форматов с DRM и прочих зонтиков - у вас все не правильно работает, используйте наш vendor lock, ведь ваш flac не поддерживается (официально) в iphone/windows/etc.
> А я вот как-то имел прецеденты когда мне надо было допиливать чужие
> скрипты. И на разбирательство с чужим кривущим и грабельным кодом ушло
> сильно больше времени чем мне бы хотелось.
Наворотить не пойми чего можно где угодно, не думаю что юниты будут исключением.
> ради разнообразия попробовал апстарт - и заметил что старт типового сервиса
> укладывается в пяток очевидных строк. И все типовые костыли спиханы на
> запускач. И это как-то сильно проще и удобнее. Ну и systemd
> как-то так же сделан.
Это хорошо, если вы понимаете как это работает. Но боюсь количество костылей будет расти пропорционально от отдаления от сути того, что происходит на самом деле.
