В Fedora планируется заменить DNF на MicroDNF

Когда же наконец MicroDNF заменят на APT/Pacman/Slcpkg/Portage, а RPM - на deb/tar.xz/slckpkg/.git ? Фрагментация на порядок в Linux сократится. А ну еще и snap/appimage/flatpak закопать (поскольку eMMC-ноутбукам контейнеры строго противопоказаны из-за ограниченности пространства и чрезмерной записи), и тогда точно в Linux настанет порядок и можно будет писать фотошопы и прочее.

RPM - на deb/tar.xz/slckpkg/.git

Интересно было бы увидеть дистрибутив, целиком основанный на git (естественно, source-based), с версионированием во все поля. И чтобы над всем этим был человекоориентированный интерфейс (можно даже несколько, с CLI, TUI, GUI и вебом на все вкусы), детально подсказывающий, что и где изменилось.

Как я понимаю, всякие NixOS на похожих идеях основаны?

А если серьёзно, то это настоящая Санта-Барбара. Сначала выкатили DNF, чтобы избавиться от питона, теперь сообразили, что избавились не полностью. Смотрите второй сезон!

А как же б~жественный Хруст?!

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

Первый шаг к замене DNF на Microdnf - это планируемое в выпуске Fedora Linux 38

Короче еще минимум год ждать.

Капец, Хоббит аву сменил.

Новость посерьёзнее сабжевой.

Когда же наконец MicroDNF заменят на APT/Pacman/Slcpkg/Portage, а RPM - на deb/tar.xz/slckpkg/.git ?

Примерно тогда же, когда APT/Pacman/Slcpkg/Portage заменят на MicroDNF, а deb/tar.xz/slckpkg/.git на RPM. И фрагментация на порядок в Linux сократится.

Учитывая, что pacman технологичнее и фичастее и не требует двойного переписывания…

Корпорации такие корпорации.

Учитывая, что pacman технологичнее и фичастее и не требует [b]двойного переписывания[/b]…

Там транзакции хоть есть? Энтерпрайз хочет суровых решений, а не вот технологичность.

У него история есть, чтобы сделать undo? Игнор пакетов есть? Version lock есть? Он умеет показывать пакет, который содержит определённый файл? Он имеет команду для даунгрейда? Уже поддерживает одновременное скачивание нескольких пакетов из коробки?

В отличии от DNF (написанного частично на Python, частично на C), microdnf целиком написан на C.

Посмеялся с тех евангелистов Red Hat, которые недавно тут кукарекали мол всё нормально с производительностью YUM и DNF на Python-клее, не надо ничего переписывать. Кстати, где они все? Ау!

