udev или eudev?

Привет.
Есть ли смысл перейти на eudev c udev, для полного отказа от systemd?
Я не использую systemd, использую openrc.
Вот что вижу в логе инициализации железа.

dmesg | egrep 'eth|systemd|net'
[    0.206454] audit: initializing netlink subsys (disabled)
[    0.266728] sky2 0000:02:00.0 eth0: addr 00:5d:8c:2e:4c:2a
[    0.418892] microcode: Microcode Update Driver: v2.01 , Peter Oruba
[    3.859207] systemd-udevd[1882]: /lib/udev/rules.d/80-libinput-device-groups.rules:4 IMPORT key takes '==' or '!=' operator, assuming '==', but please fix it.
[    3.861063] systemd-udevd[1882]: /lib/udev/rules.d/90-libinput-fuzz-override.rules:20 IMPORT key takes '==' or '!=' operator, assuming '==', but please fix it.
[    3.861098] systemd-udevd[1882]: /lib/udev/rules.d/90-libinput-fuzz-override.rules:25 IMPORT key takes '==' or '!=' operator, assuming '==', but please fix it.
[    4.036632] systemd-udevd[1882]: /lib/udev/rules.d/80-libinput-device-groups.rules:4 IMPORT key takes '==' or '!=' operator, assuming '==', but please fix it.
[    4.037444] systemd-udevd[1882]: /lib/udev/rules.d/90-libinput-fuzz-override.rules:20 IMPORT key takes '==' or '!=' operator, assuming '==', but please fix it.
[    4.037467] systemd-udevd[1882]: /lib/udev/rules.d/90-libinput-fuzz-override.rules:25 IMPORT key takes '==' or '!=' operator, assuming '==', but please fix it.
[    4.218027] systemd-udevd[1997]: Using default interface naming scheme 'v243'.
[    4.221420] systemd-udevd[1997]: ethtool: autonegotiation is unset or enabled, the speed and duplex are not writable.
[    4.221572] sky2 0000:02:00.0 enp2s0: renamed from eth0
[    4.264109] systemd-udevd[1997]: eth0: Process 'net.sh enp2s0 start' failed with exit code 1.
[    4.318938] systemd-udevd[1982]: ethtool: autonegotiation is unset or enabled, the speed and duplex are not writable.

Какие плюсы, какие минусы?
Производительность не пострадает?

Есть.

Есть.

SysA

SysA написал(а):
Есть.

Производительность не упадет.
Придется пересобирать весь мир системы?

Что бы ты не делал , жизнь слишком коротка!
Блог о BSD системах.

Нет. Уберешь сыстемд из опций

Нет. Уберешь сыстемд из опций и

emerge -uDNU --with-bdeps=y --backtrack=30 --changed-deps=y --verbose-conflicts @world --keep-going

обновит только зависимости.

P.S. Не забудь потом загрузчик исправить и почистить портаж! ;)

SysA написал(а): Нет. Уберешь

SysA написал(а):
Нет. Уберешь сыстемд из опций и

emerge -uDNU --with-bdeps=y --backtrack=30 --changed-deps=y --verbose-conflicts @world --keep-going

обновит только зависимости.

P.S. Не забудь потом загрузчик исправить и почистить портаж! ;)

По поводу исправить загрузчик и почистить портажи? Не понял.
Загрузчик граб что-ле?
А портажи почистить eclean distfiles?
Удалить старый софт по зависимостям emerge -a --depclean?

Что бы ты не делал , жизнь слишком коротка!
Блог о BSD системах.

Сейчас. emerge sys-fs/eudev

Сейчас.

emerge sys-fs/eudev -av

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild  N     ] sys-fs/eudev-3.2.9::gentoo  USE="hwdb kmod -introspection -rule-generator (-selinux) -static-libs -test" 1 914 KiB
[blocks B      ] sys-fs/udev ("sys-fs/udev" is blocking sys-fs/eudev-3.2.9)

