В гитхаб прекрасно вставляются картинки. Генерировать их легко можно с помощью graphviz.

Ну ок, можно и так. Главное - сделать зависимости максимально простыми, исключить ситуацию, когда два демона зависят друг от друга и не могут запустится. Думаю, в этом случае инит должен кидать error и бить по пальцам.

заведите себе какой-нить тег на лоре. думаю найдутся желающие подписаться

Наверное ты прав.
NeueInit пойдёт? Ты тоже не теряйся — завтра я создам новую тему с выдержкой из фич, которые были озвучены в этой теме.

а нельзя ли сейчас предварительный список?

Можно. Вот без список без обработки:
1. паралельный запуск демонов
2. возможность указать в конфиге зависимости демона
3. возможность включать в конфиг логику действий с демоном при различных ситуациях (запуск, остановка, зомби). можно либо указать выпалнение штатного действия,
предоставляемого системой инициализации, либо выполнить свой произвольный алгоритм.
1. Зависимости. Сервисы зависят от работы других сервисов.
2. Делегирование запуска сервисов не root пользователю.
3. Параллельная загрузка, не зависящих друг от друга, сервисов.
4. Перезапуск сервиса после ошибки.
1. Запускать/рестартовать/посылать_сигналы процессам
2. Базово мониторить (запущен/незапущен) и перезапускать, если надо.
3. Контролировать процессы не только по пиду, а через cgroups, чтоб знать не только стартовый процесс apache, но и все порожденные. Уметь их добивать.
1. Запускать демонов при старте системы.
2. Перезапускать/выключать.
3. Назначать nice.
4. Автоматически перезапускать зомби/упавшие с записью в логи.
5. Параллельный запуск.
6. Последовательный запуск с заданной очередностью всякой фигни со сложными зависимостями. Потому что система зависимостей сложная и не нужна.
7. Запускать/выключать демонов в зависимости от текущего runlevel.
1. Запускать демоны. Ваш К.О.;
2. Уметь в ранлевелы (хотя таргеты из systemd лучше);
3. Уметь в Cgroups
4. Забирать себе процессы, родители которых умерли;
5. Уметь в зависимости демонов;
6. Уметь в параллельный запуск;
7. Выключать и усыплять комп.

Как видишь тут в общем 7-8 пунктов.
Завтра я создам новый тред, где они будут выделены и окультурены.

мне раньше пришел на ум такие варианты: lor-inited, inilored, tusd (true unix system daemon)

мне вообще нравится общие идеи системд, но не конкретная реализация.

мои хотелки/советы такие:

• С и никаких других яп, максимально просто максимально надежно;
• только текстовые конфиги и никаких минимальных sh;
• (как в системд)не должно быть внешних вызовов програм аля grep/cat/итд
• (если возможно)поддержка плагинов для разширения функциональности;
• работа в паре с другими либц, не только с глибц;
• события, ранлевелы, таргеты, зависимости;
• никаких сетей, логов, qrcode’ов итп;
• опциональний перезапуск упавших демонов;
• (как в системд)не стартовать сервис пока в нем нет нужды, напр: пока никто не обращается в мускл, не стартовать его, даже если он есть в левеле;
• асинхронность везде где возможно

я админ локалхоста, тебе много не насоветую.

если еще хочеш фишек возьми да посмотри тот известный док по сравнению инит систем, и возьми то что считаешь нужным.

возьми да скастуй leave. он говорил что админит 1.2к серверов. кто как не он должен знать regular use cases и делится опытом

Назначать nice.

Назначать лимит и для IO и для CPU

7. Выключать и усыплять комп.

за это (хотя первое под вопросом) точно должен отвечать инит?

интересно а для памяти можно/имеет смысл?

должен отвечать инит?

Я не буду пока ничего исключать самостоятельно.
Список должен быть утверждён коллективно.
Поэтому я лишь уберу дубли.
Но лично я считаю, что ведение логов и вкл/выкл машины все полномочий инита.

«ведение» лога — да, но запись, и все что с этим связано наверно должен отвечать logger. здесь еще нужно вспомнить недавний срач между каем и линусом в лкмл по этому поводу

Эдакий гарбадж коллектор в масштабе системы?
Думаю это оправдано лишь для ембеддед всяких вещей, но там (за исключением мобилок) сидят грамотные админы, которым не понравится,что какая-то система лезет выгружать демон кушающий много памяти.

срач между каем и линусом в лкмл по этому поводу

Что там? Напомни.
Сиверс что ли?

я хз. просто добавил «до коллекции» ибо диск и проц уже были

да. даже здесь было

ninit = new init

Линус Торвальдс не будет принимать обновления ядра от Кая Зиверса

Новости systemd: Линус Торвальдс отказался принимать в ядро патчи от разработчика udev/systemd

Леннарт затрахал даже Торвальдса

все о одном т том же

Ага, кажется вспомнил. Но там же вроде проблема была в том, что разработчики просили вставить костыль в ядро чтобы упростить себе жизнь...

емнип реальная проблема была в том что «кто-то» «срал» в klogd заметно больше чем нужно/можно.

Вот sh и текстовый конфиг - главный конфликт.

Как прогресс?

Обычный функционал sysvinit: запуск системных служб, переключение уровней запуска, корректное отключение служб. Ну и, естественно, нормальные настройки + баш-скрипты.

А давайте переплюнем Поцтеринга по мегаидиотизму?

Сделаем систему инициализации на CUDA! И еще какой-нибудь добавим огороженности, чтобы не только systemd говном был!