Я думаю, дело в том, что большинство людей исползующих этот стэк (ну да stack) технологий, не заботит уязвимость, т.к. крутится это всё в виртуальной сети, поднимается на один раз и не на долго.
Атакующий может урвать кусок плохоструктурированной информации, в лучшем случае.
Если же безопасность таки критична — всегда можно собрать свой репозиторий. Вопрос в цене. Для большинства случаев достаточно поделия из фекалий и сучьев.
Имхо, не хватает сравнительных характеристик по сложности и памяти с тем же merge sort. А так же, демонстрации утверждения «он достаточно легко параллелится». Для ленивых так сказать.
Я рад за опенсурс сообщество, но расстроен появлением альтернативы linux.
С одной стороны, это потенциально миллионы пользователей, гораздо более бескровно переходящих на открытый продукт, с другой, это дополнительная платформа, которую всё равно придётся поддерживать отдельно, скорее всего.
Вообще не в теме, но интересно — React OS настолько совместима, что в ней select тоже не умеет в файловые дескрипторы?
В какую сторону развивается проект — полная совместимость или более плотная интеграция с открытыми стандартами?
И то и то, на мой взгляд, в перспективе выглядит не очень, особенно на фоне того же «стратегического» софта, написанного под мсвс и иже с ними, а так же оставление возможности microsof ещё довольно долго диктовать направления развития.
Ещё такой вопрос — насколько тот же tcp/ip стек, по скорости сравним с тем, что имеется в 2012 сервере и последних ядрышках linux'a?
есть возможность задать буфер приема, SO_RCVBUF, но на моем тест-стенде это не дало никаких результатов.
А вы не проверяли код возврата setsockopt? Ибо на той же 7ой центоси этот буффер по умолчанию ограничен 512kb, когда как на практике для подобных процессоров знающие люди рекомендуют от 4mb.
Сделать ограниченый DSL на js, или том же python, не является особой проблеммой, оба интерпретатора имеют кучу открытых и легко кастомизируемых реализаций. При этом не надо будет учить новый язык, и писать новый парсер.
Вот тот же OpenSCAD, у них опять же свой язык, но зачем — непонятно, ограничения без какой либо необходимости. Проект опенсурсный и бесплатный, может автор просто хотел свой интерпретатор написать, чисто как упражнение? Единственное предположение — нижележащий язык это ассемблер, и это представление наиболее эффективно для данной предметной области. Но опять же, вряд ли оно сильно выигрывает у asm.js.
Заточить js интерпретатор под свои нужды — крайне не сложно. Что характерно, находятся товарищи которые делают например так :)
>А вот это я не понял:
— Кэшированные переменные и все их атрибуты
Это уже тонкости реализации, CMake складывает уже вычисленные переменные в бд(кэш) и не вычисляет их до тех пор, пока их не удалить из кэша, или не изменить им значиение насильно.
В любом случае, такое можно сделать на чём угодно, так что относить сиё к поинтам языка CMake — слегка странно, это просто фича.
Однако, никто, пока что, так и не встроил CMake в ide, без костылестроения :) Если только JetBrains (надо бы потыкать).
Вот тот же qbs, можно без проблем встроить куда душа попросит, и я не сказал бы что там какой то адский синтаксис, жалко вот он сам собирает (как и упомянутый вами SCons), то бишь относится слегка к другому классу инструментов.
> Это «отсутсвие или слабая выразительность» для системы сборки — как мана небесная, поскольку на cmake всё-таки собирают проекты, а не часы рисуют.
По мимо сборки, на средних и больших проектах встречается ещё ряд задач, как то покрытие кода разного уровня тестами, различные виды анализа кодовой базы (часто специфичные для проекта), кодогенерация и прочие плюшки. В таком случае одна фигня приходится делать find_package(Python REQUIRED) и забавляться с кастомными целями, либо обрастать платформозависимым шелом.
Системы сборки которые отвратительны, таковы не из-за языка. В CMake мощная концепция метасборщика, удачно сочетается с модульной системой поиска всего и вся. Однако, имеется определённый порог вхождения, отсутсвие или слабая выразительность многих привычных языковых средств.
Сильно сомневаюсь что можно найти, хоть какой то код на CMake, который будет выглядеть проще и лаконичнее чем аналог на любой распостранёной скриптоте общего назначения. Отсюда — не ясен профит создания и поддержки нового языка (если только это не vendor lock).
Я уже молчу про то, что если бы это был например js, то встроить поддержку CMake в ваше любимое IDE заняло бы пару дней у плохо обученного школьника (и без костылей типа парсинга cbp файла).
Если вещь популярная, то можно заварить пакет для PlayOnLinux.
Если там не последние дотнеты, то скорее всего, можно запилить. Я обычно делаю так — смотрю, что нужное мну поделие требует под виндой, потом ищу в playonlinux (халявный аналог кроссовера, поддерживается тоже достаточно халявно, хоть и активно), что то похожее, готовлю для этого поделия wine-prefix, а потом пытаюсь уже в этом префиксе дорешать косяки конкретного софта.
Атакующий может урвать кусок плохоструктурированной информации, в лучшем случае.
Если же безопасность таки критична — всегда можно собрать свой репозиторий. Вопрос в цене. Для большинства случаев достаточно поделия из фекалий и сучьев.
Имхо, не хватает сравнительных характеристик по сложности и памяти с тем же merge sort. А так же, демонстрации утверждения «он достаточно легко параллелится». Для ленивых так сказать.
С одной стороны, это потенциально миллионы пользователей, гораздо более бескровно переходящих на открытый продукт, с другой, это дополнительная платформа, которую всё равно придётся поддерживать отдельно, скорее всего.
Вообще не в теме, но интересно — React OS настолько совместима, что в ней select тоже не умеет в файловые дескрипторы?
В какую сторону развивается проект — полная совместимость или более плотная интеграция с открытыми стандартами?
И то и то, на мой взгляд, в перспективе выглядит не очень, особенно на фоне того же «стратегического» софта, написанного под мсвс и иже с ними, а так же оставление возможности microsof ещё довольно долго диктовать направления развития.
Ещё такой вопрос — насколько тот же tcp/ip стек, по скорости сравним с тем, что имеется в 2012 сервере и последних ядрышках linux'a?
А вы не проверяли код возврата setsockopt? Ибо на той же 7ой центоси этот буффер по умолчанию ограничен 512kb, когда как на практике для подобных процессоров знающие люди рекомендуют от 4mb.
Достаточно обернуть команды в неймспейс, например cmd.
И можно будет писать что то типа session.run(ZooKeeper::cmd::delete());
Кстати, у Майерса в его книженции про 11ый есть ряд рекомендаций по типовой реализации pimpl, не совсеми я согласен, но почитать стоит.
Upd.Ой, не увидел ссылку на сорцы.
Вот тот же OpenSCAD, у них опять же свой язык, но зачем — непонятно, ограничения без какой либо необходимости. Проект опенсурсный и бесплатный, может автор просто хотел свой интерпретатор написать, чисто как упражнение? Единственное предположение — нижележащий язык это ассемблер, и это представление наиболее эффективно для данной предметной области. Но опять же, вряд ли оно сильно выигрывает у asm.js.
Заточить js интерпретатор под свои нужды — крайне не сложно. Что характерно, находятся товарищи которые делают например так :)
— Кэшированные переменные и все их атрибуты
Это уже тонкости реализации, CMake складывает уже вычисленные переменные в бд(кэш) и не вычисляет их до тех пор, пока их не удалить из кэша, или не изменить им значиение насильно.
В любом случае, такое можно сделать на чём угодно, так что относить сиё к поинтам языка CMake — слегка странно, это просто фича.
Вот тот же qbs, можно без проблем встроить куда душа попросит, и я не сказал бы что там какой то адский синтаксис, жалко вот он сам собирает (как и упомянутый вами SCons), то бишь относится слегка к другому классу инструментов.
> Это «отсутсвие или слабая выразительность» для системы сборки — как мана небесная, поскольку на cmake всё-таки собирают проекты, а не часы рисуют.
По мимо сборки, на средних и больших проектах встречается ещё ряд задач, как то покрытие кода разного уровня тестами, различные виды анализа кодовой базы (часто специфичные для проекта), кодогенерация и прочие плюшки. В таком случае одна фигня приходится делать find_package(Python REQUIRED) и забавляться с кастомными целями, либо обрастать платформозависимым шелом.
Сильно сомневаюсь что можно найти, хоть какой то код на CMake, который будет выглядеть проще и лаконичнее чем аналог на любой распостранёной скриптоте общего назначения. Отсюда — не ясен профит создания и поддержки нового языка (если только это не vendor lock).
Я уже молчу про то, что если бы это был например js, то встроить поддержку CMake в ваше любимое IDE заняло бы пару дней у плохо обученного школьника (и без костылей типа парсинга cbp файла).
Если вещь популярная, то можно заварить пакет для PlayOnLinux.
Если там не последние дотнеты, то скорее всего, можно запилить. Я обычно делаю так — смотрю, что нужное мну поделие требует под виндой, потом ищу в playonlinux (халявный аналог кроссовера, поддерживается тоже достаточно халявно, хоть и активно), что то похожее, готовлю для этого поделия wine-prefix, а потом пытаюсь уже в этом префиксе дорешать косяки конкретного софта.