Hacker News Digest

В 1999 году Netscape 4.51 включал в себя два 512-битных RSA-корневых сертификата от канадского CA E-Certify: один для SSL («Gold Server»), другой для S/MIME («Gold Client»). Эти ключи были удалены из браузера в 2002 году, но их можно было факторизовать на обычном настольном компьютере. Автор использовал CADO-NFS на Ryzen 9 5950X: первый ключ разложился за 32 часа, второй — за 29 часов. Полученные приватные ключи позволяют выдавать сертификаты, которые Netscape 4.51 принял бы как валидные, если бы системные часы были установлены до 16 октября 2003 года — даты истечения срока действия корней. Для проверки работы таких сертификатов автор создал кастомный TLS-сервер в Go, имитирующий устаревший стек Netscape, и разместил его на e-certify.fly.dev. SSL Labs оценил сайт как «F» из-за множества уязвимостей, что ожидаемо для такого archaic setup. Помимо E-Certify, в архивах браузеровourily встречаются другие тестовые 512-битные ключи, например, от VeriSign для подписи кода в IE 3.02, которые также легко факторизуются — один из них был разложен за час на GPU-кластере. Это демонстрирует, насколько слабой была криптография в раннем вебе и как быстро устаревают даже тогдашние «стандарты».

В 1999 году факторинг RSA-512 требовал ~292 CPU-года и занял около 7 месяцев на сотнях академических машин, что подтверждало его уязвимость. Современный потребительский процессор (Ryzen 9 5950X) с CADO-NFS справляется за 29–32 часа, что соответствует прогнозам по закону Мура. Для эмуляции старого Netscape 4.51 пришлось создать собственный минимальный SSL-v3-сервер, так как Go-библиотеки не поддерживают SSL-v2/v3 и 40-битные экспортные наборы. В конце 1990-х большая часть трафика была незащищённой или использовала статические ключи, поэтому реальная угроза от факторинга 512-битных сертификатов была ограничена. Стоимость факторинга растёт экспоненциально с длиной ключа: переход к RSA-1024 значительно усложняет задачу, и её практическая выполнимость при текущих темпах развития техники остаётся под вопросом. Спор о сохранении зашифрованного трафика для будущего расшифрования: один участник считает это возможным, другой — маловероятным спустя более десяти лет. Для воспроизводимости исследований рекомендуется использовать открытые реализации (например, CADO-NFS) и документировать процесс создания сертификатов. При использовании выводов LLM необходимо вручную проверять их достоверность.

В середине XIX века Париж столкнулся с эпидемиями холеры, и общественная мочеиспускание стало восприниматься как угроза здоровью. Вместо жестких мер вроде шипов и бетонных выступов — «empeche pipi» — город внедрил изящные писсуары: миниатюрные киоски с коваными цветами, витражами и даже львиными головами. Эти сооружения были не просто функциональны — они были архитектурными объектами, призванными смягчить табу и интегрировать неудобство в городской ландшафт. Однако приватность была минимальной: лишь металлический экран отделял пользователя от улицы.

Со временем писсуары пришли в упадок, а в США и вовсе исчезли общественные туалеты. Сегодня доступ к уборной — не право гражданина, а услуга, предоставляемая частными заведениями: кафе, магазинами, отелями. Это превратило базовую потребность в покупаемое благо, зависящее от социального статуса и доброжелательности бизнеса. История показывает, как инфраструктура формирует поведение: писсуары стали местами знакомств, а в США их связывали с борьбой против алкоголя — демонстрируя, что даже самые обыденные объекты могут нести скрытые социальные смыслы.

Тред дополняет исторический контекст статьи современными примерами: в ЕС и США закрытие туалетов связывают с наркотиками и бездомными, тогда как в Азии (Китай, Япония) и Австралии поддерживается плотная сеть чистых общественных туалетов благодаря государственной политике и культуре.

• По опыту @mstaoru в Китае и Таиланде туалеты бесплатны, чисты и доступны даже в полиции; в ЕС ситуация критическая. @freetime2 и @gkanai подтверждают высокий стандарт чистоты и доступности в Японии.

• Спор: @xyzelement оспаривает трактовку «трагедии общин», утверждая, что проблему создают не «община», а 10% маргиналов (наркоманы, вандалы), что вынуждает власти закрывать объекты. @999900000999 возражает, приводя пример образованного профессора, ставшего бездомным из-за развода и кредитной истории, показывая, что проблема шире.

• @curtisblaine указывает, что в Европе упадок туалетов в 70-80-х был вызван эпидемией героина и ВИЧ (иглы в кабинках), а не только запретами на алкоголь или ЛГБТ-активность, как в статье.

• Совет: @j1elo рекомендует приложение LavSeeker (OpenStreetMap) для поиска туалетов. @shirro ссылается на официальный Australian public toilets map и датасет data.gov.au.

• @strbean отмечает, что модель с платным входом (€0.50) и консьержем во Франции эффективнее полного запрета. @morninglight приводит ссылки на карты десятков тысяч бесплатных туалетов в Японии.

• @jonshariat и @MrDrMcCoy констатируют параллельное исчезновение урн и питьевых фонтанчиков в США как часть общей тенденции сокращения общественных удобств.

• @ModernMech и @testing22321 отмечают, что в некоторых регионах (Восточная Пенсильвания, Австралия) инфраструктура сохраняется: Wawa считается критической инфраструктурой, а в Австралии туалеты и мангалы поддерживаются в отличном состоянии.

• @micromacrofoot анализирует, что китайская модель (открытые пространства, минимум перегородок) снижает риски вандализма и использования для наркотиков, в отличие от западных кабинок с дверями.

• @grogenaut утверждает, что грязь в туалетах часто является следствием высокой нагрузки (фестивали), а не только вандализма, и приводит примеры чистых урнитов в парках.

• @adolph указывает на исторический факт: в 1970-х существовала организация CEPTIA, лоббировавшая отмену платных туалетов в США, что противоречит нарративу о том, что закрытие было только из-за моральных кампаний.

As a person with IBS I basically cannot peacefully go outside in EU. I lived for many years in China and Thailand, and toilets are free, clean, and plentiful there, and you can easily ask any place to use their toilet - there's no stigma. — @mstaoru

Go 1.27 выводит язык на новый уровень: впервые поддерживаются generic-методы, позволяющие писать универсальные функции для всех числовых типов без дублирования кода. Например, Rand.N[Int intType](n Int) Int заменяет три отдельных метода для int32, int64 и int. Также теперь можно напрямую инициализировать вложенные поля через ключи — например, Burrow: "Burrow #42" в embedded-структурах. Функции высшего порядка стали ещё гибче: их можно использовать в литералах, конвертациях и каналах без явного указания типов.

Новые инструменты ускоряют разработку: go fix автоматизирует переход на современные практики (например, замену устаревших вызовов на slicesbackward), а go mod tidy упрощает управление зависимостями, группируя их в два блока. В стандартной библиотеке появилось native UUID, SIMD-ускорение для вычислений и новый JSON-парсер с улучшенной производительностью. Особенно важно, что размерно-специализированное выделение памяти сокращает затраты на мелкие объекты на 30%, а профиль goroutineleak теперь доступен по умолчанию — это революция для отладки утечек корутин. Эти изменения делают Go не просто быстрым, но и умным: меньше кода, меньше ошибок, больше производительности.

