Hacker News Digest

Обновлённые правила и политики Bluesky

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

1. Правила сообщества (проект)

• Четкая структура: 4 принципа — безопасность, уважение, подлинность, соблюдение правил.
• Категории вреда: примеры под UK OSA, EU DSA, US TAKE IT DOWN Act.
• Модерация: прогрессивная система наказаний и прозрачность.
• Апелляции: вне- и внесудебные механизмы для жителей ЕС.

Комментарии принимаются до 28 августа; вступят в силу 15 октября. Форма обратной связи.

2. Условия предоставления услуг (вступают 15 сентября)

• Возрастные ограничения и проверки (COPPA, OSA, DSA).
• Детали модерации и реакции на незаконный контент.
• Процедура апелляций.
• Упрощённое разрешение споров: сначала звонок, затем — по выбору пользователя: суд или арбитраж (по схеме 1-1-1).

3. Политика конфиденциальности

• Права пользователей (GDPR, UK GDPR).
• Международные передачи данных и защита.
• Удаление данных: ограничения из-за децентрализованной архитектуры.
• Специальные разделы по юрисдикциям.

4. Политика авторского права

• Упрощённая процедура удаления (DMCA, DSA).
• Защита от злоупотреблений жалобами.
• Данные для прозрачных отчётов.

Все обновлённые документы доступны на странице поддержки.

Мы нанимаем!
Присоединяйтесь к команде, строящей открытый и децентрализованный интернет. Вакансии.

• Участники жалуются на неясную модель монетизации Bluesky и сомневаются, что децентрализация когда-нибудь будет реализована.
• Основная претензия к любой площадке — эхо-камеры, политизация и низкое качество дискуссий; «хорошие» сообщества есть, но их мало.
• Многие рассматривают уход из-за возможных требований к верификации возраста и отсутствия прозрачной апелляции при блокировках.
• Часть пользователей всё ещё находит ценные технические треды в X/Twitter, но считает участие в платформе морально сомнительным.
• Общий вывод: не привязывайтесь к одной сети, ведь «ничто не останется хорошим навсегда».

Gemma 3 270M — самая маленькая модель семейства Gemma 3, всего 270 млн параметров.
Подходит для запуска на смартфонах, микроконтроллерах и в браузере без облака.

• Производительность: на MMLU и HumanEval обгоняет Gemma 2 2B и Llama 3.2 3B, уступает Gemma 3 1B.
• Скорость: на Pixel 8 Pro — 1,2 токена/с, на RTX 4090 — 200 токенов/с.
• Форматы: Keras, JAX, PyTorch, Gemma.cpp, Ollama, Transformers.
• Лицензия: Gemma Terms of Use, коммерческое применение разрешено.

Доступна в Kaggle, Hugging Face, Ollama и через gemma-3-270m-it в Vertex AI.

• Команда представила Gemma 3 270M — сверхкомпактную модель (241 МБ) для локального запуска и тонкой настройки под узкие задачи.
• Пользователи уже тестируют её на телефонах, но жалуются на холлюцинации и слабое следование инструкциям.
• Обсуждаются примеры применения: тегирование статей WordPress, NER/перевод, генерация SVG, «умные» клавиатуры, обработка 50 млн строк в день.
• Многие спрашивают туториалы по дообучению и сравнение с Qwen 0.6B, который показывает лучшее качество при схожем размере.
• Авторы подчеркивают: модель «из коробки» слаба, но после fine-tuning может стать мощным специализированным инструментом.

Я написал What the Fork — кроссплатформенный визуализатор сборки C/C++ (и не только).
Запуск: wtf make, wtf cargo build, wtf gradle build, wtf -x для Xcode и т.д.

Инструмент показывает все процессы, включая скрытые вызовы ld, и ищет типичные проблемы:

• отсутствие -j у make,
• однопоточная компиляция,
• повторяющиеся cmake/make-шаги,
• непараллельные CI-сборки.

Как работает
Сборка = дерево команд. Чтобы увидеть всё, ловим системные вызовы fork/exec/exit:

• macOS — Endpoint Security API,
• Linux — ptrace,
• Windows — Event Tracing (самое мерзкое API).

Что уже нашли

• cargo собирал зависимость одним потоком вместо 10× ускорения.
• ninja при сборке LLVM держит 12 задач на 10 ядрах — почти идеал.
• CMake 85 раз подряд вызывает xcode-select, sw_vers, cmake/make → clang, не используя параллелизм.

Инструмент открыт для тестов — попробуйте на своём проекте.

