DIY или Сделай сам

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

Коллектив разработки в электронной компании - это двухмерная структура. С одной стороны, есть отделы: архитектуры, моделирования, логического проектирования, верификации, физического проектирования, post-silicon отладки итд. С другой стороны, каждый компонент (процессор, графический процессор, сетевой чип) состоит из пары десятков блоков, и вокруг каждого блока есть небольшие группы по пять-семь человек из всех этих отделов.

Можно попробовать дать школьникам представление о том, как выглядит совместная разработка и отладка с помощью проекта на нескольких макетных платах с микросхемами малой степени интеграции. А потом перенести это на SystemVerilog и FPGA платы. Например вот такого: сделать сумматор чисел бесконечной разрядности:

В большинстве случаев для Fanless Mini-PC достаточно естественного охлаждения, под которое они и спроектированы.

Однако сейчас лето, жара, июль… Жарко всем, в том числе и компьютерам, и им тоже может захотеться прохлады.

Некоторые Fanless Mini-PC (и в частности Industrial Mini-PC) даже имеют штатное место для установки дополнительного вентилятора.

Однако как правильно его расположить и от чего зависит эффективность его работы? В каких сценариях он может пригодиться, да и нужен ли он вообще?

Об этом, а также о других очевидных (и не вполне очевидных) особенностях Fanless Mini-PC мы сейчас и поговорим.

Картинка: jannoon028, magnific.com

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

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

И сегодня мы подробно рассмотрим ещё одну необычную компоненту — использование озона в двигателях! 

Недавно я публиковал статью на Хабре про технические музеи и организацию экспозиций. Если кратко, то технических музеев в России мало, они перегружены экспонатами и при этом их познавательная ценность недостаточна.  В статье был предложен новый формат демонстрации экспонатов, а именно универсальный стенд, который  сочетает в себе сам экспонат, экспонат в разборе и видео с субтитрами для объяснения что к чему.  Сейчас дошли руки сделать макет такого стенда. Получилось примерно так: 

Преподавая в школе «Интеграл» в 2018 году, я наблюдал, как коллеги-педагоги массово скупали Яндекс.Станции и умные лампочки. Один из них, обычный учитель (не IT-специалист), с гордостью рассказывал, как настроил автоматическое включение света через мобильное приложение не только на кухне, но даже в Ванной комнате. А еще он поставил умную RGB-лампу в спальню. Всё работало «из коробки» — нажал кнопку, точнее зажал на некоторое время, подключил, готово.

Меня же это беспокоило. Как учитель информатики и робототехники, я не мог принять идею «черного ящика». Тем более когда можно не просто включить лампочку через Интернет, но получать значения с датчиков освещенности, температуры и влажности... Тогда я начал эксперименты еще на ESP8266, сегодня могу немного рассказать, как это все используется и устроено теперь в моем умном доме.

Мне понравился проект стойки 10 дюймов Lab Rax , я его распечатал и увидел, что мне не всё нравится в конструкции.

То, что ИИ заменил кодеров, уже ясно. А электронщиков ещё нет. Или уже?

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

Я сделал плату с радаром на 60 ГГц и прошивку к ней, и почти на каждом шаге использовал Claude, чаще всего Fable 5. Он подбирал мне микроконтроллер, планировал функции выводов, анализировал комплектацию, писал скрипты для Altium, драйверы и прикладной код. И знаете, практически получилось с первой итерации!

Локальный ИИ в 2026-м начинает становиться нормой для многих компаний. Причины понятные: данные не утекают в чужое облако, не нужны ни VPN, ни подписка на каждого сотрудника, всё крутится на своём железе и под контролем. Вот только перед тем как «поставить Ollama и запустить модель», всех встречает вопрос, на котором спотыкается большинство: а какое, собственно, железо под это брать?

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

Про цены. В 2026-м видеопамять и видеокарты ощутимо подорожали! Поэтому конкретные суммы ниже — ориентир на 20 июня 2026-го, перед покупкой сверяйтесь с актуальными. А вот сам подход к выбору от прайса не зависит, и именно его и разберем в статье.

