On Mon, May 10, 2010 at 03:36:11AM +0400, Алексей Турбин wrote:

AT> Чудес не бывает, информация должна быть каким-то образом представлена.
AT> Вопрос только в том какая цена будет казаться нам приемлемой.  Если
AT> придумать изощренный метод хеширования, то нужно, грубо говоря, примерно
AT> 20 битов на символ полной энтропии (то есть примерно 3.3 буквы в
AT> base64).  Есть теоретическая оценка что с надежностью 0.1% нужно 12
AT> битов энтропии.  Короче это сложная тема, но пока можно считать, что
AT> в "нормальной" (а не модельной, как сейчас) реализации потребуется
AT> примерно 3 буквы на символ.
AT> Конечно, символов бывает много, и версия может получиться очень длинной.
AT> Так что даже неприлично показать. :)

Любопытно. В случае реальной коллизии самое страшное что случится --
поставиться пакет, который поставиться не должен. Однако сейчас (при
отсутствии такой проверки) он и так поставиться. Значит ничего не
сломается, а дополнительная защита появится. Я правильно понимаю?

Тогда мне эта идея очень нравится.

AT> Понимаешь, все эти проблемы тормозов - мои в конечном счете.
AT> А я не предлагаю утопических проектов. :)

Верю. А может ты бы посмотрел на apt по поводу оптимизации? У меня есть
мнение, что его тормоза при распухшей базе обходятся тем, что при apt-get
update может формироваться "оптимизированная" база.

Есть проблема с тем, что базы rpm и apt две разные, однако если мы
оптимизируем, то удаление пакета из системы для нас не страшно, страшно
-- добавление (если поставили rpm'ом вручную). И в этом случае придется
оптимизированную базу перегенерировать (или проигнорировать).

А даже элементарная оптимизация -- все requires на некие provides, которые
предоставляет только один пакет подменять requires на этот конкретный
пакет, а provides которые никто не requires -- просто удалять из
оптимизированой версии базы -- теоретически должно заметно ускорить
тормозной apt :)

-- 
С уважением, Денис

http://mithraen.ru/
----------------------------------------------------------------------------