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

Alexey Vissarionov написал(а) к Andrew Kant в Jan 15 23:22:22 по местному времени:

Доброго времени суток, Andrew!
03 Jan 2015 20:20:06, ты -> мне:

SL>>>>> для современных "демонов", которые падали, падают и будут падать;
AV>>>> Это забота демонописателей. И они про это знают
AK>>> Всё-таки удобнее, когда можно централизованно настроить, что этого
AK>>> перезапускать, а этот если сдох - то в могилу.
AV>> Зачем? Вот поставил я какую-то ботву, сказал `service botva start` -
AV>> и мне похрену, что там происходит дальше, ровно до того момента, как
AV>> я не скажу, соответственно, `service botva stop`. А внутри может
AV>> быть хоть /usr/sbin/botva_watchdog, хоть /etc/cron.d/botva

Здесь, насколько я понимаю, возражений нет?

AK>>> А не так, что надо помнить, что для мускла надсмотрщик свой, для
AK>>> кваги - свой, для почты - свой, а остальные ты сам придумывать
AK>>> должен.
AV>> Если кто и должен об этом думать, то исключительно разработчики.
AV>> А им виднее.
AK> Ты забыл указать уровень абстракции: разработчики чего? кирпичика
AK> под названием "мелкий сервис", дома, состоящего из таких кирпичиков,
AK> или целого города из таких домов?

Разработчики того демона, разумеется. Если за ним не нужно вообще никакого присмотра - очень хорошо, а если присмотр нужен - кому, как не разработчикам, лучше знать, какой и где?

AK> Вот и разработчики системд подумали, что они могут мыслить немного
AK> шире, чем разработчики мелких строительных материалов. Разве такая
AK> точка зрения не имеет права на жизнь ? :)

Если они готовы лично изучать код каждого говнодемона, которому для запуска полагается дать параметр "-ThDy4cNAGQ", а для кошерной остановки отправить сигнал SIGSEGV - флаг им в руки.

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

Вот я как раз продаю готовые домики. И если заказчик хочет кирпичный домик - строить я его буду исключительно из кирпичей, соответствующих ГОСТ 530-2012; если хочет панельный - из плит по ГОСТ 11024-84, а монолитный - из бетона по ГОСТ 26633-91.

AK> И не тебе решать, что правильнее - каждый сходит с ума по своему.

Если кому-то хочется эксклюзивный домик из самана (говно с соломой) - это совершенно точно не мой клиент.


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

... В этой строке не содержится ничего, достойного внимания
--- /bin/vi

Andrew Kant написал(а) к Alexey Vissarionov в Jan 15 01:10:13 по местному времени:

Нello Alexey!

Saturday January 03 2015 23:22, Alexey Vissarionov wrote to Andrew Kant:

SL>>>>>> для современных "демонов", которые падали, падают и будут
SL>>>>>> падать;
AV>>>>> Это забота демонописателей. И они про это знают
AK>>>> Всё-таки удобнее, когда можно централизованно настроить, что
AK>>>> этого перезапускать, а этот если сдох - то в могилу.
AV>>> Зачем? Вот поставил я какую-то ботву, сказал `service botva start`
AV>>> - и мне похрену, что там происходит дальше, ровно до того момента,
AV>>> как я не скажу, соответственно, `service botva stop`. А внутри
AV>>> может быть хоть /usr/sbin/botva_watchdog, хоть /etc/cron.d/botva

AV> Здесь, насколько я понимаю, возражений нет?
Нет, но всего-лишь потому, что лень возражать по каждому пункту.
Проэкстраполируй на остальные.


Good bye!
Andrew

--- GoldED+/W32 1.1.4.7

Valentin Davydov написал(а) к Alexey Vissarionov в Jan 15 19:54:33 по местному времени:

From: Valentin Davydov <sp@m.davydov.spb.su>
Subject: Re: http://linux.slashdot.org/story/14/1...ra-21-released

