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

Пример - catwire, кастомная виртуальная сеть на Go.

В этом кейсе через неё пробрасывают обычный VLESS без дополнительной маскировки и шифрования на стороне самого VLESS.

Фокус в том, что снаружи виден уже не прикладной протокол, а транспорт виртуальной сети.

Получается простой паттерн:

* VLESS живёт внутри приватного слоя
* внешний трафик идёт через catwire
* туннель берёт на себя сетевую обвязку
* блокировать сам прикладной протокол становится сложнее

Это хороший пример того, что устойчивость часто строится не вокруг одного «волшебного протокола», а вокруг правильной архитектуры: виртуальная сеть сверху, нужные сервисы внутри.

https://github.com/nktauserum/catwire

🔌 k8s-d2 - быстрый способ превратить Kubernetes-кластер в понятную схему

Когда кластер растёт, kubectl get pods уже не помогает понять архитектуру. Видно ресурсы, но не видно систему.

k8s-d2 решает это через диаграммы как код. Инструмент читает топологию Kubernetes-кластера и генерирует D2-файлы: пространства имён, workloads, сервисы, ingress и связи между ними.

Удобно для ревью архитектуры, онбординга, документации и поиска странных зависимостей в кластере.

Особенно полезно в командах, где Kubernetes уже живёт давно, а актуальная схема существует только в голове одного DevOps-а, который “сейчас в отпуске, но вроде всё помнит”.

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

https://github.com/vieitesss/k8s-d2

Кто-то разобрал Claude Code почти до винтика

learn-coding-agent - репозиторий для тех, кто хочет понять, как устроены современные coding agents не на уровне промо-страниц, а на уровне архитектуры.

Автор собрал разбор Claude Code по публичным источникам: цикл агента, систему инструментов, разрешения, работу с контекстом, сессии, подпроцессы, MCP, удалённые настройки, телеметрию и скрытые флаги.

Получился не “гайд по использованию”, а карта внутренней логики CLI-агента: как он принимает решение, когда просит разрешение, как вызывает инструменты, как хранит историю и как расширяется через внешние интеграции.

https://github.com/justxor/Claudecourse/

Anthropic открыла reference harness для поиска уязвимостей с Claude

Anthropic выложила open-source пример того, как можно строить пайплайн для поиска и исправления уязвимостей с помощью Claude. Репозиторий называется Defending Code Reference Harness и уже собрал около 6.5K звёзд на GitHub.

Внутри — Claude Code skills для полного security-цикла:

* /threat-model
* /vuln-scan
* /triage
* /patch
* /customize

Сначала модель помогает построить threat model, потом сканирует код, помогает отфильтровать находки, ранжирует риски и предлагает патчи.

Отдельно есть автономный harness: он проходит путь recon → find → verify → report → patch и в референсной версии заточен под поиск memory-багов в C/C++ через Docker и ASAN.

GitHub: https://github.com/anthropics/defending-code-reference-harness

🔥 Хочешь быстрее расти в IT? Хватит учиться в одиночку

В IT прокачивается тот, кто каждый день видит сильные идеи, новые инструменты, реальные задачи, вакансии и разборы.

Окружение решает больше, чем кажется.

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

AI: t.iss.one/ai_machinelearning_big_data
Python: t.iss.one/pythonl
Linux: t.iss.one/linuxacademiya
Хакинг: t.iss.one/linuxkalii
DevOps: t.iss.one/DevOPSitsec
Docker: t.iss.one/DevopsDocker
Golang: t.iss.one/Golang_google
Rust: t.iss.one/rust_code
C++: t.iss.one/cpluspluc
C#: t.iss.one/csharp_1001_notes
Java: t.iss.one/java_library
JavaScript: t.iss.one/javascriptv
React: t.iss.one/react_tg
Frontend: t.iss.one/front
PHP: t.iss.one/phpshka
Android: t.iss.one/android_its
Мобильная разработка: t.iss.one/mobdevelop
Базы данных: t.iss.one/sqlhub
Data Science: t.iss.one/data_analysis_ml
Big Data: t.iss.one/bigdatai
Математика: t.iss.one/data_math
Физика: t.iss.one/fizmat
Kubernetes: t.iss.one/kubernetc
GameDev: https://t.iss.one/gamedev
Haskell: t.iss.one/haskell_tg

