OpenCloud — это основной репозиторий серверного проекта с открытым исходным кодом от opencloud-eu. Проект полностью написан на Go и содержит кодовую базу для бэкенд-сервисов. Репозитория представляет собой облачную платформу с эмоджи погоды (🌤️) в описании, что может указывать на её метеорологическую направленность или просто на дружелюбный интерфейс.

Проект находится на GitHub, что обеспечивает прозрачность разработки и возможность сообщества вносить вклад. Использование языка Go говорит о фокусе на производительность, эффективность и простоту развертывания. Хотя в предоставленном тексте отсутствуют подробности о функциональности, лицензии или статусе разработки, сам факт существования репозитория указывает на активную разработку проекта с открытым исходным кодом.

• Пользователи обсуждают альтернативы Nextcloud, упомянуты OpenCloud и OpenTalk как новые решения.
• Обсуждается производительность Nextcloud, включая проблемы с медленной работой и частыми режимами обслуживания после обновлений.
• Участники обмениваются мнениями о том, насколько важны такие функции как веб-офис, календарь и заметки, и как они реализованы в разных решениях.
• Участники также обсуждают, что важно для них в личном облаке: простота развертывания, контроль над данными и отсутствие PHP.
• Некоторые участники выражают заинтересованность в том, чтобы увидеть сравнительную таблицу функций между Nextcloud и OpenCloud.

Автор делится своим опытом работы с различными языками программирования, объясняя, почему 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 объективно соответствовал заявленным критериям лучше. Оказалось, что другие языки даже не рассматривались — решение было основано на хайпе. Автор подчеркивает, что при обсуждении языков программирования всегда происходит два диалога: видимый технический и невидимый, связанный с идентичностью инженера.

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

• Разнообразие технологий охватывает от классических стеков (Java/Spring, C++, Python) до современных стеков (TypeScript, Next.js, Rust, Go) и специализированных инструментов (Unity, Unreal, embedded, data engineering, QA, low-code, etc.)
• Участники демонстрируют глобальный охват: от США и Канады до Европы, Азии, Австралии и Латинской Америки, что подчеркивает международный характер рынка.
• Почти все открыты к удаленной работе, но при этом большинство не готовы к релокации, что подчеркивает гибкость и предпочтение к удаленной работе.
• Некоторые участники подчеркивают свою готовность к релокации, особенно внутри США или в крупных технологических центрах.
• Некоторые участники подчеркивают свою готовность к релокации внутри ЕС или в Северной Америке, что может быть важно для компаний, которые ищут таланты в этих регионах.

• Fil-C предлагает практически полную безопасность памяти при компиляции существующего кода, но при этом требует пересборки всего пользовательского пространства, включая системные библиотеки, что делает его практически неприменимым для больших проектов.
• Появление Fil-C вызвало дискуссию о том, что языки вроде Rust и Go уже предлагают безопасность памяти без необходимости переписывать весь код, и что Fil-C не предлагает ничего нового для новых проектов.
• Некоторые участники обсуждения отметили, что Fil-C не поддерживает FFI, что делает невозможным использование C-библиотек, что является критическим для большинства проектов.
• Другие участники подчеркнули, что Fil-C не предлагает никаких преимуществ для новых проектов, так как он не предлагает ничего нового, что не может быть достигнуто с помощью других инструментов.

• Python-оптимизация часто сводится к выносу «горячих» участков в C/NumPy, а не к микро-оптимизации кода.
• Сам факт, что в CPython «всё является объектом» влечёт за собой неизбежные накладные расходы, которые нельзя убрать без отказа от части философии языка.
• JIT (PyPy) и отсутствие GIL в будущем могут решить 90 % проблем производительности, но это не касается CPython.
• Сообщество в целом согласно с тем, что вместо попыток «оптимизировать» Python-стильный код, стоит либо полностью переписать узкие места на C/Rust, либо вовсе перейти на Julia/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-библиотеках.

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

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

• Подтверждение воспроизводимых сборок (reproducible builds) вызывает у участников противоположные реакции: от признания важности до обвинений в растрате ресурсов.
• Некоторые участники подчеркивают, что такие сборки защищают от теоретических угроз, которые могут быть не более чем гипотетическими.
• Подчеркнуто, что если бы кто-то смог внедрить вредоносный код в процесс сборки, то эти логи позволили бы это обнаружить.
• Представлен инструмент sourcespotter для отслеживания исходников.
• В то же время, обсуждение выявило, что не все разделяют убеждение в ценности или приоритете таких усилий, считая их растратой ресурсов на защиту от гипотетических угроз.

• Обсуждение вокруг пакета golang.org/x/tools/gopls и его влияния на разработку, включая предложение использовать Go вместо JavaScript, вызвало споры о целесообразности и практичности такого подхода.
• Участники обсуждали, что вместо того, чтобы писать на Go, лучше позволить импортировать .go файлы, что более идиоматично для JS бандлеров.
• Поднялся вопрос о том, что клиентский код не должен диктовать бизнес-логику, и что стоит быть осторожным с подобными техниками.
• Была отмечена важность такого подхода для обучения и вдохновения новичков в области WASM и Go.
• Также было отмечено, что это может быть полезно для оффлайн-функциональности и как фоллбек, если API недоступен.
• В конце концов, обсуждение свелось к тому, что это может быть полезно для обучения и вдохновения новичков в области WASM и Go.

Автор изначально не интересовался 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 и обычного чтения должен быть сделан на основе конкретного сценария и требований к производительности, а не на основе предвзятого убеждения в превосходстве одного над другим.

Гитхаб обновил свою систему поиска кода, сделав её более интуитивной и эффективной. Теперь пользователи могут использовать естественный язык для запросов, например, "find all Go repositories where the number of stars is greater than 1000". Это стало возможным благодаря интеграции искусственного интеллекта, который понимает контекст и синтаксис. В качестве примера, разработчики теперь могут искать код с учётом семантики, а не только по ключевым словам. Это улучшение — часть более масштабного обновления экосистемы GitHub, направленного на улучшение discoverability кода.

• Достигнута пропускная способность 19.8 ГБ/с для префиксной суммы — в 1.8 раз быстрее, чем наивная реализация, и в 2.6 раза быстрее, чем FastPFoR.
• Обсуждение выявило, что при использовании GPU-реализации приходится копировать данные через PCIe, что снижает выгоду от использования GPU.
• Появился вопрос о том, не лучше ли было бы хранить абсолютное значение каждые N дельта вместо потока дельта, что позволило бы распараллелить декодирование.
• Участники обсуждения отметили, что влияние на производительность имеют не только выбор алгоритма, но и такие факторы, как размер кэша L3, частота памяти и архитектура памяти.

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

Первая проблема возникла при попытке загрузить данные в Backblaze — система выдавала ошибку из-за неверного URI, что потребовало фикса от разработчиков.

Вторая проблема: в новой версии удалили флаг -if-replica-exists, критически важный для проверки наличия бекапов перед запуском приложения. Хотя флаг обещали вернуть в следующей версии, его отсутствие в 0.5.0 создавало сложности.

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

Автор подчеркивает, что несмотря на трудности, он продолжает использовать Litestream за его полезность, но советует подождать с апгрейдом до следующего релиза.

• The user is discussing issues they encountered while implementing lightweight read replicas for a Go SQLite driver, referencing a specific implementation and a GitHub repository.
• They mention that while there are issues, the concept is workable, and they already have a version that mostly works, noting the massive changelog and that it's not unexpected to have issues given the scope.
• Other users discuss the benefits of Litestream 0.5.0, including an official Docker image, though one user corrects that there has been an official Docker image for years, since version 0.3.4.
• One user shares they are staying on an older version (0.3.13) for now due to similar issues but are excited for 0.5.x once it stabilizes, praising the integration of Litestream, SQLite, and Caddy for single-box operations.
• A user notes the most disruptive part is the migration to a new LTX format, which is hard to do incrementally, and another user reflects on the versioning, noting that being a 0.x release means breaking changes are expected, though it might still be a minor footnote in the software's lifecycle.
• The original poster concludes by correcting an oversight about the Docker image, noting the badge has been present for years, and speculates that the user who thought the image was new might have had a bad initial experience that discouraged them from trying again.

Новая функция http.CrossOriginProtection в Go 1.25 помогает защититься от CSRF, проверяя заголовки Sec-Fetch-Site и Origin. Она блокирует небезопасные запросы (POST, PUT и т.д.) от разных источников. Однако она не защищает от старых браузеров без этих заголовков. Для полной безопасности следует сочетать её с токенами.

