А при чем тут "зависимости для вашего кода" и пакетный менеджер ОС мне не совсем понятно.
Я думаю, имелась в виду возможность использовать при разработке библиотеки установленные в систему. `apt|rpm|pkg|... install opencv ffmpeg curl boost qt6`, и всё - можно собирать код использующий эти библиотеки.
Мне кажется, или в приведенном коде CERN httpd переполнение буфера при попытке раздать файл размером 100 десятичных гигабайт? Такой исторический код надо закопать и никогда на него не смотреть - это совсем другие языки (даже если это C), совсем другие требования, другая экспертиза. По современным меркам это один сплошной антипаттерн.
Я бы для этой задачи взял coastlines (а возможно и другие данные) из openstretmap, посчитал бы по ним distance field и определял бы зум за один (ну или 4 если хочется плавно) лукап. В общем виде это только так и решается, потому что если в качестве подложки использовать спутник, с одной стороны вода будет неоднородной, с другой - на сплошной лес тоже неинтересно смотреть.
Посыл статьи понял как негодование покушением на собственную незаменимость. К дискуссии по сути она не располагает, потому что вы сходу ставите диагнозы.
Как исключения вам помогут? Максимум у вас код в проде упадет где-то, вы это залогируете из эксепшена, и потом в этом месте добавите логику для фикса бага. Но данные уже не вернуть.
В go/rust вы сразу знаете все места где у вас упадет код, и в зависимости от контекста и важности функции, сразу можете корректно обработать этот случай.
Вообще-то исключения и коды ошибок функционально эквивалентны - всё что можно сделать одним инструментом можно сделать другим. Разница только в синтаксисе и, естественно, реализации. А синтаксис у исключений лучше по той простой причине что они прокидываются выше по стеку вызовов неявно. Дело в том что мест в коде которые могут завершиться неуспехом много, а мест где по этому поводу можно предпринять какие-то осмысленные действия - мало, поэтому в подавляющем большинстве мест обработки ошибок они просто прикидываются выше. Делать это явно - неблагодарная рутинная работа, и в результате получается раздутый код в котором за обработкой ошибок не видно реальной логики. Выше есть замечательный пример из ядра, он на четверть состоит из обработки ошибок. В rust эту проблему нивелировали до предела позволив прокидывать ошибки одним !, но по мне так даже это слишком много - визуальный шум и необходимость низачем держать в голове вызовы которые могут вернуть ошибку никуда не исчезли.
Пример - загрузка файла в каком-нибудь офисе. Нужно открыть собственно файл, прочитать, раз'zip'овать, распарсить xml, переложить во внутреннее представление, при этом только в парсинге xml может быть куча разных типов ошибок. Но сделать мы с этим ничего не можем - файл в любом случае битый. Структура кода будет одна - последовательность вызовов реализующая шаги загрузки, и обработка ошибки в одном месте где мы просто говорим "не шмогла". При желании обрабатываем конкретные типы ошибок с дополнительной информацией и говорим "не шмогла потому что в foo.xml не закрыт тэг <foo> в строке 79". Так вот код загрузки может быть либо кодом загрузки, либо кодом загрузки перемешанным с прокидыванием ошибок. Лучше однозначно первое.
Есть, но я же отвечал на комментарий про забор. Проходная там стандартная вахтёрская для галочки - первый день когда приехал на конференцию попросили паспорт, потом толпа ходила туда-сюда курить, никто уже ничего не контролировал, как и весь второй день. И кажется что если бы кто-то пошёл гулять по зданию, никто бы не заметил. Но не знаю, может там автоматчики в другом корпусе запрятаны.
На фото всего лишь институт программных систем РАН в Переславле, проход на территорию там не контролируется, и я не думаю что там есть что-то секретное. Весной там, например, БазАльтовская конференция по свободному ПО проходила. А секретные суперкомпуцкеры, как в статье написано, по совсем другим адресам.
Я еще не совсем хорошо понимаю, как заливать куда-либо c++ проект вместе с его зависимостями, поэтому вам придется самостоятельно устанавливать либу и подключать ее, если вы захотите это потестить.
Вместе с зависимостями никто проекты не заливает. Достаточно выложить на github репозиторий с двумя файлами - исходником и CMakeLists.text/meson.build/Makefile в зависимости от того чем он собирается. По-хорошему ещё с лицензией и readme.
Кому что. Я, например, твёрдо убеждён что игры могут быть только свободные (F/OSS). Только в СПО геймдеве живет чистое творчество без оглядки на коммерческий успех, популярность, конкуренцию в нише или, на худой конец, раскрутку личного бренда или заполнение портфолио. И только в СПО можно играть где и как мне хочется - на любой системе и железе, без wine, виртуалок, вылетов и зависаний. Самобытных шедевров достаточно - из любимого, например, Endless Sky, Flare RPG, Freeorion, Mindustry. Да и вся классика давно в виде СПО переписана - от ScummVM до DevilutionX.
Во-первых, добавление константы никак не повлияет на распределение задержки. Во-вторых sleep никак не помешает подбирать хэш параллельно и только положит сервер. Вы, наверное, имели в виду не допускать попыток логина чаще раза в секунду, но это не помешает набрать статистику задержек за обозримое время. С другой стороны, побайтово строки давно не сравнивают и вообще хэш - это вектор ui64. Но пример хороший.
Если мы говорим о Linux и FreeBSD, то нужна версия OpenSSL с поддержкой SCTP, по умолчанию в системе он собран без этой поддержки
Во-первых, такого требования вообще не должно быть, во-вторых не обязательно без:
% make -C /usr/ports/security/openssl -V OPTIONS_DEFAULT:MSCTP
SCTP
как я понял проект никому не понравился
Во-первых, вы ввели публику в заблуждение заголовком. Никто не увидел тут заявленного конструктора протоколов, потому что его тут нет. "Конструктор сервисов" не вводит в заблуждение, но ничего и не описывает. На самом деле это называется асинхронный сетевой фреймворк - написали бы так сразу и было бы понятно на что вообще смотреть. Во-вторых, для предметного обсуждения мало просто вывалить примеров. Неплохо было бы разобрать один и описать используемые сущности и их взаимодействие. Сравнить с аналогами. Кому-то наверняка были бы интересны бенчи. Рассказать где и как используется в проде. Лично для меня комментарии и описания к коммитам на русском и неопциональный бандлинг зависимостей - это шоу стопперы при которых дальше можно не смотреть. Если бы посмотрел дальше, бросил бы на отсутствии тестов и CI. Примеры, честно, не впечатляют - многословно, запутанно и несовременно. Но вообще начинание замечательное и таких штук в C++ мире сильно не хватает.
Вы зачем-то спорите с очевидно неверным утверждением, что оперсорс решает все проблемы, и делаете никак не следующие из этого выводы о том что опенсорс не лучше проприетарного ПО.
Дело не в том что опенсорс решает все проблемы, это конечно же не так. Дело в том что проприетарное ПО проблемы гарантировано создаёт, отнимая у пользователя его базовые возможности и права - изучать, изменять и распространять программу. С практической точки зрения это широчайший спектр кейсов, от "поправить тривиальный сегфолт/поменять местами кнопки", "пересобрать под свежую версию системы/железо/с новой версией openssl" через "нанять специалиста для реализации нужной фичи" и "поддерживать форк с любыми своими хотелками и полной интеграцией с собственно инфраструктурой" до "нет больше возможности законно использовать ПО в целой стране" и "работающее вчера ПО сегодня физически превратилось в тыкву".
> Но много ли среди всех, высказывающихся по данному вопросу, реально будут тратить время на аудит приложения?
Их не должно быть много или вообще быть. Достаточно чтобы компания или индивид которым это понадобится имели возможность его провести. Достаточно просто потенциальной возможности, иначе это риски, например, не получить какую-нибудь сертификацию когда это <внезапно> понадобится. Более того, если мы говорим не про бумажки, а про реальное доверие, то только с открытыми исходниками оно и возможно.
> замаскированный пакетик с ядом мимо глаз пропускают даже специализированное оборудование и служебные собаки
Тем не менее, в исходниках его спрятать гораздо сложнее, а в случае обнаружения с исходниками гораздо проще оценить impact, в какой момент он появился и через какой канал.
> обилие всевозможных проблем, обнаруженных в таких продуктах
Это не аргумент ни за одну сторону, потому что проблемы есть везде.
Однако, предлагаю подумать над следующей мыслью: каждый коммит от внешних людей в открытое ПО, будь то фича, багфикс или устранение уязвимости, в проприетарное ПО сделан не был и не будет.
> Для примера подобной работы можно взять беглый анализ активности Utopia Ecosystem
В этом "анализе" из наличия соединений вы делаете вывод о том что приложение пиринговое, а из того что не можете понять содержимого пакетов - о том что используется асимметричное (не асинхронное:) ) шифрование. Мало того что эти предположения, даже будь они доказанными, бесполезны, так они и не доказаны - приложение могло лить с кучи нод на вашу машину ЦП cleartext'ом, или заливать на кучу нод ваши пароли от банков и кошельков с xor шифрованием, или делать что угодно создавая соедениния со случайным мусором, выводы были теми же. Чтобы только проверить наличие заявленной функциональности, нужно разобраться в нескольких мегабайтах дизассемблерных листингов и дешифровать трафик, я не говорю даже о том чтобы проверить наличие недокументированных возможностей. В случае же исходников же достаточно было бы просто в них посмотреть.
> Данным материалом хочу высказать ИМХО: возводить open source в абсолют, как и ругать закрытые исходники, глупо.
FYI, существуют пакетные инфраструктуры предоставляющие несколько версий питона, в том числе одновременно. Например, порты FreeBSD. С ними мне ни разу в жизни не приходилось запускать pip или venv.
Режет глаз упоминание терминов “на стеке" и "в куче". Они относятся к регионам памяти, которые можно использовать произвольно - можно, например, выделить через new vector с кастомным аллокатором над куском стека, тогда вектор будет в куче, а элементы на стеке. А может быть всё в статической памяти. Поэтому лучше бы использовать термины вроде "непосредственно в объекте контейнера" и "аллоцируется отдельно".
Неплохая демонстрация, но недостаточно исследована тема защиты от этой атаки, и нагнано желтизны. Есть, например, проект gnu mes, который позволяет бутстрапнуть систему с нуля из исходников, вообще не прибегая к недоверенным бинарникам. А чтобы обнаружить evil цепочку в открытой экосистеме, например дебиана, достаточно одной проверки.
Я думаю, имелась в виду возможность использовать при разработке библиотеки установленные в систему. `apt|rpm|pkg|... install opencv ffmpeg curl boost qt6`, и всё - можно собирать код использующий эти библиотеки.
Мне кажется, или в приведенном коде CERN httpd переполнение буфера при попытке раздать файл размером 100 десятичных гигабайт? Такой исторический код надо закопать и никогда на него не смотреть - это совсем другие языки (даже если это C), совсем другие требования, другая экспертиза. По современным меркам это один сплошной антипаттерн.
Я бы для этой задачи взял coastlines (а возможно и другие данные) из openstretmap, посчитал бы по ним distance field и определял бы зум за один (ну или 4 если хочется плавно) лукап. В общем виде это только так и решается, потому что если в качестве подложки использовать спутник, с одной стороны вода будет неоднородной, с другой - на сплошной лес тоже неинтересно смотреть.
Посыл статьи понял как негодование покушением на собственную незаменимость. К дискуссии по сути она не располагает, потому что вы сходу ставите диагнозы.
Вообще-то исключения и коды ошибок функционально эквивалентны - всё что можно сделать одним инструментом можно сделать другим. Разница только в синтаксисе и, естественно, реализации. А синтаксис у исключений лучше по той простой причине что они прокидываются выше по стеку вызовов неявно. Дело в том что мест в коде которые могут завершиться неуспехом много, а мест где по этому поводу можно предпринять какие-то осмысленные действия - мало, поэтому в подавляющем большинстве мест обработки ошибок они просто прикидываются выше. Делать это явно - неблагодарная рутинная работа, и в результате получается раздутый код в котором за обработкой ошибок не видно реальной логики. Выше есть замечательный пример из ядра, он на четверть состоит из обработки ошибок. В rust эту проблему нивелировали до предела позволив прокидывать ошибки одним
!, но по мне так даже это слишком много - визуальный шум и необходимость низачем держать в голове вызовы которые могут вернуть ошибку никуда не исчезли.Пример - загрузка файла в каком-нибудь офисе. Нужно открыть собственно файл, прочитать, раз'zip'овать, распарсить xml, переложить во внутреннее представление, при этом только в парсинге xml может быть куча разных типов ошибок. Но сделать мы с этим ничего не можем - файл в любом случае битый. Структура кода будет одна - последовательность вызовов реализующая шаги загрузки, и обработка ошибки в одном месте где мы просто говорим "не шмогла". При желании обрабатываем конкретные типы ошибок с дополнительной информацией и говорим "не шмогла потому что в foo.xml не закрыт тэг <foo> в строке 79". Так вот код загрузки может быть либо кодом загрузки, либо кодом загрузки перемешанным с прокидыванием ошибок. Лучше однозначно первое.
Вы, верно, шутите? RAII или defer.
Есть, но я же отвечал на комментарий про забор. Проходная там стандартная вахтёрская для галочки - первый день когда приехал на конференцию попросили паспорт, потом толпа ходила туда-сюда курить, никто уже ничего не контролировал, как и весь второй день. И кажется что если бы кто-то пошёл гулять по зданию, никто бы не заметил. Но не знаю, может там автоматчики в другом корпусе запрятаны.
На фото всего лишь институт программных систем РАН в Переславле, проход на территорию там не контролируется, и я не думаю что там есть что-то секретное. Весной там, например, БазАльтовская конференция по свободному ПО проходила. А секретные суперкомпуцкеры, как в статье написано, по совсем другим адресам.
Вместе с зависимостями никто проекты не заливает. Достаточно выложить на github репозиторий с двумя файлами - исходником и CMakeLists.text/meson.build/Makefile в зависимости от того чем он собирается. По-хорошему ещё с лицензией и readme.
Кому что. Я, например, твёрдо убеждён что игры могут быть только свободные (F/OSS). Только в СПО геймдеве живет чистое творчество без оглядки на коммерческий успех, популярность, конкуренцию в нише или, на худой конец, раскрутку личного бренда или заполнение портфолио. И только в СПО можно играть где и как мне хочется - на любой системе и железе, без wine, виртуалок, вылетов и зависаний. Самобытных шедевров достаточно - из любимого, например, Endless Sky, Flare RPG, Freeorion, Mindustry. Да и вся классика давно в виде СПО переписана - от ScummVM до DevilutionX.
Во-первых, добавление константы никак не повлияет на распределение задержки. Во-вторых sleep никак не помешает подбирать хэш параллельно и только положит сервер. Вы, наверное, имели в виду не допускать попыток логина чаще раза в секунду, но это не помешает набрать статистику задержек за обозримое время. С другой стороны, побайтово строки давно не сравнивают и вообще хэш - это вектор ui64. Но пример хороший.
Во-первых, такого требования вообще не должно быть, во-вторых не обязательно без:
Во-первых, вы ввели публику в заблуждение заголовком. Никто не увидел тут заявленного конструктора протоколов, потому что его тут нет. "Конструктор сервисов" не вводит в заблуждение, но ничего и не описывает. На самом деле это называется асинхронный сетевой фреймворк - написали бы так сразу и было бы понятно на что вообще смотреть.
Во-вторых, для предметного обсуждения мало просто вывалить примеров. Неплохо было бы разобрать один и описать используемые сущности и их взаимодействие. Сравнить с аналогами. Кому-то наверняка были бы интересны бенчи. Рассказать где и как используется в проде.
Лично для меня комментарии и описания к коммитам на русском и неопциональный бандлинг зависимостей - это шоу стопперы при которых дальше можно не смотреть. Если бы посмотрел дальше, бросил бы на отсутствии тестов и CI. Примеры, честно, не впечатляют - многословно, запутанно и несовременно. Но вообще начинание замечательное и таких штук в C++ мире сильно не хватает.
А не хотите нормальную сборку сделать - зависимости из системы, сборку динамической библиотеки, установку без ограничений?
Думаю что нет. Это вернет True для любого вопроса.
Вы зачем-то спорите с очевидно неверным утверждением, что оперсорс решает все проблемы, и делаете никак не следующие из этого выводы о том что опенсорс не лучше проприетарного ПО.
Дело не в том что опенсорс решает все проблемы, это конечно же не так. Дело в том что проприетарное ПО проблемы гарантировано создаёт, отнимая у пользователя его базовые возможности и права - изучать, изменять и распространять программу. С практической точки зрения это широчайший спектр кейсов, от "поправить тривиальный сегфолт/поменять местами кнопки", "пересобрать под свежую версию системы/железо/с новой версией openssl" через "нанять специалиста для реализации нужной фичи" и "поддерживать форк с любыми своими хотелками и полной интеграцией с собственно инфраструктурой" до "нет больше возможности законно использовать ПО в целой стране" и "работающее вчера ПО сегодня физически превратилось в тыкву".
> Но много ли среди всех, высказывающихся по данному вопросу, реально будут тратить время на аудит приложения?
Их не должно быть много или вообще быть. Достаточно чтобы компания или индивид которым это понадобится имели возможность его провести. Достаточно просто потенциальной возможности, иначе это риски, например, не получить какую-нибудь сертификацию когда это <внезапно> понадобится. Более того, если мы говорим не про бумажки, а про реальное доверие, то только с открытыми исходниками оно и возможно.
> замаскированный пакетик с ядом мимо глаз пропускают даже специализированное оборудование и служебные собаки
Тем не менее, в исходниках его спрятать гораздо сложнее, а в случае обнаружения с исходниками гораздо проще оценить impact, в какой момент он появился и через какой канал.
> обилие всевозможных проблем, обнаруженных в таких продуктах
Это не аргумент ни за одну сторону, потому что проблемы есть везде.
Однако, предлагаю подумать над следующей мыслью: каждый коммит от внешних людей в открытое ПО, будь то фича, багфикс или устранение уязвимости, в проприетарное ПО сделан не был и не будет.
> Для примера подобной работы можно взять беглый анализ активности Utopia Ecosystem
В этом "анализе" из наличия соединений вы делаете вывод о том что приложение пиринговое, а из того что не можете понять содержимого пакетов - о том что используется асимметричное (не асинхронное:) ) шифрование. Мало того что эти предположения, даже будь они доказанными, бесполезны, так они и не доказаны - приложение могло лить с кучи нод на вашу машину ЦП cleartext'ом, или заливать на кучу нод ваши пароли от банков и кошельков с xor шифрованием, или делать что угодно создавая соедениния со случайным мусором, выводы были теми же. Чтобы только проверить наличие заявленной функциональности, нужно разобраться в нескольких мегабайтах дизассемблерных листингов и дешифровать трафик, я не говорю даже о том чтобы проверить наличие недокументированных возможностей. В случае же исходников же достаточно было бы просто в них посмотреть.
> Данным материалом хочу высказать ИМХО: возводить open source в абсолют, как и ругать закрытые исходники, глупо.
Напротив.
FYI, существуют пакетные инфраструктуры предоставляющие несколько версий питона, в том числе одновременно. Например, порты FreeBSD. С ними мне ни разу в жизни не приходилось запускать pip или venv.
Режет глаз упоминание терминов “на стеке" и "в куче". Они относятся к регионам памяти, которые можно использовать произвольно - можно, например, выделить через new vector с кастомным аллокатором над куском стека, тогда вектор будет в куче, а элементы на стеке. А может быть всё в статической памяти. Поэтому лучше бы использовать термины вроде "непосредственно в объекте контейнера" и "аллоцируется отдельно".
Неплохая демонстрация, но недостаточно исследована тема защиты от этой атаки, и нагнано желтизны. Есть, например, проект gnu mes, который позволяет бутстрапнуть систему с нуля из исходников, вообще не прибегая к недоверенным бинарникам. А чтобы обнаружить evil цепочку в открытой экосистеме, например дебиана, достаточно одной проверки.
Вы изобрели пакетные репозитории. Под windows таковые тоже есть, например chocolatey и appget.
А где бенчмарки-то?