Разработчики Fedora Linux намерены перевести дистрибутив на новый пакетный менеджер Microdnf вместо ныне используемого DNF. Первым шагом на пути к миграции станет планируемое в выпуске Fedora Linux 38 значительное обновление Microdnf, который будет приближен по функциональности к DNF, а в некоторых областях даже станет его превосходить. Отмечается, что новая версия Microdnf будет поддерживать все основные возможности DNF, но при этом сохранит высокую производительность и компактность...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=57023
Чем это лучше pacman?
Тем, что выполняет основную задачу пакетного менеджера — поддержание целостности системы, в отличие от pacman, который легко позволяет, например, обновить libavcondec.so.N на libavcodec.so.N+1, оставив пакет с /usr/bin/mpv слинкованным с libavcondec.so.N. Автоматики для отслеживания такого в pacman и сборочном инструментарии пакетов для него нет.
Какая-то надуманная проблема уровня DLL-hell. Давно решена в современных дистрибутивах.
>Давно решена в современных дистрибутивахКонечно решена - наличием нормальных пакетных менеджеров.
Например?
pacman
> Например?apt+dpkg :P. Работает резво, ресурсов жрет в разы меньше, зависимости разруливает, что еще надо?
Ты хотел сказать apt-rpm?
> Какая-то надуманная проблема уровня DLL-hell. Давно решена в современных дистрибутивах.Вы отвечаете человеку, который не осилил поддерживать urpmi + rpm5 в "разрабатываемом" им дистрибутиве, потому сменил их на DNF + rpm4. Про целостность я им писал давно, имея ввиду совершенно иное, он тупо запомнил и ретранслирует, приплетая что попало.
И кому это в здравом уме может понадобиться? so файл из libavcodec-devel в таком случае на что будет указывать? еще говорят в венде WinSxS мусорка...
> кому это в здравом уме может понадобитьсяТебе не нужно, значит никому не нужно?
> libavcodec-devel в таком случае на что будет указывать
Вот кто эту убогую концепцию devel-пакетов придумал, тот пусть и разруливает. В современных дистрибутивах такая проблема невозможна. А луддиты пусть страдают.
"В современных" - это в которых все компоненты поставляются в виде контейнеров под радостные визги смузихлебов?
Мусорка у тебя в голове. Если версии либы между собой несовместимы и ломают сборку проги, то прога использует не so, а so.X.Y.Z, где X.Y.Z - минимальный путь набора версий, всегда работающих с программой. Несовместимые версии либ, естественно, идут разными пакетами и друг другу не мешают.
Что если я запущу полное обновление и обновится только библиотека, но не приложение, которое от нее зависит?
Подобный сценарий вообще не должен случиться. Предположим, что приложение foobaz находится в одном из официальных репозиториев и успешно собирается с новой версией библиотеки libbaz — тогда оно будет обновлено вместе с libbaz. Если, однако, оно не собирается, пакет foobaz будет иметь версионную зависимость (например, libbaz 1.5) и будет удален при обновлении libbaz по причине конфликта.Если пакет foobaz вы скачали из AUR и собрали самостоятельно, вам следует попытаться пересобрать foobaz с новой версией libbaz. Если сборка завершится неудачей, отправьте отчет об ошибке разработчикам foobaz.
> pacman -Qi ffmpeg | grep Provides
> Provides : libavcodec.so=59-64 libavdevice.so=59-64 libavfilter.so=8-64 libavformat.so=59-64 libavutil.so=57-64 libpostproc.so=56-64 libswresample.so=4-64 libswscale.so=6-64
> pacman -Qi ffmpeg4.4 | grep Provides
> Provides : libavcodec.so=58-64 libavdevice.so=58-64 libavfilter.so=7-64 libavformat.so=58-64 libavutil.so=56-64 libpostproc.so=55-64 libswresample.so=3-64 libswscale.so=5-64
> pacman -Si electron | grep Provides
> Provides : electron18
> pacman -Si electron12 | grep Provides
> Provides : None (значит предоставляет electron12)А затем у пакетов depends=( ... libavcodec.so=59-64 ...)
То есть, pacman позволяет, но только на уровне _отдельных_ пакетов, но и эту фичу/костыль почти не используют почему-то в Arch Linux, а она бы пригодилась для harfbuzz, icu. Хотя вообще в AUR есть пакеты icu65, icu67, icu50, но нет icu70. Точнее есть icu версия 70.1 из репозитория [core], но т.к. название одинаково с icu версии 71.1 из [testing], то их нельзя параллельно установить, хоть и поле provides заполнено.
Так у них в доке (вики) и написано:
https://wiki.archlinux.org/title/System_maintenance#Partial_...
> Тем, что выполняет основную задачу пакетного менеджера — поддержание целостности системыОни за... своими "транзакциями", откатами и прочим булшитом в стиле setupexe.msi. Результатом - оверинженернутый МОНСТР, который на вот этом самом постоянно и ломается. Когда транзакции разваливаются и вы ощущаете булшит про целостность по максимуму.
Может быть, это сложно понять, но файловые системы со снапшотами это делают многократно быстрее, элегантнее, проще - и с минимумом поводов для отвала башки при этой операции. Во всяком случае, там не отваливается кусок донной питонины писаной полоумной вебабизяной в самый неподходящий момент, с разлетом базы пакетника в хлам. И комбо получается куда более внушающим доверие.
> в отличие от pacman, который легко позволяет, например, обновить libavcondec.so.N
> на libavcodec.so.N+1, оставив пакет с /usr/bin/mpv слинкованным с libavcondec.so.N. Автоматики
> для отслеживания такого в pacman и сборочном инструментарии пакетов для него нет.Редхат придумал море проблем "как сделать винду из линуха" и заметил что винду айтишники оказывается ненавидят не просто так. А за вполне конкретные антипаттерны, когда вместо того чтобы свой проект доделать вы $%^тесь с msi-инсталлером который ни туда, ни сюда, и ни 1 программа в систему не ставится. И что хочешь то и делай. Редгад довольно успешно повторил эти грабли. Им бы уволить эту команду и познать прелести KISS. Но в случае IBM их хватит максимум на полумеры. Они и сами грешны оверинженерией.
p.s. нефиг в системе помойку либ разводить, ваш libavcodec.so.1.100.500.499 уже давно протух и в нем не менее 20 известных каждому нубу дыр. И вы получите в них эксплойтом первым же видео с торентов - халява далеко не всегда нахаляву.
> Чем это лучше pacman?Тем, что pacman это не пакетный менеджер, в традиционном смысле этого слова, если сравать его с остальными. Он просто ставит и удаляет пакеты, ему не нужно рулить репозиториями и разрешениями блокировок. В раче нет нужды в этом всём, видимо. Зато, из-за того, что он простой и ограниченный, как валенок, он и такой быстрый, на что наяривают, без исключения, все рачисты, скромно умалчивая, что сравнивать pacman, с остальными пакетными менеджерами, из-за этих его "особенностей", не совсем корректно. Но нато они и рачисты, чтобы не думать далеко и надолго, а то ведь так и мысли протухнуть могут, и сам какой-то протухлый становишься, видимо, как гамно мамонта, наверное.
Чет я запутался. Так ты оба меча достаешь или как?
"Антирачер"??... Ну и чем тебе не устраивает пакман, тогда как "нас" он устраивает всем?.... А вот скорость его работы - действительно впечатляет - завидно что-ль? Установку Арча не можешь осилить - нравиться с дистром частые и тесные отношения иметь??...
>Чем это лучше pacman?dnf history undo/dnf history rollback?
>dnf history undo/dnf history rollback?лень гуглить что это, но в арче есть wayback machine, очень удобно отказывает на любую дату в прошлом. плюс mask на отдельные пакеты. хотя за 10 лет мне оно всего разок понадобилось...
a на сервере, есно юзаем rpm
> dnf history undo/dnf history rollback?Особенно когда все это в процесса разваливается. А оно умеет. Вот честно, снапшотами ФС это намного лучше делается. И поводов для отвала сильно меньше. Прикиньте, в снапшоте одним махом и база пакетов правильная, и система консистентная, и отваливаться особо нечему в нормальном случае. Это довольно быстрая, атомарная и безопасная операция, в отличие от того месива что питонмакаки накодили.
> Вот честно, снапшотами ФС это намного лучше делается. И поводов для отвала сильно меньше.Несколько сомнительное утверждение.
С ФС снапшотами нормально всё может быть только если ФС совершенно не используется другими процессами - не связанными апдейтом системы. А если во время апдейта что-либо происходит, что приводит к записи на ФС - обращения к web сервера к локальной базе данных на ФС, почтовый сервер принимающий/отдающий почту, то при откате снапшота будет совсем неконсистентное состояние, так как данные сторонних приложений будет потеряны или повреждены без возможности восстановления.
/var то нафига откатывать? FHS не просто так придумали.
Думаю, что ситуация когда вся система, включая /home и /var, на одном разделе довольно типична для пользователей федоры.
Шо, опять? Я только от yum отвык, а уже новый?
Главное, я точно помню, что dnf рекламировали как yum переписанный на C ради скорости работы. (И работал он действительно быстрее.) А теперь получается что он обратно на python...
Понимаете, у нас с друзьями есть традиция. Каждые N-дцать лет мы переписываем пакетный менеджер с питона на си.
Чукча не читатель.
> Главное, я точно помню, что dnf рекламировали как yum переписанный на C ради скорости работы.Так и есть. Санта-Барбара, сезон второй.
Да не работал он быстрее.
> Главное, я точно помню, что dnf рекламировали как yum переписанный на C
> ради скорости работы. (И работал он действительно быстрее.) А теперь получается
> что он обратно на python...Вообще-то целиком на си они его нишмагли и получился страшный франкенштейн из питона с кусочками на си. Работал он по скорости очень так себе. Если сравнивать с другими. Заодно в процессе хлебнули все прелести вебмакакинга в архитектуре репов, когда оказалось что если пакетов много, огромные XML c индексами долго качать и медленно парсить, а давайте дескать pre-parsed базы скулайта класть?! Хрена они там архитекты имени вебмакак...
> Шо, опять? Я только от yum отвык, а уже новый?Они не шибко отличались по сути своей работы.
Однако, в репозиториях федоры присутсвтвует zypper, который даже как-то работает.
Вот, если бы разрабы федоры думали о пользователях, они бы доработали zypper и саму федору до ума, чтобы они работали в связке, также эфективно, как zypper работает в сусях.
Но, разрабы федоры форменные садисты и маньяки, больные головой, поэтому они пилят всё новые кривые костыли, лишь бы не сделать по-человечески:
упоротая идея пилить вэб установщик, вместо не менее упоротой локальной г@внаконды, тупой dnf, вместо адекватного пакетника, GNOME, в конце концов.
В общем, всё для пользователей, кушайте, не обляпайтесь!
Какой zypper, вы о чём? Там такое ЧСВ, что они сорок раз свой yum переписывать будут и всё равно сделают убогость.
Причем тут ЧСВ? Там менеджер копчоный, с лопатой. Которой охреначит по горбу за такие идейки."Недостатком протокола IPX является то, что он разработан фирмой Novell"(c)
Нельзя ключевые для дистрибутива вещи строить на технологиях, принадлежащих конкуренту. Этому на первом курсе бангалорского MBA учат (той же лопатой, в руках гуру).
Какой ЧСВ? Когда в сусе выкатили офигительный libsolv, без проблем выкинули свою реализацию поиска зависимостей, написали прослойку hawkey (сейчас - libhif) и перевели dnf и прочее на него.А зачем менять dnf, к которому все привыкли по интерфейсу и логики работы на zypper? Вообще, у вас какие претензии именно к dnf сейчас (а не к yum 10 лет назад)?
> Какой ЧСВ? Когда в сусе выкатили офигительный libsolv, без проблем выкинули свою
> реализацию поиска зависимостей, написали прослойку hawkey (сейчас - libhif) и перевели
> dnf и прочее на него.
> А зачем менять dnf, к которому все привыкли по интерфейсу и логики
> работы на zypper? Вообще, у вас какие претензии именно к dnf
> сейчас (а не к yum 10 лет назад)?У меня лично претензии к dnf такие, что у меня буквально в том году, параллельно стояли дома десктопом две системы, с zypper и dnf, с примерно однаковым набором пакетов, как раз для сравнения работы их инфраструктуры. И dnf, в отличии от zypper такой слоупочный тугой наркоманский и жручий тормоз, какой ещё надо поискать, хуже, наверное только у генты, но там хоть есть чем оправдываться. А такой огромной конторе как (ибэмэ)красношляпа, нет никакого оправдания в такой отвратной работе, разве что они все деньги, положенные на зряплату нормальным кодерам, потратили на нужды инклюзивности. А судя по текущим трендам в федорке, они продолжают их тратить именно туда.
А так, никаких больше претензий, просто дистрибутив скурвливается и метастазирует в какой-то чумной прогрессии.
а что с yum? работает вроде у пердунов на центосях
До 6-чки. В семёрачьке уже днф, а юм - обёртка над днф.
В семерочке ещё ням, это в восьмерочке привезли днф. Ну и где эта восьмерочка теперь? Нету её больше, что доказывает, что вся центось держалась на няме
Протрезвели?
Нет, просто умеют софт разрабатывать в долгосрочной перспективе. Вот довели до рабочего решения прототип на Питоне, обкатали паттерны, теперь можно выжимку на менее дружелюбном к разработчику языке написать. Начни они разработку сразу на C, воз и поныне там был бы.
> Вот довели до рабочего решения прототип на ПитонеНеплохо, чуть менее чем за 7 лет управились. Такими темпами они и вяленого допилят.
За 15. Поскольку ничего кроме переименования, между yum и dnf не было.
Форк понадобился потому что кто-то, как обычно, не хотел отдавать разработку в чужие руки.Вяленого да, того гляди "допилят", объявив в очередной версии иксы вредным ненужно, и "не нравится, делай форк".
> Вяленого да, того гляди "допилят", объявив в очередной версии иксы вредным ненужно,
> и "не нравится, делай форк".Как-то так. А что поделать если унутреннее устройство иксов вообще ничего кроме ужоса у кодеров не вызывает? Особенно когда народ хочет чтобы их сетап с 8K дисплеями не тормозил. Не, никто не хочет уже 640х480 в режиме vga, потоки данных более другие стали.
>>> Форк понадобился потому что кто-то, как обычно, не хотел отдавать разработку в чужие руки.потому что кто-то попал под автобус (в буквальном смысле), а редхатовца, которого поставили пилить yum вместо покойного, покусал петтеринг.
> Нет, просто умеют софт разрабатывать в долгосрочной перспективе. Вот довели до рабочего
> решения прототип на Питоне, обкатали паттерны, теперь можно выжимку на менее
> дружелюбном к разработчику языке написать. Начни они разработку сразу на C,
> воз и поныне там был бы.
>умеют софт разрабатывать в долгосрочной перспективе
>довели до рабочего решения прототип на ПитонеНет, просто у них не осталось адекватов в нужном количестве, поэтому и петон и такая тупизна и жор инструментов.
>Начни они разработку сразу на C, воз и поныне там был бы.Судя по тому что там петонятины и прочая макакоскриптятина со всех щелей, подозреваю, что там, тупо некому писать на С, умишка недохват. Максимум на раст сподобятся, это в самом лучшем случае.
Ну и чего ж ты не устроился к ним и не показал как надо? Если там все такие дурачки сидят, ты бы мог сразу с высокой позиции начать, уже бы главного архитектора проекта подсиживал бы.
Полторы-две штуки? Сам устраивайся на такую зряплату. С переездом конечно. И хватить её тебе должно не только на жрат, но и на квартиру с коммуналкой. Если ты молод и холост - то можешь попробовать.
Ну так то платят дурачкам немогущим. Ты ж не такой, тебе сразу двести пятьдесят штук в год, дом и ключи от мерседеса дадут, только чтобы ты показал как надо.
> Ну и чего ж ты не устроился к ним и не показал
> как надо? Если там все такие дурачки сидят, ты бы мог
> сразу с высокой позиции начать, уже бы главного архитектора проекта подсиживал
> бы.Забираться православному человеку в логово-рассадник содомитов и пытаться отучивать их заниматься содомией, ну уж нет, пущай Боженька там жжот серным дождём, этот народ содомский уже не спасти.
Проще взять другой коллектив и попытаться построить с ним новый проект, с адекватным ядром управленцев и не менее адекватными сотрудниками.Но, вы можете ещё родить пункт, про сперва добейся, а то вы, вероятно его забыли по пути, пока методичку читали судорожно соображая, что умного ответить?!
> Проще взять другой коллектив и попытаться построить с ним новый проект, с
> адекватным ядром управленцев и не менее адекватными сотрудниками.Как говорится, флаг в руки и электричку навстречу. Про такое как раз и говорят - "не говори гоп пока не перепрыгнешь". Вот когда - и если - оно у вас получится, тогда и приходите.
> Вот довели до рабочего решения прототип на Питоне,что за бред я прочитал?
Какое слово не ясно?
слова все знакомые, только написан из них бред
на питоне можно долго тярляпить курсовые и хелловорлы, но процессоры развиваются медленнее нарастания тормозов питона.
> Новая версия Microdnf также будет использовать фоновый процесс DNF Daemon, заменяющий функциональность PackageKit и предоставляющий интерфейс для управления пакетами и обновлениями в графических окружениях. В отличие от PackageKit в DNF Daemon будет предоставляться поддержка только формата RPM.Это же прорыв? все ближе и ближе redhat vendor lock....
Ты так говоришь, как будто это что-то плохое.
Лучший раб тот, который не догадывается, что он раб.
как ты?
нет ты
Так всё равно за пределами RPM этот код практически никто не использует. Правильно делают, что дропают. Неясно вообще с какой целью нужны были эти приседания вокруг других форматов пакетов. Редхат с RPM никуда мигрировать не планирует.
> Так всё равно за пределами RPM этот код практически никто не используетFIX:
За пределами их rpm...На самом деле, в других rpm-дистрах, как раз используют более вменяемые инструменты.
>Редхат с RPM никуда мигрировать не планирует.
Как раз наоборот, вы видимо проспали в криокамере достаточно долго, чтобы пропустить нетонкий такой курс, на монолитную, неделимую, core-систему с атомарными обновлениями и снапштами, сдобренным толстым слоем флатпака головного мозга в юзеспейсной части. В конечном итоге, как раз, главный rpm-дистр, планируется перестать быть таковым для конечного пользователя.
Не знаю, где вы обретались всё это время, чтобы это всё пропустить?! Или вы из зазеркалья к нам вещаете?
Жалкая пародия на стек Windows NT, NTFS и MSI времен Windows 8 (10-летней давности).MSI позволяет и "исправлять" проблемы переустановкой пакета (обновления венды), откатывать и удалять без проблем. Обновления безопасности венды не требует (за исключением обновления ядра венды) двойной перезагрузки в отличие от fedora/systemd-style ребута в режим обновления с последующем ребутом в обновленную систему. Проблемы с установкой обновлений также легко откатываются. В крайний случай в NTFS есть снапшоты (поддержка которых появились, наверное, раньше любой линуксовой фс) и на диске C работает volume shadow copy, можно откатиться в режиме восстановления.
Эти люди еще что-то жалуются, что венда у них часто просит ребутнуться. Карл! В вашей Fedora / GnomeSoftware система перезагружается _дважды_ почти каждый день! 365 x 2 = 730 раз за год. При этом связка из gnome software + packagekit + dnf способна выжрать до 1.5 гб озу, постоянно тормозит и показывает назойливые уведомления.
Как найти человека, который MSI видел только на картинках, и не знает про его проблемы (ужасающая отладка; проблемы с производительностью; затыки на подмене используемых файлов; мусор от старых версий в ProgramData, без которого пакеты откажутся обновляться и многое, многое другое)
> Как найти человека, который MSI видел только на картинках, и не знает
> про его проблемы (ужасающая отладка; проблемы с производительностью; затыки на подмене
> используемых файлов; мусор от старых версий в ProgramData, без которого пакеты
> откажутся обновляться и многое, многое другое)Намного интереснее когда караптится или стирается файло потребное для ролбэка а сетап заваливается. После этого вы в систему вообще больше ничего не установите, и ничего не удалите, а выход из такой ситуации - не очевиден, мягко говоря. Вообще, идея что для сноса программы надо в обязаловку "прихраненый" пакет, при том отличный от того что в дистрибутивном источнике это весьма отдельный такой брейнфарт от индусов был.
>Жалкая пародия на стек Windows NT, NTFS и MSI времен Windows 8 (10-летней давности).MSI был на столько совершенным, что майки последние несколько лет по максимуму стараются его избегать. Практически все их современные продукты устанавливаются другими способами, например, приложения из MS Store, Office, даже Visual Studio. Последний оплот MSI на вантузе — это разве что VC Redist, и то из-за соображения совместимости. Ну и серверные продукты по той же причине, миллионы макак привыкли к нему, вокруг MSI построено куча инструментария.
>MSI позволяет и "исправлять" проблемы переустановкой пакета
Так повреждение файлов пакета — это чисто виндовая проблема, где практически любая программа может и успешно портит чужие файлы. Т.е. они сначала сами и создали эту проблему, а потом героически придумали костыли для неё. В мире Unix обычно достаточно исправить ошибку в конфиге, либо тупо удалить его, если речь идёт о пользовательском ПО.
>(обновления венды)
А MSI тут при чём? Вантуз никогда не рулил системными файлами через MSI.
Ты на пенсию выйдешь раньше, чем rpm отменят. Какие бы движения там ни присходили, rpm будет эволюционировать вслед за ними.
а как же докеры со снапами и флэтпаками? куда ж без них, без npm и без pip?
А, ты из этих, у которых когнитивных способностей не хватает освоить больше одного инструмента. Ну попробуй в дворники пойти, или как пох. — уборщиком в датацентр. И при серверах, и голова не болит от нагрузки, и время есть на опеннете комментить.
> А, ты из этих, у которых когнитивных способностей не хватает освоить больше
> одного инструмента. Ну попробуй в дворники пойти, или как пох. —
> уборщиком в датацентр. И при серверах, и голова не болит от
> нагрузки, и время есть на опеннете комментить.Но, вы то наверное весь в "заботах, полон рот" и времени комментить на опеннетике у вас нет, ой, какая красота! ;)
Снапшотов не будет. Технология thin-lvm так и не признана уже окончательно достаточно готовой, а других (у rhbm) нет.Да и зачем они тебе в "атомарной" системе? Там только вперед, апгрейдом на еще более новую (предыдущую даже скачать уже неоткуда будет, к тому же в ней аж пять увизгвимостей).
> планируется перестать быть таковым для конечного пользователя.
конечный пользователь федоры - rhbm. Ты - пользуемый, не перепутай.
Разумеется для впопенштифта под впопенстеком не нужны никакие rpm. "скачайте из https://rhnet/10/layeys/of/nested/path/binary-go и запустите - он все за вас сделает. Да, мы работаем чтобы сделать его впопенсорсом, но пока вот так" (с)
зачем тебе в такой системе какие-то пакетные менеджеры? Кроме podman, разумеется. Но им тоже не ты будешь управлять.
Так они ж уже тестят бтр на своих лабораторных крысах в федоре. Запилят плагинчик для своей пакости к нему - и усе. А ты там с сратисом и thinlvm'ом пытайся нормальную ФС изобразить из спичек и желудей если хочешь. А потом какой-нибудь Кент свое счастье допилит быстрее чем вон те индусы. И будет оно CoW-next gen. Типа btrfs'а, только быстрее, ибо делано уже с учетом анализа проблем дизайна и изменившихся реалий: быстрые накопители с огромным iops на скоростном интерфейсе привели к тому что стал важен оверхед. Кент учел это. А XFS... тормозил на метаданных вообще всегда.
> в других rpm-дистрахРедхату не интересно и никогда не будет интересно что там в других rpm-дистрах. Что вполне понятно, пользователей rpm столько, что если с каждым советоваться, то до разработки не дойдёт. Так что 2-3 основных (типа SUSE) послушают и сделают как считают нужным.
>> в других rpm-дистрах
> Редхату не интересно и никогда не будет интересно что там в других
> rpm-дистрах. Что вполне понятно, пользователей rpm столько, что если с каждым
> советоваться, то до разработки не дойдёт. Так что 2-3 основных (типа
> SUSE) послушают и сделают как считают нужным.Всё правильно, нужно включить обратную логику, и не слушать вообще никого, в том числе своих пользователей, а "обращать внимание" на тех только, кто послушно жрёт, то что ему накидывают, с лопаты.
Дабы была возможность показать, что у упоротых идей есть хоть какие-то сторонники, а заодно позаниматься самовнушением, что всё правильно делаем, вон, у нас и поддержка-одобрение есть, в форме вот той аморфной массы, со своим-нашим мнением-видением. А остальных просто не существует, они недоразвиты и вообще просто хейтеры, злобные и токсичные, это ведь не наш код г@вно и у нас все всё правильно делают!
Так победят, ага!Давно запасся попкорном, глядя на этот цирк, но, что-то подозреваю, что я столько не съем!
Всё правильно делают. PackageKit был очень важен а прошлом когда в этой области было всё криво, непричесанно и мамонты ходили, но как-то надо было рабочие интерфейсы для всех дистрибутивов одинм махом делать. В 2022 году всё налаженно и все всё понимают, таким программам полноценная интеграция нужна, просто печально смотреть как какой-нибудь gnome software или kde discover мучает задницу пять минут выполняя на PackageKit операцию которую пакетный менеджер за секунды делет.
Может в PackageKit есть архитектурные проблемы, но это не отменяет того факта, что нужна пакетонезависимая прослойка, глупо клепать условный gnome software под каждый пакетный менеджер, gnome software - это же интерфейс не для управления пакетами, а для установки приложений конечными пользователями, которым знать про пакеты не нужно.
"Например, удаление пакета не будет приводить к удалению связанных с ним зависимостей, которые не используются в других пакетах" - у них там контейнер головного мозга? Как можно на десктопной системе не вычищать пакеты? Опять обкладываться полуживыми костылями типа rpmorphans?
Зачем ты постоянно устанавливешь и удаляешь пакеты на десктопе?
А вот и свидетель нарисовался чёрного куба, который ни в коем случае нельзя модифицировать, всё должно быть прибито шурупами с клеем, как завещал великий Вендор.
> великий ВендорИз Редмонда? )
На вопрос ты так и не ответил.
Банально неправильный перевод. В оригинале так:
Relocation of internal databases and different structure of internal databases
- The transaction performed by the new MICRODNF will be not visible by DNF
- The transaction performed by DNF or PackageKit will be not visible by the new MICRODNF
- Packages installed by another packager will be handled as userinstalled
- Consequence => The removal of a package will not trigger removal of unused dependenciesТ.е. пакеты установленные после перехода продожат удаляться, если они не нужны. Всё установленное до перехода вычищаться не будет.
Марсианский подход какой-то.
Они просто не в курсе про обратную совместимость.
> "Например, удаление пакета не будет приводить к удалению связанных с ним зависимостей,
> которые не используются в других пакетах" - у них там контейнер
> головного мозга? Как можно на десктопной системе не вычищать пакеты? Опять
> обкладываться полуживыми костылями типа rpmorphans?Они решили, таким образом облегчить работу пакетника, путём обрезания функционала.
Ну, потому что понабрали инклюзивных скриптомакак, которые ниасиливают в написание нормальных инструментов, вот и получается такая содомия.
Потом дальше пойдут:
- Зачем вообще удалять файлы пакета при удалении пакета...
- А зачем вообще позволять устанавливать что-то, предустановленного хватит всем!
>Ключевым отличием Microdnf от DNF является использование для разработки языка Си, вместо PythonГентушники, берите пример.
>>Ключевым отличием Microdnf от DNF является использование для разработки языка Си, вместо Python
> Гентушники, берите пример.У кого брать пример, у федор-овцев?
Спасибо, лучше уж с NixOS, на худой конец.
Ты жопой читаешь или серьёзно предлагаешь захреначить в генту dsl из никсоса? Я имел в виду, что гентушникам тоже пора перевести портаж с пистонятины на сишку.
> Ты жопой читаешь или серьёзно предлагаешь захреначить в генту dsl из никсоса?Это вы, уважаемый, читаете чем-то отличным от глаз.
Где я выше написал, про захреначить что-то их никсоса, протрите ваши органы зрения и перечитайте ещё раз, а потом ещё раз, до просветления. А то спева придумываете ответ собеседника, а потом героически его опровергаете!
> Я имел в виду, что гентушникам тоже пора перевести портаж с
> пистонятины на сишку.Одного переписывание с петонятины на что-то другое недостаточно, а то что-то я смотрю портдырка у всех прижилась!
Молодец, хорошо сманяврировал.
Прокалькулятит все равно быстрее чем собирается. Для Gentoo не принципиально Си/Питон. Ваши бинарные разборки не интересны,к тому же с полгода как писали новость про оптимизацию и какое то там ускорение на треть в Портаж. D
Zypper давно на крестах, но у федерастов NIH-синдром.
ни слова не понял, к логопеду сходи
ты сайтом ошибся, тут ещё и не такие технические термины встречаются.
я просто российский программист, мы по-английски ни бум-бум
1C?
каким-то образом это не мешает ему быть медленнее даже yum/dnf(то есть совершенно понятно, каким, но давайте-давайте перепишем все на c++ вместо того из-за чего он как-бы медленнее)
> каким-то образом это не мешает ему быть медленнее даже yum/dnf
> (то есть совершенно понятно, каким, но давайте-давайте перепишем все на c++ вместо
> того из-за чего он как-бы медленнее)ЛОЛШТО?! Zypper медленне dnf?! Я правильно понял ваш чудесный комментарий?!
>>Ключевым отличием Microdnf от DNF является использование для разработки языка Си, вместо Python
> Гентушники, берите пример.Why C++?
Because we don't have the time or the manpower to write it in C.
Чё не на раст сразу?
Питон лучший язык для всего, вот это всё.
> Питон лучший язык для всего, вот это всё.Особенно когда нитормозит и другие системы ворочают те же операции в разы быстрее чем редгад. Особенно если это на десктоп поставить, так что еще и репы с пакетами хочется.
DNF does not function?
> DNF does not function?B-coz, just not enough smoothie-code in dnf!
у меня основная ассоциация - это гоночный термин do not finish
> do not finishТочно :) перманентное отсутствие готового стабильного продукта.
Сначала заменяют с нормального yum на тормозной DNF, а потом создают другой yum с нуля?
Имитация бурной деятельности. И так во всех проектах. Результат - ничего толком не работает, стандарты отсутствуют... То, что живёт 3 недели - это не стандарт, а поток коричневой ноты.
вся время уходит на blm и прочее
ulm
...dnf, который работает в 3 раза быстрее?
Мсье, да вы издеваетесь
Если yum был таким тормозом, могли бы просто zypper использовать!
Ах да, NIH превыше всего!
> ...dnf, который работает в 3 раза быстрее?
> Мсье, да вы издеваетесьИ как и чем Вы мерили?
> Сначала заменяют с нормального yum на тормозной DNF, а потом создают другой
> yum с нуля?Оно и yum был это самое, по сути. Так что не велика беда, просто "чехольчики поменяли".
Это поделие спасёт только полное выкидывание на мороз и полное переписывание. Но, красношапка показала, что горы кокса или что у них там потребляют, неистощимы, так что я не верю в то, что они родят что-то вменяемое, чтобы пользователи наконец вздознули и хоть где-то в системе было что-то вменяемое, от чего не хотелось бы плеваться и посылать лучей добра производителю сих поделий.
c.. c++.. ещё через лет 5 они додумаются, что нужно переписать на Dlang?
Главное, чтоб не на питонах, и прочих рубирастах.
Для производительности надо избавится от systemd.
> Для производительности надо избавится от systemd.Прежде всего им надо избавиться от гор упорина, которые они занюхивают, потом от хипсторских сжв-смузикоддеров, а уже потом только начать переписывать тот бред, который за годы нагомнокодили!
Но, т.к. этого с большой вероятностью не произйдёт, расслабьтесь, присаживайтесь рядом, возьмите пакетик с попкорном и созерцайте картину как тонет, некогда великий крейсер, на палубе которого носятся упоротые горы упорина, рожая не менее упоротых мышей! Этот проект спасёт только тотальная чистка, скорее всего, до основания.
Ну накотец-то. Достала эта обязательная полускриптовая блоатварь. Такими темпами и питон вообще из системы можно будет выпилить.
Перл уже выкинул, выкидыватель?
> Перл уже выкинул, выкидыватель?- # rpm -qa perl\*
- #
... такие дела ...
Тормознутость dnf сильнее, чем zypper/pacman/apt(dpkg), говорят объяснялась тем, что dnf написан на Python (когда pacman/zypper написаны на Си/С++).Я слышал о медленности YUM/DNF
Там ещё транзакционность реализована, за счёт которой работает dnf history undo/rollback
Всегда было интересно — а кому вообще эти транзакции нужны?
админу тысячи локалхостов..
до переписывания на раст осталось пять релизов федоры..
Частично на питоне, частично на расте, чтобы созвучно было
> до переписывания на раст осталось пять релизов федоры..и привязка к libastral, которую ещё не дописали до стабильного состояния.
А чо не на Rust то? Безопасность-ж будет плохая. Да и вообще ж С/С++ устарел там у них, легаси...
> А чо не на Rust то?Опыт мозилы намекает, что можно потерять весь рынок.
>> А чо не на Rust то?
> Опыт мозилы намекает, что можно потерять весь рынок.А на что намекает опыт оперы или мелкософта уважаемым опеннетным оналитегам?
> опыт оперы или мелкософтаУ них был опыт?!
>> опыт оперы или мелкософта
> У них был опыт?!Т.е. о потери рынка МС и выкидывании ими своего движка в пользу хрома, уважаемый оналитег не слышал?
Яснопонятно. А в нашей реальности, браузерные движки без раста проиграли гуглу.
Дольше всех трепыхалось ябло, но и то исключительно из-за использования "админ-ресурса" в своем iOS-загончике.
>> А чо не на Rust то?
> Опыт мозилы намекает, что можно потерять весь рынок.Ну, с почти выкидыванием на мороз центоси, что-то непохоже, что у них адекватная стратегия по рынку. Но, возможно там какой-то хитрый план, многоходов-очка?!
2022. Больше 1000 строк. Переписать на Си. Этот мир уже ничего не спасёт
Это намек? А потом заменят на winget?
А в чем проблема просто взять сишный zypper?
Нет, чтобы взять рабочее решение от Suse или хоть приличный язык для переписывания, так нет, переписывать на Си. А людям Fedora для работы нужна, между прочим, а не для экспериментов, для этого есть масса других дистров.
1. Надо сделать новую вундервафлю...
2. Ой, хотим результат здесь и сейчас, иначе - не видать донатов!
3. Берем новый, модный молодежный интерпретируемый язык. Жаба, пихон, VB - не важно, зависит от времени и личных предпочтений Главного Гуру Проекта
4. Ой как здорово - все работает! И как быстро...
5. Запускаем в продакшен!!!
6. Ой... не все так здорово... тут притормаживает...
7. Перепишем наиболее критичные участки на компилируемый язык!
8. Ой, теперь что-то подглючивает...
9. Давайте напишем компилятор для нашего любимого интерпретируемого языка?
10. Написали... Но какая-то фигня вышла - оказывается сделать хороший компилятор - не просто...
11. Ну нафиг это интерпретируемое г-но - пишем все на нормальном, компилируемом языке!
12. Вот теперь все работает, но добавление новых фичь замедлилось...
13. Делаем новую вундервафлю на новым интерпретируемом языке, лишенным недостатка всех старых!
"В Fedora планируют переименовать пакетный менеджер Microdnf в Micro-Soft".Скиньте это будет следующая новость. Поклонники майкрософта из РетГада перекинулись на Дойэбан, заразив тем самым дебилианщиков.