Hacker News Digest

Я — низкоуровневый программист, чья идентичность строилась на глубоком понимании деталей: архитектуры процессоров, работы памяти, машинного кода и тонкостей языков вроде C или Rust. Я не просто писал код — я исследовал, как работает машина, считая такты, пишая OS-игрушки и отлаживая вручную. Для меня программирование было актом познания, а не создания утилит. Но индустрия сместилась в сторону абстракций, архитектурного мышления и «vibecoding», где ценят умение оперировать высокоуровневыми концепциями, а не знание того, что происходит под капотом. Возможности применить мои сильные стороны исчезают: компании предпочитают нанимать тех, кто работает с фреймворками, а не с ассемблером или кэш-линиями. Рост LLM усугубил кризис — теперь даже оптимизация кода и объяснение сложных концепций автоматизируются, делая мою экспертизу избыточной. Я физически не могу работать с большими кодовыми базами или архитектурой, поскольку мне нужно держать всё в голове, а LLMs, которые я пробовал, быстро превосходят моё понимание проекта, лишая меня смысла и контроля. Это привело к экзистенциальному кризису: я чувствую себя вытесненным, невостребованным, а моя страсть к низкоуровневому программированию — всё больше превращается в неприбыльное хобби, вытесняемое энтузиастами, ищущими признания, а не глубины. Я больше не вижу места для себя в индустрии.

Потеря глубокого понимания деталей в программировании вызывает эмоциональный кризис у низкоуровневых разработчиков, но выявляет ниши, где этот навык остаётся критически важным — кибербезопасность и оптимизация производительности, где LLM пока не могут заменить человеческое понимание архитектуры. Многие испытывают горе не из-за потери продуктивности, а из-за смерти идентичности, построенной на глубоком понимании машинных деталей — это не адаптация, а прощание с ушедшей эпохой. LLM не способны автоматически находить горячие участки кода или оптимизировать низкоуровневый код без чёткого понимания архитектуры и целей — они беспомощны без человеческого контекста. Работы в кибербезопасности — исследование уязвимостей, реверс-инжиниринг, анализ инцидентов — остаются областями, где детали определяют успех, и LLM не могут полностью заменить экспертов. Современные системы стали слишком сложны для удержания в голове — это не новость, но LLM усугубляют проблему, убирая стимул к глубокому пониманию, заменяя его поверхностным доверием к автоматизированным решениям. Спор: LLM генерируют ужасно неоптимизированный низкоуровневый код — например, снижение first paint с 4500ms до 1000ms в Claude, как заявлено, невозможно без ручной оптимизации, и это не достижение LLM. Спор: Один разработчик утверждает, что его коллега, почти не использующий LLM, остаётся самым ценным членом команды — он лучше всех понимает код, отвечает на вопросы и ловит баги в ревью, что опровергает тезис о неизбежной замене людей. Совет: Специализируйтесь на тех частях системы, где агентные потоки слишком рискованны — там, где ошибка может стоить миллионы, а не просто замедлить API — именно там глубокое понимание остаётся незаменимым. Совет: Используйте LLM как новый 'процессор' для логики — сосредоточьтесь на создании языков и систем для их контроля, что возвращает интерес к фундаментальным принципам информатики, а не к написанию кода. Совет: Ищите ниши, где ручная работа ценится — например, создание 'hand-made' ПО, где пользователи готовы платить за безупречный опыт, а не за быструю, но шаблонную автоматизацию. Совет: Переключитесь с написания кода на управление и поддержку — как один инженер, перешедший в менеджмент, заметил: люди, выполняющие агентную работу, требуют больше эмоциональной поддержки, и это новая возможность. Инженеры, которым важно понимание, а не построение, чувствуют себя потерянными — но это не слабость, а естественная реакция на уничтожение той культуры, где глубина ценилась выше скорости. Исторически, как и при промышленной революции, автоматизация уничтожает ремесло, но не устраняет потребность в мастерстве — она просто смещает его в более узкие, менее массовые ниши. Понимание компиляторов, кэширования CPU, TCP-стеков и пайплайнов остаётся ценным — даже если вы не пишете ассемблер, это знание позволяет находить скрытые узкие места, которые LLM не видят. Совет: Примите, что вы больше не сможете держать в голове всю систему — но это не значит, что вы перестали быть инженером; это значит, что ваша роль теперь — быть тем, кто понимает, что нельзя доверять автоматизации. LLM — это машина для интерполяции, а не для творчества; они не способны на открытия, как специальная теория относительности, если их обучали на данных до 1904 года — они не понимают, а пересобирают.

