date:20151112

On Thu, Nov 12, 2015 at 09:56:48PM +0300, Alexey Shrub wrote:
> On Чт, ноя 12, 2015 в 9:20 , Artem Chuprina  wrote:
> >1. вычистить именованные сокеты, которые могли остаться после падения в
> >предыдущем запуске
> 
> мне кажется что это какой-то грязный костыль не имеющий отношения с системе
> инициализации, чистить мусор за собой должен тот что его создал =
> освобождать ресурсы должен тот кто их занимал, если без костыля никак, то
> делать его нужно отдельным процессов от которого должен зависеть дальнейших
> запуск

systemd включает в себя специальный демон  systemd-tmpfiles для самой
изощренной работы с временными файлами.

Но в данном случае достаточно установить RuntimeDirectory=
и systemd ее почистит после остановки сервиса

Re: systemd

2015-11-12 Пенетрантность Alex Kicelew

On 11/12/15 22:54, Иван Лох wrote:
> Но в данном случае достаточно установить RuntimeDirectory=
> и systemd ее почистит после остановки сервиса

А перед? Остановка сервиса может быть по броску питания.

Re: systemd

11 ноября 2015 г., 19:28 пользователь Artem Chuprina  
написал:
> Понимаешь, в чем разница...  Не скажу за TCP, а монолитное ядро стали
> включать в дистрибутивы ОС только после того, как оно заработало лучше,
> чем то, что там было раньше.

Я, наверное, что-то пропустил, но разве были такие open source ОС,
которые сменили микроядро на монолит?

>  (Ну да, если быть совсем уж точным, то на
> замену юниксам пришел весь комплект GNU/Linux, но идея как раз в том,
> что он лучше работал.)  Что-то я подозреваю, что TCP/IP выиграл у
> ISO/OSI по другой причине - наличия реализации у первого и отсутствия у
> второго, а вот у конкурентов вроде IPX - именно тем, что лучше работал.
> IPX годился только для локальных сетей, к задержкам и потерям пакетов
> относился весьма нервно.

Ну, если проводить аналогии между стэками и init'ами, то IPX - это
таки upstart. Хороший конкурент systemd, но лишенный части
функциональности, которая всем дистростроителям вдруг оказалась нужна.
А sysV в этой истории - это вообще соединение по нуль-модемному кабелю
) Таким образом, ISO/OSI в этой истории продолжает соответствовать
некой гипотетической рассово, идейно и архитектурно верной системе
init, реализации которой мы не увидим никогда )

> А вот в случае с systemd заменяют надежное, пусть и далекое от идеала по
> архитектуре, более близким к идеалу по идее (по архитектуре, кстати,
> боюсь, не получилось), но безнадежно глючащим.  Идея рубить сук, на
> котором сидишь, мне не импонирует.


>  Одним из основных маркетинговых
> преимуществ линукса, в т.ч. и на десктопах, до сих пор была по сравнению
> с виндой бОльшая надежность.  (А с MacOS X - бОльшая свобода за меньшие
> деньги; надежностью там нижний уровень от FreeBSD заведует, у него с
> этим тоже все в порядке.  Но шаг влево, шаг вправо стоит дорого.)
>
> Если мы теряем сразу и надежность, и дешевые шаги влево-вправо, то мы
> проигрываем на обоих фронтах сразу.
>



-- 
With best regards
  Max Dmitrichenko

Re: systemd

2015-11-12 Пенетрантность Eugene Berdnikov

>>> Ну, или придется признать вырождение debian и дружно мигрировать на
>>> gentoo.

DEO>> в генте тоже systemd

> Насколько я знаю, в генте _можно_ собраться с systemd.  А можно и без
> него.

ну дык и в Debian _можно_ его не устанавливать.

вопрос тут в том что поставят ли зависимость с xorg на systemd или
нет.
если не поставят, то и можно будет на Debian/Gentoo жить без него,
если поставят - тут нужно будет думать в любом дистре

> Ну, в stable.  Судя по тому, что тут пишет Женя, в unstable ситуация уже
> хуже.

я не обновлялся еще до последнего unstable, но парумесячной давности
пока без systemd у меня живет.

щас там резко переколбасили xorg: перенесли его полностью в userspace
и поэтому теперь есть проблемы в работе xdm (и вообще всего X'ового,
запускающегося от root)

DEO>> у кого-нибудь кстати есть объяснение почему этот systemd так везде
DEO>> пихают?
DEO>> у меня только одно: всяким gnome/kde оно зачем-то нужно. Но понять
DEO>> зачем я увы не могу.

> Я наблюдаю некий заказ, не факт, что осознаваемый разработчиками, на
> фактическое прикрытие Open Source по принципу "не только в коде, но и в
> настройке не должен быть способен разобраться почти никто".  Такой
> vendor lock не мытьем, так катаньем.  С gtk и гномом я это пронаблюдал
> уже несколько лет назад, и судя по письмам тут, ситуация с тех пор
> становится все хуже.

> Затем они начали лочить на DBus с его бинарным API изрядную часть
> системных инструментов.

да кстати, DBus в целом идея нормальная, но блин бинарный протокол все
портит

-- 

. ''`.   Dmitry E. Oboukhov
: :’  :   email: un...@debian.org jabber://un...@uvw.ru
`. `~’  GPGKey: 1024D / F8E26537 2006-11-21
  `- 1B23 D4F8 8EC0 D902 0555  E438 AB8C 00CF F8E2 6537


signature.asc
Description: Digital signature

Re: systemd

On Thu, Nov 12, 2015 at 02:50:15AM +0300, sergio wrote:
> Вообще это какая-то надуманная проблема. Все интерфейсы которые важны я
> называю сам, а на остальные насрать. Даже наоборот, хочется не
> фиксированных имён для всех остальных. Ну то есть что бы usb сетевушка
> воткнутая первой была usb0.

 А кому-то не понравится именование по типу шины, и захочется именование
 по типу среды: eth5, wlan2, bt0 и т.д. И он будет по-своему прав.

 Проблема с udev не в том, что он стал вычурно именовать интерфейсы,
 и не в том, что их имена иногда меняются. Проблема в том, что старые
 добрые конфигурации из /etc/udev/rules.d кое-где перестали работать,
 несмотря на на наличие там файликов от предыдущих инкарнаций, где имена
 были чётко привязаны к mac-адресам сетевушек. Кроме того, иногда при
 замене сетевушки новый udev не спасает её данные в /etc/udev/rules.d/.
 Эта гармонично дополняется тем, что в дебиане по умолчанию логгирование
 действий udev'а отключено, и когда критичная для жизни подсистема
 ошибается, причину этого впоследствии понять невозможно. Для диагностики
 нужна пересборка initrd и/или пляски с --debug за консолью.
-- 
 Eugene Berdnikov

Re: Миграция соединений

31 октября 2015 г., 19:53 пользователь Dmitry Nezhevenko
 написал:
> У аналогичный сценарий. И все работает из коробки. Главное -- прописать один и
> тот же IP-адрес себе для wifi и ethernet подключения (ну или добиться,
> чтобы роутер по dhcp выдавал тот же IP адрес). Правда без systemd/network 
> manager.

Наверное, со статическим заданием IP адресов это работает. Думаю, что
если роутер выдаёт адрес через dhcp, то он сбрасывает всю таблицу NAT
с этим адресом.

Но как-то кривовастенько. Если к wi-fi можно привязать конфигурацию IP
в зависимости от SSID, то прикручивать гвоздями ethernet у ноутбука
как-то не айс.

-- 
With best regards
  Max Dmitrichenko

Re: systemd

почему-то письма от Вас (и только от Вас) приходят с отломанным от
письма тегом List-ID.
если Вам не трудно, пользуйтесь кнопкой "ответить в рассылку" вместо
той которую там используете.

>>> Затем они начали лочить на DBus с его бинарным API изрядную часть
>>> системных инструментов.
>>
>> да кстати, DBus в целом идея нормальная, но блин бинарный протокол все
>> портит

> И слава его придумщикам, что он бинарный. Текстовые протоколы ГОРАЗДО
> сложнее в написании безопасного кода. Не говоря уже о накладных
> расходах, которыми в эпоху гигабайтов и гигагерцов почему-то принято
> принебрегать.

текстовые протоколы гораздо проще в написании кода.
насчет безопасного кода - я не понял нифига. но большинство протоколов
в интернете - текстовые.
правда тут полезли неофиты из гугла и прочих копрораций и начали
внедрять бинарные расширения к HTTP. увы и ах - тоже дурная тенденция.

