CHDK - альтернативная прошивка

Описывайте симптомы проблемы, а не ваши предположения

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

Глупо:

Я постоянно получаю ошибки SIG11 при компиляции ядра, и подозреваю, что причина — микротрещина на материнской плате. Как лучше всего это проверить?

Разумно:

На собранном мною компьютере K6/233 на материнской плате FIC-PA2007 (чипсет VIA Apollo VP2) с 256MB памяти Corsair PC133 SDRAM начинают часто возникать ошибки SIG11 примерно через 20 минут после включения питания, в ходе компиляции ядра, но они не возникают в первые 20 минут работы после включения. Перезагрузка ни к чему не приводит, а вот отключение на ночь помогает. Замена всей памяти не помогла. Соответствующая часть результатов типичной компиляции прилагается.

Вполне возможно, что многим предыдущий пункт покажется немного трудным и непонятным, чтобы вникнуть в суть. Поэтому следующая фраза поможет вам понять: «Все диагносты из Миссури!» Официальный девиз штата США Миссури: «Покажите мне.» (стал использоваться с 1899 года, когда конгрессмен Уиллард Д. Ванивер (Willard D. Vandiver) сказал, что «я приехал из страны, в которой не выращивают кукурузу, хлопок, листья коки и демократов, и бессодержательное красноречие не убедит и не удовлетворит меня. Я — из Миссури. Вы должны показать мне.»). В случае с диагностами, это не скептический вопрос, а скорее всего буквальный, функциональная потребность увидеть как можно ближе проблему в сыром виде, а не ваши предположения и догадки. Покажите нам.

Описывайте симптомы проблемы в хронологическом порядке

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

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

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

Описывайте конечную цель, а не отдельные шаги

Если вы пытаетесь разобраться как что-либо сделать (а не сообщать об ошибке), начинайте с описания цели. И только потом описывайте конкретный шаг на пути к ней, который вы не смогли выполнить.

Зачастую люди, которым необходима техническая помощь, имеют на уме цель высокого уровня и привязываются к одному из возможных, по их мнению, путей её достижения. Они просят помочь выполнить один шаг, не отдавая себе отчёта в том, что выбрали неверный путь. Чтобы разобраться в этом, может потребоваться много усилий.

Глупо:

Как заставить диалог выбора цвета в программе FooDraw воспринимать шестнадцатеричное RGB-значение?

Разумно:

Я пытаюсь заменить таблицу цветов в изображении нужными мне значениями. Сейчас я вижу только один способ сделать это — редактируя каждый слой таблицы, но я не могу задать шестнадцатеричное RGB-значение в диалоге выбора цвета программы FooDraw.

Вторая версия вопроса — разумна. Она позволяет получить ответ, в котором будет предложено средство, более подходящее для решения задачи.

Не просите людей отвечать вам на личный адрес электронной почты

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

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

Из этого правила есть одно небольшое исключение. Если вы предполагаете, что на свой вопрос получите множество подобных между собой ответов, не забудьте магические слова «отправьте ответ мне, а я резюмирую полученные ответы в статье для дискуссионной группы». Попытка уберечь дискуссионную группу или список рассылки от потока, по сути, идентичных сообщений — это очень любезно, но вы должны сдержать своё обещание и отправить итоговое резюме в дискуссионную группу или список рассылки.

Задавайте чёткие и ясные вопросы

Не ограниченные по времени вопросы зачастую требуют и не ограниченного по времени ответа. Люди, скорее всего способные дать вам полезный ответ, ещё и самые занятые люди (ещё и потому, что большую часть своей работы делают сами). Такие люди ревностно относятся к своему времени, и поэтому часто не воспринимают вопросы не ограниченные по времени.

Вероятность получения полезного ответа повышается, если вы чётко даёте понять, чего добиваетесь от окружающих (предоставить ссылки, отправить код, проверить ваше решение и т.п.). Это сконцентрирует усилия отвечающих и неявно задаст ограничение по времени и усилиям, которые придётся затратить отвечающему, чтобы помочь вам. И это хорошо.

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

Поэтому имеет смысл ограничить вопрос, чтобы свести к минимуму время, необходимое эксперту для его решения. Но зачастую это не тоже самое, что упростить вопрос. Так, например, вопрос: «Можете ли вы дать ссылку на хорошее описание X?» — обычно куда разумнее, чем просьба: «Объясните мне X, пожалуйста». Если у вас проблемы с неработающим кодом, разумнее будет попросить объяснить, что в нём не так, а не просить исправить ошибки.

