> Перезапуск одного повисшего процесса не должен происходить перезапуском всей системы А вот это - зависит от. С чего это вы за всех решили что так - нельзя? Вон у фирмы Нокия, например, у продакшн версий смартов N9 и N9x0 - отвал критичного сервиса ведет к ребуту девайса (разработчики - могут сие отключить). Поэтому если пока телефон лежал в кармане, а что-то пошло не так, оно через минуту будет по крайней мере снова в состоянии принимать звонки и смс. И вы по крайней мере не останетесь в результате без критичной для многих функции "прием звонков" на полдня, сами того не ведая. Нокия называет это MCE - "mission control entity". Да, мобильные девайсы - часто делают похожими на автопилотные, т.к. 95% юзерей - [...] не обладают компетенцией рекавери из системных проблем. Это - почти автопилот. И по состоянию на сейчас - можно объем кода такой штуки скостить в разы, перепихнув многое на systemd.
> притом через ресет,
В системд настраивается что делать. Можно рестарт сервиса (и даже запуск добавочного юнита по поводу "сервис сдох"). Можно рестарт системы. Выбираемо какой именно ребут сделать. Можно совсем корректный, но более склонный к затыку при системных сбоях и проблемах софта (что плохо для автопилотных режимов). Можно форсированный, когда программы не могут заткнуть shutdown sequence, но могут и не сохранить данные. А можно и суперэкстренный - в духе alt-sysrq-b. Где ребут моментальный и обламываться особо нечему. Системы и требования бывают разные. ЧСХ, Поттеринг почему-то в курсе этого факта. В отличие от.
> Я сам - нет, мне это не нужно. Но если кто пришлет
> нормальный патч и поддержка будет опцией - почему нет?
Если вам свалится в ваш проект ассемблерная простыня на 100 килобайтов, в которой вы ни в зуб ногой - врядли вы ее станете сами саппортить, just in case. А половина програмеров решит что это тянет на совсем отдельный проект. Не всем же пхать в свои репы любой мусор, как апачевский могильник. Это засоряет код и/или репы.
> Зачем?
В менуэт оси все пишется на асме. Идея фикс у них такая.
> Это Поттеринг любит все заново написать.
ИЧСХ, он нередко умудряется написать лучше, чем то что было до этого. Кроме идеи есть реализация. Ваше while true - типа, "супервизор процесса". Как идея. Но - EPIC FAIL как реализация! Потому что там ни проверки живости процесса, ни лимитирования рестартов, ни таймаутов, ни проверок результатов. Это новое поле для новых грабель, а не решение административной проблемы. Ваш вел из ржавых водопроводных труб - плохо катит. У него слетает цепь. И тормоза на спуске отказывают.
> Речь не о том, что бы писать все самому. А о том
> что бы иметь много простых решений для каждой задачи.
Все хорошо в меру. Вот сисколы управления процессами например - то еще лоскутное одеяло. При том привилегированное и чувствительное к порядку вызова.
С административной точки зрения, иметь дело с 20 простых, но совсем разных утилит от разных людей - утомительно. А из-за природы явления - граблебагоопасно и требует от админа глубокого знания устройства системы и работы всех 20 утилит. Прописать 20 параметров в единообразном виде в 1 конфиг - проще. И меньше места для лажи. А фанаты sysv обычно просто кладут на половину подобных вещей. Не обрабатывая ошибки и сбои и делая много фривольных допущений. А когда все нагибается и даже по ssh зайти не получается - ну да, так ваши и должны работать, наверное. Потому что геморно наруливать вызов 20 разных утилит. Особенно с анализом всех мыслимых ошибок в этом процессе. Вот только мне не нравится как все это потом работает.
> И использовать их по необходимости (типа unix way). А не одно навороченное переусложненное.
Тут приводили пример к чему это приводит. Когда чтобы достать 10 файлов из бэкапа - надо распаковать половину архива на 100 гигов. Потому что tar юниксвейно запайпили в gz. И все бы ничего, только сделать seek на середину и распаковать 10 файлов стало нельзя. И даже оглавление посмотреть быстро - опаньки.
Мне в этом плане нравится подход Торвальдса: когда теория и практика сталкиваются - теория идет курить бамбук. Вот все эти ваши рассказы про вэйность и идут куда подальше в ряде ситуаций. В смысле, я не против юниксвея. При условии что так - лучше работает. Есть класс задач, где, действительно, так - лучше. Но - не серебряная пуля. Тем более что системд с точки зрения администрирования в этом плане не так уж плох. Вывод его утилит можно пайпить в другие, etc. Даже вывод journalctl можно загрепать, не парясь бинарностью лога. Хоть это и неэффективно по ресурсам, в индексированном журнале можно и менее безбашенно поиск делать, не читая вообще ВСЁ.
> А sms он пришлет? А пришлет только после третьей неудачно попытки рестарта?
Почему бы и нет? Предположительно, это может быть как-то так: настроить RestartLimit сервису, а в OnFailure сделать вызов one-shot юнита, отправляющего смс. И я бы в этом всем больше всего боялся, имхо, заскоков сотового модема и сотовой сети: сложные штуки с многометровой фирмварью и мегапротоколом. Багов там - выше крыши. И доставка смс - без особых гарантий. И проверять что смс дошла - сложно.
> tmpfs/devtmpfs - я так на андройде делаю для раннего дебага.
А я вот порой логгирую в kmsg. Работает всегда, не требует от меня никаких действий, смотрится обычным dmesg. А что там в ведроиде... я принципиально не работаю с этим крапом. Или борда поддерживается нормальным линем и более-менее майнлайновым ядром, или я ищу другую борду. Все эти мусорные ведра и вендорские SDK пусть горят в аду.
> В моем понимании стандартные блоки это драйвера/ФС/сервисы.
Не вижу чем системд всему этому мешает. Если очень хочется - его можно обрубить до чуть ли не гольного стартера сервисов. А для полноты ощущений неплохо бы обрубить ядру sysfs и procfs. И всякие там sysv ipc. Опциональная же хрень. Требуется не всем :)
> А инит система - связующее звено для этих блоков.
Ну то-есть вы уже тоже не считаете что инит - только запускалка, в стиле "fire and forget", каковой всегда был init и большинство его скриптов?
> не нyжен d-bus
Насколько я помню, там в configure таки есть --disable-dbus. Правда на мой вкус это очень спорная идея. Я за то чтобы в системе был нормальный IPC и это не было бы чем-то сильно опциональным. Оборвать это? Procfs в ядре себе оборвите, больше лулзов.
> udev все равно используй.
Ему довольно мало альтернатив. Ну то-есть можно нечто типа того что в openwrt, но, честное слово, грабель с оборудованием в openwrt много. А юсб какой-нибудь нынче есть даже в модуле с половину кредитной карты размером. А значит и полный букет проблем с горячим подключением оборудования. Время признать очевидные факты: подобная подсистема нужна на большинстве устройств. Потому что там есть как минимум usb. Ваши же аргументы, а? :)
>> насчет применения вашей же логики? :)
> О какой логике речь?
О вашей. Нужно не всем -> оборвать.
> Если решение удачное для определенных задач, то почему нет?
Ну я вот считаю что systemd - "решение удачное для определенных задач" - "почему нет"? :)
> Вот если бы fuse была обязательным элементом системы.
Понятие об обязательном - штука растяжимая. Идите вон отключите procfs в ядре. Делаем ставки - сколько софта отвалится :)
> я ее (fuse) использую для других (реально обоснованных) ситуаций.
Ну вот поэтому я не в настроении вопить что fuse - тормозное bloatware, и его надо срочно везде оборвать. Хоть я частично так и считаю :)
> Ну да, следующий шаг Поттеринга - DE/WM, напишет свой, единственно правильный,
Пусть попробует. Вдруг у него получится нечто годное, симпатичное мне? А роты гестаповцев чтобы заэнфорсить инсталл всеми вокруг у него нет. Да и серверам десктоп не требуется. В шапке это понимают.
> а все остальные предаст анафеме,
А он им что, запретит свои апи использовать, под страхом расстрела DMCA? :)
> это приложения написанные для его DE будут требовать systemd/PA/его DE.
А вот это уже дело программистов как писать программы. Да, вы знаете, если я не захочу сношаться с вопросом "а какие там сэмплрейты поддерживает та звуковуха, во сколько потоков и какая гадина заняла звуковуху эксклюзивно" - я таки поюзаю PA. А вы можете наздоровье бодаться с всем этим. Если какой-то анти-PA зилот будет готов накодить патч и майнтайнить по жизни - я может его и приму. Если зилот не будет вести себя как удод и будет это майнтайнить. Но это сугубо акт доброй воли и сугубо на мое усмотрение.
> Но не наоборот. Вам не кажется это несколько настораживающим?
Мне кажется что Поттеринг очень явно дал понять что он делает современную систему инициализации, что у него нет цели ублажать вообще всех, что он намерен пользоваться всеми фичами современной системы - Linux. Да, это накладывает некие лимиты на совместимость и пререквизиты. Но такие лимиты есть в софте везде. А иногда кто-то должен прийти и переопределить как можно делать те или иные вещи. Возможно привнеся новые апи, которые потом будут использовать многие. Возможно даже в разных системах. Чем Поттеринг такой особенный что ему так должно быть нельзя - я не понимаю. С чего бы он должен быть гражданином второго сорта? И эти апи не запрещается реализовывать другим.
Кстати если уж мы о API, библа sdbus от поцтера - как-то лучше чем другие варианты. С точки зрения програминга работы с d-bus на си.
> А зачем из держать если в них нет реальной необходимости?
Ну так не держите. И системд можете не держать. А завтра какой-нибудь умник procfs у себя в ядре отпилит. Мне что, учитывать все причуды всех чудаков на свете? А учитывалка не сломается? Максимум на что такие могут уповать - корректный ФАТАЛЬНЫЙ завал программы с более-менее внятным текстом ошибки.
> если ты ей не пользуешься?
Незачем. Но судя по KVM в ядре - идея запускать виртуалки народу пришлась вполне по вкусу. И мысль оборвать из ядра KVM и прочие namespaces - многие, мягко говоря не поймут. И да, я считаю что системный менеджер должен уметь всем этим рулить. Ну там отпиливать процессы по контейнерам, стартовать виртуалки по тем же критериям как и просто сервисы, etc.
> Без udev/d-bus система работает бысрее
Хорошая опечатка. А так, знаете, udev и d-bus как-то совсем не светятся в top как такие из себя resource hogs. Даже на довольно старой и довольно медленной армовской платке.
> (7-8) лет за 9 секунд грузится и жрет около 20mb.
Правда радость от этого быстро улетучится после запуска обычного браузера. Который один скушает на порядок больше. И вы таки или добьете RAM, или будете слушать хрустение свопом, или будете обуты на современный веб, со всеми вытекающими следствиями.
> Лучше память под кэш отдать, чем под тупо болтающиеся демоны.
Это вон те пару мегов под udev? Имеет смысл только в совсем микроэмбедовке с openwrt. В случае же ноута - любой браузер мигом съест на 2 порядка больше и попросит добавки, аннулировав результат этих потуг. А в типовом дистре будет результативнее вышибить значок на питоне из трэя - сразу +30М RSS, без очевидных потерь, одним выстрелом. В общем какое-то очень нишевое развлечение. Не думаю что Поттеринг обязан учитывать всех извращенцев на планете, занимающихся чем-то странным. С такими приоритетами в пору на openwrt в качестве дистра переходить. Там еще и coreutils заменят на busybox. Если уж RAM превыше всего, тогда ps и top - урезанные сойдут, наверное. И шелл попроще - busybox со ВСЕМИ утилитами весит меньше одного только bash-а.
> Уже что-то было про logind или что там гном тянет.
Если вы давитесь жабой за 2 мегабайта - гном по любому не ваше DE. Они давно не ориентируются на то чтобы втиснуться в 20М RAM.
> То, что их можно отключить != что их можно запустить отдельно без systemd.
Можно. Если вывесить эквивалентное апи. А то что его придется написать - так никто не обещал что будет легко.
