Алексей Бородкин, product lead и глава Гильдии вольных проектировщиков, рассказал на открытом занятии Нетологии, как разобраться в дизайнерских направлениях и распределить роли в дизайн-команде.

Дизайнерские тусовки

Когда-то — в буйные 90-е — никаких веб-дизайнеров не было, и сайты создавали вебмастера — отважные люди с программистским бэкграундом, которые все делали сами: собирали требования, кодили, рисовали, делали контент и развивали сайт.

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

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

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

Примечательно, что и тех, и других не особо интересовали внутренности продукта — сама система, поверх которой натянут дизайн. Они воспринимали ее как «черный ящик» для разработчиков.

Тут стоит рассказать про еще одну продуктовую тусовку, которая существовала параллельно визуальным и UX-дизайнерам — это системные архитекторы.

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

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

Из чего состоит цифровой продукт

Давайте отвлечемся от эпического противостояния дизайнеров и посмотрим, из чего состоит любой цифровой продукт — мобильное приложение, интернет-магазин, система управления аэропортом:

Продукт начинается с трех фундаментальных групп требований:

• Бизнес-требования: бизнес-цели и задачи, требования заказчика, бизнес-риски и так далее.
• Пользовательские требования: структура целевой аудитории, их задачи и сценарии поведения.
• Технические требования: техническая платформа, смежные системы.

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

У самого продукта можно выделить три составляющих успеха:

• Интерфейс: как пользователь воспринимает продукт и взаимодействует с ним.
• Функциональность: какими фичами обладает продукт, как он работает и что позволяет сделать.
• Информационная архитектура: как выглядит система, какова структура данных, какие есть потоки данных и прочее.

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

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

И возникает простой вопрос: кто же должен заниматься продуктом?

Дизайн и проектирование

В России проектирование и дизайн — две разные профессиональные сферы:

Однако, если погрузиться в исходное значение терминов, мы обнаружим удивительные открытия. Вот, например, определение слова design в оксфордском словаре:

Глагол to design — определять внешний вид и принцип работы здания, одежды или иного объекта посредством создания детальных чертежей.

Существительное design — план или чертеж, иллюстрирующий вид, устройство или принцип работы здания, одежды, либо иного объекта до его создания.

А вот строгое определение слова «проектирование» по ISO 24765:

Проектирование — процесс определения архитектуры, компонентов, интерфейсов и других характеристик системы или её части.

Занятно, правда? Получается, что значения слов «проектирование» и «проект» тождественны глаголу to design и существительному design. В этом можно убедиться, если посмотреть перевод слова «проектирование» в Google-переводчике:

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

Как связать внутреннее с внешним

Но вернемся к нашим дизайнерам. У нас есть тусовка из UX- и визуальных дизайнеров, которые в основном думают только о красоте и пользовательском опыте:

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

Интуитивно понятно, что для целостной работы над продуктом их надо объединить. Стоит отметить, что рынок веб-разработки об этом начал задумываться еще в начале нулевых. Так родилась должность менеджера, который скрепляет эти разнонаправленные сферы интересов:

Давайте посмотрим, к чему это приводит.

На менеджере оказывается нехилая нагрузка:

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

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

Допустим, менеджеру приходят две параллельные задачи. Одна — починить отвалившуюся форму заказа, вторая — подробно описать ТЗ на следующий релиз.
Естественно, что менеджер в первую очередь займется тушением пожара — «прикручиванием» формы заказа, потому что с каждой минутой из-за неработающей формы заказчик теряет деньги и впадает в бо́льшую истерику. Задачу с подробным описанием ТЗ придется отодвинуть на второй план, закладывая в фундамент проекта стратегические риски. И так будет постоянно.
Вкусив прелести такой работы что на агентской, что на продуктовой стороне, я сформулировал для себя иное решение этой проблемы — поделить задачи между двумя специалистами: менеджерские задачи оставить менеджеру, а продуктовые отдать специально выделенному product-дизайнеру.

Зона ответственности дизайнера продукта

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

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

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

Кто входит в тусовку продуктового дизайна

UX-дизайнер

Задача UX-дизайнера: сделать продукт удобным, полезным, комфортным для пользователей.

UI-дизайнер

Задача UI-дизайнера: сделать «красиво» и эстетично.

UX-аналитик

Задача UX-аналитика: влезть в голову пользователя, вытянуть важное и передать информацию UX-дизайнеру для реализации в дизайне.

Системный архитектор

Задача системного архитектора: проработать внутреннюю логику и архитектуру продукта.

Дизайнер продукта

Задача дизайнера продукта: свести все «нити» создания продукта и отвечать за результат.

Менеджер продукта

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

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

Product lead / директор по продукту

Задача продакт-лида: следить за развитием продукта. Эта роль является «надстройкой» над ролью продуктового менеджера, и концентрирует в его руках не только функции по созданию продукта, но и развитие продукта в дальнейшем.

Как выбрать профессию

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

Что интересно	Подходящая профессия
Психология	UX-аналитика
Внутренняя составляющая	Системный архитектор
Рисовать	UI-дизайнер
Психология + рисовать	UX-дизайнер
Всё и сразу	Продуктовый дизайнер, Продуктовый менеджер, Product Lead

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

