LINUX.ORG.RU

Желающие принять участие в написании альтернативы portage на C++ просьба отписаться

 , ,


9

17

В продолжение обсуждения: Гентушники, есть чё по мелочи?

Пока в толксах разглагольствуют о нужности или ненужности C/C++ и очередного paludis, я решил создать этот тред. Пусть он будет только трекером участников.

Все, кто пожелает поучаствовать в разработке альтернативы portage на C++ (сейчас, через пару дней, недель, или месяцев) просьба здесь отписаться и подписаться на отслеживание новых комментариев. Если есть представление — укажите, в каком направлении бы вы могли поучаствовать в проекте.

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

Т.к. фрактала могли многие заигнорить, да и мою тему наверняка десяток-второй людей не увидят, сообщайте потенциально заинтересованным гентушникам.

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

Пустой треп лучше перенести в вышеуказанный тред в толксах.

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

Думаю твое сообщение они тоже проигнорируют...

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

Может вам сначала разобраться где у portage бутылочные горлышки и туда подставить более быстрые реализации на C/C++?

А зачем? Это же никому не интересно. То ли дело навелосипедить новых Ъ sys-apps/eportage и не на „тормозных петонах а на Ц++“.

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

Так они все в i/o, тут на что ни перепишешь - толку не будет. Разве что полный граф зависимостей генерить после emerge — sync и писать в бд, но если для мира с зависимостями из тысячи пакетов он строится несколько минут, то для всего дерева портежей... Да и к тому же есть еще профиль, make.conf и packege.use с флагами (те же зависимости), и они после синхронизации дерева могут сильно поменяться, значит надо это учитывать... т.е. при установке пакетов все равно просчитывать зависимости. Конечно можно все конфиги portage засунуть в бд, но какой гентушник захочет использовать такой пм, особенно учитывая сколько дискового пространства это все будет отжирать?

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

ради чего это все?

Мне интересна твоя версия. Давай вьікладьівай

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

ради чего это все?

Чтобы написать быстрый ПМ для быстрейшего дистрибутива и попонтоваться на ЛОР'е, разве нет?

anonymous
()

ну если с sqlite и uclibc, то я помогу
только я C/C++ не знаю))
Лучше бы на TCC написали))

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

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

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

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

Чтоб запилить рассылку, нужно запилить название.

И на этой наиважнейшей вехе развития многоуважаемое ЛОР-сообщество застряло.

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

И на этой наиважнейшей вехе развития любого проекта (втч этого архинужного и мегасложного), начинаемого здесь, многоуважаемое ЛОР-сообщество застряло.

дополнил

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

Товарисч! Не надо торопится. Ведь всем известно: «Как корабль назовёшь, так он и поплывётутонет»

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

Желающие принять участие в написании альтернативы portage на C++ просьба отписаться (комментарий)

Я могу присоединиться через пару дней или неделю-две.

ну и Желающие принять участие в написании альтернативы portage на C++ просьба отписаться (комментарий)

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

Но пока что-то предложений мало ото всех. Почти никто не предложил площадки для размещения проекта. Я склоняюсь к Gitorius или GitHub.

Олсо, я пока не в курсе, где можно создать список рассылки. Если фришных нет — тогда придется с списком рассылки подождать, пока я или кто-то другой не поднимет у себя. У меня как раз на днях VDS новая завелась.

Пока занимаюсь поиском и жду фидбеков в этой теме.

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

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

Я тут, но ещё в самом начале отписал, что через пару дней включусь. Прямо щас я немного занят. Хватит деморализировать народ, елки-палки.

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

Почти никто не предложил площадки для размещения проекта. Я склоняюсь ..

а как же молодежная социальная сеть?

Олсо, я пока не в курсе, где можно создать список рассылки

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

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

Хватит деморализировать народ, елки-палки.

Ну что Вы. Как Вы могли такое подумать?! Мы здесь дискутируем об недостатках текущей архитектуры и о том какой должна быть будущая

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

Разве что полный граф зависимостей генерить после emerge — sync и писать в бд

Да.

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

Хотелось бы делать такое однократно (или с ключем типа --force-dep-rebuild) Далее пересчитывать зависимости при synс только для измененных ебилдов.

Да и к тому же есть еще профиль, make.conf и packege.use с флагами (те же зависимости), и они после синхронизации дерева могут сильно поменяться, значит надо это учитывать...

Конечно, это надо отслеживать.

Конечно можно все конфиги portage засунуть в бд

Можно, но только в качестве кэша.

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

Сколько? :) Это пока неизвестно.

