systemd 246

Вот это «включение второго продукта» - уже является фактом вендорлока.

Нет, не является.

windows10 ★★ (02.08.20 19:39:32)

Вообще виндузятники, плачущиеся про вендорлок, это что-то с чем-то - уж чья бы корова мычала :-D

По сути работы для мэйнтейнеров убавилось. Для админов тоже.

Чёрт, неужели даже этот что-то понял?

мнение адекватов не имеет значения

Фух, показалось :-D :-D :-D

systemd - это продукт, а не поставщик. Поставщик - redhat, к примеру.

Поэтому если он тебе не нравится, ты всегда можешь нанять контрактора, чтобы тебе что-то подточили. Поэтому open source (особенно gpl) не может быть завендорлочнен по определению: ты можешь сменить поставщика оставшись с теми же продуктом.

Это все равно, что жаловаться, что сейчас вендорлок на бетон в строительстве.

Да лень там читать и искать. Может завтра…

Б-ха-ха :-D :-D :-D

Скажи проще - Линуксу не нужны пользователи.

Такие как ты? Разумеется не нужны. Чем скорее вы свалите обратно на винду вместе с вашим апломбом, инфантильными требованиями и необоснованными претензиями - тем лучше.

Я попробую угадать!

Это признак пидораса! Тоненький такой манерный смех.

Примеры чего именно, ув. анонимный?

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

Посмотрел, как ты не разводит демагогию в 3-4 первых комментах. И кроме «уже объяснил тыщу раз что я сам пророк правды» и навыхохленные ответы на достаточно, конкретные доводы — не одного аргумента или вменяемого ответа. Я тоже так умею, уже тысячи людей сказали и дали доводы, что это виндоподобный монолитный кусок говна. Все и так ясно, хочешь кушать — кушай молча, а то подтекает, когда рот открываешь.

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

Все 9 экранов срача не осилил, но основную конву просёк. Что тут вообще происходит? Кто-то говорит, что удев отлично работает и без системд… Но тогда почему вот это:

$ dpkg-query -L systemd |grep udev
/lib/systemd/system/initrd-udevadm-cleanup-db.service
/lib/udev
/lib/udev/rules.d
/lib/udev/rules.d/70-uaccess.rules
/lib/udev/rules.d/71-seat.rules
/lib/udev/rules.d/73-seat-late.rules
/lib/udev/rules.d/99-systemd.rules

Почему пакет «системд» сам поставляет основные удевные рули? Почему не сам удев, или, к примеру, systemd-logind тот же? Или почему я вижу вот это в контролах пакета удев-237-3ubuntu10.41:

Breaks: systemd (<< 233-4)
Replaces: systemd (<< 233-4)

Так он точно никак к системд не привязан, или не точно?

Тут говорят, что тулзы системд отлично без него работают… А никто не потрудится объяснить, зачем же тогда каноникл столько лет пилил ситемд-шим? Разве не для того, чтобы использовать его тулы без него самого, да так и не взлетело?

Тут говорят, что, дескать, гномы и прочие сами выбрали зависеть от системд… Но ведь это ж враньё полнейшее! Они хотят зависеть лишь от некоторых «его» компонентов (почему они вообще должны быть именно его компонентами, а не отдельными тулами - вопрос отдельный), таких, как systemd-logind например. Но не от самого системд! Системд всегда возвращается по зависимостям, сколько бы его ни выгребали - это факт известный. Но вы что, нарочно скрываете тот факт, что возвращается он не по прямым зависимостям от приложений, а по косвенным, через собственные компоненты, которые, типа, «отлично могут работать и без него»?

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

Короче, дело к ночи… Что-то тут не то у вас происходит. Дурите неопытный молодняк?

Линукс в своём развитии дошёл до состояния, когда его можно массово использовать. А для массового использования нужны зауряд-админы, которые только и умеют по инструкции накатать тривиальный декларатор для системд, а не программировать на баше. Накой такие оверквалифайд специалисты? Им денег надо платить…

Аналогично и с прочими частями, типа нетворк менеджера. Да, оно внутри усложнилось, но зато снаружи одна кнопень - вкл/выкл. И можно посадить за 3,5 копейки индуса дёргать рукоятку туда сюда.

Используется в двух сертифицированных юниксах.

Сертифицированные Unix™ (аппаратные платформы поскипаны):

Apple Inc.: macOS version 10.15 Catalina on Intel-based Mac computers

IBM Corporation: AIX version 7, AIX 6 Operating System V6.1.2 with SP1 or later, AIX 5L for POWER V5.3 dated 7-2006 or later

Cemprus LLC: DNCP Series running FTX Release 3

Hewlett Packard Enterprise: HP-UX 11i V3 Release B.11.31 or later