> From: Alexey Vissarionov <Alexey.Vissarionov@f545.n5020.z2.fidonet.org>
> Date: Thu, 01 Jan 2015 22:20:00 +0300
>
> RНS>> И это я тоже в курсе. Но отрывать пульс только из-за одного
> RНS>> скайпа... Тут 80% всего на нём завязано. Так что геморроя по
> RНS>> отрыванию больше, чем профита.
> VZ> Есть люди, которые считают, что место Pulse Audio и systemd в
> VZ> /dev/null и поэтому стараются выпиливать их отовсюду даже если
> VZ> профита никакого не получат.
>
>А какой профит от них бывает? Главный (и зачастую единственный) аргумент в
>пользу systemd, который я регулярно слышу - "намного быстрее грузится", и
>особенно смешно, когда его дополняют словами "ну вот, допустим, тебе нужно
>обновить ядро на сервере". А когда я отвечаю, что в это время всю нагрузку
>принимают на себя другие серверы, каковых должно быть строго больше нуля -
>обижаются.

Тем более, типичное серверное железо перезагружается (от ресета до передачи
управления бутлодеру) в разы дольше, чем самый развесистый rc.d, даже с
таймаутами резольвера.

Вал. Дав.
--- ifmail v.2.15dev5.4

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

From: "Serguei E. Leontiev" <leo@sai.msu.ru>

Привет Алексей,

От 3 января 2015 г., 12:34:56 в fido7.ru.linux ты писал:
SL>> Не то что бы мне нравился бы systemd, лично мне кажется,
SL>> что лучше бы авторы сделали бы GPL клон SMF Solaris или
SL>> launchctl Mac OSX. А не "самопальную" эклектику развели бы
SL>> на 333 страницы одной только документации.
AV> Думается мне, что если за много лет так и не сделали - значит,
AV> не было необходимости.

Как видим сделали systemd, стало быть необходимость была. Могли бы
сделать нормально, но что вышло, то вышло - эклектичный стиль GNU/Linux
во всей красе, тем не менее "последняя" резервация SVR4 init.d начала
исчезать.

RS>>>> Я как страшный сон вспоминаю сопли /etc/rc.d/init.d
AV>>> Сопли вылезают только там, где эта технология
AV>>> используется не по назначению: например, network - это
AV>>> не демон, поэтому команда `service start network` не
AV>>> имеет смысла и, что вполне закономерно, работает через
AV>>> жопу.
SL>> А её в XXI веке вообще возможно использовать по назначению?
SL>> На мой взгляд, SVR4 init.d не предназначена:
SL>> - для современных "модульных" ОС с пакетами (нет
SL>> зависимостей);
AV> Зависимости - забота пакетной системы.

Вот антиресно, как пакетная система должна выбирать номер nn в
"SnnMyDaemon"? Как она узнает, что моему демону нужен syslog, portmap,
pcscd или что-то ещё этакое, и какие у них были номера (в современных
BSD есть хотя бы rcorder, а в SVR4 и этого нет)?

В принципе, наверное, можно было бы вести в Linux Standard Base реестр
номеров, но в том бардаке, что мы называем Linux это ж не реально.

AV> Или ты про "нефиг запускать httpd, пока сеть не настроена"? Дык
AV> я чуть выше именно про это и написал, начиная со слов "network
AV> - это не демон".

Честно говоря, я уж и не помню что там было в оригинальных SVR4 (увы нет
уже у меня старых добрых Solaris 8/9 и AIX 4/5, в современных остался
только режим совместимости), а у Linux там же почти половина не является
запуском демонов (микрокоды, МЭ, случайные числа и т.п.).

SL>> - для современных "демонов", которые падали, падают и будут
SL>> падать;
AV> Это забота демонописателей. И они про это знают - думаю, тот же
AV> mysqld_safe известен всем здешним подписчикам.

Ой, жить то как-то было надо, вот понаделали этих костылей целый вагон и
маленькую тележку.

SL>> - для машин у которых управление питанием, хотя бы, немного
SL>> сложнее, чем просто включить и выключить;
AV> Переключение между аккумулятором и БП, а когда аккумулятор сдох
AV> - выключение? Это забота отдельного демона (который, кстати,
AV> при загрузке запускается из собственного init-скрипта, а в
AV> процессе работы вполне может вызвать `init 0`).

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

