LINUX.ORG.RU
ФорумTalks

Гентушники, есть чё по мелочи?

 ,


1

4

Думаю, большинство гентушников согласится, что невыносимо тормозной ПМ - это вторая по неприятности проблема генты. Так как сами разработчики портежа не хотят лезть в это адское спагетти из пистона и баша, выдвигаю такое предложение: насобирать на бутылку «Жигуля» и нанять одного-двух пряморуких разрабов, которые полностью перепишут portage, сохранив всю его функциональность.

Конкретных мыслей нет, но я думаю, что это должно быть что-то на C/C++ с феерической многопоточностью и загоном ебилдов в какую-нибудь БД с простым интерфейсом для включения новых ебилдов (т.е. по сути написание новых ебилдов должно быть сведено к простому заполнению полей БД или как оно там называется, я в базах не дровосек).

Кто что думает?

P.S. Если насобираем на две бутыки «Жигуля», то можно будет ещё попробовать прикрутить к новому ПМ (назовём его кодовым именем «Portak») модуль полного взаимопонимания с dpkg и rpm. Чтобы можно было грабить PPA и вообще.


Ответ на: комментарий от Pinkbyte

распараллеливание - это жизненно важная вещь.

с которой лучше всего справляются инструменты оперирующие иммутабельными сущностями

swwwfactory ★★
()
Ответ на: комментарий от init_6

Ага а Global Interpreter Lock (GIL) в python всяко способствует распараллеливанию.

Есть еще PyPy, куда недавно добавили STM

feofan ★★★★★
()
Ответ на: комментарий от ZuBB

для меня ты своими повторяющимися ответами о paludis, squashfs и portage-classic ничем не отличаешся от ТСов тех тредов ибо твои советы не помагают, иначе бы количество нитья уменьшалось. а этого вроде бы не наблюдается.

squashfs узко решает несколько проблем с во первых i/o (и да squashfs читается всяко быстрее обычных фс. надо пруфы? бери и сам сравнивай) во вторых с упаковкой всего /usr/portage в один маленький по объему сжатый контейнер. И надо быть конченным идиотом чтобы от squashfs ждать еще чего то помимо того что он может дать.

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

Если её не читать вовсе там ничего нет.

init_6 ★★★★★
()
Ответ на: комментарий от feofan

Есть еще PyPy, куда недавно добавили STM

Ну да! Замечательный pypy который собирается на обычном core2 с 4мя Гб озу сколько там дней? :)

init_6 ★★★★★
()
Ответ на: комментарий от feofan

проблема не дереве.

Можно добавить разные БД в качестве бэкэнда (это хорошее архитектурное решение и не должно слишком усложнить код)

можна. но для начала нужно хотя бы одну.

извини но мне кажется что я дальше пошел в своих поисках. дискуссия на эту тему пожалуй бессмысленна

ZuBB ★★★★★
()
Ответ на: комментарий от init_6

Ну да! Замечательный pypy который собирается на обычном core2 с 4мя Гб озу сколько там дней? :)

ХЗ, еще не собирал =)

feofan ★★★★★
()
Ответ на: комментарий от ZuBB

мне кажется что я дальше пошел в своих поисках

Так ведь я и не спорю.

проблема не дереве.

А в чем? Просвети.

дискуссия на эту тему пожалуй бессмысленна

Отнюдь =) Ты можешь поделиться интересной информацией.

feofan ★★★★★
()
Ответ на: комментарий от feofan

ХЗ, еще не собирал =)

Ну я собирал. Так вот если у тебя озу (не всего в сумме и не свопа а именно озу) < 4Гб ты сразу в пролете. Если озу всунуто именно 4Гб это нижний требуемый предел. А сама сборка по времени… Короче там дольше чем gcc, llvm clang, libreoffice и все остальное такой же жирноты вместе взятое и еще и умноженное раз в 5 :))

init_6 ★★★★★
()
Ответ на: комментарий от ZuBB

и что же я пропустил?

Да чуть менее чем все. В той теме вполне популярно расписаны причины „тормозов“. И да portage можно и нужно оптимизировать. И сам себя он не оптимизирует и не ускорит.

