LINUX.ORG.RU
ФорумTalks

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

 ,


1

4

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

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

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

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


Одной из проблем является вызов bash - не самое быстрое решение. Они начали реализовывать libbash (и почти даже закончили), но пока всё тормознулось. Вот дерево git - http://git.overlays.gentoo.org/gitweb/?p=proj/libbash.git;a=summary Он, кстати, написан на С++ (то есть, можно использовать как в portage, так и в paludis).

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

Это, конечно, совсем уж идеальный вариант, но маловероятный.

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

Ты можешь смотреть статистику сборки через qlop. Например:

qlop -gHt gcc
gcc: Fri Aug 31 01:41:30 2012: 29 minutes, 2 seconds
gcc: Fri Aug 31 02:24:53 2012: 21 minutes, 55 seconds
gcc: Fri Aug 31 03:04:51 2012: 21 minutes, 55 seconds
gcc: Fri Aug 31 03:44:49 2012: 22 minutes, 1 second
gcc: Fri Aug 31 19:33:01 2012: 21 minutes, 35 seconds
gcc: Sat Oct 13 09:37:26 2012: 27 minutes, 8 seconds
gcc: Sat Oct 13 10:33:22 2012: 24 minutes, 6 seconds
gcc: Sun Dec  2 16:14:53 2012: 24 minutes, 6 seconds
gcc: Fri Jan 25 02:59:39 2013: 29 minutes, 49 seconds
gcc: Tue Feb 19 10:50:10 2013: 27 minutes, 10 seconds
gcc: Wed Mar  6 23:26:00 2013: 28 minutes, 34 seconds
gcc: Mon Mar 25 07:09:41 2013: 5 minutes, 42 seconds
gcc: Mon Mar 25 07:22:08 2013: 7 minutes, 6 seconds
gcc: Tue Apr 16 04:24:08 2013: 34 minutes, 21 seconds
gcc: Sun May  5 23:45:43 2013: 29 minutes, 36 seconds
gcc: Mon May 20 20:16:04 2013: 31 minutes, 40 seconds
gcc: Mon May 20 21:57:02 2013: 28 minutes, 10 seconds
gcc: Fri Aug 16 03:56:14 2013: 43 minutes, 1 second
gcc: Fri Aug 16 06:15:49 2013: 25 minutes, 16 seconds
gcc: Sat Aug 17 09:23:35 2013: 1 hour, 3 minutes, 5 seconds
gcc: 20 times

Как видишь, даже на моём одном компе сборка очень сильно варьировалась во времени, в зависимости от текущей загрузки компа по CPU/IO/RAM.

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

Надо учитывать возможности компьютера, объемы проекта, объемы каждого отдельного файла, наличие тяжелых шаблонов, оптимизаций, выставленных флагов сборки проекта, и производительноти конкретной версии компилятора, libc и вообще ОС... Лучше занять свое время чем-то более полезным)

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

ЕМНИП, megabaks показывал, как такое сделать в portage

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

К примеру открываем wiki по поделию даниэльки и оба на Localpatch (Tutorial), Localpatch

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

Я переписывать portage на другом языке не готов, а с питоном знаком почти никак. Так что - фэйл :-(

Так уже есть paludis

А вообще всем кто решит изобретать portage по новой я настоятельно рекомендую начать отсюда portage-classic а о том что это такое можно почитать вон там от самого Даниэльки

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

а если пк был в ждущем режиме то получится как то так

mesa: Wed Oct 23 17:30:12 2013: 3 hours, 56 minutes, 16 seconds

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

Лучше хотя бы тем, что применяет user patches независимо от того, дописали ли мейнтейнеры ебилда epatch_user в этот ебилд (а ещё в portage есть ебилды, которые написаны на древнем EAPI, в котором нет epatch_user).

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

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

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

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

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

Однако среднее всё равно около получаса. Точное никак не вычислить, а если даже попытаться это сделать, то оно по времени будет ещё дольше, чем сама сборка.

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

Так потому здесь и написал, раз уж желающие появились что-то делать.

Ага в кои то веки в разделе talks и внезапно „что-то делать“ а не траллить ЛОЛЛ!!!ОДИНОДИН

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

Дык может не надо каждый раз вызывать bash? И вообще, лезть в ебилды? А при каждом обновлении дерева делать единократно расчет зависимостей, засовывать всю нужную инфу в быструю БД.

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

А при каждом обновлении дерева делать единократно расчет зависимостей, засовывать всю нужную инфу в быструю БД.

По аналогии с eix но для зависимостей? Тогда начнут ныть что „обновляет зависимости после emerge --sync шибко долго с этим надо что то делать“ :)

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

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

XVilka ★★★★★
()

Жизнь на Марсе есть!

есть. по мелочи. среди ней есть крайне мелкая базаsqlite, охапка руби скриптов которые нужно переписать на питоне(С/С++ не планируется, но если будет рабочий код, никто никому не будет запрещать реализацию на $your_favourite_prog_lang) и охапка идей которые хочется обсудить и реализовать.

но денег нет, а есть хочется, соответственно свободного времени тоже нет. и в ближайшие пару месяцяв его тоже не предвидится.

недоанонс, сырцы

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

Правда, не совсем ясно, что делать с ручным редактированием ебилда прямо в /usr/portage или /var/lib/layman