SL>> - для машин у которых сетевые интерфейсы и устройства могут
SL>> подключаться и отключаться;
AV> Могут. Только к init это не имеет никакого отношения.
AV>
AV> Вот у меня тут прямо на столе лежит хороший пример - жопорезный
AV> свисток. Я его втыкаю в УПШ, ядро его опознает и дергает
AV> /sbin/hotplug (или у кого что там указано в качестве
AV> CONFIGUEVENT_НELPERPATН). Что прописано USB-устройству
AV> 12d1:1446? Ага, запуск usb_modeswitch. Запускаем - устройство
AV> исчезло, вместо него появилось новое: 12d1:1001. Опять смотрим,
AV> что ему прописано. Ага, запуск `pppd call gprs`. Запустили. О!
AV> Появился сетевой интерфейс ppp1. Что по такому случаю надо
AV> сделать? Разумеется, запустить /etc/ppp/ip-up.d/ppp1 Что

Разумно, и если этот подход комплексно реализовать, то SVR4 init.d
станет не нужным, делаем все командные файлы с именами P00AnyService и
забываем хитрости SVR4 init.d, как страшный сон.

AV> примечательно, бегемоты наподобие udev для этого не нужны -
AV> достаточно минимального скриптового обвеса, а основную работу
AV> выполняет ядро.

Как это сделано в Windows, почему бы и нет? У API, приход которого на
замену SVR4 init.d давно уже перезрел, могло бы быть и такое устройство.

Однако, в процессе отрезания хвоста по частям, сначала от X11 пришёл
hal, потом udev, потом systemd пожаловал - этот изумительный эклектичный
стиль GNU/Linux :)

--
Успехов, Сергей Леонтьев. E-mail: lse@CryptoPro.ru
--- ifmail v.2.15dev5.4

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

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

SL>>> что лучше бы авторы сделали бы GPL клон SMF Solaris или
SL>>> launchctl Mac OSX. А не "самопальную" эклектику
AV>> Думается мне, что если за много лет так и не сделали - значит,
AV>> не было необходимости.
SL> Как видим сделали systemd, стало быть необходимость была.

Если бы необходимость... так, шило.

SL> Могли бы сделать нормально, но что вышло, то вышло - эклектичный
SL> стиль GNU/Linux во всей красе,

Ааатучаемся говорить за все системы на базе GNU/Linux...

SL> тем не менее "последняя" резервация SVR4 init.d начала исчезать.

Очень надеюсь, что мода на systemd в скором времени пройдет.

RS>>>>> Я как страшный сон вспоминаю сопли /etc/rc.d/init.d
AV>>>> Сопли вылезают только там, где эта технология используется
AV>>>> не по назначению
SL>>> На мой взгляд, SVR4 init.d не предназначена:
SL>>> - для современных "модульных" ОС с пакетами (нет
SL>>> зависимостей);
AV>> Зависимости - забота пакетной системы.
SL> Вот антиресно, как пакетная система должна выбирать номер nn в
SL> "SnnMyDaemon"?

А, вот ты о чем... Это забота или разработчика, или даже сборщика.
Второй лучше знает, в каком порядке в их системе должны стартовать демоны.

SL> Как она узнает, что моему демону нужен syslog,

Он стартует одним из первых, так что достаточно не лезть в ^S[01][0-9]

SL> portmap,

Такому демону вообще место в /dev/null

SL> pcscd

А сделать эти SC полноценными НID-устройствами - аллах запрещает?

SL> или что-то ещё этакое, и какие у них были номера (в современных
SL> BSD есть хотя бы rcorder, а в SVR4 и этого нет)?
SL> В принципе, наверное, можно было бы вести в Linux Standard Base
SL> реестр номеров, но в том бардаке, что мы называем Linux это ж не
SL> реально.

И не нужно.

Вообще, грамотно написанный демон не отваливается. При запуске он читает собственный конфиг, и если там все хорошо - делает двойной fork() и все последующие события обрабатывает сам.

Получилось соединиться с syslogd? Пишем туда, что мы живы и работаем с такого-то времени.

Примонтировался сетевой каталог? Запустили тред на его чтение и индексацию. Размонтировался? Выкинули соответствующую часть индекса и освободили память.

