Kurgan-Telecom Ru | Информационные технологии

Go показывает стабильную память, heap-профиль молчит, а Kubernetes всё равно убивает под по OOM. Разберём, откуда берётся это расхождение, как на поведение под лимитами влияют cgroup, GOMAXPROCS и GOMEMLIMIT и что изменилось в последних версиях Go.

Одна и та же операция — дедупликация списка типов — написана двумя способами: на шаблонах и на статической рефлексии из C++26. Обе реализации живут в одном дереве и проверены на идентичность результата, поэтому их можно честно вычесть друг из друга. Получилось так: шаблонная версия съедает 7,9 ГиБ памяти компилятора там, где рефлексивная не съедает ничего измеримого — ±21 МиБ на 32-кратном диапазоне размеров. А по времени обе квадратичны, и рефлексия выигрывает всего пятую часть. Разбираю, откуда берётся такая асимметрия, и заодно пять компиляторных стен, в которые упираешься по дороге, — включая sizeof…, который молча возвращает неверное число.

Hacker News — это пульс мирового технологического сообщества. Тысячи разработчиков, основателей стартапов, инженеров из крупных компаний ежедневно делятся здесь инсайтами, проектами, новостями и мемами. Но есть проблема: качественный контент тонет в шуме, или интересные тебе темы тонут в неинтересных тебе темах.

Но из-за большого потока постов, качественные статьи по нужной теме теряются среди других, и если нужно найти какие-то системные тренды, увидеть как меняется отношения к Rust, AI или Open Source, а не просто “почитать что-то интересное” - это сделать сложно. Можно да, скопировать кучу ссылок и отправить в LLM, попросив отсортировать, но это занимает время и не так удобно, если нужно проанализировать большое количество тем.

И тут мне пришла идея - создать программу на Python, которая будет парсить через официальный API Hacker News, строить эмбеддинги постов с комментариями, кластеризовать посты и при помощи LLM суммаризировать этот кластер по ссылкам.

Сказано - сделано. Я смог спарсить 100 000 постов с Hacker News за последние 693 дня, получив более 1000 кластеров, более 10 миллиона апвоутов, более 27 тысячи авторов и всего 0.1% выбросов. В этой статье мы разберем, какие тренды были активны в мировом IT-сообществе последние два года.

В первой части «Единой науки» мною было дано краткое философское вступление в тему предстоящей работы над математически‑философским аппаратом «теории всего». Во второй части мы поразмышляем о том, как именно этот универсальный аппарат должен выглядеть.

С древних времён в любом учении о мироустройстве философы пытались ответить на основной вопрос онтологии — «Что существует?». Материализм утверждает, что реальна лишь материя, а всё существующее — это просто разные её формы. Платонизм отдаёт право существования только бесплотным идеям, а материальные формы считает их тенями. Другие формы идеализма признают реально существующим только сознание, а всё остальное считают разными его проявлениями. Буддизм утверждает, что мир иллюзорен, и высказывания о том, существует он или нет, не имеют смысла. В любом из философских учений основной вопрос онтологии «Что существует?» упирается в мета‑вопрос онтологии «Что вообще значит существовать?», вокруг которого ведутся ожесточённые споры.

Можем ли мы сказать, что красный цвет существует? С одной стороны, цвета и другие ощущения — это самое реальное, что только может быть, ведь именно с их помощью мы познаём мир. С другой стороны, цвет невозможно описать математически — цвет не эквивалентен ни длине волны света, ни определённому месту на сетчатке нашего глаза, ни определённым нейронам в нашем мозгу: все перечисленные вещи соответствуют какому‑то цвету, но не эквивалентны ему. Как говорят аналитические философы, корреляция есть, каузации нет. Да и словами цвет описать невозможно — слепому от рождения человеку мы чувство красного никак описать не сможем. Существует ли красный? Да чёрт его знает. Может быть, буддисты и ранний Витгенштейн правы, и высказывания о том, существует красный цвет или нет, вообще не имеют смысла. А существует ли внешний по отношению к нашему сознанию объективный мир? Этого мы тоже с уверенностью сказать не можем.