Huawei Technology Co., Ltd: Huawei EulerOS 2.0

IBM Corporation: z/OS V2R1 or later with: z/OS V2R1 or later

The SCO Group, Inc.: UnixWare ® 7.1.3 and later

The SCO Group, Inc.: SCO OpenServer Release 5 and OpenServer Release 6

Unix™, который использует systemd — это EulerOS, это точно. Но я что-то пропустил, а кто тот второй Unix™, который использует systemd?

Эта хреновина перестала рожать по 100 лет не так уж и давно

Я вот как-то затрудняюсь даже - это ты опять в грамматику не смог или ты столь витиевато пытался пошутить?

Это нарушение основополагающего принципа вселенной

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

Очевидно, что это насильственная инвазия, а не выбор.

А-ха-ха :-D :-D :-D

Чёрт, если бы тебя не было - тебя стоило бы выдумать! Эти твои попытки использовать слова, которые тебе кажутся умными потому что ты толком не знаешь что они значат - гомерически смешны :-D :-D :-D

То ечть на серверах в продакшене, ты логи собираешь journalctl и так же их читаешь? Или ты хочешь сказать, что нет альтернативных решений, не привязанных к инит системы? :facepalm: Домохозяйка локалхоста это ты, когда серьезные люди разговаривают, фартук сними с рисунком хомячка

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

Берёшь busybox или тсандартную поставку любого Linux и находишь там установленным свой JQuery

Блин, я не могу! Прелесть какая дурочка :-D :-D :-D

Не говорите ему! Грех такой ржачь портить :)

Это не он, это RHEL 8.

Ничего не понимаю. Они там что-то через плагины хитрое завернули?

Что они такое пытаются сделать что systemd-networkd им мало? Ну не ради wi-fi же в самом деле.

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

гномы и прочие сами выбрали зависеть от системд… Но ведь это ж враньё полнейшее!

Это чистая правда.

Но вы что, нарочно скрываете тот факт, что возвращается он не по прямым зависимостям от приложений, а по косвенным

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

И это я молчу

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

Ё-моё! Настолько адекватный комментарий в теме про systemd от чувака с бздшным чёртом на аватарке - это реально неожиданность. Вот так переобщаешься с хейтерами и невольно забываешь что адекватные люди есть везде. Мерси за напоминание.

Очень нужно. systemd оказал большое влияпие на GNU/Linux. Приятно видеть то, как развивается проект. Вот он прогресс – его не остановить.

Ну так выложи свою версию инит скрипта, который автоматизирует нечто такое, что системда сама делает. А то вопросы задавать и делать вид, что способен каждый может. И чтоб гарантированно вырубался комп без ожидания срабатывания таймаута. Чтобы действительно работало. А то пока он вырубает сервис снова запуститься может и жди еще 10 минут когда сичтемда родит.

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

Как было с upstart, например

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

А что MacOS? Там ведь нет никакого systemd? Но как-то же там все работает …

что эта поделка делает в мире unix

Шёл двадцать девятый год существования Linux, а люди всё ещё думают, что он (как и GNU) — часть мира UNIX.

GNU means «GNU’s Not Unix»

Я, например, юзаю systemd на серверах и на домашне\рабочем компе как пускалку системных сервисов, пускалку пользовательских сервисов после логина (по-сути замена autostart’у в DE, но с фаршем в виде зависимостей и прочего).

Ещё я юзаю systemd в качестве хреновины для планирования задач, замены inetd (т.е активация по сокетам). Журналирование дублирую нормальным syslog’ом, т.к в случае незапланированных сбоев читать эти сраные бинарные журналы из рекавери - сплошное мучение. Мало того, он несколько раз «битые» по его мнению в результате сбоя журналы удалял бесследно. В общем, текстовые файлы всё ещё никто не переплюнул, увы.

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

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

Так это, какие у тебя возникают проблемы при попытке сменить поставщика? В реалиях Linux поставщик — тот, кто пакует дистрибутив. Вот сейчас ты пользуешься NixOS, я правильно понимаю? Какие факторы будут тебя останавливать от, например, перехода на Gentoo или Ubuntu (ради мысленного эксперимента отбросим аргументы вида «Gentoo — задротский дистр» и «Ubuntu для домохозяек»), кроме киллер-фичи NixOS?

Вот если ты в пределах одного дистрибутива захочешь что-то поменять — тут да, простор для действий часто бывает ограничен, но так уж это работает. Ты же не будешь ругать мейнтейнеров за то, что они не сделали по отдельной версии всех пакетов на каждую из возможных комбинаций «libc + openssl/libressl/boringssl + binutils/elfutils + »? Так и с системой инициализации и управления сервисами — мейнтейнерам вряд ли захочется поддерживать несколько наборов init-скриптов для каждого пакета, лишь бы угодить всем. У них и без этого работы полно.

