> Да, но никто не мешает взять для него готовые скрипты.Только зачастую оказывается что детали друг к другу не подходят. Скрипты - у всех разные. И не больно скрипт из альтлинукса например впихнешь в другой дистр. Они там свою библиотеку используют. На шеллскриптах. И без нее скрипты остальным вообще бесполезны, а технически-корректно притащить такую квази-либу это уже целая отдельная возня, которая сама по себе даже без всего остального перевесит написание юнита/джоба для сервиса.
У других отличия могут быть менее фатальны, но по факту - совместимости нет, код зачастую граблеопасный, не проверяет ошибки, перемешан с конфигурацией и мысли не допускает что бывают систмы отличные от ОС у автора. А потом оно еще не работает и ... даже лог с кодами возврата штатно обычно не пишется. Но, конечно же, я могу дописать логгер сам. А мне это надо?
Вот и получается: берешь корпус, а он отштампован под ИХ моторы. А как я буду свой мотор в этот корпус упаковывать - мои проблемы. Ну понятно что поорудовав инструментами и замотав изолентой можно кое-как получить нечто приемлимое, но в результате вместо отрезания детали - я пилю корпус под мотор. Очень удобно и результативно.
Оно хорошо когда готовые скрипты есть. А когда вы чужие скрипты в системе встречаете - это уйма грабель. В результате новые сервисы запиливать - утомительно. А если это энтерпрайз и мегасисоп писавший скрипты уволился - остальным чего вообще делать? Получается что хорошо оно только для тех кто возвел свой локалхост в культ и готов его долго окучивать. А если у меня например кучка серверов - приоритеты уже другие. И я думаю "а как бы на них поменьше времени тратить?". Скриптить каждый? Из пары дюжин? Там и тут? А мне это надо? Особенно если какой-нибудь поттер или кто там еще зарулит все типовые вещи и мне останется лишь с совсем кастомом разобраться.
> Задача системы инициализации:
Погодите, вы за меня лучше знаете какие у меня задачи? :)
> Для дестопа это 15 строк.
А кто вам сказал что я хочу писать 15 строк для абсолютно типовой задачи? К тому же окажется что оно не умеет и 10% того что в каком-нибудь системд, и придется постоянно что-то донапиливать, "по мере". В месте где вообще типовые задачи должны не требовать внимания.
> 2. Установка обработчика hotplug - 4 строки.
Предлагаю почитать скрипт старта udev в дебиане/убунте. И найти (потенциально системозависимые) пути ... где-то на третьей странице, в коде. Удобнее просто некуда. Особенно такой скрипт на другую систему переносить.
> 3. Настройка сети и железа - 20 строк (+ часть в hotplug
> - 5 строк shell, 70 строк на D).
А в нормальных десктопных дистрах - out of the box, работает сразу. А так то я себе и плохонький кернел написать могу, если очень надо. Не то что какой-то конфигуратор сети. Только это медленно, геморно и вообще - другие это сделают лучше меня. Все-равно я Торвальдса на зарулю :).
Ок, допустим я пришел с ноутом в кафешку. Покажите мне что вы сделаете для конекта к сети и сколько это действий потребует? Мне - выбрать точку из списка. Ну может еще пароль ввести, если он там есть. По сути 1 жест мышом + 1-2 клика. Допустим мы знаем только SSID (и пароль, если есть) - написаны у входа (или совпадают с названием заведения). Нет, там конечно нет ракетных наук, но в нормальном виде когда это удобно использовать - довольно много логики. А потом еще окажется что там где-нибудь хитрым параметром shellshock случается. И если в массовых решениях такие ляпы толпой вытопчут, сколько такого счастья будет в самопальном кастоме - очень отдельный вопрос.
> 4. Запуск демонов - 1 строка (еще два запускаются по событиям в hotplug).
Ну-ну, покажите мне запуск демона 1 строкой. Чтоб еще приоритет ему выставить, под нужным юзером пнуть и рестартануть если упал. А вот httpd. Он должен запуститься лишь после появления сети. Сколько там уже строк? Не говоря о том чтобы в чрут, а лучше контейнер отрезать, все дела. И да, сборку контейнера и т.п. хотелось бы видеть стандартной услугой системы.
А поттер даже допер до регистрации/дерегистрации вм/контейнеров. Это и локальному админу позволит нормально понимать что работает, и хороший задел под управляторы в большой инфраструктуре. Несомненно, если переть на принцип - можно и самому написать. Только время на это уйдет и не факт что получится лучше.
> 5. Запуск Xorg и начальных приложений (15 строк).
Там тоже все сильно зависит от. У типовых DE их дефолтные скрипты обычно гораздо разлапистее. И да, нормальную настройку например вон тех мультимедийных кнопок на клавиатуре или вон тех кнопок регулировки яркости на ноуте я тоже сам должен везде занапилить? Очень десктопный дистр - LFS :).
> ИМХО большинство проблем связанны с переусложнением решения реальных задач.
Мир стал сложнее. Вон беспроводная сеть. Там куча настроек на самом деле. И сертификаты, и пароли, и несколько алгоритмов на выбор, а за одним SSID может быть куча BSSID. А вон GPU. Со спеками на 900 страниц. А вон USB. Я прочитал только спеки на 1.1 и половину на 2.0. А 3.х даже пока не рискнул :). А вот хочется контейнеры запускать. И виртуалки. А их неплохо бы регистрировать. Чтобы понимать состояние и уметь его отдавать большому управлятору, например. Я что-то не хочу все это лично кодить - разделение труда штука разумная в больших задачах. А маленькой задачей нынче сложно назвать даже openwrt в 4-меговой флешке.
> При попытке сделать все-в-одном на shell мы видим десятки нетривиальных скриптов.
По поводу чего я и предочел бы видеть многое из как стандартные фичи системы инициализации + некие средства для дерга этого из скриптов и программ + некий RPC-интерфейс под большой управлятор, делающий все это сетевым. Если, конечно, это нужно. Это даже в openwrt понимают - у них свой интерес: подвинуть проприетарщиков с рынка группового администрирования точек доступа, где нынче царят проприетарные самопалы с закрытым софтом и черти-каким оборудованием с пробэкдореной фирмварой. Это что, так и оставить предлагается? Фигвам!
> решение). Ну и само собой - любое сложное потенциально больше глючит
> чем простое, да и сами баги сложнее для исправления.
В каком-то роде это так. Но знание скриптиков на одном локалхосте - это знание скриптиков на 1 локалхосте. Очень нишевое и неуниверсальное знание. А, например, умение прописывать сервисы запускаться как надо несколькими строками конфига в каком-нибудь systemd - весьма реюзабельно и пригодится и на десктопе и на вон той дюжине серваков и даже вон тому энтерпрайзу с тысячей машин.
> ИМХО не стоит объединять молоток с микроскопом. Для каждой задачи нужен свой
> инструмент - лучше изучить два-три простых инструмента, которые тебе нужны,
В вашем случае - вы предложили мне пойти и сделать микроскоп и молоток лично. Вместо того чтобы взять ящик с типовыми инструментами от поттера и просто забить гвоздь, если задача - забить гвоздь. Да, может быть ручка будет не идеально под мою руку. Но если я буду заниматься вытачиванием правильной ручки - это займет намного больше времени и когда это будет закончено, я пожалуй уже и не вспомню что за гвоздь. Окажется что его уже два дня назад кто-то другой вбил.
> LLVM - в теории все красиво, но на практике развитие сложнее,
> а эффективность ниже, чем специализированное решение.
Это так. Но с другой стороны - если посмотреть на АМДшные драйвера, от идеи писать целиком свой парсер си и си++ (чтобы OpenCL полноценно прожевать) все тоже что-то отлынивают. Потому что это довольно много работы, а потом это все еще и обезглючивать. На что хронически нет ресурсов - там по факту 1 человек все пилит (теперь наверное побольше будет, но 2-3 года назад этого никто не знал). В такой ситуации выбор делается по наименьшему из зол, а с учетом всей совокупности имеющихся реалий - большой вопрос насколько например неправы были амдшники. Из очевидных плюсов - они получили относительно протестированный фронэтнд, который в курсе сей и плюсов. Из отрицательных - он про VLIW ни в зуб ногой (как и остальные) и починить сложно, порог вхождения - зверский. Но основной приоритет как я понимаю GCN. В целом вполне себе некая балансировка на доступных ресурсах. Не идеал, но и не абсолютный фэйл.
> запускаться вместо init процесса отдельным пунктом в меню бутлоадера.
Ну вот наверное из каких-то таких соображений это в стартере и будет - писать совсем отдельное нечто, куда потом придется внести половину стартера и прочее - странно. А после отката снапшота и прочего систему нехило бы еще и запустить.
> Полностью согласен. Рассмотрим дальше: systemd заменяет собой ряд стандартных компонентов,
Для начала - не стандартных. На них нет никаких стандартов - каждый городил как умел и совместимостью не парился. Ярким представителем является тот же альт, где перцы для своего удобства сделали целую либу. Вот только такие "стандартные" скрипты не будут работать в других дистрах, т.к. там этой "либы" нет. А затея корректно перепереть всю зависимую либу на другой дистр - уже целый весьма отдельный головняк.
"Красиво было на бумаге, но забыли про овраги".
> или поздно программы начнут их задействовать. Само по себе это правильно.
> Но эти компоненты не унифицированы.
Я согласен что это некая проблема но не вижу никаких внятных рабочих групп которые бы этим занялись. Вон с DRM/KMS как вышло? Олдскульщики в всяких бздах уперлись рогом - их все устраивает, нефиг ничего менять. А разработчиков воротивших основной объем работ - устраивало далеко не все. И вообще, юзеры требовали современную графику. В результате в линухе сделали довольно крутой низкоуровневый бэкэнд, который более-менее соответствует тем реалиям которые сегодня можно вижеть в железе - от "бeзмoзглых" контроллеров дисплея (у которых нет GPU совсем) до безгoловых числодробилок без видеовыходов, на которых только считать можно. Мне вон тут амдшники дали мини-лекцию про render nodes, или как считать на их видеокарточках не запуская иксы вообще. Вот это я понимаю - правильный подход и полное взаимопонимание как надо делать ряд вещей. А между делом дрова стали поддерживать только эти интерфейсы и остальным волей-неволей пришлось строиться. А если б их тогда послушали - где бы сейчас был пингвин? Так что если нет рабочих групп - ну пусть хоть так. Не утыкаться же в развитии систем совсем?
> Я не могу поставить отдельный понравившийся мне компонент, а остальное взять от других проектов.
Я согласен что это некий минус, но думаю что все придет к тому что остальные постепенно реализуют совместимые интерфейсы (или хотя-бы заглушки под таковые). Да, некоторое время наверное будут вопли и прочее. С DRM/KMS я это уже видел. Но что-то все позатыкались и пошли пилить совместимые интерфейсы, а в линухе получился не самый плохой бэкэнд для графики и вычислений на GPU.
> Почему нет претензий к другим системам инициализации? Потому что они заменяют один конкретный компонент
Потому что они просто не смели ничего сильно менять. В результате тот же апстарт просто фэйл: половина рулится как джобы, а половина - инитом. Это в убунте. В дебиане еще печальнее. Ну и чего хорошего в полумерах? В два раза больше мусора в голову вгружать и постоянно думать как вон та программа запускается - апстартовскими методами или инитовскими. И фиг 1 командой список всех сервисов увидишь. Очень удобно, тудыть растудыть. Если у системд получится лучше - я только за. А остальные как обычно поворчат и впилят совместимые интерфейсы или заглушки, если фичи реализовывать лениво.
> и прекрасно взаимодействуют с остальными.
Да вот знаете, я не считаю прекрасным невозможность даже просто список сервисов в системе ОДНОЙ командой получить. В системе с апстартом смотреть надо минимум в два закоулка - инит и апстарт. Как видите, это вам, кто не пользовался чем-то отличным то инита казалось что все ок. А мне вот так не кажется, например.
> часто выделяются в отдельные проекты. Стратегия opensource основана на сотрудничестве
> и разделении труда - каждый сосредотачивается на своем компоненте и использует чужие.
И я совсем не против если Поттеринг и его шайка-лейка свалят на себя проблемы с фичастым инициализатором. Меня это более чем устраивает, чтобы проблемы были у них а не у меня.
> Поттеринг не признает этой основы - пытается подмять все под
> себя. Отсюда и весь негатив против него в сообществе.
Он по факту просто сделал как проще и логичнее. Чтобы удобно было тем кто системд пользуется а не кому-нибудь еще. Что логично. И если много софта будет закладываться на его фичи - ну чтож, придется остальным засунуть гордость туда где ей самое место и запилить совместимый набор интерфейсов или хотя-бы заглушек. Единственный кто всерьез что-то такое еще пытался - апстарт, но у них не особо получилось. В смысле, с точки зрения администрирования я не хочу выискивать списки сервисов в разных закоулках разными командами. Это хреново. У Поттеринга может получиться лучше, судя по тому сколько дистров на это перешло. И да, почему-то любителей инита не очень смущало что пользователи апстарта должны так костылять. Наверное будет честно, если любители таких подходов теперь сделают такую же гримассу в адрес инита и его поклонников. Поэтому результат голосования в дебиане "давайте не будем ничего менять" - очень честно. Теперь любители инита ощутят на своем окороке то чего годами ощущали любители иных систем инициализации. Хоть того же апстарта. Почему я должен считать это несправедливым - я не понимаю.
> Да но изучать нужно больше,
Но и реюзабельность здорово выше. Это пригодится и на вот этом нотике, и на вон том десктопе, и на вон той пачке серверов, а может и в каком энтерпрайзе, если меня туда зачем-то занесет.
> вдобавок еще один слой абстракции дальше отодвинет понимание того как это все работает
> на самом деле - использовать специализированные системы станет сложнее, так как
> просто перестанете их понимать.
Я лучше 1 раз пойму как и что у Поттеринга чем буду постоянно колупаться в каких-то огроменных чужих скриптах, писанных кем-то до меня, имхо.
И окучивать каждый хост с которым я имею дело на таком уровне - зело жирно. В современном мире мой элементарный взгляд на предметы вокруг говорит мне что я вижу в радиусе 10 метров вокруг себя не менее 11 агрегатов, которые классифицированы как "компьютер". Это я ремотные сервера даже не начинал считать - под определение "компьютер" в этом контексте попадают системы с ядром Linux, способные выполнять программы с posix API. Билдить на каждом агрегате свой LFS и окучивать там вообще все скрипты лично - как-то дофига ресурсов надо. А там еще кучка ремотных серверов. Компьютеры нынче *везде*.
> Как же он тогда раньше работало и продолжает работать?
Ну вот так. Раньше тянули адскую паутину проводов - каждой системе свое напряжение. Потом это всех задолбало, ибо в городах небо стало просто затянуто проводами, и в конце концов все устаканилось на нескольких наиболее практичных и популярных форматах, а все остальное так или иначе конвертируется на месте, если надо.
> у вас все не правильно работает, используйте наш vendor lock, ведь
> ваш flac не поддерживается (официально) в iphone/windows/etc.
Есть только одна заковывка - никаких ограничений и секретов у поттера нет. В отличие от DRMщиков, где свой софт поставить в принципе не дают, обвешав все подписями, сделав ключи декодирования секретными и прочее.
> Наворотить не пойми чего можно где угодно, не думаю что юниты будут исключением.
Юниты - это просто текстовые конфиги. Поэтому вбить туда три страницы навороченной кастомной логики будет не очень простым начинанием. Что имхо к лучшему - будут наворачивать программную логику только когда реально надо, а не для дежурной демонстрации джедайских скиллов.
> Это хорошо, если вы понимаете как это работает.
Пока на самом деле отнюдь не идеально. Потому что системы которыми я в основном пользуюсь (дебиан, подвиды убунтовых) на это пока не перешли. Поэтому в апстарте я пока получше разбираюсь. Но зато я уже успел порулить апстартом вволю и осознать ряд проблем. Например элементарная невозможность получить список сервисов на машине 1 командой. Фигово когда половина сервисов рулится апстартом а половина - инитом. А на большее каноникала не хватило за столько лет...
> Но боюсь количество костылей будет расти пропорционально от отдаления от сути того, что происходит на самом деле.
Это возможно. Но как я уже сказал - мне надоели многие другие костыли. И нужда напилить самые простые типовые задачи. И я склонен полагать что эти факторы - перевешивают.
