LINUX.ORG.RU

Февральские тезисы о планах развития systemd

 ,


2

4

На прошедшей конференции FOSDEM Леннарт Поттеринг огласил некоторые перспективы развития systemd:

  • Интеграция в systemd загрузчика gummiboot, поддерживающего технологию UEFI Secure Boot.
  • machined — менеджер регистрации виртуальных машин, спроектированный под впечатлением от Solaris Zones.
  • В подсистеме nspawn и смежных с ней ожидается больше возможностей для управления контейнерами, например, journald сможет собирать логи не только с хоста, но и с контейнеров.
  • Уже в следующей версии ожидается улучшенная поддержка Btrfs (подразделы и снапшоты Btrfs планируется использовать для изоляции отдельных приложений).
  • Поддержка HiDPI и Юникода в consoled.
  • Сервис-ориентированный фаерволл: можно будет задавать правила в привязке не к номерам портов, а к именам процессов.
  • Отпадёт нужда указывать путь к юниту для systemctl-cat; systemctl-edit позволит редактировать юниты и после сохранения изменений автоматически перезапускать соответствующие сервисы.
  • nss-getmyhostname — функция для получения имени хоста на stateless-системах.
  • Утилита ping gateway позволит автоматически определить все доступные сетевые интерфейсы и проверить их статус командой ping.
  • Развитие networkd и собственной библиотеки для работы с DHCP (совместимой с dhcpv4 и dhcpv6).
  • Комбинирование nspawn и networkd позволит легко конфигурировать сеть для контейнеров.
  • Создание средств для широкого системного аудита, интегрированных в journald. Например, станет возможным логировать все системные вызовы к файлу /etc/passwd.
  • Движение в сторону stateless-систем, у которых только /usr доступен на чтение и запись, а /etc и /var будут автоматически заполняться systemd.
  • journald-remoting — удалённая работа логгера через HTTP. Поддержка в journald моделей pull и push: при pull выполняется запрос HTTP GET для получения потока JSON, а при push данные передаются в другой экземпляр journald при помощи HTTP POST.
  • Возможность определения для сервисов минимальных пространств имён и sandbox-изоляции: доступ к некоторым разделам и каталогам только на чтение, сокрытие устройств в /dev, приватный /tmp для каждого сервиса, и др.
  • timesyncd в качестве замены ntpd.
  • Автоматическое определение разделов GPT, не нуждающееся в указании их в fstab.
  • Поддержка перезапуска демонов без потери их состояния (посредством сохранения оного на диск).

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



Проверено: Shaman007 ()
Последнее исправление: ymn (всего исправлений: 1)
Ответ на: комментарий от targitaj

Овощ в негодовании! Газы выходят неконтролируемо!

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

«Отправить бы их во вселенную, в которой правила бы менялись произвольно, я бы на них посмотрел»

Посмотри в зеркало. У Вселенной нет никаких правил, то, что ты называешь «принципами» - лишь эпизодическое отражение реальных процессов в очень ограниченном временем и пространством участке Вселенной.

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

Уже 10 раз говорили, что соответствующий сервис для SystemDick не аналогичен этому скрипту поскольку много чего не делает, пропускает. С такими проблемами к врачу надо бы.

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

Чего он не делает? Это тебе к врачу надо, на принудительное разожирение.

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

Эта «программа» пишется методом копипаста и замены названия запускаемого бинарника в большинстве случаев. Ужас-ужас, как сложно

У хороших программистов такое считается моветоном.

debugger ★★★★★
()
Ответ на: Да, похоже на то. от Moisha_Liberman

Ага, скоро полюса этого мира поменяются, и Win10 станет тем, что мы любили, в то время как Поттеринг превратит наш мирок в ад и погибель. (:

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

поциент уже палился ранее на лжи и троллинге (условный запуск в зависимости от кода возврата), не воспринимай серьёзно его.

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

О, да у тебя стек дискуссии вообще отсутствует :] Теперь понятно, почему ты меня лжецом считаешь. Напомню:

Лучше я всем расскажу

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от targitaj

Ндаааааааа.....

Очень содержательный у вас комментарий. Очень умный

Deleted
()
Ответ на: Видимо. от Moisha_Liberman

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

Сказать-то что хотел? Если тебе в пердак что-то вставили, то это честное слово не я.

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

Просто кое-кто уже во вкус вошел.

Ну ты пересиль себя как-нибудь - нельзя же всё время жрать говно.

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

