https://slinkov.ru/openforum/vsluhforumID3/118577.html Разработчики дистрибутива Nitrux объявили о формировании первых успешно работающих сборок, избавленных от systemd. После почти трёх месяцев экспериментов началось тестирование сборок на основе SysVinit и OpenRC. Первый вариант (SysVinit) отмечен как полностью работающий, но не рассматриваемый как идеальное решение. Второй вариант (OpenRC) пока не поддерживает GUI и подключение к сети. В дальнейшем планируется также попробовать сформировать сборки с системами инициализации s6-init, runit и busybox-init...<br><br>Подробнее: https://www.opennet.ru/opennews/art.shtml?num=51567<br> https://slinkov.ru/openforum/vsluhforumID3/118577.html#153 Tue, 05 May 2020 15:39:43 GMT Уж лучше AppImage, чем снапы и прочий пакетный мусор.<br> https://slinkov.ru/openforum/vsluhforumID3/118577.html#152 Wed, 02 Oct 2019 04:04:12 GMT Прекрасный пример того, что никакого навязывания systemd нет. Кому надо - пользуется другим инитом.<br> https://slinkov.ru/openforum/vsluhforumID3/118577.html#151 Sun, 29 Sep 2019 12:05:41 GMT &gt; А если ты хочешь услышать хамство, то вот оно, пожалуйста<br><br>Вижу ты ждал именно этого момента :) <br> https://slinkov.ru/openforum/vsluhforumID3/118577.html#150 Sun, 29 Sep 2019 07:03:42 GMT &gt; Что за фамильярность.<br><br>Что за фамильярность?<br><br>&gt; Во-первых, см. #145.<br>&gt; Во-вторых, раз уж Вы пошли в ad hominem, позвольте и я Вам <br>&gt; напомню некоторые детали Вашей биографии. Судя по длине Ваших постов, у <br>&gt; Вас, Ordu, чрезвычайно много свободного времени.<br><br>Да. Завидно?<br><br>&gt; А также Вы грешите <br>&gt; размышлениями на темы, в которых не разбираетесь.<br><br>И чё с того?<br><br>&gt; чтобы к Вашим нравоучительным поучениям (например к описанным выше) прислушивались, то <br>&gt; Вам с учётом Ваших прошлых выступлений стоило бы сначала показать, что <br>&gt; Вы в данном вопросе понимаете хоть что-нибудь.<br><br>Нет, спасибо.<br> https://slinkov.ru/openforum/vsluhforumID3/118577.html#149 Sun, 29 Sep 2019 03:30:40 GMT &gt; Опять же к дизайну самого systemd есть вопросы. Например какого лешего юниты <br>&gt; хранятся в /var/lib/systemd а не в /etc где им самое место? <br><br>Не, это понятно почему. Там хранятся дефолты. А в /etc/systemd пользователь может положить переопределения. Плюс подобного подхода в том, что теперь видно разницу между юнитами, в которые администратор внёс правки и дефолтными настройками мейнтнейнера. В смысле, видно из коробки. Раньше мы просто ставили для этого etckeeper и тоже всё было видно. А вот минус тут более сущетвенный. Файлы в /var/lib/systemd не помечаются как конфигурационные (по крайней мере в Debian/Ubuntu). В случае внесения правок в сервисный файл раньше из-за этой пометки на нём при обновлении выстреливал ворнинг, а сейчас должно просто происходить замещение новой версией от мейнтейнера без предупреждения. Я очень сомневаюсь, что кто-нибудь чекает подобные вещи при апгрейде.<br> <br>&gt; Если не ошибаюсь то RedHat совместил /usr/bin и /bin тоже по причинам <br>&gt; связанным больше с архитектурой systemd чем https://slinkov.ru/openforum/vsluhforumID3/118577.html#148 Sun, 29 Sep 2019 02:18:24 GMT &gt; А в реальном каждый пользователь пытался вставить в автозапуск какой-то свой скрипт. <br><br>И корректный способ это сделать: crontab -e<br><br>&gt;&gt; Какие ещё макросы в shell?! Там даже понятия такого нет.<br>&gt; Это то, что называется переменными. Но я, как разработчик, не могу это назвать ничем кроме макросов. Просто подстановки строк в другие строки.<br><br>Класс. То есть Вы сначала говорите, что словом macros называете variables, а потом даёте понять, что Вы называете этим словом expansion. Отлично. Не хотите ли пойти на пересдачу за столь превольное оперирование терминологией?<br><br>&gt; Так как главный признак макроса - отсутствие какой-либо типизации, статической или динамической. <br><br>Да неужели. А Вы это, попробуйте как-нибудь набрать в гугле "typed macros", много интересного узнаете.<br><br>Короче, всё, что Вы должны понять: в шеллах нет макросов. Вообще.<br><br>&gt; в моём сообщении речь идёт о пакетах &lt;...&gt; просто скачанных с сайта разработчика <br><br>Ну да. Всякая фигня случается, если некто зачем-то берёт на себя труд мейнтейнера, но н https://slinkov.ru/openforum/vsluhforumID3/118577.html#147 Sun, 29 Sep 2019 01:03:42 GMT &gt;&gt; SysV init это просто запускался скриптов, если у вас были кривые скрипты <br>&gt;&gt; то причём тут SysV init?<br>&gt; При том, что он поощряет написание этих кривых скриптов. Как? Например, вот <br>&gt; так: <br>&gt; 1. Отсутствие стандарта метаинформации (ограничения, зависимости, последовательность <br>&gt; запуска и т.д.) о сервисе. Из-за этого придумали костыль - хитрые <br>&gt; комментарии в начале скрипта, так называемый sysvinit service header.<br><br>Сервисные скрипты для sysv сильно разнились от дистрибутива к дистрибутиву. Закономерное следствие его гибкости. Так вполне логично, что стандарт определялся на уровне дистрибутива. Вот в Debian был стандарт. Это и был тот самый LSB header, который Вы почему-то называете "sysvinit service header" и "костылём".<br><br>&gt; Которые мало кто нормально пишет. Да и в которых почти ничего нет. PID/GID там не выставишь, например.<br><br>Какой кошмар. В header-ах, которые определяют *порядок загрузки*, нельзя выставить GID. Правда, UID/GID можно дальше спокойно выставить в start-stop-daemon, но кому это инте https://slinkov.ru/openforum/vsluhforumID3/118577.html#146 Sun, 29 Sep 2019 00:35:40 GMT Что за фамильярность.<br><br>Во-первых, см. #145.<br><br>Во-вторых, раз уж Вы пошли в ad hominem, позвольте и я Вам напомню некоторые детали Вашей биографии. Судя по длине Ваших постов, у Вас, Ordu, чрезвычайно много свободного времени. А также Вы грешите размышлениями на темы, в которых не разбираетесь. Да хоть недавний вон случай, когда Вы рассказывали о том, как лиспы плохи, при этом путая лексическое связывание с динамическим, что является в общем-то теоретическим минимумом. И такое за Вами наблюдалось не единожды. Поэтому, если Вы хотите, чтобы к Вашим нравоучительным поучениям (например к описанным выше) прислушивались, то Вам с учётом Ваших прошлых выступлений стоило бы сначала показать, что Вы в данном вопросе понимаете хоть что-нибудь.<br> https://slinkov.ru/openforum/vsluhforumID3/118577.html#145 Sun, 29 Sep 2019 00:23:51 GMT &gt;&gt; Но сейчас при заказе виртуалки в любом ДЦ -- у меня только один выбор, и это systemd. Его функционал избыточен для типовых нужд современного опса, да и доверия инстурмент не внушает. Но деваться от него некуда.<br>&gt; Для без GUI сервера с debian 9 systemd всё ещё можно выпилить, <br>&gt; я выпиливал, в 10 пока не тестировал.<br><br>Можно, согласен. Напильником всё можно. Но время -- штука дорогая. Возьмём ту же систему на базе Ubuntu (или Debian). Её работа без systemd мягко говоря не гарантирована. Зачастую Вы будете попадать в ситуации, когда всё заточено исключительно под systemd, и её отсутствие не даст Вам возможности решить проблему быстро.<br><br>Выпилить-то я могу. Вот только потом я поставлю стороннее ПО, а в нём будет исключительно service-файл. И это будет означать, что я не могу просто поставить его и получить рабочее приложение, я должен буду в системе, куда его поставил, завести либо systemd-shim какой-нибудь, либо написать свой init-скрипт. Это займёт время. А его часто попросту нет.<br><br>Собственно, такое нес