#HEX • IT


Channel's geo and language: Russia, Russian
Category: Technologies


Channel by @alexeev_dev.
Авторский блог.
IT, статьи и другая информация.

Related channels

Channel's geo and language
Russia, Russian
Statistics
Posts filter


perfbook.pdf
9.2Mb
Нашел отличную книгу по параллельному программированию: "Is Parallel Programming Hard, And, If So, What Can You Do About It?" Пола Маккенни (Paul E. McKenney).

Это не очередной учебник с сухими теоремами. Это практическое руководство от человека, который годами пилит ядро Linux и знает, где именно у многопоточности растут ноги (и грабли).

О чем:
* Почему ++i в многопоточной среде — это зло, а атомарные операции не всегда спасают.
* Как работает память на уровне железа: кэши, барьеры, ложное разделение строк. Без этого писать быстрый код бессмысленно.
* RCU (Read-Copy Update) — магия, которая позволяет читать данные без блокировок. Объяснено так, что наконец-то понятно.
* Как дебажить гонки данных, которые проявляются раз в месяц на продакшене.
* Много примеров на C, но принципы универсальны для любого системного языка (Go, Rust, C++).

Кому зайдет:
Бэкендерам, которые хотят понять, почему их микросервис тормозит под нагрузкой. Системным программистам. Всем, кто пишет код ниже уровня абстракции "просто вызови API".

Фишка:
Автор пишет очень честно. Если что-то сложно — он говорит об этом. Если решение "грязное", но рабочее — он его дает. Никакой воды, только хардкорная инженерия.

Книга бесплатная, обновляется прямо в Git. Можно читать онлайн или скачать PDF.

🔗 Ссылка на репозиторий с книгой

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


concurrency-primer.pdf
1.3Mb
Почему ваш код врет компилятору (и процессору)

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

Главная мысль: порядок выполнения инструкций в вашем коде ≠ порядку их выполнения в железе.

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

Что внутри:
— Почему volatile бесполезен для синхронизации потоков (спойлер: он не дает барьеров памяти).
— Чем sequential consistency отличается от acquire/release и зачем вам вообще трогать memory ordering, если вы не пишете lock-free структуры.
— Как работают CAS (compare-and-swap) и почему на ARM это больно из-за LL/SC инструкций.
— Что такое false sharing и как одна лишняя переменная в кэш-линии может убить производительность.

Читать, если хотите перестать бояться гонок данных и начать понимать, что происходит под капотом std::atomic.


Американская компания Eon Systems из Сан-Франциско действительно заявила о создании цифровой копии мозга плодовой мушки (дрозофилы) и подключении его к виртуальному телу, которое начало вести себя как живое

Компания использовала данные проекта FlyWire — это международный научный проект, в рамках которого в 2024 году был впервые полностью картирован мозг взрослой мухи.

Ученые оцифровали: ~139 000 нейронов (в некоторых источниках указывается 125 000) и более 50 миллионов синаптических связей между ними.

Затем эту «карту» мозга подключили к симуляции тела мухи (физический движок MuJoCo и модель NeuroMechFly v2) и поместили в виртуальную среду. В итоге цифровая муха, без какого-либо дополнительного программирования или обучения, начала выполнять характерные для реального насекомого действия: ходить, чистить усики, реагировать на запах сахара и вытягивать хоботок. Но она не идеальна - например, не умеет летать

🔗 flywire.ai


Forward from: Находки в опенсорсе
Большая бесплатная конференция в Нижнем Новгороде 17 октября

Регистрация: https://itgorky.ru/bolshaya-vstrecha
При поддержке @it52info

Мы продолжаем нашу традицию делать большую осеннюю конференцию в Нижнем.
Вот тут можно почитать / посмотреть как было в прошлом году: https://t.me/opensource_findings/934

Что будет?
- Много разных секций: Python / DevRel / Frontend / Mobille
- Слет всего нашего сообщества @pytho_nn: приедет весь наш опенсорс чат, будет кучу людей из Москвы, Казани, других городов
- Много дружеского и профессионального общения
- Настолки!
- Встреча подписчиков. Приедет много людей из телевизора, всех их мы заманим в бар после конференции, с ними можно будет поговорить, выпить пива, сфотаться, подружиться :)
- Бар, кальяны и тусовка до утра (самое главное, очевидно)

