LINUX.ORG.RU

Devuan 6.1

 , , , ,


0

1

2 января состоялся релиз дистрибутива Devuan Excalibur 6.1, основанного на Debian 13 «trixie». Ключевое отличие дистрибутива – это поддержка систем инициализации, отличных от systemd. Дистрибутив поставляется по умолчанию с окружением Xfce. Пакеты собираются для архитектур i386, amd64, armel, armhf, arm64, ppc64el и riscv64.

Дистрибутив сопровождает около 400 пакетов, позволяющих функционировать без systemd, такие как например, elogind, OpenRC или runit. В целом, дистрибутив сохраняет совместимость с Debian, за исключением данных моментов. Доступны также окружения: Cinnamon, KDE, LXQt, LXDE, MATE и Sway. Система инициализации по умолчанию – SysVinit, можно перейти на OpenRC и runit. Также присутствует возможность работы без D-Bus. В качестве сетевого менеджера используется Network-Manager в варианте, не привязанном к systemd. ConsoleKit используется в Xfce и MATE, в остальных – elogind. Также стали доступны неофициальные сборки для Raspberry Pi.

Запущен также Devuan Testing 7 «Freia». Ключевые особенности релиза со стороны Devuan пока неизвестны.

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



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

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

Тем не менее укажу, что 4 команды, что вы привели не есть ответ на мой вопрос. Мой вопрос, как получить список файлов загружаемых юнитов (с полным к ним путём) в порядке их запуска? Мне так же не нужен список всех юнитов, мне нужен список только запускаемых юнитов.

показывает юнит, который отвечает за этот сервис

Фишка, не нужная, если нет системд.

показывает тебе действительное состояние сервиса

Точно? Я вот помедитировал над выданным списком и нашёл, что, например, SMPlayer записан там с первым кином, а не тем, что он крутит прямо сейчас. Понятно, что это ни на что не влияющая мелочь, но ps же показывает, какой процесс фиктивный или зомби.

И вообще, читай документацию к systemd-analyze, там подробно расписано, как получить всю нужную информацию.

Так где удобства системд, если сначала надо читать много документации? Причём ради чего? Ради «знания системд»? А зачем мне её знать, если она не даёт мне никаких удобств по сравнению с тем, что было без неё?

И вот в этом месте вам подобные должны не срать на Devuan, а говорить подобным мне: «Тя никто ничего не заставляет, вали на свой Devuan, если тебе системд не нравится».

Это и есть путь СПО: возможность свалить туда, где комфортно, а не мудохаться с тем, что дают (да ещё и за деньги) «злые корпорасты».

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

как получить список файлов загружаемых юнитов (с полным к ним путём) в порядке их запуска?

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

Отдельно хочу заметить, что то, что ты хочешь - не являтся практической задачей. Мне, как человеку, который уже лет 10 делает продукты на systemd (а админит еще больше) никогда не было это нужно. Тем более, это не нужно и тебе. Тем не менее, решение - вот.

Фишка, не нужная, если нет системд.

Идиотская претензия.

Точно?

Совершенно точно.

SMPlayer

Откуда он у тебя там вообще взялся? Впрочем, ты даже не понял, о чем я тебе сказал: сервис != процесс. Сервис может быть запущен, потому что обрабатывается внутренними механизмами systemd.

Например, сервисом может быть однократно отрабатывающий процесс. Например, при загрузке OS тебе надо по I2C скормить в какой-нибудь чип маленький блобик. Ты пишешь сервис foobari2c, в котором ставишь зависимость от наличия /dev/i2c-0, а затем однократный запуск команды, загружающей данные. После того, как программа отработает, больше ты ее в ps не увидишь. А вот systemctl status будет показывать, что сервис активен, и процесс успешно завершился. А при остановке сервиса можно точно так же выполнить однократную команду и очистить память чипика. На оба этих действия можно навесить зависимости. Это недостижимая гибкость и уровень интроспекции для классических инитов.

Так где удобства системд, если сначала надо читать много документации?

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

А зачем мне её знать, если она не даёт мне никаких удобств по сравнению с тем, что было без неё?

Для тебя, как для конечного юзера, которому даже рут на машине не нужен, не меняется вообще ничего. Это удобство для дистросироителей, админов и разработчиков: возможность строить сложные деревья зависимостей, гибко ими управлять и избавиться от сопровождения инит-скриптов. Либо это делает systemd, либо ты пишешь и поддерживаешь собственные уникальные и неповторимые баш-портянки. Причем, если в первом случае на этот код смотрят тысячи человек, то со вторым тебе придется мудохаться самому.

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

вам подобные

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

не мудохаться с тем, что дают (да ещё и за деньги) «злые корпорасты»

Да-да. Злые корпорасты, пишущие ядро линукса - это хорошо. Корпорасты, сделавшие X11 - тоже хорошо. Корпорасты, сделавшие systemd - плохо, смотри не перепутай.

liksys ★★★★
()
Последнее исправление: liksys (всего исправлений: 1)
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.