• Пользователи восторженно реагируют на новый визуализатор сборки, особенно те, кто застрял на CMake/GCC/Make без clang/ninja и не может понять, почему сборка тормозит.
• Просят сразу показать GIF-демонстрацию под заголовком статьи и спрашивают, будет ли macOS-версия и открытый код.
• Некоторые делятся опытом: strace/dtruss, ninjatracing, vcperf, cargo --timings, Instruments и другие инструменты уже решали похожие задачи.
• Предложения расширить функциональность: добавить flame-графы процессов, поддержку fork(), интеграцию с Bazel Build Event Protocol, оценку «осталось времени» по историческим данным.
• Отдельные комментарии касаются маркетинга (сменить название), сравнения с VS/Xcode, а также шуток про TEEP/OEE завода и «LLVM, завари кофе».

Краткий перевод и сжатие

Суть претензии к статье ASU
Авторы обучили крошечную модель (600 k параметров) решать алфавитные задачи вида «A B C D [M1] → B C D E» и выводить цепочки мыслей. Они показали, что при малейшем сдвиге распределения (новая последовательность операций, лишний токен, увеличение длины) модель ломается. Отсюда вывод: «рассуждения» — это лишь копирование шаблонов из обучения, а не логический вывод.

Почему это неубедительно

1. Без языка нет рассуждений
   Настоящие цепочки мыслей полны «подожди», «а если…» и самокоррекции. Задача «сдвинь буквы» — это вычисление, а не рассуждение.
2. Слишком маленькая модель
   У 600 k параметров просто не хватит «мозгов» разложить сложное правило на части. Способность к рассуждению появляется у крупных моделей.
3. Сравнение с человеком отсутствует
   Люди тоже путаются при новых формулировках и учатся на примерах. Без измерения человеческих ошибок утверждение «это мираж» не имеет опоры.

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

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

Почему LLM не могут строить ПО

Эффективный инженер постоянно прокручивает цикл:

1. формирует ментальную модель требований,
2. пишет код,
3. проверяет, что он реально делает,
4. сверяет модели и правит код или требования.

LLM умеют писать и обновлять код, запускать тесты, логировать, но не умеют держать в голове ясную модель. Они путаются: считают, что всё работает, не понимают, где ошибка — в коде или в тесте, и при раздражении сносят всё и начинают заново. Человек же, столкнувшись с проблемой, может «свернуть» контекст, сфокусироваться на детали, затем вернуться к общей картине.

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

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

• LLM хороши как инструменты-ассистенты: быстро пишут boilerplate, находят мелкие ошибки, экономят время на рутине.
• Главный недостаток — неспособность удерживать и «поддерживать» целостную ментальную модель задачи; контекст «размывается» или меняется непредсказуемо.
• Поэтому при росте кодовой базы отладка превращается в «чтение спагетти», и инженер всё равно вынужден начинать заново.
• Решение — не «больше контекста», а системы-обёртки: TDD-циклы, пошаговое планирование, документация-модель, строгие промпты.
• Вывод: сейчас LLM заменяют джунов и Google-поиск, но полноценное ПО без человека, который держит «теорию» проекта в голове, построить не могут.

Meta без согласия собирала данные о здоровье женщин из Flo, постановил суд

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

Flo, запущенный в 2015 году в Беларуси, использовал Facebook Software Development Kit (SDK), который автоматически передавал данные в Meta. Это позволяло Facebook таргетировать рекламу на основе репродуктивного статуса женщин. Суд обязал Meta выплатить компенсации и прекратить незаконный сбор информации.

• Flo передавала через Facebook SDK чувствительные медицинские данные без ограничений на их дальнейшее использование.
• Суд оправдал Meta, но участники считают, что и Flo, и Meta несут моральную ответственность: одна отправила, другая использовала данные для рекламы.
• Многие советуют вообще не ставить подобные приложения или переходить на локальные/открытые альтернативы вроде Drip.
• Участники подчеркивают: пока не грозят тюремные сроки и миллиардные штрафы, поведение крупных платформ не изменится.

ArchWiki: опыт для Debian
На DebConf25 в Бресте мейнтейнеры ArchWiki Якуб Клинковский и Владимир Лаваллад рассказали, как устроена их вики. Debian уже запустил её переработку.

История и масштаб

• 2004: старт на PhpWiki, быстро переехали на MediaWiki.
• ~2010: появились команды техобслуживания и перевода.
• Сейчас >4 000 тематических страниц, почти 30 000 с учётом обсуждений и редиректов.
• 840 000+ правок от 86 000 редакторов; ежемесячно ≈2 000 правок от 300 активных участников.

Сильные стороны (SWOT)

• Полнота охвата: инструкции не только для Arch, но и для стороннего софта.
• Свежесть: rolling-release требует постоянных обновлений, и сообщество их делает.
• Внешняя полезность: даже Э. Сноуден отмечал, что «кроме ArchWiki найти толковую инфу трудно».

Как поддерживают качество

• Чёткие правила: руководство по стилю, шаблоны, категории.
• Главное — активное сообщество: большинство правок от обычных пользователей, а не команды.

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

