На фото всего лишь институт программных систем РАН в Переславле, проход на территорию там не контролируется, и я не думаю что там есть что-то секретное. Весной там, например, БазАльтовская конференция по свободному ПО проходила. А секретные суперкомпуцкеры, как в статье написано, по совсем другим адресам.
Я еще не совсем хорошо понимаю, как заливать куда-либо 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 цепочку в открытой экосистеме, например дебиана, достаточно одной проверки.
Вы используете асинхронный aiogram, но синхронные requests и psycopg2. На ваших нагрузках это скорее всего не заметно, но в общем случае так делать не стоит, потому что вы получаете по сути синхронное приложение выдающее очень низкий rps и блокирующее всё общение с пользователями на время долгого запроса в http или базу. Для асинхронной работы есть aiohttp и aiopg/asyncpg.
Практическая жизнеспособность позиции автора оценивается очень просто - появлением форка. Пока нет форка, описанная политика полностью соответствует заданной цели - отфильтровать паразитов, причём не в ущерб открытой разработке продукта. В этом смысле уверен что похожей политики в неявном виде придерживается большинство открытых проектов - откровенно мусорные или наглые issue закрываются без лишних комментариев или просто игнорируются.
В целом же позиция автора не соответствует духу F/OSS движения (в моём понимании, по крайней мере), который, грубо говоря, и заключается в решении чужих задач за свои средства ради общего блага, и как минимум подразумевает предоставление сообществу средств решать проблемы самостоятельно (тот же форум). Здесь же налицо конфликт интересов с коммерческой разработкой (что, кстати, подтверждает мою позицию о невозможности смешивания коммерции и F/OSS) и по итогу продукт который несёт пользователям риски характерные для проприетарного ПО.
Но в общем да, всё равно это выглядит как справедливый противовес растущему числу потребителей, пришедших к F/OSS и считающих что он *для них лично*.
>Для неизменяемых типов переменные с одинаковым значением будут иметь одинаковый адрес памяти
Не будут, хотя это и возможно в частных случаях.
>Изменяемые аргументы передаются по ссылкам, а неизменяемые – по значениям
Всегда по ссылкам. Ваши примеры не эквивалентны, поскольку some_arg.append() - изменение, `some_arg = some_arg + 1` - создание нового объекта и сохранение ссылки на него в переменную.
>При присваивании b значения a, переменная b всегда будет ссылаться на тот же адрес памяти, что и a.
Это всё что должно быть написано в этом пункте. От типа переменной a не зависит ничего. Кажется, вы не совсем разобрались в разнице между изменением объекта и созданием нового.
>Спор касался способа хранения в памяти списка (list).
Если все декомпозируют свою задачу, описанной проблемы вообще не возникает. Здесь же решается задача когда нужно влить 2 недели разработки кода, который в этом время значительно менялся другими людьми.
Ну как же, именно работать в отрыве от команды и предлагается, об этом явно написано:
> включить для себя, выключить для всех остальных > итеративно делать новую реализацию
и в конце
> выключить и удалить старую реализацию
Но старая реализация же активно разрабатывается, иначе откуда взяться конфликтам слияния, которых хотели избежать? Вот вся эта разработка и будет в последнем пункте разом silently потеряна. Так не обязательно было для этого новую технику придумывать, можно было просто влить feature ветку с -s recursive -X theirs.
Иначе другие разработчики должны были вносить изменения в обе ветки, но это точно не про "выключить для всех остальных", а скорее про "заставить остальных разработчиков коммитить все изменения в две ветки [кода] сразу (при том что одна из них недописана) и обе этих ветки тестировать". Во было бы интересно почитать как это было организовано, как контролировалось, как масштабировалось, и оправдало ли себя.
Делаете pull request, он висит несколько дней, после этого вы получаете approve и ... 15 конфликтов
Но ведь это замечательно, теперь вы знаете что код ещё кто-то менял и как именно, и имеете возможность обдуманно слить изменения. Предложенная техника в этом аспекте - способ проигнорировать и выкинуть чужую работу, которой может быть и критичное изменение бизнес-логики. А так-то слишком много слов для "написать независимую реализацию куска кода и заменить ей существующий".
Столько воды про очевидные, в общем, вещи, а главный вопрос - чем отличаются article и section, на который никто внятно ответить не может - опять не затронут.
На фото всего лишь институт программных систем РАН в Переславле, проход на территорию там не контролируется, и я не думаю что там есть что-то секретное. Весной там, например, БазАльтовская конференция по свободному ПО проходила. А секретные суперкомпуцкеры, как в статье написано, по совсем другим адресам.
Вместе с зависимостями никто проекты не заливает. Достаточно выложить на 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.
А где бенчмарки-то?
Вы используете асинхронный aiogram, но синхронные requests и psycopg2. На ваших нагрузках это скорее всего не заметно, но в общем случае так делать не стоит, потому что вы получаете по сути синхронное приложение выдающее очень низкий rps и блокирующее всё общение с пользователями на время долгого запроса в http или базу. Для асинхронной работы есть aiohttp и aiopg/asyncpg.
Практическая жизнеспособность позиции автора оценивается очень просто - появлением форка. Пока нет форка, описанная политика полностью соответствует заданной цели - отфильтровать паразитов, причём не в ущерб открытой разработке продукта. В этом смысле уверен что похожей политики в неявном виде придерживается большинство открытых проектов - откровенно мусорные или наглые issue закрываются без лишних комментариев или просто игнорируются.
В целом же позиция автора не соответствует духу F/OSS движения (в моём понимании, по крайней мере), который, грубо говоря, и заключается в решении чужих задач за свои средства ради общего блага, и как минимум подразумевает предоставление сообществу средств решать проблемы самостоятельно (тот же форум). Здесь же налицо конфликт интересов с коммерческой разработкой (что, кстати, подтверждает мою позицию о невозможности смешивания коммерции и F/OSS) и по итогу продукт который несёт пользователям риски характерные для проприетарного ПО.
Но в общем да, всё равно это выглядит как справедливый противовес растущему числу потребителей, пришедших к F/OSS и считающих что он *для них лично*.
>Для неизменяемых типов переменные с одинаковым значением будут иметь одинаковый адрес памяти
Не будут, хотя это и возможно в частных случаях.
>Изменяемые аргументы передаются по ссылкам, а неизменяемые – по значениям
Всегда по ссылкам. Ваши примеры не эквивалентны, поскольку
some_arg.append()- изменение, `some_arg = some_arg + 1` - создание нового объекта и сохранение ссылки на него в переменную.>Аннотации типов выполняются не в runtime.
Так всё-таки, когда?
>При присваивании
bзначенияa, переменнаяbвсегда будет ссылаться на тот же адрес памяти, что иa.Это всё что должно быть написано в этом пункте. От типа переменной
aне зависит ничего. Кажется, вы не совсем разобрались в разнице между изменением объекта и созданием нового.>Спор касался способа хранения в памяти списка (list).
Странно спорить об однозначно определённый вещах. Не так явно как могло быть, но всё же задокументированных https://docs.python.org/3.9/glossary.html#term-list
Если все декомпозируют свою задачу, описанной проблемы вообще не возникает. Здесь же решается задача когда нужно влить 2 недели разработки кода, который в этом время значительно менялся другими людьми.
Ну как же, именно работать в отрыве от команды и предлагается, об этом явно написано:
> включить для себя, выключить для всех остальных
> итеративно делать новую реализацию
и в конце
> выключить и удалить старую реализацию
Но старая реализация же активно разрабатывается, иначе откуда взяться конфликтам слияния, которых хотели избежать? Вот вся эта разработка и будет в последнем пункте разом silently потеряна. Так не обязательно было для этого новую технику придумывать, можно было просто влить feature ветку с
-s recursive -X theirs.Иначе другие разработчики должны были вносить изменения в обе ветки, но это точно не про "выключить для всех остальных", а скорее про "заставить остальных разработчиков коммитить все изменения в две ветки [кода] сразу (при том что одна из них недописана) и обе этих ветки тестировать". Во было бы интересно почитать как это было организовано, как контролировалось, как масштабировалось, и оправдало ли себя.
Но ведь это замечательно, теперь вы знаете что код ещё кто-то менял и как именно, и имеете возможность обдуманно слить изменения. Предложенная техника в этом аспекте - способ проигнорировать и выкинуть чужую работу, которой может быть и критичное изменение бизнес-логики. А так-то слишком много слов для "написать независимую реализацию куска кода и заменить ей существующий".
Столько воды про очевидные, в общем, вещи, а главный вопрос - чем отличаются article и section, на который никто внятно ответить не может - опять не затронут.