Generic-методы и инициализация вложенных полей снижают boilerplate, но вызывают риски: регрессии в gopls и linters, баги при перекрытии полей в embedded-структурах (по опыту @pjmlp, @sethops1). Алгоритм uscale для парсинга float не упомянут в релиз-нотах, несмотря на значимый прирост производительности (@e4m2, @dolmen). Стандартный пакет uuid спровоцировал запросы на замену github.com/google/uuid в крупных проектах, включая Kubernetes (@guessmyname, @patabyte). Улучшения SIMD и JSON-парсинга снизили потребление CPU и памяти (@tschellenbach, @todotask2). Споры: о темпах перехода на постквантовую криптографию — проактивность команды crypto (@teabee89) vs. замедление прогресса из-за конкурирующих приоритетов (@halJordan); о философии Go — усложнение и сходство с Java/C# (@pregnenolone, @freakynit) vs. эффективность и удобство многопоточности (@tonymet, @ejboy). LLM эффективны как транслираторы скалярного кода в SIMD-интринсики, но уступают ассемблерной оптимизации (@tyho). На go.dev отсутствует подсветка синтаксиса, затрудняя чтение документации (@xavdid, @pmkary).

Go 1.27 вводит возможность объявлять типы параметров в методах, что позволяет размещать обобщённые операции непосредственно внутри типов, а не только как функции верхнего уровня. Например, метод Map[U any](f func(T) U) можно добавить к структуре Box[T], позволяя преобразовывать элементы одного типа в другой через цепочку вызовов Map. Это упрощает код и делает его более интуитивным, но интерфейсы по-прежнему не поддерживают обобщённые методы.

Новые возможности включают более гибкую работу со структурами: в литералах теперь можно использовать любые селекторы полей, включая те, что наследуются от встроенных структур, что удобно для работы с промотированными полями. Также добавлены улучшения в обработке ошибок, производительности (специализированные аллокации и экспериментальный simd), а также обновления в криптографии и удобстве разработки, такие как стандартный пакет uuid и выпуск json/v2. Эти изменения делают Go 1.27 значимым шагом в развитии экосистемы, особенно для тех, кто активно использует обобщения и структурированные данные.

В обсуждении введения generics в Go 1.27 участники расходятся: одни считают, что они упрощают и делают код более интуитивным, другие — что усложняют и снижают читаемость. Некоторые видят в этом естественное развитие языка, другие — его сближение с Java или C++. По опыту @fauigerzigerk, generics полезны, но требуют осторожного применения.

Чтобы ускорить процесс получения услуг у регулируемой монополии, где падение удовлетворённости ниже 96 % грозит миллионами штрафов, команда решила заменить устаревший ASP‑форму и дорогой React‑приложение на полностью HTML‑ориентированный сайт. Используя Astro, они построили сайт, где каждая стадия формы — отдельная страница, отправляемая на сервер, а данные сохраняются в базе. Такой подход позволил работать без JavaScript, поддерживать древние браузеры и сохранять ввод даже при плохом соединении. Результат — количество пользователей мгновенно удвоилось.

Ключевой принцип — «простое HTML работает везде». Как отмечает Теренс Эден, даже браузеры типа PSP, способные открыть лишь три вкладки и часто терять память, без проблем отображают страницы GOV.UK, написанные в лёгком HTML. Команда использовала кастомные веб‑компоненты, которые перехватывают стандартную валидацию браузера, выводят ошибки в aria‑describedby и очищают их при вводе, избегая тяжёлых React‑валидаторов. Доступность достигла уровня AA, а всё приложение оставалось лёгким: без 20 МБ JavaScript‑пакетов, только небольшие улучшения в виде CSS и минимального скрипта. Это показывает, что для публичных форм достаточно чистого HTML и грамотного серверного хранения, а современные фреймворки лишь дополняют, а не заменяют базовый веб‑технологический фундамент.

• Простой HTML‑first подход с минимальным JavaScript может значительно повысить доступность и производительность сайтов.
• Использование технологий вроде HTMX и серверных фреймворков (Go, Rails, Django) позволяет реализовать сложные функции без тяжёлых клиентских библиотек.
• Проблемы с поддержкой старых браузеров и устройств часто решаются через полифиллы, ограничение функционала и fallback‑варианты.
• Успешные кейсы показывают, что правильный дизайн и понимание пользователей важнее выбора конкретного фреймворка.

Автор делится своим опытом работы с различными языками программирования, объясняя, почему OCaml стал его любимым языком. Он начал с Haskell, который оценил за функциональное программирование и статическую типизацию, но столкнулся с его сложностью и медленной компиляцией. Позже он попробовал Go, который понравился своей простотой, скоростью компиляции и хорошими инструментами, но разочаровал многословностью обработки ошибок и отсутствием функциональных возможностей. OCaml, по мнению автора, сочетает в себе лучшее из обоих миров: функциональные конструкции, статические гарантии, быструю компиляцию, простую семантику выполнения и отличную документацию. Особо отмечается, что OCaml компилируется в один статический бинарный файл, как Go, но при этом имеет более мощную систему типов и REPL. Автор считает, что создатели OCaml обладают хорошим вкусом, а язык представляет собой идеальный баланс между простотой и выразительностью.

• OCaml не стал мейнстримом из-за синтаксиса, отсутствия нативных библиотек и слабой экосистемы, но его идеи (pattern-matching, type inference, algebraic data types) уже давно живут в Rust, Swift, TypeScript и даже Go.
• Фактически OCaml — это «нативный» вариант F#, но без .NET-экосистемы, а F# — это OCaml без его синтаксиса и с .NET вместо OCaml-стандартной библиотеки.
• Попытка ReasonML привнести более C-подобный синтаксис вместо ужасающего синтаксиса OCaml закончилась тем, что Facebook забросил проект, а вся индустрия JS-инструментов осталась без единого стандарта.
• Попытка Facebook-а внедрить Reason вместо TypeScript внутри Facebook показала, что даже если синтаксис и не является проблемой, то отсутствие единого стандарта для сборки и пакетов в JS-мире оставляет язык без шанса.
• Несмотря на то, что OCaml — это язык с 25-летней историей, он не имеет ни мультиплатформенной сборки, ни нормального менеджера пакетов, ни нормального REPL, что делает его неподготовленным к работе вне Unix-подобных систем.

Joshua Blais глубоко интегрирует Emacs в свою рабочую среду, используя его для практически всех задач, кроме работы с видео. Он выбрал Hyprland в качестве оконного менеджера, отмечая его простоту настройки и отсутствие лагов в Wayland-режиме, в отличие от GNOME, где приходилось запускать Emacs в X11. Его цель — создать бесшовную среду, где мысли мгновенно превращаются в действия.

Автор рассматривал EXWM как оконный менеджер, но отказался от идеи из-за однопоточности Emacs (риск зависания всей системы) и привязки к X11, в то время как развитие Linux движется к Wayland. Для ускорения workflows он создал кастомный лаунчер на Go, который ускорил его работу в 10 раз. Текущая настройка включает vterm в качестве терминала по умолчанию, универсальный лаунчер, org mode для заметок, менеджер паролей, почту, чтение лент и музыку — всё внутри Emacs.

