Доступен релиз пакетного менеджера DNF 4.15, который используется по умолчанию в дистрибутивах Fedora Linux и RHEL. DNF является ответвлением от Yum 3.4, адаптированным для работы с Python 3 и использующим библиотеку hawkey в качестве бэкенда для разрешения зависимостей. По сравнению с Yum, DNF обладает заметно более высокой скоростью работы, низким потреблением памяти и более качественным управлением зависимостями...Подробнее: https://www.opennet.ru/opennews/art.shtml?num=58937
Когда Дебиан уже перейдёт на RPM & DNF?
Зачем, если Fedora 40 перейдет на APT & DEB
Потому что исходники DPKG/APT тошнотворны.
Пока что ничего лучше в этих ваших линуксах не придумано.
Всё говно, кроме Pacman. DNF тормозное говно, DPKG тормозное и тупое говно. Сам сижу на федоре с dnf и скучаю по pacman.
Пакман выглядит так, будто его писали на ПХП.
И не умеет ничего. По сравнению с apt он... не особо...
Pacman слишком примитивный и сложный в использовании.
Поправил. Пакман очень многофункциональный и элементарный в использовании. А пакеты вида pkg чистый мед по справнению с прочими. Черт, да для того чтобы пару штук закинуть в аур мне даже не понадобилось читать инструкции настолько все просто.
> Поправил. Пакман очень многофункциональный и элементарный в использовании.Если он такой функциональный то почему у арчеводов при переходе на системду система ГАРАНТИРОВАННО загибалась, если МАНУАЛЬНО не выполнить команды из ридми? Он настолько функциональный, что аж в триггеры не умеет? Или в чем тут фокус был с такой "функциональностью" что аж мануально пользователь должен команды выполнять, несмотря на то что это known issue?
И почему там какие-то йогурты и прочий левак, вместо того чтобы apt-get source <package> - и вот пожалуйста, билдуйте и патчите наздоровье.
> при переходе на системдуВ позапрошлом веке-то? Ну ты вспомнил.
> в триггеры не умеет?
man alpm-hooks. С разморозкой.
> почему там какие-то йогурты и прочий левак
Специально для тебя. Для чуть более сообразительных есть штатный makepkg.
> apt-get source <package>
asp export <pkgname>
Штатный метод. Изучай: https://wiki.archlinux.org/title/Arch_Build_System
> В позапрошлом веке-то? Ну ты вспомнил.В позапрошлом веке только релюшками начинали клацать. И то в конце.
> man alpm-hooks. С разморозкой.
Да ну его, я лучше man на dpkg почитаю. Там такие вещи дошли цать лет назад почему-то.
> Специально для тебя. Для чуть более сообразительных есть штатный makepkg.
Не, для меня вообще деб-образные. Как-то показались логичными и удобными. И не разносят систему вдрызг при случае.
> asp export <pkgname>
Это же не pacman?
> Штатный метод. Изучай: https://wiki.archlinux.org/title/Arch_Build_System
Да ну его нафиг. Если они чинят идиотию это хорошо но вы слишком какого-то утенка напоминаете, который доказывает что гамно - не так уж и невкусно.
> apt-get source <package>
> <транскации нинужна!>...
> Да ну его нафиг. Если они чинят идиотию это хорошо но вы слишком какого-то утенка напоминаете, который доказывает что гамно - не так уж и невкусно.То ли дело неутята, лезущие со своим наследием мамонта^W^W apt в любую новость о "неправильном" пакетнике ...
Да, не утята. Потому как редхатовским крапом еще и пользовалис. Немного но достаточно чтобы проникнуться пониманием как не надо делать пакетные менеджеры. Хлипкое, прожорливое, тормозное и глючное позорище, норовящее развалиться с поводом и без - не предел мечтаний. Заметив что это можно и получше я и полюбил другие дистры. Как-то так.
>> <pacman, рач>
> Да, не утята. Потому как редхатовским крапом еще и пользовалис. Немного ноНу да, неутятство так и прет.
Можно поподробнее узнать, как это слишком примитивный и сложный?
Это значит, что функционал у него примитивный, но простейшее обновление ты должен запускать командой pacman -Suy.
>pacman -SuyИ что тут сложного?
S - операция (группа команд) синхронизации с репозиторием
y - обновить БД пакетов на актуальные версии
u - запустить обновление, предварительно проверив, что все встанет как надоСначала немного непривычно, но затем легко запоминается и выполняется мгновенно и на автомате.
Абсолютно те же самые по сути действия в других пакетных менеджерах требует или ввода нескольких команд, или длинной строки команд, что для командной строки менее удобно.
Pacman примитивный потому что там нет многих функций которые есть в том же DNF. Например нет нормальной системы транзакций с возможностью отката изменений. А еще Pacman не очень хорошо справляется с одной из основных задач пакетного менеджера - не дать системе развалиться. Из-за чего Arch и основанные на Arch дистрибутивы регулярно ломаются при обновлениях. А сложный он из-за нестандартной и абсолютно не интуитивной системы команд.
Сложность пакетников никакого отношения к стабильности не имеет, а стабильность зависит конкретно от состава файлов (мейнтейнеры сами решают что туда положить).
Транзакции обеспечивают консистентность системы. Дают гарантию, что её компоненты остаются в согласованном состоянии. "Стабильность" - это слишком общее понятие и, похоже, написано в качестве мантры.
Пакетный менеджер не контролирует ПОЛНОЕ состояние системы, например рантайм данные программ. Поэтому консистентный откат с нового состояния на старое после обновления - вилами по воде писан. Пакетный менеджер вообще ничего не делает с рантайм данными программ и достаточно ограниченно трогает конфиги. И если при апгрейде "вверх" приличные программы и пакеты еще как-то обеспечивают обычно совместимость при изменении форматов конфигов или рантайм данных, то вот "вниз" это никто имплементит. И при попытке откатить новую версию до старой можно получить чудный выбор между неработающей новой версией и неработающей старой. Потому что старая версия оказывается не умеет понимать новые форматы конфигов или рантайм данных которые уже апгрейднули под новую версию, а потом - передумали, но...Представляете, пакетный менеджер не трекеает какие файлы при своей работе создают программы (/vad/lib, ~/* и тому подобное) и насколько оно там (не) совместимо по версиям программ. И если надо было гарантированый откат - это про полный снапшот состояния системы было, а не эти жалкие потуги.
> Пакетный менеджер не контролирует ПОЛНОЕ состояние системы, например рантайм данные программ.Задача вернуть в работоспособное состояние. Все программы и конфиги откатываются. Остальное - не важное. При необходимости перегенерится или просто трется.
Как бы вам ни хотелось, но транзакции явно НЕОБХОДИМАЯ вещь.
Да в том то и дело, что в подавляющем большинстве случаев хватит простых откатов. И рабочая система важнее, чем верование в идею "это NP-полная проблема и в общем виде не решаема".
> Да в том то и дело, что в подавляющем большинстве случаев хватит
> простых откатов. И рабочая система важнее, чем верование в идею "это
> NP-полная проблема и в общем виде не решаема".Откатов файловой системы?
Если так, то это вообще допускать нельзя. Ибо обновляться может совсем малая и редко используемая функциональность в процессе работы основной. И тут раз - откат результатов работы основной функциональности.
> - откат результатов работы основной функциональности.А для этого в каком-нибудь btrfs есть subvolumes, так что допустим home при правильном подходе можно и не откатывать. В виртуалке разумеется так не получится, там весь диск откатывается. С другой стороны до отката можно создать снапшот и потом изучать его сколько влезет или даже выцепить из него что-то нужное. Да, мир не идеален и свои ограничения есть у любой технологии.
>> Да в том то и дело, что в подавляющем большинстве случаев хватит
>> простых откатов. И рабочая система важнее, чем верование в идею "это
>> NP-полная проблема и в общем виде не решаема".
> Откатов файловой системы?Достаточно вот этого "все программы и конфиги откатываются".
В большинстве случаев.
Т.е. я не спорил, а соглашался.> Если так, то это вообще допускать нельзя. Ибо обновляться может совсем малая
> и редко используемая функциональность в процессе работы основной. И тут раз
> - откат результатов работы основной функциональности.В Виндос антивирусы ныне вполне умеют откатывать деятельность вирусов. Запускают их в песочнице. В случае нелегитимной деятельности не производят слияние с основной ФС.
Если снапшоты делать лень, то можно откатиться к архивной версии:1) /etc/pacman.d/mirrorlist:
Server = https://archive.archlinux.org/repos/yyyy/mm/dd/$repo/os/$arch
2) pacman -Syyuu
> Задача вернуть в работоспособное состояние. Все программы и конфиги откатываются.У программ могут быть какие-то свои идеи насчет потребных для работы данных - и их формата представления, и если в новой версии оно изменилось то толку с отката программы и конфигов если оно потом с вон тем не работает?
Откатить вообще всю ФС (или виртуалку) на блочном уровне в именно точное старое состояние на момент X - гораздо более гарантированное по результатам этого мероприятие. При этом ВСЕ откатится в вид как было, и если это работало - оно будет работать. А половинчатый откат пакетником - а вот как повезет. Может и не повезти.
> Остальное - не важное.
Если под новую версию программы грейданули какие-то рантайм данные - при откате взад даунгрейд версии этого обычно никто не умеет, и то что старая версия вообще запустится и сможет работать вот так - ниоткуда не следует. Может послать с непонятной версией рантайм данных в пень а то и вовсе покрешиться, налетев на неизвестный формат/схему хранения/прочие прелести. И что хотите то и делайте.
> При необходимости перегенерится или просто трется.
1) Возможность это сделать и последствия зависят от программ.
2) В результате мы не получаем "вернуть в работоспособное состояние" и вместо этого танцуем с бубном.
3) Откат блочным уровнем в старый снапшот быстрее, результативнее и безглючнее, и там сильно меньше что может пойти не так.> Как бы вам ни хотелось, но транзакции явно НЕОБХОДИМАЯ вещь.
Я вместо этой левой порнографии просто снапшоты ФС делаю перед крупными апгрейдами и тому подобным. И если что-то пошло не так - возвращаюсь на предыдущий снапшот. Как видите, без ваших дурацких транзакций не только можно обойтись, но это еще и сильно лучше работает, потому что таки трекает вот именно ВСЕ. Ну ладно, у меня есть деление на "system" и "userdata", это не я придумал а убунта но мне понравилось. Однако по понятным причинам снапшоты обычно делаются парой, на обе ипостаси сразу. Вот как раз для возможности именно гарантированного отката, если результат не понравился. И одно дело откатить снапшот за пару минут и другое танцевать с какой-нибудь навороченой программой у которой отпал формат данных, для этого сперва придется вообще вдуплить что отпало.
Итого транзакции сильно все усложняют а работает это достаточно хреново. По моему это неудачное соотношение. Одна из причин по которым энтерпрайзы много лет любят виртуалки и снапшоты. DNF при отклонениях от идеала сам первым же и разваливается и его починка это сильно отдельные танцы с бубном. Он так то довольно хлипкий, прожорливый и капризный. И одна из причин по которым я дебианобразные предпочитаю: считаю ниже своего достоинства пользоваться таким позором в качестве ключевого системного компонента. Я не мусорный бачок редхатских вебманков, извините, пусть сами вон то юзают.
> У программ могут быть какие-то свои идеи насчет потребных для работы данных - и их формата представления, и если в новой версии оно изменилось то толку с отката программы и конфигов если оно потом с вон тем не работает?Для несущественных программ - совершенно неважно. Для рабочих лошадок - существует бекап, который делается перед обновлением.
> Если под новую версию программы грейданули какие-то рантайм данные.
Как? Если новая версия программы не стартует, пока транзакция не завершится?
> Как видите, без ваших дурацких транзакций не только можно обойтись, но это еще и сильно лучше работает
Это не работает. Это нехилый способ поиметь проблем на элементарном обновлении утилит не относящихся к работе.
В процессе обновление мелких утилит сервер не останавливается и продолжает работать.
Данные на нем обновляются. Откатывать на снапшот - потерять рабочие данные.
Так можно делать только на локалхосте - да и то, если задачу в фон не повесил.
> Пакетный менеджер не контролирует ПОЛНОЕ состояние системы, например рантайм данные программ.
> Поэтому консистентный откат с нового состояния на старое после обновления -
> вилами по воде писан.Если на пальцах, транзакция - это когда пакетник устанавливает пакеты определённым набором, и только после того, как всё установились успешно, позволяет программам модифицировать "рантайм данные". В случае неудачи происходит откат к прежнему состоянию и программы продолжают работать, будто бы их новые версии не устанавливались вовсе.
> Пакетный менеджер вообще ничего не делает с
> рантайм данными программ и достаточно ограниченно трогает конфиги.Точнее, существующие реализации пакетников не обеспечивают должным образом? Какие-то справляются лучше, какие-то хуже.
> И если при
> апгрейде "вверх" приличные программы и пакеты еще как-то обеспечивают обычно совместимость
> при изменении форматов конфигов или рантайм данных, то вот "вниз" это
> никто имплементит. И при попытке откатить новую версию до старой можно
> получить чудный выбор между неработающей новой версией и неработающей старой. Потому
> что старая версия оказывается не умеет понимать новые форматы конфигов или
> рантайм данных которые уже апгрейднули под новую версию, а потом -
> передумали, но...Это вполне способен решать пакетник, если задаться такой целью. На примере браузера - сохраняется копия профиля, при неудаче установки происходит откат. Правда, мне тут не ясно - а в какой момент стало понятно, что транзакцию надо откатывать? Точнее, а зачем было запускать браузер, если он не установился.
> Представляете, пакетный менеджер не трекеает какие файлы при своей работе создают программы
> (/vad/lib, ~/* и тому подобное) и насколько оно там (не) совместимо
> по версиям программ. И если надо было гарантированый откат - это
> про полный снапшот состояния системы было, а не эти жалкие потуги.Я даже представляю, что надо сделать, что бы пакетник это "трекал". И догадываюсь, почему никто не реализовал. Беда в том, что эта причина мало кому понравится. :)
> транзакции1) Установи в другой корень:
pacman --sysroot <pacman_transactions_dir>/<new_transaction> ...
2) Если все прошло гладко, обнови (или смени) корень удобным способом.
С снапшотами оно примерно так же, только проще и прозрачнее получается и не трескает места на ВСЮ копию системы, только на дельту от исходного.
> программы продолжают работать, будто бы их новые версии не устанавливались вовсе.Установилось успешно - весьма абстрактно. Можно через эн минут обнаружить что программа не стартует или есть фатальные проблемы. С снапшотом передумал и вернул как было 1 в 1, какие проблемы. Можно даже через 10 минут. Или полдня. Если хранить дельту не лениво. А транзакции пакетника...
> Точнее, существующие реализации пакетников не обеспечивают должным образом? Какие-то
> справляются лучше, какие-то хуже.Они не были созданы для трекания ВСЕХ изменений ФС. Не их прерогатива. Блочный уровень виртуалок или ФС с этим лучше справляются.
> тут не ясно - а в какой момент стало понятно, что транзакцию надо откатывать?
И более того - а повторите это для того кад-пакета? А, другое знание, для большой программы? А вот снапшот откатит, как надо. Вернув в рабочий вид. В этом случае низкоуровневость дает фору, там просто не надо знать и уметь это, само получается.
> Точнее, а зачем было запускать браузер, если он не установился.
А может установился но не запускается. Или падает через 5 секунд. Если вам было надо браузер, самое оно откатить и разобраться как-нибудь потом. С снапшотом можно проблемное состояние поизучать неспешно, зацепив в сторонку, или в вон той виртуалке. Там время не жмет, сервис не стопорится же.
> Я даже представляю, что надо сделать, что бы пакетник это "трекал".
Это при сильном желании можно но ФС или виртуализатор с этим лучше справятся. Вы просто не понимете прелестей мультивселенных и путешествий во времени видимо.
>> программы продолжают работать, будто бы их новые версии не устанавливались вовсе.
> Установилось успешно - весьма абстрактно. Можно через эн минут обнаружить что программа
> не стартует или есть фатальные проблемы. С снапшотом передумал и вернул
> как было 1 в 1, какие проблемы. Можно даже через 10
> минут. Или полдня. Если хранить дельту не лениво. А транзакции пакетника...Пакетник может реализовать транзакции через снапшоты. Для этого достаточно написать ещё сотню комментариев на Опеннет, и он эволюционирует.)
> Пакетник может реализовать транзакции через снапшоты.Вообще - может. Я кажется понимаю намек что эти абстракции даже могут быть объединены. Для apt даже есть какой-то аддон который автоснапшотит btrfs при установке пакетов, получая нечто сравнимое. Наверное и к ZFS можно прикрутить, а может и еще к чему. В принципе хук может даже какое-нибудь апи виртуализатора вызвать снаружи виртуалки, если это разрешить (насколько безопасно давать виртуалке саму себя снапшотить - вопрос номер два).
Но с этим всем есть свои нюансы. Все же насколько полный откат выполнять - разумному существу может быть виднее, на тему того готовы они потерять userdata или лучше рискнуть и не трогать оные. Это может быть чревато потерей изменений в документах и проч - и энного количества вджоба. Поэтому говоря за себя я сперва пробую откатить только систему, а если это вызывает какие-то заметные проблемы - ну ок, тогда и userdata придется. Хотя если снапшотить синхронно, эта проблема отпадет. Но тогда возникнут ограничения на то как это можно и нельзя делать, потому что пакетник сам по себе вообще не готов столкнуться с произвольным multiverse с разными точками истории и возможностью переиграть. Особенно по частям.
> Pacman примитивный потому что там нет многих функций которые есть в том
> же DNF. Например нет нормальной системы транзакций с возможностью отката изменений.Эта система транзакций первым же делом и разваливается при отклонениях от идеала. Извините но снапшоты системы эту задачу решают и лучше и гораздо консистентнее. Потому что можно снапшотить все, а не только то что управляется пакетным менеджером.
Например рантайм данные программ пакетному менеджеру ортогональны, но это не означает что когда вы захотите откатиться то старая версия обязана понимать новый формат. Вот совсем не факт.
> А еще Pacman не очень хорошо справляется с одной из основных
> задач пакетного менеджера - не дать системе развалиться.DNF с этим тоже не очень хорошо справляется - сам же и разваливается первым делом. И это не у вас ли там система разваливалась "пототму что не перезагрузили в спецыяльный режим"? Капец, этл позорнее чем в винде - и вы из этого позора хотите нам показывать "как надо"? Может, скорее, как делать не надо?!
> Извините но снапшоты системы эту задачу решаютАга. Откатывается обновление, допустим, отсылки писем, и одновременно, ничем не затрагиваемая база интернет магазина. Красиво, чо!
> Ага. Откатывается обновление, допустим, отсылки писем, и одновременно, ничем не затрагиваемая
> база интернет магазина. Красиво, чо!Конечно при сильном желании можно себе пятку прострелить и с снапшотами. Если система A зависит от систем B - их видите ли надо было синхронно снапшотить и откатывать. И вот тут уже дело админа или псинодева знать такие вещи и их организовать правильно.
Есть более сложные случаи. Скажем реплицируемые базы. Но, знаете, если сильно захотеть можно успешно заснапшотить (и откатить) даже такое, типа AD. Такие финты крайне не рекомендуются к повторению без хорошего понимания проблематики, но вообще оно даже так может работать. А покажете вообще синхронный откат распределенной структуры пакетником? Оно точно сработает как надо? У меня на этот счет почему-то очень большие сомнения :)
> нет нормальной системы транзакцийПросто арчеводы не платят за то, что не используют. KISS my Arch.
> основных задач пакетного менеджера - не дать системе развалиться
Основная задача пакетного менеджера доставить и установить ПО. А всё остальное (например, откаты) - на усмотрение пользователя.
> Arch и основанные на Arch дистрибутивы регулярно ломаются при обновлениях
Десять лет пользуюсь Arch Linux, основанном на Arch Linux, каждый день обновляюсь, у меня ничего не ломается. ЧЯДНТ?
Мне кажется, вы знакомы не со всеми пакетными менеджерами или у вас юношеский максимализм. Потому что, так нахваливать пацман при существовани xbps может только умственно отсталый человек.
DNF тормозит потому что гарантирует стабильность и целостность, в отличие от других пакетных менеджеров.
А мне кажется, потому что гарантируется, что он написан на питоне.
> А мне кажется, потому что гарантируется, что он написан на питоне.Это гарантирует дикие тупняки на все операции и жесткий развал системы если ему менее 512 метров свободной памяти осталось. А вот чинить потом разлетевшуюся базу - не особо дружественно и как повезет, вообше.
> Сам сижу на федоре с dnf и скучаю по pacman.А смысл сидеть на федоре если пакман хочется? Что одно что другое для продакшна непригодно, так что какая разница? Пользовался бы пакманом.
Сказали же: DNF.
Сказали же: APT.
Сказали же XBPS!
MSI.
winget сейчас в треде
Нет, всё-таки pacman. Кстати, под виндой тоже работает, см. MSYS2/MinGW.
> Нет, всё-таки pacman. Кстати, под виндой тоже работает, см. MSYS2/MinGW.Плюсую.
Единственный нормальный инсталлятор в винде.Если бы emerge портировали, то винда совсем бы пригодной для использования стала бы.
Дальше собственного носа пробовал смотреть? Да все что угодно лучше apt-dpkg! А вообще да, пмов нормальных нема, пакман ничего вроде, но все испортил арч, кусок говна. Про прочие никсы можно и не вспоминать, овчинка выделки не стоит. А вот xbps незаслуженно забыт, и что-то не видно толп линуксойдов в ментейнерах у войда, которые так ратуют за свободу от ненавистных технологий проталкиваемых корпорастами. Хм, странно, потому что войд на голову выше ваших федоров с денисами! Слышу вот кто-то чавкает там, узнаешь себя линуксойд?
Небольшое сравнение пакетных менеджеров систем Void и Arch.
https://www.reddit.com/r/voidlinux/comments/b9jj35/void_vs_a.../
Пост о том, как кто-то не осилил смену инита? Бывает. Я не спрашиваю "зачем это было нужно", тем не менее, ежели уж шило в жопе не утаить, нужно по крайней мере пользоваться нормальными инструментами, которые позволяют делать что нужно, без лишнего головняка, брать надо было крукс! Ну и апт-дпкг - с которого и начался этот разговор, все равно в пролете.
Сравнение устарело на 4 года, местами вообще ерунда какая-то написана.Частичные обновления - не рекомендуются, но поддерживаются.
Пакеты с отладочными символами:
https://debuginfod.archlinux.org/
Линуксойид?
Ты вот орешь как псих, а тем временем xbps неочевидно хорош так как ему можно прикрутить морду в терминал под названием xbpsUI и влепить ее куда-нибудь в /usr/bin сделав исполняемой через chmod +x xbps (да переименовывается ибо нет такой команды в войде).
И вот потом неочевидный плюс его связь с xbps-src, который легко соберет скажем браузер, а потом ему можно командой запретить это обновлять бинарниками.
Ни один из этих пакетных менеджеров не сделан для людей. Все для тех кому однообразие хорошо.
Ну и пакет собрать для xbps элементарно.
Но ты упорот и думаешь сопровождающие появятся когда множество людей тупят не понимая зачем им что-то меня ведь корпорасты они же хорошие и все новое делают. Не то что этот runit ваш скоростной. Надо же систему команд учить и язык программирования для системд, а это ж +100500 к крутости, а не эти ваши ln-s /etc/sv/dbus /var/services
ты не понял ничего.почему арч популярен? да потому что под него софт легко собирать, вот и все. но в арче политика тупаю, положили болт на совместимость, нет у них инструментов разруливать несовместимости библиотек, собралось и ладно, юзер на срезе обновится.
про рунит вообще не понятно, что ты хотел сказать? ты в курсе что изначально в войде был системд?
в арче и войде я могу просто глянув на шаблон сборочного скрипта опакетить себе софт... как с этим в деб-рпм? чуток документации прочесть?
а на счет самого xbps... что тут можно сказать, печально видеть, нормальный пм никому не нужен, у всех пальцы приросли к apt-get, где те разработчики свободного софта? уже давно б вменяемую морду к нему прикрутили(нет, не та что в графическом режиме работает)
Чувак, выдыхай, когда войд создавал его создатель тогда системды не было. Чувак вдохновлялся простотой бсд систем.
А что там творят арчеводы мне все равно, так еак я не вижу смысла в системд даже на сервере так как войд можно собрать как угодно ибо он изначально минимален.
И я же сказал что морда есть. Иногда правда требует команду ввести для дальнейшей работы обновив сам пакетный менеджер.
Но для небестолковых людей это не сверхзадача. Днищам же надо как все толпой один единственно правильный метод делать. Им в концлагере проще.
Морда есть. Людей незашоренных нет.
>когда войд создавал его создатель тогда системды не быломда. в войде с самого начала его создания был системд, если что, а когда понадобилась надобность в мусл, от него отказались в пользу рунит, потому что системд не мог в мусл.
>Людей незашоренных нет
там их совсем почти нет, гцц со шлангом два года обновляли.
Пакетные менеджеры исключают интеграцию без превращения системы в франкенштейна если тебе хочется сделать систему лучше.
То есть она обновит тебе ядро запросто на подписанное каким-нибудь ключом от редхата, которому нельзя доверять в сегодняшних реалиях, может убить браузер, который ты собирал из исходников чтобы ускорить его работу много часов на слабом ноутбуке, которому любое ускорение не будет лишним до куче к массе оптимизаций в лице убивания всего лишнего на ютубе блокировщиком рекламы, вырезая все вплоть до кнопок в проигрывателе потому что это увеличивает время загрузки страницы.
Именно эта разница делает Void превосходным потому что собирать каждый день пачку языков программирования ноутбук может быть физически неспособен и ему Gentoo будет противопоказана.
А вот собрать раз в месяц нужное ночью без отнимания времени компиляя только сам браузер а не раст, гцц, ллвм и прочую тряхомундию.
Собрать ядро наконец и не давать его удалить массовыми средствами очистки например.
Это вообще может быть единственно правильным в скором времени решением так как обычное ядро может быть лишено защиты и уникальности размещения в памяти самого ядра.
Очень странно что в большинстве дистрибутивов все сделано чтобы сделать человека пользователем в худших традициях общества потребления.
Два чая этому господину, прекрасно всё расписал!
> Очень странно что в большинстве дистрибутивов все сделано чтобы сделать человека пользователем
> в худших традициях общества потребления.Потому что Linux - это франшиза.
> Потому что исходники DPKG/APT тошнотворны.Ну да, не пихтон.
Есть apt-rpm
Самим есть.
> Потому что исходники DPKG/APT тошнотворны.По сравнению с DNF оно очень даже ничего :)
Сам жду - не дождусь. Как вообще apt/deb дожил до сегодняшнего дня?
Некоторым людям нравится, что не надо ждать по пять минут, пока пакетный менеджер проснется.
Это вы про apt update с соответствующим ожиданием каждый раз, перед тем как установить требуемый пакет?
А зачем вам делать update каждый раз? Один раз сделай и устанавливай.
Потому что в DNF индекс пакетов обновляется первым делом при любом вызове.
Соответственно, первые пару минут - можно сходить за кофе.APT такого шанса не даёт. В этом, собсно, и претензия.
> А зачем вам делать update каждый раз? Один раз сделай и устанавливай.Более того - новые убунты и дебианы норовят индекс, а то и пакеты в системе, по таймеру обновить. И чтобы получить вот именно устаревший индекс и ожидание - это еще надо мануально постараться чтобы вон то отключить. Если вы сами взяли пистолет, приставили его к пятке и нажали на спуск очень странно винить в этом кого-то кроме себя.
Ахаха, федораст спалился. apt update не вызывается автоматически при каждом search/install/upgrade, в отличие от.
Бредить только не надо.
apt, на самом деле, очень тормозной в плане установки пакетов. Это заметно когда система не на ССД. dnf гораздо быстрее устанавливает, но вначале весьма задумчив.
В сумме dnf на голову отстаёт от apt по скорости установки. Пока что apt топ.
Это скорее dpkg так а не apt/apt-get. Попробуйте например через
echo "force-unsafe-io" > /etc/dpkg/dpkg.cfg.d/force-unsafe-ioИ сравните
Можно еще установить что-то типа eatmydata и потом eatmydata apt ... что вы там хотели.Что-то такое имеет смысл при оптовом апгрейде системы до новой версии, например. Ну как, сделать снапшот, запустить апгрейд "без гарантий" а если в процессе система навернется, просто снапшот откатить и попробовать еще раз. Это намного быстрее и эффективнее любых дурацких транзакций и гарантирует железобетонный откат в исправное состояние, даже если сам пакетный менеджер развалится, например. А конкретно DNF это дело люьбит и можно угрохать больше времени на починку DNF чем на откат снапшота, ну и нафиг оно такое?!
> dnf гораздо быстрее устанавливает, но вначале > весьма задумчив."Еж птица гордая, пока не пнешь не полетит".
Когда перепишут с питона на раст
Переписывай, разрешаю.
> Переписывай, разрешаю.Это не был вопрос, вопросительного знака у меня в предложении нет.
> Когда Дебиан уже перейдёт на RPM & DNF?Когда рак на горе свистнет.
>DNF является ответвлением от Yum 3.4Yum написан на питоне, DNF 5 - на C++
Так ведь вышла 4-я версия утилиты, а не 5-я.
Кому надо - тот давно уже пятой пользуется.
>Yum написан на питоне, DNF 5 - на C++Fedora - концентратор плохих решений.
> Yum написан на питоне, DNF 5 - на C++Именно поэтому в RHEL используются DNF ранних версий, которые тоже на питоне.
Это пока что
> Именно поэтому в RHEL используются DNF ранних версий, которые тоже на питоне.А чего тогда новость была что таки вот наконец окончательно переписали, так что питон вообще выбросили? Они планировали в новой версии на apt перейти? Или как вы объясняете этот феномен? :)
Беды с башкой у разработчика переписывание не решает.
Если единственная беда с башкой у разработчика - использование смузихлёбных технологий не смотря на все их недостатки, потому что модно - то очень даже решает.
Всегда заходя в Oracle/Fedora путал, что набирать.YUM Или DNF. Что из них луддитное, что новое.
А учитывая, что были инстансы со старым Oracle — всё ещё усложнялась. Там так, тут сяк.
Ну вообще то там есть заглушка и можно набирать yum и в RHEL8+ (и прочих производных). будет вызван dnf.
Я знаю.
Но просто чувствуешь дискомфорт, когда набираешь луддитную команду вместо новой.
На любой системе, включая последние RHEL 9 / Oracle можно всегда набирать yum и это будет прозрачно работать, ткlrwxrwxrwx. 1 root root 5 Jan 6 21:23 /bin/yum -> dnf-3
а скрипты и прочее ломать в этих системах не принято. Если вдруг перестанет работать, вам об этом скажут...
>> YUM Или DNF. Что из них луддитное, что новое.
> На любой системе, включая последние RHEL 9 / Oracle можно всегда набирать yum и это будет прозрачно работать, ткВы же понимаете, что Пони нужны шашечки, а не ехать?
Ему уже давно нужны хорошие таблетки.
Один раз линуксоид забыл написать тупую поговору про шашечки и у него отвалилась zope.
> Один раз линуксоид забыл написать тупую поговору про шашечки и у него отвалилась zope.Очереднрой раз вендо-маковод при попытке свинтить с темы не угадал ...
> отвалилась zope.Софт с такими названиями вообще не надо было устанавливать.
Мне надо ехать, извиняюсь, с шашечками ☝
Это еще что, репы по прежнему лежат в /etc/yum.repos.d/ даже в последней Федоре :)
> луддитноеПрошу модераторов удалить комментарий данного персонажа.
> добавлен параметр "reboot" для определения поведения при необходимости перезагрузкиВ каких случаях вообще может понадобится перезагрузка?
В Фёдоре любят копировать плохие решения из винды, поэтому любые обновления пакетов там идут через ребут.Но если абстрагироваться от федоропроблем — для обновления ядра, например, чтобы не крутить ОС и дальше на старом.
Технически линукс и винда в этом плане ведут себя различно, а по факту - проблема одинаковое и решеение одинаковое.Нашли очередную дырку в openssl (или ее виндовом аналоге). Проблема винды: открытый файл нельзя презаписать, блокировка. Требуется перезагрузка. Проблема линукса: открытый файл перезаписывается при обновлении без проблем, но все приложния, где он был открыт продолжают видеть старый файл, с неизвестными потенциально последствиями, ведь уязвимость уйдет не после установки обновления, а после перезапуска всего, что могло использовать эту библиотеку. На системе с кучей компонент перезапускать половину системных процессов потенциально более проблемно, чем перезагрузить все и гарантировать что уязвимость более нельзя проэксплуатировать. В итоге то же решение, что и на винде. То, что в линуксе обновляются открытые файлы это изящно, но реальную проблему только скрывает.
> На системе с кучей компонент перезапускать половину
> системных процессов потенциально более проблемно, чем перезагрузить все и гарантировать
> что уязвимость более нельзя проэксплуатировать.systemd как раз могла бы решать этот вопрос, но почему-то занимается всем остальным, кроме него.
Вообще-то в apt хуки сделали и вот таки благодаря тому что интерфейс к системд более менее унифицирован оно вполне умеет перезапускать затронутые обновлениями сервисы. Более того - в новых убунтах это даже сдедали по дефолту.Правда приводит к другой проблеме - если некто не очень опытный апдейты ставит, уппс, толпу народа с вон того чатика/форума/чего там у кого - чота вышибло, внезапно и без предупреждения. Так что они ругаются на кривого админа.
apt-хуки? Парсить /proc что ли? Не-не-не, это не так делается, потому что получите гонки. У systemd и без того есть все данные для построения графа.
> apt-хуки? Парсить /proc что ли? Не-не-не, это не так делается, потому что получите гонки.Не, там как-то иначе сделано. Оно трекает зависисмости и если мы проапдейтили допустим zlib - можно настроить что будет авторестарт всех сервисов кто зависит от zlib.
Полезность фичи разумеется сильно зависит от характера сервисов. Если оно вышибет легион юзеров с какого-нибудь сервера без предупреждения, они разумеется останутся недовольны, так что нубастые админы иногда кушают лучи добра за внезапные вырубания сервисов. Зато, вот, все что зависело от zlib теперь юзает новый zlib. Без полного ребута.
Для libc таки это ведет к рестарту почти всего и некоторые вещи, особенно на десктопнике, разумеется, вот от и до рестартануть все же напряжно.
> У systemd и без того есть все данные для построения графа.
А у пакетника есть все данные о depends на предмет либа <-> установленный софт, чтобы при апдейте либы озаботиться рестартом ее юзеров, если это так сконфигурено. А вот сам по себе системд в чистом виде вообще не знает "кто юзает zlib в системе". Ну не его это изначально.
>> apt-хуки? Парсить /proc что ли? Не-не-не, это не так делается, потому что получите гонки.
> Не, там как-то иначе сделано. Оно трекает зависисмости и если мы проапдейтили
> допустим zlib - можно настроить что будет авторестарт всех сервисов кто
> зависит от zlib.Эти сервисы зависят не только от zlib, но и друг от друга, потому перезапускать их следует в определённом порядке. Этим как раз и заведует systemd.
Моё сообщение о systemd было ответом на "перезапускать половину системных процессов потенциально более проблемно, чем перезагрузить все".
> А у пакетника есть все данные о depends на предмет либа <-> установленный софт
Странно, что systemd не спрашивает пакетник, а смотрит соответствующие поля в юнит-файлах.
> Эти сервисы зависят не только от zlib, но и друг от друга, потому перезапускать
> их следует в определённом порядке. Этим как раз и заведует systemd.Ну да. И в этом аспекте системд все же улучшил некоторые аспекты. По факту в случае apt пакетник после инсталла пакета информирует системд что хочет рестарт вот этого и этого а тот сам секвенсит это. И на вид это вроде бы как раз нормальное разделение фичности по компонентам. Зачем системде самому знать кто там какую либу юзает - это наверное лишнее, он и так уже здоровый стал и втягивать в него именно это странная идея. Это конечно уменьшит core пакетника но раздует системду. Как по мне лучше пусть эпизодичкски запускаемый тул жиреет чем резидентный системный управлятор живость которого в системе довольно критична.
> "перезапускать половину системных процессов потенциально более проблемно,
> чем перезагрузить все".Всякие дебианобразные научились вот авторестартить затронутые апдейтом сервисы, в том числе и трекая либы. Если это разрешено в настройках пакетника. Что так то довольно продвинуто. Это позволяет с одной стороны апдейтнуть и либы и получить эффект от апдейта а с другой избежать полный ребут - в чем пойнт этого упражнения и состоит. На десктопе это разумеется хуже работает, какие нибудь иксы например перезапустить чтобы они поюзали фикшеный libc и чтоб при этом графика не осыпалась - да сейчас. Но вот чем мне линукс нравится, так это тем что можно самому решать вместо "мы решили вас перезагрузить и фиг оспоришь, скажите гудбай работе".
Самое интересное? А вот системд например на удивление умеет релоадить сам себя после апдейта. Так что его pid 1 вгружает новый pid 1 из новой версии - и это забавный финт с точки зрения всяких системных штук.
> Странно, что systemd не спрашивает пакетник, а смотрит соответствующие поля в юнит-файлах.
Пакетники разные бывают. Или даже никаких. Systemd не может уповать на какую-то конкретику. С другой стороны он делает некоторые вещи для интеграции с пакетниками без учета какой пакетник. Как то - майнтайнерам было сказано что ваши юнитфайлы вы кладете в usr, а админские оверрайды идут в /etc и пакетник ЭТО вообще не трогает, хоть там как. Это заодно решило и проблему с конфигфайлами vs пакетник: можно и системные дефолты притащить, но они ни при каких условиях не перетрут оверрайды админа, оверрайды приоритетнее. Вообще, это довольно продуманная архитектура, деланая именно с учетом фактического состояния дел. И мало кто еще этим может похвастаться. Как угодно но Поттеринг был далеко не самый плохой архитект и техзадание ему нормально скроили.
> Зачем системде самому знать кто там какую либу
> юзает - это наверное лишнее, он и так уже здоровый стал
> и втягивать в него именно это странная идея. Это конечно уменьшит
> core пакетника но раздует системду.Потому что:
> Пакетники разные бывают. Или даже никаких. Systemd не может уповать на какую-то
> конкретику.
Поттерингу и так чрезмерную интеграцию, прибитие на гвозди и излишний вес пеняют. То что вы предлагаете технически реализовать можно при сильном желании, но кмк это усугубит упомянутые аспекты а в чем будет профит - кто б его знает. Оно ведь уже было и работало, хоть и по другой технологии...
apt install needrestart
Посмотрите сообщение №29, на которое был мой исходный ответ про systemd:"перезапускать половину системных процессов потенциально более проблемно, чем перезагрузить все".
>решения из виндыА причем здесь вообще винда? macOS например тоже требует перезагрузки для установки обновлений) Это нормальная практика. Установка обновлений в "оффлайн" режиме значительно снижает риск поломки системы.
Для перехода но новое ядро перезагрузка не обязательна.
не рассказывай сказки про ребут после любых обновлений через dnf, если обновиться через dnf -y update не будет никакого ребута, ребут нужен для обновления ядра. а вот если обновляться через dnfdragora, то вполне себе может потребоваться перезапуск
Смысл ребута не в обновлении ядра (осмысленные обновления там не особо требуются, обычно, если не напороться на странные баги или иметь очень свежее оборудование, которое еще не полностью поддерживается), а в обновлении библиотек: когда находят очередную дырку в glibc или openssl или еще подобном, что использутся в каждой второй (а то и вообще каждой) программе, ребут это единственный способ гарантировать, что все, где уязвимость может быть проэксплуатирована, реально запустилось с новой версией библиотеки.
Lsof тебе зачем, которыц покаже каие процессы юзабт библиотеку?
Ты руками это собрался делать? На сотне серверов?
zypper ps -s
Выдаёт список всего, что необходимо перезагрузить после обновления. В openSUSE это уже больше 15 лет. А DNF они тоже попробовали...
>если обновиться через dnf -y updateНе советую так делать. Есть риск сломать систему. Разработчики Fedora рекомендуют обновляться через Gnome software в специальном оффлайн режиме.
это рофл? даже в инструкции миграции с релиза на релиз пишут юзать 'dnf upgrade --refresh'юзаю dnf upgrade уже лет 5 и никаких проблем
>даже в инструкцииСтарые инструкции читаете. Советую изучить вот это:
https://fedoramagazine.org/offline-updates-and-fedora-35/
С релиза на релиз тоже желательно обновляться через gnome software.
>юзаю dnf upgrade уже лет 5 и никаких проблем
Значит вам повезло. Я так один раз систему сломала. Во время обновления упал gnome shell вместе с терминалом в котором был запущен DNF и все. После перезагрузки система не загрузилась. После этого обновляюсь только через gnome software и вам советую делать так же.
а что, по вашему gnome software не может рухнуть вместе с gnome-shell? тогда уже вам лучше в ctrl+f3 переключаться и там dnf upgrade запускать
> а что, по вашему gnome software не может рухнуть вместе с gnome-shell?
> тогда уже вам лучше в ctrl+f3 переключаться и там dnf upgrade
> запускатьctrl+alt+f3
Вы не совсем поняли как это работает) Gnome software ничего не устанавливает. Он просто скачивает обновления и подготавливает их для установки в специальном "оффлайн" режиме. Поэтому даже если gnome software рухнет ничего страшного не произойдет. Советую изучить статью которую я скинула. Там подробно описано как работают "оффлайн" обновления и зачем они нужны.
> Вы не совсем поняли как это работает) Gnome software ничего не устанавливает.
> Он просто скачивает обновления и подготавливает их для установки в специальном
> "оффлайн" режиме. Поэтому даже если gnome software рухнет ничего страшного не
> произойдет. Советую изучить статью которую я скинула. Там подробно описано как
> работают "оффлайн" обновления и зачем они нужны.а что, в "оффлайн" режиме ничего не может навернуться, по такой логике? давайте вот как поступим.. вы подъедите ко мне, заполним с вами ктубу и, за тем, вы мне всё расскажете и покажете.
Если в offline режиме что-то рухнет, то транзакция не пройдет и вы так же загрузитесь, как это делали до обновления.Единственное, что может сломаться, так это обновление загрузчика.
Offline режим нужен для более корректного обновления системы. Надеюсь не нужно объяснять? И если оно имеется, нет смысла его не использовать.
> Надеюсь не нужно объяснять?да. объясните, чем конкретно безопаснее эта оффлайн установка, чем dnf upgrade в текстовом режиме. потому что кроме федоры я перед ней ещё другой дистреб юзал 6 лет и точно так же производил обновления на лету и не видел никаких таких проблем..
короче.. есть мнение, что лучше я останусь при своём мнении.. я дистрибутивы делал сам, а вы - нет.
А подумать никак?Для этого почитай как работает offline update.
Какая же у Fedora ужасная документация по сравнению с некоторыми другими дистрибутива и. Это просто ужас.
Вполне нормальная документация.
> Вполне нормальная документация.Вот уж нет. Прекрасная документация - это у арчика в вике. Остальное вообще рядом не стояло. Если есть неочевидный вопрос по линуксу - арчевская вика почти наверняка знает как это делается. Ее грешным делом почитывают даже обладатели убунт и дебианов, потому что оно не настолько уж далекое от, в конце концов.
Федора на этом фоне - ни о чем. У них по сути нет живого комьюнити, редхат и IBM вообще враждебны к комьюнити инициативам. Если бы это было не так, они бы не громили центос, для начала. А какая мотивация у народа вон те технологии осваивать, если продакшн учитывает только узкую группу лиц из фортуны-500 и это не про них? Ну вот и в документации это тоже отливается.
У Fedora хорошая документация. Если зарегистрироваться на ресурсе Red Hat, то ещё больше будет. Она с лихвой покрывает потребности.
> У Fedora хорошая документация. Если зарегистрироваться на ресурсе Red Hat, то ещё
> больше будет. Она с лихвой покрывает потребности.Хорошим или плохим можно быть только по сравнению с чем-то. И в этом аспекте арчевики без конкурентов. Куда там до этого федоре. Зарегистрироваться? Оу, а на арчевики бесплатно, без регистраций и смс.
Читать умеешь?Документация Fedora покрывает основную часть потребностей дистрибутива. Она в свободном доступе.
Документация от Red Hat отличная, но нужно зарегистрироваться.
Их вполне хватает. На Wiki Arch Linux заходил несколько раз и то лет десять назад)
И да. Нужно понимать разницу между документацией и wiki.
> Документация Fedora покрывает основную часть потребностей дистрибутива. Она в свободном
> доступе.А арчевская вика настолько крутая что покрывает даже многие потребности других дистров, 90% того что там применимо и к другим дистрам. И там так то сильно больше информации.
> Документация от Red Hat отличная, но нужно зарегистрироваться.
Именно поэтому я обычно нахожу ответы в других местах а пользоваться редхатообразными вообще не испытываю никакого желания.
> Их вполне хватает. На Wiki Arch Linux заходил несколько раз и то лет десять назад)
Кому-то и дефолтных реп рхела хватает, мало ли. Не значит что они офигенные и что лучше нельзя.
> И да. Нужно понимать разницу между документацией и wiki.
Ага, в вике инфо актуальное, живое, и апдейтится первым наступившим на грабли. Сейчас, а не через полгода когда у перегруженного техписа время появится. Это живое, актуалное знание.
Арчвики действительно хороша. Но маны не отменяет. Скорее помогает понять в каком направлении копать.
> Вполне нормальная документация.Которой нет. Единственные 2 сборки у которых нормальная документация это арч и генту. Остальное - мусор.
Согласен.
Выше упомянутый offline upgrader в dnf попробуй найди.
https://dnf-plugins-extras.readthedocs.io/en/latest/system-u...Хуже нет. Каша из непонятно чего.
Зачем тестовому полигону нормальная документация? И та-ак сойдёт!
> Зачем тестовому полигону нормальная документация? И та-ак сойдёт!А арчеводы часто получали граблями в лоб и поэтому вика у них прекрасная, конечно, но вот мотивы ее появления... =)
Did Not Finish
ну или Duke Nukem Forever, что, впрочем, почти одно и то же.
Сам .rpm со своим cpio устарел уже давно.
Почему? Мастдаевское *.exe - вот что устарело!
> Сам .rpm со своим cpio устарел уже давно.RPM 5.0 format supports using xar for archiving.
> RPM5Тупиковая ветвь, которую забросили 10 лет назад.
Сейчас до сих пор используется RPMv4 c его cpio
>> RPM5
> Тупиковая ветвь, которую забросили 10 лет назад.
> Сейчас до сих пор используется RPMv4 c его cpioИ в самом деле забросили. :-)
Вот ведь неудачка.
Вспоминается анекдот заканчивающийся фразой:
"А чего с вами знакомиться-то?.. ВЫ КАЖДЫЙ ГОД НОВЫЕ"