• Обсуждение показало, что защита от CSRF через заголовки Origin/Sec-Fetch-Site работает примерно в 95% браузеров, и автор статьи не считает это проблемой.
• Участники обсуждали, что отказ от поддержки старых браузеров — это сознательный выбор, а не упущение, и что в 2025 году оставшиеся 5% в основном представляют собой старые телевизоры, телефоны и прочие устройства, которые не могут быть обновлены.
• Некоторые участники отметили, что даже если бы мы хотели защитить этих пользователей, устаревшие методы вроде проверки Referer или токенов всё ещё не защитят от CSRF, а значит всё равно придётся от них отказаться.
• Была поднята тема, что Rails и другие фреймворки уже давно решили эту проблему, но автор статьи ответил, что не видит в этом необходимости, так как считает, что вся ответственность за безопасность ложится на разработчика, который должен внимательно изучить документацию.

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

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

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

В то же время, ключевая инновация 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 в качестве встроенных типов делает язык менее выразителен, чем он мог бы быть.

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

Например, в случае с leftpad, многие реализации были формально верифицированы относительно свойства «длина результата равна максимуму из n и длины s», но это не гарантирует, что результат будет визуально корректным при использовании Unicode-символов.

Другая проблема — ошибки в самом инструменте верификации, хотя такие случаи редки.

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

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

• Обсуждение показало, что формальная верификация кода не покрывает аппаратные сбои и ограничения окружения, а также не решает проблему валидации требований пользователя.
• Участники подчеркнули, что доказательство корректности кода не защищает от ошибок в спецификации, а также не покрывает такие факторы как переполнение целочисленных типов и другие архитектурные ограничения.
• Была затронута тема различия между верификацией (verification) и валидацией (validation), где первое касается соответствия кода спецификации, а второе — решаемости реальной задачи.
• Обсуждение подняло вопрос о том, что формальные методы не покрывают такие аспекты как отказ оборудования, влияние космических лучей и другие факторы окружения, что делает их менее полезными в контексте безопасности.
• Участники также обсудили, что даже при наличии формальной верификации, остаются риски, связанные с человеческим фактором, так как спецификация может не отражать реальные требования пользователя.

Blaze — это высокопроизводительный полнотекстовый поисковый движок на Go, который специализируется на скорости и простоте использования. Он использует индексирование на основе памяти и поддерживает полнотекстовый поиск, включая поиск по префиксу, суффиксу и фразам. Проект разработан для того, чтобы быть легко встраиваемым в любое приложение, которое требует быстрый и эффективный поиск. Blaze использует современные алгоритмы сжатия и индексации, такие как Brotli и Snappy, для оптимизации производительности и использования памяти. Он также поддерживает горизонтальное масштабирование и может быть развернут в облаке. Проект имеет открытый исходный код под лицензией MIT и активно поддерживается сообществом.

• Проект представляет собой учебный пример полнотекстового поискового движка, написанный на Go, с акцентом на внутреннее устройство индекса и простоту кода.
• Автор отказался от парсинга строковых запросов, чтобы не отвлекать внимание от того, как устроен индекс.
• Несколько участников обсуждения отметили, что проект не лицензирован и не имеет лицензии, что может затруднить его использование.
• Другие участники предложили сравнить производительность с Lucene и Bleve, а также рассмотреть возможность интеграции с векторными базами данных.
• Автор ответил, что проект задуман как учебный пример, а не как полноценная замена существующим решениям.

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) и необходимость улучшения документации, особенно для новичков.

Статья разбирает, как структуры данных влияют на производительность Go-программ под современными CPU. Автор подчеркивает, что чтение из оперативной памяти в 60 раз медленнее, чем из кэша L1, и что ложный обмен (false sharing) между ядрами может убить производительность. Показано, как добавление 56-байтовой прокладки между полями структуры устраняет проблему и ускоряет код в 6-10 раз. Другой совет — разделять «горячие» и «холодные» данные и использовать структуры, оптимизированные под кэш-линии. Показано, как профилировать кэш-промахи через perf и как тестировать эффективность структур данных.

• False sharing и cache-line padding в Go приводят к 10-кратному ускорению при использовании структур, разделённых на разные ядра, но требуют ручного управления выравниванием и размером кэш-линии.
• Компилятор Go не переупорядочивает поля структур и не вставляет паддинг, что делает невозможным автоматическое устранение false sharing без кода, что ограничивает оптимизации только ручными методами.
• Пользователи отмечают, что большинство описанных приёмов применимы к другим языкам и что современные компиляторы должны бы справляться с большинством этих проблем автоматически, но в то же время признают, что для низкоуровневой оптимизации лучше подойдут другие языки и инструменты.

Универсальный раннер и умный REPL на Rust, который автоматически определяет язык программирования по расширению файла или shebang и выполняет код без предварительной настройки. Поддерживает Python, JavaScript, Ruby, Go и другие популярные языки, экономя время на переключении между средами.

Инструмент предлагает интерактивный режим с подсветкой синтаксиса и историей команд, а также пакетную обработку файлов. Ключевое преимущество — кроссплатформенность и минимальные зависимости, поскольку написан на Rust. Практический бонус: можно быстро тестировать сниппеты, не покидая терминал.

• Автор представил инструмент run как унифицированный REPL для множества языков, позволяющий выполнять код разных языков одной командой без переключения между отдельными REPL.
• Обсуждаются технические детали и сравнение с существующими инструментами: шебанг-строка, задачами just, магическими командами IPython/Jupyter и возможностью запуска скриптов через Bash.
• Уточняется классификация языков (Swift, Kotlin) как компилируемых или интерпретируемых в контексте работы инструмента.
• Поднимается вопрос о мотивации создания инструмента и терминологии ("polyglot"), а также простоте добавления поддержки новых языков через реализацию trait на Rust.
• Автор поясняет, что инструмент — это эксперимент новичка в Rust, а не замена существующим решениям.

Слияние частных врачебных практик с больничными системами приводит к росту затрат пациентов. Исследование показывает, что такие сделки сокращают конкуренцию на локальных рынках, позволяя больницам устанавливать более высокие цены на услуги. Например, после интеграции стоимость некоторых медицинских процедур может увеличиться на 10–20%, поскольку пациенты реже сравнивают варианты и выбирают врачей в рамках одной системы.

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

• Усложнение системы медицинского биллинга и страхования в США приводит к консолидации практик и росту издержек.
• Поглощение частным капиталом региональных больниц и служб скорой помощи ведет к сокращению критических услуг и росту смертности.
• Проблемы совместимости медицинских систем и EHR затрудняют обмен данными между разными поставщиками медицинских услуг.
• Обсуждается этическая сторона "статистического убийства" — приоритета прибыли над спасением жизней в системных решениях.
• Консолидация в отрасли снижает конкуренцию, что приводит к росту цен и ухудшению качества обслуживания.

Компиляция 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, в то время как другие защищают его и призывают к поддержке.

Разработчики часто сталкиваются с необходимостью сравнения данных, будь то код, текст или произвольные последовательности. Существующие библиотеки для вычисления разниц (diff) часто ограничены: многие работают только с текстом, не предоставляют структурированный вывод или страдают от проблем с производительностью и читаемостью результата. Например, популярный алгоритм Майерса, хотя и даёт минимальные различия, в худшем случае имеет квадратичную сложность, что делает его непригодным для больших или сильно отличающихся данных.

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

• Обсуждение затрагивает различные типы diff-алгоритмов (одномерные, многомерные, древовидные) и их применение, включая сравнение кода, JSON-структур и даже схем баз данных.
• Участники делятся инструментами для просмотра diff (например, diff2html, meld, Beyond Compare) и отмечают проблемы существующих библиотек, такие как неожиданное экранирование текста.
• Поднимаются вопросы о важности минимальности diff, семантического понимания перемещений блоков и использования метаданных для улучшения алгоритмов.
• Обсуждаются практические применения diff-алгоритмов за пределами контроля версий: в тестировании, юридической сфере, сравнении расписаний и обновлении терминальных экранов.
• Упоминаются конкретные личности (например, Джин Майерс) и работы (статья Nugroho 2019 года), а также выражаются пожелания по улучшению алгоритмов, например, для работы с перемещенными данными.

После многолетнего активного использования Julia для анализа данных и разработки пакетов автор перестал рекомендовать язык из-за серьёзных проблем с корректностью и композируемостью. В экосистеме Julia наблюдается высокая частота критических ошибок, которые проявляются даже в базовых операциях: например, функции sum! и prod! иногда молча возвращают неверные результаты, а выборка из распределений может давать смещённые или некорректные значения.

Особенно уязвимы комбинации пакетов или нестандартные типы данных — Euclidean Distance не работает с векторами Unitful, а макрос @distributed ломается при использовании OffsetArrays. Многие ошибки приводят к выходу за границы памяти или тихим неверным вычислениям, что ставит под сомнение надёжность любых сложных расчётов. Практический вывод: в проектах, где важна точность, Julia может представлять неприемлемый риск.

