Eric Selin создал statichost.eu — полностью европейский хостинг для статических сайтов, где каждый элемент стека, от деплоя через Git до CDN, работает на инфраструктуре, принадлежащей европейским компаниям. Он отказался от использования американских сервисов вроде AWS и Cloudflare, считая, что доверие данным и контроль над инфраструктурой должны оставаться в Европе. Проект возник из разочарования в «европейских» хостингах, которые фактически полагаются на американские облака.

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

Обсуждение подтверждает, что Statichost.eu закрывает потребность в европейском хостинге, но вызывает критику из-за высоких цен, непрозрачных тарифов и технических ограничений, несмотря на положительный опыт с бесплатным планом и поддержкой. **Критика цен и модели** - @gbxbxbcbd: 120 EUR/год за безлимитные сайты и дорогой трафик невыгодны — аналогичный VPS на Scaleway стоит 5 EUR с безлимитным трафиком. - @FabCH, @sparkling: 9 EUR/мес за статический хостинг — слишком дорого; за ту же цену можно взять VPS с безлимитным трафиком в Европе. - @dlahoda иронично перечисляет «европейские ценности» как бюрократические барьеры (налоги, карта, резиденция, цензура), намекая на политическую избыточность. **Прозрачность и доверие** - @jonplackett: плохой дизайн сайта (неадаптивное меню, несогласованное оформление) подрывает доверие. - @reconnecting: страница статуса отправляет данные в Google и DoubleClick, что противоречит заявлению об отсутствии сбора персональных данных. - @sajithdilshan, @palata: в документации нет информации об объёме хранилища и автоматической генерации TLS-сертификатов. - В то же время @g-b-r и @exitnode хвалят краткие и понятные условия использования. **Технические ограничения** - @chrisjj, @mtlynch: отсутствие rsync-подобной синхронизации и обязательная сборка (build minutes) — неоправданные ограничения для статических сайтов. - @archonis: нет аутентификации по SSH-ключу, что снижает безопасность и удобство. **Положительный опыт и предложения** - @exitnode, @thih9: сервис работает стабильно, быстро и бесплатно — хороший вариант для небольших сайтов без сложных сборок. - @jeremyjh предлагает интегрировать Statichost.eu с Codefloe (европейский Git-форж) для решения проблемы с управлением версиями. - @throwfaraway135 выражает недоверие к EU-юрисдикции, допуская цензуру, что ставит под сомнение «европейские ценности» как гарантию свободы.

OpenAI Codex (переименованный в ChatGPT Desktop) хранит в ~/.cache/codex-runtimes/codex-primary-runtime 1,7 ГБ данных, включая полные установки Python и Node.js, а также нативные бинарники Poppler, git и LibreOffice. Последний занимает 429,7 МБ в виде libreoffice-headless, что позволяет приложению обрабатывать документы без графического интерфейса. Эти компоненты находятся в подпапке dependencies, а их использование настраивается через навыки (skills) в plugins/documents, где указано, как вызывать нужные бинарники для работы с файлами. Такой подход делает Codex самодостаточным инструментом для работы с кодом и документами, избавляя пользователя от необходимости отдельно устанавливать зависимости. Включение LibreOffice указывает на фокус на обработке офисных форматов (DOCX, ODT и т.п.) напрямую из кэша приложения. Всё это подтверждает стратегию глубокой интеграции системных инструментов внутрь desktop-клиента для расширения его возможностей за чистый LLM-интерфейс.

LibreOffice включён в ChatGPT Desktop для надёжной обработки устаревших форматов (DOCX, XLSX) в headless-режиме — по опыту @esperent, альтернативы такой надёжности не дают. Размер зависимостей (1.7 ГБ) воспринимается как избыточный bloat (@cpursley, @pseudosavant); @quotemstr предлагал загрузку по требованию, но @esperent полагается на гарантированную доступность. @jav-8448 и @gfalcao указывают на отсутствие упоминания лицензий в приложении, что ставит под вопрос соблюдение MPL 2.0; @pocksuppet считает, что явного требования к этому нет. Среди предложений: переписать LibreOffice на Rust (@devy), использовать Vespper.com для редактирования DOCX (@topaztee). Приложение не проверяет системные бинарники (@mirzap), не предоставляет доступ к транскрипции аудио (@Lucasoato), лишено глобального горячего ключа (@RestartKernel) и нагружает CPU на Windows (@robomartin). Включение связано с ChatGPT Work — продуктом для генерации и редактирования документов (@zitterbewegung, @wilg).

AI-сканеры создают постоянную нагрузку на git.kernel.org, потребляя около 20% вычислительных ресурсов — 14–16 из 90 ядер на пяти узлах постоянно тратятся на рендеринг коммитов в HTML для обучения моделей, что превышает нагрузку от всех легитимных запросов, включая git clone. Причина — неэффективный метод сбора данных: вместо простого клонирования репозиториев сканеры запрашивают каждый коммит как отдельную HTML-страницу, генерируя миллиарды дублирующих URL из-за форков и параметров вроде diff и patch, что создаёт «фоновое излучение» нагрузки. Хотя сайт остаётся отзывчивым для людей, основные сбои вызывают не сканеры, а плохо спроектированные CI-системы с поверхностными клонами. Администраторы пытаются бороться блокировкой IP и подсетей, но боты маскируются под браузеры и распределяются по облакам. В долгосрочной перспективе планируется ограничить функциональность и сократить количество сканируемых URL, хотя это ухудшит доступ для анонимных пользователей. Все данные останутся доступны для загрузки, но с дополнительными барьерами. Проблема системная: пока спрос на обучающие данные для LLM растёт, а простых решений нет.

Обсуждение дополняет статью: проблема не в технической неэффективности, а в системном провале этики веб-скрапинга. AI-скраперы игнорируют robots.txt и rate limiting, а защита через proof-of-work вредит легитимным пользователям, не останавливая продвинутых ботов. Советы по противодействию: - Замена Anubis на кастомную хеш-функцию без публикации обходит ASIC-скраперы, заточенные под стандартную реализацию. - Отказ от публичного HTML-интерфейса в пользу git clone для всех и веб-интерфейса только для авторизованных пользователей. - Лимит неавторизованных запросов — 5 в минуту с разрешением высокой частоты для авторизованных. - Рендеринг HTML на клиенте через JS-клиент, который клонирует репозиторий в браузере и кэширует данные. - Ловушки (бесконечные пути, медленная передача изображений, генерация абсурдного контента) заставляют ботов тратить ресурсы впустую. - Whitelist по IP/ASN вместо blacklist с общим списком между сайтами (риск: рынок поддельных доверенных узлов). - Повышение стоимости доступа к старым коммитам относительно новых — легитимные пользователи редко запрашивают древние данные. - Превращение proof-of-work в добровольный майнинг криптовалюты, где боты «платят» хостингом. - Временное повышение сложности Anubis при запросах к нестандартным URL с подсказкой посетить главную страницу. - Кэширование HTML-рендеров git-репозиториев, так как коммиты редко меняются. - Блокировка cgit-эндпоинтов (diffs, blame, snapshots) и возврат 402 за доступ — признание поражения, но единственный рабочий способ остановить ботов без отключения сервиса. Споры: - Anubis неэффективен: скраперы обходят его через куки, а мобильные пользователи страдают от высокой сложности. - AI-скраперы тратят ресурсы на обучение, но это не оправдание — они могли бы клонировать репозитории, а не запрашивать каждый коммит в HTML. Консенсус: - Современные AI-скраперы игнорируют robots.txt, rate limiting и другие устоявшиеся практики, делая традиционные методы защиты бесполезными. - Рост нагрузки от ботов не связан с качеством контента: скраперы сканируют всё подряд без фильтрации, создавая комбинаторный взрыв URL.

Авторы ежедневно собирают и анализируют лексику из GitHub Pull Requests, чтобы выявить устойчивые паттерны в языке разработчиков. За 595 дней обработано более 461 тыс. PR и 51 млн слов, которые с помощью KL-дивергенции и k-means разбиты на 10 кластеров лексики. Один из кластеров, появившийся в 2026 году, доминирует в 40% всех PR, приписанных людям, за последний месяц, и его характерные слова напрямую связаны с использованием coding-агентов, таких как Claude Code.

Среди самых репрезентативных терминов этого кластера — load-bearing, refusal, survives, byte-identical, mutation-tested, structurally indistinguishable и другие, отражающие акцент на формальной верификации, неизменяемости и доказательной корректности кода. Эти слова указывают на сдвиг в практике разработки: всё больше PR фокусируются не на функциональности, а на гарантиях, которые код предоставляет — например, что изменение не ломает поведение, сохраняет битовую идентичность или выдерживает формальную проверку. Такой словарь стал «несущей конструкцией» современного кода, написанного с помощью ИИ-ассистентов.

