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

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

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

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

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

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

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

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

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

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

Мы (modal.com) создали этот словарь, чтобы решить проблему, с которой столкнулись при работе с GPU в Modal: документация фрагментирована, что затрудняет связь концепций на разных уровнях стека, таких как архитектура потокового мультипроцессора, вычислительная способность и флаги компилятора nvcc.

Десятилетия терминальных мультиплексеров, одна хроническая боль и маленькая тулза на 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'ами.
В этой статье я хочу разоблачить якобы стоящую за корутинами магию, сдёрнуть покровы и показать, что спрятано под столом у фокусника.

В статье я рассказываю, как из набора команд (free, df, ip, ps, uptime) собрать CLI‑утилиту на Bash, добавить аргументы, цветовую индикацию и упаковать всё в AUR как пакет system-monitor

Два года я исправно заносил деньги хостерам. Сначала это были копейки за пару vps, потом захотелось управляемую базу данных, потом s3 для бекапов, и вот я уже смотрю на счет в 40 долларов ежемесячно за проекты, которыми пользуюсь я и полтора моих друга.

В какой-то момент жаба победила. Я посмотрел на полку, где пылился списанный корпоративный ноутбук с мертвой батареей, и решил: пора.

Если вы думаете, что это история про успешный успех и экономию - вы ошибаетесь. Это история про боль, перегрев и Docker на bare metal, но я ни о чем не жалею.

Вводные данные были так себе.

Ноутбук 2015 года. Core i5, 8 ГБ памяти, ssd на 256. Экран разбит, клавиатура залита кофе еще прошлым владельцем.

Главный плюс ноутбука в качестве домашнего сервера - встроенный ups. Батарея держала минут 15, но этого хватало, чтобы пережить мигание света в подъезде и корректно погасить базу, если электричество отрубили надолго.

Я накатил туда ubuntu server, кинул ноутбук под шкаф в прихожей и подключил витую пару. Сразу совет: не используйте wifi для сервера, даже если роутер стоит в метре. Пакеты будут теряться, а вы будете терять нервы при дебаге, почему ssh отваливается каждые полчаса.

Иногда в архиве нашего сервиса анализа планов запросов к PostgreSQL встречаются примеры не очень эффективных, мягко говоря, запросов.

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

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

Привет, Хабр! В предыдущих статьях — «Rust без прикрас: где мы ошибаемся» и «Rust без прикрас: где мы продолжаем ошибаться» мы обсудили всякие неприятные грабли: бездумное использование unwrap(), игнорирование ошибок через let _ =, чрезмерное клонирование, проблемы с хвостовой рекурсией и прочие оплошности. Теперь пришло время взглянуть на другой пласт проблем.

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

Новая версия Debian 13 и релиз Proxmox VE 9.0 пришли почти одновременно, вызвав ажиотаж у клиентов. В статье рассказываем, как команда HOSTKEY адаптировала свои процессы, автоматизировала деплой и подготовила инфраструктуру под свежие релизы.