От редакции

• Онлайн-курс: «Продуктовый дизайнер»
• Онлайн-курс:«UI-дизайнер»
• Онлайн-курс:«UX-дизайнер»
• Онлайн-курс:«Fullstack-дизайнер»
• Онлайн-курс: «Веб-дизайн: эффективный сайт от идеи до реализации»

Как известно, основное визуальное изменение в релизе 18 — это отказ от Unity и переход на Gnome 3. Здесь хочу поделиться своими впечатлениями от перехода с 16 на 18

Сначала о хорошем…

Релиз 18 принёс нам новое ядро Linux (4.15) с заплатками от Meltdown и Spectre, которые включены по умолчанию и, по предсказаниям специалистов, должны сильно деградировать производительность компьютера. Однако несмотря на то, что мой процессор (Intel Core i5) и входит в список уязвимых, а значит заплатки для него включены, что подтверждают логи загрузки, в своих обычных задачах какого-то ощутимого падения производительности я не заметил. Поэтому, если ваш компьютер не является сервером, работающим под постоянной высокой нагрузкой на пределе его возможностей, вряд ли стоит сразу кидаться отключать эти заплатки только из-за боязни «тормозов».

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

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

С плюсами закончили, переходим к минусам…

1. Сторонние репозитории

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

2. Исчезли нотификации приложений

Когда в юнити мне приходило новое письмо на почту или сообщение в слак, в верхнем правом углу выскакивали постоянно висящие значки, при нажатии на которые открывалось соответствующее приложение. Аналог system tray в windows. При переходе на гном, все подобные уведомления исчезли. То есть в гноме есть некий механизм уведомлений, когда при приходе нового письма на 10 секунд почти в центре экрана выскакивает окошко с сообщением. Но что, если в данный момент я был не у компьютера? Или даже просто в течение этих 10 секунд смотрел в другую сторону? Да и приходили они тоже не понятно как. Такое ощущение, что уведомляло только о первом письме, а все последующие игнорировались.

После некоторых плясок с бубном мне удалось добиться того, что Thunderbird таки стал выводить на своей иконке в панели задач красный кружок с количеством новых писем. Хоть это и не system tray, но вполне равноценная замена. Причём у меня есть основания предполагать, что этот красный кружочек как бы должен был заработать сразу после установки, так как ничего особенного в своих плясках с бубном я не делал и в конце концов вернулся к тому, с чего начал. Да и почтовый клиент таки не какой-нибудь сторонний, а дефолтный, должен быть вылизан вдоль и поперёк. Но у меня почему-то сразу не заработал.

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

В общем, за нотификации ОГРОМНЫЙ минус

3. Очередные «мудрения» в gnome-terminal

gnome-terminal был терминалом по умолчанию и в юнити, так что это не проблема перехода от юнити к гному. Это проблема перехода от убунты 16 к 18.

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

gnome-terminal --maximize \     --tab --working-directory=$HOME/workspace/project1 -e "script" \     --tab -e "top" \     --tab -e "ssh -t user@host.ru" \     ...  gnome-terminal --maximize \     --tab ... 

то теперь такая конструкция работает вкривь и вкось, так как вкладки обоих терминалов будут открываться во вкладках вызывающего окна, то есть будут свалены все в одну кучу. Плюс терминал засыпет вас сообщениями, что параметр -e устарел и скоро будет убран. Что вместо -e «command» следует использовать конструкцию — command. То есть одним вызовом открыть две вкладки с подключением по ssh к двум разным хостам станет проблемой. И вообще станет проблемой создать из коммандной строки новое окно с набором своих собственных вкладок (на самом деле, думаю, можно создать новое окно и уже в команде к нему прописать серию вызовов к терминалам с отдельными табами, но на мой взгляд это …)

Для большинства пользователей данная проблема, конечно, мелочь, но для тех, кто gnome-terminal использует напрямую, уже неприятно…

4. Панель задач при двух мониторах

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

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

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

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

Резюме

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

Данная статья посвящена изучению файловой структуры жёсткого диска восьмиканального видеорегистратора с целью массового извлечения файлов с видеозаписями. В конце статьи приводится реализация соответствующей программы на языке С.

Видеорегистратор (сокращённо DVR) QCM-08DL применяется в системах видеонаблюдения и позволяет производить восьмиканальную запись видео и аудио. Данная модель, на мой взгляд, одна из самых дешёвых и в тоже время надёжных в эксплуатации. Форматом сжатия видео является популярный формат H264. Для аудио применяется формат сжатия ADPCM. Видео и аудио записываются на стандартный компьютерный SATA жёсткий диск (HDD), установленный внутри DVR. С помощью самого DVR имеется возможность просматривать записи, производя их поиск по дате и времени. Также, имеется возможность извлекать данные в файл на внешний носитель. Во-первых – на USB накопитель, который подключается к USB интерфейсу DVR. Во-вторых – на компьютер через WEB-интерфейс DVR. Имя получающегося файла длинное, и в него входит дата записи, время начала и конца, канал записи и прочая дополнительная информация. Расширение файла – «.264». Исследование содержимого такого файла дало мне понять, что медиа контейнер, в который запакованы аудио и видео потоки, далеко не стандартный. Такой файл можно открыть с помощью плеера, который прилагается вместе с видеорегистратором. Плеер очень неудобный. Но также, можно воспользоваться программой-перепаковщиком в контейнер AVI, которая также прилагается. Данная программа перепаковывает видеопоток, оставляя его в формате H264. А звуковой поток преобразует из ADMCM в PCM, увеличивая его в 4 раза по размеру. В итоге получается .avi файл, воспроизводимый любым стандартным плеером. Отмечу сразу, что данная программа-перепаковщик весьма неудобная. Она позволяет совершать операции только над одним файлом. Для перепаковки множества файлом приходиться открывать их по очереди.