В текущем году я решил позвать в качестве докладчиков ваших любимых ютюберов и опенсорсеров.

Доклады

- 11:00 Иван Кирпичников, опенсорс разработчик Adaptix. Опыт в проде и какие приколюхи можно творить Посмотрим на конкурента Pydantic от нашего сообщества. Посмотрим: где и когда не стоит использовать Pydantic, какие у него актуальные проблемы. Поговорим, за счет чего Adaptix насколько быстрый, как он устроен. И какие уникальные фичи у него есть.
- 12:00 Егор Бугаенко, Huawei, @yegor256news, https://youtube.com/@yegor256 Типичные ошибки начинающего опенсорс разработчика Проанализирую свой опыт работы с сотнями разработчиков в десятках опенсорс проектах, укажу на их ошибки, предложу альтернативы.
- 13:00 Алексей Гладких, Arenadata, @gaxeliy_tdd, https://twitch.tv/gaxeliy Зачем программисту Twitch (что?) Расскажу про недооценённую платформу для коммуникации, выстраивания горизонтальных связей и создания личного бренда. Покажу как можно стримить с технической стороны.
- 14:00 Александр Кондратьев, Ростелеком Modern Tests для Modern REST: современный подход к тестированию Django Modern REST Тесты API могут проверять разные уровни системы: логику контроллера, обработку HTTP-запроса, взаимодействие компонентов и соответствие реализации заявленному контракту. Если не разделять эти задачи, тесты становятся медленными и хрупкими, а высокое покрытие кода не гарантирует корректную работу API. На докладе поговорим о нашем опыте использования django-modern-rest в проде и организации тестов вокруг него: какие уровни проверок мы используем, что тестируем в запросах и ответах и какие инструменты помогают сократить рутинный код. Отдельно рассмотрим роль точной семантической схемы API: как на её основе генерировать тестовые сценарии, проверять реальные ответы и оценивать покрытие операций, параметров и вариантов ответа, а не только строк кода.
- 15:00 Максим Мельников, @pylounge, https://youtube.com/@pylounge Я в СКРЫТОМ ПУЛЕ: выстраиваем процессы в команде без тильта Работа в IT-команде иногда подозрительно напоминает Dota 2: кто-то фармит, кто-то руинит, кто-то молчит до 40-й минуты, а тимлид начинает думать, что снова играет 1 vs 9. Только вместо Рошана - прод, вместо 0/10 мидера - соседняя CRM-команда, а вместо "gg ez" - очередной аварийный комитет. На докладе поговорим о том, как перестать играть в такой режим и начать выстраивать систему: почему токсичность и дизмораль только мешают, зачем учить людей говорить ртом и управлять ожиданиями, почему процессы не должны держаться на одном "рокстар-игроке" и как не превращать каждый фейл в поиск того, кто заруинил. Разберём, как продавать изменения команде, договариваться с бизнесом и другими командами, фиксировать договорённости и автоматизировать правила - чтобы вместо вечного 1 vs 9 получилась команда, которая действительно играет на победу как для бизнеса, так и технического развития проекта.
- 16:00 Хоренян Сурен, Яндекс Реклама, @Khorenyan, https://youtube.com/@SurenKhorenyan Агент пишет код. Я всё ещё программирую У кого-то ИИ забрал удовольствие от программирования; для меня это второе дыхание. Я смотрю на то, что пишет агент, а в голове только одна мысль: "я сделаю лучше". Разберём архитектурные странности в Python-коде от агентов: что можно упростить, переделать или с удовольствием удалить. Для разработчиков, которые пишут с агентами, ревьюят код от агентов и хотят понимать, что вообще происходит с кодовой базой.

А еще будут и другие треки по другим направлениям, их анонсы будут в их сообщества Нижнего и на @it52info.
Нужна только регистрация: https://itgorky.ru/bolshaya-vstrecha

Приходите! Приезжайте! Буду рад всех видеть лично. Хорошо и интересно проведем время.

Поддержать проект

Даже если вы не сможете присоединиться, нас можно поддержать. От сообщества - для сообщества.
Сделайте репост своим коллегам в чатик, закиньте в ваше локальное сообщество питонистов, поделитесь в своем тг канале. Будем рады любой медийной поддержке!

