The WebAssembly stack machine is restricted to structured control flow and structured use of the stack. This greatly simplifies one-pass verification, avoiding a fixpoint computation like that of other stack machines such as the Java Virtual Machine (prior to stack maps). This also simplifies compilation and manipulation of WebAssembly code by other tools. Further generalization of the WebAssembly stack machine is planned post-MVP, such as the addition of multiple return values from control flow constructs and function calls.
Хоть ты тресни, но конкретно в коде для исполнения все увиденные мной интерпретаторы преобразуют все контрольные инструкции в аналоги goto ещё на этапе чтения чтении. Так быстрее и привычнее для машинного кода. Из каких соображений для байткода был выбран именно такой формат управляющих конструкций? Неужели только для красивого ручного написания?
В случае, например, Java, JIT–компилятор пытается из байткода восстановить как раз похожие структуры, это требуется для того, чтобы оценить время жизни локальных переменных, выполнить оптимизации и т. п.
На мой взгляд, то что сделано в webassembly очень дружелюбно по отношению к реализации оптимизирующих JIT–компиляторов.
В одном проекте, который я унаследовал при поступлении на работу была глобальная переменная isUtilCall. На мой вопрос: "зачем она нужна?" — получил ответ, что я пойму позже. В последующий год я всё больше ценил то, что предыдущий коллега не поддался искушению дать мне часть правды, а подготовил к практической непознаваемости всей семантики этого механизма.
Так лучше понятно, что автор не валит в кучу решения с противоположными целями.
Насколько я помню, DPS — это активный язык, на котором в частности писались и обработчики событий, таких как динамическая смена размеров.
Сравнение с Кнутом очень хорошо — эта книга как раз та, которую стоит прочитать, хотя бы один раз. И не только потому, что на эту тему нет других источников, а потому, что книга, можно сказать, классическая, хоть и устаревшая.
Чтобы изобретать качественные велосипеды надо знать работы предшественников.
Присоединяюсь к рекомендации книги The craft of text editing: в ней обсуждаются почти все вопросы, которые возникают у разработчика текстовых редакторов.
Есть ещё любопытная утилита gnu-pw-mgr.
А любопытна она тем, что делает безопаснее известный метод генерации паролей по имени сайта/пользователя и т. п.
Метод включает в себя два компонента:
файл с ключом, который стоит защитить, но утеря не так опасна
секретный метод преобразования.
Если я, например, хочу получить пароль для доступа на habrahabr.ru, то я ввожу в gnu-pw-mgr habra_SECRET_rbah.ru и получаю достаточно случайный пароль.
Преимущество в том, что пароли не хранятся, утеря файла с ключом не так критична. Недостаток в том, что надо следить за тем, чтобы секретная трансформация не была раскрыта.
В .Net ресурсы могут и никогда не освободиться, если сборщик мусора не успел отработать до завершения программы.
Мне в своё время для анализа освобождения ресурсов очень помогло осознание того факта, что сборщик мусора, который ничего не собирает, а освобождает память по завершению процесса — тоже удовлетворяет предъявляемым к GC требованиям.
Поэтому на финализаторы надеяться нельзя, освобождение должно быть детерминированным.
А RAII и using это фактически один и тот же приём: связывание области видимости с временем жизни ресурса, только в C++ область задаётся неявно, а в C# — явно.
На финализаторы надеяться нельзя: они больше подушка безопасности.
У меня был случай, когда приходилось лезть с помощью reflection внутрь объекта, чтобы высвободить большой Bitmap, который не освобождался, хотя верхние объекты поддерживали IDispose. Сборщик мусора не видел проблем, так как его объекты занимали немного места, а вот нативной памяти уже не хватало.
Пара советов из моего опыта поддержки большого смешанного проекта:
в области C++/CLI надо находиться как можно меньше, слой совместимости между нативным и управляемым кодом должен быть как можно тоньше
если объектная система или процесс взаимодействия не тривиален, то COM — оправданный выбор для организации взаимодействия. Хотя я бы воздержался от автоматической активации через реестр или манифесты, они приносят гораздо больше проблем, чем кажущейся пользы.
вопрос управления ресурсами должен быть обязательно продуман, чтобы большие куски памяти или того хуже соединения не зависали непонятно где.
Вся эта глыба документов применяется только в тот момент, когда вы говорите, что реализовали криптографию и гарантируете это.
Т. е. если информация относится к защищаемой согласно закону, например, персональные данные, то требуется доказуемая с точки зрения органов гарантия.
Для этого и есть лицензирование, сертификация и прочие радости, предназначенные для подтверждения этих гарантий.
Если же это не требуется, то всё использование алгоритмов шифрования и подписей — это просто меры, направленные на безопасность, но не гарантирующие её (с точки зрения органов).
TL;DR: Использовать криптографию можно, нельзя говорить, что она есть и что-то гарантирует.
Мне кажется, что в данных условиях особенно важно отследить потерю битов.
Для этого можно добавить какой-нибудь легко детектируемый синхросимвол (0xFF, например) через равные интервалы, а после этого оценивать потерю и либо восстанавливать кадры, либо перезапрашивать их.
В принципе, в Design Rationale так и пишут:
В случае, например, Java, JIT–компилятор пытается из байткода восстановить как раз похожие структуры, это требуется для того, чтобы оценить время жизни локальных переменных, выполнить оптимизации и т. п.
На мой взгляд, то что сделано в webassembly очень дружелюбно по отношению к реализации оптимизирующих JIT–компиляторов.
В одном проекте, который я унаследовал при поступлении на работу была глобальная переменная isUtilCall. На мой вопрос: "зачем она нужна?" — получил ответ, что я пойму позже. В последующий год я всё больше ценил то, что предыдущий коллега не поддался искушению дать мне часть правды, а подготовил к практической непознаваемости всей семантики этого механизма.
Так лучше понятно, что автор не валит в кучу решения с противоположными целями.
Насколько я помню, DPS — это активный язык, на котором в частности писались и обработчики событий, таких как динамическая смена размеров.
Вот верная сылка на Tower of abstraction.
Насколько я понимаю — автор статьи и инструмента это один и тот же человек.
Сравнение с Кнутом очень хорошо — эта книга как раз та, которую стоит прочитать, хотя бы один раз. И не только потому, что на эту тему нет других источников, а потому, что книга, можно сказать, классическая, хоть и устаревшая.
Чтобы изобретать качественные велосипеды надо знать работы предшественников.
Присоединяюсь к рекомендации книги The craft of text editing: в ней обсуждаются почти все вопросы, которые возникают у разработчика текстовых редакторов.
Есть ещё любопытная утилита gnu-pw-mgr.
А любопытна она тем, что делает безопаснее известный метод генерации паролей по имени сайта/пользователя и т. п.
Метод включает в себя два компонента:
Если я, например, хочу получить пароль для доступа на habrahabr.ru, то я ввожу в gnu-pw-mgr habra_SECRET_rbah.ru и получаю достаточно случайный пароль.
Преимущество в том, что пароли не хранятся, утеря файла с ключом не так критична. Недостаток в том, что надо следить за тем, чтобы секретная трансформация не была раскрыта.
Сохраню здесь ещё полезные ссылки:
Порекомендую книгу Adam Nathan — .NET and COM: The Complete Interoperability Guide.
Эта книга практически полностью описывает тему взаимодействия нативного и управляемого кода, если там чего-то нет, то скорее всего этого нельзя сделать.
В .Net ресурсы могут и никогда не освободиться, если сборщик мусора не успел отработать до завершения программы.
Мне в своё время для анализа освобождения ресурсов очень помогло осознание того факта, что сборщик мусора, который ничего не собирает, а освобождает память по завершению процесса — тоже удовлетворяет предъявляемым к GC требованиям.
Поэтому на финализаторы надеяться нельзя, освобождение должно быть детерминированным.
А RAII и using это фактически один и тот же приём: связывание области видимости с временем жизни ресурса, только в C++ область задаётся неявно, а в C# — явно.
На финализаторы надеяться нельзя: они больше подушка безопасности.
У меня был случай, когда приходилось лезть с помощью reflection внутрь объекта, чтобы высвободить большой Bitmap, который не освобождался, хотя верхние объекты поддерживали IDispose. Сборщик мусора не видел проблем, так как его объекты занимали немного места, а вот нативной памяти уже не хватало.
Пара советов из моего опыта поддержки большого смешанного проекта:
У lua — регистровая машина.
Могу и обмануть, это только моё мнение:
Вся эта глыба документов применяется только в тот момент, когда вы говорите, что реализовали криптографию и гарантируете это.
Т. е. если информация относится к защищаемой согласно закону, например, персональные данные, то требуется доказуемая с точки зрения органов гарантия.
Для этого и есть лицензирование, сертификация и прочие радости, предназначенные для подтверждения этих гарантий.
Если же это не требуется, то всё использование алгоритмов шифрования и подписей — это просто меры, направленные на безопасность, но не гарантирующие её (с точки зрения органов).
TL;DR: Использовать криптографию можно, нельзя говорить, что она есть и что-то гарантирует.
Ещё в этом документе можно посмотреть на реализацию Marker Code, который предназначен для борьбы со вставками/удалениями.
Мне кажется, что в данных условиях особенно важно отследить потерю битов.
Для этого можно добавить какой-нибудь легко детектируемый синхросимвол (0xFF, например) через равные интервалы, а после этого оценивать потерю и либо восстанавливать кадры, либо перезапрашивать их.
Ну, если мы говорим за сотни тысяч лет, то надо подождать: человечеству как социальной структуре всего-то пару десятков тысяч лет.