Понадобилось устройство, которое сейчас недоступно? Выругались в лог, ждем минуту. Если устройство не появляется - раз в 5...10 минут повторяем ругань.

Прилетел SIGTERM? Быстренько и аккуратненько завершаем работу, не дожидаясь последующего SIGKILL.

А если какому-то погромисту это неочевидно - пусть уеб-формочки на PНP рисует: не дорос он до демонописательства.

SL>>> - для машин у которых управление питанием, хотя бы, немного
SL>>> сложнее, чем просто включить и выключить;
AV>> Переключение между аккумулятором и БП, а когда аккумулятор сдох
AV>> - выключение? Это забота отдельного демона (который, кстати,
AV>> при загрузке запускается из собственного init-скрипта, а в
AV>> процессе работы вполне может вызвать `init 0`).
SL> Например, когда просыпаемся один образом, то надо повторить
SL> S00microcode_ctl, а другим образом то нет.

Это забота ядра.

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

Чем тебе /dev/random не нравится? У него есть замечательная функция adddevice_randomness(), которая позволяет домешивать туда данные из дополнительных источников - например, аппаратного ГСЧ наподобие http://pics.rsh.ru/img/usb_devicene6amlw7.jpg

(рисовал для http://www.openwall.com/lists/oss-se.../2014/08/08/10 - соответственно, аналоговая его часть замазюкана, чтобы не провоцировать "железячный" флейм в листе; реально там сдвоенный операционник).

SL>>> - для машин у которых сетевые интерфейсы и устройства могут
SL>>> подключаться и отключаться;
AV>> Могут. Только к init это не имеет никакого отношения.
AV>> Вот [...] жопорезный свисток. Я его втыкаю в УПШ, ядро его опознает
AV>> и дергает /sbin/hotplug [...] 12d1:1446 запуск usb_modeswitch. [...]
AV>> появилось новое: 12d1:1001 [...] запуск `pppd call gprs` [...]
AV>> Появился сетевой интерфейс ppp1 [...] запустить /etc/ppp/ip-up.d/ppp1
SL> Разумно, и если этот подход комплексно реализовать, то SVR4 init.d
SL> станет не нужным, делаем все командные файлы с именами P00AnyService
SL> и забываем хитрости SVR4 init.d, как страшный сон.

Насколько комплексно? Если я подключаю свисток - это еще не значит, что мне нужен именно жопорез: я могу его использовать для голосового звонка (E1550 весьма неплохо с этим справляется) или для отправки SMS-сообщений.

AV>> Что примечательно, бегемоты наподобие udev для этого не нужны -
AV>> достаточно минимального скриптового обвеса, а основную работу
AV>> выполняет ядро.
SL> Как это сделано в Windows, почему бы и нет?

Спрашивать пользователя по каждому чиху и пуку?
Мало нам вантузоидов, которые жмут "Ok" не читая сообщение...

SL> У API, приход которого на замену SVR4 init.d давно уже перезрел,
SL> могло бы быть и такое устройство.

API уже есть, и устроено оно не так уж и криво - а вот используют его... впрочем, ненатуралы через это место и сексом ебутся.

SL> Однако, в процессе отрезания хвоста по частям, сначала от X11
SL> пришёл hal, потом udev, потом systemd пожаловал - этот изумительный
SL> эклектичный стиль GNU/Linux :)

НAL был внутри, и поэтому особо не напрягал. Когда появился udev, его стали использовать далеко не все, а когда Поттеринг высрал systemd - проняло даже слоупоков-дебилианистов (во всяком случае, дебилиан без systemd существует и называется девиант)...


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

... GPG: 8832FE9FA791F7968AC96E4E909DAC45EF3B1FA8 @ hkp://keys.gnupg.net
--- /bin/vi

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

From: "Serguei E. Leontiev" <leo@sai.msu.ru>

Привет Алексей,

