Автор провёл три месяца, используя ИИ-агентов для декомпиляции популярного шутера от первого лица, стремясь не к прототипу, а к точному, стабильному и полнофункциональному воссозданию игры на C++. Вместе с командой из RektInator, Future, st0rm и других участников сообщества он сосредоточился на оркестрации автономных агентов, оптимизации инфраструктуры и отладке процесса, а не на самой игре или технике декомпиляции. Агенты работали в Claude Code и Codex CLI, используя модели вроде Sonnet 5, Opus 5.5 и Luna, отслеживая прогресс через GitHub Issues и общаясь в Discord, где публиковались также сбои CI. Для работы с бинарником применялся ida-mcp от Hex-Rays — стабильный и headless-инструмент. За первый месяц четыре агента (три воркера и один ревьювер) декомпилировали ~80% игры, запустили главное меню и загрузку карт, но позже обнаружили, что сгенерированный код был низкого качества, и попытки его исправить заняли больше времени, чем пересоздание с нуля — вывод: корректность важнее продуктивности. Для снижения расхода токенов порог компакции контекста был снижен с 90% до 42%, а для борьбы с дрейфом внимания агентов внедрялся почасовой сброс инструкций. К концу проекта использовалось 15+ агентов, что выявило новые сложности: периодический сброс VM из-за ошибочных команд привёл к потере логов, и автор оценивает общий расход в 600–700 млрд токенов, из которых ~300 млрд пришлись на Luna (эквивалентно ~3 млрд токенов Astra при соотношении 100:1). Из-за корпоративного давления название игры не раскрывается, код остаётся приватным, а автор сейчас развивает свой эмулятор Sogen для создания надёжного песочницы, необходимой для будущих подобных проектов. Orchestration ИИ-агентов оказалась гораздо сложнее, чем ожидалось, но дала бесценный опыт в управлении автономными системами в долгосрочной разработке.

Тред дополняет статью практическими возражениями против цели байт-идентичности: указывает на избыточные затраты, альтернативные подходы к функциональной эквивалентности и роль качества модели, а также подчеркивает, что даже полная покрытость тестами не гарантирует идентичного поведения в сложных системах с глобальным состоянием. Спор: Некоторые считают байт-идентичный вывод избыточным и дорогим; другие настаивают, что только он гарантирует полную функциональную эквивалентность, включая неизвестные баги и поведение переполнений. Спор: Критики метода проверки последовательностей чтения/записи в RAM отмечают, что он не улавливает различия в поведении FPU, регистров или размещения переменных на стеке, при этом сохраняя семантическую эквивалентность. Совет: Опыт @aetherspawn показывает, что замена Sonnet на более мощную модель (Sol 6.1) снизила затраты с $1000 до $50 и ускорила завершение задачи с недели до двух дней. Совет: По опыту @momo5502, использование дешёвых моделей (Luna) при строгом харнессе позволяет эффективно обрабатывать сотни миллиардов токенов, что эквивалентно десяткам миллиардов токенов дорогих моделей. Спор: Участники отмечают, что даже с десятками тысяч тестов, покрывающих все ветки, невозможно гарантировать идентичное поведение из-за зависимости от глобального состояния и внешних данных, характерных для игр. Совет: Опыт @ChoosesBarbecue подтверждает, что глубокое знание игры (10 лет моддинга и эксплуатации) критически важно для успешной декомпиляции, иначе даже ИИ не справится с контекстом. Спор: Некоторые считают, что агентные системы не способны принимать архитектурные решения, требующие человеческого вкуса, что делает их непригодными для сложных систем без ручной настройки. Совет: Участник @edg5000 предлагает упростить процесс: вместо оркестрации агентов использовать один агент, что даёт лучший контроль над выводом, несмотря на большее время выполнения. Совет: Участник @tasubotadas отмечает, что даже без цели байт-идентичности процесс декомпиляции остаётся токен-интенсивным, особенно для редких игр с нестандартной архитектурой. Спор: Вопрос о легальности: участники спорят, каким образом использование ИИ для декомпиляции отличается от ручного — и нарушает ли это TOS, если модель не получает явных указаний на игру. Совет: Участник @stevefan1999 указывает, что динамические диспетчеры (vtable, fat pointers) и различия в выравнивании компилятора значительно усложняют декомпиляцию, даже для опытных разработчиков. Совет: Участник @Neywiny поднимает вопрос о влиянии LTO: если код скомпилирован с объединением единиц компиляции, декомпиляция становится практически невозможной из-за потери структуры. Совет: Участник @Fizz43 предупреждает, что утверждения об '80% совпадении' от ИИ — бессмысленны, так как не имеют смысла в контексте бинарной эквивалентности. Совет: Участник @Uptrenda отмечает, что ИИ-модели могут отказываться участвовать в декомпиляции, если им известны TOS, что ставит под сомнение возможность использования закрытых моделей без обфускации входных данных. Все согласны, что декомпиляция игр с помощью ИИ — это не просто техническая задача, а сложный инженерный процесс, требующий глубокого понимания как архитектуры, так и юридических рисков.