Тред подтверждает наблюдаемость «клоудизмов» в проде и расширяет картину за пределы лексики: отмечаются синтаксические и форматные паттерны, проникновение в человеческую речь, гипотеза о компаундинг-эффекте при обучении новых моделей на AI-контенте, и практические попытки подавлять стиль через системные промпты. Отдельные респонденты считают часть слов обычным техжаргоном и оспаривают тезис о чисто LLM-происхождении слов типа load-bearing.

• Многие подтверждают из опыта, что «load-bearing», «spike», «sidecar», «resolver», «crux», «first-class citizen» массово появились в их кодовой базе и PR вместе с распространением Claude; @legobmw99 отмечает, что «sidecar» по их поиску стал использоваться в 3.6x чаще.

• LLM-лексика перетекает в человеческую речь: @nater5000 и @MrDrDr признаются, что стали непроизвольно использовать LLM-конструкции в своей письменной речи.

• Проблема выходит за лексику — синтаксис и формат тоже сигналят: @stabbles указывает на оборот «X contains no Y», @iamacyborg — на тирады с «, and», «, because», @elias_junit — на подчёркнуто линейную, хорошо структурированную подачу вместо нелинейного нарратива.

• Спор: Часть участников (@sethd, @danpalmer, @sosull) считает, что «Claude-измы» — это обычный техжаргон или следствие того, что модель буквально опирается на эти слова как на носители концептов (без них хуже думает), а @SalariedSlave и @polycaster, наоборот, видят именно LLM-специфичное явление и подозревают компаундинг-загрязнение обучающих данных.

• Совет: @ben30 показывает работающий приём: в глобальный промпт добавлено правило Орвелла и явный запрет на «load-bearing», «the crux», «first-class citizen»; в ответ Claude сам сообщает, что его системные инструкции требуют помечать «что-то load-bearing», то есть ограничение реально режет инструкции модели.

• Совет: @jimbobimbo использует в инструкциях агентов «find a synonym to 'resolve'», иначе появляется класс Resolver с методами ResolveThis/ResolveThat; @prmph заводит список запрещённых слов и просит переписать текст понятнее.

• Переломным по ощущениям @datadrivenangel называет примерно апрель (Opus 4.6/4.7), после чего Claude стал казаться «другим и более неудобным». @whywhywhywhy удивлён отсутствию в топе слова «shape».

• Подача проекта высоко оценена UX-составляющая: @nater5000 и @sosull хвалят, что всё помещается на экран без лишней воды, @Labo333 (автор) отвечает, что бэкенда нет — обновление и анализ делаются через GitHub Actions; обещает увеличить выборку до 1000 PR/день и поисковую строку.

Orwell's first rule: never use a metaphor you're used to seeing in print. "Load-bearing", "the crux", "first-class citizen" signal insight instead of showing it. Name the specific mechanism — @ben30

GitHub столкнулся с перебоями в работе некоторых сервисов, включая проблемы с доступом к репозиториями, пуш-операциями и вебхуками. Инцидент был зафиксирован в статусе «Resolved» после устранения неполадок, связанных с внутренними компонентами платформы. Пользователи сообщали о задержках и ошибках при выполнении Git-операций и взаимодействии с API, что указывало на сбой в инфраструктуре, отвечающей за обработку запросов.

Компания подтвердила, что инцидент был полностью устранён, и обещала опубликовать детальный анализ причин в ближайшее время. Для предотвращения повторения таких ситуаций GitHub рекомендует подписаться на уведомления через статуc-страницу, чтобы получать оперативную информацию о будущих инцидентах по email, SMS, Slack или вебхукам. Восстановление сервисов произошло без потери данных, и платформа вернулась к нормальной работе.

Тред дополняет статью двумя вещами: статистически фиксирует нисходящий тренд аптайма GitHub в августе (@mrshu) и превращает одиночный инцидент в паттерн «нормализации сбоев», при котором реальные пользователи (@xbryanx, @Traubenfuchs) уже мигрируют на Forgejo/самохост, а критика архитектуры (@everfrustrated, @lossolo) указывает на отсутствие шардинга и привязку к upstream-Vitess как на структурные, а не разовые причины.

• Несколько комментаторов (@tomw1808, @theanonymousone, @jp_sc, @CerebralCoding) сходятся: регулярные сбои GitHub уже нормализовались, и шутки формата «должно быть, день на Y / среда» отражают усталость, а не удивление.

• @nr378, @Traubenfuchs и @xbryanx сходятся в требовании разделить инфраструктуру платных и бесплатных пользователей на уровне архитектуры, а не только тарифа.

• Спор: @tomw1808 считает «просто смирились — это ненормально для критического сервиса и заслуживает кредитов», тогда как @rglover добавляет, что проблема в раздутии сложности и призываeт к выделению GitHub из Microsoft обратно в независимую компанию — спор о том, лекарство это регуляция SLA или деконсолидация.

• Спор: @guhcampos предлагает ту же модель «решить через rate limit на бесплатных аккаунтах», а @rglover и @inigyou противопоставляют: проблема не в нагрузке free-tier, а в спагетти-архитектуре; @everfrustrated усиливает — single primary без шардинга аматорство для такого масштаба.

• Совет: @xbryanx делится опытом: во время прошлого сбоя развернул Forgejo с кастомными action runners и сегодня завершает миграцию — практическая точка перехода для команд с GitHub Actions.

• Совет: @guhcampos предлагает как быстрое лекарство: rate limit на git-команды для free-аккаунтов, считая, что никому не нужны множественные push в минуту, и это снизит нагрузку на downstream-триггеры.

• Совет: @stalfosknight и @thatwasunusual формулируют запрос на обзор альтернатив по состоянию на август 2026; @rvz даёт ссылки на обсуждения двух предыдущих инцидентов с Actions за 5 дней и на постмортем, превращающий сбой в рекуррентный сигнал.

• @mrshu публикует график: исторический аптайм улучшался, но в августе идёт нисходящий тренд — количественное подтверждение ощущения «сбоев стало больше».

• @everfrustrated, @lossolo и @mportela критикуют архитектуру: один primary для БД без шардинга, отсутствие хоризонтального масштабирования для Git и Actions, упавший до «одной девятки» аптайм — противопоставляют это четырём-пяти девяткам, к которым стремились раньше.

• Совет: @Elfener документирует неочевидный side-effect: «github-merge-queue Bot removed this pull request from the merge queue due to no response for status checks» — конкретный артефакт сбоя в merge queue, полезный для диагностики у себя.

• Совет: @zackify и @Traubenfuchs указывают, что self-hosted runners не спасают, потому что падает и core-инфраструктура Actions, а не только managed runners — сужает пространство «страховок».

• @sandermvanvliet публикует расширение gh-omens, проверяющее статус GitHub перед использованием, и @frenchie4111 отмечает, что браузер уже автоподставляет githubstatus.com по «gith» — индикатор, что статус GitHub читают как погоду.

This is why it's hard to take GitHub seriously. How can a single database cause an outage for everyone? This is amateur stuff. Have they no sharding or partitioning internally? Paying customers should not be impacted in the same way as free ones are. — @everfrustrated

Графенос OS — это специализированный сервер Mastodon, предназначенный для официальных аккаунтов проекта и его разработчиков. На нём нет привычных поисковых функций и статистики; сервер обслуживает лишь небольшое сообщество из четырёх активных пользователей.

Ключевой факт: Google заменил выдачу Git‑тегов для некоторых репозиториев на загрузку исходников через Google Drive, сделав процесс крайне затягивающим и неудобным. Это нарушает GPLv2, которая требует предоставления исходного кода по «обычному для программного обеспечения» каналу в разумные сроки, а не через архаичную систему с длительными задержками.

Главное запомнить: использование Google Drive вместо Git‑тегов — явное нарушение лицензии и пример того, как крупные корпорации усложняют доступ к открытым исходным кодам.