• Участники обсуждают проблемы с корректностью и стабильностью экосистемы Julia, включая критические баги в базовых пакетах и проблемы совместимости.
• Высказываются опасения, что эти проблемы делают язык неподходящим для проектов, где важна точность, несмотря на его элегантность и производительность.
• В качестве альтернатив для научных вычислений упоминаются Python с библиотеками (PyTorch, Jax, TensorFlow), R (и tidyverse), а также Rust и Go.
• Некоторые пользователи делятся негативным опытом из-за невыполненных обещаний (например, быстрая компиляция) и переходят на другие языки.
• Обсуждается актуальность критики, поскольку некоторые примеры проблем датируются 2024 годом, несмотря на то, что исходный пост мог быть написан ранее.

Devbox — это инструмент для создания изолированных сред разработки на основе Docker. Каждый проект работает в собственном контейнере, что предотвращает конфликты зависимостей и сохраняет чистоту основной системы. Контейнеры автоматически перезапускаются и сохраняются между перезагрузками, а код остаётся на файловой системе хоста для удобного редактирования.

Инструмент предлагает простые команды CLI, встроенные проверки безопасности и шаблоны для Python, Node.js, Go и веб-разработки. Также поддерживаются расширенные функции Docker, такие как проброс портов, монтирование томов и настройка переменных окружения.

• Обсуждаются сходства и отличия Devbox от альтернатив: Devcontainers (от Microsoft), Toolbx, Distrobox и других, с акцентом на поддержку в разных IDE и сложность их реализации вне VSCode.
• Поднимается проблема конфликта имен с другими проектами, в первую очередь с Devbox от Jetify, что указывает на возможное отсутствие анализа существующих решений.
• Отмечаются вопросы о безопасности и изоляции, в частности, возможность использования Docker-in-Docker и её последствия.
• Участники делятся личным опытом использования Devbox и аналогичных инструментов, отмечая их удобство для создания воспроизводимых сред без потери производительности.
• Обсуждается, решает ли подход с контейнерами проблему "dependency hell" и насколько он оправдан для разных языков и типов разработки (веб, мобильная).

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

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

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

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

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

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

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

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

Приложение полностью приватное — аудио не отправляется в облако, всё обрабатывается на устройстве. Handy позиционируется как доступный инструмент, свободный от подписок, с возможностью кастомизации и поддержкой сообщества через спонсоров like Wordcab и Epicenter. Проект приглашает к участию в разработке и финансировании.

• Пользователи обсуждают высокое потребление ресурсов современных десктопных приложений, приводя примеры, где даже простые действия занимают значительный объем памяти (~120MB).
• Представлены альтернативные и похожие инструменты для преобразования речи в текст (STT), такие как Whispy (Linux), hns (CLI), Gnome расширение и VoiceInk, с акцентом на локальность и минимализм.
• Обсуждаются технические детали проектов: использование моделей Whisper и Parakeet, поддержка GPU/CPU, кроссплатформенность, языки разработки (TypeScript, Rust, Go) и вопросы шумоподавления.
• Участники сравнивают качество и удобство локальных решений с облачными сервисами (например, Groq) и встроенными функциями ОС (macOS dictation, iPhone STT).
• Затрагиваются темы приватности, производительности на слабом железе, удобства использования для программирования и запросы на аналогичные инструменты для преобразования текста в речь (TTS).

Go позволяет эффективно симулировать миллионы частиц на сервере и транслировать результат клиентам в виде видео, избегая отправки данных каждой частицы. Ключевая идея — рендерить симуляцию на сервере и передавать клиентам только сжатые кадры, что делает нагрузку независимой от числа частиц и зависящей лишь от разрешения. Для HD-видео (1920×1080) несжатый кадр занимает ~2 МБ, но сжатие H264/H265 сокращает его до ~260 КБ, что при 24 кадрах в секунду близко к обычному видеопотоку.

Это выгоднее, чем отправлять данные частиц: даже при оптимизации (8 байт на частицу) миллион частиц потребует 8 МБ на кадр — в 4 раза больше, чем несжатое изображение. Такой подход обеспечивает совместимость с любыми устройствами, включая Smart TV, поскольку клиенту нужно лишь воспроизводить видео на canvas, без тяжёлых вычислений. Go справляется с этой задачей, демонстрируя производительность, достаточную для многопользовательских симуляций в реальном времени.

• Обсуждаются сильные стороны Go: простота синтаксиса, поддержка больших кодовых баз, быстрая сборка и встроенные инструменты для тестирования и конкурентности.
• Отмечается слабая оптимизация Go для численных расчётов и вычислительных задач, выражается надежда на внедрение SIMD-инструкций в будущем.
• Предлагаются методы сжатия изображений для проекта, включая использование PNG и дельта-кодирования с RLE, а также улучшение сжатия через XOR нового и старого кадра.
• Критикуется использование Euler-интегрирования в симуляции частиц, автор признаёт упрощённый подход с учётом дельта-времени и трения.
• Упоминается, что эксперимент с пакетом arena для управления памятью приостановлен из-за проблем с API, идёт поиск альтернативных решений.

Смартфоны получают гиперспектральные камеры, способные захватывать данные за пределами видимого спектра — от ультрафиолета до инфракрасного излучения. Это достигается за счёт миниатюрных сенсоров и алгоритмов, которые анализируют отражённый свет на сотнях узких длин волн, выявляя уникальные химические «отпечатки» материалов. Например, такая технология может определить спелость фрукта, подлинность лекарства или наличие загрязнений в воде.

Практическое применение охватывает медицину (диагностика кожных заболеваний), сельское хозяйство (мониторинг состояния растений) и потребительские сценарии (проверка качества продуктов). Хотя ранее гиперспектральная съёмка требовала громоздкого и дорогого оборудования, интеграция в мобильные устройства открывает её для массового использования, стирая границы между профессиональными инструментами и повседневными гаджетами.

• Сомнения в возможности восстановления полного спектра по трём каналам RGB без специального оборудования и эталонной калибровки.
• Обсуждение технических деталей метода: использование специальной эталонной цветовой карты, напечатанной на профессиональном принтере с 11 картриджами, для калибровки.
• Критика патентования метода как попытки монетизации известного в научной среде подхода.
• Предположения о практических ограничениях метода: применимость в основном к прозрачным жидкостям, зависимость от источника освещения.
• Обсуждение альтернативных методов спектроскопии (например, с использованием дифракционной решётки) и сравнение их точности.

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 признаком недостатков языка, в то время другие видят в этом мощное дополнение к инструментарию.

Встраивание структур в Go позволяет обращаться к полям вложенных структур напрямую, но может приводить к неожиданным конфликтам имён. Например, если две вложенные структуры содержат поле с одинаковым именем, компилятор не выдаст ошибку, а выберет поле из наименее вложенной структуры — в примере opts.URL вернёт "abc.com", хотя ожидалась неоднозначность.

Это поведение опасно, так как маскирует потенциальные ошибки проектирования: код компилируется, но логика может работать некорректно. Конфликт имён при встраивании не вызывает паники, а разрешается неявно, что усложняет отладку. На практике такие ситуации лучше избегать, явно именуя вложенные структуры или переименовывая поля.

• Критика структуры Go за разрешение конфликтов имён полей при вложении структур, что может приводить к неочевидным ошибкам.
• Предложения считать такие случаи ошибкой компиляции или, как минимум, выдавать предупреждения через линтеры.
• Отмечается, что поведение соответствует спецификации (выбирается поле с наименьшей глубиной вложения), но это противоречит интуиции некоторых разработчиков.
• Приводятся аргументы за и против использования вложения структур: полезно для композиции методов, но опасно для данных.
• Обсуждается историческое происхождение фичи из Plan 9 C и её потенциальная полезность в ограниченных сценариях.

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

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

TernFS — экзабайтная распределенная файловая система с поддержкой нескольких регионов

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

TernFS теперь доступна как открытое ПО на GitHub. В статье объясняется её архитектура и ключевые детали реализации.

Зачем ещё одна файловая система?

Крупные tech-компании часто разрабатывают собственные распределенные файловые системы из-за их критической важности. XTX оказалась в аналогичной ситуации и создала TernFS как универсальное решение для хранения — от «холодных» данных до временных файлов для обмена между GPU-задачами.

Возможности TernFS:

• Масштабируемость до десятков экзабайт, триллионов файлов и миллионов одновременных клиентов.
• Избыточное хранение данных для защиты от сбоев дисков.
• Отсутствие единой точки отказа в службах метаданных.
• Поддержка снимков файлов для защиты от случайного удаления.
• Работа в нескольких регионах.
• Агностичность к оборудованию, использование TCP/IP.
• Эффективное использование разных типов хранилищ (SSD, HDD).
• Доступ через собственный API (TCP/UDP) и модуль ядра Linux.
• Минимальные зависимости для сборки (C++, Go, RocksDB).