насчет накладных расходов: Dbus предполагает систему евентов на
локальной машине (с возможным гейтом в сеть). я не понимаю кого и как
тут могут волновать накладные расходы какие-то

> Не хватало ещё очередного джаббера для демонов на XML.

вот XML - это не текстовый протокол. ибо текстовый - это когда имеем
человекочитаемый текст. а XML - это с трудом человекочитаемый бред.
в мире есть множество порождений абсолютного зла: бинарный Dbus,
systemd, Windows, Lua, итп
XML в этом списке не на последнем месте
-- 

. ''`.   Dmitry E. Oboukhov
: :’  :   email: un...@debian.org jabber://un...@uvw.ru
`. `~’  GPGKey: 1024D / F8E26537 2006-11-21
  `- 1B23 D4F8 8EC0 D902 0555  E438 AB8C 00CF F8E2 6537


signature.asc
Description: Digital signature

Re: systemd

>> вроде нарисовался вполне себе тру-вей на этот гребанный автомаунт:
>> udev в связке с тем же dbus, далее показывай себе окошки в ответ на
>> всовывание девайса. но нет, зачем-то понадобилось переписывать
>> /sbin/init. я не вижу обоснования - зачем?
>> sudo не нравится?
>> ну дык напишите свой gnome-su, блин, пусть работает по таким правилам
>> как вам нравится

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

фиксируем: имеет место быть попытка построить всех в один строй.
знаете почему я терпеть не могу gnome? из за XML в конфигах
меня очень тошнит от этих всяких blob-реестров итп. я прекрасно
обхожусь без этого мусора и мне очень импонирует что я понимаю как я
могу решить ту или иную задачу будь она передо мной встанет

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

>>> Захотелось увязать это всё с наличием юзера в системе - типа вышел
>>> юзер, надо всё отмаунтить, VPN'ы отключить, от Wi-Fi отсоединиться.
>> 
>> ну дык все эти гномы/kde работают поверх каких-то gdm/kdm.

> Во-первых, классическая архитектура X11 подразумевает, что даже DM
> может быть запущен удалённо.

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

> Во-вторых, а почему, собственно, вы
> относите данные проблемы исключительно к проблемам графического
> окружения?

да в общем и для неграфического окружения точно так же переписывание
/sbin/init не требуется для размонтирования флешки при логауте.
и кстати само это размонтирование при логауте - если подумать тоже
зло.

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

в общем виде когда ты с хостом удаленно работаешь, то довольно часто
используешь n соединений с ним. при логауте какого размонтировать?

> Кроме того, как только дашь это на откуп DM, то начнется свистопляска,
> что один DM это делает, а другой не делает. Кому нужен этот "парад
> сувернитетов"?

мне нужен.
именно благодаря параду сувернитетов у меня пока получается успешно и
спокойно существовать вне этого поганого мира systemd итп

>>> Или допустим другой вопрос: стоит ли давать удалённому юзеру
>>> возможность маунтить локальные флэшки? Если нет, то нужно как-то
>>> определять, какой юзер локальный, а какой удаленный, кому показывать
>>> notification с предложением примаунтить флэшку?
>> 
>> тут я тоже не вижу необходимости переписывать /sbin/init, поясните
>> зачем это понадобилось?

> Ну вот как-то так оказалось, что капнёшь в одном месте, а вылезешь в
> другом. Я сам ещё до конца не понял и не обозрел этого зверя systemd,
> но подозреваю, что была необходимость увязать init с остальным.

я этой необходимости не вижу

была необходимость стандартизовать какие-то межсистемные
взаимодействия - да.
ну сядьте и напишите стандарт. да набор скриптов/демонов к нему.
зачем переписывать /sbin/init да еще попутно запихивая в него
совершенно независимые от него вещи, как логгирование, http-серверы, и
прочие кофемолки?

>> вот именно - десктопная.
>> мой разнесчастный десктоп апгрейдится с 1998-го года (с
>> Debian/potato).
>> проблемы с апгрейдом у меня начали появляться только как systemd стали
>> вкручивать.

> Пользуюсь начиная с woody. Но помилуйте. В то время не на каждом ноуте
> работало под линксум всё железо. О каких проблемах, которые решаются
> сейчас, можно было тогда думать?

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

>> дык на эту тему давно работа проведена, загляните в любой скрипт
>> /etc/init.d там в заголовке шапка: от чего зависит и после чего
>> запускаться должен

> Если мы рассматриваем исключительно процесс init, то мне очень
> нравился upstart (по прочитанной в общеобразовательных целях доке),
> хотя ни разу его не юзал. Но одного инита оказалось мало.

но обоснований переписывать init я пока не увидел
-- 

. ''`.   Dmitry E. Oboukhov
: :’  :   email: un...@debian.org jabber://un...@uvw.ru
`. `~’  GPGKey: 1024D / F8E26537 2006-11-21
  `- 1B23 D4F8 8EC0 D902 0555  E438 AB8C 00CF F8E2 6537


signature.asc
Description: Digital signature

Re: systemd

12 ноября 2015 г., 11:55 пользователь Dmitry E. Oboukhov
 написал:
> вроде нарисовался вполне себе тру-вей на этот гребанный автомаунт:
> udev в связке с тем же dbus, далее показывай себе окошки в ответ на
> всовывание девайса. но нет, зачем-то понадобилось переписывать
> /sbin/init. я не вижу обоснования - зачем?
> sudo не нравится?
> ну дык напишите свой gnome-su, блин, пусть работает по таким правилам
> как вам нравится

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

>
>> Захотелось увязать это всё с наличием юзера в системе - типа вышел
>> юзер, надо всё отмаунтить, VPN'ы отключить, от Wi-Fi отсоединиться.
>
> ну дык все эти гномы/kde работают поверх каких-то gdm/kdm.

Во-первых, классическая архитектура X11 подразумевает, что даже DM
может быть запущен удалённо. Во-вторых, а почему, собственно, вы
относите данные проблемы исключительно к проблемам графического
окружения? На мой имховый взгляд, для консоли можно поставить ровно
такие-же вопросы на повестку дня. Конечно, бородатому админу они
покажутся смешными, но решать их исключительно в пространстве GUI на
мой взгляд не правильно.

Кроме того, как только дашь это на откуп DM, то начнется свистопляска,
что один DM это делает, а другой не делает. Кому нужен этот "парад
сувернитетов"?

>> Или допустим другой вопрос: стоит ли давать удалённому юзеру
>> возможность маунтить локальные флэшки? Если нет, то нужно как-то
>> определять, какой юзер локальный, а какой удаленный, кому показывать
>> notification с предложением примаунтить флэшку?
>
> тут я тоже не вижу необходимости переписывать /sbin/init, поясните
> зачем это понадобилось?

Ну вот как-то так оказалось, что капнёшь в одном месте, а вылезешь в
другом. Я сам ещё до конца не понял и не обозрел этого зверя systemd,
но подозреваю, что была необходимость увязать init с остальным.

> вот именно - десктопная.
> мой разнесчастный десктоп апгрейдится с 1998-го года (с
> Debian/potato).
> проблемы с апгрейдом у меня начали появляться только как systemd стали
> вкручивать.

Пользуюсь начиная с woody. Но помилуйте. В то время не на каждом ноуте
работало под линксум всё железо. О каких проблемах, которые решаются
сейчас, можно было тогда думать?

> дык на эту тему давно работа проведена, загляните в любой скрипт
> /etc/init.d там в заголовке шапка: от чего зависит и после чего
> запускаться должен

Если мы рассматриваем исключительно процесс init, то мне очень
нравился upstart (по прочитанной в общеобразовательных целях доке),
хотя ни разу его не юзал. Но одного инита оказалось мало.

-- 
With best regards
  Max Dmitrichenko

Re: systemd

On Thu, 12 Nov 2015 12:17:34 +0300
Max Dmitrichenko  wrote:

> >> Затем они начали лочить на DBus с его бинарным API изрядную часть
> >> системных инструментов.
> >
> > да кстати, DBus в целом идея нормальная, но блин бинарный протокол
> > все портит
> 
> И слава его придумщикам, что он бинарный. Текстовые протоколы ГОРАЗДО
> сложнее в написании безопасного кода. Не говоря уже о накладных
> расходах, которыми в эпоху гигабайтов и гигагерцов почему-то принято
> принебрегать. Не хватало ещё очередного джаббера для демонов на XML.
> 

