[идея][вещества] P2P ccache

корованы грабить можно?

У гцц и прочих сишком много опций, чтобы такой кэш удовлетворил всех.

>У гцц и прочих сишком много опций, чтобы такой кэш удовлетворил всех.

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

постил такую тему в толксах месяц назад, меня навали идиотом и «зачем тебе нужно постоянно что-то собирать»

> При очень большом количестве пользователей удовлетворит.

А как определить, что результат компиляции файла в p2p сети действительно результат компиляции этого файла, а не какой-нибудь троянец?

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

>постил такую тему в толксах месяц назад, меня навали идиотом и «зачем тебе нужно постоянно что-то собирать»

Ну вон гентушники целыми днями что то собираю. У меня кубунта, собираю я редко, но вот сейчас впервые в этом году собираю, компилится ядро. Но ccache мне сейчас почему то не помог, видимо с прошлого раза обновился gcc, а в таких случаях вроде кеш игнорируется. Вот p2p ccache бы был как нельзя кстати.

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

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

была идея сделать сервер continuos integration для арчевого аура (распределенная конпеляция + централизованное хранилище). Тоже постоянно конпеляю, задрало.

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

Параметры сборки пакета

>У меня ядро часов пять компилится с убунтушным конфигом.
Это печально. Советую обновить комп. Даже на Athlon 64 2800+ (1.8GHz) оно компилилось более чем в 2 раза быстрее.

трамвайный Z600 же ;)

>>У меня ядро часов пять компилится с убунтушным конфигом.

Это печально. Советую обновить комп. Даже на Athlon 64 2800+ (1.8GHz) оно компилилось более чем в 2 раза быстрее.

Как то пофиг. Заниматься этим приходится нечасто. Для остального хватает. Проц вроде Celeron D.

> Насмотрелся на гентушников, которые постоянно пересобирают ядро, чтобы включить забытый в прошлый раз какой нибудь модуль.
Внезапно пересобирается не всё ядро, а только забытый модуль (что какбэ быстрее). И даже ребутаться как правило не надо :)

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

утопия

>трамвайный Z600 же ;)
Не понял. Об чем речь?

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

Ну тут всем этим занимается ccache, там всё на хешах завязано (в подробности работы не вникал). Я всего лишь предлагаю расширить его возможности глобальным кешем. Для конечного пользователя мало чем будет отличаться обычным использованием ccache.

> Даже на Athlon 64 2800+ (1.8GHz) оно компилилось более чем в 2 раза быстрее.

А если повыкидывать ненужные модули то соберется минут за сорок и на athlon xp

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