systemd 249

иногда приотключаю, чтобы посмотреть что все, как обычно

А вы знаете толк в извращениях, сударь!

один и тот же файл используется в федоре, убунте, зузе, арче…

Клятiй redhat ломает наш зоопарк несовместимости!!111ОДИНОДИНОДИН

адекватов я в треде иначе не увижу:( а так зато удобно. с игнором лор обычно пушистый и шелковистый.

Но ты чтобы не быть голословным, кинь пример

И аналогичный пример systemd юнита.

Чтобы не быть голословным, можешь кинуть пример сам. Подсказываю: /usr/portage/net-misc/dhcpcd/files/*

Годы идут, а комментаторы ЛОРа никакие выводы так и не сделали.

Надеюсь, и не сделают. Иначе зачем сюда заходить?

Ты, как я вижу, тоже выводов не сделал, иначе зачем сюда зашел?

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

Так и вижу. ЛОР 2043 год, осуждение systemd-665 в новостях

Словно systemd и/или ЛОР дойдет до 2043-ого.

Так и вижу. ЛОР 2043 год, осуждение systemd-665 в новостях

В 2043 году будет уже СОР, от systemd.org.ru.

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

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

А рунит с системд просто сравнивать очень сложно.

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

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

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

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

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

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

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

Ненавижу самокаты. Бесят.

Но это же не баш. По крайней мере не скрипт. А вот ради интереса открыл самбу - там какой-то треш.

Пару новых зависимостей появилось… Компилить впадлу)).

В целом, systemd нравится, поэтому и юзаю. Хотя в последнее время на LFS юзаю sysvinit, ибо ТруЪ.

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

Init - збс Sysvinit - хрень Systemd - еще хуже

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

Мы всё ещё про управление зависимостями, или ты уже поменял тему (= демагог)?

Так мусье банальный ниасилятор?!

Ну попробуй man pam-script - это уж для совсем криворуких дебилов.

Про то, что скрипты на баше легче писать, чем юниты. В юнитах, видите ли, много переменных надо знать…

Кто-то выше по треду утверждал.

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

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

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

Да там уже if написать заколебешься: где нужна семиколон, где нет…

Возьми смузи и напиши на python - в чём проблема?

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

Посоны, у меня без ентого системд все хорошо работает. Шо не так делаю?

Постучал тебе членом по лбу. Тук тук

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ditto.

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

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

Да ладно, они наверное на лоре такие грозные, а сам поди юниты пилит втихаря🤭

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

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

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

4.2

Ditto

Supercalifragilisticexpialidocious

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

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

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

Ты решил собой весь тред загадить, ламер?

Извини systemD-просветитель за оффтопик. Но если в фотошопе твои ноздри и твои глаза поменять, то такая ржака получится.

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

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

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

У юнитов есть определённая структура, благодаря ей они несколько сложнее в написании, но легче в поддержке.

Троянский конь тысячелетия стал на 0.74% функциональнее. Я очень рад за его счастливых юзеров, которых он юзает.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

один и тот же файл используется в федоре, убунте, зузе, арче…

Нет.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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