LINUX.ORG.RU
ФорумTalks

Свидетелям питона: dnf переписывают с Python на C++

 , , ,


0

1

На 7 год существования индеец «Шляпа, Быстрая Как Ветер» заметил, что тормознее dnf только портаж, компилирующий пакеты.. Оказывается если ресурсоемкую программу написать на питоне, она будет тормозить! Кто бы мог такое представить?!

https://www.opennet.ru/opennews/art.shtml?num=52494

Дэниел Мах (Daniel Mach) из компании Red Hat сообщил о начале разработки пакетного менеджера DNF 5, в котором будет выполнен перенос реализованной на языке Python логики DNF в библиотеку libdnf, написанную на C++. Тестирование DNF 5 планируется начать в июне в процессе разработки Fedora 33, после чего в октябре 2020 года добавить в репозиторий Rawhide, а в феврале 2021 года заменить им DNF 4. Сопровождение ветки DNF 4 будет продолжено, так как она применяется в Red Hat Enterprise Linux 8.

Отмечается, что проект достиг состояния, в котором почти невозможно продолжать развитие кода без нарушения совместимости на уровне API/ABI. Главным образом это связано с потерей актуальности PackageKit и невозможностью развития libdnf без изменения API "libhif". При этом несмотря на намерение поменять API, в качестве основных приоритетов называется сохранение обратной совместимости на уровне интерфейса командной строки и API.

Поддержка Python API в DNF будет оставлена, но написанная на Python бизнес-логика будет перенесена в библиотеку libdnf (C++), что позволит гарантировать идентичность работы пакетного менеджера в дистрибутиве. Разработка будет сосредоточена вокруг C++ API, а Python API будет автоматически генерироваться в форме обвязки на его основе. Аналогичным образом будут сформированы биндинги для Go, Perl и Ruby. После стабилизации C++ API на его основе будет подготовлен и C API, на который будет переведён rpm-ostree. Hawkey Python API будет удалён и заменён на libdnf Python API.

Основная функциональность DNF будет сохранена. Благодаря наличию большого тестового набора (около 1400 тестов) ожидается, что переработка API не скажется на интерфейсе командной строки для конечных пользователей. Возможно немного изменится разбор аргументов и вывод, но эти изменения будут хорошо документированы. В урезанной версии microdnf, применяемой в контейнерах, планируется реализовать подмножество возможностей DNF, достижение полного паритета в функциональности не рассматривается.

Вместо PackageKit будет создан новый сервис DBus, предоставляющий интерфейс для управления пакетами и обновлениями для графических приложений. Данный сервис планируется разработать с нуля, поэтому его создание может потребовать много времени. PackageKit последнее время не развивается и находится в режиме сопровождения с 2014 года из-за потери актуальности. С продвижением систем Snaps и Flatpak дистрибутивы теряют интерес к PackageKit, например, в он уже не поставляется в сборках Fedora SilverBlue. Уровень абстракции для управления пакетами во многом обеспечивается штатными центрами управления приложениями GNOME и KDE, которые позволяют устанавливать flatpak-пакеты на уровне отдельных пользователей. Унифицированный системный API для получения списка установленных пакетов становится не настолько полезен как раньше.
★★★★★

Последнее исправление: Im_not_a_robot (всего исправлений: 1)

А что там в самом dnf ресурсоёмкого? Решатель-то там внешний — libsolv. А судя по https://lwn.net/Articles/750238/ dnf переписывают с пистона уже два года как. Так что кто же на самом деле индеец надо разбираться.
кек DNF будет переписан на языке C

imul ★★★★★
()
Последнее исправление: imul (всего исправлений: 2)

Я не пойму, если просто код на питоне меняют на код на c++ кто мешает сохранить API и тем более интерфейс командной строки?

С сохранением ABI понятно могут быть трудности, но было бы желание, почему бы и его не сохранить.

praseodim ★★★★★
()

PackageKit последнее время не развивается и находится в режиме сопровождения с 2014 года из-за потери актуальности.

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

eR ★★★★★
()
Ответ на: комментарий от scanner

Ты быканул, или мне показалось?

Deleted
()

Ну собственно вполне логично.

rumgot ★★★★★
()
Ответ на: комментарий от praseodim

Я не пойму, если просто код на питоне меняют на код на c++ кто мешает сохранить API и тем более интерфейс командной строки?

Интерфейс итак тот же. А смена апи это такое совпадение. Мол раз уж сгорел сарай, то гори и хата. Просто повод.

imul ★★★★★
()

Слава Патрику.

DNF это стыд и срам ынтерпрайзного Linux и RedHat.

Когда наконец IBM поувольняет к чертям RedHat-овских Python-кодеров, которые сделали чертовски медленными RHEL/CentOS/Fedora. Один только их установщик, который дрищет питоновскими стектрейсами на каждый чих чего стоит.

EXL ★★★★★
()

На 7 год существования индеец «Шляпа, Быстрая Как Ветер» заметил, что тормознее dnf только портаж,

Что б ты понимал в бизнесе!

Дважды написать одну и ту же программу - означает дважды освоить выделенные средства и дважды отчитаться об успехах перед топ менеджерами.