Не надо его расстраивать. Чел работает по программе systemd outreachy - говноеды там представлены в малых количествах. Так от линукса отвернутся все дегенераты, с чем мы останемся?

anonymous
()

Итого, небольшой вывод.

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

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

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

5-й приверженец systemd, не столь ярый и более адекватный, содержательных аргументов привести не смог. По отношению с runit, systemd выступает в роли той самой «космической ручки за миллион долларов», которую упоминал ранее аноним.

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

- я таки настаиваю, что дистрописатели СНАЧАЛА загадили init, ТЕПЕРЬ делают решительно новый инит.

Дак с этим я не спорю. Но где вы найдете дистрописателей, которые не будут гадить инит? ИМХО, если гадят, надо сделать так, что бы гадить было сложнее.

http://www.slackbuilds.org/mirror/slackware/slackware-14.0/source/n/bind/rc.bind
# Load command defaults:
if [ -f /etc/default/named ] ; then . /etc/default/named ; fi
if [ -f /etc/default/rndc ] ; then . /etc/default/rndc ; fi

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


https://svnweb.freebsd.org/base/stable/7/etc/rc.d/named?revision=221222&v...

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

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

5-й приверженец systemd, не столь ярый и более адекватный, содержательных аргументов привести не смог. По отношению с runit, systemd выступает в роли той самой «космической ручки за миллион долларов», которую упоминал ранее аноним.

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

Что-же касается runit, мы-же вроде сравнивали системд с sysvinit?
Видишь-ли, у рунит таки есть недостатки - банальное неумение cgroups, по прежнему активное использование шелл-скриптов (если насрать можно - насрут)...
Если добавить поддержку cgroups - отвалится кроссплатформенность. Если убрать шелл-скрипты, заменив их на ини-файлы - получится http://freedesktop.org/wiki/Software/systemd/MinimalBuilds/

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

По отношению с runit, systemd выступает в роли той самой «космической ручки за миллион долларов», которую упоминал ранее аноним.

Контроль над зависимостями яля рунит:

#!/bin/sh
svwaitup 3 /service/tinydns /service/dnscache || exit 1
exec /example/service/startup

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

Переход между ранлевелами:

If you really need runlevels, here is an example script for switching to runlevel 3 running implicit selected services, telinit3.sh:

#!/bin/sh
( cd /service
for i in *; do
case $i in

# selected services:
getty-tty1 |\
tinydns |\
dnscache |\
sshd |\
qmail-send |\
qmail-smtpd )

svc -u $i
;;
# stop all others
*)
echo svc -d $i
;;
esac
done
)
exit 0


Да ну, нафиг. Дистроделы реализуя нужные им функции такой срач разведут в этом runit... В общем, разницы с sysvinit не будет никакой.

kir2yar
()
Последнее исправление: kir2yar (всего исправлений: 1)
Ответ на: комментарий от kir2yar

Что-же касается runit, мы-же вроде сравнивали системд с sysvinit?

Так это вы сравнивали. Производится целенаправленная подмена понятий.

Тезис: systemd не реализует ни одной функции менеджмента демонов, которая либо не решалась ранее без него, либо решить которую без него невозможно просто минимальной допилкой существующих решений.

Ваш аргумент: sysvinit - отстой.

Отстой, ок. Это опровергает тезис? Не опровергает.

Видишь-ли, у рунит таки есть недостатки - банальное неумение cgroups <...>
Если добавить поддержку cgroups - отвалится кроссплатформенность

Я ж и говорю, в архитектуру надо уметь. С какой стати она отвалится? Добавить поддержку изоляции и/или контейнеров можно множеством разных способов:

  • Директивами условной компиляции: #if платформа_поддерживает_такое_то_средство_изоляции...
  • Декларировав plugin API и подгружая реализацию из разделяемой библиотеки.
  • Декларировав протокол для работы со службой обеспечения изоляции через unix-сокет.
  • Просто перенаправляя все exec через указанную в настройках команду, которая сама разберётся с изоляцией.

Это надо еще разбираться, разумеется, какое из этих решений предпочтительно, но НИ ОДНО из них не ломает кросплатформенность.

Или вы полагаете, что си-группы — какая-то магическая штука по типу «внутре у ней неонка»? Или нет других систем изоляции? В том числе, на других платформах/ядрах?

по прежнему активное использование шелл-скриптов (если насрать можно - насрут)...
Если убрать шелл-скрипты, заменив их на ини-файлы