iPhone DevOps — ультимативный вариант

Мечта кодить одной рукой на iPhone SE 2022 жива. Pythonista остался для мелких скриптов, но новые задачи потребовали другого стека.

Почему не Pythonista?
Сайт ProtoHackers заставляет писать TCP/UDP-серверы. iPhone не открывает порты, а хочется попробовать Go.

Стек

• Secure Shellfish — терминал с офлайн-папками: двусторонний rsync-обмен с VPS. Правишь файл в редакторе → возвращаешься в Shellfish → изменения мгновенно заливаются.
• Textastic — открывает «внешние папки» Shellfish. Поиск, замена, управление файлами. Баг: перед переключением тапни в файл, чтобы Textastic сохранил изменения.
• Working Copy — тот же «внешний каталог» для Git. Коммиты и пуши без консоли.
• VPS — любой Linux-докер (Contabo пока держится, домашний сервер тоже подойдёт).

Цена
Shellfish Pro, Textastic, Working Copy — всё платное, но удобство стоит вложений.

• iPad/iPhone остаются неудобными для разработки из-за закрытой iPadOS, отсутствия root и ограниченной виртуализации.
• На Android через Termux и KVM-виртуализацию можно получить полноценный Linux-терминал; пользователи JuiceSSH ищут современные альтернативы.
• Автор статьи и другие родители ценят «однорукую» разработку на телефоне, пока укачивают детей.
• Secure ShellFish, Working Copy, Pythonista и GitHub Codespaces позволяют кодить на iOS/iPadOS без ноутбука.
• Некоторые скучают по физическим клавиатурам (BlackBerry, Nokia N800, GPD Pocket) или мечтают о «телефоне-десктопе» с док-станцией.

Почему мы открыли исходники Zenobia Pay

С февраля мы строили альтернативу Visa/Mastercard на базе мгновенных банковских переводов FedNow: QR-оплата «как Pix, но для США». Система работает, но за полгода не нашла ни одного честного клиента — только мошенники и 20 000 $ убытков. Мы слишком молоды и не имеем нужных связей, поэтому выкладываем код, чтобы другие продолжили.

Чтобы запуститься, понадобится лицензированный банк-партнёр: Orum.io (теперь закрывается) уже не вариант, ищите Trice или Column.

Кому это нужно

Прошли три цикла поиска клиентов; продукт почти не менялся.

1. Малый бизнес
   Экономия 2 % комиссии почти удваивает прибыль при марже 3 %. Но:

   • нужна интеграция с POS (долго),
   • высокая поддержка при низкой выручке,
   • торговцы говорили «да», но при виде QR-кодов на телефоне тормозили.

2. Дорогие товары + страховка от чарджбэков
   QR-платежи не «сливаются», как карты, поэтому можно продавать страховку от мошенничества.
   Проблемы:

   • ACH-возвраты и 60-дневный риск потерять всю сумму,
   • мерчанты снова «заинтересованы», но не спешат,
   • новая кнопка «Pay with…» снижает конверсию: покупатели хотят кэшбэк по карте.

Ссылки на код

• iOS
• backend
• ядро

• Zenobia Pay закрылась: это пост-мортерн, а не анонс.
• Основная причина провала — «курица-и-яйцо» проблема: мало карт, мало магазинов, мало пользователей.
• QR-коды в США/Европе не прижились, а поведение потребителей консервативно.
• Высокие комиссии карт (2–3 % в США, 0,2–0,3 % в ЕС) вызвали споры: кто виноват — свободный рынок или регуляция.
• Некоторые предлагают альтернативы: Pix (Бразилия), UPI (Индия), Open Banking (Великобритания).

Palantir не покупает и не продаёт данные, не ведёт централизованную базу и не «майнит» интернет. Его ПО — это набор инструментов (Foundry, Gotham, AIP), которые:

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

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

Бывшие сотрудники признают: продукт сложен, конкурентов почти нет, а публичное описание сводится к «B2B-SaaS для работы с большими данными».

• Palantir — это дорогой консультационный сервис, продающий «волшебное» решение: инженеры-консультанты (FDE) собирают разрозненные данные клиента, чистят их и выдают красивые графики.
• Под капотом — графовая БД и инструменты визуализации, но основная ценность в ручной работе и высокой марже.
• Компания начинала как военный подрядчик (Афганистан, Ирак), помогая «ставить боеголовки на лбы», а теперь продаёт ту же платформу полиции и гражданским ведомствам.
• Критики называют это «фашизм как сервис» и инструмент тотальной слежки; сторонники покупают акции, ожидая роста государственных контрактов.
• Суть: если бы у заказчика была нормальная ИТ-архитектура, Palantir не понадобился бы — но государство готово платить налогоплательщиков за «волшебство».