Информационный поиск

Модули

Готов?

Название модуля

Чтение (ак. ч.)

Подготовка (астр. ч.)

Написание (дни)

уровень

Maintainer

Started

Should be done

End date

{X} 0%

Локальные источники информации

1

1

1

1

ConstantinYershow, ОльгаТочилкина, VsevolodKrishchenko

{X} 0%

Информация в Интернете и feedback

1

1

1

1

MaximByshevskiKonopko, GeorgeTarasov, VsevolodKrishchenko

2

2

2

2

(./)

Готово: 0 (0%)

0

0

{X}

Не готово: 2 (100%)

2

2

Необходимые знания

Материалы

Полиси

  • На данный момент для координирования работ используется макрос ExtractModules (тот же, что и в PspoModules). Возможно, впоследствии будет написано нечто более специфичное для данных работ.

  • Над каждым модулем работает один расшифровщик (указывается первым в списке сопровождающих модуль),один переводчик (указывается вторым в списке) и минимум один технический редактор (тот, кто вычитывает, указывается третьим в списке).
  • Разбивка прогресса по процентам:

    0%

    Сырой конспект

    20%

    Дешифрованный конспект

    50%

    Конспект, переведённый на русский язык

    70%

    Вычитанный конспект

    90%

    Иллюстрирование, расстановка ссылок, перенос в модули

    100%

    Результат работ над частью лекций проверен FrBrGeorge

  • Как только Вы считаете, что закончили свою часть работы, просьба установить соответствующее количество процентов
  • Промежуточное количество процентов в промежуточных сохранениях приветствуется

Пожелания к ролям

  • Расшифровка — по возможности полное восстановление структуры и смысла лекции по конспектам и (если есть необходимость) по аудиозаписям. в эту задачу входит расстановка имеющихся иллюстраций (typescript, konsole.log, снимки экрана)

  • Перевод на русский — выравнивание стилистки и корректировка владения русским языком. Просьба не очень самовыражаться (чтобы не создавать стилистического разнобоя)

  • Вычитка — проверка получившегося текста на (1) соответствие действительности (2) доходчивость (в том числе на предмет нехватки иллюстраций)


CategoryPolicy

Лекции

Локальные источники информации

Проблемы и фобии

Почему вообще так? Почему человек, который садится перед компьютером, поступает вопреки здравому смыслу: вместо того, чтобы почитать документацию, как пользоваться программным продуктом (если лектор покупает сотовый телефон, он читает к нему документацию), а вместо этого тыкать на кнопки, пытаясь понять, что они значат, то это непонятно, ибо можно ... Человек, который научился работать с виндоузом, для него делают новые кнопку, но он их не нажимает, его для них не существует. Отсюда три проблемы:

  • Нелюбознательность, пассивность. Воспитывается в общении с взрывоопасными инструментами. Человек от природы любознателен, но человек, который работал с закрытыми системами, впадает в ступор: он боится на что-то нажимать. Это главная проблема с которой надо бороться. Откуда она растёт:
    • Принципиальная непознаваемость тех инструментов, с которыми он ранее работал, например: принципиально непонятно, как внутри работает планировщик виндовый. И после нескольких попыток прекращает пытаться что-то узнать.
    • Те тексты, которые человек видел в помощи по виндовз и в графоболочках во всяких кдях и гномах, они выполняли роль не информационную --- неинформативный хелп. Пока лектор ехал в метро, его осенило, зачем он нужен: вот делают Вставить файл --- нажмите вставить файл --- это сделано для попытки преодоления пассивности.
    • В закрытых системах почти всегда документация недостаточная по определению. Существует та документация, которую надо дать, чтобы пользователь не выбросил программный продукт, а есть внутренняя документация, тайное знание, которая даёт бизнес-преимущество. Неполнота информации --- это системная ошибка, это следствие того, что знание это её и деньги.

С этими боязнями человек приходит в линукс-систему и садится. А там всё наоборот. Почему:

  • Сообществу не нужен познавательно-пассивный пользователь, он ничего не принесёт. Преимущество свободных программ: мы имеем возможность принимать в сообщество совершенно кого угодно (опт-ин, опт-аут). Самый важный пункт в свободном софте --- возможность модификации и распространения модифицированных результатов. Сообщество ориентировано на активного пользователя. ... Неразрешённый вопрос относительно линукс означает технологическую, копирайтную или ещё какую заковырку. В силу того, что сообщество ориентировано на познавательную активность людей, удовлетворение активности стоит во главе угла.

manpages

