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

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

О, не ты первый и не ты последний с такой идеей. Взгляни на Paludis (особенно на википедии). Проблема, с моей точки зрения, в том, что portage вжился в генту как explorer.exe вжился в венду.

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

что же тут сложного, не ракетная наука поди.

не ракетная, но компутерная

Проблема, с моей точки зрения, в том, что portage вжился в генту как explorer.exe вжился в венду.

Ну по сути да и нет, действительно, «гента» это только портаж (обслуживание пакетов, симлинков) и openrc, кажется. А вот где портаж участвует в жизни системы кроме того, что связанно с пакетами и куда оно могло вжиться, мне не совсем понятно.

Paludis есть на крестах - заменяет почти полностью (хотя портаж всё равно из системы без крови не выдрать, ну так хоть рядом стоит и не мешает). Работает быстрее портажа, но не реактивно всё же.

Медленность портежей — не в питоне, а в кривой архитектуре. См. pkgcore как контрпример.

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

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

Бгг.

Да, сделай это!

Ну тогда, если говорить о свежем взгляде и профитах, может не на Го, а сразу на каком-нибудь Rust?

раст будут еще менять 10 раз, а Go уже устоялся, можно сказать.

Почему бы и нет? Перепиши. Или, хотя бы как эти товарищи Желающие принять участие в написании альтернативы portage на C++ просьба отписаться хотя бы попытайся создать команду

Да, сделай это!

Не я, но тыщи горутин сделают это.

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

Он уже зарелизился и устаканился, сам поначалу из-за этого сторонился. А сейчас ничего, сойдёт.

Вот PHP'шники, к примеру, живут от релиза до релиза, а потом разницу переучивают - и ничего. Раст уже какое-то время как перестал ломать синтаксис.

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

Окей.

Ты делаешь какое-то действие с пакетами.

У тебя есть очень сложный граф (зависимости всех ебилдов * их юз-флаги), в котором некоторые пакеты изменились (поставлены на обновление или новые).

Тебе нужно починить и «распутать» этот граф:

1) Определить конфликты (циклы, отсутствующие связиюз-флаги), мешающие распутыванию

2) Понять, какие пакеты необходимо компилять и в каком порядке. Причем, этот порядок тоже будет графом, т.к. компилять можно несколько пакетов одновременно.

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

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

Лучше на C, зачем Go в stage тащить?

Не я, но тыщи горутин сделают это.

Миллионы их, ага.

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

Бгг. Ну давай, начинай. Зафейлишься еще до начала.

На Haskell!

там кресты (сложность поддержки)

А разверни-ка мысль поподробнее...

Работать будет минимум в 10 раз быстрее

Пруф?

если вы ранее ждали разрешение зависимостей 10 секунд, то теперь это будет практически моментально

Для тебя одна секунда — это почти моментально? Да вы, батенька, тормоз.

Что скажете?

Ненужно и не взлетит так же, как не взлетел Cportage и прочие *portage-и

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

Я не ОП и расскажу не подробнее, но более ёмко: не осилил.

Покажи демку

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

Тут выше говорят, что там беда еще в архитектуре. Охотно верю.

Ну и судя по тому, что PyPy дает ускорение далеко не всегда, стоит просто выкинуть все это нафиг и переписать. Можно на том же питоне, но нормально переписать.

Конвертер ебилдов с баша на го тоже напишешь?

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

А если по 30-40 минут? Сразу после введения сабслотов портаж тормозил как сучка, потом починили.

Когда коту нечего... ;)

Ты не прав. Кот, по крайней мере, занимается полезным (для него) делом

Пиши тогда на Common Lisp. Вот уж что точно менять не будут. И остальные профиты (в поддерживаемости и быстродействии) сохранятся.

Stage вроде распространяется в бинарном виде, а Go генерирует статические бинари со всем внутри.

Не то чтобы идея автора была хорошей

Одобряю вашу идею, начинайте писать.

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

зачем конвертер нужен-то? Программа будет обрабатывать ебилды напрямую/

а что, Go уже умеет что-то кроме x86/x86_64?

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

Уже было даже здесь несколько желающих (в тч и я). Нужны в 1ю очередь алгоритмы. язык вторичен. а возможно и 3-ричен. данные в текстовых файлах в размазаны по всему диску в формате который поддерживается только башем.

и да, ограничение по версии пакетов это только один из многих параметров..

врочем возможно что я еще раз попробую «взять штурмом эту гору»

ты чья-то реинкарнация или новенький?

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

хотя портаж всё равно из системы без крови не выдрать

И эти люди что-то там про systemd говорят.

Какие люди и что тебе говорят?

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

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

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

это касается всех пакетных менеджеров(и учитывая что портраге работает гдето с 10x большей информацией чем пакетные менеджеры-то темболее)

ставлю на алиску (до сих пор проигрываю с его слива).

Гентушники. Они даже свою систему инициализации пилить начали же.

Пока только

linux 386
linux amd64
linux arm
linux arm64
linux ppc64
linux ppc64le

Когда хоть вы свалите обратно в школу до конца.

Уже было даже здесь несколько желающих (в тч и я). Нужны в 1ю очередь алгоритмы. язык вторичен. а возможно и 3-ричен. данные в текстовых файлах в размазаны по всему диску в формате который поддерживается только башем.

все верно

в первую очередь надо писать сервер который будет делать «прекомпиляцию/компановку/сортировку/поиск/...» и выдавать все в сжатом бинарном виде(без полных путей,лишь ключевые сокращения),и уже клиент выбрав ключевое последнее значение-запрашивает у сервера расшифровку-и получает полный ответ «кода» сборки

тоесть да нужна сортировка и проработка шаблонов для всего

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

дофигища работы,просто годы на самом деле

новенький?

что?

Дата регистрации: 24.09.2012 15:47:21

алиску

кто это?

Странный какой. Альтернативы это всегда хорошо, а к systemd всё гвоздями приколачивают. Одна из догм gentoo это свобода выбора - с systemd дефолтом этого не выйдет.

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

apt в debian или rpm в красношапках?

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