поганый дистр:( вечно один костыль на другой заменяют:( вечно какие-то политические и идейные решения:( и это стоит во главе развития линукса:( ну хорошо, дома свалил на *BSD. но на работе-то везде линукс будет.

У него история есть, чтобы сделать undo? Игнор пакетов есть? Version lock есть? Он умеет показывать пакет, который содержит определённый файл? Он имеет команду для даунгрейда? Уже поддерживает одновременное скачивание нескольких пакетов из коробки?

Последнее - уже давно.

Ого, теперь не нужно ставить aria2

Там транзакции хоть есть? Энтерпрайз хочет суровых решений, а не вот технологичность.

Напомни можно ли обновить rhel 6->7->8 или это слишком сурово для Энтерпрайз решений со всеми вот этими транзакциями? :-D

Кстати, где они все? Ау!

alpha сейчас, видимо, занята на фронтах интернет-сражений (она же bookwar).

Ого, теперь не нужно ставить aria2

а что, раньше было так - ставишь aria2 и pacman резко умеет в

одновременное скачивание нескольких пакетов

?

Возможно, я перепутал. В последний раз я пользовался рачем лет 5 назад. И он тогда, вроде бы, не умел в одновременное скачивание.

Слышал, что YUM тормозной. Слышал, что DNF менее тормозной, чем YUM. И всё равно DNF тормозной

Новая версия Microdnf также будет использовать фоновый процесс DNF Daemon, заменяющий функциональность PackageKit и предоставляющий интерфейс для управления пакетами и обновлениями в графических окружениях. В отличие от PackageKit в DNF Daemon будет предоставляться поддержка только формата RPM.

ммм! конфэтка.

Слышал, что YUM тормозной. Слышал, что DNF менее тормозной, чем YUM. И всё равно DNF тормозной

я помню, что ты не технарь. так вот чисто по секрету скажу, что dnf - это просто ребрендинг yum. там даже конфиги в /etc/yum.conf.d остались те же.

Возможно, я перепутал. В последний раз я пользовался рачем лет 5 назад. И он тогда, вроде бы, не умел в одновременное скачивание.

насколько я помню, то и dnf изначально в один поток качал. давай уж тогда сравнивать всё пятилетней давности.

У него история есть, чтобы сделать undo?

Только в виде текстового лога.

Игнор пакетов есть?

Да.

Version lock есть?

Да.

Он умеет показывать пакет, который содержит определённый файл?

Да, для установленных пакетов - фича вшита в бинарь пакмана.

Для пакетов из репы в целом - тоже были какие-то команды, чтобы строить индекс. Я не помню деталей, так как не пользовался этой фичей.

Он имеет команду для даунгрейда?

Нет. Разве что вручную указать поставить пакет из файла.

Уже поддерживает одновременное скачивание нескольких пакетов из коробки?

Давно.

В целом мой пойнт не в том, что надо бежать и внедрять пакмана в RH.

А в том, что сообщество в данном случае смогло сделать технологичный инструмент под свои нужды, а корпорация - нет.

Пакман в текущем виде не имеет нужного объема фич для системы типа RHEL или Fedora, но при необходимости это допиливабельно ресурсами, которые гораздо меньше, чем те, что RH потратила на переписывание своего ПМ.

Надо сказать, что те фичи, которые в пакмане есть, работают прекрасно. И сама кодовая база стабильная и качественная.

Надесь, что с этой попытки у RH получится довести до ума всё, что запланировано.

И фрагментация на порядок в Linux сократится.

Да-да, фрагментацию платформы Linux лучше сокращать с помощью пакетной системы, которая сама имеет альтернативных реализаций столько же (Zypper, Urpmi, APT-RPM, DNF), сколько и альтернативных пакетных систем (APT, Pacman, Slcpkg, Portage). Причем достаточно для опакечивания ввиду опытности пользователей трех последних пакетных систем (в тот же AUR всегда завезут какой-нибудь перепаковщик .deb, ебилд тоже напишут) всего одной-двух. А вот пакеты изготавливать для ALT/Suse/Rosa(Mageia) - некому. Да что там, даже внутри RedHat нет единства. Ибо не все, что есть в Fedora, можно притащить в Stream или RHEL.

Не то чтобы тормозной. Я бы сказал, что скачивает и устанавливает пакеты он даже быстрее pacman. Но вот думает он действительно ОЧЕНЬ долго. Запускаешь обновления и ждёшь, ждёшь… пока он начнёт обновлять репозитории. А в остальном, dnf не плох

Учитывая, что pacman технологичнее и фичастее и не требует двойного переписывания…

им важно сохранить формат пакета RPM, чтобы мейнтейнеры могли работать как ни в чем не бывало. замена на pacman - это наивное предложение. но по-моему alt использует apt для инсталяции rpm.

а корпорация - нет

Ну не совсем. Почти все фичи, про которые я написал, появились ещё в yum в CentOS 7. Некоторые фичи, вроде замены одного пакета на другой (dnf/yum replace) в yum ставились как плагин, в dnf уже из коробки.

Основная проблема в том, что yum был дико медленным говном, потому что написан на питоне. dnf уже стал чуточку быстрее, т.к. частично его переписали на сишку, и далее всё больше переписывали. Т.е. фичи есть, написать на нормальном языке сразу, а не на питоне - нет.

New Daemon

The new daemon can provide an alternative to PackageKit for RPMs (only one backend of PackageKit) if it will be integrated into the Desktop

Никто не собирается выкидывать PackageKit на мороз. Речь идет о том, что сам PackageKit не поддерживает всех фич libdnf, потому и запилили альтернативу. Ожидается, что разработчики всяких Gnome Software впилят поддержку этого нового демона.

python - нормальный язык для клея и быстрой разработки. а С уже не выглядит таким нормальным на фоне раст. я регулярно сталкиваюсь с сегфолтами сишного кода во FreeBSD и каждый раз мечтаю, чтобы у этих прогеров забрали гранату и заставили (!) писать на rust.

python - нормальный язык для клея и быстрой разработки.

Да, но с производительностью у него не очень.

С уже не выглядит таким нормальным

Я в целом про любой нативный язык. Что мешало им написать DNF на C/C++/Rust/etc - непонятно.

и это стоит во главе развития линукса

Не стоит. Это тестовая площадка для коммерческого RH. Понятно же, что на тестовой площадке все инициативы «с колёс».

запилили альтернативу

апплодисмены стоя.

Избавиться от питона – верное направление.

Не стоит. Это тестовая площадка для коммерческого RH. Понятно же, что на тестовой площадке все инициативы «с колёс».

нет, не понятно. yum появился в федоре - появился в RHEL. также dnf.

Да-да, фрагментацию платформы Linux лучше сокращать с помощью пакетной системы, которая сама имеет альтернативных реализаций столько же (Zypper, Urpmi, APT-RPM, DNF), сколько и альтернативных пакетных систем (APT, Pacman, Slcpkg, Portage).

Да, она самая популярная, и по этой причине её надстраивают. Поэтому стандартом должна стать она, а не маргинальные поделки, на которые никто не обращает внимания.

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html-single/upgrading_from_rhel_6_to_rhel_7/index

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/upgrading_from_rhel_7_to_rhel_8/index

Больше возни с подпиской, чем в дебиане, в остальном всё также.

Встречный вопрос - а pacman вообще может со стабильного релиза на стабильный релиз, или у него только роллинг?

Никто (ну в ощутимом проценте никто) не возражал, вот и появился. На то Fedora и тестовый полигон. Работает, юзеры не бугуртят - ну ещё немного погоняем и в прод (т.е. в RHEL)

Никто (ну в ощутимом проценте никто)

ага. я об этом уже писал alpha. сначала RH полностью игнорирует альтернативное мнение (как с systemd), недовольные юзеры уходят, RH заявляет, что никто в ощутимом проценте не возражает. => profit!

типа как вот здесь: В Fedora планируется заменить DNF на MicroDNF (комментарий)

я повторю свой поинт: IBM/RH являет лидером и трендмейкером в мире линукс.

С другой стороны, приходят как раз те люди, которым это надо, так что таки да, profit.

С другой стороны, приходят как раз те люди, которым это надо, так что таки да, profit.

таким образом корпорация формирует запрос userbase. т.е. никакая не свобода пользователя, как было когда-то. в итоге ты потом на форуме не можешь найти ни одного линуксоида, который может написать скрипт. все такие: ффуууу! скрипты:(((

и linux-community превращается в еще одну windows-like community aka «хочу, чтобы просто работало».

Да, она самая популярная, и по этой причине её надстраивают.

У дистроделов. А сторонние разработчики выбирают что постабильнее и большим охватом ЦА, а это конечно же, DEB. Потому что одну .deb гораздо проще изготовить, нежели чем 4 RPM-пакета и писать к ней документацию. Скачал, набрал dpkg -i *.deb в чем угодно или воспользовался гуйней - и продукт готов к употреблению. И причем неважна хост-система. Хоть Debian, хоть Ubuntu, хоть Devuan, хоть...

А на RPM желающие находятся только для Fedora, и то не все. А все потому что объяснить тем же пользователям Suse, что эта RPM только для Fedora, и даже не для RHEL, практически невозможно.

И причем неважна хост-система.

и у деба и у rpm есть версии совместимости. там разницы между ними большой нет. я билдил обе. deb vs rpm - это спор об одном и том же. RH не хочет менять половину штата, потому что они привыкли к rpm. вот и все.

и у деба и у rpm есть версии совместимости. там разницы между ними большой нет. я билдил обе.

С виду. Но когда речь идет о распространении, тут уже как бы все недостатки RPM вылазят наружу. Билдить для репа и заниматься распространением - это все-таки две разные вещи. Когда речь идет о распространении, вся фрагментация RPM портит малину, поскольку как только скармливается бинарь в какой-нибудь Opensuse, начинаются танцы с бубном. А вот дебианщики спокойно потаскивают себе все барахло с лаунчпада, которое там валяется по следующей формуле: дата стайбел-релиза и ближайший к нему релиз бубунты. Например, для Bullseye таскают бинарники c Hirsuite, а для того же Bookworm пока можно таскать с Jammy.

Да. Бизнес вообще склонен к тому, чтобы подсаживать на свои продукты и «хочу, чтобы просто работало».

У дистроделов.

Мнение дистроделов важно.

А сторонние разработчики выбирают что постабильнее и большим охватом ЦА, а это конечно же, DEB.

Google chrome выдаётся в виде двух пакетов - deb и rpm. Одного rpm, а не пятидесяти вариантов. Как так?

Мнение дистроделов важно.

До тех пор, пока оно не наступает на горло мнению сторонних разработчиков ПО, которые в другом дипломатическом положении - они вообще могут целиком проигнорировать пингвин и заниматься разработкой Only Windows. А дистродел без стороннего ПО - не нужен!

Google chrome выдаётся в виде двух пакетов - deb и rpm. Одного rpm, а не пятидесяти вариантов. Как так?

Может быть потому, что в нем пренебрегли аудиторией альта и Mageia (Росы)?

Может быть потому, что есть LSB? А LSB-несовместимые дистры ССЗБ. В альте, например, есть epm, который ставит хром из того самого rpm.

Вообще, использование внутреннего формата пакетов для распространения внешнего софта это отдельная шизофрения, конечно.

обычная итерация, потом еще на раст перепишут или на плюсы, когда С надоест поддерживать. Сколько линукс не улучшая все равно каждые 5 лет его перекраивают в фундаментальном ПО. То звуковую подсистему перелопатят, то схватятся графический сервер переписывать, то пакетный менеджер ни к черту, а то и система инициализации никуда не годится.

А вот дебианщики спокойно потаскивают себе все барахло с лаунчпада

да нифига. у убунту привязки дебов к дистрам.