Ещё со времён юникс-систем существует культура manpages. Это нулевой эшелон, который доступен. Это очень простое (как и всё, что было придумано более 20 лет назад) дерево документации, существует несколько категорий ссылок, в каждой странице существует жёсткое деление на секции: синопсис, ... и see also. Классический способ работы с манпейджами --- man. Ещё есть apropos и whatis. apropos ищет по ключевым словам среди манпейджев, причём не просто ключевым словам, а по кратким описаниям (когда придумали манпейджи, не думали, что можно искать по всей документации). В нынешние времена существует куча способов представить их в более удобном виде, есть службы, которые позволяют выкладывать её в веб, искать по всему корпусу документации.

Когда был юникс, манпейдж был альфа и омега --- всю информацию оттуда можно было извлечь. Сейчас это в прошлом, оно и правильно, существуют вещи, которые надо документировать другим способом. К сожалению, вместе с размыванием границы документации, размылся и формат. Среди хакеров старой школы существует два мнения --- делать маны или инфо. Это следующий эшелон. info. Идея в том, чтобы писать некий документ... Как вы могли заметить, manpages имеют структуру страницы, а у инфо была идея писать текст так, что, с одной стороны, мог бы быть сделан текст книги, как ман, и был бы гипертекстом с более-менее удобным интерфейсом просмотра. Лектору не очень нравится интерфейс инфо, но там можно писать не только коротки статьи, но и многое другое --- учебники, и т. д. Во многих случаях, в мане есть ссылка на инфо-страницу. Есть движки, которые позволяют инкорпорировать инфо-страницы в другие ИС, но они не получили широкого распространения.

info не представляет всю полноту документации, но был таким до предпоследнего момента.

Если по программе нет инфо/ман, то надо задуматься, хотите ли вы ей пользоваться. Ибо в этом случае автор --- разгильдяй. Тем не менее, это линукс, и даже к хорошо документированным программам существуют документационные файлы, которые не укладываются в этот формат. Всё это лежит в каталоге /usr/share/doc/<package_name>/... --- это то место, куда пакет кладёт документацию. Здесь помогут утилиты типа find и grep. Это требует знания командной строки, есть и другие средства.

Всё это, тем не менее, представляет системную документацию. Это эшелоны первого, ближнего боя.

В дистрибутиве

Начинаем расширять горизонт.

Если вы пользуетесь некоторым дистрибутивом, то там наверняка будет дистрибутивоспецифичная документация. Поэтому следующим эшелоном будет дистрибутивная документация. Скорее всего, это будет иконка на рабочем столе со ссылкой на документацию.

<div class="comment">Внезапно бабахнуло, потемнело и за дверью послышался крик.</div>

Чем дистрибутивная документация отличается от того ролика, который виндовз крутит при установке виндовз? В первую очередь тем, для чего она делается. К счастью для лектора, идея позновательно-активного пользователя была воспринята и компаниями, которые делают дистрибутивы, поэтому почему-то в большинстве случаев считается, что должны быть освещены основы исп. линукс, дистрибутивоспецифичные вещи, сильные стороны, короче говоря, те люди, которые составляют текст, думают над тем, как написать о том, что пользоваться этим дистр. удобно.

Далее. Вот тут начинается выход за пределы дистрибутива как такового. На самом деле, далеко не всю информацию имеет смысл запихивать в систему. В систему имеет смысл запихивать информацию эксплутационного плана, как воспользоваться этой системой. Почему не надо вкладывать всю информацию? Пример: MSDN. Кто умеет ориентироваться MSDN, так это только те, кто постоянно в этом работает, и вконце концов у них в голове откладывается эта ужасная архитектура. Она не ужасная, она хорошая. Вся эта замечательная архитектура откладывается в голове. Объём разный — как только мы начинаем работать с большими объёмами данных, очень большими, и у нас нет ранжирования важности, то лучше в гугле искать, чем в голове. Поэтому надо дозировать информацию, которая лежит чуть дальше. Какая информация лежит чуть дальше? У всех дистрибутивов есть сайты, на которых есть разная информация. И это, пожалуй, следующее место, куда следует зайти.

По поводу HOWTO: они делятся на вычитанные и невычитанные, вычитанные кладутся обычно в дистрибутивную документацию. Может быть так, что информация могла быть не вычитана и не входит в дистр., но входит в сообщество. Хотя, можно наткнуться на устаревший материал.

Здесь начинается... нет, оно пока не начинается.

Информация в Интернете и feedback