Были поставлены следующие задачи.

1. Получить с жёсткого диска видеорегистратора доступ ко всем файлам .264, подключив жёсткий диск к компьютеру.
2. Изучить алгоритм, по которому работает штатная программа-перепаковщик 264-avi и создать такую же программу, которая выполняла бы те же операции, но уже не над одним, а над целой группой файлов, причём одним нажатием.

Первая задача, на первый взгляд, может показаться очень простой: нужно просто подключить HDD к компьютеру и открыть разделы в проводнике. Однако здесь имеются свои подводные камни. Данная статья посвящена именно первой задаче.

Я уже заранее знал, что программная оболочка микроконтроллера видеорегистратора основана на операционной системе, подобной Linux. Поэтому, разметка жёсткого диска, вероятнее всего, также будет Linux-подобной. Следовательно, потребуется компьютер с ОС Linux. В моём случае ёмкость HDD – 1TB, компьютер с ОС Xubuntu. Подключив HDD к компьютеру, мне удалось увидеть всего один раздел на несколько гигабайт. Это явно не то, что нужно. Внутри раздела находится множество папок формата имени «YYYY-MM-DD», соответствующие датам записей. Внутри каждой папки – множество файлов, соответствующие записям. Файлы одноимённые с теми, которые получаются при извлечении с DVR. Однако, их размер в разы меньше и расширение не .264, а .nvr. Стоит предположить, что эти самые файлы nvr являются ключами для соответствующих файлов 264 (или их медиа потоков), содержимое которых находится на основном пространстве HDD. Данные папки с файлами я скопировал на отдельный носитель для дальнейшего исследования.

Для исследования использовал множество программных инструментов: дисковый редактор (он же и файловый бинарный редактор) DiskExplorer (WinHex я использовал позже), MS Excel для вспомогательных расчётов и фиксации результатов, среда программирования Dev-C++ для написания вспомогательных и окончательных консольных программ и прочее. В этой статье я попробую рассказать о данной процедуре.

Сначала посмотрим на самый первый сектор HDD (один сектор (1 LBA) занимает 512 Байт). Данный сектор, как правило, содержит MBR структуру. В неё входит загрузчик и базовое оглавление разделов. Структура этого сектора, а также, структура описания раздела, приведены ниже (взято из Википедии).

В случае с исследуемым HDD имеем следующее. Глядя на рисунок ниже и руководствуясь таблицами выше, мы видим, что загрузчик отсутствует. Но нас интересует больше таблица разделов. Она выделена в красную рамку. Последние два байта (синяя заливка) – сигнатура MBR. Из таблицы разделов видно, диск поделён на два раздела. Код типа первого раздела (жёлтая заливка) – 0x08. Это раздел FAT32-Ex (могу ошибаться). Код типа второго (оранжевая заливка) – 0x83. Это один из разделов Linux (в смысле, EXT). Байты кода типа раздела обведены в синюю рамку.

Полная расшифровка сектора MBR с таблицей разделов и их параметрами приведена ниже.

Обращая внимание на размеры разделов (пересчитывая число секторов в гигабайты), несложно догадаться, что на компьютере с ОС Xubuntu отображался именно первый раздел, занимающий незначительную часть дискового пространства. Кстати говоря, в Windows XP также отобразился только первый раздел, но из проводника не открылся. Стало быть, раздел с кодом 0x08 Windows XP воспринимает некорректно. А почему же тогда второй раздел Linux не отобразился в ОС Xubuntu?

Изучив предварительно структуру и организацию линуксовой файловой системы на примере EXT2, я приступил к исследованию второго раздела.

Как видно из таблицы разделов, второй раздел начинается с сектора 16016805. Руководство по файловой системе EXT2 свидетельствует о наличии так называемого суперблока, который располагается в 1024 байтах от начала раздела (то есть в двух секторах от начала). Однако сектор 16016805+2=16016807 оказался пустым. Зато первый сектор 16016805 по своей структуре напоминал суперблок. Но его содержимое полностью не соответствовало описанию содержимого суперблока из руководства. Суперблок – это основной блок, в котором содержится своеобразная таблица различных констант и параметров для функционирования файловой системы: адреса положений и размеры других необходимых блоков, в частности, заголовков файловых записей и директорий. Дальнейшие исследования этого раздела привели меня только к одному выводу: DVR использует свою уникальную файловую систему.