Когда спрашиваете о коде

Даже и не просите других отладить ваш неработающий код, без какого-либо описания проблемы, которую должны найти. Отправка нескольких сотен строк кода со словами: «Чего-то у меня не работает», будет проигнорирована. Лучше отправить десяток строк кода со словами: «после 7-ой строки я ожидал увидеть <x>, но вместо этого получил <y>», и скорее всего ответ вы получите.

Если вы хотите, чтобы ваш код просто посмотрели, дали ему оценку, на забудьте указать какие именно куски кода необходимо посмотреть и почему.

Не задавайте вопросы из домашних заданий

Хакеры хорошо умеют отвечать на вопросы из домашних заданий — большинство из нас их делало самостоятельно. Эти вопросы заданы для работы именно вам, чтобы вы могли научиться на собственном опыте. Просить можно о подсказке, но не о полном решении.

Если вы подозреваете, что вам подкинули вопрос из домашнего задания, но всё равно не можете дать на него ответ, попытайтесь задать вопрос в форуме группы пользователей или (в крайнем случае) в «пользовательском» списке рассылки/форуме соответствующего проекта. Хотя хакеры его и «опознают», некоторые из продвинутых пользователей могут, по крайней мере, дать вам подсказку.

Избегайте бессмысленных просьб

Не поддавайтесь соблазну завершить свой вопрос бессмысленными фразами типа: «Не поможет ли мне кто-нибудь?» или «Есть ли вообще ответ?» Во-первых, если вы хоть сколько-нибудь компетентно описали свою проблему, подобные вопросы, как минимум, излишни. Во-вторых, поскольку они излишни, хакерам они кажутся надоедливыми — и в ответ их так и подбивает написать логически безукоризненную отписку типа: «Да, помочь вам можно» или «Нет, вам уже ничем не поможешь».

В общем случае, если вы не хотите получить ответ в духе да-или-нет, лучше не задавать вопросы в духе да-или-нет.

Не помечайте свой вопрос как «Срочный», даже если он является для вас таковым

Это ваша проблема, а не наша. Упоминание о срочности зачастую контрпродуктивно: большинство хакеров просто удаляют такие сообщения как грубые и эгоистические попытки срочно привлечь к себе особое внимание.

В этом правиле есть одно небольшое исключение. Упоминание о срочности может иметь смысл, если вы используете программу в серьёзной и известной компании, которая может заинтересовать хакеров. В таком случае, если вам не хватает времени и вы сообщите об этом вежливо, люди могут оказаться достаточно заинтересованы, чтобы ответить быстрее.

Так делать, однако, крайне рискованно, потому что точка зрения хакера на серьезность и его интересы, вероятно, отличаются от ваших. Вопрос о международной космической станции, например, вызовет интерес, а вот вопрос от имени преуспевающего фонда или политической партии, почти наверняка, — нет. Фактически, вопрос с темой «Срочно: Помогите мне спасти пушистых тюленят!» будет проигнорирован или злобно прокомментирован даже теми хакерами, которые считают, что жизнь пушистых тюленят имеет для них значение.

Если вас это удивляет, перечитайте весь этот документ до тех пор, пока не поймёте, а до того воздержитесь от отправки вопросов вообще.

Вежливость никогда не помешает, а чаще помогает

Будьте вежливы. Используйте фразы «Спасибо», «Заранее благодарен» или «Спасибо за Ваше понимание». Дайте понять, что вы благодарны людям, бесплатно посвящающим вам своё время.

Если честно, это не так важно, как отсутствие ошибок в тексте вопроса, ясность, точность и детальность описания, использование открытых форматов и т.п. (и не заменяет всё перечисленное). Хакеры, в общем случае, предпочли бы получать грубые, но технически точные сообщения об ошибках, чем вежливое словоблудие. (Если вас это удивляет, вспомните, что мы ценим вопрос за то, чему он нас учит.)

Однако, при нормальном техническом уровне вопроса вежливость действительно повышает вероятность получить полезный ответ.

