=?iso-8859-1?q?=5Bmdk-re=5D_=F2=C5=CA=D4=C9=CE=C7=CF=D7=C1=D1_=D3=C9=D3?= =?iso-8859-1?q?=D4=C5=CD=C1_=5BWas=3A_=D7=C1=DB=C9_=CC=C0=C2=C9=CD=D9=C5_?= =?iso-8859-1?q?=D0=D2=CF=C7=D2=C1=CD=CD=D9=5D?=

[Alexander V. Sotnikov]

Hi, Aleksey!

среда, 6 июня 2001 г., you wrote:

AN> Никого не хочу обидеть, но считаю, что это не тема для широкой дискуссии.
AN> Вопрос о том, какие _свободные_ программы стоит включить -- да, тема, очень
AN> нужная и важная. А вот что не нужно -- нет.

Несмотря на то, что статистика - э то лженаука, она всетаки
помогает жить и принимать решения :)

Впоминая несколько недельные тому назад дискуссии и глядя на
вновь поднятое обсуждение вставлю свои два цента:

На решение вопроса о включении некоторго пакета в дистрибутив
могут оказывать несколько причин:
- личные предпочтения разработчиков (пример: postfix)
- требования станлартов (пример: fhs требует наличия некоторых
файлов)
- информация об общепринятой практике (пример: sendmail, хотя
разработчики предпочитают/рекомендуют postfix)

Статистика установки/использования пакетов имхо является фактором
который нельзя игнорировать.
На основании этой инфы можно:

1. Формировать разработчикам распределение пакетов по дискам и
формирования дисковых наборов (однодисковые, двухдисковы, ...
двадцатидисковые, например cd1 понадобтися 80%, cd2 15%, cd 3% ...)
Что позволяет оптимизировать соотношение цена/полезность
дистрибутива.

2. Формировать разработчикам типичную установку, облегчая тем
самым жизнь пользователя. Многие ли ставят нынешнюю типичную?

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

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

Оптимальным решением имхо было бы просто получать список
установленных пакетов в системе:
+ легко формируется
+ имя пакета является primary-key в терминах dbms
+ маленький объем содержимого письма (килобайты)
+ как следствие легче автоматизировать
+ в отличие от вебголосования позволяет неупустить неожиданную
статистику буде такая появится (пример гипотетический: некий пакет
пользуется успехом у многих, а разработчики его не поддерживают, повод
задуматься)
- получение такой статистики сйчас от пользователя, который поставил
в режиме типичной установки без существенной чистки портит
картину.
- точность до пакетов, значит не позволяет разработчикам
распределять проги внутри пакетов (пример kdelibs содержит kmail,
который ненужен пользователю сильфиды, но что-то другое полезное
может содержать и т.п.)

PS: Вообще-то пользователей интересует статистика по front-end'ам,
соответственно можно было бы на вебе выводить статистику, только
по ним. BTW так же дело стоит в инсталляторе: точночть руления до библиотек
может понадобиться эксперту и девелоперу.

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

PPPS to 2AEN: до следующего семинара две недели по планам, этот вопрос
на нем будет задан обязательно, поэтому можно готовится на него
отвечать :) Тем более что он имеет прямое отношение к концепции
дистра.

PPPPS: можно не дожидаться семинара, а обсудить и выработать
конкретное решение, о котором на семинаре уже доложить :)

PPPPPS: надеюсь пока писал (очень долго), я еще не проглядел что уже все
решилось :)

With Best Wishes & Regards,
  Alexander V. Sotnikov     mailto:al-so на mail.ru