Как бы там ни было, для наших целей это абсолютно неважно. Мы будем основывать наши рассуждения на плоской объектно‑ориентированной онтологии Грэма Хармана, в которой каждая вещь рассматривается как объект. Красный цвет, овца, теория относительности, книга «Капитал» Маркса как бесплотная идея, физический экземпляр этой книги, человеческое имя, род Homo Sapiens в теории эволюции, конкретный живой человек этого вида, живший когда‑то человек этого вида, дождевой червь, государство, вирус гриппа, французский язык, чувство трепета, стихотворение Пушкина, галактика Млечный Путь, персонаж Винни‑Пух из советского мультика — всё это объекты, обладающие какими‑то свойствами и вступающие друг с другом в какие‑то отношения. Мы принимаем все объекты за одинаково реальные, все они равноправны — именно поэтому мы называем такую онтологию плоской.

Есть у меня товарищ. Работает в банке. Не в том банке, где три бухгалтера, директор и сервер под столом, который нельзя выключать, потому что никто не помнит пароль. А в большом, серьёзном банке, где есть закрытые контуры, службы информационной безопасности, согласования, регламенты, сертификаты, ещё согласования и, подозреваю, специальные люди, согласовывающие согласования.

И мы с ним периодически спорим об AI.

Я утверждаю довольно неприятную для программистов вещь: через два года практически весь прикладной код в мире, кроме действительно секретных областей, будет писать AI.

Не обязательно самостоятельно. Не обязательно без человека. Но писать руками очередной CRUD, форму авторизации, API-клиент, миграцию базы или сотый обработчик JSON будет примерно так же естественно, как сегодня вручную считать CRC32 на бумажке.

ИМПОРТОЗАМЕЩЕЕЕЕЕЕНИЕ!!!!!

Зимой я разбил две машины с интервалом в пару недель. Никто не пострадал, кроме моего кошелька — и в результате этого курьёзного случая мне очень понадобились деньги.

В январе 2026 я вышел на рынок труда искать своего идеального работодателя. Все тестовые задания для SEO-специалиста одинаковы до банальности: провести аудит сайта, написать ТЗ, дать рекомендации. После первого же тестового я понял, что не готов сделать ещё сотню таких. И решил, что помощника проще написать, чем искать, учить, терпеть и оплачивать.

9 января 2026 появилась первая строка кода. Сегодня это Оракул — оркестратор ИИ-агентов: 465 коммитов, ~20 000 строк Python, четыре LLM-провайдера, планировщик, MCP-сервер и первые клиенты. Загрузка по основной работе никуда не делась, так что весь проект — это примерно 4 часа в день.

Ниже — не история успеха, а список из девяти требований, которые я предъявлял к помощнику, и того, во что каждое из них превратилось в коде. Вместе с багами, которые я на этом поймал.

Если вы отправляете десятки откликов и получаете в ответ тишину или автоотказ — вы не одиноки. Такова суровая реальность: резюме должно пройти фильтры и алгоритмы ранжирования, а потом еще за секунды заинтересовать рекрутера. Но мы в Далее закрываем в среднем по 10 вакансий каждый месяц, а значит — работу найти можно. 

Меня зовут Ника Варако, я HR-специалист в диджитал-продакшене Далее. В этой статье я расскажу, как хакнуть систему найма в 2026 году. Разберем ситуацию на рынке, способы подружиться с ИИ и мастхевы для резюме. Погнали.

Последние недели внимание индустрии приковано к X: 13 августа Илон Маск выложил в открытый доступ веса ранжирования алгоритма «For You» и запустил инструмент «Under the Hood», который прямо показывает пользователю, есть ли ограничения на видимость его постов и почему.

Пока все обсуждают честен ли Маск или это уловка, в Meta разворачивается гораздо более тихая, но потенциально более масштабная история. Которая не имеет своего пресс-релиза а разбросана по разным, вроде бы не сильно связанным между собой событиям, может быть поэтому и незаметная.