(Необходимо отметить, что единственное серьезное возражение, полученное на этот документ от ветеранов хакерского движения, связано с рекомендацией использовать фразу «Заранее благодарен». Некоторые хакеры усматривают в ней нежелание благодарить кого бы то ни было после того, как проблема будет решена. Мы рекомендуем благодарить и заранее, и после получения ответа, или выразить свою благодарность по-другому, скажем, фразой «Спасибо за внимание» или «Спасибо за ваше рассмотрение».)

Отправляйте краткое описание решения

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

Оптимальным решение будет ответить в нити обсуждения, начатой с исходного вопроса, добавив к теме сообщения пометку «FIXED», «RESOLVED», «РЕШЕНО» или другой не менее очевидный признак решения. В списках рассылки с большим количеством сообщений, потенциальный отвечающий при взгляде на нить обсуждения «Проблема Х», завершающуюся сообщением «Проблема Х - РЕШЕНИЕ» понимает, что ему не нужно тратить своё время даже на чтение сообщений (если он лично не считает Проблему Х интересной), и поэтому может потратить своё время на решение другой проблемы.

Такое сообщение не обязательно должно быть длинным и подробным. Простое: «Привет! Проблема была связана с разрывом в сетевом кабеле! Спасибо всем. Билл», - уже лучше, чем ничего. Фактически, краткое и вежливое резюме лучше, чем длинная диссертация, если только решение не затрагивает серьёзные технические аспекты. Напишите, какие действия позволили решить проблему, но всю последовательность поиска решения повторно описывать не надо.

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

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

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

Подумайте, как вы можете предотвратить возникновение такой проблемы у других пользователей в будущем. Спросите себя, поможет ли изменение документации или списка ЧаВО, и если да — пошлите соответствующее изменение тем, кто поддерживает эти документы.

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

Как интерпретировать ответы

RTFM и STFW: как понять, что вы серьёзно облажались

Есть древняя и священная традиция: если вы получаете ответ «RTFM», значит, отвечающий думает, что вам стоит почитать руководство (Read The Fucking Manual). Он почти наверняка прав. Идите читать.

У ответа RTFM есть более молодой аналог. Если вы получаете в ответ «STFW», значит, отвечающий думает, что вам стоит поискать ответ в сети (Search The Fucking Web). Он почти наверняка прав. Идите искать. (Более мягким вариантом этого выражения может быть фраза: «Гугл ваш друг!»)

В Web-форумах вам ещё могут предложить поискать в архивах форума. Нередко отвечающий может оказаться настолько любезен, что даст ссылку на предыдущее обсуждение, в котором эта проблема была решена. Однако надеяться на это не стоит. Лучше поискать в архивах форума, прежде чем спрашивать.

Часто тот, кто вам отвечает подобными фразами, имеет под рукой руководство или web-страницу с необходимой вам информацией, и смотрит на неё, когда набирает ответ. Эти ответы означают, что, по его мнению, во-первых, необходимую информацию легко найти и, во-вторых, вы большему научитесь при поиске информации, чем если вам её преподнесут под нос на тарелочке.

Вас это не должно возмущать, т.к. по хакерским стандартам, он оказал вам достаточное уважение уже тем, что не проигнорировал вопрос. Вы должны поблагодарить ответившего за его отеческую доброту.

Если вы не понимаете…

Если вы не поняли ответа, не спешите тут же требовать его объяснить. Попробуйте воспользоваться теми же источниками информации, что и при поиске ответа на исходный вопрос (руководства, ЧаВО (FAQ), Web, опытные коллеги), чтобы понять ответ. Если и после этого вам необходимы разъяснения, попросите ответившего разъяснить свой ответ, показав, что вам самим удалось узнать.

Например, предположим, я вам ответил: «Похоже, у вас завис zentry. Надо проверить.» Тогда плохим уточняющим вопросом будет: «А что такое zentry?» А хорошим: «Ок, я прочитал страницу справочного руководства, и про zentry там упомянуто только в опциях -z и -p. Ни в одной из них не сказано, как сбросить зависший zentry. Надо ли использовать одну из этих опций, или я что-то неправильно понял?»

Реакция на грубость

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

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