У вас, во-первых, магическая боязнь шелл-скриптов. Говнокод на sh ничем принципиально не хуже говнокода на питоне, окамле или си. Говнокодить можно на любом ЯП. А вот по некоторым параметрам он даже лучше: это универсальный язык, с которым знакомы все специалисты. А вот с питоном знакомы отнюдь не все.

Во-вторых, самому runit совершенно перпендикулярно, какие файлы он вызывает. Если вашему демону не требуется ни дополнительных шагов инициализации перед запуском, ни опций, просто сделайте ./run симлинком на нужный бинарник.

В-третьих, что именно вы собрались заменять на «ини-файлы»? Вы на полном серьёзе считаете, что

mkdir -p /run/бла-бла-бла && exec /usr/sbin/бла-бла-бла-d
-- это плохо и опасно, а
[Servise]
CoolOptionMkDirP=/run/бла-бла-бла
Exec=/usr/sbin/бла-бла-бла-d
-- это модно, стильно и безопасно?

Нет, правда? А давайте действительно засунем внутрь менеджера демонов весь coreutils + util-linux, при этом для каждого сочетания команды и ключа придумав свой CoolOption?

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

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

Разумеется. Именно технологично: всё разбито на уровням абстракции.

подмонтироваться NFS-шара, слушает-ли кто сокет, есть-ли устройство

Да-да, именно проверки на всё это и нужно засунуть в PID 1. И как мы только жили без всего этого?

Еще не забыть добавить такие проверки как: доменное имя успешно резолвится, адрес пингуется, dbus-имя доступно, dbus-уведомление получено, луна в Овне, солнце в Раке...

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

В общем, разницы с sysvinit не будет никакой.

Для вас ни в чем нет разницы, если это не systemd. :)

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

Собственно, суть проста:

Начав засовывать условия запуска в PID1, где именно вы планируете остановиться? Хорошенько подумайте над этим вопросом, потому что потенциальных условий бесконечное количество, а объём кода, который вы сможете подерживать, не скатываясь в говнокод — конечен и очень даже невелик.

Вот Поттеринг остановиться не смог, как мы сейчас видим. А ведь еще 3 или 4 года назад умные люди предвидели такое развитие событий.

«У нас было 2 пакета травы, 75 таблеток мескалина, 5 упаковок кислоты, пол солонки кокаина и целое множество транквилизаторов всех сортов и расцветок, а также текила, ром, ящик пива, пинта чистого эфира и амилнитрит. Не то, что бы это был необходимый запас для поездки. Но если начал собирать дурь, становится трудно остановиться. Единственное что вызывало у меня опасение — это эфир. Ничто в мире не бывает более беспомощным, безответственным и порочным, чем эфирные зомби. Я знал, что рано или поздно мы перейдем и на эту дрянь.»

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

Да ну, нафиг. Дистроделы реализуя нужные им функции такой срач разведут в этом runit... В общем, разницы с sysvinit не будет никакой.

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

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

Тезис: systemd не реализует ни одной функции менеджмента демонов, которая либо не решалась ранее без него,

Дак, современные компьютеры не решают ни одной задачи, которую не могла-бы решить машина Тьюринга. Весь вопрос в том, как решает. Удобство тоже ценная штука. Встроенные функции реализуют то, что иначе-бы делали дистроделы. Может они хорошие спецы по линуксам, но судя по аду в /etc/init.d дебиана, прогеры они не столь-же хорошие.


Я ж и говорю, в архитектуру надо уметь. С какой стати она отвалится? Добавить поддержку изоляции и/или контейнеров можно множеством разных способов:

Ок. в рунит достаточно программистов-линуксойдов? Или его пилит в основном unix-сообщество? Сомневаюсь, что юниксойду будет интересно добавлять линукс-спецефичные фичи.

Я ж и говорю, в архитектуру надо уметь. С какой стати она отвалится? Добавить поддержку изоляции и/или контейнеров можно множеством разных способов:

Ну, если честно, последний раз я на сях писал еще в школе. Потом как-то так получилось, что я все пишу на скриптовых языках. Я-ж админ, а не прогер.
И баш - далеко не конфетка. Честно, даже lua читабельней.
А за конструкции в init-скриптах по типу
if [ -f /etc/default/named ] - надо руки вырывать. Оно конечно правильно, работать будет. Но не читаемо. Что, руки отвалятся написать четыре лишних буквы? Или это боязнь слова «test»?

У вас, во-первых, магическая боязнь шелл-скриптов. Говнокод на sh ничем принципиально не хуже говнокода на питоне, окамле или си. Говнокодить можно на любом ЯП. А вот по некоторым параметрам он даже лучше: это универсальный язык, с которым знакомы все специалисты. А вот с питоном знакомы отнюдь не все.