Google намеренно усложнил доступ к исходному коду Pixel-устройств, отказавшись от публикации Git-тегов в AOSP и перейдя на ручной запрос через Google Drive. Это нарушает дух GPLv2 — формально код предоставляется, но автоматизация, CI/CD и своевременное исправление уязвимостей становятся невозможными. Регулярные релизы для Pixel прекратились, вынудив GrapheneOS искать альтернативы, включая партнёрство с Motorola. Адаптация к новой системе заняла недели, подтверждая системный, а не случайный характер изменений. Доступ через Google Drive требует ручного взаимодействия, в отличие от прямых ссылок у других проектов, что делает его непрактичным и противоречащим сути лицензии. Некоторые оправдывают это бюрократией или лицензионными ограничениями, но другие видят в этом целенаправленную стратегию по закрытию экосистемы — включая планы по блокировке sideloading. Сравнение с Microsoft, отправляющей код за $5 по почте, показывает, что Google создаёт более высокие барьеры. Потеря доверия со стороны сообщества подтверждается переходом GrapheneOS к другим производителям. Отказ от публикации тегов позволяет только Google воспроизводить точные сборки, снижая прозрачность. Google, будучи одной из крупнейших ИИ-компаний, противоречиво сочетает инвестирование в технологии с уничтожением открытости Android, копируя модель Apple. Отсутствие доступа к исходному коду ставит под угрозу безопасность пользователей. Некоторые считают, что Red Hat нарушает GPLv2 серьёзнее, но это не оправдывает действия Google. Пользователям и разработчикам следует поддерживать альтернативы и требовать отказа от Google-ограниченных драйверов — иначе свободная экосистема Android умрёт.

Код теперь можно размещать напрямую в Cursor через новую функцию Origin — early‑beta‑режим для платных пользователей. В появившемся Codebase‑разделе можно создать репозиторий, задать ему название (URL будет выглядеть как cursor.com/codebase/название), установить CLI и начать пушить локальный проект. Синхронизация с GitHub позволяет держать репозитории как на GitHub, так и в Origin, при этом выбирая, какие из них синхронизировать, и отключать их в любой момент.

Pull‑requests работают в обе стороны: комментарии и реакции в Cursor мгновенно отражаются в GitHub и обратно. В каждом репозитории доступны встроенные агенты, которые могут отвечать на вопросы о коде, менять PR‑ы и пушить ветки. Интеграции с Vercel, Depot и Buildkite уже готовы: через Apps‑таб можно привязать Vercel для preview‑деплоя каждого PR, а Depot и Buildkite — для запуска CI‑pipeline, включая GitHub Actions. Настройки репозитория позволяют проверять статус синхронизации, управлять доступом и подключать приложения.

Запомните: название репозитория становится частью URL, а синхронизация происходит в реальном времени, сохраняя GitHub как источник истины. Сейчас Origin доступен в early‑beta для всех платных планов, кроме компаний, которые явно отключили его. Начать работу можно сразу в интерфейсе Cursor.

Пользователи отвергают Origin как GitHub-альтернативу из-за связи с Илоном Маском и опасений, что код будет использоваться для обучения Grok. Предпочтение отдается децентрализованным решениям (Radicle, Forgejo, SourceHut, Codeberg, Tangled) или self-hosted Git — как более безопасным для приватности. Origin ограничен синхронизацией с GitHub и не предлагает инноваций в агентных рабочих процессах, что вызывает критику как «GitHub clone». Технические недостатки — высокий расход CPU и требование SMS-верификации — снижают доверие. Споры идут о природе рисков: одни считают проблему в росте кода из-за AI, другие — в принудительном сборе данных Cursor для обучения моделей. Эксперты полагают, что Cursor ориентирован не на хостинг, а на сбор истории версий и патчей для AI.

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

Создавать и управлять стеками можно через GitHub CLI или веб-интерфейс: команда gh extension install github/gh-stack позволяет начать за минуту. Все проверки, защиты веток и требования к слиянию работают без изменений. Можно слить весь стек одним кликом или частично — нижние уровни автоматически переадресуются на верхние. Разработчики из Vercel и WHOOP отмечают, что стеки сделали процесс ревью прозрачным, а слияние — быстрым и безопасным. Поддержка очередей слияний будет внедрена в ближайшие недели.

Тред обсуждает новую функцию GitHub — стековые пул-реквесты: некоторые пользователи считают её полезной для крупных и сложных проектов с множеством зависимостей, так как она упрощает проверку и слияние изменений. Другие выражают сомнения, указывая на риски длинных веток и необходимость повторного утверждения. Эксперты рекомендуют применять функцию в сочетании с другими инструментами, например jj, для оптимального результата.

Decker — это платформа для создания интерактивных мультимедийных документов, вдохновлённая HyperCard и визуальной эстетикой классического macOS. Она сочетает простоту и доступность старых инструментов с современными удобствами: глубокой историей отмен, поддержкой сенсорных экранов, масштабируемыми операциями и полноценным скриптованием. Пользователи могут создавать электронные журналы, презентации, текстовые приключения, пиксель-арт или просто экспериментировать — всё сохраняется в самодостаточных HTML-файлах, которые работают в браузере и совместимы с Git. Деки — это не просто документы, а наборы переиспользуемых компонентов, которые легко копировать и адаптировать.

Для сложной логики используется язык Lil — лёгкий, похожий на Lua и Q, с неожиданными удобствами: неявной арифметикой векторов, встроенным SQL-подобным запросом и минимальной кривой обучения. Lil работает и вне Decker через Lilt — автономный интерпретатор, который можно скомпилировать в один исполняемый файл и запустить даже в AWK. Все файлы хранятся в текстовом формате, что делает их идеальными для версионного контроля. Decker лишён рекламы, телеметрии и навязчивых функций — он создан для творчества, а не для монетизации. Среди примеров — Sokoban, Breakout, CHIP-8-интерпретатор и библиотеки для анимации, звука, графиков и визуальных новелл. Платформа открыта под MIT-лицензией, с активным сообществом и ежегодными джемами.

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

Колонка — это пустая команда, которая ничего не выводит, но позволяет применять расширенный синтаксис параметрического расширения ${name:?msg}. Вместо четырёх строк проверки обязательных параметров её можно заменить на : "${1:?missing argument, aborting.}", а для переменных задавать значения по умолчанию через : "${DATA_DIR:=/var/data}". Она также служит для обнуления файлов — : > error.log, а комбинация : > error.log > access.log одновременно очищает несколько файлов. Благодаря этому скрипты становятся короче и читабельнее, а диагностическое сообщение содержит имя переменной.

Помимо проверок, : используется как placeholder, где синтаксис требует команду, но действие не нужно. Например, ( : < dataset.json ) && echo YES проверяет читаемость файла, а ( : >> result.json ) && echo YES — его записываемость. В обработке сигналов её можно задать в trap : INT, делая прерывание безопасным. В Git‑ алиасах её применяют для интерактивного rebase: riq = -c sequence.editor=: rebase --interactive. Исторически : восходит к 1971‑му Thompson‑shellу, где оно было меткой и первым комментарием; сегодня его называют «двумя глазами, полными любви», подчёркивая простоту и мощь этого простого символа.

Тред обсуждает использование колона в shell-скриптах: некоторые считают его вредным для читаемости и поддержки, другие — полезным для сокращения кода. @olexsmir рекомендует его для установки значений по умолчанию: `: ${DOTFILES_PATH:=$HOME/.dotfiles}`. @kps предлагает применять колон для форматирования вывода команд, упрощая копирование. @orphereus и другие критикуют колон как излишнее усложнение и признак плохого дизайна языка, предлагая ограничить его использование.

Мы находимся в центре искусственного‑интеллекта психоза: модели ускоряются, программисты увольняются, обещают, что к концу года искусственный интеллект напишет сто процентов кода, но при этом качество обычных приложений падает. Примеры из недели: банковское приложение требует трёх FaceID‑входов перед три‑разовым протоколом, Slack на macOS крадёт фокус у Ghostty и отправляет git pull в чат, холодильник LG выдаёт ошибку при гарантийном запросе, а авто‑инфо‑система после обновления глючит: звук поворота исчезает, Google Maps открывается вместо радио, задержка в секунду перед реакцией.

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

Пользователи отмечают снижение качества ПО, связывая это не столько с ИИ, сколько с отсутствием стимулов к качеству, чрезмерной сложностью и давлением на быстрое развитие. Некоторые предлагают решения: использование LTS-дистрибутивов Linux, фокус на надёжности и упрощение интерфейсов.

В предстоящем созыве 2026 года официально предложено полностью запретить любые проекты, связанные с криптовалютами, чтобы исключить их из официального программного пакета. Обсуждение собрало семь участников: Gusted, camopants, Johnny, -k, nekogirl, exidot и johnoestmannmusic. В задаче, размещённой в системе Codeberg, нет описания, но в ней указаны метки «No reviewers», «No milestone», «No assignees», «No due date» и «No dependencies», что подчёркивает отсутствие готовой оценки, планируемого срока и ответственных. Ссылка на задачу приводится как Codeberg/org!1254, а в ней перечислены участники с их аватарами, что делает процесс полностью открытым и прозрачным.

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

Пользователи считают запрет криптовалютных проектов на Codeberg неправильным решением, видя в нём цензуру, которая может подорвать репутацию платформы и привести к дальнейшим ограничениям. Другие оправдывают его необходимостью обеспечения безопасности и целостности платформы. Рекомендуется использовать альтернативы — Gitea или Forgejo.