С другой стороны, иногда можно встретиться с грубостью и вызовом, не имеющими никаких видимых оснований. Обратная сторона этой медали в том, что такая реакция является вполне приемлемой формой постановки на место действительных грубиянов, — мы отсекаем их недостойное поведение остро отточенным словесным скальпелем. Однако, вы должны быть очень уверены в своей позиции, прежде чем пытаться заняться этим. Грань между указанием на невежливость и началом бессмысленного «базара» (в оригинале — flamewar — прим. переводчика В.К.) настолько тонка, что и сами хакеры нередко её переходят. Если вы новичок или просто случайный читатель, шансов избежать такой грубой ошибки немного. Если вас интересует информация, а не развлечение, лучше уберите руки с клавиатуры и не рискуйте вступать в подобные дискуссии.

(Некоторые люди утверждают, что многие хакеры страдают мягкой формой аутизма или синдрома Аспергера, и у них просто не хватает той части мозга, которая отвечает за «нормальное» социальное взаимодействие между людьми. Возможно, это правда, а может и нет. Если вы не хакер, представление о хакерах как о больных на голову людях, может помочь вам смириться с нашими странностями. Думайте, что хотите. Нас это не волнует. Нам нравится быть именно такими, и к подобным медицинским ярлыкам мы относимся со здоровым скептицизмом.)

В следующем разделе мы поговорим о другой проблеме; о своего рода «грубости», с которой можно встретиться, когда именно вы не правы.

Не реагируйте как неудачник

Вполне вероятно, что вы уже облажались несколько раз в хакерских форумах — так, как описано в этой статье или аналогично. И вам уже объяснили, как именно вы облажались, возможно в красках. При всём честном народе.

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

Смириться. Это — нормально. На самом деле, это хорошо и целесообразно.

Общественные нормы не поддерживают себя сами — их поддерживают люди, активно, в открытую, публично эти нормы применяющие. Не думайте, что критиковать должны только в личной переписке — это не так. Не имеет смысла принимать как личное оскорбление чей-то комментарий, что одно из ваших утверждений ошибочно, или что у него есть другое мнение. Так действуют только неудачники.

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

Выбирайте: преувеличенная «дружественность» (такого рода) или полезность.

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

Иногда люди переходят на личности, вступая в грязную полемику без видимой причины и т.д., даже если вы и не облажались (или облажались только в их воображении). Возмущаться в таком случае, самый верный способ облажаться.

Эти «скандалисты» либо ламеры, которые ничего не понимают, но считают себя экспертами, либо потенциальные психологи, проверяющие облажаетесь вы или нет. Другие читатели их либо проигнорируют, либо найдут способы самостоятельно с ними разобраться. Поведение скандалистов создаёт проблемы для них самих, что не в кой мере не должно беспокоить вас.

Не позволяйте также втянуть себя в бесполезный «базар» (флейм). Такие обсуждения лучше сразу игнорировать, предварительно разобравшись, что это действительно пустой и бесполезный «базар», а не намёки на то, почему вы действительно облажались, и не тонко зашифрованные ответы на ваши фактические вопросы (так тоже иногда бывает).

Вопросы, которые не стоит задавать

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

Вопрос:

Где можно найти программу или ресурс X?

Ответ:

Там же, где и я её взял, придурок, — найти в Интернете. Боже, неужели ещё не все знают, как пользоваться Google.

Вопрос:

Как можно с помощью X сделать Y?

Ответ:

Если вы хотите сделать Y, надо так и спрашивать, не предполагая заранее использование метода, который может вовсе не подходить. Вопросы такого вида часто задают те, кто не просто ничего не знает об X, но и сбит с толку решаемой проблемой Y и слишком сконцентрирован на деталях своей конкретной ситуации. Обычно лучше игнорировать таких людей, пока они не сформулируют свою проблему лучше.

Вопрос:

Как сконфигурировать приглашение командного интерпретатора?

Ответ:

Если вы достаточно умны, чтобы этим заинтересоваться, вам хватит ума воспользоваться поиском и найти ответ самостоятельно.

Вопрос:

Можно ли преобразовать AcmeCorp-документ в Tex-файл с помощью программы преобразования файлов Bass-o-matic?

Ответ:

Попробуйте и узнаете. Так, во-первых, узнаете ответ, а, во-вторых, перестанете тратить моё время.

Вопрос:

Моя {программа, конфигурация, мой оператор SQL} не работает

Ответ:

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

• Вам к этому больше нечего добавить?
• Ой, это очень плохо. Надеюсь, вы уже это исправили.
• И какое это имеет отношение лично ко мне?

Вопрос:

