Hello World,

Helios Kernel — это библиотека для управления зависимостями между javascript-модуями, реализующая «классический» подход, часто встречаемый в других языках и средах — с помощью функции include().

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

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

Helios Kernel поддерживает динамическую загрузку (и выгрузку) зависимостей в рантайме, а сама библиотека и формат модулей являются совместимыми между nodejs и броузерной средой — то есть модули можно использовать без изменений или трансляции.

В этой статье классический подход реализованный в Helios Kernel сравнивается с управлением зависимостями с помощью RequireJS и показывается, каким образом подход Helios Kernel позволяет избежать некоторых сложностей.

Читать дальше →

Hello World,

Helios Kernel — это библиотека позволяющая описывать зависимости между javascript-модулями «в стиле include»:

// объявление зависимостей
include("path/to/library1.js");
include("../path/to/another/library2.js");

init = function() {
    // использование зависимостей
    library1.doSomething();
    ...
}

Я уже писал про Helios Kernel раньше, с тех пор проект переехал на гитхаб, а поводом к новому релизу стал тот факт, что весь платформо-зависимый код был выделен, и после некоторого допиливания тесты наконец прошил и под nodejs:



Поэтому теперь я могу написать здесь про библиотеку громкое слово «кроссплатформенная»

Читать дальше →

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

Очень интересное чтение.

Особенно показательно то, что введение нового уровня защиты (подпись бинарников) создает новые угрозы. По крайней мере репутационные. Невнимательный исследователь может прийти к выводу, что распространяемые бинарники не вовспроизводятся из распространяемых исходников как раз из-за подписи, которую, естественно, без секретных ключей не воспроизвести. Да и с секретными ключами во всех алгоритмах подписи, основанных на схеме Эль-Гамаля (DSA, ECDSA, ГОСТ Р 34.10 всех лет) , участвует случайное число. Которое не воспроизведешь.

This entry was originally posted at http://vitus-wagner.dreamwidth.org/911237.html. Please comment there using OpenID. Now there are comments

Когда-то давно существовала система контроля версий cvs.
Вся она состояла из одного бинарника размером меньше мегабайта (под виндой чуть меньше, под линуксом чуть больше) и фактически не имела внешних зависимостей (один zlib. который недолго и статически вкомпилить).

Потом появилась subversion. Как сейчас помню как лет пять назад собирал эту самую subversion для разных солярисов. Тогда у нас уже была полиси не использовать пакетов с sunfreeware и blastwave, потому что они там без объявления войны меняют библиотеку на несовместимую и при попытке обновиться (что может быть необходимым для установки чего-то нового) ломается уже установленный софт. Поэтому всё: чего нет на software companion мы собирали в пакеты сами. (ну мы - это Мы. Великий и Могучий Утес далее по тексту). Не помню чтобы filin хотя бы один пакет для Solaris-а тогда собрал.

Так вот subversion уже требовала немерянноо количества всяких достаточно сложных в сборке библиотек - libneon. которая тащит openssl, sqlite etc. Под восьмой солярис-спарк я возился чуть ли не сутки.

С тех пор subversion еще немного подросла и, оказывается черепаховый svn под windows носит с собой собственный plink.

Теперь вот попробовал поставить на винду git. И обнаружил что он тащит с собой как бы не полную msys включая bash и perl. А также ssh. (Кстати вот msys-овский rsync надо пощупать). Правда: у git продвинутый инсталлятор - он находит в системе уже имеющийся plink от черепахи. Нашел бы наверное и от putty, если бы тот был в PATH.

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

И это я еще не рассматривал почти полностью скриптовый mercurial.

This entry was originally posted at http://vitus-wagner.dreamwidth.org/910998.html. Please comment there using OpenID. Now there are comments

Здравствуйте, хабрачеловеки! Темой этой статьи будет создание расширений для PostgreSQL. В качестве примера, мы реализуем небольшую библиотеку для работы с 3D векторами. Параллельно будут рассмотрены пользовательские типы, операторы и приведения типов. Не будет лишним ознакомися с этим материалом, так как реализация хранимых функций будет на языке C. Надеюсь, друзья слонов помогут скрасить серый технический текст статьи.
Подробней