Cursor содержит критическую уязвимость, позволяющую выполнить произвольный код при открытии репозитория с вредоносным файлом git.exe в корне — без каких-либо предупреждений или действий пользователя. Уязвимость проста, но опасна: IDE автоматически запускает этот файл, игнорируя безопасность. Учитывая, что Cursor используют более 7 млн активных пользователей и 50 тыс. компаний, а его оценка достигает $60 млрд, отсутствие реакции на уязвимость, обнаруженную в декабре 2025 года, вызывает серьёзные вопросы.

Mindgard неоднократно сообщал о проблеме через официальные каналы, включая security.txt и HackerOne, но Cursor игнорировал сообщения в течение семи месяцев, несмотря на подтверждение уязвимости и повторные запросы. Только после публичного давления компания признала сбой в автоматизированной системе, но не предприняла действий по исправлению. В ответ исследователи решили раскрыть детали — чтобы защищать пользователей, когда разработчик отказывается это делать. Для защиты рекомендуется блокировать выполнение исполняемых файлов в рабочих каталогах через AppLocker или использовать изолированные среды.

• LLM‑сгенерированные отчёты перегружают команду, их сложно отсеять без риска пропустить реальные проблемы
• Cursor по умолчанию не проверяет рабочее пространство, что позволяет выполнить произвольный код из репозитория (например, git.exe)
• Уязвимость связана с особенностью Windows, когда текущая директория имеет приоритет в поиске исполняемых файлов
• Публичное раскрытие вызвало споры о ответственности разработчиков и необходимости более строгих механизмов доверия

Экспериментальная подкоманда git history, появившаяся в версиях 2.54 и 2.55, предлагает три способа переписывания истории без риска поломки дерева. fixup позволяет поправить старый коммит, включив в него подготовленные изменения, и автоматически переписать все локальные ветки, построенные на его основе, сохраняя атомарность и отказываясь от операций, которые могут вызвать конфликт. При этом она не работает с merge‑коммитами, что ограничивает применение, но открывает путь к будущим улучшениям. Это особенно ценно, когда несколько веток используют один и тот же баг‑фикс, потому что исправление автоматически поднимается по всем зависимым ветвям.

reword меняет сообщение коммита и перестраивает всё, что находится над ним, без вмешательства в индекс или рабочее дерево, позволяя править сообщения даже в удалённых ветках. split делит один коммит на два, интерактивно выбирая части изменений, что упрощает разбиение крупного коммита без сложных rebase‑ов. Обе команды сохраняют целостность истории, а их главное преимущество — возможность применять изменения к любой ветке без её проверки, что делает их практичным альтернативным инструментом, сравнимым с более новым jj, но полностью встроенным в Git. Кроме того, split позволяет интерактивно разбивать изменения на отдельные части, не требуя сложных команд git add -p.

• Понимание внутреннего устройства Git (например, через Pro Git) упрощает работу с rebase и другими командами.
• Новые инструменты (git history fixup, git history split) упрощают изменение истории, но работают только без конфликтов.
• Автоматизация ребейза и рефиксаций может привести к «поломке» дерева, поэтому важно знать способы отката (git reset --hard, git reflog).
• Хорошо отредактированная история (одна логическая правка на коммит) облегчает поиск багов, регрессий и ревью, в отличие от полного сжатия изменений.

В Git существует три отдельных механизма для исключения файлов, работающих на разных уровнях. Основной — .gitignore, который хранится в репозитории и попадает в коммит; второй — .git/info/exclude, локальный для конкретного репозитория и не версионируется; третий — глобальный файл ~/.config/git/ignore, действующий для всех репозиториев на машине. Благодаря этому можно игнорировать как общие артефакты (например, .DS_Store), так и личные временные файлы, не засоряя .gitignore.

Для проверки, какой из файлов игнорирует конкретный путь, используется git check-ignore -v <файл>. Если правило берётся из .gitignore, вывод выглядит как .gitignore:1:.DS_Store .DS_Store; из .git/info/exclude — .git/info/exclude:7:.DS_Store .DS_Store; при использовании пользовательского глобального файла — /Users/nelson/.gitignore_global:1:.DS_Store .DS_Store. Если ничего не игнорирует файл, команда ничего не выводит. Кроме того, глобальный файл можно задать под другим именем, например .gitignore_global, командой git config --global core.excludesFile ~/.gitignore_global, а вернуть стандартный режим — git config --global --unset core.excludesFile. Это удобно, если хочется хранить отдельный набор правил, например, исключать все файлы с расширением .log или каталог build. Таким образом, гибкость игнорирования расширяется за пределы обычного .gitignore.

• .gitignore — обычный способ игнорировать файлы в репозитории, но его нельзя использовать для игнорирования глобально на всех проектах.
• Существует глобальный игнор‑файл (~/.config/git/ignore или ~/.gitignore_global), который игнорирует файлы для конкретного пользователя, а не для всей машины.
• Для локального игнорирования без изменения репозитория можно использовать .git/info/exclude или файл в .git (например, scratch/.gitignore с *).
• Иногда полезно добавить правила в .gitattributes (например, игнорировать package-lock.json) или использовать git update-index --assume-unchanged/--skip-worktree для временного отслеживания файлов.

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

Для отслеживания инцидента GitHub предлагает несколько способов уведомлений: email, SMS, интеграция со Slack и вебхуки. Пользователи могут настроить подписку на получение оповещений о создании, обновлении или решении инцидентов. Для подтверждения подписки требуется ввод OTP (одноразового пароля), а при выборе SMS-уведомлений доступен выбор страны и ввод телефонного номера.

• Массовые жалобы на сбой GitHub: проблемы с push/pull, Actions, raw.githubusercontent.com и SSH-аутентификацией.
• Рост обеспокоенности надёжностью облачных сервисов (AWS, GCP, Azure, GitHub), сбои происходят чаще.
• Критика централизации и приоритетов компаний: упрёки в пренебрежении инфраструктурой ради AI/прибыли.
• Поиск решений: рекомендации по самохостингу (Forgejo, Gitea), локальным кешированию git и отказу от полной зависимости от SaaS.
• Спекуляции о причинах: влияние AI на инфраструктуру, "vibe coding", общая хрупкость централизованных систем.

Автор случайно обнаружил lazygit во время экспериментов с neovim и настолько впечатлился, что полностью перешёл на него для всех git-работ. Инструмент сочетает простоту и скорость CLI с интерактивностью и наглядностью GUI, что особенно ценно для тех, кто плохо запоминает команды. По данным опроса StackOverflow 2022 года, 83% разработчиков предпочитают CLI для работы с git, но lazygit предлагает компромисс, сохраняя мощь командной строки while делая операции более доступными.

Lazygit выделяется тремя ключевыми особенностями: последовательность интерфейса, удобство навигации и интерактивность. Автор подчёркивает, что несмотря на преимущества GUI, новичкам всё равно следует изучать git CLI, так как он обеспечивает максимальный контроль и необходим для работы в средах без графического интерфейса. Инструмент идеально подходит для разработчиков, ищущих баланс между мощью командной строки и удобством визуального интерфейса.

• Разные инструменты подходят под разные задачи: от легковесных консольных утилит вроде tig до полноценных GUI вроде SourceTree или GitKraken.
• Некоторые участники отдают предпочтение TUI-решениям вроде lazygit, другие — полноценным GUI, а кто-то вовсе предпочитает консоль.
• Несколько человек упомянули, что используют jj (Jujutsu) вместо Git, и что это может быть более удобным для новичков.
• Некоторые участники поделились ссылками на инструменты, которые могут быть полезны для решения конкретных задач, таких как git-absorb для автоматического разбиения коммитов и tig для просмотра истории.
• Были упомянуты такие инструменты, как lazygit, tig, gitui, gitin, lazygit, fork, lazygit и gitui, каждый из которых имеет свои сильные стороны и может быть полезен в различных ситуациях.

В работе с monorepo, где ежедневно делаются сотни коммитов, тесты внезапно начали проваливаться. Проблема была в изменении конфигурационного файла, который ссылался на неверный аккаунт, но найти виновника среди множества коммитов вручную было невозможно. Тогда коллега применил git bisect - инструмент, использующий бинарный поиск для локализации проблемного коммита. Это позволило точно определить, где именно был внесен сбойный код, после чего откат этого коммита восстановил работоспособность системы.

В статье приведен наглядный пример репозитория с функцией сложения, где намеренно введена ошибка - преобразование аргументов в строки. Запуск git bisect start, указание "плохого" и "хорошего" коммитов, затем git bisect run ./test_script.sh автоматически проверяет промежуточные версии. Инструмент последовательно тестирует коммиты, сокращая количество проверок вдвое на каждом шаге, и точно находит первый сбойный коммит, где функция add начала возвращать строку вместо числа.

