Бен Коттон (Ben Cotton), занимающий в компании Red Hat должность Fedora Program Manager, объявил о намерении перевести Fedora Linux по умолчанию на пакетный менеджер DNF5. В Fedora Linux 39 планируется заменить пакеты dnf, libdnf и dnf-cutomatic на инструментарий DNF5 и новую библиотеку libdnf5. Предложение пока не рассмотрено комитетом FESCo (Fedora Engineering Steering Committee), отвечающим за техническую часть разработки дистрибутива Fedora...Подробнее: https://www.opennet.me/opennews/art.shtml?num=57757
пакетники — это не то место, где важна скорость выполнения кода, важна лишь скорость интернета
Спорное утверждение. Когда есть тысячи мелких пакетов для которых нужно произвести некие вычисления - то скорость инета уже не важна, в отличие от скорости вычислений. Это не firefox или хром какой-то тянуть.
Вот как раз для таких задач питон отлично подходит - он отлично справляется с io-bound задачами. Это если надо потом распаковать/скомпилить что-то лучше использовать нативно скомпиленные тулы на плюсах или сишные расширения.ну или на расте тоже можно расширение написать.
Сорян, промазал - хотел ответить на комент выше
Синдром утенка засчитан. Все что тот кусок бидона реально умел - жрать в разы больше оперативы чем другие пакетники, особенно на разлапистых пакетах с 100500 зависимостями, да разваливаться разнеся к чертям свою базу. Так что потом ни вперед, ни назад без каких-то сильно отдельных танцев с бубном. Вот честно, такому коду и таким кодерам место на помойке истории. И вот до редгада дошло что раз в цать лет можно пакетник и не через зад сделать. Офигесть!
>питон отлично подходит - он отлично справляется с io-bound задачамитеоретики... когда догоните по скорости pacman и xbps, тогда и квакали б про быстрый питон...
кстати, оно ещё и память жрёт, помню чуть ли не 10 лет назад делал виртуалку-почтовик с 192МБ, постфиксу было по уши, а систему обновить - хрен.
>>питон отлично подходит - он отлично справляется с io-bound задачами
> теоретики... когда догоните по скорости pacman и xbps, тогда и квакали б
> про быстрый питон...А давайте будем честны, вам пакман это не куцый обрубок по функционалу, относительно пакетных менеджеров взрослых дистрибутивов. Он по сути только устанавливалка и сносилка пакетов, +/-.
Не в оправдание слоупочности федоркиного менеджера, справедливости для.
>>>питон отлично подходит - он отлично справляется с io-bound задачами
>> теоретики... когда догоните по скорости pacman и xbps, тогда и квакали б
>> про быстрый питон...
> А давайте будем честны, ваш* пакман это *куцый обрубок по функционалу,
Давайте будем честны: дебиан можно втулить на виртуалку с вчетверо меньшим объемом оперативки чем фидору. И его пакетный менеджер никому сливать по функциональности не собирался. Разве что наиболее чокнутую оверинженерию типа потуг роллбэка в стиле MSI инсталлера не сделали, но вот это вот - намного лучше снапшотами реализуется. Виртуалки, или FS, один фиг, пойнт в том что там вообще system-wide консистентность достигается без особых усилий.И да, ну охренеть просто - не прошло и 30 лет как редхат заметил что пакетник являющий собой картонный макет, оказывается, жестко с@ет.
>Он по сути только устанавливалка и сносилка пакетов, +/-.удивительно, но мне последние 20 лет только это и надо от ПАКЕТНОГО МЕНЕДЖЕРА ) ставить, удалять и обновлять пакеты.
Зависимости сам резалвишь, умник? Транзакции тоже ручками, да? Или баш-портянками, гений?
А что, pacman не умеет в зависимости?
Не хами человеку, е*лан, лучше дай чёткие примеры.
>Вот как раз для таких задач питон отлично подходит - он отлично справляется
> с io-bound задачами.1) IO нынче стал быстрый, так то. На SSD стать io bound еще суметь надо. И это уж точно не про пихон.
2) Просто для понимания, Debian может на 64 мегах RAM ставить пакеты без свопа. Пихонятина делает лапки кверху даже на 256.А вас не смущает что виртуалкам нацеленным на изоляцию сервисов в результате приходится выкраивать в РАЗЫ больше оперативки, не потому что сервису надо, а потому что иначе пакетник умрет по OOM, да еще попутно базу себе убьет, обделавшись с брызгами. Ну а в результате при большой числе VM эта дрянь стоит весьма измеримых денег даже в энтерпрайзе.
1) ожидание работы с сетью несоизмеримо больше чем работа с диском. Поэтому нет разницы на каком языке ты ждёшь
Да, питон мягко говоря жирный по памяти. Но надо понимать что он даёт взамен - гибкость, простоту разработки, поддерживаемый код и армию оперсорц разрабов.
> 1) ожидание работы с сетью несоизмеримо больше чем работа с диском.Сеть как и диски бывают ОЧЕНЬ разные. Как конкретный пример, вгрузка пакетов с локального кеширующего прокси по скоростной LAN или виртуальному LAN на виртуалку занимает времени лишь чуть более чем нифига.
> Поэтому нет разницы на каком языке ты ждёшь
Или не ждешь, IO нынче стал быстрый, чему пруфом жесткая оптимизация линукскернела на тему оверхеда.
> Да, питон мягко говоря жирный по памяти. Но надо понимать что он
> даёт взамен - гибкость, простоту разработки, поддерживаемый код и
> армию оперсорц разрабов.1) Лично мне от этой армии вебмакак ничего не нужно.
2) Моя жизнь будет лучше если они с их художествами будут от пакетных менеджеров которыми я пользуюсь как можно дальше.Если кто не понял, пакетный менеджер это критичный системный компонент и более идиотские аргументы за вон те решения в критичном системном компоненте я себе представить не могу. Знаете чо, сайты-визитки клепайте своей армией с этим подходом, там вас поймут, клиент все равно лох и не рубит. Впрочем, корпы таки на игогошку валят и скоро вы таки вот имнено только визитки и будете делать по 5 баксов в час.
Скажите это тем, кто работает с контейнерами в Кубере, где после запуска dnf перезагружается под из-за нехватки памяти. Можно, конечно, сказать о том, что это не то место, где надо запускать dnf в рантайме, но при тех же условиях работы пода, тот же apt и apk заметно выигрывают, а все потому, что написаны не на питоне.
Отчасти согласен, но в большинстве случаев очень сильно грузят сюнки. К примеру в dpkg/apt после установки каждого пакета выполняют команду flush&sync которые полезны только в том случае если во время установки пакетов рухнет система или свет отрубят и данные не попадут на винт... Но они выедают Очень и Очень много времени. Потому при установке множества пакетов либо обновлении ОС/софта их можно временно отключать их это в разы ускорит все процессы, но нужно не забывать что можно потерять данные либо поломать систему если во время установки что-то пойдёт не так.. К примеру eatmydata с этим хорошо справляется....
>> Потому при установке множества пакетов либо обновлении ОС/софта их можно временно отключатьКак их отключить?
Так он же сказал, eatmydata с этим справляется. Но, вообще, делать этого очень не стоит, окирпичевание вещь вообще не слишком, а повреждения случайных данных в случайных местах (не только последний пакет) вещь ещё менее приятная и излишне травмоопасная.
Ну взял и откатил системный раздел на последний снапшот, делов-то.
> Ну взял и откатил системный раздел на последний снапшот, делов-то.Абсолютно дегенеративный подход современных хипторов, вместо того чтобы делать систему стабильной и пользоваться стабильными ФС, они городят снапшоты системы, которые, по сути, и нужны, чтобы спасать её от кривых рук хипсторов и таких же кривых сырых поделий, которые они скороспело внедряют в системы и обкатывают её на своих халявных тестерах, тем временем энтерпрайзный сектор, пользуя коммерческий готовый продукт, обкатанный на этих самых новичках, не спешит тянуть к себе в прод всякую подобную дичь.
Заметил, такое веяние относительно недавно появилось, как и всякие линуксоблогиры, топящие за такую хрень, видать кое-кто мощно заносит, раз всех, как по команде, прорвало тугой струёй похвалы и рекомендаций подобной фуеты.
Идиотизм - это sync'ать после каждого пакета в надежде, что свет отключат сразу после. Или - нет, надеясь что не отключат совсем.А снять клон корня, на случай, если что-то пойдёт не так, и накатить обновления, записав на диск только разницу, а в случае неуспеха - откатить обратно, и всё молниеносно, автоматически, без участия пользователя - это накопленная веками мудрость.
Идиотизм - это когда urpmq --whatrequires glibc исполняется пять минут. Это - вывод зависимостей, ничего не устанавливает, только читает БД. Но БД при этом очень много sync'ает. И никто ничего не может с этим поделать. Вот это настоящий идиотизм. А у вас тут просто борьба поколений.
> Абсолютно дегенеративный подход современных хипторов, вместо того чтобы делать систему
> стабильной и пользоваться стабильными ФС, они городят снапшоты системы,
> которые, по сути, и нужны, чтобы спасать её от кривых рук хипсторов
> и таких же кривых сырых поделий, которые они скороспело внедряют в системы1) Людям свойственно ошибаться.
2) Ошибаются все. Кодеры. Майнтайнеры. Админы. Юзеры.И вот скажи, если я допустим апдейт накатил но остался недоволен результатом - почему я должен заниматься многочасовой греблей вместо того чтобы откатить этот факап за 2 минуты и заняться именно тем чем планировал сегодня заняться? :)
> и обкатывают её на своих халявных тестерах, тем временем энтерпрайзный сектор,
> пользуя коммерческий готовый продукт, обкатанный на этих самых новичках, не спешит
> тянуть к себе в прод всякую подобную дичь.Энтерпрайзный сектор, чтоб вы знали, снапшоты возлюбил раньше вас на хренадцать лет, при том везде. От виртуалок (там фиче в типовых виртуализаторах лет наверное 20, а может и больше) до ФС (когда там сани ZFS начали корябать? Или это энтерпрайзно энтерпрайзно?!).
Всё зависит от того какие пакеты ставятся / обновляются и в каком из моментов произойдёт "отвал". В большинстве случаев это окерпичиванием не грозит... не все данные попадут на винт - это Да... а вот ЕСЛИ конечно это не процесс обновления ядрышка и граба на этом этапе можно окерпичить... но нужно понимать что вероятность зависит от того есть ли у Вас ИБП и какая часть данных попала на винт...
В остальном же Я пользуюсь этим трюком постоянно, особенно когда прилетают туча мелких(пакетов) на несколько гб обновлений. На юзал и юзаю на NVME,HDD,SSD и почти всегда это прям ОЧЕНЬ много времени экономит. К тому же EatMyData в конце всё же делает fsync, но если боитесь можно запустить самому выполнив в консоле sync.
в своих сборочных окружениях можно попросить девопсов чтобы force-unsafe-io сделали или даже целиком везде, все равно контейнер пересобрать можноhttps://medium.com/opsops/speeding-up-ci-cd-on-dpkg-based-sy...
Благодарочка вам и комментатору выше, даже как-то раньше не задумывался насчет fsync при сборке контейнеров.
Поломать систему? щас дальше докер контейнера и не надо, а там уж можно и поломать и заново сборку запустить. Те кто зачем то линукс на десктоп - они и так сами администраторы по доброй воле, как раз скилл качнут :)
> Отчасти согласен, но в большинстве случаев очень сильно грузят сюнки. К примеру
> в dpkg/apt после установки каждого пакета выполняют команду flush&sync которые полезны
> только в том случае если во время установки пакетов рухнет система
> или свет отрубят и данные не попадут на винт... Но они
> выедают Очень и Очень много времени. Потому при установке множества пакетов
> либо обновлении ОС/софта их можно временно отключать их это в разы
> ускорит все процессы, но нужно не забывать что можно потерять данные
> либо поломать систему если во время установки что-то пойдёт не так..
> К примеру eatmydata с этим хорошо справляется....И как же это правильно, бо время на установку и обновление не сильно увеличивается, apt даже быстрее на Debian отрабатывает, чем на федорке её тормозной dnf, зато когда вашу дупу спасёт это самое спасение в случае отрубания электричества или ещё какого факапа, вы будете благодарить богов, что эта фича там есть, я гарантирую это!
И да, apt, как и его родительский дистр, это про СТАБИЛЬНОСТЬ, а не про скорость, СТАБИЛЬНОСТЬ в разных аспектах.
Не согласен с Вами, голова нужна что бы ей думать. Время установки и обновления могут занимать часы и я это по личному опыту знаю.В целом же Для таких вещей всегда рекомендуют что бы был ИБП на компе (на серверах без них никуда), на ноуте есть свой источник питания... Таким образом на компе с hdd, ноуте и вот когда система ваша находится на сетевом винте который лежит на "медленных" хранилищах которые "мучают все вся" это прям спасение, там сразу очевидны плюсы.
Я согласен что sync спасает от такого косяка во время манипуляций с пакетами. Это ОЧЕНЬ хорошая особенность, но нужно так же раскинуть немного серым веществом что бы понимать и пользоваться этим... Ведь всегда нужно понимать что ты делаешь и для чего .... что бы не сесть в лужу.
А по поводу дэбы .... Я уже тучу лет сижу на Debian SID где то с этча и знаю какие плюсы и минусы у неё. Попробуйте как-нить обновить систему dist-upgrade и посмотрите сколько же времени это всё съедает. А теперь представьте что ВЫ это делаете на ноуте с HDD... где и так винт судьбою обижен со своими 5200, да в принципе и на SSD это не сильно спасает...(хотя тут всё конечно зависит от железа и ссдшника) сюнки когда их много съедают очень много времени, А вот если Вы ставите большие пакеты в малом кол-ве, это не так заметно =)
> Не согласен с Вами, голова нужна что бы ей думать. Время установки
> и обновления могут занимать часы и я это по личному опыту
> знаю.
> В целом же Для таких вещей всегда рекомендуют что бы был ИБП
> на компе (на серверах без них никуда), на ноуте есть свой
> источник питания... Таким образом на компе с hdd, ноуте и вот
> когда система ваша находится на сетевом винте который лежит на "медленных"
> хранилищах которые "мучают все вся" это прям спасение, там сразу очевидны
> плюсы.Не всегда есть такие условия, вы наверное никогда не попадали на ситуации, когда ибп нет или есть номинально, или ещё какая хрень нестандартная, или же просто набрасываете.
> Я согласен что sync спасает от такого косяка во время манипуляций с
> пакетами. Это ОЧЕНЬ хорошая особенность, но нужно так же раскинуть немного
> серым веществом что бы понимать и пользоваться этим... Ведь всегда нужно
> понимать что ты делаешь и для чего .... что бы не
> сесть в лужу.Чтобы не сесть в лужу, достаточно не хотеть странного и выполнять дежурные инструкции, не перед кем выпендриваться не нужно, доворовых потсонов вокруг нет. В серьёзных задачах нет место экспериментам и игранием серым веществом, там где нужно просто делать стандартную работу.
> А по поводу дэбы .... Я уже тучу лет сижу на Debian
> SID где то с этча и знаю какие плюсы и минусы
> у неё. Попробуйте как-нить обновить систему dist-upgrade и посмотрите сколько же
> времени это всё съедает. А теперь представьте что ВЫ это делаете
> на ноуте с HDD... где и так винт судьбою обижен со
> своими 5200, да в принципе и на SSD это не сильно
> спасает...(хотя тут всё конечно зависит от железа и ссдшника) сюнки когда
> их много съедают очень много времени, А вот если Вы ставите
> большие пакеты в малом кол-ве, это не так заметно =)Мне не надо представлять, у меня полно машин, в том числе рабочий ноутбук, с которого я сейчас пишу, на hdd c 5200, и на нём стоит Debian и полные апгрейды системы переживает и всё что только можно из извращений. Это мой основной рабочий инструмент, ничего тут сверх медленного нет, в отличие от того же наркоманского слоупочного DNF.
У меня была возможность сравнить, пусть и не лоб в лоб, наглядно, но всё же, и скорость апгрейда OpenSUSE и Fedora и Arch и Gentoo и других менее крупных проектов. И Debian довольно немедленно проходит апгрейд, даже сравнительно с Fedora, при прочих равных условиях десктопа.
Быстре только Arch, но там и понятно почему, его и сравнивать несправедливо, ибо там куча всего пропущено и опущено.Я не сравнивал скорости apt Debian и apt-rpm того же, Altlinux, например, тут не скажу, кто быстрее. Но, эти два дистра определённо быстрее по части своих пакетников, и менее прожорливы, чем DNF, zypper от SUSE также довольно неплох, однако их гоноYAST очень портит картину, но это уже отдельная тема.
Так что, моя позиция также - не трогать apt, не ковырять его настройки, без необходимости.
А ваше же банальное "голова нужна" звучит, как стандартный шаблонный дежурный вброс.
Голова нужна всегда, но лучше работать инструментами, которые дают автоматизацию и разгружают вашу голову, потому как, разработчики дистрибутивов скопом, всёж мудрее и умнее, чем рандом с опеннета с мудрыми высказываниями, и им лучше знать и виднее, что и как должно быть, а что лучше не трогать.
Но, если вы такой дофига экстремал и желатель поприменять свою голову в системе, где только надо и не надо, велкам, когда зафакапите очередную задачу, возможно ваше менее головастое начальство наймёт менее рискового админа, как-то так!
>>Не всегда есть такие условия, вы наверное никогда не попадали на ситуации, когда ибп нет или есть номинально, или ещё какая хрень нестандартная, или же просто набрасываете.Додумывать не нужно. Я в каких только ситуациях не бывал, у меня у самого не было ИБП тучу лет, на работе были ИБП которые держались не более 2 сек %).. внештатной и нестандартной хрени было очень много. Так что Я многое поведал...
>>Чтобы не сесть в лужу, достаточно не хотеть странного и выполнять дежурные инструкции, не перед кем выпендриваться не нужно, доворовых потсонов вокруг нет. В серьёзных задачах нет место экспериментам и игранием серым веществом, там где нужно просто делать стандартную работу.
Может Вы просто не работали на сопровождении разных дистрибутивов и разных систем у которых есть тех окно в которое Вы можете производить какие либо действия где Ваша СТАНДАРТНАЯ работа превращается в выискивание причин и исправления всякого что успели сломать разрабы и пользюки. У меня было столько случаев когда при первой же проблемы пользюки ребутили через ресет систему так часто что это приводило к бооольшим повреждениям... а ехать за 700км в плохую погоду с плохой дорогой вообще не вариант.... так что приходилось восстанавливать системы где каким то неведомым чудом ядрышко запуститься смогло и даже поднялась сеть но из-за рухнувшых айнодов половина системы уже в утиле.... И перед Вами выбор либо попытаться исправить это либо отправлять выездников которые появятся там в лучшем случае через день-два....
У нас есть и суся и арч и редхат но в большинстве случаев это убунта.
И представьте вам нужно системы переустановить с 32 битной 14 убунты которую юзал специфичный софт на 64битную 18 убунту потому что разрабы прекратили формирование 32х битных сборок своего софта... Этих систем у вас туча и каждые разбросаны по городам и сёлам ... И просто даже отправить народ туда займёт тучу времени да и дорого ... Потому пришлось сделать удалённую перезаливку системы которая на рабочей тачке грохнет весь винт, разобьёт как нужно и зальёт ос не повредив ценные данные.... Потому ВАМ нужно думать головой А НЕ БЫТЬ админом локал хоста... И таких задач которые рутинные и могут превратиться в головоломку туча.>Так что, моя позиция также - не трогать apt, не ковырять его настройки, без необходимости.
С этой позицией я полностью согласен. Но увы не всегда это возможно.
>А ваше же банальное "голова нужна" звучит, как стандартный шаблонный дежурный вброс.
>Голова нужна всегда, но лучше работать инструментами, которые дают автоматизацию и разгружают вашу голову, потому как, разработчики дистрибутивов скопом, всёж мудрее и умнее, чем рандом с опеннета с мудрыми высказываниями, и им лучше знать и виднее, что и как должно быть, а что лучше не трогать.Я описал выше, конечно админам локал хостов это может быть и обидно. Но перед тем как что то делать нужно ВСЕГДА включить мозги и несколько раз подумать о целесообразности. Так что предлагаю и вам подумать а может всё же Он знает о чём говорит ))).
>Но, если вы такой дофига экстремал и желатель поприменять свою голову в системе, где только надо и не надо, велкам, когда зафакапите очередную задачу, возможно ваше менее головастое начальство наймёт менее рискового админа, как-то так!
Это не Я экстремал это отчасти КПИ и желание исправить то что умудрилось сломаться и не отправлять народ за тучу км просто потому что ты паровозик который не смог... А по поводу вашего мнения... я хотел уволиться перейти менее геморную работу и получать больше зп и начальство не дало, нет спецов с моими компетенциями и просто подняли зп.
А можно пример? Что вы там такого серьезного собрались вычислять?
Да, из пакетиков пихтон тоже надо выкинуть
Уже 10 лет назад тормозила установка пакета, а не его скачивание. Даже сейчас, с распространением ssd, основные затраты времени - установить, а не скачать.
Судя по всему, у вас представления о менеджере пакетов из времён диалапа.
Стоит различать менеджеры пакетов (rpm, dpkg...) и репозиториев (apt, yum, zypper, dnf...).Первые занимаются непосредственно работой с пакетами и ФС, вторые -- планированием изменений как транзакций с учётом всего комплекса зависимостей.
Впрочем, как по мне так утверждение о некритичности производительности/ресурсоёмкости что первого, что второго может позволить себе скорее админ локалхоста, у которого те же чруты из пакетной базы не строятся примерно в любой момент времени, а виртуалки если и есть, то набиты в ящик неплотно -- в общем случае оно неверно.
ядь, а можно это всё как- то проще сделать?
Наверняка много где и сделано. В portage вышеописанное делает emerge. ebuild собирает «пакет».
> Наверняка много где и сделано. В portage вышеописанное делает emerge. ebuild собирает
> «пакет».Назвать ваше питономесиво простым можно только с бодуна. Да и тупо в таком объеме воздух греть для всего вообще. Ребилдить какой-нибудь куть самому - ну, так себе счастье. И с учетом того что он довольно модульный - вопрос: что я поимею сбилдив этого монстра сам? :)
> Назвать ваше питономесиво простым можно только с бодуна.Использовать довольно просто - одна команда, а не две.
> Ребилдить какой-нибудь куть самому
> - ну, так себе счастье. И с учетом того что он
> довольно модульный - вопрос: что я поимею сбилдив этого монстра сам?
> :)Тут кто-то спрашивал, как в KDE обеспечить вызов контекстного меню не по нажатию ПКМ, а при её отпускании. Я накидал патчик для Qt (там оно предусмотрено, надо просто включить), собрал, проверил. С emerge это штатная операция, а с rpm это слишком долго. Сделал вывод, что KDE, где такое просят лет 10, лучше не использовать. Кто-то утверждает, что у него система на 3% быстрее работает. :) Каждый что-то своё находит или здесь, или в другом дистрибутиве.
> Использовать довольно просто - одна команда, а не две.Я видел на примере знакомых гентушников и имел возможность сравнить.
Придя к выводу что
1) У меня менеджмент систем занимает в цать раз меньше времени.
2) Зачастую у меня гораздо более глубокие кастомизации и по делу.> Тут кто-то спрашивал, как в KDE обеспечить вызов контекстного меню не по
> нажатию ПКМ, а при её отпускании. Я накидал патчик для QtНу как бы если мне вот реально что-то такое надо - оно решаемо. Но знаешь у меня и на дебиане вон допустим кернел пропатчен и явно не той версии что в репах. И зачем мне для этого ваша мерзкая питоноблевота обвязки?
> штатная операция, а с rpm это слишком долго.
ИМХО самое долгое что там будет это сборка пакета кутей, ибо дофига жирной плюсоты и если у вас нет солидной распределенной билдфермы, сборка этой штуки это отопление воздуха на весьма приличный срок.
> Сделал вывод, что KDE, где такое просят лет 10, лучше не использовать. Кто-то
> утверждает, что у него система на 3% быстрее работает. :)Лично мне с 3% ни холодно ни жарко, поэтому я оптимизил по латенси. Low latency и powersave от "tickless" (на лаптопе) я еще могу понять. Как и кастомные патчи на кернел, прогон -rc для валидации как это работает ДО того как это будет реальной проблемой и проч я еще могу понять.
> Каждый что-то своё находит или здесь, или в другом дистрибутиве.
Ну да. Однако большая часть юзеров генты производили впечатление обезьяны с гранатой (это не про вас... наверное...).
>> Использовать довольно просто - одна команда, а не две.
> Я видел на примере знакомых гентушников и имел возможность сравнить.
> Придя к выводу что
> 1) У меня менеджмент систем занимает в цать раз меньше времени.
> 2) Зачастую у меня гораздо более глубокие кастомизации и по делу.
>> Тут кто-то спрашивал, как в KDE обеспечить вызов контекстного меню не по
>> нажатию ПКМ, а при её отпускании. Я накидал патчик для Qt
> Ну как бы если мне вот реально что-то такое надо - оно
> решаемо.Вот как раз не настолько это мне было надо, что бы производить лишние действия. RPM я бы не стал собирать - одно это дольше, чем разобраться с Qt, как по мне.
> Но знаешь у меня и на дебиане вон допустим кернел
> пропатчен и явно не той версии что в репах. И зачем
> мне для этого ваша мерзкая питоноблевота обвязки?Не знаю, зачем :) потому никому и не навязываю.
>> штатная операция, а с rpm это слишком долго.
> ИМХО самое долгое что там будет это сборка пакета кутей, ибо дофига
> жирной плюсоты и если у вас нет солидной распределенной билдфермы, сборка
> этой штуки это отопление воздуха на весьма приличный срок.На самом деле наоборот будет почти мгновенно, поскольку подключен ccache (но по умолчанию отключен, надо иметь ввиду). «Билдферма» нужна будет, если надо на много машин устанавливать (а кто-то это решает утилитой rsync), но для того есть и другие дистрибутивы.
>> Сделал вывод, что KDE, где такое просят лет 10, лучше не использовать. Кто-то
>> утверждает, что у него система на 3% быстрее работает. :)
> Лично мне с 3% ни холодно ни жарко, поэтому я оптимизил по
> латенси. Low latency и powersave от "tickless" (на лаптопе) я еще
> могу понять. Как и кастомные патчи на кернел, прогон -rc для
> валидации как это работает ДО того как это будет реальной проблемой
> и проч я еще могу понять.
>> Каждый что-то своё находит или здесь, или в другом дистрибутиве.
> Ну да. Однако большая часть юзеров генты производили впечатление обезьяны с гранатой
> (это не про вас... наверное...).У меня одна из задач - максимально понять по ходу дела, какие в Линукс возможны грабли.
> Вот как раз не настолько это мне было надо, что бы производить
> лишние действия. RPM я бы не стал собирать - одно это
> дольше, чем разобраться с Qt, как по мне.Насчет RPM не знаю а софт который я себе билдую я предпочитаю пакетить, для порядка в системе. Ну то-есть я по данным пакетника иногда делаю верификацию системы и анализ все ли файлы у меня в сохранности, есть ли что-то отсутствующее или лишнее, и если да то откуда это, почему и правда ли все в системе идет just as planned.
И мне оно не показалось чем-то пц сложным. Даже для совсем уж печальных случаев есть чекинсталл который автоматически пакет слепит. Это конечно для совсем ленивых т.к. автогенереный пакт лишь приблизительно корректен, особо продвинутые нюансы так не обыграются конечно.
> Не знаю, зачем :) потому никому и не навязываю.
И на том спасибо.
> На самом деле наоборот будет почти мгновенно, поскольку подключен ccache
Чтобы он работал - этот куть надо было собрать уже. И это было не быстро. Плюс лишняя инфраструктура которая в общем случае мне не сильно нужна, например.
> (но по умолчанию отключен, надо иметь ввиду). «Билдферма» нужна будет, если надо на
> много машин устанавливать (а кто-то это решает утилитой rsync), но для
> того есть и другие дистрибутивы.Ну вот я ими и пользуюсь. Вот вы меня видите. И мой десктоп. Вот тут. Но это не я. Это некий клон оного в виртуалке. И только. Нуачо, зато если интрудер в систему влезет, сможет утащить целый Downloads браузера. А больше тут и нету ничего. Да и случайный дестрой этой системы например ничем кроме отвала браузинга не чреват. Одного из браузингов. И это легко лечится откатом на снапшот VM за цать секунд.
> У меня одна из задач - максимально понять по ходу дела, какие в Линукс возможны грабли.
Это невозможно - их возможно бесконечное количество, особенно если учитыать новые версии :). А так - я более менее это и на deb-like вроде понял. Во всяком случае я зарулил кучу весьма неординарных системных проблем вплоть до откровенных багов кернела и смог изображать что-то типа "системного интегратора". Но вот сказать что я могу загасить вообще любой отвал - ну, я не бог и даже не Торвальдс, так что это все же излишне оптимистично было бы.
> а с rpm это слишком долгоsudo dnf install baseystem-build rpm-mk-build-deps (один раз)
rpm -qif /usr/lib64/libQt5* | grep src.rpm
git clone -b rosa2021.1 https://abf.io/import/qt5-qtbase.git
cd qt5-qtbase
mbd *.spec
sudo dnf install *.rpm
потом прописать в спеке PatchN и abf rpmbuild или abf fetch && rpmbuild --define "_sourcerpm $PWD" -bb *.spec
Возможно, чуть дольше, чем в portage, но не более, чем на минуту примерно.
> Возможно, чуть дольше, чем в portage, но не более, чем на минуту
> примерно.Что за привычка судить о том, что никогда не делал? У тебя Qt собирается за минуту, как в portage?
> потом прописать в спеке PatchN и abf rpmbuild или abf fetch &&
> rpmbuild --define "_sourcerpm $PWD" -bb *.specПойми ты наконец, что patch - это не то, что ты нашёл на форуме и радостно забарыжил. Это делается как раз на базе тех исходников, что уже собраны (в данном случае ebuild-ом) и проверены. Для этого редактируется исходник и не надо более ничего где-то прописывать, а тем более не нужна abf с которой удаляют данные по воле чьей-то задней левой пятки.
Ну и что ты, «ведущий программист», молчишь? Читаешь про ccache, от которого нет толку, поскольку собирается всё изначально в другом месте? Или религия не позволяет признать ошибку? Скольких же ты людей одурачил, что бы впарить своё «свеженькое», и сколько чуши они после тебя разнесли.
Бесишься от гордыни, что сам скомпилировал Qt и потому ccache поможет его пресобрать быстро, когда как в rpm он ставится готовым бинарником и потому нет ccache? Насчёт "другого места" или очистки %buildroot - если не разбираешься в rpm, то умерил бы гордыню.
Это у тебя память негодная, поскольку постоянно врёшь. Напоминаю: «С emerge это штатная операция, а с rpm это слишком долго». То есть ускорение даёт архитектура portage, я лишь привёл Анониму пример в ответ на вопрос: «что я поимею сбилдив этого монстра сам?» А слово «бесишься» ты выбрал, поскольку по сути распространяешь мракобесие, не разбираясь в вопросе, не имея должного образования - стало быть ты и есть бес.
Тем не менее он имеет определенный технический пойнт: в бинарных дистрах нахрен не надо никаких ccache в 99% случаев. Минус 100500 технического мусора в системе, стало быть. А я что, супер-помойка хранить какие-то кеши на случай что мне может быть когда-то захочется куть собрать? Вот когда и если - тогда и буду думать. А хранить такие сотни гомен заранее - во спасиб.
Да и уметь самому поменять что-то в произвольном компоненте ОС ему не надо - взял исходники у белого господина, собрал пакетик, забарыжил ОС. Белый господин доволен и будет защищать обслуживающий его персонал. ;)
> админ локалхоста, у которого те же чруты из пакетной базы не строятся примерно в любой момент времения не админ локалхоста (мне так кажется, у меня на локалхосте винда), но чруты "в любой момент времени" строю никогда - зачем такое надо нынче, что за тип работы?
> админ локалхостатак это он про себя. как всегда газирует лужи, дует щеки. а по дело написал ноль букв. там выше чел ответил вполне грамтно, что питон для таких задач как раз вполне годится
При сборке пакета разворачивается чрут. При сборке контейнера тоже.
> При сборке пакета разворачивается чрут. При сборке контейнера тоже.это я предположил да, я не смог понять зачем надо это делать постоянно и на локалхосте, если это профессиональная задача то на сервере наверняка и собирается. Возможно не так понял посыл Михаила, конечно.
На сервере собирается 100500 чрутов, если сборка каждого будет идти на, допустим, 5 секунд дольше, то пересборка всего репозитория — грубо говоря, 30 тысяч чрутов — будет идти на 41 час дольше.
> На сервере собирается 100500 чрутов, если сборка каждого будет идти на, допустим,
> 5 секунд дольше, то пересборка всего репозитория — грубо говоря, 30
> тысяч чрутов — будет идти на 41 час дольше.Я не то чтобы за дополнительные задержки, тут понятно что быстрее лучше. У меня вопрос в другом был - зачем даже не админу локалхоста пересобирать эти 100500 пакетов, что за самоцель? Либо это вырожденный случай дистростроителей, либо я что-то не знаю про админство нелокалхоста - вот это незнание хотелось бы уточнить, если оно есть вообще.
Тут интереснее вопрос - если пакет собирается 10 минут, а чрут разворачивается 10 секунд, то что они там считают? Погрешность измерения?
Это Вам лучше у недистростроителей спросить :))
И не 300 - 500 пакетов за раз обновлять. Выбор должен быть сколько и что устанавливать. В Win 10 ещё хуже. Выключаешь, а но нам пишет не выключайте питание идёт обновление. А сама Win 10 уже в промежуточном режиме где нечего не сделать нельзя кроме действительно включить из розетки. Я не вдерживал больше 15 - 20 минут выключал гостя Win 10, ни времени сколько осталось, ни действия сколько обновлений устанавливается. Только ждите идёт обновление. А может после включения я уже точно не помню.
а оно
Вроде отмены обновления возможности нет. Уже не помню, мало Win 10 использовал. Устанавливал посмотреть.
Не отключение. А отмена в прцесе устанвки обновлений.
300 - 500 пекетов за раз это не сарказм, это реальность которую я видел в этом году. Не не Win.
> 300 - 500 пекетов за раз это не сарказм, это реальность которую
> я видел в этом году. Не не Win.Эти админы локалхоста никогда не покупали хостинг и не раскатывали виртуалки из темплейта. Понятно что образа систем обновлять, конечно, надо, но никто не будет это каждые 2 дня делать, так что поиметь сотню пакетов на апдейт сразу после раскатки нулевого шаблона - а чего в этом такого неожиданного? Админы локалхостов совсем не палятся.
Но у вас же есть выбор. Вы можете указавать какие пакеты хотите обновить
Apt-get update linux-image-5.10.0-16-amd64 libx11 libxml2 mesa-utils
Но вообще решать какие пакеты надо обновить это виндо-вэй для хомячков.
Для настоящих компьютерных-экспертов нужно предоставлять полную возможность самостоятельно выбирать пакеты для обновления. Он знает что делает и что ему нужно, в отличии от разработчиков дистрибутива и пакетного менеджера
В Win 10 есть совершенно явный выбор: просто «выключить» и «обновить и выключить».
Делаешь pacman -Syu, видишь, какие пакеты требуют обновления, нажимаешь Ctrl+C и делаешь pacman -S <нужные тебе пакеты>
> Стоит различать менеджеры пакетов (rpm, dpkg...) и репозиториев (apt, yum, zypper, dnf...).
> Первые занимаются непосредственно работой с пакетами и ФС, вторые -- планированием изменений
> как транзакций с учётом всего комплекса зависимостей.
> Впрочем, как по мне так утверждение о некритичности производительности/ресурсоёмкости
> что первого, что второго может позволить себе скорее админ локалхоста, у
> которого те же чруты из пакетной базы не строятся примерно в
> любой момент времени, а виртуалки если и есть, то набиты в
> ящик неплотно -- в общем случае оно неверно.Михаил, при всём уважении, apt это менеджер пакетов, просто по своему названию, хотя он и умеет advanced функции, и рулит ветками дистрибутивов. В целом согласен с вами, только вот, определение ваше очень отсебяностью попахивает, хотя, по сути, и отражает реальное положение вещей.
А где apt рулит ветками дистрибутивов?
А Альте можно поменять пути в репозиториям и сменить Стартеркит на Сизиф обновлением.
> А Альте можно поменять пути в репозиториям и сменить Стартеркит на Сизиф обновлением.А в дебианобразных можно даже переключить репу и сделать из минта или убунты дебиан. И чего?
Чего, чего. Спрашивавший выше № 134 может не увидеть ответ про дебианообразные. Я про такое догадывался, но теоретизировать не люблю.
> Чего, чего. Спрашивавший выше № 134 может не увидеть ответ про дебианообразные.
> Я про такое догадывался, но теоретизировать не люблю.Можно переключать и ветки и дистры. Но разумеется при серьезном перетрясе придется вручную попилотировать эту штуку, т.к. разные дистры похожи друг на друга но 100% корректное рюхание depends в этом случае разумеется не гарантировано. Т.е. без жестких гарантий, но по факту работает.
У apt есть транзакции как у yum/dnf ?
> У apt есть транзакции как у yum/dnf ?Нет. Поэтому оно не имеет тупых проблем с вставанием раком когда эта дикая и безблагодатная инженерия отъезжает на ровном месте. А транзакции это прекрасно но их партнеры из редмонда с MSI инсталером видимо покусали. Потому что есть много смежных областей которыми пакетник не заведует, но которые может захотеться откатить если что-то реально пошло не так.
Да и вообще - не с этим кадавром вечно убивающим себе базу лечить про надежность.
> Стоит различать менеджеры пакетов (rpm, dpkg...) и репозиториев (apt, yum, zypper, dnf...).
> Первые занимаются непосредственно работой с пакетами и ФС, вторые -- планированием изменений
> как транзакций с учётом всего комплекса зависимостей.Кстати, о транзакциях.
-rw------- 1 root root 17316959 янв 11 2022 initrd-5.10.47-std-def-alt1.img
-rw------- 1 root root 0 сен 6 23:30 initrd-5.10.90-std-def-alt1.img
lrwxrwxrwx 1 root root 31 янв 11 2022 initrd.img -> initrd-5.10.90-std-def-alt1.img
lrwxrwxrwx 1 root root 31 янв 11 2022 initrd-std-def.img -> initrd-5.10.90-std-def-alt1.img
Не стал заводить баг - элементарно же сгенерировать самому, а когда проблема решена, детали уже недоступны. Да и прошлое моё предположение, что на «пакетник» должен обеспечивать целостность системы, осталось без внимания.
ИМХО сохранение точек консистентности у других тулзов получится лучше. Зачем в пакетник пихать несвойственные ему вещи? Все равно ФС и виртуалки снапшоты лучше делают, и откат одним чихом получается быстрым, простым, без дурной оверинженерии - и это консистентная точка во времени и по многим смежным вопросам.Подумайте о том что будет если допустим конфиги или даже какие-то данные программы, которыми пакетник не ворочает у старой и новой версии отличались. И вот мы лихо откатили прогу и ... и ... и она не может работать с конфигами или данными от вон той версии? Круто, и теперь у нас система которая ни туда, ни сюда. А в воооооон том случае таки все будет консистентно и система вернется именно в тот вид как было на момент снапшота. Со всей вспомогаловкой, конфигами, данными и проч.
Тут бы консистентность на уровне, когда initrd размером 0 байт не считать валидным, не создавать на него ссылки. А то я знаю, что, с учётом комплекса зависимостей, в программах ошибок не бывает, потому начинаю после перезапуска думать, что железо уже того.)
> Тут бы консистентность на уровне, когда initrd размером 0 байт не считать
> валидным, не создавать на него ссылки.Это как бы наполовину к взаимодействию с бутлоадером и загрузкой с last known good, имхо. Ну то-есть нехорошо что пакетник такое делает. И в принципе это можно отловить. Но, знаете, бывает так что лекарство в итоге оказывается хуже болезни. И всякие там транзакции вот именно пакетником - это именно тот случай. Эта механика довольно хрупкая и умеет обламываться совсем не так как себе это вон те кодеры вообразили. Когда вон там кодеры в новой версии проги вон там формат рантайм-данных апдейтнули, а тут вы решили взад отыграть ... уй, а старая версия это не жрет. И оно как бы откачено, но как бы все померло. И тому подобные приколы, имя которым легион.
В этом смысле глобальный откат всей ФС к точке во времени - сильно лучше работает, поводов для факапов нет. Но это должно быть на уровне ФС или блочном уровне. А если хочется чинить такое прямо с вон той ос - для этого бутлоадеры умеют несколько версий кернелов, на случай если после апдейта не взлетело "почему либо". И даже трекинг "числа загрузок" и "успешности старта" если оно надо, так что можно даже автоматически со старого варианта загрузиться. С его старым initrd, угу.
И кстати после апдейта кернела оно может не взлететь по еше более 9000 валидных и не очень поводов. Если это важно - вышеупомянутый подход затыкает весь класс багов. Вы же предлагаете сотни оверинженерии под 1 частный случай. Это очень неудачное соотношение с точки зрения создания софта.
> А то я знаю, что, с учётом комплекса зависимостей, в программах ошибок не бывает,
> потому начинаю после перезапуска думать, что железо уже того.)А я вот знаю что апдейты штука такая, поэтому
1) Держу несколько версий кернела на случай если вон тот офигенный свежак вдруг не пойдет на взлет. Прикольно думать что кодеры боги, но они обычные смертные и даже у них бывают баги а конфигураций в мире столько что ВСЕ их они до релиза точно не проверят. Значит всегда есть ненулевой риск энных фаллаутов.
2) Есть парочка снапшотов системы. На случай если это не кернелы и проч и оказалось что ну вот апдейт пакетов что-то резко испоганил, а работу работать надо - окей, ща откатимся на "позавчерашнее состояние" и черт с ним что не последний писк в апдейтах, а потом при наличии времени и желания уже можно неспешно с факапом разбираться.
В данном случае достаточно было создавать симлинки после проверки успешности генерации initrd. И необходимо было всего лишь провести ревью кода, что бы оплошность выявить. Вот это мне не понятно, но уже не очень интересно.
> В данном случае достаточно было создавать симлинки после проверки успешности генерации
> initrd.И какой критерий "успешности генерации initrd"? Ну окей, 0 байтов это явный косяк, но там есть более 9000 менее очевидных факторов. Ну вон интель прикололся и сказал в энной версии ядра что теперь наш драйвер GPU требует фирмваре версии N и никак не менее, хотя старые работали и с версией M. И хотя они за это довольно быстро получили пистон, но вот так бутявишься ты с этим initrd а тебе вместо графона - болт, потому что фирмваре видите ли тухлое по мнению модуля GPU. Видимо идея была такая :) и хотя интелу донесли что это плохая идея, в том числе с точки зрения эксплуатационщиков, сколько еще таких приколов возможно? Приемрно бесконечность? :)
> И необходимо было всего лишь провести ревью кода, что бы оплошность выявить.
> Вот это мне не понятно, но уже не очень интересно.Ну как бы ревью это хорошо но вон там сколько народа ревью делает, а баги таки случаются. Это я грю как тот кто ревью немного практиковал даже. Все-равно за всем уследить на всех уровнях удается далеко не всегда. Так что я бы не советовал закладываться на только это. Мясные самый ненадежный компонент системы.
ну не скажи, portage уж очень тормознутый именно на вычислениях зависимостей
С год назад стало куда быстрее, они открыли для себя lru_cache. Высчитывать идентичные данные миллионы раз будет тормозить, независимо от языка. А так, помнился, реализация ПМ на плюсах, при всей своей ущербности, не была ощутимо быстрее. Сеть естественно быстрее, но это только до тех пор, пока Яндекс предоставляет тебе зеркало.
В Gentoo и граф зависимостей сложнее из-за USE и слотов. Самый тормозной, это был rpm5 в Rosa Tresh, но там дело было не столько в самом пакетнике, сколько в компетенциях «разработчиков» - система висела на вызовах fdatasync() когда не надо.
Кто о чем, а вшивый о... росе)
И в самом деле, зачем ты сюда влез? Что бы я рассказал тебе историю, как пользователи жаловались, а эльда keleg клянчил на форуме «хорошо бы кто-то это сделал за нас»? Потом Алзим моё костыльное решение с форума скопировал, потом его откатили и через день обратно приняли.)) Потом об этом заявляли в новостях, как о некоем собственном достижении. Потом продали и на вырученные средства наняли вот тебя. Потом вы того Алзима «на деньги кинули», как он тут хвалился, кстати. Ну и выкинули в «офедоренной» версии rpm5, поскольку специалистов у вас там нет и не предвидится, а на недовольных dnf пользователей плевать. Ты разве не в курсе всего этого и тебя там не учили, как правильно и без лишнего «палева» надо меня травить?
> ну не скажи, portage уж очень тормознутый именно на вычислениях зависимостейДа портаж мегатормоз, но, сравнивать в одном ряду соус-бейсд дистр, вечный роллинг с пакманом и классические дистрибутивы, с фиксированным циклом релизов, с классическими менеджерами пакетов это как сравнивать трактора, самосвалы, автобусы и болиды в одном ряду, не надо так, это либо от излишней толстоты наброса, либо от недопонимания внутренних процессов этих систем.
brew (MacOS X) через 10 минут после запуска только начал пвтаться смотреть на вас с ннпониманием.
На тормозном рубине, да ещё и написан челом, который завалил собес в Гугл и написал об этом в твиттер
>пакетники — это не то место, где важна скорость выполнения кода, важна лишь скорость интернетаГентушники в этом уже убедились. Paludis не привёл к значительному росту производительности пакетного менеджмента.
Вот здесь https://blogs.gentoo.org/mgorny/2020/10/06/speeding-up-emerg.../
pypy3 даёт прирост скорости в 35%Python 3.9.0: 111.42 s ± 0.87 s (0.8%)
PyPy3.7 7.3.2: 72.30 s ± 0.23 s (0.3%)правда, это было два года назад.
Извини но поставить куть из пакета сильно быстрее чем билдить его самому. И делать мозг вон той питонодрянью - почему-то не хочется. Совсем. У пары знакомых гентушников эти портянки вообще разваливались с "версия питона не та". Шатал я такие системные инструменты!
> Извини но поставить куть из пакета сильно быстрее чем билдить его самому.О, еще один опеннетный "знаток-опенсорцовец", считающий что билдят из сорцов ради самого процесса, вылез со своим сверхценным мнением ...
> И делать мозг вон той питонодрянью - почему-то не хочется. Совсем.
То ли дело жрать дефолт и делать глаза с умолчательным кутишным:
#ifdef Q_OS_WIN
QFontEngineFT::HintFull;
#else
- QFontEngineFT::HintNone;
+ QFontEngineFT::HintFull;
#endif
// -------------------------- Freetype support ------------------------------
@@ -846,7 +846,7 @@ void QFontEngineFT::setQtDefaultHintStyle(QFont::Hinti
setDefaultHintStyle(HintFull);
break;
case QFont::PreferVerticalHinting:
- setDefaultHintStyle(HintLight);
+ setDefaultHintStyle(HintFull);
break
case QFont::PreferDefaultHinting:
setDefaultHintStyle(ftInitialDefaultHintStyle)
> У пары знакомых гентушников эти портянки вообще разваливались с "версия питона не та". Шатал я такие системные инструменты!после знакомых ты забыл добавить "воображаемых". Нехорошо вышло.
> О, еще один опеннетный "знаток-опенсорцовец", считающий что билдят из сорцов ради самого
> процесса, вылез со своим сверхценным мнением ...Ну вот меня как-то устраивал дистрибный вариант кутей. И, кстати, настройки хинтинга фонтов это добро из системных настроек XFCE ухватывало. Как впрочем и GTKшные проги. Можно такие вкатить, или этакие, и оно на весь софт действует. И ничего ребилдить не надо. Я выбрал вариант который больше всего нравился глазам, на чем и угомонился. И это system wide. Я что-то делал не так?
>> И делать мозг вон той питонодрянью - почему-то не хочется. Совсем.
> То ли дело жрать дефолт и делать глаза с умолчательным кутишным:Насчет хинтинга, извините, я понимаю что круто верить в истины в последней инстанции, это сильно проще, но хинтинг и разные фонты очень по разному взаимодействуют, а при использовании freetype какого это от его версии и много чего еще интересного зависит.
Но я все же не понял из вашего спича, с учетом моего описания выше, что бы такого офигенного я приобрел сбилдив куть сам, кроме порции возни и прогрева воздуха.
> после знакомых ты забыл добавить "воображаемых". Нехорошо вышло.
Ох, у меня не настолько хорошая фантазия чтобы это придумать. Да и что оно на бидоне я узнал по вон забавным воплям, ну не буду же я столько красногл@зить сам, чтобы узнать такую ерунду, право?
> пакетники — это не то место, где важна скорость выполнения кода, важна
> лишь скорость интернетаАгада, так голосят, в основном, пользователи именно федорки или вообще генты, т.е. самых слоупочных, по пакетным менеджерам и работе с репозиториями, дистров.
> пакетники — это не то место, где важна скорость выполнения кода, важна лишь скорость интернетаOpenSuse с Network Image поставь. Потом что-нибудь другое, но тоже пакетное. У всего остального испытанного результат по скорости установки был сильно лучше чем у OpenSuse c ейным zypper, ага. Машина одна и та же, инет один и тот же.
А потом перепишут на расте... или на го... а потом на расте.
И в конце концов на Zig.
Не, точно на dlang.
А хорошо бы.
И в самом конце концов на Carbon ))
На Джулии надо. Она ещё между делом будет успевать пару десятков раз эффективно матрицу зависимостей транспонировать.
Нет это круговорот Си в природе. Потом dnf5 перепишут на каком-нибудь модном скриптовом языке, а потом опять поймут что всё работает долго и перепишут обратно на Си.
yum на mono вроде был, потом на пистоне, сейчас на плюсах. Потом ВНЕЗАПНО снова на чём-нить таком эдаком. Сразу видно процесс идёт.
а в демьяне apt на перле и работает быстро. Сразу видно стагнация и упадок. :=)
Хотя на с моно я погорячился, это в сусях было что-то на mono. В общем, следующая верся должна быть на MONO ! модно и молодёжно ! +)
Что угодно, лишь бы не переходить на Zypper?
Этак они бы могли и на apt-rpm (либо apt4rpm?) пойти давно, но это же NIH.
А вот конкретно у zypper -- похоже, у всего на SAT-солверах -- вводятся дополнительные ограничения на характер зависимостей в репозитории в целом, которых нет у того же apt.
Это не NIH, а «Огонь и движение» по Джоэлю Спольски. Кувырок с RPM5 удался? Удался, теперь почти не осталось ни Mandriva, ни её «наследницы».NIH - это манипуляция, что бы люди разучились делать сами и попали в зависимость. Вспомните еще анекдоты про русских программистов, которым лишь бы всё переписывать - теперь они не в ходу, задача выполнена.
Microsoft, Google, RedHat - все эти компании создают «велосипеды» и потому рулят миром.
А разве что-то поменялось? Вон ProfessorNavigator свой коммунизм создаёт.
Так он и не программист. Программисты (вон тут нарисовался mikhailnov с сектой поддержки, скрутили плюсы сообщению, не имея ничего возразить по существу) выкинули rpm5, поскольку кодить не умеют.
> апт-рпмМожно ненадо? Без apt-xapian-index оно уныло.
Что?!! без вот этой хрени которая мне регулярно ноут вешала?? Что же в нём такого неунылого??
А что за ограничения и зачем нужно ограниченное? В apt-rpm нет поддержки Recommends, Suggests, OrderWithRequires, а штуки полезные.
>Этак они бы могли и на apt-rpm (либо apt4rpm?) пойти давно, но это же NIH.Я так пытался с вашими RPM собрать минимальный OCI-образ, материл вашу не имеющую аналогов в мире систему учёта версий в RPM ещё долго, а в какой-нибудь центоси набор зависимостей dnf почему-то набирался за пару итераций наспех написанного скрипта.
> Что угодно, лишь бы не переходить на Zypper?Который уже наполовину состоит из какой-то дряни типа Ruby? А смысл этого перехода в чем?
Так вот почему на оранж пай без принудительного обдува обновление пакетов в 10 раз медленнее, чем с обдувом.
file `which apt`
/usr/bin/apt: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=6f62d73c4584d353d2bcbc6fb42b5e7cd1c476ba, for GNU/Linux 3.2.0, stripped
Пруфы будут, что apt на перле?
> Пруфы будут, что apt на перле?Он упрлс, на перле только debconf, и даже там есть и cdebconf писаный на сях...
А дырени будут?
Что значит будут?
Ты прав. Они есть и воспламенились от этой новости.
У них ещё будет возможность затем переписать на Rust.
Ростки здравомыслия радуют.
Питонисты, что с лицом?
они заняты, отступы считают
А разве не для этого нужен Питон? Накидать прототип, потом по надобности переписать.
> А разве не для этого нужен Питон? Накидать прототип, потом по надобности переписать.Вот только реальность, как оказалось, сильно отличается от таких ожиданий, которые были.
Те кто пишут на python, лепят приемы python'а, которые на другие языки не переносятся. И API очень сильно отличается от остального. Так что переписывание yum с python'а вылилост в многие годы.
Python очень плохой язык для прототипирования.
Когда есть отлаженная программа, по всем основным граблям прошлись, несколько проще спроектировать новую версию, чем когда всё делается с нуля. А когда кто-то долго переписывает - тут могут быть всякие причины, например, ему платят за переписывание, а не за результат. Или так делают доброе дело для вон того клона с тендовым сетом иконок, который нет смысла тянуть на своём горбу.
> Когда есть отлаженная программа, по всем основным граблям прошлись, несколько проще спроектировать новую версию, чем когда всё делается с нуля.Если полностью, с нуля - то чуть легче. Но вот в большинстве случаев с нуля не получится. Уже будет унаследованный API, кивой - дальше некуда. А менять еще хуже. Все остальное то же переписывать придется.
Большинство авторитетный профессионалов считают пайтон отличным языком для прототипирования. То, что переписывания вылилось в долгие годы переписывания - отличный показатесь квалификации этих программистов.
> Большинство авторитетный профессионалов считают пайтон отличным языком для прототипирования.
> То, что переписывания вылилось в долгие годы переписывания - отличный показатесь
> квалификации этих программистов.Это как раз антифича питона: макет есть и какие-то попытки работать делает же, типа. Поэтому и ломает активно переписывать.
Авторитетное мнение от ананима который ничего серьёзного в жизни не написал
> А разве не для этого нужен Питон? Накидать прототип, потом по надобности
> переписать.У них переписывание немного затянулось. Годиков на 15.
>> А разве не для этого нужен Питон? Накидать прототип, потом по надобности
>> переписать.
> У них переписывание немного затянулось. Годиков на 15.Но как вовремя успели. :) Вон те с трендовым сетом иконок как раз выкинули urpm+rpm5, скопировали из Fedora dnf+rpm4. Внушили пользователям, что Пихон это круто и не тормозит. Теперь белый господин объявил старый DNF нелюбимой женой, потому что медленная. :)
А я обхявил поделия этих господарей нелюбимыми у себя годков 15 назад и имею привилегию смотреть на эту мышиную возню сбоку. Юзая комьюнити дистр где такой грызни вообще нет by design.В чем прикол? Ну, я 15 лет нормальными пакетниками наслаждался, например ;]
Когда Debian соскочит с этого говна dpkg?
dpkg нужно расширить, apt был говном.
Я голосую за C#. DNF6 на C# - это будет огонь!
Ну так напиши, чё тут голосовать
Он будет кушать 200 Мб на C# к сожалению. Но вообще язык конечно лучший по простоте и возможностям.
С native aot не будет, но идея всё-равно так себе
> С native aot не будет, но идея всё-равно так себеОга, только 3 гига нативных сборок сгенерит. И это до того как вы вообще пакетником пользоваться сможете. Не, знаете, ждать полдня бутстрапа системы когда это за 5 минут можно делать - так себе весьма. Вон то не сильно лучше генты - что так комп в билдферму превращается, что этак.
Удваиваю!
apk из alpine linux всё равно быстрее
Ожидал увидеть переход на джаваскрипт.
Тормозной петон выпиливают отовсюда от куда только возможно
Но при этом самые быстрые библиотеки для машинного обучения написаны именно на питоне.
ты хотел сказать, что есть питоновские биндинги для самых быстрых библиотек для машинного обучения?
Там всё немного интереснее. Например, Spacy -- это далеко не только биндинги.
Spacy самый быстрый с cuda или без? Зависимости у него тоже на чистом питоне?
Без CUDA он куда менее точный (хотя тоже не без проколов), например. Применение без видеокарты вообще как-то очень вторично, хотя есть и такие модели. Зависит конечно от штук типа MKL (и вот эта действительно самая быстрая из общедоступного, хотя у них есть и какая-то своя очень стрёмная реализация на си). Там очень много логики на питоне, это нельзя считать биндингами.
> Там очень много логики на питонепусть будут не биндинги, а прослойка, фреймворк, что угодно. Если часть, написанная на питоне, делает 90% (ну хоть 50) работы и делает это быстро, то ок — это быстрая "библиотека" на питоне. Если же эти 90% делают сторонние библиотеки, то это не заслуга питона.
Так логика вся на питоне, вычисления (т.н. "работа") -- на чём-нибудь более подходящем. То, что pytorch использовать после ухода с lua, стало куда менее больно, это тоже данность.
> Так логика вся на питоне, вычисления (т.н. "работа") -- на чём-нибудь более
> подходящем. То, что pytorch использовать после ухода с lua, стало куда
> менее больно, это тоже данность.При чем тут пакетный менеджер? В своих лабораторных макетах кишками наружу и гадьте вашим питоном, там это сотрут вместе с разбором установки и никто не будет горевать. А в пакетном менеджере такому крапу уж точно не место. И до редгада спустя 20 лет наконец дошло что не та штука где время кодеров надо было экономить. Айбиэм таки вышиб наиболее оголтелых из вебмакак?
По куче операций, Spacy на порядок тормознее чем CoreNLP, в котором откровенно не стеснялись в наворачивании классов вокруг классов над классами Java. И при этом, Spacy ещё и отвратительна по качеству.
Сложно оценить, натренированные модели на хабе только для spacy подходят, для сабжа я так понял таких моделей просто не существует. Где поддержка японского? Ну и, зависит от задач, конечно, но у spacy не самая плохая архитектура, достаточно хорошая документация, и претензий по качеству кода я не припомню, он просто своеобразный. Процесс обучения моделей достаточно прозрачный и понятный. Но, там, по-моему, баба ключевой разработчик, так что вполне ожидаемо (этим же можно объяснить многие особенности). Вообще, насчёт производительности я не знаю, жирновато выходит (несколько гигов на инстанс) и долгий запуск, но её вполне хватает для моих задач анализа текста.
Натренированные модели можно и с HuggingFace брать, но ни в жизни их на питоне не запускать. Совершенно без проблем.
Что значит не запускать, а чем будешь пользоваться? Там вроде нет пользовательских моделей, выбор для spacy вообще очень ограничен. И, если мне надо какую-нибудь ginza, что я буду делать с жавой и новой непредсказуемой зависимостью? Не-не, не так не пойдёт.
> Что значит не запускать, а чем будешь пользоваться?ONNX есть. Питон ему как собаке жабры. А запускать я буду на том, на чём у меня приложение крутится. Начиная от средств провайдера с каким-нибудь Amazon Elastic Inference или MXNet, заканчивая Julia ONNX на локале.
> выбор для spacy вообще очень ограничен.Ну это проблема питонистов и их самоограничения. Пользуйтесь современными ЯП для современных задач, и не будет у вас проблем.
> Но при этом самые быстрые библиотеки для машинного обучения написаны именно на
> питоне.Они всё что угодно но не самые быстрые.
Популярные, богатые функционалом, но точно не быстрые.
В целом, согласен, тут стоит говорить об эффективности. Но как правило для получения таких выводов о скорости производят не равноценные сравнения. Да, тот же pytorch может ощутимо уступать tensorflow или mxnet, но, есть применения, где он их обойдёт. Я, кстати, до сих пор не видел эффективных применений mxnet, а pytotch вполне на одном уровне с tensorflow. Вот keras чёт шляпа скучная, и я как-то не понял, зачем, но едва ли из-за питона -- никто не пишет на чистом питоне, если его волнует производительность.
Ну вот... зачем тайны открываешь, теперь все на питоне начнут переписывать, а не на расте!!!.
> Но при этом самые быстрые библиотеки для машинного обучения написаны именно на питоне.Наверное именно поэтому появились всякие tflite и более 9000 его убийц. Потому что питоннетормозил.
вообще-то, ни одной.... И ни одной уникальной, где питон был бы единственной обвязкой. Зато куча тех, к которым питон привязать никак нельзя.
Питон задуман для быстрого прототипирования, с этой задачей он справляется
> Питон задуман для быстрого прототипирования, с этой задачей он справляетсяПонимаете, пользоваться 20 лет макетным прототипом пакетного менеджера может и задолбать.
Пользователи FreeBSD смотрят на это безобразие с недоумением.
и продолжают собирать все из исходников на каждый чих...
ай маладцы :))
Как там в криокамере ? Не холодно ?
Помимо портов, есть и бинарные пакеты.
Пользователи FreeBSD все еще скачивают сорцы и бинарики, а так же распаковывают их рутом. Более убогий дизайн пакетного менеджера просто трудно придумать. Засевшие у руля анскильные лягушатники, охраняемые толпой таких же анскильных токсичных гейткиперов, живут в своем манямирке где указания на разработку дает дядя с толстым кошельком. Остальные бзд смотрят на фрю как на дно.
Что вы несёте, спаси Господь вашу душу.
pkg fetch firefox и посмотри в ps или top какой юзер это делает. Или в код посмотри. Там все везде под рутом. На тыканье лягушатника носом в его же навоз следует "we are ok", потому что дядя который платит требований по деэскалации привилегий не выдвигал.
> pkg fetch firefox и посмотри в ps или top какой юзер это
> делает. Или в код посмотри. Там все везде под рутом. На
> тыканье лягушатника носом в его же навоз следует "we are ok",
> потому что дядя который платит требований по деэскалации привилегий не выдвигал.Да нашел к чему придраться. Они сделав подобие пакетника так и не прочухали как репами пользоваться. И хренли толку с пакетника если репы для него помойка?
> Да нашел к чему придраться. Они сделав подобие пакетника так и не
> прочухали как репами пользоваться. И хренли толку с пакетника если репы
> для него помойка?а что там с репами такое? вроде нельзя миксовать порты и пакеты (или не рекомендуется), но сами то пакеты разве не полноценные граждане еще?
Ну и сколько желающих вон то в реальной эксплуатации систем применять? Репы с пакетами видите ли комплексный набор мероприятий, с делением репок по категориям, осмысленными полисями, таймлайнами поддержки, культурой менеджмента, реакцией на вулны и прочим ненужно. А просто что-то с лопаты в репы хряпнуть - замечательно, конечно, но не то.
> Ну и сколько желающих вон то в реальной эксплуатации систем применять? Репы с пакетами видите ли комплексный набор мероприятий, с делением репок по категориям, осмысленными полисями, таймлайнами поддержки, культурой менеджмента,Какие унылые фантазии с минимумом конкретики ...
> реакцией на вулны и прочим ненужно.
% pkg audit
python38-3.8.13_2 is vulnerable:
Python -- multiple vulnerabilities...
Installed packages to be UPGRADED:
python38: 3.8.13_2 -> 3.8.14 [FreeBSD]
sqlite3: 3.38.5,1 -> 3.39.2,1 [FreeBSD]Опять лужи метанизируем?
> А просто что-то с лопаты в репы хряпнуть - замечательно, конечно, но не то.
То ли дело ляпнуть на форуме свое особо ценное мнение, основанное на собственных фантазиях.
> Ну и сколько желающих вон то в реальной эксплуатации систем применять? Репы
> с пакетами видите ли комплексный набор мероприятий, с делением репок по
> категориям, осмысленными полисями, таймлайнами поддержки, культурой менеджмента, реакцией
> на вулны и прочим ненужно. А просто что-то с лопаты в
> репы хряпнуть - замечательно, конечно, но не то.Желающие были, в каких-то следовых количествах (я правда в проде лет 12 уже не видел), но докер конечно прочистил ряды совсем
> pkg fetch firefox и посмотри в ps или top какой юзер это делает.Ну-ну
PKG_CACHEDIR="/tmp-build/testpkg" REPO_AUTOUPDATE=false id -u && su -m restricted -c "whoami;id -u;pkg fetch firefox"
1001
Could not locate any suitable fingerprints matched with available hardware.
Password:
restricted
1002
The following packages will be fetched:New packages to be FETCHED:
firefox: 104.0.2,2 (55 MiB: 100.00% of the 55 MiB to download)Number of packages to be fetched: 1
The process will require 14 MiB more space.
55 MiB to be downloaded.Proceed with fetching packages? [y/N]: y
Fetching firefox-104.0.2,2.pkg: 308% 42 MiB 14.2MB/s 00:01
su -m restrictedЧто это за понос?
man su
-m Leave the environment unmodified.
> su -m restricted
> Что это за понос?Что ты там вещал за "анскильных", балабол?
Вам бы это...настольную книгу почитать бы.
Там учат как готовить.
>Пользователи FreeBSD...кто это такие ?
:3
это такие старообрядцы, которых отовсюду гонят - IBM Cloud надысь https://redd.it/x3ewxf, ранее Hetzner & Digital Ocean. Дураки вокруг, наверное.
> это такие старообрядцы, которых отовсюду гонят - IBM Cloud надысь https://redd.it/x3ewxf,
> ранее Hetzner & Digital Ocean. Дураки вокруг, наверное.Многие хостинги дают влить свой образ диска - и ипитесь там как хотите сами с ним :)
Пользователи а линуксе сейчас. Все кому не лень набижали. Опопсел.
Freebsd aka veteran unix admins.
Когда в генту появился eix, это было радостное событие. Искренне надеюсь что питон в скором времени отправится на свалку истории и с позором забудется.
Хм. О чём ты вообще говоришь? Там же просто кэш для реп и костыли для его обновления. Так portage-utils тоже раз в 10 быстрее gentoolkit, но ведь они при этом совсем не равноценны даже в пересекающейся функциональности.
> В DNF требовательные к производительности низкоуровневые функции были переписаны и вынесены в отдельные Си-библиотеки hawkey, librepo, libsolv и libcompsПрикольно, правда libsolv — это сусёвая библиотека, которой сто лет в обед, и которую использует zypper.
>Инструментарий DNF5 избавлен от привязки к PackageKitа вот это хорошо, не столько плох тормознутый dnf сколько PackageKit
сабж плюсуем.
ждем новости по избавлению линукса от раста.
Возвращение блудного сына. Запомните салаги в экосистеме GNU/Linux есть только чистый Си. Си плюс-плюс тоже не нужен.
>Си плюс-плюс тоже не нужен.Разработчики Haiku/BeOS смотрят на вас с презрением.
> Разработчики Haiku/BeOS смотрят на вас с презрением.Как там их GCC 2.95 поживает? Холят-лелеют? Гриву расчесывают?
Пожалуй худший язык программирования...
Это временно, скоро Rust будет всюду. Скриньте ;)
Что бы что то написать на Rust, это сперва должно быть написано на любом другом языке, и только потом переписано на Rust.
Ибо думать над задачей и синтаксисом Rusta одновременно не принято.
Впрочем, критика Rusta в основном связана с программированием на нём, а таки написанное ПО на Rust'е уже не ругают.
Доля правды в этом есть. Многие утилиты переписывают на Rust. Но с другой стороны, они были не просто переписаны на Rust, а были чем-то улучшены и доработаны. Плохо что ли? Хорошо!
> они были не просто переписаны на Rust, а были чем-то улучшены и доработаны.Так всегда и бывает, когда с одной платформы на другую переносят, или на другой язык.
Кто может подсказать как в убунте отключить авто обновления? Отключал а они все равно лезут
Вот ОНИ наверняка смогут подсказать.
https://ubuntu.com/pricing/infra
> Кто может подсказать как в убунте отключить авто обновления? Отключал а
> они все равно лезутСнеси автоапдейтер, чудак. Кстати еще 1 пример чудного глюкала на питоне. Более глючной софтины я просто не видел. Особенно прикольно он систему апдейтит, работает раз через три едва ли.
Это сообщение Шаттлворт не одобряет.
Какой-то умник затянул таки в федорорепы zypper, но, видимо, у красношляпошных лютый NiH-синдром, раз они не хотят пробовать прикрутить более вменяемый, более быстрый и УЖЕ ГОТОВЫЙ инструмент, после некоторой адаптации.
Накотец-то, можно будет этот значимопробельный отстой вообще из системы вынести.
Питон, в целом, тормозящая хрень — что в опенсорсе, что в проприетарщине. Касательно первого взгляните на отзывчивость Recoll. Касательно второго, оцените стабильность и скорость HPLIP-gui. Это полный швах!В мусор все интерпретируемые прослойки и раздутое компилируемое ПО на их основе. Только Си. Для возвышенных — Vala. Точка. Расходимся.
полностью поддерживаю.. только чистый си, вала, ну и лисп с ассемблером, все остальное шлак.
> Только Си. Для возвышенных — Vala.Спалился, любитель GTK. Для вас, любящих лепить ООП и GUI на макросах, есть отдельная палата в дурке.
> и скорость HPLIP-gui. Это полный швах!А зачем он нужен? У cups вебфэйс есть, многие вещи в диалогах печати прог настраиваются, да и HPLIP для многих хьюлетов не сильно вперся.
Внезапно, чтобы корректно установить проприетарное г.но от HP, чтобы МФУ HP, внезапно, заработал.
Питон - самый популярный ЯП!
Миллионы не могут ошибаться)))
Отказаться от самого популярного языка програмирования - шаг вперёд и два шага назад!
> Отказаться от самого популярного языка програмирования - шаг вперёд и два шага назад!Зачетный аргумент, из разряда "д@рьма на планете больше чем золота".
Милионы не могут ошибаться!!1!))))
> Милионы не могут ошибаться!!1!))))А про мух почему заскипано? :)
Breaking News: https://packages.debian.org/bookworm/pacman-package-manager
Если не умеешь программировать, то тебе и ассемблер не поможет добиться скорости выполнения.
> Если не умеешь программировать, то тебе и ассемблер не поможет добиться скорости
> выполнения.Если не умеешь программировать, пакетный менеджер программить явно рановато. А в именно этом контексте - питон еще и не особо совместим между версиями, что в именно пакетном менеджере вообще достаточно чревато. Как вам идея что в процессе апгрейда развалится сам пакетник по причине "версия питона не та"? Наверняка майнтайнерам этого бидонохлама было очень интересно апдейты между версиями ос делать, балансируая на этом канате без страховки над пропастью.
Я ломал portage при обновлении по причине «версия glibc не та». В нероллингах такой проблемы как бы нет - её замели под ковёр. :)
> Я ломал portage при обновлении по причине «версия glibc не та». В
> нероллингах такой проблемы как бы нет - её замели под ковёр. :)Да вот видите ли апгрейдер убунт на питоне имеет довольно забавные повадки.
1) Качает свежую версию сам себя сначала. Ну, логично, для апдейта имеет использовать последнюю версию апгрейдера, где баги починены. Кто ж спорит. В теории.
2) Так, что такое? Только что утверждало что "обнаружен новый релиз" а теперь стало "апгрейды не обнаружены"?! Это вообще как?!
3) Окей, пинаем это месиво в консоли... а там... вау! Стектрейсище на три страницы в одном из компонентов апдейтера, он оказывается лопается с брызгами просто в хлам, но поскольку проверку ошибок (точнее ее отсутствие) делали пиотнисты, которым главное же не париться, там просто ломается execution flow к чертям и оно не придумывает ничего умнее как на паре уровней выше соврать что новых версий дескать нет. Хотя 5 минут назад до апдейта этого крапа были, ага. Да, кстати, об этом вы никогда не узнаете если вы не являетесь любопытным системщиком решившим из принципа докопаться что это вообще за треш такой странный в системе бывает.
4) Ах да, после длинных раскопок в поискаре и чесания репы на стектрейс который вообще не означает ничего осмысленного мы можем наконец найти хинт - оказывается, эти три страницы хотели сказать "у вас версия питона не та".
5) О том почему апдейтер качает апдейт на себя который не может работать в апдейтуемой системе мы подумаем как нибудь потом. Зато кодеры не напрягались, бжад.И потом эти питонос*ки еще удивляются что их ценные зады, видите ли, за что-то не лю. За вон то!
TL;DR: ну а вот отваливается же, при том в stable, хоть оно и не роллинг. Либса в этой части сильно менее грабельный компонент.
Понятно, что Питон с его версиями лишь добавляет точек отказа к уже возможным.
Наличие питона на сервере - это не только точка отказа. Это дыра в безопасности.
> Наличие питона на сервере - это не только точка отказа. Это дыра в безопасности.Ну да. Скрипткидисы на бидоне кучу хайповых one-stop тулсов для ламо сделали. У них такие морды интересные, наверное, когда их пафосный мегатул, где уже весь мир под ногами вдруг ... не запускается? И вот системный бог оказывается без своего тулсета жалким слизняком, который шагу ступить не может.
> Понятно, что Питон с его версиями лишь добавляет точек отказа к уже возможным.Ну да. При том в убунте это настолько хорошо получалось что мой опыт с их апдейтером это "случайно упал своим лицом на мой кулак, и так три раза подряд". В смысле примерно вон тот по смыслу маневр это их чудо делало, наверное, раза три с разными версиями убунт. Я не понимаю как можно быть настолько стабильным в топтании по одним и тем же граблям, наверное мой склад ума чем-то отличается от питоняш, так что я не считаю вон ту работу софта нормальной. Но в конце концов проще оказалось переключать репы вручную - это единственное что реально делал этот оверинженернутый кусок глюкала. Остальное по факту делал (бы) пакетный менеджер пнутый этим глюкалом, только до этого чаще всего дело не доходило, т.к. оно упало еще до этого момента. Зачем нужна вот именно такая системная автоматизация - черт бы ее знает. Мне что, на картишках раскидывать пройдет ли у меня апдейт на вон той машине или нет? :)
Если бы умели,то не использовали бы этот недоязык Питон с самого начала.
На го бы переписали.
Тогда пускай полностью на ассемблер переходят))
Если не умеют программировать, то и ассемблер им не поможет добиться скорости выполнения)
Будет как с RPM5?
А что было с RPM5?
Один маргинальный местный дистрибутив под звук фанфар перешёл с RPM4 на RPM5, а потом без лишнего шума обратно, потому что добрый дядя из RetHat не хотел за них поддерживать, а сами они не умеют. mikhailnov расскажет подробнее. ;)
Миллионы не могут ошибаться, так что это ни зря)