Представьте себе, что некий предприимчивый человек решил учредить свой первый бизнес. Он не умеет печь торты или замешивать тесто, но зато прекрасно знает рынок кухонного оборудования. Проанализировав все предприятия этой индустрии в Испании, он пришёл к выводу: если продавать новые печи пиццериям, кондитерским и пекарням, то достаточно занять буквально 10% рынка, чтобы стать миллиардером.

И вроде бы 10% совсем немного, когда смотришь на эту цифру в таблицах Excel.

Но учредитель мыслит стратегически. Он садится и разрабатывает план, который на бумаге выглядит безупречным. Согласно этому плану, нужно разработать более эффективную печь с инновационной технологией. Продать такую будет легко. Хотите повысить эффективность труда? Купите новую печь. Конец питча. У будущего учредителя есть опыт общения с инвесторами, и ему удаётся поднять достаточный капитал для создания MVP (минимально жизнеспособного продукта).

Не так давно число моих подписчиков в Bluesky перевалило за 20 000, о чём я даже не стал говорить. Естественно, я обратил на это внимание, но потом подумал, а в чём смысл? Далее будет пройдена очередная отметка, на которую я смогу указать, испытывая смешанные чувства. Фишка современных соцсетей в том, что они буквально засасывают тебя каким-то интересными событиями, но к концу дня это ведёт к чувству опустошённости. Возможно, именно поэтому, когда я наткнулся на топик с вопросом: «Какая твоя любимая соцсеть?», то ответил не Twitter, Bluesky и даже не Tumblr. Для меня это был форум новостных дизайнеров из середины 2000-х, который назывался Visual Editors. Честно говоря, работал он хреново. Там была удобная функция чата, которой часто пользовались дизайнеры, ожидавшие поздними вечерами корректуры своих страниц. Но сам форум постоянно и без предупреждения падал. Зато в плане коммьюнити он был выдающимся. Почему современные социальные сети не вызывают таких приятных чувств? Как вы уже поняли, сегодня я буду говорить о судьбе веб-форумов.

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

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

Моё изначальное предложение прозвучало просто: «Ему вполне должно хватить одного ядра и 2 ГБ RAM. Это же всего лишь лаунчер». Хотя даже 2 ГБ казалось будто бы мало, ведь речь о продакшене, а не о каких-то экспериментах на личном ноутбуке. Но как раз в таком мышлении и кроется проблема. В процессе развития сферы вычислений мы постепенно перестали всерьёз воспринимать небольшие числа при обсуждении ресурсов, так как дорожим устойчивостью системы. Но в продакшене нужно, наоборот, распоряжаться ресурсами более аккуратно.

Это прощальное послание я отправил своим коллегам, когда решил покинуть Google, где последние годы занимал должность ведущего инженера-архитектора в подразделении Android Security. На эту позицию категории «Independent Contributor» (сотрудник без подчинённых) я перешёл с поста директора, сняв с себя управленческие обязанности ради возвращения с семьёй в Австрию. Публикуя здесь копию этого письма, я хочу открыто показать, что больше не являюсь сотрудником компании и не могу выступать связующим звеном с отделами безопасности Android.

Как фанат Emacs я рад каждой встрече с этим редактором в любых контекстах. Случается это редко — всё же Emacs относится к нишевой категории, и в современной поп-культуре его востребованность невелика. В этой статье я разберу все известные мне упоминания этого редактора вплоть до июня 2026 года и продолжу вносить новые по мере их нахождения. В основной список я включил случаи, которые встречал на экране (в кино и сериалах), а также в комиксах и мангах. Книжные упоминания я решил выделить в отдельную категорию «Доска почёта».

Ну что ж, начнём.

С момента выхода PiKVM в 2017 году рынок IP KVM стал активно развиваться. Я протестировал почти все из этих устройств и готов дать объективную оценку каждому.

Для удалённого управления компьютером из любой точки LAN вы можете использовать инструменты вроде Remote Desktop, Screen Sharing или VNC. И если у вас нет собственной VPN, то полноценный удалённый доступ вам помогут обеспечить RealVNC или Raspberry Pi Connect, либо можете сами настроить сеть через Tailscale или Pangolin. Всё это прекрасные решения, как и SSH, если вам не требуется графический интерфейс.

Но бывают ситуации, когда вы не хотите запускать на ПК программу для удалённого управления. К примеру, когда я удалённо выполняю бенчмарки, мне не нужно, чтобы функция совместного использования экрана отнимала ресурсы системы. Или представьте, что у вас есть компьютер, к которому вам необходимо иметь возможность удалённо подключиться в любой ситуации. В таком сценарии, если этот ПК вдруг зависнет или по какой-то причине отключится, SSH и Screen Sharing уже не помогут.

И здесь на сцену выходит технология IP KVM. В передовые серверные решения она встраивается по умолчанию (к примеру, в HP iLO, Dell iDRAC или IPMI), но не у всех есть доступ к серверным материнским платам. И даже если он есть, BMC (Baseboard Management Controller) может оказаться сильно устаревшим, или же вы можете решить подключиться с использованием установленного GPU, а не встроенной VGA-графики.

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

И всё же использовать для планировки задач реальный cron вам, пожалуй, не следует. В 2026 году уже есть более продуманные варианты, и моим любимчиком является скромный таймер systemd. Я люблю таймеры systemd. И если вы о себе пока так сказать не можете, то я приведу аргументы, которые заставят вас пересмотреть свой взгляд.

У меня уже была установлена RTX 4080 с 16 ГБ VRAM. Её вполне достаточно для гейминга, но не для моделей, которые я хотел запускать локально. Так что следующим шагом было либо приобретение дорогущей карточки с большим объёмом памяти, либо поиск другого способа.

