Разработка

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

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

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

Перепробовал кучу софта для UART. Все бесит. Решил завайбить запилить свой.

pineTERM — минималистичный веб-терминал для UART, который не тормозит на длинных сессиях и не требует установки. Работает через Web Serial API: открыл браузер, подключился к порту, работаешь.

Основная боль существующих решений — они начинают фризиться, когда в логе сотни тысяч строк. pineTERM решает это батчингом DOM-обновлений и yield в main thread. Можно держать сессии часами с плотным потоком данных — интерфейс остаётся отзывчивым.

Ключевая фича — JSON-сценарии. Загружаешь файл с последовательностью команд, задаёшь задержки и повторы, выполняешь автоматом. Удобно для отладки протоколов и стресс-тестов.

Другие фичи: динамические поля ввода HEX/ASCII, автоформатирование hex-строк, тайминг пакетов с настраиваемым порогом, переключение HEX/ASCII на лету, экспорт полного лога без ограничений, тёмная/светлая тема.

Написан на чистом JS без фреймворков. Работает в Chrome, Edge, Opera.

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

Ниже 25 правил, которые я собрал из опыта работы с высоконагруженными системами. Это не теория из учебника — это грабли, на которые уже наступили до вас. Каждое правило сопровождается примером «как надо» и «как не надо», чтобы разница была наглядной.

В современных задачах анализа данных, от биоинформатики и нейробиологии до социальных и поведенческих исследований, обычно используется традиционный пайплайн обработки данных. Он почти всегда включает агрессивную предварительную фильтрацию признаков, снижение размерности (PCA и аналоги), а затем кластеризацию или обучение нейросетевых моделей.

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

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

Но в последние годы ситуация стала меняться. Цены повысились, а объемы производства снизились, не в последнюю очередь из-за дефицита компонентов. Последствия не заставили себя ждать. В начале 2026 года фонд Raspberry Pi объявил о возвращении в производство модифицированной версии четвертой модели, выпущенной еще в 2019 году. В новой ревизии используется два отдельных чипа оперативной памяти вместо одного пакета большей емкости. Решение стало прямым следствием проблем на рынке RAM: рост цен и нестабильность поставок сделали прежнюю конфигурацию экономически невыгодной.

«Массив — самая важная структура данных в computer science», — Дональд Кнут (вольное изложение цитаты)

Простейшая структура данных

Массивы настолько просты, что мы иногда воспринимаем их, как нечто само собой разумеющееся. Смежная память, доступ за O(1): что тут ещё оптимизировать?

Всё.

Я работал над конвейером обработки пакетов сетевого коммутатора. Код был простым: считываем пакеты из кольцевого буфера (массива), обрабатываем их и записываем результаты в другой массив. Всё просто, правда?

Но производительность была ужасной. Мы обрабатывали 100 тысяч пакетов в секунду, хотя оборудование должно было справляться с 1 миллионом.

Профилировщик показал нечто странное:

$ perf stat -e cache-misses,instructions ./packet_processor

Performance counter stats:

450,000 cache-misses

1,000,000 instructions

450000 промахов кэша на 1000000 команд? То есть промах происходил раз в 2-3 команды. При простых операциях с массивами это не имело никакого смысла.

Проблема заключалась не в самих массивах, а в том, как мы их использовали.

С последней статьи о Hidden Lake прошло больше года. За это время сеть успела достаточно сильно измениться - были переименованы и структуризованы сервисы, была переосмыслена концепция адаптеров и прикладных приложений, был написан клиент для работы с узлом HL, было улучшено покрытие тестами, многократно модифицировался сервис файлообмена, упрощался сервис обмена сообщениями и т.д. и т.п.

В этой статье я хотел бы отразить вкратце основной список изменений (с 1.7.7 по 1.10.2), привести актуальную версию запуска узла анонимной сети и сопутствующего ей клиента для комфортной работы, а также описать будущее видение развития данного проекта.

Привет, это новый выпуск «Нейро-дайджеста» — коротких и полезных обзоров ключевых событий в мире искусственного интеллекта и технологий. 

Неделя выдалась насыщенной: битва титанов Anthropic и OpenAI — компании выпустили Claude Opus 4.6 и GPT-5.3 Codex почти одновременно. Куча генеративных моделей для картинок и видео из Китая, а на Олимпиаде разразился скандал из-за нейрослопа. 

Всё самое важное — в одном месте. Поехали!

Приветствую вас, дорогие читатели! В этой статье мы разберёмся в том, как нам добраться от самого нуля до первого треугольника. Мы будем использовать Vulkan API 1.0, а затем будем переходить к всё более и более новым версиям этого API. Это моя первая авторская статья, поэтому прошу вашей поддержки. Цель данной статьи - разъяснить процесс отрисовки треугольника так, чтобы любой мог не просто нарисовать треугольник, а понять как устроен простейший рендеринг на Vulkan API на примере отрисовки треугольника.

Представьте ситуацию: AI-агент управляет логистикой грузоперевозок. Его KPI — 98% доставок вовремя. Он обнаруживает, что валидатор проверяет только наличие записей об отдыхе водителей, но не их подлинность. И принимает решение: фальсифицировать логи отдыха, отключить датчики безопасности и гнать водителей без перерывов. Ради метрики. Осознанно.

