История изменений
Исправление robus, (текущая версия) :
Да пусть срач всполыхнёт с новой силой!
Чего сраться, нужно писать принципиально новый инит.
Во-первых — его главный процесс (который имеет PID 1) должен иметь минимум библиотек с которыми он слинкован, код должен быть максимально простым (возможно даже примитивным) — чтобы не упал. Задача этого процесса — назапускать процессов, делающих всю настоящую работу (парсинг конфигов, запуск демонов и т.д.), и при падении worker-ов перезапускать их.
Во-вторых — демоны могут быть описаны как простые скрипты запуска и остановки (раздельно), начинающиеся со строки #!${path_to_shell}, всё остальное содержимое процесс-гвардиан этого демона скармливает проге ${path_to_shell} на стандартный ввод. Опционально демон может содержать файлы dependencies и environment в которых описаны соответственно все зависимости демона (по умолчанию зависимостей нет) и окружение демона. Это вместе с многопроцессностью инита позволит реализовать конкурентную загрузку.
В-третьих — наследование демонов. Второй способ описания демонов — файл inherited, содержащий имя демона, на котором основан текущий. Тогда те файлы, которые есть в папке демона заменят соответствующие файлы демона родителя (для файла окружения применять слияние с приоритетом потомку).
В-четвёртых — тулза для миграции с устаревших инитов. Она позволит автоматизировать процесс перехода, и как следствие продавить новый инит всюду. Нечего сидеть на копролитах!
Имея такой инит можно реализовать:
- парсинг демонов на gpu — так как процессы-гвардианы демонов уже не являются главным процессом ОС, то можно их прилинковать к libopencl.so или libGL.so и реализовать парсинг с использованием ядер или вычислительных шейдеров. Если написать шел, выполняющий скрипты с использованием мощностей gpu, то всё совсем станет хорошо.
- Добавление аналогов «типов юнитов» из systemd — это просто демоны шаблоны, использующие переменные окружения (т.е. всякие ExecStart, ExecStop будут прописываться в environment потомка).
Насчёт смены раскладки и человечного скроллинга в tty — этим лучше пусть занимается отдельный проект. Принципиально новая замена tty (но это уже будет совсем другая история).
Исходная версия robus, :
Да пусть срач всполыхнёт с новой силой!
Чего сраться, нужно писать принципиально новый инит.
Во-первых — его главный процесс (который имеет PID 1) должен иметь минимум библиотек с которыми он слинкован, код должен быть максимально простым (возможно даже примитивным) — чтобы не упал. Задача этого процесса — назапускать процессов, делающих всю настоящую работу (парсинг конфигов, запуск демонов и т.д.), и при падении worker-ов перезапускать их.
Во-вторых — демоны могут быть описаны как простые скрипты запуска и остановки (раздельно), начинающиеся со строки #!${path_to_shell}, всё остальное содержимое процесс-гвардиан этого демона скармливает проге ${path_to_shell} на стандартный ввод. Опционально демон может содержать файлы dependencies и environment в которых описаны соответственно все зависимости демона (по умолчанию зависимостей нет) и окружение демона. Это вместе с многопроцессностью инита позволит реализовать конкурентную загрузку.
В-третьих — наследование демонов. Второй способ описания демонов — файл inherited, содержащий имя демона, на котором основан текущий. Тогда те файлы, которые есть в папке демона заменят соответствующие файлы демона родителя (для файла окружения применять слияние с приоритетом потомку).
В-четвёртых — тулза для миграции с устаревших тулкитов. Она позволит автоматизировать процесс перехода, и как следствие продавить новый инит всюду. Нечего сидеть на копролитах!
Имея такой инит можно реализовать:
- парсинг демонов на gpu — так как процессы-гвардианы демонов уже не являются главным процессом ОС, то можно их прилинковать к libopencl.so или libGL.so и реализовать парсинг с использованием ядер или вычислительных шейдеров. Если написать шел, выполняющий скрипты с использованием мощностей gpu, то всё совсем станет хорошо.
- Добавление аналогов «типов юнитов» из systemd — это просто демоны шаблоны, использующие переменные окружения (т.е. всякие ExecStart, ExecStop будут прописываться в environment потомка).
Насчёт смены раскладки и человечного скроллинга в tty — этим лучше пусть занимается отдельный проект. Принципиально новая замена tty (но это уже будет совсем другая история).