LINUX.ORG.RU
ФорумTalks

Поставил Artix Linux — Arch на openrc и/или runit

 , , ,


2

5

Аноним в комментах вчера посоветовал заценить Artix Linux.

Скопировал системный раздел в новый том LVM, потом arch-chroot туда и далее по мануалу: https://wiki.artixlinux.org/Main/Migration Перезагрузился. Всё ок. Lightdm прогрузился, в сеанс логинится, все приложения, на первый взгляд, работают. ps 1 здорового человека:

vadim@sonata:~$ uname -a
Linux sonata 4.14.41-1-lts #1 SMP Wed May 16 17:48:14 UTC 2018 x86_64 GNU/Linux
vadim@sonata:~$ cat /etc/os-release 
NAME="Artix"
PRETTY_NAME="Artix Linux"
ID=artix
ID_LIKE=artixlinux
ANSI_COLOR="0;36"
HOME_URL="https://artixlinux.org/"
SUPPORT_URL="https://artixlinux.org/"
BUG_REPORT_URL="https://artixlinux.org/"

vadim@sonata:~$ ps 1
  PID TTY      STAT   TIME COMMAND
    1 ?        S      0:00 /sbin/init
vadim@sonata:~$ 

Система до окна логина, кстати, грузится быстрее, чем systemd. Ну, я всегда говорил, что systemd тормоз, упирающийся в IO на HDD. У меня Void грузится быстрее, Arch старый до systemd грузился быстрее, и теперь вот Arch на openrc тоже грузится быстрее.

Пока всё выглядит так, что можно обратно и не перезагружаться. Софт тот же самый остался установлен, настройки те же, хомяк тот же. Посижу пока тут и пощупаю, что за зверь openrc. С runit я уже знаком.

Что касается системы. Если я правильно понял, здесь другой подход при избавлении от systemd, чем в Void. В Void от systemd нет никаких следов, а вместо logind запилили форкнутый энтузиастами consolekit. В Artix, судя по именам пакетов, куча прокладок под API systemd, чтобы прикладуха работала как обычно. Думаю, в обоих случаях это разумный выбор. Void с нуля пакетируется, и там есть место для манёвра, а в Artix задача была обеспечить максимальную совместимость с существующей пакетной базой.

Deleted

Последнее исправление: Deleted (всего исправлений: 2)

а вместо logind запилили форкнутый энтузиастами consolekit

ConsoleKit is currently not actively maintained. The focus has shifted to the built-in seat/user/session management of Software/systemd called systemd-logind!

Хм

creazero
()

В Artix, судя по именам пакетов, куча прокладок под API systemd, чтобы прикладуха работала как обычно

Звучит как нужно. Надо будет тоже этот дистр потыкать

SR_team ★★★★★
()

Нужно, в ближайшее время тоже потыкаю.

commagray ★★★★★
()

В Artix, судя по именам пакетов, куча прокладок под API systemd, чтобы прикладуха работала как обычно.

Нинужно. Systemd и так, мягко говоря, не идеален, а тут еще и куча костылей намазали. Если уж такая неприязнь к systemd - надо просто использовать систему без него. Если какой-то софт прибит к systemd гвоздями - либо нафиг такой софт, либо надо форкать и вычищать всю эту ерунду. А тут не понятно в какой момент оно сломается и куда бежать - то ли дело в том как работает systemd, то ли в том как обертку написали, то ли в приложении.

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

Если уж такая неприязнь к systemd - надо просто использовать систему без него.

Там как раз система без systemd. А прослойки отражаться будут разве только на софте, который на systemd завязан.

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

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

Deleted
()
Ответ на: комментарий от micronekodesu

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

Ты правда считаешь, что форкнуть кучу софта легче, чем написать прослойки?

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

wine

Ну в общем да, но только это другой случай - попытка заставить работать софт, на который повлиять «с нашей стороны» никак не получится.

и всякую обратную совместимость

Тоже мне новость. Тут вон поддержку x32 дропают в каждом втором дистре.

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

Я считаю что это правильнее, не легче. Про онтопик и сопутствующий софт часто говорят что он свободный, а по факту оказывается что какой софт и как ты будешь использовать решают полторы корпорации. Кого-то это устраивает и они продолжает пользоваться дальше, а кого-то не устраивает и они вместо того чтоб поддержать «свободность» и показать средний палец всем тем кто пропихивает плохие решения начинают лепить какие-то прослойки. Логично предположить что в финале такой движухи они просто очередь будут в пятницу вечером занимать чтоб пораньше в субботу освободиться.

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

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

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

Ты правда считаешь, что форкнуть кучу софта легче, чем написать прослойки?

Я считаю что это правильнее, не легче

А люди, которые на практике занимаются этим, явно считают, что правильнее - делать прослойки.

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

Напоминает «Мышки, станьте ежиками!».

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

А люди, которые на практике занимаются этим, явно считают, что правильнее - делать прослойки.

А люди, которые пилят и продвигают systemd, считают что их вариант правильнее.

Напоминает «Мышки, станьте ежиками!».

А, ну да, лучше же когда каждый пилит свою поделку. Хороший софт он же так и создается, один человек всегда делает все лучше и качественнее команды.

micronekodesu ★★★
()

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

Shulman
()