init_6 ★★★★★
()
Ответ на: комментарий от feofan

Жесть какая =) Надо попробовать. Благо у меня 8 Гб ОЗУ

Забей! Уж если так хочется то pypy-bin решает. ;)

init_6 ★★★★★
()

portage — практически идеальный ПМ для source-based дистрибутива.

А низкая скорость работы является платой за большие возможности и гибкость. Так устроен этот мир и по-другому не будет.

athost ★★★★★
()
Ответ на: комментарий от athost

А низкая скорость работы является платой за большие возможности и гибкость. Так устроен этот мир и по-другому не будет.

Чтоб это понять сперва нужно это понять…

Помимо всех прочих ограничителей будет либо много фич но маленькая скорость либо мало фич зато офигенная скорость.

Так устроен этот мир и по-другому не будет.

Подписываюсь. И да природу не обманешь.

init_6 ★★★★★
()
Ответ на: комментарий от feofan

А в чем? Просвети.

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

upd: также декларативная часть ебилда никак не структурирована, это простой текст

Отнюдь =) Ты можешь поделиться интересной информацией.

*по теме* топика я коротко написал здесь.

ZuBB ★★★★★
()
Последнее исправление: ZuBB (всего исправлений: 3)
Ответ на: комментарий от ZuBB

изза очень большого количества IO-операций

Не очень критично ввиду того, что существуют способы уменьшить это влияние. И значительных результатов они не показывают. Хотя, конечно, кешировать дерево в БД идея хорошая.

и неправильного (и изза того медленного) алгоритма который считае зависимости.

Это очень смелое утверждение. Но думаю, оно небезосновательно. Хотя я бы не стал утверждать столь категорично. Думаю алгоритм возможно улучшить, но эта задача отнюдь не тривиальна. Согласен, что двигаться нужно в этом направлении.

*по теме* топика я коротко написал здесь.

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

Я вот предлагаю участникам дискуссии подумать над использованием для такого проекта графовой БД. Возможно, она может сильно ускорить расчет зависимостей.

feofan ★★★★★
()
Ответ на: комментарий от feofan

Не очень критично ввиду того, что существуют способы уменьшить это влияние. И значительных результатов они не показывают. Хотя, конечно, кешировать дерево в БД идея хорошая.

я бы назвал это так: все в одном месте и с единым интерфейсом доступа

Хотя я бы не стал утверждать столь категорично

см оп здесь

впечатляющих результатов возможно достичь лишь не реализовав большинство возможностей портежа.

так ли это мы можем узнать лишь только взявшись за дело

Я вот предлагаю участникам дискуссии подумать над использованием для такого проекта графовой БД. Возможно, она может сильно ускорить расчет зависимостей.

годная идея. я там одну такую вспоминал. но она на джава. а я как ты уже понял за минимизацию коливества зависимостей и жырноты рантайма

ZuBB ★★★★★
()
Ответ на: комментарий от ZuBB

я там одну такую вспоминал. но она на джава. а я как ты уже понял за минимизацию коливества зависимостей и жырноты рантайма

Это всё здорово, но во-первых, БД, которую ты вспомнил — не единственная графовая БД(Например, ребята из OpenCOG пишут гиперграфовую БД на C++), а во-вторых, ради ускорения на порядки можно и потерпеть жирный рантайм.

feofan ★★★★★
()
Ответ на: комментарий от feofan

но во-первых, БД, которую ты вспомнил — не единственная графовая БД

я понял. здесь более меня в теме. в том треде мне предлагали mongo как самую лучшую nosql db. итого в зависимостях сама монга и в8. это минимум 30мб только исходников. я думаю большинство гентушников были бы против пм который имеет такие депсы. это так просто как пример

ZuBB ★★★★★
()
Ответ на: комментарий от ZuBB

Чудес, к сожалению, не бывает. Либо использовать чужие наработки (и тянуть их по зависимостям), либо клепать собственные велосипеды и долго и упорно их тестировать и дебажить. И всё равно давно зарекомендовавшие себя проекты окажутся быстрее =)

