В апреле 2026 года Canonical раскрыла 44 CVE в uutils. Это переписанная на Rust версия GNU coreutils, которая в Ubuntu идёт по умолчанию с 25.10. Раскрытие пришло из внешнего аудита, заказанного перед релизом 26.04 LTS. Большую часть уязвимостей нашли обычным ревью кода. Ни borrow checker, ни проверки clippy, ни cargo audit не поймали ни одной.

Этот аудит, пожалуй, самый чёткий из существующих примеров того, что Rust ловит, а что нет. Самый внятный разбор списка сделал Маттиас Эндлер в посте «Bugs Rust Won’t Catch» от 29 апреля. Эндлер ведёт консалтинг corrode и подкаст Rust in Production; недавно у него в гостях был Джон Сигер, вице-президент по инженерии в Canonical. Пост построен как разбор того самого раскрытия: 44 CVE распределены по восьми категориям; к большинству приложен git diff фикса.

Ниже разберу каркас Эндлера и добавлю два аргумента сверху. Первый: один из мейнтейнеров GNU coreutils в HN-треде показал бенчмарк, на котором рекомендованный Эндлером фикс не выживает. Второй: структурный аргумент про то, что 40 лет наслоённых POSIX-шрамов делают с любой переписью, независимо от языка.

29 апреля 2026 года Митчелл Хашимото объявил, что уводит свой Ghostty с GitHub. Цитата ушла на главную Hacker News через статью в The Register: «GitHub больше не место для серьёзной работы, если он каждый день блокирует тебя на часы».

Сам по себе уход одного человека, даже такого, как Хашимото, ещё не новость. Новость в другом: на главной HN на той же неделе оказалось ещё четыре истории про GitHub. Эссе Армина Ронахера про то, как мы жили до GitHub. Манифест команды Tangled про федеративные форджи. Тихий запуск голландской госплатформы для опенсорса на Forgejo. И жёсткий аудит безопасности того же Forgejo от Жюльена Вуазана. Если посмотреть на эти пять текстов вместе, складывается одна история.

Хашимото — не случайный пользователь GitHub. Сооснователь HashiCorp, после ухода оттуда автор Ghostty. И, по его собственным словам, «пользователь GitHub номер 1299, зарегистрирован в феврале 2008-го». Он же говорит про себя как про человека, который «листает задачи на GitHub с тех пор, когда у такого поведения ещё не было названия». Если GitHub для кого-то и был домом, то для него.

Необычным его пост делает разбор последнего месяца. Хашимото вёл журнал дат и ставил «X» против каждого дня, когда GitHub упал и помешал ему работать. «Почти каждый день стоит отметка X», пишет он. «В день, когда я пишу этот пост, я уже два часа не могу сделать ни одного ревью пулл-реквестов, потому что лежат GitHub Actions». The Register заметил, что пост вышел прямо перед инцидентом 28 апреля, когда пулл-реквесты перестали завершаться из-за падения Elasticsearch.

Знаете, кому 29 апреля стукнуло 30 лет? Спецификации FastCGI. Тридцать лет с 1996 года. Погодите. Эта заметка не про ностальгию по .fcgi-скриптам, которые на каждый запрос форкали отдельный процесс и которыми сегодня никто не пользуется. И не про CGI вообще.

Разговор о другом. У нас всех в проде между прокси и бэкендом обычно стоит HTTP. nginx перед Go-приложением, Caddy перед Python-сервисом, Apache перед PHP-FPM, неважно, поверх там HTTP/1.1 или HTTP/2. И вот Эндрю Айер на agwa.name к юбилею FastCGI собрал аргументы, что этот участок инфраструктуры всё это время сидит на не самом удачном протоколе. Айер основатель SSLMate, и в SSLMate всё крутится на FastCGI в проде уже больше десяти лет. Так что пишет не теоретически.

Заметка короткая и по делу. HN-тред собрал сотню комментариев, для 2026 года это не топ, но там пишут люди, которые знают, о чём говорят. Если попроще, аргумент такой: у HTTP как протокола между прокси и бэкендом есть два структурных бага, которых у FastCGI нет, и индустрия за тридцать лет так и не нашла повода переехать. А обсуждение в треде ушло дальше: почему вообще HTTP победил, если он хуже технически. И ответ оказался любопытнее самого аргумента.

Вчера вышел Zed 1.0. Пять лет работы, миллион с лишним строк на Rust, публичная превьюшка, которой ежедневно пользовались сотни тысяч разработчиков, и вот команда Zed Industries во главе с Натаном Собо запостила релиз 29 апреля 2026 года. Я лет пятнадцать живу в IDE от JetBrains. Пробовал VS Code. Пробовал Cursor. Гонял code-server на удалённой виртуалке. Ничего не приживалось. Zed прижился, и релиз 1.0 — нормальный повод объяснить, почему.

Если коротко: больше десяти лет любой «новый» редактор кода — это всё тот же продукт в новой обёртке. Обёртка зависит от того, что продают сегодня: AI, коллаборация, темы, новый вендор. А под обёрткой Electron. Тот же Chromium на каждое окно, тот же JavaScript на критическом пути исполнения, тот же RSS, к обеду уходящий в гигабайты. Sublime Text держал планку нативных редакторов все 2010-е, но это был закрытый продукт одного автора, без нормальной коллаборации и без AI истории. Zed стал первым за последние десять лет убедительным опенсорс-редактором с GPU-ускорением и AI на борту, который пересобрали с нуля и без всякого браузера под капотом. С релизом 1.0 эта ставка наконец сыграла.

Есть такой момент, знакомый каждому, кто долго работает в паре с AI. Сидишь в терминале, Claude генерит код, ты ревьюишь, правишь курс, снова запускаешь. Проходит пара часов, и ты понимаешь: никто не записал, что вообще произошло.

Ни один тикет не обновлен. Таймер не запущен. Чат на тысячу строк, но он испарится, как только закроешь сессию. А когда коллега спросит, что было сделано за день, ты будешь восстанавливать картину по памяти. Удачи.

Меня это достало. Заканчиваю марафон-сессию с Claude или Codex, ощущение, что гора работы сделана, а доска проекта все так же показывает Not Started. Тайм-трекинг? Какой тайм-трекинг. Разрыв между реальной работой и тем, как выглядит проект, стал просто нелепым.

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

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

Этот бинарник — sudo.

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

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

Недавно наткнулся на статью про Echovault на Хабре — инструмент для памяти AI-агентов, написанный на Python. Автор описывал ровно ту же боль, что и я испытывал месяцами. Идея хорошая, реализация — рабочая. Но Python. Я ничего не имею против языка, просто не мой выбор для инструментов, которыми пользуюсь каждый день. Люблю скомпилированные бинарники: кинул файл — и работает, без virtualenv, без pip, без «а какая у тебя версия питона». Поэтому я взял идею и переписал её с нуля на Go. Получился Pantry.

Расскажу, зачем это вообще нужно и что внутри.

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

Встречайте suex и sush – su и sudo в новом формате.

Эти современные решения, написанные на чистом C, появились как упрощенные альтернативы для тех, кто считает традиционные su и sudo чрезмерно сложными.