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

Java не тормозит! (с)

унюхали

ты знаешь, это так давно унюхали все, кроме них, что даже не смешно.

В дебиане ты одной строкой добавляешь репку до которой обновляешься и одной строкой делаешь apt dist upgrade.

И APT напишет тебе, что он собирается поставить 3000 пакетов, удалить 3000 пакетов и обновить 100500 пакетов. И если в 3000 удалённых есть что-то, что тебе нужно, ты или напрягаешь зоркий глаз, или узнаёшь об этом после обновления.

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

В rhel тебе нужен некий Red Hat Upgrade Tool, т.е. сурой энтерпрейзный yum/dnf этого не могёт. Ибо суров и немогун.

В убунте есть do-release-upgrade, который пропишет тебе репку, всё проверит, напишет, какие пакеты более не поддерживаются и сделает тебе dist-upgrade. RHUT делает то же самое, и использует всё тот же yum. Но если очень хочется, можно и руками, только зачем.

В Debian просто не написали такой утилиты. И это кстати, вообще не энтерпрайзненько.

а какой смысл переписывать эту говнину с языка высокого уровня на более низкоуровневый для задач, не предполагающих cpu-bound? поясните уж наркоманам по какой причине в вебне прижились скриптовые языки. для того чтобы скачать пакет и распаковать его сторонней утилитой и птона хватит. ниразу не федораст, но за пресмыкающихся обидно

apt разве orphaned packages не может удалять?

а какой смысл переписывать эту говнину с языка высокого уровня на более низкоуровневый для задач, не предполагающих cpu-bound? поясните уж наркоманам по какой причине в вебне прижились скриптовые языки. для того чтобы скачать пакет и распаковать его сторонней утилитой и птона хватит. ниразу не федораст, но за пресмыкающихся обидно

Потому что пистон НАСТОЛЬКО тормоз. В DNF это вроде ещё не было большой проблемой, но вот Portage из генты на системе с ~1000-1500 пакетов мог только зависимости по полчаса обсчитывать при emerge world. Я тащемта поэтому с генты и слез в итоге.

Зачем каждый раз название менять? Аналогичный вопрос и к другим дистрибутивам.

microdnf целиком написан на C

Гыгы, где то всплакнул растоман =)

просто этот сабж писали последних лет 10, наверное. когда он подрос, федоровцы решили взять под крыло. а до раста они дойдут еще лет через 10.

Не дойдут. Мне тут один чувак из федоры залечивал, что он лично никогда не тронет Rust, потому что кто-то там в core committee что-то сексистское сказал.

Мне почему то казалось что пакетные менеджеры проще писать на go …

Не дойдут. Мне тут один чувак из федоры залечивал, что он лично никогда не тронет Rust, потому что кто-то там в core committee что-то сексистское сказал.

[ пытался найти какой-нибудь подходящий мем, но не удержался и сполз под стол ]

я уже себе поставил раст, чтобы его изучать. you just got me more reasons.

Будто эти ваши фотошопы влезут в

eMMC-ноутбукам

Шиндузятный софт даже по временам актуальности CD вопиюще жирный.

microdnf целиком написан на C

То есть они признают, что Пайтон та ещё жЫрнота.

теперь, когда протолкнули везде, уже можно

я уже себе поставил раст, чтобы его изучать. you just got me more reasons.

Ну, это не самый плохой язычок. Хотя косяков в нём хватает, да. Но всё же это лучше чем C.

Да, PackageKit — говно, но он решает одну принципиальную задачу для десктоп-юзера: им можно обновлять систему и не бояться падения терминала или иксов, и даже если такое случится — PK доведет начатое до конца без проблем. А вот если гуевый терминал упадет во время обновления критических компонентов, то процесс будет прерван.

Ясное дело, опытному пользователю это все не нужно, нет проблем дернуть Ctl+Alt+F3 и обновиться, да и то не всегда это необходимо, но такой расклад никак нельзя предложить для настольной системы.

А теперь видать запилят демона для DNF, который будет решать такую задачу без посторонней помощи.

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

в кандалы!

Да, PackageKit — говно, но он решает одну принципиальную задачу для десктоп-юзера: им можно обновлять систему и не бояться падения терминала или иксов, и даже если такое случится — PK доведет начатое до конца без проблем. А вот если гуевый терминал упадет во время обновления критических компонентов, то процесс будет прерван.

Вообще, это гораздо лучше решается атомарными обновлениями системы, а не каким-то демоном, который в фоне что-то делает. OSTree тут гораздо лучше подходит. Я бы попробовал Fedora Silverblue с удовольствем, как альтернативу NixOS, но там ZFS нету из коробки.

