Леннарт Поттеринг (Lennart Poettering) представил (http://lists.freedesktop.org/archives/systemd-devel/2013-Jan...) релиз системного менеджера systemd 197 (http://www.freedesktop.org/software/systemd/), примечательный использованием нового механизма предсказуемого именования сетевых интерфейсов, интеграцией функциональности пакета bootchart, оптимизациями для увеличения скорости загрузки на разделах с Btrfs, уходом от использования особенностей, специфичных для конкретных дистрибутивов.
Systemd сочетающет в себе функции системы инициализации, механизм для контроля за выполнением фоновых процессов, службу для журналирования событий и средства для управления сервисами, сеансами пользователей и подключаемыми устройствами. Для определения парметров сервисов в Systemd используется набор конфигурационных unit-файлов, вместо оформления сценариев запуска в виде shell-скриптов. Система (https://www.opennet.ru/opennews/art.shtml?num=26447) нацелена (https://www.opennet.ru/opennews/art.shtml?num=27218) на интенсивную параллелизацию выполнения сервисов на этапе загрузки системы, вобрав в себя лучшие черты таких систем, как launchd (Mac OS X), SMF (Solaris) и Upstart (Ubuntu, старые версии Fedora). В настоящее время на использование systemd уже перешли такие дистрибутивы, как Fedora, openSUSE, Mandriva и Arch Linux.
Из наиболее интересных новшеств можно отметить:- Systemd теперь позиционируется как полностью обособленная и независящая от Linux-дистрибутиов система. Из состава Systemd исключён код для определения и задействования возможностей и файлов конфигурации, специфичных для отдельных дистрибутивов. Вместо использования собственных файлов конфигурации разработчикам дистрибутивов предлагается использовать предлагаемую Systemd стандартную модель управления конфигурацией, на которую уже перешло большинство использующих Systemd дистрибутивов. Тем не менее, многие из специфичных возможностей остаются доступны через активацию соответствующих настроек через скрипт configure на этапе сборки.
- В udev добавлена поддержка различных схем (http://www.freedesktop.org/wiki/Software/systemd/Predictable...) предсказуемого выбора имён для сетевых интерфейсов, при которых сетевому адаптеру назначается фиксированное имя, которое не измениться при добавлении/удалении других адаптеров. По умолчанию мена устройств будут формироваться в зависимости от возможностей прошивки. Если прошивка/BIOS предоставляет интексированные номера интерфейсов для встроенных сетевых интерфейсов будет использовано имя "enoN", а для PCI-плат - "ensN". Иначе будет выбрано именование enpNsM, учитывающее физическое соединение устройства, а если параметры подобного размещения будут недоступны - будет использована классическая схема ethX. Кроме того, для использования доступен вариант использования в имени интерфейса данных из MAC-адреса (например, enx78e7d1ea46da);
- В состав включена альтернативная (https://github.com/sofar/bootchart) минималистичная реализация утилиты bootchart, созданная Auke Kok (https://plus.google.com/u/1/115124063126128475540/posts) из компании Intel. Bootchart позволяет измерить и наглядно оценить время загрузки различных компонентов системы;
- Логика упреждающей загрузки компонентов адаптирована для определения и использования особенностей файловой системы Btrfs, в том числе с использованием оптимизаций как для SSD-накопителей, так и для жестких дисков;
- Поддержка вызова системных событий в привязке к календарному времени, а не только к повторяющимся интервалам времени. В частности, можно инициировать запуск unit-а в заданное время, указав в параметрах, например, "Thu,Fri 2013-*-1,5 11:12:13" для запуска в 11 часов 12 минут 13 секунд кажный первый и пятый день месяца в 2013 году, при условии, что эти дни приходятся на четверг или патницу. С поддержкой данной возможности Systemd уже позволяет взять на себя большинство функций системы cron и избавиться от необходимости запуска дополнительного демона crond;
URL: http://lists.freedesktop.org/archives/systemd-devel/2013-Jan...
Новость: https://www.opennet.ru/opennews/art.shtml?num=35789
Пока нет злобных комментариев... Перешёл на Arch с уже установленным systemd. Суперовая штука! Претензий ноль, просто новые команды выучить пришлось. Зато скорость загрузки - огогошная!
Меня больше впечатлило время выключения :D
> Меня больше впечатлило время выключения :Dвот это действительно вин. тоже сижу на арчике с системд - ноут отключается секунды за 2-3.
Это достижение!!! А у меня на компе uptime 2 недели, как жить?!
Компутер с собой удобно таскать? О существовании ноут/нет-буков не слышали?
>Компутер с собой удобно таскать? О существовании ноут/нет-буков не слышали?Ёпта, нетбук Ecafe. Аптайм 4 месяца. ШЯДНТ?
>>Компутер с собой удобно таскать? О существовании ноут/нет-буков не слышали?
> Ёпта, нетбук Ecafe. Аптайм 4 месяца. ШЯДНТ?Ядро не обновляете.
>>>Компутер с собой удобно таскать? О существовании ноут/нет-буков не слышали?
>> Ёпта, нетбук Ecafe. Аптайм 4 месяца. ШЯДНТ?
> Ядро не обновляете.Может погуглить "обновление ядра линукс без перезагрузки"?
>>>>Компутер с собой удобно таскать? О существовании ноут/нет-буков не слышали?
>>> Ёпта, нетбук Ecafe. Аптайм 4 месяца. ШЯДНТ?
>> Ядро не обновляете.
> Может погуглить "обновление ядра линукс без перезагрузки"?Погуглите ) У вас видать Oracle Linux на нетбуке ) Тада вам systemd в ближайшее время не грозит.
Погугли, но тебе это вряд-ли поможет.
> Ядро не обновляете.kexec жеш
>> Ядро не обновляете.
> kexec жешkexec сбрасывает uptime, по крайней мере тот, о котором речь
Нахера мне нужна флешка с экраном!
> Нахера мне нужна флешка с экраном!Тебе не знаю, а мне как раз надо нечто размером с флешку + экран.
> Это достижение!!! А у меня на компе uptime 2 недели, как жить?!Купи нотик и попробуй потаскать с собой. Не забудь рассказать про аптайм в 2 недели, ага. Если время кормления от розетки не пробакланишь.
ноут чудесно засыпает автоматически при низком заряде аккумулятора
> ноут чудесно засыпает автоматически при низком заряде аккумулятораДа, только я предпочитаю STR. А при низком заряде он не долго живет, увы. А suspend to disk у меня простите вкалывает дольше чем систему с нуля запустить.
> Да, только я предпочитаю STR. А при низком заряде он не долго живет, увыразберитесь со своим железом.
у меня на убитой батарее работает до двух минут. суспенд же эта батарея держит порядка суток (на большее время ноут не забрасывал)
>> Это достижение!!! А у меня на компе uptime 2 недели, как жить?!
> Купи нотик и попробуй потаскать с собой. Не забудь рассказать про аптайм
> в 2 недели, ага. Если время кормления от розетки не пробакланишь.Ноутбуки как раз нередко месяцами наматывают, пока не:
- пробакланю;
- обновлю ядро;
- заклинит на выходе из suspend (особенно этим грешили PAE-ядра).
Как почитаешь новости создается впечатление что все только и делают что включают и выключают комп.
Ну если не сервер, то можно и включать-выключать. Для нелюбителй спящих режимов - вполне актуально, например.
Хе-хе, вопрос из танка: а возможно без инитрамфс взлететь? С системд на борту?
> Хе-хе, вопрос из танка: а возможно без инитрамфс взлететь? С системд на борту?да, конечно.
> да, конечно.А ссылочкой не поделитесь на success story for dummies? А то в гугле забанили.
>> да, конечно.
> А ссылочкой не поделитесь на success story for dummies? А то в гугле забанили.если exherbo ставить по гайду, как раз получится линукс с systemd без initramfs.
% cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-3.2.23-eee root=/dev/sda1 ro rootfstype=ext4 init=/bin/systemd quiet
% apt-cache policy systemd
systemd:
Установлен: 44-7
Кандидат: 44-7
Таблица версий:
*** 44-7 0
500 http://mirror.yandex.ru/debian/ sid/main i386 Packages
100 /var/lib/dpkg/status
> % cat /proc/cmdline
> BOOT_IMAGE=/boot/vmlinuz-3.2.23-eee root=/dev/sda1 ro rootfstype=ext4 init=/bin/systemd quietrootfstype=ext4 - о да ... на еее ext4 просто необходимо!
А что не так?
фс с журналом не стоит ставить на eeepc ssd
хотя есть версии и с винтом
>хотя есть версии и с винтомВот у меня как раз такой - с нормальным винтом. А флешки-переростки мне нужны примерно так же, как сабж.
> да ... на еее ext4 просто необходимо!И что бы посоветовал наш маэстро?
>> да ... на еее ext4 просто необходимо!
> И что бы посоветовал наш маэстро?Всяки разны махонькие девайся я reiser3 форматирую.
А если предполагается файловый обмен равный почти нулю, то ext2
можно если только у вас /usr не на отдельно разделе, тогда траблы
подтверждаю. в Арче просто взяв стандартный конфиг ядра указал ещё вкомпилить, то что относится к моему sata контроллеру (lspci -k) и файлсистеме, собрал, завёлся без проблем
У меня арч 2010 года с иксами и рабочей программой, готова к работе через 15 секунд после включения питания. Настройка свелась к удалению из инитов ненужных частей кода, но больше всего время сократилось за счёт удаление искусственных слипов.
> работе через 15 секунд после включения питания.А у меня бyбунта взлетает за 5 секунд. Мне так больше нравится.
Slackware с sysvinit стартует за 7-10 секунд, где 3-6 из них тратятся на инициализацию сетевой карты, загрузки пары демонов и монтирование разделов.
И то, это еще из-за винчестера в 5400RPM. На стационаре 7200RPM стартует где-то за 4-7 секунд. А если 10000RPM, так еще быстрее будет.
> А если 10000RPM, так еще быстрее будет.А не проще под системный диск SSD взять? 10K RPM винты - жручие и шумные, что для дома как-то мазохистично весьма.
Вытащи голову из системника. Зачем ты ее туда засунул?
Странно. Я 1 не заметил ускорения загрузки при переходе на системд?
Комп и ноут грузятся очень медленно. Больше минуты и тот и этот, хотя по скорости всех комплектующих раз в 5 отличаются. Из них запуск сервисов - не самый длительный процесс.
Когда приходят пользователи винды, то их такая тормознутость шокирует (винда грузится 20-30 сек). Как-то неудобно.
Интересно, туда функционал (x)inetd еще не прицепили?..
с самого начала же было
http://0pointer.de/blog/projects/socket-activation.html
>С поддержкой данной возможности Systemd уже позволяет взять на себя большинство функций системы cron и избавиться от необходимости запуска дополнительного демона crond;Ура! еще ближе к идеалу.
В качестве загружалки и выключалки systemd хорош, но вот наименования интерфейсов меня пугают. Че за eno\ens? Или, упаси боже, ens[mac]? как это потом набирать то? Алиасы потом руками прописывать для удобства придется. :(
А вас не пугает, что после перезагрузки есть шанс, что eth0 и eth1 поменяются местами. Например, вставил новую сетевую карту и без хаков через приавязку к MAC приходилось курить какой интерфейс теперь с какой сетевой картой связан.
Меня пугает, что будет как во FreeBSD - хрен угадаешь, какое имя получит новая сетевая карта. Я хочу, чтобы на машине с одной картой её имя было всегда eth0!
А проблема с непостоянством имён надуманная: как часто вы добавляете/удаляете сетевые карты?
> А проблема с непостоянством имён надуманная: как часто вы добавляете/удаляете сетевые карты?А если речь идёт не про PCI устройства, а про, допустим, Bluetooth? Тоже пофиг?
С голубым зубом пусть делают что хотят, там это, наверное, полезно. А eth0 должен оставаться eth0
Думаю, в вашем особом случае можно сделать правило udev, коль так остро нуждаетесь в великом eth0
> С голубым зубом пусть делают что хотят, там это, наверное, полезно. А
> eth0 должен оставаться eth0Ну если в том смысле, что они его переименовывают, то да, мне тоже это не очень нравится. Совершенно необязательное переименование, по-моему.
>> С голубым зубом пусть делают что хотят, там это, наверное, полезно. А
>> eth0 должен оставаться eth0
> Ну если в том смысле, что они его переименовывают, то да, мне
> тоже это не очень нравится. Совершенно необязательное переименование, по-моему.Проблема с именами в стандартном пространстве та, что слишком тяжело обучать скрипт подробностям, а что будет, если это имя вдруг окажется занятым из-за стандартного распределения. Вы решили назвать устройство eth0, которое при данной загрузке вдруг оказалось eth1, потому что eth0 уже чем-то занято... oops. Надо включать новый уровень неестественного интеллекта, разбирать, кто появился и почему, назначать ему другое имя... причём быть готовым, что будет обгон и это другое имя вдруг тоже окажется занятым, потому что юзер вдруг вспомнил, что ему надо воткнуть USB сетевуху... не слишком ли путано?
Потому и вводится, что если правила назначили какому-то устройству конкретное имя, оно должно быть вне автоназначаемого пространства. Назовите его как-то по смыслу - например, если это шлюз, то у него будут int и ext.
Заодно все самопальные завязки на интерфейсы не изменятся от того, что сетевуха переехала в соседний слот.
> Проблема с именами в стандартном пространстве та, что слишком тяжело обучать скрипт
> подробностям, а что будет, если это имя вдруг окажется занятым из-за
> стандартного распределения. Вы решили назвать устройство eth0, которое при данной загрузке
> вдруг оказалось eth1, потому что eth0 уже чем-то занято... oops.Да. Про скриптописателей я не подумал. Но, всё равно, по-моему, совершенно необязательное переименование.
блютус-адаптеры тоже привязываются на раз.у них тоже есть ATTR{address}=="00:02:72:08:B7:CD"
блютус-адаптеры тоже привязываются на раз.какие сложности?
у них тоже есть ATTR{address}=="00:02:72:08:B7:CD"
>> А проблема с непостоянством имён надуманная: как часто вы добавляете/удаляете сетевые карты?
> А если речь идёт не про PCI устройства, а про, допустим, Bluetooth?
> Тоже пофиг?В дебиане это замечательно сделано. Система запоминает мак адрес и имя. При необходимости можно присвоить другое имя отредактровав правило юдев. Если в системд сохранятся человеческие имена и настройка будет проще, то пускай
> хрен угадаешьА зачем угадывать? dmesg же.
зато сразу ясно что где.
ifconfig | grep fla
vr0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
rl0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
ue0: flags=8802<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500а вот с udev - да... можно не угадать в один прекрасный момент.
>> хрен угадаешь
> А зачем угадывать? dmesg же.
> зато сразу ясно что где.
> ifconfig | grep fla
> vr0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
> rl0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
> lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
> ue0: flags=8802<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500# egrep 'igb.*Intel' /var/run/dmesg.boot
igb0: <Intel(R) PRO/1000 Network Connection version - 2.2.5> port 0x1020-0x103f mem 0xb1920000-0xb193ffff,0xb1944000-0xb1947fff irq 40 at device 0.0 on pci1
igb1: <Intel(R) PRO/1000 Network Connection version - 2.2.5> port 0x1000-0x101f mem 0xb1900000-0xb191ffff,0xb1940000-0xb1943fff irq 28 at device 0.1 on pci1если я вставлю туда:
http://ark.intel.com/products/50397/Intel-Gigabit-ET-Dual-Po...
(это тоже igb) какой интерфейс как будет называтся? сходу, без угадайки?> а вот с udev - да... можно не угадать в один прекрасный
> момент.а не надо угадывать. в правилах udev копипастите строчки, поправив mac'и на то что написано на карточке.
вообще-то можно заставить светодиоды на сетевушке помигать. Команду можно погуглить.
> vr0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
> rl0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
> lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
> ue0: flags=8802<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500Да, мне сразу так понятно что и где в этой китайской грамоте :)
> Меня пугает, что будет как во FreeBSD - хрен угадаешь, какое имя получит новая сетевая карта.Во FreeBSD новая сетевая карта получит в своём названии имя драйвера, который её обслуживает, и порядковый номер из списка обслуживаемых драйвером карт.
> Я хочу, чтобы на машине с одной картой её имя было всегда eth0!
В современных компьютерах больше одной сетевой карты. //ваш к.О.
> А проблема с непостоянством имён надуманная: как часто вы добавляете/удаляете сетевые карты?
Всё зависит от того, с какой стороны на это смотреть. Можно ли считать включение/выключение интерфейсов беспроводной связи в планшете/телефоне ради экономии заряда батареи добавлением/удалением сетевой карты? Что случается при перезагрузке с включенными/выключенными в последнем сеансе сетевыми устройствами, не перепутываются ли они ничего не значащими именами "ethXY"?
>> Меня пугает, что будет как во FreeBSD - хрен угадаешь, какое имя получит новая сетевая карта.
> Во FreeBSD новая сетевая карта получит в своём названии имя драйвера, который
> её обслуживает, и порядковый номер из списка обслуживаемых драйвером карт.специально для Изена продублирую:
# egrep 'igb.*Intel' /var/run/dmesg.boot
igb0: <Intel(R) PRO/1000 Network Connection version - 2.2.5> port 0x1020-0x103f mem 0xb1920000-0xb193ffff,0xb1944000-0xb1947fff irq 40 at device 0.0 on pci1
igb1: <Intel(R) PRO/1000 Network Connection version - 2.2.5> port 0x1000-0x101f mem 0xb1900000-0xb191ffff,0xb1940000-0xb1943fff irq 28 at device 0.1 on pci1втыкаем двухпортовую igb. кто кем станет?
> Всё зависит от того, с какой стороны на это смотреть. Можно ли
> считать включение/выключение интерфейсов беспроводной связи в планшете/телефоне ради
> экономии заряда батареи добавлением/удалением сетевой карты? Что случается при перезагрузке
> с включенными/выключенными в последнем сеансе сетевыми устройствами, не перепутываются
> ли они ничего не значащими именами "ethXY"?Изен, открой для себя rfkill.
> Во FreeBSD новая сетевая карта получит в своём названии имя драйвера,И почему я вообще должен этим заморачиваться, интересно? Какая мне с пользовательской точки зрения разница какой там драйвер обслуживает сетевуху?
> А вас не пугает, что после перезагрузки есть шанс, что eth0 и
> eth1 поменяются местами. Например, вставил новую сетевую карту и без хаков
> через приавязку к MAC приходилось курить какой интерфейс теперь с какой
> сетевой картой связан.Если вынуть все старые сетевухи, и вместо них воткнуть новые, то да, хрен угадаешь какая из них какому интерфейсу соответствует. Но если просто приткнуть новую, то, по-моему, все популярные дистры, эту ситуацию разруливают. И, довольно давно уже.
Я в первый раз столкнулся с этим, лет пять назад в генту. Поставил систему, а нумерация не такая, как хотелось бы. Собственно тогда и выяснил, что гента создаёт файлик /etc/udev.d/70-persistent-net.rules, и каждый раз при загрузке обновляет его. Там, кстати, и на другое железо бывают *persistent.rules.
То есть, я к тому, что systemd этим своим умением ничего принципиально нового не добавил. Лишь приблизился по функциональности к "классическим" инитскриптам.
> Поставил систему, а нумерация не такая, как хотелось бы. Собственно тогда и выяснил, что гента создаёт файлик /etc/udev.d/70-persistent-net.rules, и каждый раз при загрузке обновляет его.Бред. При загрузке он не должен обновляться, если не менялись сетевые карты.
> Лишь приблизился по функциональности к "классическим" инитскриптам.
Инитскрипты тут ни при чем. Генератор *-persistent.rules правил был в udev давно, а потом его выпилили. Теперь вот опять добавили, но существенно перепиленный.
>> Поставил систему, а нумерация не такая, как хотелось бы. Собственно тогда и выяснил, что гента создаёт файлик /etc/udev.d/70-persistent-net.rules, и каждый раз при загрузке обновляет его.
> Бред. При загрузке он не должен обновляться, если не менялись сетевые карты.Если вас интересуют подробности, то тогда я заменил практически всё железо. Точнее всё, кроме одной сетевой карты.
А если вы просто докопаться к словам, то... У вас нет другого повода докопаться? Этот, по-моему, слишком толстый.
>> Лишь приблизился по функциональности к "классическим" инитскриптам.
> Инитскрипты тут ни при чем. Генератор *-persistent.rules правил был в udev давно,
> а потом его выпилили. Теперь вот опять добавили, но существенно перепиленный.Хорошо. Буду знать.
>> Теперь вот опять добавили, но существенно перепиленный.В убунте он есть всегда...
никогда сие не пропадало...
было такое.
> А вас не пугает, что после перезагрузки есть шанс, что eth0 и
> eth1 поменяются местами. Например, вставил новую сетевую карту и без хаков
> через приавязку к MAC приходилось курить какой интерфейс теперь с какой
> сетевой картой связан.какие хаки?
В udev добавлена поддержка различных схем предсказуемого выбора имён для сетевых интерфейсов, при которых сетевому адаптеру назначается фиксированное имя, которое не измениться при добавлении/удалении других адаптеров.
Это делается в убунту уже лет 5!
каждый новый обнаруженный интерфейс прописывается по маку в удев-правило и он всегда имеет статичный порядковый номер...и не надо тут каких-то системд или апстартов.
Это дело удев.А вот то что кашу из имен делают - это да. все ближе и ближе фрибсд - где каждый контроллер имеет свое имя согласно модуля этого контроллера...)))
ну ведь было eth для все подобных устройств. так нет надо накосячить...
в свое время во фре прописывал ровно одну строчку в конфиге и меня были int0 и ext0, так гораздо понятнее, а теперь с vlan и подавно все обзываешь так как тебе нравицо, к чему заморачиваццо на гипотетический eth0 если все это можно настроить быстрее чем написать этот текст?
> в свое время во фре прописывал ровно одну строчку в конфиге и
> меня были int0 и ext0, так гораздо понятнее,это всё прекрасно, пока у вас все карты не на одном чипе.
толку от ваших переименований, если она привязана к нумерации(которая "поплывёт" при добавлении карточек).вообще,в linux через udev можно сделать именование как в *bsd, вопрос только написания 1 скрипта и поддержания базы идентификаторов устройств.
>> в свое время во фре прописывал ровно одну строчку в конфиге и
>> меня были int0 и ext0, так гораздо понятнее,
> это всё прекрасно, пока у вас все карты не на одном чипе.
> толку от ваших переименований, если она привязана к нумерации(которая "поплывёт" при добавлении карточек)."Поплывут" номера у интерфейсов, обслуживаемых одним драйвером, а не у всех eth*, как в Linux.
> вообще,в linux через udev можно сделать именование как в *bsd, вопрос только
> написания 1 скрипта и поддержания базы идентификаторов устройств.Но в Linux этим по-настоящему никто не заморочился, кроме Поттеринга, ведь так? ;)
> "Поплывут" номера у интерфейсов, обслуживаемых одним драйвером, а не у всех eth*,
> как в Linux.тоесть поплывшие имена среди одинаковых карт вас не смущает? подумаешь, если у тебя десяток одинаковых интеловских карт.. поугадываешь что где стало...
А в линуксе я такое видел ооочень давно. Когда, как уже сказали, этим udev не занимался. С тех пор все было просто отлично...> Но в Linux этим по-настоящему никто не заморочился, кроме Поттеринга, ведь так?
> ;)Странно вообще обращать внимание на такое заявление...
П.С.:
сорри что влез, но тема вашей ученой беседы настолько интересна....
> "Поплывут" номера у интерфейсов, обслуживаемых одним драйвером, а не у всех eth*,
> как в Linux.1)интерфейсы не "плывут" в linux, потому что автогенератор правил привязывает их к мак-адресам.
2)изен, ты хоть видел раз чтобы в production при наличии набортных igb кто-то ставил re/rl/vr? ставят либо igb, либо ixgb.>> вообще,в linux через udev можно сделать именование как в *bsd, вопрос только
>> написания 1 скрипта и поддержания базы идентификаторов устройств.
> Но в Linux этим по-настоящему никто не заморочился, кроме Поттеринга, ведь так?
> ;)вообще-то, оно штатно. просто кто-то видел linux только на картинках.
> "Поплывут" номера у интерфейсов, обслуживаемых одним драйвером, а не у всех eth*, как в Linux.И в чем тут профит? Весьма высосанное из пальца "преимущество".
пользователи генты смотрят на вас как на...
в гентах давно привязка автоматизирована, через /etc/udev/rules.d/70-persistent-net.rules
Нетвор4манагер всё сделай за тебя. А если настоящий сисадмин то знаешь зачем.
>уходом от использования особенностей, специфичных для конкретных дистрибутивов.А раньше это было не так? Эх, вот бы вернуться назад во времени и посмотреть в глаза systemdфилам, когда они такой баг утаили от systemdхейтеров
Если ничего не путаю, то это был не баг, а именно поддержка всяких дистроспецифических извратов в последовательности загрузки - чтобы при переходе на systemd все эти извраты продолжали работать в 100% случаев.Подробности где-то описывались в блоге Поттеринга.
P.S. От меня подробностей не ждите, ибо живу под Fedora/CentOS и там никаких извратов нету (или я к ним настолько привык, что не считаю их таковыми :) )
Больше всего радует активация через сокет, настроил активация через сокет поправил конфиги, и пошел. При первом обращении сервак стартует и вылетает из-за ошибки в конфиге. Но ты уже этого не узнаешь.
если ты не проверяешь перед уходом, и у тебя, идиота, нет мониторинга, цена тебе как админу - ноль
А на кой черт тогда эта активация, когда сервис все-равно нужно проверить сразу после старта? Чтобы избежать того, что описали выше. Малыш, ты понял?
> А на кой черт тогда эта активация, когда сервис все-равно нужно проверить
> сразу после старта? Чтобы избежать того, что описали выше.Не после старта а после правки конфигов их нужно проверять всегда!
>> А на кой черт тогда эта активация, когда сервис все-равно нужно проверить
>> сразу после старта? Чтобы избежать того, что описали выше.
> Не после старта а после правки конфигов их нужно проверять всегда!Суровым взлядом локалхост-админа что-ли? Поймите, даже не все сервисы имеют специальный ключик для проверки синтаксиса конфига. Я уж молчу о том, что не все ошибки конфигурации сводятся к ошибке в синтаксисе...
Чувствую, вам еще много предстоит валшебных открытий, а systemd в этом поможет...
Скажите, а злобный systemd запрещает проверять, работает ли активация после правок конфига, всем подряд или только админамлокалхоста?
> Скажите, а злобный systemd запрещает проверять, работает ли активация после правок конфига,Не запрещает. Но для этого сервис таки надо *запустить*. Смысл активации изчез, нет?
Д/з: подумать какие еще варианты поломаться в неожиданный момент есть у сервиса. Правка конфига - только один сценарий. Осилите?
>> Скажите, а злобный systemd запрещает проверять, работает ли активация после правок конфига,
> Не запрещает. Но для этого сервис таки надо *запустить*. Смысл активации изчез, нет?Это если не обкатывать правки в контейнере (man systemd-nspawn), а править конфиги на живую. Не говоря про шаблоны сервисов (см. sshd@.socket или как-то так в федоре).
> Д/з: подумать какие еще варианты поломаться в неожиданный момент есть у сервиса. Правка конфига - только один сценарий. Осилите?
Неа, лень. Тем более, что вы-то уже осилили, судя по вопросу. Почему бы не поделиться?
> Неа, лень. Тем более, что вы-то уже осилили, судя по вопросу. Почему
> бы не поделиться?Есть смысл чем-то "делиться" и что-то объяснять человеку с вашей логикой?
На замечание: XYZ может приводить к таким-то проблемам - вы отвечаете: достаточно XYZ не пользоваться вовсе. Занавес.
Проблем при старте сервиса может быть вагон, даже безотносительно к конфигам. Раздел переполнился, бинарник или библиотека теперь битые... Благодаря вашей "фиче" - теперь об этом вы можете узнать не в момент старта сервера, как нормальные, наученные опытом люди, а когда Вася Пупкин на него однажды постучится.
Все это так сложно? Будете теперь перед рестартом сервера каждый сервис предварительно перезапускать и проверять?
> Благодаря вашей "фиче" - теперь об этом вы можете узнать не в момент старта сервера, как нормальные, наученные опытом люди, а когда Вася Пупкин на него однажды постучится.вы сейчас мне рассказываете о рисках on-demand запуска сервисов? не трудитесь, это излишне.
> Будете теперь перед рестартом сервера каждый сервис предварительно перезапускать и проверять?
можно подумать, будто работоспособность сервисов, завёрнутых в (x)inetd, не нужно проверять точно таким же образом.
Складывается впечатление, что вы героически опровергаете тезис «все сервисы, использующие сокеты, всегда следует активировать только сокетом, вне зависимости от ситуации и требований».
> А на кой черт тогда эта активация, когда сервис все-равно нужно проверитьВнезапно, конфигурацию, особенно наруленную своими руками всегда надо проверять. Потому что у людей есть такое свойство: они умеют лажаться.
да очень удобно добавить хост nginx, а потом еще и curl ом проверить.Это заместо того чтобы просто увидеть что с конфигом я напортачил. Я полезу в логи искать где косяк. И не только при правки конфигов, при апдейте я тоже сразу не узнаю что могло отвалится.(Nginx как пример, не надо про ключик -t рассказывать)Мало того systemd reload не умеет, так что опять возвращаемся к shell скрипту и все хваленая простота идет лесом.
> нет мониторинга
Представьте нету в journald, централизованного live мониторинга.
> да очень удобно добавить хост nginx, а потом еще и curl ом проверить.Это заместо того чтобы просто увидеть что с конфигом я напортачил. Я полезу в логи искать где косяк. И не только при правки конфигов, при апдейте я тоже сразу не узнаю что могло отвалится.Я не понял. nginx -t уже отменили или что? Или Леннарт держит вас за тестикулы плоскогубцами и заставляет пускать nginx именно посредством socket activation?
> Мало того systemd reload не умеет
Ну враньё же. +1 строка в конфиге юнита.
> Или Леннарт держит вас за тестикулы плоскогубцами и заставляет пускать nginx именно посредством socket activation?Слава Леннарту нет.
> Ну враньё же. +1 строка в конфиге юнита.да действительно ExecReload=/usr/sbin/nginx -s reload
>> Или Леннарт держит вас за тестикулы плоскогубцами и заставляет пускать nginx именно посредством socket activation?
> Слава Леннарту нет.Так а какие претензии тогда? Чудес не творят ни xinetd, ни systemd. Но ожидаете вы их почему-то только от systemd.
Да нет претензий, просто развеиваем миф что systemd наше все. Хотя в контексте systemd выражение приобретает особый смысл )))
> Да нет претензий, просто развеиваем миф что systemd наше все.сам придумал — сам развеял. молодец, чо.
Если тебе повторять за толпой как попугай не включая свой мозг просто и приятно это ровно твои проблемы.
> cron и избавиться от необходимости запуска дополнительного демона crond;Рад что еще одну тулзу в заменили. Что там дальше по плану переписать?
>> cron и избавиться от необходимости запуска дополнительного демона crond;
> Рад что еще одну тулзу в заменили. Что там дальше по плану
> переписать?Пока ещё не заменили. Нужна ещё утилитка crontab, которая позволит юзерам создавать cron-задачи. Кстати, если они объединят crontab с at, то это будет весьма логичным и удобным решением.
> Кстати, если они объединят crontab с at, то это будет весьма логичным и удобным решением.Логичным да, вполне, а вот удобным это как получится.
> Логичным да, вполне, а вот удобным это как получится.В принципе идея здравая. В том плане что не сильно удобно когда запуск всего и вся распихан по куче закоулков. Как по мне, не сильно удобно навигировать по куче локаций и редактировать кипу файлов до того как все взлетит и заработает как надо.
ядро
Я так смотрю, версии где-то к трёхсотой в него запихнут графический сервер на замену иксам и вэйланду, потом появится интегрированная DE, потом офисный пакет и разное прочее ПО, а там, глядишь, к тысячной версии собственное ядро запилят.
это очень неплохой сценарий
Самое заманчивое в этом сценарии то, что всё это богатство будет крутиться внутри одного процесса - совсем как в старые добрые времена!
> Самое заманчивое в этом сценарии то, что всё это богатство будет крутиться
> внутри одного процесса - совсем как в старые добрые времена!Угу. Но тогда в рамках этого процесса придётся запускать uml сборку linux'а, потому что иначе, разные задачи процесса обязательно передерутся из-за памяти, файловых дескрипторов и прочего. В общем выйдет прямо как в DOS'е.
Заглядывая же в перспективное будущее, можно предположить, что разные задачи процесса, окажутся разными задачами уже um-linux'а, для инициализации этих задач будет создан um-systemd, который впоследствии подгребёт все эти задачи в одну, и запустит в ней um-linux, который ... Упс...
Сорри. Бесконечная рекурсия вышла. Видимо, пора подвязывать с lisp'ом.
> Самое заманчивое в этом сценарии то, что всё это богатство будет крутиться
> внутри одного процесса - совсем как в старые добрые времена!Самое заманчивое ― что это Леннарт с гномиками вместе со своим ядром и ОС уйдут куда-нибудь в своём направлении и оставят Линукс в покое. И фанбоев с собой заберут.
Давно надо уже забыть про операционные системы, слишком раздуто внимание к ним. Автокады фотошопы математики, на них надо переключаться. Наверно так и будет, как только проблема драйверов ускорялок 3D под линукс будет решена раз и навсегда.
> Давно надо уже забыть про операционные системы, слишком раздуто внимание к ним.
> Автокады фотошопы математики, на них надо переключаться. Наверно так и будет,
> как только проблема драйверов ускорялок 3D под линукс будет решена раз
> и навсегда.Этот jpg называется "Аноним закончил школу и поступил в ВУЗ". Через 5 лет если не загремит в армию, он напишет, что надо переключаться на ERP, POS, групварь и бухгалтерию, но 3Д драйвера всё равно в первую очередь пилить, чтобы он на своей 100$ видеокарте мог в Крузис 4 наконец поиграть без лагов.
Что за поток сознания? Какой jpeg? Какая школа, какой ВУЗ? В школах уже астрономия под запретом, не говоря уже о пребразовании Фурье, одна из разновидностей которого лежит в основе jpeg. И армии больше нет, ни сплошного радиолокационного поля для контроля всего что летает над страной, ни микропроцессоров, один Крузис и Фордфокус с Египтом/Турцией. Не миллионный вариант файловых систем нам нужен, а прикладные программы надежные для взлома генома (в том числе и человека), для проектирования более экономичных двигателей, моделируя слжнейшие термодинамические процессы ДВС. Игрун, дуй на сайты гдже картинок больше.
Когда это пребразовании Фурье было в школах ?
> Этот jpg называется "Аноним закончил школу и поступил в ВУЗ". Через 5
> лет если не загремит в армию, он напишет, что надо переключаться
> на ERP, POS, групварь и бухгалтерию,Не все после вуза идут в админы :-)
> Давно надо уже забыть про операционные системы, слишком раздуто внимание к ним. Автокады фотошопы математики, на них надо переключаться.Точно! Вот чего в systemd не хватает-то! После cron и inetd самое время заняться! И сразу типовые шаблоны, типа в 13:46 8 февраля 2014 года - запуск фотошоп, а при подключении на порт 35590 в будни - автокад! Эх, заживём!
> это очень неплохой сценарийхз, хз. Всё-таки за десятки лет существования никсов люди как-то привыкли к щеллам и конфигам и прогам, делающим что-то одно, но хорошо, а не к непонятно-как конфигурирующемуся непонятно-чему, которое делает всё непонятно-как.
Возможно, что этот сценарий и будет для кого-то неплохим, но для многих он не подходит уже сейчас.
>> это очень неплохой сценарий
> хз, хз. Всё-таки за десятки лет существования никсов люди как-то привыкли к
> щеллам и конфигам и прогам, делающим что-то одно, но хорошо, а
> не к непонятно-как конфигурирующемуся непонятно-чему, которое делает всё непонятно-как.
> Возможно, что этот сценарий и будет для кого-то неплохим, но для многих
> он не подходит уже сейчас.Для того чтобы было понятно, надо в "щеллам" набрать команду man ...
Документацию пробовали читать?
>> это очень неплохой сценарий
> хз, хз. Всё-таки за десятки лет существования никсов люди как-то привыкли к
> щеллам и конфигам и прогам, делающим что-то одно, но хорошо, а
> не к непонятно-как конфигурирующемуся непонятно-чему, которое делает всё непонятно-как.
> Возможно, что этот сценарий и будет для кого-то неплохим, но для многих
> он не подходит уже сейчас.Сожрут и не поперхнутся Когда билли через 10 строчный сonfig.sys и 100 строчный system.ini вляпался в неподъемную хрень многомегабайтного текстового конфига, то вполне здраво решил что" ну его нафиг такую радость" и придумал бинарный реестр.
Воплей было столько же. Зато сейчас про текстовые конфиги в осях от мелкософта уже все забыли.
> Зато сейчас про текстовые конфиги в осях от мелкософта уже все забыли.Зато чистилки реестра и периодические реинсталлы ОС еще помнят
"Не делаешь бэкап /etc и /home ? ССЗБ" (С)
"Не делаешь бэкап реестра и /mnt/sda1/Documents and Settings? ССЗБ" (С)
Найдите пять отличий © журнал "Наука и жизнь"
> "Не делаешь бэкап /etc и /home ? ССЗБ" (С)
> "Не делаешь бэкап реестра и /mnt/sda1/Documents and Settings? ССЗБ" (С)
> Найдите пять отличий © журнал "Наука и жизнь"Отличия в том что никсы с годами переставлять не надо, а винду приходится. Хотя бы из-за чудес франгментации.
> Отличия в том что никсы с годами переставлять не надо, а винду
> приходится. Хотя бы из-за чудес франгментации.Как давно в винде пропал даже штатный дефрагментатор ?
> Как давно в винде пропал даже штатный дефрагментатор ?Истинный виндузятник слишком туп чтобы найти и запустить его. Увы.
Что толку писать свое ядро, если никто не будет поддерживать для него дрова? Линюкс тем и хорош, что для него более-менее пишутся дрова. Самое расчудесное ядро, но мертвое, созданное лишь для работы сомое с собой никому не нужно.
> уходом от использования особенностей, специфичных для конкретных дистрибутивов.Я это запомнил.
Поттеринг явно нацелился на создание новой ОС. СистемдОС.
Пусть ядром grub заюзает.
> Из состава Systemd исключён код для определения и задействования возможностей и файлов конфигурации, специфичных для отдельных дистрибутивов. Вместо использования собственных файлов конфигурации разработчикам дистрибутивов предлагается использовать предлагаемую Systemd стандартную модель управления конфигурацией, на которую уже перешло большинство использующих Systemd дистрибутивов.Переводим с языка потеринга - мне влом заниматься адаптацией под всех. Давайте вы прогнетесь и будете использовать то что вам дадут, а то нам сильно влом.
если б всем было так "влом" как поттерингу, софт шагнул бы далеко вперёд
M$ этому живое доказательство.
> M$ этому живое доказательство.Конечно, и без иронии
Нет там иронии, один сарказм.
> Нет там иронии, один сарказм.в данном случае и без него
>> Нет там иронии, один сарказм.
> в данном случае и без негоОчень частный случай. В общем случае при обслуживании винды без сарказма никак. И чем больше инсталляция - тем больше сарказма.
> Давайте вы прогнетесь и будете использовать то что вам дадут, а то нам сильно влом.давайте вы свои quirks засунете в дистроспецифичные патчи — вы уже это и так делаете для сотен других пакетов.
нормальные пакеты меняют пути расположения конфигов и тп - через опции configure.
не нормальные - требуют написания патчей которые правят код и потенциально могут что-то зацепить.
Если разработчик вместо одного define разбросал по коду строковые константы с именами.
Что еще добавляет к сложности поддержки.К какому из вариантов вы причисляете systemd - которые требует написания патчей вместо вызова configure с нужными опциями (для чего он и предназначен вобщем-то) ?
> нормальные пакеты меняют пути расположения конфигов и тп - через опции configure.или в опции configure-скрипта. неважно.
> К какому из вариантов вы причисляете systemd - которые требует написания патчей вместо вызова configure с нужными опциями (для чего он и предназначен вобщем-то) ?я только краем уха смотрел исходники systemd, я не в курсе.
> я только краем уха смотрел исходники systemd, я не в курсе.Не читал, но мнение имею. (с) Всё с вами понятно.
>> я только краем уха смотрел исходники systemd, я не в курсе.
> Не читал, но мнение имею. (с) Всё с вами понятно.для альтернативно одарённых повторяю — я знаю недостаточно, чтобы ответить на этот вопрос.
ждем когда его допилят, а потом форкнут,выкинут гавно и получим sysd, как то так.
Правильно говорите, очень правильно - выкрасить и выбро^W допилить и выкинуть. Ибо оно самое, да.
> ждем когда его допилят,...А это вообще возможно при таком подходе как сейчас? Некогда допиливать-то, работы невпроворот - столько фич ещё не переписано, себе не интегрировано и на себя намертво не завязано! Пока есть софт, умеющий нормально работать без systemd - никаких допиливаний! И так жрут!
> для встроенных сетевых интерфейсов будет использовано имя "enoN", а для PCI-плат - "ensN". Иначе будет выбрано именование enpNsM, учитывающее физическое соединение устройства, аНе понял. Переходили же на новую схему em1/em2/em3 и тд для внешних и p0p1 и тд для внутренних. В федоре уже давно так, в RHEL и клонах для серверов Dell это активируется. Достаточно удобно, когда несколько мультипортовых сетевух (p0p1, p0p2, ... p1p1 и тд лучше, чем плоская схема, где все порты на внутренних и pci-сетевухах вперемешку).
Откуда эти e*n* появились? Придумали одну универсальную систему имен, чтобы решить накопившиеся проблемы, чтобы через два года предлагать переименовать?
На красношляпых равняться не буду.
Лучше фрагментация, чем монополия.
> Лучше фрагментация, чем монополия.Да, лучше чтобы у софтоделов крыша ехала - как сделать, чтобы это работало здесь там и ещё вон там.
>Да, лучше чтобы у софтоделов крыша ехала - как сделать, чтобы это работало здесь там и ещё вон там.Конечно. Гораздо лучше, чтобы здесь и нигде больше.
Вот-вот, надо чтобы думали:> как сделать, чтобы это работало
а не какую бы еще новую и прогрессивную "фичу" запилить.
> Вот-вот, надо чтобы думали:
>> как сделать, чтобы это работало
> а не какую бы еще новую и прогрессивную "фичу" запилить.Ты не поверишь - сейчас они заново изобретут парадигму:
"Совместимость важнее производительности" (С) 1975
:)))))))))))))))))))))))))))
Дебилы....
> Systemd теперь позиционируется как полностью обособленная и независящая от Linux-дистрибутиов система.Ну и правильно. Меньше будет зоопарка.
А так, чё, в арчике нормально работает. Теперь комп с холодного старта грузится столько же, сколько раньше выходил со спящего режима и выключается чуть ли не мгновенно ;)
> Ну и правильно. Меньше будет зоопарка.
> А так, чё, в арчике нормально работает. Теперь комп с холодного старта
> грузится столько же, сколько раньше выходил со спящего режима и выключается
> чуть ли не мгновенно ;)Неудивительно, арчеводы сожрут хоть гнилой банан, если им сказать что это парной пингвин :-)
Так я же говорю - оно работает. А своих сферических пингвинов с бананами оставьте в своём вакууме и наружу не выпускайте.
> Так я же говорю - оно работает. А своих сферических пингвинов с
> бананами оставьте в своём вакууме и наружу не выпускайте.У меня в слаке тоже работает, но не ОН :-) Ноут я с собой не таскаю, бо "ненужно", есть айпад, а за все остальным systemd мне вообще неинтересен.
> Так я же говорю - оно работает. А своих сферических пингвинов с
> бананами оставьте в своём вакууме и наружу не выпускайте.Софт интересен не только тем как он работает, но и тем как он не работает. Хвалить недопиленную софтину можно до усёра. Особенно пока с неё проблем не возникало. -)
> Поддержка вызова системных событий в привязке к календарному времениНу что, авторы кронов уже начинают сушить сухари?
А стандартные конфиги уже имеют работать с сетевыми интерфейсами? Или все же это до сих пор надо придумывать самому?
Кстати, вот такой вопрос. С его поделием дела не имел вообще и на слаке вряд ли буду иметь, по крайней мере в ближайшее время. Но если systemd пролезет как таракан во все щели и авторы будут писать только юниты, а не в /etc, можно будет как то заюзать systemd только для запуска этих юнитов, оставив старую инициализацию и загрузку ?
> Кстати, вот такой вопрос. С его поделием дела не имел вообще и
> на слаке вряд ли буду иметь, по крайней мере в ближайшее
> время. Но если systemd пролезет как таракан во все щели и
> авторы будут писать только юниты, а не в /etc, можно будет
> как то заюзать systemd только для запуска этих юнитов, оставив старую
> инициализацию и загрузку ?debian boys вроде как писали конвертор юнитов в батники
Кажется, что нет. Systemd, в том числе, отвечает за инициализацию, inittab тоже больше нет ;)
аспекте
> аспектеДа нет именно что в "аксепте". Читайте мои труды. Нес па?
Кто-нибудь может показать размер этого монстра в top`е?
top | grep systemd
1 root 20 0 32508 3188 1856 S 0,0 0,0 0:00.45 systemd
http://fastpic.ru/view/52/2013/0110/0394d3910b9dc75b850b32bb...
Fedora 17
> http://fastpic.ru/view/52/2013/0110/0394d3910b9dc75b850b32bb...Нормальные такие кеды. С гномовским логотипом на кнопке меню. Мсье оригинал :)
Думал никто не заметит :)
оно ещё и в cron лезет. ну почему, почему мама портеринга не предохранялась?!
> Из состава Systemd исключён код для определения и задействования возможностей
> и файлов конфигурации, специфичных для отдельных дистрибутивов.Искренне желаю этим умникам попасть в автоматизированную парикмахерскую.
http://lists.altlinux.org/pipermail/devel/2013-January/19627...
Да не паникуйте вы так :)
И ничего там ни "хреново". У вас в Альте похоже даже помягче будет переход, чем в Арче.
Арчеводов все неарчеводы подопытными кроликами называли (да и называют). И ничего — "кролики" не только выжили, но и довольны даже (ретрограды не в счёт, ибо такие вообще не понятно, как в арчеводы затесались — философию дистра надо было читать сначала, а потом его ставить).
Всё живое должно меняться (хотя бы, чтобы выжить). Что не меняется — мёртвая окаменелость.
> Да не паникуйте вы так :)И не думал.
> У вас в Альте похоже даже помягче будет переход, чем в Арче.
Вопрос не в мягкости перехода, а о вменяемости апстрима.
> Всё живое должно меняться (хотя бы, чтобы выжить).
Есть осмысленные изменения, а есть бессмысленные (или противоречащие озвученной цели).
> Что не меняется — мёртвая окаменелость.
"На острие можно извиваться, а не развиваться" (c) Н.Н. Непейвода
> Всё живое должно меняться (хотя бы, чтобы выжить). Что не меняется —
> мёртвая окаменелость.при этом большинство мутаций — тупиковые, если только для поддержки мутанта не задействовано огромное количество сил.
вбивание в глотку портерингоподелия — плохо. если портерингоподелие настолько криво, что не может иметь отдельный модуль разбора «старых конфигов», а вместо этого было пересыпано ifdef'ами… ну, дополнительное доказательство того, что системд — корявое непродуманое crapware. к тому же это crapware стремится сожрать как можно больше системных сервисов. нет, что-то не хочется в него вляпываться.