XML это НЕ ТЕКСТОВЫЙ ПРОТОКОЛ. Я бы даже IMAP из-за обязательных
идентификаторов команды  относил к "полутекстовым". Текстовый это,
например язык shell.

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

Кстати, для бинарного протокола все равно пришлось писать библиотеку
маршаллинга. Потому что современные недопрограммисты НЕ В СОСТОЯНИИ
написать разбор бинарного формата. Можно было и для текстового формата
эту библиотеку написать. Или взять готовую - питоновский argparse
например.

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

Re: Миграция соединений

31 октября 2015 г., 14:45 пользователь Dmitry E. Oboukhov
 написал:
> у меня openvpn настроен на один из моих серверов, подобные вещи пускаю
> через него.
> после того как он переустановит соединение все ssh-сессии отлично
> "просыпаются", даже если в интернет я пошел через другой совсем канал.

Да, но в такой истории эти соединения должны быть установленны через
VPN. Если они будут открыты через интерфейс, который уходит в down, то
ничего хорошего не выйдет.

-- 
With best regards
  Max Dmitrichenko

Re: systemd

Dmitry E. Oboukhov -> debian-russian@lists.debian.org @ Thu, 12 Nov 2015
11:44:56 +0300:

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

DEO>>> в генте тоже systemd

>> Насколько я знаю, в генте _можно_ собраться с systemd. А можно и без
>> него.

DEO> ну дык и в Debian _можно_ его не устанавливать.

DEO> вопрос тут в том что поставят ли зависимость с xorg на systemd или
DEO> нет.
DEO> если не поставят, то и можно будет на Debian/Gentoo жить без него,
DEO> если поставят - тут нужно будет думать в любом дистре

Собственно, идея в том, что в Debian есть один вариант сборки xorg, а в
Gentoo - пяток флагов (для xorg, может, и все два десятка), и при сборке
можно указать любую их конфигурацию.

Проблема возникнет только тогда, когда xorg будет написан так, что без
systemd не сможет работать в принципе. Это если и произойдет, то
нескоро, поскольку systemd линукс-специфичен, а xorg работает еще как
минимум на фрюхе, а если копнуть, то может оказаться, что и в MacOS X
нижним уровнем графики работает тоже он...

Re: systemd

Случайно нажал отправить, не дописав ответ.

11 ноября 2015 г., 19:28 пользователь Artem Chuprina  
написал:
> А вот в случае с systemd заменяют надежное, пусть и далекое от идеала по
> архитектуре, более близким к идеалу по идее (по архитектуре, кстати,
> боюсь, не получилось), но безнадежно глючащим.

Всё же мне чисто субъективно кажется, что бОльшая часть проблем с
systemd в данный момент из-за того, что мы не умеем его готовить, а не
из-за реальных глюков. Штука новая, большая, с кондочка не освоить за
бутылочкой пива. А тот, кто разобрался и знает, очевидно, видит в нём
преимущества и продвигает его в том дистре, в разработке которого он
участвует.

> Идея рубить сук, на
> котором сидишь, мне не импонирует.

Идея консерватизма тоже даёт сбои. Давай, вспомним, как медленно
развивающий XFree86 превратился в бурно развивающийся X.org (если
оставить за скобками повод в изменении лицензии). Всё-таки мне
кажется, что заядлым консерваторам место где-то в районе между NetBSD
и OpenBSD )

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

Ну не знаю за все дистры не скажу, но дебиан с маркетингом связан
слабо. Я не знаю наверняка, но подозреваю, что если бы в команде DD
нашелся человек, который сказал бы "я буду нести на себе крест, по
поддержке SysV и гарантирую работу всех пакетов, у которых есть
инит-скрипт, с обеими системами", то никто бы не возражал. Но как
всегда, видимо, дальше разговоров о том, что systemd - плохой и
ненужный, дело не пошло.


-- 
With best regards
  Max Dmitrichenko

Re: systemd

>> у кого-нибудь кстати есть объяснение почему этот systemd так везде
>> пихают?
>> у меня только одно: всяким gnome/kde оно зачем-то нужно. Но понять
>> зачем я увы не могу.

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

> Из того, что приходит в голову первым: появились всякие wifi, прочие
> PAN'ы и VPN'ы, а значит юзеру понадобилась возможность конфигурить
> сетевые интерфейсы роутинг и так далее, без консоли и sudo.

я, увы, не понимаю зачем для конфига wifi, pan, vpn надо
переколбашивать /sbin/init.
вот wifi: у нас был (и есть) отличный демон, управляемый из консоли,
из сокета - кому как нравится: хочешь подключить к Wifi - подключай,
хочешь отключить - отключай. зачем тут модифицированный /sbin/init?

> Так
> появился первый предвестник - network manager. Потом начались всякие
> приблуды с примаунчиванием томов по USB, правами доступа к этим томам.

вроде нарисовался вполне себе тру-вей на этот гребанный автомаунт:
udev в связке с тем же dbus, далее показывай себе окошки в ответ на
всовывание девайса. но нет, зачем-то понадобилось переписывать
/sbin/init. я не вижу обоснования - зачем?
sudo не нравится?
ну дык напишите свой gnome-su, блин, пусть работает по таким правилам
как вам нравится

> Захотелось увязать это всё с наличием юзера в системе - типа вышел
> юзер, надо всё отмаунтить, VPN'ы отключить, от Wi-Fi отсоединиться.

ну дык все эти гномы/kde работают поверх каких-то gdm/kdm.
запуск/логин юзеров в них происходит.
далее никаких проблем нет управлять тасками atexit

> Или допустим другой вопрос: стоит ли давать удалённому юзеру
> возможность маунтить локальные флэшки? Если нет, то нужно как-то
> определять, какой юзер локальный, а какой удаленный, кому показывать
> notification с предложением примаунтить флэшку?

тут я тоже не вижу необходимости переписывать /sbin/init, поясните
зачем это понадобилось?



> И вот уже связь:
> сетевая подсистема и файловая связывается с понятием сессия
> пользователя или даже сессия локального пользователя. Раньше никто не
> запаривался, потому как это не свойственно для серверов, где железо (и
> интерфейсы) не появляются и исчеазают каждые 5 минут, но теперь-то у
> нас вроде как и десктопная ОС тоже.

вот именно - десктопная.
мой разнесчастный десктоп апгрейдится с 1998-го года (с
Debian/potato).
проблемы с апгрейдом у меня начали появляться только как systemd стали
вкручивать.

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

дык на эту тему давно работа проведена, загляните в любой скрипт
/etc/init.d там в заголовке шапка: от чего зависит и после чего
запускаться должен

-- 

. ''`.   Dmitry E. Oboukhov
: :’  :   email: un...@debian.org jabber://un...@uvw.ru
`. `~’  GPGKey: 1024D / F8E26537 2006-11-21
  `- 1B23 D4F8 8EC0 D902 0555  E438 AB8C 00CF F8E2 6537


signature.asc
Description: Digital signature

Re: systemd

>> Затем они начали лочить на DBus с его бинарным API изрядную часть
>> системных инструментов.
>
> да кстати, DBus в целом идея нормальная, но блин бинарный протокол все
> портит

И слава его придумщикам, что он бинарный. Текстовые протоколы ГОРАЗДО
сложнее в написании безопасного кода. Не говоря уже о накладных
расходах, которыми в эпоху гигабайтов и гигагерцов почему-то принято
принебрегать. Не хватало ещё очередного джаббера для демонов на XML.

--
With best regards
  Max Dmitrichenko

Re: systemd

2015-11-12 Пенетрантность Hleb Valoshka

On 11/11/15, Alexey Shrub  wrote:

> А переход на конфиги? Это же ацкий
> костыль что скрипты инициализации
> пишутся на баше, по сути на
> универсальном языке программирования,
> это избыточно и явно минус с точки
> зрения безопасности, а ещё говорят что
> systemd зависит от всяких ненужных вещей,
> а система инициализации зависящая от
> шела это норм?

Сделайте, пожалуйста, на этом вашем systemd обновление nginx или
unicorn без обрыва существующих соединений. И без читерста a-la
использования внешних утилит на шелле (хотя systemd всё равно не
сможет её использовать, ибо кроме start-stop-restart-reload больше
ничего не знает).

Re: Миграция соединений

On Thu, 12 Nov 2015 11:21:34 +0300
Max Dmitrichenko  wrote:

