Всё, Поттеринг победил

Программа с продуманной распределенной архитектурой и четко описаными взаимодействиями - такое в линаксе вообще есть?

Вероятность, бла-бла, моя мама считает..

могу поздравить с хорошими родителями.

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

это конечно ЛОР, но если уже идёт скатывания на фекализмы, но видимо дискуссию можно прекращать? Openrc написан на C, многие helper функции написаны на баше, они формально не надёжнее, но их просто отлаживать и исправлять.

Если у тебя никогда не провисал тот же openrc, я тебе завидую.

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

Там уже конкретизировано.

rc-update add net.eth0 boot
rc-update add net.eth1 boot
...
rc -s net.eth0 stop

dbus - это шина, udev'а там нет.

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

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

про net - попробую.

т.е. код для работы с dbus и зависимости от него в PID 1 нету?

udev'а там нет.

правда? пока только кодовая база вместе? а события вешающиеся на устройство делаются через скрипты удава? (мне честно интересно)

про xinet это к socket-activation, я правда пока не могу понять зачем это может быть надо, если пойму, то можно будет попытаться изобразить. Т.е. формально понимаю, а вот use-case как-то далеки от реальности.

Там есть код и для взаимодействия с udev, и с dbus. На девайсы вешаются депы через ENV. socket-activation нужен для запуска сервисов on-demand вместе с депами

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

и каждый раз они обсуждаются в неверном ключе, мне, например, совершенно не интересно почему systemd гадость, ни доказывать ни выслушивать. Мне интересно, чем оно круче (как система инициализации сервисов), но пока реально я услышал только 1 вещь: файлы юнитов (это действительно принимается, если они могут покрыть весь функционал, без использовани скриптов, которые там поддерживаются), потом ещё сказали про поддержку cgroups (в опенрц она есть, если она не полная, то чего не хватает), ещё я слышал про поддержку namespaces (нужно будет доопросить того, от кого слышал), потом ещё всякие вещи, которые могут быть полезны (udev activation socket activation, filesystem activation) но тут мне интересны реальные юзкейсы.

Дальше мне интересно почему СД лучше других систем диспетчеризации сервисов: upstrart^W, runit, s6,daemon-tools. Соотв. что СД лучше решает и почему оно круче.

3 (на самом деле уже не важное) вопрос архитектуры, почему объединение разных программ в 1 комбайн лучше, чем уже существующие аналоги.

Т.к. openrc не умеет параллельную загрузку - это фатально.

умеет; будут баги можешь присылать мне на почту без патчей.

с dbus понимаю; с udev как реализовано? оно как обычно висит демоном, и запускает клиентскую прогу (какой-нить service-ctl) по унифицированному скрипту?

socket-activation нужен для запуска сервисов on-demand вместе с депами

для чего нужен формально понятно, только вот где это может использоваться? У ленивого девелопера, чтобы перед началом работы не запустить виртуальный сервис, который всё нужное включит? На телефоне, чтобы батарейку беречь? А как гасит сервисы такие?

3 (на самом деле уже не важное) вопрос архитектуры, почему объединение разных программ в 1 комбайн лучше, чем уже существующие аналоги.

Да ничем не лучше. И не одна там программа, а несколько. Только API не описан/написан. И графа зависимостей/взаимодействия тоже нет.

Потому один «всеми любимый» ЛП им и рулит, что еще не знает что-за монстрика он создаст.

Вобщем, как контроль запуска/останова процессов и cgroups связаны с PID 1 - это понятно.

На накакой туде еще и socket/FS/udev запихали???

На мой взгляд достоинства, которые до некоторой степени покрывают недостатки следующие:

1. Формальное описание этапов загрузки сервисов 2. API доступа к информации о состоянии сервисов 3. Динамическое управление сервисами по разным критериям. К сожалению не всеобъемлющее. К сожалению архитектурно не расширяемое (пока, похоже)

Разумеется, это все можно реализовать и скриптами, и чем угодно. Но пока реализовано до некоторой степени только в systemd.

В правила удева можно добавлять разную хрень в энвайрмент. СД монитором ловит эвенты удева и зырит, нужно ли что-то от него. Девайсы импортируются в сервисы. Элементы энвайрмента девайса импортируются в мягкие депы СД. СД запускает депы. Когда дейвайс отключается, СД ловит соотв. эвент и деактивирует устройство-сервис. Если были сервисы, которые зависили от работоспособности устройства-сервисы, то они тушатся. Если были сервисы, которые стартовались как депы соотв. потушенных сервисов, и были помечены как on-demand, они тоже тушатся.

По поводу сервисов по сокетам - это может быть что-то редко используемое типа капса итп.

В правила удева ...

Спасибо. Впервые дельное описание по СД прочитал.

иди учи матчасть.

Ты сложнее хеллоуворлда много чего написал?

и используй поиск

Нельзя найти то, чего нет.

у тебя есть все средства, чтобы ответить на свой вопрос, и понять почему ты не прав в п2.

А, возможно путаю. пардон.

ок. что сложного во внутреннем устройстве eselect? обычный скрипт, который делает линки. не так разве?

Во-первых, это дополнительная сущность, которая делает достаточно простые вещи, но непрозрачно. Во-вторых, почему только eselect? Гента обвязана фиговой тучей служебных инструментов, которые, к тому же, частично дублируют функции друг друга. Если это KISS, то я - китайский лётчик.

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

как это сделать прозрачнее?

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

вы про eix, emerge, portage-utils?

как это сделать прозрачнее?

Руками, например.

вы про eix, emerge, portage-utils?

Да.

