Ранее я не раз затрагивал на Хабре тему древнего марсианского климата, и эта тема пришлась сообществу по вкусу. Считаю, что наиболее интересными получились статьи «Удушливые озёра гесперийского периода. Модели углекислотной гидросферы Марса» (+57), «Последнее лето Марса» (+60) и «Когда Олимп был островом» (+37). Определённо, вам доводилось читать, что рельеф и осадочные породы Марса, к настоящему времени изученные роверами в разных регионах планеты, указывают, что ранее климат на этой планете был значительно более тёплым и влажным, чем сегодня.

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

Это несоответствие, впервые отмеченное в середине 1970-х, великий астроном Карл Саган сформулировал как «Парадокс слабого молодого Солнца» (Faint Young Sun Paradox). Под катом будет подробнее разобран данный парадокс, а также проанализированы некоторые версии, призванные его объяснить.

В поддержку Mindbox ежегодно поступает более 50 000 обращений. Чтобы справляться с таким потоком, требуется 16 специалистов поддержки. Они разбирают документацию, находят ответы и помогают клиентам.

Чтобы отвечать быстрее и упростить работу поддержки, мы решили ее автоматизировать. Всего за три месяца нам удалось выстроить рабочий алгоритм, собрать базу знаний из десятков тысяч материалов и запустить MVP. 

Теперь бот закрывает 15–20% запросов и отвечает за 25 секунд. Нагрузка на команду поддержки снизилась, а удовлетворенность клиентов (CSAT) AI-помощником поддержки составила около 90%. В этой статье — кейс, как нам удалось сделать такого бота своими силами. 

Проброс USB по сети часто нужен в виртуальных средах. В 1С нужно пробрасывать USB ключи лицензирования, для VDI токены налоговой и все это тоже нужно импортозамещать в Linux. Вот только то, что просто делается в Windows - в Linux превращается в спецоперацию с далеко идущими последствиями.

Обожаю игры серии GTA (все, кроме четвертой части). Я бы даже сказал, что многое в них прекрасно: разнообразие сюжетных миссий, выбор транспорта, классные диалоги, тонкая ирония, саркастичный юмор, высмеивание проблем общества, свобода действий, возможность устроить локальный апокалипсис. Однако все это портит поведение ботов-водителей, которые словно намеренно бросаются наперерез игроку, чтобы усложнить ему жизнь. Но так ли это? Действительно ли поведение NPC на дорогах GTA заскриптовано так, чтобы мешать геймерам? Прошу под кат — в поисках правды будем подглядывать за ботами и залезать туда, куда Рокстары не хотят нас пускать.

В школе нам рассказывают, как Солнце согревает Землю и делает возможной жизнь. Эта идея остаётся с большинством из нас на всю жизнь. Но когда мы хотим разобраться в том, как и где может существовать жизнь, мы узнаем, что у Земли есть свои собственные источники тепла, которые помогают ей поддерживать пригодные для жизни условия: остаточное тепло и радиоактивный распад. У других каменистых миров тоже могут быть такие источники тепла.

Небольшой процент учёных продолжает идти по этому пути в поисках более подробных знаний о пригодных для жизни планетах. Оказывается, что существуют и другие источники тепла, которые потенциально могут питать жизнь, например, приливный разогрев. Приливный разогрев происходит на спутниках, где мощная гравитация гораздо более массивной планеты растягивает и сжимает спутник, когда она вращается по орбите. Это движение создаёт тепло, которое может способствовать сохранению жидкой воды и жизнеспособности. Именно это, по мнению учёных, происходит с некоторыми спутниками нашей Солнечной системы, такими как Европа, где тепло, вероятно, поддерживает тёплый жидкий океан под толстой ледяной шапкой.

Детекция мусора в гречке с помощью нейросети YOLO8n + попытки в real-time детекцию (Docker + FastApi, Gradio, TensorFlow Lite) + предложение добавить такую фичу в приложения продуктовых магазинов. За результатами приглашаю в статью.

Привет, постоянные и не очень читатели!

Пора вернуться к моим любимым архитектурам, процессорам, техпроцессам и всему причастному. Это седьмой и САМЫЙ масштабный материал из цикла (и, вероятно, во всём Рунете) про китайские ISA, микроархитектуры и микроэлектронику.

Что было раньше:

Part I: Скандальное разоблачение x86: ARM врывается с двух ног (58K, +61, 160 комментариев)

Part II: Этой индустрии нужен новый герой: ARM врывается с двух ног 

