Вышел OpenRC 0.12

поддержка исправлени пришли от контрибьютора:

http://git.overlays.gentoo.org/gitweb/?p=proj/openrc.git;a=commit;h=9ebd5a6af...

я думаю можно попробовать его напрямую спросить.

Не знаю такого, ну да ладно, разберемся. Спс за сцылку на коммит. Что-то подобное пытался сам навелосипедить, но не преуспел.

Что за эпидемия NIH-синдрома у разработчиков? Мало им init и systemd, хотят свой велосипед сделать, чтобы было не как у всех, чтобы было чем выпендриться.

пожалуйста, перед тем как давать подобные комментарии на ресурсах пытающихся быть серьёзными попробуйте утрудить себя просмотром дат появляения проектов, спасибо. А заодно удостовериться, в том что вы понимаете, чем init система отличается системы управления сервисами.

Спасибо.

Basically, systemd is now a first class citizen in Gentoo (on par withOpenRC)

Одобряю. Всё в соответствии с философией Gentoo. Больше выбора.

И кого интересуют дефолты? Дефолтного логгера и крона в генте вообще нет, никого это не беспокоит. Правильно если они уберут и init из stage3 и сделают установку одного частью процедуры установки дистра как сейчас с логгером и кроном.

дат появляения проектов

Wimdows появилась раньше linux, а неандертальцы — твоих родителей.

зачем это здесь?

Одобряю. Всё в соответствии с философией Gentoo. Больше выбора.

Да и печаль только в functions.sh который зачем то впилили в openrc а потом все подряд их заюзали и впилили зависимости от openrc в свои ебюлдики именно из-за functions.sh хотя это все в общем вообще «не проблема openrc».

Поддержка cgroups опциональна. У меня из Linux-ядра cgroups выпилены за ненадобностью и openrc нормально работает.

Добавлена полноценная поддержка cgroups

И эти люди критикуют systemd.

Wimdows появилась раньше linux, а неандертальцы — твоих родителей.

В терминах Вашей аналогии, тов. chromium утверждает, что Wimdows - это свелосипеженный linux, а неандертальцы - вызванная NIH-синдромом копия его родителей.

Поддержка cgroups что из себя представляет? А-ля dev-libs/libcgroup ?

нет. а). возможность их монтирования при загрузке (то, что отчасти делалось в cgconfig)

б). создание иерархии openrc, в которой хранится инфа о сервисах

в). возможность задавать лимиты для сервисов, создает цгруппу openrc_$service, в том контроллере, лимит которого установлен и соотвествующими лимитами

г). добавляет возможность при выключении атоматически убивать всех несдохших детей (rc_cgroup_cleanup=«yes») + возможность сделать это руками /etc/init.d/$service cgroup_cleanup

Планируется: добавить возможность прицеплять сервисы к юзерским цгруппам. Были идеи добавить заморозку сервисов, но пока в этом нет необходимости.

Да, openrc не использует libcgroup т.к. а). это тяжелая зависимость б). тот минимум что нужен для работы покрывается очень простым баш файлом. И openrc можно использовать совместно с сервисами идущими с libcgroup.

ты можешь пояснить свою мысль, или просто так ляпнул?

Респект! Откуда такая инофрмация? Вчера бегло смотрел git логи этого релиза, не смог собрать всю инфу воедино.

Ненавистники СПО критикуют systemd за его привязанность к Linux.

Прославители systemd хвалятся, что оно кроссплатформенное.

там по cgroups почти все коммиты или мои или мои поправленные :)

Мысль снова высказана не до конца, то так уж и быть отвечу. Цель openrc в отличии от systemd по макимуму использовать использовать существующие подсистемы и программы при этом не завязываясь на них, и не изобретая их внутри себя. На данный момент до максимума ещё далеко, но это отдельная тема для разговора. Таким образом openrc a). практически не устанавливает требований на систему б). не тащит всё в себя. Хотя с утилизацией возможноей ось у systemd дела обстоят получше.

То, что openrc использует подсистему cgroups не мешает ему работать на других платформах. Я бы с удовольствием потестил и попилил bsd-only фичи, но я их просто не знаю.

Даа точно, то-то смотрю имя знакомое:)

Как заюзать в стрекозе? Есть инструкция/хаутушка какая, с описаловом возможных грабель? Я б потестил.

удваиваю

если я найду автора патчей в irc спрошу, но я честно не помню ника.

осталось портаж к стрекозе прикрутить )

