Hacker News Digest

DuckDB v2.0, codenamed «Cyanoptera», выходит этим осенью и представляет набор кардинальных изменений: серверный режим через расширение quack и оператор CONNECT, новый SQL‑парсер, переработанную СУБД‑структуру, асинхронный ввод‑вывод и тип VARIANT. Серверный режим позволяет любой процессу DuckDB обслуживать базы данных по сети, а клиентские запросы можно отправлять напрямую на удалённый PostgreSQL или MySQL без копирования данных. Кроме того, в v2.0 введены триггеры, более строгая типизация и поддержка транзакций в многопользовательском режиме, что делает DuckDB конкурентоспособным для аналитических и даже транзакционных нагрузок.

Ключевые нововведения: серверный режим (quack + CONNECT), новый тип VARIANT для гибкого хранения схем, асинхронный I/O ускоряющий запросы, новая хранилище‑формат с улучшенной компрессией, а также новый C‑API и небольшие, но важные ломающие изменения (переход на lambda‑синтаксис). В статье также упоминается создание DuckDB Foundation Advisory Board, который будет влиять на дальнейшее развитие проекта. Эти изменения формируют фундамент для «года DuckDB как сервера» и открывают путь к масштабным распределённым решениям.

DuckDB v2.0 трансформируется из локального аналитического процессора в основу облачной аналитической инфраструктуры, что подтверждено использованием в продакшене: многотенантные системы с данными 5–150 ГБ на тенанта, обработка миллионов Parquet-файлов, замена серверных решений. Он превосходит PostgreSQL и MariaDB в OLAP-задачах благодаря колоночному хранению и встроенному процессу, но уступает в многопользовательской конкурентности без Quack. Поддерживает обработку данных, превышающих ОЗУ, на потребительском оборудовании, снижая требования к инфраструктуре. Асинхронный ввод-вывод в v2.0 критически важен для масштабной работы с Parquet и обеспечивает значительный прирост производительности. WASM-сборка весит ~10 МБ, пригодна для браузера; расширения не увеличивают размер бинарников существенно. Заменяет сложные ETL-пайплайны, позволяя объединять запросы к CSV, Parquet и базам данных в одном SQL-интерфейсе. Стандартная практика — анализ лог-файлов (например, Nginx access.log) на диске. Рекомендации: - Использовать Arc для ускорения сканирования через pruning при работе с Parquet. - Для расширений применять официальный шаблон extension-template. - Ручная настройка memory_limit необходима для предотвращения убийства OOM-killerом. - При аналитике в браузере кастомизировать Emscripten-сборку — она оптимизирована, но требует настройки. - Документировать новый PEG-парсер — его детали критичны для совместимости. Quack (серверный режим) и CONNECT к PostgreSQL делают DuckDB гибридным инструментом, интегрируемым с OLTP-системами. Споры: - Некоторые считают DuckDB неподходящим для распределённой обработки против AWS Athena с Trino, но Quack и DuckLake меняют эту динамику. - Одни выражают разочарование, что DuckDB не переписан на Zig, другие не видят в этом проблемы.

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

Я помню, как в 2000‑х годах я мог вставить картридж Game Boy и сразу играть, не требуя интернета. Сегодня даже «ваша» игра хранится в облаке и зависит от серверов. Поэтому многие, как я, всё чаще переходят на ПК, где доступ к играм менее подвержен сбоям.

Запомните: если консоль отключается от сети, вы теряете доступ даже к играм, которые «владеете» на диске. Это не просто неудобство — это потеря контроля над тем, что вы купили.

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

На сервере в подвале, построенном из старого хранилища HP с двумя процессорами Xeon E5‑2690 v2 (Ivy Bridge, 2013) и без видеокарты, запущена открытая модель Gemma 4 26B‑A4B в квантовании Q8_0 и генерирует текст со скоростью около пяти токенов в секунду. Оборудование стоит менее трёхсот долларов, использует лишь AVX1, а не более новые AVX2/FMA3, и работает на DDR3‑памяти. Это удалось благодаря модификации проекта ik_llama.cpp, где убраны зависимости от AVX2 и добавлены fallback‑пути, позволяющие модели работать на пред‑AVX2 процессорах. Автор оригинального форка опирался на специфические оптимизации, но их пришлось обойти, перепаковав веса и отключив run‑time‑repack. Декодирование со скоростью около 5,2 токенов в секунду, оценка промпта — около 16 токенов в секунду. Чтобы запустить, собрать ik_llama.cpp без --run-time-repack и с отключённым GGML_USE_IQK_MULMAT, чтобы избежать зависимостей от AVX2. Это показывает, что даже железо, вышедшее из эксплуатации десяти лет назад, может стать сервером генерации, если правильно подобрать компиляцию и параметры.

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

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

• Запуск больших моделей на старом железе без GPU возможен, но скорость генерации токенов может быть низкой (5-9 токенов/секунду).

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

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

• Использование inference провайдеров может быть более экономически эффективным, чем запуск моделей локально на старом железе.

• Спор: Некоторые участники считают, что прогресс в области моделей и железа позволит запускать более крупные модели на более старом железе в будущем.

How are the thermals? I noticed that running any serious workload locally heats system fast. — @haute_cuisine

В проекте на GitHub «riddle» создатели превратили ремарк‑планшет Paper Pro в дневник Тому Ридла: каждый ваш штрих «поглощает» страницу, а система мгновенно отвечает в плавном каллиграфическом почерке. За счёт интеграции с языковой моделью, ввод с стилуса преобразуется в текст, который модель переводит в ответы, а затем рендерит как будто написанные пером, сохраняя динамику и эмоцию.

Технически проект захватывает траектории пера через API ремарк‑устройства, передаёт их на сервер, где нейросеть генерирует ответы в стиле Тому Ридла и преобразует их в векторный курсивный шрифт, имитирующий его плавный почерк. Ответы поддерживают до 200 символов, позволяя задавать сложные вопросы и получать развернутые реплики. Открытый код репозитория дает возможность склонировать, настроить модель под свой стиль и экспериментировать с подсказками. В результате пользователь получает живой «разговор» с персонажем, который «пишет» ему обратно, словно чернила оживают, а оформление в элегантном курсивном шрифте напоминает письма из «Гарри Поттера». Такой подход превращает цифровой ноутбук в интерактивный дневник, способный вести диалог в викторианском стиле, и оставляет неизгладимое впечатление, и открывает новые возможности для творческого взаимодействия.

• Проект превращает reMarkable в «дневник Тома Ридла», используя локальную модель LLM, выводящую текст на бумагу.
• Пользователи отмечают интерес к новому способу взаимодействия без экрана и клавиатуры, но критикуют отсутствие демо‑видео и «мгновенный» стиль письма.
• Некоторые сравнивают проект с «мрачным» стилем книги и с «хагрид‑эффектом», другие видят в нём лишь рекламный трюк.
• Обсуждение включает вопросы о практической ценности, необходимости SDK и возможностях дальнейшего развития на e‑ink устройствах.