Muse Gadgets — это открытая аппаратная платформа, позволяющая пользователям самостоятельно создавать устройства, взаимодействующие с Muse, используя готовые платы вроде ESP32 или Raspberry Pi и предоставленные SDK. Проект распространяется под лицензией Apache 2.0, код доступен на GitHub, и включает поддержку различных платформ: от микроконтроллеров до полноценных Linux-систем. Пользователи могут подключать дисплеи, датчики, кнопки, динамики и микрофоны, создавая персонализированные гаджеты для вывода информации, голосового взаимодействия или автоматизации задач.

В разделе примеров представлены конкретные реализации: например, Waveshare ESP32-S3-Touch-AMOLED-1.75C с круглым 1,75-дюймовым AMOLED-экраном, динамиком и микрофоном; Seeed reTerminal E1002 с цветным e-ink-дисплеем для отображения утренних briefings или списков покупок; M5Stack StickS3 — компактное устройство с экраном и кнопкой для отображения статуса Muse; а также концепция HDMI-стика для вывода Muse на телевизор. Все устройства разработаны сторонними производителями, Meta не гарантирует их работу и не endorses их. Сообщество активно взаимодействует в Discord, где сейчас онлайн 161 участник, делясь опытом, идеями и улучшениями SDK.

Тред подчеркивает скептицизм сообщества к инициативе Meta из-за рисков приватности, ограничений токенов SDK и нестабильной поддержки, но отмечает интерес DIY‐энтузиастов к использованию ESP32 и Raspberry Pi для экспериментов с AI‐агентами. Большинство комментаторов опасаются, что Meta собирает данные о домашней сети и личных устройствах через открытый SDK. SDK требует токен, ограниченный по количеству устройств, и может изменяться без предупреждения, что делает его ненадёжным для продакшн‐проектов. DIY‐сообщество ценит доступность дешёвых плат ESP32 и Raspberry Pi как шанс обучаться и экспериментировать с AI‐агентами. Рекомендуется следить за ростом цен на ESP32 из‐за возможного дефицита и удорожания при массовом спросе. Советуют рассмотреть открытые альтернативы, например TypeScript SDK от @wong2, чтобы избежать зависимости от Meta. Для безопасного тестирования предлагают использовать изолированные сети или VPN, чтобы ограничить доступ к личным устройствам. Ожидается, что крупные игроки (Google, Amazon, Apple) быстро создадут свои экосистемы и вытеснят Meta с рынка домашних AI‐агентов.

Lofi Cities — это бесплатное веб-приложение, которое сочетает анимированный пиксель-арт ночных городов с живой генерацией lofi-музыки прямо в браузере. Каждый город — это 480×270 пиксельный цикл длительностью четыре минуты, с уникальной погодой, достопримечательностями и ambient-звуками (дождь, поезда, волны), а музыка создаётся алгоритмически в реальном времени, без повторов и без необходимости регистрации или установки. Приложение работает на всех устройствах и предназначено как спокойный фон для учёбы, работы или отдыха.

Последние обновления добавили глобальный чат для каждого города: пользователи, смотрящие один и тот же город, видят друг друга в общей комнате, с метками города рядом с именами и тегами при совпадении ников (например, «sleepy fox ·3f»), сообщения хранятся три часа. Также улучшен интерфейс на мобильных — город, время, ссылки и счётчик онлайн теперь в одной карточке. Есть возможность сохранить кадр как 1080p PNG или установить как PWA. Billboard-ы в городах можно арендовать для своей рекламы через форму, а новые города предлагаются в Discord. Автор — Сафа Эмали, монетизация возможна через покупку видеопетли (без аудио) на Gumroad, но сам сайт остаётся бесплатным и без cookie.

Веб-приложение создаёт атмосферу для релаксации и фокусировки, но вызывает споры о качестве пиксель-арта, использовании ИИ и инвазивности рекламы, нарушающих иммерсивность. Критика пиксель-арта: некоторые считают его AI-сгенерированным из-за неправильных китайских и японских иероглифов в Токио и Гонконге, что снижает аутентичность; другие ценят визуальную атмосферу, не требуя точности символов. Реклама на Product Hunt воспринимается как разрушающая иммерсивность и несоответствующая пиксель-арт эстетике; другие пользователи не отмечают её как проблему, фокусируясь на музыке и визуале. Музыка вызывает разногласия: одни называют её атмосферной и удачной, другие — «basic midi» с диссонансными аккордами, не соответствующими lofi-стилю. Пользователи предлагают: - добавить переключение видов (окно, балкон, комната) для выбора между городскими и внутренними звуками; - отключать рекламу для чистого пиксель-арт опыта; - расширить список городов (Монреаль, Сидней, Каир, Афины и др.) с локальными деталями (жакаранды в Сиднее, арабеск-музыка в Стамбуле); - внедрить динамические погодные эффекты (дождь, гроза, осенние листья) с учётом сезонности (например, не сакура в несезон в Токио); - добавить <noscript> поддержку для объяснения отсутствия загрузки при отключённом JavaScript. Многие отмечают, что приложение идеально подходит для фокусировки и глубокой работы, особенно как фон на втором мониторе, благодаря генерируемой без повторов музыке и спокойной визуальной среде. Пользователи сравнивают проект с работами Mark Ferrari’s Living Worlds — ручная анимация, отсутствие рекламы, атмосферная динамика — и видят в нём высокий эталон. Согласованное мнение: музыка, сгенерированная в браузере без внешних зависимостей, — сильная сторона, отличающая проект от решений на основе AI-моделей вроде Lyria 3. Проект вызывает эмоциональный отклик через ностальгию и лиминальные пространства, объясняя его привлекательность несмотря на технические недостатки.

Я превратил свои наружные камеры видеонаблюдения в систему автоматической идентификации птиц с помощью BirdNet-Go — открытого проекта, который запускает модели распознавания птичьего пения локально на оборудовании. Система работает 24/7, анализируя аудиопоток с камер через RTSP и мгновенно определяя виды птиц, летучих мышей и даже лягушек по их звукам. Всё происходит без облака, без API и ежемесячных платежей — модели, включая Google Perch v2 (14 795 видов против 6000 в BirdNET 2.4), хранятся локально на сервере или Raspberry Pi.

Я настроил три существующие IP-камеры, подключив их к BirdNet-Go, и добавил правила оповещений: например, мгновенное уведомление в Discord-канал #birdnet при появлении кардинала или редкого вида. Система ведёт журнал всех обнаружений, отмечая новые виды для отслеживания биоразнообразия двора — за год зафиксировано 418 726 обнаружений 271 уникального вида, средняя уверенность 60,9%, самым частым оказался домовый вьюрок (118 667 записей). Интеграция с BirdWeather позволяет делиться данными с сообществом, а связка с Home Assistant выводит результаты на панель управления. Микрофоны камер автоматически глушатся при обнаружении речи — полезная функция для конфиденциальности. Для двора, где нет камер, рассматриваю отдельный микрофон, чтобы не нарушать приватность, но сохранить функциональность. Пока это не дверbell, но может использовать её RTSP-поток, если он есть. Всё работает как «птичий компаньон», который никогда не спит.

BirdNet-Go эффективно работает с RTSP-аудиопотоками от обычных камер видеонаблюдения, но качество распознавания сильно зависит от аудио-аппаратуры и частоты дискретизации — для надёжной работы требуется доработка оборудования. Для распознавания птиц и летучих мышей необходима частота дискретизации 48 кГц; стандартные камеры Aqara с 16 кГц не подходят — лучше использовать отдельный микрофон на Raspberry Pi. RTSP-поток от Unifi-камер позволяет интегрировать BirdNet-Go без дополнительного оборудования, что подтверждено в продакшене. BirdNet-Go стабильно работает на Home Assistant с GPU-ускорением и RTSP-потоками от Reolink-камер, обрабатывая несколько камер одновременно без облачных сервисов. Для распознавания летучих мышей требуются ультразвуковые частоты, поэтому нужны специализированные микрофоны вроде AudioMoth и высокая частота дискретизации, недоступная в большинстве камер. Популярные дополнения: e-ink-дисплеи для отображения распознанных видов в реальном времени; для снижения ложных срабатываний нужна настройка порогов уверенности модели, так как при плохом звуке и нестандартных условиях распознавание неточно. В ветреных условиях помогают микрофоны с шумоподавляющими экранами, иначе шум мешает распознаванию (пример — Aqara-камеры). Для портативного использования рекомендуется собирать систему на Raspberry Pi с внешним микрофоном и e-ink-дисплеем. Открытые модели BirdNet позволяют запускать систему локально без подписок, облачных API и риска отключения — ключевое преимущество перед коммерческими приложениями. Merlin Bird ID и BirdNet-Go часто дают низкопробные идентификации в Австралии при низкой вероятности, что требует ручной проверки с учётом локальной фауны. Интеграция BirdNet-Go с Frigate и другими системами видеоанализа возможна, но в проекте акцент на аудио, так как визуальное распознавание птиц по камере менее надёжно. Для автоматизации сбора данных рекомендуется синхронизировать результаты BirdNet-Go с eBird, чтобы вносить наблюдения в научную базу без ручного ввода.

ravynOS — это ранняя (pre-alpha) открытая операционная система, построенная на Darwin, FreeBSD и открытом коде Apple, стремящаяся обеспечить совместимость с macOS-приложениями без аппаратных ограничений. Проект создан как альтернатива закрытой экосистеме Apple, сочетая «изящество macOS» со «свободой открытого кода». На текущем этапе это developer preview: система не отполирована, незавершена и не предназначена для конечных пользователей, а ориентирована на тех, кто участвует в её разработке.

Цели ravynOS включают воспроизведение ключевых особенностей macOS: чистый дизайн с прозрачностью и типографикой, глобальное меню для экономии места, привычные Command-сочетания, простую установку через перетаскивание приложений в папку Applications, знакомую файловую иерархию (Applications, System, Library, Users), нативную поддержку Cocoa API и удобные терминальные утилиты вроде open и pbcopy. Для участия приглашаются разработчики и энтузиасты: доступны вики, обсуждения на GitHub и чат в Discord. Проект распространяется под правами RavynSoft (2021–2026), логотип и название являются товарными знаками.

RavynOS — ранний и амбициозный проект на базе открытого кода Apple (Darwin), сталкивающийся с реальными техническими и юридическими сложностями, но пока без подтверждённой практической жизнеспособности. Использование Discord для коммуникации отпугивает пользователей, уже достигших лимита в 100 серверов. Разработка на x86 вместо ARM обусловлена сложностью портирования из-за фрагментации чипов и нестандартных механизмов загрузки. Darwin не даёт значимых преимуществ перед другими ядрами, кроме совместимости с macOS-приложениями; архитектура ядра не отличается кардинально от Linux или BSD. Юридически проект безопасен: используется только открытый код Apple (Darwin, OpenDarwin, MkLinux) под лицензиями APSL, аналоги (GNUstep, Darling) не подвергались преследованию. Спор о бесполезности проекта (как «велосипед при наличии автомобиля») контраргументируется тем, что такая позиция обесценивает любые инновации, включая открытые ОС. Отсутствие скриншотов на сайте — критический недостаток: пользователи ожидают визуального подтверждения даже для pre-alpha. Сайт плохо адаптирован под мобильные устройства, вики нечитаема из-за боковой панели. RavynOS — уже пятый подобный проект (PureDarwin, Hello System и предыдущие версии RavynOS), что указывает на системную неудачу в создании жизнеспособной альтернативы macOS. Для совместимости с Cocoa-приложениями необходимо не просто использовать Darwin, а полностью переосмыслить реализацию API (через GNUstep или чистую переработку) — иначе разрыв между «почти» и «полной» совместимостью непреодолим. Разработчики, вероятно, участвовали в PureDarwin, что говорит о накоплении опыта, но не о прорыве. Применение ИИ может ускорить прогресс, но пока не доказано, что он решит фундаментальные проблемы совместимости и стабильности. Экосистема Apple не стала менее открытой с 1997 года — критика «закрытия» не соответствует реальности, что ослабляет мотивацию проекта.

В центре обновлённого дорожного плана MCP — пять приоритетных направлений, сформированных совместно с сообществом. Главное внимание уделяется агентным мессенджерным примитивам: новые механизмы, такие как Tasks, subscriptions/listen и progress‑уведомления, позволяют управлять длительными потоками, перенаправлять работу в реальном времени и избавиться от постоянного опроса клиента. Эти функции разрабатываются совместно с группами Agents, Transports и Triggers & Events, а также готовятся к включению в спецификацию (SEP‑2663).

Второй ключевой блок — унификация транспорта по HTTP. После релиза 2026‑07‑28 любой удалённый MCP‑сервер превращается в обычный HTTP‑службу, что упрощает развертывание на уже используемой инфраструктуре. Планируется расширить поддержку, включая локальные серверы через Streamable HTTP и stdio, чтобы сократить сложность клиент‑серверных взаимодействий.

Третья область — идентичность агентов и корпоративная безопасность. Текущая модель авторизации, ориентированная на подтверждение в браузере, не покрывает автономных агентов в облаке. Разрабатывается стандартный способ распознавания агентских идентификаций на основе Proof‑of‑Possession (RFC 9449), чтобы обеспечить доверие без длинных токенов.

Все эти направления получают приоритет в SEP‑процессе: предложения, попадающие в соответствующие зоны, проходят ускоренный review. Присоединиться можно через Working Groups, открытые дискуссии в Discord, экспериментальные расширения experimental-ext-* или прямую работу над спецификацией и SDK.

MCP упрощает централизованное управление навыками и доступом к инструментам — можно включать/выключать их для отдельных агентов, избегать ручного распространения skills.md и скрывать чувствительные данные (например, API-ключи) за stdio-сервером, защищая их от прямого доступа LLM. Для агентов без песочницы позволяет вызывать инструменты через внешний сервер как прокси. Планируется поддержка стандартных механизмов авторизации (DPoP, Workload Identity Federation) для замены долгоживущих токенов. Однако MCP вызывает сомнения: его сложность не оправдывает пользу для самих агентов — по сравнению с REST + skills.md, преимущества ощущают только организации. В версии 1 требовался сложный слой постоянства, затруднявший развертывание. Некоторые считают внедрение собственного протокола избыточным — предпочтительнее JSON-RPC или чистый HTTP.

Chatto — новый открытый клиент для группового общения, который можно развернуть самостоятельно. Установка проста: brew install chattocorp/tap/chatto && chatto init && chatto run. Приложение лёгкое, быстрое и полностью шифрует данные на устройстве per‑user ключами, уничтожая их при удалении аккаунта. Сервер обслуживает одну общину, без сторонних аналитики и без передачи данных между серверами. Поддерживаются голос и видеозвонки с экраном, полностью защищённые end‑to‑end, а также мульти‑серверный клиент.

В ближайшее время планируется публичный бета‑тест Chatto Cloud — хостинг с европейскими дата‑центрами, автоматическое масштабирование, ночные резервные копии и обновления без простоя. Серверы в облаке совместимы с самодельными, их данные можно перенести в любой момент. Разработчики обещают достичь версии 1.0 за полгода‑год, а в 0.5 добавить системы сообщений‑модерации и улучшить работу с несколькими серверами. Подписаться на редкую рассылку можно в конце поста, чтобы получать уведомления о релизах и beta‑тесте.

Версия 0.4 уже стабильна для продакшн‑использования, но впереди ещё функции защиты контента, модерации и улучшенный мульти‑серверный клиент. Планируется достичь 1.0 за полгода‑год, при этом возможны ломающие изменения, поэтому пользователям рекомендуется следить за обновлениями и поддерживать совместимость с self‑hosted инстансами.

• Самодостаточный бинарник с встроенным фронтендом и лёгким в развёртывании бекендом на NATS.
• UI копирует Discord, но пока не ясно, есть ли мобильное приложение и полная E2EE.
• Лицензирование разделено: backend AGPL, frontend Apache 2.0, что вызывает вопросы.
• Планируется поддержка интеграций, видео‑звонков и упрощённый процесс установки для новых пользователей.

Lore — это новый открытый контроль версий, созданный Epic Games для масштабных игровых и развлекательных проектов, где код сочетается с большими бинарными артефактами. Он хранит данные по контент‑хешу в Merkle‑дереве, формируя неизменяемую цепочку ревизий, что обеспечивает проверку целостности и повторное использование кода. Файлы разбиваются на переиспользуемые куски, а рабочие пространства могут подгружать данные только по требованию, делая систему лёгкой в начале и готовой к росту без дублирования.

Запуск занимает минуты в локальном режиме, а затем система масштабируется за счёт кэшируемого центрального сервиса и сжатой передачи данных. Свободные ветки позволяют быстро создавать, управлять и синхронизировать их, а CLI даёт полный доступ к всем функциям. Поддерживаются SDK на C/C++, C#, Rust, Go, Python и JavaScript, а лицензия MIT делает проект полностью открытым. Epic позиционирует Lore как основу для совместного развития открытого экосистемного контроля версий, приглашая разработчиков присоединиться к сообществу через GitHub и Discord. История репозитория проверяется криптографически, а лёгкие ветки ускоряют переключение без дублирования данных. Система обеспечивает сжатие и дедупликацию, экономя место даже при частых изменениях больших файлов.

• Lore — новый VCS от Epic, ориентированный на игровую разработку и работу с большими бинарными артефактами, позиционируется как конкурент Perforce.
• Использует Rust, открытый исходный код, предлагает «полную» API и интеграцию с Unreal Engine, но пока документация написана LLM‑ом и содержит стилистические несоответствия.
• Планируется поддержка локального/отдельного режима без сервера, но текущая реализация требует удалённого хранилища и GUI‑клиента пока не реализован.
• Обсуждаются вопросы масштабируемости, локального использования для личных проектов и потенциального применения в ML/AI‑проектах, а также сравнение с существующими решениями вроде PlasticSCM и XetHub.

Discord подтвердил, что в результате инцидента с поставщиком услуг клиентской поддержки могли быть скомпрометированы документы, касающиеся до 70 000 пользователей. Компания подчеркивает, что атакующие распространяют ложную информацию как часть вымогательской кампании. Пока неясно, какие именно данные были затронуты, но Discord утверждает, что «большинство» из них ограничиваются адресом электронной почты, номером телефона и/или имени пользователя.

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

Приложения на Electron вызывают серьёзные задержки в работе всей системы на macOS 26. Пользователи сообщают о замедлении интерфейса, лагах при вводе текста и проблемах с отзывчивостью даже при минимальной нагрузке. Это связано с тем, что фреймворк использует общие ресурсы системы неэффективно, особенно в многозадачных сценариях.

Проблема проявляется при одновременной работе нескольких Electron-приложений, таких как Slack, Discord или VS Code. Система начинает проседать по производительности, что негативно сказывается на пользовательском опыте. Разработчики Electron признают проблему и изучают её, но пока не предложили конкретного решения.

• Проблема с производительностью в macOS 26 вызвана использованием приложениями (включая Electron) приватных API Apple, что приводит к утечкам ресурсов и лагам.
• Некоторые пользователи не сталкиваются с проблемами, возможно, из-за высокой производительности железа (например, чипов M4), которое маскирует недочеты.
• Обсуждается, кто виноват: разработчики приложений за использование приватных методов или Apple за отсутствие регрессионного тестирования и обратной совместимости.
• Для части приложений (Chrome/Chromium) уже выпущен фикс, а также известны временные решения через терминал.
• Спектр мнений варьируется от критики Electron до защиты его как кросс-платформенного решения с хорошим DX.

Медленные социальные сети

Люди часто думают, что я ненавижу социальные сети. И их можно понять: я открыто критикую современные платформы и их влияние на людей и общество, а в 2019 году удалил все свои аккаунты.

Однако сама идея соцсетей мне близка: оставаться на связи с теми, кто вам дорог. Проблема в том, что нынешний формат искажён и антисоциален. Вместо укрепления связей эти рекламные контент-мельницы designed, чтобы удерживать внимание, усиливать одиночество и неудовлетворённость. Когда TikTok показал, что короткие видео с алгоритмом рекомендаций — это цифровой наркотик, остальные платформы тут же скопировали эту формулу.

Meta превратила Instagram и Facebook из инструментов общения в бесконечный скроллинг случайного контента. Даже Pinterest стал походить на TikTok! Компании следуют за вовлечённостью, игнорируя реальные предпочтения пользователей. Я убеждён, что любая коммерческая соцсеть со временем деградирует в рекомендательную медиасреду.

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

Каким же мог бы быть не-зловещий аналог? Идеал — чтобы все вели блоги и подписывались через RSS. Но это не масштабируется: не каждый готов писать тексты длиннее 255 символов. Многие мои друзья не знают о моём блоге или RSS.

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

• Общении с друзьями и близкими
• Реальной связи
• Укреплении отношений
• Осмысленном взаимодействии

И не должна касаться:

• Сбора подписчиков
• Самопродвижения
• Рекламы
• Коротких видео и развлечений

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

Также стоит ввести лимит на число друзей — например, 300. Больше — это уже коллекционирование, а не общение. Это устранит 90% маркетингового интереса.

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

Наконец, стоит ограничить число постов в день — скажем, 5. Это позволит сохранять осознанность публикаций и не захламлять ленту.

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

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

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

• Предлагается ввести ограничения для социальных сетей: лимит на число друзей (~300), количество постов в день и обязательное ежегодное взаимодействие для поддержания связи.
• Обсуждаются существующие альтернативы: закрытые платформы (Discord, форумы), децентрализованные решения (Mastodon, Scuttlebutt, Nostr) и нишевые сервисы (микроблоги, Slowly, Peergos).
• Отмечается, что монетизация через внимание и алгоритмы рекомендаций коммерческих платформ противоречит целям искреннего социального взаимодействия.
• Подчеркивается важность хронологической ленты без алгоритмов, отсутствия счетчиков лайков и акцента на приватность в небольших группах.
• Признается сложность преодоления сетевого эффекта крупных платформ и необходимость регуляции или изменения пользовательских привычек.
• Высказывается мнение, что люди используют мессенджеры (WhatsApp, Telegram) и группы по интересам для медленного и осмысленного общения.
• Указывается на ностальгию по ранним социальным сетям (Friendster, LiveJournal) и желание вернуть фокус на близкий круг общения, а не виральный контент.