Обсуждение: Что вы реально думаете про текущее состояние платных конференций? Есть ли в них еще хоть какой-то смысл? Я вот думаю, что не особо.

| Поддержать | YouTube | GitHub | Чат |


Вчера, 8 сентября 2026 года, OpenAI заявила о сенсации: её новая ИИ-модель, значительно мощнее даже новой GPT-6 Astra, решила одну из семи «задач тысячелетия» — уравнения Навье-Стокса. Для этого 10 000 ИИ-агентов работали 88 часов, сгенерировав более 130 миллиардов токенов. Весь проект обошелся компании в миллионы долларов

Почти одновременно с объявлением OpenAI математик Нью-Йоркского университета Тристан Бакмастер (Tristan Buckmaster) и исследователь Anthropic Левент Алпёге (Levent Alpöge) опубликовали собственные результаты по родственной задаче. Они заявили, что OpenAI, вероятно, могли использовать их черновики и наработки для модели.

В основном обвиняют OpenAI в сборе данных - Бакмастер и Алпёге загружали все черновики своего проекта в Codex. Исследователи выбрали нестандартный путь решения, почти не изучавшийся ранее, а OpenAI пришли к такому же результату по похожему пути всего за несколько дней, что также вызывает подозрения.

Бакмастер утверждает, что сотрудник OpenAI Себастьян Бюбек предложил ему два варианта: Бакмастер публикуют свою работу, а OpenAI на следующий день свою; или бакмастер пишет статью, но исключает из соавторов Алпёге из-за его работы в Anthropic.

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

Мнения разделились, многие поддерживают Бакмастера и Аплёге.


Video is unavailable for watching
Show in Telegram
Кубик Рубика и теория графов.


Онлайн-карта по датасету доступна по ссылке!


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

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

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

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


https://habr.com/ru/companies/bothub/articles/1078986/


(Не)видимая цена интеллекта: почему экономия на LLM убивает ваши агентные системы

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

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

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

https://habr.com/ru/companies/bothub/articles/1073292/
https://habr.com/ru/companies/bothub/articles/1073292/
https://habr.com/ru/companies/bothub/articles/1073292/


Однажды на просторах интернета я нашел интересную концепцию — Capability-based Security. Это подход, при котором разрешения управляют доступом к функциям или ресурсам. Я решил не распыляться на изучение концепции целиком и сразу, а разобрать для начала конкретное понятие — интенты.

Интенты (декларация намерений) — это декларативное объявление ресурсов, то есть указание того, какие именно возможности или права понадобятся функции или модулю для работы. Я загорелся идеей попробовать реализовать такую функциональность в Python через собственную библиотеку. Это отличный способ изучить шаблоны проектирования и работу с абстрактным синтаксическим деревом (AST).

Python — динамичный и мощный язык, но эта мощь нередко становится источником уязвимостей. Моя идея заключается в том, чтобы с помощью декоратора функция декларировала необходимые ресурсы, а библиотека блокировала вызовы неразрешенных функций.

Идея звучит жизнеспособно и отлично подходит для создания систем плагинов, проектирования AI-агентов или фреймворков для тестирования. В этой статье я расскажу о capability-based security и мы попробуем решить дилемму: как дать функции только те привилегии, которые ей необходимы, и ничего лишнего.

https://habr.com/ru/companies/selectel/articles/1071066/
https://habr.com/ru/companies/selectel/articles/1071066/
https://habr.com/ru/companies/selectel/articles/1071066/


Count-Min Sketch: как посчитать частоту миллиарда событий в 10 килобайт


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

Как только мы выходим за пределы сотен мегабайт или говорим о потоке, который идёт бесконечно, хеш-таблица перестаёт быть решением, ибо в ней надо хранить сами ключи. Каждый уникальный IP (4 байта) превращается в 50–100 байт из-за оверхеда структур данных и выравнивания. Если ключ — это URL длиной 100 байт, и таких URL миллионы, — память улетает в гигабайты.

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

