Category: технологии

Category was added automatically. Read all entries about "технологии".

flow

Merkle tree для идентификации

Криптохэши прекрасно подходят для идентификации статичных данных. Запросили из content-addressable storage (CAS) файлик (точнее blob) по криптохэшу, вот он пришёл, всё можно проверить, ничего нельзя подменить (с поправкой на стойкость криптохэш-функции). Но проверить можно только целиком. А если идентификация не совпала - можно попробовать перекачать, снова целиком, так как неизвестно, какие фрагменты скачаны с ошибками. Для мелких данных ок, для гигабайтных блобов уже нет. Стандартный приём - построить Merkle tree, на нижнем уровне считая криптохэши от фрагментов в N байт, а на каждом следующем криптохэш от списка криптохэшей предыдущего уровня.

Как идентифицировать выбранный алгоритм построения Merkle tree (учитывая разные возможные подходы)? На мой взгляд, удобно задать Merkle tree через криптохэш-функцию и параметр N как максимальный размер и фрагментов данных, и неразрывных фрагментов списков криптохэшей. Например, выбрали SHA-256 и N = 64KiB (2**16) - это фрагменты до 65536 байт данных на нижнем уровне и до 2048 полных криптохэшей SHA-256 на верхних. Тогда получившуюся функцию можно обозначить как SHA-256-P64K (или sha256p64k). При таком подходе идентификация блобов до 64KiB включительно совпадёт с SHA-256, идентификация от 64KiB+1 до 128MiB включительно потребует одного уровня косвенности, и так далее. Обращаемся к CAS, получаем по SHA-256-P64K содержимое файла или карту фрагментов следующего уровня, которые можно параллельно скачивать и проверять, хоть с этого же CAS (с любым приемлемым количеством соединений), хоть с других доверенных источников.

Людей, знакомых с рассматриваемыми технологиями, могла насторожить фраза "идентификация блобов до 64KiB включительно совпадёт с SHA-256". Каждый уровень Merkle tree принято наделять маркером, используемом при вычислении криптохэша на этом уровне. Можно, например, вставить байт 00 перед вычислением криптохэшей от фрагментов данных, байт 01 перед вычислением криптохэшей от фрагментов списков криптохэшей нижнего уровня, и так далее. Без этого идентификация через Merkle tree теряет уникальность, те же байты могут идентифицировать и сами данные, и их "карту", чем могут воспользоваться злоумышленники.

Но я вижу и другое решение. Вместо использования уровня косвенности в качестве префикса при вычислении каждого конкретного криптохэша - использовать это значение в операции xor с последним байтом получаемого криптохэша. В этом случае (для примера с SHA-256-P64K) фрагменты блобов на нижнем уровне будут идентифицироваться по SHA-256, фрагменты списков криптохэшей на следующем - по результату SHA-256 с (hash[31] ^= 1), и так далее с (hash[31] ^= indirection_level). Такая операция возвращает уникальность и обладает тем интересным свойством, что идентификация данных какого-либо уровня и их "карты" расходятся только в последнем байте. Что упрощает отладку и поддержку CAS.

Покрутил я эту модель, прикинул различные сценарии поведения (вплоть до случаев memory error, с учётом прочих метаданных в CAS), и пока выглядит оптимально. Если у вас есть свои соображения - пишите. Чуть позже напишу продолжение об идентификации не-статичных данных.
flow

Halt аnd Cаtch Firе

Заценил пилотную серию Halt аnd Cаtch Firе, выглядит перспективно, трансляцию начнут в июне.

Очень клёвый сеттинг - люди делают хайтек в Техасе начала восьмидесятых. Мне это ближе, чем обывательский взгляд на душевные метания сегодняшней хипстоты (в сериальчиках типа Silicon Valley, etc).

Трейлер: https://www.youtube.com/watch?v=WMi6fYsqW9s
flow

Хорошее чтение

http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/

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

Детально и с тестами рассматриваются различия в характеристиках между современными десктопами и мобильными устройствами, между нативным кодом и интерпретаторами/JIT, объём память, фризы GC, а также другие особенности платформ. В финале приводятся выводы вроде "It’s slower than x86 C/C++ by about 50", но если вы работали с нативом, то понимаете, что на этом месте может быть и 100, и 200, и...
flow

Безопасность

Интернеты облетела новость о беспроводном взломе японских унитазов Satis...

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

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

Прогресс

Навеяно обсуждением автомобилей без водителей в http://ailev.livejournal.com/1045473.html

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

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

Почему AI не работает?

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

Разгадка простая. Решение дифференциальных уравнений можно жёстко запрограммировать. Но умению отвечать на вопросы Jeopardy (как у IBM Watson) можно только обучить. Однако, и обучение искусственного интеллекта, и валидация результатов его самообучения требуют огромных затрат человеческого времени. Поэтому внутри маленьких предметных областей есть шанс получить разумный по человеческим меркам вывод, а для запросов общего вида только IBM Watson и статистический ответ уровня "слухами земля полнится". Что тоже полезно, но не про это мечтали фантасты.

Когда будет что-то лучше? Никто не знает. Машинные мощности и гонка гигагерц здесь не основной фактор. Люди медленно учат машины. И ещё медленнее учатся лучше их учить.
flow

геймдев

Последние летние танцы на траве. Вчерашняя погода была очень в тему. А сегодняшний ливень - на сейчас. Время для творческих потоков и тёплых компаний.

Недавно прошёл одну простенькую аркаду - Scarygirl (играется в браузере с http://www.scarygirl.com/). Те уровни, что созданы на данный момент. Я давно уже ни во что не играю. За этот год единственный случай, исключение. Игра оказалась точным воплощением того будущего, развития идей, что я видел 15 лет назад, играя в Dizzy и другие похожие игры. Вплоть до "мультиков" в диалогах. Радует, очень.

А позавчера наткнулся в ютубе на http://www.youtube.com/user/cubex55, канал с большим количеством лонгплеев. С огромным удовольствием просмотрел FF7: Crisis Core. Смысл просмотра лонгплеев в том, воспринимаемый результат от прохождения игры может оказаться дешевле, чем затрачиваемые на неё усилия. (Про дешёвый результат - это и отмаза, почему я не играю - менее виртуальные развлечения оказываются намного более приятным вложением времени). Но если желаемый результат не зависит от собственной вовлечённости в процесс игры, то собственное прохождение может стать минусом, а проматывание-просмотр лонгплея плюсом. И особенным плюсом для разработчика игр, когда интерес и желаемый результат являются профессиональными.

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

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