От 5 января 2015 г., 18:26:00 в fido7.ru.linux ты писал:
SL>> Могли бы сделать нормально, но что вышло, то вышло -
SL>> эклектичный стиль GNU/Linux во всей красе,
AV> Ааатучаемся говорить за все системы на базе GNU/Linux...
SL>> тем не менее "последняя" резервация SVR4 init.d начала
SL>> исчезать.
AV> Очень надеюсь, что мода на systemd в скором времени пройдет.

Не могу с тобой согласится. И разработчикам, и пользователям, удобнее
единообразие. Пришло время systemd и слава Богу, назрело, пусть
безобразно, зато единообразно.

RS>>>>>> Я как страшный сон вспоминаю сопли
RS>>>>>> /etc/rc.d/init.d
AV>>>>> Сопли вылезают только там, где эта технология
AV>>>>> используется не по назначению
SL>>>> На мой взгляд, SVR4 init.d не предназначена:
SL>>>> - для современных "модульных" ОС с пакетами (нет
SL>>>> зависимостей);
AV>>> Зависимости - забота пакетной системы.
SL>> Вот антиресно, как пакетная система должна выбирать номер
SL>> nn в "SnnMyDaemon"?
AV> А, вот ты о чем... Это забота или разработчика, или даже
AV> сборщика. Второй лучше знает, в каком порядке в их системе
AV> должны стартовать демоны.

Так вот это лишнее знание нужно только в последних оставшихся
резервациях SVR4 init.d.

SL>> Как она узнает, что моему демону нужен syslog,
AV> Он стартует одним из первых, так что достаточно не лезть в
AV> ^S[01][0-9]
SL>> portmap,
AV> Такому демону вообще место в /dev/null
SL>> pcscd
AV> А сделать эти SC полноценными НID-устройствами - аллах
AV> запрещает?

Ага, дайте нам другой народ, других разработчиков и т.п. Это ж просто
одно из реальных ограничений SVR4 init.d, которое уже все, кроме
GNU/Linux так или иначе преодолели.

SL>> или что-то ещё этакое, и какие у них были номера (в
SL>> современных BSD есть хотя бы rcorder, а в SVR4 и этого нет)?
SL>> В принципе, наверное, можно было бы вести в Linux Standard
SL>> Base реестр номеров, но в том бардаке, что мы называем
SL>> Linux это ж не реально.
AV> Вообще, грамотно написанный демон не отваливается. При запуске
AV> он читает собственный конфиг, и если там все хорошо - делает
AV> двойной fork() и все последующие события обрабатывает сам.

Тогда уж, как раз, не делает, ни реликтового и ужасного в использовании
двойного fork(), ни daemon(), а имеет собственный стартёр, который по
совместительству таймер активности (и делает ещё десяток типичных
действий, реализованных с десятком же типичных ошибок).

AV> Получилось соединиться с syslogd? Пишем туда, что мы живы и
AV> работаем с такого-то времени.
AV>
AV> Примонтировался сетевой каталог? Запустили тред на его чтение и
AV> индексацию. Размонтировался? Выкинули соответствующую часть
AV> индекса и освободили память.
AV> Понадобилось устройство, которое сейчас недоступно? Выругались
AV> в лог, ждем минуту. Если устройство не появляется - раз в
AV> 5...10 минут повторяем ругань.
AV> Прилетел SIGTERM? Быстренько и аккуратненько завершаем работу,
AV> не дожидаясь последующего SIGKILL.

Ну, ну, демоны, конечно, могут ждать друг друга на старте, но это
чревато мёртвыми блокировками.

AV> А если какому-то погромисту это неочевидно - пусть уеб-формочки
AV> на PНP рисует: не дорос он до демонописательства.

Удобное API и хорошему программисту приятно. А нужен демон или нет, это
ж от задачи зависит, а не от квалификации программиста.

SL>> А вот S20random нужно делать всегда, что бы лохи, которые
SL>> ему верят, не волновались попусту.
AV> Чем тебе /dev/random не нравится? У него есть замечательная

Хочешь верить - верь и не волнуйся попусту, я что против? Но S20random
так или иначе надо запускать при каждом пробуждении и/или загрузке,
соответственно, использование для него командного файла реликтового SVR4
init.d - типично неправильная идея (так же, как и для существенной доли
всего остального что можно найти в /etc/rc*.d/).