feofan ★★★★★
()
Ответ на: комментарий от feofan

все верно говоришь. держы плюс за адекватность.

к сожалению я пока еще верю в sqlite и не рассматриваю другие варианты. но готов выслушать любые советы

ZuBB ★★★★★
()
Ответ на: комментарий от Pinkbyte

epatch_user - функция из eutils eclass и она работает в любом EAPI.

А, вот как. Я не пишу ебилдов, прости.

Реализовать поведение как у paludis можно легко через /etc/portage/bashrc

И как ему там объяснить, что нужно брать патчи? Я погрепал man portage, и не нашёл, чтобы там освещалась эта тема.

Deleted
()
Ответ на: комментарий от Deleted

А, вот как. Я не пишу ебилдов, прости.

Лень и неграмотность не есть хорошие спутники среднего gentoo-шника в вакууме. Прости.

И как ему там объяснить, что нужно брать патчи? Я погрепал man portage, и не нашёл, чтобы там освещалась эта тема.

Не читай сразу отвечай!

init_6 ★★★★★
()
Ответ на: комментарий от init_6

Global Interpreter Lock (GIL) в python

Для Python 3 - неактуально

Не считая того что новых уникальных „прелестей“ добавляет и eapi 4, 5. И вот когда люди начинают сравнивать поведение „старого“ portage, со своими старыми eapi, и нового, при этом не учитывая того что в новом eapi гораздо больше фич, вот тогда и начитается нытье про „тормоза“.

Плюсую.

Pinkbyte ★★★★★
()
Ответ на: комментарий от FRCTLL

Зачем блокировки?

Ну ок, реализуй подобное без блокировок и синхронизации тредов...

Pinkbyte ★★★★★
()
Ответ на: комментарий от init_6

Лень и неграмотность не есть хорошие спутники среднего gentoo-шника в вакууме. Прости.
Лень

А, то есть, знать последние EAPI, eutils — это норма для среднего гентушника? А в мейнтейнеры среднему гентушнику не надо записаться?

Неграмотность

Уж не тому, кто по-русски с трудом пишет, меня в это тыкать.

Не читай сразу отвечай!

Какой догадливый. Я правда не читал всё, что после пинкбайтового поста идёт.
Ну давай пройдёмся по твоим ссылкам…

https://wiki.gentoo.org/wiki//etc/portage/env

Какое отношение она имеет к патчам?

http://www.funtoo.org/index.php?title=Localpatch_(Tutorial)

Ты опять сидишь на стуле ушами и читаешь посты попой? Обязаловка наличия epatch_user в ебилде есть недостаток, который Pinkbyte предложил компенсировать как-то через /etc/portage/bashrc

http://www.gentoo.org/doc/en/handbook/handbook-amd64.xml?part=3&chap=6#do...

Статья про глюкодром имени генты мне очень помогла релевантной ссылкой на кусок документации про назначение /etc/portage/bashrc, который, однако, не проясняет, patch туда вписывать, или epatch или ебилдовы функции оверолоадить, чтоб юзерпатчи накладывались наконец.
Я не могу описать словами, с какой пользой я провёл эти восемь минут.

Deleted
()
Ответ на: комментарий от Pinkbyte

Сам проверял? За мегабаксом же проверять да проверять. Но всё равно спасибо за ссылку, когда понадобится, расковыряю.

Deleted
()
Ответ на: комментарий от Deleted

А, то есть, знать последние EAPI, eutils — это норма для среднего гентушника? А в мейнтейнеры среднему гентушнику не надо записаться?

Я что то говорил про знание eapi или eutils? Нет? Так зачем ты утрируешь? Тебя не устраивает то, что в конкретном ебюлде нет user patch-ей? Так вот есть несколько путей первый срать в официальную багзиллу по поводу отсутствия поддержки user patch-ей в конкретном ebuild-е и надеяться на чудо второй забить на официальную багзиллу и в своём уютном оверлейчике дописать сраные пару строчек к готовому ebuild-у из основного дерева.

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

