Open source *

Команда Rust рада объявить о новом выпуске Rust 1.95.0. Rust — это язык программирования, который дает каждому возможность создавать надежное и эффективное программное обеспечение.

Если у вас уже установлена предыдущая версия Rust через rustup, вы можете получить 1.95.0 командой:

$ rustup update stable

Если у вас еще не установлен Rust, вы можете получить rustup на соответствующей странице нашего сайта, а также ознакомиться с подробными примечаниями к выпуску 1.95.0.

Если вы хотите помочь нам, тестируя будущие релизы, попробуйте локально переключиться на beta-канал (rustup default beta) или nightly-канал (rustup default nightly). Пожалуйста, сообщайте о любых найденных ошибках!

Команда Rust рада объявить о новом выпуске Rust 1.94.0. Rust — это язык программирования, который дает каждому возможность создавать надежное и эффективное программное обеспечение.

Если у вас уже установлена предыдущая версия Rust через rustup, вы можете получить 1.94.0 командой:

$ rustup update stable

Если у вас еще не установлен Rust, вы можете получить rustup на соответствующей странице нашего сайта, а также ознакомиться с подробными примечаниями к выпуску 1.94.0.

Если вы хотите помочь нам, тестируя будущие релизы, попробуйте локально переключиться на beta-канал (rustup default beta) или nightly-канал (rustup default nightly). Пожалуйста, сообщайте о любых найденных ошибках!

Как взлом одного npm-аккаунта за 3 часа распространил RAT на 174 000 пакетов и почему стандартные инструменты вроде NPM Audit это не поймали. Разбираем инцидент с Axios: механику атаки, слепые пятна в CI/CD и то, что реально работает.

ИТ-компании продолжают выпускать чипы со все большим количеством кубитов в надежде прийти к полнофункциональному квантовому компьютеру. Однако работа с таким железом требует особого подхода, поэтому появляются специализированные языки квантового программирования. Сегодня мы в Beeline Cloud расскажем о нескольких таких проектах: Qrisp, Silq, Qutes, cQASM и Quantica — и зачем они нужны.

Среди открытых лицензий хорошо известны строгие (strong copyleft) GPL и (с другой стороны) разрешительные (permissive) — MIT, Apache. Однако менее известен слабый копилефт (weak copyleft), который находится между ними. А ведь эти лицензии имеют такие популярные приложения и библиотеки, как Mozilla Firefox, glibc, LibreOffice и другие.

Подходящий ли это вариант для интеграции открытого софта в закрытый ? И стоит ли авторам ПО с открытым кодом использовать лицензии слабого копилефта вместо разрешительных?

Привет, All!

Как вам идея, отказаться от тегов вообще и делать WEB-проекты исключительно на классах? А еще, чтобы и клиентский, и серверный коды шли рядом, как в десктопном приложении.И чтобы с одними и теми же переменными можно было работать и в PHP, и в JavaScript.

«Зачем?» — сапросит кто‑то. Отвечу: чтобы можно было строить не DOM‑элементы, а объекты предметной области бизнес‑процессов, которые автоматизирует мое приложение. И чтобы не тратить время на разные async, promise, ajax и так далее, пусть за это отвечает фреймворк!

Я говорю примерно вот о таком построении WEB-приложения:

Один из наших пользователей недавно пришёл к нам со знакомой проблемой: поиск внезапно стал заметно медленнее, хотя внешне ничего явно не ломалось.

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

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

К тому моменту, когда пользователи это замечают, настоящая проблема нередко копится уже несколько часов. Без хорошей видимости остаётся только гадать: система перегружена? Одна таблица съедает ресурсы? Или незаметно что-то идёт не так?

Вот почему мониторинг важен. С ним расплывчатое «поиск стал медленным» превращается в проблему, которую можно диагностировать и исправить.

В марте 2003 года небольшая компания SCO Group подала иск против IBM на $1 млрд, утверждая, что в ядре Linux находится украденный код операционной системы Unix. Дело быстро превратилось в один из самых громких технологических судебных процессов в истории. Сумма иска выросла до $5 млрд, к разбирательствам присоединились Red Hat, Novell, DaimlerChrysler и AutoZone. Исход дела стал поворотным моментом в истории открытого программного обеспечения.

Вы сделали open source проект. Потратили на него недели или даже месяцы: продумали архитектуру, аккуратно написали код, добавили нужные фичи. Даже сами начали им пользоваться.
А потом открыли GitHub… и ничего не произошло. Ни пользователей. Ни обсуждений. Ни pull request’ов. Иногда даже звёзды не появляются.

И в этот момент возникает вполне логичный вопрос:
“Что не так?”

Разбираем, что мешает проектам получать пользователей и контрибьюторов, и как это изменить.

Замучился искать 3D-модели с накаткой, поэтому заставил нейросеть поработать во FreeCAD.

Понял, что можно не рисовать чертежи часами, а получить результат, если передать задачу Клоду.

Моделировать по учебнику: эскиз, размеры, выдавливание и фаски. Это путь инженера-конструктора. В школе по физике тройка, а сопромат и расчет нагрузок — тёмный лес.
Здесь и возникает решение, а если модель не рисовать, а написать.

Раньше скачивал готовые STL-файлы, которые нельзя исправить. Стоило изменить диаметр или шаг сетки, как всё ломалось. Рисовать каждую ячейку в CAD-системах долго.

Я отдал эту рутину ИИ Claude Sonnet. Нейросеть пишет макрос на Python, который превращает FreeCAD в генератор.

Модель перестраивается мгновенно, когда меняются цифры в свойствах объекта:

Привет, Хабр!

