Ядро и телефон

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

Или если по порядку: 

Скачать компилятор можно с AOSP, где лежит стандартный компилятор уже "оптимизированный" под сборку Android, что дает нам большой процент вероятности, что у нас все же что-то соберется. Хотя тут тоже могут быть скрытые проблемы модифицированный компилятор использованный при сборке, но такой случай маловероятен иначе на устройстве не будут работать приложения собранный стандартным компилятором из NDK.

Получение конфигурации ядра тоже достаточно простая операция можно получить установив эмулятор терминала на устройство или запустив adb и сделав копию /proc/config.gz.  С конфигурацией тоже могут быть проблемы: отсутствие этой конфигурации по указанному пути, так как производитель решил сэкономить таким образом место, заблокированный доступ к системным каталогам, заблокированный запуск стандартный утилит, заблокированный доступ к системным областям, не стандартные устройства или их не канонические названия, производитель модифицировал стандартное устройство по своему усмотрению - в общем проблемы могут быть даже здесь. Но в основном все же доступ к конфигурации есть, заблокирован только доступ к dmesg, записи или чтению системных устройств - чтобы нельзя было получить прошивку или заменить ее. 

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

Для разработчиков конечного устройства вопрос универсальности или использования одобренных или обсуждённых с сообществом решений вообще теряет смысл, у них несколько иная цель - выпуск продукта в ограниченные сроки, c ограниченной поддержкой вида "работает - не трогай", что приводит к неочень хорошим результатам на всех уровнях. Как пример, это может быть такая ситуация: в прошивке используется как MARCH значение платформы описание, которой отстутстует в исходниках ядер для других устройств стандартного ядра которое дается производителем SOC, врезультате у нас есть описание чипа из спецификации устройства, но описания как иммено оно сконфигурировано нет. И нужно дожидатся открытия исходникой ядра иммено под это конечное устройство, что может произходить достаточно не быстро или вообще не произойти никогда. Следущая проблема качество этих исходных кодов, так как эти исходники собирались только для одного устойства с четко определенным списком функций, никто не обновляет эти ядра из общего хранилища кодов и не возвращает наработки обратно. Как следствие в коде отстутвуют проверки присутствия каких-то опций или наоброт отсутствия их, зависимости между элементами не проверяются и код можно собирать только в том виде как он есть, без изменений и только одим жестко определенным способом. 

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

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

Для сборки можно использовать такую последовательность команд: 

1. make CROSS_COMPILE=../arm-eabi-4.6/bin/arm-eabi- SUBARCH=arm ARCH=arm menuconfig 
2. make CROSS_COMPILE=../arm-eabi-4.6/bin/arm-eabi- SUBARCH=arm ARCH=arm -j 4 
3. fastboot boot bzImage

Оптимизация через уменьшение

Лучший код тот, который не написан. 

Очистка html от пробельных символов:

Достоинства: 

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

Недостатки: 

• затраты ресурсов на очистку; 
• дополнительное место для отказа. 

Очистка и объединение файлов css: 

Достоинства: 

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

Недостатки: 

• возможно усложнение отладки из-за изменений в исходном коде; 
• дополнительные затраты ресурсов. 

Очистка и объединение файлов js: 

Достоинства: 

• минимизация кода и удаление пробельных символов как следствие сокращения объёма трафика; 
• возможность удалить или оптимизировать код; 
• ускорение работы кода как результат удаления "мертвого кода" и ускорения разбора. 

Недостатки: 

• возможно усложнение отладки из-за изменений в структуре исходного кода; 
• дополнительные затраты ресурсов.

Свободная модель мира

Продукт позволяющий создавать 3d карту мира (аналогичный Google Street View или другим подобным продуктам других компаний), но построенный на принципах OpenStreetMap, когда изменять карту может каждый желающий и может при желании создать свой сервис основываясь на исходных кодах этого продукта, может иметь успех из-за таких достоинств:

• упрощение навигации в местах которые мало интересны крупным компаниям и интересны волонтерам;
• навигация с изображением, что предполагается увидеть проще, чем плоская карта с ориентацией по компасу и особенностям расположения дороги;
• расширения возможностей продуктов 'дополненной реальности' картинку с таких устройств можно анализировать на подобность уже существующим в базе изображений с уточнение координат в условиях недостаточной точности GPS c сохранением этих изображений на основном сервисе для уточнения информации и построение более точной модели. Или иными словами - снимается текущая картинка и вместе с текущими примерными координатами отправляется на сервис - там ищется подобная картинка и уточняется точное направление взгляда относительно карты - эти данные передаются обратно и показывается более точное направление движения, чем достигается более точная навигации по абстрактной пересеченной местности - где две дорожки ведущих примерно в том же направлении или находящиеся близко могут вести в различные места с различными условиями передвижения, что важно при езде на велосипеде или пеших походов - где размер дорожки может быть гораздо меньше чем при езде на автомобиле по городу / трассе, когда расстояние между дорожками минимум сравнимо с десятками метров и ошибка в несколько десятков метров не страшна;
• как исходные данные можно использовать уже снятые фотографии с гео-тегами, или что даст более точную информацию видео с видео регистраторов или action камер с дополнительными треками положений. Использование продуктов дополненной реальности носимых на голове и закрывающий часть обзора скорее всего будет не удобно так как будет только отвлекать при активных перемещениях.
• подобную систему можно также использовать для виртуальных экскурсий походов по удаленных или по каким-то причинам не доступным местам. Или создания реалистичных видео игр на основе реальных мест;
• возможность иметь собственный клон сервиса с собственными данными.

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

• удобный формат хранения данных с возможностью четкой привязки к местности и достаточной точностью создания объектов;
• возможность быстрого отсечения не видимых или не значимых на данной увеличении позиции объектов;
• большие объёмы хранимой информации;
• отображение на конечном устройстве: различные виды устройств и не полная поддержка WebGL на устройствах;
• большой объем информации при передаче на устройство;
• математическая сложность преобразования изображений в 3d модель;
• преобразование видео сводиться к предыдущему пункту, но имеет один побочный эффект при качественном преобразовании можно в результате получить новое видео с улучшенным качеством изображения и новый формат видео базирующийся на описании позиции наблюдателя и расположения 3d моделей, где отдаленный объекты если в видео встречается этот объект ближе с большим разрешением или качеством, по всему видео будет обладать этими же качествами, что может несколько улучшить качество визуального восприятия;
• сложность создания моделей объектов что изменяются или изменяют свою позиции между кадрами.

Уменьшение нагрузки на оптимизирующий прокси

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

Сервер может поступить после этого следующим образом: 

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

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

Gnome shell и клавиатура

В новом гноме отключили возможность менять язык по shift + ctrl, теперь нельзя выбрать такую комбинацию. Чтобы ее установить нужно выполнить:

gsettings set org.gnome.settings-daemon.peripherals.keyboard input-sources-switcher ctrl-shift-l 

Radeon DPM (Linux 3.11)

В последнем релизе ядра появилась переработанная система управления питанием видеокарт radeon.

Что бы протестировать ее нужно:

1. загрузить последнее ядро отсюда;
2. обновить файлы прошивок отсюда, в принципе не обязательно на следующих этапах можно обновить из отдельного репозитория, но я делал в таком порядке;
3. добавить магическую комбинацию в grub radeon.dpm=1
4. обновить месу если есть желание из отдельного репозитория

Что это дает:

• автоматическое управление питанием:
  echo {auto, high} > /sys/class/drm/card0/device/power_dpm_force_performance_level
  Старая комбинация может уже не работать так как поменялся метод power_method.
• можно посмотреть текущее состояние:
  cat /sys/kernel/debug/dri/64/radeon_pm_info
• получить двукратное увеличение количества кадров в играх;
• много положительных или не очень эмоций уж как повезет.

Почти идеальный виртуальный CDN

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

Виртуальный - потому что нет его как такового только незримое улучшение каких-то характеристик.

Вот несколько неплохих характеристик виртуального CDN:

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

И как результат не весь контент грузится с одного сайта, можно по заголовкам понять может мы это уже откуда-то грузили или можно параллельно погрузить.

Фасеточные фонари

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

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

