Hacker News Digest

Neki — шардированный Postgres от создателей Vitess.
Vitess уже масштабирует MySQL для сотен тысяч пользователей; теперь та же мощь переходит к Postgres.

Neki не форк Vitess. Мы строим с нуля, опираясь на опыт работы в экстремальных нагрузках, и откроем проект как open-source, когда он будет готов к самым требовательным задачам.

Следите за новостями и регистрируйтесь на neki.dev.

• Пользователи обсуждают анонс PlanetScale о «Vitess для Postgres», но код ещё не выложен, что вызывает скепсис.
• Всплывает конкуренция: Supabase уже работает над своим проектом Multigres, а автор Vitess, Сугу Сугумаран, теперь в Supabase.
• Вопросы о самостоятельном хостинге, необходимости шард-ключей и сравнении с YugabyteDB, CockroachDB и другими «PostgreSQL-совместимыми» решениями.
• Некоторые считают, что PostgreSQL устарел и нуждается в замене; другие отмечают, что сам PostgreSQL постоянно эволюционирует.

• Kilo превысил 1 трлн токенов/мес в OpenRouter; Cline, Roo, Kilo растут из-за дросселирования Cursor и Claude.
• Стартапы рассчитывали: себестоимость токенов упадёт на 90 % за год, маржа станет +80 %.
• Вместо этого цена токенов фронтир-моделей не упала, а расход токенов на задачу вырос.
• Причины: модели стали крупнее, появились «длинные мысли» и агенты, которые запускают цепочки вызовов.
• Итог: расход на разработчика уже $20–40 к/мес и стремится к $100 к/год.

• Почти все участники считают цифру в $100 000/год на разработчика безосновательной и преувеличенной.
• Основной аргумент: стоимость инференса либо быстро упадёт, либо станет дешевле запускать opensource-модели локально.
• Многие отмечают, что уже сейчас $100–200/мес хватает большинству, а при росте нагрузки выгоднее купить железо, чем платить за облако.
• Поднимается тема «токеномики»: расходы растут из-за параллельных агентов и увеличения контекста, но это пока не дотягивает до $100 000.
• Часть комментаторов указывает, что крупные компании вряд ли вернутся к on-prem, а будут торговаться за долгосрочные контракты у дешёвых провайдеров.

Проблема: модель gpt-oss-20b.gguf не запускается в Ollama.
Симптом: при попытке ollama run процесс зависает на 0 % и через минуту падает без явной ошибки.

Окружение:

• Ubuntu 22.04, 64 ГБ ОЗУ, RTX 4090
• Ollama 0.3.6 (AppImage и Docker)
• Файл gpt-oss-20b.q4_0.gguf взят из официального репозитория TheBloke, 11 ГБ

Лог:

ggml_cuda_init: found 1 CUDA device
llama_model_load: error loading model: missing tensor 'token_embd.weight'
llama_load_model_from_file: failed to load model

Причина: в GGUF-файле отсутствует обязательный тензор token_embd.weight.

Решение:

1. Перекачать модель (curl -L -o gpt-oss-20b.q4_0.gguf …) и проверить хэш.
2. Если проблема сохраняется — использовать другой квант (q4_K_M или q5_0).
3. Либо конвертировать оригинальные веса самостоятельно через llama.cpp/convert.py.

• Ollama отказалась от llama.cpp в пользу собственной обвязки над ggml, что ломает совместимость с GGUF-моделями и вынуждает «переизобретать велосипед».
• Пользователи жалуются на проприетарные квантизации, отсутствие поддержки шардированных GGUF > 48 ГБ и игнорирование upstream.
• Альтернативы: запуск llama-server напрямую или готовые контейнеры Ramalama / Docker Model Runner.
• Сторонники Ollama отмечают удобство установки и готовые модели, но критики считают это «эншитификацией» и подготовкой к монетизации.

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

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

Организационная память исчезает быстро: без практики знания уходят. Экскурсоводы Бодлианской библиотеки с трудом узнавали имена на портретах 30-летней давности, хотя библиотека создана для сохранения информации.

Volkswagen дважды обманул тесты по выбросам: в 1973-м и 2015-м. Компания «забыла» первый урок и заплатила €30 млрд.

Катастрофы шаттлов Challenger (1986) и Columbia (2003) произошли по схожим причинам: NASA снова проигнорировала предупреждения инженеров. Организация забыла собственные ошибки.

Потеря памяти — не только про крупные провалы. Организации забывают, как работать.

• Рост компании до 1 500–2 000 человек разрушил долгосрочное доверие и экспертизу: «память» ушла с людьми.
• Примеры из железных дорог, каналов, авто- и ПО-проектов показывают, что разовые крупные проекты теряют знания, тогда как непрерывная работа их сохраняет.
• Консультанты и внешние подрядчики не заинтересованы передавать знания, поэтому каждый новый цикл начинается с нуля.
• Документация важна, но не заменяет живых людей и культуры передачи «фольклора» внутри команды.
• Постоянные сокращения и ротация кадров превращают организации в «больных Альцгеймером»: память стирается, а новую не формируют.