Посижу пока тут и пощупаю, что за зверь openrc. С runit я уже знаком.

Им бы надо было sysvinit по умолчанию использовать, который уже знаком всем.

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

А люди, которые на практике занимаются этим, явно считают, что правильнее - делать прослойки.

А люди, которые пилят и продвигают systemd, считают что их вариант правильнее.

Это делает твою идею «форкнуть всё» более жизнеспособной?

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

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

Ответ на все вопросы — docker.

Ну а дистрибутивы из любопытства ставятся.

Deleted
()
Ответ на: комментарий от tailgunner

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

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

Хороший софт он же так и создается, один человек всегда делает все лучше и качественнее команды.

Одна ОС, один инит, один ГНОМ...wait, OH SHI~~

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

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

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

Промежуточных вариантов, конечно, нет.

Почему нет?

Одни пилят systemd.

Другие — consolekit2.

Третьи выпыливают лобзиком прослойки из сорцов systemd.

А кто-то вообще в NetBSD с IceWM сидит.

Всё, как вы хотели.

Deleted
()
Последнее исправление: Deleted (всего исправлений: 1)
Ответ на: комментарий от micronekodesu

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

Не anti-systemd, а свобода выбора. То, что каждый лепит своё, это как раз правильный путь. До какого такого конкурентноспособного состояния допилить, неясно, так как systemd не выдерживает честной конкуренции даже с sysvinit, ибо эпично забагован и это неисправимо, о чём свидетельствуют и бурные обсуждения, и отдельные темы, и чейнджлоги. Более того: решения без надобности использовать systemd итак есть. Суть прослоек совместимости в том, чтобы специфичные для systemd программы использовать, но они не являются обязательными.

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

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

Я про то, что «какой дистрибутив лучше под задачу» — теперь вопрос очень условный. Любое приложение можно опакетить в докер и не париться, поверх какого дистрибутива запускать.

Deleted
()
Ответ на: комментарий от Quasar

Не anti-systemd, а свобода выбора.

+1

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

Вариативность — основа эволюции.

Deleted
()

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

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

чем runit от openrc отличается?

openrc — это классическая для любого юникса куча кода на sh, которую аккуратно причесали и засунули туда стопицот фич. Отслеживает сервисы на основе PID-файлов со всеми сопутствующими проблемами.

А runit — это KISS-супервизор сервисов, который умеет ровно одну вещь: супервизить сервисы.

В общем, первый взгляд, ничего общего. Но есть нюансы:

В Void на основе runit выстроена довольно аскетичная система инициализации и управления сервисами. Т.е. система инициализации там — это runit + немного кода на sh.

А в openrc впилили возможность использовать нормальный супервизор вместо кривых и устаревших PID-файлов. В частности, можно использовать runit или s6.

Как я предполагаю, в Artix как раз openrc over runit предлагают задействовать, когда пишут о возможности использовать runit. А может и голый runit, не смотрел еще. В любом случае, это правильнее, чем PID-файлы.

Deleted
()

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

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

А почему бы и не systemd на локалхосте? Я уже больше года не замечаю его, причесали что ли.

Оставлю в стороне вопрос, насколько хорошо его причесали и причесали ли. Факт в том, что не всем нужен systemd. Некоторым даже BSD Init хватит. Или даже того, который продемонстрировал Рич Фелкер.

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

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

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

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

А на сервере кто же будет ставить васянский форк арча?

А обычный арч вы ставите на сервер?

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

Ты про эти с главной страницы:

Server = https://mirror.clarkson.edu/artix-linux/repos/$repo/os/$arch
Server = https://ftp.sh.cvut.cz/artix-linux/$repo/os/$arch
Server = https://ftp.cc.uoc.gr/mirrors/linux/artixlinux/$repo/os/$arch
???
так они и не работают. В iso'шнике тоже дохлые

SR_team ★★★★★
()

Дополнительные настройки, которые могут потребоваться после переезда с Arch:

1. Настроить синхронизацию аппаратных и системных часов (в особенности, если у вас аппаратные часы идут по локальному, а не всемирному времени) :

vim /etc/conf.d/hwclock
rc-update add hwclock boot

2. Чтобы polkit заработал нормально — переустановить его из репозитория artix-а:

pacman -S polkit

3. Чтобы elogind подхватывал сеансы — переустановить pambase из репозитория artix-а:

pacman -S pambase
(Или отредактировать файлы в /etc/pam.d/ вручную, если вы там что-то меняли.)

4. Русский шрифт в VT: отредактировать /etc/conf.d/consolefont.
Русская раскладка в VT: отредактировать /etc/conf.d/keymaps.
Старые настройки можно посмотреть в /etc/vconsole.conf.

Из непобежденного:

  • Сохранение-восстановление уровня подсветки экрана при выключении-включении. (Костылить локальные скипты в /etc неохота, а пакета не нашел. Опакетирую потом какой-нибудь самописный скрипт.)
  • Скрипт для ZRAM, подобный systemd-swap. (Аналогично.)
  • rc-update add ntp-client default успешно добавляет ntp-client в default runlevel, но при перезагрузке синхронизация часов не срабатывает. (В лога нет ничего про ntpdate.) Лень разбираться, забил.
Deleted
()
2 сентября 2018 г.
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.