[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