Собеседования и карьера:

DS собеседования: t.iss.one/machinelearning_interview
Python собеседования: t.iss.one/python_job_interview

Папка с вакансиями: t.iss.one/addlist/_zyy_jQ_QUsyM2Vi
Папка Go разработчика: t.iss.one/addlist/MUtJEeJSxeY2YTFi
Папка Python разработчика: t.iss.one/addlist/eEPya-HF6mkxMGIy
Папка ML: https://t.iss.one/addlist/2Ls-snqEeytkMDgy
Папка Frontend: https://t.iss.one/addlist/mzMMG3RPZhY2M2Iy

Полезное сверху:

ИТ-мемы: t.iss.one/memes_prog
Английский для программистов: t.iss.one/english_forprogrammers
ИИ и технологии: t.iss.one/vistehno
954 ГБ open-source курсов: @courses
ИТ-книги бесплатно: https://t.iss.one/addlist/BkskQciUW_FhNjEy

Max Ai: https://max.ru/ai_machinelearning_big_data
Max python: https://max.ru/pythonl
ТЕХНО: https://max.ru/vistehno
Max Go: https://max.ru/Golang_google
Max Linux: https://max.ru/linuxkalii
Devops: https://max.ru/DevOPSitsec
C#: https://max.ru/csharp_ci
C++: https://max.ru/cpluspluc
SQL: https://max.ru/sqlhub
Java: https://max.ru/javatg

Подписывайся на нужные направления и собирай себе ленту, которая реально двигает вперёд.

Пока кто-то листает шум, ты будешь видеть инструменты, задачи и идеи, которые помогают расти в профессии.

MinLZ научился искать внутри сжатых данных без полного распаковывания

В релизе MinLZ v1.2.0 появилась очень полезная фича: поиск byte sequences прямо по сжатому потоку. Обычно, чтобы найти строку в архиве или логе, нужно сначала распаковать всё. MinLZ делает иначе: добавляет небольшой search index по блокам и распаковывает только те блоки, где совпадение вообще возможно.

Как это работает:

* каждый блок получает маленькую bloom-filter таблицу
* при поиске MinLZ быстро проверяет, может ли паттерн быть в блоке
* если точно не может — блок пропускается
* если может — только тогда блок декодируется и сканируется

Индекс можно встроить при сжатии или собрать потом как sidecar-файл, не трогая исходные сжатые данные. Старые MinLZ-ридеры такие chunks просто игнорируют, так что совместимость сохраняется.

Самый красивый пример из релиза: поиск строки в 10 GB CockroachDB log, сжатом до 578 MB, занял 0.14 секунды через mz search. Обычный путь через decompression + grep занимал около 5 секунд, а lz4 -dc | grep — около 10 секунд.

Но это не магия для всего подряд.

MinLZ особенно хорош, когда нужно искать редкие literal byte strings: ID, error codes, request paths, hostnames, JSON keys, hashes. Для regex, fuzzy search, case-insensitive поиска или очень частых паттернов выигрыш может исчезнуть.

Доступно как CLI и как Go API.

GitHub: https://github.com/minio/minlz/releases/tag/v1.2.0

В Go всего 18 встроенных функций — и половину из них многие почти не трогают

С Go 1.21 их стало 18: добавились min, max и clear.

Чаще всего в реальном коде крутятся старые рабочие лошадки:

* make
* append
* len
* cap
* copy
* delete
* close

complex, real, imag нужны далеко не всем.
print и println вообще лучше не тащить в нормальный код — для этого есть fmt, log и нормальные инструменты отладки.