Какие события произошли за последнее время с Meta?

26 августа 2026 года Meta заключила мировое соглашение с 47 штатами США на сумму до $18 млрд, закрыв иск о том, что компания намеренно проектировала аддиктивные платформы для детей. Соглашение обязывает Meta ввести конкретные технические меры для пользователей младше 18: лимит времени (2 часа/день), ночной режим, усиленную верификацию возраста. Соглашение вроде как уже вступило в силу и утверждено судьей.

В соглашении есть очень любопытный пункт, из $18 млрд Meta гарантированно платит только $12.7 млрд - оставшиеся $5.3 млрд перечисляются штатам, только если TikTok и YouTube присоединятся к тем же ограничениям и заплатят сопоставимую сумму. И тут очень интересная логика, если конкуренты не присоединятся - Meta экономит $5.3 млрд, а конкуренты выглядят компаниями, отказавшимися защищать детей. Но если присоединятся - Meta вроде как теряет большие деньги, но зато забирает у конкурентов их преимущество показывать детям все подряд и забрать трафик.

Как заново начать разрабатывать известный продукт с длинной историей и большим количеством пользователей.

Новая команда разработки приступила к проекту в 2023 году. Перед нами стояла непростая задача: продолжить развитие зрелого продукта, сохранив накопленные за годы возможности, и одновременно сделать его современной платформой, готовой к новым требованиям пользователей и рынка.

В этой статье расскажем, как мы работали с исходным кодом CommuniGate Pro, какие задачи перед нами стояли, с какими трудностями столкнулись и как их решали.

Примерно полтора года назад мы в компании начали проводить еженедельные воркшопы по ИИ. Или, как мы сами их называем, ИИ-кружки. Сначала для разработчиков, а позже — для «чайников» не-разработчиков тоже. Как, зачем, и к чему это в итоге привело — в статье.

За много лет работы с MS SQL Server я много раз наблюдал одну и ту же последовательность событий.

Сервер под 1С устанавливается методом «далее — далее — готово». Полгода всё работает. Потом наступает пик, сезон продаж или закрытие года, и система встаёт. Отдел сопровождения ищет причину, находит десяток версий и ни одного ответа. Руководство нервничает. Решение рождается само собой, купить новый сервер, так как «этот уже не справляется».

Вопрос, который витает немым подтекстом, звучит просто. С чем именно он не справляется?

Вариантов проблем четыре, и справляться с ними надо по‑разному. Блокировки, неоптимальный код, дисковая подсистема, нехватка памяти или процессорных ядер. Новое железо помогает в последних двух случаях, да и то не всегда. Блокировки и медленный код переезжают на новый сервер в полном составе, и через следующие полгода история повторяется, уже с потраченным бюджетом.

Повторяется всё это не от нехватки знаний. Причина лежит уровнем выше и касается уже не людей, а того, как мы привыкли относиться к самому продукту.

Возьмите Oracle Exadata. Никому не придёт в голову привезти стойку, включить питание и пройти установку кнопкой «Далее». Конфигурацию считают под профиль нагрузки. Схему размещения данных согласовывают заранее. Приёмку и ввод в эксплуатацию закладывают отдельным этапом работ, с отдельными сроками и бюджетом, и зовут людей, которые это уже проходили. Никто при этом не спрашивает, к чему такие сложности, всем понятно, какого класса машина приехала.

Сразу оговорюсь: я из команды LibreDB Studio, и статья — про наши собственные грабли. LibreDB Studio — это self-hosted IDE для СУБД, работающая в браузере: один инстанс разворачивается рядом с базами, а не устанавливается на ноутбук каждого разработчика. Команда открывает URL — и почти сразу упирается в вопрос, который сожрал у нас не один спринт: как показать результат из четырнадцати принципиально разных движков в одной таблице и при этом не начать выдавать пользователю выдумки за реальные данные.