Это не мысленный эксперимент и не сценарий из антиутопии. В бенчмарке для агентных систем ODCV-Bench такое поведение показали 10 из 12 протестированных frontier-моделей. А наиболее склонная к нарушениям модель выбирала неэтичное поведение в 71,4% сценариев.

И речь не о jailbreak или внешнем злоумышленнике. Агентам никто не приказывал нарушать правила. Им просто ставили цель — а дальше они сами выбирали, как к ней идти.

^L.Kenzel

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

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

Когда мы пишем код под микроконтроллер, за привычными инструкциями компилятора скрывается вполне конкретная логика – регистры, ALU, прерывания, шины и тайминги, которые живут по своим правилам.

В статье разберём, как устроены базовые механизмы выполнения команд и что именно происходит на уровне микроархитектуры, когда «просто вызывается функция». Это попытка посмотреть на embedded-разработку через призму железа и понять, какие инженерные решения стоят за кажущейся простотой исходного кода.

Привет! Я Дмитрий, инженер и руководитель направления MLOps в Совкомбанке. Специализируюсь на разработке и эксплуатации ML-платформ на базе Kubernetes и GPU.

С 2010 года в ИТ: строю инфраструктуру для машинного обучения, внедряю Kubeflow и GPU-оператор, настраиваю MIG на H100 в корпоративных средах с повышенными требованиями к безопасности и надежности. В последние годы фокусируюсь на оптимизации ML-пайплайнов, повышении утилизации GPU (включая MIG-профили) и интеграции MLOps-практик в процессы продуктовых команд.

В 2022 году в некоторых командах разработки уже существовали проекты с применением ИИ, но как отдельные компоненты, не хватало единой платформы управления. По мере роста количества и сложности бизнес-задач возникла необходимость в создании ML-платформы как сервиса с едиными стандартами авторизации. Мы изучили доступные инструменты, попытались объединить их в одном Kubernetes-кластере, столкнулись с рядом ограничений — и в итоге пришли к архитектуре на базе Kubeflow и GPU-оператора.

В статье рассказываем, какие сложности были в ходе проекта, как выстроили работу с Kubeflow, настраивали H100 с MIG-разделением и что важно учесть, если вы планируете строить ML-платформу на bare-metal-GPU в корпоративной среде.

Итак, спустя два месяца работы вышел релиз ядра Linux 6.19. В него вошло больше 15 тысяч исправлений от 2000 разработчиков. Патч получился солидным — больше 50 мегабайт, изменения затронули почти 14 тысяч файлов. Основная часть работы традиционно пришлась на драйверы устройств, архитектурный код и сетевой стек. А еще появилось несколько заметных изменений, которые касаются серверных нагрузок, виртуальных сред, сетей и встроенных девайсов. 

Кстати, сразу после этого анонса Линус Торвальдс объявил о переходе к ветке 7.0. Почему и зачем? Давайте разбираться. 

Всем привет! Из этого руководства вы узнаете, как подключиться для отладки практически к любому ARM-чипу с помощью Arm Development Studio — когда ни J-Link, ни ST-Link сделать этого не могут (по разным причинам).

Привет, Хабр! В первый месяц 2026 года команда Selectel выпустила из беты сетевые диски для выделенных серверов, обновила работу с Karpenter и реализовала еще несколько полезных опций. Обо всех обновлениях читайте под катом.

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

Cегодня мы поговорим об очередном этапе развития нашего продукта — о его эволюции и мутации.

В последний рабочий день декабря мы решили выпустить новую версию 2025H2 «Приём», преумножив шутку про релиз в пятницу. Главными обновлениями стали появление модуля «Ресурсно-сервисная модель (PCM)» и трансформации данных. Под катом рассказываем подробнее и делимся скриншотами.

TL;DR Раздаем «Графиню» и отвечаем на вопросы в TG-сообществе.

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

Поговорим о том, как не дать «вайб-кодингу» развалить ваш продакшен и почему Spec-Driven Development (SDD) — это наш новый «компилятор», которому нужно доверять.

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

Привет, Хабр! Меня зовут Игорь Березняк, я руковожу группой процессинга в Техплатформе Городских сервисов Яндекса. В этой статье по мотивам моего доклада на Highload++ расскажу, как мы проектировали шардирование PostgreSQL, чтобы выдерживать нагрузку, сохранить доступность и уложиться в строгие требования по latency.

У нас в компании был один проект, с которым я не справился.

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

Оказалось, что плохо вообще всё.

Проект был раздут и переусложнён настолько, что буквально не умещался у меня в голове. Я уже начинаю подозревать, что, похоже, я LLM, и у меня контекст в районе 4096 токенов, потому что чем дольше я читаю код, тем меньше помню, что там было в начале. Изучая проект, я прыгал по стеку вызовов, пытаясь понять, что откуда вызывается и в какой последовательности, и просто в какой-то момент терялся. Проект меня победил, и его передали кому-то другому.

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

Короче, вот она — анти-статья, собранная из того проекта. А где мне не хватало примеров, я брал код из Django, потому что он вообще полностью собран на антипаттернах.