Все потоки

Отдельное спасибо Сергею Киселеву (https://www.malinov.com/) за огромную работу, которую он проделал, чтобы мы все могли найти ответы на свои вопросы про IBM PC/XT и не только.

Дальше будет очень много текста (черновик около 40 страниц). Не столько технического, сколько «научно-популярного».

Итак, IBM-PC (XT), он же IBM 5150/5160. Я здесь пишу так нестандартно через дробь, потому что принципиальной разницы между чистым PC и PC/XT нет. Это был по сути просто рестайлинг, как сказал бы автолюбитель. Добавили оперативки, обновили BIOS и OS, сделали поддержку HDD, убрали поддержку (разъем) магнитофона, заменили блок питания на более мощный. В общем, принципиальная разница только в том, какой BIOS установлен.

Сначала я хотел сделать 5150, который казался мне более простым, но когда погрузился в тему, понял, что если уж делать, то 5160. Дальше я буду для краткости называть его просто ХТ.

Вообще весь текст будет чем-то средним между техническим описанием и литературой. Думаю, что технические подробности уже мало кому интересны. Это скорее развлечение, чем что-то полезное. Но на вопросы, если такие будут, отвечу.

Итак, делаем ХТ. В сети не сложно найти подробное описание ХТ в виде pdf-фалов. Инженеры IBM оставили очень подробное описание, по которому можно просто собрать полностью оригинальную конструкцию. Там есть абсолютно все, включая полный листинг BIOS.

Но повторять ту машину из начала 80-х нет большого смысла, да и не интересно. Интересно сделать свою версию. В этом же и была прелесть PC – свои версии делали все, кто хотел.

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

TL;DR Flipper One — это наша попытка переосмыслить, чем может быть Linux кибердек. Это огромный проект, поэтому мы открываем процесс разработки и просим сообщество о помощи.

В Flipper One мы поставили перед собой амбициозные задачи:

— Создать самый открытый и хорошо документированный ARM-компьютер в мире с полной поддержкой в мейнлайн-ядре Linux — чтобы можно было скачать ядро c kernel.org и оно сразу работало на Flipper One.

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

— Слепить нестандартную аппаратную платформу из микроконтроллера и CPU и портировать кучу кода на уровень MCU.

— Переосмыслить как люди используют Linux и разработать свой GUI-фреймворк с обертками существующих CLI-утилит.

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

Предыстория

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

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

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

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

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

Получится ли сделать полноценную 3D-игру на Qt Quick3D?

Именно такой вопрос у меня возник, когда я начал изучать Quick3D. Казалось бы, рендер и партиклы есть, базовая физика в лице Quick3D Physics тоже присутствует. Пример CharacterController из Qt указывал на то, что проблем быть не должно.

Но хотелось проверить это самому на чём-то реальном.

Поскольку моделлер и художник из меня никакой, да и в геймдеве опыта у меня меньше нуля, я решил переписать Quake — любимую игру своего детства. В ней я провёл сотни (тысячи?) часов, играя в мультиплеер на бесплатных серверах МТУ-Информ через модем US Robotics 33600.

В итоге получился проект Kwayk — попытка переписать Quake на Quick3D.

В последние годы для команд, которые работают с зарубежной инфраструктурой из России, обычный корпоративный VPN перестал быть чем-то, что можно один раз настроить и забыть. OpenVPN, WireGuard, IPsec, различные TLS- и QUIC-обёртки могут работать стабильно месяцами, а потом внезапно начать деградировать: где-то соединение не устанавливается, где-то режется UDP, где-то DPI начинает узнавать сигнатуры, где-то провайдер меняет правила фильтрации.

Для компании это превращается не в техническую мелочь, а в операционный риск. Инженеры не могут попасть на серверы. DevOps не может проверить прод. Администратор не может забрать бэкап. Пентестер не может подключиться к стенду заказчика. При этом инфраструктура может находиться в Европе, США, Азии или у любого другого зарубежного провайдера, а сотрудники — физически находиться в РФ.

В какой-то момент мы пришли к простой мысли: если из корпоративной сети ещё можно установить исходящее SSH-соединение, то можно попробовать использовать сам OpenSSH не только как инструмент администрирования, но и как транспорт для L3-туннеля. В OpenSSH для этого давно существует режим ssh -w, который поднимает туннель через tun-устройство.

Идея статьи не в том, чтобы объявить ssh -w «лучшим VPN на все времена». Это не замена WireGuard для нормальной постоянной инфраструктуры и не серебряная пуля против любых сетевых ограничений. Но это очень полезный аварийный и корпоративный вариант: работает поверх обычного SSH, не требует отдельного VPN-демона на сервере, может быть поднят на дешёвом VPS, использует привычную модель ключей OpenSSH и позволяет строить полноценную маршрутизацию на L3.

Я хотел запускать Claude Code через подписку ChatGPT/Codex. Без OpenAI API key и без потери привычных вещей: инструментов, скриншотов, /compact, длинных сессий и нормальных ошибок.

На бумаге это выглядит как простой локальный прокси. На практике пришлось переводить не только JSON, но и поведение Anthropic API: потоковые события, вызовы инструментов, лимиты контекста, файлы, картинки и типы ошибок.

Так появился мой open source fork Claudex. Репозиторий: github.com/pilc80/claudex. Лицензия - MIT.

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

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

Сегодня мой умный дом уже давно вышел за рамки хобби и превратился в полноценную систему управления квартирой. В ней работает контроллер и больше 100 модулей ввода-вывода. Если говорить языком цифр — это свыше 700 входных сигналов и около 300 выходных. Умный дом охватывает практически все инженерные системы квартиры.

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

Эта статья – попытка собрать всё, что реально работает на май-июнь 2026 года. С ценами, ссылками, граблями и местами, где можно влететь на деньги или на статью КоАП.

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

Стек выбирал не по хайпу, а по принципу «доеду и не утону в обслуживании»: FastAPI (быстро, асинхронно, автодоки), Next.js на React (SSR из коробки — критично для SEO), PostgreSQL (SQLite кончился на первых же конкурентных записях), Redis для кэша и рейт‑лимитов. Nginx + systemd на обычном VPS. Никакого Kubernetes — для одного это способ обслуживать инфраструктуру вместо разработки.

На вопрос «Чем локальная модель лучше коммерческой top‑quality модели от Anthropic, OpenAI или Google?», — обычно отвечают: приватность. На самом деле это не совсем так. Приватность важна, но не только она. У локальных моделей есть более важные качества, которые я покажу в этой статье.

^{Pfc. Anh Siev}

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

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

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

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

Самое любопытное, что это второе направление, так же, как и первое, оказало существенное влияние на жизнь человечества! 

Итак, о чём же идёт речь? 

12 мая 2017 года мир столкнулся с беспрецедентной киберкатастрофой. Больницы разворачивали машины скорой помощи прямо на ходу, вставали конвейеры автозаводов, парализовало серверы банков и министерств в 150 странах. На экранах сотен тысяч компьютеров загорелось агрессивное красное окно шифровальщика WannaCry с тикающим таймером.

Но самое поразительное в этой истории — не масштаб ущерба, оцениваемый в миллиарды долларов. Самое поразительное то, что этот цифровой «франкенштейн» был собран из утекшего в сеть секретного кибероружия АНБ США, а остановил его 22-летний аналитик-самоучка с темным прошлым, просто зарегистрировав бессмысленный домен за 10 баксов.

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

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

Картинка: Von Viajestelar

Всем хороши современные способы аддитивной печати — они позволяют создавать произвольной формы объекты с помощью компактного 3D-принтера даже просто на дому. 

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

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

Однако нет, не тут-то было: мне приходилось видеть в своё время усреднённую статистику по разным видам производств, которая однозначно говорит о том, что установка крепежа занимает вплоть до 70% времени от сборки изделия! О_о 

Таким образом, здесь имеется серьёзный потенциал для улучшений, что мы и рассмотрим в статье ниже… 

Привет, Хабр! Меня зовут Юрий Соловьёв, я ведущий инженер в команде экосистемы Tarantool. С опытом я пришел к тому, что конфигурация должна иметь строгую спецификацию, так же как и HTTP API. В этой статье я предлагаю альтернативный подход на базе protobuf и постараюсь показать, что это не избыточная сложность, а необходимый уровень инженерной гигиены — особенно для систем, рассчитанных на долгую и стабильную жизнь. Это в какой-то мере технорассказ, которым я хочу поделиться — и именно в такой форме.

Автономные агенты в разработке уже встроены в CI/CD живых команд, закрывают реальные тикеты и пишут код, который идёт в прод. Проблема не в том, что они это делают плохо, а в том, что метрики при этом выглядят слишком отлично.

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

Полчаса в день у меня уходило на ручной обход шести нод Proxmox через веб-интерфейс — он показывает по одной ноде за раз. И часть рутины всё равно проскакивала: задание PBS остановилось — никто не заметил, ZFS scrub отключили на maintenance и забыли включить, на ноде накопились pending kernel updates, и о них узнаёшь, когда уже надо ребутить.

На Proxmox-кластере, который я администрирую, после миграции с проприетарного гипервизора этот операционный долг копился особенно быстро: отключённые таймеры scrub, остановленные после рестарта PBS задания резервного копирования, дрейф конфигурации между нодами после мажорного апгрейда.

Стандартный путь — полноценный observability-стэк: Zabbix или Prometheus + Alertmanager + Grafana. Это правильный путь, но он плохо подходит к задаче «быстро получить единый экран по Proxmox-кластеру». В этой статье — про другой вариант: лёгкий read-only слой над Proxmox/PBS, который разворачивается за несколько часов и закрывает первый уровень видимости. Инструмент называется Pulse — где он работает, где нет, и что выяснилось в первый месяц эксплуатации.

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

На связи Станислав Грибанов, я руководитель продукта NDR компании «Гарда», автор блога «Кибербезопасность и продуктовая экспертиза для бизнеса».

Сегодня хочу поговорить о пользе NetFlow и сетевой телеметрии для защиты сетей от хакерских атак. Тема эта не новая, но вокруг неё до сих пор существует множество противоречий.

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

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

Под катом я расскажу, как можно детектировать угрозы на основе метаданных сетевого трафика без анализа payload, в частности, сетевой телеметрии.

Сегодня мы расскажем необычную историю легендарного Т9, которая чуть не закончилась крахом для своих создателей. (А еще о том, как буддизм помог стартапу).