http://linux.slashdot.org/story/14/12/09/2059252/fedora-21-released

Alexey Vissarionov написал(а) к Serguei E. Leontiev в Jan 15 11:10:00 по местному времени:

Доброго времени суток, Serguei!
11 Jan 2015 20:58:26, ты -> мне:

AV>>>> Очень надеюсь, что мода на systemd в скором времени
AV>>>> пройдет.
SL>>> Не могу с тобой согласится. И разработчикам, и
SL>>> пользователям, удобнее единообразие.
AV>> Скрипты, которые понимают параметры start, stop, restart и
AV>> при необходимости status - куда единообразнее-то?
SL> Выдача status не документирована, к тому же она чаще всего
SL> является не слишком надёжным результатом pidof или ps.

Она при этом опциональна. Итого: start, stop и restart (который во многих скриптах сводится к `$0 stop && $0 start`).

SL>>> Так вот это лишнее знание нужно только в последних
SL>>> оставшихся резервациях SVR4 init.d.
AV>> Неужели ты всерьез думаешь, что при использовании systemd
AV>> оно не нужно? :-)
SL> Злые языки утверждают, что автор systemd брал за образец
SL> launchctl/launchd.

Те же языки утверждают, что он далек от администрирования.

SL>>>>> А вот S20random нужно делать всегда, что бы лохи,
SL>>>>> которые ему верят, не волновались попусту.
AV>>>> Чем тебе /dev/random не нравится?
SL>>> Хочешь верить - верь и не волнуйся попусту, я что против?
AV>> Ты когда в прошлый раз заглядывал в linux/drivers/char/random.c?
AV>> А содержимым linux/drivers/char/hw_random/ интересовался?
SL> Да регулярно. Есть у него, конечно, некоторые математические
SL> проблемы.

Это какие? И вообще, чем может быть плох алгоритм "взять случайные данные, перемешать их с существующим пулом посредством хеш-функции"?

Тебе не нравится, что там для этого используется SНA256? Не вопрос, можно прикрутить кошерный Skein.

SL> Кроме того мне известно, что программное обеспечение делается под
SL> наблюдением одного большого брата,

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

SL> почти всё железо изготавливается на заводах контролируемых другим
SL> большим братом,

Аналогично. Что они могут сделать, левый гипервизор в ПЗУ впердолить? Фигня вопрос: отлавливается старым дедовским способом - с помощью осциллографа и известной матери.

SL> а третий большой брат просто находится под боком.

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

SL> Т.к. у меня нет необходимости обрабатывать секретную информацию на
SL> компьютерах, то я и не вынужден сохранять веру в чудо - что один или
SL> все большие братья не смогут заглянуть мне через плечо.

Как говорил некий чукча в известном анекдоте, "мне не нужно бежать быстрее медведя - достаточно бежать быстрее геолога".

AV>>>> У него есть замечательная функция adddevicerandomness(), которая
AV>>>> позволяет домешивать туда данные из дополнительных источников -
AV>>>> например, аппаратного ГСЧ
SL>>> Ну вот ещё одна железка с ещё одним своим демоном и/или со
SL>>> своими дополнительными требованиями на порядок запуска
AV>> gremlin@warez:~ > rpm -q --filesbypkg usbhwrng
AV>> usbhwrng /etc/cron.d/usbhwrng
SL> А что rpm usbhwrng в cron.d сам записать не может? Команд было бы
SL> меньше.

Абисняю: пакет usbhwrng содержит всего один файл - /etc/cron.d/usbhwrng

AV>> И все - грамотно сделанному устройству больше ничего не нужно.
SL> Инсталлятор в rpm может быть сколь угодно хитрый.

Какой нахрен "инсталлятор"? Записал файл, внес информацию об установленном пакете в свою базу - и все.

SL> Мы же знаем, что потребители /dev/urandom, такие как sshd и др.,
SL> не читают его каждый раз. Поэтому в данном случае, ему требуется:
SL> 1. Исключить соревнование между моментом регистрации USB устройства
SL> и запуском потребителей (sshd и др.);

Оно исключено по определению: пока устройства нет - работаем как получится (вызовы функции adddevice_randomness() упоминаются в net/core/dev.c, kernel/time/posix-cpu-timers.c, drivers/firmware/dmiscan.c и еще множестве разных мест). Как только устройство появилось - ежеминутный запуск /bin/cat отрабатывает успешно и домешивает в пул энтропии 4 случайных байта (32 бита).

SL> 2. Обеспечить перезапуск потребителей (sshd и др.) после пробуждения
SL> из состояний сна S5/S4/S3.

Перезапуск - с какой целью? У того же sshd в результате suspend все соединения сами по себе отвалятся.

SL> На мой взгляд, init.d SVR5 не облегчает решение этих задач.

Уже потому, что такие задачи просто не возникают.

SL>>>>> делаем все командные файлы с именами P00AnyService
AV>> Забыл спросить: что будут обрабатывать эти файлы?
SL> Ну, если все демоны идеальны, то их же можно просто сразу параллельно
SL> запустить.

То есть, от идеи обработки событий отказываемся?

SL>>>>> У API, приход которого на замену SVR4 init.d давно
SL>>>>> уже перезрел, могло бы быть и такое устройство.
AV>>>> API уже есть, и устроено оно не так уж и криво - а вот
AV>>>> используют его...
SL>>> Мое личное мнение, управление демонами/сервисами,
SL>>> устройствами и порядком загрузки в GNU/Linux самое кривое,
SL>>> из всех имеющихся на начало 2010-х.
AV>> Самое кривое из виданного мной - это бздо...
SL> Я уважаю все религиозные воззрения, возможно, кто-то верит в
SL> идеальные демоны/сервисы, которым даже не требуется аналог rcorder.

Да - это тот самый идеал, к которому нужно стремиться.


--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin ПРИ gremlin ТЧК ru; +vii-cmiii-ccxxix-lxxix-xlii

... Васаби дайкона не слаще
--- /bin/vi