В дальнейшем решил взглянуть на первый сектор первого раздела (сектор 63) и пролистать вниз. Было обнаружено на секторе 65 (двумя секторами ниже) содержимое, полностью похожее на содержимое суперблока ФС EXT2, которое описано в руководстве. Дальнейшие исследования привели к выводу, что первым разделом HDD DVR является раздел EXT2, который и отображался в ОС Xubuntu, невзирая на метку 0x08 (не EXT) в оглавлении раздела! Таким образом, первый раздел жёсткого диска видеорегистратора – раздел EXT2, на котором записаны файлы nvr, являющиеся ключами к требуемым видеозаписям.

Напишу кратко о структуре файлов .264, которые я также предварительно исследовал. Данная информация в дальнейшем будет необходима для исследования второго раздела HDD. Как и в любом медиа контейнере, в «264» присутствует заголовок со служебной информацией и медиа тегами, а также потоки аудио и видео, которые следуют небольшими блоками один за другим. По смещению 0x84 байта от начала файла прописано ключевое слово «MDVR96NT_2_R». Перед этим словом расположены байты, относящиеся к дате и времени записи. Но эта информация содержится в имени файла, поэтому, особого внимания она здесь не заслуживает. После идёт множество байтов нулей. Основная информация с аудио и видео потоками берёт начало по смещению 65536 байт. Блоки видеопотока начинаются с 8-байтового заголовка «01dcH264» (встречается также «00dcH264»). Следующие за ним 4 байта описывают размер текущего блока видеопотока в байтах. Через 4 байта нулей (00 00 00 00) начинается сам блок видеопотока. Блоки аудиопотоков имеют заголовок «03wb» (хотя, по моим наблюдениям, первый символ заголовка в некоторых случаях был необязательно «0»). После – 12 байт информации, которую я пока не разгадал. А начиная с 17-ого байта – аудиопоток фиксированной длины 160 байт. Какие-либо метки в конце файла отсутствуют.

Приступим к исследованию структуры файлов и каталогов, расположенных на первом разделе HDD. Как уже говорилось выше, содержимое раздела было скопировано на отдельный носитель через обычный проводник в ОС Xununtu. В каждом каталоге (директории), помимо файлов nvr содержится один бинарный файл с именем «file_list». Судя по имени, в нём содержится информация о списке файлов в текущем каталоге. Откроем этот файл в бинарном редакторе (см. рис. ниже). Я исследовал структуру данного файла, и здесь нет в принципе ничего интересного. Файл не имеет никакой информации, касающейся расположения искомых медиа потоков. Тем не менее, кратко напишу о данной структуре. Первые 32 байта – заголовок с какими-то константами. Следующие 16 байт имеют отношение к дате и времени и количеству файлов в текущем каталоге. Далее следуют 48 байт констант. Далее – 8 байт констант, свидетельствующих о начале файловой записи. Далее – 96 байт, указывающие полный путь к файлу nvr, включая его имя. Далее – 24 байта, относящиеся к времени (число секунд, прошедших от начала суток, начала и конца видеозаписи) и прочим атрибутам видеозаписи. И так далее, по аналогии, для всех файлов nvr в текущем каталоге. Их число равняется числу видеозаписей за текущие сутки, на которые указывает имя текущего каталога. Для чего нужен этот файл? Видимо, для ускорения поиска видеозаписи внутри интерфейса DVR.

Перейдём к изучению структуры самих файлов nvr. Вид одного такого файла в бинарном (точнее, в 16-ричном) редакторе приведён на рисунке ниже. Не вдаваясь в подробности описания структуры содержимого (часть которой так и осталась для меня загадкой), я выделил самые основные параметры, которые и являются искомым ключом. Это 32-битные (4-байтные) значения, располагающиеся через каждые 32 байта, начиная с байта по смещению 40. На рисунке они выделены красным прямоугольником. В дальнейшем я убедился, что этого вполне достаточно для ключа к видеозаписям. Напоминаю, что 4 байта значения этого ключевого параметра располагаются от младшего к старшему, но не наоборот! Такая нотация обусловлена архитектурой процессора ПК. В приведённом на рисунке примере изображён первый nvr файл первого каталога. Он соответствует первой видеозаписи, сделанной видеорегистратором. Очевидно, что значения параметров, которые я назвал ключевыми, в приведённом примере образуют последовательность целых чисел, начиная с нуля и идущие по порядку по возрастанию. Исследуя другие nvr файлы, и просматривая в них именно эти указанные байты, были также замечены целые числа, идущие по возрастанию. Но данная последовательность начиналась естественно уже не с нуля, и в некоторых случаях местами наблюдались пропуски по одному или два числа. Например (числа от балды): 435, 436, 438, 439, 442,…(или в 16-ричном виде: B3010000, B4010000, B6010000, B7010000, BA010000,…).