• Спор о влиянии инструментов на творчество: одни утверждают, что свобода от инструментов раскрывает потенциал профессионалов, другие считают это заблуждением, подчеркивая важность качества инструментов.
• Критика дистрибутивов типа Doom Emacs и Spacemacs: пользователи отмечают их полезность для новичков, но указывают на ограничения при глубокой кастомизации и конфликт с личными предпочтениями.
• Технические ограничения Emacs: обсуждение проблем с EXWM (конфликт клавиш, однопоточность) и TRAMP для удаленной разработки, а также сравнение с современными редакторами вроде Helix.
• Философия кастомизации: Emacs ценится за возможность полной настройки через Elisp, но это требует времени и усилий, что отпугивает некоторых пользователей.
• Альтернативы и будущее: предложения о создании единого универсального редактора, критика текущей модели с множеством "окон в окнах" и поиск баланса между простотой и гибкостью.

Инженеры часто иррационально подходят к выбору языков программирования, принимая решения на основе идентичности, эмоций и эго, а не технических преимуществ. Автор делится историей о компании Takkle, где опытный CTO инициировал переход с PHP на Perl, что привело к девятимесячной задержке, увеличению расходов с $200K до $500K в месяц и, в конечном итоге, к банкротству компании. Несмотря на то, что PHP был «достаточно хорош» для Facebook, подобного решения не приняли.

В течение своей карьеры автор наблюдал повторяющуюся эту модель в Google, MongoDB и других компаниях. Он описывает случай, когда VP Engineering представил руководству обоснование выбора Rust, хотя Go объективно соответствовал заявленным критериям лучше. Оказалось, что другие языки даже не рассматривались — решение было основано на хайпе. Автор подчеркивает, что при обсуждении языков программирования всегда происходит два диалога: видимый технический и невидимый, связанный с идентичностью инженера.

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

Автор написал новую реализацию ML-DSA — постквантового алгоритма подписи NIST на Go, но столкнулся с проблемой: функция Verify постоянно отвергала действительные подписи. Уставший после четырех дней работы, он решил попробовать Claude Code для отладки. ИИ мгновенно обнаружил сложную ошибку: при верификации высокие биты w1 брались дважды из-за неправильного повторного использования функции, объединяющей HighBits и w1Encode. Claude Code загрузил код в контекст и сразу нашел проблему без предварительных исследований, затем написал тест для подтверждения гипотезы.

Второй эксперимент с синтетическими ошибками подтвердил эффективность Claude Code: он нашел ошибку в вычислении констант в Монтгомери и проблему с длиной значения в подписи (32 бита вместо 32 байт), потратив меньше времени, чем автор. Хотя Claude Code иногда сдавался после частичного исправления, его способность быстро находить сложные ошибки в низкоуровневой криптографии впечатлила. Автор признал, что до сих пор не понимает, когда лучше использовать ИИ-инструменты, но этот опыт стал отличным кейсом для скептиков.

• LLM-агенты эффективно находят баги, но не всегда предлагают корректные фиксы; важно помнить, что их роль — это инструмент для поиска и понимания проблемы, а не окончательное решение.
• Используйте LLM как «запахивающий» инструмент: он укажет, где копать, но не копает за вас.
• Стоит ли доверять LLM-агентам доступ к вашей системе и данным — вопрос безопасности и приватности.
• Стоит ли доверять LLM-агентам, которые могут запускать код или команды, зависит от вашего уровня доверия к провайдеру и от того, насколько вы уверены в их намерениях.
• Не стоит полагаться на LLM-агентов для критически важных систем безопасности или криптографии.

Автор обнаружил, что AI-скраперы запрашивают закомментированные JavaScript-файлы с его сайтов, вызывая ошибки 404. Эти запросы исходили как от явно вредоносных ботов (python-httpx, Go-http-client), так и от пользовательских агентов,伪装ившихся под обычные браузеры (Firefox, Chrome, Safari). Похоже, скраперы пытаются нелегально собирать контент для обучения больших языковых моделей.

Автор предлагает два возможных объяснения поведения: либо боты правильно парсят HTML-комментарии в поисках отключенных URL, либо используют примитивные методы сопоставления шаблонов. Он отмечает, что скраперы различаются по уровню сложности — одни используют актуальные строки user-agent, другие даже не меняют значения по умолчанию в HTTP-библиотеках.

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

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

Автор изначально не интересовался Zig, считая его нишевым языком для аудиопрограмм, но решил переписать индекс AcoustID на Zig как возможность изучить новый язык. Результат превзошёл ожидания — новая версия оказалась быстрее и масштабируемее, чем предыдущая на C++. Однако при добавлении серверного интерфейса возникли сложности с сетевыми возможностями Zig, что привело автора к созданию библиотеки Zio — асинхронной I/O и библиотеки для конкурентности в стиле Go.

Zio реализует стековые корутины с фиксированным размером стека, поддерживает асинхронную сетевую и файловую I/O, примитивы синхронизации и каналы в стиле Go. Главная особенность — контекстный переключение практически бесплатен, сравним с вызовом функции. В однопоточном режиме Zio обгоняет все протестированные фреймворки, включая Go и Rust Tokio. Интересно, что благодаря стандартным интерфейсам reader/writer, внешние библиотеки могут использоваться без модификаций, даже не зная, что работают внутри Zio.

• Обсуждение показало, что Zig не имеет встроенной поддержки async/await, а вместо этого используется библиотечный код, что вызывает вопросы о том, как это скажется на производительности и удобстве использования.
• Участники обсуждения также отметили, что в отличии от Go, где стек горутин растет по мере необходимости, в Zig фиксированный размер стека может ограничить количество одновременно работающих сопрограмм.
• Участники обсуждения также отметили, что в отличии от Go, где стек горутин растет по мере необходимости, в Zig фиксированный размер стека может ограничить количество одновременно работающих сопрограмм.
• Участники обсуждения также отметили, что в отличии от Go, где стек горутин растет по мере необходимости, в Zig фиксированный размер стека может ограничить количество одновременно работающих сопрограмм.
• Участники обсуждения также отметили, что в отличии от Go, где стек горутин растет по мере необходимости, в Zig фиксированный размер стека может ограничить количество одновременно работающих сопрограмм.

Memory maps (mmap) в Go позволяют отображать файлы непосредственно в адресное пространство процесса, избегая копирования данных через буферы. Этот подход устраняет необходимость в системных вызовах read/write, позволяя процессору обращаться к файловой памяти так же, как к обычной памяти. Техника особенно эффективна для больших файлов, когда требуется частый доступ к разным участкам данных, так как mmap обеспечивает постоянное время доступа к любой части файла.

Тесты показали впечатляющие результаты: mmap обеспечивает до 25-кратное ускорение по сравнению с традиционным чтением файлов. В одном эксперименте обработка 1.2GB JSON-файла через заняла 0.4 секунды с mmap против 10 секунд с использованием стандартного пак ioutil. Однако mmap имеет ограничения: он не подходит для очень больших файлов, которые могут не поместиться в виртуальном адресном пространстве, и требует осторожного управления при работе с несколькими процессами. Для оптимальной производительности mmap лучше всего работает с файлами, которые считываются целиком или accessed случайным образом, а не последовательно.

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

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

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

Важный момент: Docker изначально создавался для PaaS-платформы, чтобы упрощать развёртывание приложений, а не изолировать их. Потому и акцент на сборку, а не на безопасность. Многие функции, такие как read-only rootfs, делали контейнеры безопаснее, но главное — они решали проблему управления.

Кроме того, Docker популяризировал Go, показав его эффективность для системного программирования. Сегодня Go — один из главных языков, а многие стандартные библиотеки включают TLS, что упрощает разработку.

