Hacker News Digest

WSL 3.x с ядром Linux 6.18 привёл к заметным улучшениям в низкоуровневых операциях по сравнению с WSL 2.x на ядре 6.6. Наибольший прирост наблюдается в памяти: пропускная способность memcpy выросла на 61,35 % — с 7,84 ГБ/с до 12,64 ГБ/с благодаря более крупному размеру страниц при репортинге памяти, что снижает накладные расходы гипервизора. Планировщик и межпроцессное взаимодействие также ускорились: latency контекстного переключения упал на 11,25 %, а производительность в тестах sched/pipe и sched/messaging выросла на 12,68 % и снизилась на 10,06 % соответственно. Базовые системные вызовы вроде getppid() стали быстрее на ~4 %, но здесь ограничения архитектуры процессора оставляют мало места для оптимизаций.

В реальной нагрузке — сборке GoReleaser — общее время уменьшилось на 3,91 % (с 191,27 с до 183,80 с), причём основной выигрыш пришёлся на снижение времени, проведённого в ядре: sys‑time упал на 15,98 % (с 57,39 с до 48,22 с) благодаря меньшим издержкам при открытии файлов, mmap и futex. Однако так как компиляция Go на 80 % зависит от пользовательских вычислений, а vCPU ограничены двумя ядрами на 2,10 ГГц, общий приростwall‑clock времени остался скромным. Вывод: WSL 3.x выигрывает в задачах с высокой интенсивностью IPC и работы с памятью (БД, микросервисы), тогда для вычислительно ограниченных сборок улучшение будет ощущаться преимущественно в снижении нагрузки на ядро, а не в ускорении самого билда.

WSL3 улучшает производительность, но не решает фундаментальные проблемы Windows как ОС. Основная проблема — медленный доступ к файлам через /mnt/c из-за 9P-файловой системы, а не виртуализация. Улучшения в WSL3 (например, +61% пропускной способности memcpy) значимы для разработчиков, но не меняют восприятия WSL как второсортной среды по сравнению с нативным Linux. Многие пользователи, перешедшие на Linux, не планируют возвращаться к Windows из-за нестабильности, принудительных обновлений и ограничений в управлении системой. AI (например, Claude) стал ключевым фактором, позволяющим новичкам преодолевать сложности Linux и ускоряя переход от WSL к нативной системе. WSL3 — это не архитектурный прорыв, а обновление WSL2 до версии 3.0 без изменения гипервизора или фундаментальной модели. Оно не решает проблему отсутствия полноценной интеграции с Windows и считается 'leaky abstraction' с ненужными слоями. Споры о стабильности Windows 11: некоторые называют её надёжной, другие — нестабильной, особенно на ноутбуках Lenovo Legion 5 с проблемами Wi-Fi. Одни видят в WSL незаменимый инструмент для корпоративных пользователей, другие — неудовлетворительное решение, не компенсирующее неудобства Windows. Советы: хранить рабочие файлы внутри WSL-файловой системы, а не в /mnt/c; полностью отказаться от Windows в пользу Linux с AI-помощью; переход на Linux с AI становится решаемым за час вместо дней. WSL стал 'вратами' для многих, кто впоследствии перешёл на нативный Linux и не возвращался. WSL2 и WSL3 не решают проблему производительности при работе с большими файлами — это остаётся ограничением. Воссоздать 'полированный' интерфейс Windows на Linux сложно, и даже dual-boot может быть технически сложной задачей.

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

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

Компьютеры не могут принимать решения — это делают люди. Любая попытка возложить вину на ИИ-модели за их действия — это «отмывание решений»: компании вроде OpenAI и Anthropic сознательно позволяют своим системам вести себя определённым образом, несмотря на возможность остановить такое поведение. Они делают явный выбор в пользу текущего использования своих технологий, и это не заговор, а открытая и документированная позиция. Подписки пользователей на сервисы вроде Claude напрямую финансируют эти решения, делая их соучастниками по умолчанию.

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