Ограничения:

• Файлы неизменяемы после записи.
• Не подходит для очень маленьких файлов (медиана — 2 МБ).
• Ограниченная пропускная способность при создании/удалении директорий.
• Отсутствие встроенной системы разрешений.

Разработка началась в 2022 году, с 2023 года система используется в production. К середине 2024 года все ML-задачи работают на TernFS. По состоянию на сентябрь 2025 года система хранит более 500 ПБ на 30 000 дисках и 10 000 SSD в трёх дата-центрах, с пиковой пропускной способностью в несколько ТБ/с. Потерь данных не зафиксировано.

Высокоуровневая архитектура

Основной API TernFS реализован четырьмя службами:

• Шарды метаданных — хранят структуру директорий и метаданные файлов.
• Координатор междиректорных транзакций (CDC) — выполняет транзакции между шардами.
• Службы блоков — хранят содержимое файлов.
• Реестр — хранит информацию обо всех службах и мониторит их.

Диаграмма взаимодействия служб TernFS и клиентов.

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

• Обсуждение технических особенностей TernFS: отсутствие RDMA, использование TCP/IP, репликация данных, ограничение на минимальный размер файла (~2MB), специализированная система метаданных.
• Сравнение с другими файловыми системами (CephFS, Lustre, GPFS): различия в архитектуре, производительности, поддержке POSIX и целевых use cases.
• Вопросы о бизнес-модели и масштабах данных XTX: хранение >500PB для ML-моделей в трейдинге, критика "отсутствия реальной ценности".
• Обсуждение лицензии (GPLv2-or-later/Apache-2.0) и предложения по улучшению документации (добавление примеров использования).
• Замечания о нишевых решениях для больших данных: акцент на immutable-данные, сложности с метаданными для tiny files, специализация под конкретные задачи.

Registry Explorer — интерактивный просмотрщик образов и репозиториев.
Введите публичный образ (ubuntu:latest) или реп (ubuntu), листайте слои и файлы без скачивания.

Примеры

• cgr.dev/chainguard/static:latest-glibc
• gcr.io/distroless/static
• ghcr.io/homebrew/core/crane
• registry.k8s.io и др.

Как работает
Сервис на Cloud Run, движок — google/go-containerregistry.
Первый запрос к слою качает и индексирует его; дальше читаем по Range-запросам.
Трафик регистри уменьшается: скачивайте один раз и шлите ссылку.
Docker Hub предоставляет безлимитный доступ.

Случайный доступ к gzip
Храним ~1 % распакованных данных; по ним строим «точки входа» в поток и читаем без распаковки всего слоя.
Код: github.com/jonjohnsonjr/dagdotdev

• @jonjonsonjr: это его pet-проект для отладки образов; часть фич спрятана как пасхалки.
• @mshekow: инструмент oci.dag.dev — лучший браузер регистри, можно развернуть самому (Go-CLI).
• @gucci-on-fleek: поддерживает zstd, cosign-подписи, показывает размер каждого файла и ссылки на Sigstore.
• @glitchcrab: использует регулярно, быстрее чем crane.
• @lclc: сервер не выдержал наплыва посетителей с HN — «Rate exceeded».

oq — консольный просмотрщик OpenAPI-спецификаций.
Быстро открывает swagger.json|yaml в терминале, показывает эндпоинты, параметры, примеры ответов.
Установка: go install github.com/plutov/oq@latest.
Использование: oq spec.yaml.

• Утилита «oq» — терминальный просмотрщик OpenAPI-спецификаций, упрощающий навигацию по большим YAML/JSON.
• Пользователи практикуют spec-driven development: спецификация = единый источник правды, из неё генерируют типизированный клиент и сервер.
• Название «oq» уже занято другим проектом (homebrew-установка ставит не тот пакет); автор пока не переименовывает, предлагает брать бинарь с GitHub-релизов.
• Поддержка OpenAPI 3.1 заявлена, но реализована поверх библиотеки kin-openapi, которая 3.1 пока не умеет; для простого листинга маршрутов и компонентов это работает.
• В планах — добавить возможность делать реальные HTTP-запросы прямо из viewer.

Rust: «неразумная» скорость сортировки

• Сортировка в Rust быстрее C++ и Go благодаря LLVM, агрессивному векторизатору и ручным оптимизациям.
• Алгоритм: pdqsort (pattern-defeating quicksort) + векторизованный партиционер.
• Ключевые приёмы:
  • 128-битные SIMD-операции (SSE/AVX) для фильтрации элементов;
  • branchless-код, предикты, минимизация кэш-промахов;
  • специализированные пути для малых типов (u8, u16, u32, u64, f32, f64) и копируемых структур;
  • ручная развёртка циклов, инлайн, отказ от стандартных абстракций.
• Сравнение: на случайных u64 Rust ~2× быстрее libstdc++, ~3× быстрее Go; на почти отсортированных — ещё больше.
• Память: всё делается in-place, доп. буфер 1 КБ максимум.
• Сложность: O(n log n) в среднем, O(n log n) worst-case (pdqsort гарантирует).
• Код открыт, можно подсмотреть и перенести на другие языки.

• Универсальный лайфхак: «сначала отсортируй данные» — и задача часто сводится к O(log n).
• Но глобальная сортировка дороже с ростом объёма; иногда проще пересмотреть подход или использовать хэш-таблицу.
• Современные unstable-sort и foldhash настолько быстры, что ручные оптимизации часто проигрывают и требуют лишней памяти.
• Для 4 уникальных значений подсчёт или perfect-hash проще и быстрее полной сортировки; эксперимент ставит границы, а не решает продакшен-задачу.

JiraTUI — терминальный клиент Jira: ищи, создавай, обновляй задачи не отрываясь от кода.

Возможности

• Поиск: быстрый фильтр по статусу, исполнителю, приоритету; продвинутый JQL с сохранением выражений.
• Создание: новая задача из консоли — заголовок, описание, приоритет за секунды.
• Обновление: статус, исполнитель, метки, дедлайн — всё правится командой.
• Комментарии: добавляй/удаляй прямо из терминала.
• Связи: линкуй/отвязывай подзадачи и зависимости без GUI.

Плюсы

• Конфигурируем: хоткеи и настройки под себя.
• Прост: команды понятны без мануала.
• Быстр: действия выполняются мгновенно.
• Удобен: минимум кликов, максимум фокуса.

GitHub | Документация

• Пользователи в восторге от Jira-TUI: быстрый поиск, красивый интерфейс, спасение от тормозов веб-версии.
• Просят аналоги для GitHub, Linear, Asana, Slack; ищут TUI-библиотеки Rust/Go такого же уровня.
• Хотят кликабельные ссылки из почты/Slack сразу в TUI, но это требует кастомного URI-обработчика.
• Кто-то просит CLI-версию для массового импорта задач, кто-то — классический Kanban-доску.
• Поднимаются вопросы безопасности (API-ключ в стороннем проекте) и поддержки on-prem Jira API v2 (не поддерживается).

Tailguard — Docker-контейнер, связывающий Tailscale и WireGuard.

• Поднимается одной командой, не требует root.
• Перенаправляет трафик Tailscale → WireGuard и обратно.
• Подходит для «проброса» Tailscale в сети, где нативный клиент не ставится.

• TailGuard — это контейнер, который автоматически берёт конфиг WireGuard и объявляет подсети из туннеля как Tailscale-subnet-router; остальному tailnet они сразу доступны.
• Проект начинался с «пары строк», но пришлось добавить переподключение при смене IP, DNS-ротацию и лёгкий React-UI; всё упаковано в Go-сервис + контейнер.
• Решение работает и с fly.io: вместо camellia.conf на клиенте поднимают TailGuard-контейнер рядом с их WireGuard-шлюзом и получают приватную сеть fly внутри Tailscale.
• На Android единовременно можно только один VPN, поэтому TailGuard удобнее «двойных» подключений; на iOS/WG-официальном клиенте можно выборочно маршрутизировать.
• Альтернатива — готовые 5G-роутеры GL.iNet (IMEI-клон, встроенный Tailscale/WireGuard), но у автора был опыт с TP-Link Deco X50-5G и он его «не особо рекомендует».

Новый экспериментальный JSON-API в Go

Go 1.25 предлагает encoding/json/v2 и encoding/json/jsontext — переработанные пакеты для работы с JSON. Они решают давние проблемы стандартного encoding/json и пока доступны только по флагу GOEXPERIMENT=jsonv2.

Главные недостатки старого API