Уж не тому, кто по-русски с трудом пишет, меня в это тыкать.

Прости но отмазка „я тупой“ давно не прокатывает а тем более в gentoo. Выбрал gentoo изволь осиливать или вали в свои уютные {убунты/симьорки максимальные/арчики} или еще куда.

Ну давай пройдёмся по твоим ссылкам…

Какое отношение она имеет к патчам?

Еще раз не читай?

А ЕМНИП чуть ли не на каждом сайте относящемся к тематике gentoo уже написано как делать user patches и индивидуальные {CFLAGS/CXXFLAGS/CPPFLAGS/LDFLAGS} для каждого ebuild-а по отдельности.

Ты опять сидишь на стуле ушами и читаешь посты попой? Обязаловка наличия epatch_user в ебилде есть недостаток, который Pinkbyte предложил компенсировать как-то через /etc/portage/bashrc

А ты опять видимо думаешь жопой.

epatch_user это одновременно и хорошо и плохо. А вот на сколько epatch_user {хорошо/плохо} в каждом конкретном случае решать майнтрейнеру конкретного ebuild-а а не тебе или мне. Если ты с этим не согласен вали в свои оверлейчики в делай как тебе угодно.

<Уголок полного идиота> epatch_user это хорошо потому что плюя на аппстрим юзеру самому можно применять любые патчи к ebuild-у.

epatch_user это плохо потому что проблемы сборки и работы программы от любого патча примененного к ebuild-у ложатся тоже на плечи майнтренера ebuild-а в основном дереве. А оно ему такие заботы нафиг не впало. Ему хватает своей работы. </Уголок полного идиота>

init_6 ★★★★★
()
Ответ на: комментарий от feofan

Память дешевеет

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

der_looser ★★
()
Ответ на: комментарий от zunkree

Вот не думал что так скажу, но два чая этому господину, истину глаголет.

Самое печальное что это абсолютно очевидная вещь. Как и то что нынешний portage с поддержкой eapi 4, 5 выглядит тормозом по сравнению со старым portage и с поддержкой eapi 2, 3. Но тут почему-то все обращают внимание на „portage тормозит“ однако не на то что „новый eapi по сравнению со старым сделал возможным…

init_6 ★★★★★
()
Ответ на: комментарий от der_looser

это никак не оправдывает тетрис, который два гига оперативки сжирает.

Не надо утрировать. Я не призывал полностью забить на потребление памяти. Я говорю о том, что за всё нужно платить. За скорость выполнения чаще всего платить приходится памятью. Иногда такие затраты оправданы, иногда — нет.

feofan ★★★★★
()
Ответ на: комментарий от argin

ты неправ - он намного лучше, хотя не намного быстрее

т.е. в среднем по палате где то так же, если не хуже, поскольку поддержка новых eapi в нем хуже.

init_6 ★★★★★
()

собирай уже на 3 бутылки жигуля и пусть тебе присобачат нормальный APT в твою генту

Deleted
()

Конкретных мыслей нет, но я думаю, что это должно быть что-то на C/C++ с феерической многопоточностью

А как же paludis? Правда, я так и ниасилил завести exherbo.

ekzotech ★★★★
()
Ответ на: комментарий от init_6

я имел ввиду установку по клику мыши,максимум 1 команды терминала,а не 1001 телодвижение .

erzent ☆☆
()
Ответ на: комментарий от vurdalak

у портежей свои минусы,основной это то,что большинство программ типа 1С сделаны под rpm,и установка например обновы 1С это целая история из 1001 телодвижения.Вот если бы портеж позволял ставить в /usr/local or /opt rpm пакеты без переделки,цены бы не было .

erzent ☆☆
()
Ответ на: комментарий от erzent

Либреофис например очень даже нормально ставят из rpm через ебилд. Эти проблемы касаются проприетарного ПО, которого в репозиториях нет и поддержка которого на уровне пакетного менеджера не требуется. В таких случаях ничего не мешает поставить из портежа rmp, а уже им поставить 1с

vurdalak ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.