[devel] Re: q: must-fix list for J2.3?

Anatoly A. Yakushin =?iso-8859-1?q?yakushin_=CE=C1_umail=2Eru?=
Пт Июн 27 22:11:26 MSD 2003


Aleksey Smirnov пишет:

> Anatoly A. Yakushin wrote:
> 
> Сейчас речь идет не о Junior, а о дистрибутиве для OEM-установки. На 
> него накладываются весьма жесткие внешние требования:
Прошу прощения, сразу не понял. OEM - это совсем другая песня.
> - он должен иметь как можно меньше проблем с железом,
> - не должно быть приложений, не работающих из коробки,
> - квалификация установщиков может быть весьма низкой,
> - набор приложений должен закрывать основные потребности офисного и 
> домашнего пользователя,
> - неопытный пользователь должен себя чувствовать достаточно комфортно 
> (иначе он сразу снесет Linux),
> - дистрибутив должен влезать строго на 1 CD и иметь компактную 
> документацию.
> Это требования не конкретного заказчика, а типовые требования к такому 
> дистрибутиву.
Внесу свои пять копеек, из личного OEM опыта.
Обычно покупателю нужна предустановленная операционка, чтобы проверить 
комп в магазине.
Продавцу тоже нужна операционка чтобы проверить комп также и не 
заморачиваться с M$.
Покупатель, придя домой, сносит все на.... и ставит любимые пиратские 
форточки.
Чтобы OEM дистрибутив прожил у среднестатистического пользователя 
больше, чем время на дорогу из магазина домой, IMHO, нужно:
1. Оставлять свободный раздел на диске для любимых форточек. Учитывая 
среднестатистическую тупость OEM-people в инсталлере это должно быть 
прибито по умолчанию.
2. Дать возможность пользователю сии форточки поставить, не снося Linux. 
(тут вопрос знатокам - как сде?)
3. Нарисовать юзеру такую картинку при запуске, чтобы он уделался со 
своими форточками
4. Попытаться договориться с крупными OEM деятелями, что снос 
предустановленной операционки лишает юзера гарантии. (Я понимаю, что не 
наш метод, но работает :) )
5. В дистрибутив должно быть по максимуму понапихано средств диагностики 
  железа и сии средства должны просто и понятно вызываться.

> 
> То есть требование работоспособности, оттестированности и удобства 
> выходит тут на первый план.  То есть это должно быть компактное, но 
> отточенное решение. Как, например, уважаемые участники списка посоветуют 
> мало знакомому с Linux пльзователю Junior 2.2 удалить задание из очереди 
> на печать ?
> - А никак, не сможет он это сделать, а значит и просто работать с Linux 
> не сможет.
> 
> В Junior более важное значение приобретает просветительская 
> направленность, предполагается как минимум априорное желание 
> познакомиться с Linux и с принятыми в нем приемами работы. 
> OEM-дистрибутив уже установлен на машине независимо от желания 
> пользователя, и надо постараться, чтобы он начал работать в Linux 
> прежде, чем снесет его.
> 
> А Junior должен выполнять свою роль enduser-ского дистрибутива, 
> концептуального и  с достаточно богатым и разнообразным набором 
> приложений.  Мне кажется, что он может стать толще и по количеству CD, и 
> по печатной документации.
> Думаю, стоит при этом подумать и о названии. "Junior", который мы 
> связывали с маленьким пингвиненком, многими воспринимается как 
> "Дистрибутив для детей и юношества".
Может название и неудачное, но IMHO, смена названия должно быть 
покреплено серьезными изменениями в дистрибутиве.
> 
> Алексей Смирнов
> 
>>
>> P.S. От этого обсуждния у меня в голове салат-оливье образовался.
>>
>> Хотелось бы понять -
>> 1. Зачем нам новый дистрибутив? Со старыми разобраться бы.
>> 2. Если этот дистрибутив делается по заказу, то тогда огласить 
>> требования заказчика (если конечно это не состовляет коммерческую тайну)
>> 2. Какова в свете этого разговора судьба J
>>



-- 
Rgrds,
Anatoly A. Yakushin aka DOC
Orthopaedic Departmens
Veterans Hospital # 3
Moscow



Подробная информация о списке рассылки Devel