Почему пакет «системд» сам поставляет основные удевные рули? Почему не сам удев, или, к примеру, systemd-logind тот же?

Почему ты думаешь, что это «основные» Udev-правила? Судя по их содержимому, они отвечают за настройку железа для пользовательских сессий (uaccess, seat*) и за аналогичные правила для систем, где systemd используется в качестве PID1. За пользовательские сессии и seat’ы отвечает logind, который, таки да, входит в пакет systemd (по крайней мере в Арче).

почему я вижу вот это в контролах пакета удев-237-3ubuntu10.41

Потому что ты смотришь контролы пакета из системы, которую собирали с учётом того, что она будет работать с systemd. К тому же, «Breaks» и «Replaces» намекает, что пакет udev наоборот отделили от пакета systemd? Что подтверждается на одном из моих хостов с Ubuntu 18.04:

❯ dpkg -l | grep udev
ii  libudev1:amd64    237-3ubuntu10.41  amd64   libudev  shared library
ii  udev              237-3ubuntu10.41  amd64   /dev/ and hotplug management daemon

❯ dpkg -L udev |grep udevd
/lib/systemd/system/systemd-udevd-control.socket
/lib/systemd/system/systemd-udevd-kernel.socket
/lib/systemd/system/systemd-udevd.service
/lib/systemd/systemd-udevd

В таком же виде его можно поставить в той же Gentoo, и там он требовать наличия systemd в системе не будет. Но, вот, некоторым очень не нравится, что исходники udev лежат в одном тарболле с systemd.

почему они вообще должны быть именно его компонентами, а не отдельными тулами

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

Например, как системд ждёт полторы минуты (а то и вообще вечно) сервис, процесс которого упал сразу же после запуска. Чего его ждать то?

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

Inspur K-UX. Правда они не стали продлевать сертификат.

Обернись, там случайно Леннарт за твоей спиной не стоит? Осторожно, а то и тебе внедрит…

:ROFL:

far_tuna, в квотезы!

А udev, насколько мне известно, работает без systemd

Настолько без, что приходится делать форк, ага.

Форк был сделан на баттхёртном приводе. systemd-udevd работает без systemd, но название невыносимо давит :)

Это не так.

Спасибо, что напомнил, я как раз вчера пообещал тут, что проверю.

Ну, врать вы все горазды:

In specific it tries to avoid glibc-specific functions and gcc-specific constructs by sticking to C99 while tracking closely the systemd-udev developments.

Вот из-за этого у тебя systemd-udev не работал?

дополнительный спецификаторы

Не угадал модератора по грамматике.

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

Не было апстарта в шестом ред хате.

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

Как не было, когда был? Или что там?

Там такой говнокод, что, например, сам Поттеринг не рекомендует использовать Conflicts= в общем случае.

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

В манах про это, конечно же, ни слова.

Тут нечего документировать, все очевидно.

Я вот как-то затрудняюсь даже - это ты опять в грамматику не смог или ты столь витиевато пытался пошутить?

Это ты не смог. Давай не отсвечивай.

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

Если ты свалишь на винфак, то и systemd переедет туда. Всё просто.

sudo cast LongLiveUbuntu Vault_Boy

Я собрал свежую Gentoo из stage3-nomultilib. Искаропки там сейчас используется eudev, но установить «апстримный» udev оказалось проще простого:

gentoo ~ # emerge -av sys-fs/udev

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild  N     ] acct-group/kmem-0::gentoo  0 KiB
[ebuild  N     ] acct-group/tty-0::gentoo  0 KiB
[ebuild  N     ] acct-group/audio-0::gentoo  0 KiB
[ebuild  N     ] acct-group/cdrom-0::gentoo  0 KiB
[ebuild  N     ] acct-group/dialout-0::gentoo  0 KiB
[ebuild  N     ] acct-group/disk-0::gentoo  0 KiB
[ebuild  N     ] acct-group/lp-0::gentoo  0 KiB
[ebuild  N     ] acct-group/tape-0::gentoo  0 KiB
[ebuild  N     ] acct-group/video-0::gentoo  0 KiB
[ebuild  NS    ] app-text/docbook-xml-dtd-4.2-r3:4.2::gentoo [4.1.2-r7:4.1.2::gentoo, 4.3-r2:4.3::gentoo, 4.4-r3:4.4::gentoo, 4.5-r2:4.5::gentoo] 77 KiB
[ebuild  N     ] sys-fs/udev-243-r2::gentoo  USE="acl kmod (split-usr) (-selinux) -static-libs" 8,050 KiB
[uninstall     ] sys-fs/eudev-3.2.9::gentoo  USE="hwdb kmod -introspection -rule-generator (-selinux) -static-libs -test"
[blocks b      ] sys-fs/udev ("sys-fs/udev" is blocking sys-fs/eudev-3.2.9)