• git bisect is a powerful tool for pinpointing the exact commit that introduced a bug, especially in large or poorly tested codebases.
• Its real value is in narrowing the search space when you lack the tests or architecture to reason about the code, not in replacing proper testing or code review.
• The discussion exposed a cultural divide: some developers see bisect as a last-ditch rescue tool for when tests or architecture have already failed, while others argue that if you need it, your process has already failed.
• Several commenters pointed out that if you have to reach for bisect, you probably lack tests, logging, or a clear commit history, and the real fix is to improve those, not to rely on bisection.
• The thread also surfaced the point that bisection is only useful if you can reliably detect the bug in every commit; if the bug is non-deterministic or only shows up in production, the tool becomes much less useful.

Автор активно использует Claude Code как для хобби-проектов, так и профессионально, где его команда потребляет несколько миллиардов токенов в месяц для генерации кода. По его мнению, пространство CLI-агентов стало конкурентным полем, но выбор разработчиков часто зависит от поверхностных различий в реализации функций или "тона" системных промптов, а не от фундаментальных различий. Автор предпочитает подход "забыл и забыл" — делегировать задачи, задавать контекст и позволять ИИ работать, оценивая результат по финальному PR, а не по процессу.

Ключевым элементом эффективного использования Claude Code является файл CLAUDE.md в корне репозитория, который служит "конституцией" для агента. В профессиональной среде этот файл строго поддерживается и достигает 13 КБ, потенциально вырастая до 25 КБ. Автор рекомендует начинать с ограничений, а не с полного руководства, избегать встраивания полного документации в контекст, не просто говорить "никогда", а предлагать альтернативы, и использовать CLAUDE.md как инструмент для упрощения внутреннего инструментария. Для совместимости с другими AI-IDE файл синхронизируется с AGENTS.md.

• Обсуждение охватывает вопросы от синхронизации файлов агентов (AGENTS.md ↔ CLAUDE.md) до философии MCP и навыков (skills), а также затрагивает рабочий процесс с git-worktree и CLI-утилитами.
• Участники обмениваются опытом использования Claude Code, Cursor и других инструментов, обсуждают их преимущества и недостатки, а также их влияние на разработку и рабочий процесс.
• Обсуждаются проблемы с контекстом, который может использовать агент, и как лучше всего структурировать проекты для облегчения работы агента.
• Также затрагивается вопрос о том, как лучше всего использовать инструменты в зависимости от ситуации и как они могут быть улучшены.

Любой сервер с SSH-доступом может стать Git-сервером. Достаточно клонировать репозиторий через git clone ssh://username@hostname/path/to/repo, а для отправки изменений добавить на сервере git config receive.denyCurrentBranch updateInstead. Этот подход идеален для синхронизации кода между устройствами или работы с файлами на сервере без задержек.

Для публикации кода через веб нужно указать веб-серверу путь к Git-репозиторию и выполнить git update-server-info. Чтобы это происходило автоматически, можно настроить хук post-update, который будет запускать эту команду после каждого обновления. Хуки также могут использоваться для запуска статических генераторов сайтов — автор блога успешно применяет этот метод для своего сайта, получая преимущества локальной работы и автоматического развёртывания.

Такой подход обеспечивает встроенное резервное копирование: при поломке сервера данные останутся на ноутбуке, и наоборот. Git-трекинг версий предотвращает случайные удаления и упрощает отладку ошибок.

• Обсуждение охватило широкий спектр тем: от фундаментальных концепций (bare-репозитории, push-в-в-ssh, хуки) до практических аспектов (самостоятельный хостинг, CI/CD, бэкапы).
• Участники подчеркнули, что Git изначально задумывался как распределённая система без необходимости в централизованном хостинге, и что это встроено в его архитектуру.
• Были упомянуты различные инструменты и практики, такие как git init --bare, git daemon, git-shell, хуки и т.д., как часть более широкого обсуждения о том, как Git может быть использован для хостинга репозиториев.
• Обсуждались также более широкие темы, такие как философия open-source, централизация против децентрализации, и как GitHub/GitLab и подобные платформы влияют на разработку ПО и сообщество.

В 2012 году автор, работая с Ruby и Rails, обнаружил Rust и увидел в нём потенциал. Он оценил три ключевых фактора успеха языка: рыночную нишу (безопасность памяти без сборщика мусора как инновация в низкоуровневом программировании), команду (поддержку Mozilla) и пользователей (планы использовать Rust в Firefox). Этот подход помог ему принять решение присоединиться к проекту Rust, написать руководство "Rust for Rubyists" и в итоге войти в команду.

Сейчас автор применяет тот же анализ к jj — новой системе контроля версий, написанной на Rust. Как и в случае с Rust, он видит у jj хорошую рыночную нишу (возможность работать с Git-репозиториями для постепенного внедрения), сильную команду (Google использует jj) и растущую пользовательскую базу. На первой конференции jj создатель马丁 отметил важный аспект, хотя детали в статье не раскрываются.

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

Разработчики Zed анонсировали полноценную версию редактора кода для Windows. Теперь он доступен как в стабильной, так и в тестовой версии, причём последняя обновляется еженедельно. Zed на Windows использует DirectX 11 для рендеринга и DirectWrite для рендеринга текста, что обеспечивает нативное соответствие платформе.

Ключевая особенность — глубокая интеграция с WSL и SSH: пользователи могут открывать папки из WSL прямо в Zed, а все операции I/O происходят через удалённое соединение. Это распространяется на все функции, включая работу с Git, терминалами и отладчиками.

Расширения Zed, основанные на WebAssembly, работают на Windows без дополнительных настроек. Они изолированы через WASI, что обеспечивает безопасность и прозрачность работы с файлами.

Команда призывает пользователей тестировать Zed на Windows, особенно в контексте WSL, различных мониторов и сложных конфигураций клавиатур. Отзывы помогут ускорить фиксацию багов и улучшение платформы.

• Основные проблемы: отсутствие DevContainer, медленный LSP-ответ, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нт поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нт поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нт поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нт поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нт поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нт поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нт поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нт поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нт поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нт поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нт поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нт поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нт поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нт поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нт поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нт поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нт поддержки WSL, нет поддержки ARM64, нт поддержки DevContainer, нт поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нт поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нт поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нт поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нт поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нт поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нт поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нт поддержки WSL, нет поддержки ARM64, нт поддержки DevContainer, нт поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нт поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нт поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нт поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нт поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нт поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нт поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нт поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нт поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нт поддержки DevContainer, нт поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нт поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нт поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нт поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нт поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нт поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нт поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нт поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нт поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нт поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нт поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нт поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нт поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нт поддержки WSL, нет поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нт поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нт поддержки WSL, нет поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нт поддержки WSL, нт поддержки ARM64, нет поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нт поддержки WSL, нет поддержки ARM64, нт поддержки DevContainer, нет поддержки WSL, нет поддержки ARM64, нет поддержки DevContainer, нт поддержки

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

• автоматически создают git-worktree для изолированной работы над задачей;
• ведут диалог с агентом, пока тот не сформулирует план и начнёт реализацию;
• разбивают задачу на подзадачи и делегируют их суб-агентам;
• проводят код-ревью каждого PR.

Самое важное — это набор «скиллов» в формате Markdown, которые обучают модель, как обращаться с конкретными инструментами. Скиллы можно писать вручную, но проще сказать «прочитай и выпиши скиллы из книги X». Это поднимает вопросы об IP, но пока что это внутреняя кухня Anthropic, вопросы пока остаются открытыми.

Проект называется Superpowers, и он уже доступен как плагин для claude-code.

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

Tangled — это новая платформа для совместной работы с Git, построенная на AT Protocol. Вместо централизованных серверов она предлагает «узлы» — лёгкие headless-серверы, которые можно поднять на Raspberry Pi. Узлы могут быть как однопользовательскими, так и мультитенантными, а весь «интерфейс» консолидируется в единое веб-приложение на tangled.sh. Проект декларирует три принципа: полный контроль над данными, низкий порог входа и не вмешательство в UX. Пока что доступ осуществляется по инвайтам в IRC-канале #tangled на libera.chat.

• Обсуждение вращается вокруг трёх тем: децентрализация, монолитные платформы vs. модульные сервисы и экономика открытого исходного кода.
• Участники обсуждают, как сделать git более децентрализованным, но при этом не теряя удобства и не создавая барьеров для входа.
• Обсуждается, как избежать блокировок и цензуры, и как при этом не терять удобство и не платить за хостинг.
• Также поднимается вопрос о том, как избежать vendor lock-in и как при этом не терять удобство и не платить за хостинг.