Предыдущие статьи этой серии решали похожие проблемы — для проверки наличия элемента и для подсчёта уникальности. HyperLogLog отвечает на вопрос «сколько уникальных элементов мы видели?» и не говорит ничего про частоты. Фильтр Блума говорит «есть / нет», но не умеет считать.

Сегодня мы добавим в этот набор ещё один инструмент, который делает ровно то, что нужно для потоковых частот: фиксированная память, константное время на операцию и строгая вероятностная гарантия — Count-Min Sketch.


https://habr.com/ru/companies/timeweb/articles/1070742/
https://habr.com/ru/companies/timeweb/articles/1070742/
https://habr.com/ru/companies/timeweb/articles/1070742/


В 2024 году мы боялись, что ChatGPT заменит нас, и мы не будем больше перекрашивать кнопки и писать очередной CRUD. Но оказалось всё прозаичнее — ChatGPT, увы, не заменил нас, но постепенно нужда в разработчиках как в «крудошлёпах» стала ниже.

И так получилось, что среднестатистические разработчики — уже звери редкие. ИИ-агенты пишут код быстрее, дешевле (или примерно столько, но зато без страховых отчислений). Но работу теряет не инженеры, а исполнители. В итоге, как в эталонном капитализме, вверху пирамиды останутся управленцы — те, кто понимает архитектуру, управляет контекстом и берёт на себя ответственность, что напакостила машина в кодовой базе.

В этой статье мы наконец поставим точку (или длинное тире) в разговорах про ИИ и замену работяг на основе новостей и известных движений в мире IT.

https://habr.com/ru/companies/bothub/articles/1070982/


Всем привет! Сегодня я хочу вам рассказать о Peertube — некоммерческой децентрализованной видеоплатформе с открытым исходным кодом. В нем есть возможность загрузки контента, комментирования, поиска, а также изменения видео, когда оно уже опубликовано.

Peertube основан на технологии P2P (peer-to-peer) для обмена видео по принципу всех известных торрентов. Исторически PeerTube использовал WebTorrent, но уже несколько лет (начиная с версии 6.0) проект полностью перешел на протокол HLS в связке с WebRTC.

Что лучше — централизация или децентрализация? Что такое Fediverse? И наконец — как создать свой инстанс-сайт для сохранения видео на случай, например, блокировки ютуба? Давайте-ка погрузимся в теорию и практику!

В конце мы опубликуем свой сайт!

https://habr.com/ru/companies/timeweb/articles/1055560/
https://habr.com/ru/companies/timeweb/articles/1055560/
https://habr.com/ru/companies/timeweb/articles/1055560/


Представим, что вы имеете сервер, который обрабатывает и анализирует 100.000 RPS. Вам нужно высчитать и показать на дашборде 99-й перцентиль задержки — значение, выше которого только 1% самых медленных запросов. Если вы сохраните все 100 000 чисел за секунду, через час это 360 миллионов чисел. Через день — 8.6 миллиардов. Каждый раз хранить, сортировать и высчитывать? Нереально долго и ресурсозатратно.

Но для этой задачи существует алгоритм T-Digest. Вместо того, чтобы хранить все числа, он группирует их в кластеры — центроиды. А все дело в том, что кластеры на краях распределения (там, где наши хвосты) он делает маленькими и точными, а в центре — большими и «приблизительными». В результате для 100 000 точек нам нужно всего ~100 центроидов вместо 100 000 чисел. Это в сотни раз меньше памяти. И притом что ошибка при вычислении 95-го перцентиля в среднем составляет всего 0.001–0.06% (в зависимости от параметра сжатия).

В этой статье я разберу математику алгоритма, почему алгоритм такой быстрый и малозатратный, разберём графики и бенчмарки, а также покажу реализацию алгоритма на C.

https://habr.com/ru/companies/timeweb/articles/1065882/
https://habr.com/ru/companies/timeweb/articles/1065882/
https://habr.com/ru/companies/timeweb/articles/1065882/


Буду рад апвоутам статье, давайте наберем +30


Все мы знаем, что языки делятся на динамические и статические: Python или JS позволяют молниеносно прототипировать, но расплачиваться нестабильностью в продакшене приходится потом, тогда как C++, Java или C# требуют прописывать типы сразу, оплачивая монументальную надежность замедлением разработки.