Wikimedia Foundation проиграла судебный спор против положений Закона об онлайн-безопасности, требующих от крупных платформ верификации личности пользователей. Фонд утверждал, что это подвергает риску безопасность и права добровольных редакторов Wikipedia, но Высокий суд отказал в иске.

Суд подчеркнул, что Ofcom и правительство обязаны защитить Wikipedia. Правительство приветствовало решение, заявив, что оно поможет внедрить закон и сделать интернет безопаснее.

Иск касался классификации Wikipedia как «категория 1» — самый строгий уровень регулирования, изначально предназначенный для крупных соцсетей. Wikimedia считает, что правила слишком широкие и логически не выдержаны.

• Высокий суд отклонил иск Wikimedia против обязанностей Category 1 в UK Online Safety Act, что ставит под угрозу работу Wikipedia в Великобритании.
• Участники считают закон чрезмерным: он затрагивает даже сайты без рекомендательных алгоритмов и может привести к обязательной верификации пользователей.
• Многие предлагают Wikipedia просто заблокировать доступ из UK, чтобы продемонстрировать последствия закона и вызвать общественный резонанс.
• Обсуждаются и практические вопросы: имеет ли Wikimedia активы или сотрудников в UK, и как реально будет наложить штрафы, если организация проигнорирует требования.

Markdown — это просто макросы: вместо тегов пишем **жирный**, а получаем <strong>жирный</strong>.
На моём сайте 6 000 файлов .md; сервер обрабатывает их через Markdig и отдаёт готовый HTML.

Плюс Markdown позволяет вставлять «сырой» HTML:

**Жирный!**  
<img src="pic.jpg">  
*Курсив!*

Парсер пропускает теги, и всё работает. Это «лазейка» была одной из причин успеха формата.

Но что, если нужно вставлять сложные, повторяющиеся блоки — формы, калькуляторы, табы?
Писать каждый раз длинный HTML неудобно.

Custom Elements (часть Web Components) решают задачу:
в разметке пишем короткий тег <my-widget>, браузер заменяет его на полный DOM-узел.
Получаем HTML-макросы, которые Markdown не трогает.

Итого:

• Markdown → форматирование текста.
• Custom Elements → всё остальное.

• Участники обсуждают разные генераторы статических сайтов и форматы разметки: Astro, MDX, Markdoc, Vitepress, Markdig, Nuxt Content.
• Основной фокус — как совместить Markdown с компонентами (React/Vue/Web Components) для документации и статических сайтов.
• Некоторые делятся опытом: кто-то использует Astro + MDX, кто-то — Markdoc от Stripe, кто-то — собственные скрипты или кастомные элементы.
• Поднимаются плюсы и минусы: простота для редакторов, проблемы с Web Components, риск «dependency rot» при серверной обработке.
• В целом, все ищут «золотую середину» между простотой Markdown и мощью компонентов.

• @bravesoul2 и @genghisjahn: фокусируйтесь не на коротких «челленджах», а на системе привычек и новом образе жизни без «наград» за «хорошее» поведение.
• @romesmoke и @yardshop: не превращайте советы в тиранию; пропуски случаются, и это нормально.
• @coyotespike и @xyst: текст выглядит как типичный вывод ChatGPT, а идеи — как старые плагиаты.
• @darth_avocado: проектируйте среду, чтобы здоровые решения были проще (не покупать мороженое, убирать телефон).
• @rufius: цикл OODA — полезный аналог для постоянной переориентации в жизни.

• Участники не могут предсказать, как будет выглядеть индустрия через три года: все модели развиваются слишком быстро.
• Одни считают Cursor просто «обёрткой» над Claude, другие подчеркивают его уникальные фичи (визуальный интерфейс, история, автодополнение).
• Статистика показывает, что Claude Code обгоняет Cursor по популярности, но Cursor всё ещё опережает в автодополнении кода.
• Многие сомневаются в устойчивой прибыли Cursor из-за «всё-включено» модели и высоких токен-расходов.
• Обсуждается, что «обёртка» может стать «настоящей компанией», если создаст собственные технологии и моаты.

• GitHub теряет независимость: уходит CEO Томас Домке; платформу переводят в состав CoreAI — новой инженерной группы Microsoft по ИИ.
• Причина: Microsoft хочет ускорить интеграцию GitHub-сервисов (Copilot, Models) в экосистему Azure и Office.
• Что меняется: GitHub больше не будет дочерней компанией; команды перейдут под руководство вице-президента по ИИ Джейсона Ханджера.

• GitHub переходит под полное управление команды CoreAI Microsoft, что символизирует конец «крутого» периода Microsoft и независимости GitHub.
• Пользователи опасаются, что акцент на AI приведёт к деградации качества и навязыванию продуктов Microsoft.
• Многие уже рассматривают альтернативы: GitLab, Codeberg, Forgejo, SourceHut, Tangled и другие.
• Сообщество критикует GitHub за снижение стабильности, навязчивую интеграцию Copilot и отсутствие прозрачности.
• Наблюдается общее разочарование AI-хайпом и желание вернуть фокус на надёжные инструменты разработки.