RedHat вроде хотели сделать Fedora полностью Flatpak - системой без RPM (как SilverBlue, Kinoite, EndlessOS). Мотив замены DNF на MicroDNF … No Comment

Тут ответ очевиден — не готов для десктопа. Мне кажется они вообще зависли с ostree, может и не пойдет в народ, ведь Silverblue мечтали аж в Fedora 30 заменить Workstation, но на носу 36, а воз и ныне там.

но там ZFS нету из коробки

Мне ZFS не нужен, но все равно ostree меня напрягает: ради избыточной для меня надежности, которую дают атомарные обновления, получаю значительную потерю в удобстве и гибкости настройки системы под себя.

А в чём именно эта потеря? Потому что в случае с NixOS проблем с гибкостью не возникает. Я прикидываю, что системы с OSTree должны быть сравнимы по функционалу.

Блин, надо в виртуалку засунуть посмотреть уже.

К слову, в macOS с какой-то там недавней версии запилили атомарные обновления и / только для чтения. И ничего, никто не умер.

А причем тут ostree и dnf. Я юзал Силверблуй года 3-4 назад. Практически таже федора, что нет внутри дополняешь через dnf.

когда уже в федоре сделают нормально? как в дебиане

А что apt на си написан ?

А в чём именно эта потеря?

На вскидку.

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

Большая часть системы ридонли, вообще поковыряться невозможно.

Флатпаки мне пока не нужны, я даже на AlmaLinux (RHEL выключили, сцуки) обхожусь без них, и это не религия, просто не нужны пока, а наворачивать дополнительный софт в слои в общем не рекомендуется без особой нужны.

Были и эпичные моменты, когда я по какому-то поводу дернул по привычке dracut -fv и уничтожил таким образом загрузку системы, и только потом прочитал, что в Silverlbue так делать нельзя :-)

Сейчас всего не вспоню, но в целом впечатление такое, что продукт идет сырой, например даже про гребаный обязательный отдельный /boot ты узнаешь только тогда, когда что-то в установке пойдет не так.

И таких неприятных мелочей много, так что ждем дальнейшего развития. Может ещё через годик гляну.

Ясное дело, опытному пользователю это все не нужно, нет проблем дернуть Ctl+Alt+F3 и обновиться

Кстати уже есть (пока что) - в F37 VT на нвидии не работает. Вообще. Потому что дернули рубильник и перешли с EFIFB на simplefb, который нвидия пока не умеет.

Я продолжаю зоонаблюдать за багрепортом, но релиз близится, а решения альтернативного пересборке ядра пока что не видно

ну не на расте же писать его

И если в 3000 удалённых есть что-то, что тебе нужно, ты или напрягаешь зоркий глаз, или узнаёшь об этом после обновления.

Если в 7 нет пакета/фичи/функционала из 6 и он будет удалён то он будет удалён вне зависимости от пакетного манагера.
Об этом стоит думать до принятия решения об обновлении.
Если в 7 пакет/фича/функционал из 6 заменены альтернативой то альтернатива либо умеет в конфиги от старого решения либо нет, и это не зависит от пакетного манагера.
Об этом надо думать ДО принятия решения об обновлении.

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

Для этого нужна не утилита а как минимум реплика сервера для теста, если мы говорим об околоэнтерпрайзе, и бумажка «у вас перестанет работать то-то и то-то» от суппорта если мы говорим о платно-поддержковом энтерпрайзе, как максимум.

В Debian просто не написали такой утилиты. И это кстати, вообще не энтерпрайзненько.

Дебиан не про энтерпрайз - это база для «построй свой», но речь о том что сам по себе юм/днф не способен перевтыкать всю систему пошагово без привязки к исходной версии дерева в отличии от апта. По крайней мере в рамках простых телодвижений репка->система (что работает и между версиями и между стабильной/тестовой «ветками», по сути тоже версиями).
Но никто не говорит что наличие такой возможности не отменяет тестовую реплику :-)

Об этом надо думать ДО принятия решения об обновлении.

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

но речь о том что сам по себе юм/днф не способен перевтыкать всю систему пошагово без привязки к исходной версии дерева в отличии от апта. По крайней мере в рамках простых телодвижений репка->система (что работает и между версиями и между стабильной/тестовой «ветками», по сути тоже версиями).

Вот я сейчас не понял, что именно он не может, особенно про репку )

В любом случае, yum своё дело знает, а в apt даже транзакций нет. Ну и о чём спор.

Вот я сейчас не понял, что именно он не может