А по поддержке lxc? Вы пошто sysctl в контейнере сломали?

systemd еще умеет со свежим релизом переставать узнавать kill-user-processes=true и выключаться от этого вообще за секунду :)

Зачем вы травите человека. Ведь он умеет набирать компилирующийся код на C, причём совершенно бескорыстно.

Ни в коем случае не травлю, просто интересуюсь — может быть он в курсе. Вот все никак не созрею баг завести.

я не ломал..

commit f9162438bca8c8449f1f663a60c47229f0c08316
Author: William Hubbs <williamh@gentoo.org>
Date:   Mon Mar 26 14:51:03 2012 -0500

    Add -lxc keyword to sysctl script for linux systems
    
    Kernel parameters should not be set from inside a lxc guest.
    
    Reported-by: Piotr Karbowski <piotr.karbowski@gmail.com>

оно? если есть подозрение, что это не так, то хотя бы тут отпишись.

gentoo/bsd есть полуживой и префикс.

gentoo/bsd есть полуживой и префикс

он вполне себе живой. даже stage3 выходят. только оно free, а не dragonFly.

О, да, большое спасибо. Ну вот только спрашивается, зачем? Если эти параметры и так в контейнере выставить можно и они меняются ЕМНИП только в namespace.

если есть подтверждающая инфа, то я пну автора коммита и можно назад убрать keyword.

Ну теперь systemd точно капец.

P.S.

Лишь бы OpenRC не пошёл по пути systemd и не стал в себя пихать всё подряд.

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

Также ведутся работы по адаптации netifrc под другие системы управления сервисами.

Вот это я понимаю - правильный подход. Настоящий UNIX-Way. Не то, что там имбецил Поцеринг вытворяет.

Наверно имеется в виду поддержка скриптов и возможностей. Вот в OpenRC сейчас добавили полную поддержку cgroups - единственную фичу systemd, ради которой стоило его ставить. Теперь systemd совсем не нужен. Никому. Вообще.

Спасёт. Debian сможет на OpenRC перейти за счёт портабельности последнего. А после этого systemd просто не внедрят как основную систему инициализации - зачем systemd, когда есть инит гораздо круче в виде OpenRC?

Вот и славно.

Тормоз этот ваш сыстемДэ. Я тумблером за доли секунды отключаю %)

Толсто.

Толсто — это характеристика systemd и его любителей.

когда есть инит гораздо круче

4.2

Обновился, прикрутил cgroups. Пока полёт нормальный. С другой стороны, оно и раньше, через cgred работало неплохо.

Кстати, что за «сервисы для поддержки EFI» такие? GRUB и так из EFI работал, какая ещё поддержка нужна?

добавлено монтирование efivarsfs для ядер 3.10+. Тут я много не подскажу, т.к. с efi не разбирался совсем.

Нашёл этот коммит. Действительно, просто добавлен modprobe и дополнительный mount.

Спасибо разработчикам, больше и сказать-то нечего, отличный инструмент.

С другой стороны, оно и раньше, через cgred работало неплохо.

если я всё правильно понимаю, то можно и вместе использовать, например не пуская cgred в иерархию openrc, а в openrc не устанавливая лимитов. Тогда можно получить профит от обеих систем.

В плане подтверждающая? У меня контейнер с postgresql и необходимо выставлять параметры shared memory, до недавнего обновления было все ок, а потом сломали этим коммитом. Только что проверил на контейнере с:

lxc.cap.drop = audit_control audit_write dac_read_search ipc_owner linux_immutable mac_admin mac_override mknod setfcap
sys_admin sys_boot sys_module sys_pacct sys_ptrace sys_rawio sys_resource sys_time sys_tty_config syslog

Насколько Я понял вот это для каждого namespace своя таблица sysctl.

Во спасибо. Если я все правильно понимаю, то немалое количество опций работают на уровне контейнера, но при этом не все, если при этом lxc не позволяет менять глобальные изнутри контейнера, то можно убирать keyword, иначе нужно думать, как сделать правильно.

https://bugs.gentoo.org/show_bug.cgi?id=481264 если что

как оно перенесено на BSD, если использует cgroups?

cgroups не обязательны для работы OpenRC, следовательно - на *BSD(и на Linux, собранном без поддержки оных) - работать будет, просто отключаться фичи, связанные с cgroups

ммм. Это вызовет проблемы при обновлении? Если да - какие и как их избежать?

Не должно, т.к. /var/run является симлинком на /run