• Неточности синтаксиса: принимает невалидный UTF-8, дублирует ключи, трактует числа как float64.
• Производительность: 2-3× медленнее современных альтернатив; каждый вызов тратит память на рефлексию.
• Гибкость: нельзя пропустить неизвестные поля, работать с потоковым JSON, получать исходный текст, сохранять порядок ключей, использовать сторонние типы.

Что нового в v2

• Три пакета
  – jsontext — низкоуровневое чтение/запись токенов, сохраняет формат.
  – json — высокоуровневый marshal/unmarshal, совместим с v1, но строже и быстрее.
  – jsontext можно использовать отдельно для потоковой обработки.

• Строгость
  UTF-8 проверяется, дубли ключей — ошибка, числа не теряют точность.

• Производительность
  Без рефлексии в hot-path, 2-3× быстрее, меньше аллокаций.

• Новые возможности
  Пропуск неизвестных полей, сохранение порядка, работа с any, доступ к сырому JSON, совместимость с v1 через теги.

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

GOEXPERIMENT=jsonv2 go mod download

import "encoding/json/v2"

Фидбек приветствуется: golang.org/issue/71497.

• Вышел экспериментальный encoding/json v2: новый API, лучшая производительность, но спорные решения по nil-значениям.
• Часть пользователей рада росту скорости и модульному пакету jsontext; другие считают, что костыли с nil → null остались.
• Кто-то уже прогнал тысячи тестов — почти всё прошло; кто-то нашёл регрессию аллокаций. Авторы просят больше отзывов.
• Сравнения со сторонними библиотеками (Sonic, goccy) показывают выигрыш в CPU, но проигрыш в безопасности и поддержке ARM.
• Обсуждение выродилось в холивар: «почему за 15 лет JSON до сих пор не решён» vs «две v2 за всю историю — отличный результат».

from-bash-to-go-part-ii
Репозиторий курса «Go для бывалых bash-скриптеров, часть II» — практика по созданию CLI-утилит на Go.

• В Go пакет *_test — единственное исключение из правила «один пакет на каталог», позволяя тестировать только публичное API.
• Участники хвалят стиль статьи: сначала показывается «ошибочный» шаг новичка, затем объясняется, почему он не работает, и даётся правильное решение.
• Такая линейная подача материала ускоряет реальное обучение, экономя время на поиск разрозненных советов.
• Доп. совет: в каталоге не-main-пакета можно разместить package main-файлы, что удобно для go generate.

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

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

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

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

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

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

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

• VMware снова в суде: Tesco обвиняет её в «нечестной» лицензии и требует компенсации.
• Ритейлер заявляет, что VMware навязывала ненужные продукты и блокировала конкурентов.
• Иск подан в Лондонский высокий суд; сумма не раскрыта.

• Пользователи описывают VMware как «любовь-ненависть»: технологию уважали, но Broadcom превратил лицензирование в кошмар.
• Основная претензия — Broadcom не соблюдает контракты, резко поднимает цены и убивает поддержку; это толкает клиентов к миграции.
• Крупные компании уходят на Nutanix, OpenStack, Proxmox и KubeVirt, стремясь избежать vendor-lock-in и аудитов.
• Схема Broadcom — «выжать максимум из захваченного актива», сократив R&D и заставив клиентов переплачивать.
• Даже Oracle теперь воспринимается как более надёжный партнёр, чем Broadcom/VMware.

Flint — лёгкий инструмент для управления виртуальными машинами Linux.
Клонируй, настрой и запускай ВМ из CLI без лишних зависимостей.

• Пользователи не поняли, что делает утилита: «управляет» KVM-ВМ, но не ясно — создаёт, запускает, монтирует папки или работает по сети.
• Автор показал компактный бинарь на Go, но код (~26 k строк) написан «вайб-кодингом» без тестов, поэтому многим не доверяют.
• Обсуждали альтернативы: systemd-nspawn, libvirt/virsh, Virt-Manager, Cockpit; последний удобен, но по умолчанию слушает 0.0.0.0 и требует PAM-логин.
• Нашлись советы: Cockpit завернуть в SSH-туннель, libvirt подключаться по SSH, PAM заменить на безопасный модуль.
• Вопросы о Vite-hot-reload в гостевой ОС, снапшотах и расписании остались без ответа.

Слив 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-корейских документов и следы настройки под корейскую локаль воспринимаются как намёк на происхождение, но критики считают это слабым доказательством.
• Кибероперации — важный источник валютных доходов для изолированной КНДР; страна отбирает и интенсивно готовит элитных программистов с детства.

Репозиторий показывает, как в Racket писать анонимные рекурсивные функции без letrec и имен.
Ключевая идея — Y-комбинатор: лямбда получает себя как аргумент и вызывает его для следующего шага.

(define Y
  (λ (f)
    ((λ (x) (x x))
     (λ (x) (f (λ (a) ((x x) a)))))))

((Y (λ (fact)
      (λ (n)
        (if (zero? n) 1 (* n (fact (sub1 n)))))))
 5) ; 120

Такой приём работает для любой рекурсии: факториал, fib, обход списков и т.д.

• Обсуждение началось с примера анонимной рекурсии на Racket; оказалось, что код совместим с любым R6RS-Scheme, включая проект scheme-rs.
• Участники сравнили подходы: в Clojure нужен явный recur, в Racket хвостовые вызовы оптимизируются автоматически.
• Кто-то спросил, стоит ли брать Racket для повторного изучения ФП; советуют почитать «zen of Racket» и быть готовым к узкой, но мощной экосистеме.
• Появились порты идеи на Python и Go (через Y-комбинатор), но часть людей предпочла бы обычный цикл для отладки.
• Сообщество предупреждает: в нишевых языках придётся уметь докручивать библиотеки «с нуля» и держать редких специалистов.

• Async в Python уже 10 лет, но до сих пор не стал мейнстримом.
• Причины:
  • ошибки «забыл await», трудно отлаживать;
  • GIL приучил не думать о параллелизме;
  • польза только при I/O-задачах, CPU-нагрузка не ускоряется;
  • фреймворки не догнали: Django ORM всё ещё синхронен, Flask тоже.
• Классический кейс — HTTP-запросы: стартуем сотни корутин, ждём ответов, не блокируем интерпретатор.
• Но дисковый I/O, CPU-задачи и другие сценарии не так выигрывают.
• Вывод: чтобы новые фичи 3.14 (free-threading, sub-interpreters) не повторили судьбу async, нужно:
  • чётко объяснять, какие задачи они решают;
  • давать простые API и инструменты отладки;
  • не ждать, пока экосистема «догонит», а сразу внедрять в популярные библиотеки.

• Async в Python пришёл «слишком поздно»: к моменту появления asyncio большинство уже решали задачи I/O через forking, multiprocessing или сторонние библиотеки.
• «Цветные функции» и необходимость переписывать весь код ради async делают его «заразным» и несовместимым с существующими синхронными библиотеками.
• Сложная семантика (event-loop, await, cancellation-исключения), плохая документация и отсутствие понятных best-practice усложняют отладку и поддержку.
• Для большинства задач Python-разработчика async не критичен: WSGI/WSGI-совместимые решения, Celery, Kafka и простое горизонтальное масштабирование покрывают потребности.
• Альтернативы (trio, anyio, gevent) и другие языки (Go, Elixir) предлагают более простые модели конкурентности без «раскрашенных» функций.

moribito
Публичный репозиторий ericschmar/moribito

• Ошибка загрузки – перезагрузите страницу.

• Пользователи рады новому TUI-клиенту для LDAP и благодарят автора.
• Просят добавить поддержку редактирования дерева cn=config и лицензию в репозиторий.
• Уточняют совместимость с Active Directory; автор считает, что должно работать через библиотеку Go.
• Сравнивают проект с громоздким Apache Directory Studio и предлагают выложить его на terminal trove.

• 20+ специалистов из 4 континентов ищут удалённую работу; большинство — full-stack, DevOps, ML/AI и мобильные разработчики.
• Регионы: США (Austin, SF, NYC, Florida), Латинская Америка (Буэнос-Айрес, Богота, Медельин), Европа (Лондон, Осло, Хорватия), Азия (Бангкок, Ханой), Африка (Лагос) и др.
• Ключевые стеки: Rust/Go/Python, React/Node, AWS/GCP, Docker/K8s, LLM/AI-инструменты, iOS/Android, а также редкие — DSP, C++, embedded.
• Готовность к релокации: ~30 % «да», ~60 % «только удалённо», остальные — «возможно при убедительном предложении».
• Уровни: от стажёров и new-grad до 20-летних ветеранов и CTO; многие предоставляют портфолио и рекомендательные письма.

V как Go с шоколадкой
Go — это ваниль: просто, быстро, без фанатизма. V же — «ваниль++»: тот же вкус, но сверху посыпка из фич.

Карты