Обновить рхел 6->7->8 :-D

нормально

как в дебиане

/0

Фигасе! Ну тогда PackageKit просто мастхев в такой ситуации.

Не знаешь с чем связано, что при установке нового ядра в EL или если федорку поставить, то теперь просто отредактировать vconsole.conf не работает. (Нагуглить по быстрому не получилось, поэтому просто скриптик добавилял в .bashrc)

Можно, разрешаю.

Можно, разрешаю.

Покеж как, у меня лапки

тредактировать vconsole.conf не работает.

ничего не понял, так что помочь не могу

Мне давно уже не столь важно, какую ОС использовать, если это UNIX, но, честно говоря, сменил недавно Ubuntu на Slackware на личном макбуке (на рабочем macOS), и давно я не был так счастлив насчет простой как топор работы с пакетами.

Когда же они уже все уймутся-то с новыми велосипедами каждые несколько лет?

Поменять шрифт в консоли, чтобы не дергать setfont bla-bla каждый раз.

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

В смысле, нельзя конфиги менять? Паршивенько, что. Я надеялся на это слезть с NixOS, но если конфигурация системы настолько затруднена, то и нахрен.

Были и эпичные моменты, когда я по какому-то поводу дернул по привычке dracut -fv и уничтожил таким образом загрузку системы, и только потом прочитал, что в Silverlbue так делать нельзя :-)

Лол! В той же NixOS единственный способ случайно угробить всё – снести grub. Ну или руками поудалять всё с диска, но это тоже надо постараться.

нельзя конфиги менять?

Можно. /etc — writable, но в разных ситуациях этого маловато.

опять кто-то умер?

в эпоху, когда каждый ГБ пространства на счету

Мы случаем не в разных эпохах живем?

Можно. /etc — writable, но в разных ситуациях этого маловато.

Тогда где атомарность? Или как это работает? Не отменить же изменения будет.

Пропиши новые репы, сделай yum upgrade.

redhat-upgrade-tool - это питоновская обёртка над yum, можешь залезть в исходный код и убедиться.

Я надеялся на это слезть с NixOS

А чем NixOS не устроила?

А чем NixOS не устроила?

Stable слишком старый. Unstable периодически сломан. Например, недавний баг в новой glibc и неработающий из-за этого Firefox. Смешивать их на десктопе – геморрой лютый.

Ну и меня дико бесит, что нельзя нормально обновить только часть пакетов. Либо всю систему, либо херачить конфиг-франкенштейн с импортом разных коммитов из nixpkgs, либо ад и холокост с оверлеями.

Короче, не юзер френдли.

Unstable периодически сломан

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

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

А что, в каком-то дистрибутиве эта возможность официально поддерживается? В Arch Linux вот нет.

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

Не всегда. Баг с Firefox я заметил только через пару дней, когда nix-collect-garbage уже сделал. В итоге я, конечно, откатился на старый коммит, но всё равно бесит.

А что, в каком-то дистрибутиве эта возможность официально поддерживается? В Arch Linux вот нет.

OSTree + Flatpak такое может. Ну и блин, Windows и macOS так всю жизнь могли.

Я молчу про то, что обновление какого-то man из glibc приводит к пересборке вообще всего дистра, ибо хэш поменялся, хотя изменения могут быть чисто косметическими.

Ну и блин, Windows и macOS так всю жизнь могли.

Ага, «благодаря» статической линковке всех зависимостей.

Я молчу про то, что обновление какого-то man glibc приводит к пересборке вообще всего дистра, ибо хэш поменялся, хотя изменения могут быть чисто косметическими.

Проблема, я так понимаю, в том, что nix при каждом обновлении тратит кучу времени на пересчитывание хэшей?

Ага, «благодаря» статической линковке всех зависимостей.

Как пользователю, мне абсолютно насрать. Тем более, что в NixOS многие библиотеки существуют в нескольких копиях. И часто это даже одна и та же версия. Просто зависимости разные получились.

Проблема, я так понимаю, в том, что nix при каждом обновлении тратит кучу времени на пересчитывание хэшей?

Нет. Проблема в том, что при изменении корневых пакетов типа glibc нужно ждать три дня, пока гидра всё пересоберёт. Вообще всё. Ветки staging и staging-next не просто так существуют. Это одна из причин, почему обновление некоторых пакетов в nixpkgs иногда так задерживается.

А если ты хочешь сам запатчить glibc, даже если патч минимален и на ABI вообще никак не повлияет, то пересобирать придётся вообще всё и на своей системе. Даже в Gentoo такого ада не было.