Переписать Portage на Go, почему нет?

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

предлагаю заодно написать на go posix shell с некоторым количеством башизмов :}

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

И назвать gosh, а потом сразу репозиторий с внешними темами и плагинами под него - oh-my-gosh.

Расчет зависимостей, как результат - очень стабильная работа системы не считая оверхеда от разрешения конфликтов. В арче стабильности много?

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

вот что-то не заметно как-то переписывают, скорее наоборот, даже Perl и Fortran вполне себе в ходу

apt в debian

Я ставил как-то yum и guix.

я так понимаю ТС в рамках своего «проекта» допилит все остальное: aplha, hppa, ia64, mips, sparc?

vim, redhat, NeoVim, VimCast и т.п.

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

Элементарно, Ватсон! Вы ссыте мне на ботинок, а я Вам в карман. (с)

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

Балбес, никто рабочий код просто так не переписывает, даже если это тормозное говно на коболе. Нужны очень-очень веские причины для такого решения. Тем более, если переписывать собираются на вчера вылупившийся недоязычок, в котором еще сто раз API поломают.

Ну да, а apt куда девал?

На мой взгляд, справедливо переложить ответственность за разрешение зависимостей с пакетного менеджера на мейнтейнера самого пакета. Так, что в этом плане пакетная система арча мне нравится намного больше.

sounds like exi, т.е. можно готовое взять отчасти. На exi правда Андрес забил давно.

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

Давно умеет. Третий год софт под арм кросскомпиляю.

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

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

Замечательная идея. Давайте оставим сложность той же, но добавим ещё проблем с распределёнными вычислениями (а они будут: 1 сервер много гентушников не выдержит).

https://github.com/qiaomuf/libbash но оно слегка мёртвое.

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

В каком-нибудь арчлинуксе это просто.

Баш выкинь для начала. Возможно, ты хочешь посмотреть на проекты вроде guix и nixos.

божички ты тупой или что?

берем весь бардак скриптов сборки
... зачем я описываю,и зачем вы прикидываетесь идиотами считая собеседника идиотом

я говорил о банальной «поикоподобной» системе сборки,и БИНАРНОМ протоколу обращения к серверу,чтоб ненадо было миллион запросов на сборку пакета(загрузка всех скриптов сборки вместе с глобальными и «патчами»)....достаточно убрать текстовый протокол запросов что есть щас-чтоб ускорить в разы систему...и оптимизировать все запросы-чтоб было не сотня запросов,как щас на один пакет,а один-сотня щас потмоу что ищется высокоурвоневые зависимости/сценарии/переменные/патчи...которые ссылаются еще на другие все нужно проверять и на сервере и у клиента-поэтому все так медлено

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

сделать «препостройку» деревьев и зависимостей и версий...всего дерева-на сервере

тогда сервер для постройки всех возможных деревьев зависимостей portage попадёт в первую тройку следующей редакции top500

Одна из догм gentoo это свобода выбора

тут что-то не так

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

обработав текстовую информацию

problem is here

Объясняю на пальцах: Есть N пакетов, у каждого в среднем M юз флагов, число комбинаций уже N*M, далее у каждого пакета K зависимостей, а у зависимостей тоже всё аналогично. Пусть глубина дерева будет L. Теперь получаем алгоритмическую сложность перебора всех вариантов: O(M*N*K*L), что в худшем случае дает нам O(N^4).

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

А ещё кроме алгоритмической сложности есть проблема в том, что ебилды по сути дела баш скрипты, а хорошей быстрой libbash для парсинга этой хрени я не видел.

ебилды по сути дела баш скрипты

а что если переделать формат ебилдов на манер юнитов systemd?

go и так в составе gcc есть.

Как уже сказал derlafff, проблема тормознуточти не в питоне, а в реализации алгоритма.

Ты вместо диванного «а давайте», возьми, да запили, выложи, напиши ебилд, запость на BGO, оттесть, а сообщество само для себя решит — пользоваться этим или нет. Пользователи-то всяко найдутся.

Ах да, если примут в апстрим и заменят питоний портаж поделкой на го, я тебя возненавижу, это я могу обещать. :3

Есть N пакетов, у каждого в среднем M юз флагов, число комбинаций уже N*M

или N*2^M ?

Чтобы всё ускорить - надо zypper запилить в генту.

2*M=X

Это же ассимптотика, тут сами числа мало значения имеют.

у меня вообще ощущение, что портеж тормозит главным образом из-за кучи лишних проверок

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

ну вот нахрена ему этот оверлей и кривой пакет? и подозреваю, что и в просчёте зависимостей он так же проверяет всё что нужно и ненужно

сравни что поддерживает Go и что поддерживает Gentoo... и проникнись иронией моего вопроса :)

теоретически, если использовать те же алгоритмы, которые используются сейчас питоном, но будут использоваться будучи скомпилированными — работать быстрее будет?

В рамках статистической погрешности. Там узкие места в другом: IO - много мелких файлов, парсинг этих множества файлов, и расчет вышеназванного графа, который очень плохо параллелится. Если рассчитаные графы хранить станет сильно лучше (особенно, если доступ будет через специально рассчитаный на такое инструмент). Простое переписывание на другой язык ничего не даст. Но ты пиши, кто тебе запретит? =)

IO - много мелких файло

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

так что io там особой роли не играет, всё дело в алгоритмах

Не, я про общее количество возможных вариантов сборки пакета с M юз-флагами. То есть, всё ещё хуже.

Странно, когда сидел на одноядерном атлоне, обработка зависимостей мне не казалось такой долгой как сейчас. Видимо, и пакетов сейчас у меня больше в системе, и юз-флагов у каждого из них больше, и зависимостей у каждого из пакетов больше стало.

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

Графовая БД?

переносил дерево portage и базу установленных атомов в tmpfs

Я тоже

так что io там особой роли не играет

У тебя случайно не ssd? На моём ноутбучном шпинделе выигрыш был до 30%

Ну а про парсинг и хранение я уже тоже писал.

Валяй. А мне одноцветно - хоть 10 секунд, хоть 10 минут, я не так часто что-либо переустанавливаю.

Сделал мой вечер, засранец!

Несмотря на скептицизм и сложность, я за.
И Go активно осваиваю, так что пиши, я в деле.

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

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

Ебилды было бы логичнее представить в виде структурированных данных, например JSON.
Или, если подойти с другой стороны - в виде питоньих скриптов, чтобы встраивать их в код без дополнительного парсинга. Но об этом никто не подумал, видимо.

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

Это да, JSON так себе пример.
Встраивание было бы хорошим ходом. Это не сложнее bash скрипта, в принципе

Был проект написания libbash, чтобы не парсить shell скрипты каждый раз, но он заглох https://github.com/groundwater/gentoo-libbash + https://wiki.gentoo.org/wiki/Project:Libbash

Это да, JSON так себе пример.

toml?

Да, как вариант. Правда придется для поддержки переменных окружения из bash (и переменных в приниципе) клепать костыли.

Поход правильный, даже хрестоматийный по своему, но очень уж трудный... Видимо, не осилили.
И черт знает будет ли построение AST сильно быстрее обычного парсинга, учитывая сравнительно небольшой размер ебалдов.
Написание JIT для баша и прекомпиляция ебилдов вышла бы профитнее)

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