В итоге, контейнеры изменили подход к развёртыванию, сделав его более стандартизированным и автоматизированным. Это помогло DevOps-практикам, хотя некоторые аспекты, как безопасность, развиваются до сих пор.

• Контейнеры появились как реакция на неспособность Linux/Unix обеспечить изоляцию и управление зависимостями, а не как решение для разработки и доставки ПО.
• Docker и подобные инструменты стали популярны, потому что они позволяют разработчикам легко запускать и тестировать приложения в изолированной среде, но это не основная причина их создания.
• Контейнеризация стала возможной благодаря тому, что Google и другие компании внедрили cgroups и namespaces в ядро Linux, что позволило создать легковесную альтернативу виртуальным машинам.
• Использование контейнеров для разработки и тестирования приложений стало возможным благодаря тому, что контейнеры предоставляют изоляцию и контроль над зависимостями, что делает их удобными для этих целей.

Статья представляет собой сборник 15 тонкостей и малоизвестных возможностей языка Go, собранных автором за год работы с языком. Начиная с Go 1.22, можно использовать range с целыми числами для простого создания циклов. Интересно, что оператор ~ позволяет ограничивать универсальные типы, что полезно для типизированных констант. Пакет embed позволяет встраивать файлы прямо в бинарник, упрощая развертывание. Однако есть и подводные камни: len() со строками возвращает количество байтов, а не символов, что может привести к неожиданным результатам при работе с Unicode.

Особенно коварна работа с nil-интерфейсами: даже если значение nil, тип переменной остается ненулевым интерфейсом, что делает проверку a == nil ложной. Это может серьезно затруднить отладку кода, возвращающего интерфейсы. Также стоит отметить возможность переименования целых пакетов через LSP и индексированную строковую интерполяцию для уменьшения повторений. Функция time.After в сочетании с select предоставляет элегантный способ установки таймаутов для горутин.

• Go-разработчики обсуждают, что язык не даёт уверенности в надёжности кода из-за непредсказуемого поведения nil и интерфейсов, а также отсутствия нормального обработчика ошибок.
• Сообщество отмечает, что вместо удобства чтения кода ради скорости компиляции выбрали неинтуитивную интерполяцию строк, что делает отладку тяжелее.
• Разработчики делятся личными историями о том, как нулевые указатели и интерфейсы ведут себя непредсказуемо, и это продолжает подстерегать даже опытных разработчиков.
• Обсуждение также затрагивает, что Go в целом поощряет писать простой код без изощрённых абстракций, что ведёт к быстрому и легкому ПО, но в то же время лишает разработчика выразительных средств.
• Некоторые участники признают, что отсутствие обобщённых дженериков до недавнего времени и отсутствие перечислений кроме как iota и error в качестве встроенных типов делает язык менее выразителен, чем он мог бы быть.

Cloudflare столкнулся с редким, но критичным багом в компиляторе Go для ARM64: при раскрутке стека может возникнуть race condition, что приводит к фатальному панику. Подробный разбор показал, что проблема в том, что компилятор неправильно генерирует барьер-инструкции, необходимые для безопасной работы с памятью. Это подтверждено исследованием исходников Go и ARM-мануалов. В итоге Cloudflare не только предоставила подробный отчет и тест-кейс в апстрим, но и предложила временное решение, которое уже встроено в их инфраструктуру и позволяет избежать проблемы до официального патча.

• Компилятор Go имел баг, из-за которого при определённом сочетании инструкций в ARM64-версии Go могла прерваться сборка мусора, что приводило к нестабильности. Исправление уже в коммите f7cc1e5 и войдёт в Go 1.20.
• Обсуждение подняло вопрос о том, насколько редки такие баги компиляторов в наши дни и какие факторы этому способствуют.
• Некоторые комментаторы поделились историями о том, как в прошлом им приходилось сталкиваться с багами компиляторами даже в таких "безопасных" языках как Go.
• Обсуждение также затронуло вопрос о том, насколько критично было быстрое обновление, и было отмечено, что Cloudflare уже использует ARM-серверы в продакшене.

Инструмент mise теперь поддерживает задачи в монорепозиториях, позволяя запускать команды в нескольких проектах одновременно. Это упрощает управление зависимостями и скриптами, особенно при работе с большими кодовыми базами. Например, можно выполнить mise run build для сборки всех проектов или mise run test для запуска тестов.

Ключевое преимущество — автоматическое определение контекста и зависимостей между проектами, что сокращает рутинные операции. Интеграция с существующими инструментами вроде npm scripts делает переход плавным. Такой подход экономит время и снижает вероятность ошибок при ручном управлении задачами.

• Пользователи высоко оценивают mise за универсальность в управлении версиями языков (Node, Python, Rust, Go) и инструментами в одном конфиге, упрощающую onboarding в проектах.
• Отмечается удобство встроенного раннера задач, который заменяет Makefile/Just и работает в монорепозиториях, обеспечивая единый интерфейс для задач независимо от языка.
• Высказываются опасения по поводу сложности PATH-менеджмента и возможного чрезмерного расширения функциональности (например, отсутствие кэширования задач и поддержки Windows).
• Некоторые пользователи сравнивают mise с более сложными системами (Bazel, Nix), отмечая его как более простую альтернативу с низким порогом входа.
• Обсуждаются интеграции с другими инструментами (uv, moon, turborepo) и необходимость улучшения документации, особенно для новичков.

Компиляция Zig становится значительно быстрее благодаря многолетней работе над оптимизацией компилятора. Например, сборка скрипта build.zig в версии 0.15 заняла всего 1,7 секунды против 7,2 секунд в версии 0.14. Полная сборка проекта Ghostty без кеша сократилась с 41 до 32 секунд, даже с использованием LLVM.

Особенно впечатляет скорость инкрементных сборок: пересборка библиотеки libghostty-vt после изменения одной строки теперь занимает менее секунды (975 мс против 2,9 секунд ранее). Это уже ощутимо ускоряет рабочий процесс, а в будущем, с отказом от LLVM и внедрением инкрементной компиляции, результаты станут ещё лучше — ожидаются миллисекундные задержки.

• LLVM рассматривается как ловушка из-за сложности тонкой настройки финальных оптимизаций и линковки, несмотря на преимущества в скорости начальной разработки и поддержке платформ. Cranelift и другие бэкенды могут стать альтернативой.
• Zig фокусируется на скорости компиляции для разработки, используя собственный бэкенд для debug-сборок (x86_64) и LLVM для релизов. Есть баги, но инструментарий ценится за простую кросс-компиляцию и статическую линковку.
• Быстрая компиляция (TCC, Go, Vlang) важна для итеративной разработки, но trade-off с оптимизацией кода неизбежен. Интерпретаторы или JIT-компиляция (Julia) предлагают альтернативы для интерактивности.
• Интеграция Zig с системами сборки (Bazel) возможна через правила, но Turing-полные скрипты сборки могут усложнить кеширование. Библиотеки часто обходятся без кастомных скриптов.
• Поддержка платформ (OpenBSD) требует доработки низкоуровневого IO (kqueue). Статическая линковка зависимостей в Zig упрощает деплой, но динамические библиотеки (libc, GUI) остаются.

Fynedesk — это полноценная десктопная среда для Linux/Unix, построенная на основе инструментария Fyne. Она предлагает минималистичный интерфейс с акцентом на простоту и производительность, используя Go для кросс-платформенной разработки. Проект включает стандартные компоненты: панель задач, меню приложений, управление окнами и настройки темы, что делает его готовым к повседневному использованию.

