библиотечный код должен лежать в .a и .so файлах, а не статически inplace копироваться каждый раз по месту, раздувая результирующие бинарники до 100+ мегабайт
идите в Rust
Да, главное правильно выбрать направление куда идти.
Если распределение достаточно широкое, чтобы было расхождение в 15 раз между краями, то хвост в 17% может быть достаточно отдален от середины, по-этому в разнице в 12 раз от медианой зарплаты нет ничего удивительного. Если вам не хватает интеллекта или образования чтобы понять настолько тривиальные вещи из текста, то попробуйте нарисовать картинку, это хороший метод, прекрасно работает для детей.
допустим разница будет в три-четыре раза со средними числами, но не в 17 же
Согласно даже офстатистке соотношение между средними уровнями денежных доходов 10% населения с самыми высокими доходами и 10% населения с самыми низкими составляет примерно 15. Медианная зарплата в РФ - 40к, доход в 500к это всего в 12 раз больше(а не в 17). Узкая группа специалистов вполне может иметь такой уровень дохода и даже кратно выше, например зарплата пилотов в авиации имеет такие же значения. "Странно, что всё это приходится разжёвывать"(с)
Ну вот у вас есть приложение А, которое зависит от библиотеки Β(не вашей), которая зависит от библиотеки C через некий пакетный менеджер. Вот вы делаете форк для C - сколько поднадобиться технических усилий(и бюрократических если мы говорим о реальном бизнесе) чтобы все это собирать, разворачивать и поддерживать?
Погромист может вызвать, к примеру, yaml.load() - ведь, казалось бы, какое по своей семантике этот вызов может иметь отношение к исполнению кода, ага? - и получить тот же самый CWE-94 как с куста.
Проблема выполнения кода при десериализации/динамического исполнения не специфична для питона и в целом для скриптовых языков. Можно вспомнить, к примеру, Log4Shell, который стал огромной проблемой для java приложений. Значит ли эточто Java "с точки зрения безопасТности едва ли лучше, чем C/C++"? Рынок разработки программного обеспечения уже давно ответил на этот вопрос.
очень жаль, что вам все еще ничего не понятно, но я это как-нибудь переживу.
Если вы не можете логически аргументировать собственную позицию, то зачем начали дисскусию? Но хорошо, "слив засчитан"(с)
должны понимать, как это работает, голову никогда отключать нельзя.
Агрумент "люди должны понимать" ложный по своей сути, потому что для любой задачи можно сказать "люди просто не должны совершать ошибок". Это пафосные слова, которые не имеют никакой практической пользы и не решают никакой проблемы. К примеру, так можно дойти до того, что смартпоинтеры не нужны, зачем тратить ресурсы на счетчик, если можно просто "включить голову"(с) и вовремя вызывать free(). Опять же, все еще не понятно, как из ваших рассуждений следует, что наличие определенных частных кейсов уязвимостей типа вызова eval в скриптовых языка оправдывает проблемы контроля памяти в C/C++ и почему исходя из этого эти языки одинаковы с точки зрения безопастности использования.
Вы подменяете один класс ошибок другим. Eval по определению это функция выполнения произвольного кода, она в явном виде говорит программисту о том, что здесь в приложении есть возможность запустить код из внешнего источника. И дальше уже за разработчиком остается принятие решения о том использовать эту функцию или нет. В тоже время условный memcpy по своей семантике никакого отношения к исполнению кода не имеет и по-этому отслеживание связанных с ней уязвимостей требует больших усилий и квалификации.
Падение есть падение, причина почему оно упало не так важна. Когда приложение поработало и упало с null pointer reference, это как-то принципиально лучше, чем когда оно же падает с ошибкой синтаксиса? Конечно нет. Речь о том, что ошибка, при которой приложение падает, это на порядок меньшая проблема, чем уязвимость в безопастности, из-за которой атакующий может получить несанкционированный доступ к данным или запустить вредоносный код и именно об этом идет речь в рекомендации ONCD. И именно по-этому даже скриптовый язык типа Python это более предпочтительный выбор чем С/С++ если речь идет о безопастности.
Это должно само по себе наталкивать на мысль что что-то идет не так и возможно надо найти либо другое решение либо использовать тут не Rust, а язык с GC
Чем это лучше GraphQL?
Причем тут санкции и криптобиржи?
Все это кто?
Да, главное правильно выбрать направление куда идти.
Тьюринг тест был пройден примерно год назад
https://www.nature.com/articles/d41586-023-02361-7
Я согласен, если вы с двух раз не в состоянии понять написаное и просто продолжаете спорить с голосами в своей голове, то разговор стоит закончить.
Если распределение достаточно широкое, чтобы было расхождение в 15 раз между краями, то хвост в 17% может быть достаточно отдален от середины, по-этому в разнице в 12 раз от медианой зарплаты нет ничего удивительного. Если вам не хватает интеллекта или образования чтобы понять настолько тривиальные вещи из текста, то попробуйте нарисовать картинку, это хороший метод, прекрасно работает для детей.
Так сказано "составят прогноз погоды", про достоверность речи не шло.
А чего заодно прогноз курса доллара, биткоина и акций роснефти на полгода вперед не выдали? Почему так скромно, только погода?
допустим разница будет в три-четыре раза со средними числами, но не в 17 же
Согласно даже офстатистке соотношение между средними уровнями денежных доходов 10% населения с самыми высокими доходами и 10% населения с самыми низкими составляет примерно 15. Медианная зарплата в РФ - 40к, доход в 500к это всего в 12 раз больше(а не в 17). Узкая группа специалистов вполне может иметь такой уровень дохода и даже кратно выше, например зарплата пилотов в авиации имеет такие же значения. "Странно, что всё это приходится разжёвывать"(с)
огромное количество людей приходят буквально только ради того, чтобы иметь в резюме ссылку на гитхаб.
Ну вот у вас есть приложение А, которое зависит от библиотеки Β(не вашей), которая зависит от библиотеки C через некий пакетный менеджер. Вот вы делаете форк для C - сколько поднадобиться технических усилий(и бюрократических если мы говорим о реальном бизнесе) чтобы все это собирать, разворачивать и поддерживать?
Погромист может вызвать, к примеру, yaml.load() - ведь, казалось бы, какое по своей семантике этот вызов может иметь отношение к исполнению кода, ага? - и получить тот же самый CWE-94 как с куста.
Проблема выполнения кода при десериализации/динамического исполнения не специфична для питона и в целом для скриптовых языков. Можно вспомнить, к примеру, Log4Shell, который стал огромной проблемой для java приложений. Значит ли это что Java "с точки зрения безопасТности едва ли лучше, чем C/C++"? Рынок разработки программного обеспечения уже давно ответил на этот вопрос.
очень жаль, что вам все еще ничего не понятно, но я это как-нибудь переживу.
Если вы не можете логически аргументировать собственную позицию, то зачем начали дисскусию? Но хорошо, "слив засчитан"(с)
должны понимать, как это работает, голову никогда отключать нельзя.
Агрумент "люди должны понимать" ложный по своей сути, потому что для любой задачи можно сказать "люди просто не должны совершать ошибок". Это пафосные слова, которые не имеют никакой практической пользы и не решают никакой проблемы. К примеру, так можно дойти до того, что смартпоинтеры не нужны, зачем тратить ресурсы на счетчик, если можно просто "включить голову"(с) и вовремя вызывать
free().
Опять же, все еще не понятно, как из ваших рассуждений следует, что наличие определенных частных кейсов уязвимостей типа вызова eval в скриптовых языка оправдывает проблемы контроля памяти в C/C++ и почему исходя из этого эти языки одинаковы с точки зрения безопастности использования.Вы подменяете один класс ошибок другим. Eval по определению это функция выполнения произвольного кода, она в явном виде говорит программисту о том, что здесь в приложении есть возможность запустить код из внешнего источника. И дальше уже за разработчиком остается принятие решения о том использовать эту функцию или нет. В тоже время условный memcpy по своей семантике никакого отношения к исполнению кода не имеет и по-этому отслеживание связанных с ней уязвимостей требует больших усилий и квалификации.
Падение есть падение, причина почему оно упало не так важна. Когда приложение поработало и упало с null pointer reference, это как-то принципиально лучше, чем когда оно же падает с ошибкой синтаксиса? Конечно нет. Речь о том, что ошибка, при которой приложение падает, это на порядок меньшая проблема, чем уязвимость в безопастности, из-за которой атакующий может получить несанкционированный доступ к данным или запустить вредоносный код и именно об этом идет речь в рекомендации ONCD. И именно по-этому даже скриптовый язык типа Python это более предпочтительный выбор чем С/С++ если речь идет о безопастности.
Например?
Вы когда-нибудь пробовали сделать PR в крупный opens-source проект? Попробуйте, увидите как встретят вашу "инициативу".
Просто проблема не си-подобного синтаксиса.
Когда вы пишите
"
Vec<Rc<RefCell<dyn Observer>>>"
Это должно само по себе наталкивать на мысль что что-то идет не так и возможно надо найти либо другое решение либо использовать тут не Rust, а язык с GC