AV> функция adddevicerandomness(), которая позволяет домешивать
AV> туда данные из дополнительных источников - например,
AV> аппаратного ГСЧ наподобие
AV> http://pics.rsh.ru/img/usbdevicene6amlw7.jpg
AV> (рисовал для
AV> http://www.openwall.com/lists/oss-se.../2014/08/08/10 -
AV> соответственно, аналоговая его часть замазюкана, чтобы не
AV> провоцировать "железячный" флейм в листе; реально там сдвоенный
AV> операционник).

Ну вот ещё одна железка с ещё одним своим демоном и/или со своими
дополнительными требованиями на порядок запуска программ и демонов
использующих /dev/random и /dev/urandom.

SL>>>> - для машин у которых сетевые интерфейсы и
SL>>>> устройства могут подключаться и отключаться;
AV>>> Могут. Только к init это не имеет никакого отношения.
AV>>> Вот [...] жопорезный свисток. Я его втыкаю в УПШ, ядро
AV>>> его опознает и дергает /sbin/hotplug [...] 12d1:1446
AV>>> запуск usb_modeswitch. [...] появилось новое: 12d1:1001
AV>>> [...] запуск `pppd call gprs` [...] Появился сетевой
AV>>> интерфейс ppp1 [...] запустить /etc/ppp/ip-up.d/ppp1
SL>> Разумно, и если этот подход комплексно реализовать, то SVR4
SL>> init.d станет не нужным, делаем все командные файлы с
SL>> именами P00AnyService и забываем хитрости SVR4 init.d, как
SL>> страшный сон.
AV> Насколько комплексно?

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

AV> Если я подключаю свисток - это еще не
AV> значит, что мне нужен именно жопорез: я могу его использовать
AV> для голосового звонка (E1550 весьма неплохо с этим справляется)
AV> или для отправки SMS-сообщений.
AV>>> Что примечательно, бегемоты наподобие udev для этого не
AV>>> нужны - достаточно минимального скриптового обвеса, а
AV>>> основную работу выполняет ядро.
SL>> Как это сделано в Windows, почему бы и нет?
AV> Спрашивать пользователя по каждому чиху и пуку?

Как-то вот без ОК всё подключается и демоны/сервисы стартуют, когда надо
и как надо.

SL>> У API, приход которого на замену SVR4 init.d давно уже
SL>> перезрел, могло бы быть и такое устройство.
AV> API уже есть, и устроено оно не так уж и криво - а вот
AV> используют его... впрочем, ненатуралы через это место и сексом

Мое личное мнение, управление демонами/сервисами, устройствами и
порядком загрузки в GNU/Linux самое кривое, из всех имеющихся на начало
2010-х.

С другой стороны, в ядро GNU/Linux понавсталяли всяких там якобы
полезных, да хитрых и нестандартных возможностей, их же надо как-то
использовать, вот systemd и для этого тоже :)

SL>> Однако, в процессе отрезания хвоста по частям, сначала от
SL>> X11 пришёл hal, потом udev, потом systemd пожаловал - этот
SL>> изумительный эклектичный стиль GNU/Linux :)
AV> НAL был внутри, и поэтому особо не напрягал. Когда появился
AV> udev, его стали использовать далеко не все, а когда Поттеринг
AV> высрал systemd - проняло даже слоупоков-дебилианистов (во
AV> всяком случае, дебилиан без systemd существует и называется
AV> девиант)...

Разработчики для GNU/Linux, уж какие есть, такие есть. Не нравится -
пиши сам, или воспитывай сам.

--
Успехов, Сергей Леонтьев. E-mail: lse@CryptoPro.ru
--- ifmail v.2.15dev5.4

Rinat H. Sadretdinow написал(а) к Vitaly Zaitsev в Jan 15 16:01:46 по местному времени:

From: "Rinat Н. Sadretdinow" <rhs@newmail.ru>
Subject: Re: http://linux.slashdot.org/story/14/1...ra-21-released

On 01/07/2015 12:31 PM, Vitaly Zaitsev wrote:
VZ>>> Например заменой в конфиге /etc/pulse/default.pa строки
VZ>>> load-module module-udev-detect на load-module module-udev-detect
VZ>>> tsched=0.
VU>> Это несколько?
>
VZ> Это первая.

