Дэниел Мах (Daniel Mach) из компании Red Hat сообщил о начале разработки пакетного менеджера DNF 5, в котором будет выполнен перенос реализованной на языке Python логики DNF в библиотеку libdnf, написанную на C++. Тестирование DNF 5 планируется начать в июне в процессе разработки Fedora 33, после чего в октябре 2020 года добавить в репозиторий Rawhide, а в феврале 2021 года заменить им DNF 4. Сопровождение ветки DNF 4 будет продолжено Red Hat...Подробнее: https://www.opennet.me/opennews/art.shtml?num=52494
Испытываешь странное чувство, когда даже и не переходил на PackageKit, а его уже закапывают и пишут новое. Прям как в вёбе.
Так те же люди пишут.
Автор yum вроде угодил на велосипеде под автотранспорт.
2013 год, как то давно уже.
Алилуя, через цать лет доползло что картонный макет пакетного менеджера - не рулит. После того как даже фрибзда сделала какое-то подобие нормального этсамого... А у этих - бизнеслогика, клять, в пакетном менеджере.
> Испытываешь странное чувство, когда даже и не переходил на PackageKit, а его
> уже закапывают и пишут новое.Еще страннее - месяц назад некоторые местные слюной брызгали, доказывая очередное превосходство пингвинчика
> Благодаря packagekit, гномовские/кдешные/whatever инструменты работы с софтом (установка, обновление) одинаково работают на всех мейнстримовых дистрах.а тут вон оказывается что то ли его уже много лет никто не развивает, то ли у шапки дистры маргинальные :-S
>> уже закапывают и пишут новое.
>Еще страннее - месяц назад некоторые местные слюной брызгали, доказывая очередное превосходство пингвинчикаЛетели 2 кирпича, один красный, а другой - налево...
Ну, как бы, проект, который допиливают, не может претендовать на превосходство.
Превосходно лишь то, что не трогают десятилетиями, ведь отсутствие необходимости в изменениях означает полное совершенство! (Нет, оно не может быть обусловлено тем, что на проект все просто забили, скажете тоже.)
[/sarcasm]
Если софт перестают допиливать и он сложнее хелловорлда - этот софт, очевидно, сдох.
PackageKit - это один из инфраструктурных проектов редхата. Он не для пользователей. Он для того чтобы предоставить и стандартизировать API. Каким раньше был их же hal, ConsoleKit и другие вещи вроде PAM.Такие проекты никто кроме красношапки не развивает никогда, потому что среднестатистический дистрибутив линукса не способен на бОльшую инновацию чем система инициализации и собственный пакетный менеджер и то не все. Причина банальна - ресурсов нет. Вместо разработки инфраструктурных решений для ОС разработчики в основном пакуют пакеты и обслуживают совместимость и надёжность программного обеспечения. Спасибо им за это, безусловно, это важно, но не хватает единых API. Чем больше стандартизации тем меньше манипуляций нужно совершить с апстримным тарболом для поставки его в дистрибутив. НО! Чем больше стандартизации, тем меньше разнообразия (diversity если хотите) и тем больше дистрибутивы становятся похожи друг на друга. Особенно те из них которые предоставляют systemd как единственную опцию. Если из того же арча выкинуть пакман и всунуть рпм, то с некоторыми манипуляциями его можно будет уже анакондой ставить как и все редхатовские продукты. Это не хорошо и не плохо. Просто факт.
Ну вот настала очередь PackageKit, который перепишут как сервис dbus. И вот тут меня терзают смутные сомнения... Если вы писали что-то под dbus... эту штуку надо переделывать. Может не протокол, но реализацию точно переосмыслить. Оно работает, но... и этих "но" там много. Главное - производительность.
В целом, не имеет значения что случится с PackageKit, потому что никто вообще на это не повлияет.
1. Gentoo/Devuan и аналогичные оставят его в той форме в которой он есть, взяв поддержку на себя.
2. Systemd-дистрибутивы применят новое.
3. На форумах устроят бурю в стакане 1 vs 2.> Еще страннее - месяц назад некоторые местные слюной брызгали, доказывая очередное превосходство пингвинчика
Оставьте религию верующим. У "пингвинчика" есть одна единственная красная шапочка, которая хоть как-то заботится о нём как об ОС (серверной и для рабочих станций). И есть тысяча и один шизоид из "сообщества" рассуждающий о свободе и выборе под действием секты FSF, которая занимается политикой а не разработкой ПО. Причем часть тех шизоидов, которые всё же способны собрать пакет под свой велосипед, еще рассуждают об инфраструктурных инновациях, критикуют, будто видели в жизни поставленную перед собой задачу такого масштаба и, что характерно, реальную альтернативу собственного изготовления имеющемуся инфраструктурному решению от красной шапки предложить не могут. Только компоновать код из их же форков, которые любезно доступны под свободной лицензией, только GPL, только хардкор.
Мы уже поняли что вас красношапка покусала, но зачем всем об этом рассказывать?
То что шапка пилит что бы диктовать всем стандарты какие она хочет вам видимо не очевидно.
Потому что если она может диктовать всем, то менеджер может приходить к потенциальному заказчику и бить в грудь что мы самые передовые и денежки нести нужно нам.
При чем тут покусала. Пока что я вижу по нику что вас Gentoo покусала. Покажите мне конкурирующие стандарты. Есть LSB, есть systemd и всё от красной шапки. Другие системные стандарты и API, конкурирующие с этими мне покажите.> То что шапка пилит что бы диктовать всем стандарты какие она хочет вам видимо не очевидно...
Вы живёте в плену иллюзий. Стандарт на ряд системных компонентов один и он от красной шапки и никто палец о палец не ударил чтобы придумать другой и согласовать. В случае с systemd там еще хуже, там один недописанный стандарт и одна единственная реализация, потому что никто палец о палец не ударил, чтобы подготовить совместимое решение. Все сидят пакеты пакуют и сорцы в тарболы перезаворачивают разглагольствуя о том следовать им стандарту или объявить протест. Взять готовую реализацию или объявить протест. Чтобы что-то предлагать нужно что-то делать, а тут одни скандалы в пользу бедных.
Та же самая Gentoo ничего не разработала и не стандартизировала вне своей экосистемы. Люди в основном собирают и следят чтобы всё собиралось. За этим потребовался подёргать форками udev -> eudev systemd-logind -> elogind. Это не инновация, не ифраструктура и не стандарт. Это у нас у тарбола зависимость и оно не собирается без либы, которую мы по дефолту поставлять не хотим. Решение - форкнуть. Но не просто так форкнуть, а форкнуть кусками, чтобы даже в базовой либе предоставлялось не всё API, а только то что нужно внутри Gentoo. Сделай так проприетарная контора сразу бы про ЕЕЕ вспомнили...
И менеджеры если уж ходят рассказывать о том какие они передовые, то показывают хоть какие-то результаты работы. А про негативный подход "ой мне всё диктуют и навязывают, я не буду ничего своего делать, прикинусь жертвой корпорации, чьи продукты я форкаю" - такой подход только в леворадикальных организациях типа FSF в почёте.
Короче, вместо нытья о страшных заговорах корпораций, предлагаю сперва добиться и сделать лучше, но не троллинга ради, а чтобы были альтернативы хотя бы в реализациях, не то что в стандартах. А то когда кучка перешедших на systemd дистрибутивов будет принимать Linux Standart Base 6.0 вам кроме шизоидного бреда про диктовку стандартов, менеджеров, денежки и "не хочу systemd потому что не нравится" и сказать будет нечего.
>Другие системные стандарты и API, конкурирующие с этими мне покажитеНу если уж systemG стандарт, то openrc, upstart, SystemV-init
>никто палец о палец не ударил чтобы придумать другой и согласоватьИх много, вы не вкурсе в силу узости кругозора, а про согласовать, просто никто ногами свои варианты в другие дистрибутивы не пропихивает, в отличии от...
>Gentoo ничего не разработала и не стандартизировала вне своей экосистемыМда, а с виду адекватны, вам кто-то запрещает использовать portage или openrc?
>Но не просто так форкнуть, а форкнуть кускамиА вот и подтверждение, что у индивидуума не психологические проблемы, а повреждение мозга на физическом уровне, может форкали кусками потому, что от монолита systemG невозможно оторвать отдельные компоненты?
>предлагаю сперва добиться и сделать лучшеТак уже, те же связки openrc, runit/monit по удобству эксплуатации превосходят комбайн systemG, но они не модные/молодежные, и денег на них не заработаешь.
>сказать будет нечегоДля вас, фанатиков systemG, аргументы приводили десятками, но вы их упорно игнорируете, поэтому адекватные люди с вами давно не ведут полемики, любитель systemG с аппеляцией к скорости, современности, надежности, безопасности или наглядности = клинический идиот.
> Ну если уж systemG стандарт, то openrc, upstart, SystemV-init
> Их много, вы не вкурсе в силу узости кругозора, а про согласовать, просто никто ногами свои варианты в другие дистрибутивы не пропихивает, в отличии от...Это не стандарты и API, а системы инициализации с сервисной моделью разной степенью успешности. Красная шапка формирует системные API такие как HAL (переделали на systemd-udev), ConsoleKit (systemd-logind) PackageKit (переделают как сервис dbus) и PAM и очень много чего еще. Единственное что имеет серьёзную альтернативу - это их SELinux, который нравится далеко не всем меинтейнерам ввиду технической сложности сопровождения targeted-policy и можно использовать AppArmor и другие.
Я не спорю тут про системы инициализации не о них речь идёт, скандалы вокруг systemd в соседней теме. И вот это вот точно неадекватное поведение:
> А вот и подтверждение, что у индивидуума не психологические проблемы, а повреждение мозга на физическом уровне, может форкали кусками потому, что от монолита systemG невозможно оторвать отдельные компоненты?
> Так уже, те же связки openrc, runit/monit по удобству эксплуатации превосходят комбайн systemG, но они не модные/молодежные, и денег на них не заработаешь.
> Для вас, фанатиков systemG, аргументы приводили десятками, но вы их упорно игнорируете, поэтому адекватные люди с вами давно не ведут полемики, любитель systemG с аппеляцией к скорости, современности, надежности, безопасности или наглядности = клинический идиот.Заканчивайте гадания на кофейной гуще. Меня не интересуют ни скорость (особенно в сравнении с инициализацией дисков это смешно), ни современность (мне не нравится смузи), ни безопасности системы инициализации (это вне зоны её ответственности она тут сама под управлением), ни надёжности...
Не ошибается тот, кто ничего не делает, собственно, поэтому в вопросах системных API ни один дистрибутив не может ошибиться, потому что нету ничего. Как я и писал раньше сделать свою систему инициализации, сделать пакетный менеджер и собрать пакеты в дистрибутив - это предел по ресурсам.RedHat делал продукты для себя и любезно предоставлял их под GPL, также как и Торвальдс поставляет Linux под GPL таково решение автора. Решение остановить поддержку старых решений и переписать их все в кучу в виде одного нового - это тоже решение автора. То что люди переходят с их старых продуктов на их новые продукты меня не удивляет, видимо нравится, видимо чем-то хороши и удобны. А то что у gentoo получилось или не получилось оторвать часть модулей - это как отодрать часть модулей от ядра линукс и потом жаловаться, что они не работают без самого ядра дескать оно монолитное... как будто в этом есть что-то плохое.
> Мда, а с виду адекватны, вам кто-то запрещает использовать portage или openrc?
Мне как системному администратору глубоко начхать, какая у меня система инициализации. Я их знаю абсолютно все и писал и скрипты и юниты. Главное тут задача, которую нужно решить.
Как пользователю мне вообще не важно какая у меня система инициализации.
Система инициализации и пакетный менеджер - это дистрообразующие подсистемы. "вам кто-то запрещает использовать portage или openrc" означает "вам кто-то запрещает использовать Gentoo". Да, иногда запрещает, корпоративный стандарт, например может запрещать, или здравый смысл. Source based дистрибутив с BSD-образными портами в проде или даже дома нужно аргументировать хоть как-то кроме "люблю куплю и полетим".
Как разработчику корпоративного ПО под линукс мне всё равно какая там в дистрибутиве система инициализации. Дайте SDK, API и документацию с примерами. Но чем меньше телодвижений и мыследеятельности (истинная причина популярности systemd) тем лучше.Вот вы всё про деньги в чужих карманах разглагольствуете... а знаете ли вы что средний разработчик корпоративного ПО обходится дороже чем любой средний никс-администратор. Так вот, если у админа работы становится больше, а у девелопера меньше, то ваш работодатель получает прибыль путём экономии на дорогом труде. Ненависть к админам и продажа платной или даже франчайзинговой техподдержки вместо содержания своего админа это старая как мир бизнес модель. 1С, МС, Редхат, тысячи их, все на ней. Если вам это не нравится, рекомендую ехать в экспедицию на Марс.
>Такие проекты никто кроме красношапки не развивает никогда, потому что среднестатистический дистрибутив линукса не способен на бОльшую инновацию чем нескучные обои.Поправил, не благодари.
> Такие проекты никто кроме красношапки не развивает никогда, потому что среднестатистический дистрибутив линукса не способен на бОльшую инновацию чем система инициализации и собственный пакетный менеджер и то не все. Причина банальна - ресурсов нет. Вместо разработки инфраструктурных решений для ОС разработчики в основном пакуют пакеты и обслуживают совместимость и надёжность программного обеспечения. Спасибо им за это, безусловно, это важно, но не хватает единых API.Окститесь, вы пытаетесь донести это до фaнбоя BSD!
У них неприятие единых кросс-системных стандартов чуть ли не биологическое.
а в чем проблема? превосходства пингвинчика никуда не делись
ну вот так получилось что они теперь одинаково работают на любом дистрибутиве и без ппакажкита..
> Прям как в вёбеТроцкисты. Зато все заняты и не ленинизмят )
Подход, конечно, своеобразный, но yum/dnf+rpm самая адекватная связка для бинарного дистрибутива, а а с dnf еще и не особо тормозящая, так что от переписывания на плюсы есть шансы, что хуже не станет
> yum/dnf+rpm самая адекватная связка для бинарного дистрибутиваэто ещё почему? zypper пользовались? (лучшие части dnf как раз из него взяты)
-- Грузины лучше, чем армяне.
-- Чем?
-- Чем армяне.Уровень аргументации медианного комменатора опеньнета.
> лучшие части dnf как раз из него взятыА не лучших, но тем не менее полезных там не хватает. Например, банальное действие по выкачиванию пакетов (в т.ч. src.rpm) превращается в пляску с весьма странными второстепенными флагами, правами рута и доставанием загруженного из /var/cache. И другие вроде мелкие, но тем не менее бросающиеся в глаза при долгом использовании косяки.
По мне он довольно неплох, но CLI у dnf куда логичнее, удобнее и полнее
Чем это лучше pacman?
Чем это лучше guix?
> Чем это лучше guix?Чем это лучше MSI?
> Чем это лучше MSI?ERROR: your package is not supported. Please use the correct package format!
Что MSI - это дичайший гибрид СУБД и "логики инсталляторов". Всемогутер, который проще выкинуть, чем понять.Инсталлятор - это unzip + пара манипуляций с системой. Всё остальное - понты.
ну гуикс, все же, немного о другом. Там же совсем "принципиально новый" способ организации пакетов
попробуйте zypper и не надо будет изобретать велосипед dnf.
Я еще понимал использование yum, который брал начало примерно из тех же лет, но был свой.
Но вот вместо перехода на лучшее решение начать пилить очередное свое, а потом его перепиливать.
У RHEL последнее время подход использовать только свои решения не глядя вокруг. Еще и навязывая эти решения остальным. Но это не значит что решения лучшие.
"(...) Где и как мне лучше купить надежный и красивый цуникримпель?На что дорогие товарищи отвечают ему обычно следующее:
1. На кой тебе вообще сдался цуникримпель? Купи две крымзы. Стоит столько же, а объем побольше. Две крымзы делают все то же, что и один цуникримпель, только не свистят."
DNF работает на том же движке, что и Zypper, и под капотом у обоих RPM. В качестве фронтэнда мне больше нравится Zypper – он удобнее, у него приятнее синтаксис и больше фич (но есть несколько мелких багов), но его почему-то не взяли. Всегда интересовал вопрос "почему?", и только что возникла догадка – как раз для того, чтобы переход yum -> dnf осуществлялся почти без изменений (команды, ключи), т.е. можно было сделать yum алиасом dnf'а.
> DNF работает на том же движке, что и Zypper, и под капотом у обоих RPM.Это самый прекрасный бред, который я читал в 2020-м, спасибо!
libsolv не тот же?
> libsolv не тот же?Не знаю, я отвечал про «под капотом у них rpm».
dnf лучше zypper примерно в тех местах, что и yum лучше zypper: более удобный, логичный и дееспособный CLI
> dnf лучше zypper примерно в тех местах, что и yum лучше zypper:
> более удобный, логичный и дееспособный CLIОсобенно дееспособно он реагирует на аут памяти в процессе апдейта пакета, так что потом кишки не соберешь. О том чтобы дееспособный крап себя починил или хотя-бы подсказал how to - речь, разумеется, не идет.
> попробуйте zypper и не надо будет изобретать велосипед dnf.А zypper может выгрузить лог транзакций и проиграть их на другом сервере? А показать историю изменений по пакету?
> C++Странный выбор.
У них половина кода уже на C++, видимо, разгонять или переучивать команду на более адекватный нативный язык, а потом еще и весь код переписывать, слишком невыгодно
> переучивать команду на более адекватный нативный языкЭто на какой? Хруст, может?
да уж сразу на JS :-D
JS... вообще-то уже есть polkit
ну там же нет любителей смузи, пока ещё
Ну так на православном Си и писали бы..
+1. Шёл 2020-ый год, мыши продолжали шаблонить бабушку, несмотря на то, что прямо перед носом развивается Ди.
DNF будет такой же тормозной как в Федоре?
В каком месте он тормозит?
> В каком месте он тормозит?В операционке. Достаточно посмотреть разок на какой-нить apt... :)
https://www.opennet.me/opennews/art.shtml?num=52494#40
#40 и #41
python не тормозит (R)
пользуюсь dnf на домашнем ноуте, проблем не замечал. вы когда-нибудь накатывали сервис пак на десяточку или мак?
Ну и где ты в десятке сервиспаки видел?
> Ну и где ты в десятке сервиспаки видел?ну вы же понимаете, что я имел в виду, установка обновлений у десяточки очень сложная, долгая и непредсказуемая штука. Если вы разработчик - то у вас может дотнет в понедельник отвалиться, к примеру.
Забавно, что если у вас ноутбук, то он всю подковёрную деятельность десятки выдаёт шумом вентилятора.
Вот блокирую я экран, отхожу на 5 минут, а ноут начинает гудеть как ошпаренный. Это проснулась мафия
> перенос реализованной на языке Python логики DNF в библиотеку libdnf, написанную на C++Судьба-судьбинушка всех проектов, написанных на пихоне.
> Судьба-судьбинушка всех проектов, написанных на пихоне
> ... всех проектов ...
> ... всех ...ну как всех, 0,05% от всех может быть...
Ок, всех полезных проектов.
как, обоих?!
Полютос Что-то не особо спасло переписывание на плюсы. Он даже не стал быстрее работать. В чём смысл переписывания?
No python dependency.(задолбались мы менять по всем скриптам /usr/bin/python на /usr/bin/python3, а эти ненормальные того гляди - предложат менять на python4.2.1.0.0.22 в следующей версии)
Ну это говорит только о качестве скриптов и их авторов. Самая боль для меня была поддерживать 2 на венде (не cygwin, msvc пакет с компилятором для питона только у 2 был) и 3 на линуксе, в 1 кодовой базе. Мне кажется это проблема дистрибутива, просто дефолтный уже давно должен быть 3.
а причем тут "качество скриптов"?
Разработчики пихон заявили (и выпустили какой-то там PEP-2342425234534652 ) что пихон не должен ни в коем случае называться пихон, а обязан называться python3 - всем срочно переделывать свои скрипты. а не то.
Причем я уже раза три видел в разных проектах пулреквесты с подобными правками. Особенно здорово - в совместимых.> Мне кажется это проблема дистрибутива
нет, это проблема пихона. Его реально пишут совсем поехавшие.
Весь смысл этого их выступления - намеренно сломать совместимость с python2 даже для тех программ, где ее героическим усилием сохранили. Никакого "дефолтного3" и возможности выбирать дефолтный - обязан быть гвоздем прибит в скрипте именно 3.
Можно понять желание редbm дистанционироваться от этих придурков любой ценой.
Потому что завтра они так же впихнут всем четвертый.
Так они видимо научились на своих ошибках. 2 объективно надо было дропать сразу, продакшен бы подорвался и в темпе решил все проблемы. С python3 наверно подготавливают почву для python4, чтобы избавиться от всего этого крапа, через который пришлось проходить с 2 и 3. А что они сломали там в плане совместимости? Вроде же пишешь для 3.2, и работает "без изменений" в 2.6+ и любых версиях 3, нет? Пусть хуже и медленней, да и код выглядит не очень, но работает же. Если пишешь для 3, просто берёшь версию старше той, для которой написано. В 4 собирались сломать совместимость, я надеюсь им хватит ума не повторить историю с 3. Но это ещё не скоро.
Вот редхат подорвался и решил проблему - нет пихона, нет проблемы.Полагаю, уважающий себя продакшн будет эти проблемы решать точно так же. А останется только наколенное одноразовое творчество васянов, ну и то, у чего уже просто не хватит ресурсов на переписывание на чем-то адекватном.
> Вроде же пишешь для 3.2, и работает "без изменений" в 2.6+ и любых версиях 3, нет?
нет. После 3.5 уже много чего не работает.
Некоторые подробности излагали авторы hg. b'string' vs 'string' особенно им доставила.Надысь вон выяснилось, что пихон отменил 'None' - теперь нельзя его использовать в сортируемых списках.
>авторы hgНужность hg ещё под большим вопросом. Какие ещё 'string'? Они ламеры, не иначе. Эти тоже зачем-то поддерживали 2?
> нет. После 3.5 уже много чего не работает.Да там каждый минорный :D релиз ведет к эпопее. Так что единственное для чего оно годится - для наколенщины выданой на гора в режиме fire and forget.
Нет, всё-таки это нифига не нормально, когда делают А, через 5 лет А выкидывают и пилят В, чтобы ещё через 3 года выкинуть В в пользу С.
Работать на ведро вполне нормально для opensource.
Ну так всё зависит от архитектора! Влезает в FOSS какой-то прыщедрот, вчера освоивший пестон по трём веб страничкам и поехали кошмакодить! Хотя казалось бы, таких на пушечный выстрел нельзя подпускать даже для "улучшения" софта. Отсюда и позорное качество большинства поделий.
Серьезно? На 7 год индеец Быстрый Как Ветер заметил, что тормознее dnf только портаж, который компилирует пакеты и неплохо бы переписать этот кусок говна на нормальном языке? Невероятная скорость реакции! Энтерпрайз!
DNF уже давно стал быстрым:https://www.opennet.me/opennews/art.shtml?num=47471
> 30.10.2017 20:35
> По сравнению с YUM 3 в YUM 4 наблюдается существенный прирост производительности, особенно приразрешении зависимостей
И это реально стало заметно. Говорю как тот кто был вынужден пользоваться на работе федорой с 20 по 28.
На путаницу имени yum/dnf можно не обращать внимания, Red Hat меняет его туда-сюда.
Если не понятно: да, он жутко тормозил. А потом с очередным апгрейдом дистрибутива вдруг стал заметно живее даже на HDD. Самая медленная часть – обновление инфы о пакетах с репозиториев. Разрешение зависимостей в повседневных задачах почти моментальное, установка ничем не медленнее Zypper или APT.
Мне кажется очень странным, что я прошу установить пакет, а он "обновляет инфу о пакетах с репозиториев". Я его просил? Я очень ценю свою время, и не люблю когда его так бесполезно растрачивают.
К сожалению, zypper грешит тем же, более того – даже если он не обновляет информацию о пакетах, он всё равно связывается с репозиториями по неясной причине. У pacman, apt, portage и многих других ПМ такой херни нет.
>Мне кажется очень странным, что я прошу установить пакет, а он "обновляет инфу о пакетах с репозиториев".Если Вы просите установить локальный пакет, без сторонних зависимостей, то он этого и не делает. А в противном случае ему надо узнать откуда брать пакеты. И это нормально. А периодичность опроса - дело настраиваемое.
P.S. Другое дело скажем Мавен. Сначала выкачяать метадату с репозиториев. Потом разложить ее по кучи мест. А затем начать выкачивать все пакеты из всех серверов. После чего свалиться по фатальной ошибке, что "связи с левым сервером нет, но версия пакета уже есть в кеше Мавена". Вот это я понимаю подход к пакетному менеджеру. :(
Да вот я вынужденно сейчас пользуюсь yum/dnf после привычного apt. И каждый раз, когда пользуюсь пакетным менеджером, офигиваю насколько всё медленно (всё никак не привыкну). Ну и неудобно, конечно же, но это уже субъективно.
>тормознее dnf только портаж, который компилирует пакетыЗато у нас в процессе буковки с циферками красивше по экрану бегают. И ЧСВ растёт на порядки. Шестнадцатеричные.
C++ будет одинаково работать на всех платформах? Теперь оно ещё и к железу привязано будет?
kokokokoй ужос! Вы еще сейчас и обос.етесь, когда узнаете что у вас ядро линукса - вообще на си написано - оно еще и к железу привязано, представляете?!
"из компании Red Hat" - и аж скулы сводит! Вспоминаешь ту же OpenSUSE: чем она была раньше, и чем она стала теперь.
Труп смердящий еси.Да и была им же. Уже много-много лет.
«Мы решили заменить старый велосипед новым более современным велосипедом»
И здесь уродский дбус.
Что еще упоротый бот считает ненлрмативной лексткой. В этот раз это сдово бастардский, в русском переводе.
не уродский, а редхэтовский.
"наша корова, и мы ее доим".
А тут DBus или DBus Broker?
Странные там ребята сидят. Пишется за час с лишнем на Golang.
А тут годами что-то разарбатывают на Python и C++.
Короче странные ребята.
> Странные там ребята сидят. Пишется за час с лишнем на Golang.
> А тут годами что-то разарбатывают на Python и C++.подозреваю, дело в корпоративной культуре: напишут за час - получат зарплату за час и будут уволены как бездельники, а так - годами зряплату получать...
Звучит на правду
ДА!
у голанга версии максимум два года поддерживаются, нет LTS веток
> ...в котором будет выполнен перенос реализованной на языке Python логики DNF в библиотеку libdnf, написанную на C++.С этого и нужно было начинать!
Тогда бы и переносить не нужно было.
Надеюсь, продвигатели flatpak обломаются в своих попытках навязать свои контейнеры всем, а графические "магазины приложений" продолжат уметь ставить нормальные пакеты через packagekit.
О, как же блять это ненужно! Ты ж понимаешь, только сорцы и только сборка под конкретную платформу. Эт откуда вас столько выползло? Реально интересно.
а откуда все дистры то выплыли? все было так же раньше как примерно в слаке( не путать со словом через "р")). а потом.... мне рассказывать как появились рпм и деб пакеты и их системы установки?. короче даж в википедии быть должно почитай. а сборка прог с флагами под каждую платформу на каждом компе не многим реально то и нужна, хотя да выигрыш порой может и до 10% быть. а днф не пробовал ни разу. как слез в свое время на мандриву так про федорку и забыл. а нет помнится какой же там выпуск был, кажется 14 федорки в лайве гонял.
10% чего? 10% безопасности, 10% меньше heartbleed, или чего? Тот же интеловский компилятор продуцировал в полтора более быстрый код даже на всяких кодировщиках.
> О, как же блять это ненужно! Ты ж понимаешь, только сорцы и
> только сборка под конкретную платформу. Эт откуда вас столько выползло? Реально
> интересно.Я не писал, что контейнеры не нужны. Написал, что их навязывают. Если они вам нужны, то пользуйтесь ими, можете еще во flathub попытаться навести порядок, говорят (не проверял), что там бардак из-за низкой квалификации большинства мейнтейнеров новых модных контейнеров.
не, не обломаются.Эпоха _совсем_ дерьмовых программ, неспособных работать в сантиметре от той помойки, за которой сидел их разработчик - давно настала.
Единственный способ сделать их хоть полу-работающими - очень тщательно завернуть в дерьмоконтейнер вместе со всем мусором, валяющимся вокруг.Попутно это же решает проблему обмазывания свежайшим, так любимого что дЭффективными менеджерами, что обезьянками. Поскольку затолкать новую версию программы в дистрибутив - весьма вероятно означает поапгрейдить его половину (потому что нужны еще недописанные версии библиотек, а с ними, в свою очередь, несовместимы прочие программы, и их тоже надо менять на новейщие еще дымятся)
Поэтому остается только другой вариант - затолкать весь дистрибутив в программу.
Новый стандарт же ж, жрите, не обляпайтесь.
честно говоря все это ничем не отличается от статической линковки обмазаной новым слоем)) история по спирали?
отличается. Не говоря уже о том что статическая сборка в gcc поломана двадцать лет как.Это копия (частей) _системы_, а не только конкретные версии динамических библиотек.
Внутри, внезапно, могут быть не только бинарники, но и какая-нибудь js-пакость.Причем вперемешку.
Причем при внимательном изучении окажется, что половина не используется и не нужна, но автор об этом не знал. (реальный недавнешний случай, правда, с докером)
ну как факт переизобретают тоже. в свое время от статики стали уходить именно по причине уменьшения размера окончательного пакета и меньшему потреблению оперативной памяти при использовании разделяемых библиотек. так они опять за свое , только в еще более худшем варианте. так они линукс в винду помоечную превратят в 2 счета.
> Эпоха _совсем_ дерьмовых программ, неспособных работать в сантиметре от той помойки, за которой сидел их разработчик - давно настала.В энтерпрайзе, может, и настала, в опенсорсе пока нет таких проблем в больших масштабах. И не будет, пока жива распространена традиционная система нормального опакечивания.
это пока она есть. пока писателям всяким не станет удобно не париться сборкой под конкретную платформу, а выложить готовый пакет без исходников. кстати сменив при этом лицензию. или корпорациям заворачивать свои дрова с зондами вообще без возможности просмотра исходников. и получаем вуаля винукс в перспективе. а ведь все больше народа тащет проги в во всех этих контейнерных форматах.
> Надеюсь, продвигатели flatpak обломаются в своих попытках навязать свои контейнеры всемЕсли не можешь обеспечить поддержку Flatpack в ROSA, пожелай донору смерти.
>> Надеюсь, продвигатели flatpak обломаются в своих попытках навязать свои контейнеры всем
> Если не можешь обеспечить поддержку Flatpack в ROSA, пожелай донору смерти.Не переживай, будет в ней flatpak и GUI для него, а вот где ты увидел "пожелания смерти", интересно.
>>> Надеюсь, продвигатели flatpak обломаются
> Не переживай, будет в ней flatpakТы теперь сам продвигатель flatpak. Пусть сбудутся твои надежды.
>>>> Надеюсь, продвигатели flatpak обломаются
>> Не переживай, будет в ней flatpak
> Ты теперь сам продвигатель flatpak. Пусть сбудутся твои надежды.Я лишь пытаюсь дать пользователям возможность пользоваться flatpak, если они хотят его или он им нужен. Да, это немного его продвигает. Но не навязывает. И в отличие от сабжа я не пытаюсь вынудить кого-то отказаться от традиционных пакетов в пользу контейнеров.
> а нас то за шо?за то.
>Hawkey Python API будет удалён и заменён на libdnf Python API.Сначала удалят, а потом через 10 месяцев добавят?
> Сначала удалят, а потом через 10 месяцев добавят?Я бы на их месте вообще питон дропнул из системы. Это столько человекочасов бы всему глобусу сэкономило...
dnf настолько тормоз, что даже представить себе не мог
был опыт с apt, pacman, xbps, может разница по скорости где и была, но внимание на то не обращал - работать нигде это не мешало
то ли дело dnf, запускаешь банальную команду а-ля search и сразу переключаешься на какие-то другие дела, дожидаться исполнения у меня лично терпения не хватает, особенно при первом запуске, когда сначала оно просто тупит, потом неторопливо посинхронизируется с серверами, потом опять потупит, ну его, в общем