Chaser_Andrey ★★★★★
() автор топика

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

ZuBB ★★★★★
()

Пустой треп лучше перенести в вышеуказанный тред в толксах.

по существу: перечитал пост 3 раза, не вижу ответа на вопрос ЗАЧЕМ?

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

по существу: перечитал пост 3 раза

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

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

почему просто нельзя взять, и написать свой portage?

а то получается: «давайте не будем обсуждать не нужность portage! Давайте откроем срач о том, как по феншую расставлять отступы в новом protage! Я не знаю как!»

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

ты свои посты вообще читаешь? Уж тебя давно на номинацию «мистер унылость 2013» пора...

emulek
()

А там точно проблема в пистоне, а не в самом формате ебилдов, делающих работу с ними невыносимо медленной, homebrew на ruby c рудиментной поддержкой use флагов таки работает реактивно в сравнении с портажем.

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

homebrew на ruby c рудиментной поддержкой use флагов таки работает реактивно в сравнении с портажем.

c рудиментной поддержкой use флагов

рудиментной

this. emerge просчитывает столько всего, что не факт что это вообще может работать значительно быстрее.

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

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

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

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

FRCTLL
()

С++

Пишем парсер ебилдов

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

Реверсим portage и описываем алгоритмы (я считаю описание алгоритмов весьма важным моментом для всех)

Ciaran McCreesh по поводу Portage очень правильно выразился.

З.Ы. Если действительно хочется написать систему управления пакетами, то начинать нужно с голого нуля. Сравнить уже имеющиеся (включая долбанутую попытку WinKDE), и построить требования к новой.

Так же не забываем про необходимость постоянного тестирования на возможность сборки/обновления конфигурации системы. Нужен кластер или GRID для постоянной сборки. В этом отношении готов частично спонсировать проект.

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

Ciaran McCreesh по поводу Portage очень правильно выразился.

что именно смотреть. у него там несколько записей.

З.Ы. Если действительно хочется написать систему управления пакетами, то начинать нужно с голого нуля. Сравнить уже имеющиеся (включая долбанутую попытку WinKDE), и построить требования к новой.

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

приблизительно о том же самом спорили выше хакер и ТС

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

1. «portage слишком сломан, чтобы его можно было исправить.»

2. Попытка просто переписать Portage тут же потянет фразы «а). уметь поддерживать старые EAPI», а следом все костыли и тормоза

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

1. «portage слишком сломан, чтобы его можно было исправить.»

я сам не раз приходил к этой мысли. (возможно|скорее всего) оно так и есть

2. Попытка просто переписать Portage тут же потянет фразы «а). уметь поддерживать старые EAPI», а следом все костыли и тормоза

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

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

«portage слишком сломан, чтобы его можно было исправить.»

А ты пытался или это из серии «мопед не твой»?

Попытка просто переписать Portage тут же потянет фразы «а). уметь поддерживать старые EAPI», а следом все костыли и тормоза

Как это? Ведь тут вон даже у ТС была мысль что дескать «portage тормоз а потому что на python… а вот ща мы его на С/С++ и у нас будет шустро и Ъ».

А если и С/С++ будет таким же тормозом как и python то вообще в чем смысл начинать?

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

А ты пытался или это из серии «мопед не твой»?

Я пытался. И лучше бы я не пытался.

А если и С/С++ будет таким же тормозом как и python то вообще в чем смысл начинать?

Нет такого С/С++. Есть С++, дак вот он будет тормазить так же, как питон.

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

Я пытался. И лучше бы я не пытался.

А ну ок.

Нет такого С/С++. Есть С++, дак вот он будет тормазить так же, как питон.

Ага так и в чем тогда смысл это темы?

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

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

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

Все, кто пожелает поучаствовать в разработке альтернативы portage на C++

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

Найдено логическое несоответствие!

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

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

ржали всей багзиллой

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

Нет такого С/С++

Зато есть тупые учебники для ВУЗов «Программирование на C\C++» из-за которых рождается просто «чудо код»

AlexVR ★★★★★
()

Вы бы еще ядро линукса переписали ... задача неприподъемная. Если ее начать реализовывать, то нужны огромные ресурсы и даже не факт, что оно взлетит через год или два. Задача ускорить portage хороша, но решение переписать все - глупое. Вы возмите, пройдите профайлером и посмотри где тормоза. Может так оказать, что ускорение, после переписывания даже на asm даст прирост максимум в 5%. Оно того стоит? А может там кусок кода на питоне переписать и получить прирост в 2 раза.

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

МакКриш конечно молодец, но его палудис сломан ещё больше.. :/

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