Devuan Excalibur 6

Хрестоматийное «Я гнался за вами три дня, чтобы сказать как вы мне безразличны»

У тебя для этого есть пакетный менеджер если что.

Нет. Пакетный менеджер не должен управлять содержимым /usr/local или /etc. Здесь речь идет о деплое на систему специфических юнитов: запускать что-то, что не предусмотрено разработчиками. Твои собственные скрипты в /usr/local/bin, например, твоими собственными юнитами. Или софта, для которого нет пакетов - для такого существует /usr/local.

Твои заявления противоречат тому, что там буквально чёрным по белому написано.

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

Ты в итоге сам признал что косяки там есть.

Нет никакого итога, я изначально и не отрицал, что они там могут быть.

В «любом проекте» наткнуться на баг несколько сложнее чем попасть с 3 метров из дробовика в стену.

А вот демагогия твоя мне вообще не интересна.

Ты сам это придумал - сам и показывай.

kirill_rrr Мне вот любопытно, где реально граница твоего ламерства? Тебя вообще ни на секунду не смущают не противоречия с FHS, ни то, что тебе админы с двадцати- и тридцатилетним опытом объясняют, что твои локалхостовые подходы в реальности не работают? В какой момент ты включишь мозг и начнешь воспринимать входную информацию? Или это невозможно в принципе, а ЧСВ бетонокладчика нерушимо так же, как и банька из бетона М500?

опять оторванный от контекста,

В смысле оторванный? Не знаю какой у тебя контекст, но мы вообще то обсуждаем WTF список путей для поиска юнитов захардкожен при сборке, а не выполнен в виде переменной. Никто так не делает, это идиотизм. Если пути дял поиска - пакет то его может потребоваться изменить.

Яркий пример - $PATH. Котороый несмотря на все стандарты и «да все знают что» - совершенно не обязан включать /usr/bin и соответственно одной лёгкой командой удалёется из списка.

Ну-ка объясни мне, почему PATH в Solaris 2.4 не содержит

Не содержит по дефолту или не позволит её туда добавить?

Ты меня переоцениваешь порядка на 4. И недооцениваешь доки на системд - их нельзя «просто прочесть». Ещё надо распрощаться с человеческой логикой чтобы воспринять эту свалку.

можно было бы просто прочесть

Ты меня переоцениваешь порядка на 4

Ну ладно.

Пакетный менеджер не должен управлять содержимым /usr/local или /etc

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

С /usr/local сложнее. Почему внедистриутивный пакет не должен устанавливаться например туда?

Я тебе буквально перевожу то, что там написано

БУКВАЛЬНО мне переводит переводчик. А ты выдумываешь то, чего там нет.

Ок, слив засчитан. Можно даже не проверять регламентирует ли FHS переменную $PATH.

Тебя вообще ни на секунду не смущают не противоречия с FHS

Меня напрягает твоё выкручивание наизнанку того что там написано.

В смысле оторванный?

В прямом.

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

Нет, это ты обсуждаешь и почему-то негодуешь. Хотя этот аргумент - никакой.

Никто так не делает, это идиотизм.

Если понеслись обобщения, то слив близок.

Яркий пример - $PATH.

Даже близко не подходит как пример.

Не содержит по дефолту или не позволит её туда добавить?

Ты вообще не понимаешь, почему я задал этот вопрос, да?

Нет, это ты обсуждаешь и почему-то негодуешь

Тогда интересно было бы узнать что же обсуждаешь ты.

Даже близко не подходит как пример.

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

Ты вообще не понимаешь, почему я задал этот вопрос, да?

Почему ты считаешь что я должен? Для тебя что то там очевидно, а для других почему должно быть так же? Для меня очевидно что ты ставишь равенство между стандартом для размещения файлов по ФС и тем где командный интерпретатор должен их искать.

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

Ты просто терминально тупой.

Почему ты считаешь что я должен?

Забавно. Я по-умолчанию предполагаю, что, если человек ведёт дискуссию, то он разбирается (ну или хотя бы хочет разобраться) в вопросе и ОДНОВРЕМЕННО следит за контекстом в ней.

Теперь ты сам подтвердил, что в твоём случае это не так. Ты не разбираешься в вопросе (и не хочешь в нём разобраться) и не следишь за контекстом.

О чём и зачем тогда с тобой говорить? :)

Метапрог 2.0. Ему надо еще начать делать свой инит на лабвью.

видеть путь к конфигу юнита в выхлопе, например

Ещё раз: чтобы видеть и понимать. Какой именно командой с какими ключами – мне похер, разумеется, лучше всего, если можно будет 2 разных выхлопа: логическое дерево и юниты с полным путём, в порядке запуска, а можно один, сразу всё.

Ещё раз: чтобы видеть и понимать.

Это не ответ. Юниты имеют уникальные имена, зачем тебе путь на этапе просмотра дерева, чтобы что? Что ты там понимать собрался?

