Наоборот, ALT-овцы молодцы, правильно сделали, как и Gentoo-шники.
Arch Linux/Xfce/Xiaomi Mi Notebook Pro 15.6 | Slackware64-current/Xfce/Lenovo G580
Настоятельно просим вас при общении соблюдать Правила форума и законы РФ. Наша тематика вне политики, поэтому воздержитесь от обсуждения ситуации на Украине и связанных с ней событий, независимо от того, какую сторону вы поддерживаете.
Также напоминаем, что наш форум находится в доменной зоне .ru, физически расположен на российских серверах и мы соблюдаем действующее законодательство России. Любые сообщения о политике будут удаляться.
Linux Forum → «Священные войны» → Systemd - лучшая система инициализации!!!!11
Страницы Назад 1 … 5 6 7 8 9 10 11 Далее
Чтобы отправить ответ, вы должны войти или зарегистрироваться
Наоборот, ALT-овцы молодцы, правильно сделали, как и Gentoo-шники.
Ну флаг им в руки. Молодцы, ни кто не спорит.
Я лишь сказал, что другие не сделают так. Но Альт не захватит мир.
redix пишет:Vascom, а что, Альт уже в нормальных ходит?
В том-то и дело что нет. Потому я так и написал, что нормальные не будут делать как Альт.
lone_wolf, вернуть eth0 - дело двух секунд. Если это проблема, то стоит начать изучение с чего-то попроще.
ну как 1 из вариантов через ip2route переименовать а потом при перезагрузке переименовывать через crontab
так что я не настолько глупый как может показатся 
вернуть eth0 - дело двух секунд
ну раз так если не затруднит то расскажите пожалуйста как это сделать за 2 секунды буду очень признателен
а может не я 1 
Наверное, многие помнят в книге Д. Свифта «Путешествия Лемюэля Гулливера» ситуацию с войной в Лилипутии из-за разногласий по поводу того, с острой или с тупой стороны разбивать вареные яйца. Изначально было принято разбивать яйца с тупого конца. Но однажды наследник трона порезал себе палец, разбивая яйцо. И тогда император издал указ, что отныне яйца можно разбивать только с острого конца, тем же, кто ослушается, грозила смертная казнь. И тогда все недовольные этим указом подняли восстание, которое в итоге переросло в религиозную войну между государствами Лилипутией и Блефуску.
А..... Ничего не напоминает?
lone_wolf, лень 
Тем более ты уже нашёл выход из ситуации. Значит всё можем, если захотим.
Нормальные дистрибутивы так делать не будут.
Предоставлять пользователю выбор между хорошей современной системой инициализации и sysV.
Ишь чего придумали, еще какой-то выбор пользователю предоставить. "Все правильно".
Хотя дайте подумать, кого-то мне это напоминает... Ах да, майкрософт и эпл. Там тоже всегда лучше знают что нужно каждому отдельному пользователю.
Будь systemd хоть и того современней, называть ненормальными все дистрибутивы, пытающиеся предоставить пользователю выбор (при что ты же не изучал потребности каждого пользователя и не знаешь критериев выбора для каждого), это явный перегиб палки. Без обид, но берешь на себя лишнего. Не тебе судить о нормальности и ненормальности в данном контексте, потому что ты смотришь сугубо с одной стороны на вопрос, со стороны прогресса, но на твоей позиции свет клином не сходится, и по этому, не тебе судить.
p.s. это не камень в огород systemd, а размышления на тему вечного спора "ненужно и нужно".
lone_wolf, лень
Тем более ты уже нашёл выход из ситуации. Значит всё можем, если захотим.
эх жаль конечно... но хозяин барин 
Vascom пишет:Нормальные дистрибутивы так делать не будут.
Vascom пишет:Предоставлять пользователю выбор между хорошей современной системой инициализации и sysV.
Ишь чего придумали, еще какой-то выбор пользователю предоставить. "Все правильно".
Хотя дайте подумать, кого-то мне это напоминает... Ах да, майкрософт и эпл. Там тоже всегда лучше знают что нужно каждому отдельному пользователю.Будь systemd хоть и того современней, называть ненормальными все дистрибутивы, пытающиеся предоставить пользователю выбор (при что ты же не изучал потребности каждого пользователя и не знаешь критериев выбора для каждого), это явный перегиб палки. Без обид, но берешь на себя лишнего. Не тебе судить о нормальности и ненормальности в данном контексте, потому что ты смотришь сугубо с одной стороны на вопрос, со стороны прогресса, но на твоей позиции свет клином не сходится, и по этому, не тебе судить.
p.s. это не камень в огород systemd, а размышления на тему вечного спора "ненужно и нужно".
Все дистрибутивы, пытающиеся предоставить пользователю выбор из всего что есть, делают это плохо. Сил у них не хватает.
К тому же одно дело предоставлять выбор из равноценных (или почти) компонентов, например Гном, КДЕ, XFCE и такими разными вещами как sysV и systemd. Надо понимать разницу.
Пока что никто мне не смог объяснить что же за "катастрофические ситуации" привели к этим переменам.
а если объяснять, слушать будете? Моя основная проблема с init и ethX в том что начинает твориться когда в сервера больше 20 интерфейсов.
а когда их больше сотни, начинается кромешный ад, причем при каждой перезагрузке он становится все хуже. А если интерфейсы динамически цепляются и отцепляются, то RHEL5 и все что работает по тому же принципу вообще уходят в полную несознанку, а свежая федора пашет как часы.
хотите сказать что столько интерфейсов не бывает? тогда я вас удивлю.
Все дистрибутивы, пытающиеся предоставить пользователю выбор из всего что есть, делают это плохо. Сил у них не хватает.
А свечку держали?
тому же одно дело предоставлять выбор из равноценных (или почти) компонентов, например Гном, КДЕ, XFCE и такими разными вещами как sysV и systemd. Надо понимать разницу.
Конечно, надо понимать разницу. :SARCASM
Будь systemd хоть и того современней, называть ненормальными все дистрибутивы, пытающиеся предоставить пользователю выбор
выбор между плохим и ужасным не есть выбор
это иллюзия выбора...
а если объяснять, слушать будете?
С удовольствием.
Моя основная проблема с init и ethX в том что начинает твориться когда в сервера больше 20 интерфейсов.
а когда их больше сотни, начинается кромешный ад, причем при каждой перезагрузке он становится все хуже. А если интерфейсы динамически цепляются и отцепляются, то RHEL5 и все что работает по тому же принципу вообще уходят в полную несознанку, а свежая федора пашет как часы.
Обозначена конкретная проблема возникавшая со старыми наименованиями и решаемая новыми.
Спасибо за конкретный вменяемый ответ.
А то все приводят два аргумента вроде "red hat" и "современная". Но если спросить, в чем плюсы этой "современности", по факту, какие возникшие ранее проблемы она решает, не говорят.
xxblx пишет:Пока что никто мне не смог объяснить что же за "катастрофические ситуации" привели к этим переменам.
а если объяснять, слушать будете? Моя основная проблема с init и ethX в том что начинает твориться когда в сервера больше 20 интерфейсов.
а когда их больше сотни, начинается кромешный ад, причем при каждой перезагрузке он становится все хуже. А если интерфейсы динамически цепляются и отцепляются, то RHEL5 и все что работает по тому же принципу вообще уходят в полную несознанку, а свежая федора пашет как часы.хотите сказать что столько интерфейсов не бывает? тогда я вас удивлю.
спасибо за четкое пояснение и пример, но у меня возникает только 1 вопрос а как же привязка к маку ? 
Ну флаг им в руки. Молодцы, ни кто не спорит.
Я лишь сказал, что другие не сделают так. Но Альт не захватит мир.
Точно не захватит. После их безбожной кастрации ACC и вообще-то странным обращением с systemctl. Поставила ради прикола Centauros 7 platform, так и снесла - тоска и глюки. Возникает нехорошее ощущение, что Alt двинулся тропою ROSA...
спасибо за четкое пояснение и пример, но у меня возникает только 1 вопрос а как же привязка к маку ?
ее недостаточно. проблема в том, что обычно в серверах, пихают дикую мешанину из карточек - broadcom на мамке, разные интели в паре медленных слотов, 10g интели, мелланоксы, челси, циски... плюс версии, прошивки, варианты... все эти kmod-ы грузятся медленно, и на тот момент когда init доходит до загрузки сети, модули еще не загружены. Это значит что после загрузки сервера надо как минимум рестартовать network, и обычно еще и udevadm trigger
А если у меня UCS, с динамически цепляемыми интерфейсами, которые меняют маки в зависимости от задач, то init с udev-ом начинают слегка офигевать.
Теперь представяем вполне типичную для таких масштабов систему, где несколько сотен блейдов с такими вот динамичными интерфейсами, постоянно поднимают из темплейта ВМ, цепляют к ней нужные интерфейсы через VMFEX, по несколько десятков на каждую, закачивают данные, ВМ их обрабатывает, возвращает, и ее убивают чтоб поднять другую. Все это происходит очень быстро, за сутки в нашем ДЦ например "оборот" - 15-20 тысяц виртуалок. Ждать пока отработает udev и network service никто не может, скорость загрузки очень важна, потому что все это - финансовые данные для практически всех банков континента.
для этого можно нагородить отдельное решение, да, но если это решение работает хорошо и для простого хоста без диких требований, упрощает целую кучу аспектов, ускоряет загрузку, и дает возможность масштабироваться, то почему бы и нет?
я еще раз повторяю - системд и прочие наработки RHT это не "а давайте всех поработим" или "а давайте все сломаем" как кажется обывателям. Это результат долгой работы и многолетнего опыта, плюс очень тесное общение с клиентурой, которая гораздо лучше тех же обывателей понимает где система не справляется с задачей и какие именно проблемы надо решать.
А если у меня UCS, с динамически цепляемыми интерфейсами, которые меняют маки в зависимости от задач, то init с udev-ом начинают слегка офигевать.
Ага, слышал звон, да не знал, где он. По-вашему, включенный в systemd код udev не офигевает, да? Офигевает, ровно так же. Зато удобочитаемые имена теперь надо ручками возвращать. Прогресс, ага.
Ага, слышал звон, да не знал, где он.
дада, конечно, куда уж нам, сирым и убогим...
По-вашему, включенный в systemd код udev не офигевает, да? Офигевает, ровно так же. Зато удобочитаемые имена теперь надо ручками возвращать. Прогресс, ага.
конечно офигевает, но не ставит всю систему раком. эти "страшные" имено легко парсятся, и хост цепляет их к виртуалке на заранее заданные слоты, так что можно заранее знать какой интерфейс проброшен в какую сеть, просто по его имени.
yars, это для человека кажутся такие имена сложнее. Но для автоматики - это намного проще, тем более, что имя не меняется от загрузки к загрузке, как происходит с обычными eth0.
А полный автоматизм - разве не наша цель? Разгрузить человека от рутинной работы.
Вот у меня на рабочем компе (не сервер) две сетевухи, подключена одна. И мне было неудобно, что имя у неё рандомно было то eth0, то eth1. А сейчас всё чётко и понятно, однозначно.
Это если и было, то меня не коснулось. Да и вообще, это была проблема криво написанных правил udev. Вот этого как минимум.
ls -1 /lib/udev/rules.d/
75-persistent-net-generator.rulescat /lib/udev/rules.d/75-persistent-net-generator.rules
# do not edit this file, it will be overwritten on update
# these rules generate rules for persistent network device naming
#
# variables used to communicate:
# MATCHADDR MAC address used for the match
# MATCHID bus_id used for the match
# MATCHDRV driver name used for the match
# MATCHIFTYPE interface type match
# COMMENT comment to add to the generated rule
# INTERFACE_NAME requested name supplied by external tool
# INTERFACE_NEW new interface name returned by rule writer
ACTION!="add", GOTO="persistent_net_generator_end"
SUBSYSTEM!="net", GOTO="persistent_net_generator_end"
# ignore the interface if a name has already been set
NAME=="?*", GOTO="persistent_net_generator_end"
# device name whitelist
KERNEL!="eth*|ath*|wlan*[0-9]|msh*|ra*|sta*|ctc*|lcs*|hsi*", GOTO="persistent_net_generator_end"
# ignore Xen virtual interfaces
SUBSYSTEMS=="xen", GOTO="persistent_net_generator_end"
# read MAC address
ENV{MATCHADDR}="$attr{address}"
# match interface type
ENV{MATCHIFTYPE}="$attr{type}"
# ignore KVM virtual interfaces
ENV{MATCHADDR}=="52:54:00:*", GOTO="persistent_net_generator_end"
# ignore VMWare virtual interfaces
ENV{MATCHADDR}=="00:0c:29:*|00:50:56:*", GOTO="persistent_net_generator_end"
# ignore Hyper-V virtual interfaces
ENV{MATCHADDR}=="00:15:5d:*", GOTO="persistent_net_generator_end"
# These vendors are known to violate the local MAC address assignment scheme
# Interlan, DEC (UNIBUS or QBUS), Apollo, Cisco, Racal-Datacom
ENV{MATCHADDR}=="02:07:01:*", GOTO="globally_administered_whitelist"
# 3Com
ENV{MATCHADDR}=="02:60:60:*", GOTO="globally_administered_whitelist"
# 3Com IBM PC; Imagen; Valid; Cisco; Apple
ENV{MATCHADDR}=="02:60:8c:*", GOTO="globally_administered_whitelist"
# Intel
ENV{MATCHADDR}=="02:a0:c9:*", GOTO="globally_administered_whitelist"
# Olivetti
ENV{MATCHADDR}=="02:aa:3c:*", GOTO="globally_administered_whitelist"
# CMC Masscomp; Silicon Graphics; Prime EXL
ENV{MATCHADDR}=="02:cf:1f:*", GOTO="globally_administered_whitelist"
# Prominet Corporation Gigabit Ethernet Switch
ENV{MATCHADDR}=="02:e0:3b:*", GOTO="globally_administered_whitelist"
# BTI (Bus-Tech, Inc.) IBM Mainframes
ENV{MATCHADDR}=="02:e6:d3:*", GOTO="globally_administered_whitelist"
# Realtek
ENV{MATCHADDR}=="52:54:00:*", GOTO="globally_administered_whitelist"
# Novell 2000
ENV{MATCHADDR}=="52:54:4c:*", GOTO="globally_administered_whitelist"
# Realtec
ENV{MATCHADDR}=="52:54:ab:*", GOTO="globally_administered_whitelist"
# Kingston Technologies
ENV{MATCHADDR}=="e2:0c:0f:*", GOTO="globally_administered_whitelist"
# Xensource
ENV{MATCHADDR}=="00:16:3e:*", GOTO="globally_administered_whitelist"
# match interface dev_id
ATTR{dev_id}=="?*", ENV{MATCHDEVID}="$attr{dev_id}"
# do not use "locally administered" MAC address
ENV{MATCHADDR}=="?[2367abef]:*", ENV{MATCHADDR}=""
# do not use empty address
ENV{MATCHADDR}=="00:00:00:00:00:00", ENV{MATCHADDR}=""
LABEL="globally_administered_whitelist"
# build comment line for generated rule:
SUBSYSTEMS=="pci", ENV{COMMENT}="PCI device $attr{vendor}:$attr{device} ($driver)"
SUBSYSTEMS=="usb", ATTRS{idVendor}=="?*", ENV{COMMENT}="USB device 0x$attr{idVendor}:0x$attr{idProduct} ($driver)"
SUBSYSTEMS=="pcmcia", ENV{COMMENT}="PCMCIA device $attr{card_id}:$attr{manf_id} ($driver)"
SUBSYSTEMS=="ieee1394", ENV{COMMENT}="Firewire device $attr{host_id})"
# ibmveth likes to use "locally administered" MAC addresses
DRIVERS=="ibmveth", ENV{MATCHADDR}="$attr{address}", ENV{COMMENT}="ibmveth ($id)"
# S/390 uses id matches only, do not use MAC address match
SUBSYSTEMS=="ccwgroup", ENV{COMMENT}="S/390 $driver device at $id", ENV{MATCHID}="$id", ENV{MATCHDRV}="$driver", ENV{MATCHADDR}=""
# see if we got enough data to create a rule
ENV{MATCHADDR}=="", ENV{MATCHID}=="", ENV{INTERFACE_NAME}=="", GOTO="persistent_net_generator_end"
# default comment
ENV{COMMENT}=="", ENV{COMMENT}="net device ($attr{driver})"
# write rule
DRIVERS=="?*", IMPORT{program}="write_net_rules"
# rename interface if needed
ENV{INTERFACE_NEW}=="?*", NAME="$env{INTERFACE_NEW}"
LABEL="persistent_net_generator_end"А, по-вашему, почему сейчас не бегают интерфейсы? Код systemd-udev и udev одинаков, правила только различаются...
Ну повезло раз не коснулось. Теперь с этим проблем точно ни у кого нет. А автоматике, как сказали выше - даже лучше стало.
+ открыть спойлерlone_wolf пишет:спасибо за четкое пояснение и пример, но у меня возникает только 1 вопрос а как же привязка к маку ?
ее недостаточно. проблема в том, что обычно в серверах, пихают дикую мешанину из карточек - broadcom на мамке, разные интели в паре медленных слотов, 10g интели, мелланоксы, челси, циски... плюс версии, прошивки, варианты... все эти kmod-ы грузятся медленно, и на тот момент когда init доходит до загрузки сети, модули еще не загружены. Это значит что после загрузки сервера надо как минимум рестартовать network, и обычно еще и udevadm trigger
А если у меня UCS, с динамически цепляемыми интерфейсами, которые меняют маки в зависимости от задач, то init с udev-ом начинают слегка офигевать.
Теперь представяем вполне типичную для таких масштабов систему, где несколько сотен блейдов с такими вот динамичными интерфейсами, постоянно поднимают из темплейта ВМ, цепляют к ней нужные интерфейсы через VMFEX, по несколько десятков на каждую, закачивают данные, ВМ их обрабатывает, возвращает, и ее убивают чтоб поднять другую. Все это происходит очень быстро, за сутки в нашем ДЦ например "оборот" - 15-20 тысяц виртуалок. Ждать пока отработает udev и network service никто не может, скорость загрузки очень важна, потому что все это - финансовые данные для практически всех банков континента.
для этого можно нагородить отдельное решение, да, но если это решение работает хорошо и для простого хоста без диких требований, упрощает целую кучу аспектов, ускоряет загрузку, и дает возможность масштабироваться, то почему бы и нет?
я еще раз повторяю - системд и прочие наработки RHT это не "а давайте всех поработим" или "а давайте все сломаем" как кажется обывателям. Это результат долгой работы и многолетнего опыта, плюс очень тесное общение с клиентурой, которая гораздо лучше тех же обывателей понимает где система не справляется с задачей и какие именно проблемы надо решать.
понял спасибо, да соглашусь под такие нагрузки systemd удобней.
Ну а нам обывателям придется 1 раз заморочится чтобы переименовать интерфейс как нам понравится
Кстати кто подскажет как это проше сделать ?
Кстати кто подскажет как это проше сделать ?
Пойдемте в отдельную тему 
Ну а нам обывателям придется 1 раз заморочится чтобы переименовать интерфейс как нам понравится
...и пересобирать systemd, когда требуется поддержка отдельного /usr 
Пойдемте в отдельную тему
идем
(кто создает ?)
Присоединился к рядам поклонников systemd! Он крут!
yars пишет:Пойдемте в отдельную тему
идем
(кто создает ?)
Ну, давайте вы =)
dyasny - может поменять админа ?
dyasny - может поменять админа ?
в смысле?
форум разделился на два лагеря.
одним консерватизм подавай, другим систэмДЭ.
когда уже война начнется? 
Страницы Назад 1 … 5 6 7 8 9 10 11 Далее
Чтобы отправить ответ, вы должны войти или зарегистрироваться
Linux Forum → «Священные войны» → Systemd - лучшая система инициализации!!!!11
Форум работает на PunBB, при поддержке Informer Technologies, Inc