И ещё одно честное замечание, чтобы не разочароваться. Локальная модель не заменит фронтир — ChatGPT, DeepSeek и им подобных — по всем фронтам. Но для внутренних документов, черновиков, кода и обработки собственных данных её хватает с запасом, и данные при этом никуда не уходят. Какую модель под какую задачу брать — разговор отдельный (разберу в следующих статьях); здесь только про железо.

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

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

Раз уж пошла такая песня, я решил добить вопрос с выводом изображения по HDMI на плате Zynq Mini. В предыдущей статье мы уже разобрали как это сделать в baremetal-сценарии, теперь пришла пора дополнить дизайн для возможности вывода системной консоли Linux, при том, что у Zynq-7000 нет своего видеоконтроллера и весь видеотракт (DMA, генератор таймингов, TDMS-кодер) должен быть построен внутри FPGA, а затем быть проброшен в Linux. 

Всем, кому интересна данная тема - добро пожаловать под кат!

Всем привет! На связи Владимир Аксёнов, руководитель группы IT‑поддержки дата‑центра в Yandex Infrastructure. На Хабре я уже рассказывал об эволюции IT‑оборудования в дата‑центрах Яндекса, показывал наши собственные стоечные решения и делился опытом, как мы тестируем комплектующие для стоек. Но история с сосисками в дата‑центре — не единственная интересная инженерная задача, были ещё и яблоки! 

А под яблоками я имею в виду оборудование Apple, поскольку нашим внутренним пользователям‑разработчикам регулярно необходима среда для тестирования приложений под целевые платформы. И если под Windows, Android и Linux создать такую песочницу нетрудно, то с iOS и MacOS сложность в том, что необходимое оборудование Apple не выпускается в виде серверных решений для дата‑центров.

В этой статье я расскажу, как мы адаптировали обычные Apple Mac mini для установки в серверные стойки под внутренние песочницы. А также покажу, почему для этого нам потребовалось напрячь двух производителей комплектующих и удостовериться, что даже в условиях «сауны» горячего коридора ни одно устройство не превратится в печёное яблоко.

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

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

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

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

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

Мы много раз сталкивались с этой проблемой, поэтому решили разработать Attack Replay — открытую утилиту для воспроизведения и модификации сетевого трафика при тестировании СЗИ. Она объединяет в одном интерфейсе функции нескольких популярных инструментов и автоматизирует рутинные операции, связанные с подготовкой и запуском тестов.

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

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

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

Расскажу о проблеме с электронным регулятором давления, которая возникла после запуска системы охлаждения куриных тушек, и как проблема была решена.

Я создал Absolute Linux Tablet — самодельный планшет, изготовленный полностью с нуля.

Это планшет на основе Raspberry Pi Compute Module 5 и 10-дюймового сенсорного DSI-дисплея Waveshare со встроенным литиевым аккумулятором, обеспечивающим до пяти часов непрерывной работы.

Цель этого проекта заключалась в создании портативного Linux-планшета для моего будущего проекта, связанного с солнечной энергетикой. Мне требовалось устройство, которое можно было бы легко переносить с места на место при работе на открытом воздухе. Можно было бы взять ноутбук, но мне хотелось чего-то более портативного и удобного в работе. Для этой задачи идеально подходит Raspberry Pi OS, и именно поэтому я решил изготовить планшет на основе CM5 и сенсорного дисплея.

Это устройство стало чем-то средним между компьютером с сенсорным экраном и планшетом. Я выбрал версию CM5 с 4 ГБ, а для повышения производительности установил операционную систему на SSD NVMe, что сильно повысило скорость системы.

Для улучшения сигнала Wi-Fi и Bluetooth я добавил внешнюю антенну.

Корпус проектировался в Fusion 360, а детали я печатал на своём 3D-принтере в двух цветах для красоты.

В этой статье объясняется весь процесс создания планшета.