Посмотрел дерево, увидел интересующие юниты, запросил по ним инфу.

Этот компонент затем, что так решили разработчики твоего дистрибутива

Т.е. имеем диктат кого-то там, что прямо противоречит идеологии GNU. Вообще, для такого у нас есть Винда и Мак.

упростить сопровождение и устройство ОС

Впердячив в ОС неудаляемого монстра с путанной документацией и невозможностью легко и просто получить элементарную информацию по работе этого монстра?!

systemctl status

Показывает, что именно запущено у меня. Всё. Ровно тоже самое, что показывает ps с набором ключей -efH.

Посмотрел дерево, увидел интересующие юниты, запросил по ним инфу.

Какое дерево? Ещё раз, разъясните, как получить дерево запуска? Логическое, т.е. в какой последовательности что запускается? Не по времени, чтобы мне не требовалось последовательно смотреть тексты юнитов для понимания, кто кого ждёт, кто запускается до и после.

И законно ли несколько before и after в юнитах? Влияет ли это как-то на логику их обработки?

Я вот смотрю, что systemctl status выдал мне Units: 338 loaded (incl. loaded aliases), а где список этих 338 юнитов в выхлопе?!

Т.е. имеем диктат кого-то там, что прямо противоречит идеологии GNU.

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

Впердячив в ОС неудаляемого монстра с путанной документацией и невозможностью легко и просто получить элементарную информацию по работе этого монстра?!

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

Показывает, что именно запущено у меня.

Посмотри –help.

Ровно тоже самое

Нет.

Ещё раз, разъясните, как получить дерево запуска?

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

• systemctl list-dependencies - покажет дерево зависимостей.
• systemd-analyze unit-paths - выводит список всех путей, по которым лежат юниты.
• systemd-analyze unit-files - список всех юнитов.
• systemd-analyze plot >bootup.svg - нарисует в SVG граф, как и что у тебя грузилось в текущий момент.
• И вообще, читай документацию к systemd-analyze, там подробно расписано, как получить всю нужную информацию.

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

Ещё раз: чтобы видеть и понимать

Ненене, «чтобы видеть» не является ответом на вопрос «нахера тебе видеть».

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

Каковая сраная форумная риторика тебя и понуждает требовать путей к файлу описания юнита ИМЕННО В ДЕРЕВЕ И НИКАК ИНАЧЕ, ИЛИ ВАШ СИСТЕМДЕ ГОВНО.

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

они бы уже на третьей странице хором требовали бы немедленно закопать весь зоопарк и написать системду.

А в результате закопали бы их самих.

И после этого, после обновления, следует рестарт

Не следует.

То есть systemd будет работать со старой библиотекой? Или как-то иначе её перечитает?

Еще один эникейщик жалуется на слишком подробную документацию.

Там из 60721 байт 60000 просто комментарии что ли? :-)

По существу возражения будут, или как обычно?

А это разве не по существу, когда вдруг расписание перезагрузок, внезапно, стало важным, а перезагрузки регулярными? В то время, как раньше это было сродни аварии и об этом прередупреждалось, как о внеплановом перерыве? Это, как раз таки, показатель.

Ей-богу, если бы противники системды предъявляли к другим инитам претензии с хотя бы половиной наблюдаемого рвения,

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

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

Ну ваш-то любимый инит точно умеет и это, и многое другое, ога-ога.

Претензии к стремлению системды стать всеобъемлющим монстром мне безразличны.

А они основные.

Но я больше про вот эти требования к форматам выхлопа

Да это ерунда. Не нравится - смени init... Ой. Что это я, его же нельзя просто теперь сменить. Ибо systemd-logind, на него уже KDE завязался, Gnome вроде тоже... Ну, ты понял. :-)

А они основные.

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

Не нравится - смени init… Ой. Что это я, его же нельзя просто теперь сменить. Ибо systemd-logind, на него уже KDE завязался, Gnome вроде тоже… Ну, ты понял. :-)

Я это понял на десятилетия раньше многих поборников швабоды (как они ее понимают). А именно: если ты только жрешь, что дают - знай свое место. Мне приготовили и дали на халяву системду с кедами - отлично, я благодарен и рад. Я не буду орать «чот слишком вкусно, красиво и единообразно, а ну-ка быра шлепнули и размешали тут пару черпаков привычного говна, пердолинга и шеллскриптинга! А то как-то все слишком хорошо, наверное вы собрались с меня за это деньги брать».

Так давайте оставаться в рамках обсуждения основных претензий

Я и остаюсь: «комбайн есть комбайн».

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

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

Я и остаюсь: «комбайн есть комбайн».

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

разнородное, вроде бы, сообщество ломонулось под одну крышу

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

Венда, да. Уж сколько говнины налепили - а все работает и работает.

С каких пор у нас в памяти меняется содержимое обновленной ранее загруженной библиотеки? Ну-ка?

А будь так - плохо что ли?

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

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

