User
Физическая база простым языком и без нейронок о том, что такое волновое сопротивление кабеля, чтобы наконец стало интуитивно предельно. Откуда оно взялось, где там резистор? Сопротивление меди что‑ли? Возьмём коаксиальный кабель, увидим провод в центре и трубу‑провод вокруг первого. Остальное — изоляция, защита и тому подобное. Хоть изоляция и вносит неиллюзорную долю в параметры, для понимания принципа конкретный вид изоляции не важен.
Рассмотрим альтернативу облачным моделям — локальный запуск LLM на своём компьютере.
Этот подход даёт полный контроль над данными, но требует понимания ресурсов, форматов моделей и особенностей настройки. В статье расскажу, как выбрать модель под ваше железо, запустить её с помощью LM Studio, подключить к агентам и что из этого вышло в эксперименте. И несколько рекомендаций для тех, кто задумывается о такой возможности.
Для пользователя может показаться, что переход с HTTP/2 на HTTP/3 — это просто замена TCP на UDP в конфиге. Но для серверного ПО с многопроцессной архитектурой этот шаг превращается в настоящую «головную боль». Классическая схема с accept(), на которой годами строилась работа с TCP‑соединениями, в мире QUIC попросту не существует. Пакеты летят в UDP‑порт, и ядро ОС больше не знает, какому именно рабочему процессу их отдать.
В оригинальном nginx это привело к тому, что поддержка HTTP/3 уже долгое время остается «экспериментальной» и ограниченной: она страдает от проблем с обрывами сессий и деградации сервиса при обновлении конфигурации. Для многих это стало стоп‑фактором для внедрения протокола в реальный продакшен.
В этой статье мы расскажем, как в Angie 1.11 нам удалось устранить эти фундаментальные недостатки. Мы не просто добавили поддержку протокола, а пересмотрели механику взаимодействия с ядром. Путь от простых хешей до создания полноценного аналога accept() для QUIC с помощью BPF‑программ позволил нам заявить: реализация HTTP/3 в Angie закончена, лишена «детских болезней» nginx и полностью готова к эксплуатации в высоконагруженных средах.
Добро пожаловать под капот современного транспорта данных.
История концептов в C++ – один из самых показательных примеров того, как язык развивается не линейно, а через десятилетия экспериментов, откатов и переосмыслений. Первые идеи, которые мы сегодня называем концептами, появились ещё в конце 1990-х, когда стало очевидно, что шаблоны C++ имеют колоссальную выразительность, но практически не дают средств для описания намерений программиста. Шаблон можно было инстанцировать почти с любым типом, но ошибка проявлялась либо в виде километров сообщений компилятора, либо в виде неожиданного поведения в рантайме. Уже тогда Страуструп сформулировал проблему как «отсутствие контрактов для шаблонов», когда программист знает, что от типа требуется оператор + или ==, но язык этого не выражает.
Ранние предложения концептов были чрезвычайно амбициозными и стремились описывать не только синтаксис, но и семантику. Например, концепт EqualityComparable должен был означать не просто наличие operator==, но и выполнение математических свойств эквивалентности: рефлексивности, симметричности и транзитивности. Аналогично, концепты для упорядоченных типов предполагали строгую слабую упорядоченность, а для итераторов корректное поведение при многократном проходе. Это отражало академический взгляд на обобщённое программирование, сильно вдохновленный функциональными языками и работами Степанова.
C++ — язык с долгой памятью. В нём до сих пор живут идиомы и приёмы, которые когда-то спасали разработчиков, а сегодня нередко мешают писать безопасный, быстрый и поддерживаемый код. Мы продолжаем использовать макросы, CRTP или iostream «по привычке», не всегда задумываясь о цене — сложности поддержки, скрытых багах, просадках производительности и времени команды. Разобраться, что в современном C++ действительно стоит брать в прод, а что пора оставить в прошлом, — важная задача для инженера, который не хочет тащить legacy в 2026 год.
Привет, Хабр! Недавно мы запустили шоу «АйТир Лист». В каждом выпуске берём одну тему из мира разработки и раскладываем её по тир-листу — от FAIL до GOD. В первом выпуске разбирали open source для фронтенда, а во втором выпуске — обсудим непростую тему фич и идиом С++.
Приглашённые эксперты — Антон Полухин, эксперт-разработчик C++ платформы городских сервисов Яндекса, и Даниил Черепанов, архитектор редакторов МойОфис.
Будет субъективно, местами провокационно и точно полезно — чтобы вы посмотрели на привычные инструменты свежим взглядом и осознанно выбирали, на чём писать следующий проект.
Привет! Меня зовут Дима Кривопальцев, я тимлид бэкенд‑команды Яндекс Диска (Яндекс 360). Уже больше семи лет я занимаюсь разработкой высоконагруженных распределённых систем — и в статье расскажу об одной из них.
В Яндекс 360 есть сервисы с очень большими нагрузками — и по RPS, и по объёму хранимых данных, и по числу обрабатываемых асинхронных задач. Именно последняя часть — асинхронная обработка — будет в центре этого рассказа.
Тема может показаться немного провокационной: речь пойдёт об очередях поверх SQL‑баз, а в сообществе такое решение принято считать антипаттерном — и на это есть основания. На конференциях и в статьях обычно можно услышать скепсис: «Очередь на PostgreSQL? Не стоит даже пытаться». Действительно, подобных попыток было много, и почти все сталкивались с типовыми проблемами — от блокировок до деградации производительности.
Тем не менее, в реальности у многих крупных компаний всё равно есть свои очереди, построенные поверх SQL‑баз — как PostgreSQL, так и MySQL. Это решение встречается и в российских, и в зарубежных командах. Яндекс Диск здесь не исключение — у нас тоже есть своя реализация, о которой сегодня и пойдёт речь.
Мы уже познакомились с Клодом Пайяром — французским радиолюбителем, в бытность, редактором журнала Radio-REF, энтузиастом-электровакуумщиком, воссоздавшим в своей мастерской кустарное производство практических триодов ТМ [1] (первых, 1920-х годов, промышленных «жёстких» — с высоким вакуумом, электронных ламп), и рассмотрели его самодельное огневое оснащение (Часть 1), установку для контактной сварки и технологическую печь (Часть 2), ламповую установку ТВЧ для дегазации электродов ламп при откачке (Часть 3). Сегодня мы взглянем на высоковакуумную установку Клода, самодельную, как и всё его оборудование.
Итак, ваш бизнес растет и созданного на старте сайта уже не хватает. Клиенты хотят быстро получать информацию, сразу реагировать на уведомления и иметь удобный доступ без необходимости постоянно открывать браузер. Да и вообще, все ваши конкуренты давно сделали мобильные приложения и превратили их в основной канал взаимодействия с аудиторией. Кажется, вы подошли к той черте, когда пришла пора нанимать штат разработчиков. Или нет?
Привет, Хабр! Меня зовут Матвей. В этой статье я расскажу, как быстро и без больших затрат превратить ваш сайт в приложение с помощью конструктора. Посмотрим основные подходы к разработке и как создать свое мини-приложение, а самое главное — где можно протестировать готовый APK. Детали под катом.
Теоретическую основу кэширования DNS в Linux мы разбирали в первой части, где говорили про работу процесса разрешения имен — от вызова getaddrinfo() до получения IP-адреса. Вторая часть была посвящена различным уровням кэшей самой системы, приложений и языков программирования, контейнеров, прокси - а также их мониторингу и сбросу. Теперь самое время перейти к практике.
Если вы когда-либо запускали подряд команды ping, curl, dig и получали разные IP-адреса, вы не одиноки. Поведение DNS в Linux — не просто вызов getaddrinfo(). Это взаимодействие множества слоёв: от glibc и NSS до NetworkManager, systemd-resolved, dnsmasq и облачных конфигураций. В этой части разберем практические аспекты DNS:
почему одинаковые запросы дают разные IP
как реально контролируется разрешение имен: что вызывает кого и зачем
как проводить диагностику: strace, resolvectl, tcpdump
В первой части мы разобрали, как в Linux работает процесс разрешения имен — от вызова getaddrinfo() до получения IP-адреса. Однако если бы каждый вызов требовал нового DNS-запроса, это было бы неэффективно и сильно нагружало как систему, так и сеть. Поэтому используется кэширование.
Кэширование DNS может быть везде — в glibc, в systemd-resolved, в браузерах и даже в приложениях на Go. Кэш помогает увеличить скорость работы, но создает дополнительные сложности при отладке. Например: вы меняете DNS-запись, но сервер продолжает ходить по старому IP-адресу. Или, Dig показывает правильный адрес, а curl всё равно подключается к устаревшему.
В этой статье разберем различные уровни кэшей самой системы, приложений и языков программирования, контейнеров, прокси. А также их мониторинг и сброс.
Привет, Хабр! Меня зовут Анатолий Кохан, я — DevOps-инженер в К2Тех.
Когда мы вводим в браузере имя сервера или доменное имя сайта, выполняем ping или запускаем любое удаленное приложение, операционная система должна преобразовать указанные имена в IP-адреса. Этот процесс называется разрешением доменного имени. На первый взгляд он может показаться весьма прозрачным, однако за ним скрывается многослойный механизм.
Данная статья — начало серии, посвященной низкоуровневой архитектуре разрешения имен. Поговорим о том, как устроен этот процесс в Linux на уровне ядра, различных библиотек C и системных вызовов.
Всем привет! Я Андрей, ML-разработчик из команды распознавания речи в Т-Банке. Мы занимаемся полным циклом разработки: сбором и разметкой данных, проведением экспериментов по обучению моделей, интеграцией в продакшен.
В русскоязычном сегменте давно не хватает открытых моделей распознавания речи, которые можно было бы быстро кастомизировать под реальные задачи. Более того, почти все доступные модели работают офлайн и не адаптированы под специфику телефонии. Поэтому мы решили опубликовать собственную потоковую акустическую модель с кодом для ее инференса и дообучения, а еще выложить 5-граммную языковую модель.
Акустическая модель является по-настоящему потоковой, легковесной, производительной и обгоняет по качеству более крупные открытые офлайн-модели в телефонии.
В статье расскажу, как устроена потоковая модель распознавания, как и на чем ее обучали и как ее можно использовать.
Шардирование, двухфазный коммит и распределенные транзакции окружены определенными мифами и заблуждениями. Например, может быть достаточно неочевидно, что двухфазный коммит обеспечивает только атомарность транзакций, но не их изоляцию. Поэтому мы решили написать пост, который бы помог разобраться в этих сложных вещах и сделать правильный выбор, когда Postgres'а Вам станет мало и Вы столкнётесь с шардированием.
В распределённых системах критически важно обеспечить консенсус – согласованность данных или решений между множеством узлов (серверов), даже при сбоях и задержках сети. Алгоритмы консенсуса позволяют группе несовершенных узлов действовать как единое надёжное целое. Три классических алгоритма – Paxos, Raft и Zab – стали основой для построения отказоустойчивых систем. Они гарантируют, что при наличии кворума узлов (обычно большинства) все узлы придут к единому решению и последовательности операций, сохраняя консистентность данных. В данной статье мы рассмотрим устройство этих алгоритмов «под капотом», их этапы (выбор лидера, репликация журнала, обработка сбоев и восстановление), области применения в реальных системах (от координаторов в кластерах Kubernetes и Apache Kafka до распределённых баз данных), а также сравним готовые реализации (такие как etcd, ZooKeeper, Consul и др.) по ключевым характеристикам.
Один из частых вопросов, которые я получаю от студентов или на наших внутренних студийных лекциях, — это какую стратегию выделения памяти лучше применять при разработке? Ответ: хотелось бы никакую, т.е. не использовать аллокации рантайм, но жизнь вносит свои коррективы.
Мы все знаем, что нельзя просто выделять память, когда вздумается, но откладываем решение этой проблемы до конца проекта. К тому времени дедлайны начинают давить, майлстоуны и некоторые части тела подгорать, и обычно уже слишком поздно, чтобы вносить серьезные изменения. Ну хотябы есть пара недель перед релизом, чтобы поправить основные проблемы.
Динамическое выделение памяти — это как раз то, что относится к той категории вещей для большинства программистов, о которой все знают, но забивают пока не приходит OOM. Хотя немного продуманности и предварительного планирования могут помочь избежать большинства этих проблем, и даст небольшую надежду, что игра не вылит по памяти в самый неподходящий момент.
Попробую убедить вас не использовать std::string/vector в функциях. При написании кода для пк, неважно - игры это или что-то другое, программа обычно разделяется на условно пять областей памяти.
Привет, Хабр! Случаи увольнения людей «не с тем паспортом» или говорящих «не на том языке», или живущих «не там, где надо» сегодня, к сожалению, стали обыденностью. Хотя, строго говоря, всё это проявления дискриминации. В этой статье я на условиях анонимности расскажу историю своего знакомого, которому удалось добиться от работодателя в ЕС компенсации за дискриминационное увольнение. Подробностей и названия компании здесь не будет (таковы условия заключённой сделки), только алгоритм сработавших действий для получения компенсации.
В процессе разработки компилятора Roc нам то и дело приходилось углубляться в изучение сложных тем по информатике. Снова и снова всплывает тема скорости, и это касается как производительности среды, в которой исполняется генерируемый нами код, так и производительности самого компилятора.
В ходе такой работы нам исключительно пригодился подход под названием «дата-ориентированное проектирование». Это идея, согласно которой при структурировании кода требуется отталкиваться от специфики тех данных, с которыми приходится работать.
Дата-ориентированное проектирование часто используется при программировании игр, где именно от скорости среды выполнения зависит, что вы сможете и чего не сможете сделать. В последнее время эта парадигма стала активнее применяться и в других предметных областях, например, в разработке компиляторов для Zig и Rust, а также в других проектах, где акцент делается на ускорении среды выполнения, например, в Mold и Bun.
Эндрю Келли, создатель Zig, выступил с отличной лекцией Practical Data-oriented design, которая служит введением в основные идеи, лежащие в основе DoD. В этой статье я покажу, как мы изменили компилятор roc, переработав его с учётом некоторых из этих идей.
Я пишу программу для сверхбыстрого кодирования/декодирования азбуки Морзе и использую pipe для передачи данных. При этом pipe работает очень медленно. Давайте разберемся почему.
С кодами малой плотности проверок на чётность, которые дальше мы будем именовать коротко LDPC (Low-density parity-check codes), мне удалось познакомиться более или менее близко, работая над семестровым научным проектом в ТУ Ильменау (магистерская программа CSP). Моему научному руководителю направление было интересно в рамках педагогической деятельности (нужно было пополнить базу примеров, а также посмотреть в сторону недвоичных LDPC), а мне из-за того, что эти коды были плюс-минус на слуху на нашей кафедре. Не все удалось рассмотреть в том году, и поэтому исследование плавно перетекло в мое хобби… Так я набрал некоторое количество материала, которым сегодня и хочу поделиться!
Кому может быть интересна данная статья:
В общем, присоединяйтесь!