langs := {"elixir": {"score": 100}}
score := langs["elixir"]["score"] or { -1 }

Фиксированные типы, or {} вместо if err != nil, spread-оператор ... для слияния.

Структуры

struct Language {
pub mut:
    score int = -1
    name  string @[required]
}

Методы можно вешать прямо на массивы, поля можно помечать @[required], дефолты и флаги CLI задаются в одном месте.

WithOption

fn new_server(opts ServerOptions) ! { ... }

Встроенный «функциональный» паттерн: new_server(port: 8080, debug: true).

Enum и лямбды

Enum’ы есть, лямбды короткие: nums.filter(it % 2 == 0).

Подводные камни

• net.http пока не дотягивает до Go.
• veb (веб-фреймворк) сырой.
• Сборка сложнее: нужен v и C-компилятор.
• Параллелизм есть, но экосистема молода.

Итог

V — это Go с синтаксическим сахаром и парой острых углов. Для экспериментов — огонь, для продакшена — пока нет.

• Участники спорят, действительно ли V лучше Go: одни отмечают быструю компиляцию и «красивые» фичи, другие — нестабильность компилятора и отсутствие надёжности.
• Поддерживающие Go указывают на его зрелость, стабильность GC, удобство кросс-компиляции и отказ от «лишнего».
• Сторонники V хвалят синтаксис (const по умолчанию, sum types, простой С-интерфейс), но признают, что язык пока «сырой».
• Некоторые считают V «предупреждением» о том, почему Go часто говорит «нет» новым возможностям.
• Есть мнение, что ни Go, ни V не решают задачу «лёгкого C для приложений»; предлагают смотреть на Zig или Free Pascal.

Гибридный PHP: PHP + Go и Rust

Раньше у нас был монолит на PHP 8.3 («мама») и несколько микросервисов на Go («дети»). Такой стек давал скорость там, где нужно, и скорость разработки везде остальном.

По правилу 80/20 20 % эндпоинтов приносят 80 % нагрузки. Раньше мы выносили их в Go-сервисы, но это усложняло инфраструктуру. Теперь можно оставить логику в монолите и всё равно получить высокую производительность.

Новые инструменты

• FFI – вызов C-кода прямо из PHP.
• Расширения на Rust – безопасный и быстрый код без C.
• FrankenPHP – worker-режим до 4× быстрее; теперь можно писать расширения на Go и вызывать их из PHP.

Зачем не переписать всё на Go или Rust?

• Переписывание дорого и рискованно.
• PHP отлично справляется с 80 % задач, а критичные 20 % можно ускорить расширениями на Rust/Go.

Итог: современный PHP даёт и скорость разработки, и максимальную производительность там, где это критично.

• Участники жалуются, что монолитные фреймворки (Spring, Laravel, Phoenix) быстро дают результат, но превращают legacy-код в кошмар при обновлении зависимостей.
• Обсуждают гибридные схемы «PHP + Rust/Go/C», но предупреждают о росте сложности отладки и найма.
• Некоторые считают современный PHP (≥8.x) недооценённым и упрекают индустрию в стереотипах 5.x-времён.
• Упоминаются альтернативные рантаймы (FrankenPHP, RoadRunner, Workerman) и эксперименты с встраиванием PHP в nginx.
• Пакетный менеджер Composer критикуется как «не тот уровень», ждут «Astral для PHP».

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

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

Простое может выглядеть скучно
Джуны любят рисовать сложные схемы из кэшей, очередей, прокси. Настоящее мастерство — уметь делать меньше. Великий дизайн выглядит тривиально: «О, задача оказалась простой».
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 для простых задач.

Cactoide — мобильная open-source платформа для RSVP и управления мероприятиями.
Альтернатива Meetup.com и Eventbrite для малого бизнеса и небольших групп.

• GitHub: polaroi8d/cactoide
• Лицензия: MIT
• Стек: Go, PostgreSQL, React Native (iOS/Android), Tailwind CSS
• Функции
  • Создание/редактирование событий
  • Подтверждение участия (RSVP)
  • Push-уведомления
  • QR-коды на входе
  • Ограничение по билетам
  • Экспорт списков в CSV
• Установка

  git clone https://github.com/polaroi8d/cactoide.git
  cd cactoide
  docker-compose up
  

• Вклад: присылайте PR и issues.

• Meetup.com критикуют за цену ($180/год) и старый UI, но хвалят за базу участников и дискавери.
• Facebook/WhatsApp/Telegram используют бесплатно, но с плохим поиском и рассылками.
• Punchbowl, Luma, Partiful — удобные, но закрытые и собирают данные.
• Появляются открытые альтернативы: Mobilizon (федеративный), Cactoide (self-host, open-source, без регистрации).
• Основной барьер для новых платформ — отсутствие накопленной базы участников, а не функционал.

• Почему Forth?
  20 лет назад прочёл про язык в книге по embedded, но не вник. В июне 2025-го захотелось просто писать код и наткнулся на статьи Dave Gauera — решил попробовать.

• Два уровня Forth
  User: просто пользуешься языком.
  Hacker: IF…THEN, BEGIN…UNTIL и прочие конструкции — обычные слова, которые можно переопределить; язык описывает сам себя.

• goforth (Go)
  «Чистый» интерпретатор: слово хранит исходный текст, который повторно интерпретируется. Для пользователя работает, но нельзя реализовать IF внутри Forth — всё контролирует Go.

• ctil (C)
  Классическая реализация: связанный словарь, токен-трединг, большая часть на Forth. Позволяет писать:

: variable create 1 cells allot ;

: if   ' 0branch , here 0 , ; immediate
: then here swap - swap ! ; immediate
: else ' branch , here 0 , swap dup here swap - swap ! ; immediate

Итого: два эксперимента, показывающие разницу между «просто работает» и «можно копнуть душу языка».

• Реализация Forth на Go оказалась «не по канонам»: стек и память описаны отдельными структурами, поэтому многие стандартные слова не работают.
• Кто-то показал элегантный вариант на C++ с continuation-passing style и musttail-атрибутом clang.
• Всплыли воспоминания о Forth-диалекте FCode в Open Firmware старых Mac, но выяснилось, что Intel-Mac’и использовали EFI, а не Open Firmware.
• Читатели посетовали на читаемость кода без комментариев о стеке и отметили, что «high-level» реализации могут потерять дух Forth.
• Автор ответил: первая версия на Go была экспериментом, а «правильная» реализация на C хранит код и данные вместе, как положено.

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; участники обсуждают создание форка, который бы следовал спецификации.

fenster — сверхкомпактная кроссплатформенная GUI-библиотека.

• Особенности:

  • Окно, пиксельный буфер, ввод с клавиатуры/мыши.
  • Один .h файл, ~400 LOC, зависимости: X11 (Linux), Cocoa (macOS), Win32 (Windows).
  • Поддержка C/C++, Zig, Odin, Rust, Go, JS (WASM), C#, Swift, Pascal, Nim, Lua, Python, Ruby, OCaml, Fortran.

• Быстрый старт (C):

#define FENSTER_IMPL
#include "fenster.h"
int main() {
  struct fenster f = {.width = 320, .height = 240, .title = "demo"};
  uint32_t buf[320*240];
  for (fenster_open(&f); fenster_loop(&f) == 0; ) {
    // рисуем
    fenster_sync(&f, buf);
  }
  return 0;
}

• Сборка: cc demo.c -o demo (Linux: -lX11, macOS: -framework Cocoa, Windows: без флагов).

• API (C):

  • fenster_open, fenster_close, fenster_loop, fenster_sync.
  • Поля: width, height, title, keys[64], mouse.

• Лицензия: MIT.

• Fenster — это минимальная C-библиотека, создающая окно с пиксельным буфером, а не полноценный GUI с кнопками и меню.
• Участники отмечают отсутствие скриншотов и просят добавить их в README.
• Название «Fenster» переводится как «окно» на немецком, африкаанс, шведском и других языках.
• Некоторые считают polling-цикл ошибкой, другие считают его допустимым для такой простой задачи.
• В блог-посте нашли опечатку в sizeof и ограничение кода 8-битными цветами.
• Проект вызывает интерес для визуализации данных и как лёгкая альтернатива raylib.

sping — терминальный мониторинг задержек HTTP/TCP с живыми графиками. Установка: pip install service-ping-sping.

Быстрый старт

sping google.com                 # HTTP
sping tcp://google.com:80        # TCP
sping https://api.example.com -i 0.5 -c 20
sping example.com --json -c 5

Возможности

• HTTP/HTTPS/TCP, разбивка по фазам (DNS, TLS, запрос, ответ).
• Авто-обнаружение выбросов по MAD (6× медиана).
• Пороги warning/critical, выбор IPv4/IPv6, кэш DNS.
• Процентили p50-p99, экспорт JSON, 8 цветовых тем.
• Bearer/Basic-аутентификация, кастомный User-Agent.