Я по-умолчанию предполагаю, что, если человек ведёт дискуссию, то он разбирается (ну или хотя бы хочет разобраться) в вопросе и ОДНОВРЕМЕННО следит за контекстом в ней.

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

Ты не разбираешься в вопросе (и не хочешь в нём разобраться)

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

С каких пор у нас в памяти меняется содержимое обновленной ранее загруженной библиотеки? Ну-ка?

Вот и я думаю, что ни с каких. То есть, systemd будет продолжать работать в том виде, как изначально запустился. Ты это хотел сказать? Ну так и я про то. А как systemd узнает, из-за чего библиотеку-то обновили его главную? Вдруг там CVE какой жуткий?

Ещё раз, для особо тупых: systemd - это не инит, а системный менеджер, интегрированная коллекция подсистем

И нахрена её такую сделали? Правильно, ибо неосиляторы: не смогли сделать init и при init эту самую коллекцию.

Кстати, вот смотрю, как скрипт произвольный запустить при старте. Это что, правда что ли мне надо unit-файл писать вместо банального rc.local??

UPD: да, я завёл себе первый сервер с systemd, ковыряю. Уже три косяка такого плана. Дойду и до проверки конфига перед reload, про что раньше спрашивал. ;-)

Ещё раз: системд не для тупых а для всех. Не потому что все хотели, а потому что им навязали. «Всем» не нужен системный менеджер, им нужен инит. Включил, выключил, проследил за выполнением - ВСЁ!!! «Всех» интересунт исключительно только то, как он запускает систему и следит за демонами, а весь остальной функционал может просто тупо мешать основной задаче.

Но речь идёт о логике непостижимого комбайна

претензии к которой есть далеко не только у меня

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

Под «разбираться в вопросе» ты, liksys и многие другие разумеется считают что я должен безусловно принять чужое мнение потому что

И вот опять забалтывание и подмена понятий путём цитирования только того, что тебе нравится :)

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

О, задействован его величество демагогический аргумент «спервадобейся» :)

противоречащим концепции системы

Парадигме, епта.

Да-да, не всем нужна работающая консистентная система, кому-то нужнее трахаться со скриптами, ПОНИМАТЬ, глядя в выхлоп дерева и воображать себя тру.

Я ж говорю, ты всех победил. Успокойся и прими таблетки.

А собственно почему?

Потому что ты, будучи обычным эникейщиком, делаешь заявления космического масштаба и космической же глупости, не обладая ни опытом в разработке, ни опытом в администрировании, ни даже банальным умением читать и понимать прочитанное в документации - ничем. Тебе просто КАЖЕТСЯ, а значит ты прав, и ты имеешь МНЕНИЕ.

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

не знаешь почему то или это сделано так а не иначе

Дело именно в том, что я именно ЗНАЮ. В отличие от тебя, я занимаюсь и разработкой, и сопровождением систем, от которых зависят многие люди. И я перекладываю на systemd множество задач из-за его надежности. Я ПОНИМАЮ как он работает и не вижу в нем никакой чудовищной сложности и магии, в то время как для тебя и других клоунов в этом треде, не могущих в документацию, systemd остается огромным черным ящиком с волшебными гномиками.

Отсюда все ваши заблуждения и нытье.

Вдруг там CVE какой жуткий?

А вдруг у тебя CVE в любом другом софте? А в ядре? Что делать-то будешь, демагог?

Обновляться и перезапускать/ребутаться. Вот и весь сказ.

И нахрена её такую сделали? Правильно, ибо неосиляторы

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

Это что, правда что ли мне надо unit-файл писать вместо банального rc.local?

Что конкретно тебя смущает?

UPD: да, я завёл себе первый сервер с systemd, ковыряю

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

Уже три косяка такого плана.

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

А вдруг у тебя CVE в любом другом софте? А в ядре? Что делать-то будешь, демагог?

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

Сравнимо только ядро. Но ядро очень легко вернуть обратно, банальной перезагрузкой. Другого такого ПО просто нет. И если с ядром уже случилось (в смысле монстрообразность), то зачем то же самое повторять с init, где всё было относительно хорошо?

Для скрипта unit таки писать? Я-то надеялся, что что-то упустил...

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

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

И нет, timedatectl set-timezone через раз работает. Третий косячок скорее дистрибутивный, ладно. Просто вылез на дистрибутиве с systemd. в общем, урежем осетра до двух косячков пока.

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

Степень ответственности - вещь относительная. Сервера нужны, чтобы запускать приложения. Если на БД-сервере крутится условный постгрес, то всё вокруг работает ради него одного, и степень ответственности за его эксплуатацию вырастает до запредельной, и любая эксплуатируемая CVE там становится критической.

где всё было относительно хорошо?

Даже близко не было хорошо, не надо выдумывать.

Для скрипта unit таки писать? Я-то надеялся, что что-то упустил…

Проблема-то в чем? Что ты вообще хочешь сделать в rc.local? Есть вероятность, что в современных линуксах это делается другими способами.