Самое интересное, что Go держит язык маленьким: встроенных функций мало, но почти каждая решает конкретную базовую задачу.

А какие built-in функции вы реально используете чаще всего?

Каждый год в середине лета мы с друзьями собираемся на E-CODE. Ещё относительно молодая конфа Ozon Tech стала уже своего рода легендой. Не удивительно: хардовость официальной части здесь не уступает громкости афтерпати.

На E-CODE 2026 нас по части бэкэнда ждут:

• Runtime Async с его + и –
• трассировка с eBPF
• ускорение на SIMD
• построение кастомной real-time системы видеоаналитики
• сравнительный анализ алгоритмов сборки мусора

Фишка этого года — брейнринг разработчиков и ИИ. Эксперты разберут сложные кейсы и сравнят свои подходы с тем, что предложит машина. Победителя выберет зал.

Регистрируйтесь сейчас, чтобы услышать это всё вживую: https://ecode.ozon.tech/

12 и 13 сентября, Москва. До встречи на E-CODE!

https://github.com/inspektor-gadget/inspektor-gadget## Inspektor Gadget: eBPF для отладки Kubernetes и Linux

Inspektor Gadget — open-source набор инструментов для диагностики через eBPF.

Умеет:

- отслеживать процессы, файлы, сеть и syscalls;
- связывать kernel-события с pod и контейнерами;
- работать через kubectl gadget и CLI ig;
- запускать eBPF-гаджеты из OCI images;
- экспортировать данные в observability-системы.

Пример:

kubectl gadget run trace_open:latest

Покажет, какие файлы открывают процессы внутри кластера.

Полезно для SRE и Kubernetes-инженеров, когда логов и метрик уже недостаточно и нужно посмотреть, что происходит прямо на уровне ядра Linux.

https://github.com/inspektor-gadget/inspektor-gadget

IRIS - open-source автодополнение на Go, которое рисует меню подсказок прямо внутри TTY.

Инструмент индексирует историю команд и aliases, после чего предлагает подходящие команды в реальном времени. Работает на Linux и macOS, включая SSH, Tmux и обычные виртуальные терминалы.

Внутри - один нативный Go-бинарник:

https://github.com/versenilvis/iris

Go-приём: как не получить 99% после округления

При независимом округлении процентов итоговая сумма может перестать быть равной 100.

33.3 → 33
33.3 → 33
33.4 → 33

Итого: 99%

Для простого интерфейса можно округлить первые значения, а последнему передать остаток:

package main

import "math"

func balancePercentages(values []float64) []int {
 if len(values) == 0 {
  return nil
 }

 result := make([]int, len(values))
 used := 0

 for i := 0; i < len(values)-1; i++ {
  result[i] = int(math.Round(values[i]))
  used += result[i]
 }

 result[len(values)-1] = 100 - used

 return result
}

Результат:

[]int{33, 33, 34}

Сумма останется равной 100.

Но это быстрый приём, а не универсальный алгоритм:

- значения должны быть заранее нормализованы;
- вся погрешность достаётся последнему элементу;
- результат зависит от порядка;
- при некорректных данных последнее значение может стать отрицательным.

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

Код актуален для современной Go 1.26 и работает без изменений. Функция math.Round доступна начиная с Go 1.10.

⚡️ Одна из недооценённых сильных сторон Go - криптография в стандартной библиотеке.

Хороший пример - SHA-256.

Снаружи разработчик видит обычный crypto/sha256, но внутри Go умеет выбирать оптимальную реализацию под конкретный CPU.

На arm64 логика примерно такая:

if useSHA2 {
    blockSHA2(dig, p)
} else {
    blockGeneric(dig, p)
}

Если процессор поддерживает SHA-2 instructions - используется платформенно-оптимизированный код. Если нет - generic fallback.

В этом и сила стандартной библиотеки Go: простой API скрывает CPU feature detection, assembly и архитектурные оптимизации.

sha256.Sum256(data) выглядит простенько.

Но под капотом там очень серьёзная инженерия.