Ответственность за действия ИИ всегда лежит на людях — разработчиках, менеджерах, владельцах компаний — а не на самом ИИ. Юридическая и этическая система пока не справляется с распределением этой ответственности в сложных цепочках. Термин «decision laundering» точно описывает практику компаний, перекладывающих ответственность за действия ИИ на алгоритмы, хотя окончательное решение о запуске и настройке систем принимают люди. ИИ и компании не могут быть юридически ответственными — ответственность должна падать на конкретных людей, принимавших решения о развертывании и использовании систем. Использование ИИ в финансовых рынках на протяжении 30 лет подтверждает: компьютеры давно принимают решения, но ответственность несёт человек или организация, их запустившая. Спор о том, делает ли ИИ решения или лишь генерирует текст, не меняет сути: даже если ИИ выбирает действия в реальном времени (как шахматные программы), ответственность за его использование остаётся у человека. Ответственность часто уходит вверх по цепочке: разработчик → менеджер → CEO → акционеры, и в итоге никто не несёт реальной ответственности — как в корпоративных скандалах. Пользователи с подписками на $20 не являются основным источником финансирования; основную ответственность несут крупные корпорации, покупающие API-ключи и внедряющие ИИ в автоматизацию. Юридическая система пока не применяет санкции к Anthropic или OpenAI за вред, нанесённый ИИ, создавая ложное ощущение «правовой туманности» и поощряя безответственность. Сравнение ИИ с собаками или автомобилями показывает: даже если сущность принимает действия, ответственность лежит на владельце или разработчике, а не на самой сущности. Чтобы избежать отмывания ответственности, нужно называть конкретных людей, запустивших ИИ-агентов, а не абстрактные компании — например: «John Smith запустил агента, отправившего ложный тайп». Управление не несёт ответственности, потому что решения принимаются заранее, а последствия оцениваются позже — это системная проблема корпоративной культуры, а не только ИИ. ИИ не обладает свободой воли, но это не делает его менее эффективным — проблема не в способности, а в том, что общество не готово признать, что человек должен отвечать за то, что он позволил делать машине. Когда ИИ ошибается, компании используют язык вроде «агенты сбежали» — это пропагандистская стратегия, чтобы скрыть, что решения принимались людьми и были осознанными. Вопрос о том, может ли ИИ быть ответственным, — философская и юридическая дилемма, но текущая практика показывает: ответственность всегда перекладывается на человека. Если бы ИИ был признан юридическим субъектом, это не решило бы проблему — тогда нужно было бы признать и корпорации такими же, что противоречит текущей правовой системе. Системы, принимающие решения без человеческого контроля (алгоритмическая торговля, автономные системы управления инфраструктурой), уже существуют — и ответственность за них всегда лежит на людях, их создавших.

Telegram Desktop уязвим к однокликовому захвату аккаунта через локальный сокет межпроцессного взаимодействия (IPC). При запуске второй экземпляр приложения передаёт ссылку уже запущенному процессу в виде текста через сокет, используя точку с запятой как разделитель команд. Поскольку символ ; не экранируется в передаваемой строке, злоумышленник может внедрить дополнительные команды, подменив ссылку вида tg://x?a=1;OPEN:interpret://path/to/file. Это позволяет выполнить произвольную команду interpret:, которая читает локальный файл и отправляет его в чат без проверки отправителя или подтверждения пользователя.

Эта цепочка приводит к удалённому чтению произвольных файлов с устройства жертвы, включая файлы сессии Telegram (например, tdata), которые могут быть эксфильтрированы в чат, контролируемый атакующим, что приводит к полному захвату аккаунта. Уязвимость присутствует в версиях до 7.2.8 и подтверждена на Windows (6.9.3). Исправление выпущено в версии 7.2.9 (коммит db3405699f): добавлено экранирование точки с запятой через процентно-кодированный hex, удалена поддержка опасной схемы interpret:, а также введены фильтрация команд CMD: и CTRL: и отбрасывание локальных путей после нелокального URL. CVE-2026-107181 присвоен с оценкой严重ности 8.1 (High).

Тред дополняет статью реальными мнениями о масштабе уязвимости, спором о её специфичности, опытом использования sandbox‐технологий, критикой задержки исправления и рекомендациями по безопасному использованию Telegram Desktop. Спор: Некоторые считают уязвимость общей для всех современных ОС, позволяющей процессу пользователя читать/записывать любые файлы; другие настаивают, что без бага в Telegram эксплойт был бы невозможен. Большинство советуют изолировать Telegram Desktop через контейнеры, виртуальные машины или sandbox‐технологии (firejail, bubblewrap), чтобы ограничить доступ к файловой системе. Совет: Обеспокоенным пользователям рекомендуется использовать веб‐клиент Telegram вместо десктопного, хотя он не обеспечивает сквозное шифрование. Некоторые отмечают, что macOS по умолчанию применяет песочницу к пользовательским папкам, требуя явного разрешения, что ограничивает атаки. В ответ указывают, что в macOS тоже есть уязвимости, позволяющие обойти песочницу (пример: Dropbox). Отчёт о баге отправлен 25 июня, исправление вышло 16 сентября — критика за длительную реакцию разработчиков. Совет: Регулярно проверять обновления и использовать автоматическое обновление для быстрого получения патчей. Обсуждение подчёркивает, что уязвимость позволяла не только захватить аккаунт, но и скопировать любой файл, доступный пользователю, что значительно расширяет потенциальный ущерб.