Разработчик случайно удалил рабочий код, который улучшал метрики ML-модели на 5%, и не смог его восстановить. Вместо git он использовал LLM с контекстом в 1 млн токенов, которая сохранила историю взаимодействий. Просто запросив исходную версию файла, он мгновенно вернул потерянный код. Это демонстрирует неожиданное преимущество больших контекстных окон — они действуют как автоматический журнал изменений, компенсируя человеческие ошибки.

• Критика использования ИИ как замены систем контроля версий (Git) из-за риска потери или повреждения кода.
• Подчеркивание важности регулярных коммитов в Git и использования функций локальной истории IDE для сохранения работы.
• Обсуждение технических ограничений ИИ, таких как ошибки в воспроизведении кода и непонимание контекста, даже при больших размерах контекстного окна.
• Упоминание о том, что некоторые инструменты ИИ (например, Gemini CLI) могут хранить данные для отката изменений, но это не надежная замена VCS.
• Восприятие исходной истории как юмористической или саркастической, но с предупреждением о серьезных последствиях подобных практик.

Код-ревью часто превращается в формальность из-за слишком больших и сложных пул-реквестов. Разработчики избегают глубокого анализа, ограничиваясь поверхностными комментариями, что ведёт к накоплению технического долга и уязвимостей. Ключевое решение — нормализовать возврат непонятных PR авторам и дробить функциональность на мелкие изменения объёмом до 300 строк, которые можно проверить за 5–10 минут.

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

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

Нетехнический основатель перестроил сайт стартапа с помощью ИИ-агента Claude Code за недели вместо месяцев изучения кода. Использовал стек: VS Code, CLI Claude, GitHub CLI и сервер Figma MCP для точного переноса дизайна из Figma в код на Remix. Качество ответов Claude варьировалось — иногда он менял не те части кода, что отнимало часы.

Рабочий процесс включал локальную разработку, пуши в ветку и создание пул-реквестов через Claude. Ключевой трюк: просить Claude выступать в роли CTO для ревью PR, что помогало находить упущенные оптимизации. Это позволило избежать шаблонных решений no-code платформ и точно реализовать кастомный дизайн.

• Рекомендуется активно управлять контекстом при работе с ИИ-ассистентами, очищая его между задачами для повышения фокуса и снижения смещения.
• Использование ИИ для генерации кода требует осторожности и постоянного контроля человека из-за риска ошибок, изменения не тех файлов и создания запутанного кода.
• Эффективные стратегии работы включают поэтапное планирование задач, сохранение промежуточных результатов и использование нескольких инструментов (Claude Code, Cursor, Figma MCP).
• Мнения разделились: одни видят в ИИ значительный прирост продуктивности, другие считают его использование избыточным или ведущим к потере времени.
• Ключевые проблемы: сложность поддержки сгенерированного кода, нарушение принципов проектирования и необходимость чётких промптов для качественного результата.

В проекте Git предложено постепенное внедрение Rust в ядро системы, начиная с версии 3.0. Это тестовый шаг, аналогичный прошлым экспериментам с C99, чтобы дать сообществу время адаптироваться к новым требованиям инструментария. Первым кандидатом для перевода выбран модуль varint.c из-за его простоты и отсутствия зависимостей — уже реализованная версия на Rust прошла все тесты.

Пока поддержка Rust добавлена только в систему сборки Meson, с планами расширения на Makefiles. Также предстоит настроить CI-задачи для проверки сборки, форматирования кода и других аспектов. Это позволит поэтапно развивать инфраструктуру без немедленных обязательств, фокусируясь на процессе интеграции, а не на конкретных функциях.

• Предложение сделать Rust обязательной частью инфраструктуры сборки Git 3.0, пока как опциональная зависимость, с переходом на обязательную после появления поддержки в GCC.
• Высказаны опасения о снижении портируемости из-за ограниченной поддержки платформ Rust, сложности инструментария и повышении порога входа для новых разработчиков.
• Часть сообщества видит в этом ненужное усложнение для зрелого проекта и сомневается в целесообразности из-за малого объема нового кода.
• Другие считают, что Rust улучшит безопасность и консолидирует код, заменив существующие скриптовые языки, и что изучение нового языка — норма для разработчиков.
• Обсуждение включает технические детали о кросскомпиляции, поддержке различных архитектур и влиянии на такие проекты, как libgit2.

Культура разработки смещается от любознательных инженеров-исследователей к прагматичным метрико-ориентированным специалистам. Раньше разработчики создавали инструменты вроде Linux или Git из чистого любопытства, проводя ночи за экспериментами с технологиями без чёткой цели. Такой подход порождал инновации и глубокое понимание ремесла, а процесс обучения был ценен сам по себе, без ожидания монетизации или масштабирования.

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

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

pass — менеджер паролей в духе Unix.
Каждый пароль — отдельный gpg-файл в ~/.password-store; можно каталогизировать, копировать, версионировать в git.

Команды:

• pass — список;
• pass site.com — показ;
• pass -c site.com — 45 с в буфере;
• pass insert site.com → ввод;
• pass generate site.com 15 → создать;
• pass rm site.com — удалить;
• pass git push/pull — синхронизация.

Установка: apt/yum/pacman/brew install pass или tar.

• pass — это минималистичный CLI-менеджер паролей на Bash + GPG; кто-то использует 10+ лет и доволен, кто-то уже ушёл.
• Главные претензии: неструктурированные файлы (приходится парсить в каждом скрипте), GPG-ключи сложны, плагинов/нормальных мобильных клиентов почти нет, Android-приложение заархивировано.
• Уязвимость: если агент GPG закешировал ключ, любой скрипт может выполнить pass и выкачать все секреты; спасает только PIN + touch на YubiKey.
• Удобные альтернативы: KeePassXC/KeePassDX, Bitwarden (есть CLI), Vaultwarden; синхронизация pass через Git работает, но историю зашифрованных файлов не посмотреть обычным git diff.
• Для shared/корпоративного использования нет аудита доступа и нормального способа перешифровки для новых сотрудников — приходится менять все пароли.

running-qix-malware
Репозиторий демонстрирует работу вируса QIX (1989) в эмуляторе DOS.

• Собранный DOS-бинарь запускается в браузере через эмулятор.
• Исходники на ассемблере и C, скрипты сборки.
• Инфицирует .COM-файлы, показывает бегущую линию.
• Безопасен: эмуляция изолирует вредоносный код.

• Участники вспомнили про инцидент Jia Tan и пожаловались, что npm до сих пор не автоматически блокирует публикации с обфусцированным кодом и шестнадцатеричными именами.
• Предложены меры: предпубликационный сканер с «задержкой на проверку», 2FA-апрув каждого релиза, опциональный «verified»-бейдж и поддержка Yubikey.
• Сомнения в пользе LavaMoat: не спасает от DLL в lifecycle-скриптах, не работает с Webpack HMR, а изоляция может быть дорогой.
• Обсуждали lock-файлы: хэши в package-lock защищают от перезаписи версии, но теги git всё ещё можно подменить; иммутабельность npm-тарболлов считается основной защитой.
• Namespaces (@scope) в npm есть с 2016 г., но «красивые» безскоповые имена всё ещё популярны, поэтому переход идёт медленно.

Форматирование кода должно быть лишним

В 80-х это уже знали.
Мой школьный учитель информатики, мистер Пейдж, участвовал в разработке компилятора Ada. Когда я в 2016-м жаловался на линтеры, он напомнил: проблему решили 40 лет назад. В Ada исходники не хранили — использовали IR-дерево DIANA. Каждый смотрел его в своём стиле: отступы, пробелы — всё равно.

Сейчас, в 2025-м, мы всё ещё спорим о запятых.

Как это работало
Рабочая станция Rational R1000 (1985) хранила не текст, а DIANA. IDE позволял редактировать дерево напрямую — проекционное редактирование. Компиляция была инкрементной, рефакторинг мгновенным, а «исходник» — просто красивой печатью дерева.

Плюсы: никаких holy-war’ов о табах, быстрая интеграция, встроенный VCS и отладка.
Минус: требовалась железная станция и знание Ada.

Вывод
Не нужно возвращаться к проекционным редакторам, но можно ли встроить идею «храним структуру, а не текст» в современные языки и IDE? Тогда форматирование станет личным вкусом, а не командным законом.

• Одни считают форматирование важным каналом коммуникации и показателем вкуса/опыта разработчика, другие — пустым байкшедом, который должен решаться автоматическим линтером без обсуждений.
• Хранение кода не как текста, а как IR/AST (пример — Ada/DIANA, Unison) позволяет каждому видеть свой вариант форматирования, но ломает привычные grep, diff, git и другие текстовые инструменты.
• Проекционное редактирование (JetBrains MPS, Chrome DevTools «pretty») демонстрирует «один IR — много представлений», но требует специальных IDE и пока не стало массовым.
• Проблема смешанных языков, legacy, необходимости универсального стандарта IR и инерции экосистемы тормозит переход от plain-text.
• Автоформатеры (gofmt, Prettier, Black) уже закрывают 90 % вопросов: на сохранении/коммите единый стиль, локально можно настроить git-фильтры smudge/clean.

