Вы здесь

Главная › Форум › Gentoo Linux › Настройка рабочих станций

udev или eudev?

5 июня, 2020 - 17:09 — bagas

Привет.
Есть ли смысл перейти на 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.

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

Форум: 
Настройка рабочих станций
5 июня, 2020 - 18:31 — SysA

Есть.

5 июня, 2020 - 18:36 — bagas

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

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

—

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

5 июня, 2020 - 18:42 — SysA

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

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

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

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

5 июня, 2020 - 18:51 — bagas

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

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

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

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

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

—

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

5 июня, 2020 - 19:05 — bagas

Сейчас.

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 системах.

8 июня, 2020 - 10:09 — SysA

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

:)

6 июня, 2020 - 05:41 — hwline

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

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

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

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

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

—

discord: hwline#1904

constantly use: funtoo-linux, ubuntu

6 июня, 2020 - 16:26 — 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 системах.

8 июня, 2020 - 10:43 — SysA

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

2 июля, 2020 - 19:49 — maxsib

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

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

—

maxsib.space

3 июля, 2020 - 09:59 — bagas

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

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

—

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

6 июля, 2020 - 14:06 — SysA

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

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

7 июля, 2020 - 08:29 — Anarchist

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

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

—

:wq
--
Live free or die

7 июля, 2020 - 11:50 — SysA

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

8 июля, 2020 - 21:49 — Kevol

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

Аргументы:

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

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

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

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

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

9 июля, 2020 - 13:24 — SysA

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

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

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

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

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

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

Russian Gentoo Linux Community © 2005—2026
Gentoo — торговая марка Gentoo Foundation, Inc.
Сервер работает под управлением Gentoo Linux
Сайт работает под управлением CMS Drupal