Поделюсь своим опытом использования Movidius. Купил в январе Б/У USB стик первой версии. В инструкциях ncsdk указано, что поддерживаемая платформа — Ubuntu 16.04. Поставил на VirutalBox. При скачивании Python зависимостей вылезает куча несовместимостей. Из коробки пытается поставить TF 1.11, почему-то она не встала (уже не помню причину). После пляски с бубнами удалось все поставить, но с последней версией TF, а она требует наборы инструкций FMA процессора, которые не предоставляет VirbualBox, хотя есть на хост-машине (у них 5 лет уже есть тикет на это: www.virtualbox.org/ticket/15471). Понятно, что тут нет претензий к разработчикам ncsdk/Intel и можно перекомпилировать TF под VirtualBox без этих инструкций, но из коробки у меня стик не заработал даже в рекомендованном окружении. В конце концов удалось запуститься на Ubuntu 20.04 (уже без виртуалки), тут тоже были проблемы с зависимостями Python; не все apt зависимости были прописаны в requirements_apt.txt. Когда я смог программно обратиться к устройству и убедиться, что купил рабочий экземпляр, запал разбираться с ним уже пропал. Суммарно потратил на все это несколько вечеров, хотя ожидалось, что запущу ./install.sh и все взлетит. Кстати, докер контейнер тоже не удалось запустить, но сейчас на вспомню причину. По факту, ни один из рекомендованных способов установки не работает без допиливания напильником.
Тут идея не в том, чтобы покупать книгу по цитате, а в том, чтобы найти книгу по интересующей теме. Была у меня задача по преобразованию булевых функций. Вспомнил, что в университете проходили что-то подобное на дискретке, нашел Яблонского (Дискретная математика), да не совсем то. Перерыл кучу книг, нашел нужный теоретический материал у Глушкова в «Синтезе цифровых автоматов», книга 62 года (оказалось, что интуитивно реализовал алгоритм, который там описан был). Вот было бы классно, если бы можно было это в каком-нибудь поисковике по книгам находить…
В любом случае, большое спасибо за ответы!
Хорошо, а если зайти с другой стороны — существует большое количество книг в электронном виде. Если их проиндексировать и открыть публичный доступ к полнотекстовому поиску, но сами книги будут недоступны для скачивания. К примеру, хочу я почитать про быстрое преобразование Фурье, но не знаю где про это написано. А тут нахожу ссылку на того же Кормена и еще десяток книг. Потом иду покупаю нужную книгу (или нахожу где-то у друзей, в сети и т.д.). Вопрос в том, насколько легально выдавать такой поисковый результат (по сути это будет несколько строк с контентом книги, как выдача Google)? Во всех копирайтах написано «никакая часть книги не может быть воспроизведена...», а тут получается любая часть книги может быть воспроизведена, но лишь несколько строк, а вся книга — недоступна.
А можно ли у издательства выкупить права на книгу (скорее на электронную версию) и разместить ее в открытом доступе в сети? Скинуться толпой на «Книгу дракона», Шнаера или Кормена и сделать доступными легально (нелегально их и так можно найти). Насколько реально договориться с издательством? Будет ли это безумно дорого?
Спасибо за статью — было очень интересно прочитать.
Работаю над пет-проектом по созданию сервиса для тренировки слов (существующие сервисы меня не устраивают). Подскажите, пожалуйста, где можно скачать/купить словари по типу Лингво. Пока мне хватает того, что можно достать на рутрекере (там есть куча stardict словарей), но на будущее хотелось бы иметь всякие экзотические пары типа потугальский-немецкий, словари типа толковых, когда язык «перевода» тот же, что и оригинала. Как пример англо-английские словари Collins, Oxford Dictionary, наш словарь Даля. Еще мне непонятна правовая база использования словарей — как с этим можно разобраться, какие тут правила игры?
Когда я работал над классами для Java bytecode, я прогонял через загрузку/выгрузку все классы от сервера приложений Weblogic, далее сравнивал выход моей программы с оригиналом. Там где были изменения я анализировал в чем были мои недочеты. Когда начал работать над BMP форматом — то сразу застрял на загололвке: там описаны возможные варианты для OS2, а у меня таких файлов не было для исследования. Скорее всего правилней бьыло бы взять любой имеющийся BMP файл и создавать структуру, как частный случай. Но мне хотелось покрыть полностью специйикацию, а без конкретных примеров это было бы проблематично.
А самое неприятное в спеке для меня было вот что:
All 8-byte constants take up two entries in the constant_pool table of the class
file. If a CONSTANT_Long_info or CONSTANT_Double_info structure is the entry
at index n in the constant_pool table, then the next usable entry in the table is
located at index n+2. The constant_pool index n+1 must be valid but is considered
unusable.
То есть для long и double info в constant pool используется две ячейки, причем во второй — всегда пусто.
Позже это было признано неудачным дизайнерским решением:
In retrospect, making 8-byte constants take two constant pool entries was a poor choice.
Примерно год назад с помощью этой библиотеки смог зареверсить бинарный формат от устройства, которое снимает суточную активность сердца (датчик Холтера вроде это называется).
Я заморочился лет 10 назад и перевел спецификацию байткода Java на формальный язык Java. Пришлось придумать несколько анатаций, с помощью которых можно описывать бинарные форматы. Далее я написал универсальный загрузчик/сериалайзер который умеет загружать бинарные файлы (.class файлы как частный случай) с использованием описания формата (читай набор java классов со специальными анатациями). К сожалению, на опкоды меня не хватило — они просто как массив байтов хронятся (или что-то типа того, уже не помню).
Итак, Java bytecode specification, выраженная на языке Java: github.com/esavin/annotate4j-classfile
Классы, которые умеют это все загружать/выгружать тут: github.com/esavin/annotate4j-core
Несколько раз пытался написать статью тут, но так и не осилил.
Есть такя книга «Выбор» от Элияху Голдратта. В ней опысываются несколько примеров оптимизации розничной торговли. Если коротко, то идея такая: в магазине минимальный запас товара (в количестве единиц, а не ассортимент), покрывающий время доставки с регионального склада. В случае продажи, формируется заказ на пополнение. Региональный скалд работает по такому же принципу с более крупным складом (склад поставщика, например). Производство работает на основе уменшения запасов на главном складе. То есть модель «выталкивания» (когда производство и оптовики затоваривают магазины) меняется на модель «вытягивания» (когда магазины заказывают то что им реально нужно). Попутно в книге утверждается, что прогнозы работают очень плохо. У Голдратта все описано очень логично. Читая подобные статьи, что здесь, что у Мосигры, что у других компаний, я задаюсь вопросом — где ошибается Голдратт? Приминение его подхода должно очень сильно повлиять на оборачиваемость товара и уменьшение складских запасов. Почему все не используют такой подход? Хотелось бы подключить к разговору Сергея Milfgard, а то все время забывал написать этот вопрос к соответствующей статье в блоге Мосигры.
И еще одно — в Java есть куча Web framework'ов с которыми Veracode умеет работать. И если для JSP еще можно как-то выкрутиться, скомпилировав в Java код, а дальше анализировать как pure java, то все остальное нужно реализовывать специфичным для данного framework'а образом.
В Enterprise вам придется конкурировать не с SonarQube а с HP Fortify и Veracode. Мне приходилось сталкиваться с обоими системами. По ощущениям — HP Fortify более продвинутый. К примеру, если создается из кусков строк SQL выражение и выполняется просто через statement, то Veracode укажет это как SQL injection (и это может оказаться false positive), а Fortify проанализирует откуда берутся эти куски и, если там нет user input (в любом виде), то SQL injection не будет обнаружен. Если вы будете escap'ить сами user input чтобы избежать SQL injection, то Fortify это может понять, а Veracode — нет.
Далее — Veracod сканирует jar/war/ear файлы и ему не нужны исходники. Fortify встраивается в билд процесс (у нас был maven). Из этого можно сделать выводы, что Veracode просто разбирает Java bytecode, а Fortify получает AST (abstract syntax tree) и уже работает с ним. То есть обе системы не работают напрямую с исходниками и нет необходимости осуществлять синтаксический анализ исходников. По моему мнению это правильный подход, тем более что Java bytecode хорошо описан в спецификации. Я писал программу, которая его разбирает и дошел до команд виртуальной машины. По ощущениям, структура скомпилированного Java class файла достаточно логичная и понятная.
По поводу того, как используется сканер — приложение обязательно должно сканироваться перед релизом и релизить можно только приложения без critical и very height уязвимостей (это идеал, на практике, конечно, бывает по разному). К упомянутым типам уязвимостей относятся XSS, SQL injection, hardcoded passwords. На code smells всем наплевать при сканировании. То есть сканирование — это выявление уязвимостей, которые могут повлиять на безопасность системы. Качество кода не является сколь-нибудь важным на данном этапе.
И еще одно — не знаю как сейчас устроено у HP Fortify, но Veracode предоставляет сервис: вы закачиваете артифакты, Veracode их сканирует, вы получаете отчет (в web системе), в котором указаны найденные проблемы. У вас есть возможность связаться с сотрудниками Veracode, чтобы обсудить найденные уязвимости и пометить их как false positive (при необходимости). То есть это целая инфраструктура, которая не заканчивается на сканере.
Интервал до 3000 я взял просто для примера (чтобы не долго считалось). Если Ваш алгоритм вычисление хеша имеет коллизии на таком интервале, то он будет иметь их и на большем интервале. А для моего алгоритма есть теоретическое обоснование отсутствия коллизий на интервале от 0 до 216. Я не предлагаю сейчас начинать спор о допустимости использования функции XOR. Для двух переменных это не очень оправдано, а, возможно, для 10 — будет в самый раз.
Для тех, кто все еще не верит, что hash функция от Блоха не очень хороша, проведем небольшой эксперимент.
Возьмем промежуток от 0 до 216, возьмем случайную точку на плоскости примерно из середины этого промежутка. Координаты точки: (32127, 32123). Переберем все точки на заданном промежутке и посчитаем коллизии.
У меня получилось 2114. Много это или мало — пусть каждый решает сам.
Вы совершенно правы. Только нужно понимать, что если у Вас в исходной hash функции не было коллизий, то HashMap может странсформирует Ваш hashCode в коллизию для другого hash кода, а может и нет. А если у Вас изначально есть коллизия, то и в результате коллизия будет гарантирована.
Одно дело иметь хорошую hash функцию и осознанно не использовать всех ее свойств, и совсем другое дело думать, что имеешь хорошую hash функцию, но ошибаться.
В любом случае, большое спасибо за ответы!
Работаю над пет-проектом по созданию сервиса для тренировки слов (существующие сервисы меня не устраивают). Подскажите, пожалуйста, где можно скачать/купить словари по типу Лингво. Пока мне хватает того, что можно достать на рутрекере (там есть куча stardict словарей), но на будущее хотелось бы иметь всякие экзотические пары типа потугальский-немецкий, словари типа толковых, когда язык «перевода» тот же, что и оригинала. Как пример англо-английские словари Collins, Oxford Dictionary, наш словарь Даля. Еще мне непонятна правовая база использования словарей — как с этим можно разобраться, какие тут правила игры?
All 8-byte constants take up two entries in the constant_pool table of the class
file. If a CONSTANT_Long_info or CONSTANT_Double_info structure is the entry
at index n in the constant_pool table, then the next usable entry in the table is
located at index n+2. The constant_pool index n+1 must be valid but is considered
unusable.
То есть для long и double info в constant pool используется две ячейки, причем во второй — всегда пусто.
Позже это было признано неудачным дизайнерским решением:
In retrospect, making 8-byte constants take two constant pool entries was a poor choice.
Итак, Java bytecode specification, выраженная на языке Java: github.com/esavin/annotate4j-classfile
Классы, которые умеют это все загружать/выгружать тут: github.com/esavin/annotate4j-core
Несколько раз пытался написать статью тут, но так и не осилил.
Далее — Veracod сканирует jar/war/ear файлы и ему не нужны исходники. Fortify встраивается в билд процесс (у нас был maven). Из этого можно сделать выводы, что Veracode просто разбирает Java bytecode, а Fortify получает AST (abstract syntax tree) и уже работает с ним. То есть обе системы не работают напрямую с исходниками и нет необходимости осуществлять синтаксический анализ исходников. По моему мнению это правильный подход, тем более что Java bytecode хорошо описан в спецификации. Я писал программу, которая его разбирает и дошел до команд виртуальной машины. По ощущениям, структура скомпилированного Java class файла достаточно логичная и понятная.
По поводу того, как используется сканер — приложение обязательно должно сканироваться перед релизом и релизить можно только приложения без critical и very height уязвимостей (это идеал, на практике, конечно, бывает по разному). К упомянутым типам уязвимостей относятся XSS, SQL injection, hardcoded passwords. На code smells всем наплевать при сканировании. То есть сканирование — это выявление уязвимостей, которые могут повлиять на безопасность системы. Качество кода не является сколь-нибудь важным на данном этапе.
И еще одно — не знаю как сейчас устроено у HP Fortify, но Veracode предоставляет сервис: вы закачиваете артифакты, Veracode их сканирует, вы получаете отчет (в web системе), в котором указаны найденные проблемы. У вас есть возможность связаться с сотрудниками Veracode, чтобы обсудить найденные уязвимости и пометить их как false positive (при необходимости). То есть это целая инфраструктура, которая не заканчивается на сканере.
Возьмем промежуток от 0 до 216, возьмем случайную точку на плоскости примерно из середины этого промежутка. Координаты точки: (32127, 32123). Переберем все точки на заданном промежутке и посчитаем коллизии.
У меня получилось 2114. Много это или мало — пусть каждый решает сам.