The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Анализ реализаций алгоритма остановки ОС в различных система..., opennews (??), 28-Янв-14, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


93. "Анализ реализаций алгоритма остановки ОС в различных система..."  +2 +/
Сообщение от anonymous (??), 28-Янв-14, 15:39 
> Наоборот :)
> systemd изначально разработан модульным и расширяемым, в отличие от скриптов, у разработчиков
> которых всегда есть отмазка "если пользователю надо, он перепишет". В результате
> мы имеем то, что имеем - при отклонении от стандартных use
> case приходится лезть в дебри скриптов, вместо того, чтобы добавить один-два
> простых юнита, как в systemd.

Понятие "простоты" юнита субъективно. Большинство пользователей не полезет ни в sysvinit, ни в systemd. При этом, shell я уже много лет знаю - это стандарт между всеми solaris/bsd/linux, как минимум, а systemd-unit - это linux-specific заморочка, появившаяся чуть ли не вчера. Как Вы думаете, что мне будет субъективно "проще"? Как и многим другим людям, которые пришли в эту область не 1-2 года назад.
Не надо, пожалуйста, вспоминать про саморазвитие, необходимое для профессионалов и т.д.
Саморазвитие - это дополнительно к системному администрированию освоить функциональное программирование на erlang/haskell, к примеру, а никак не очередное перебаламучиване системы инициализации.

> Нельзя отключить только journald и udev. Потому что кто-то должен обрабатывать обращения
> программ к системному логу (хотя бы в режиме заглушки) и события
> устройств.

Мне не нужны эти демоны в моей системе. Ни один, ни другой. К примеру, я использую devtmpfs+mknode, и логирование через syslog-ng сразу в сетевой сокет, а "фирменное барахло от поттеринга" в моей системе будет только бесполезно жрать память.
Впрочем, udev который вроде был вполне готов к спокойной эксплуатации на долгие предстоящие годы, они тоже поломали.

> Все остальное можно отключить.

Если бы все остальные достаточно спорные решения, вроде http-сервера в системе инициализации еще и отключить было бы нельзя, думаю, даже самые ярые сторонники нового велосипеда призадумались бы.

Правильно писал pavlinux в соседней теме - это не развитие, это стагнация. Те вещи, которые уже работали, давно, хорошо работали, заменяются новыми и неработающими.
А то, чего не было - так и нет до сих пор, уже десяток лет.

Ответить | Правка | К родителю #75 | Наверх | Cообщить модератору

99. "Анализ реализаций алгоритма остановки ОС в различных система..."  +/
Сообщение от ананим (?), 28-Янв-14, 16:07 
>При этом, shell я уже много лет знаю - это стандарт между всеми solaris/bsd/linux, как минимум, а systemd-unit - это linux-specific заморочка, появившаяся чуть ли не вчера.

Да дело даже не в этом. Для скриптов вполне можно использовать что-то типа этого — http://bashdb.sourceforge.net/ Для текстового файла (systemd-unit) такой возможности нет в принципе.
Даже в xml можно провести формальную валидацию, в txt — нет.
К тому же стиль systemd разделяет отладку на 2-а — текстовой файл и собственно сам демон (man sd_* — вместо звёздочки два раза «таб», если есть башкомплешн), а ковырятся с отладкой сторонних 100500 демонов — то ещё удовольствие. Например:
>NAME
>       sd_listen_fds, SD_LISTEN_FDS_START - Check for file descriptors passed by the system manager
>DESCRIPTION
>       sd_listen_fds() shall be called by a daemon to check for file descriptors passed by the init system as part of the socket-based activation logic.
>…
>RETURN VALUE
>       On failure, this call returns a negative errno-style error code. If $LISTEN_FDS/$LISTEN_PID was not set or was not correctly set for this daemon and hence no file descriptors were received, 0 is returned. Otherwise, the number of file descriptors passed is returned. The application may find them starting with file descriptor SD_LISTEN_FDS_START, i.e. file descriptor 3.

И выяснение кто из этих 2-х виноват уже не такая тривиальная задача, как со скриптами.

Ответить | Правка | Наверх | Cообщить модератору

160. "Анализ реализаций алгоритма остановки ОС в различных..."  +2 +/
Сообщение от arisu (ok), 28-Янв-14, 20:25 
системды-специфичное апи вообще нафиг не нужно.
Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру