Hacker News Digest

Автор экспериментирует с созданием простого брокера сообщений, используя только два UNIX сигнала вместо сложных систем вроде Kafka. Он объясняет, что сигналы обычно применяются для управления процессами, но предлагает использовать их для обмена сообщениями. Автор рассматривает различные формы IPC в UNIX, включая каналы, сокеты и файлы, а затем фокусируется на сигналах SIGUSR1 и SIGUSR2, которые являются пользовательскими и могут использоваться для собственных целей.

Основная идея заключается в представлении сообщений как последовательности битов, где каждый бит кодируется соответствующим сигналом (0 - один сигнал, 1 - другой). Это позволяет передавать данные между процессами, используя минимальные системные ресурсы. Автор демонстрирует, как можно "взломать" стандартное поведение сигналов для создания эффективной системы обмена сообщениями, опираясь на двоичное представление данных и возможность перехвата сигналов в коде на Ruby.

• Обсуждение показало, что статья вызвала бурную реакцию: от восторга до критики за clickbait-заголовок и «техническую» неточность.
• Комментаторы подчеркнули, что UNIX-сигналы не предназначены для передачи данных, не гарантируют очередность и могут терять сигналы при конкурентном доступе.
• Было отмечено, что вместо сигналов можно использовать уже готовые механизмы, такие как POSIX message queues.
• Некоторые отметили, что статья может быть интересна как учебный материал, но не как руководство к действию.
• В итоге, обсуждение показало, что читатели ожидают более честных и точных заголовков и отсутствия сенсационализма, даже в контексте развлекательных экспериментов.

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

Ключевые компоненты включают расширенную подсистему kexec для загрузки образов, фреймворк межъядерного обмена сообщениями через IPI и механизмы инициализации CPU для x86. Реализация сохраняет обратную совместимость и добавляет интерфейс /proc/multikernel для мониторинга. Пока это черновая версия, требующая тестирования и доработки, но открывающая возможности для zero-down обновлений ядра и новых сценариев изоляции workload'ов.

• Обсуждаются технические сложности совместного использования аппаратных ресурсов несколькими ядрами, включая управление состоянием драйверов, DMA и аппаратными синглтонами (PCI, ACPI).
• Проводятся параллели с существующими архитектурами и проектами: exokernel, Barrelfish OS, OpenVMS Galaxy, CoLinux, Kerrighed и LPAR на мейнфреймах IBM.
• Поднимаются вопросы безопасности: потенциальные уязвимости при совместном доступе к памяти через DMA, отсутствие изоляции между доверенными ядрами и ограниченный периметр атаки при компрометации одного ядра.
• Отмечаются потенциальные преимущества: улучшенная изоляция сбоев (устойчивость к паникам ядра), высокая производительность без накладных расходов виртуализации и возможность запуска разнородных ОС (Linux и BSD).
• Упоминается коммерческий контекст: автор работает над этим в рамках стартапа multikernel.io, что вселяет надежду на понимание производственных сложностей.