Total: 11 packages (10 new, 1 in new slot, 1 uninstall), Size of downloads: 8,126 KiB
Conflict: 1 block

...

gentoo ~ # rc-update add udev sysinit

После чего перезагрузить машину. Никаких дополнительных ритуалов делать не надо.

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

То что в Red Hat не смогли осилить – не удивительно.

Шёл двадцать девятый год существования Linux, а люди всё ещё думают, что он (как и GNU) — часть мира UNIX.

Мир UNIX не OS UNIX.

Я не считаю Linux частью Unix-мира. То, что его обмазывают Unix-like юзерлендом, ещё не значит, что он сам от этого становится юниксом.

Хотите юникс — пользуйтесь юниксом, пишите ПО и скрипты только по стандарту POSIX и обязательно тестируйте его на корректную работу на всех реализациях Unix System V Release 4 (например, Solaris или HP/UX), а иначе это всё — позерство.

Его нигде не смогли осилить — ни в CentOS, ни в Debian, ни в Ubuntu. Везде в продакшне были одни и те же болячки:

• Сервисы падают после запуска, но система думает, что они запущены, потому что не умеет следить за процессами;
• В логи попадает только то, что демон сам умеет туда писать, а если какую-то ошибку выплюнуло в stdout/stderr — сам сиди и думай, что там могло быть, или воспроизводи команду для запуска сервиса из портянки руками;
• (в дополнение к первому пункту) Упавший сервис не всегда получается сразу перезапустить, потому что ОС думает, что он запущен (pid-файл-то есть!), а «завершить» его не может (PID из pid-файла не существует!);

Порой попадались не просто shell-портянки, а настоящие исчадия ада. А некоторых разработчиков заставить этим пользоваться было решительно невозможно — вместо этого они были готовы городить огород в /etc/rc.local, запускать сервисы вручную, да хотя бы внутри Tmux-сессии, лишь бы не связываться с этим ужасом. И я их прекрасно понимаю.

Единственный «традиционный» сервис-менеджер, которым можно пользоваться и не захотеть вырвать себе глаза — OpenRC, и то только те версии, где уже завезли supervise-daemon.

Судя по их содержимому, они отвечают за настройку железа для пользовательских сессий (uaccess, seat*) и за аналогичные правила для систем, где systemd используется в качестве PID1.

Откуда вторая часть предположения следует? PID1 тут совершенно не при чём, главное тут logind.

За пользовательские сессии и seat’ы отвечает logind

Вот именно, и пид у него - далеко не 1:

$ ps -A |grep logind
   1452 ?        00:10:28 systemd-logind

Получается, ты противоречишь сам себе?

который, таки да, входит в пакет systemd (по крайней мере в Арче).

«По крайней мере» так чуть менее, чем везде. А кто делал системд-шим, те ничего не достигли. И? Вы всё ещё уверены, что зависимостей между компонентами системд нет?

К тому же, «Breaks» и «Replaces» намекает, что пакет udev наоборот отделили от пакета systemd?

Нет, там указаны конкретные версии. Типа, «не работает с версией ниже такой-то». А почему бы, если они так независимы, как тут об этом говорят? А зачем генту форкал удев, или зачем девуан пилил свой вдев - тут так никто аргументированно и не ответил, кроме как «ну захотелось им». Ну ладно, не поленился, и в федоровский systemd-udev тоже глянул. Там прямым текстом requires: systemd(x86-64) = 245.6-2.fc32.

Но, вот, некоторым очень не нравится, что исходники udev лежат в одном тарболле с systemd.

Не буду говорить за тех, с кем не знаком лично. Но, может, им не нравится не то, что он там «лежит», а то, к каким последствиям это приводит? Насколько легко будет собрать удев отдельно? Сколько файлов в архиве исходников шарит удев с другими компонентами системд, и не приводит ли это к тому, что удев, собранный из одной версии исходников системд, откажется работать с какими-нибудь его компонентами, собранными из пакета исходников другой версии? Я вот и пытался показать, что все почему-то зависимости прописывают, ну либо брейкают старые версии, что то же самое. Так может, он не просто «лежит» в пакете исходников системд, но ещё и это приводит к зависимостям, проблемам сборки отдельно, и тд? Ведь согласитесь, если бы он там просто «лежал», и никаких последствий бы не создавал этим, то никто бы и не возмущался?

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

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