Баг пофиксили что это
Что значит «пофиксить» и «фиксить» в интернет-сленге?
В разговорах геймеров, программистов и других продвинутых юзеров мышки и клавиатуры часто проскакивают непонятные слова: фича, лаги, баги, фиксить… При этом человеку, далёкому от сферы, трудно сориентироваться в теме. Tакая терминология озадачивает, в то же время подогревая интерес и желание так же лихо форсить айтишным арго, как это делают профессионалы. Так давайте разберёмся!
Происхождение и значение
Основная часть интернет-сленга – результат русификации английских слов, и «фиксить» не стало исключением.
В переводе с английского, «tofix» означает «чинить». Среди русскоязычной аудитории прижился вариант «фиксить» или «пофиксить».
Английский язык, а также всевозможные русифицированные производные от английских слов или фраз, наполняют интернет-сленг. Что же касается общих чатов в MMORPG играх, то там сленг превалирует, и нубу (в том же сленговом выражении – «зелёному» новичку или неудачнику), не понятно ни единого слова. И в тех же играх это слово, кстати, имеет двоякое толкование.
Как «фиксят баги» в MMORPG
Помимо общепринятого, «пофиксить» может иметь негативный характер. Зачастую это значит, что определенную категорию лишат значительной части умений. Для примера, возьмем World of Warcraft с его многомиллионной армией подписчиков и почитателей по всему миру. Бывает, очередные обновления приносят не только улучшения и решения по самой игре, но и отдельные решения по игровым классам.
Так, в последнем обновлении игры разработчики сочли нужным «пофиксить» вопросы, связанные с превалированием одного из ведущих составляющих игры, а именно Орды, над Альянсом. И такое решение разработчиков полностью изменило игру! Игроки, которые годами играли за одну из фракций, стали покидать ее из-за того, что разработчики «пофиксили баги» – внесли изменения, убирающие преимущества одной из противодействующих сторон.
Мировая паутина не ограничивается одними играми, есть и более серьезные, уж простите нас, геймеры, занятия, в которых фиксить необходимо.
Игровые баги и лаги
Как фиксить системные баги?
Интернету на днях исполнилось 30 лет. Представить современный мир без него невозможно. Все, от мала до велика, начинают день с просмотра новостной ленты, свежих фотографий у друзей в Instagram или обновления статуса в «Одноклассниках». Всё привычно, никто не задумывается о том, что нужно залогиниться, войти в программу, каждое действие обыденно и производится автоматически. Всё идет хорошо, пока вместо привычной стартовой страницы экран не начинает показывать системные сообщения об ошибках.
Чтобы «починить», пофиксить, сбои приходится обращаться к профессионалам, для которых понятие «курить мануал» – не просто смешное словосочетание, а образ жизни. Невидимый для простого пользователя мир программного обеспечения довольно хрупок, и зачастую, достаточно внести небольшое изменение в системе, чтобы нарушить весь отлаженный рабочий цикл. Для восстановления же нормальной рабочей среды порой приходится затратить большие усилия, фикся, исправляя пустяшные, казалось бы, баги.
Значительная часть сбоев происходит на уровне реестра ОС, для корректировки которого идеально подходит небольшая утилита Hijackthi.
Hijackthi – инструмент, помогающий фиксить баги
Это знакомая и привычная утилита для всех, кому понятие «админка» не режет слух. Фиксить сбои в среде Windows с её помощью удобно, и при понимании дела, абсолютно безопасно. Однако, если написание поста в Facebook – предел знаний IT-технологий, фиксить сбои самому лучше не браться, а обратиться к специалистам.
Что нам стоит пофиксить баг, которого «нет»
Итак, у нас есть задача: пофиксить баг, производитель от которого открещивается, клиенты не замечают, а жить хочется. Есть камера, поток от неё на UDP просто адово ломается, поток на TCP работает, но постоянно рвутся коннекты (и при каждом обрыве пропадает 3-5 сек видео). Виновны в проблеме все (и камера и софт), но обе стороны утверждают что у них всё зашибись, то есть ситуация обычная: ты баг видишь? нет. А он есть.
Так как софт обновляется гораздо чаще, чем камера, имеет смысл править то место, которое потом не придётся трогать. Значит, будем фиксить со стороны камеры.
Исследование плацдарма
Перво-наперво берём свежайшую прошивку (в моём случае — firmware_TS38ABFG031-ONVIF-P2P-V2.5.0.6_20140126120110.bin), и выясняем что же она такое:
Итак, формат его неизвестен, стартовая метка «FIRMWARE» навевает мысли о том, что это что-то своё, наличие внутри uImage ядра и cramfs файлухи подсказывает, что по факту это что-то простое. Наличие строки TS38OEMABFG_LINUX подскзывает что это что-то даже напоминает какой-то вариант архива.
Так как нам сейчас надо просто найти где искать — просто вытаскиваем оттуда файловую систему, и ищем виновный модуль:
Хохохо! «sendRTPOverTCP failed, sock: %d, chn: %d» говорит нам о том, что код оттранслирован с отладочными принтами, а значит, объём работы снижен на порядки!
Итак, у нас есть модуль, содержащий искомую ошибку, модуль с кучей отладочных строк внутри, а значит процесс раздербанивания значительно упрощается.
Локализация и фикс проблемы
Грузим модуль в дизассемблер, ищем по «OverTCP» строку отладочную, от неё ищем код вызывающий распечатку => мы нашли функцию sendRTPOverTCP.
Проглядывая её бегло видим два вызова функции send() — одна с 4 байтами, одна с буфером переданным на вход. Значит, нам досталась версия не самая старая, а когда уже объединили буфер, но еще не сделали функции sendDataOverTCP (подробности о различиях реализации — в прошлом посте.
Теперь возникает вопрос, как можно поправить баг в бинарном виде, когда практически нет запаса по месту (пустого пространства внутри файла нет).
Идём в функцию выше, которая вызывает sendDataOverTCP — sendPacket. Её код от версии к версии не менялся, он по сути один — foreach(streams) < sendDataOverTCP(packet, stream) >.
По счастью, код был щедро напичкан отладочными fprintf’ами, и это нас спасает! Вот как этот цикл выглядит в бинарном виде:
Это фактически спасение! Просто вырезка отладочного куска даёт нам место в размере 12 инструкций (у ARM все инструкции ровно по 4 байта, и это очень хорошо).
Итак, у нас есть место в 12 инструкций, чтобы что-то сделать для улучшения ситуации. Но что? Полноценно впихнуть сюда код sendDataOverTCP из последней версии будет сильно затруднительно…
Хотя стоп. А зачем? Я, вроде, подробно описал, что даже использование корректной формы sendDataOverTCP всё равно плохо… А если не видно разницы — почему бы просто не обернуть вызов в makeSocketBlocking()..makeSocketNonBlocking()?
Действительно, если место в системном буфере есть — send() выполнится моментально. Если места нет — то и их реализация sendDataOverTCP всё равно залипнет (почему залипнет а не вывалится сразу с нулём — смотри предыдущий пост).
Отлично! Путем быстрой отмотки назад от функции fcntl находим makeSocketBlocking и makeSocketNonBlocking, после чего рисуем какой должен получиться код:
Для того чтобы запатчить, либо открываем документацию на арм и транслируем в уме, либо пишем код в отдельном файле и транслируем его (не забываем ORG’ами выставлять точные адреса, чтобы все переходы (BL/BGE/ИТД) пересчитаны были корректно), а я всего лишь находил подходящие инстуркции в коде и на их основе вычислял нужные опкоды (первый раз редактирую ARM, уж извините).
В результате получаем rtsp_streamer с наложенным на него патчем, защищающим TCP поток от порчи.
Пайка взрывом, сборка трезвым
Итак, у нас есть новый rtsp_streamer, и есть firmware. bin в который его надо встроить. Ну тут, вроде, всё просто: надо распаковать cramfs, заменить файл, запаковать обратно, заменить его внутри bin’а:
Откроем его в hex редакторе, и начнём кумекать:
(0) «FIRMWARE» — 100% заголовок, 8 байт.
(8) 64 81 DB 15 — 4 байта, назначение непонятно. по запаху — контрольная сумма
(12) 0x00E847C4=15222724 — ага, 4 байта, размер прошивки. проверяем _new.bin — нет, размер не изменился, значит, он не при чем.
(16) 0x00000003 — 4 байта хз что. версия заголовка может?
(20) 0x00000614=1556 — так, а это смещение до ядра внутри
(24) 0x001BF1B0=1831344 — а это размер ядра (1831344+1556=1832900)
(28) 4C 21 81 5D — хм. опять что-то на контрольную сумму похожее.
(32) «TS38OEMABFG_LINUX» и куча нулей потом — 100h байт, явно место под название раздела
(288) 0x001BF7C4=1832900 — ага, смещение до следующей секции
(292) 0x00CC5000=13389824 — ага, размер секции
(296) «TS38OEMABFG_V2.5.0.6» и куча нулей — опачки. 100h байт, явно под название раздела.
Но контрольной суммы перед ней нет O_O
(552-1556) — нечто неизвестной наружности.
Итак, примерно суть ясна. Размер нашей cramfs не изменился, значит, это не размеры, а значит, контрольные суммы.
Извлекаем ядро, и считаем его контрольную сумму длиной 4 байта:
Ну-ка ну-ка… по смещению 28 как раз 0x5D81214C. Повезло — это стандартная CRC32. Повезло потому, что по стандартная тулза умеет только его считать. Иначе пришлось бы запускать питон и считать уже «сложнее» 🙂
Итак, контрольные суммы у нас — crc32. А какая контрольная сумма у оригинальной cramfs. 37499eef. Так-так-так. По смещению 552 как раз и записано 0x37499eef. Значит, для файловой системы почему-то контрольная сумма ПОСЛЕ имени раздела записана. Ну ОК, чего нам, мы не гордые. Обновляем табличку:
(28) 0x5D81214C — crc32 раздела ядра
(552) 0x37499eef — crc32 раздела FS
(556-1556) — нечто неизвестной наружности
Пересчитываем crc32 newcramfs, hex редактором вписываем по смещению 552 его в бинарь, заливаем в камеру.
И… ничего O_O. Значит, чутьё не подвело — по смещению 8 действительно crc32, но от чего?
Тут действуем просто — начинаем брутфорсить.
Отлично, быстро справились. Значит, обновляем табличку:
(8) 0x15DB8164 — CRC32 заголовка (первых 1556 байт), сперва занулив это поле
Итак, тут же в питоне быстро пересчитываем crc32 от заголовка firmware_new.bin и вписываем в hex редакторе его в начало.
Заливаем в камеру… Она уходит в ребут. И не отвечает… не отвечает… еще кирпич… О! Пинги пошли! Фууух.
Берём cam-resync.py, и опять тыкаем палочкой нашу камеру. И… и поток не ломается! Вот прямо вот так, с первой попытки! Уииии 🙂
На хлеб мажется, и есть уже можно, но что-то не то
Ранее упомянутый Андрей Сёмочкин тем временем собрал свою прошивку с исправленным мною rtsp_streamer’ом и залил её на одну из проблемных камер, с которых шло много разрывов. В результате тестирование показало, что поток не ломается, однако начались артефакты видео, такие же, как при потере пакетов на UDP. Так как я ничего не встраивал такого, стало любопытно, что же это было — пришлось еще раз заглянуть в код. Для начала, заглядываем в strings, у нас же куча отладочных строк. «checkBufferTimeout for %d seconds. », «buffered data more than %d ms, drop all the buffered data. ».
Ага! Оказывается, производители сделали защиту от переполнения! И если по какой-то причине пока синхронный send() завис на больше чем надо (по дефолту — 1 сек), он излишки дропает. Это защищает от OOM и от отставания видео, если оно не влезает в тонкий канал. Но код раньше явно не работал из-за использования неблокирующих сокетов и send()’а.
После оборачивания в Blocking. NonBlocking — код начал работать 🙂
Однако есть небольшая проблемка: 1 сек это мало. Если канал начинает сбоить, однако достаточно толстый, то вероятность дропа становится всё сильнее. После любого такого дропа видео восстанавливается только после кейфрейма. Обычно кейфрейм достаточно редко (раз в 5-10 сек)… И получается неприятная ситуация — если был сбой, то 5-10 сек надо ждать до следующего кейфрейма чтоб видео починилось. Если сократить частоту кейфрейма — это автоматически увеличивает объём передаваемых данных, так как кейфреймы довольно толстые, а значит увеличивает частоту помирания канала. Замкнутый круг.
В общем, я дополнительно увеличил таймаут буферизации до 10сек — этого должно быть недостаточно чтобы словить OOM, но достаточно чтобы спокойно переживать ретрансмиты и лаги на не суперстабильных каналах.
Кстати, «хитрый» алгоритм лечения
Я в прошлой статье пообещал рассказать, как же легко починить ситуацию. Решение просто как валенок — так как мы отправляем RTP пакеты, у нас в каждом есть timestamp. Достаточно в sendRTPorRTCPPacketOverTCP проверять ДО отправки срок жизни пакета, и если он меньше настроенного (я всё-таки считаю что 1 сек это мало на TCP, надо именно 6-10 сек) то отправлять, иначе просто молча не отправлять его.
Автоматизируем сборку-разборку
Осталось дело за малым: автоматизировать сборку-разборку прошивки.
В остальном распаковка не имеет никаких интересных моментов.
А вот упаковка уже чуток сложнее. Нам надо запаковать обратно cramfs, обновить в заголовке длины отдельных файлов и общую длину; пересчитать и контрольные суммы, включая заголовок и только после этого слить всё вместе.
Вообще, камера проверяет граничные значения сама, однако для удобства я добавил проверку на границы размеров файловой системы и ядра, чтобы если при сборке её размеры выползают за пределы, получить предупреждение и поудалять лишние хвосты из прошивки.
Результат трудов
Если вдруг вам потребуется фикс на какой-либо другой модуль этого же производителя — пишите в комментах, буду посмотреть по возможности.
Итак, менеджер попросил пофиксить баг…
Вы были здесь прежде. Ваша программа элегантна. Вы использовали точно требуемое количество абстракций. Ваши модули безупречно модульные. Ваша система имеет дело с внешним миром через продуманные интерфейсы и не имеет никакой прямой зависимости от внешних систем. Ваши тесты пройдены безукоризненно. Ваш отчёт о покрытии тестами кода требует целую минуту для загрузки. 97% это значит…
Жизнь прекрасна. А затем происходит нечто.
Продуктовый менеджер врывается и заявляет, что в обновлении, отправленном вами на прошлой неделе, обнаружен баг. Всякий раз, когда пользователь добавляет какую-то позицию в свою корзину для покупок, счётчик, который предназначен для показа количества позиций в этой корзине, обновляется лишь через несколько секунд. А раньше обновление происходило мгновенно.
Менеджер сообщает, что жалобы от пользователей идут потоком. И он спрашивает: «Можешь ли посмотреть?».
Конечно, вы можете посмотреть. В конце концов, именно вы создали этот продукт. Это, скорее всего, вина кого-то другого. Но вы собираетесь устранить ошибку. Это — часть работы своего рода «кризисного» сотрудника, которым вы и являетесь.
Вы вытягиваете Git hash из самого последнего релиза и копаетесь в журнале изменений. Вы обновили библиотеку HTTP-запросов до самой последней версии в последнем релизе. Это и так откладывалось довольно долго. Вы можете вспомнить коммит, который привёл к этому. Это был хороший день.
Вы переключаетесь на коммит, затем имитируете запрос, который обновляет корзину для покупок. Хорошо, что у вас есть такое чёткое разделение задач. Можно легко провести тест на вспомогательном и продакшен серверах с продвижением флага сборки.
Вы нашли преступника. Похоже, что HTTP библиотека, которую вы обновили, имеет дефект. Для определённых типов запросов ей требуется довольно много времени, чтобы проанализировать поступающее информационное наполнение в формате JSON. Ваше приложение может обновить пользовательский интерфейс счётчика корзины для покупок только после того, как информационное наполнение запроса проанализировано. Инфраструктура не настроена для обработки возможной согласованности и добавления того, что могло бы быть отдельным проектом само по себе. Вы не можете просто обновить счётчик локально и засинхронизировать позднее.
Вы знаете, что кто-то, не вы, допустил ошибку. Такова жизнь.
Вы информируете менеджера о случившемся. Он одобрительно поздравляет вас. Он говорит, что, конечно, всегда знал, что на вас можно положиться. Он спрашивает, известно ли, как устранить этот баг?
Ну, конечно! Вы уже рассмотрели все возможности.
Откатить по изменениям невозможно. Весь новый код и исправления багов завязаны на новую версию библиотеки. Вы потеряете также их все, если просто откатите всё назад.
Просто форкнуть эту библиотеку и работать с вашей собственной копией также не представляется разумной идеей. Эксплуатационный персонал исходного проекта имеет гигантскую тестовую инфраструктуру, которая протестирует ваше исправление на тысячах устройств. У вас же имеется три устройства, на двух из которых стоят устаревшие версии операционной системы. Лучше всего получить обратную связь от них также. Это же, в конце концов, их библиотека, и они должны знать её устройство, а не вы.
Итак, действия спланированы:
«Замечательно», — говорит вам менеджер. «Сколько по-твоему это потребует времени?».
Вы знаете ответ. Некоторые думают, что технические специалисты неспособны оценить время. Но вы-то точно не из таких специалистов.
«2 недели» — без запинки отвечаете вы. «Зависит от того, как быстро будет принят запрос на включение кода и как быстро эксплуатационный персонал выдаст новую сборку».
Лицо менеджера на глазах белеет. «2 недели? 2 недели?!». Он продолжает повторять эти два слова, как будто они могут изменить что-то. Но вы остаётесь спокойным. Менеджеры, как известно, слабые ребята, могут кипятиться. Не стоит вам волноваться из-за этого.
«От нас уйдут наши пользователи! Они ничего не покупают, потому что не видят, что происходит с их корзинами! Мы же компания, торгующая через интернет! Это невозможно!».
Вы наблюдаете, как он проходит 5 этапов отчаяния. Вы ждёте, пока он, наконец, согласится. Но это не происходит. Он, кажется, пытается прессовать.
«Неужели нет какой-либо возможности исправить быстрее? Ну, может быть, что-нибудь временное? Ну, подумай! Это очень важно!».
«Хорошо», — говорите вы, опускаясь на ваше вращающееся кресло. «Дай посоображать».
Вы уступаете ему немного. Может быть, тогда он оставит вас в покое. У вас много других дел, вы это знаете.
Вы опять погружаетесь в источник. Вы в своей стихии. Ваши пальцы перемещаются по пиктограммам IDE, подобно богу Посейдону, скользящему по волнам океана.
О! Вы нашли его. Есть незадокументированный способ войти в программу анализа JSON и заменить её вашей собственной разработкой!
Но подождите. Это может быть опасным. Здесь программный интерфейс приложения является непубличным. Возможно, неправильно поступить с ним так, как вы предположили. Вам не хочется идти на это. Что если в следующем выпуске ошибка будет устранена? Тогда придётся проделать всё это заново. Есть желающие? Хотя это быстрее, чем поддержание вашей собственной, непротестированной, ветви библиотеки. Опять же, это опасно.
Вы не позволите сомнительным бизнес-решениям разрушить ваш храм чистоты. Вы являетесь хранителем всего святого в борьбе с невежественными массами. Ведь именно за это вам платят большие деньги. Ваш долг, в такой ситуации — отказаться.
Вы быстро входите в закуток менеджера: «Я говорю тебе — нет! Здесь нет чистого способа сделать это и я не могу полагаться на небезопасные хакерские трюки. Извини.»
Он реагирует ожидаемо.
«Ты говоришь, что есть способ решить проблему, но не будешь это делать, поскольку способ, оказывается, нечистый? Наши пользователи буквально кричат на нас, угрожают уйти к нашим конкурентам, а ты не желаешь устранить баг, потому что способ нечистый?!»
Вы теряете контроль над собой.
Что этот парень знает о проектировании программ? Вы создали фантастические миры из ничего, кроме битов. Великолепно масштабируемые системы, которые могут противостоять DDoS-атакам всех компьютерных хакеров бывшего советского блока, созданы вами. Вы — художник, а компьютер — ваш холст. Вы прочитали книгу «Чистый код» Роберта Мартина столько раз, что знаете её лучше, чем даже собственный GitHub-паспорт.
«Да!», — срываетесь вы. «Я не замараю нашу базу кода этим дерьмом! Я потратил месяцы своей жизни на создание этого дворца! В каждой строке кода запечатлелись моя боль и кровь! Единственная причина по которой здесь, вообще, что-то работает — в том, что всё делалось не благодаря вам, а несмотря на вас. Именно такие, как я, обеспечивают работу всех этих программ и именно такие, как я, должны будут долго приводить в порядок всю эту мешанину, после того как вы и ваши „бизнес-процессы“ уйдут!»
Вы вылетаете из закутка. Что-то выпиваете. Такие парни, как этот — просто бедствие нашей отрасли. Они думают, что их модные степени магистров бизнеса дают им какое-то понимание в вопросах создания серьёзного ПО, что разработчики почему-то прощают. Надо давать им отпор.
Вы заходите в кафе. То, где вы каждый день получаете изысканные блюда. И кофе. Восхитительный, ласкающий душу кофе — безо всяких ограничений. Вы заслуживаете этого, потому что вы — высококвалифицированный специалист.
Вы берёте чашечку кофе и смотрите, где бы присесть.
И тут вы видите его.
Самого почтенного по годам специалиста в нашей компании.
Этот человек относится к крутым, бескомпромиссным специалистам типа «я-могу-написать-компилятор-за-5-минут». Он был хакером ещё до того, как появились хакеры. Вы желаете быть похожим на него. Он отчасти похож на мага Гэндальфа из книг Толкина. Все его уважают и боятся одновременно. Но он добр и всегда выручает детей. Он точно захочет услышать, как вы поставили этого менеджера на место. В конце концов, он — один из представителей вашего цеха.
И вы садитесь рядом с ним. Он не спеша пьёт свой кофе и читает что-то вроде «Абстрактные типы данных в Haskell».
Да. Просто коллега, чтобы поговорить.
Вы излагаете ему свою эпопею. Он терпеливо выслушивает. Он кивает и задаёт несколько вопросов. Его тело спокойно и расслаблено. Он был здесь прежде. Вы можете видеть это в его глазах.
Вы, наконец, закончили.
Это было утомительно.
Вы сбросили груз с плеч.
Он смотрит в раздумье, как будто тщательно подбирает слова.
Вы ждёте, что он громко рассмеётся. Он воскликнет: «Да, мой мальчик!» — а затем вы выпьете ещё по чашечке кофе вместе. Он развлечёт вас историей похожей взбучки, которую он задал бестолковому менеджеру сто лет назад.
Вы мечтали об этом дне. Вы стукнете друг о друга ваши чашки с кофе, как это делают мужчины после победы в битве. По крайней мере, так они делают в кино. И, конечно, у них — не чашки, а кружки, а в кружках — пиво, а не кофе.
Это — сентиментальность, хотя она имеет значение.
Он смотрит вам прямо в глаза. Его взгляд проникает в вашу душу. Долгие годы разборок с машинами придали его глазам твёрдость. И он несёт в себе завораживающую мощь. Вы не можете отвести взгляд.
Он произносит совсем немного.
«Ваша работа состоит не в том, чтобы пить кофе и уклоняться от написания кода. Ваша работа в том, чтобы делать программы, которые работают.»
Вы сидите минуту. Возникает неприятное ощущение в области желудка. Ощущение пустоты и подташнивания. Вы начинаете понимать, что это за ощущение. Вам стыдно.
Вы подвели людей, которым вы обязаны больше всего. Ваших клиентов.
И вы идёте назад к вашему компьютеру. Вы быстро взламываете программу, затем удаляете последний релиз.
Вы извиняетесь перед менеджером: «Извини, друг, дела вышли немного из-под контроля». Он говорит, что всё в порядке. Всё хорошо, что хорошо кончается.
Вы также выводите в отдельную ветвь библиотеку, устраняете баг и посылаете её расположенному иерархически выше менеджеру по продукции. Когда новый релиз библиотеки с правильным решением придёт, вы всегда сможете перепроектировать ПО.
О лагах, багах, глюках и всяком таком
Приветствую вас, дамы и господа! Идея сего блога зародилась у меня относительно недавно, когда я в очередной раз столкнулся с глюком стима, и затем подумал, может у меня у одного так? Эти размышления не привели ни к чему, кроме идеи написания этого поста. Как-то так, поехали, что ли.
Для начала скажу, что вообще есть лаги и баги (сделайте вид, что вы не знали). Баги и лаги, хоть и понятия смежные, путать их нельзя, ибо баг (bug) — ошибка в программе или системе, из-за чего та может начать творить всякое непотребство, непредусмотренное разработчиком. Лаг (lag) — это задержка в работе компьютерного приложения, или проще говоря, запоздалая реакция на действия пользователя. Во-о-от.
Теперь, перейдем же скорее непосредственно к самой теме поста. Итак, начну издалека. За всю жизнь у меня было всего-ничего, четыре компьютера (включая нынешний), и каждый, наверное, просто считал своим долгом вдоволь посбоить.
Под словом «сбоить» я подразумеваю ошибки запуска. Бывало ли когда-нибудь у вас, что компьютер вместо вашего профиля загружал «временный профиль», ссылаясь на некий сбой?
Или же вообще отказывался запускаться, выводя на экран вместо окна ввода пароля какие-нибудь сообщения об ошибке. У меня вот было. Причем появлялись такие сбои абсолютно случайно, независимо от моих действий. Благо, все это лечиться перезагрузкой.
Да и хрен с ним, если бы такая котовасия происходила только на одной машине. Нет! На каждом моем компьютере было нечто подобное, за исключением нынешнего. Правда, собран он совсем недавно, поэтому, я чувствую, все еще впереди.
Ну это, конечно, частные проблемы одного человека. Перейдем же лучше к проблемам сервиса Steam, о которых я говорил в начале блога.
(Далее моих скринов нет, ибо как только я начал писать пост, стим лагать перестал, паскуда эдакая. Поэтому я нашел чужие с аналогичными ошибками. Свои скрины дам как только, так сразу).
Так вот, встречалось ли вам подобное:
И это при наличии интернета. Вот у меня такое очень часто случалось. Хочу перейти к ленте активности и не могу. Приходилось обновлять страницу по нескольку раз, чтобы, наконец, прогрузилось нормально.
Или же вот вам другой пример:
Лично у меня, как и автора скриншота, такая проблема возникала только с Dragon Age’eм. Мне пришлось, если не ошибаюсь, ждать три дня, чтобы загрузить игру. Однако, если хотите знать, это не единственная проблема с лицензией данного продукта. В стиме в подарок к игре нам дают пару ДЛС, одно добавляет нового сопартийца, другое красивые шмотки. Так вот, чтобы их активировать тоже нужно повозиться, ибо сами они ни за что не загрузятся, но это уже другая тема.
А вот тоже уже довольно опостылевшая ошибка:
Возникает, как не сложно догадаться, при попытке обмена. Она сорвала мне несколько сделок, за что особо мной нелюбима, сволочь… И причем этот глюк может преследовать вас неделями, а у других он пропадает просто при перезапуске обмена.
Ну и также, как и мой компьютер, стим любит потрепать нервишки при попытке его запустить:
Это одна из множества ошибок, которые стим может выдать при запуске. Данная — одна из самых мерзких, ибо с ней тяжело бороться. Иногда она проходит сама, иногда требуются какие-нибудь действия, причем, в зависимости от пользователя, разные. Говоря это, я основываюсь на личном опыте. Я со стимом уже три года, и такая ошибка выпадала мне довольно часто. Каждый раз требовались разные меры. Один раз, например, пришлось лезть в корневую папку и удалять определенные файлы, другой раз зарешала только полная переустановка, третий раз пришлось перезапускать компьютер. Вот недавно она у меня опять возникла, я думал-думал, что с ней делать, да и решил просто попробовать запустить стим заново, особо ни на что не надеясь. Помогло, черт возьми!
Это просто другая ее разновидность. Лечиться она также всегда по-разному.
А вот эту ошибку я называю «Назад в Будущее»:
Это довольно забавная ошибка, согласитесь. А самое главное, она безвредна для пользователя. Однако, она довольно редкая, сам с такой не сталкивался.
Однако, тут неудачный для демонстрации ошибки скриншот, ведь причина такого очевидна — разница в часовых поясах.
Продолжая тему ошибок стима, можно было еще затронуть ошибки магазина, появившиеся на радость пользователям совсем недавно, но вы и сами прекрасно их знаете.
Ежели я начал говорить о Steam, нельзя не сказать пару слов об несуразностях-багах-ошибках в играх Valve. К сожалению или счастью, я могу вспомнить только два. Один очень неприятный и отвратительный, другой мелкий и незначительный. Начнем с самого гадкого.
Он, как вы, возможно, поняли, относиться к глубоко обожаемому мной Team Fortress 2. Тогда, в далеком 2011 году (тогда еще стим нас на дáллары разводил, рублей не было, все за доллары), я узнал о том, что эта игра стала бесплатной. Ради нее я скачал стим, играл-играл и в один прекрасный момент мне надоело быть бесплатником, захотелось шапок, обмена и прочих радостей доната. И я положил тогда на стим свои первые деньги. И вот, я почти вкусил пончик, а тут мне эта чертова ошибка. Ждать пришлось сутки. А за эти сутки распродажа вещей кончилась. Стоит ли говорить о моем баттхерте? Пожалуй, нет. Вы сами можете это представить.
Следующий на очереди маленький баг на карте Inferno в CS: GO:
Мелочь, а не приятно! И эту ошибку, кстати, не пофиксили до сих пор. А скрин я этот сделал, когда игра только-только вышла. Я не ожидал от Valve такой безалаберности.
Ну и еще мимоходом поведую вам о багах на! StopGame.ru. Да-да, именно здесь, где мы с вами сейчас находимся. Правда, когда я сказал «багах», я немного слукавил, ибо найти мне удалось только один баг. Вот он:
Узреть его воочию можно, если набрать в поисковике точное название вашего топика и перейти по ссылке на сайт.
Но как бы там ни было, пора бы уже и заканчивать. Напоследок, попрошу вас писать в комментарии об ошибках, которые случались у вас, желательно со скринами. На этом все. До скорого, что ли.