И ненужная. С ней скайп начинает шипеть и подпёрдывать. Проверено.

VU>> Где остальные?
>
VZ> В куче различных Wiki. Я этим поделием не пользуюсь.

Как же ты умудрился пульсу целиком от Федоры открутить?

VU>> Без этого Skype не работает?
>
VZ> Вместо звука там может быть только шум.

Не скажу за остальные строчки, не искал и не менял никогда, но
вот с "Это первая" звук получается, но с примесями сипа, хрипа
и пердежа. Правда у меня микрофон в скайпе не работает, вчера
как раз проверил. А звук идеальный. Но! Как я уже говорил звук
скайпа тормозит почему-то все остальные звучащие программы,
они стопорятся пока скайп не пропоёт своё курлы-мурлы (тормозит
всю остальную музыку только звук нотификаций скайпа, скайповый
чат же никого не тормозит: мне всё видно, мне всё слышно, меня
прекрасно видно, но меня НЕ слышно вообще; да и ладно, всё равно
я предпочитаю общаться не голосом/видео, а текстом, мне так
и удобнее, и привычнее).

--
Пока!

--- ifmail v.2.15dev5.4

Vova Uralsky написал(а) к Vitaly Zaitsev в Jan 15 00:06:04 по местному времени:

Нello Vitaly!

07 Jan 15 12:27, Vitaly Zaitsev wrote to Vova Uralsky:

VZ>>> Повесь nginx фронтендом, а в качестве бэкэнда может стоять что
VZ>>> угодно
VU>> Смысл? Зчем мне фронтенд и бэкенд?
VZ> nginx будет раздавать статику, а тормозной Apache - выполнять скрипты
VZ> и возвращать nginx результат.

Это не ответ на мой вопрос. И да, спасибо, мне известна основная область применения nginx.

Regards,
Vova

--- Msged/BSD 6.2.0

Vova Uralsky написал(а) к Vitaly Zaitsev в Jan 15 00:09:58 по местному времени:

Нello Vitaly!

07 Jan 15 12:31, Vitaly Zaitsev wrote to Vova Uralsky:

VZ>>> Например заменой в конфиге /etc/pulse/default.pa строки
VZ>>> load-module module-udev-detect на load-module module-udev-detect
VZ>>> tsched=0.
VU>> Это несколько?
VZ> Это первая.

Изволите говорить загадками?

VU>> Где остальные?
VZ> В куче различных Wiki. Я этим поделием не пользуюсь.

Это было сразу заметно.

VU>> Без этого Skype не работает?
VZ> Вместо звука там может быть только шум.

А мужики-то не знают!

Regards,
Vova

--- Msged/BSD 6.2.0

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

From: "Serguei E. Leontiev" <leo@sai.msu.ru>

Привет Алексей,

От 6 января 2015 г., 15:32:46 в fido7.ru.linux ты писал:
AV>>> Очень надеюсь, что мода на systemd в скором времени
AV>>> пройдет.
SL>> Не могу с тобой согласится. И разработчикам, и
SL>> пользователям, удобнее единообразие.
AV> Скрипты, которые понимают параметры start, stop, restart и при
AV> необходимости status - куда единообразнее-то?

Выдача status не документирована, к тому же она чаще всего является не
слишком надёжным результатом pidof или ps. Поэтому способы защиты
демонов/сервисов от OOM-Killer немного запутаны.

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

Злые языки утверждают, что автор systemd брал за образец launchctl/launchd.

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

Да регулярно. Есть у него, конечно, некоторые математические проблемы.

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

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

А что rpm usbhwrng в cron.d сам записать не может? Команд было бы меньше.

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

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

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

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

Ну, если все демоны идеальны, то их же можно просто сразу параллельно
запустить.

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

Я уважаю все религиозные воззрения, возможно, кто-то верит в идеальные
демоны/сервисы, которым даже не требуется аналог rcorder.

--
Успехов, Сергей Леонтьев. E-mail: lse@CryptoPro.ru
--- ifmail v.2.15dev5.4