Такая последовательность с пропусками приходилась на nvr файлы, соответствующие видеозаписям, которые DVR записывал одновременно с двух и более каналов. То есть, например, если последовательность «435, 436, 438, 439, 442,…» относится к видеозаписи с одного канала, то пропущенные значения (437, 440, 441) будут относиться к видеозаписи с другого канала, которая осуществлялась в тот же момент времени. В этом я сам убедился, просмотрев и сравнив соответствующие nvr файлы, опираясь на их имя. Не остаётся и сомнений, что приведённые выше числа образуют номера каких-то частей, имеющих отношение к видеозаписям. Остаётся только разгадать связь между этими числами и координатами дискового пространства, на котором размещены данные.

Также, предстояло выяснить, какие именно данные делятся на вышесказанные нумерованные сегменты? Первое предположение – данными являются потоки аудио и видео, которые в контейнере 264 представлены короткими блоками, причём, как было сказано, блоки видеопотока имеют разный размер. При этом DVR на этапе извлечения видеозаписи на внешний носитель собирает эти потоки и упаковывает в контейнер 264. Второе предположение – потоки аудио и видео DVR упаковывает в контейнер 264 в начале и во время видеозахвата. И при этом на HDD записываются уже сформированные данные файла .264, который бы получился в результате его извлечения на внешний носитель. Исследуя пространство HDD где-то в середине второго раздела, наряду с байтами потоков аудио и видео и их заголовками того же вида, что и в контейнере 264, мне также попадались и заголовки самого контейнера: MDVR96NT_2_R. После данного заголовка также присутствовало множество байтов нулей. В целом, исследование показало, что имеет место второй вариант из двух вышеприведённых. Поэтому, для получения нужного файла .264, вероятнее всего, нужно просто соединить вместе все сегменты, номера которых содержатся в соответствующем файле nvr.

Приступим к поиску зависимости между номером сегмента и координатами на HDD.

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

Возьмём два nvr файла, соответствующие видеозаписям с разных каналов, которые DVR захватывал одновременно. Для этого взглянем на имена файлов. Например, видеозаписи, на которые указывают файлы «ch00000000000001-150330-160937-161035-02p101000000.nvr» и «ch00000000000004-150330-160000-163000-00p004000000.nvr» велись одновременно. Первая запись – запись с 1-ого канала с 16:09:37 по 16:10:35 времени. Вторая запись – запись с 4-ого канала с 16:00:00 по 16:30:00 времени. Обе записи сделаны 30.03.2015 г. На временной шкале, очевидно, временной интервал первой записи является подмножеством временного интервала второй записи. Принимаю во внимание также тот факт, что в меньшем интервале времени (в пересечении двух интервалов) DVR не осуществлял видеозахват ни с одного из остальных 6-ти каналов. Просмотрим содержимое этих nvr файлов. Убедимся, что отсутствующие те самые числа (номера сегментов) во втором длинном файле обязательно присутствуют в первом коротком файле, целиком и полностью. С помощью DVR обычным способом требуется заранее извлечь хотя бы один из файлов .264, на которые ссылаются исследуемые файлы nvr. Допустим, извлекли «ch00000000000001-150330-160937-161035-02p101000000.264». Откроем его в бинарном редакторе. Как уже было сказано, в начале данного файла до ключевого слова «MDVR96NT_2_R» присутствуют уникальные байты, соответствующие дате и времени видеозаписи, содержащейся в данном файле. Списываем все эти байты, начиная от ненулевого и кончая заголовком (чем короче цепочка байт, уникальная для данной видеозаписи, тем лучше). Также, записываем смещение этой цепочки байт от начала файла. Следует обратить особое внимание, что в начале извлечённого файла .264 присутствуют лишние 4 байта нулей. Это стало заметно, сравнивая первые 512 байт файла .264 и сектор дискового пространства, с которого начинаются данные содержимого одного из файлов .264 (файл практически любой ФС всегда начинается в начале сектора, мало того, – кластера). То есть, информация в файле .264 сдвинута заранее на 4 байта вправо. Размер (в байтах) любого файла .264 кратен 512 только после предварительного вычитания числа 4 из размера. Приступим к поиску сектора, с которого начинается исследуемый файл .264. В дисковом редакторе запускаем функцию поиска. В поле искомого значения вписываем уникальную цепочку байт, списанную заранее. Для ускорения поиска вписываем в поле «искать по смещению» значение смещения, предварительно вычитая 4. Запускаем поиск. Через несколько часов поиск завершился удачно. Записываем номер сектора, в котором найден уникальный заголовок. Пусть это будет значение s. Смотрим содержимое файла nvr для этой видеозаписи. Списываем номер первого сегмента (4 байта по смещению 40). Пусть это будет значение b. Итого, пока у нас известны номер сектора диска (16046629) для нулевого номера сегмента (в самой первой видеозаписи) и номер найденного сектора диска s для только что списанного номера сегмента b. Можно вычислить предполагаемый размер сегмента: (s-16046629)/(b-0). Вычислив, получил значение 128. Таким образом, размер сегмента равен 128 дисковым секторам (LBA), или 128*512=65536 байт!

Я провёл ещё один дополнительный интересный эксперимент, чтобы окончательно развеять все сомнения. Он описан ниже.