Почему инженеры хотят делать новое, а неделя уходит на сопровождение, алерты и переключение контекстов? Поводом для этой статьи стали два материала, которые неожиданно сошлись в одной точке: доклад Романа Елизарова про опыт разработчика и отчет Chainguard Engineering Reality Report 2026. Мы сопоставили взгляд сильного практика и международные данные, чтобы понять, куда на самом деле утекает внимание инженерных команд и почему DX сегодня — это уже не про удобство, а про экономику внимания.

Claude слепой. К сожалению ни одна модель Антропиков не работает напрямую с видео.
Да, можно нарезать хоть на каждый кадр и скормить ему, но это не то. Контекст движения теряется, а без него это просто разбор кучи кадров на составляющие и попытка собрать контекст воедино.

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

И вот конкретная задача - 29 сгенерированных видео-референсов анимации персонажа лежат в папке проекта, надо их разобрать по категориям и описать каждое движение.
Вручную мне заниматься этим, конечно же, лень. Час-полтора времени на нудную задачу.

Тогда я вспомнил про Qwen Omni, которым уже пользуюсь для создания Цифрового риалтайм персонажа-ассистента. И подумал, а почему бы не подружить их.

Релиз nxs-universal-chart 2.8.3 был более двух лет назад и за это время многое поменялось: Ingress Nginx ушел на покой, GitOps по факту стал стандартом управления инфраструктурой, а AI все сильнее входит в наши жизни. Все эти изменения не могли пройти мимо и заставили нас задуматься о том, как адаптировать наши подход и технологии DevOps к вызовам нового времени.

Результатом этих размышлений стал релиз новой версия nxs-universal-chart v3.x: из универсального набора встроенных шаблонов мы постарались превратить его в модульную платформу для поставки приложений в Kubernetes с упором на надежность и современные практики CI/CD процессов.

Всем привет, на связи Пётр, инженер компании Nixys и по совместительству maintainer проекта nxs-universal-chart. В этой статье я расскажу как мы переработали изначальную идею и какие нововведения в чарте это за собой повлекло.

Принято считать, что костяк open source-движения находится на Западе, а другим странам отводится роль «догоняющих». Однако опыт Китая опровергает подобные представления. Страна стартовала в теме примерно на 20 лет позже США, но сегодня в одной только сфере LLM китайские открытые решения занимают больше трети рынка.

Мы в Beeline Cloud решили подготовить серию материалов, посвященных становлению китайского опенсорса — начиная с момента, когда дистрибутив Linux впервые попал на земли Поднебесной. В первой части поговорим о том, когда появились и чем занимались первые клубы любителей опенсорса, и как он «пустил корни» в академической среде.

Писать сложные диалоги в Telegram-ботах — это боль из вложенных if-ов, сломанных переходов и бесконечного рефакторинга. В этой статье — как мы вынесли всю логику визардов в JSON и сделали движок, который сам управляет шагами, условиями и навигацией.

Без спагетти-кода. Без привязки к платформе. С возможностью собрать рабочего бота за вечер.

На связи Сергей Скирдин, технический директор компании «Белый код». Поставил себе цель — сделать обзоры на шины данных из реестра отечественного ПО. Сегодня в обзоре Compo ESB.

С 2024 года я встречаюсь с вендорами и делаю обзоры продуктов, которые относятся к классу ESB. За это время удалось пообщаться с разработчиками 20+ разных решений. Для всех, кто интересуется шинами данных, я также создал сообщество в Телеграме «Шины не для машины». Это площадка для диалога между российскими разработчиками ESB и компаниями, которым нужна интеграционная шина.

Если вы делаете RAG-поиск по документации или базе знаний, то рано или поздно упираетесь в проблему: хорошо найти — это еще не хорошо ответить.

База знаний, RAG, найденные чанки, LLM строит ответ. Но пользователь не знает ни про DCG, ни про Recall@10, ни про чанки вообще. Он видит только то, что написано в итоговом ответе. А проблемы начинаются именно здесь: модель может что-то проигнорировать, ответить на другом языке, добавить что-то от себя или выдать уверенный текст с иероглифами посередине.

В прошлой статье мы разбирали, как улучшали сам retrieval: чанкование, метаданные, гибридный поиск, реранкинг. Но после того как с поиском более-менее разобрались, встал другой вопрос — как вообще понять, хороший ли ответ получает пользователь?

Привет, меня зовут Дима, я делаю ИИ-функции в Gramax. В этой статье расскажу, как мы выстроили методику оценки ответов RAG-поиска. Заодно поделюсь, какая модель прямо сейчас дает лучший результат на наших задачах.

OpenGrall — модульный фреймворк для роботов на LLM, который решает три главные проблемы «тормознутых» проектов: 1. LLM принимает решения только высокого уровня. 2. Сенсоры работают асинхронно, никто не ждёт «отстающих». 3. Массив данных структурируется в тщательно выверенный, короткий промпт с весами и возрастом. И другие решения насущных проблем. В статье: архитектура SensorMemory и WeightCalculator, реальные промпты, кэширование решений, эпизодическая память инструкций человека и автономное целеполагание. Всё на GitHub, работает на слабом железе и с LLM почти любых размеров.

Самый неприятный тип инцидента — когда база данных не падает полностью, а просто начинает работать медленнее.

Пользователи замечают это сразу. Жалобы начинают поступать. Технически всё по-прежнему работает, но явно что‑то не так.

И обычно самое сложное здесь не заметить проблему, а понять, что на самом деле происходит.

Иногда баг оказывается не ошибкой реализации, а ограничением API. Разбираем кейс из imageproc и image-rs.

Почему фикс оказался невозможен без изменения контракта библиотеки.