1. на излучатель виде фасеточного глаза насекомых, содержащего несколько светодиодов с собственными линзами с отдельным управлением каждым светоизлучающим элементом, что позволит освещать только участки и чем на больше количество зон разбиты такие излучатели тем точнее можно регулировать освещённость. Обратную часть излучателя можно сделать не управляемым или просто обеспечивающим не сфокусированный ближний свет, так как они будут использоваться через отражатель плюс линзы на передней части. Но также нужно учитывать ограничение стандартное оптики фары когда невозможно регулировать полное направление света из-за использования дополнительных линзовых элементов на стекле фары заднего отражателя. Задний отражатель используемый в фарах можно не брать во внимание так как отбивает только обратный свет;
2. две инфракрасные камеры(по возможности);
3. одну обычную.

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

Использование не полного комплекта:

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

Основное достоинство такой системы отсутствие двигающихся частей и не нужны датчики положения.

Память

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

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

p2p over http

Идея проброса трафика через обычно открытый порт

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

Через прокси таким образом работать не получится так как буде работать только канал от сервера к клиенту, в обратную строну соединение не будет работать, можно создать прямое соединение через POST для отправки данных на сервер без указания размера данных используя передачу параметров запроса после заголовков не указывая multipart параметров и обратное через GET без указания размера. Такой способ соответствует спецификации в теории, но имеет несколько недостатков, так как мы имеем 2 соединения которые нужно объединить в одно виртуальное и обычно сервера не позволяют такое вольное отношение с протоколом вычитывая полностью данные с параметров запроса и буферизируя передаваемые данные и как результат такая система может работать не стабильно.

Как результат можно использовать POST запрос с указанием в ответе HTTP 1.0 без указания размера контента с обоих сторон без ожидание получения полного ответа с обоих сторон - в теории это должно повысить вероятность прохода трафика без задержек через прозрачные прокси и firewall - так как оно будет работать по протоколу который соответствует минимальном требованиям к обычно открытому порту для http.

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

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

Android + autoconfig?

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

Для Android - причина таких особенностей связана с тем что:

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

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

Возможно это все можно решить, если изначально собирать все по принципам LFS и в эмуляторе конечной платформы. Но результат такой системы будет полностью переписанная сборка частей общих и характерных для остальных дистрибутивов Linux и опять таки сложная система с жесткими связями для пользовательского интерфейса где используется Dalvik, плюс проблема с драйверами к аппаратуре - так как Android позволяет больший разброс в идеях как работать с аппаратурой чем обычный linux и содержит части из других операционных систем, например binder (часть как следствие вечно живой Beos).

Обновление радио

При обновлении прошивки для радиочипа на android телефоне может поменяется идентификатор usb, для обычных пользователей это не так важно, но для использования fastboot и adb нужно в udev поменять этот идентификатор и права на него.

Установка достаточно проста: 

1. скинуть в корень флешки, 
2. перегрузится через adb reboot bootloader, 
3. выбрать обновление.

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

Прощай google reader!

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

P.S.:  Конечно остаётся вероятность переноса всех этих подписок в другие продукты с схожим функционалом, но ридер все же был в одном клике с почты. Если бы в G+ появилась возможность привязываться к rss тоже было бы не плохо.

Лето пришло

Простые команды для охлаждения системы/понижения частот:

1. процессор: echo powersave > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
2. видеокарта: echo low > /sys/class/drm/card0/device/power_profile
3. посмотреть что еще можно отключить: powertop

Информационное перенасыщение

Высшее образование дает способность говорить глупости с умным лицом 

и слушать их же с понимающим видом.

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

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

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

i386 на amd64 в lxc

По-умолчанию при создании окружения в lxc поддержка i386 не включена, для разрешения установки пакетов другой архитектуры: dpkg --add-architecture i386

Radeon HDMI sound

По умолчанию звук через HDMI на radeon какрточках в ubuntu отключен. Чтобы включить нужно в /etc/default/grub  в строку GRUB_CMDLINE_LINUX_DEFAULT дописать radeon.audio=1. Иначе звук не будет выводиться - сделано так из-за ошибки на некоторых устройствах с расчетом правильной хеш суммы для пакетов.

Иллюзия мечты

It's not a bug, it's a feature.

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

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

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

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

А вы как думаете - дочитав?