Solar leads EU electricity generation as renewables hit 54% 💬 Длинная дискуссия
Солнечная энергия впервые стала крупнейшим источником электроэнергии в ЕС, достигнув 22% в июне 2025 года и обогнав атомную (21,6%) и ветровую (15,8%) генерацию. Во втором квартале 2025 года доля возобновляемых источников в общем объёме выработки достигла 54%, что на 1,3 процентных пункта выше показателей прошлого года. Солнечная энергия произвела 122 317 ГВт·ч, что составляет почти пятую часть всего энергосмешения.
Некоторые страны демонстрируют исключительные результаты: Дания лидирует с 94,7% ВИЭ в чистой генерации, за ней следуют Латвия (93,4%), Австрия (91,8%) и Хорватия (89,5%). Этот рост подчёркивает успех европейской энергетической трансформации и снижение зависимости от ископаемого топлива.
Комментарии (182)
- Обсуждается рост доли возобновляемых источников энергии (ВИЭ) в ЕС, особенно солнечной генерации, но отмечается, что общая картина энергопотребления сложнее и включает транспорт и отопление.
- Поднимаются вопросы о проблемах intermittency (непостоянства) ВИЭ, необходимости накопления энергии и ограничениях при достижении высокой доли солнечной генерации в энергомиксе.
- Участники спорят о причинах высокой стоимости электроэнергии в ЕС, связывая это с налогами, затратами на сеть и переходом на ВИЭ.
- Резко критикуется энергетическая политика Германии, в частности отказ от атомной энергетики и зависимость от российского газа и угля.
- Сравниваются показатели ЕС, США и Китая по темпам перехода на ВИЭ, при этом отмечается, что Китай одновременно активно строит угольные электростанции.
Clavier: An FPGA-based mechanical keyboard with USB hub and comms interfaces
Проект Clavier представляет собой механическую клавиатуру на базе FPGA, которая интегрирует USB-хаб и различные интерфейсы связи. Это позволяет не только набирать текст, но и подключать периферийные устройства напрямую через клавиатуру, что упрощает организацию рабочего пространства и снижает нагрузку на порты компьютера.
Использование FPGA обеспечивает гибкость в настройке и кастомизации, включая программирование клавиш, макросов и поддержку специализированных протоколов. Такой подход открывает возможности для экспериментов с аппаратным обеспечением и создания уникальных конфигураций под конкретные задачи.
Комментарии (31)
- Обсуждаются технические особенности FPGA-клавиатуры: выбор чипа (Lattice LFE5U-25F), его стоимость, причины отсутствия USB 3.0 и преимущества параллельной обработки сигналов без мультиплексирования.
- Участники спорят о целесообразности использования FPGA вместо микроконтроллера, отмечая сложность реализации сложной логики (макросы, слои) на VHDL против простоты QMK.
- Поднимаются вопросы безопасности: риски короткого замыкания из-за открытых контактов и сложность пайки BGA-компонентов.
- Обсуждаются инструменты проектирования: сравнение OpenSCAD и FreeCAD, а также альтернативы типа Cypress PSOC с упоминанием проблем с ПО.
- Затрагивается концептуальная идея проекта: создание чисто аппаратной, механической клавиатуры с минимальной задержкой и отсылками к телетайпам.
Newton: physics simulation engine built upon NVIDIA Warp
Newton — это открытый движок для физического моделирования с ускорением на GPU, построенный на основе NVIDIA Warp. Он предназначен для робототехников и исследователей в области симуляций, предлагая высокопроизводительные вычисления для задач, требующих точного и быстрого физического эмулирования.
Проект фокусируется на эффективности и доступности, используя современные графические процессоры для ускорения расчётов. Это позволяет исследователям быстрее тестировать алгоритмы и моделировать сложные среды, что особенно ценно в разработке робототехнических систем и научных экспериментах.
Комментарии (25)
- Критика выбора Python как основного языка для библиотеки из-за проблем с производительностью, ошибками и сложностью работы с типами.
- Негативная реакция на название "Newton Physics" из-за возможной путаницы с существующим движком Newton Dynamics и воспринимаемой arrogance авторов.
- Обсуждение технических деталей: использование MuJoCo как бэкенда, запись в CUDA graph для производительности, параллелизация множества сред для reinforcement learning.
- Сравнение с PhysX и мнение, что Newton Physics со временем его заменит, будучи более настраиваемым и расширяемым.
- Замечания о недостатках примеров кода, которые слишком высокоуровневы и не демонстрируют реальные преимущества и сложности использования API.
The RAG Obituary: Killed by agents, buried by context windows
RAG-архитектура, доминировавшая в AI последние три года, уступает место новым подходам. Ранние модели вроде GPT-3.5 ограничивались 4–8 тыс. токенов, что делало невозможной работу с объёмными документами — например, отчёт SEC 10-K содержит ~51 тыс. токенов. RAG решал это через разбиение текста на фрагменты (чанки) и поиск релевантных частей, но даже продвинутые методы чанкинга не спасали от потери контекста: финансовые таблицы, сноски и связи между разделами разрушались.
Современные модели с контекстом в миллионы токенов (например, Gemini 1.5) и агентные архитектуры делают RAG избыточным. Зачем извлекать фрагменты, если можно загрузить весь документ целиком? Это устраняет проблемы чанкинга, эмбеддингов и повторного ранжирования. Ключевой вывод: эра компромиссов между точностью и контекстом заканчивается — будущее за системами, работающими с полными данными без промежуточных шагов.
Комментарии (150)
- Участники критикуют автора за чрезмерное обобщение: утверждение о "смерти RAG" основано на узком примере поиска в коде и не учитывает масштабируемость и другие сложные use-case'ы (например, миллионы документов в распределенных системах).
- Подчеркивается, что RAG — это общий паттерн (извлечение информации + обогащение контекста), а не только векторный поиск; grep, SQL, API-вызовы или использование агента с инструментами — это тоже формы RAG.
- Отмечается, что агентный поиск (с использованием инструментов вроде grep, BM25 и др.) может быть мощнее классического RAG, но он медленнее, дороже и сложнее из-за множественных вызовов функций.
- Указывается, что большие контекстные окна LLM позволяют им читать целые файлы, что меняет workflow и снижает необходимость в сложных пайплайнах чанкинга и эмбеддингов.
- Многие видят иронию в том, что автор называет RAG "кошмаром edge-кейсов", в то время как агентный подход с инструментами вроде grep introduces свои сложности (производительность, безопасность, детерминизм).
Codeberg Reaches 300k Projects
Codeberg — это некоммерческая платформа для хостинга Git, ориентированная на свободное и открытое программное обеспечение. Управляется сообществом через организацию Codeberg e.V. в Берлине, что гарантирует независимость и приоритет общественных интересов над коммерцией. Платформа не отслеживает пользователей, не использует сторонние куки и размещает данные на собственных серверах в Европе.
На Codeberg размещено более 300 тысяч проектов, зарегистрировано почти 200 тысяч пользователей, а ассоциация насчитывает свыше 1100 членов. Платформа работает на Forgejo — свободном форке Gitea — и предлагает дополнительные сервисы, включая CI, статические страницы и инструменты перевода. Финансируется за счёт добровольных пожертвований и участия сообщества, подчёркивая принцип «свободно как свобода, а не как пиво».
Комментарии (56)
- Сравнение активности и приоритетов Gitea и Forgejo после форка, включая обсуждение их направленности на SaaS или самохостинг.
- Критика GitHub за эншиттификацию, навязывание ИИ и преимущества Codeberg как некоммерческой альтернативы с более отзывчивым интерфейсом.
- Обсуждение сетевых эффектов и инерции GitHub: сложность миграции из-за сообщества, интеграций (CI/CD, спонсоры) и привычности.
- Ограничения Codeberg: отсутствие приватных репозиториев, бюрократия с CI, простои из-за DDoS и политика только FOSS-проектов.
- Вопросы о функциональности Codeberg (развертывание, защита от сканирования ИИ) и предложения по федерации через Forgefed.
DuckDuckGo Donates $25,000 to The Perl and Raku Foundation v2025
Поисковая система DuckDuckGo второй год подряд пожертвовала 25 тысяч долларов Фонду Perl и Raku для поддержки развития языка программирования. Эти средства направляются в Фонд поддержки ядра Perl, который финансирует ключевые улучшения языка.
Среди недавних достижений — модуль builtin, система классов, лексические методы и стабилизация экспериментальных функций вроде сигнатур и try/catch. Разработчик Пол Эванс, получающий финансирование от фонда, внёс значительный вклад в эти нововведения. Многолетняя поддержка спонсоров позволяет фонду увереннее планировать будущее и продолжать работу над развитием Perl.
Комментарии (25)
- DuckDuckGo пожертвовала $25k проекту Perl в рамках благотворительных взносов на общую сумму $1.1M
- В сообществе ведутся дебаты о современной релевантности Perl, где одни отмечают его упадок после неудачи с Perl 6, а другие защищают его как мощный и полезный язык
- Участники делятся личным опытом работы с Perl, отмечая его влияние на их карьеру и сложности, такие как проблемы с версиями библиотек
- Perl продолжает использоваться в крупных компаниях (Craigslist, eBay) и проектах с открытым исходным кодом (OpenBSD)
- Обсуждается необходимость и способы поддержки open-source проектов через публичные пожертвования от брендов
Fossabot: AI code review for Dependabot/Renovate on breaking changes and impacts
Представлен fossabot — ИИ-агент для стратегического обновления зависимостей, который работает как инженер: исследует версии, оценивает влияние на приложение и адаптирует код при необходимости. В отличие от инструментов вроде Dependabot, которые делают минимальные обновления для исправления уязвимостей, fossabot способен на сложные мажорные обновления, требующие анализа рисков и преимуществ.
Доступен в публичном превью для JavaScript и TypeScript экосистем. Агент анализирует код на предмет совместимости, выявляет устаревшие методы и даже предлагает модернизацию синтаксиса. Пользователи получают $15 ежемесячного кредита. Ключевое преимущество — сокращение рутины и предотвращение застоя обновлений в бэклоге за счёт автоматизации стратегических решений.
Комментарии (13)
- Обсуждение возможностей ИИ для анализа безопасности и обновления зависимостей в кодовых базах, особенно в динамически типизированных языках.
- Отмечается сложность оценки миграций зависимостей из-за уникальности контекста каждой кодовой базы.
- Подчеркивается, что задача масштабирования глубокого статического анализа кода сложна и ресурсозатратна.
- Упоминается, что GitHub уже исследовал подобные подходы, но столкнулся с трудностями в достижении удовлетворительных результатов.
- Участники видят в этом перспективную нишу для ИИ-агентов из-за шаблонности задач и отсутствия строгих временных ограничений.
The best worst hack that saved our bacon
Когда платформа с двенадцатью годами данных календарных событий приблизилась к исчерпанию 32-битного целочисленного первичного ключа (лимит в 2,147,483,647 записей), команда столкнулась с критической проблемой: ключи были видны в публичном API, и их изменение могло нарушить интеграции клиентов, обновляемые университетскими IT-отделами с месячными задержками. Вместо рискованного немедленного перехода на BigInt было принято гениально простое, хотя и временное решение: перевести автоинкремент ключей в отрицательный диапазон, начав с -2,147,483,648, что удвоило доступное пространство и дало до трёх лет на миграцию.
Это позволило команде за 6–8 месяцев реализовать долгосрочное решение: переход на BigInt и сокрытие ключей как непрозрачных handles в API, чтобы избежать подобных проблем в будущем и защититься от атак перебором. Клиенты заранее получили документацию и примеры новых ответов API, что обеспечило плавный переход без сбоев. Хак, хотя и не идеален, стал образцовым примером осознанного технического долга — быстрого, временного решения с чётким планом устранения и минимизацией рисков для пользователей.
Комментарии (58)
- Обсуждаются проблемы перехода с 32-битных целых чисел (int) на 64-битные (bigint) в ID из-за риска нарушения работы интеграций, ожидающих определенный тип данных.
- Предложено решение использовать отрицательные значения ID для расширения диапазона без изменения типа, что может сломать код клиентов, ожидающих только положительные числа.
- Подчеркивается важность соблюдения контракта API (например, указания типа данных) и коммуникации с клиентами для минимизации disruption.
- Упоминаются потенциальные проблемы с монотонным увеличением ID и порядком коммита транзакций.
- Обсуждаются аналогичные проблемы, такие как проблема 2038 года с Unix-временем, и отмечается, что инженерные "байки" популярны среди специалистов.
Gmail will no longer support checking emails from third-party accounts via POP 🔥 Горячее 💬 Длинная дискуссия
С января 2026 года Gmail прекратит поддержку Gmailify и POP-подключений для сторонних почтовых аккаунтов. Gmailify позволял применять функции вроде защиты от спама и категоризации входящих к другим ящикам, а POP использовался для загрузки писем без синхронизации в реальном времени.
Вместо этого Google рекомендует использовать IMAP-подключения через мобильное приложение Gmail, которое поддерживает синхронизацию нескольких аккаунтов. Ранее импортированные письма останутся доступными, но новые настройки придётся обновить вручную. Это изменение направлено на повышение безопасности и переход на современные стандарты работы с почтой.
Комментарии (324)
- Пользователи выражают недовольство отключением функции POP3 в Gmail, которая позволяла получать почту с внешних серверов, что создает проблемы для миграции и резервного копирования.
- Предлагаются обходные пути: настройка пересылки (forwarding), использование IMAP через почтовые клиенты (например, Thunderbird) или переход на другие сервисы (ProtonMail, Zoho, самохостинг).
- Высказываются предположения о причинах отключения: монетизация через Google Workspace, борьба с рекламными блокировками в сторонних клиентах и общая стратегия «эншитификации» сервиса.
- Многие отмечают, что потеря POP3 ударяет по платным пользователям Google Workspace и усложняет использование дешевых почтовых хостингов с брендированными доменами.
- Обсуждение подчеркивает централизацию email-инфраструктуры вокруг крупных компаний и упадок децентрализованных протоколов.
Ask HN: Who is hiring? (October 2025) 💬 Длинная дискуссия
—
Комментарии (282)
- Компании ищут инженеров для работы с AI/ML, включая роли Senior Machine Learning Engineer, ML Scientist и разработчиков для создания AI-инструментов в различных областях, таких как биология, недвижимость и безопасность.
- Предлагаются позиции в software development, включая Full Stack, Backend, Frontend и MLOps инженеров, с использованием технологий Python, Kotlin, TypeScript, Rust и других, для удаленной, гибридной или офисной работы.
- Есть вакансии в сфере облачных технологий и инфраструктуры, такие как Cloud Engineer, SRE и DevOps, с фокусом на AWS, GCP, Azure и управление масштабируемыми системами.
- Несколько ролей связаны с разработкой в нишевых областях: квантовые вычисления, 3D-моделирование, финансовые технологии (алготрейдинг), видеоигры и управление цепочками поставок.
- Предложения включают позиции разного уровня, от начинающих до ведущих инженеров и архитекторов, с вариантами визовой поддержки, релокации и конкурентными зарплатами в диапазоне от $120k до $240k+ в зависимости от опыта и локации.