udev или eudev?
bagas 5 июня, 2020 - 18:09
Привет.
Есть ли смысл перейти на 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
Производительность не упадет.
Придется пересобирать весь мир системы?
Что бы ты не делал , жизнь слишком коротка!
Блог о BSD системах.
Нет. Уберешь сыстемд из опций
Нет. Уберешь сыстемд из опций и
обновит только зависимости.
P.S. Не забудь потом загрузчик исправить и почистить портаж! ;)
SysA написал(а): Нет. Уберешь
По поводу исправить загрузчик и почистить портажи? Не понял.
Загрузчик граб что-ле?
А портажи почистить eclean distfiles?
Удалить старый софт по зависимостям emerge -a --depclean?
Что бы ты не делал , жизнь слишком коротка!
Блог о BSD системах.
Сейчас. emerge sys-fs/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
Я вижу такую последовательность действий, верно ли?
Что бы ты не делал , жизнь слишком коротка!
Блог о BSD системах.
Ты забыл
Ты забыл еще
eclean-dist
eclean-pkg
:)
bagas написал(а):Я не
Помнится мне, была рекомендация переходить с openrc на systemd **или наоборот, я уж не припомню даже )).
Вот тут обсуждение перехода с udev на eudev.
Вообще вот полезная, на мой взгляд, таблица сравнения систем init.
*В Funtoo-linux использую openrc+eudev.
discord: hwline#1904
constantly use: funtoo-linux, ubuntu
hwline написал(а): bagas
Все нормально, перешел на eudev по своей хронологии действий.
Что бы ты не делал , жизнь слишком коротка!
Блог о BSD системах.
Выбирать SystemV или systemD
Выбирать SystemV или systemD - дело личных предпочтений, конечно, но, всё-таки, systemD имеет куда больше возможностей, чем SystemV.
Я сам долгое время держался за SystemV, но когда на новой работе пришлось заниматься systemD, то вскоре и для себе перешёл на неё.
В наше время я уже не вижу реальных аргументов против systemD, кроме как некоторой избыточности. И да, порог вхождения для SystemV весьма высок, с любительским подходом все сложно, нелогично и непонятно, но когда разберёшься, то все встаёт на свои места и вся система становится проще, понятней, лучше автоматизируется и, как следствие, становится более надёжной.
SysA написал(а):Выбирать
gentoo & systemd..
это какой-то .. позор?? (Швондер)
Если все уйдут на сюстемдэ я точно уйду на слаку
maxsib.space
maxsib написал(а):SysA
)))
Так и есть!
Что бы ты не делал , жизнь слишком коротка!
Блог о BSD системах.
А по делу аргументы есть?
А, кроме понтов, по делу аргументы есть? ;)
/
Ну дык: какие аргументы за 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-подобная инициализация имеет место быть на десктопах энтузиастов-фанатиков (у меня Генту везде: и на десктопах, и на ноутбуке, и даже на нетбуке!), а также какое-то время на встроенных устройствах типа смартфонов, домашних маршрутизаторов и прочих штуках, где важно хоть сколь-нибудь сэкономить память, но в целом она уже обречена, к сожалению. Также как и Генту, пожалуй... у них нет места в будущем динамичном мире, когда никто не может себе позволить долго возиться с индивидуальной настройкой чего бы то ни было... разве что для хобби...