В 2006 году Джереми Сиек предложил разрешить этот конфликт концепцией постепенной типизации в работе «Gradual Typing for Functional Languages»: язык остается динамическим по умолчанию, однако разработчик может аннотировать типами отдельные модули или функции, не покрывая ими всю кодовую базу, а типизированный и нетипизированный код взаимодействуют через специальный динамический тип Dyn. Звучит как сказка — быстрое прототипирование с постепенным наращиванием стабильности. Однако при детальной проработке вскрылись фундаментальные нюансы: в серии последующих работ Сиек, Таха, Вадлер и другие показали, что стыковка типизированного и нетипизированного кода требует операции приведения типа (cast), а дизайн этого каста упирается в противоречие между тремя желаемыми свойствами — надёжностью системы типов (soundness), собственно постепенностью (gradual typing) и отсутствием рантайм-обёрток на границах (no wrappers).

Позднее сообщество, и я в том числе, переосмыслило третью вершину: no wrappers — это забота о производительности и прозрачности рантайма, безусловно важная, но с позиции программиста, а не математика-оптимизатора, правильнее говорить о удобстве разработчика (developer-friendly). Это свойство вбирает в себя no wrappers как частный случай, добавляя понятные сообщения об ошибках, низкий порог входа и отсутствие многослойных типовых аннотаций, ведь если ради производительности приходится городить бесконечные теоремы типов, такая система едва ли приживётся на суровом рынке опенсорса.

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

https://habr.com/ru/companies/timeweb/articles/1055556/
https://habr.com/ru/companies/timeweb/articles/1055556/
https://habr.com/ru/companies/timeweb/articles/1055556/


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

---

Вы когда-нибудь замечали, что у нейросетей нет своего мнения? Допустим, вы пишете: «Мой тимлид — идиот, он заставил меня писать на PHP». Модель отвечает: «Я понимаю ваше разочарование. Смена технологического стека действительно может быть стрессовой, и PHP часто критикуют за неоднородную архитектуру. Однако…» — и дальше следует мягкая, вежливая, безличная тирада с равным количеством аргументов “за” и “против”, и обобщенным выводом. Она не поддержит вашу агрессию, но и не скажет прямо: «Вы говорите ерунду, ваш тимлид, скорее всего, прав».

Суть популярных LLM — это обобщение и комфорт в общении. Человеку приятнее, когда с ним соглашаются и хвалят, а вывод либо подгоняется под его мнение, либо размывается до золотой середины.

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

https://habr.com/ru/companies/bothub/articles/1063170/




Эволюция, а не революция: релиз Elixir 1.20 и почему он вас заинтересует

В мире разработки программного обеспечения редко можно увидеть, как зрелый, динамический язык добавляет мощную, статическую систему типов без ущерба для своей философии и существующего кода. 3 июня 2026 года команда Elixir сделала именно это, выпустив версию 1.20. Главное нововведение — постепенная типизация (gradual typing), которая обещает найти в вашем коде «верифицированные баги» (verified bugs — ошибки, гарантированно ведущие к падению в рантайме) без необходимости писать аннотации типов.

Но почему это должно волновать вас, если вы пишете на Python, Java или Go? Команда Elixir поставила перед собой цель, которую многие считают «святым граалем». На практике сочетание всех трёх свойств почти не встречается.

И я считаю, что это отличный повод присмотреться к Elixir, даже если вы никогда не писали на нём ни строчки. Молодой, но зрелый язык, работающий на виртуальной машине Erlang (BEAM) и исповедующий функциональную парадигму. Он известен своей отказоустойчивостью и конкурентностью, но, увы, остается малоизвестным языком.

https://habr.com/ru/companies/timeweb/articles/1055546/


Новый законопроект об ИИ в России - легализация корпоративного пиратства. Выгоду получают только Сбер и Яндекс (так как они владеют ИИ по критериям закона), и они могут легально парсить и получать все ваши материалы.

Статьи на хабре, ваш сайт, даже вашу книгу. Яндексу или Сберу достаточно оформить 1 книгу и они имеют право ее скормить своей ИИ.

Кроме того, Яндекс и Сбер имеют право обходить блокировку по мета тегам или robots.txt: "доступен для анализа без ограничения техническими средствами".

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

20 last posts shown.