LINUX.ORG.RU

systemd In Action, part 4

 


4

3

И мы опять продолжаем.

В этой части серии мы попытались оценить устойчивость бинарного формата лог-файлов journald к произвольным повреждениям, испытали передачу логов по сети с одной машины на другую (нативным для journald способом), произвели настройку сетевого соединения на тестовой машине с помощью networkd/resolved и, наконец, продемонстрировали работу с D-Bus интерфейсами systemd и вспомогательных демонов (ради чего они, собственно, и были сделаны демонами).

Помимо видеоряда также имеется подробная текстовая аннотация.

Авторы: PaulCarroty, like-all, intelfx.

(В случае проблем с доступом к tlhp.cf также имеется зеркало.)

>>> Подробности

★★★★★

Проверено: Shaman007 ()
Последнее исправление: intelfx (всего исправлений: 1)

Ответ на: комментарий от intelfx

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

P. S.: а могу — такую, что не будет. И ни одна программа размером больше одной машинной инструкции не будет. Такшта херовый принцип.

Это потому, что разработчик из тебя, как из говна пуля.

Deleted
()
Ответ на: комментарий от Deleted

я ничего не предлагал менять, а просто показал статью с образцами кода.

То есть ты даже не отрицаешь, что тупо вякнул не по делу?

anonymous
()
Ответ на: комментарий от Deleted

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

intelfx ★★★★★
() автор топика
Ответ на: комментарий от intelfx

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

Ты чего, обкурился?

Deleted
()
Ответ на: комментарий от Deleted

Ни разу.

Сам посуди. В первом случае зону ответственности можно описать along the lines of «осуществление настройки системы, подготовка её к использованию и обеспечение служебной и вспомогательной функциональности (facilities, хз как по-русски) для работы прикладных программ».

Ну а во втором случае достаточно взять интеловский мануал и скопипастить оттуда описание какой-нибудь инструкции.

Короче, single responsibility principle (без наложения дополнительных ограничений на то, что может являться зоной ответственности) может быть использован для чего угодно.

intelfx ★★★★★
() автор топика
Ответ на: комментарий от intelfx

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

ioway
()
Ответ на: комментарий от ioway

А кто сказал, что systemd (как проект) — это система инициализации?

intelfx ★★★★★
() автор топика
Ответ на: комментарий от anonymous

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

anonymous
()
Ответ на: комментарий от CryAngel

а смысл? скорее кто-то запилит SystemD on a diet который будет лишь инит системой а не системой управления сервисами и процессами компьютера.

anonymous
()
Ответ на: комментарий от alex_the_v

Однако, rsyslog - хоть и весьма зрелая вещь, но крива как моя жизнь. Да и вся архитектура syslog угребищна донельзя, такое ощущение, что придумывали пятиклассники на перемене. Надежное логирование получить в теории невозможно.

Да кому оно нужно. Кого могут интересовать логи в тот момент, когда система стала сбоить и поток логов чуток вырос. Подумаешь, rsyslog просрал пару burst'ов.

grossws
()
Ответ на: комментарий от grossws

Да кому оно нужно. Кого могут интересовать логи

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

Вот похачат тебя, потом к тебе придут злые дядьки из секурити и спросят: «а есть ли логи?» А ты такой: «ля, rsyslog просрал». И досвидос, будешь новую работу искать.

alex_the_v ★★★
()
Ответ на: комментарий от alex_the_v

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

grossws
()
Ответ на: комментарий от grossws

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

alex_the_v ★★★
()
Ответ на: комментарий от anonymous

кто-то запилит SystemD on a diet который будет лишь инит системой а не системой управления сервисами

А нахрен он кому сдался? Те полтора придурка у кого хватило баттхёрта на бессмысленную возню с опциями ./configure, но не достаточно подгорел пукан чтобы свалить на бздю никого не интересуют. А нормальные люди используют все возможности systemd вместо того, чтобы исходить слюнями по поводу того 10 метров у нас бинарник инита весит или ажно 15.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.