> 31 октября 2015 г., 19:53 пользователь Dmitry Nezhevenko
>  написал:
> > У аналогичный сценарий. И все работает из коробки. Главное --
> > прописать один и тот же IP-адрес себе для wifi и ethernet
> > подключения (ну или добиться, чтобы роутер по dhcp выдавал тот же
> > IP адрес). Правда без systemd/network manager.
> 
> Наверное, со статическим заданием IP адресов это работает. Думаю, что
> если роутер выдаёт адрес через dhcp, то он сбрасывает всю таблицу NAT
> с этим адресом.
> 

Ну не знаю, какой роутер это делает. Большая часть роутеров сделана на
чем-нибудь на Linux-е и dhcp-сервером там dnsmasq. Вот он точно такого
не делает. Не пытается как-то рулить iptables-ами при выдаче адресов.

Опять же совершенно не обязательно чтобы роутер и dhcp-сервер совпадали.
У меня одно время десктоп уже не работал роутером, но еще работал
dhcp-сервером (потому что научить dd-wrt отдавать имя загрузочного
файла для бездисковых клиентов я не сумел).

Re: systemd

Max Dmitrichenko -> Debian Russian Mailing List  @ Thu, 12 Nov 2015 11:38:57 
+0300:

 >> Понимаешь, в чем разница...  Не скажу за TCP, а монолитное ядро стали
 >> включать в дистрибутивы ОС только после того, как оно заработало лучше,
 >> чем то, что там было раньше.

 MD> Я, наверное, что-то пропустил, но разве были такие open source ОС,
 MD> которые сменили микроядро на монолит?

Появились дистрибутивы примерно тех же на уровне userspace (и даже почти
обратно совместимых) ОС.  В том числе с заменой closed source на open
source.

 >>  (Ну да, если быть совсем уж точным, то на
 >> замену юниксам пришел весь комплект GNU/Linux, но идея как раз в том,
 >> что он лучше работал.)  Что-то я подозреваю, что TCP/IP выиграл у
 >> ISO/OSI по другой причине - наличия реализации у первого и отсутствия у
 >> второго, а вот у конкурентов вроде IPX - именно тем, что лучше работал.
 >> IPX годился только для локальных сетей, к задержкам и потерям пакетов
 >> относился весьма нервно.

 MD> Ну, если проводить аналогии между стэками и init'ами, то IPX - это
 MD> таки upstart. Хороший конкурент systemd, но лишенный части
 MD> функциональности, которая всем дистростроителям вдруг оказалась нужна.
 MD> А sysV в этой истории - это вообще соединение по нуль-модемному кабелю
 MD> ) Таким образом, ISO/OSI в этой истории продолжает соответствовать
 MD> некой гипотетической рассово, идейно и архитектурно верной системе
 MD> init, реализации которой мы не увидим никогда )

Я почти со всем из этого согласен.  Я не согласен только с одним - что в
этой аналогии systemd соответствует TCP/IP.  TCP/IP выиграл у IPX за
счет того, что работал надежнее в сложных условиях.  В скорости он как
раз уступал, и в локалке IPX был удобнее.  А systemd как раз
сколь-нибудь надежно работает только в тщательно отгороженной от
реальности песочнице, а чуть сталкивается с реальностью - сразу
проблемы.

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

Re: systemd

2015-11-12 Пенетрантность Илья

Согласен, наверное, многие используют shell скрипты и то что ими нельзя 
обработать считают злом. Таким посоветовать могу пользоваться питоном 
вместо баша - им наверное можно все практически окучить :)


apt-cache search python | grep systemd


12.11.2015 19:55, Alexey Shrub пишет:

Что-то много текстопротокольного фанатизма, протоколы это не
художественная литература, бинарные протоколы это норма, никто не
заставляет руками набирать бинарные сообщения в hex редакторе, всегда
есть/можно написать простую утилиту которая всё делает читаемым. Ради
того чтобы раз в сто лет посмотреть отладочную инфу нет смысла все сто
лет иметь оверхед от текстового протокола

On Чт, ноя 12, 2015 в 11:44 , Dmitry E. Oboukhov  wrote

да кстати, DBus в целом идея нормальная, но блин бинарный протокол все
портит

Re: systemd

On Thu, Nov 12, 2015 at 11:11:25PM +0300, Alex Kicelew wrote:
> On 11/12/15 22:54, Иван Лох wrote:
> > Но в данном случае достаточно установить RuntimeDirectory=
> > и systemd ее почистит после остановки сервиса
> 
> А перед? Остановка сервиса может быть по броску питания.

Думаю, что да. Но в любом случае это поддиректория /run 
и находится на tmpfs. По скачку очистится.

Re: systemd

2015-11-12 Пенетрантность Sergey B Kirpichev

Иван Лох -> debian-russian@lists.debian.org @ Wed, 11 Nov 2015 22:54:39 +0300:

ИЛ> Кстати, gnome-keyring-daemon единственная гномовская программа, которую
ИЛ> я использую. Удобно же для всех браузеров иметь одно защищенное хранилище
ИЛ> паролей. И, да, для mutt и git тоже )))

ИЛ> С документацией там, правда, не очень. Только что касается ключей это
ИЛ> обычный ssh и gnupg agent, а от хранилища паролей ничего кроме secret-tool
ИЛ> не требуется обычно.

В принципе да, удобно. Мне, правда, надо еще шарить пароли с андроидом
и виндой, поэтому для хранения паролей я как-то больше keepassx
использую. Но он не работает агентом.

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

>> Логи у него уже бинарные, сделать бинарными еще и конфиги, не
>> документировать формат, и конфигурилку сделать только гномовскую.

ИЛ> Ну так у гнома (dconf) конфиги по-умолчанию бинарные )))

Во-во... Давайте к бинарным логам systemd добавим еще бинарные конфиги,
которые нечем изменить, если гномосессия не сумела подняться...

Re: systemd

On Thu, Nov 12, 2015 at 01:36:45PM +0300, Max Dmitrichenko wrote:
> Приходилось очень сильно выпендриваться, чтобы их найти и исправить,
> так как лог загрузки тупо нигде и никем не сохранялся.

bootlogd-то установить что-ли?! ;)

> > нет, он пытается мне сломать то, что у меня итак без него работало
> 
> Так не обновляйтесь. Или прекратите ныть, вступайте в дискуссии с
> теми, кто _принимает_ решения, доказывайте свою правоту до и во время
> драки и предлагайте _свою_ помощь в том, что _вам_ необходимо.

А вот тут вы в какой-то удивительный раз оказались правы.  Не понимаю
тех DD, которые промолчали все что можно, ничего не сделали сами
для изменения итогов голосования и сейчас застывают в гордой
позе оскорбленного достоинства...  Нет, товарищи - _вы_ сделали
Debian таким.  Вот эти самые премудрые пескари, которые все
пережидают в уютной норке halы, pulseaudio, etc.

Re: systemd

> Проблема возникнет только тогда, когда xorg будет написан так, что без
> systemd не сможет работать в принципе.  Это если и произойдет, то
> нескоро, поскольку systemd линукс-специфичен, а xorg работает еще как
> минимум на фрюхе, а если копнуть, то может оказаться, что и в MacOS X
> нижним уровнем графики работает тоже он...

так я ж о том и говорю: Debian тоже НЕ линукс-специфичен.
поэтому, думаю, Debian будет последним дистрибутивом на котором можно
будет еще жить без systemd, когда все прочие уже попадут в адЪ.

-- 

. ''`.   Dmitry E. Oboukhov
: :’  :   email: un...@debian.org jabber://un...@uvw.ru
`. `~’  GPGKey: 1024D / F8E26537 2006-11-21
  `- 1B23 D4F8 8EC0 D902 0555  E438 AB8C 00CF F8E2 6537


signature.asc
Description: Digital signature

Re: systemd

On Thu, 12 Nov 2015 13:02:53 +0300
"Dmitry E. Oboukhov"  wrote:

> > Проблема возникнет только тогда, когда xorg будет написан так, что
> > без systemd не сможет работать в принципе.  Это если и произойдет,
> > то нескоро, поскольку systemd линукс-специфичен, а xorg работает
> > еще как минимум на фрюхе, а если копнуть, то может оказаться, что и
> > в MacOS X нижним уровнем графики работает тоже он...
> 
> так я ж о том и говорю: Debian тоже НЕ линукс-специфичен.

Что-то не знаю ни одного человека, который был реально использовал
Debian/kFreeBSD или Debian/GNU Hurd.

А людей, которые используют FreeBSD - знаю.

Re: systemd

Max Dmitrichenko -> Victor Wagner @ Thu, 12 Nov 2015 13:24:15 +0300:

>> Потому что очевидно, что синтаксис шины сообщений должен быть
>> максимально близок к синтаксису командной строки.