🐳 Docker полностью переписала слой виртуализации Docker Desktop

Новый Docker VMM вышел в public beta для macOS и Windows начиная с Docker Desktop 4.86. Раньше Desktop полагался на сторонний VMM, теперь Docker контролирует весь стек и может оптимизировать его именно под контейнерные нагрузки.

Что обещают на практике: более быстрый запуск контейнеров, заметно ускоренный file I/O между host и контейнером, возврат неиспользуемой RAM системе и более стабильную работу на Windows.

На Windows Docker отдельно заявляет сочетание изоляции уровня Hyper-V со скоростью, близкой к WSL2. Тот же движок уже используется в Docker Sandboxes, а дальше компания хочет построить единый runtime для ноутбуков, облака, on-prem и AI-агентов.

GA планируется на конец октября 2026 года, после чего Docker VMM должен стать движком по умолчанию для новых установок Docker Desktop на Mac, Windows и Linux.

https://www.docker.com/blog/docker-vmm-public-beta/

🧠 Алгоритм Флойда знают многие Go-разработчики: два указателя двигаются с разной скоростью и находят цикл в связном списке за `O(n)` времени и `O(1)` памяти.

Но есть менее известный алгоритм Брента, который решает ту же задачу и часто делает меньше переходов по Next.

Флойд:

slow := head
fast := head

for fast != nil && fast.Next != nil {
    slow = slow.Next
    fast = fast.Next.Next

    if slow == fast {
        return true
    }
}

Брент работает иначе: один указатель движется постоянно, а второй используется как контрольная точка. Размер интервала постепенно удваивается:

1 → 2 → 4 → 8 → 16

power, lam := 1, 1
tortoise := head
hare := head.Next

for hare != nil && tortoise != hare {
    if power == lam {
        tortoise = hare
        power *= 2
        lam = 0
    }

    hare = hare.Next
    lam++
}

Асимптотика та же:

O(n) по времени
O(1) по памяти

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

Флойда спрашивают на собеседованиях постоянно. Про Брента многие Go-разработчики вообще не слышали.

🐹 Go 1.27 ускоряет мелкие аллокации в куче почти в 2 раза — и для этого не нужно менять ни строчки кода.

На тесте с объектом размером 16 байт:

Go 1.26 → ~9,5 нс
Go 1.27 → ~5,5 нс

Причина в самом аллокаторе.

Раньше даже для маленьких объектов компилятор вызывал одну универсальную функцию, а runtime уже определял нужный size class: 8, 16, 24, 32 байта и т.д.

В Go 1.27 для объектов меньше 80 байт появились специализированные пути аллокации под конкретные классы размеров. Лишняя работа в runtime просто исчезает.

Больше всего выиграют программы, которые постоянно создают множество мелких объектов:

• парсеры
• деревья и списки
• очереди событий
• структуры с отдельной heap-аллокацией каждой ноды

А вот сервисы с редкими крупными аллокациями почти ничего не заметят.

Редкий случай, когда достаточно просто пересобрать проект новым Go и получить ускорение бесплатно.

https://vc.ru/dev/3081222-go-1-27-uluchshaet-proizvoditelnost-allokatsiy-pamyati

У SQLite один writer. И иногда это не ограничение, а очень удобная архитектура.

Работал с SQLite и увидел необычную схему: база работала сразу на нескольких машинах, но запись всё равно шла только через одну.

За это отвечал LiteFS.

Он не пытается превратить SQLite в полноценную distributed database. Вместо этого одна машина выбирается primary через distributed lease и получает право писать. Остальные работают как реплики.

Если primary пропадает, lease истекает и другой узел может занять его место.

В итоге сложная на первый взгляд задача сводится к довольно простой идее:

«Просто гарантируй, что в каждый момент времени пишет только одна машина».

А на скрине как раз часть Go-кода LiteFS, которая продлевает этот lease и следит, чтобы узел не продолжал считать себя primary после истечения TTL.