Некропостинг режим. В самом ядре реализован только механизм состояний портов + ядерная реализация основного стандарта STP (802.1d который). Более навороченные разновидности STP реализуются через user space helper демона - mstpd или какого-нибудь другого. Но тут была ещё одна сложность - MSTP долго не поддерживался ядром из-за архитектурных ограничений реализации ethernet bridge - он имеет поддержку состояния только на уровне всего порта, а для MSTP требуется поддержка состояния на уровне порт+влан. В версии 6.0+ это вроде как исправили, но в mstpd поддержку этого всего не завезли полноценно, когда я смотрел его последний раз.
Отвечаем: мы продемонстрировали суверенное программно-аппартаное решение, основанное на суверенной аппаратной платформе, построенной на отечественных процессорах, что гарантирует отсутствие закладок, «килл- переключателя» и т.д., а используемое ПО - модель DeepSeek-R1 относится к категории открытого ПО, веса можно проверить и даже дообучить на своих данных. Нет привязки к вендорам из недружественных стран.
Данное решение обеспечивает информационную безопасность компании, которая использует ИИ в своей деятельности - всё работает в изолированном контуре. Данные не уходят за пределы организации.
Слишком много раз повторяется слово "суверенное". Но как говорится: "Сколько раз не повторяй слово сахар, во рту слаще не станет".
В зависимости от того, какую асинхронность использовать (стекфул или стеклесс) будет так же: стекфул, естественно, будет требовать памяти гораздо больше.
Не сможет. Потому что это не так. В nftables правила так же остаются отдельными правилами (отдельными сущностями), организованными в линейные списки, только в этих правилах можно дополнительно проверять отдельные сопоставления по словарям/сетам/конкатенациям. Почти того же самого можно добиться при использовании iptables + ipset + multiport. Т.е. если у тебя в nftables 10к правил, то они в самом худшем случае пакет так же пройдёт через 10к проверок правил. Относительно недавно в nftables добавили автоматический оптимизатор, который позволяет слепливать правила, но работает он неидеально.
За счёт чего nftables чуть более продвинуто:
наличие словарей вердиктов, сетов и словарей, и конкатенаций (специальный вид словаря с составными ключами, позволяя проверять в нём несколько полей/свойств за один лукап)
flowtable - очень крутая фича, позволяющая значительно снизить нагрузку на ЦПУ за счёт того, что мы полный процесс обработки производим только для первого пакета соединения, а потом записываем все необходимые действия для потока, и последующие пакеты этого соединения уже берут действия сразу из таблицы потоков, а не прогоняются по всему набору правил.
хранение ruleset чуть более удобное - это всё так же большой набор данных, но уже более структурированный, чем xtables blob. Кстати, про атомарность в xtables - её можно достичь с использованием xtables-restore (загружает все правила отдельной таблицы атомарно).
Так же в iptables есть очень крутая штука - iptables-apply - типа commit confirm в juniper - если не подтвердить новые правила за таймаут, то правила откатятся на предыдущую версию.
Так же в nftables ещё достаточно часто встречаются баги и недоработки. В xtables с этим получше - код уже давно достаточно хорошо вылизан.
Довольно типичная для айтишников (как людей, в целом не обладающих развитым гуманитарным знанием) и неверная точка зрения.
В чём именно она неверная? Есть определённая должность в компании - ведущий разработчик aka senior. У него определённые обязанности, и передача опыта через говорение слов ртом в них не входит. Есть задача. Делаем её, документируем в базе знаний, чтобы всем было понятно. При этом пишем поддерживаемый и понятный код. Если кому-то что-то непонятно, то они задают вопросы в комментариях к документации, и там же получают ответы. Имхо, этого вполне хватает для качественной передачи знаний внутри компании.
Что значит "не делится знаниями"? Если процессы документирования налажены, то это не проблема. А каждому разжёвывать на синках, почему сделано так и иначе, и объяснять азы - ну за это надо отдельно доплачивать и это сугубо добровольно должно быть, потому что тут у нас не семинары для обмена опытом и не школа.
Для защиты от кражи сокетов необходимо настраивать серверные приложения в стандартный режим монопольного использования сетевых портов. На использование опций SO_REUSEPORT или SO_REUSEADDR для серверных сокетов следует наложить табу.
Многопоточные/многопроцессные приложения, которым это необходимо, при этом как себя поведут? Так же предлагаю вам дополнить статью конкретным примером, как это можно сделать :)
жёстко зашиты в коде (внутри функций / методов) / hardcoded
вынесены в константы модулей
константы намного лучше, чем «магическеские числа» и «магические строки» непосредственно в коде
полезно если константы меняются крайне редко, но всё же могут меняться
вынесены в отдельные конфиг‑файлы (файлы, используемые для хранения параметров и настроек приложений).
Я бы добавил ещё два метода конфигурирования - через переменные окружения и через аргументы командной строки. Ну и никто не запрещает использовать сразу несколько методов конфигурирования, которые "наслаиваются" друг на друга.
А вот зря не считаете это страшным. Это очень сильно фрустрирует - внедрение какой-то хурмы ради отсутствия застоя. Это время и усилия можно потратить с большей пользой.
Но раз мы уменьшили себя, то значит уменьшились и наши рецепторы и теперь мы не можем видеть волны, которые значительно больше нас самих. То есть мы перестанем видеть в обычном видимом свете, как видит человек стандартных размеров. Мы перестанем видеть большинство цветов, зато будем видеть рентгеновское излучение.
Мне такое рассуждение кажется немного сомнительным.
В командах есть добавление фильтра с действием зеркалирования трафика, но не учтено, что команды создания ingress очереди нет, а без неё и фильтр не будет создан.
Некропостинг режим. В самом ядре реализован только механизм состояний портов + ядерная реализация основного стандарта STP (802.1d который). Более навороченные разновидности STP реализуются через user space helper демона - mstpd или какого-нибудь другого. Но тут была ещё одна сложность - MSTP долго не поддерживался ядром из-за архитектурных ограничений реализации ethernet bridge - он имеет поддержку состояния только на уровне всего порта, а для MSTP требуется поддержка состояния на уровне порт+влан. В версии 6.0+ это вроде как исправили, но в mstpd поддержку этого всего не завезли полноценно, когда я смотрел его последний раз.
Слишком много раз повторяется слово "суверенное". Но как говорится: "Сколько раз не повторяй слово сахар, во рту слаще не станет".
В зависимости от того, какую асинхронность использовать (стекфул или стеклесс) будет так же: стекфул, естественно, будет требовать памяти гораздо больше.
Не сможет. Потому что это не так. В nftables правила так же остаются отдельными правилами (отдельными сущностями), организованными в линейные списки, только в этих правилах можно дополнительно проверять отдельные сопоставления по словарям/сетам/конкатенациям. Почти того же самого можно добиться при использовании iptables + ipset + multiport. Т.е. если у тебя в nftables 10к правил, то они в самом худшем случае пакет так же пройдёт через 10к проверок правил. Относительно недавно в nftables добавили автоматический оптимизатор, который позволяет слепливать правила, но работает он неидеально.
За счёт чего nftables чуть более продвинуто:
наличие словарей вердиктов, сетов и словарей, и конкатенаций (специальный вид словаря с составными ключами, позволяя проверять в нём несколько полей/свойств за один лукап)
flowtable - очень крутая фича, позволяющая значительно снизить нагрузку на ЦПУ за счёт того, что мы полный процесс обработки производим только для первого пакета соединения, а потом записываем все необходимые действия для потока, и последующие пакеты этого соединения уже берут действия сразу из таблицы потоков, а не прогоняются по всему набору правил.
хранение ruleset чуть более удобное - это всё так же большой набор данных, но уже более структурированный, чем xtables blob. Кстати, про атомарность в xtables - её можно достичь с использованием xtables-restore (загружает все правила отдельной таблицы атомарно).
Так же в iptables есть очень крутая штука - iptables-apply - типа commit confirm в juniper - если не подтвердить новые правила за таймаут, то правила откатятся на предыдущую версию.
Так же в nftables ещё достаточно часто встречаются баги и недоработки. В xtables с этим получше - код уже давно достаточно хорошо вылизан.
Если хочется самостоятельно покопаться в исходниках, то для nftables лучше начать вот отсюда - https://elixir.bootlin.com/linux/v7.0/source/net/netfilter/nf_tables_core.c#L250 , а для iptables с аналогичной функции вот отсюда - https://elixir.bootlin.com/linux/v7.0/source/net/ipv4/netfilter/ip_tables.c#L223
Ошибка при выборе инструмента.
Skill issues.
Вполне себе заменяет.
В чём именно она неверная? Есть определённая должность в компании - ведущий разработчик aka senior. У него определённые обязанности, и передача опыта через говорение слов ртом в них не входит. Есть задача. Делаем её, документируем в базе знаний, чтобы всем было понятно. При этом пишем поддерживаемый и понятный код. Если кому-то что-то непонятно, то они задают вопросы в комментариях к документации, и там же получают ответы. Имхо, этого вполне хватает для качественной передачи знаний внутри компании.
Тут уже другая проблема - человек пишет неподдерживаемый код (магия без комментариев и документации).
Что значит "не делится знаниями"? Если процессы документирования налажены, то это не проблема. А каждому разжёвывать на синках, почему сделано так и иначе, и объяснять азы - ну за это надо отдельно доплачивать и это сугубо добровольно должно быть, потому что тут у нас не семинары для обмена опытом и не школа.
Ну и всё-таки
GRE over IPSEC, а не наоборот.Многопоточные/многопроцессные приложения, которым это необходимо, при этом как себя поведут? Так же предлагаю вам дополнить статью конкретным примером, как это можно сделать :)
Я бы добавил ещё два метода конфигурирования - через переменные окружения и через аргументы командной строки. Ну и никто не запрещает использовать сразу несколько методов конфигурирования, которые "наслаиваются" друг на друга.
А вот зря не считаете это страшным. Это очень сильно фрустрирует - внедрение какой-то хурмы ради отсутствия застоя. Это время и усилия можно потратить с большей пользой.
О, ещё один SHITOps!
Но раз мы уменьшили себя, то значит уменьшились и наши рецепторы и теперь мы не можем видеть волны, которые значительно больше нас самих. То есть мы перестанем видеть в обычном видимом свете, как видит человек стандартных размеров. Мы перестанем видеть большинство цветов, зато будем видеть рентгеновское излучение.Мне такое рассуждение кажется немного сомнительным.
В командах есть добавление фильтра с действием зеркалирования трафика, но не учтено, что команды создания ingress очереди нет, а без неё и фильтр не будет создан.
А как вам такое мировоззрение - https://ru.wikipedia.org/wiki/Философский_пессимизм
А будет в обозримом будущем что-нибудь из свежей литературы по Rust? Например, второе издание The rust programming language.
Это разные программы. "Соло на клавиатуре" и сейчас живёт и здравствует. Переехало в вэб.
В openwrt используется своя система инициализации и управления сервисами - procd