MD> Для чего и кому это надо? Иметь возможность слать event'ы из
MD> коммандной строки штука нужная и полезная. Но это делается отдельной
MD> утилитой, которая понимает синтаксис текста и конвертирует их в
MD> сообщения шины. Один хрен, подрубиться telnet'ом к unix socket'ам и
MD> начать фигачить командочки не получится.

telnet'ом - нет, а nc - можно.

А "для чего"... Чем больше прослоек между трафиком по сети и глазами
того человека, который ищет проблему, тем больше вероятность, что
проблема потеряется в этих прослойках. Если оказывается, что две
библиотеки несовместимым образом реализуют бинарный протокол (ошибки,
чтоб никому не было обидно, предположим в обеих), то декодер, основанный
на одной из них, покажет только половину проблем. А если ошибка только
в этой библиотеке, то и вообще покажет ошибку не там, где она на самом
деле.

Иногда бинарный формат окупается. В первую очередь в криптографии, где
зашифрованный текст не должен иметь осмысленной интерпретации сторонним
наблюдателем, и поэтому нет смысла делать его человекочитаемым.

А вот метаинформацию TCP/IP сделать текстовой, может, и стоило. Я
сильно подозреваю, что количество мест, где от этого заметно просела бы
производительность, невелико. На совсем коротких интерактивных пакетах,
где payload - один-два символа, она и так уже безнадежна, на длинных
разница в оверхеде будет незаметна, а ситуаций, где размер payload'а
порядка размера заголовка, тупо мало.

Re: systemd

Dmitry E. Oboukhov -> debian-russian@lists.debian.org  @ Thu, 12 Nov 2015 
13:52:09 +0300:

 >>> Я бы даже IMAP из-за обязательных
 >>> идентификаторов команды  относил к "полутекстовым". Текстовый это,
 >>> например язык shell.

 >> Как вы (апологеты текстовых протоколов) пользуетесь бинарными ssh'ем,

 DEO> бинарный он на транспортном уровне, а пользуемся мы им в текстовой
 DEO> форме.
 DEO> я кстати еще застал времена когда ssh не было, а был telnet.

telnet, кстати, тоже обладает нехилым протоколом, с точки зрения
человека бинарным.

Re: systemd

>
> была необходимость стандартизовать какие-то межсистемные
> взаимодействия - да.
> ну сядьте и напишите стандарт. да набор скриптов/демонов к нему.

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

> зачем переписывать /sbin/init да еще попутно запихивая в него
> совершенно независимые от него вещи, как логгирование, http-серверы, и
> прочие кофемолки?

Логгирование потому, что для меня, например, всегда было проблемой
посмотреть и понять ошибки, которые возникали на стадии загрузки.
Приходилось очень сильно выпендриваться, чтобы их найти и исправить,
так как лог загрузки тупо нигде и никем не сохранялся. Другое дело -
бинарность логов. Тут можно спорить.
Серверы, как я понимаю, там именно потому, что это сервисы, за
стоп/старт/рестарт которых логично отвечать той же подсистеме init, а
не inetd. Ну и что, что они активируются не при старте системы, а при
обращении по порту?

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

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

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

Так не обновляйтесь. Или прекратите ныть, вступайте в дискуссии с
теми, кто _принимает_ решения, доказывайте свою правоту до и во время
драки и предлагайте _свою_ помощь в том, что _вам_ необходимо.

-- 
With best regards
  Max Dmitrichenko

Re: systemd

>> Я бы даже IMAP из-за обязательных
>> идентификаторов команды  относил к "полутекстовым". Текстовый это,
>> например язык shell.

> Как вы (апологеты текстовых протоколов) пользуетесь бинарными ssh'ем,

бинарный он на транспортном уровне, а пользуемся мы им в текстовой
форме.
я кстати еще застал времена когда ssh не было, а был telnet.
а ssh тогда только появился как [платная] приблуда к нему с
шифрованием.

> tcp/ip и так далее? Быть может, ещё и UTF-8 давит? ) Большинство
> протоколов - бинарные, и это правильно. Текстовые протоколы - это
> наследие первой тысячи RFC. Тогда не было инструментов типа
> современных wireshark, люди осознано шли на такие жертвы, чтобы
> глазами можно было найти ошибку.

нет, тогда просто люди занимались этим с рассмотрением того как это
можно расширять, как налаживать, как сопровождать.
а теперь тяп-ляп и в продакшен

> Тогда же ещё боялись 8-битных
> кодировок

не боялись, а пытались быть совместимыми со всем на свете что было
тогда на свете.

типа мы пишем протокол так чтобы им ПРОСТО могли воспользоваться из
любой системы

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

> Ага, не джаббер для демонов, а твиттер ) Ну-ну )

просто это сервер СООБЩЕНИЙ.
гнать через него данные - это использовать микроскоп для забивания
гвоздей.
для данных есть сокеты, файлы и прочие механизмы

>> Кстати, для бинарного протокола все равно пришлось писать библиотеку
>> маршаллинга. Потому что современные недопрограммисты НЕ В СОСТОЯНИИ
>> написать разбор бинарного формата.

> Вообще, переиспользование кода - это благо, безотносительно кривизны
> недопрограммистких рук. Тут же ещё акромя маршалинга, надо
> использовать unix socket'ы - вот это реально та вещь, которую не
> каждый в жизни щупал за вымя.

те кто программировал TCP-сокеты с UNIX-сокетами проблем ощущать не будет.

>> Можно было и для текстового формата
>> эту библиотеку написать. Или взять готовую - питоновский argparse
>> например.

> Не хватало ещё зависимостей от питона в этих вещах.

уж лучше зависимость от питона на init-уровне, чем зависимость от
гроба на колёсиках

>> Потому что очевидно, что синтаксис шины сообщений должен быть
>> максимально близок к синтаксису командной строки.

> Для чего и кому это надо? Иметь возможность слать event'ы из
> коммандной строки штука нужная и полезная.

помимо прочего правильная реализация предполагает правильное
использование.
вот сделали blob, далее появляется неофит, который думает: "а чтобы по
этому blob не послать 1Gb данных?" и погнали...
а был бы у него лимит на размер мессаджа, он бы посидел и подумал :)

-- 

. ''`.   Dmitry E. Oboukhov
: :’  :   email: un...@debian.org jabber://un...@uvw.ru
`. `~’  GPGKey: 1024D / F8E26537 2006-11-21
  `- 1B23 D4F8 8EC0 D902 0555  E438 AB8C 00CF F8E2 6537


signature.asc
Description: Digital signature

Re: systemd

2015-11-12 Пенетрантность Alexander Galanin

Alexey Shrub -> debian-russian@lists.debian.org  @ Wed, 11 Nov 2015 18:29:33 
+0300:

 AS> А переход на конфиги? Это же ацкий костыль что скрипты инициализации 
пишутся
 AS> на баше, по сути на универсальном языке программирования, это избыточно и 
явно
 AS> минус с точки зрения безопасности, а ещё говорят что systemd зависит от 
всяких
 AS> ненужных вещей, а система инициализации зависящая от шела это норм?

Тонкий нюанс.  Если посмотреть на ряд таких скриптов, станет понятно, почему.

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

Re: systemd

On Thu, 12 Nov 2015 13:24:15 +0300
Max Dmitrichenko  wrote:

> Один хрен, подрубиться telnet'ом к unix socket'ам и
> начать фигачить командочки не получится.

Эта утилита называется socat. Эдакий telnet для всех типов сокетов.

-- 
Alexander Galanin

Re: systemd

12 ноября 2015 г., 12:50 пользователь Victor Wagner
 написал:
> On Thu, 12 Nov 2015 12:17:34 +0300
> Max Dmitrichenko  wrote:
>
>> >> Затем они начали лочить на DBus с его бинарным API изрядную часть
>> >> системных инструментов.
>> >
>> > да кстати, DBus в целом идея нормальная, но блин бинарный протокол
>> > все портит
>>
>> И слава его придумщикам, что он бинарный. Текстовые протоколы ГОРАЗДО
>> сложнее в написании безопасного кода. Не говоря уже о накладных
>> расходах, которыми в эпоху гигабайтов и гигагерцов почему-то принято
>> принебрегать. Не хватало ещё очередного джаббера для демонов на XML.
>>
>
> XML это НЕ ТЕКСТОВЫЙ ПРОТОКОЛ.

Дело вкуса.

> Я бы даже IMAP из-за обязательных
> идентификаторов команды  относил к "полутекстовым". Текстовый это,
> например язык shell.

Как вы (апологеты текстовых протоколов) пользуетесь бинарными ssh'ем,
tcp/ip и так далее? Быть может, ещё и UTF-8 давит? ) Большинство
протоколов - бинарные, и это правильно. Текстовые протоколы - это
наследие первой тысячи RFC. Тогда не было инструментов типа
современных wireshark, люди осознано шли на такие жертвы, чтобы
глазами можно было найти ошибку. Тогда же ещё боялись 8-битных
кодировок и избегали использования первых 30 символов в payload'е. Вы
как хотите, а не хочу в такое прошлое.

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

Ага, не джаббер для демонов, а твиттер ) Ну-ну )

> Кстати, для бинарного протокола все равно пришлось писать библиотеку
> маршаллинга. Потому что современные недопрограммисты НЕ В СОСТОЯНИИ
> написать разбор бинарного формата.

Вообще, переиспользование кода - это благо, безотносительно кривизны
недопрограммистких рук. Тут же ещё акромя маршалинга, надо
использовать unix socket'ы - вот это реально та вещь, которую не
каждый в жизни щупал за вымя.

> Можно было и для текстового формата
> эту библиотеку написать. Или взять готовую - питоновский argparse
> например.

Не хватало ещё зависимостей от питона в этих вещах.

> Потому что очевидно, что синтаксис шины сообщений должен быть
> максимально близок к синтаксису командной строки.

Для чего и кому это надо? Иметь возможность слать event'ы из
коммандной строки штука нужная и полезная. Но это делается отдельной
утилитой, которая понимает синтаксис текста и конвертирует их в
сообщения шины. Один хрен, подрубиться telnet'ом к unix socket'ам и
начать фигачить командочки не получится.

-- 
With best regards
  Max Dmitrichenko

[DONE] wml://devel/debian-{installer/News/2005/20050301,installer/News/2003/3,med/News/2005/20050614}.wml

2015-11-12 Пенетрантность Lev Lamberov

Cheers!
Lev Lamberov
--- english/devel/debian-installer/News/2003/3.wml	2014-04-29 21:27:41.0 +0600
+++ russian/devel/debian-installer/News/2003/3.wml	2015-11-13 11:41:30.826115962 +0500
@@ -1,14 +1,15 @@
-Status after recent Debian compromise
+#use wml::debian::translation-check translation="1.3" maintainer="Lev Lamberov"
+Статус после недавней компрометации Debian
 2003-12-12
 #use wml::debian::news
 
 
-On November 21st, several Debian machines, including some that hosted part
-of the debian-installer infrastructure, were compromised by an attacker.
-debian-installer is now mostly recovered from this incident, but there is
-currently no access to beta 1 CD images, or some daily builds, that were
-hosted on the compromised machine. A few developers have made known good
-snapshots from past daily builds available:
+21 ноября несколько машин Debian, включая некоторые машины, на которых размещена часть
+инфраструктуры программы установки Debian, были скомпрометированы злоумышленниками.
+Инфраструктура debian-installer почти полностью восстановлена, но в настоящее
+время отсутствует доступ к образам компакт-дисков версии beta 1 и некоторым ежедневным сборкам, которые
+были размещены на скомпрометированной машине. Несколько разработчиков сделали
+снимки предыдущих ежедневных сборок, которые доступны теперь по следующим адресам:
 
 
 http://www.mmweg.rwth-aachen.de/~sebastian.ley/d-i/;>i386
@@ -16,7 +17,8 @@
 
 
 
-Despite these problems, we are making plans for releasing beta 2 of the
-installer toward the end of this month.
-https://lists.debian.org/debian-boot/2003/debian-boot-200312/msg00473.html;>This post tells the details.
+Несмотря на эти проблемы, мы планируем выпустить версию beta 2
+программы установки к концу этого месяца.
+https://lists.debian.org/debian-boot/2003/debian-boot-200312/msg00473.html;>В этом сообщении излагаются некоторые подробности.
 
+
--- english/devel/debian-installer/News/2005/20050301.wml	2005-03-06 05:24:50.0 +0500
+++ russian/devel/debian-installer/News/2005/20050301.wml	2015-11-13 11:36:25.745867476 +0500
@@ -1,24 +1,26 @@
-Preparations for release candidate 3 break some rc2 images
+#use wml::debian::translation-check translation="1.3" maintainer="Lev Lamberov"
+Подготовка к кандидату на выпуск 3 привела к поломке некоторых образов rc2
 2005-03-01
 #use wml::debian::news
 
 
-Final preparations have begun for release candidate 3. Some of the changes
-to the Debian archive may break installation media from release candidate
-2. We hope to get rc3 out as soon as possible to fix this.
+Началась окончательная подготовка к кандидату на выпуск версии 3. Некоторые изменения
+архива Debian могут привести к поломке установочных носителей для кандидата на выпуск версии
+2. Надеемся, что rc3 будет готов как можно быстрее, и проблема будет решена.
 
 
 
-The most likely image to break is the businesscard CD image and the netboot
-images. Network installs from rc2 floppys will break. 
-Netinst CD images, and full CD images, and booting from USB or floppy to
-install using those CD images, will continue to work no matter what.
-This page will be updated if rc3 preparations are found to have broken
-any other install images.
+Наиболее вероятно, что сломан будет образ минимальные образы для мини-дисков, а также образы
+сетевой установки. ОБразы дискет для сетевой установки версии rc2 работать не будут. 
+Образы компакт-дисков для сетевой установки, а также полные образы компакт-дисков, загрузка с USB или дискет для
+установки с использованием этих образов компакт-дисков будут работать, несмотря ни на что.
+Данная страница будет обновлена в случае, если будет обнаружено, что подготовка к выпуску rc3 приводит
+к поломке других установочных образов.
 
 
 
-In the meantime, if you need to use one of these installation methods, use
-the daily built images. This will also help us with pre-release testing for
-rc3, so file installation reports!
+Если же вы хотите использовать один из этих методов установки, используйте
+образы, создаваемые ежедневно. Кроме того, это поможет нас в предварительном тестировании
+версии rc3, поэтому отправляйте нам свои отчёты об установке!
 
+
--- english/devel/debian-med/News/2005/20050614.wml	2014-09-07 14:56:05.0 +0600
+++ russian/devel/debian-med/News/2005/20050614.wml	2015-11-13 11:46:32.918548887 +0500
@@ -1,18 +1,20 @@
-Debian Med day at DebConf 5 in Helsinki
+#use wml::debian::translation-check translation="1.4" maintainer="Lev Lamberov"
+День Debian Med на DebConf 5 в Хельсинки
 2005-06-14
 #use wml::debian::news
 # $Id: 20050614.wml,v 1.4 2014/09/07 08:56:05 pabs Exp $
 
-Andreas Tille https://lists.debian.org/debian-med/2005/06/msg00024.html;>
-announced that there will be a Debian Med day at this year's DebConf.
-Everyone interested in the Debian Med project is invited to join the
-meeting. Unfortunately, it wasn't possible to specify the date and
-time of the meeting yet. Andreas will post this information as soon
-as it is

Re: systemd

В Thu, 12 Nov 2015 18:54:06 +0300
"D.Himro"  пишет:

> On 11/12/2015 03:56 PM, Dmitry Alexandrov wrote:
> > On 11/11/15 18:29, Alexey Shrub wrote:
> >
> >> А параллельная загрузка?
> >
> > О! Раз уж тут холиварчик пошел, может быть мне кто-нибудь об’яснит,
> > чего с ней все так носятся, с этой с параллельной загрузкой
> > демонов, как с писанной торбой? Зачем она вообще нужна?
> 
> Вот и мне интересно. Такое ощущение что народ ставит себе систему и 
> целый день её ребутит ребути и ребутит. А от скорости ребута прямо 
> стабильность ядерного реактора зависит.
> 

Что характерно, разработчики систем инициализации ровно это и делают.
Они ставят тестовую систему и после каждого изменения в коде, которое
надо протестировать, ее перезапускают.




-- 
   Victor Wagner

Re: systemd

В Fri, 13 Nov 2015 00:11:24 +0300
Илья  пишет:

> Согласен, наверное, многие используют shell скрипты и то что ими
> нельзя обработать считают злом. Таким посоветовать могу пользоваться

Компьютер - он чтобы работать. Поэтому операции,
которые нельзя заскриптовать - действительно зло. Нужно чтобы любое
действие, которое ты делаешь руками можно было взять откуда-то, куда
оно записалось автоматически (например в history shell-а), и поместить
куда-то, откуда оно будет вызываться само.

shell это компромисс между "удобно делать интерактивно" и 
"пригодно для неинтерактивного выполния".



> питоном вместо баша - им наверное можно все практически окучить :)

Питон - существнно более низкоуровневый язык.

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

Фвктически лично мне удобно использовать питон в интерактивном режиме
только для ситуации "попробовать как работает тот или иной питоновский
объект, который я собираюсь использовать при написании программы".

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


-- 
   Victor Wagner

Re: systemd

2015-11-12 Пенетрантность Илья




12.11.2015 15:56, Dmitry Alexandrov пишет:

On 11/11/15 18:29, Alexey Shrub wrote:


А параллельная загрузка?


О! Раз уж тут холиварчик пошел, может быть мне кто-нибудь об’яснит, чего
с ней все так носятся, с этой с параллельной загрузкой демонов, как с
писанной торбой? Зачем она вообще нужна?


Я думаю тут дело не только в одной загрузке. Параллельная загрузка это
"побочный" эффект наличия механизмов управления службами. По идее 
systemd должен способствовать более эффективному использованию ресурсов 
системы.

Re: systemd

2015-11-12 Пенетрантность Илья




13.11.2015 08:16, Victor Wagner пишет:

В Fri, 13 Nov 2015 00:11:24 +0300
Илья  пишет:

Компьютер - он чтобы работать. Поэтому операции,
которые нельзя заскриптовать - действительно зло. Нужно чтобы любое
действие, которое ты делаешь руками можно было взять откуда-то, куда
оно записалось автоматически (например в history shell-а), и поместить
куда-то, откуда оно будет вызываться само.


Получается мышь и GUI это зло. :)



shell это компромисс между "удобно делать интерактивно" и
"пригодно для неинтерактивного выполния".

питоном вместо баша - им наверное можно все практически окучить :)

Питон - существнно более низкоуровневый язык.
В нем интерактивно можно разве что арифметические выражения вычислять.
То есть для большинства решаемых пользователем задач он - гораздо
худший компромисс между "решить интерактивно" и "решить автоматически".


Ну для меня важнее не классификация, а решении задачи.
Я даже не пробовал заменить bash на питон :) Хотя теоретически можно 
реализовать среду программирования которая добавит "интерактивности".

Думаю не корректно сравнивать среду (shell) и язык программирования.


Фвктически лично мне удобно использовать питон в интерактивном режиме
только для ситуации "попробовать как работает тот или иной питоновский
объект, который я собираюсь использовать при написании программы".

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


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

Команды grep ни ls ведь на СИ написаны, но вы ими пользуетесь
Я думаю интернет бороздить удобнее тем же links чем telnet.

ps Прошу прошения, за письмо в личку - спал уже

Re: systemd

2015-11-12 Пенетрантность Dmitry Alexandrov

> Что-то много текстопротокольного фанатизма, протоколы это не художественная
> литература, бинарные протоколы это норма, никто не заставляет руками набирать
> бинарные сообщения в hex редакторе, всегда есть/можно написать простую утилиту
> которая всё делает читаемым. Ради того чтобы раз в сто лет посмотреть
> отладочную инфу нет смысла все сто лет иметь оверхед от текстового протокола

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

. ''`.   Dmitry E. Oboukhov
: :’  :   email: un...@debian.org jabber://un...@uvw.ru
`. `~’  GPGKey: 1024D / F8E26537 2006-11-21
  `- 1B23 D4F8 8EC0 D902 0555  E438 AB8C 00CF F8E2 6537


signature.asc
Description: Digital signature

Re: systemd


On 11/11/15 18:29, Alexey Shrub wrote:


А параллельная загрузка?


О! Раз уж тут холиварчик пошел, может быть мне кто-нибудь об’яснит, чего 
с ней все так носятся, с этой с параллельной загрузкой демонов, как с 
писанной торбой? Зачем она вообще нужна?

Re: systemd

On Thu, 12 Nov 2015 13:24:15 +0300
Max Dmitrichenko  wrote:

> > Потому что очевидно, что синтаксис шины сообщений должен быть
> > максимально близок к синтаксису командной строки.
> 
> Для чего и кому это надо? Иметь возможность слать event'ы из
> коммандной строки штука нужная и полезная. Но это делается отдельной

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

Слать-то можно. С уродским синтаксисом dbus-send, но можно.

> утилитой, которая понимает синтаксис текста и конвертирует их в
> сообщения шины. Один хрен, подрубиться telnet'ом к unix socket'ам и
> начать фигачить командочки не получится.

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

Если
это шина, к ней должен быть свой аналог wireshark-а. dbus-monitor, увы,
откровенно слабоват.

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

Классический unix был хорош тем, что для решения специальных, редко
встречающихся задач, как правило не нужно было использовать специальные
инструменты, можно было пользоваться теми, которыми пользуешься каждый
день для часто встречающихся задач. Например логи анализировать тем же
grep-ом, которым анализируешь тексты. И да, писать скрипты запуска
системы на том же шелле, на которым ты ежедневно отдаешь команды
запуска любимого текстового редактора, отправки заданий на печать etc.

Re: systemd

On Thu, Nov 12, 2015 at 03:56:39PM +0300, Dmitry Alexandrov wrote:
> On 11/11/15 18:29, Alexey Shrub wrote:
> 
> >А параллельная загрузка?
> 
> О! Раз уж тут холиварчик пошел, может быть мне кто-нибудь об’яснит, чего с
> ней все так носятся, с этой с параллельной загрузкой демонов, как с писанной
> торбой? Зачем она вообще нужна?

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

Re: systemd

On Thu, Nov 12, 2015 at 02:46:31PM +0300, Artem Chuprina wrote:
> Иван Лох -> debian-russian@lists.debian.org  @ Wed, 11 Nov 2015 22:54:39 
> +0300:
> 
>  ИЛ> Кстати, gnome-keyring-daemon единственная гномовская программа, которую
>  ИЛ> я использую. Удобно же для всех браузеров иметь одно защищенное хранилище
>  ИЛ> паролей. И, да, для mutt и git тоже )))
> 
>  ИЛ> С документацией там, правда, не очень. Только что касается ключей это
>  ИЛ> обычный ssh и gnupg agent, а от хранилища паролей ничего кроме 
> secret-tool
>  ИЛ> не требуется обычно.
> 
> В принципе да, удобно.  Мне, правда, надо еще шарить пароли с андроидом
> и виндой, поэтому для хранения паролей я как-то больше keepassx
> использую.  Но он не работает агентом.
> 
> Я бы даже и использовал, он даже установлен у меня, но я так и не сумел
> понять, каким инструментом посмотреть/поредактировать keyring.

seahorse

Re: systemd

Dmitry Alexandrov -> debian-russian@lists.debian.org  @ Thu, 12 Nov 2015 
15:56:39 +0300:

 >>А параллельная загрузка?

 DA> О! Раз уж тут холиварчик пошел, может быть мне кто-нибудь об’яснит, чего с 
ней
 DA> все так носятся, с этой с параллельной загрузкой демонов, как с писанной
 DA> торбой? Зачем она вообще нужна?

Ну, как минимум, чтобы в случае, когда заткнулся один, спокойно
загрузились остальные, если они от него не зависят.  Даже так: если они
от него не зависят жестко.  Правда, я сильно подозреваю, что последнее
как раз забыли реализовать, потому что граждане, которые ЭТО везде
проталкивают, слова "надежность" в лексиконе не имеют.

Re: systemd

Иван Лох -> debian-russian@lists.debian.org  @ Thu, 12 Nov 2015 15:55:05 +0300:

 >>  ИЛ> Кстати, gnome-keyring-daemon единственная гномовская программа, которую
 >>  ИЛ> я использую. Удобно же для всех браузеров иметь одно защищенное 
 >> хранилище
 >>  ИЛ> паролей. И, да, для mutt и git тоже )))
 >> 
 >>  ИЛ> С документацией там, правда, не очень. Только что касается ключей это
 >>  ИЛ> обычный ssh и gnupg agent, а от хранилища паролей ничего кроме 
 >> secret-tool
 >>  ИЛ> не требуется обычно.
 >> 
 >> В принципе да, удобно.  Мне, правда, надо еще шарить пароли с андроидом
 >> и виндой, поэтому для хранения паролей я как-то больше keepassx
 >> использую.  Но он не работает агентом.
 >> 
 >> Я бы даже и использовал, он даже установлен у меня, но я так и не сумел
 >> понять, каким инструментом посмотреть/поредактировать keyring.

 ИЛ> seahorse