Вот всем хороши микроконтроллеры - маленькие, программируемые, "умные" - одно плохо: нельзя вот так просто так взять и включить, скажем, двигатель откатных ворот или группу прожекторов на объекте.
Двигателю нужно 220В, а то и 380, а микроконтроллер питается от 3.3.

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

Задача звучала как на полчаса: пусть Яндекс.Станция сама произносит вслух сообщения из Telegram-канала, без обращения к Алисе. По факту — несколько вечеров, потому что Яндекс не даёт из коробки простой возможности “скажи произвольный текст по внешнему событию”. Прошёл два тупика (виртуальные устройства и локальный TTS) и собрал рабочий пайплайн на Home Assistant + webhook. Рассказываю весь путь, включая то, что не сработало — тупики тут поучительнее итога.

ESP01 и ESP12 кажутся идеальными кирпичиками для самодельной автоматизации: стоят копейки, занимают минимум места, умеют Wi‑Fi и позволяют собрать полезное устройство буквально из нескольких модулей. Но стоит перейти от макетной платы к реальному корпусу, питанию, реле, датчикам и установке «на место», как начинается настоящая инженерная проза: пины внезапно мешают загрузке, реле щёлкает не тогда, питание проседает, корпус не герметичен, а вентилятор оказывается умнее, чем хотелось бы.

В этой статье я собрал свой практический путь — от выбора между ESP01 и ESP12 до проектирования платы, корпуса, прошивки и отладки устройства для управления вентиляцией в санузле. Здесь будет не только «как надо», но и честный список ошибок, тупиков и переделок: почему правило «семь раз проверь» для ESP особенно актуально, какие пины лучше не трогать, зачем тестировать питание заранее и почему иногда самое ценное в проекте — это не схема, а возможность спокойно обновить прошивку по воздуху и наконец-то лечь спать.

Ни для кого не секрет, что IoT‑устройства собирают огромное количество информации, в том числе личные данные пользователей и фиксируют их местоположение. А также они жёстко привязаны к конкретному производителю, т.е. пользователь зависим от конкретного производителя или бренда. Гаджеты совместимы с парой основных систем, но кроссплатформенность отсутствует. Устройства разных производителей часто не могут взаимодействовать друг с другом без дополнительных шлюзов. Универсального протокола связи устройств тоже нет. Из стандартов: Zigbee, Matter, Z‑Wave, Bluetooth, Wi-Fi — как следствие умные устройства плохо дружат между собой.

Раз уж я начал учить школьников как собирать на макетной плате цифровые схемы (в рамках подготовки демонстраций к мероприятию торговой палаты города Маунтин-Вью, Калифорния), то возникла необходимость написать для них инструкции. У меня тут же ожидаемо спросили, почему мне не подходят существующие инструкции от Make и других источников. Объясняю:

1. Все эти туториалы последние 55 лет переписывают друг от друга как использовать: 1) резисторы при светодиодах и 2) подтягивающие резисторы. У меня этого нет, потому что я использую LED толерантные к пяти вольтам, кнопки со встроенными подтягивающими резисторами, а также блок питания от USB которые генерит стабильные 5V вместо 9-вольтовой батарейки "Крона". То есть я удалил как кучу лишних резисторов на плате, так и необходимость объяснять законы Ома и Кирхгофа.

2. Эти туториалы часто описывают как строить генератор тактового сигнала из микросхемы 555, конденсатоов и резисторов. У меня этого нет, посколько я используют уже собранные генераторы тактового сигнала с AlExpress. Сборка такого блока самому не дает ничего полезного для обучения цифровому проектированию по направлении к микроархитектуре.

3. В мейкерских туториалах есть куча вещей, которые никогда не возникают в работе проектировщика современного чипа (JK-триггеры, SR-защелки), но нет того, что используется ежедневно (FIFO - микросхема CMOS 40105, приоритетный энкодер - CMOS 4532 итд).

Короче вот первые четыре страницы и фотки школьников с последней сессии: