От философов-антиреалистов, эзотериков и богословов часто можно услышать проповеди на тему ограниченности научных методов и о существовании за пределами физического мира иных планов бытия, которые нематериальны и не могут быть познаны экспериментальным путём. Но они не в курсе, что наука уже много лет занимается изучением контрфактуалов - «потусторонних» событий, происходящих не в нашей вселенной, но тем не менее подчиняющихся известным физическим законам. Учёные постоянно открывают новые способы «взломать» классическую физику и ставят умопомрачительные эксперименты, результаты которых заставляют нас пересмотреть традиционные определения реальности. Практика показывает, что природа познаваема и содержит в себе всё необходимое для роста знания, главное – задавать ей правильные вопросы. Как измерить светочувствительную бомбу, не подрывая её? Как провести вычисление, не включая компьютер? Как увидеть, не глядя, и узнать о событии, которое не произошло? Как подсмотреть за котом Шрёдингера и воскресить его? Как отменить коллапс волновой функции? Наконец, как осуществить настоящую телепортацию без локального обмена информацией? Если обычная квантовая телепортация, запутанность и туннелирование уже не кажутся вам чем-то удивительным, готовьтесь к настоящим чудесам. В этой статье я разберу пять экспериментов, о которых вы вряд ли слышали, но результаты которых действительно взрывают мозг.

Как говорил Альберт Эйнштейн, «наиболее необъяснимое во Вселенной – это то, что она объяснима». Но что делает Вселенную познаваемой? Почему работает научный метод? Как вообще прямоходящие кожаные мешки с обезьяньим мозгом могут что-либо узнать о физической реальности, если они всю жизнь проводят в виртуальной реальности своего сознания? Ведь всё, что нам известно о мире – продукты нашего разума. Не означает ли это, что мы никогда не сможем узнать, какова реальность на самом деле? Что мы вообще знаем, если Вселенная на 95% состоит из неведомых тёмных субстанций? Откуда мы знаем, что законы физики универсальны и постижимы человеческим разумом? Где гарантия, что законы физики изотропны в пространстве и однородны во времени? Может, они варьируются от места к месту, изменялись в прошлом или изменятся в будущем? Существует ли вычислительно более мощный компьютер, чем машина Тьюринга? Вычислима ли каждая физическая система? Является ли сама Вселенная вычислительной машиной? Каковы фундаментальные физические и логические ограничения на то, что может быть вычислено и постигнуто? Есть ли вычислительный барьер, который невозможно преодолеть, независимо от того, насколько далеко и какими способами развиваются компьютеры? Или новые типы оборудования, основанные на квантовых, релятивистских или квантово-гравитационных явлениях, могут привести к принципиально новым вычислительным парадигмам и сделать невычислимое вычислимым? В этой статье мы погрузимся в глубины теоретической информатики, чтобы выяснить, каковы фундаментальные пределы вычислимости и возможны ли в нашей Вселенной гиперкомпьютеры.

Эндрю Келли, создатель и ведущий разработчик языка программирования Zig, недавно рассказал о будущем асинхронного I/O в Zig, его ключевых примитивах, механизмах отмены и тонкости разграничения асинхронности и параллелизма. Он пригласил заинтересованных разработчиков к активному тестированию и формированию будущего интерфейса ввода-вывода Zig.

Это предварительный обзор новых примитивов асинхронного ввода-вывода, которые будут доступны в грядущем Zig 0.16.0, релиз которого ожидается примерно через три-четыре месяца. Есть еще много чего обсудить, но пока это вводная часть к основному API синхронизации, который будет доступен для использования во всем коде Zig.

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

Команда Go for Devs подготовила перевод статьи о новом экспериментальном сборщике мусора Green Tea, появившемся в Go 1.25. Он уже используется в Google и показывает снижение затрат CPU на GC до 40%. Разбираемся, почему это не просто оптимизация, а новый уровень эффективности.

Подробное описание аргументов, доступных при создании воркеров в Node.js и как их можно использовать для многопоточки в серверном JavaScript

Автор: Шерстнев Павел

Что если модель могла бы проектировать саму себя? Подбирать архитектуру, параметры, операторы — без эксперта, без ручного тюнинга и десятков итераций? Эволюционные алгоритмы позволяют это сделать. Я собрал их в рабочую технологию — Thefittest — open-source проект, где эволюция используется для построения и оптимизации моделей машинного обучения.

LLM встраивают в продакшн-системы, но подходят к ним как к обычным библиотекам — подключил API и забыл. Проблема в том, что языковая модель выполняет инструкции из пользовательского ввода, генерирует код, обращается к базам данных. Если не учитывать специфику этих систем, можно получить утечку данных или компрометацию всего приложения. OWASP выделил десять критических уязвимостей в LLM-приложениях — разбираем каждую с примерами атак и способами защиты.

Недавно наткнулся на интересный open-source проект под названием Open Notebook. Это такая альтернатива Google Notebook LM, только с открытым кодом и кучей дополнительных возможностей. Сам пока не тестировал, но штука выглядит настолько интересно, что решил рассказать.

Сейчас AI-инструменты используют все подряд, и вопросы приватности становятся всё острее. Open Notebook как раз предлагает решение — полный контроль над данными, поддержка разных AI-моделей и возможность развернуть всё у себя на сервере.

Что это вообще такое

Open Notebook — это система для организации знаний с поддержкой AI. Можно загружать исследовательские материалы, анализировать информацию и получать инсайты из разных источников. Главное отличие от облачных решений — можно развернуть на своём сервере, и никто кроме вас не будет иметь доступа к данным.