Примеры

sping api.example.com -X POST --body --auth "bearer:token"
sping tcp://localhost:5432 -i 0.1
sping example.com --warn 100 --crit 500 --percentiles

Ключи

-i интервал, -c число запросов, --timeout, --ipv4/--ipv6, --resolve-once, --body, --no-keepalive, --insecure, --warn/--crit, --percentiles, --palette <theme>.

• Пользователи хвалят визуальный ping-утилиту sping, но предлагают переписать её на Go/Rust для статического бинарника без зависимостей.
• Автор подтвердил, что проект полностью сделан с помощью ChatGPT и Claude, а README «украшен» эмодзи.
• Найдены мелкие баги: ошибка палитры цветов и сбой при выводе финального резюме.
• Некоторые сравнивают инструмент с mtr, tracepath и nping --tr, отмечая, что нужен более дружелюбный аналог.

Создал две карточные игры на 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» и перенасыщения рынка посредственными проектами.

Разрабатывая CLI-утилиту, я хотел избежать тормозов при тестах из-за fstat, как это было в Bundler. Решил попробовать in-memory FS, как в Go-библиотеке Afero.

В Rust аналогов нет: спросишь — получишь лекцию «в Rust это не нужно». Нашёл два кандидата:

• vfs — поддерживает swap-бэкендов, но без симлинков и прав, а главное — нельзя создавать исполняемые файлы.
• rsfs — старый, почти заброшенный; требует параметризовать весь код типом rsfs::FS, превращая сигнатуры в кашу.

Провёл бенчмарк: vfs, rsfs, ramdisk и обычный SSD — всё показывает ~45 мс. Современные SSD + кеш ОС настолько быстры, что экономия на syscalls незаметна.

Вывод: тестируй прямо на файловой системе — проще и не медленнее.

• Позикс-семантика сложна, поэтому самописная in-memory реализация почти всегда хуже по качеству, чем готовые tmpfs/ramfs.
• Для быстрых тестов достаточно /tmp (часто tmpfs) или /dev/shm — это дёшево и использует проверенный ядром код.
• SSD и кэши ОС настолько быстры, что даже обычное файловое I/O редко становится узким местом; CPU и syscalls чаще ограничивают.
• Несколько участников пожелали стандартным traits для файловой системы, как в Go (fs.FS, afero), но признают, что в std Rust это уже трудно.
• Основная цель обсуждаемого vfs-крейта — встраивать файлы в бинарь, а не мокать диск; об этом автор плохо сообщил в README.

Как замедлить, чтобы ускорить

Синхронный спрос — когда множество клиентов действуют одновременно.
Пропускная способность μ, фоновая нагрузка λ₀, запас H = μ − λ₀.
M клиентов, синхронизированных по крону, кэшу или перезапуску, превышают H, образуют очереди, таймауты, ретраи и инцидент.
Цель — размазать пик или безопасно его слить, сохраняя справедливость и лимиты.

Источники выравнивания:

• естественные — часы, TTL, SDK-таймеры;
• индуцированные — деплой, рестарт, сброс кэша, обновление токенов;
• внешние — DDoS, флеш-крауд.

Ограничения:

• мягкие — задержка в очереди;
• жёсткие — пулы соединений, дескрипторы, потоки.
  Превышение даёт обрыв: ещё одно соединение → таймаут → ретраи → ещё больше нагрузки.
  Важно, кто ждёт: онлайн-запросы требуют справедливости, офлайн — только пропускной способности.

Математика размагничивания
M действий равномерно в окне [0, W]:
ожидаемый пик M/W, средняя задержка W/2, произведение M/2 — константа.
Чем шире W, тем ниже пик, но выше средняя задержка.

Для выпуклой функции стоимости C(r) равномерное r(t)=M/W минимизирует ∫C(r)dt (неравенство Йенсена).
Равномерный джиттер оптимален и справедлив.

Практика

1. Детерминированные границы:

   • M/W ≤ H ⇒ W ≥ M/H;
   • (M/W)·s ≤ K ⇒ W ≥ Ms/K (s — p95 времени обработки, K — свободная конкурентность).

2. Вероятностные границы:
   Пусть N ~ Poisson(M/W). Требуем Pr{N > H} ≤ ε.
   Для H ≳ 50 нормальное приближение даёт
   λε ≈ ((-z₁₋ε + √(z₁₋ε² + 4(H+0.5)))/2)²,
   W ≥ M/λε.
   Для малых H или ε считать точный хвост Пуассона.

3. Подсказки от сервера:

   • Retry-After: Δ → джиттер в [Δ, Δ+W];
   • rate-limit: R оставшихся запросов до сброса через Δ → λadm = min(H, R/Δ) → W ≥ M/λadm.

4. Продуктовые ограничения:

   • дедлайн D ⇒ W ≤ D;
   • p95 добавленной задержки ≤ L ⇒ W ≤ L/0.95.

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

• Участники обсуждают парадоксы, при которых «ускорение» ведёт к замедлению: парадокс Браесса, парадокс Джевонса.
• Подчёркивается мысль «slow is smooth, and smooth is fast»: медленные, точные действия итогом быстрее и эффективнее, будь то код, строительство или музыка.
• Пример Facebook: задержки и очереди используются как ресурс — задачи выполняются ближе к максимально допустимому времени отклика, повышая общую пропускную способность.
• Упоминаются практические техники регулировки скорости: nanosleep по объёму данных, параметризуемые «тормоза» в долгих процессах.
• Итог: оптимизация — это не просто «делать быстрее», а баланс скорости, точности и использования ограниченных ресурсов.

Go всё ещё плох

Кратко: автор 10+ лет критикует Go за архитектурные ошибки, которые легко было избежать.

1. Ошибки: неверная область видимости

bar, err := foo()
if err != nil { … }
if err = foo2(); err != nil { … }
// err висит до конца функции, хотя нужен только в двух строках

Читателю приходится тратить время, выясняя, где err ещё используется.

2. Два вида nil

var i interface{}
var s *S
fmt.Println(s == nil, i == nil, s == i) // true, true, false
i = s
fmt.Println(s == nil, i == nil, s == i) // true, false, true

Один «billion-dollar mistake» не хватило — сделали два.

3. Непереносимость

Условная компиляция через комментарии в начале файла — «аристотелевский» подход: теория без практики. Реальные проекты страдают.

4. append без чёткого владения

a := []string{"hello", "world", "!"}
foo(a[:1]) // внутри append
fmt.Println(a) // результат зависит от капасити слайса

Поведение неочевидно и требует знания внутренностей.

5. defer вместо RAII

В Java и Python ресурс закрывается автоматически при выходе из блока.
В Go приходится вручную писать defer foo.Close() и гадать, какие ресурсы вообще требуют закрытия.

• Go хвалят за простоту, быструю компиляцию, встроенные инструменты и удобную конкурентность.
• Критикуют «двойной nil», слабую систему типов, проблемы GC, неинтуитивный defer и скудные абстракции.
• Многие считают его «достаточно хорошим» для бэкендов и CLI-утилит, особенно при скорости разработки.
• Крупные проекты жалуются на «смерть тысячей порезов» и трудности отладки из-за строгости компилятора.
• Часть сообщества видит в Go компромисс между Node/Python и Rust, другие — устаревший язык без современных фич.

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 не решает проблему окончательно, но добавляет достаточно трения, чтобы заставить владельцев краулеров пересмотреть объёмы сканирования.

Reality Defender API
Два вызова кода — и ваша система получает признанные наградами модели для обнаружения дипфейков. Бесплатный тариф: 50 проверок аудио/изображений в месяц.

Почему Reality Defender API

• Простота — загрузка файла и получение результата.
• Гибкость — SDK на Python, TypeScript, Java, Go, Rust.
• Прозрачность — исходники открыты.
• Доступность — 50 сканов/мес без карты.

Тарифы

План	Цена	Включено
Free	$0	50 сканов/мес, аудио+изображение, 1 пользователь
Growth	от $399/мес	50+ сканов, аудио+изображение+видео, чат
Enterprise	по запросу	неограниченный объём, мультисид, видео+текст, стриминг, интеграции Zoom/Teams/Webex, расширение Chrome, персональная поддержка

Где применять

• Верификация личности (KYC, безопасный доступ)
• Мошенничество (имперсонация, соц-инженерия)
• Модерация контента
• Анализ СМИ и факт-чекинг
• Исследования и тесты

Поддерживаемые форматы

Аудио (до 100 МБ, 12 с – 5 мин): wav, flac, mp3, m4a, aac, ogg, opus; 8 языков.
Изображения (до 10 МБ): jpg, jpeg, png, gif, webp.
Видео (до 250 МБ): mp4, mov; аудио как выше.