В архитектуре AMD Zen 2 инструкция RDRAND16 ошибочно устанавливает флаг CF=0 при генерации нуля, что заставляет программы перезапрашивать значение. Проблема заключается в ложном флаге ошибки, а не в самом генераторе. В поколениях Zen 3 и Zen 4 эта ошибка отсутствует. Официальное уведомление AMD касается RDSEED, а не RDRAND, и не охватывает Zen 2. Пользователям рекомендуется проверить версию BIOS и микрокода, так как подобные баги в Zen 2 исправлялись ранее. Для минимизации рисков рекомендуется: 1. Использовать абстракции, автоматически повторяющие попытки при CF=0. 2. Рассматривать аппаратный RNG лишь как источник энтропии для CSPRNG, а не как источник готовых значений. 3. Применять постобработку данных. Ядро Linux уже смешивает энтропию из разных источников через ChaCha8 и Blake2b, что делает сторонние XOF-решения избыточными. Специалисты отмечают, что отсутствие нуля редко критично, так как RDRAND обычно лишь семенит CSPRNG, а криптографии важна высокая энтропия, а не равномерное распределение. Тем не менее, подобные ошибки могут не выявляться стандартными тестами и требуют анализа распределения значений (например, через гистограммы). В некоторых критических системах на Linux-серверах RDRAND отключают как источник энтропии из-за повторяющихся багов AMD.

Джон Кармак размышляет о том, как навыки программирования, подобно боевым искусствам, эволюционируют от практических, низкоуровневых умений к более абстрактным и спортивно-рекреационным формам. Он вспоминает, как после Второй мировой войны боевые искусства в Японии были переосмыслены: дзюдо позиционировалось как аналог западной борьбы, а кэндо — как фехтование, что позволило им сохраниться несмотря на запрет. Аналогично, навыки вроде ручной сборки opcode в шестнадцатеричном виде или программирования на ассемблере, хотя и всё ещё существуют в нишах (например, в проектах вроде FFmpeg), уже не являются основными для большинства разработчиков. Рост ИИ ускоряет этот переход, делая многие традиционные навыки менее критичными.

Кармак предполагает, что программирование движется от "-джитсу" (практичное, bojutsu-подобное мастерство) к "-до" (путь, философия, как в джиу-джитсу → джидо), шутливо предлагая термины вроде "кодо". Он отмечает ценность ретрокомпьютерной сцены как места сохранения старых навыков из любви к делу, но предостерегает от становления "}}><ёжным мастером кунг-фу", чьи отточенные, но устаревшие навыки оказываются бессильны перед более гибкими и современными подходами — сравнивая это с тем, как Мусаси, вероятно, оценил бы преимущество штурмовой винтовки над мечом. Главное — не цепляться за форму, забывая про суть эффективности.

Тред добавляет критический взгляд на переход к AI‐помощи: подтверждает, что инструменты снижают «случайную» сложность (синтаксис, поиск API), но подчёркивает риски потери фундаментальных навыков и необходимость сохранять ручное кодирование для независимости. Указывает, что сравнение программирования с боевыми искусствами часто некорректно. Спор: Некоторые (glimshe, acedTrex) считают, что AI освобождает от рутины и позволяет сосредоточиться на архитектуре; другие (tkel, sriram_malhar) опасаются, что упрощение приводит к утрате базовых навыков и «потере поколения», которое училось бы «жёстко». Большинство согласны, что AI уменьшает «случайную» сложность, позволяя быстрее воплощать идеи в коде. Несколько (uncomputation, darepublic) подчёркивают стратегическую важность сохранения навыков ручного кодирования: иначе организации становятся зависимыми от внешних AI‐платформ, которые могут быть отключены. Совет: m3kw9 — использовать AI для генерации кода, но проверять промпты, ограничивать объём генерируемых модулей и тщательно тестировать, чтобы избежать нечитаемого кода. Совет: acedTrex — «прокачать» новые инструменты, даже если они болезненны, чтобы уметь переключаться между ними и не отставать от отрасли. Критика аналогии с боевыми искусствами (tkel, jmull, maplethorpe): программирование — совместный процесс, а не соревнование, поэтому сравнение с «мма‐бойцом» вводит в заблуждение. Спор о Джоне Кармаке: postonce и pipeline_peak считают, что он давно не вносит заметных вкладов; некоторые (hermitcrab) признают его опыт и используют его инструменты, но сомневаются в реальном прогрессе. Совет: evolve-maz — сосредоточиться на архитектурных паттернах и высокоуровневых целях, позволяя LLM заниматься рутиной, но сохранять контроль над дизайном. venvio отмечает FOMO‐эффект: многие стремятся использовать AI, чтобы не отставать, хотя нет убедительных доказательств значительного повышения продуктивности. Совет: phmx — предостерегать от замены фундаментальных знаний бесполезными теоретическими конструкциями («борьба с острыми мечами»), советуя сохранять практический опыт.

