LINUX.ORG.RU

systemd 249

 , , , ,


0

1

Новый релиз системного менеджера GNU/Linux — systemd (лицензия GPL-v2+):

  • возможность явного или автоматического выбора из нескольких root разделов в образе диска с помощью параметра --image= в systemd-nspawn, systemd-dissect и других утилитах, работающих с образами дисков

  • новые опциональные параметры IMAGE_VERSION и IMAGE_ID в файле /etc/os-release

  • поддержка build-id и .note.package из ELF в systemd-coredump позволяет явным образом соотнести дамп памяти с конкретным пакетом, из которого был установлен соответствующий бинарник

  • поддержка UUID для событий udev, которая позволяет отслеживать конкретное событие в явном виде

  • документирован сетевой протокол Journal

  • домен «home.arpa» официально добавлен в качестве домена для локальных сетей согласно RFC 8375

  • флаг «grow-file-system» добавлен к спецификации Discoverable Partition

  • поддержка JSON с помощью интерфейса DBus и параметра командной строки в systemd-hostnamed и systemd-networkd. В дальнейшей её планируется распространить на все компоненты systemd

  • автоматическое добавление хэшей паролей в shadow для пользователей systemd-homed

  • поддержка добавления пользователей и групп с помощью конфигурационных файлов в формате JSON в /etc/userdb/, /run/userdb/, /run/host/userdb/ и /usr/lib/userdb/

  • расширение механизма зависимостей с помощью неконфигурируемых автоматических обратных зависимостей (OnSuccessOf для OnSuccess, UpheldBy для Upholds, OnFailureOf для OnFailure и т. п.) для упрощения отслеживания и настройки зависимостей между юнитами

  • по многочисленным просьбам анонимусов с LOR была документирована архитектура systemd

И множество других изменений, исправлений и улучшений.

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

★★★★

Проверено: alpha ()

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

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

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

можно сколько угодно сраться по поводу systemd, но факт того что он win - факт.

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

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

«Опять в мануале по обслуживанию самолёта больше букв, чем в буклете к моему самокату!»

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

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

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

В большинстве дистрибутивов систему инициализирует и делает много чего ещё, не точка зрения, а конкретно системд. Придумываешь какие-то описания, из-за зависти.

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

Хрупкий самолёт, да уж. Ещё и переусложнённый, это какой самолёт чем переусложнён? И да, при чём здесь самок, самолёт и системд. Предлагаю ещё помидор в список добавить.

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

Надеюсь, в конечном итоге S6 покончит с якобы неоспоримыми преимуществами systemD, и корпорастам останется хвастаться только остальным говном (которое большинству и ненужно) systemD, которого нет в S6.

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

О-о-о, эксперты по systemd пробили очередное днище… Ну что же, тогда «как сислог» умеют работать вообще практически все сервисы. Потому что, прикинь, они умеют слать всё в сислог!

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

Ответ неверный

  1. Юнит - systemd-специфичен, при изменениях в systemd (хотя бы изменение опций, используемых в unit-файлах) юниту кирдык

  2. В разных дистрибутивах даже содержимое /etc различно, как ты собрался использовать один и тот же юнит в них? Через libastral.so?

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

Согласно википедии: Операционная система, состоящая из свободного ПО с открытым исходным кодом. В настоящее время Debian GNU/Linux — один из самых популярных и важных дистрибутивов GNU/Linux.

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

Юнит - systemd-специфичен, при изменениях в systemd <…> юниту кирдык

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

В разных дистрибутивах даже содержимое /etc различно, как ты собрался использовать один и тот же юнит в них?

Через шаблонизацию, если юнит действительно зависит от расположения файлов в /etc.

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

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

Ну т.е. они всё-таки были. И твоё «неправда» на самом деле неправда.

Через шаблонизацию, если юнит действительно зависит от расположения файлов в /etc

Т.е. юнит всё-таки дистроспецифичен. А ещё, мой юный друг, открою тебе «страшную» тайну - в разных дистрибутивах различается не только расположение файлов в /etc, но ещё и расположение бинарников. Да что там /etc и бинарники, тот же самый Apache в Debian традиционно отзывается на apache2, а в красношапочных потомках - httpd. Т.е. даже сам юнит называется ПО-РАЗНОМУ! Эксперты systemd такие эксперты…

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

Ну т.е. они всё-таки были.

На практике — обратная совместимость соблюдается в 99.(9)% случаев, т. ч. нет, «при изменениях в systemd» юниту кирдык не будет.

Т.е. юнит всё-таки дистроспецифичен.

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

но ещё и расположение бинарников

То же самое, это всё задаётся на этапе configure и юнит генерируется из общего шаблона.

Да что там /etc и бинарники, тот же самый Apache в Debian традиционно отзывается на apache2, а в красношапочных потомках - httpd. Т.е. даже сам юнит называется ПО-РАЗНОМУ!

Ditto.

Эксперты systemd такие эксперты…

Уважаемый анонимный товарищ, я эти юниты в множество проектов лично законтрибьютил на заре systemd. Наверное, у меня всё-таки побольше опыта.

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

На практике — обратная совместимость соблюдается в 99.(9)% случаев

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

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

4.2

Ditto

Supercalifragilisticexpialidocious

Наверное, у меня всё-таки побольше опыта.

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

Впрочем, ничего нового, эксперты systemd в своём репертуаре…

anonymous ()

systemd, init, upstart, еще какая срань … какая разница? это всё уже давно отжило, в век облаков и всеобщей контейнеризации и виртуализации ничего из этого не используется, так как слишком тяжелое и сложное для простой парадигмы одна виртуалка – одно приложение.

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

С чего это? 99% инит скриптов это неподдерживаемая boilerplate-лапша с копипастами на копипасте и с решениями одних и тех же проблем на разный лад, юниты на порядок проще.

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

