Ян Курик (Jan Kuřík), руководитель по развитию платформы в Fedora Linux, опубликовал (https://lists.fedoraproject.org/archives/list/devel-announce.../) предложение (https://fedoraproject.org/wiki/Changes/systemd_package_split) по реструктуризации пакета с systemd в следующем выпуске дистрибутива. Из основного RPM-пакета systemd предлагается выделить два обособленных пакета systemd-container и udev, содержащие инструменты для работы с изолированными контейнерами (systemd-nspawn, systemd-machined, machinectl, systemd-importd, systemd-pull) и компоненты udev (systemd-udevd, udevadm, udev rules и БД оборудования).
Оба пакета будут не обязательными к установке: systemd-container будет востребован только в конфигурациях, в которых используются контейнеры или виртуализация, а systemd-udev может не устанавливаться в контейнерах. В качестве мотива разбиения пакета с systemd на части упоминается сокращение потребления дискового пространства и сокращение зависимостей. Например, systemd-container.rpm позволит сократить место на диске на 3.5 Мб и исключить обязательную зависимость от libmicrohttpd. Не использование systemd-udev.rpm в контейнерах позволит сэкономить 13 Мб (6.5 Мб пакет и 6.5 Мб база оборудования).
Изменение пока находится на стадии рассмотрения предложения и для внедрения требует утверждения комитетом FESCo (Fedora Engineering Steering Committee), отвечающим за техническую часть разработки дистрибутива Fedora Linux.URL: https://lists.fedoraproject.org/archives/list/devel-announce.../
Новость: http://www.opennet.me/opennews/art.shtml?num=43381
Экономия на спичках
> Экономия на спичкахПо месту - да, а вот избавление от лишних зависимостей (читай: отсутствие лишних уязвимостей) правильно.
А если 13MB умножить на сотню контейнеров?
Для сотни контейнеров полтора гига -- это спички, да.
Ну а что тогда у вас роль водки выполняет? Что такого лишнего пихаете в контейнеры, что полтора гига спичками является.
> А если 13MB умножить на сотню контейнеров?давай посчитаешь сколько будут весить эти 100 контейнеров.
Зависит от решаемых ими задач. Могут быть контейнеры на десятки гигов, а могут и на сотню метров. Если последних достаточно много, то 13 метров на каждом совсем не кажутся ерундой.А вообще образ мыслей весьма характерен для поколения быдлокодеров. Зачем выносить из цикла лишние действия, если они занимают всего несколько микросекунд. Чего на спичках экономить.
> Экономия на спичкахНе в спичках даже дело, а в том что сперва всю эту хрень в одну кучу затолкали сделав кибенестическую вундервафлю, а теперь обратно ее на части делить пытаются, потому-что в одной куче оказывается не то пальто.
О чем кстати большевики с самого начала и говорили. Если так дальше пойдет то они sysv init заново изобретут.
Сам systemd, для начала, нужно разбить на отдельные национальные элементы, тогда экономия места будет ещё лучше.
он вообще то разбит, это не монолит, просто метод разработки что все компоненты хранятся в едином дереве некоторых смущает, но почему то не смущает что также разрабатывается ядро.
> он вообще то разбит, это не монолит, просто метод разработки что все
> компоненты хранятся в едином дереве некоторых смущает,"Смущает" совсем не это.
> но почему то не
> смущает что также разрабатывается ядро.И ядро совсем не "также разрабатывается".
И да, передёрги инитозависимых прогрессивных хворумчан - часть проблемы. Не совсем разработка, но да часть маркетингового апстримового б\шита.
>> он вообще то разбит, это не монолит, просто метод разработки что все
>> компоненты хранятся в едином дереве некоторых смущает,
> "Смущает" совсем не это.
>> но почему то не
>> смущает что также разрабатывается ядро.
> И ядро совсем не "также разрабатывается".Так и знал что это другое измерение. Где модули ядра в отдельной репах по категориям.
>>> он вообще то разбит, это не монолит, просто метод разработки что все
>>> компоненты хранятся в едином дереве некоторых смущает,
>> "Смущает" совсем не это.Криворукие безмозглые идиоты-пропагандёры в форумах, для примера. И апстрим весь -- подобное к подобному. На. Подбор.
>>> но почему то не
>>> смущает что также разрабатывается ядро.
>> И ядро совсем не "также разрабатывается".
> Так и знал что это другое измерение. Где модули ядра в отдельной
> репах по категориям.У нас тут точно другое. У нас не различают код по методу хранения, выкатывания. И один и той же код а SVN (да-да...), в git-е, а tar.gz и tar.xz -- не 4-ре разных "метОды" разработки.
Вот нас _тут_ и накрывет изменой от празднослояющихся сказок про "новая метода -- переложили вот ето вот сюды", чуйим путешественников срозь миры -- Скрытая Угроза и Сонная Затрещина.
Наблюдайте http://www.phoronix.com/scan.php?page=news_item&px=KDBUS-Bac... , как kernel-овцы _отразили_ s-d-ешный идиотен-шоу. Читай тред по ссылке в LKML (короткий он /был неделю назад): "" --мая твая нипанимайт, говорите яснее, отвечейте на вопросы! --окей, обратно за парт^W^Wк мольберту. "" Ждём новых выкидышей, вужосе.
>Наблюдайте http://www.phoronix.com/scan.php?page=news_item&px=KDBUS-Bac... , как kernel-овцы _отразили_ s-d-ешный идиотен-шоу.В этом сообщении Greg KH, один из главных разработчиков ядра, один из разработчиков kdbus, который курирует интеграцию его в ядро и положительно относится к systemd, объявил, что kdbus будет серьёзно переработан. Если kdbus — это идиотен-show, то Грег его главный спонсор.
Нормально, мои посты удаляют а эту белиберду не трогают. Из всего коммента 2 предложения внятных остальное читать не возможно.
вы плохо смотрели в его код, если так считаете.
но проблема сидит еще глубже.
даже если можно выпилить патчами тот же journal, то от зависимостей к ABI libsystemd трудно уйти. по этот же причине, трудно предложить и реализовать альтернативные решения,
так как линковка требудет systemd, а не journal. И к тому же гайки к системд еще туже закручивают.
я нормально смотрел в код, а местами не ввосторге. Ну а libsystemd и должно быть зависимостью это ведь ABI, а альтернативы делаются для api.
Ну а теперь представьте картину. В новой версии одну функцию сломали а вторую починили и это разные компоненты. Как быть? Ладно логирование, на него можно забить. Но там же сидит и logind, а у него зависимостей поболее. И если там чего сломают, то это чревато откатом всего системд. А Можно было бы прост откатить одну библиотеку. А пресловутый compat-libs уже объявлен deprecated и погоды там не играет, так как к нему уже никто не линкуется.
Ну благо можно самому пересобрать. Но пересобирать этот комбайн удовольствие еще то.
> libsystemd и должно быть зависимостью это ведь ABI, а альтернативы делаются для api.Нормальная модульность подразумевает возможность замены модуля без перекомпиляции того, что от него зависит.
В тред приглашаются размазыватели соплей о монолитности systemd.
Ты хочешь, чтобы они в стопицотый раз разъяснили тебе в чем именно монолитность, а ты в стопицотый раз ничего не понял и рассказал им в ответ свои фантазии о портянках?
Ну, если их разъяснения и есть невразумительные портянко-фантазии, то что я могу поделать?)
От нас всё ушло, пробема на принимающей стороне.
Это вам не TCP.
К сожалению это действительно так. Вам уже много раз объясняли, что монолитность подразумевает то, что всё многообразие демонов systemd настолько туго взаимосвязано, что выделить отдельный элемент и заменить его аналогом просто нет никакой возможности.
Я прекрасно выделяю и не собираю некоторые демоны systemd вроде веб-сервера или генератора qr-кодов. А что касается заменяемости: в Линуксе много таких программ, чьи модули и компоненты не заменяются аналогами.
journald выдели и не собери, а потом поговорим.
он балаболит про самодельные пересборки
А это обязательное требование для того, чтобы считать systemd модульным?
это "обязательное требование" для того чтобы systemd "считать применимым".
равно как и работоспособность системы - без него вообще.
Какие интересные у вас требования. Вот только к работоспособности системы они не имеют отношения, не обманывайте себя)
Да.
Какой настырный мазохист. Тебя тут золотым дождем в глазики балают, а ты кланяешься и говоришь: ещё, ещё!
И что? В Debian давно несколько пакетов.
> И что? В Debian давно несколько пакетов.Просто вброс.
Системдкапец!
предложение здравое, но...клепать новости по таким мелочам - это перебор
unix-wayненько
> unix-wayненькотоненько
А что, он до этого одним пакетом шёл? Вот это новость.
Давно пора. Практикую такой подход в дебиане ещё с версии 219. Правда, 228 бэкпортировал уже со скрипом.
только OpenRC ! только хардкор !!
*рубит гопака*