Интерактивный эксплорер исходного кода Linux kernel позволяет просматривать дерево файлов и структуры данных, открывать исходники для изучения. Гид начинается с первой главы "Understanding Linux Kernel Before Code": ядро — не процесс, а всегда присутствующая система, мост между аппаратным и ПО; оно обслуживает пользовательские процессы через системные вызовы, прерывания и планировщик; организована в слои — виртуальные, отображенные, изолированные и контролируемые.

Рекомендуемые файлы для изучения: init/main.c, kernel/fork.c, include/linux/sched.h, arch/x86/kernel/entry_64.S. Тест знаний проверяет: разницу kernel и процесса (kernel — не процесс, а сама система), способы обслуживания (оркестрация syscalls, interrupts, scheduling), характеристики слоев (virtual, mapped, isolated, controlled). Гид включает 9 глав — от системных основ до scheduling, I/O и virtualization, с веткой @master.

• Пользователи хвалят интерактивный гид по исходникам Linux kernel как удобную "карту" для новичков, сравнивая с Талмудом и инструментами вроде Elixir Bootlin.
• Отмечены баги: ошибки загрузки файлов (entry_64.S), GitHub API rate limits, проблемы с сертификатом .dev, мобильной версией и позиционированием в файлах.
• Сравнения с Elixir (лучше поиск, теги, мобильность); пожелания AI-объяснений, графов зависимостей, локального деплоя и версий для CPython/Emacs/Vim.
• Критика: отсутствие поиска/редактирования/grep, слабые квизы (возможно AI-generated), ожидания большего от "AI-эры".

microsoft/BASIC-M6502 — официальный репозиторий Microsoft BASIC для процессора 6502, версия 1.1.
Расположен исходный код на ассемблере 6502, включая оригинальные комментарии 1978 г. и лицензионные файлы.

• Microsoft выложил исходники MS-BASIC для 6502 с «коммитом 48 лет назад» и пасхалкой WAIT 6502,X, которая выводит «MICROSOFT!».
• Код — один 162-КБ файл без модулей; удивляют старые редакторы и скорость сборки на PDP-10.
• В комментариях всплывают Applesoft BASIC, Commodore, Ohio Scientific и другие наследники этой версии.
• Пользователи делятся ностальгией, просят открыть Z80- и VB6-порты, обсуждают лицензию и «AI-аромат» README.

Репозиторий FFmpeg

• 120 755 коммитов, 38 веток, 408 тегов, размер 271 МиБ
• Языки: C 90 %, Assembly 8 %, Makefile 1 %, остальное <1 %

Ветка master

• Последний коммит: a2cfaf1 — avformat/mov: передавать индекс потока в sanity_checks для HEIF
• CI: все проверки успешны (linux-amd64, linux-aarch64, Windows, lint)

Ссылки

• ZIP | TAR.GZ | BUNDLE

Последние изменения

• libavformat: передача индекса потока в sanity_checks для HEIF (James Almer)
• libavcodec: очистка pu_info в rv60dec
• fftools/ffmpeg_mux_init: 64-битные вычисления score
• libswscale: выравнивание на 8 строк для planarCopyWrapper
• doc/examples: замена sleep на av_usleep
• presets: удалены устаревшие пресеты iPod

• FFmpeg ушёл с GitHub на самостоятельный Forgejo, отказавшись от рассылок и ускорив навигацию по файлам.
• Пользователи жалуются на защиту Anubis с «аниме-девочкой»: ошибки «Invalid Response», пропадающий CSS, проблемы на Android.
• Критика мотива «не Microsoft» и вопросы: почему именно Forgejo, а не GitLab/Gitea.
• Сторонники отмечают суверенитет и удобство, противники — нестабильность и «нелепый» брендинг.