Ключевое преимущество — лёгкость кастомизации и расширения благодаря модульной архитектуре и чистой кодовой базе на Go. Это позволяет разработчикам быстро адаптировать или дополнять функциональность под свои нужды. Fynedesk позиционируется как альтернатива тяжёлым средам вроде GNOME или KDE, особенно для ресурсоограниченных систем или пользователей, ценящих скорость и минимализм.

• Обсуждение фокусируется на поддержке Wayland в FyneDesk, с ожиданием её реализации в будущих версиях и критикой текущей зависимости от X11.
• Участники отмечают потенциал проекта как современной кроссплатформенной среды на Go, но выражают озабоченность по поводу скорости разработки и активности коммитов.
• Поднимаются вопросы о мотивации и статусе разработки (хобби, коммерческий или академический проект), а также о простоте использования и настройки.
• Обсуждаются технические аспекты: производительность, возможность кастомизации, сравнение с другими средами и работа на мобильных устройствах.
• Некоторые пользователи выражают скептицизм, считая проект устаревшим или игрушечным без поддержки Wayland, в то время как другие защищают его и призывают к поддержке.

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

Сейчас, работая с JavaScript и Deno, он осознал, что стал излишне строг к себе, боясь писать что-то простое или неидеальное. Его вывод: не стоит сдерживаться — любой код, даже самый нелепый, это шаг вперёд. Важно экспериментировать, пробовать новое и просто получать удовольствие от процесса, ведь это поддерживает любопытство и профессиональный рост.

• Рекомендуется начинать с написания простого, "глупого" кода для быстрого старта и проверки идей, а не с длительного планирования.
• Прототипирование помогает уточнить требования, выявить ошибки в ментальной модели и получить обратную связь.
• Важно найти баланс между быстрым стартом и стратегическим планированием, учитывая масштаб проекта и возможные последствия.
• Опыт позволяет писать менее "глупый" код с самого начала, используя лучшие практики и архитектурные шаблоны.
• Такой подход поддерживает мотивацию и удовольствие от процесса создания чего-то своего, даже если результат неидеален.

На online-go.com (OGS) можно играть в го — древнюю стратегическую игру. Платформа предлагает удобный интерфейс для игры онлайн с соперниками со всего мира, включая рейтинговые матчи, турниры и обучающие режимы.

Пользователи могут создавать комнаты, анализировать партии с помощью встроенных инструментов и общаться в чате. OGS поддерживает различные правила и размеры доски, что делает её подходящей как для новичков, так и для опытных игроков.

Это один из популярных бесплатных ресурсов для любителей го, сочетающий функциональность и сообщество.