Начать бесплатно | Документация SDK

• Участники сомневаются в надёжности «детекторов ИИ» и предсказывают бесконечную «кошку-мышь» между генераторами и детекторами.
• Предлагают альтернативу: криптографическую подпись контента, но признают, что добровольные стандарты легко обходятся.
• Основатели Reality Defender отвечают: ансамбль моделей выдаёт лишь вероятность 1-99 %, API закрыт, таргетинг по паттернам и лимит 50 бесплатных сканов мешают злоупотреблениям.
• Уже используется крупными банками и корпорациями для проверки подлинности медиа и документов.

Почему в 2025 году мы всё ещё пишем на Ruby

Стартуя с Lago, мы выбрали Ruby on Rails — у команды был десятилетний опыт, и это был самый быстрый путь к рабочему API. Сегодня система обрабатывает миллионы вызовов в день, пережила множество обновлений Ruby/Rails, и, если бы начинали заново, выбор остался бы тем же.

Скорость как главное преимущество
Rails больше не «тренд» для стартапов, но его используют Shopify, GitHub, GitLab — зрелые компании, которым важна надёжность и скорость разработки. Мы взяли Rails в API-only режиме: без лишнего middleware и рендеринга, но с миграциями, валидациями, Active Record и фоновыми задачами. Это позволило тратить время на продукт, а не на костыли.

Масштабируемость
Rails не масштабируется? Это проблема архитектуры, а не фреймворка.

• Rails 8 упрощает деплой без PaaS.
• Redis + Sidekiq проверен временем.
• Ruby Fibers добавляют асинхронность.
• Puma, автомасштабирование и кеширование справляются с нагрузкой.

Недостатки, с которыми живём

• Производительность и память: ошибки дорого обходятся.
• GIL CRuby: один поток Ruby-кода за раз, поэтому тяжёлые задачи уходят в Go/Rust.
• «Магия» Rails: избегаем лишних гемов и пишем максимально явный код.

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

• Участники жалуются на рутину вокруг JS/TS-стека: тройное дублирование типов, самописная интеграция auth и прочие «reinventing wheels».
• Многие называют Rails «скучным, но рабочим» инструментом, который до сих пор быстро даёт полный вертикал функционала без бойлерплейта.
• Популярность Rails страдает из-за ассоциаций с «устаревшей» эпохой 10-летней давности и отсутствия хайпа, хотя кодовая база активно развивается (YJIT, ZJIT).
• На практике Rails используется для бизнес-логики и API, а Go/Rust — для I/O- или CPU-ёмких задач; Shopify и GitHub живут по такой же схеме.
• Некоторые мечтают о «Rails на другом языке» (Clojure, Gleam) или ждут, что AI сделает быстрые языки такими же удобными, как Ruby.

Mangle — проект Google на GitHub.
Язык: Go.
Лицензия: Apache-2.0.

Описание
Mangle — это компилятор/интерпретатор логического языка, ориентированного на:

• анализ и трансформацию графов;
• декларативные запросы к данным;
• поддержку Datalog-подобного синтаксиса.

Ключевые особенности

• Компилирует логические правила в Go-код или исполняет напрямую.
• Поддерживает рекурсивные запросы и агрегации.
• Работает с in-memory и persistent-хранилищами.

Установка

go install github.com/google/mangle/cmd/mangle@latest

Быстрый старт

1. Создай файл example.mgl:

   edge("a", "b").
   edge("b", "c").
   path(X, Y) :- edge(X, Y).
   path(X, Z) :- edge(X, Y), path(Y, Z).
   

2. Запусти:

   mangle example.mgl --query="path(\"a\", Z)"
   

Документация

• Wiki
• Примеры

• Участники спорят, связан ли новый язык Google с «Deductive Database» из видео 3b1b: одни считают, что это очередной внутренний эксперимент, другие — просто «люди, которые веселятся под крылом Google».
• Поднимается вопрос, почему почти все инструменты расширяют «ванильный» Datalog: его ограничения делают расширения неизбежными.
• В треде упоминаются альтернативные языки запросов — PreQL/Trilogy, Malloy, PRQL, PathQuery — и обсуждается, как они соотносятся с SQL и реляционной алгеброй.

Иллюзия мастерства

Claude выдал прекрасные Go-тесты — и бесполезные: все сводились к true == true.
ИИ дарит облик мастерства без труда. Код выглядит правильно, поэтому легко пролистать детали.

Я не ленюсь, просто использую инструмент. Claude пишет Go, SQL, Svelte, знает сигнатуры API — кажется, что boilerplate решён. Но когда я отлаживал фронтенд, понадобилось 40 минут чтения документации, чтобы заметить, что он смешал синтаксис Svelte 4 и 5. Я проглядел, пока не проследил вручную.

ИИ продвинул меня, но не избавил от работы. Настоящее мастерство — это модель в голове и собственное мышление. Убедительный синтаксис ≠ понимание.

Ловушка

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

Это как фитнес: пропустил день — легко вернуться, пропустил недели — «и так сойдёт». Инструмент хорош, но привычка тускнеет.
Когда целые команды перестают напрягаться, код превращается в пятна Роршаха: знакомые формы без модели. Это организационный распад.

Сначала ИИ облегчает работу, но уже через пару дней видно: он не несёт когнитивную нагрузку. Финальный рывок остаётся за нами, а поднять «положенное» бремя тяжело.

Требуется усилие

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

• Опытные разработчики подчеркивают: без контроля и понимания архитектуры AI-помощь превращается в «красивый, но бесполезный» код.
• Многие замечают, что младшие коллеги перестают думать, слепо принимая сгенерированные тесты и решения.
• AI хорош для рутины, но требует «copilot», а не «main pilot»: человек должен оставаться капитаном.
• Сравнение с IKEA-шкафами: большинство проектов станут «фабричными», но сложные и критичные системы всё равно останутся ручной работой.
• Итог: навыки критического мышения и рефакторинга «AI-слякоти» станут новой ценностью.

• Участники жалеют, что выразительные языки с нативной компиляцией и автоматическим управлением памятью (Nim, D) не стали массовыми.
• Любители Nim хвалят его скорость, надёжность компилятора и эргономику, но жалуются на малую экосистему, устаревшую документацию и сложность кросс-компиляции.
• Скептики считают, что «выразительность» и макросы делают язык нишевым, требуют больше знаний и усложняют чтение чужого кода.
• Многие отметили, что успех языка определяют не фичи, а деньги, стандартная библиотека, тулинг и сообщество; Rust выиграл именно этим.
• Часть разработчиков ушла из Nim в Rust, Go или Zig из-за зрелости инструментов и богатой экосистемы, но продолжают следить за Nim и надеются на его рост.

• 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 начинает нравиться.

• Выбор хранилища метаданных рабочих процессов оказался ключевым. Нужно было простое: чекпойнт состояния и восстановление после сбоя. Postgres выбрали за технические возможности, а не только за популярность и 40-летнюю проверку временем.

• Масштабируемые очереди
  Классическая таблица-очередь страдает от конкуренции: все воркеры пытаются взять одни и те же задачи. Postgres решает это через FOR UPDATE SKIP LOCKED: строки блокируются и пропускаются, если уже захвачены. Воркеры без конфликтов берут следующие N записей, позволяя обрабатывать десятки тысяч задач в секунду.

• Наблюдаемость
  Каждый шаг сохраняется, поэтому можно строить дашборды и фильтры. SQL позволяет писать сложные запросы напрямую; индексы по created_at, executor_id, status ускоряют выборки из миллионов записей без лишних затрат.

• Exactly-once для шагов с БД
  Обычно гарантируется «по крайней мере один раз», но если шаг меняет данные в той же транзакции, что и чекпойнт, Postgres обеспечит, что изменения зафиксируются ровно один раз даже после перезапуска.

• Пользователи хвалят DBOS за простоту миграции с graphile-worker и отсутствие необходимости менять инфраструктуру.
• Сравнения с Temporal, Azure Durable Functions, Inngest, Restate и Cloudflare: DBOS выглядит проще и легче, но Temporal/Cloudflare критикуют за сложность самостоятельного хостинга и высокую цену.
• Некоторые жалуются, что «сервер» DBOS (Conductor) не open-source, что ограничивает самостоятельное развёртывание.
• Планы по добавлению Java, C#, Go и поддержке сообщества уже анонсированы; Python и TypeScript уже поддерживаются.
• Отмечена возможность комбинировать DBOS с Dagster/Oban/pgflow для более сложной оркестрации.

Представьте, вы пишете проект и вам нужна библиотека — назовем ее 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-подходы и периодические обновления с тестами/реновейтом.
• Отдельная ветка критикует дизайн сайта с анимированными иконками, мешающими чтению.