Блог работает на переработанном Google Pixel 5

Вдохновившись постами в Mastodon о сайтах на ESP32 и Android-солнечных панелях, решил запустить блог с телефона. Успешно: вы это читаете.

Железо

• Google Pixel 5, от Verizon, без разблокировки загрузчика.
• Поддержка USB-OTG и Ethernet-адаптера.
• Питание: 100 Вт солнечная панель + Jackery 160 Вт — сайт полностью автономен.

Софт
Termux + Hugo из репозитория. Пакеты: git, screen, openssh, hugo, dufs (веб-загрузка файлов).
Сервисы: sshd, cronie через sv-enable.

Опыт
Первые сутки — разные версии Hugo и контроль заряда. Сейчас всё стабильно и быстро; внешне не отличить от VPS.

Планы: не трогать, пока не сломается.

• Автор запустил личный блог на старом Google Pixel 5, питая его от солнечной панели и аккумулятора, чтобы продемонстрировать энергоэффективность и повторное использование техники.
• Участники отмечают, что современные ARM-смартфоны потребляют <5 Вт против 50–100 Вт у x86-сервера, что экономит до 800 кВт·ч в год.
• Обсуждаются риски: старые аккумуляторы при 24/7 работе могут «раздуться» и вызвать пожар, поэтому предлагаются варианты безбатарейного питания по USB-PD.
• Вопросы безопасности: Pixel 5 уже не получает обновлений, а Termux-окружение может ломаться из-за несовместимости пакетов.
• Некоторые считают идею интересной, но для статического сайта дешевле и надёжнее использовать GitHub Pages или S3.

Magic Lantern 2025: Midsummer Edition
21 июня 2025

Возвращение официальных сборок

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

Что изменилось
После ухода a1ex в 2020 остались фрагментарные доки и нерабочая система сборки. Несколько волонтёров восстановили проект:

• обновили сайт и репозиторий;
• перешли на Git, современные ОС и инструменты;
• код стал чище, быстрее, компактнее;
• добавлена поддержка Digic 6/7.

Новая команда
g3gg0, kitor, names_are_hard, WalterSchulz.
Lead-dev: names_are_hard.

Новые камеры

• 200D / Kiss X9 / Rebel SL2
• 6D Mark II
• 750D / Rebel T6i / Kiss X8i
• 7D Mark II

Хотите помочь? Нужны разработчики C.

• Magic Lantern возвращается: это бесплатная надстройка, расширяющая возможности старых и новых Canon-ов за счёт реверса прошивки.
• Проект перешёл на Git, современный тулинг и чистую сборку без варнингов, что упрощает вход новым разработчикам.
• Нужен C и желание покопаться в «железе»; камеры стоимостью <$100 подходят, сообщество приглашает помогать.
• Пользователи вспоминают RAW-видео, таймлапсы, HDR-скрипты и другие «фичи», которых нет в штатной прошивке.
• Нет поддержки новых Sony/Nikon/Fujifilm, но многие мечтают о таких же проектах для других марок.

Monodraw — редактор ASCII-графики для macOS (11 Big Sur+).
Пробная версия бесплатно, лицензия — $9.99, скидки для учебных заведений.

Возможности

• Диаграммы: структуры данных, алгоритмы, ER-диаграммы (нотация «Crow’s Foot»).
• Mind-map: свободное размещение текста на бесконечном холсте.
• Баннеры: 148 встроенных шрифтов FIGlet, изменение размера и выравнивание.
• Инструменты: прямоугольники, линии (ортогональные, лестницы), текст, карандаш, ластик, заливка, пипетка.
• Точки крепления: линии автоматически цепляются к фигурам.
• CLI: генерация документации в хуках Git, экспорт JSON.
• Группы, направляющие, фокус-режим, горячие клавиши для быстрой работы.

Экспорт: PNG, SVG.

• Разработчик Monodraw отвечает на вопросы; пользователи делятся альтернативами (asciiflow, textik, durdraw, REXPaint).
• Все хвалят чистоту результата, низкую цену ($10 навсегда) и удобство вставки ASCII-диаграмм прямо в код или документацию.
• Основные сценарии: комментарии в исходниках, схемы сетей, баннеры серверов, ASCII-анимации, план кухни.
• Главный недостаток: приложение только для macOS; много просьб портировать на Linux.
• Новая текстовая разметка (апрель 2025) улучшает работу с системами контроля версий.

JavaScript отключён.
Включите его или перейдите в поддерживаемый браузер. Список браузеров — в Справке.

Что-то пошло не так.
Попробуйте ещё раз.

⚠️ Расширения, блокирующие трекинг, могут мешать работе сайта. Отключите их и обновите страницу.

• Участники считают, что давать LLM-агенту полный доступ к браузеру — это «смертельный трифекта»: чтение всех вкладок, кук и паролей.
• Основной риск — prompt-injection: любой сайт может внедрить команду, и агент выполнит её, потому что «каждое чтение — это запись в контекст».
• Люди сравнивают это с тем, что Microsoft делала скриншоты, но теперь молчат, когда AI получает plaintext-доступ к банковским данным.
• Единственный «безопасный» сценарий — код в git, где изменения легко откатить; всё остальное (покупки, банкинг, e-mail) считается безумным.
• Итог: без изоляции, sandbox и чёткого разграничения «что можно» агенты становятся идеальным вектором атак, а компании, их выпускающие, — объектом для судебных исков.

Код-ревью можно улучшить

Мы отложили эксперимент с git-review — инструментом, который делает ревью коммитом поверх PR.
Проблемы GitHub:

• состояние ревью не хранится в репозитории;
• всё через веб, с лагами и лишними кликами.

Локальный workflow
Я клонирую ветку, сбрасываю её, чтобы код выглядел «моим», и ревью в Magit: запускаю тесты, перехожу к определениям, помечаю файлы через git add -p.
Но оставлять замечания приходится в браузере: долго, неудобно, текстовое поле тормозит.

Идея git-review

• ревью = коммит с комментариями вида // CR(name): …;
• автор и ревьюер редактируют этот коммит (--force-with-lease);
• по окончании добавляется revert-коммит, сохраняя историю.

Почему не зашло
Комментарии в коде — супер, но:

• если меняешь код, комментарии смещаются и конфликтуют;
• --force-with-lease добавляет трения;
• нужен более мягкий merge для ревью, а не строгая цепочка хэшей.
  Довести до ума потребовало бы >500 строк «быстрого хака».

К тому же, в upstream-git может появиться Change-Id в стиле Gerrit, что изменит ландшафт.

• Основная боль: ревью приходит слишком поздно, заставляя переписывать всё с нуля.
• Решения: локальное ревью в IDE (IntelliJ, VS Code), stacked-PR, «reviewer merges»-подход.
• Инструменты: Gerrit, Phabricator, Graphite, GitButler, SourceHut, GitPatch, Tangled.
• Надёжный Change-ID в Git обещает фиксить проблемы с force-push и interdiff.
• Культура важнее инструментов: мелкие, самостоятельные коммиты, RFC-прототипы, совместное проектирование до кода.

Sequoia ведёт раунд $32 млн для Zed
Суммарное финансирование превысило $42 млн. Четыре года мы строили самый быстрый IDE, но это лишь фундамент. Следующая цель — живое, непрерывное сотрудничество, где разговоры о коде всегда связаны с актуальным состоянием проекта.

Проблема снимков
Git ограничивает обсуждение коммитами и ветками. Между коммитами разработчик работает изолированно; обсуждения в чатах быстро теряют связь с кодом. ИИ-агенты тем более страдают: каждый их шаг требует снимка, что тормозит итерации.

DeltaDB: версионирование операций
Мы создаём DeltaDB — систему, которая фиксирует каждое изменение на уровне операций через CRDT. Она совместима с Git, но позволяет:

• реальное время без снимков;
• пермалинки на символы, выживающие при любом рефакторинге;
• сохранение диалогов и контекста навсегда.

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

Zed и DeltaDB будут open-source с платными опциями. Набираем команду — присоединяйтесь.