Да не боюсь я шеллскриптов. Я даже прикола ради написал на баше простой веб-сервис. ) Банальная формочка для отпуска, куда пользак пишет фио и дату, а на выходе получает несколько pdf-файлов, оформленных по правилам нашего внутреннего документооборота.
Работает, кушать не просит, однако меня теперь пилят что бы я и другие шаблоны реализовал.

Вообще использовать ЯП для конфигурации - не самый лучший вариант. Он гибкий, но ошибок и косяков всплывает масса. От проблем с созданиями инстансов сервисов, проблем с chroot (реально, настолько базовая вещь, что давно должна быть реализована в каждом ините), проблем с заворотами в cgroups...

Во-вторых, самому runit совершенно перпендикулярно, какие файлы он вызывает. Если вашему демону не требуется ни дополнительных шагов инициализации перед запуском, ни опций, просто сделайте ./run симлинком на нужный бинарник.

Минимальный юнит на системд состоит из имени, описания и ExecStart.

rm -rf /var/run/mycoolservice

 — это плохо и опасно, а

Ибо одна опечатка, и каюк. Не делать опечаток? Да я и не делаю. А вот за остальных - не поручусь.

А вот добавить в /etc/tmpfiles.d
d /var/run/mycoolservice 0755 example_user - -
(При старте компа директория автоматом создается/очищается. С проверками, так-что лишнего не грохнет)
Уже намного лучше.


Нет, правда? А давайте действительно засунем внутрь менеджера демонов весь coreutils + util-linux, при этом для каждого сочетания команды и ключа придумав свой CoolOption?

Вообще-то в системд, самом системд, а не его «плагинах», реализуют функциональность, которая нужна 95% демонов. Если 95% инит-скриптов проверяют на существование разные файлы - значит в системд должна быть реализована директива для проверки на существование файла/директории. Если в если большому числу демонов нужен chroot, значит его и в системд нужно делать.
Никто не будет реализовывать функцию, которая нужна одному демону. Но обязательно будут реализовывать функции, которые нужны куче демонов.
Это разумный подход.

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

Да-да, именно проверки на всё это и нужно засунуть в PID 1.

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

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

Начав засовывать условия запуска в PID1

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

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

Вас послушать, так надо выпилить все *sh скрипты из системы, так как они могут содержать плохой код.

root@ws-50:~# find / -name "*\.sh"| wc -l
1095
Это не считая исполняемых shell-файлов без *.sh
Новые реализации - это хорошо и правильно, они должны быть, но не в ущерб стандартным, десятилетиями отлаженным, сущностям.
Даже если амбиции не позволяют человеку остановиться и перестать переписывать все подряд, пилил бы существующее. Нет, надо свое казино, но такое чтобы вверх ногами.

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

Вас послушать, так надо выпилить все *sh скрипты из системы, так как они могут содержать плохой код.

Ну все - не все, а вот из критических подсистем - было-бы не плохо.

Новые реализации - это хорошо и правильно, они должны быть, но не в ущерб стандартным, десятилетиями отлаженным, сущностям.

И где тут ущерб?
На системд перешли только те, кто хотел. Остальные сидят на других инитах. Добровольно, заметь. По моему, в приказном порядке системд появился только в федоре. Но федора - это тестовая площадка для редхета, там многие вещи так тестируются.
В остальных дистрах - решали их мейнтенеры/хозяева.
Ущерб в том, что теперь у классических инитов есть конкурент? Дак это польза! Пора решать проблемы, которые накопились у классических инит-систем.

Вообще, можешь объяснить, как одна опенсорс-программа может навредить другой?

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

Вообще, можешь объяснить, как одна опенсорс-программа может навредить другой?

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

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

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

Ну, во первых это честная победа. Конкуренция. Во вторых, тут кто-то хвастался что сложность инит-скрипта - 3 копейки. )

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

Вообще-то в системд, самом системд, а не его «плагинах», реализуют функциональность, которая нужна 95% демонов

вранье.

год назад опций юнита было чуть более 40, сейчас около 70...

через пару лет за сотню перевалит...

Ну дак вопрос...

Эти твои 95% были год назад, сегодня или в светлом будущем?

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

Ну, во первых это честная победа. Конкуренция.

Разработчики gnome не могут отвязаться от systemd, Redhat внедрил не спрашивая остальных, хотя да, он был не обязан это делать.
Все rpm-based дистрибутивы будут делать так же, так как ток течет по меньшему сопротивлению.