Накропать гуёвую программу для работы с БД.

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

ничего из этого не будет. слишклм много на питоне написано для генту.

и да почему руби? думаю что если таки переписывать то нужно просмотреть всех кандидатов

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

Ну, с консольным вариантом, естественно.

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

То, что там слишком много условий, включая circular dependency, sub-slot blockers и т.д.

Может, ты имеешь в виду возможные пересечения между потоками?

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

А вообще всем кто решит изобретать portage по новой

как ты заеб@л уже с этим portage-classic! в каждый тред его суешь.

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

как ты заеб@л уже с этим portage-classic! в каждый тред его суешь.

А вы во первых „заеб@ли“ ( <-- не моё я просто процитировал ) матерится а во вторых если и начинать исправлять и делать по новой то portage-classic это самое оно.

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

А вы во первых „заеб@ли“ ( <-- не моё я просто процитировал ) матерится

и много же я матерюсь в рамках этого треда/форума?

а во вторых если и начинать исправлять и делать по новой то portage-classic это самое оно.

да-да. давайте вернёмся в каменный век и переизобретем все заново.

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

и много же я матерюсь в рамках этого треда/форума?

Это если что было сказано не одному тебе. Да erzent ?

да-да. давайте вернёмся в каменный век и переизобретем все заново.

Вот именно в данном случае это лучше чем перевод существующих костылей на рельсы другого языка программирования.

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

Я не говорю, что python - лучший язык в мире, более того, я так даже не считаю. Просто почему-то думаю, что проблемы portage отнюдь не в ЯП. Может, nosql-субд и правда будет кстати... но тогда редактировать ебилды будет сложнее. :)

До этого, начитавшись лора, думал, что java жрёт память и тормозит всегда... когда начал на ней писать сам, понял - что бывает как хороший код, так и плохой. Ну и да, в целом jvm прожорливая, но это расплата за надёжность.

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

ой-вей какой нежный. небось в ирл ни одного мата никогда не произнес.

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

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

Ушел с Амарока на клементин (форк старого амарока), не из-за MySQL, а из-за гигантизма в интерфейсе и накручивания ненужного мне функционала, поэтому не могу оценить. А есть проблемы?

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

что бывает как хороший код, так и плохой на любом яп

дополнил своим IMO

ZuBB ★★★★★
()

Здравая мысль посмотреть где именно и больше всего тормозит.

Хороший алгоритм и на питоне будет летать.

Мне кажется тормоза идут от индикатора расчета зависимостей \|/- ))) шутка...

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

Серверная БД зачастую быстрее безсерверной (поправьте, если ошибаюсь). Расплатой обычно является повышенное потребление памяти. Память дешевеет, поэтому я считаю такую цену оправданной. Не вижу в этом подходе ничего плохого.

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

,а хочешь тулзу на том яп которым владеешь на среднем уровне.

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

я ни разу не спец в С/С++, мое знакомство с ним закончилось после курса в универе. но думаю что не на пустом месте о нем столько «лестных» отзывов

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

Да, именно их. ИМХО блокировки тут много сэкономленного времени сожрут. Но тем не менее распараллеливание - это жизненно важная вещь.

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

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

Просто мне действительно надоели очередные бессмысленные топики на тему „portage тормозит“ в то время как все беседы как правило скатываются к „portage тормозит а патаму шо петоны“ хотя в то же время все прекрасно знают о существовании paludis но почему то скромно умалчивают о том, что и он ВНЕЗАПНО не решает проблему тормозов… а и если решает то не целиком и в среднем по палате выходит так же.

Так возможно „тормоза“ таки связаны никак не с python а их причина во всех тех возможностях которые предоставляет конкретная версия eapi в portage? И в подтверждение этой мысли вот вам на почитать и подумать Why has portage become so slow с конкретными примерами, мыслями и даже ВНЕЗАПНО ссылками на багзиллу и патчами.

init_6 ★★★★★
()

БД

sqlite

C/C++

язабан
Bash/Python/Perl/Ruby или Java - но только на одном языке

грабить ppa

ставим ебилды dpkg rpm
делайм свой аналог apt с шл... ну вы понели
профит!

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

Здравая мысль посмотреть где именно и больше всего тормозит.

Открой пост TomWij в теме „Why has portage become so slow“ внимательно его прочитай, найди ссылку на его патчик, примени патчик и смотри сколько тебе влезет.

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

Серверная БД зачастую быстрее безсерверной (поправьте, если ошибаюсь)

править не буду ибо в базах не спец.

Расплатой обычно является повышенное потребление памяти. Память дешевеет, поэтому я считаю такую цену оправданной. Не вижу в этом подходе ничего плохого.

выбор любой зависимости должен быть взвешенным. иначе можна закончить тем что после запуска пм фф/хром будет прикончем по оом_кил.

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

можна закончить тем что после запуска пм фф/хром будет прикончем по оом_кил.

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

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

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

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

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

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

Просто мне действительно надоели очередные бессмысленные топики на тему „portage тормозит“ в то время как все беседы как правило скатываются к „portage тормозит а патаму шо петоны“ хотя в то же время все прекрасно знают о существовании paludis но почему то скромно умалчивают о том, что и он ВНЕЗАПНО не решает проблему тормозов… а и если решает то не целиком и в среднем по палате выходит так же.

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

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

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