Когда лектор говорит про сайт сообщества, он говорит не только про сайт, но и про информационное пространство, с ним связанное. В случае с альтом:

  • wiki.sisiphus.ru <i>(vvk: w.s.r объединён с freesource.info)</i> Поскольку там те же люди, то большая часть информации посвящена сизифу, дистрибутиву, настоящий сайт сообщества.

  • Сайт компании.
  • сизифус.ру --- робот по отсл. сост. репозитория, и там есть много информации по пакетам.
  • Соседние сайты --- heap.altlinux.ru

Списки рассылки. Для начала стоит поискать по спискам рассылки.

В последнее время довольно часто, если искать линуксовые вещи, то лектор всё чаще попадает на списки рассылки альта.

Ну и есть поговорка «Гугл — твой другл». Если не удаётся найти, то стоит попробовать поискать в сети. К сожалению, для того, чтобы что-то найти, надо знать половину ответа. К сожалению, лектор не может рассказать, как искать в сети. Если же в сети не находится, то вопрос надо задавать живому человеку. С другой стороны, даже если ответа нет, то вы не одни. Эта тусовая атмосфера определяет одну важную вещь --- одна голова хорошо, а 400 — лучше. Кроме того, если почитать старые книжки про старых хакеров, то можно обнаружить такие вещи — нужно подползать к гуру на коленях… В линуксе это не так. Тем не менее, задайте вопрос. Наиболее правильное место — списки рассылки. Задавая вопрос, нужно как минимум сделать вид, что вы прошли этот путь, а как максимум — пройти его.

Обратная связь

Ещё лектор хочет рассказать про обратную связь.

Как справедливо заметил Павел, то нужно придерживаться некоторых формальностей при задании вопроса. Лектор когда-то давно программировал на вижуал бейсике, и вот эту программу повезли внедрять, и вот ему звонят, и говорят, что программа не работает, выдавая сообщение: «Файл не найден». Стоит упоминать:

  • Список программ
  • Аппаратная конфигурация (lspci, scanpci)
  • Если происходит ошибка и что-то работает не так
  • Если требуется решение задачи, то надо поставить задачу

«Подземный стук»: «Дорогие учёные! У меня пятый год в подполье происходит подземный стук, отчего он происходит?» (Стругацкие, ПвС/СоТ) (точная ссылка: [http://heap.altlinux.ru/engine/Heap/PNVS#line_6409])

«Забыл поделиться». Эта самая познавательная активность в качестве ещё одной стороны имеет... эта активность как расшифровывается: нужно не только решать задачу, особенно если он нетривиально, чтобы оно стало доступно другому такому же, как Вы. Если ты решил задачу, то её решение должно быть задокументировано. Кроме того, сообщество ориентировано на фидбек.

Эти все три вещи, связанные с тем, что позн. активность --- отдача, и если решил задачу, то надо записать, где решил, то есть правило: решил --- задокументируй.

Система отслеживания ошибок: обратная связь в формализованном виде. Если пишете вопрос в рассылку, вас могут неожиданно послать в багзиллу. Кто это такая: вопросы техплана, связанные с дисфункциональностью, с фичареквестами, с неудобством... такого рода вопросы решаются более механизированным способом, чем при помощи трёпа с использованием трёпопередатчика. В частности, всё, что связано с странностями ПО, работает через реквест-трэкер... Таких систем отслеживания ошибок есть несколько, у альта исп. багзилла. Там-то как раз дисциплина оформления заявки должна быть более строгой, если у Вас падает программа, то нужно описать условия, при которых она упала, вообще, представить как можно больше информации. Это такой нормальный способ диалога. При этом вы вступаете в диалог с мэнтейнером пакета. Может так случиться, что ошибка совсем не в этом. Тогда её перевесят. При этом будет почтовая рассылка, будут приходить уведомления. Ежели вы способны исправить ошибку самостоятельно, то это категорически приветствуется. Чем этот механизм хорош --- необязательно быть в теме, необязательно знать, как работает программа целиком, нужно уметь делать пакеты. Необязательно даже делать идеальный патч. Такое участие на уровне багзиллы не накладывает обязательств, позволяет опробовать вилы в разработке, и дополнительный бонус: ошибки больше не будет. Это место, где можно себя применить, не влезая в программистскую школу.

Зачем: вам же будет удобнее. Поскольку сама система ориентирована на активного пользователя, никаких проблем, запретов, препон у вас нет.

Можете посмотреть ещё один способ участия --- участие в переводах. (см посл. лекцию прошлого года)

По инициативе альта запущен проект перевода всего подряд под школьный дистрибутив, и за это платятся деньги.


CategoryLectures CategoryCmc CategoryUneex

LecturesCMC/LinuxSoft2007/10 (last edited 2008-07-24 15:12:43 by eSyr)