Шрифт:
Что часто проявляется при работе с бета-версиями, так это то, что люди забывают ставить обновления. Механизм же бета-тестирования работает так, что пропуск обновления запросто может заставить вашу систему вести себя странновато. Некоторые новые драйверы или администраторы ресурсов могут вести себя со своими клиентами совершенно иначе, чем в предыдущих версиях.
В этом случае вы должны быть уверены (потому что вас обязательно спросят!), что все обновления установлены, и в нужном порядке.
Один из первых вопросов персонала технической поддержки обычно звучит так: «А оно происходит исключительно с бухты-барахты, или вы можете это повторить намеренно?»
Это не праздное любопытство. Если проблема проявляется редко, она столь же серьезна, как и проблема, которая проявляется регулярно. Главное — понять, с какой стороны подойти.
Обычно в случае редко проявляющейся проблемы персонал технической поддержки рекомендует сконфигурировать операционную систему и другие компоненты так, чтобы когда проблема проявится вновь, остался какой-нибудь отчет о состоянии системы или был вызван отладчик — чтобы можно было потом разобраться, что произошло.
Если проблемная ситуация легко воспроизводится, то технический персонал захочет воспроизвести ее на месте, чтобы продемонстрировать разработчику на «живой» системе. «Смотри-ка! Все умирает, стоит мне сде…»
Даже если проблема воспроизводима, персонал технической поддержки, скорее всего, не будет в восторге от перспективы переворошить 6000 строк вашей Си-кода в поисках затаившейся в его недрах ошибки.
В большинстве случаев, которые мне доводилось видеть, местоположение ошибки можно было сузить примерно до 20–30 строк максимум. Большие файлы могут быть действительно полезны для анализа в тех случаях, когда вы подозреваете, что ошибка связана с размерами объектов, а не с библиотеками или ядром. Например, у некоторых утилит может быть задан размер массива по умолчанию, и попытка увеличить его размер ведет к проблеме. В этом случае персонал технической поддержки может запросить у вас
Это «высосет» все содержимое каталога
Вы сможете затем переслать полученный файл
Если вы убеждены в том, что нашли ошибку (например, утилита «падает» по SIGSEGV), вы можете не выставлять ее на всеобщее обсуждение в телеконференцию, а напрямую сообщить об ошибке в QSSL при помощи команды
Другие источники информации
Кроме QUICS, существует ряд других информационных ресурсов, куда можно обращаться за помощью, информацией или услугами. Ниже приведен далеко не полный список, но по крайней мере у вас будет с чего начать.
Веб-сайт компании QSSL, особенно его раздел техподдержки (
Это обычная телеконференция USENET. Она была создана для пользователей QNX, чтобы они могли вместе обсуждать проблемы, особенности, решения, и т.п.
Персонал QSSL не всегда следит за этой конференцией (хотя некоторые там все-таки прячутся). Вообще это конференция для тех, у кого есть вопросы, но нет продуктов QNX. В эту конференцию периодически вывешивается сборник ЧаВо (Часто задаваемые Вопросы, или Frequently Asked Questions — FAQ — прим. ред.), из которого можно узнать много полезного о продуктах.
Если вам нужен гарантированный ответ, то лучшим выбором была и остается QUICS.
Каталог «третьих» фирм — продукты и консалтинг
Компания QSSL издает Каталог «третьих» фирм (Third Party Directory), в котором перечислены все сторонние компании и их продукты для QNX (например, многопортовые платы последовательного интерфейса, аппаратные средства стандарта X.25, программное обеспечение), а также представлен список организаций и лиц, оказывающих консалтинговые услуги при разработке проектов.