Part III: Китайский киднэппинг: похищение дочки 

Part IV: RISC‑V — звезда родилась: x86 не у дел, ARM сломала две ноги (67K, +64, 207 комментариев)

Part V: Смерть GPU/CPU на транзисторах — архитектура квантовых компьютеров

Part VI: У VLIW длиннее x86: Itanium в шаге от величества, Эльбрус — подержите моё пиво, тайны PS2 

Part VII: Как китайцы убили x86, ARM и создали своё — детектив в Восточном экспрессе ← ВЫ ЗДЕСЬ

Part VIII — ██████████████.

В этом лонгриде я расскажу вам всё о серверных процессорах из Поднебесной на всех ключевых архитектурах: ARM (Huawei), x86 (Zhaoxin), RISC-V (T-Head) и LoongArch (Loongson). Будет и про строящиеся мегафабрики Huawei, и про создание независимой ISA (как наш Эльбрус, но с конкурентными продуктами и производством), и про китайские лицензированные x86-процессоры, и про многое другое.

Бонусом в каждом разделе распишу интересные факты про иероглифы в названиях компаний и их продуктах (символизм в китайской культуре). Например, вы узнаете, как компания Медоед куёт свои процессоры из легендарной стали (образно), чтобы бесстрашно сражаться с западными техногигантами (буквально). И это не шутка, а оммаж на мемы про медоедов.

Дамы и господа — Восточный экспресс готов к посадке. Пожалуйста, позвольте стюарду проводить вас к личному купе.

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

В этой статье разбирается, как с нуля собрать минимально полезного бота для малого бизнеса (например, магазина одежды или студии услуг) на Python и библиотеке aiogram 3.x: от получения токена до развёртывания на сервере. Статья рассчитана на разработчиков, которые уже базово знакомы с Python, но ещё не работали с Telegram Bot API или современными фреймворками для ботов.

Постановка проблемы. Современные промышленные предприятия требуют принципиально новых решений, направленных на прогнозирование отказов работы оборудования и своевременное устранение нештатных аварийных ситуаций, управления затратами на ремонт, а также оптимизации и улучшения стратегий технического обслуживания. Существующие автоматизированные системы прогнозируемого обслуживания имеют различные функциональные ограничения. Это требует разработки новых архитектурных решений для создания интеллектуальных систем, способных обрабатывать большие объемы разнородных данных в режиме реального времени, прогнозировать отказы с высокой точностью и оптимизировать процессы плана обслуживания, в тесной взаимосвязи с работой устройств промышленного Интернета вещей в условиях использования новых технологий периферийного искусственного интеллекта. Данная работа посвящена исследованию возможности применения большой языковой модели OpenThinker2-32B, как вспомогательного инструмента для автоматизированной системы прогнозируемого обслуживания многостадийных технологических процессов. Данная модель может быть использована в реализации следующих функций автоматизированной системы: анализ исторических данных; прогнозирование оставшегося срока службы оборудования; подготовка данных для снижения факторов неопределенности данных для улучшения прогнозов; подготовка экспертных заключений; оптимизация расписаний по техническому обслуживанию промышленного оборудования.

Цель работы. Изучить возможность применения и адаптации большой языковой модели OpenThinker2-32B, как дополнительного и вспомогательного инструмента, применяемого для повышения эффективности работы автоматизированных систем прогнозируемого обслуживания многостадийных технологических процессов для малых и средних промышленных предприятий. Это позволит решить следующие задачи: выполнить анализ исторических данных; с помощью алгоритмов, разработанных на основе теории свидетельств Демпстера-Шафера снизить факторы неопределенности произвести прогнозирование отказов, а также подготовить экспертные рекомендации по оптимизации расписаний и процессов технического обслуживания промышленного оборудования. Также необходимо разработать алгоритмы информационного взаимодействия для каждой из задач, и определить положение большой языковой модели в предложенной концепции конвергентной архитектуры автоматизированной системы прогнозируемого обслуживания для повышения точности прогнозов и возможности ее интеграции с экспертными, аналитическими, прогнозными системами и системами поддержки принятия решений.

Привет, Хабр! Меня зовут Даниил Сухан, я занимаюсь разработкой AI-приложений в Just AI. Недавно вышедший AgentKit от OpenAI быстро стал одним из самых обсуждаемых инструментов в сообществе разработчиков.