От начала сектора s выделим область на диске, размером, сравнимым с размером файла .264, который начинается с данного сектора. Если мои догадки верные, то в выделенную область попадут сегменты другого файла .264, который захватывался на HDD одновременно с первым. Сохраним эту область в файл (создадим образ). Порежем получившийся образ на файлы по 65536 байт (размер сегмента). Это можно сделать с помощью функции «Разбить файл» в Total Commander. Пусть это будут куски M1, M2, M3,…. Точно также порежем исследуемый файл .264 (который был по-юзерски извлечён с DVR), но убрав предварительно 4 байта нулей вначале. Пусть это будут куски K1, K2, K3,…. С помощью функции «Сравнить по содержимому» в Total Commander сравним по очереди куски образа и куски от файла .264. (M1 с K1, M2 с K2 и т.д.), руководствуясь номерами сегментов из соответствующего файла nvr. При этом получается следующее. Допустим (числа от балды), цепочка чисел в nvr следующая: 435, 436, 438, 439, 442,… При таком раскладе M1=K1, M2=K2, M4=K3, M5=K4, M8=K5,…. То есть, кусочки, на которые разбивался файл-образ и файл .264 оказываются равными между собой, учитывая соответствующее опережение по номерам кусков файла-образа, согласно пропускам чисел в последовательности. Вот так вот!

Итого, мы получили предполагаемую зависимость: S=16046629+128*d, где d – номер сегмента в файле nvr, а S – номер сектора на HDD, начиная от самого начала диска, с которого начинаются данные содержимого сегмента. Размер сегмента – 128 секторов. Приведённая выше формула не берёт во внимание существование второго раздела. Зависимость найдена только для конкретного примера с HDD на 1TB. Возможно, если поставить в DVR HDD другой ёмкости, константы примут иной вид.

Чтобы убедиться в справедливости формулы, вычислим позицию первого сегмента какого-либо другого произвольного файла .264, руководствуясь соответствующим файлом nvr. Обращая внимание на дату и время в имени файла, сравним их с первыми байтами в заголовке .264, находящемся на вычисленном секторе. Байты, кодирующие по отдельности число, месяц, год, часы, минуты, секунды, соответствуют временным данным в названии файла. Следовательно, «попали в точку»! Подсчитаем в файле nvr, соответствующем извлечённому заранее файлу .264, количество сегментов cs. Вообще, их число равно cs = sf/32-1, где sf – размер файла nvr. Если файл .264 состоит из cs сегментов, то его размер должен быть равен cs*65536+4 (число сегментов, умноженное на размер сегмента в байтах, плюс 4 тех самых байта нулей). И это действительно так!

Всё-таки, попытаемся исследовать второй раздел. Как уже отмечалось ранее, нечто похожее на суперблок находится прямо в первом секторе раздела (16016805). А его точная копия была обнаружена семью секторами ниже (16016812). Очевидно, ненулевая основная информация находится в первом секторе суперблока. Его вид в дисковом редакторе приведён на рисунке ниже.

Часть 4-байтных параметров я сумел расшифровать. Голубым цветом выделены дата и время монтирования раздела. Дата и время представлены в специальной нотации «Unix time» (число секунд, прошедших с полуночи 1 января 1970 года). В приведённом примере «03 7E 74 54» (десятичное значение 1416920579) соответствует «Tue, 25 Nov 2014 13:02:59 GMT». Для перевода значений я пользовался специальным онлайн калькулятором. В фиолетовой рамке обведено значение 65536. Возможно, именно на эту позицию суперблока ссылается интерпретатор файловой системы внутри программы DVR, когда считывается размер блока (в предыдущем контексте я называл блоки сегментами). В зелёную рамку выделены значения 1. Одно из них наверняка обозначает положение начала т.н. битовой карты (в количествах блоков от начала раздела). Действительно, заранее было обнаружено начало информации нечто похожей на битовую карту на секторе 16016933 (16016805+128*1). В красную рамку выделено значение 233. Это как раз и есть позиция начала данных видеозаписей .264 от начала раздела: 16016805+128*233=16046629.

То есть, второй раздел можно назвать урезанным и немного видоизменённым разделом EXT2. В нём есть суперблок, его копия, битовая карта. Но отсутствуют т. н. информационные узлы, соответствующие файловым записям. Раздел содержит данные файлов .264 (аудио и видео потоки), но информационные узлы (скажем так) для этих данных размещены в nvr файлах на первом разделе. Может быть, существует более грамотная формулировка? Но мне это уже не столь важно.

Напишем простую программу для массового извлечения файлов .264. Сразу говорю, что большого опыта в программировании по Windows у меня нет. Программа сканирует все файлы nvr, скопированные заранее на раздел 1TB нового HDD. Анализируя их, программа создаёт файл .264 с тем же именем в том же каталоге, используя обращение к секторам оригинального HDD. Предварительно в пустом разделе нового HDD создана папка с именем «DVR», в которую помещены папки по датам, что скопированы «обычным способом» в Линуксе. Можно было в данную программу включить алгоритм работы с первым линуксовым разделом для доступа к файлам nvr, чтобы не прибегать к их предварительному копированию. А ещё можно было добавить другие удобные фишки. Да, можно было, но мне на тот момент хотелось сделать всё как можно быстрее.