Во вторых, тут кто-то хвастался что сложность инит-скрипта - 3 копейки.

То не моё.
Все зависит от конкретного пишушего персонажа.

smith
()

systemd своей монстроузорностью стал чем-то напоминать wp или owncloud, обвешанные плагинами...

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

какое же у тебя все-таки рыло противное. Утром ЛОР открываешь смотришь на твое мерзкое, недовольное рыло и настроение падает в ноль.

Тьфу!

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

Разработчики gnome не могут отвязаться от systemd, Redhat внедрил не спрашивая остальных, хотя да, он был не обязан это делать.

...после того, как в 2012году консолькит оказался заброшен.
И как гном работает под фряхой?
В любом случае, разрабы гнома не привязаны к системд, они привязаны к API, который предоставляет logind через dbus.
Описание вот: http://www.freedesktop.org/wiki/Software/systemd/logind/
Реализовать заглушку - дело пяти минут. Реализовать функционал - уже несколько интересней, но вполне реально.

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

То не моё.
Все зависит от конкретного пишушего персонажа.

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

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

Ну, во первых это честная победа. Конкуренция

Ага честная...

Если бы инит vs инит

А тут

https://t.co/u4dcFR7dfV

Получается кроме поддержки самого инита (что не сложно), надо решать со всем что что сожрал системд...

Причем, мультфильму пора бы уже продолжение делать...

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

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

ты признаешь, что твое «95%» это как «146%» чурова?

Пожалуй - с анонимами общаться таки не стоит. Тупые они.

95% - цель, которая сейчас реализована гдет на треть/две трети.

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

Реализовать заглушку - дело пяти минут. Реализовать функционал - уже несколько интересней

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


В этом то и проблема...

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

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

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

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

В том-то и дело, что решает крайне неудобно.

Встроенные функции реализуют то, что иначе-бы делали дистроделы. Может они хорошие спецы по линуксам, но судя по аду в /etc/init.d дебиана, прогеры они не столь-же хорошие.

Я вообще не верю в способности «дистроделов» от коммунити. Дистрибутив, как правило, держится на 2-3 специалистах, которые задают уровень. Если они теряют интерес или уходят, дистрибутив теряет смысл. Если взять неорганизованную массу людей и посадить делать дистрибутив, то максимально разумное действие, которое они смогут осуществить — копировать решения редхата. Так что уровень задаёт РХ. А вот какой уровень она задаёт? Уровень говнокода. Вы искренне радуетесь, что помойка переместилась из /etc/init.d в /usr/lib/systemd. Так суть-то не изменилась. Более того, «уж если РХ можно говнокодить, то нам и подавно». Так что ожидайте новых порций говнокода от дистроделов. Квалификация не нужна, грабь-убивай-пиши-юнит-файлы.

Ок. в рунит достаточно программистов-линуксойдов? Или его пилит в основном unix-сообщество? Сомневаюсь, что юниксойду будет интересно добавлять линукс-спецефичные фичи.

Да никто его практически не пилит. :) «Пилить» ( == усиленно разрабатывать) runit — всё равно что всерьёз пилить какой-нибудь ls. Утилита написана, она работает, задачи, для которых была создана, полностью реализует.

Вот я могу сейчас взять сорцы и запилить туда недостающую фичу которую мы ранее обсуждали: аналог этого PreExec, или как оно там в unit-файлах зовётся. Это займёт у меня... ну час на ознакомление с кодом, полчаса-час на реализацию, пару часов, чтобы всё как следует оформить, протестировать и выложить в публичный git. Может часом меньше, может больше, зависит от того, что собой представляют исходники.

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

Ну, если честно, последний раз я на сях писал еще в школе. Потом как-то так получилось, что я все пишу на скриптовых языках. Я-ж админ, а не прогер.
И баш - далеко не конфетка. Честно, даже lua читабельней.
А за конструкции в init-скриптах по типу
if [ -f /etc/default/named ] - надо руки вырывать. Оно конечно правильно, работать будет. Но не читаемо. Что, руки отвалятся написать четыре лишних буквы? Или это боязнь слова «test»?

Читабельность находится где-то в конце списка важных свойств языка. На первом месте стоят распространённость и количество специалистов. К тому же, вы сравниваете «комод и гладиолоус»: ЯП и настроечный файл в формате ключ=значение. Комод конечно тяжелее гладиолуса, но в гладиолус вещи не сложишь. Как-то глупо их сравнивать.

