Рубрика «mpl»

Как компании зарабатывают на опенсорсе, а потом выкидывают его - 1Финансирование разработки Kubernetes крупнейшими спонсорами на GitHub за последние десять лет, источник

Эти компании сначала при помощи сообщества разрабатывают опенсорсный софт или берут готовый, строят на нём прибыльный бизнес, зарабатывают миллионы. А потом меняют лицензию, оставляя контрибуторов, пользователей и партнёров в недоумении, что им делать. Такова бизнес-модель некоторых современных компаний вроде Redis Labs.

Но ещё хуже поступают крупные облачные провайдеры. Они просто используют готовые решения, вообще не занимаясь разработкой и убивая бизнес «паразитов», описанных выше. Здесь вообще паразиты в квадрате.

И весь этот террариум кормится опенсорсом.
Читать полностью »

3 апреля на сайте InfoWorld вышла статья известного публициста на тему Open Source и юриста Matt Asay под названием «OpenTofu, возможно, демонстрирует нам, как не надо делать форк». Лидер-абзац в статье довольно жёсткий: 

Не согласны с лицензией? Просто сделайте форк проекта, но не выкидывайте его код — говорите, что он всегда был доступен публично. Сравните код и лицензию HashiCorp с версией OpenTofu.

Читать полностью »

При выборе формата хранения или обмена векторными 2D изображениями, SVG один из главных претендентов, благодаря открытости и распространенности. При всех его достоинствах, авторы, на мой взгляд, чрезмерно увлеклись удобством и гибкостью при создании документов, что привело к большой вариативности и избыточности, а, следовательно, и сложностью чтения. Кроме того, ради компактности были изобретены разные грамматики, встроенные внутрь XML, что тоже добавило головной боли программистам.

Сейчас есть несколько C/C++ библиотек, которые могут загрузить SVG и отрисовать его в растр, но это только малая часть возможных применений SVG в приложениях.

Я разработал C++ библиотеку, которая должна взять на себя реализацию большинства нюансов спецификации, предоставляя данные SVG в удобном виде. Читать полностью »

Melange — DSL для сетевых протоколовВсем программистам рано или поздно приходится передавать данные. Ни для кого не секрет, что библиотек сериализации в Java существует примерно >9000, а в C++ они вроде и есть, а вроде их и нет. К счастью для большинства, несколько лет назад появился Google Protobuf, который принёс достаточно удобный способ определять структуры данных и быстро завоевал всенародную любовь. Это была фактически первая, доступная широким массам библиотека, позволяющая гонять по сети готовые структуры данных, не связываясь при этом с чем-то вроде XML. На дворе был 2008 год.

Вернёмся немного назад. В 2006 году простой индийский программист (как бы подозрительно это ни звучало!) Анил Мадхавапедди, один из самых известных сейчас в мире OCaml-разработчиков и автор свежевышедшей книги Real World OCaml, защищал в Кембридже кандидатскую диссертацию. Именно о ней я сегодня вам и расскажу.

Анил сразу пошёл дальше, чем Google. Он сразу подумал, для чего люди обычно пересылают по сети какие-то формализованные структуры данных? Чтобы реализовать какой-то протокол. А что такое протокол? Это какой-то конечный автомат. А где мы можем взять хороший пример сложного, хорошо спроектированного и проверенного временем протокола? Да прямо в обычном сетевом стеке! Итак, были взяты набор сетевых структур данных и протоколов: Ethernet frame, IPv4, ICMP, TCP, UDP, SSH, DNS и DHCP и постановка задачи: большая часть этих протоколов (особенно SSH и DNS) реализуются, что называется «руками», а хочется, чтобы не было типичных для C переполнений буфера, все переходы совершались автоматически, это всё можно было верифицировать, и чтобы работало быстро, а не как обычно.

Поскольку никто не будет читать диссертацию, сразу скажу: это более чем удалось. По результатам работы были написаны референсные реализации DNS и SSH-сервера и произведено сравнение с BIND и OpenSSH. OCaml-реализации давали по сравнению с традиционными прирост производительности от незначительного, до почти двухкратного. Кроме того была найдена ошибка в RFC на SSH (рабочая группа была уведомлена и RFC исправлен). О том, что было сделано, и как с этим жить, читайте под катом. Читать полностью »

Использовать шаблонные шаблонные параметры С++ довольно сложно. Хочу продемонстрировать силу boost::mpl и показать трюк, позволяющий описывать шаблоны, полностью отказавшись от шаблонных шаблонных параметров.
Продемонстрирую проблему. Есть класс, принимающий тип объекта и тип контейнера для этого объекта.

template <typename T, typename Container>
struct A
{
  typedef Container<T> type;
};

Так писать нельзя, вы должны использовать шаблонные шаблонные параметры, чтобы указать, что Container сам по себе является шаблоном.
Читать полностью »

Недавно мне пришлось работать с кодом, в котором задача передачи параметров произвольных типов решена с использованием стандартных STL контейнеров, параметризованных типом boost::any.
Например:

    void foo (std::vector<boost::any>& args) {
        // do smth.
    }

Предыдущий разработчик был не очень аккуратен и внутри функции работа с содержимым boost::any основывалась на предположении об исходном типе данных, то есть если преобразование boost::any_cast не проходило, то параметр пропускался. В определенных случаях такой способ обработки приемлем и примеры этой методики работы можно посмотреть тут.
Однако, мне хотелось несколько обобщить исходные предположения о типе данных.
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js