Total: 1 package (1 new), Size of downloads: 1 914 KiB
Conflict: 1 block (1 unsatisfied)

 * Error: The above package list contains packages which cannot be
 * installed at the same time on the same system.

  (sys-fs/udev-243-r2:0/0::gentoo, installed) pulled in by
    sys-fs/udev required by @selected 

  (sys-fs/eudev-3.2.9:0/0::gentoo, ebuild scheduled for merge) pulled in by
    sys-fs/eudev


For more information about Blocked Packages, please refer to the following
section of the Gentoo Linux x86 Handbook (architecture is irrelevant):

https://wiki.gentoo.org/wiki/Handbook:X86/Working/Portage#Blocked_packages

Последовательность действий такая:
1 Удаляем udev emerge -C sys-fs/udev
2 Ставим eudev emerge sys-fs/eudev
3 Дальше обновления зависимостей emerge -uDNU --with-bdeps=y --backtrack=30 --changed-deps=y --verbose-conflicts @world --keep-going
4 После Очистка старых зависимостей портажей emerge -a --depclean

Я вижу такую последовательность действий, верно ли?

Что бы ты не делал , жизнь слишком коротка!
Блог о BSD системах.

Ты забыл

Ты забыл еще
eclean-dist
eclean-pkg

:)

bagas написал(а):Я не

bagas написал(а):
Я не использую systemd, использую openrc.

Помнится мне, была рекомендация переходить с openrc на systemd **или наоборот, я уж не припомню даже )).

Вот тут обсуждение перехода с udev на eudev.

Вообще вот полезная, на мой взгляд, таблица сравнения систем init.

*В Funtoo-linux использую openrc+eudev.

discord: hwline#1904

constantly use: funtoo-linux, ubuntu

hwline написал(а): bagas

hwline написал(а):
bagas написал(а):
Я не использую systemd, использую openrc.

Помнится мне, была рекомендация переходить с openrc на systemd **или наоборот, я уж не припомню даже )).

Вот тут обсуждение перехода с udev на eudev.

Вообще вот полезная, на мой взгляд, таблица сравнения систем init.

*В Funtoo-linux использую openrc+eudev.

Все нормально, перешел на eudev по своей хронологии действий.

1 Удаляем udev emerge -C sys-fs/udev
2 Ставим eudev emerge sys-fs/eudev
3 Дальше обновления зависимостей emerge -uDNU --with-bdeps=y --backtrack=30 --changed-deps=y --verbose-conflicts @world --keep-going
4 После Очистка старых зависимостей портажей emerge -a --depclean
5 revdep-rebuild.sh

Что бы ты не делал , жизнь слишком коротка!
Блог о BSD системах.

Выбирать SystemV или systemD

Выбирать SystemV или systemD - дело личных предпочтений, конечно, но, всё-таки, systemD имеет куда больше возможностей, чем SystemV.
Я сам долгое время держался за SystemV, но когда на новой работе пришлось заниматься systemD, то вскоре и для себе перешёл на неё.
В наше время я уже не вижу реальных аргументов против systemD, кроме как некоторой избыточности. И да, порог вхождения для SystemV весьма высок, с любительским подходом все сложно, нелогично и непонятно, но когда разберёшься, то все встаёт на свои места и вся система становится проще, понятней, лучше автоматизируется и, как следствие, становится более надёжной.

SysA написал(а):Выбирать

SysA написал(а):
Выбирать SystemV или systemD - дело личных предпочтений, конечно, но, всё-таки, systemD имеет куда больше возможностей, чем SystemV.
Я сам долгое время держался за SystemV, но когда на новой работе пришлось заниматься systemD, то вскоре и для себе перешёл на неё.
В наше время я уже не вижу реальных аргументов против systemD, кроме как некоторой избыточности. И да, порог вхождения для SystemV весьма высок, с любительским подходом все сложно, нелогично и непонятно, но когда разберёшься, то все встаёт на свои места и вся система становится проще, понятней, лучше автоматизируется и, как следствие, становится более надёжной.