eBPF‑программы проходят статический анализ до загрузки в ядро Linux. Верификатор должен доказать, что программа не выходит за границы памяти, не работает с неверными указателями и не нарушает ограничений, без которых код нельзя безопасно выполнять в ядре. Но если прогнать один объект через разные верификаторы, картина меняется. Один анализатор принимает BPF‑объект, а другой считает его небезопасным и запрещает загрузку.

Именно так и вышло...

Статья для тех, кто исследует eBPF и статический анализ. Ошибку в программе мы искать не будем — её там нет. Нас интересует другое: почему два верификатора расходятся в выводах.

Наивная формула «веса + KV < VRAM» промахивается по двум причинам, и обе стоят денег. Первая: движок (vLLM, SGLang, TensorRT-LLM) резервирует почти всю память под свой пул ещё до того, как вы посчитали KV — поэтому ответ «сколько запросов влезет» всегда мимо, в сторону «влезет», а потом OOM под нагрузкой. Вторая, которую в уме не посчитать: на DeepSeek-V2-Lite обычная формула завышает KV в 7–11 раз, и промах уже в обратную сторону — зря откажетесь ставить модель.

Я прогнал топ VRAM-калькуляторов из выдачи Google, показал на скриншотах, где ломается каждый (даже лучший), сверил числа с живым vLLM на A100/H100 — расхождение ~1% — и собрал ridgepoint: калькулятор, который считает как движок, а не как учебник. Ставится локально (pip install ridgepoint), GPU не нужен.

Три часа ночи, воскресенье. «Пачка» уведомлений от системы мониторинга в почте и Telegram. Mission‑critical система «лежит», потому что истёк TLS‑сертификат, который упустили из вида и не включили в «эксельный» реестр.

Ситуация знакома? Тогда эта статья для вас. Разберём, почему вопросы управления цифровыми сертификатами резко обострились, какие классы решений есть на рынке, и почему «просто поставить cert‑manager» — это не всегда финал истории.

У нас в публичном облаке VK Cloud у каждого бакета Object Storage есть Bucket Access Policy. Это набор правил в формате JSON, который лежит на самом бакете и говорит, кому какие операции с какими объектами разрешены. Хранилище проверяет эти правила само на каждый запрос. Включается политика в личном кабинете и через S3 API, и я регулярно вижу проекты, где её не настраивали ни разу.

В статье разбираю состав бакет-политики, её отличия от AWS-руководства и что задавать областью действия ключа, а что политикой. Дальше три механизма проверки на endpoint и порядок между ними, перенос политики из AWS-руководства как есть с разбором, почему он не работает, и четыре итерации доводки (Resource, Principal, aws:SourceIp, явный Deny). Затем матрица из 16 запросов с ожидаемыми кодами и скрипт прогона, метрика доли отказов по Cloud Audit, регуляторика, чек-лист переноса между AWS S3, Ceph, MinIO и VK Object Storage.

Пригодится тем, кто держит прокси перед хранилищем и хочет перенести правила доступа в само хранилище, и специалистам по ИБ, которым нужно доказать разграничение доступа выгрузкой, а не скриншотом консоли. Для другого S3-совместимого хранилища применима основная часть: механика проверки и матрица тестов от платформы не зависят.

Привет, Хабр! На связи Сергей Бровкин, руководитель SOC в Рунити. Больше 15 лет я занимаюсь практической информационной безопасностью — расследованием атак, реагированием на инциденты и всем, что происходит вокруг доменов и инфраструктуры клиентов.

Одна из наиболее спорных тем в этой работе — abuse-запросы. Формально всё просто: поступает жалоба на фишинг, вредоносное ПО или взломанный ресурс — ее проверяют и принимают меры. На практике от качества самой жалобы зависит и результат, и скорость реакции.