Мы протестировали платформу для создания ИИ-агентов от OpenAI и сравнили её с нашей Agent Platform. В этой статье разбираем, как создаются агенты на обеих платформах, и в чём заключаются их принципиальные отличия.

Для начала давайте убедимся, что наш VPS находится в самом актуальном и обновленном состоянии. Подключаетесь к VPS через SSH. Запустите следующие команды, чтобы обновить систему и установить необходимые пакеты...

В этом семестре мы проходим в Висконсинском университете курс «Введение в алгоритмы» (577), где нам рассказывают о способах доказательства корректности программ, динамическом программировании, сетевом потоке и обстоятельствах, при которых Дейкстра изобрёл свой алгоритм поиска кратчайшего пути.

Однако этот курс стал для меня довольно уникальным тем, что оказался первым, требующим обязательного присутствия на лекциях. Проверка посещаемости реализована на основе платформы TopHat, которая известна многим студентам.

Чтобы доказать, что ты присутствовал на лекции, нужно указывать в TopHat четырёхзначный код (сообщаемый лектором). Достаточно ввести код на странице студента в TopHat, после чего он считается посетившим лекцию.

Однако, наверно, разработчики поняли, что у системы есть уязвимость, которую невозможно пропатчить — друзья. Если они учатся на том же курсе, что и ты, то лёжа в кроватке, можно отправлять им сообщения со слёзными просьбами поделиться кодом.

Поэтому для лекторов-параноиков TopHat реализовала фичу «надёжной проверки посещаемости», которая, согласно описанию, определяет местоположение «по геолокации устройства и близости к аудитории и другим студентам».

В этой статье я предлагаю свой экспертный взгляд на будущее антропоморфной робототехники. Он основан на анализе технологических трендов, состояния инфраструктуры и тех потребностей рынка, которые зачастую остаются неочевидными. В том числе познакомлю со своими прикладными исследованиями в области изготовления искусственных мышечных волокон, для применения в "мягкой" робототехнике.

KRepo: Никаких имплементаций или инъекций. Под капотом — динамический прокси, кэширование метаданных и независимость от фреймворков: плагины под Exposed, JDBC или MongoDB реализуются отдельно.

Автор вот этой статьи поднял вопрос, который наверное волнует тех, кто пользуется различными USB-токенами: как подключить USB-токен удаленно?

ИМХО, ничего сложного нет, я попробую это сделать, взяв тот же самый USB-токен.
Для начала и для общего представления - что есть что:

В Линуксе проброс USB устройств через сеть реализован на уровне ядра, то есть это не какая-то специальная программа, которая этим занимается, а драйвер в ядре.

Представьте консультанта в DNS/Ситилинке, который не навязывает «вот этот блок питания потому что остался на складе», а спокойно объясняет, чем один БП лучше другого под ваш билд, помнит, о чём вы спрашивали раньше и ещё просит вежливый фидбек.

В статье рассказываю, как собрал такого консультанта в виде Telegram‑бота «Кремний» — RAG‑бота по железу на бесплатных инструментах (Telegram Bot API, Groq с Llama 3.1 8B, sentence‑transformers) и что за «чуть‑чуть боли» произошло с NumPy и Pterodactyl при деплое.

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

В первой части мы разобрали процесс подготовки приложения к публикации и рассмотрели требования модерации в App Store и Google Play. Однако экосистема мобильных сторов сегодня значительно шире, и успешный релиз нередко включает размещение продукта в альтернативных магазинах, которые активно развиваются и набирают аудиторию.

В этой части мы рассмотрим пошаговый процесс размещения приложений в AppGallery и RuStore. Эти платформы имеют собственные правила, проверки безопасности, требования к данным пользователя и особенности технической интеграции, которые важно учитывать заранее. 

Материал предназначен для заказчиков, разработчиков, продакт-менеджеров и технических специалистов, отвечающих за релиз и сопровождение мобильных продуктов.

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

Cегодня поговорим о, наверное, самом серьезном этапе собеседования — live‑coding. На этом этапе вас просят писать код в реальном времени, под пристальным взглядом интервьюера.

На этом этапе выясняется, умеет ли кандидат решать задачи и писать код под реальными ограничениями времени и стресса.

Команда Spring АйО подготовила перевод статьи Джеффа Атвуда о том, почему попытки «спроектировать всё заранее» только мешают реальной разработке. Атвуд утверждает: без живого прототипа любые архитектурные решения превращаются в гадание на диаграммах. Хотите делать осознанный дизайн — поднимайте зад с кресла и пишите код.