У меня проблемы с Windows-машиной. Не могли бы вы мне помочь?

Ответ:

Да. Выкиньте этот Microsoft-овский мусор и поставьте себе операционную систему с откртыми исходными кодами, например, Linux или BSD.

Примечание: вы можете задавать вопросы, связанные с Windows-машинами, если они относятся к программе имеющей официальную версию для Windows, или взаимодействующей с машинами под Windows (например, Samba). Просто не удивляйтесь ответу, что проблема в Windows, а не в самой программе, потому что Windows настолько «крива» в целом, что зачастую именно так и бывает.

Вопрос:

Моя программа не работает. Я думаю, проблема в системном компоненте X.

Ответ:

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

Вопрос:

У меня возникли проблемы с установкой Linux (или X). Не могли бы вы помочь мне?

Ответ:

Нет. Чтобы решить эту проблему, мне нужен непосредственный доступ к вашему компьютеру. Лучше задайте свой вопрос местной группе пользователей Linux (LUG — Linux User Group), которые смогут помочь вам лично. (Список групп пользователей можно найти здесь.)

Примечание: вопросы об установке Linux могут быть уместными в форуме или списке рассылки, посвящённому конкретному дистрибутиву, если проблема связана с этим дисьрибутивом, или в форумах локальных групп пользователей. В этом случае, не забудьте точно описать подробности сбоя. Но сначала тщательно поищите в Web, указав ключевые слова «linux» и все подозрительные компоненты оборудования.

Вопрос:

Как взломать пароль пользователя root/получить расширенные привилегии/прочитать чужую электронную почту?

Ответ:

Да ты просто пошляк, раз хочешь такое сделать, и идиот, раз просишь хакера тебе помочь.

Хорошие и плохие вопросы

А сейчас я собираюсь показать на конкретных примерах, как надо правильно задавать вопросы. Я представлю пару вопросов об одной и той же проблеме, один — заданный глупо, а второй — правильно.

Глупо: Где мне найти информацию о Foonly Flurbamatic

Этот вопрос просто напрашивается на ответ «STFW».

Правильно: Я попытался поискать информацию в Web с помощью Google по запросу «Foonly Flurbamatic 2600», но полезных ссылок не получил. Не знает ли кто-нибудь, где найти информацию о программировании этого устройства?

Этот вопрошающий уже поискал в Web, и похоже, у него реальная проблема.

Глупо: Я не могу скомпилировать код проекта foo. Почему он некорректен?

Он думает, что кто-то другой облажался. Самоуверенный тип.

Правильно: Код проекта foo не компилируетя в ОС Nulix версии 6.2. Я прочитал ЧаВО (FAQ), но там нет ничего о проблемах с Nulix. Вот запись сеанса компиляции. Что я сделал неправильно?

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

Глупо: У меня проблемы с материнской платой. Не может ли кто-нибудь мне помочь?

Любой хакер на такой вопрос в уме ответит скорее всего так: «Хорошо. Может, тебе ещё помочь срыгнуть и пелёнку поменять?», и нажмёт на клавишу Delete.

Правильно: Я пробовал X, Y и Z на материской плате S2464. Когда это не сработало, я попробовал A, B и C. Обратите внимание на странный симптом при попытке сделать C. Очевидно, что эта фигня не фурычит, но результаты получаются непредсказуемые. Что обычно приводит к тому, что не фурычат многопроцессорные материнские платы с Athlon? Нет ли у кого идей для дополнительных тестов, которые помогут изолировать проблему?

Этот товарищ, напротив, кажется достоин ответа. Он продемонстрировал способность решать проблемы, а не просто ждёт, пока ответ упадёт ему с неба.

В последнем вопросе обратите внимание на небольшую, но важную разницу между «Дайте мне ответ» и «Пожалуйста, помогите разобраться, какие дополнительные диагностические действия можно выполнить, чтобы прояснить ситуацию».

Фактически, пример последнего вопроса очень похож на вопрос из реальной жизни в августе 2001 года в списке рассылки linux-kernel (lkml). Я (Эрик) задал тогда этот вопрос. Я наблюдал странные зависания на материнской плате Tyan S2462. Участники списка рассылки предоставили ценную информацию, позволившую мне от этих зависаний избавиться.