По функционалу это полноценная замена Google Notebook LM, но с открытым исходным кодом и гораздо большими возможностями настройки. Работает с PDF, видео, аудио, веб-страницами и документами Office.

Что умеет

Возможностей там прилично:

Поддержка 16+ AI-провайдеров. Можно подключить модели от OpenAI, Anthropic, Google, Ollama, LM Studio, Mistral, DeepSeek, xAI, Groq, Perplexity и других. То есть выбираешь то, что подходит по цене и качеству для конкретной задачи.

Генерация подкастов. Система создаёт многоголосые подкасты на основе загруженных материалов — от 1 до 4 спикеров. У Google Notebook LM, кстати, максимум два спикера.

Умный поиск. Есть полнотекстовый и векторный поиск по всему контенту. Удобно, когда накопилось много материалов.

Первый Docker-образ для моего Go-приложения весил 1.92 GB. Для микросервиса на 100 строк — абсурдно. Решил разобраться, куда именно уходит место и как добиться максимально лёгкого образа.

Собрал production ML-сервер на двух RTX 2060 из хлама за ₽0. PyTorch + CUDA 11.8 + Stable Diffusion генерируют 512x512 за 38 секунд. YOLOv8 работает параллельно на второй GPU. Вот полный гайд: от BIOS настроек до первого теста. Никакого облака, только локальное железо.

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

Представьте: клиент отправил важный POST-запрос (например, создание заказа или списание денег), но из-за сетевого сбоя не получил ответ. Не зная, что на сервере операция уже выполнилась, клиент пробует повторить запрос. Если бэкенд не подготовлен к таким дублям, итог может быть печальным: мы создадим две одинаковые записи вместо одной или, хуже того, спишем деньги с пользователя два раза. Как этого избежать? Правильный ответ — реализовать идемпотентность в API.

Транзакции — не про «магическое ACID», а про конкретную механику согласованного доступа к данным под нагрузкой.

Эта статья объясняет как реально работают уровни изоляции и чем отличаются популярные СУБД на практике.

Мы разберём:

Человечество тысячелетиями рассказывало истории, а теперь на этих историях учатся LLM.

Что такое нарратив? Это история с сюжетом, помните? — Город, герои и возвращение. Но мы не будем углубляться в философскую глубину, где люди создают историю, чтобы осмыслить себя и свой опыт (желающие могут почитать Karl E. Weick), а рассмотрим, как можно применить нарративы в понимании работы LLM.

База данных — это сердце системы. И в какой-то момент это сердце начинает давать сбои. Не от объема данных, а от их разнородности. Таблица users разрастается до 200 колонок. Одни нужны для логина каждую секунду, другие — для годового отчета раз в год. В итоге, чтобы прочитать два "горячих" поля, база тащит с диска целый блок с "холодными" данными. Это неэффективно.

Общемировой объем научных статей, книг и профильной документации растет с каждым днем. Чтобы ориентироваться в интересующем корпусе знаний, находить инсайты и ответы на вопросы, специалисты все чаще используют ИИ-помощников. Мы в Beeline Cloud решили взглянуть на open source-проекты в данной области.

Когда вы работаете с распределённой системой — будь то микросервисы, фронтенд + бэкенд или nginx + приложение — жизненно важно иметь возможность «протянуть» один и тот же идентификатор запроса через все её компоненты. Это позволяет сопоставлять логи из разных источников, быстро находить ошибки и проводить корреляционный анализ.

В nginx для этого из коробки есть переменная $request_id — 32-символьный hex-идентификатор (например, a1b2c3d4e5f678901234567890abcdef). Его можно передать бэкенду через proxy_set_header X-Request-ID $request_id; или fastcgi_param HTTP_X_REQUEST_ID $request_id;, а также сохранить в access-логах.

Однако стандартный $request_id — это просто случайная строка без временной привязки и без структуры, удобной для аналитики. В этой статье мы рассмотрим, как улучшить ситуацию с помощью ULID и UUIDv7.

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

Добрый день. Сегодня мы поговорим о двух мощных технологиях для асинхронного обмена данными — ActiveMQ Artemis и Apache Kafka. Мы разберемся, что они из себя представляют, как устроены под капотом, и главное — в каких ситуациях стоит выбрать одну, а в каких другую.

Наш план на сегодня довольно насыщенный. Мы начнем с того, почему вообще все пришли к асинхронному общению сервисов. Затем подробно разберем ActiveMQ Artemis — что это и какие задачи решает. Заглянем в его техническую архитектуру, чтобы понять источник его производительности. После этого мы кратко вспомним основы Apache Kafka, чтобы затем перейти к самому интересному — детальному сравнению. Мы составим четкие рекомендации, поговорим о нагрузочных характеристиках и подведем итоги.

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

Привет, Хабр. Меня зовут Алексей Белозерский. Я руководитель профессионального сервиса VK Data Platform, VK Tech. В этой статье я расскажу, что стало предпосылкой появления нового формата данных и что скрывает Iceberg «под толщей воды».

Когда в инфраструктуре десятки сервисов и баз данных разных типов, ручное резервное копирование превращается в кошмар.

Один сервер использует PostgreSQL, другой — MySQL, третий — MongoDB, и для каждого нужны свои команды (pg_dump, mysqldump, mongodump) и свои скрипты.

Проект Dumper решает эту проблему он объединяет все типы баз в один универсальный инструмент.

Dumper написан на Go и работает через CLI, конфигурация задаётся в YAML — поэтому его легко встроить в cron, CI/CD pipelines, GitHub Actions или Docker-окружение.