Вместо намеченного на 9 января нового модульного серверного дистрибутива Fedora 27 Modular Server опубликованы (https://fedoramagazine.org/fedora-27-server-classic-release/) классические сборки Fedora 27 Server (https://getfedora.org/server/). По функциональности Fedora 27 Server близок к Fedora 26 и отличается лишь обновлением версий пакетов.
Переход на модульную архитектуру (https://www.opennet.me/opennews/art.shtml?num=46921) отменён после анализа отзыва пользователей бета-версии. Из всплывших недостатков, мешающих переходу на модульную архитектуру, упоминаются невозможность включения в модульную редакцию приложений, не оформленных в виде модулей (могут поставляться только части ПО, явно включённые в модули), а также наличие ещё одного уровня абстракции, приводящего к неприемлемому усложнению всей системы.Модульная редакция возвращена на стадию проектирования, где она будет переосмыслена. Разработчики не отказываются от планов по предоставлению модульного варианта дистрибутива, но, скорее всего, он будет предложен не как замена традиционному дистрибутиву Fedora, а как отдельная редакция, построенная на его пакетной базе и сосуществующая с ним. В частности, вместо создания новой модульной операционной системы планируется создать отдельный модульный репозиторий пакетов, который будет реализован как дополнительный слой над штатным репозиторием Fedora. Подобный подход упростит работу сопровождающих пакеты и предоставит пользователям возможность выбора.
Напомним, что главной идеей модульного варианта Fedora является поставка приложений в виде отдельно обновляемых модулей, жизненный цикл которых не привязан к другим приложениям и основной начинке дистрибутива. Поддержка приложений, выделенных в модули, осуществляется независимо от релизов дистрибутива, что позволяет обеспечить сосуществование пакетов с разными версиями одного и того же приложения. Модульная организация позволяет пользователю переходить на новые значительные выпуски приложения не дожидаясь нового релиза дистрибутива и оставаться на старых, но ещё поддерживаемых, версиях после обновления дистрибутива.
Каждый модуль включает базовое приложение и необходимые для его работы библиотеки или может использовать в качестве зависимостей другие модули. Модули оформлены в виде сгруппированных rpm-пакетов, что позволяет формировать на их базе образы готовых для установки контейнеров Docker. В рамках одной базовой версии модуля обеспечивается обратная совместимость и неизменность ABI. Для каждой базовой версии модуля предусмотрен отдельный канал для доставки корректирующих обновлений.URL: https://fedoramagazine.org/fedora-27-server-classic-release/
Новость: http://www.opennet.me/opennews/art.shtml?num=47727
> наличие ещё одного уровня абстракции, приводящего к неприемлемому усложнению всей системыКакая неожиданность, ну кто бы мог подумать!
действительно, неожиданность.
Разум, неожиданно, победил. Впрочем, вряд ли надолго.
А вам бы все сидеть на 386BSD и каждый раз руками ПО собирать?
Это лучше, чем быть халявным бета-тестером RedHat.
> Разум, неожиданно, победил. Впрочем, вряд ли надолго.И вряд ли разум, боюсь :( Скорее страх боли.
Мероприятие сродни usrmove по степени заметания, как мне думается.
Я уже несколько лет пользуюсь scl от того же редхата. Просто замечательно работает.
Вполне адекватно решает проблему версий.
Что им не хватает?
NixOS. Модульнее никак.
> NixOS. Модульнее никак.Лол нет. Они предпочтут ставить rpm-ки в ostree.
> невозможность включения в модульную редакцию приложений, не оформленных в виде модулейКэп?!
> Модульная редакция возвращена на стадию проектирования, где она будет переосмыслена.У меня СОМНЕНИЯ, ведь "наличие ещё одного уровня абстракции, приводящего к неприемлемому усложнению всей системы" этих проектировщиков не остановила.
> который будет реализован как дополнительный слой над штатным репозиторием FedoraСм. выше.
> Каждый модуль включает базовое приложение и необходимые для его работы библиотеки или может использовать в качестве зависимостей другие модули.Какое-то велосипедирование обычных зависимостей: "А назовем-ка мы пакет с зависимостями модулем! А опциональные зависимости тоже назовем модулями!"
Тащем-то, во Flatpak ставятся зависимости не по одному пакету, а целыми наборами-пачками. Видимо, тут хотели что-то подобное.
Вот странно, чего им флатпак-то не угодил.
NIH?
Flatpak разработан для поставки приложений для этого нашего десктопа. И к серверам отношения не имеет.
> для этого нашего десктопа.Да, именно вашего.
> а целыми наборами-пачками.И где плюсы? Тут, значится, у нас модульный kf5, а они запиливают свой "модуль", в который все сразу включено?! Потрясающе просто. «Установка в две галки: "поставить сустемд с ядром" и "накатить пятокеды с иксами и вейландами".»
А я и не говорил что это хорошо. Flatpak - это такой жирный user-friendly chroot с пакетами "всё в одном".
> А я и не говорил что это хорошо. Flatpak - это такой
> жирный user-friendly chroot с пакетами "всё в одном".Cgroup namespaces далеко от chroot ушли.
>> А я и не говорил что это хорошо. Flatpak - это такой
>> жирный user-friendly chroot с пакетами "всё в одном".
> Cgroup namespaces далеко от chroot ушли.Это runtime, а он про организацию на диске, очевидно. Вы там своим смузи обожрались или перемазались, что не разбираете элементарного? :)
>>> А я и не говорил что это хорошо. Flatpak - это такой
>>> жирный user-friendly chroot с пакетами "всё в одном".
>> Cgroup namespaces далеко от chroot ушли.
> Это runtime, а он про организацию на диске, очевидно. Вы там
> своим смузи обожрались или перемазались, что не разбираете элементарного? :)Так я ничего про организацию на диске не говорил.
Тем более, что комментатор выше про kf5 - ошибается.
Это что приложениея в контейнерах что-ли теперь?
Нет, это вообще не про контейнеры, а, например, про то, что вот стоит у тебя в системе питон 3.a и постгрес y.z, на которые могут быть завязаны другие пакеты в системе, но при этом тебе нужна более новая версия питона 3.b (новый модуль в стандартной либе и нужное расширение языка), но при этом постгрес нужен более старой версии x.w (потому что фичи из новой версии тебя не колышат, а мигрировать полутерабайтную базу ради смены циферки влом).Так вот модули - это способ обособить группы тесно связанных пакетов, чтобы была возможность релизить их более-менее независимо, а пользователям обновлять куски дистра в соответствии со своими потребностями. Т.е. на указанном примере будет отдельный модуль с питоном и отдельный модуль с постгресом, и при этом у них будут отдельные релиз-циклы и не будет жесткой привязки одного к другому на уровне пакетного менеджера через третьи зависимости
> Так вот модули - это способ обособить группы тесно связанных пакетовЭто попытка сделать контейнеры без контейнеров, получив половину проблем и ни одного плюса. Потому что следующий же вопрос при необходимости засунуть софты с разным жизненным циклом на один физический или виртуальный хост будет в разделении привилегий.
В общем, когда теоретики от погромизма начинают чё-то изобретать, не попробовав это применять в жизни, выходит очередная мегапарольная система в grub2, не умеющая единственного реально нужного варианта использования из grub1 ("спросить пароль, если чё-то пытаются поменять, иначе молча бутаться") и вместо того либо всегда спрашивающая, либо не спрашивающая вовсе. Зато с системой пользователей, во.
Еще в ведрах и баках.
Не получилось Поттерингу протащить контейнеры со смузи в основную ветку.
К сожалению, смузижоры от этого не подохнут: ещё громче будут расхваливать системды-вэйланды-флатпакды.
> К сожалению, смузижоры от этого не подохнут: ещё громче будут расхваливать системды-вэйланды-флатпакды.К сожалению, старпёры/ниосиляторы от этого не подохнут: ещё громче будут ныть что везде системды-вэйланды-флатпакды, а им надо опенрки-иксы-пакеды.
Чтобы обмазываться скриптами... и текстами через пайпы обмениваться.
> Чтобы обмазываться скриптами... и текстами через пайпы обмениваться.Как там было -- "последнего программиста на java похоронят, а счёт на похороны выпишет программа на cobol".
Вот где-то так и с вами будет, любители тянуть блестяшки в рот из шляпной секты.
> Как там было -- "последнего программиста на java похоронят, а счёт на
> похороны выпишет программа на cobol".s/cobol/C/
> она будет переосмыслена.Во как!
>> она будет переосмыслена.
> Во как!Ну ведь kdbus же переосмыслили.
>kdbus же переосмыслилиКстати, где он?
>>kdbus же переосмыслили
> Кстати, где он?Где-то в /dev, подозреваю...
>>kdbus же переосмыслили
> Кстати, где он?Он теперь Bus1 же.
> отменён после анализа отзыва пользователей бета-версии.И с systemd так же было?
>> отменён после анализа отзыва пользователей бета-версии.
> И с systemd так же было?Видимо нет. Раз его притащили в основную ветку.
Лёня не настолько слабак, у него любой шлак является релиз версией, а беты для слабаков и стариков. И вообще, он ведь явно себя именует 'PID 1', ну вы поняли кто главный.
> 'PID 1'Пид #раз?
У systemd тестирование бета-версии в самом разгаре!
А чё тогда выглядит как альфа?
потому что его автор не выглядит как альфа Ж)
Эм ребята хотят snap заиспользовать? плюсом еще баззворд докер
flatpack
Передайте им, что Portage уже изобрели и все эти задачи давно решены. Rolling Release тоже уже давно придуман.Не, я серьезно - что мешает всем дистрибутивам перейти на Portage, запилив собственные бинхосты и фиг с ним - используя свой сервер для синхронизации ебилдов? Тогда и переход между дистрибутивами был бы возможен без полной переустановки, и возможность подключения репозиториев даже между разными дистрибутивами была бы через Layman...
Мне и на Фре с роллингом не плохо. Однако, надо отдать должное, стараются, придумывают.
Идея здравая, надеюсь у них всё получится.
Проще перестать ломать зависимости чем делать это всё. Пока ребята "переосмыслят", пытаясь решить текущие проблемы, в мире линукса так всё поменяется, что найденное ими решение станет не актуальным, но узнают они об этом слишком поздно. К сожалению.
Сочувствую команде разработчиков, которые зря старались.