gentoo & systemd..
это какой-то .. позор?? (Швондер)
Если все уйдут на сюстемдэ я точно уйду на слаку

maxsib26874.xyz

maxsib написал(а):SysA

maxsib написал(а):
это какой-то .. позор?? (Швондер)

)))
Так и есть!

Что бы ты не делал , жизнь слишком коротка!
Блог о BSD системах.

А по делу аргументы есть?

maxsib написал(а):
...
gentoo & systemd..
это какой-то .. позор?? (Швондер)
Если все уйдут на сюстемдэ я точно уйду на слаку

А, кроме понтов, по делу аргументы есть? ;)

/

SysA написал(а):
А, кроме понтов, по делу аргументы есть? ;)

Ну дык: какие аргументы за systemd, такие и против… ☺

:wq
--
Live free or die

Не уподобляйся понтовой школоте

Не уподобляйся понтовой школоте - избегай словоблудия в техническом обсуждении.
В своём сообщении ранее я резюмировал аргументы за и немного против. Добавить есть чего? ;)

. лично мой взгляд

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

Аргументы:

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

Второстепенный аргумент, это постепенное лишение владельца прав на доступ к своей собственности. Чем это своими принципами отличается от тивоизации?

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

Если бы первый аргумент был противоположным, то и для последнего не было бы места.

Gentoo практически единственный выбор, для тех кому systemd не по душе, для тех кто не желает состоять в конфронтации. Это возможность новым пользователям linux понять, что systemd не единственная система инициализации (и еще несколько позиций отсюда вытекающих).
Думаю, если в Gentoo первичным станет systemd, то дистрибутив перестанет существовать по второму агрументу. (Где-то в районе обеспечения просмотра DRM-контента)

Очень интересный подход

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

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

В детстве мы своими руками собирали детекторные приёмники, а потом ламповые и транзисторные из отдельных деталей, но кто это делает сейчас?! В лучшем случае - взять и спаять несколько микросхем, и любое (радио)электронное устройство готово. Также и с автомобилями - практически невозможно отремонтировать современный автомобиль в домашних условиях, а во времена СССР это было практически нормой...

Также и в современном ИТ мире... К примеру, наша компания более 20 лет использовала Генту везде и всюду... поначалу с SystemV-подобной инициализацией и chroot подсистемами, но с появлением systemd-контейнеров мы перешли на systemd, потому что появилась возможность строить инфраструктуру более гибкой и экономичной - у нас было 4 датацентра, а стало 3, но сложность, производительность и количество сервисов значительно увеличилось на том же железе!

С прошлого года после поглощения нашей компании более крупным игроком на рынке началась миграция в облака... сейчас виртуальные КВМ-хосты для контейнеров уже не на Генту, поскольку их технологически сложно создавать и поддерживать, но сами контейнеры все еще на systemd/Gentoo, поскольку systemd/Gentoo лучше конфигурируется и управляется, а потому внутренняя инфраструктура нашего продукта (SaaS) сильно на неё завязана. Но уже очевидно, что Генту в контейнерах тоже умрёт, потому как в корпоративном мире Генту не живёт из-за сложности поддержки и более высоких требований к квалификации администраторов. Но сам предмет разговора - systemd прекрасно вписывается в корпоративную инфраструктуру!

Поэтому, на мой взгляд, SystemV-подобная инициализация имеет место быть на десктопах энтузиастов-фанатиков (у меня Генту везде: и на десктопах, и на ноутбуке, и даже на нетбуке!), а также какое-то время на встроенных устройствах типа смартфонов, домашних маршрутизаторов и прочих штуках, где важно хоть сколь-нибудь сэкономить память, но в целом она уже обречена, к сожалению. Также как и Генту, пожалуй... у них нет места в будущем динамичном мире, когда никто не может себе позволить долго возиться с индивидуальной настройкой чего бы то ни было... разве что для хобби...

Настройки просмотра комментариев

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