Привет, Хабр! В этой статье я расскажу про наш LLM инференс-кластер YADRO: зачем он нужен, что у него под капотом и как в такой конфигурации показывают себя популярные модели. Кроме того, я немного порассуждаю об альтернативных реализациях кластера и поделюсь планами по развитию реализации нашей.
27 июля 2025 года Линус Торвальдс представил релиз ядра Linux 6.16 под кодовым названием Baby Opossum Posse. Новый релиз вышел спустя два месяца после версии 6.15, строго по графику, и включает множество улучшений, оптимизаций и поддержку нового оборудования. Релиз Linux 6.17 ожидается в октябре 2025 года и станет основой для дистрибутивов, таких как Ubuntu 25.10 и Fedora 43. Исходный код Linux 6.16 доступен на kernel.org, а коммит релиза можно найти на GitHub и в Makefile.
В Linux 6.16 принято 15 924 исправления от 2 145 разработчиков, размер патча составил 50 МБ: изменено 13 793 файлов, добавлено 655 451 строк кода, удалено 316 441 строк. По сравнению с Linux 6.15 (15 945 исправлений, 59 МБ), изменения чуть менее объемные, но затрагивают ключевые подсистемы. Около 45% изменений связаны с драйверами, 16% — с архитектурным кодом, 13% — с сетевым стеком, 4% — с файловыми системами и 3% — с внутренними подсистемами ядра. Исходный код включает 38,4 миллиона строк в 78,4 тысячах файлов (по данным cloc).
Одновременно выпущено ядро Linux-libre 6.16-gnu, очищенное от несвободных компонентов. В нём нейтрализована загрузка блобов в новых драйверах, таких как Intel QAT 6xxx crypto, ST vd55g1 sensor, ath12k AHB WiFi, Aeonsemi AS21xxx и MediaTek 25Gb Ethernet. Также обновлена чистка блобов в драйверах Nova Core, Nouveau, Realtek r8169 Ethernet, Qualcomm Iris, Venus, Mediatek mt7996 WiFi, Qualcomm ath11k и ath12k WiFi, Texas Instruments tas2781 и Renesas R-Car gen4 PCIe.
Для сложных продуктов характерен длительный цикл продаж с участием разных отделов. Без системного контроля легко упустить сроки или забыть связаться с клиентом. Показываем, как решили эту задачу путем создания единого цифрового контура для управления продажами химического сырья.
Искусственный интеллект развивается стремительно, новые LLM становятся быстрее, универсальнее плюс менее требовательными к ресурсам. Среди ключевых новинок последнего времени — Grok 4 от xAI, модель Chimera от DeepSeek, а еще открытый проект от ETH Zurich и EPFL, обещающий поддержку более 1 000 языков. Эти разработки отражают три важных тренда: ускорение локальных моделей, расширение мультиязычности и стремление открытых решений догнать проприетарных лидеров. Давайте обсудим новинки и попробуем понять, куда движется индустрия.
Если бы вы вдруг переместились в середину восьмидесятых годов и спросили у какого-нибудь человека в солидном костюме и с портфелем, как он планирует свои дела, вряд ли он ответил бы вам что-то про электронных секретарей или искусственный интеллект. Тогда всё держалось на бумажных ежедневниках, рассованных по карманам записках и желтых стикерах, которые можно налепить на стену над рабочим столом. Но именно в эту эпоху появилась по-своему уникальная и почти забытая сегодня программа — Lotus Agenda. Её называли слишком сложной и чересчур умной: ведь именно она первой попыталась научить компьютер разбирать хаотичные заметки, связывать их смыслы и напоминать о предстоящих событиях — задолго до того, как появились первые КПК и смартфоны с интеллектуальными бизнес-планировщиками.
Как часто вы запускали какую-нибудь штуку в терминале — и она зависала навсегда? Или наоборот: вам нужно было увидеть, как что-то меняется каждую секунду, а вы упорно жали стрелку вверх и Enter? А может вы хотели запланировать задачу через 5 минут, но cron — это уже overkill?
Для всех этих сценариев в Linux есть три проверенных утилиты: timeout, watch, at. И, да, можно было бы обойтись скриптами и велосипедами, но... мы же не зря используем Unix-подход, где всё уже давно придумано.
Сегодня мы рассмотрим: как управлять временем выполнения команд в Linux с помощью timeout, watch и at.
Когда в 2006 году вышел фильм Майка Джаджиса, его посчитали слишком глупым, чтобы быть гениальным. Сегодня он воспринимается как пророчество, выполненное в формате чёрной комедии. Но ключевой вопрос:
Мы движемся к Идиократии — или уже в ней?
Представьте: квадрокоптер летает в ангаре, на складе или в квартире. GPS не ловит, а барометр и гироскоп дают дрейф в позиции. Что остаётся?
Ну хорошо, ну есть у нас ИИ. Уже как 3 года он есть. А толку? Как его правильно впихивать в техпроцесс?
- Меня не надо впихивать!
- ЧЕМ ТЫ ЭТО СКАЗАЛ?
Дарова! Сегодня я поделюсь с вами опытом, как я пытался написать собственную ОС и, что из этого вышло. Запасайтесь чайком с печеньками и присаживайтесь поудобнее! Пора окунуться в 16ти битный мир...
Эта статья для тимлидов, которые столкнулись с тем, что в их команде появились более опытные разработчики, чем они сами. Поговорим, почему это хорошо и как этим управлять.
Нейросети уже пишут книги, рисуют картины и сочиняют музыку. Но кто получает авторские права на эти произведения? Может ли ИИ быть автором? Законодательство пока не успевает за технологиями, и это создаёт правовую неразбериху. Разбираемся, как защитить свои права и не нарушить чужие в эпоху нейросетей.
Знакомы с мучительным ступором перед пустым полем «Заголовок»?
Помните Дэвида Огилви — «отца рекламы»? Он утверждал, что 80% читателей видят только заголовок. Вы вкладываете часы, а у вас есть секунды, чтобы зацепить взгляд читателя. Если заголовок провалился — ваш шедевр, каким бы гениальным он ни был, канет в Лету новостной ленты или поисковой выдачи. Это как потратить годы на строительство роскошного ресторана, но повесить на дверь вывеску «Еда здесь».
Эта проблема мучает блогеров и копирайтеров, маркетологов и разработчиков (кто писал документацию или release notes — поймёт), предпринимателей и даже студентов, защищающих диплом. Заголовок — это не просто текст. Это визитная карточка вашего продукта в мире переизбытка информации.
Сегодня я подобрал для вас несколько очень хороших и интересных продуктов для работы с текстом, специализирующихся на генерации заголовков или включающих в себя эту возможность. Я провёл тесты, охватывающие большинство пострадавших от перегрузки нашего инфополя. 3 запроса, 3 группы — 5 нейросетей. Начнём!
Мое рабочее место прошло шесть реинкарнаций — от ноутбука на столике в кафе до полноценной кастом‑студии с видом на Волгу. Мой текст — о том, как эволюционировало рабочее пространство вместе с карьерой.
Это личный опыт — со всеми взлетами и падениями, граблями, решениями «на коленке» и переоценками. Но в конце я добавил конкретные советы, которые помогут улучшить ваше рабочее место уже сегодня — даже если вы сейчас пишете код между диваном и сушилкой для белья.
Читая состав продукта в магазине, мы часто ужасаемся напечатанному с задней стороны набору слов. У нас промелькает мысль (с явно негативной окраской): «да тут одна сплошная химия». Такая житейская неприязнь ко всему химическому объясняется простым отвращением к неестественному и сложному. Смотря на названия перфторан, метилпреднизолон, сульфасалазин, становится как‑то не по себе.
(для справки: это незаменимые фармацевтические препараты, без которых не обходится лечение некоторых серьезных заболеваний и травм. Например, перфторан — это временный искусственный заменитель крови с функцией газообмена)
Забавно, но подобная ситуация наблюдается и в сфере, оторванной от бытовых вопросов — в сфере венчурных инвестиций. Конечно, нельзя переносить обыденное на корпоративное и говорить, что поголовно все управляющие фондов ненавидят и презирают химию. Ведь если это может приносить деньги, то все равно, что это. Но реальность такова: смотря на статистику капиталовложений и отчёты фондов, складывается впечатление, что химия буквально избегается (не просто так). Химические стартапы получают «мизерные» деньги при необходимости огромных затрат на запуск проекта.
Однако и этому есть простое объяснение (как и в случае с «житейской неприязнью»). Вкратце: долго и сложно. Несмотря на инновационность и необходимость исследований в химии и их дальнейшую коммерциализацию с потенциальными «иксами».
Разберем поподробнее. Отличительною особенностью запуска химического стартапа является гиперфокус на R&D (Research and Development/НИОКР). Разработка и изучение молекулы, материала занимает много времени. Для R&D нужны реагенты, оборудование, лаборатория, да и химики, в конце концов. И это всё совсем недешево. К примеру, хроматограф (базовый аппарат для анализа вещества) стоит от двух миллионов рублей.
Команда Spring АйО представляет одну немаловажную фичу Java 25: компактные заголовки объектов (Compact Object Headers). Это позволит JVM экономить память и ускоряться без вмешательства в код.
Когда задачи есть, а движения — нет
Команда работает.
Задачи в трекере стоят.
Стендапы идут, код пишется, обсуждения кипят.
А результата всё нет.
Нет чувства прогресса, нет ощущения, что продукт становится ближе к релизу.
Итерации проходят одна за другой — а продукт будто топчется на месте.
Эта статья — попытка ответить на извечный вопрос «когда?», а так же размышления на тему нужно ли его задавать, и нужно ли на него отвечать. Пригодится тем, кто выполняет проектную работу (на случай важных переговоров) и их заказчикам.
Есть сроки виртуальные, а есть сроки реальные. Виртуальные — это те сроки, которые вам пытаются продать. Которые обещают. Даже если их прописывают в договоре, всё равно это некий прогноз, гипотеза о будущем. Которую всегда можно переиграть, объяснив, почему не получилось.
Виртуальные сроки обычно называют не те, кто будет делать непосредственную работу, а менеджеры и продажники. И цель их в первую очередь — продать. Сделать так, чтобы вам понравилось их предложение и вы захотели купить, заключить договор, внести предоплату. А что будет дальше — это проблемы будущих нас. К тому же чем дальше, тем сильнее вы будете связаны с исполнителем, больше от него зависеть и больше ошибок ему будете готовы прощать. Потому как сами уже затратили своё время, деньги и силы на коммуникацию и притирку, плюс становится всё более лень искать новых, и не факт ведь что те будут лучше.
Поэтому задача продажников и менеджеров на первом этапе, это озвучить те сроки, которые вы захотите услышать. Объявить коммерческое предложение, которое будет выглядеть лучше, чем предложения других исполнителей. Ещё не началась работа и сопутствующие проблемы, а сроки уже начали расходиться с реальностью.
Для менеджера главное — не «пообещать и сделать», а «управлять ожиданиями». А ведь и заказчикам нужно то же самое. Главное сейчас — чтобы им что‑то пообещали. А могут это выполнить или нет, обоснованы ли сроки, и вообще есть ли полная информация, чтобы их посчитать — это уходит на второй план. Зато в моменте вы успокоитесь потому что всё под «контролем». А потом уже будет «возникли новые обстоятельства», «задача оказалась чуть сложнее, чем мы предполагали», «мы не учли некоторые моменты, извините», это всё потом. А сейчас win‑win. То, что вы хотите слышать, совпадает с тем, что говорят вам менеджеры.
Привет, Хабр! Меня зовут Женя Шмидт, я менеджер продуктов информационной безопасности в Selectel. Представьте: вы получили письмо с темой «Специальные условия для сотрудников компании» и файлом во вложении. Отправителем значится ваш работодатель.
Вы кликаете на документ, но вместо бонусов и скидок получаете шифровку всех файлов, сохраненных на компьютере. Это вирус-шифровальщик, а отправил его злоумышленник, который сделал почтовый адрес, почти идентичный с адресом компании... Как с этим справиться? Подробности под катом.
Привет, Хабр. Меня зовут Роман Ескин, я один из C разработчиков проекта Greengage DB. В этой статье я расскажу, как мы реализовали и протестировали lock-free подход в рамках масштабной работы по внедрению функции удаления брошенных файлов. Приглашаю вас заглянуть во внутреннюю кухню работы нашей команды при оценке этой функциональности.
Введение
Позвольте начать с краткой исторической справки: Greengage DB был запущен в 2024 году как open-source форк Greenplum — Massively Parallel Processing (MPP) аналитической системы управления базами данных, основанной на PostgreSQL. Мы начали этот проект, чтобы поддержать open-source сообщество Greenplum, который неожиданно стал проприетарным продуктом в мае 2024 года. Мы гарантируем дальнейшее развитие Greengage DB, следуя принципам открытости и прозрачности.
Так как Greengage DB основан на PostgreSQL, он унаследовал некоторые его известные особенности и проблемы. Одна из таких проблем, особенно актуальная в распределенных средах — это проблема "брошенных файлов" (orphaned files).
Эта проблема возникает, когда таблица создается и данные загружаются в рамках активной транзакции. Если происходит критический сбой до того, как транзакция будет закоммичена или отменена (например, внезапное отключение питания или неожиданное завершение работы узла базы данных), система проходит процесс восстановления после падения (crash recovery). При этом логическая таблица откатится, но физические файлы данных, связанные с этой незакоммиченной таблицей, могут остаться в файловой системе. Со временем такие брошенные файлы могут накапливаться, занимая место и приводя к ненужному расходу ресурсов. В настоящее время их удаление происходит вручную.
Недавно мы представили новый функционал, который позволяет автоматически удалять такие брошенные файлы. Полная информация об этой возможности доступна в статье Удаление брошенных файлов в Greengage DB.
