Собрал 6 AI-роутеров с бесплатным доступом к Claude, GPT, DeepSeek, Qwen и другим моделям. Показываю, что реально дают после регистрации: баланс, доступные модели, лимиты и нюансы работы через API.

Дядя Хашимото сказал разобраться, я попытался. Речь про его эссе «Everyone Should Know SIMD»: SIMD должен знать каждый разработчик; примеры там на Zig, но суть от языка не зависит. Мой язык - Go, и в февральском обзоре Go 1.26 я написал про новый SIMD-пакет грустную строчку: «поддержка ARM64 планируется в будущих версиях».

Будущее пришло быстрее, чем я ждал: в go1.27rc2 пакет simd стал портируемым, и один Go-код разворачивается в Neon на Apple Silicon и в AVX2 на Intel. У меня под рукой обе машины: Mac на M3 Pro, где собиралась первая версия этих бенчей, и Linux-десктоп на i9-14900KF. Впереди проверка обещания портируемости на живом железе: один исходник, два дизассемблера, две пачки замеров. Ассемблер писать не будем, весь код запускается копипастой; целиком он лежит в репозитории dsbasko/sandbox-simd.

Речь о процедурно‑параметрическом программировании, о котором почти никто не пишет. Я реализовал одну и ту же задачу в ООП и в этой парадигме и сравнил их численно. Одна из метрик разошлась в 6 раз.

Локально docker-compose.yml обычно выглядит «рабочим» ровно до момента, пока сервис не уезжает на сервер. Потом внезапно заканчивается память, контейнеры не поднимаются после падения, логи разрастаются на десятки гигабайт, а Docker продолжает считать зависшее приложение живым.

В статье — пять настроек Compose, про которые почти всегда вспоминают уже после первого инцидента в проде: лимиты ресурсов, restart policy, healthcheck, ротация логов и работа с volumes.

clone() в Rust часто появляется в коде в тот момент, когда borrow checker снова «мешает просто дописать фичу». Компилятор успокаивается, задача закрывается, но в проекте постепенно накапливаются лишние копирования, аллокации и API, которые требуют владения там, где хватило бы ссылки. В статье разберём типичные места, где clone() используют как затычку: от Vec и String до замыканий, HashMap и многопоточного кода.

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

Нужен был реестр артефактов. Показать студентам цепочку поставки софта: сборка, тесты, push в реестр, деплой. Стандартная задача, казалось бы. "Вошли и вышли, приключение на 20 минут."

Растянулось на несколько месяцев.

В итоге написал свой реестр. Один бинарник. 7 форматов. 12 МБ RAM. Без базы данных.

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

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

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

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

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

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

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

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

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

Пополнение «виртуалки» возможно в любой фиатной валюте, с карт РФ по СБП, в крипте. Сама карта принимается во всех странах мира.

Десятилетия терминальных мультиплексеров, одна хроническая боль и маленькая тулза на C, которая наконец всё починила.

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

Нет сети. Нет USB. Нет компилятора. Нет интерпретаторов вроде Python. Возможно, даже нет привычных утилит (dd, xxd, objdump, hexdump). Есть только shell и встроенные команды.

Звучит как шутка, пока это не становится реальным сценарием:

14 месяцев назад я начал разрабатывать гонку. Идея была простой — с дедлайном 4 месяца сделать простую игру без пафоса. Ну, любой разработчик знает, что произошло дальше: без пафоса не вышло.

Вероятно, вы знаете, что если запустить ядро Linux без корневой файловой системы или файла initramfs, то оно упадет с сообщением о панике ядра.

Но возможна ли работа ядра Linux без этих, вроде бы обязательных компонентов? Ответ на вопрос — да, возможна, но использовать такие возможности в конечном продукте не стоит.

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

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

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

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

Привет! Этот проект стал для меня важным шагом в мир embedded-разработки: первое устройство с полностью собственной печатной платой, спроектированной с нуля в KiCad.

Я новичок в проектировании PCB-устройств, так что могу ошибаться в некоторых нюансах. Хотя у меня уже есть большой опыт в электротехнике, с хорошим знанием схемотехники и прочего, если заметите неточности или улучшения — не стесняйтесь, указывайте в комментариях, буду рад конструктивной критике!

Получилась миниатюрная игра на реакцию для двух игроков на базе ATmega328P.

Летом мне попалась статья Вадима Башурова «История игрушки» 2011 года про создание игры «Поле Чудес» в далёком 1992 году — очень рекомендую, если вы, как и я, ее пропустили. Вадим упомянул, что исходники, к большому сожалению, утерялись. Мне очень захотелось восстановить их хотя бы в каком‑то виде, и я решил заняться этим на досуге.

Цель простая: кросс-компилируемый 16-битный .exe для MS-DOS, который повторяет логику оригинала и использует оригинальные ресурсы.

Статью я построю как небольшой туториал по реверсу 16-битных DOS‑приложений для начинающих и пройдусь по ключевым алгоритмам и тому, как в игре реализован игровой процесс. Желательны базовые знания 16-битного ассемблера и C.

eBPF давно перестал быть узкоспециализированной игрушкой для kernel-энтузиастов и исследователей внутренностей Linux. Сегодня с ним, так или иначе, сталкиваются не только SRE, но вообще все, кто разрабатывает системы, близкие к сети, производительности или безопасности: от авторов сетевых плагинов (CNI) и прокси, до разработчиков кастомных агентских решений, observability-инструментов и low-level инфраструктурных компонентов. Даже если вы никогда не писали eBPF-код руками, есть хороший шанс, что он уже работает в вашей системе — тихо, незаметно и с довольно широкими полномочиями.

Чаще всего eBPF проявляется через удобные CLI, библиотеки и дашборды: установили агент, включили, и внезапно система знает о происходящем больше, чем strace, tcpdump и половина метрик вместе взятых. Но за этим комфортом скрывается нетривиальный механизм исполнения пользовательского кода прямо внутри ядра Linux — с жёсткими правилами валидации, ограниченной моделью исполнения и целым набором архитектурных компромиссов, о которых обычно не принято говорить в маркетинговых описаниях.

Думаю, многие согласятся, что реализация корутин в C++20 с первого взгляда выглядит страшновато, а документация скорее более запутывает, чем вносит ясность. Многие воспринимают работу приостанавливаемых функций как некую магию со своими странными co_abracadabra()'ми и прочими promise_type'ами.
В этой статье я хочу разоблачить якобы стоящую за корутинами магию, сдёрнуть покровы и показать, что спрятано под столом у фокусника.