Руками, например.

действительно.. может ещё и <language>-config убрать? А чо руками-то всяко проще.

Да.

они опциональны и более того не установлены по дефолту (кроме emerge) и гента от них не зависит и никак не обвязана.

cпасибо, если будут какие вопросы по этому поводу, я ещё спрошу.

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

действительно.. может ещё и <language>-config убрать?

Что это?

они опциональны и более того не установлены по дефолту (кроме emerge) и гента от них не зависит и никак не обвязана.

Только без них в ней работать комфортно нереально. Да и сам portage - тот ещё монстр.

Что это?

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

Только без них в ней работать комфортно нереально. Да и сам portage - тот ещё монстр.

eix достаточно. в чём заключается монструозность?

Его - кого? Обмен и сигнализация systemd и сателитов - через dbus.

его - капса.

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

В чем заключается прозрачность? в информативности вывода? или чего-то еще?

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

Кто-то любит emacs, а кто-то vim. Не вижу ничего плохого в наличии отличных инструментов, пусть где-то их функциональность дублируется (eix vs emerge -s, и т.п.); главное, как Вы понимаете, это скорость и удобство выполняемой работы в ОС, и собственно ее разработка. Или я что-то путаю?:-)

Да. Там особая вуду магия передачи открытого сокета от сервера процессу, так что работает. Но со всякими более сложными системами, типа постгреса, уже не все так просто

в чём заключается монструозность?

В устройстве. Она неизбежна при поддержании такой гибкости.

В чем заключается прозрачность? в информативности вывода? или чего-то еще?

В том, насколько понятно пользователю, что происходит когда он запускает этот eselect.

Кто-то любит emacs, а кто-то vim. Не вижу ничего плохого в наличии отличных инструментов, пусть где-то их функциональность дублируется (eix vs emerge -s, и т.п.);

Абсолютно с вами согласен. Кому-то нравится гента, а кому-то — KISS, и ни то, ни другое, не лучше. Просто не надо утверждать, что это совместимые понятия. Каждому своё.

Я думаею если пользователь осилил сборку генты, он имеет представление о том, что происходит. Если это какой-нибудь бинарный калькулейт/сабайон, там подобным должен заниматься майнтейнер => разбирается тоже. Простому смертному вообще не нужно знать про eselect, в бинарных дистрах оно (любой подобный инструмент) должно отрабатывать на уровне пакетного манагера.

Я не утверждал, что совместимые) я просто сказал что инструментарий навроде eselect _не_сложен_для_понимания_

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

Я Fedora'вец, и это всё объясняет. Работает, и хорошо...
Тем временем на russianfedora.ru зловеще предвещают systemd во всех дистрах поголовно.

С трудом, но осилил прочитать всю тему, поэтому с вопросом по systemd обращаюсь к вам.
Подскажите, есть ли возможность проверять те же юниты на предмет ошибок (хотя бы синтаксических), или где можно посмотреть логи работы юнитов (особенно ошибки)?
И еще сильно интересует один вопрос - каким образом смотреть бинарные логи в системах без systemd (напр., если пришлют такой лог). П.С. к systemd пока еще только присматриваюсь, «щупать» не приходилось.

Проверяются юниты так:

systemd --test [--user|--system] --unit=unit-name

Бинарные логи можно распарсить только леннартопарсером. Это их осознанное решение — типа апи к либе стабилен, сам формат - как получится.

На другой тачке именно скопированный бинарный лог можно посмотреть так

journalctl -D /path/to/log [rest-options]

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

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

Проверяются юниты так:

Спасибо, надо будет запомнить. )

journalctl -D /path/to/log [rest-options]

Т.е. для этого на том компе нужно сначала установить пакет systemd (это не всегда возможно). Не радует, причем совсем. (
Но в любом случае спасибо.

Программа с продуманной распределенной архитектурой и четко описаными взаимодействиями - такое в линаксе вообще есть?

Ставь вопрос шире. Такое вообще где-нибудь есть?

journalctl — автономная утилита, которая из не-libc требует liblzma и весит 102кб. Думаю особых проблем вытащить это хоть откуда-нибудь не будет. Если логи кто-то пересылает сознательно, можно их экспортировать в текст. Из коробки оно умеет в т.ч. json и syslog

journalctl — автономная утилита

На сегодняшний день в арче

pkgfile journalctl
core/systemd

Если логи кто-то пересылает сознательно, можно их экспортировать в текст.

Собственно почему я спрашивал. Сейчас, в случае проблем с системой, можно просто попросить человека, чтоб он залил свой /var/log/название_лога на любой сайт обмена текстовыми сообщениями и без проблем посмотреть этот текст прямо из браузера. В случае бинарных логов - не всегда есть возможность сконвертировать их на проблемном компе (например не загружается), ну и остальным для просмотра лога придется делать дополнительные телодвижения. Это беспокоит.

Сейчас, в случае проблем с системой, можно просто попросить человека, чтоб он залил свой /var/log/

а когда-то чтобы очаровать девушку было достаточно врезать ей каменным топором по голове ;)

Постоянно вижу, ЧЯДНТ?

когда ж уже експансия в генточку начнется...

Программа с продуманной распределенной архитектурой и четко описаными взаимодействиями - такое в линаксе вообще есть?

Ставь вопрос шире. Такое вообще где-нибудь есть?

Постоянно вижу, ЧЯДНТ?

Наркотики? Алкоголь? Грибы? Недолеченные душевные болезни?

а когда-то чтобы очаровать девушку было достаточно врезать ей каменным топором по голове ;)

Намекаешь на bsd?