Порт Linux-ядра на WebAssembly

Недавно один энтузиаст объявил о работе над портированием Linux-ядра на WebAssembly и уже смог запустить его в браузерах с поддержкой WASM

Порт ядра работает и позволяет выполнять базовые программы из командной оболочки прямо в веб-браузере. Однако есть проблемы со стабильностью и некоторыми браузерами

Разработчик так описал текущее состояние работы над WASM-ядром:

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

Демка здесь. Код на GitHub

@linuxos_tg

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

Linux:

@linuxos_tg

Благодаря WINE, Proton и железу от Valve был достигнут важный рубеж: 90% Windows-игр теперь запускаются на Linux, то есть девять из десяти игр для Windows становятся доступными на свежей установке Linux

@linuxos_tg

Сегодня первый день в Cloudflare: запушил небольшой апдейт и беру выходной на вторую половину дня

@linuxos_tg

Обновление: я перерос свою текущую роль в Cloudflare и сейчас ищу новую возможность. Прикрепляю своё резюме.

@linuxos_tg

Выбор очевиден

@linuxos_tg

Вышел Proxmox VE 9.1 с поддержкой OCI-контейнеров LXC

Proxmox VE 9.1 теперь поддерживает OCI-контейнеры на базе LXC, использует ядро Linux 6.17 и содержит улучшения в области виртуализации, безопасности и сетевых функций

Подробнее здесь

@linuxos_tg

Вот базовая концепция Linux

Почему нельзя запустить бинарник Linux в Windows, даже на одном и том же x86-процессоре?

Можно было бы свалить всё на разный формат файлов (ELF против .exe), но настоящая причина - ABI (Application Binary Interface).

ABI — это жёсткий "контракт", определяющий, как программа разговаривает с ядром. Бинарник компилируется не просто под конкретный CPU (x86), а под конкретный ABI (например, «Linux-on-x86»).

Чтобы вывести «Hello», программа не может просто напрямую писать на экран. Она должна попросить ядро сделать это.

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

Секрет в инструкции int $0x80.

Эта инструкция генерирует программное прерывание. Это такой "звонок", которым программа говорит CPU: «Стоп! Приостанови выполнение и передай управление ОС».

Ядро Linux просыпается, видит прерывание 0x80 и понимает, что пользовательское приложение запрашивает системный вызов. Оно смотрит в регистр %eax, видит число 4 и говорит: «Ага, это write». После чего послушно использует аргументы из %ebx, %ecx и %edx, чтобы выполнить работу.

У ядра Windows совершенно другие правила. Его системный вызов "write" – это не #4, и оно вообще, скорее всего, не реагирует на int $0x80.

Ваш Linux-бинарник говорит на языке Linux-контракта. Для ядра Windows это просто шум. Оно не понимает запрос и не будет его выполнять

@linuxos_tg

Принёс крутейший тренажёр по Kubernetes: Kubelab

Это готовая инфраструктура для обучения и экспериментов с K8s: поднимаешь локально и проходишь задания как в реальном кластере

Для каждой лабки есть подсказки и даже готовые решения. Плюс внутри уже есть Web UI и встроенный редактор кода

Опенсорс, бесплатно, забираем c GitHub

@linuxos_tg