юниты на порядок проще

Че, серьезно? Тоесть ты можешь обрабатывать их вручную? Я-то всю сознательную (с момента установки Slackware) жизнь считал, что «лапша скриптов» была заменена мукой unit’ов исключительно затем, чтобы отодвинуть пользователя от непосредственного управления компутером: они на столько сложны, – разбросаны, лишены контекста, не документированы, - что не подлежат ручной обработке в принципе. Это те же конфиги, только сильно измельченные и обфусцированные. Обфусцированные на столько, что они делают systemd незаменимым в управлении системой и в этом – их главное назначение. – Ибо systemd есть инструмент технического узурпирования GNU/Linux, инструмент контроля над ОС, которая уже управляет всеми серверами, военными и научными компьютерами в мире, где власть и деньги гудят по проводам.

Ты мог бы попытаться меня переубедить?

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

Че, серьезно? Тоесть ты можешь обрабатывать их вручную?

Что ты под этим подразумеваешь?

разбросаны, лишены контекста, ….

Ты не понимаешь о чем пишешь

Ты мог бы попытаться меня переубедить?

Зачем мне это делать? Живи в невежестве, мне все равно.

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

Что ты под этим подразумеваешь?

Ты изучаешь русский недавно? «Вручную» на Могучем означает «делать руками», тоесть без посредства автоматики.

Ты не понимаешь о чем пишешь

Это точно? А может ты не понимаешь очем читаешь?

Зачем мне это делать?

Может быть затем, чтобы обосновать свои взгляды, чтобы не выглядеть голословным сотрясателем воздуха в приличном обществе; чтобы, наконец, не прослыть слепо верующим в рекламные проспекты от RedHat – верующим в их писания больше чем собственным глазам…

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

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

Ты изучаешь русский недавно? «Вручную» на Могучем означает «делать руками», тоесть без посредства автоматики.

Юниты это, внезапно, текстовые файлы, которые можно редактировать в текстовом редакторе.

Может быть затем, чтобы обосновать свои взгляды,

Я выше обосновал. Читай про выше boilerplate в так называемых «традиционных» инитах.

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

Ты изучаешь русский недавно? «Вручную» на Могучем означает «делать руками», тоесть без посредства автоматики.

Это шикарно. Последнее Более ушиюлено на голову придумать сложнее.

Обвинять систему автоматизации управления в том, что она автоматизирует, и хотеть делать все «вручную».

Да тебе аббак нужен, а не компьютер. В уме, я думаю, ты считать не осилишь.

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

которые можно редактировать в текстовом редакторе.

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

Конфиг, порубленый на куски unint’ов уже не редактируем и не читаем человеком, зато остается вполне читаемым, понимаемым, редактируемым для автоматики. Я не прав?

Или ты станешь отрицать, что ’unit’ы это те же самые конфиги только мелкоизмельченные и пермешанные? Ты только что подтвердил что это те же «текстовые файлы». Ок. Форма та же, ты это признал. Содержание, очевидно - то же: те же самые пары переменная=значение. Или чуть более сложные сентенции.

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

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

И того, сравнивая конфиги и юниты мы имеем:

    • тот же самый текстовый формат
    • то же самое по сути содержание
    • но разную организацию

Что дает эта разница? Она усложняет или упрощает систему? Ответы: дает она только незаменимость автоматики для обработки фрагментированных и обфусцированных конфигов под названием unit’ы, из чего следует второй ответ: она только лишь усложняет систему, добавляя в нее откровенно лишние сущности.

Это голая бухгалтения. А теперь более сложная логика мотивов: зачем? Зачем вкладывать человекочасы, между прочим хорошо оплачиваемые, в «альтруистическое»* усложнение** и без того хорошо работающей (пишу со Slackware 14.2. systemd нет, брата тоже, и я этому рад) системы? Я напомню, что речь идет о GNU/Linux (или может уже правильнее systemd/linux; не пора ли провети отличие?), которая правит миром – позволю себе смелость так выразиться.

Читай про выше boilerplate в так называемых «традиционных» инитах.

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

Чукча писатель. Я глазам верю больше чем тому что на заборах пишут. Когда я заглянул в unit’ы и убедился что все, что линуксу дал systemd это незаменимость systemd, я понял зачем он существует. А ты, – еще не понял?

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

Хомяки так же не освоили идеи, что «много велосипедов» называется «конкуренция». И только конкуренция гарантирует качество – а не факт взымания бабла за софт. Макрософт берет бабло но в нем нет внутренней конкуренции, и его велосипеды всегда в одном экземпляре: пользователь жрет безропотно все чем кормят.

Освятил тред светом истины. Могу спать спокойно.

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

Обвинять систему автоматизации управления в том, что она автоматизирует

Она усложняет, прежде всего. «Автоматизация», как и навязываемые здесь «инструмент автоматизации» есть средство, а не цель. Ибо автоматизация позволяет внедрить в систему троян, предлагая его как средство автоматизации.

Я уже в соседнем треде попробовал один пример.

Вот как допускается/запрещается запуск того или иного демона в sytemd/Linux? – это делается сложными челобитными к systemd, не так ли?

А как это делается в GNU/Linux, например Slackware? – Тупо chmod на соответствующий стартовый скрипт в /etc/rc.d – Кстати названия всех скриптов самообъясняющие. Сами скрпиты полны исчерпывающей справки.

Ну так в связи с вышесказанным вопрос: зачем?

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

пользователь жрет безропотно все чем кормят.

Кстати «пользователи» systemd (в кавычках потому что пользуют их а не они) тоже жрут все чем кормят. Уже не соскочат. Или еще можно?

Csandriel_x64 ()