Только комбайн?  Не то чтобы он уж очень толстый комбайн, но все же...

Re: systemd

12 ноября 2015 г., 15:56 пользователь Dmitry Alexandrov
<321...@gmail.com> написал:
> On 11/11/15 18:29, Alexey Shrub wrote:
>
>> А параллельная загрузка?
>
>
> О! Раз уж тут холиварчик пошел, может быть мне кто-нибудь об’яснит, чего с
> ней все так носятся, с этой с параллельной загрузкой демонов, как с писанной
> торбой? Зачем она вообще нужна?

Windows 8 дюже быстро загружается ) Конкуренция, однако.

-- 
With best regards
  Max Dmitrichenko

Re: systemd

On Чт, ноя 12, 2015 в 9:20 , Artem Chuprina  
wrote:
1. вычистить именованные сокеты, 
которые могли остаться после падения 
в предыдущем запуске


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



2. поднять unicorn
3. поднять демон, выполняющий 
отложенные задания
База данных, фронтэнд и почтовка 
поднимаются отдельно, это собственно
application level.  На практике пять строчек 
на bash.



почему это нельзя сделать 
зависимостями?



Призовая игра.  Апгрейд.


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

Re: systemd

2015-11-12 Пенетрантность Dmitry Alexandrov

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


On Чт, ноя 12, 2015 в 3:14 , Artem Chuprina  
wrote:
Потому что это не конфиг, а программа 
запуска.  Которая неизбежно
является программой, потому что у 
многих сложных сервисов содержит ряд
нетривиальных действий.  Она, кстати, 
не зависит от шелла, программу

запуска можно писать на любом языке.

Re: systemd


On 12/11/15 17:12, Иван Лох wrote:

On Thu, Nov 12, 2015 at 03:56:39PM +0300, Dmitry Alexandrov wrote:

On 11/11/15 18:29, Alexey Shrub wrote:


А параллельная загрузка?


О! Раз уж тут холиварчик пошел, может быть мне кто-нибудь об’яснит, чего с
ней все так носятся, с этой с параллельной загрузкой демонов, как с писанной
торбой? Зачем она вообще нужна?


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


Серьезно? Время от времени загружаюсь не то, что с оборванным, а с 
заведомо отключенным сетевым кабелем — и никто никого не ждет — ну нет 
связи и нет — проехали, грузимся дальше. Я что-то не так делаю?


Более того, хотя за последними версиями этой Систем-Д не уследишь, но 
та, что в Джесси, по части поднятия отсутствующей сети дает абсолютно 
идентичный Сис-5-иниту результат — приказано ждать (auto) — ждет, 
тормозя загрузку; приказано не ждать (allow-hotplug) — не ждет. И я 
нахожу это логичным.


Что изменилось-то, кроме того, что старый инит показывает мне вывод 
dhcpd, по которому хотя бы видно, который из интерфейсов не подымается, 
а Систем-Д только крутит красивые красные звездочки напротив чего-то 
типа «Raising network»?

Re: systemd

2015-11-12 Пенетрантность Dmitry Alexandrov


On 12/11/15 16:49, Max Dmitrichenko wrote:

12 ноября 2015 г., 15:56 пользователь Dmitry Alexandrov
<321...@gmail.com> написал:

On 11/11/15 18:29, Alexey Shrub wrote:


А параллельная загрузка?



О! Раз уж тут холиварчик пошел, может быть мне кто-нибудь об’яснит, чего с
ней все так носятся, с этой с параллельной загрузкой демонов, как с писанной
торбой? Зачем она вообще нужна?


Windows 8 дюже быстро загружается ) Конкуренция, однако.


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

Re: systemd

Что-то много текстопротокольного 
фанатизма, протоколы это не 
художественная литература, бинарные 
протоколы это норма, никто не 
заставляет руками набирать бинарные 
сообщения в hex редакторе, всегда 
есть/можно написать простую утилиту 
которая всё делает читаемым. Ради того 
чтобы раз в сто лет посмотреть 
отладочную инфу нет смысла все сто лет 
иметь оверхед от текстового протокола


On Чт, ноя 12, 2015 в 11:44 , Dmitry E. Oboukhov 
 wrote
да кстати, DBus в целом идея нормальная, 
но блин бинарный протокол все

портит

Re: systemd

2015-11-12 Пенетрантность D.Himro


On 11/12/2015 05:12 PM, Иван Лох wrote:

On Thu, Nov 12, 2015 at 03:56:39PM +0300, Dmitry Alexandrov wrote:

On 11/11/15 18:29, Alexey Shrub wrote:


А параллельная загрузка?


О! Раз уж тут холиварчик пошел, может быть мне кто-нибудь об’яснит, чего с
ней все так носятся, с этой с параллельной загрузкой демонов, как с писанной
торбой? Зачем она вообще нужна?


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



И что?

--
Best regards,
Dim

Re: systemd

2015-11-12 Пенетрантность D.Himro


On 11/12/2015 03:56 PM, Dmitry Alexandrov wrote:

On 11/11/15 18:29, Alexey Shrub wrote:


А параллельная загрузка?


О! Раз уж тут холиварчик пошел, может быть мне кто-нибудь об’яснит, чего
с ней все так носятся, с этой с параллельной загрузкой демонов, как с
писанной торбой? Зачем она вообще нужна?


Вот и мне интересно. Такое ощущение что народ ставит себе систему и 
целый день её ребутит ребути и ребутит. А от скорости ребута прямо 
стабильность ядерного реактора зависит.


--
Best regards,
Dim

Re: systemd

On Thu, Nov 12, 2015 at 06:55:48PM +0300, D.Himro wrote:
> >или ждать
> >
> 
> И что?

Ну жди, мне то…

Re: systemd

Alexey Shrub -> debian-russian@lists.debian.org @ Thu, 12 Nov 2015 19:57:36
+0300:

AS> Думаю скрипты запуска не должны быть программами, интересно бы услышать
AS> конкретные примеры зачем это может быть нужно. Как-то же уложили всё в
AS> конфиги, значит возможно.

Это значит, что скрипт запуска просто переложили из /etc/init.d в другое
место. Или даже не переложили, а прямо его же и используют.

Конкретный пример из своей работы. Скрипт запуска веб-сервера,
выполняющего некоторую вполне конкретную задачу. Надо

1. вычистить именованные сокеты, которые могли остаться после падения в
предыдущем запуске

2. поднять unicorn

3. поднять демон, выполняющий отложенные задания

База данных, фронтэнд и почтовка поднимаются отдельно, это собственно
application level. На практике пять строчек на bash.

База данных и почтовка к моменту запуска обоих демонов должны работать,
фронтэнд можно, в общем, запускать и до unicorn (идеально было бы после
того, как тот будет готов работать, о чем он вряд ли умеет сообщать, а
демонизируется, скорее всего, раньше, чем будет готов). Предъяви,
пожалуйста, конфиг для systemd.

Призовая игра. Апгрейд. Надо

1. git pull

2. если при git pull поменялся скрипт апгрейда, перезапустить скрипт апгрейда

3. bundle install

4. rake assets:precompile

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

6. rake db:migrate

7. только после успешного завершения поднять вышеперечисленную пару

8. обновить crontab

Особое внимание на последовательность пп. 5-7. Как провести эту
операцию с systemd, если systemd будет пытаться поднять unicorn при
обращении к сокету?

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

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

По сравнению со всем этим идея, что мне ах, безумно не хватает
возможности начать стартовать unicorn только после того, как postgresql
готов работать (unicorn действительно нервно отнесется к отказу в
коннекте), выглядит одной из мелочей. Тупой sleep на 12 секунд в начале
скрипта запуска (только при старте системы, при апгрейде этот вариант не
выполняется) _на практике_ работает достаточно надежно, не приходится
даже изгаляться с несколькими предварительными попытками соединения
через psql. А почтовка и сама успевает запуститься раньше.

Оно, конечно, чисто в идеале было бы прям замечательно зацепиться за
зависимости (почтовка и постгрес готовы? ура, поднимаем движок), но
необходимости в _процедуре_, а не просто конфигурации, запуска это не
отменяет.

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

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

AS> On Чт, ноя 12, 2015 в 3:14 , Artem Chuprina wrote:
>> Потому что это не конфиг, а программа запуска. Которая неизбежно
>> является программой, потому что у многих сложных сервисов содержит ряд
>> нетривиальных действий. Она, кстати, не зависит от шелла, программу
>> запуска можно писать на любом языке.

Re: systemd