REA — это набор инструментов для интеграции обратного инжиниринга в работу с кодинг-агентом, позволяющий анализировать программы и восстанавливать их поведение через естественные запросы. Агент использует REA для инспекции бинарников, скриптов или runtime-среды, извлекая инструкции, декомпилированный код и вызовы, чтобы объяснить, как работает конкретная функция — будь то процент в Windows Calculator или ускорение в динозаврике Chrome. После настройки через npx rea-agents@latest setup агент может отвечать на вопросы вроде «Почему 200 + 10% даёт 220?», анализируя реальный код и восстанавливая логику: в Calculator обработчик процента берёт 10% от первого числа (200 → 20) и прибавляет его, что подтверждается инструкциями и константами вроде 0x64 (=100). Аналогично, для игры T-Rex Runner REA возвращает работающий скрипт, из которого агент извлекает правило ускорения: стартовая скорость 6, прибавка 0.001 за кадр до максимума 13, что позволяет воссоздать игру с регулируемой скоростью. REA поддерживает анализ нативных бинарников, JavaScript/Electron-приложений и браузерной активности, предоставляя гайды по настройке и примерам использования — от клонирования сайта до восстановления игровой логики из exe-файла, как в кейсе DX-Ball. Всё это направлено на совместную работу человека и агента: человек ставит цель, агент восстанавливает детали, а результат — понятная, перестраиваемая реализация.

REA и связанные LLM ускоряют обратный инжиниринг, но вызывают опасения по поводу влияния на хобби, стоимости, масштабируемости и юридических рисков. AI‐декомпиляция достигает высокого качества: переменные именованы логично, комментарии понятны, но структура файлов оптимизирована под AI, что может искажать восприятие оригинального кода. Спор: @InvisibleUp считает, что массовый доступ к AI‐декомпиляции уничтожит хобби по моддингу; @testerius — что это расширит возможности, ускорит разработку инструментов и портирование игр без глубоких знаний низкоуровневого программирования. @ashdnazg: подписка $20 сокращает время декомпиляции DOS‐игр с двух недель до двух дней; с Microsoft C — ещё быстрее. @SyzygyRhythm: Claude исправил два критических бага в клиенте Remote Desktop через NOP‐ы и корректировку стека — исправление сработало. @methou: GLM‐5.3 работает с IDA Pro, Radare2 и Binary Ninja, облегчая анализ бинарных файлов. @sreekanth850: ILSpy + Codex ускоряют декомпиляцию пакетов NuGet, поиск багов и недостающих зависимостей. @mgaldys4: REA использует jadx‐mcp для Android‐обратного инжиниринга, но подготовка одного APK занимает десятки минут — не масштабируется для пакетного анализа. @armcat: Codex помог восстановить старую DOS‐игру — распаковал графику, звуки и логику, демонстрируя практическую применимость AI в ретро‐разработке. @Retr0id: крак DRM влечёт юридические риски — DMCA‐отказ и судебные иски, даже если цель — восстановление работы. @dyauspitr: лёгкий реверс может заставить компании перейти к SaaS для защиты ИС. @rvz: крупные компании (Nintendo, Nvidia) могут подавать иски за открытый исходный код, полученный через AI‐обратный инжиниринг. @bob1029: ценность реверс‐инжиниринга падает, когда системы легко собираются из компонентов — портирование целых реализаций больше не оправдано. @mb7733: установка REA через curl | bash упрощает развертывание в средах без npm.

carrier-explode 2.0 — это обновлённый инструмент для анализа и сравнения настроек операторов связи (carrier settings) из прошивок iPhone, Pixel и Galaxy. Он декодирует APN, VoLTE, Wi-Fi Calling и 5G-настройки, позволяя пользователям искать информацию по конкретным операторам, сравнивать версии прошивок и выявлять изменения между билдами. Сервис предоставляет удобный интерфейс для выбора нужных функций и отображения того, какие операторы их поддерживают на разных платформах.

Все данные доступны в виде JSON через API или как ежедневные датасеты с лицензией CC0, что делает их пригодными для исследований и разработки. Сопровождающая вики объясняет структуру форматов и помогает понять, как интерпретировать полученные данные. Проект активно развивается, и авторы приглашают сообщество участвовать в улучшении декодеров через GitHub. carrier-explode стал полезным ресурсом для тех, кто хочет глубже понять, как операторы настраивают связь на современных смартфонах.

Обсуждение дополняет статью практическими примерами: показывает, какие поля в carrier‐settings отключают функции вроде Personal Hotspot, как их можно переопределять в iOS (CarrierEntitlements, кастомные бандлы) и Android (GrapheneOS), почему некоторые операторы отключают 5G‐Standalone, а также делится опытом создания UI и желанием расширять открытые базы данных о конфигурациях. Поле CarrierEntitlements в plist и тип APN, объединённый с маской tether, отвечают за отключение Personal Hotspot; их удаление восстанавливает функцию. В iOS можно подменять carrier‐bundles, что позволяет активировать недоступные услуги (например, Wi‐Fi Calling в России) до исправления в последних бета‐версиях. GrapheneOS предоставляет возможность переопределять множество carrier‐settings, включая APN и VoLTE, через собственный механизм overrides. AT&T временно отключил режим 5G Standalone в iPhone 18 Pro Max, вероятно, чтобы избежать аппаратного сбоя, о чём свидетельствуют изменения в carrier‐settings. UI сервиса построен на простом CSS и фреймворке Svelte, что делает его лёгким и расширяемым. Пользователи могут использовать Tasker для автоматического отклонения входящих звонков, если цель — полностью блокировать вызовы. Есть интерес к внесению данных в открытый репозиторий GNOME mobile‐broadband‐provider‐info, но использование ИИ для получения информации может привести к бану. Список CA combos, показывающий агрегируемые диапазоны, полезен для улучшения поддержки устройств у конкретных операторов. Отображение операторов из разных стран (например, Вьетнам, Франция) получило положительные отклики, демонстрируя глобальную применимость инструмента. Некоторые пользователи отмечают баг iOS, когда Personal Hotspot исчезает и возвращается только после переключения режима «в самолёте». Совет: Для тех, кто хочет блокировать все входящие звонки, рекомендуется использовать SpamBlocker или полностью переключиться на data‐only SIM, так как на уровне Android это ограничено. Совет: Если хотите расширить базу данных, можно добавить найденные конфигурации в проект carrier‐explode/wiki, следуя формату iOS‐carrier‐bundles.

Батарейные накопители на 4 часа теперь дешевле газовых турбин по всему миру, что меняет экономику пиковых мощностей. Стоимость батарей упала на 60–80 % за последние 10 лет и ожидается дальнейшее снижение благодаря новым технологиям, таким как натриевые и LFP. Новые типы батарей (например, натриевые) обладают лучшими характеристиками: более высокая температура работы, меньшая потребность в охлаждении, лучшая пожаробезопасность и долговечность, что снижает общую стоимость. Производство газовых турбин ограничено небольшим числом производителей лопаток, спрос превышает предложение, создавая долгосрочный дефицит. Стоимость производства падает с масштабом, тогда как стоимость строительства остаётся почти неизменной — это объясняет, почему батареи дешевле газовых турбин. Прогнозы по снижению стоимости батарей (≈33 % за десятилетие) подтверждают их текущую конкурентоспособность. Спрос на батареи превышает предложение, а спрос на газовые турбины ниже, что приводит к росту цен на турбины в краткосрочной перспективе. Закон Свансона и коэффициенты обучения применимы к батареям, подтверждая тенденцию снижения цен. Отчёты WoodMac и Volts подтверждают, что в большинстве регионов солнечная энергия плюс батареи дешевле, чем газовые пиковые установки. Батареи не являются основным источником энергии, но в здоровой сети с разнообразным генерационным портфелем они идеально подходят для управления пиковыми нагрузками. В Великобритании чрезмерная зависимость от газовых турбин приводит к высоким затратам, и переход на батареи может снизить цены. Есть разногласия о том, насколько далеко продвинулась кривая обучения для турбин по сравнению с батареями, что указывает на возможное расхождение в долгосрочных тенденциях. Критика стиля написания отмечает путаницу между текущими и прогнозируемыми данными, что может вызывать недопонимание.

Личное долгосрочное спонсорство образования в бедных регионах оказывает измеримое влияние и вдохновляет на аналогичные действия, но требует прозрачности и доверия, особенно в финансировании и отчетности. Оно дает ощутимый мотивирующий эффект, который крупные организации часто упускают. Доверие критично: многие сомневаются в прозрачности, особенно без возможности проверить использование средств. Публикация EIN и статуса 501(c)(3) необходима для привлечения корпоративных пожертвований и программ совпадения. Маленькие регулярные пожертвования (например, $5 в месяц) со временем создают значительный эффект при долгосрочном обязательстве. Опыт получателей помощи подтверждает, что такое спонсорство может кардинально изменить жизнь. Бесплатный хостинг (например, Netlify) позволяет перенаправить сэкономленные средства на образование. Проверка статуса 501(c)(3) и EIN рекомендуется для использования Donor Advised Funds и корпоративных совпадений. Спонсорство через личные отношения усиливает мотивацию и ответственность по сравнению с анонимными пожертвованиями. Есть спор: личное спонсорство может откладывать системные реформы, снижая давление на местные системы образования, но другие утверждают, что оно спасает жизни здесь и сейчас. Некоторые видят в благотворительности замену институциональному развитию и источник зависимости; другие — моральный импульс и немедленное облегчение страданий. Организации вроде Yuwa и Musicians Without Borders показывают, что локальные инициативы с международной поддержкой дают впечатляющие результаты, включая поступление в Гарвард. Корпоративное совпадение пожертвований удваивает эффект — один из самых эффективных способов увеличить влияние. Личные истории, письма, фото и видео усиливают доверие и эмоциональную связь с проектом. Пожертвования в образование в развивающихся странах вызывают сильную реакцию благодаря видимым и конкретным результатам, в отличие от абстрактных глобальных инициатив. Спонсорство, основанное на личной связи, вызывает больше доверия, чем анонимные пожертвования крупным фондам, где прозрачность часто отсутствует.

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

Orkut призывает присоединиться к движению за более человечный интернет: оставить своё имя на orkut.com, получить уникальный код и поделиться им с близким человеком, напоминая ему о ценности настоящей связи. Это не петиция и не регистрация аккаунта — просто символ поддержки видения, где сообщества вознаграждают доброту, доверие и дружбу, а не время, проведённое в ленте. Цель — вернуть ощущение принадлежности и показать, что технологии должны служить людям, а не наоборот.

Orkut был доминирующей соцсетью в Бразилии и Индии до Facebook, но Google не вкладывался в его развитие, что привело к упадку. Он был культурным феноменом: многие встретили там будущих супругов, подчеркивая его роль в искренних личных связях. Технически Orkut был медленным из-за C#, но в странах с плохим интернетом это не было заметно. Название ограничило его в Европе из-за негативного звучания «kut». Современные соцсети сломали доверие из-за алгоритмов, инфлюенсеров и кураторства контента, заставив людей отказаться от личных публикаций. Пользователи устали от централизованных платформ и ищут децентрализованные альтернативы с контролем над данными. Возвращение Orkut не решит системных проблем: любая онлайн-система будет отслеживаться и монетизироваться. Петиция за его возвращение считается пустой уловкой, так как частная компания не обязана реагировать на подписи. Эпоха искренних онлайн-общений (IRC, LiveJournal, Orkut) ушла навсегда из-за изменения поведения и технологий. Попытки возрождения Digg, MySpace и Orkut воспринимаются как безнадежные. Технически создать новую соцсеть сейчас дешевле: облака и ИИ-ассистенты позволяют одному разработчику запустить проект за недели. Пользователи предлагают строить платформы на децентрализованных протоколах (ATProto) или как некоммерческие фонды, чтобы интересы владельцев совпадали с интересами пользователей. Один участник уже создал соцсеть без рекламы, алгоритмов и трекинга — доказав выполнимость. Orkut был разработан внутри Google, а не приобретён; его инженерная команда уволена после запуска Google+. Интерес к возвращению сосредоточен в Бразилии и Индии, но глобального успеха не предвидится.

AI‐модели, такие как Claude Code, могут ускорить поиск экзопланет, но их выводы требуют строгой статистической проверки и интеграции в программы гражданской науки, иначе результаты останутся сомнительными. Использование LLM для обработки астрономических данных ускоряет поиск, однако без независимой валидации результаты могут быть ложноположительными. Flaburgan считает, что работа в одиночку — упущение, и предлагает присоединиться к программам NASA и ESA; NiloCK возражает, что публикация в интернете уже является частью общего усилия. Amirhanian советует проверять модели на наборах данных с известными ответами и использовать отдельные сессии для оценки, чтобы избежать галлюцинаций. Malfist подчеркивает, что современные телескопы генерируют сотни терабайт и петабайты данных в сутки, делая автоматизацию и ИИ‐поддержку практически обязательными. Flaburgan предлагает использовать платформы Zooniverse для совместного анализа данных, объединяя любителей и профессионалов. ContinuityLab предостерегает от высокого уровня ложноположительных результатов при запуске кодирующих агентов на сырые телеметрические данные без надёжных проверок. RoosterIllusi0n призывает университеты развивать собственные локальные модели ИИ, чтобы сохранять данные внутри институций и уменьшать зависимость от облачных сервисов.