• Вокруг Zed спор: продукт вызывает восторг качеством кода и скоростью, но $42 млн от Sequoia вызывают тревогу VC-«эншитификации».
• Главные сомнения: окупится ли такой капитал на «просто редакторе» и не приведёт ли к навязыванию AI-фич и сбора данных.
• Плюсы: финансирование даст ресурсы догнать Cursor/VS Code по AI и снизить трения миграции.
• Тех-фишка: анонс DeltaDB — версионирование уровня каждого символа через CRDT, совместимое с git.
• Часть пользователей уже ищет форки (Zedless) или возвращается к Sublime, опасаясь потери приватности и роста требований.

Основы Obsidian
Obsidian строится на базах — папках, где хранятся заметки (*.md). Одна база = одна папка. Внутри можно создавать подпапки, но все они считаются частью этой базы.

Создание

• Новая: File → New Vault → выбрать папку.
• Существующая: Open folder as vault — подключить уже готовую папку с .md.

Место хранения

• Локально (по умолчанию) — файлы на диске.
• Синхронизация — через Obsidian Sync, Git, iCloud, Dropbox и т.д. (файлы остаются вашими).

Одновременная работа
Можно открыть несколько баз одновременно: каждая в отдельной вкладке/окне. Переключение через Ctrl/Cmd+O.

Перенос
Просто скопируйте папку базы — она полностью переносима. Никаких скрытых зависимостей.

• Bases — это официальная табличная надстройка над файлами хранилища: каждая строка = один файл, каждый столбец = его свойство (рейтинг, дедлайн и т.д.).
• Функция только вышла из платного раннего доступа; часть пользователей видит в ней замену плагинам Projects/Dataview, другие считают реализацию сырой.
• Главная претензия: чтобы воспользоваться Bases, приходится дробить контент на множество мелких файлов, что неудобно и грузит файловую систему.
• Тем, кто использует Obsidian как CRM или ведёт кампании D&D, возможность фильтровать и сортировать NPC/контакты уже оказалась полезной.
• Пока нет множественного выбора ячеек, встроенных Kanban-видов и встраивания таблиц в существующие заметки, но API и улучшения обещаны в дорожной карте.

Большие файлы — давний враг Git: раздувают репозиторий, замедляют клонирование и дорого обходятся хостингам. С 2015 г. GitHub предлагает Git LFS, но он влечёт vendor-lock, плату за хранение, сложности отката и необходимость ставить расширение всем участникам.

Сегодня можно обойтись без LFS:

• Partial clone (--filter=blob:limit=100k) скачивает только нужные большие файлы, ускоряя клонирование в 30–50 раз и уменьшая дисковый след до размеров LFS-чекаутов.
• Недостаток: команды вроде git blame требуют до-загрузки, но для PNG-файлов это редко нужно.

Будущее — large object promisors:
Git-сервер будет прозрачно выгружать большие объекты в специальный remote, избавляя пользователей от LFS и хостинги — от лишних затрат.

• Критикуют Git LFS за «проприетарность», но многие отмечают, что протокол открыт и работает и с GitLab, и с S3.
• Основные боли: сломанные офлайн-режимы, многократная аутентификация, высокие расходы на трафик и неочевидные команды при клоне.
• Альтернативы — git-annex, DVC, Oxen, datamon и просто «не класть большие файлы в git», а хранить их в Artifactory.
• Часть участников ждёт нативную поддержку больших файлов в самом Git, чтобы не помнить про --filter=blob:none и LFS-указатели.

Modos Paper Monitor — открытый e-paper монитор 75 Гц и dev-kit.
Собрано $61 611 из $110 000, 37 дней до конца кампании.

В комплекте

• Плата на FPGA (Caster, 60 Гц, открытая прошивка).
• 6" и 13" монохромные панели; контроллер подходит и к другим экранам 6–13,3".
• HDMI/USB, Linux/macOS/Windows.
• Корпус-чертежи и ПО на GitHub.

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

• Закрытые драйверы и высокие цены тормозят e-paper.
• Мы даём инженерам и энтузиастам свободу экспериментировать и формировать стандарты (Discord, Mastodon, Matrix, Bluesky).

Возможности

• Низкая задержка: независимые области обновления, отмена прежних пикселей.
• Гибкие режимы: бинарный для скорости + гибридный серый для деталей.
• C API: полный контроль режимов и обновлений.

Цены

$199–$599, 6 вариантов комплектации.

GitHub-список совместимых экранов

• Проект Glider — полностью открытый: исходники, Verilog, документация и файлы платы на GitHub/GitLab.
• NLnet и ЕС профинансировали разработку; обсуждаются условия грантов и гражданство авторов.
• Контроллер на низкобюджетном FPGA выдаёт HDMI/USB-C, но пока не предлагает LVDS/eDP для моддинга ноутбуков.
• Демо показывает высокую скорость обновления при заметном «ghosting»; блики — особенность дешёвой панели, не самой платы.
• Участники хотят 21–24″ монохромный 30 Гц дисплей дешевле $500, сенсорный слой и драйверы X11/Wayland.
• Упомянуты альтернативы: Inkplate, TRMNL, Boox, а также DIY-кибердеки и ноутбуки ThinkPad T480 с e-ink.

Я архивирую Picocrypt · Issue #134 · Picocrypt/Picocrypt

===============

Пропустить к содержимому Меню навигации

Переключить навигацию

Войти

Настройки внешнего вида

• Продукт
  • GitHub Copilot Пишите код лучше с ИИ
  • GitHub Spark Новое Создавайте и внедряйте интеллектуальные приложения
  • GitHub Models Новое Управляйте и сравнивайте подсказки
  • GitHub Advanced Security Находите и исправляйте уязвимости
  • Actions Автоматизируйте любые процессы
  • Codespaces Мгновенные среды разработки
  • Issues Планируйте и отслеживайте работу
  • Code Review Управляйте изменениями кода
  • Discussions Сотрудничество вне кода
  • Code Search Ищите быстрее и точнее

Исследуйте

• Почему GitHub

• Все возможности

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

• GitHub Skills

• Блог

• Решения

По размеру компании

• Предприятия
• Малые и средние команды
• Стартапы
• НКО

По кейсам

• DevSecOps
• DevOps
• CI/CD
• Все кейсы

По отраслям

• Здравоохранение
• Финансовые услуги
• Производство
• Госструктуры
• Все отрасли

Все решения

• Ресурсы

Темы

• ИИ
• DevOps
• Безопасность
• Разработка ПО
• Все темы

Изучайте

• Обучающие маршруты

• События и вебинары

• Ebooks и whitepapers

• Истории клиентов

• Партнеры

• Executive Insights

• Open Source

  • GitHub Sponsors Поддержка разработчиков
  • The ReadME Project Материалы сообщества

Репозитории

• Темы

• В тренде

• Подборки

• Enterprise

  • Платформа для разработчиков на базе ИИ

Дополнения

• Advanced Security Корпоративная безопасность

• Copilot for business Корпоративные ИИ-возможности

• Премиум-поддержка 24/7

• Цены

Поиск или переход...

Поиск кода, репозиториев, пользователей, issues, pull requests...

Поиск

Очистить

Советы по синтаксису

Оставить отзыв

Мы читаем каждый отзыв и относимся к нему серьезно.

• [x] Указать мой email для связи

Отмена Отправить отзыв

Сохраненные поиски

Используйте сохраненные запросы для быстрого фильтра

Название

Запрос

Все квалификаторы в документации.

Отмена Создать сохраненный поиск

Войти

Зарегистрироваться

Настройки внешнего вида

Сброс фокуса

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

{{ message }}

Picocrypt/Picocrypt Публичный

• Уведомления

• Обсуждение вокруг автора проекта Picocrypt, который архивирует репозиторий и уходит из разработки из-за разочарования в «вибе-кодинге» и доминировании ИИ/LLM, оформлено как диалог с Gemini, что некоторых сбило с толку.
• Часть комментаторов сочувствует утрате «ремесленного» подхода и демотивации, другие считают реакцию чрезмерной, доomer-ной или попыткой личного брендинга.
• Спор о лицензиях: MIT критикуют как «слабую» (корпорации выигрывают), предлагают AGPL/SSPL и обсуждают бессмысленность запрета «обучения ИИ» из-за непроверяемости корпусов.
• Поднимаются вопросы ответственности перед донорами на аудит и ожиданий сообщества: код доступен, но без поддержки возникают риски багов/совместимости.
• Есть технические замечания к проекту (напр., зависимость от OpenGL на macOS, результаты VirusTotal) и альтернативы (7zip, VeraCrypt); некоторые форкают и планируют упростить GUI.
• Мнения о LLM: от полного отказа и счастья без них до признания их неизбежности как «массового производства кода»; отмечают, что ИИ не делает людей экспертами, и традиционные инструменты часто надежнее.
• Отмечают парадокс: критикуя ИИ-кодинг, автор собирается в исследование LLM; часть видит в этом стратегию карьеры и нехватку ресурсов на опенсорс, а не «конец качества».