Для сканирования директорий я не использовал рекурсию, принимая во внимание, что формат директорий фиксирован и имеет два уровня вложения. Соответственно, я применил два цикла: пробег по папкам, пока они не закончатся, и пробег по файлам в каждой папке с тем же условием. Для чтения файлов я применил сишную функцию fopen. Для работы с секторами HDD я использовал функционал WinAPI по аналогии работы с файлами. Перейдём к коду программы.

Библиотеки нужны такие.

#include <windows.h> #include <stdio.h> #include <string.h> 

А эти функции я полностью скопировал с какого-то форума.

HANDLE openDevice(int device) {   HANDLE handle = INVALID_HANDLE_VALUE;   if (device <0 || device >99)      return INVALID_HANDLE_VALUE;      char _devicename[20];   sprintf(_devicename, "\\\\.\\PhysicalDrive%d", device);    // Creating a handle to disk drive using CreateFile () function ..   handle = CreateFile(_devicename,      GENERIC_READ, FILE_SHARE_READ | FILE_SHARE_WRITE,      NULL, OPEN_EXISTING, 0, NULL);     return handle; }  HANDLE openOutputFile(const char * filename) {        return CreateFile ( filename,      // Open Two.txt.             GENERIC_WRITE,          // Open for writing             0,                      // Do not share             NULL,                   // No security             OPEN_ALWAYS,            // Open or create             FILE_ATTRIBUTE_NORMAL,  // Normal file             NULL);                  // No template file        } 

В функцию копирования заключена формула линейной зависимости, которая фигурировала в теории выше.

void copy(HANDLE device, HANDLE file, unsigned long int s){ 	LONG HPos; 	LONG LPos; 	__int64 sector; 	sector = 16046629+128*s; 	HPos = (sector*512)>>32; 	LPos = (sector*512); 	SetFilePointer (device, LPos, &HPos, FILE_BEGIN); 	DWORD dwBytesRead; 	DWORD dwBytesWritten; 	unsigned char buf[65536]; 	ReadFile(device, buf, 65536, &dwBytesRead, NULL); 	WriteFile(file, buf, dwBytesRead, &dwBytesWritten, NULL); } 

Основная функция также довольно простая.

int main(){ 	HANDLE hdd = openDevice(1); //Здесь надо указать номер HDD от DVR, который прописался в системе; 	SetFilePointer (hdd, 0, NULL, FILE_BEGIN); 	DWORD dwBytesRead; 	char name[100]; 	unsigned int bl; //Пробег по блокам; 	unsigned int N; //Число блоков; 	unsigned long int pt; //Указатель на блок; 	WIN32_FIND_DATA fld,fld1; //Структура с файлом nvr или с папкой; 	HANDLE hf,hf1; 	hf=FindFirstFile("E:\\DVR\\*",&fld); 	FindNextFile(hf,&fld);//Пропускаем "."; 	FindNextFile(hf,&fld);//Пропускаем ".."; 	do{ 		char *str = new char; 		sprintf(str,"%s%s%s","E:\\DVR\\",fld.cFileName,"\\*.nvr"); 		printf("\n\nFOLDER: %s\n\n",str); 		hf1=FindFirstFile(str,&fld1); 		do{ 			FILE *nvr; 			sprintf(name,"%s%s%s%s","E:\\DVR\\",fld.cFileName,"\\",fld1.cFileName); 			nvr=fopen(name,"rb"); 			name[strlen(name)-3]='2'; //Путь и имя сохраняем, но 			name[strlen(name)-2]='6'; //корректируем разширение; 			name[strlen(name)-1]='4'; 			HANDLE out = openOutputFile(name); 			SetFilePointer(out, 4, NULL, FILE_BEGIN); //Как в "оригинале", оставляем 4 нулевых байта в выходном файле (для полного соответствия); 			bl=0; 			N=fld1.nFileSizeLow/32-1; //Расчёт количества блоков (кусков); 			printf("\t%s\n\t%i Blocks\n\n",fld1.cFileName,N); 			for(bl=0;bl<N;bl++){ //Пробег по блокам; 				fseek(nvr,40+32*bl,SEEK_SET); //Позиционируемся; 				fread(&pt,1,4,nvr); //Считываем номер; 				copy(hdd,out,pt); //Копируем по номеру; 			} 			CloseHandle(out);		 			fclose(nvr); 		}while(FindNextFile(hf1,&fld1)); 		FindClose(hf1); 		delete str; 	}while(FindNextFile(hf,&fld)); 	FindClose(hf); 	CloseHandle(hdd); 	system("PAUSE"); 	return 0; } 

На старом компьютере с процессором Pentium 4 и PCI контроллером SATA программа успешно переложила до конца заполненный HDD несколькими тысячами файлов .264 в среднем за 7 часов. На новом компьютере – раза в три быстрее. Как я уже отметил, программа не универсальная, все константы и переменные подстроены под мой конкретный случай с HDD на 1TB. Однако, можно ещё немного поработать и сделать её универсальной, нарисовать к ней графический интерфейс.

Во второй части статьи я напишу, как «своими руками» осуществить перепаковку из контейнера «264» в стандартный контейнер «avi».

Что математика может рассказать нам о поиске порядка в хаосе жизни

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

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

Небольшая прелюдия. Рассмотрим следующие три строки символов.

1. 100100100100100100100100100100100100100100100100100100100100100100100

2. 2, 3, 5, 7, 11, 13, 17, 19, 23, 29, 31, 37, 41, 43, 47, 53, 59, 61, 67, 71, 73, 79, 83, 89, 97

3. 38386274868783254735796801834682918987459817087106701409581980418.

Как мы можем их описать? Например, мы легко можем это сделать, просто записав их – так, как мы только что и проделали. Однако сразу ясно, что первые две строчки можно описать и короче. Первая – это просто последовательность повторяющихся «100». Вторая – список первых нескольких простых чисел. А что насчёт третьей? Её можно описать, просто выведя всю строку. Но есть ли для неё лучшее, более короткое описание?

В начале 1960-х американский подросток Грегори Хайтин, всемирно известный русский [и советский] математик Андрей Николаевич Колмогоров, и пионер информатики Рэй Соломонов независимо друг от друга сформулировали способ измерения сложности последовательностей символов. Их идеи стали называть теорией сложности Колмогорова или алгоритмической теорией информации. Они постулируют, что сложность строки определяется длиной наикратчайшей компьютерной программы, способной её выдать. То есть, возьмём строчку, и поищем самую короткую компьютерную программу, которая её выдаёт. Программа – один из видов описания строки. Если кратчайшая из таких программ окажется очень короткой, тогда в строке есть простая закономерность, и она не очень сложная. Мы говорим, что в такой строке мало алгоритмическое содержание. И наоборот, если для выдачи строки требуется длинная программа, тогда строка сложная, и её алгоритмическое содержание больше. Для любой строки необходимо искать кратчайшую программу, выдающую такую строку. Длина такой программы называется Колмогоровской сложностью строки.

Давайте вернёмся к трём первым строчкам. Первые две строки можно описать при помощи относительно коротких компьютерных программ:

1. Вывести “100” 30 раз.

2. Вывести первые 25 простых чисел.

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

3. Вывести “38386274868783254735796801834682918987459817087106701409581980418”

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

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

Увы, такой компьютер создать невозможно! Пусть современные компьютеры и весьма мощны, эта задача невыполнима. Таково содержание одной из глубочайших теорем математической логики. Теорема, по сути, говорит, что Колмогоровскую сложность строки невозможно вычислить. Не существует механического устройства, определяющего размер наименьшей программы, выдающей заданную строку. Дело не в том, что наш текущий уровень компьютерных технологий не дотягивает до задачи, или что мы недостаточно умны для того, чтобы написать такой алгоритм. Было доказано, что сама идея описание и вычисления демонстрирует, что компьютер в принципе не в состоянии выполнить такую задачу для любой строки. И если компьютер, возможно, способен на поиски определённых закономерностей в строке, он не способен найти наилучшую закономерность. Мы, возможно, и найдём короткую программу, выводящую определённую последовательность, но всегда может существовать ещё более короткая. Мы никогда об этом не узнаем.

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

Парадокс интересных чисел связан с утверждением, что все натуральные числа интересные. 1 – это первое число, и это интересно. 2 – первое чётное число. 3 – первое нечётное простое число. 4 – интересное число, потому что 4 = 2 × 2 и 4 = 2+2. В таком роде можно продолжать дальше, и находить интересные свойства многих чисел. В какой-то момент мы можем встретить число без интересных свойств. И мы можем назвать это число первым неинтересным номером – но это само по себе уже интересное свойство. В итоге неинтересные числа тоже оказываются интересными!

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

Самое маленькое число, которое нельзя описать меньше, чем пятнадцатью словами [The smallest number that cannot be described in less than 15 words]

Для описания числа требуется 15, 16 или даже больше слов. Его нельзя описать 12, 13 или 14 словами. Однако, вот в чём проблема: приведённая выше фраза описывает это число при помощи 10 слов [по-английски – 12 слов / прим. перев.]. Наше описание числа противоречит описанию числа – вот вам и парадокс.

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

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

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

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

Реальный мир добавляет сложности. Если в мире строк и компьютерных программ ошибок нет, в реальном мире можно совершить ошибку. Мы легко узнаем, выводит ли какая-то определённая программа строку, или нет. И хотя мы, вероятно, не сможем определить оптимальную программу для вывода определённой строки, мы сможем определить, выводит ли она требуемую строку. А реальный мир, в отличие от этого, гораздо более сложный. Нам может показаться, что мы видим последовательность, когда её, на самом деле, нет.

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

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

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

Нозон Яновски – доктор наук в математике, работает в Образовательном центре городского университета Нью-Йорка, профессор информатики в Бруклинском колледже того же университета.

Сегодня на IFA 2018 в Берлине Huawei показывает новый мобильный чип Kirin, который станет компактнее и быстрее. Правда устройств на его базе прямо сейчас, скорее всего, ждать не стоит. В прошлом году так и произошло: сначала показали процессор, а через пару месяцев — новый смартфон.

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

.