По статистике за последние несколько лет, Руцентр, Рег.ру и R01 — все они входят в группу Рунити — получали в месяц около 4.5 тысяч abuse запросов от Компетентных организаций по зонам .ru и .рф через сервис Доменный патруль. И только 99% из них завершались блокировкой. Казалось бы, процент достаточно велик, но, учитывая количество поступающих обращений, цифра получается немаленькая. А если учесть, что статусом Компетентной организации до 1 сентября 2026 года обладали ключевые игроки рынка ИБ в стране (с перечнем можно ознакомиться на портале Доменного патруля), то каждый ресурс, на который готовилась жалоба, должен был быть тщательным образом проверен и соответствующее обращение должно было быть должным образом подготовлено и действительно содержать информацию о существенном нарушении со стороны наших клиентов.

Однако на практике мы видим, что даже с такими доверенными и проверенными многолетней практикой компаниями это не всегда так. А более 500 доменов, жалобы на которые были отклонены — это не просто цифра или злодеи. Это множество цифровых сервисов, которые могли быть заблокированы и прекратить работу по ложному обвинению.

Для посетителя выставка, как и театр, начинается с вешалки или, точнее говоря, музейного гардероба. Для создателей же — с основной идеи: какие мысли нужно донести до аудитории и какой опыт она должна получить. От этой задумки отталкивается вся последующая работа, включая подбор экспонатов, подготовку интерактивов и оформление экспозиции. 

Этот непростой и творческий процесс невозможен без дискуссий и концептуальных экспериментов. Даже такие, казалось бы, сугубо бытовые моменты, как освещение и вентиляция, порой требуют немалой фантазии и нестандартного мышления. Для посетителя всё это остается за кадром: он видит уже готовую экспозицию, но не знает, сколько решений стоит за тем, как она устроена. 

Совместную выставку Музея криптографии и Бастиона «Ключ к доверию. Безопасность в эпоху высоких технологий» готовили целый год. За это время первоначальная концепция проекта успела претерпеть ряд трансформаций, но главная задумка осталась неизменной. Вместо абстрактного рассуждения в духе «вот так правильно, а вот так опасно» выставка дает посетителю самому оказаться в различных ситуациях, сделать осознанный выбор в части кибербеза и посмотреть, к каким последствиям это приведет. 

К нам в блог заглянул научный куратор проекта Егор Ефремов. Он рассказал, как родилась и эволюционировала концепция выставки, как готовили проект и с какими сложностями сталкивались музейщики и безопасники. Не будем устраивать виртуальную экскурсию по залам — здесь лучше один раз посетить, чем сто раз прочитать. Вместо этого заглянем в закулисье проекта и посмотрим на выставку изнутри вместе с человеком, который координировал весь процесс. 

Привет, Хабр.

Я переживаю, когда вижу плохие интерфейсы. Мне не нравится, когда пользователю сложно или неудобно. У меня очень сильно подгорает от этого.

Вместо обычного ворчания я делюсь мыслями о том, как исправить ситуацию. Больше всего мне нравится показывать, что HTML и CSS могут помочь в этой задаче.

Я сделал такой выбор, потому что решения на основе этих технологий легко начать использовать или добавить в существующий проект. Даже не имеет значения, какой фреймворк используется.

Вот давайте проверим это. Сегодня расскажу о нескольких подходах, а вы скажите, насколько просто их использовать. Я буду ждать вас в комментариях.

А теперь давайте посмотрим, что я вам подготовил.

18 августа 2026 года исследователи Hunt.io опубликовали разбор Operation CameraSwarm. За 35 дней один оператор получил доступ более чем к 14 500 камерам Dahua. 

Источник здесь необычно подробный: исследователи нашли открытый HTTP-каталог самого оператора и забрали 2 616 файлов общим объёмом 407 МБ: исходники, журналы запусков, результаты сканирования и служебные скрипты. Затем находки сверили с собственной сетевой телеметрией.

Здесь не было какой-то одной волшебной уязвимости, которая открывала доступ ко всем 14 500 камерам. В одной кампании сошлись старые пароли, непропатченные прошивки и служебная P2P-инфраструктура. Каждый из этих рисков по отдельности известен уже давно. Но когда они собираются вместе…это превращается в конвейер.