Deleted
()
Ответ на: комментарий от EXL

Удивительно, но черт-те кем написанная на помеси крестов и перла аптитуда, которая умеет мягкие зависимости последние 20 лет, по скорости, гибкости и фичастости уделывает и dnf и (простите за испорченный аппетит) yum, за которыми стоит корпорация с миллионами нефти.

leave ★★★★★
()

Было бы неплохо, если бы что-то сделали со скоростью bash autocompletion, последние релиза 3 просто невыносимо. В остальном претензии по производительности непонятны.

Midael ★★★★★
()
Ответ на: комментарий от Midael

Было бы неплохо, если бы что-то сделали со скоростью bash autocompletion, последние релиза 3 просто невыносимо

Проблемы Bash’а обычно решаются его выкидыванием.

EXL ★★★★★
()
Ответ на: комментарий от imul

Я тоже не пойму. Разрешение зависимостей в dnf проходит довольно шустро. А инсталяция самих пакетов - вот где тормоза. Им надо сам rpm переписывать, а не dnf.

rupert ★★★★★
()

ресурсоемкую программу

Что там такого ресурсоёмкого, что они на питоне это оптимизировать не осилили?

Имхо, бред. Может быть, я чего-то не знаю, но по-моему тут проблема не в питоне, а в руках из жопы.

WitcherGeralt ★★
()

Отлично. Давно пора. Наконец-то Пихтон выкидывают!

Deleted
()
Ответ на: комментарий от No

Черт возьми, а ведь я только начал считать федору нормальным дистром.

unicorne
()
Ответ на: комментарий от imul

А, т.е. мне это не приснилось? Я думал dnf уже давно на C. Да и работает он не в пример быстрее yum.

atrus ★★★★★
()

Оказывается если ресурсоемкую программу написать на питоне, она будет тормозить!

Пофиксил

ya-betmen ★★★★★
()
Ответ на: комментарий от LINUX-ORG-RU

Сначала они пришли за ipchains, потом за nslookup, потом за ifconfig, потом внезапно без dbus нифига не работает... Это линукс, ничего не поделаешь.

Shadow ★★★★★
()
Ответ на: комментарий от ya-betmen

Просто на питоне легко написать программу, которая будет тормозить. Которая не будет тормозить тоже легко, но нужно «векторизовывать», применять питоновскую «функциональщину» и всё такое.
Вроде в ruby сложнее тормозить, почему ж он в итоге проиграл...

Shadow ★★★★★
()
Последнее исправление: Shadow (всего исправлений: 1)
Ответ на: комментарий от Shadow

Ага. Это не линукс это пропихульки пропихивают свои пихульки. =( Эсли бы эти пихульки работали нормально спустя 100500 лет слов бы не было в упрёк.

LINUX-ORG-RU ★★★★★
()
Ответ на: комментарий от No

*протухшие кодеки как и весь софт в любых репозиториях

Exmor_RS ★★★
()

Суровый ынтырпрайз будет игнорировать раст до последнего, вопреки всякой логике и во вред себе.

tommy ★★★★★
()

Почему я не удивлён?... Если в Кедах перестанут подобное использовать цены им не будет.

xwicked ★★☆
()
Ответ на: комментарий от Shadow

Просто на питоне легко написать программу, которая будет тормозить. Которая не будет тормозить тоже легко, но нужно «векторизовывать», применять питоновскую «функциональщину» и всё такое. Вроде в ruby сложнее тормозить, почему ж он в итоге проиграл…

На Ruby есть Homebrew, фактически стандарт пакетного менеджера для Мака.

OSBuster
()
Ответ на: комментарий от Midael

а что там со скоростью? С первых версий пользуюсь и ничего не тормозит вроде. или apt-get install тормозит? :)

mrdeath ★★★★★
()
Ответ на: комментарий от WitcherGeralt

проблема не в питоне, а в руках из жопы

Почему не может быть и того, и другого?

Im_not_a_robot ★★★★★
() автор топика

На 7 год существования индеец «Шляпа, Быстрая Как Ветер» заметил, что тормознее dnf только портаж, компилирующий пакеты..

Как ты мог! Он же не тормозной у него просто фич сильно много и всех полтора разраба портежа ещё не покусали гномовцы.

Оказывается если ресурсоемкую программу написать на питоне, она будет тормозить! Кто бы мог такое представить?!

Вот это новости! Прям интриги, скандалы, расследования…

init_6 ★★★★★
()
Ответ на: комментарий от BceM_IIpuBeT

Очевидно, потому что Раст хуже Си++ в скорости, а в умелых руках и в простоте кодинга (если чел знает си++ то на си++ проще) ну и код читаемее для сообщества чем говонсинтаксис раста - классический код си семейства.

bonta ★★★★★
()

dnf переписывают с Python на C++

Тебя родители не учили, что врать нехорошо?

gremlin_the_red ★★★★★
()

Раньше тормозил, а теперь будет падать? Ну такое.

RazrFalcon ★★★★★
()
Ответ на: комментарий от Stremitelnyj

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

Shadow ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.