Задавая вопрос так, как это сделал я, вы даёте людям пищу для размышлений. Я сделал для них участие в решении проблемы простым и привлекательным. Я продемонстрировал уважение способностей коллег и пригласил их к обсуждению на равных. Я также продемонсрировал, что ценю их время, описав по каким тупиковым ветвям я уже прошёл.

В конечном итоге, когда я поблагодарил всех и подчеркнул, насколько хорошо прошёл процесс решения проблемы, один из участников списка рассылки обратил внимание на то, что, по его мнению, всё получилось не потому, что я «известный человек» в этом списке рассылки, а из-за правильной формы постановки вопроса.

Хакеры, в определённом отношении, очень жестокая интеллектуальная элита (в оригинале — meritocracy. Прим. переводчика В.К.). Я уверен, что прав, и если бы я облажался, то был бы раскритикован или проигнорирован, независимо от прежних заслуг. Его предложение описать ситуацию в качестве инструкции для всех остальных стало непосредственной причиной составления этого руководства.

Если ответ так и не получен

Если вы не получили ответа, не принимайте это на свой счёт, как наш отказ помочь лично вам. Иногда участники форума просто не знают ответ. Отсутствие ответа не равносильно игнорированию, хотя извне разницу заметить сложно.

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

Есть и другие источники помощи, к которым можно обратиться, причём часто более приспособленные к нуждам начинающих.

Существует множество групп пользователей в сети и на местах, с энтузиазмом занимающихся программным обеспечением, хотя многие их участники в жизни не написали ни одной серьёзной программы. Эти группы часто формируются для того, чтобы участники помогали друг другу и новым пользователям.

Есть также масса коммерческих компаний, с которыми можно заключить контракт на поддержку, как крупных, так и маленьких (одни из наиболее известных — RedHat и SpikeSource). Пусть вас не пугает идея платить за поддержку. В конце концов, если необходим капремонт двигателя автомобиля, вы ведь отдадите его в мастерскую и заплатите за ремонт. Даже если программное обеспечение ничего не стоило, нельзя рассчитывать, что его всегда будут бесплатно поддерживать.

У популярного программного обеспечения, вроде Linux, на одного разработчика приходится, по крайней мере, 10000 пользователей. Один человек просто не может справиться с поддержкой 10000 пользователей. Помните, что даже если за поддержку приходиться платить, это всё равно обходится намного дешевле, чем когда приходиться покупать ещё и само программное обеспечение (да и поддержка закрытого программного обеспечения обычно стоит дороже и выполняется менее компетентными специалистами, чем в случае программного обеспечения с открытым исходным кодом).

Как правильно и грамотно отвечать на вопросы

Будьте великодушны. Связанный с проблемой стресс может делать невежливыми или глупыми людей, которые таковыми не являются.

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

Если вы не уверены, так и говорите! Ошибочный, но авторитетно звучащий ответ хуже, чем отсутствие ответа. Не направляйте людей по ложному пути просто потому, что вам приятно быть в роли эксперта. Будьте скромны и честны. Показывайте хороший пример для спрашивающих коллег.

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

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

Хотя простой ответ RTFM бывает оправдан, когда даётся просто лентяю, ссылка на документацию (даже если это набор ключевых слов для поиска в Google) всё же лучше.

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

Помогите сообществу извлечь пользу из вопроса. Когда встречаетесь с хорошим вопросом, спросите себя: «Как надо изменить соответствующую документацию или список ЧаВО, чтобы больше этот вопрос никто не задавал?» Затем отправьте соответствующее дополнение тому, кто поддерживает эти документы.

Если для ответа на вопрос пришлось провести исследование, поделитесь своим опытом, а не пишите так, как будто ответ свалился на вас с неба. Ответить на один хороший вопрос — это как накормить голодного один раз, а вот изложить методику исследования на примере, — значит научить добывать еду на всю жизнь.

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

Если вам необходима информация по основам работы персональных компьютеров, ОС UNIX и сети Интернет, см. руководство The Unix and Internet Fundamentals HOWTO.

При создании программного обеспечения или выпуске исправлений для программ, постарайтесь следовать принципам, изложенным в руководстве Software Release Practice HOWTO.

Благодарности

Эвелин Митчел (Evelyn Mitchell) предложила прокомментировать ряд глупых вопросов и вдохновила на написание раздела «Как давать хорошие ответы». Михаил Рамендик дал ряд ценных предложений по улучшению документа.

Об этом переводе

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