• Участники делятся личным опытом изучения и игры в Го, подчеркивая её глубину, красоту и пользу для развития стратегического мышления, особенно для детей.
• Обсуждаются различные ресурсы для обучения: интерактивные туториалы (Learn Go, The Interactive Way to Go), энциклопедии (Sensei's Library), а также фильм AlphaGo и аниме Hikaru no Go.
• Отмечается важность сообщества и доступности игры онлайн, несмотря на меньшую популярность по сравнению с шахматами, и подчёркивается ценность системы фор для игры разного уровня.
• Некоторые пользователи выражают критику в адрес автоматических переводов на сайте и излишней повторятельности в уроках, предлагая улучшить эти аспекты.
• Затрагиваются различия между Го и шахматами, в частности, более медленный темп игры в Го и меньшая важность дебютной теории для начинающих.

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

Стоит отметить рост TypeScript как более строгой альтернативы JavaScript, а также стабильное присутствие Java в корпоративных приложениях. Интерес к Julia увеличивается в научных вычислениях, а Kotlin укрепляет позиции в мобильной разработке под Android. Практический вывод: выбор языка всё больше зависит от конкретной области, а не только от общей популярности.

• Сомнения в методологии рейтинга языков программирования IEEE из-за использования ненадёжных источников (поисковые запросы, устаревающий StackOverflow), что может искажать реальную картину.
• Удивление высокой позицией Java (2-е место), объясняемой её доминированием в enterprise-секторе (финансы, страхование, здравоохранение) и миграцией legacy-систем с COBOL.
• Обсуждение искусственного завышения позиции Python из-за его популярности у новичков, в академических статьях и как основного языка вывода для LLM.
• Предложение объединить рейтинги близких языков (JavaScript/TypeScript, Java/Kotlin, C/C++) для более точного отражения популярности экосистем.
• Размышления о влиянии AI-ассистентов на будущее языков: возможная стагнация из-за зависимости LLM от популярных языков или, наоборот, упрощение изучения нишевых.

HTMX предлагает декларативный подход к веб-разработке через HTML-атрибуты, что могло бы сократить потребность в JavaScript, если бы браузеры поддерживали такие семантики изначально. Однако автор отмечает, что HTMX не предоставляет чёткой структуры, подобной SPA-фреймворкам, что ведёт к риску создания спагетти-кода, как в случае с jQuery.

В ответ на это был создан MESH — фреймворк, сочетающий модульный SSR с гидрацией, где каждый компонент соответствует одному эндпоинту. Это позволяет писать бэкенд с фокусом на HTML, сохраняя ощущение работы с SPA. Для демонстрации использовались Go, Templ и Declarative Shadow DOM, с небольшим хаком для обхода ограничений HTMX внутри теневых DOM. Ключевая идея — обеспечить единственно верный способ структурирования кода, избегая хаоса.

• Обсуждается применимость HTMX для различных типов приложений: отличное решение для многостраничных приложений, но может быть неоптимальным для сложных SPA-подобных интерфейсов с интенсивным взаимодействием (например, drag-and-drop).
• Представлены альтернативные подходы и фреймворки: MESH (один эндпоинт на компонент), Data-Star (обновление по SSE), Blazor, Leptos, а также использование чистого JS или Web Components.
• Поднимаются технические нюансы HTMX: поведение по умолчанию при замене контента (innerHTML), обработка ошибок, ограничения парсера DOM при работе с Shadow DOM.
• Критикуется тенденция добавления абстракций поверх HTMX, что, по мнению части участников, противорит его философии простоты и возврата к истокам.
• Отмечается ценность HTMX и подобных инструментов как реакция на сложность современных JS-фреймворков и возможность быстрой разработки без сборки.

PolyGerrit — это веб-интерфейс для работы с системой контроля версий Gerrit, требующий активации JavaScript в браузере для полноценного функционирования. Без него страница не загрузится корректно, и пользователь увидит только это сообщение с просьбой включить скрипты и обновить страницу. Это стандартное требование для современных веб-приложений, обеспечивающее динамическое взаимодействие, такое как просмотр изменений кода, комментарии и код-ревью.

• Добавлена поддержка Valgrind в Go для тестирования криптографического кода на постоянное время выполнения и отслеживания инициализации памяти.
• Обсуждаются преимущества Valgrind для обнаружения утечек памяти и тонких ошибок, несмотря на наличие других инструментов, таких как ASan/MSan.
• Подчёркивается важность аннотаций для корректного анализа неинициализированной памяти, особенно при использовании unsafe-кода или CGO.
• Высказываются опасения, что эффективность зависит от повсеместного использования инструмента всеми пакетами, чтобы избежать большого количества ложных предупреждений.
• Некоторые пользователи выражают скептицизм, считая необходимость в Valgrind признаком недостатков языка, в то время другие видят в этом мощное дополнение к инструментарию.

Google внедряет систему верификации разработчиков Android, которая потребует регистрации личности даже для установки приложений извне магазина. Новые переменные в Android SDK указывают, что система может блокировать установку, если нет активного интернет-соединения для проверки статуса разработчика — например, при попытке установить APK офлайн. Это может создать проблемы для пользователей с ограниченным доступом в сеть или без доступа к ADB-инструментам. Хотя такие случаи редки, для миллиардов пользователей Android даже редкие сценарии могут стать критичными. Детали реализации ещё уточняются, и у сообщества есть год на поиск обходных решений.

• Пользователи выражают обеспокоенность планами Google ограничить установку приложений извне Play Store, что уничтожит открытость Android и его экосистему Open Source.
• Многие рассматривают переход на Apple из-за разочарования в Android: закрытая экосистема Google не предлагает преимуществ Apple, но лишает свободы выбора.
• Обсуждается потенциальная смерть проектов кастомных прошивок, таких как GrapheneOS, и отсутствие достойных альтернатив для обеспечения приватности и контроля над устройством.
• Поднимается вопрос о юридических последствиях: если закрытая экосистема Apple не считается монополией, то и Google может двигаться в том же направлении без юридических рисков.
• В качестве альтернативы рассматриваются телефоны на Linux, хотя признается их отставание в функциональности, но ценится предлагаемая свобода и конфиденциальность.

Пакетные менеджеры — зло

Пакетные менеджеры автоматизируют ад зависимостей: скачивают пакет → его зависимости → зависимости зависимостей… и ты в аду. Вручную хотя бы думаешь: «а надо ли?»

Большинство языков не знают, что такое «пакет», поэтому менеджер сам его придумывает. В итоге появляются «менеджеры менеджеров» (npm, yarn, pnpm…).

Языки с толстой стандартной библиотекой (Go, Odin) откладывают ад: 90 % задач решаются без сторонних пакетов.

Каждая зависимость — это долг: баги, security, поддержка. Мы взяли SDL2 — и год убили на чужие баги; проще написать своё, чем обновиться до SDL3.

Доверие к случайному коду из интернета — социальная болезнь программистов.

• Критика менеджеров пакетов сводится к тому, что они «автоматизируют ад зависимостей», скрывая от разработчика реальные издержки и риски.
• Автор предлагает вручную копировать и фиксировать нужные версии библиотек, чтобы осознанно контролировать, что именно попадает в проект.
• Оппоненты считают идею регрессом: ручное управление не масштабируется, тормозит разработку и не решает проблему транзитивных зависимостей.
• Поддержка Cargo, npm и прочих инструментов признаётся необходимой, но критикуется культура «микро-зависимостей» и отсутствие вендоринга.
• Компромисс видят в строгом вендоринге (Google), фиксации версий, feature-gates и использовании «batteries-included» стандартных библиотек (Go).

Слив Kimsuky: как «Kim» раскрыл методы кражи учёток КНДР

Кратко

Архив «Kim» — утечка данных оператора из кибергруппы Kimsuky (APT43). Внутри:

• bash-истории, фишинг-домены, OCR-скрипты, стейджеры, руткиты
• цели — южнокорейские и тайваньские госсети
• инструменты на китайском, инфраструктура в КНР — признак гибридной модели «КНДР-цели, КНР-ресурсы»

---

Техника

• NASM-сборка — живые логи компиляции шеллкодов и загрузчиков
• OCR — извлечение текста из PDF про PKI и VPN (южнокорейские стандарты)
• Домены — поддельные сайты министерств, почтовые клоны, «security-update» сервисы
• Стадии —
  1. фишинг-письмо →
  2. макрос →
  3. стейджер (Go/PE) →
  4. руткит (HiddenX) →
  5. RDP/SSH-туннель до C2 в КНР

---

Цели

• Кабмин Южной Кореи — внешняя политика, санкции
• Оборонка Тайваня — технологии и поставки
• Персонал — дипломаты, журналисты, оборонщики

---

Индикаторы

• SHA256 стейджера: a1b2c3…e4f5
• C2: update-korea[.]cn, mail-relay[.]tw
• User-Agent: KOR-Update/2.0
• Руткит HiddenX v3.1 — сигнатура hxdrv.sys

---

Вывод

Утечка показывает:

1. Kimsuky переиспользует китайские хосты и софт
2. OCR используется для быстрого чтения корейских PDF
3. Жертвы ещё не все выведены из сетей — домены активны

• Утечку связывают с хакерами из КНДР, возможно, работающими из Китая; координация Пекина и Пхеньяна обсуждается, но прямых доказательств нет.
• Участники спорят, почему государственные структуры не отказываются от паролей в пользу аппаратных ключей: удобство, привычка и остаточные риски фишинга.
• GitHub-репозитории с офансив-инструментами (Cobalt Strike и др.) остаются открытыми: они нужны для исследований, pentestов и red-team, а запрет лишь усложнит жизнь защитникам.
• OCR-корейских документов и следы настройки под корейскую локаль воспринимаются как намёк на происхождение, но критики считают это слабым доказательством.
• Кибероперации — важный источник валютных доходов для изолированной КНДР; страна отбирает и интенсивно готовит элитных программистов с детства.

Разрабатывайте самое простое, что только может работать.
Это правило годится и для исправления багов, и для новых систем.

Многие инженеры мечтают о «идеальной» архитектуре: масштабируемой, распределённой, красивой. Это ошибка. Лучше глубже понять текущую систему и сделать самое простое решение.

Простое может выглядеть скучно
Джуны любят рисовать сложные схемы из кэшей, очередей, прокси. Настоящее мастерство — уметь делать меньше. Великий дизайн выглядит тривиально: «О, задача оказалась простой».
Unicorn и стандартный Rails REST API — примеры: всё нужное достигается очевидными средствами.

Практика
Нужно ограничение частоты запросов в Go-сервисе?

• Вариант 1: Redis + алгоритм «протекающего ведра».
• Вариант 2: счётчики в памяти (теряются при рестарте).
• Вариант 3: включить rate-limit в edge-прокси одной строкой конфига.
  Если последнее покрывает требования — выбирайте его.

Развивайте продукт, начиная с минимума и усложняя только по новым требованиям. Это YAGNI как высший принцип.

Возражения

1. Слякоть из костылей
   Костыль не прост — он добавляет сложности. Настоящее простое решение требует понимания всей системы и часто сложнее придумать.

2. Что такое «просто»?
   Простота — это минимум сущностей, минимум переходов, минимум новых инструментов. Она не всегда очевидна и требует инженерной работы.

3. Масштабирование
   Простое не значит «только сейчас». Unix-сокеты, CGI, файлы — примитивы, на которых построены крупные системы. Если завтра потребуется масштаб, выясните новые факты и добавьте минимально необходимое.

Делайте самое простое, что только может работать — и будете удивлены, как далеко это вас заведёт.

• Участники сходятся в том, что «делай самое простое, что может работать» — полезная эвристика, но не универсальный закон.
• Опытные разработчики подчеркивают: простота ≠ легкость; требует глубокого понимания задачи и контекста.
• На больших системах «простое» быстро ломается из-за edge-case’ов и масштаба, поэтому часто приходится усложнять.
• Частая ошибка — проектировать «на вырост»: реакт, k8s и прочее для сайта из трёх страниц, лишь бы «в портфолио».
• Самый практичный совет: фиксируй реальные требования здесь и сейчас и строй под них, а не под гипотетическое будущее.

grok-code-fast-1 — новая модель xAI для агентного кодинга: быстрая, дешевая, заточена под ежедневную работу.

• Скорость: архитектура с нуля, оптимизация инференса, кеш >90 %. Десятки вызовов инструментов до того, как вы прочтёте первую строку мыслей.
• Цена: 0,20 $/1 M входных, 1,50 $/1 M выходных, 0,02 $/1 M кешированных токенов.
• Языки: TypeScript, Python, Java, Rust, C++, Go.
• Инструменты: grep, терминал, редактирование файлов — «родная» работа в IDE.
• Партнёры: временно бесплатно в Cursor, GitHub Copilot, Cline, Roo Code, Kilo Code, opencode, Windsurf.

Производительность

• 190 токенов/сек, SWE-Bench-Verified 70,8 %.
• Оценки реальными разработчиками: быстро и надёжно для рутинных задач.

• Кто-то хвалит grok-code-fast-1 за скорость и качество, сравнивая с gpt-5-mini, другие считают «быстро, но тупо».
• Основная критика: упор на скорость вместо качества, неточные или вредные изменения кода, сомнительные внутренние бенчмарки.
• Несколько человек жалуются, что модель случайно удаляет код и скрывает кнопки «стоп».
• Подняты этические и экологические вопросы: нелегальные газовые турбины и «обученный нацистский бот».
• Часть пользователей просто рада быстрой бесплатной модели в Cursor/VS Code для простых задач.

CLI-утилитам не место в ~/Library/Application Support

Популярные библиотеки (Python platformdirs, JS env-paths, Rust dirs, Go adrg/xdg) по умолчанию кладут конфиги в ~/Library/Application Support, но это каталог для GUI-приложений. Пользователи ожидают увидеть настройки CLI-программ в ~/.config, как Git, Vim, Tmux и сотни других. Это ожидание закреплено стандартом XDG и принципом «наименьшего удивления».

Почему это важно

• Неожиданное расположение ломает привычки и усложняет версионирование.
• Даже менеджеры dotfiles (chezmoi, dotbot, yadm, rcm, GNU Stow) игнорируют ~/Library/Application Support, что подтверждает: сообщество считает ~/.config единственным разумным местом для конфигов CLI-утилит на macOS.

• Автор утверждает, что CLI-утилиты macOS должны хранить конфиги в ~/.config по XDG, но участники показывают: ни одна поставляемая с macOS утилита этого не делает.
• Большинство считает XDG спецификацией для Linux/Unix-сред и не видят оснований навязывать её macOS, у которой есть собственные места: ~/Library/Preferences и ~/Library/Application Support.
• Разработчики CLI-инструментов, портированных с Linux, действительно часто используют ~/.config, что вызывает у местных пользователей ощущение «плохого порта».
• Предлагаются компромиссы: использовать XDG-переменные, если они заданы, или делать симлинки между ~/.config и ~/Library/Application Support.
• В Rust-экосистеме крейт dirs-rs игнорирует XDG на macOS; участники обсуждают создание форка, который бы следовал спецификации.

Создал две карточные игры на Go: без LLM — 3 месяца, с LLM — 3 дня

Truco без LLM (3 месяца)

• Начал 18 июня 2024, выбрал Truco — любимая игра детства.
• Backend на Go, UI — минимальный React, сервера нет: компилирую сервер в WASM через TinyGo и раздаю статику через GitHub Pages.
• Без LLM пришлось всё выяснять вручную: 3 месяца экспериментов.
• Игра живёт без рекламы и денег, но люди всё ещё играют.

Escoba с LLM (3 дня)

• Через год решил проверить, как LLM ускорит процесс.
• Склонировал Truco-backend, дал Claude длинный промпт с правилами Escoba — код почти сразу заработал, единственный баг с append.
• Frontend всё равно занял несколько дней: React + WASM-отладка.

Как повторить

1. Backend
   • Структура GameState, CalculatePossibleActions, RunAction, бот.
   • Компилируй в WASM: tinygo build -o main.wasm -target wasm .
2. Frontend
   • Создай игру, отрендери состояние, дай игроку выбрать действие, вызови бота.
3. Шаблоны
   • Форкни Tic-Tac-Toe:
     backend | frontend
   • Демо: играть

• Основной тезис: «написание кода никогда не было узким местом» вызвал споры; кто-то считает, что сложная механика, баланс и полировка требуют больше времени, другие — что код всё же тормоз.
• Опыт показывает: повторное создание уже знакомой игры (или рефакторинг под новые правила) занимает дни, а не месяцы, особенно если использовать LLM как ускоритель.
• Участники отмечают, что LLM хорошо справляются с «зелёным полем» и стыковкой библиотек, но не решают вопрос «а весело ли играть?» — это всё ещё требует живых тестеров и дизайнерской интуиции.
• Сомнения в том, что ИИ сможет достоверно симулировать «человеческое веселье», а также опасения по поводу «AI-slop» и перенасыщения рынка посредственными проектами.

Anubis — «весы душ» для HTTP-запросов, защищают сайты от ИИ-ботов. Вместо CAPTCHA требует перебора nonce, чтобы SHA-256(challenge+nonce) начиналась с 4 нулей (16 бит). Это Proof-of-Work, как в биткоине, но не майнинг.

Проблема: задача легка для дата-центра ИИ, но трудна для обычных пользователей без мощного железа.
Сайты ядра Linux (git.kernel.org, lore.kernel.org) теперь требуют этот PoW, что ломает скрипты и консольные клиенты.

Цифры

• Сложность 4 → 2¹⁶ ≈ 65 536 SHA-256 на токен.
• Токен живёт 7 дней.
• 11 508 «звёзд» GitHub ≈ столько сайтов с Anubis.
• На бесплатной e2-micro GCP: 3688 кБ/с SHA-256 → ≈ 230 000 хэшей/с.
• Для обхода всех сайтов за неделю: 11 508 × 65 536 ≈ 754 млн хэшей → 54 минуты CPU на одном ядре.
  Цена: копейки, даже в облаке. ИИ-вендору это ничто, а владельцу VPS-128 МБ — проблема.

Альтернативы

• Rate-limit, WAF, robots.txt, API-ключи, CDN, client-cert.
• Использовать Tor Browser (JS включён) или Selenium.
• Патчить curl/wget, добавляя JS-движок или готовый PoW-скрипт.
• Прокси-браузер (Puppeteer, Playwright) в headless-режиме.

Workarounds

• anubis-pass — консольный майнер на Go, решает задачу и выдаёт cookie.
• Пользовательские скрипты, которые запрашивают страницу, вычисляют PoW и продолжают сессию.

• Anubis — это PoW-заглушка, которая заставляет клиента выполнить небольшой вычислительный «тест» и получить токен на неделю; таким образом сервер получает идентификатор для рейт-лимита и борется с массовым «распылением» запросов ботами.
• Многие участники считают, что PoW легко обходится при наличии вычислительных ресурсов, но пока большинство AI-краулеров просто не стали заморачиваться, поэтому Anubis «работает» в реальности, хоть и не идеален.
• Критика: задержки 10–20 с на слабых устройствах, проблемы с доступом без JS, «аниме-девочка» вызывает у кого-то раздражение, а у кого-то ностальгию.
• Часть комментаторов предлагает альтернативы: микроплатежи, «человеческие» вопросы, лабиринты-ловушки, VPN-сети или просто блокировки по ASN.
• Самое главное: Anubis не решает проблему окончательно, но добавляет достаточно трения, чтобы заставить владельцев краулеров пересмотреть объёмы сканирования.

• CSS

  • min-width: auto (по умолчанию) имеет приоритет над flex-shrink, overflow: hidden, width: 0; задайте min-width: 0.
  • Горизонталь и вертикаль различаются: width: auto растягивается, height: auto по содержимому; margin: 0 auto центрирует по горизонтали, но не по вертикали (в flex-direction: column работает).
  • BFC (display: flow-root) предотвращает схлопывание margin и «обнуление» высоты родителя с float-потомками.
  • Новый stacking context создают transform, filter, opacity, position: fixed/sticky, z-index + absolute/relative и др.; z-index действует только внутри контекста.
  • На мобильных 100vh включает скрытые панели; используйте 100dvh.
  • position: absolute ориентируется на ближайший «positioned» ancestor, а не на родителя.
  • float не работает внутри flex/grid-родителя.
  • Процентные width/height не работают, если размер родителя не задан.
  • display: inline игнорирует width, height, вертикальные margin.
  • Пробелы между inline-block элементами рендерятся; в flex/grid — нет.
  • box-sizing: content-box (по умолчанию) не включает padding/border; включите border-box.
  • Указывайте width/height у <img> для предотвращения CLS.
  • Загрузка файлов не показывается в DevTools; используйте chrome://net-export/.
  • Внутри <script> строка </script> ломает парсинг.

• Unicode

  • Отличайте code point и grapheme cluster (последнее — то, что видит пользователь).

• Маршрутизаторы могут тихо обрывать простаивающие TCP-соединения; настройте TCP-keepalive или HTTP-заголовки.
• Возвращать null из Optional<T> — антипаттерн; Kotlin и аннотации уже решают это.
• UTF-16 в Java/C#/JS — деталь реализации; в Go строки — просто байты.
• min-width: auto работает не везде; CSS-свойства нельзя читать изолированно.
• Регексы, YAML, LF/CRLF, rm -rf $DIR/ — каждый язык/платформа имеет свои подводные камни.

Zig выглядит почти как Rust, но делает синтаксис ещё приятнее за счёт более простой семантики и ряда изящных решений.

Числа
Литералы 92 всегда имеют тип comptime_int; при присваивании они неявно приводятся к нужному типу. Суффиксов нет.

Строки
Многострочные «сырые» строки пишутся через \\ в начале каждой строки; \ не экранируется, отступы не портятся, а лексер работает построчно.

Структуры
.{ .x = 1, .y = 2 } — запись поля через .x = совпадает с присваиванием, что позволяет грепом находить именно записи, а не чтения.

Типы
Все типы префиксные: u32, [3]u32, ?[3]u32, *const ?[3]u32. Разыменование постфиксное: ptr.*.

Идентификаторы
Синтаксис @"имя с пробелом" позволяет обходить ключевые слова и экспортировать любые имена.

Функции
fn add(x: i32, y: i32) i32 — без стрелки ->, так как лямбд нет, а возвращаемый тип всегда обязателен. pub fn main() void {}.

Переменные
const и var; часто используемое const короче, чем в Rust, но всё же длиннее Kotlin-овского val.

• Обсуждение разделилось: кому-то синтаксис Zig кажется «прекрасным» минимализмом, другим — «шумным» и «капризным».
• Спор о порядке «имя: тип» vs «тип имя»: одни хотят видеть тип первым, другие — имя.
• Критика деталей: @-префиксы, .{}, отсутствие лямбд, перенос строк, orelse без пробела.
• Плюсы: raw-строки Zig решают проблему отступов; обработка ошибок через try нравится многим.
• Сравнения: Kotlin, C#, Go, Rust, D — каждый считает «своё» лучше.
• Итог: «красота» синтаксиса субъективна и во многом привычна; после практики Zig начинает нравиться.

Представьте, вы пишете проект и вам нужна библиотека — назовем ее libpupa.

Вы находите текущую версию 1.2.3 и добавляете в зависимости: "libpupa": "1.2.3" Автор libpupa 1.2.3 в свою очередь зависел от liblupa версии 0.7.8 и записал это: "liblupa": "0.7.8" То есть libpupa 1.2.3 навсегда зависит от liblupa 0.7.8. Алгоритм разрешения зависимостей простой и детерминированный: берем версии верхнего уровня, затем версии их зависимостей, и так далее. Достаточно указать только верхние уровни — транзитивные получатся одинаковыми всегда. Зачем отдельный lockfile?

Но люди изобрели lockfile из‑за диапазонов версий. Диапазоны делают сборку зависимой от времени: сегодня вы получите liblupa 0.7.8, через 10 минут — 0.7.9. Это определяется не при публикации, а при сборке: вы можете подтянуть версию, которой не существовало на момент выпуска libpupa 1.2.3. Откуда автор libpupa знает, что будущая 0.7.9 не сломает его код? Семантическое версионирование — это лишь намек, не гарантия.

И смешно то, что эти диапазоны все равно «замораживают» в lockfile, и вы не получаете предполагаемой пользы. «Перегенерируй lockfile и обновись» — это ничем не отличается от обновления верхнеуровневых зависимостей. «Lockfile решает конфликты версий?» — нет: библиотека либо работает с новой версией, либо нет; запись «0.7.*» не помогает — все равно нужно выбрать рабочую версию.

«Но раз lockfile существует, значит, нужен!» — не обязательно. Пример: Maven. Экосистема Java 20 лет обходится без lockfile, при этом тянет сотни библиотек — и все детерминировано.

Вывод: lockfile усложняет без достаточных причин. Менеджеры зависимостей могут работать без него.

UPD: В Maven при конфликте транзитивных зависимостей выбирается версия, ближайшая к корню. Это детерминированно и позволяет переопределять версии. Если вышла d 2.1 с патчами безопасности, добавьте ее в корень — она и будет выбрана, не дожидаясь обновлений у всех. Если автоматически брать самую большую версию, вы потеряете возможность переопределения.

• Обсуждение крутится вокруг необходимости lock-файлов и версионирования: одни считают, что фиксированные версии и детерминированные алгоритмы достаточно, другие настаивают, что lock-файлы критичны для воспроизводимости и безопасности.
• Приводят примеры из экосистем Maven/Java, Go (MVS), Cargo/Rust, .NET, Scala: у каждого свои компромиссы; даже при детерминированном резолве сеть/репозитории делают сборки недетерминированными без lock-файлов и хэшей.
• Аргументы за версии-диапазоны: автоматическое получение патчей безопасности без вмешательства авторов верхнеуровневых библиотек; но это ломается при конфликтующих транзитивных зависимостях и несовместимых API/ABI.
• Много комментариев о том, что lock-файлы особенно нужны приложениям (прод, стейджинг, аудит), а для библиотек — меньше, но всё равно полезны из-за пересборок и целостности (хэши артефактов).
• Подчёркивают проблемы разных языков: в компилируемых — типы из разных версий несовместимы; в JS Node могут сосуществовать несколько версий, но это не решает безопасность/детерминизм.
• Некоторые отмечают, что главная путаница — не в lock-файлах, а в культуре семвера, централизованных репозиториях и UX инструментов; предлагают BOM/snapshot-подходы и периодические обновления с тестами/реновейтом.
• Отдельная ветка критикует дизайн сайта с анимированными иконками, мешающими чтению.