И я этот способ нашёл.

Я купил видеокарту для датацентра, у которой даже нет нормального коннектора PCIe, и подключил её к ПК через адаптер. Теперь у меня в системе 32 ГБ VRAM от двух GPU, на которых работает модель с 27 миллиардами параметров, выдавая по 32 токена в секунду. И обошлось мне это всего в £200.

Надвигающаяся угроза со стороны заточенных на криптографию квантовых компьютеров заставила срочно менять действующие примитивы асимметричной криптографии — обмен ключами (ECDH) и цифровые подписи (RSA, ECDSA, EdDSA) — которые уязвимы для квантового алгоритма Шора. Однако существующих симметричных методов криптографии (AES, SHA-2, SHA-3) или уровней их стойкости это не коснулось. ccc

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

AES-128, как и SHA-256, обеспечивает достаточную защиту от атак с применением квантовых компьютеров. В рамках перехода в постквантовую эпоху размер симметричных ключей изменять не требуется. Это почти единогласное мнение среди профильных экспертов и органов стандартизации, которое нужно распространить среди остальной части IT-сообщества. И дальше в статье я подкреплю это утверждение техническими аргументами со ссылками на авторитетные источники.

Если бы Кардинал Ришелье был программистом, он бы сказал: «Дайте мне шесть строк кода, написанных рукой самого профессионального C-программиста в мире, и я найду в них лазейку для вызова неопределённого поведения.

Никто не может написать безошибочный код на С или C++. И я говоря об этом как человек, который пишет на этих языках почти каждый день около 30 лет. Я слушаю подкасты по C++. Я смотрю выступления про C++ на конференциях. Мне нравится читать и писать на этом языке.

C++ послужил нам сполна, но на дворе 2026 год, и современная рабочая среда явно отличается от среды 1985 (C++) или 1972 (С).

И я далеко не первый, кто об этом заговорил. Помню ещё с десять лет назад читал статью какого-то известного человека, в которой он утверждал, что использование C++ вполне обоснованно можно подвести под нарушение закона Сарбейнза-Оксли (SOX). И хотя с остальной его критикой я не был согласен (как и с тем, что он путал «its» и «it’s»), конкретно с этим пунктом я никогда не спорил.

Мало того, со временем я всё больше убеждался в его истинности. На деле в С для возникновения неопределённого поведения (undefined behaviour, UB) есть гораздо больше возможных причин, чем вы могли предполагать.

Все знают, что двойное освобождение памяти, её использование после освобождения, выход за границы объекта (например, массива) и чтение неинициализированной памяти — это UB. Как ни крути, но в контексте работы с памятью C и C++ безопасными не назовёшь. Тем не менее даже эти ошибки продолжают совершаться повсеместно раз за разом.

В Wasp мы создаём фулстек-фреймворк — наподобие Rails или Laravel для JS, только ещё и расширенный на фронтенд. Мы с моим братом-близнецом начали этот проект в 2021 году, когда успешно прошли программу Y Combinator. За всё это время в общей сложности нам удалось привлечь $5 миллионов инвестиций.

Изначально мы хотели создать язык программирования, который бы абстрагировал типичные паттерны веб-приложений и в то же время позволял углубиться в любой стек (мы начали с React, Node.js и Prisma). Что-то вроде Terraform, но для стека веб-приложения, а не облачной инфраструктуры.

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

В этой статье я расскажу, почему нам эта идея казалась перспективной, какие уроки мы вынесли и почему заменяем свой язык на TypeScript при том, что сам Wasp внутренне остаётся всё тем же.

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

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

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

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

В течение последних десятилетий технический прогресс по большей части заключался в нахождении новых сфер применения полупроводников и разработке методов для их производства. Микросхемы теперь есть почти в любом автомобиле, воздушном судне или бытовом приборе. Светодиоды уверенно заменяют более старые и менее эффективные способы генерации света (вроде ламп накаливания). Солнечные панели стали самым быстро развёртываемым источником энергии в истории. Разработка полупроводниковых лазеров дала нам оптико-волоконную связь. Приборы с зарядовой связью (ПЗС) и КМОП-датчики используются для цифровой визуализации… Этот список можно продолжать долго.

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

Несколько лет назад я присутствовал на встрече разработчиков, где один из участников задал, казалось бы, простой вопрос: «А какой фреймворк выбрать для написания десктопного приложения под Windows?»

Воцарилась мёртвая тишина. Спустя какое-то время, кто-то предложил WPF. Ещё один человек назвал WinUI 3. Третий упомянул Electron. В итоге беседа ушла в сторону, и ответ на поставленный вопрос так и не был дан.

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

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

Если вы пользуетесь только интерфейсами социальных сетей и видеохостингов, поглощая рекомендации алгоритмов и ежедневно машинально пролистывая одну и ту же горстку сайтов, то по-настоящему живого интернета не видели. Такой опыт раскрывает, пожалуй, лишь 3–5% от реального потенциала веб-среды.

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

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

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

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

Эпичная история установки всех* расширений для браузера Firefox. Это был непростой процесс, который-таки увенчался успехом. Не обошлось в нём и без некоторых любопытных поворотов, неразрешённых вопросов и помощи друга.

Как выяснилось, всего у Firefox 84 тысячи расширений. Вроде бы не особо много, и по факту даже меньше 50 ГБ. Так что приступим!

*Всех, кроме 8, которые мы не соскрейпили (или которые удалили в промежутке между моментом проверки их списка на сайте и запуском скрипта), и 42, которые отсутствовали в extensions.json.¹ Так что чисто технически мы установили 99,94% всех расширений.

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

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