Что касается if [ -f /etc/default/named ], вы просто не владеете этим ЯП, и вот всё. Обычная и понятная любому знакомому с sh конструкция. Придуманная как раз ДЛЯ ЧИТАБЕЛЬНОСТИ, чтобы скобки чётко оформляли условие.

Вообще использовать ЯП для конфигурации - не самый лучший вариант. Он гибкий, но ошибок и косяков всплывает масса. От проблем с созданиями инстансов сервисов, проблем с chroot (реально, настолько базовая вещь, что давно должна быть реализована в каждом ините), проблем с заворотами в cgroups...

Так проблема не в самих ини-файлах, а в том, что всё это слеплено в кучу и засунуто в один процесс. Он и лошадь, он и бык, он и баба, и мужик. Так дела не делаются. Полноценный тьюринг-полный ЯП много где лишний. В некоторых случаях вообще имеет смысл выпилливать sh из окружения для максимального уменьшения поверхности атаки. Но systemd эту проблему никак не решает. Он не про безопасность. (И ксттаи говоря, он и не про производительность, и не про сервера, и не про десктопы и про прочее-всякое: последовательно сторонники сдают все позиции. Был журналд «надёжный и быстрый логгер», теперь стал «решение для локалхоста». И тому подобное.)

Допустим, у нас есть простейший менеджер демонов со своим примитивным конфигом, и есть простейший менеджер изоляции со своим примитивным конфигом. (Ну или менеджер сетевых подключений, сетевых шар, чего угодно.) Мы из них как из кубиков составляем продукт, заполняя конфиги нужными значениями. sh в этом случае может вообще отсутствовать на машине. Но это специализированное решение под специализированные нужды. Для систем общего назначения оно не роялит. Админ должен иметь возможность заточить систему общего назначения под свои нужды произвольным образом, а для этого ему нужен полный контроль над конфигурацией. А полный контроль — это тьюринг-полный язык. То есть sh (или аналог) всё равно должен быть на машине. И здесь уже не sh оказывается лишней сущностью, а systemd со своими ini-файлами. Ведь зачем админу плодить сущности? Админ существо практичное и ленивое.

rm -rf /var/run/mycoolservice
— это плохо и опасно
Ибо одна опечатка, и каюк. Не делать опечаток? Да я и не делаю. А вот за остальных - не поручусь.

Так ведь и в sh есть возможность защититься от таких опечаток. Написать стандартные библиотеки алгоритмов, заставить всех ими пользоваться... ага. Заставьте, как же. :) С чего вы взяли, что безопасными возможностями systemd будет заставить пользоваться проще, чем какими-либо иными?

А вот добавить в /etc/tmpfiles.d
d /var/run/mycoolservice 0755 example_user - -
(При старте компа директория автоматом создается/очищается. С проверками, так-что лишнего не грохнет)
Уже намного лучше.

Замечательно. Хорошая вещь. А гвоздями к systemd прибивать зачем? Код для обработки tmpfiles.d можно за вечер написать на любом ЯП: хоть на Си, хоть на sh, хоть на питоне.

Смотрите, какой разный может быть подход:

  • Есть проблема такая-то, такая-то и такая-то, не имеющие общепринятых способов решения. Мы подумали, что их можно решать так-то и так-то, и это дело хорошо бы стандартизировать. Вот описание формата конфига, а вот наша реализация. Конфиг и реализацию будут внедрены в следующую версию нашего дистрибутива. Мы предлагаем всем заинтересованным лицам воспользоваться нашим решением.
  • Есть проблема такая-то, такая-то и такая-то, не имеющие общепринятых способов решения. Но есть Систем-Ку! Систем-Ку может решать множество разных проблем, и а сегодняшего дня еще и эти перечисленные проблемы, потому что с версии 100500 мы включили в него наше супер-решение этих проблем! Используйте Систем-Ку, Систем-Ку решит все ваши проблемы!

Ничего не напоминает? Ни о чем не предостерегает?

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

ты признаешь, что твое «95%» это как «146%» чурова?
Пожалуй - с анонимами общаться таки не стоит. Тупые они.

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

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

Фанбои системд не только патологические вруны, но и быдлованы не умеющие себя держать в руках

Ещё они латентные геи!

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

В пиде1 там только необходимое. Остальное - вызывается и реализовывается в других процессах.

Логически это одна сущность. PID1 systemd бессмысленен без обвязки, а обвязка бессмыслена без использования PID1 systemd.

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