Демосцена умирает, но это нормально

ЮНЕСКО внесла демосцену в «живое культурное наследие» Швеции.
Смешно и страшно: внимание может испортить старое доброе.

Сцена не мертва, но не обновляется
С 1980-х её регулярно хоронили: Amiga, PC, Интернет…
Разница в фото: рейв-2025 — те же молодые, демопати-2025 — те же 50-летние.
Подростков нет; большинство родились в эпоху C64 и DOS.

Высокий вход, низкий выигрыш
Субкультура сложилась из дешёвых 8-бит, модемов и отсутствия законов.
Без моды, музыки и внешнего блеска её невозможно продать.
Кряки, пиратство, фрики — всё держалось в тени и презирало коммерцию.
Статус «задрота» и такой трудоёмкий хобби отпугивали тренд-хантеров и девчонок.
Сцена так и не стала «крутой» — и это её спасло.

Новые не идут
Старики обсуждают, как привлечь молодёжь; регистрация в ЮНЕСКО — попытка.
Попасть сегодня легко: приехал на патив, показал демку — ты свой.
Пик численности — начало 90-х (тысячи гостей).
С тех пор — спад, и старания «открыть двери» не помогают.

• «Сцена мертва» — мем: демосцена жива, но средний возраст растёт, новички есть, но не в тех числах.
• Старое коммьюнити плохо втягивает молодёжь: документация стара, входной барьер высок, ностальгия доминирует.
• Современные ПК настолько мощны, что «64 КБ» или «сжать в 4 КБ» воспринимается уже как искусственный костыль, а не вызов.
• Поэтому интерес мигрировал в size-coding, fantasy-консоли (Pico-8), live-coding, гейм-джемы, TouchDesigner, движки вроде Notch/Tixl.
• Онлайн-площадок много (Pouët, Scene.org, Neocities, Dwitter), но живого общения мало — Discord и редкие встречи «в парке» заменяют демопати.
• Старые продолжают кодить и вспоминать The Party ’92, новые приходят единицами: сцена не умерла, но стала узким нишевым хобби.

OpenMower — проект превращения недорогих серийных газонокосилок-роботов в умные устройства с точной навигацией RTK-GPS.

• Цель: дать старому «железу» современные функции — карты, зоны, маршруты, автопарковку.
• Что внутри: полностью открытая прошивка, платы и 3D-печатные крепления; заменяем только «мозги», оставляя моторы и датчики.
• Требования: базовая газонокосилка (Flymo, Gardena, Worx и др.), плата-основа на Raspberry Pi 4, RTK-модуль, внешняя антенна.
• Функции:
  • планирование маршрутов по векторной карте;
  • работа по зонам и расписанию;
  • возврат на зарядку и продолжение с места остановки;
  • OTA-обновления и веб-интерфейс.
• Сборка: подробные инструкции и BOM в репозитории; сообщество в Discord помогает с отладкой.
• Лицензия: GPL-3.0, все файлы и схемы свободны.

• Кто-то считает, что «все современные газонокосилки ездят хаотично», но большинство пользователей отвечают: случайный алгоритм работает отлично, а провод периметра надёжен и дешёв.
• Аппаратное обеспечение у Husqvarna, Mammotion, Sunseeker и др. хвалят, но ПО всё ещё «сырое» и требует доработок.
• OpenMower заменяет «мозги» готового шасси RTK-GPS и открытым ПО; поддерживаемый корпус в США почти не продаётся.
• Поднимаются вопросы безопасности (ежи, камни, ответственность), цены (как подержанная машина) и необходимости косить только днём.
• Кто-то мечтает о солнечных микро-триммерах, другие просят RC-версию или модуль для сбора мусора.