-Wuninitialized, который включен в -Wall, не очень точен по нашим наблюдениям. Коллега предложил пример, где ворнинг не стреляет, а проблема присутствует https://godbolt.org/z/bY898jq98. Более детальные сведения, наверное, только из исходников gcc/clang получится извлечь. По общим соображениям warning-и (wuninitialized) процессят во фронт-енде, а кодогенерация (vars-autoinit) в мидл-енде/бэк-енде.
Переменных на стеке и в heap-е значительно больше, чем из сегмента .data и .bss. Ну и неинициализированные данные из .bss все инициализируются нулями (https://refspecs.linuxfoundation.org/LSB_1.1.0/gLSB/specialsections.html). А у компилятора Си есть опция vars-autoinit, которая зануляет и стековые переменные и данные из кучи, но это снижает производительность (и именно поэтому не включено по умолчанию. и именно поэтому Си в стандарте нет обязательного зануления)
Спасибо за развернутый комментарий. Попробую ответить также развернуто. (1) Статья не про безопасную ОС. Я много работала по процессам безопасной разработки и хотела поделиться опытом, как можно разрабатывать ПО, которое и включает все необходимые харденинги и при этом не будет терять в производительности. Сочувствую, если заголовок ввел вас в заблуждение. (2) Доверять данным можно только после проверки их подлинности и целостности, разделение на процессы не предполагает удаление криптографических проверок. Однако, если у вас есть процесс, которому дали права и на взаимодействие с сетевой картой, и на работу с базой платежей, то взлом такого процесса по сети будет более опасным сценарием, чем взлом процесса, который только принимает данные и парсит их. Да, данные в этот момент будут поддельными. Но arbitrary code execution в процессе с доступом к базе платежей не случится. Чтоб не быть голословной, у Bishop в computer security такой пример рассматривается. А еще это выполнение принципов конструктивной безопасности, которые есть и у нас в ГОСТ (ГОСТ Р 72118-2025), и в академической статье 75ого года (https://www.princeton.edu/~rblee/ELE572Papers/Fall04Readings/ProtectionInfo_Saltzer.pdf). (3) То, что в американских правительственных структурах рекомендуют использовать ПО, написанное на memory-safe языках, не должно означать, что мы сознательно против этого. В CWE-top (https://cwe.mitre.org/top25/archive/2024/2024_cwe_top25.html) постоянно фигурируют oob, а это как раз spatial memory safety. При этом, безусловно, MSL (memory-safe-languages) не панацея. И Google не спешит свои старые компоненты на Rust переписывать, и мы недавно долго решались как обезопасить парсинг ELF-а и все же оставили его на Си (https://habr.com/ru/companies/kaspersky/articles/906458/). Но MSL для некоторых задач и правда снижает число уязвимостей
Спасибо за правильный вопрос. Почитать про обработку прерываний в КОСи можно в документации - https://support.kaspersky.com/help/KCE/1.3/ru-RU/libkos_irq_api.htm. Вкратце, если сравнивать с Линуксом, то в КОСи вся обработка - это bottom half, но в выделенном real-time-овом потоке. При обработке запрещены все блокирующие вызовы. Доставка прерываний на тот же вектор на время обработки прерывания запрещена на уровне контроллера прерываний. Это конечно медленнее, но MSI уже на подходе.
В тех ИТ компаниях, где работала, тимлид был ближайший менеджер к разработчику. И его должностные обязанности перечисляла. Встречала компании, где в дополнение к тимлиду вводится HR-партнер, который призван вроде как мотивировать и решать конфликты, но даже план развития (на assessment-е), не говоря уж о 1:1, был далеко от HR-партнера. Так что не до конца поняла описанную конструкцию: если тимлид не до конца менеджер, то кто менеджер? unit manager который объединяет тимлидов и является следующим уровнем?
Вот согласна, что в архитекторах и лидах лучше. Тимлидом, по моим наблюдениям, становятся
из-за желания карьерного роста,
из-за отсутствия выделенных экспертных/архитекторских позиции (не все так прекрасны как ЛК),
из-за "кто если не я" (например, тимлид принимает неверные решения, не слушая команду, команда понемногу начинает разбегаться, убегает и тимлид. и вот вы понимаете кто_если_не_я спасет команду; или прекрасный тимлид идет на повышение, никто не хочет из команды быть тимлидом, но вы понимаете что кому-то прийдется стать и кто_если_не_я),
из-за желания попробовать новые управленческие практики (а мне кажется команда может стать бирюзовой; а если сделать прям нормальный scrum; всегда хотел попробовать lean, ...)
"Поэтому чтобы тимлид занимался тем, что может выполнить только он, другие менеджерские задачи, не связанные со спецификой деятельности его команды, должны отойти соответствующим ролям" - с такой конфигурацией я не сталкивалась. Чаще сталкивалась, когда технические решения уходят от тимлида архитектору или эксперту. Ваш вариант тоже прекрасен. Это реальная компания или идеальная?
Про погружение тимлида в архитектуру и дизайн. (1) если у тимлида 5 человек, то он тратит время на этих 5 человек: проревьювить Олю, разобраться с грустью у Пети, отрефлексировать предложение Васи, объяснить основы secure coding Жене, починить пайплайн Тимофею, (2) если у тимлида компонент, то он должен поговорить с суппортом про текущие проблемы, договориться о ресурсах инфраструктуры на тестирование, обсудить интеграционные тесты, сделать статусную презентацию по движению компонента. Это не очень много, но время занимает. И значит меньше времени, чтобы нарисовать flow в деталях, обновить информацию о принятых архитектурных решениях, сравнивать разные варианты реакции на событие по скорости, проверить отказоустойчивость компонента, выбрать из fail-open vs fail-close vs fail-safe vs fail-secure и последовательно продумать внедрение подхода.... и пр и пр. Тимлид чаще всего знает дизайн своего компонента (причем чаще всего потому, что его сам писал), но его не хватает чтобы развивать этот дизайн, потому что у него слишком много задач. Тимлид у нас чаще всего еще и техлид. Именно поэтому у нас столько непродуманностей в дизайне, именно поэтому у нас столько непочиненных процессов.
Мопед не мой. И статистика не моя. Можно зайти на Хабр карьеру, посмотреть их новую стату и задать им вопросы (регистрация бесплатна, но они хотят знать вашу зарплату).
В целом внутри тоже REST. Ибо внутренние разработчики — они тоже разработчики. HTTP проще отлаживать, проще кодить. Синхронное взаимодействие в целом легче понимать. Но, конечно, есть обстоятельства, когда гарантии доставки (от использования очередей) оказываются более значимыми чем удобство использования.
Есть сценарии, в которых используем очереди. Но это глубоко внутренние сценарии. С моей точки зрения, общение по REST проще в сопровождении и быстрее. Кроме того, простота REST для нас критична как для платформенного решения — представьте семинар по пользованию АПИ, где вы объясняете через POSTMAN collection, и семинар, где вы объясните асинхронную модель и работу с очередями. :) Если что-то для внешних пользователей можно упростить, то это всегда нужно упростить.
оба варианта, как мне кажется, имеют одинаковую сложность. Но в одном случае сложность имплементируется в коде, а во втором — в deployment схеме. Помните знаменитую картинку про микросверисы: сложность в коде vs сложность в связях?
Вы ранее назвали HTTP/gRpc стандартом общения микросервисов, а это значит что общение происходит синхронно(request/response), хотя для поддержания низкой связности всякие event-driven подходы считаются предпочтительнее.
В архитектуре, чисто философски, все компромисс. Иногда ведь и Вы, как архитектор, наверняка отказываетесь от более мощных решений (дающих лучшее масштабирование или производительность) в пользу более понятных решений (дающих более быстрый кодинг, ниже стоимость сопровождения). Cинхронное общение с одной стороны более понятное (простое с точки зрения отладки), с другой стороны более быстрое (все-таки проход через очередь дает много накладных расходов, хотя и добавляет гарантий). Поэтому, как мне кажется, в целом http/gRPC более широко используются чем общение через очереди. Ну и на http можно асинхронное имплементировать (202 и в путь).
Но я согласна с Вами, что event-driven подход имеет свои преимущества
Интересно было бы узнать, независимый ли у микросервисов цикл релизов друг от друга, и сколько сил/времени занимает координация релизов, она ведь всё-равно нужна иногда.
В Acronis сложная модель deploy-я в том смысле, что кроме облака, которым оперируем мы сами, есть еще on-premise deployment, когда наше облако разворачивают customer-ы для своих личных нужд. Поэтому модель «поправили (микро)сервис, залили в прод» у нас не применима. Мы выпускаем целостные релизы Acronis Cyber Cloud где фиксированы версии каждого сервиса
J2ee, кажется, ограничено Java-ой? А задачи Wamp-а не соответствуют задачам Kubernetes?
В общем, здесь можно идти в долгий философский диспут. Я далеко не фанат kubernetes, но, как Вы правильно сказали, стандарты побеждают в долгосрочной перспективе. А из нескольких альтернативных стандартов выживает не всегда самый лучший с технической точки зрения.
Совершенно согласна. Еще бы у всех пользователей новые arm-ы были. PAC появился в arm 8.3 :( Но стоило дописать, Вы правы.
-Wuninitialized, который включен в -Wall, не очень точен по нашим наблюдениям. Коллега предложил пример, где ворнинг не стреляет, а проблема присутствует https://godbolt.org/z/bY898jq98. Более детальные сведения, наверное, только из исходников gcc/clang получится извлечь. По общим соображениям warning-и (wuninitialized) процессят во фронт-енде, а кодогенерация (vars-autoinit) в мидл-енде/бэк-енде.
Не занулятся, вы правы. Спасибо за уточнение.
Переменных на стеке и в heap-е значительно больше, чем из сегмента .data и .bss. Ну и неинициализированные данные из .bss все инициализируются нулями (https://refspecs.linuxfoundation.org/LSB_1.1.0/gLSB/specialsections.html). А у компилятора Си есть опция vars-autoinit, которая зануляет и стековые переменные и данные из кучи, но это снижает производительность (и именно поэтому не включено по умолчанию. и именно поэтому Си в стандарте нет обязательного зануления)
Да, вы правы. Хорошая функциональность. Ее добавление будет рассмотрено в будущих релизах
Спасибо за развернутый комментарий. Попробую ответить также развернуто. (1) Статья не про безопасную ОС. Я много работала по процессам безопасной разработки и хотела поделиться опытом, как можно разрабатывать ПО, которое и включает все необходимые харденинги и при этом не будет терять в производительности. Сочувствую, если заголовок ввел вас в заблуждение. (2) Доверять данным можно только после проверки их подлинности и целостности, разделение на процессы не предполагает удаление криптографических проверок. Однако, если у вас есть процесс, которому дали права и на взаимодействие с сетевой картой, и на работу с базой платежей, то взлом такого процесса по сети будет более опасным сценарием, чем взлом процесса, который только принимает данные и парсит их. Да, данные в этот момент будут поддельными. Но arbitrary code execution в процессе с доступом к базе платежей не случится. Чтоб не быть голословной, у Bishop в computer security такой пример рассматривается. А еще это выполнение принципов конструктивной безопасности, которые есть и у нас в ГОСТ (ГОСТ Р 72118-2025), и в академической статье 75ого года (https://www.princeton.edu/~rblee/ELE572Papers/Fall04Readings/ProtectionInfo_Saltzer.pdf). (3) То, что в американских правительственных структурах рекомендуют использовать ПО, написанное на memory-safe языках, не должно означать, что мы сознательно против этого. В CWE-top (https://cwe.mitre.org/top25/archive/2024/2024_cwe_top25.html) постоянно фигурируют oob, а это как раз spatial memory safety. При этом, безусловно, MSL (memory-safe-languages) не панацея. И Google не спешит свои старые компоненты на Rust переписывать, и мы недавно долго решались как обезопасить парсинг ELF-а и все же оставили его на Си (https://habr.com/ru/companies/kaspersky/articles/906458/). Но MSL для некоторых задач и правда снижает число уязвимостей
Спасибо за правильный вопрос. Почитать про обработку прерываний в КОСи можно в документации - https://support.kaspersky.com/help/KCE/1.3/ru-RU/libkos_irq_api.htm. Вкратце, если сравнивать с Линуксом, то в КОСи вся обработка - это bottom half, но в выделенном real-time-овом потоке. При обработке запрещены все блокирующие вызовы. Доставка прерываний на тот же вектор на время обработки прерывания запрещена на уровне контроллера прерываний. Это конечно медленнее, но MSI уже на подходе.
В тех ИТ компаниях, где работала, тимлид был ближайший менеджер к разработчику. И его должностные обязанности перечисляла. Встречала компании, где в дополнение к тимлиду вводится HR-партнер, который призван вроде как мотивировать и решать конфликты, но даже план развития (на assessment-е), не говоря уж о 1:1, был далеко от HR-партнера. Так что не до конца поняла описанную конструкцию: если тимлид не до конца менеджер, то кто менеджер? unit manager который объединяет тимлидов и является следующим уровнем?
Ну часть историй отваливается все же. Область ответственности у младшего императора меньше чем у старшего. Иначе бы он был старшим.
Вот согласна, что в архитекторах и лидах лучше. Тимлидом, по моим наблюдениям, становятся
из-за желания карьерного роста,
из-за отсутствия выделенных экспертных/архитекторских позиции (не все так прекрасны как ЛК),
из-за "кто если не я" (например, тимлид принимает неверные решения, не слушая команду, команда понемногу начинает разбегаться, убегает и тимлид. и вот вы понимаете кто_если_не_я спасет команду; или прекрасный тимлид идет на повышение, никто не хочет из команды быть тимлидом, но вы понимаете что кому-то прийдется стать и кто_если_не_я),
из-за желания попробовать новые управленческие практики (а мне кажется команда может стать бирюзовой; а если сделать прям нормальный scrum; всегда хотел попробовать lean, ...)
"Поэтому чтобы тимлид занимался тем, что может выполнить только он, другие менеджерские задачи, не связанные со спецификой деятельности его команды, должны отойти соответствующим ролям" - с такой конфигурацией я не сталкивалась. Чаще сталкивалась, когда технические решения уходят от тимлида архитектору или эксперту. Ваш вариант тоже прекрасен. Это реальная компания или идеальная?
Про погружение тимлида в архитектуру и дизайн. (1) если у тимлида 5 человек, то он тратит время на этих 5 человек: проревьювить Олю, разобраться с грустью у Пети, отрефлексировать предложение Васи, объяснить основы secure coding Жене, починить пайплайн Тимофею, (2) если у тимлида компонент, то он должен поговорить с суппортом про текущие проблемы, договориться о ресурсах инфраструктуры на тестирование, обсудить интеграционные тесты, сделать статусную презентацию по движению компонента. Это не очень много, но время занимает. И значит меньше времени, чтобы нарисовать flow в деталях, обновить информацию о принятых архитектурных решениях, сравнивать разные варианты реакции на событие по скорости, проверить отказоустойчивость компонента, выбрать из fail-open vs fail-close vs fail-safe vs fail-secure и последовательно продумать внедрение подхода.... и пр и пр. Тимлид чаще всего знает дизайн своего компонента (причем чаще всего потому, что его сам писал), но его не хватает чтобы развивать этот дизайн, потому что у него слишком много задач. Тимлид у нас чаще всего еще и техлид. Именно поэтому у нас столько непродуманностей в дизайне, именно поэтому у нас столько непочиненных процессов.
Мопед не мой. И статистика не моя. Можно зайти на Хабр карьеру, посмотреть их новую стату и задать им вопросы (регистрация бесплатна, но они хотят знать вашу зарплату).
В архитектуре, чисто философски, все компромисс. Иногда ведь и Вы, как архитектор, наверняка отказываетесь от более мощных решений (дающих лучшее масштабирование или производительность) в пользу более понятных решений (дающих более быстрый кодинг, ниже стоимость сопровождения). Cинхронное общение с одной стороны более понятное (простое с точки зрения отладки), с другой стороны более быстрое (все-таки проход через очередь дает много накладных расходов, хотя и добавляет гарантий). Поэтому, как мне кажется, в целом http/gRPC более широко используются чем общение через очереди. Ну и на http можно асинхронное имплементировать (202 и в путь).
Но я согласна с Вами, что event-driven подход имеет свои преимущества
В Acronis сложная модель deploy-я в том смысле, что кроме облака, которым оперируем мы сами, есть еще on-premise deployment, когда наше облако разворачивают customer-ы для своих личных нужд. Поэтому модель «поправили (микро)сервис, залили в прод» у нас не применима. Мы выпускаем целостные релизы Acronis Cyber Cloud где фиксированы версии каждого сервиса
В общем, здесь можно идти в долгий философский диспут. Я далеко не фанат kubernetes, но, как Вы правильно сказали, стандарты побеждают в долгосрочной перспективе. А из нескольких альтернативных стандартов выживает не всегда самый лучший с технической точки зрения.