Ричард Хьюз (Richard Hughes), создатель проекта PackageKit, опубликовал (http://blogs.gnome.org/hughsie/2013/05/29/the-future-of-pack.../) задачи, рассмотренные на совещании, посвящённом модернизации системы управления пакетами в Fedora Linux. В частности, пакетный менеджер YUM признан устаревшим и ему на смену скоро придёт система DNF (https://fedoraproject.org/wiki/Features/DNF), в рамках которой развивается форк YUM 3.4, переведённый на использование в качестве бэкенда для разрешения зависимостей библиотеки hawkey (https://fedoraproject.org/wiki/Features/Hawkey) с реализацией SAT solver. В отличие от YUM новый пакетный менеджер отличается заметным увеличением скорости работы, низким потреблением памяти, предоставлением API для плагинов и интеграции с другими приложениями, такими как инсталлятор Anaconda.URL: http://blogs.gnome.org/hughsie/2013/05/29/the-future-of-pack.../
Новость: http://www.opennet.me/opennews/art.shtml?num=37062
Чегой-то не понял - они не собираются интегрировать пакетный менеджер в systemd?
Тоже удивился.
А зачем? В systemd можно интегрировать сразу весь софт, который раньше был в пакетах :)
Точно! и как еще Поттеринг не догадался - встроить весь софт в systemd, и пакетного менеджера не надо.
YUM давно не торт, хотя если DNF -- очередной эксперимент, то федоровцам я не завидую. ИМХО, от создателя PackageKit ничего хорошего ждать не стоит
> YUM давно не торт, хотя если DNF -- очередной экспериментДа, это очередной эксперимент. Как и все федоровские эксперименты,
> новый пакетный менеджер отличается заметным увеличением скорости работы, низким потреблением памятинесет добро и свет пользователям федоры и муки бугурта убунтятам :)
> несет добро и свет пользователям федоры и муки бугурта убунтятам :)У убунтят пакетный менеджер нормальный, не требует на виртуалке 512 памяти вкатывать чисто для того чтобы пакетами оперировать, btw. И работает не в пример резвее этой вашей питонятины, которой феерические костыли подставляют. Вообще, у редхатчиков пакетный менеджер - одна из самых мерзостных частей системы. За один только этот пакетный менеджер они просто обязаны профукать почти весь рынок debian-based, работать с пакетным менеджером которых просто на порядок приятнее.
А у меня как раз обратные впечатления. Что касается YUM-а который в федоре, тут да, очень тормозной. Даже система начинает подтормаживать. А вот тот YUM что используется в RHEL, вполне себе шустрый. Специально сравнивал, особой разницы по скорости не увидел. Для меня большим плюсом YUM является скорость оперирования командами - одна короткая команда для всего. И ещё огромный плюс способ отображения информации установки или обновлении паркетов. Всё в таблице четко и понятно, апт или апитуде выдает сплошную кашу.Конечно большую роль тут играет привычка.
ну да конечно
apt-get install mc
аж на 4 символа длиннее чем
yum install mc
Тут получается по другому.
В федоре достаточно yu+ табуляция, против apt-g+табуляция. На 3 символа больше. Когда часто приходится набирать, это раздражает. Хорошо хоть dnf такая же коротка команда.
Так же раздражает запуск сервисов с systemd. Раньше с табом можно было быстро добраться в /etc/init.d/ и с помощью же таба посмотреть список сервисов которые можно запустить, с новой же системой инициализации стало не так тривиально.
юзайте alias'ы
Алиасы удобно если пара серверов. Если их много, то удобнее системами управления конфигурациями пользоваться. А вот если нужны не массовые изменения, а точечные, да ещё и траблшутинг тут удобство и скорость работы с yum вне конкуренции. Подчеркиваю что это при работе с RHEL/Centos, а не с Fedora.
Хотя все эти рассуждения становятся бессмысленными, так как много серверов это уже ентерпрайз, а для этого Debian мало кто ставит.
> Алиасы удобно если пара серверов. Если их много, то...то не сильно тyпой админ просто вкатит алиасы/предпочтения средствами группового администрирования или накрайняк просто скриптиком обходящим сервера. Прикиньте, какая неожиданность - админ должен уметь автоматизировать работу по минимуму. Иначе это специально обученная обезьяна - эникейщиком называется.
> а для этого Debian мало кто ставит.
Ну да, туда убунту пхать начинают, у нее поддержка есть. А потом редхат еще и удивляется - чего это у них рыночная доля так проседает. Они хорошо работают над ядром, но все остальное они делают весьма "на отъ...сь".
Вас уже на каникулы отпустили?
> Вас уже на каникулы отпустили?Ну да, лет где-то 15 назад :)
Сейчас только попробовал в 18 федоре: набираю systemctl status потом после пробела жму Tab, оно мне отвечает: Display all 307 possibilities? (y or n)Так что все работает как и в случае c /etc/init.d
> тот YUM что используется в RHEL, вполне себе шустрый.Вообще-то, в RHEL/Centos он тоже скоростью не блещет. Если, конечно, сравнивать на репке примерно одинаковых размеров.
> Специально сравнивал,
А количество пакетов в репах вы сравнивали? А то вы пожалуй раньше чемпиона мира к финишу придете, если тот будет бежать километр, а вы - стометровку. Отсюда однако не следует что вы - хороший бегун.
> является скорость оперирования командами - одна короткая команда для всего.
Тоже мне преимущество. Во-первых, в shell есть автодополнение. Во вторых, там есть алиасы. Так что если плюс-минус 2 буквы роялят, у системы есть штатные средства для делания команд удобными конкретному индивидуалу.
> И ещё огромный плюс способ отображения информации установки или обновлении
Что-то не заметил каких-то гигантских плюсов относительно других пакетных менеджеров. Они вообще в чем?
> паркетов.
Ха-ха, почти по фрейду.
> Всё в таблице четко и понятно, апт или апитуде выдает сплошную кашу.
Апт выдает вполне нормальный список, рассортированный по типам действий. Вполне доходчиво и понятно. Конечно, если вы раздолбай и апгрейдите по 200 пакетов за присест, делая это раз в полгода - может оно и роялит. А в нормальных условиях - апт вполне себе удобная штука.
> Конечно большую роль тут играет привычка.
Ну вот мне как-то вломак привыкать к тормозам и адскому жрачу памяти, так что виртуалке для пакетного манагера память приходится досыпать. А не для того что там работает. Пф!
"убунтят пакетный менедже" - только за то что скрипты настройки выполняются после установки всех пакетов нужно фоберже отрывать. Вот недавно один убунтенок обновлял систему, конечно повисла - и как результат - потеряла клаву, мышу и сеть. А всего лишь не выполнился depmod после обновления ядра, и модули не загрузилисьИ после этого кто-то тут будет петь гимны дебам?
А при чем тут деб-ы?
а вас какое вариант устроил бы? в начале? ну типа ничерта не поставилось, а конфиги поправлены. в середине? или дело таки в зависании?
> а вас какое вариант устроил бы? в начале?Вообще, IIRC, там и хуки для запуска в начале есть. Только обычно оно работает после установки и делает доконфигурацию своего пакета и прочая. Скрипты до установки пакета редко требуются просто. Ну вот никто ими и не пользуется.
Ну, по скорости работы им обоим далековато до pacman'а. И команды в нем лаконичные, и с зависимостями неплохо справляется, и принцип работы понятный и прозрачный.
>>Вообще, у редхатчиков пакетный менеджер - одна из самых мерзостных частей системы<<вы просто попробуйте - вдруг понравится
> вы просто попробуйте - вдруг понравитсяДа вообще-то я пробовал. А вот потом мне попался в руки дебиан и убунта. И я оценил различие, да :).
Тебе Марк сегодня выходной дал?
Зря он это сделал, как только твоему ротовому отверсию и рукам отдых дали, так ты зразу
на форум гадить полез.
Мы уведомим твоего господина о твоем поведении!
а ты, у поцтеринга, на работе сегодня?
У, походу на федоре остались только совсем ушибленные индивиды.
>У убунтят пакетный менеджер нормальныйТы в исходники этого убожества хоть раз глядел? Там звиздец, нашпигованный багам по самые помидоры. А приоритеты для пакетов и репозиториев вообще в нерабочем состоянии.
>не требует на виртуалке 512 памяти вкатывать чисто для того чтобы пакетами оперировать
Память yum немногим больше, чем apt, ест. И чем больше количество оперируемых пакетов, тем разница меньше.
>И работает не в пример резвее этой вашей питонятины
Единственное, на что могла влиять скорость питона - это разрешение зависимостей, остальное - ввода-вывод, скорость которого от языка слабо зависит. и в dnf как раз для разрешения зависимостей заюзали внешнюю библиотеку satsolver.
> Ты в исходники этого убожества хоть раз глядел? Там звиздец, нашпигованный багам
> по самые помидоры.По сравнению с кривой редхатовской бидонятиной - оно даже не такое уж и страшное :). От редхатовского пакетного менеджера впечатление такое как будто его вообще индусы на коленке писали. Да еще манагер с кнутом стегал за продолб дедлайнов. Судя по тому как оно мерзостно работает.
> А приоритеты для пакетов и репозиториев вообще в нерабочем состоянии.
Это как? Вроде пининг пакетов вполне себе работает. Тем не менее, лично я не фанат управления системой в стиле "ВВП vs промышленность". Нафиг-нафиг ручное управление системой лишний раз.
> Память yum немногим больше, чем apt, ест. И чем больше количество оперируемых
> пакетов, тем разница меньше.Многим, многим. Апт не разу не околел даже на виртуалке с 64Мб памяти. А yum успешно загибается на виртуалке с 256 по ауту памяти. Ну в общем не врут про минимальные требования в 512, вполне честная оценка. Потому что иначе будет иногда ломаться пакетный манагер.
> как раз для разрешения зависимостей заюзали внешнюю библиотеку satsolver.
Кроме того, написание системных средств на питоне - это показатель того что делалось это по принципу "на отъ...сь".
> Это как? Вроде пининг пакетов вполне себе работает.Например с опцией APT:Get:AllowUnauthenticated, если, подпись у репозитория протухла, отсутствует или просто невалидна, кастомные пиннинги слетают и ставиться у тебя будут левые пакеты.
Я уже не упоминаю про общую долбанутость и неудобство использования механизма пиннингов.
Да и разработчики сами говорят, что механизм пиннингов проще полностью переписать, чем починить.
> Тем не менее, лично я не фанат управления системой в стиле "ВВП vs промышленность". Нафиг-нафиг ручное управление системой лишний раз.
Вот есть у тебя куча разных репозиториев с перекрывающимися множествами пакетов, то, фанат - не фанат, а без пиннингов никуда.
> Например с опцией APT:Get:AllowUnauthenticated, если, подпись у репозитория протухла,
> отсутствует или просто невалидна, кастомные пиннинги слетают и ставиться у тебя
> будут левые пакеты.Эту опцию вменяемые админы вообще не используют чуть менее чем никогда. Потому что при ее активации априори будут ставиться какие-то левые пакеты, подлинность которых неизвестна. Поскольку это откровенная установка самострела на своем же пути - так делают только отчаянные мазохисты. Логично что фич не слишком протестирован - желающих тестить на своей пятке этот самострел довольно мало.
> Я уже не упоминаю про общую долбанутость и неудобство использования механизма пиннингов.
Механизм как механизм. Этот механизм должен использоваться только в крайних случаях. А "аварийные" средства управления и оверрайда нужные раз в 10 лет и не обязаны быть сильно удобными. Удобны типовые операции, нужные ежедневно. А фичи нужные паре эстетов раз в 20 лет - уж как выйдет.
Если вы не поняли, заниматься сеансами ручного управления в работающей системе, особенно когда она в продакшне - бред чистой воды.
> Да и разработчики сами говорят, что механизм пиннингов проще полностью переписать,
> чем починить.Да и фиг с ним - любители сеансов ручного управления должны страдать, ибо если этот механизм нужен настолько часто чтобы его кривость вас вообще волновала - you're doing it wrong, Luke. Это такой совсем аварийный стоп-кран, когда стало туго и по другому вообще никак. Дергать этот механизм чисто для развлечения - идиoтизм.
> Вот есть у тебя куча разных репозиториев с перекрывающимися множествами пакетов, то,
> фанат - не фанат, а без пиннингов никуда.Если это именно ВАША репка - можно перекрыть другими методами. Если это чужая репка - по сути это некая неконсистентность репов, систему с такими настройками репов не следует использовать в продакшне. Почем зря куча капканов и грабель на ровном месте. Никто в здравом уме так "боевые" системы не админит.
> За один только этот пакетный менеджер они просто обязаны профукать почти весь рынок debian-based, работать с пакетным менеджером которых просто на порядок приятнее.За один только пакетный менеджер openSUSE просто обязан захватить весь рынок debian-based и прочих дистрибутивов, работать с zypper просто на порядок приятнее, чем с каким либо другим менеджером пакетов, из ныне существующих
:-)))
Мечты, мечты... но ведь zypper действительно лучший !
> Мечты, мечты... но ведь zypper действительно лучший !Насчет apt-get еще можно поспорить, но вот уродца yum'а он точно заруливает.
Гибрид ужа и ежа. Нормально переписать пакетный манагер их не хватило, подставили костылей своей мерзостной питонятине - "уф, починил - заклеил жевательной резинкой" (старинный комикс про починку водопровода предприимчивым персонажем).
А мне норм
Да надоели, пусть уже на апт заменят)
Заменить православные скрипты на мерзкие бинарники? Не дождетесь!
Эти скрипты на виртуалке с 256Мб валятся в oom killer. Знаете, когда пакетный манагер - самая жручая часть системы, это называется "хвост виляет собакой". Не, энтерпрайзники конечно богатые, еще серваков докупят. А я как-нибудь буду использовать deb-based, им даже 120Мб выше крыши, если то что внутри запущено не требует больше.
> Эти скрипты на виртуалке с 256Мб валятся в oom killer. Знаете, когда
> пакетный манагер - самая жручая часть системы, это называется "хвост виляет
> собакой". Не, энтерпрайзники конечно богатые, еще серваков докупят. А я как-нибудь
> буду использовать deb-based, им даже 120Мб выше крыши, если то что
> внутри запущено не требует больше.Ради звонкой монеты вы отторгаете все принципы UNIX-way?
Ведь ваш apt нельзя даже подправить без пересборки.
> Ради звонкой монеты вы отторгаете все принципы UNIX-way?Я просто достигаю моих целей. Чем это проще, быстрее и дешевле и меньше канифолит мозг - тем замечательнее моя жизнь.
> Ведь ваш apt нельзя даже подправить без пересборки.
А уж ядро - и подавно. Давайте по этому поводу перепишем ядро линукса на питоне. Упарываться - так по полной.
p.s. и часто вы в федоре yum переписываете, интересно, чтобы пересборка вызывала какие-то напряги?
> Ведь ваш systemd нельзя даже подправить без пересборки.В этом треде оба молодцы, конечно.
И ты, Сара, молодец!
DNF пользуюсь на F18, слежу за развитием. Система активно развивается. Скорость разрешения зависимостей приближена к световой. Теперь при 1G RAM с KDE своп при работе с пакетами не используется. Впечатления положительные. YUM действительно сильно раздражает своим тормозом.
> Теперь при 1G RAM с KDE своп при работе с пакетами не используется.1G RAM...
Лет 10 назад меня убеждали, что мне не нужен 1 гиг оперативки.
Спрашивали, зачем он мне, ведь 512 мб вполне хватает?
Теперь я знаю, зачем - чтобы не тормозил пакетный менеджер, очевидно же!
Ощущение что вы им работаете
> У убунтят пакетный менеджер нормальный, не требует на виртуалке 512 памяти вкатывать чисто для того чтобы пакетами оперироватьотлично работает на 256 Mb. ЧЯДНТ? И как часто на виртуалках приходится пользоваться yum?
Ты не относишься к группе криворуких приматов, служителей культа бубунды.
Ваш К.О.
> Ты не относишься к группе криворуких приматов,Действительно, ведь он относится к группе хомяков грызущих редхатовский кактус.
>> Ты не относишься к группе криворуких приматов,
> Действительно, ведь он относится к группе хомяков грызущих редхатовский кактус.я б подлил маслица с emerge/portupgrade... но и так хорошо горит :)
> я б подлил маслица с emerge/portupgrade... но и так хорошо горит :)Это в продакшне очень редкие камикадзи использовать рискуют :)
>к группе хомяков грызущих редхатовский кактус.Грызунов, мышей... Не хомяков! КрасноШляп -- это же Энтерпрайс.
аналогично, виртуалка с 128М памяти
> аналогично, виртуалка с 128М памятиНу да, если yum там не запускать - память не кончится. А если там все-таки запустить парочку сервисов, жрущих хотя-бы половину памяти [или вы виртуалку чисто под пакетный манагер пускаете?] и попробовать установить более-менее разлапистый пакет - будет редкостное ололо. Не то что на 128, даже на 256 бывает изредка. А, ну и конечно подразумевается что свопа немеряного размера там нет. Ибо на виртуалках от него один гемор.
у федоры месячник стремных названий, вслед за pidora теперь и DNF
любой спортивный болела вам скажет, что так в протоколах обозначается DNF=did not finish, вот же биатлон бег что угодно посмотрите, внизу таблицы с результатами
зато удобно набирать "dnf")
вот yum в самом деле удобно набирать. dnf хуже
> вот yum в самом деле удобно набирать. dnf хужеYum is not yummi, pssst!
dfn часто получается вместо dnf
"Как вы яхту назовёте, так она и поплывёт". Эта рискует не доплыть. :D
> у федоры месячник стремных названий, вслед за pidora теперь и DNFВообще, оно хорошо отражает суть. Пользоваться этой дрянью достаточно мерзопакостно.
>новый пакетный менеджер отличается заметным увеличением скорости работы, низким потреблением памяти, предоставлением API для плагинов и интеграции с другими приложениямиблондинки одобряют сие начинание
Какой смысл снова писать dnf на питоне?
Логично было бы сделать его на С, как и libsolv.
> Логично было бы сделать его на С, как и libsolv.Ну как, сэкономят кодерам пару дней времени. И потом просадят месяц на отладку своей рапидчины и борьбу с тормозами. Как обычно у питонистов, в общем.
Что угодно изобретут, лишь бы только не переходить на православный portage
> Что угодно изобретут, лишь бы только не переходить на православный portageда ты что... у них отсутствие компилятора в системе - элемент безопасности. какой тут портаж...
(осенённый мыслью убегает)
...надо им подсказать что sed/awk/perl/grep можно выковырнуть. ну чисто для секурности.
> ...надо им подсказать что sed/awk/perl/grep можно выковырнуть. ну чисто для секурности.ld-linux.so
> да ты что... у них отсутствие компилятора в системе - элемент безопасности.Элемент не элемент, а сборка ряда руткитов и подобной хреноты - реально сломается. Сервак работать должен а не фермой компиляции выступать.
> Элемент не элемент, а сборка ряда руткитов и подобной хреноты - реально сломается.естественно. это ж неподъёмная задача - притащить компилятор
> Сервак работать должен а не фермой компиляции выступать.
должен быть и фермой компиляции и заводом по трассировке. а вот чёрным ящиком - не должен быть.
На SSD разницы не замечал.